Le run
Livrer est une chose.
Tenir dans la durée en est une autre.
Une application en production sert un métier tous les jours. Nous l’exploitons avec la même règle que nous la construisons : on prouve, on ne suppose pas. Voici comment nous livrons, surveillons, sauvegardons et protégeons la flotte, et comment nous revenons en arrière quand il le faut.
- 6
plateformes Hub en service - 69
versions du Hub consignées en sept semaines - 30 min
entre deux vérifications de version par les gardiens - 5 min
entre deux remontées d’état de chaque site surveillé
Livrer une application : la recette d’abord, la production ensuite
Nous tenons deux environnements séparés : une recette, où l’on éprouve, et une production, qui sert les utilisateurs. Les deux tirent leurs images du même registre. Ils ne se confondent jamais.
Situer
Quelle version tourne en recette, laquelle en production, ce que porte le dépôt, ce qui n’est pas encore enregistré. Si la production est en avance sur la recette, on s’arrête et on le dit : quelque chose a été livré sans passer par l’épreuve.
Construire
L’application est construite, ses tests tournent, l’interface est vérifiée avant d’être compilée. On ne livre pas sans avoir vu les tests verts.
Publier une image neuve
Chaque livraison reçoit une étiquette neuve, et la version du code change avec elle. Une étiquette n’est jamais réutilisée : sans cela, plus de retour arrière possible.
Poser en recette et éprouver
La fonction livrée est vue, pas supposée : une requête qui rend le contenu attendu, une capture, une ligne en base. Les preuves sont rangées avec la version, dans un dossier daté.
Promouvoir en production, sur accord
La production reçoit exactement l’image déjà éprouvée, et la même batterie de vérifications. On ne reconstruit pas, on ne renumérote pas : une image reconstruite n’est plus celle qui a été vérifiée.
Savoir revenir
L’image précédente reste disponible. Le retour arrière, c’est elle, reposée. Rien à changer côté routage : la route vise le service, pas une version.
Un conteneur qui tourne n’est pas un service qui répond
Une livraison n’est jamais déclarée faite sur la foi de l’état d’un conteneur. La vérification, c’est une requête qui rend le contenu attendu.
Les pièges deviennent des fiches
Chaque piège rencontré en livrant une application est consigné : son symptôme, sa cause, son remède. Dix-sept fiches à ce jour ; le suivant ne les repaie pas.
Livrer la plateforme : le canary d’abord
Le Hub sert toutes les applications : s’il ne redémarre pas, tout tombe. Sa livraison obéit donc à trois règles de plus : un canary avant toute production, la configuration de la cible sauvegardée avant toute modification, et aucune conclusion tirée de la seule liste des conteneurs.
Le canary : la nouvelle version, lancée à part
Avant toute production, la nouvelle version démarre seule, sur une copie du schéma réel de la base cible, restaurée dans une base jetable. Elle tourne sans accès aux secrets de production, sans pouvoir piloter les conteneurs, sur un réseau à part. Neuf sondes l’interrogent : démarrage complet, sécurité qui refuse par défaut, tableau de bord fermé, page de connexion, description des API, historique des migrations inchangé. Il faut une vingtaine de minutes. Un défaut trouvé là est un succès.
Une intégration continue verte ne suffit pas
Une version dont tous les tests passaient ne démarrait pas : deux pannes au lancement, qu’aucun test unitaire ne pouvait voir. Seul le canary les a arrêtées. Depuis, un test balaie tous les composants, et le canary se joue sur le résultat d’une série de fusions, pas fusion par fusion.
La vérification après bascule
L’état de santé doit répondre avec ses quatre contrôles : la base, le coffre, le pilote de conteneurs, les workers. Puis chaque application servie est contrôlée, une à une. Le nombre de workers est comparé à celui d’avant : tout écart doit être expliqué.
Le retour arrière, préparé avant
L’étiquette précédente et la configuration sauvegardée avant la bascule, reposées. La base n’est restaurée que si une migration a été appliquée, ce qui se vérifie avant de décider.
Une note de version publique
Chaque version de la plateforme a sa page publique, tirée de son journal des modifications. Les passages internes et les références aux demandes des clients en sont retirés. L’intégration continue refuse une version qui n’a pas sa section dans le journal.
Mettre à jour les machines, sans s’y connecter
Chez nos clients, la plateforme se prolonge par des agents posés sur leurs machines : les minihubs et les miniMiniHubs. Personne ne se connecte à ces machines pour les mettre à jour : c’est le travail du gardien, un programme posé une fois sur chacune.
Trois contrôles de confiance, tous obligatoires
Toutes les trente minutes, le gardien lit le manifeste de la dernière version. Il vérifie sa signature avec une clé épinglée à l’installation, compare son empreinte à celle publiée dans le DNS, puis la taille et l’empreinte de chaque fichier avant de s’en servir. Un manifeste plus ancien que le dernier appliqué est refusé. Pour tromper un gardien, il faudrait compromettre à la fois le stockage, la clé de signature et la zone DNS.
Des vagues, et une machine témoin
Une nouvelle version part d’abord sur une machine témoin, puis sur le reste de la flotte deux heures plus tard. On publie, on observe, on décide d’ouvrir la vague suivante.
Le retour arrière, tout seul
Après l’installation, le gardien vérifie que l’agent tient : dix minutes pour un minihub, trois pour un miniMiniHub. Sinon, il revient à la version précédente, et arrête la vague : les machines suivantes n’appliquent pas la version qui a échoué. Le gardien se met à jour lui-même en dernier, avec un filet de secours après trois démarrages ratés.
Le système et les certificats aussi
Les mises à jour du système se font la nuit, dans une fenêtre fixe, une heure par rang de vague, et jamais deux redémarrages en vingt heures. Les certificats sont renouvelés trente jours avant leur échéance ; leur clé est générée sur la machine et ne la quitte jamais.
Surveiller
La plateforme constate, elle ne décide pas. Elle reçoit les rapports, lève les anomalies, et laisse l’arbitrage à Alfred ou à un humain.
TheSupervisor
L’état de tous les sites WordPress sur un seul écran : versions, extensions à mettre à jour, thème, trafic, comptes administrateurs, dérive des fichiers. L’âge du dernier relevé est toujours affiché, et le gris veut dire « inconnu », pas « vert ».
La supervision externe
Chaque source déclarée a son propre jeton révocable, qui ne parle que pour elle. Onze règles, rangées comme des données et non comme du code : source muette depuis un quart d’heure, fichier modifié, administrateur apparu. Une alerte s’acquitte.
Alfred, le majordome
Un agent intégré au Hub qui exécute des tâches écrites en français. Il se déclenche à heure fixe, sur un courriel, sur un événement interne, sur un appel extérieur ou sur une file de messages, dans des listes d’actions fermées, avec budgets et anti-boucle.
Les échéances de supervision
Certificats, sauvegardes, rapports à relire : chaque échéance est confiée à Alfred, qui l’inscrit dans notre boîte de tâches et l’annonce le jour venu au carnet de bord. Alfred écrit l’échéance ; l’agent la lit et répond « fait ».
Le gardien des gardiens
Chaque gardien rend compte à la plateforme. Un retour arrière, un contrôle de confiance en échec, ou un gardien muet depuis plus de deux heures lèvent une alerte.
Les salons
Humains et agents s’y retrouvent : chaque incident, chaque chantier a sa conversation, avec ses pièces jointes. Les ordres donnés aux gardiens y passent aussi, dans un vocabulaire fermé, signés, et confirmés quand ils sont sensibles.
Une règle tient toute la supervision : muet n’est pas vide. Une source qui ne rapporte plus rien est une alerte, pas un état calme ; une valeur absente n’est pas une valeur nulle.
Sauvegarder, et prouver qu’on sait restaurer
Une sauvegarde n’est prouvée que par sa restauration. C’est la règle, et elle a déjà payé.
Planifiées, et copiées ailleurs
La plateforme sauvegarde ses bases sur un calendrier, avec une durée de rétention, vers des stockages dont les accès sont rangés au coffre. Une réplique de secours, sur une autre machine, vient les tirer toutes les six heures.
Scellées
La sauvegarde d’un site WordPress est chiffrée vers la clé publique de la plateforme. Le site ne peut pas relire ce qu’il a écrit ; un volume volé est inexploitable.
Rejouées
La première sauvegarde complète d’un site, 78 tables et près de 22 000 fichiers, a été rejouée dans une base neuve sans une seule erreur. Ce rejeu avait auparavant révélé un dump corrompu qu’aucun autre contrôle n’avait vu.
Basculées sans coupure
Une base de site se remplace d’un seul geste atomique, réversible par le geste inverse. Les anciennes tables sont gardées sous un autre nom. On ne recharge jamais une table en service.
Protéger
Antivirus
Les pièces jointes du courrier sont analysées en continu par ClamAV, sans retarder la livraison. Un fichier infecté part en quarantaine, et une alerte est levée.
Filtrage des requêtes
La plateforme écarte les balayages automatiques et les requêtes malveillantes connues avant qu’elles n’atteignent une application. Le filtre peut être suspendu un temps ; il se rétablit seul.
Secrets au coffre, et renouvelés
Aucun mot de passe dans le code ni dans une base : tout passe par le coffre-fort de la plateforme. Les clés d’API se renouvellent tous les quatre-vingt-dix jours, les mots de passe d’administration tous les six mois, la paire de clés des jetons chaque année.
Sites durcis
Chaque site WordPress ferme les portes inutiles et pose ses en-têtes de sécurité. La pose est vérifiée site par site, avec la mesure après chacun.
Consentement au droit français
Bannière où refuser est aussi simple qu’accepter, services tiers bloqués avant accord, registre de preuve sans adresse IP.
Être trouvé
Aucun site n’est livré sans son référencement. Un site laissé fermé aux moteurs ne serait indexé par personne ; un site ouvert avant relecture serait indexé en l’état. Les deux se vérifient.
Déclarer la propriété par le DNS
Les sites sont inscrits chez Google, puis chez Bing, qui sert aussi Yahoo. La propriété se prouve par le DNS : elle survit à un changement de thème comme à un changement d’hébergeur.
Porter l’identité légale
Les données structurées de chaque page portent la raison sociale et le numéro d’immatriculation de l’éditeur : c’est ce qui distingue une fiche reconnue d’une page anonyme.
Prévenir à chaque publication
Chaque publication est signalée par IndexNow à Bing, Yandex, Seznam et Naver. Google ne l’a pas adopté : il lit le plan du site.
Suivre
L’indexation se relit à un jour, trois jours et sept jours. Ce qui n’est pas indexé se traite, page par page.
Suivre les anomalies
Les erreurs remontent seules
Chaque socle en service dépose ses erreurs sur le serveur de licences de la flotte, qui les regroupe. Début octobre 2026, il suivait soixante-seize instances.
Un circuit de correction
Chaque anomalie remontée de la production suit un circuit : nouvelle, en cours, corrigée, en attente de précisions, ou renvoyée au framework quand la cause est dans le socle lui-même.
L’échange entre équipes
Anomalies, spécifications, comptes rendus et questions passent par un outil dédié, avec une API que les agents consomment.
La mémoire de l’exploitation
Un référentiel d’exploitation dit ce que nous avons, comment y accéder et comment réagir. Chaque piège rencontré devient une fiche ; le suivant ne le repaie pas.
Questions fréquentes
Que se passe-t-il si une livraison casse quelque chose ?
On repose l’étiquette précédente, toujours disponible puisqu’aucune étiquette n’est jamais réutilisée. Pour la plateforme, la configuration d’avant la bascule a été sauvegardée exprès.
Qui décide du passage en production ?
Le commanditaire, explicitement. La recette se fait sans attendre ; la production attend son accord.
Comment savez-vous qu’une sauvegarde est bonne ?
En la restaurant. Une sauvegarde qui n’a jamais été rejouée n’est pas une sauvegarde : c’est un fichier.
Vos agents IA ont-ils la main sur la production ?
Ils livrent en recette, éprouvent, rangent les preuves, et préparent la production. Le passage en production et toute suppression attendent une décision humaine.