Expertise · Infrastructure et exploitation

Nous mettons l’application sur un serveur que nous contrôlons, avec une publication réversible, des sauvegardes vérifiées et un endroit où l’on voit quand quelque chose est tombé.

Hébergement, mise en service, surveillance et continuité pour les applications web et les plateformes avec base de données. Nous travaillons sur une infrastructure que le client peut revendiquer : machines virtuelles chez des fournisseurs européens, nginx, processus sous supervision, conteneurs, base de données auto-hébergée. Cela inclut la réponse à la question « où sont réellement mes données ».

Discuter d'un projet

Déjà construitOperăm în acest fel mai multe sisteme proprii, iar configurațiile sunt în depozite, nu doar pe servere. Site-ul acesta rulează pe nginx cu Next.js 16 sub PM2, la OVHcloud București. Platforma de asistenți rulează pe Microsoft Azure, Poland Central, cu MySQL, Redis și RabbitMQ în containere legate la interfața locală. O platformă civică proprie folosește unități systemd cu publicare prin comutare atomică de legătură simbolică, copie de siguranță zilnică verificată și o sarcină separată de retenție care rulează numai dacă acea copie a reușit. Un board intern se publică prin runner propriu, cu acțiuni GitHub fixate pe amprentă completă și cu revenire automată la versiunea anterioară dacă verificarea de sănătate cade după publicare. Rezerva care trebuie spusă: gradul de automatizare diferă de la sistem la sistem. Publicarea acestui site se face încă manual, iar migrările de bază de date sunt aplicate cu mâna, deliberat. Nu vindem un lanț automat pe care nu îl avem peste tot.

Une application qui fonctionne sur un ordinateur portable et une qui fonctionne en production se distinguent par des choses qu’on ne voit pas dans l’interface : ce qui se passe quand le processus meurt à trois heures du matin, ce qui se passe quand une publication se passe mal, où vont les journaux, qui apprend en premier qu’un problème est survenu et d’où l’on récupère la base de données si le disque disparaît. Ce service s’occupe exactement de cette partie.

Le choix de base que nous proposons est l’infrastructure que le client peut revendiquer : une machine virtuelle chez un fournisseur européen, nginx en façade, des processus sous un superviseur, des conteneurs là où cela a du sens, une base de données auto-hébergée là où l’indépendance compte plus que la commodité. Non pas parce que les plateformes gérées seraient mauvaises — mais parce qu’un jour vous voulez pouvoir tout prendre et partir, et si cela n’a pas été pensé dès le départ, cela ne peut plus se faire à bon marché.

La question de la souveraineté des données n’a qu’une réponse honnête : une réponse vérifiée. L’emplacement se confirme en interrogeant le service de métadonnées de la machine virtuelle et le registre des adresses, et non en lisant la page marketing du fournisseur. La différence n’est pas théorique — pour un transfert à l’intérieur de l’Espace économique européen, le chapitre des transferts de la Loi 195/2024 ne s’applique tout simplement pas. Une migration que nous avons réalisée a déplacé une plateforme d’une base de données hébergée aux États-Unis vers une pile auto-hébergée dans l’Union européenne, précisément pour cette raison.

Ce que nous ne promettons pas : que tout est automatique. Nous appliquons les migrations de schéma à la main, délibérément, parce qu’une migration appliquée automatiquement en production par une chaîne qui ne sait pas ce qu’il y a dans la table est la manière habituelle de perdre des données. La publication du code s’automatise ; le changement de structure de la base reste une décision humaine, avec une sauvegarde fraîche derrière.

Ce que cela comprend

Le travail, par composantes

Publication réversible, avec vérification après, pas seulement avant

La publication ne se termine pas lorsque les fichiers sont arrivés sur le serveur, mais lorsqu’une requête réelle prouve que la nouvelle version est bien celle servie. Dans l’une des implémentations, le script synchronise le répertoire, conserve la version précédente à côté, puis extrait le nom du paquet depuis la page livrée et vérifie sur l’adresse publique que c’est bien ce fichier exact qui est servi; sinon, il revient tout seul à la version précédente. Ce n’est pas théorique: le mécanisme a détecté un paquet resté ancien dans le répertoire du runner et a annulé une publication qui, sinon, aurait semblé réussie.

Basculement atomique de version, avec le processus sous systemd

L’alternative à « on arrête, on copie par-dessus, on redémarre » est le répertoire de versions plus un lien symbolique basculé en une seule opération. L’unité systemd pointe toujours vers le chemin stable, et le retour en arrière signifie rebascule du lien. L’unité a une politique de redémarrage en cas d’échec avec une courte pause, un temps d’arrêt maximal, et des restrictions système: sans élévation de privilèges, système de fichiers protégé, répertoires personnels inaccessibles, avec une liste explicite de chemins dans lesquels elle a le droit d’écrire.

nginx en frontal, avec des limites écrites pour le cas réel

Terminaison TLS avec renouvellement automatique du certificat, HSTS avec une durée d’un an et inclusion des sous-domaines, compression avec seuil minimal de taille, ressources statiques avec expiration longue et marquage immuable, et l’application liée à l’interface locale afin de ne pas pouvoir être atteinte directement depuis Internet. Les limites de débit se définissent par type de trafic, pas globalement. Une leçon payée mérite d’être dite: sous HTTP/2, la limite de connexions compte les flux, pas les connexions — à une valeur faible, un seul chargement de page se renvoie lui-même ses polices et scripts avec 429.

Copie de sauvegarde qui se vérifie, pas seulement qui s’exécute

Tâche quotidienne programmée, avec lancement au prochain boot si la machine était arrêtée à l’heure correspondante et avec un délai aléatoire pour que tout ne démarre pas à la même seconde. L’export de la base est compressé, et si le fichier obtenu est vide, l’exécution est traitée comme un échec — un export qui se termine « avec succès » et produit zéro octet est la manière habituelle de découvrir, six mois plus tard, qu’il n’existe aucune copie. Les fichiers du dépôt d’objets sont synchronisés séparément. Une copie 100 % locale ne survit pas à la perte du disque, donc la copie part aussi en dehors de la machine, dans un compte de stockage de l’Union européenne avec réplication géographique, versioning, suppression réversible et expiration automatique — avec accès via identité gérée, afin qu’aucune clé de stockage ne se trouve sur le disque.

La suppression programmée ne s’exécute qu’après une copie réussie

La tâche de rétention dépend explicitement de celle de copie et démarre après elle. Un nettoyage sans copie fraîche est la seule forme de suppression dont on ne revient pas. Contrairement à la copie, la suppression ne récupère pas les exécutions manquées: si la machine était arrêtée, on ne supprime pas deux fois le lendemain. Chaque exécution écrit une ligne dans un tableau d’exécutions, et avant la première activation réelle la tâche tourne à vide pendant au moins une semaine et le journal est lu.

Des alertes qui ne mentent pas et ne spamment pas

Une tâche programmée qui renvoie 200 ne veut pas dire qu’elle a fonctionné. Notre enveloppe d’exécution lit le corps de la réponse et y cherche les échecs partiels, puis envoie une alerte avec limitation de fréquence, afin qu’un service en panne toute la journée ne produise pas quatre-vingt-seize messages identiques. La raison de son existence: un rapport quotidien a été mort onze jours de suite, et la seule trace était un vide dans un tableau que personne ne regardait. La tâche programmée s’était déclenchée les onze fois.

Chaîne de publication qui ne peut pas être détournée en amont

Les actions du flux d’intégration sont fixées sur l’empreinte complète du commit, pas sur l’étiquette. En mars 2026, une action populaire a été redirigée des étiquettes `v1`…`v45` vers du code malveillant et a touché plus de 23.000 dépôts en 24 heures ; une empreinte ne se déplace pas. Le flux ne conserve pas d’identifiants dans la copie de travail, et la publication ne passe pas par un jeton : elle passe par un runner propre, sur la machine cible, avec des droits accordés ponctuellement. Ainsi, aucune clé d’accès au serveur ne reste dans la plateforme de code.

Conteneurs avec limites, vérifications de santé et journaux qui ne remplissent pas le disque

Chaque service a une politique de redémarrage, une vérification de santé propre (préparation de la base de données, un point d’état de l’application), des limites de processeur et de mémoire lorsque la charge l’exige, et la rotation des journaux au niveau du moteur de conteneurs, avec taille maximale et nombre de fichiers. Les ports des bases de données sont liés à l’interface locale, jamais publics. Les variables obligatoires sont déclarées de sorte que le conteneur refuse de démarrer si elles manquent, au lieu de démarrer avec une valeur par défaut dangereuse.

Base de données auto-hébergée, quand l’indépendance compte

Pile complète en conteneurs — base de données, authentification, interface REST, canal temps réel, stockage de fichiers, passerelle d’accès — avec les extensions activées explicitement et avec les paramètres de mémoire et de connexions adaptés à la machine, et non laissés aux valeurs par défaut. Les migrations sont des fichiers versionnés dans le dépôt et s’appliquent manuellement, avec redémarrage du composant qui garde son schéma en mémoire. La raison de ce choix est simple: une plateforme gérée en dehors de l’Union européenne peut être excellente techniquement et pourtant inadaptée juridiquement.

À quoi cela ressemble

Le parcours, étape par étape.

Nous inventorient ce qui existe et ce qui peut être perdu

Ce qui tourne effectivement sur la machine, sous quel superviseur, avec quelles versions, avec quels ports exposés ; quelles copies de sauvegarde existent et si l’une d’elles a déjà été restaurée ; quels secrets ont fini dans les dépôts ; quelle est la différence entre la configuration du dépôt et le fichier sur le serveur. Le dernier point produit presque toujours des surprises — nous avons nous-mêmes documenté un cas où le fichier sur le serveur avait été modifié directement, hors dépôt, et avait laissé à côté de lui une copie de secours horodatée. Nous livrons l’inventaire et la liste des points uniques de défaillance.

Nous mettons en place la base : serveur, nginx, processus, hardening

Pare-feu qui refuse par défaut les entrées et n’ouvre que ce qui est nécessaire, protection contre les tentatives répétées d’authentification, espace de swap dimensionné, nginx avec TLS et renouvellement automatique, application liée à l’interface locale, superviseur de processus configuré pour démarrer au boot. Nous livrons les configurations dans le dépôt, pas seulement sur la machine, afin que la personne suivante n’ait pas à les reconstruire de mémoire.

Nous rendons la publication répétable et réversible

Script de publication avec conservation de la version précédente, vérification de santé après publication et retour automatique en cas d’échec. Là où il y a une équipe et de l’intégration continue, nous ajoutons un runner propre sur la machine cible, avec des actions figées sur l’amprunte et sans credentials dans la copie de travail. Nous livrons la procédure écrite et un retour exécuté devant le client — un retour non testé n’est pas un retour.

Nous mettons en place les copies, la rétention et les alertes

Copie quotidienne avec vérification que le fichier n’est pas vide, copie hors de la machine dans une région de l’Union européenne, tâche de rétention qui ne s’exécute qu’après une copie réussie et laisse une trace, plus des alertes avec limitation de fréquence qui lisent le contenu de la réponse, pas seulement le code de statut. Nous livrons une restauration de test réellement effectuée et son journal.

Nous remettons les clés et écrivons ce qui reste non fait

Accès dans un compte propre, documentation d’exploitation, liste des tâches programmées et — obligatoirement — la liste honnête des choses qui n’ont pas été automatisées et pourquoi. Chez nous, deux restent presque toujours sur la liste : les migrations de schéma, appliquées à la main de manière délibérée, et la publication de ce site, qui est encore manuelle.

Straturile unei instalări, de jos în sus: mașina virtuală într-o regiune europeană confirmată, motorul de containere cu rotația jurnalelor, baza de date cu copia zilnică verificată și copia din afara mașinii, procesele sub supraveghetor cu repornire la eșec, nginx cu TLS și limite de rată — iar lateral, lanțul de publicare cu versiunea anterioară păstrată și revenirea automată.

Les données

Ce que nous touchons, où elles sont et combien de temps elles restent

Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.

Où se trouvent effectivement les données et comment cela se vérifie: L’emplacement se confirme depuis la machine, pas depuis la documentation : le service de métadonnées du fournisseur indique la région réelle, et le registre d’adresse indique le pays. Nos systèmes se trouvent chez OVHcloud, București, România et sur Microsoft Azure, Poland Central — tous deux dans l’Espace économique européen. Les copies de sauvegarde de la plateforme civique se trouvent dans une région nordique de l’Union, avec réplication vers une deuxième région elle aussi située dans l’Union. Ces lignes ont remplacé une liste plus longue d’emplacements que nous n’avons pas pu confirmer.
Ce que nous voyons pendant le travail: Configuration, journaux, schéma de la base et état des processus. Le contenu des données personnelles ne fait pas partie du travail ; lorsque le dépannage exige néanmoins un exemple, on utilise un cas créé à cet effet. L’accès administratif est accordé pendant l’intervention, nominativement, et retiré à la fin — et la révocation est vérifiée, non supposée.
Les journaux et leur durée de vie: Les journaux web de ce site sont rotés quotidiennement, avec quatorze exemplaires conservés, avec des droits de lecture restreints au groupe d’administration. Au niveau des conteneurs, la rotation est effectuée par le moteur de conteneurs, avec une taille et un nombre de fichiers fixés, afin qu’un service trop bavard ne remplisse pas le disque et n’arrête pas la base de données — la manière la plus banale de faire tomber une production.
Les secrets ne sont pas dans le dépôt: Les valeurs sensibles entrent depuis des fichiers d’environnement à droits restreints, lus par l’unité système, non écrits dans l’unité — car la définition d’une unité et le journal système sont lisibles par plus de personnes qu’on ne le croit. Dans la chaîne de publication, le fichier d’environnement de production ne passe pas par la plateforme de code : il est copié localement sur la machine et supprimé immédiatement après la construction. Lorsqu’on reprend une infrastructure existante, le premier passage est toujours un inventaire des secrets arrivés dans les dépôts, avec un plan de rotation.
La continuité : ce qui se passe quand nous partons: La transmission signifie un accès en propre chez le fournisseur d’infrastructure, le dépôt avec toutes les configurations de serveur, la procédure de publication et de retour en arrière, celle de restauration de la copie de sauvegarde — testée, pas seulement écrite — et la liste des tâches planifiées avec la fonction de chacune. Le verrouillage contre la suppression accidentelle est mis dès le départ sur le groupe de ressources de production.

Un cas

Un rapport quotidien qui ne tournait plus depuis onze jours, dans un système où tout répondait 200

La situation

Dans une plateforme interne propre, plusieurs routines automatiques produisent chaque jour des rapports et nettoient des données. Les tâches étaient lancées depuis l’intérieur de l’application, avec des compteurs en processus. Rien n’indiquait un problème : le service était démarré, l’adresse répondait, les journaux ne contenaient pas d’erreurs.

Ce que nous avons construit

Le rapport quotidien manquait depuis onze jours, et la seule trace était un vide dans un tableau que personne ne consultait. Deux défauts distincts sont apparus. Le premier : un compteur lancé à l’intérieur de l’application se réinitialise à chaque redémarrage du service, donc une routine avec un intervalle plus long que l’intervalle entre les publications ne se déclenche jamais. Le second, plus insidieux : la routine avait été déclenchée correctement les onze fois et avait renvoyé à chaque fois le code 200 — mais le corps de la réponse contenait des échecs partiels que personne ne lisait.

Ce qui en est sorti

La programmation a été déplacée en dehors de l’application, vers un planificateur système auquel les redémarrages importent peu. L’exécution a été enveloppée dans un script qui écrit une ligne de journal par exécution, parcourt le corps de la réponse à la recherche de clés d’échec et envoie une alerte vers un canal de messagerie — avec une limitation de fréquence, afin qu’une dépendance tombée toute la journée ne produise pas quatre-vingt-seize messages identiques. Une réponse 200 avec des échecs internes a désormais son propre état, distinct du succès.

Ce que le cas ne dit pas

Rien de tout cela n’a été un problème d’infrastructure au sens classique : le serveur tournait, le disque avait de la place, le processus était vivant. C’est précisément pour cela que cela a duré onze jours. Les défauts d’exploitation les plus coûteux ne sont pas les pannes — celles-là se voient — mais les choses qui signalent le succès sans rien faire. La vérification de santé qui compte ne demande pas « êtes-vous démarré ? », mais « avez-vous fait ce qu’il fallait, autant de fois qu’il le fallait ? » .

Questions

Ce que les gens nous demandent avant d'appeler

Où nos données seront-elles effectivement stockées ?

Là où vous choisissez, et nous vérifions que c’est bien là. Nos systèmes sont hébergés chez OVHcloud, Bucarest et sur Microsoft Azure, Poland Central, tous deux dans l’Espace économique européen, et l’emplacement a été confirmé en interrogeant le service de métadonnées de la machine virtuelle et le registre d’adresse — pas en lisant la documentation du fournisseur. La vérification compte : pour un transfert à l’intérieur de l’Espace économique européen, le chapitre sur les transferts de la Loi n° 195/2024 ne s’applique pas et aucune autorisation spéciale n’est nécessaire. En dehors de celui-ci, un dossier de garanties apparaît.

Pourquoi un serveur propre et pas une plateforme gérée ?

Pas toujours. Une plateforme gérée est le bon choix quand l’équipe est petite, que le trafic est irrégulier et que rien dans la pile n’a d’exigences de résidence. Le serveur propre devient le meilleur argument dans trois situations : quand les données doivent rester dans une juridiction précise, quand le coût devient imprévisible à l’échelle, et quand vous voulez pouvoir tout prendre et partir. Nous avons aussi fait la migration inverse pour un système propre : d’une base de données hébergée aux États-Unis vers une pile auto-hébergée dans l’Union européenne, avec huit conteneurs — base de données, authentification, interface REST, temps réel, stockage, métadonnées, panneau et passerelle d’accès.

Que se passe-t-il si une publication se passe mal ?

On revient en arrière, et de préférence tout seul. La version précédente reste sur le disque à côté de la nouvelle, et après la publication une vérification demande la page réelle et confirme que le fichier servi est bien celui qui vient d’être construit ; sinon, le script revient automatiquement en arrière. Là où nous utilisons le basculement atomique du lien symbolique, le retour en arrière n’est qu’une seule opération. Ce n’est pas une description de brochure — le mécanisme a déjà attrapé une publication avec un ancien paquet resté dans le répertoire de travail du runner et l’a annulée.

Faites-vous des copies de sauvegarde ? À quelle fréquence et les testez-vous ?

Tous les jours là où nous l’avons construite — et nous le soulignons, parce qu’une copie automatique n’apparaît pas d’elle-même quand vous déplacez une application sur un serveur. La copie s’exécute à heure fixe, est récupérée au prochain démarrage si la machine était éteinte, et si l’export est vide l’exécution est traitée comme un échec. La copie part aussi hors de la machine, vers une région de l’Union européenne, avec réplication, versioning, suppression réversible et expiration automatique. Le test de restauration fait partie de la livraison : une copie jamais restaurée est une hypothèse, pas une copie.

Qui est le premier informé quand quelque chose tombe ?

Cela dépend de ce que nous avons construit, et cela mérite d’être dit sans fioritures. Les vérifications de santé au niveau du conteneur et les points d’état des applications existent ; l’alarme vers un canal de messagerie, avec limitation de fréquence, existe là où nous l’avons construite. Un point de vérification d’état que personne n’interroge n’est pas de la surveillance — c’est une page. Si vous voulez une vraie surveillance, c’est une étape séparée, avec un observateur externe qui interroge périodiquement et un destinataire de l’alerte qui a le droit d’être réveillé.

Appliquez-vous automatiquement les migrations de la base de données à chaque publication ?

Non, et c’est une décision prise en toute connaissance de cause, pas un oubli. La chaîne de publication construit et copie le code ; rien de plus. Les changements de schéma sont des fichiers versionnés dans le dépôt, appliqués manuellement, avec une sauvegarde fraîche en arrière-plan, et les composants qui gardent leur schéma en mémoire sont redémarrés après. Une migration appliquée automatiquement en production par un processus qui ne sait pas ce qu’il y a dans le tableau est la façon habituelle de perdre des données de manière irréversible.

Comment évitez-vous que votre chaîne de publication devienne une voie d’attaque ?

Par trois règles. Les actions externes sont fixées sur l’empreinte complète du commit, pas sur l’étiquette — en mars 2026, une action largement utilisée a été redirigée de ses étiquettes vers du code malveillant et a touché plus de 23.000 dépôts en 24 heures. La copie de travail ne conserve pas de credentials. La publication ne se fait pas avec une clé d’accès stockée dans la plateforme de code, mais via un exécuteur propre qui s’exécute sur la machine cible, avec des droits accordés ponctuellement. Nous reconnaissons que tous nos projets plus anciens ne respectent pas encore ces trois règles ; leur migration est un travail en soi.

Reprenez-vous une infrastructure faite par quelqu’un d’autre ?

Oui, et la première étape est toujours un inventaire, pas une modification. Ce qui s’exécute réellement, sous quel superviseur, avec quelles versions, quels ports sont exposés, quelles sauvegardes existent, si l’une d’elles a déjà été restaurée, quels secrets ont fini dans les dépôts et dans quelle mesure la configuration du dépôt ressemble encore au fichier du serveur. Le dernier contrôle produit presque toujours quelque chose : nous avons documenté, dans un projet propre, un fichier de configuration modifié directement en production, qui a laissé une copie de sauvegarde horodatée à côté.

Que se passe-t-il si nous voulons travailler avec quelqu’un d’autre ?

Vous partez avec tout. L’infrastructure repose dès le départ sur vos comptes chez le fournisseur, et la remise inclut le dépôt avec toutes les configurations de serveur, la procédure de publication et de retour en arrière, la procédure de restauration testée et la liste des tâches programmées avec ce que fait chacune. Le verrouillage contre la suppression accidentelle du groupe de ressources de production est mis en place dès l’installation. Si un fournisseur conditionne votre départ à la réécriture de l’infrastructure, c’était le problème, pas la technologie.

Sur quoi reposent les affirmations ci-dessus (30 sources)

https://www.megapromoting.com răspunde 200 pe nginx + Next.jshttps://www.megapromoting.com/servicii · 2026-09-06

29 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.

Comment nous travaillons Tous les services

Qu'est-ce que vous voudriez voir mieux fonctionner ?

Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.

Discutons