Hermes

Le jour où un service est mort cinq semaines en silence

Un service lancé au démarrage, qui ne pouvait pas écrire son journal, et qui mourait avant sa première ligne de code. Relancé automatiquement, il mourait à nouveau. Dix-sept mille fois. Personne pour le remarquer, puisque le seul témoin était un fichier qu’il n’arrivait pas à écrire. C’est l’incident fondateur : tout ce qui suit en découle.

Ce que j’ai construit

Chaque système porte une consigne d’exploitation : ce qu’il fait, ses contrôles de santé, les incidents déjà rencontrés, les remèdes autorisés et les décisions à me remonter. Hermes exécute ces contrôles, applique les remèdes réversibles prévus, et m’alerte par messagerie (Discord surtout, Telegram aussi, avec un canal réservé aux alertes d’infrastructure) quand un écart sort du cadre. Il a d’abord tourné sur un serveur loué, puis a rejoint mon serveur local pour rester au plus près de ce qu’il surveille. C’est aussi lui qui alimente le second cerveau.

Ce qu’il fait seul : diagnostiquer, relancer un processus prévu, relancer une tâche, vider un cache, corriger une configuration non sensible, vérifier une intégration, produire un rapport, alerter. Ce qu’il me remonte toujours : tout ce qui change un usage, un budget ou une exposition ; toute action irréversible ; tout ce qui touche à une authentification ou à une permission ; les arbitrages produit ou métier ; les conflits entre sources qu’il ne peut pas trancher.

La tournée

Onze tâches planifiées ont été créées depuis juillet ; six sont en service. Un contrôle de santé du service principal toutes les quinze minutes, avec relance automatique et alerte si le service ne revient pas. Une synchronisation du corpus de connaissances toutes les trente minutes, qui ne notifie que s’il y a du nouveau. Une sauvegarde hors site chaque nuit, avec accusé de succès et taille transférée. Une surveillance quotidienne de l’espace disque. Une vérification hebdomadaire des accès et des clés. Un audit d’exposition hebdomadaire.

Point commun des six : aucune n’appelle un modèle. Elles exécutent un script et livrent son résultat, sans coût en jetons et sans dépendre d’un fournisseur. Les cinq tâches retirées étaient exactement les seules qui consommaient un modèle à chaque exécution (veilles d’actualité, brief matinal, surveillance de comptes) : le déterministe est resté, le reste est parti. Depuis leur mise en place, les compteurs cumulent environ 9 600 exécutions, pour une seule panne de tâche enregistrée (un délai dépassé sur la surveillance la plus fréquente).

Ce qu’il a appris

Une partie de ses règles vient de mes préférences, une partie de ses propres erreurs, et chaque règle sait d’où elle vient.

• De mes préférences. Pas de préambule, réponse directe. Une question ambiguë se tranche par une seule question ciblée, pas par une supposition. Quand je demande un avis, il ne modifie rien : je tranche d’abord. Rien de signé, souscrit ou payé sans ma validation explicite.
• De ses erreurs. Ne jamais inventer un chiffre, une durée ou un paramètre absent de la source, et dire « je ne sais pas ». Ne jamais laisser un identifiant ou un jeton dans un message ou un journal, règle née d’un incident où des identifiants ont circulé dans des adresses pendant un flux d’autorisation, corrigé puis rendu permanent. Redémarrer un service par le mécanisme du système, jamais par sa commande interne, règle née d’une boucle de redémarrage.
• Des refus qu’il tient. Il ne contourne pas une authentification, même quand je le lui demande : il a refusé de valider un écran d’autorisation tiers à ma place et proposé trois voies légales. Il ne modifie pas un document officiel, même avec mon accord.
• Une règle de forme. Sur un sujet où je tiens au respect dû à une autorité citée, une de ses formulations était fautive. Il a mesuré l’étendue du problème sur tout le corpus, corrigé une cinquantaine de documents, et inscrit la règle en dur pour que la correction tienne.

Sauvegarde

Tout l’environnement de l’agent est sauvegardé chaque nuit hors site, sur un serveur distinct du serveur local : configuration, historique, mémoire, procédures, tâches planifiées, journaux. Sept instantanés quotidiens conservés, dédupliqués (sept instantanés occupent l’espace d’environ deux), accès par une clé dédiée à cette seule fonction. La tâche rapporte la taille réellement transférée en cas de succès, et alerte en cas d’échec : un échec silencieux n’est pas possible côté notification. À ce jour, 76 sauvegardes réussies. Chaque montée de version ou modification sensible est en plus précédée d’une archive locale ; cinq montées de version entre août et septembre, retour arrière possible à chaque fois.

Ce qui n’est pas prouvé, et qui est écrit tel quel dans la consigne : aucune restauration n’a encore été exécutée, ni réelle ni simulée. La sauvegarde est présente et complète ; elle n’est pas encore démontrée restaurable. C’est la première chose à faire.

Sécurité

Le principe, pas les mécanismes. Le service tourne avec un compte ordinaire, jamais avec des privilèges d’administration. Les identifiants applicatifs sont distincts de ceux de la machine. Tous les services locaux écoutent uniquement sur l’interface locale ; l’accès distant passe par un réseau privé, et un seul point est exposé publiquement, volontairement et pour un usage précis. Les tâches planifiées n’ont aucun accès à un fournisseur de modèle, et chacune dispose du jeu d’outils minimal. Les secrets sont masqués dans tout ce que l’agent produit. Un audit automatique hebdomadaire vérifie processus, ports en écoute, permissions des fichiers sensibles et présence éventuelle de secrets ; il signale, il ne corrige pas.

Rien n’est installé sans inspection préalable du dépôt, de la licence et du script d’installation.

Ce qu’on a testé

• Redémarrage complet du serveur local. Cas réel, pas provoqué : la machine a redémarré pendant une session de travail. Services relancés seuls, session reprise là où elle s’était arrêtée.
• Arrêt forcé du service principal. Deux fois, dont une en pleine session. Relance automatique en quelques secondes.
• Double supervision. Deux mécanismes de relance concurrents se remplaçaient en boucle et provoquaient des arrêts répétés. Cause identifiée, un seul mécanisme conservé, l’autre désactivé et archivé. Plus aucun arrêt parasite depuis.
• Expiration d’authentification. Reprise réussie, puis bascule vers un accès à durée longue pour supprimer la récurrence hebdomadaire.
• Fournisseur de modèle indisponible. Des échecs réels ont été constatés ; un fournisseur de repli est configuré.
• Messagerie indisponible. L’appairage d’une messagerie a été bloqué plusieurs jours par le fournisseur lui-même. Bascule sur une autre messagerie sans interruption.
• Montée de version. Cinq fois : archive préalable, mise à jour, contrôle de santé, vérification des canaux. Service opérationnel après chacune.

Non testé, et présenté comme tel : la coupure de courant brutale, la restauration complète depuis la sauvegarde distante, la perte du serveur distant, la reprise après corruption de la base d’historique.

Les audits

Trois niveaux. L’audit d’exposition hebdomadaire, déterministe, silencieux quand tout est conforme. L’audit du corpus de connaissances, confié à un autre agent avec pour consigne de signaler sans supprimer (contradictions, pages périmées, pages isolées). Et les audits ponctuels : ce site a été relu fiche par fiche par Hermes et par un second agent, qui ont trouvé six formulations impossibles à prouver et une confusion entre ce qui tourne, ce qui est testé et ce qui n’est que spécifié. Les textes de remplacement ont été intégrés ; les sections vides ont été supprimées plutôt que remplies de générique. Règle appliquée partout : une correction annoncée par un agent n’est acquise qu’après vérification dans le système réel. Un rapport n’est pas une preuve.

Ce que ça raconte

• Une documentation écrite pour une machine. Une consigne d’exploitation est un contrat, pas une notice : verbes d’action, limites explicites, incidents passés et remèdes autorisés.
• Des limites avant des pouvoirs. L’agent peut redémarrer, lire, alerter, archiver. Il ne supprime pas de données, ne désinstalle pas, ne reconstruit pas sans moi, ne contourne jamais une authentification.
• Le déterministe d’abord. Tout ce qui tourne sans surveillance tourne sans modèle. Les modèles servent au diagnostic et à la conversation, pas aux tâches de nuit.
• Honnête sur ce qu’il ne mesure pas. Pas de série d’alertes consolidée, donc pas de chiffre mensuel. Pas de mesure du délai entre panne et alerte, seulement une borne de quinze minutes. Pas de taux de disponibilité. Il le dit plutôt que de l’inventer. C’est exactement le comportement que j’attends d’un testeur.

Ce que j’ai vérifié

• Signal observé : un service mort en silence pendant cinq semaines, faute de journal.
• Test ou contrôle : une consigne d’exploitation par système, six tâches planifiées déterministes, arrêts forcés et redémarrages réels, cinq montées de version avec archive préalable, un audit d’exposition hebdomadaire.
• Résultat : environ 9 600 exécutions planifiées pour une panne enregistrée, 76 sauvegardes réussies, six familles d’incidents détectées et documentées dans les consignes.
• Limite actuelle : la restauration depuis la sauvegarde n’a jamais été exécutée, le canal d’alerte dépend d’un service tiers sans voie de secours, et le délai panne-alerte n’est pas mesuré.