Automates, crons et runs

1. Modèle mental : agent qui pense, automate qui exécute

Synedre orchestre CodeMyShop : ce chapitre documente le harness Synedre, la couche d'orchestration interne — mono-organisation, centralisée — qui pilote le produit et les opérations. Il ne décrit pas CodeMyShop lui-même, le PaaS e-commerce multi-tenant que Synedre opère pour ses clients.

Le harness sépare deux registres bien distincts :

	Agent	Automate
Rôle	Pense, décide, délègue	Exécute une routine déterministe
Support	Un modèle de langage incarnant une persona	Un script d'automatisation
Déclenchement	Délégation depuis l'orchestrateur, ou tâche assignée	Planification (horaire ou événementielle), ligne de commande

Un automate ne « réfléchit » pas : il peut appeler un modèle de langage pour une tâche précise (génération de contenu, classification), mais son flux de contrôle reste codé en dur. La décision vit du côté des agents ; l'exécution répétable vit du côté des automates.

  déclencheur (message, email, tâche planifiée)
         │
         ▼
  orchestrateur (Atlas)
         │ délègue
         ▼
  exécution déléguée à un agent
         │ spawn
         ▼
  modèle de langage  /  automate d'automatisation

2. Les façades automatisées

Le harness regroupe plusieurs centaines de points d'entrée d'automatisation (« façades »), chacun exposant une capacité unique et invocable : synchronisation, audit, génération de contenu, sauvegarde, surveillance, etc. Une minorité sont planifiées ; la majorité sont des outils invoqués à la demande par un agent, ou des librairies partagées non exécutables seules.

Un registre central classe chaque façade selon deux axes :

• Nature technique — planifiée (récurrente), déclenchée à la demande (ponctuelle), outil invocable par un agent, librairie partagée, ou méta-outillage (le superviseur d'exécution lui-même).
• Groupe propriétaire — chaque façade est rattachée à une des familles d'agents qui la maintiennent conceptuellement : audits/QA, veille/reporting, rédaction, build/déploiement, infrastructure/sauvegarde, SEO/maillage, finances/trésorerie, et une famille dédiée à l'arbitrage stratégique. Cette classification reste un métier de terrain : la casse et la nomenclature ne sont pas encore parfaitement homogènes sur l'ensemble du registre.

Familles fonctionnelles

Famille	Rôle
Orchestration	Pipeline boîte de réception → intention → délégation → mise en production. Un incident de nettoyage a supprimé à tort deux composants de supervision santé/monitoring dédiés à cette famille ; la surveillance générique (coûts, alerting) continue de couvrir ce besoin par un autre chemin.
Audits	Détection d'écarts et de findings (schéma, sauvegardes, accessibilité, sécurité). Une sortie non nulle signale un constat d'audit, pas un plantage. Un audit de sécurité périodique multi-site (reconnaissance hebdomadaire + alerte sur finding critique) a remplacé un ancien outil de test d'intrusion générique retiré pour dette technique.
Sauvegardes	Extraction base de données et fichiers vers un stockage objet, avec test de restauration mensuel.
Brainstorm	File de traitement asynchrone pour l'idéation (promotion, contestation, mise en récit).
Blog / SEO	Génération et hygiène de contenu, détection de cannibalisation, SEO technique.
Email / boîte de réception	Lecture/écriture de courrier électronique — l'envoi vers un client passe systématiquement par un point d'entrée unique.
Navigation automatisée	Automatisation de navigateur (voir §6).
Banque / facturation	Synchronisation bancaire, facturation récurrente, relances. Un module de relance générique a été absorbé dans un package plus large mais n'est aujourd'hui plus câblé à aucune planification — seule une relance spécifique à un client tourne réellement.
Veille marque	Surveillance de marque, veille technologique, avis clients.
Mémoire / apprentissage	Recherche sémantique, consolidation, retours d'expérience post-incident.
Fiabilité opérationnelle	Surveillance des coûts, détection d'emballement (« runaway »), alerting, garde-fous d'écriture en production.
Auto-maintenance documentaire	Boucle nocturne décrite en détail au §7.
Rythme d'autonomie	Amorçage du pipeline d'exécution autonome, borné par une fenêtre horaire (voir §8).

Une régression non alertée mérite d'être signalée ici en exemple : un chantier de nettoyage automatisé (destiné à purger le code mort) a supprimé par erreur plusieurs scripts pourtant encore appelés par l'orchestrateur nocturne de maintenance documentaire (§7) et par un module d'audit d'accessibilité. Ces appels échouent depuis lors, silencieusement absorbés par les garde-fous existants — aucune alerte dédiée ne s'est déclenchée. Détail et portée au §7 et §9.

3. Le superviseur d'exécution planifiée

Tout automate planifié passe par un superviseur d'enrobage commun, responsable de :

1. Chargement de configuration — charge les variables d'environnement nécessaires sans écraser celles déjà présentes.
2. Disjoncteur — au-delà d'un seuil de dix échecs consécutifs, le script est automatiquement désactivé (une seule alerte au moment du seuil, pas de spam).
3. Exécution encadrée — lancement en sous-processus isolé, avec un temps limite par défaut de cinq minutes, étendu jusqu'à trente minutes pour les tâches longues connues.
4. Auto-réparation — pour une poignée de classes d'erreurs identifiées (import manquant, dépendance manquante, dossier de log inexistant, conflit de nommage local, erreur réseau transitoire), le superviseur tente un correctif automatique puis relance une fois. Les erreurs réseau bénéficient d'un ré-essai en cascade avec délai croissant.
5. Tolérance aux findings — les scripts d'audit sortant en erreur volontaire (un audit qui trouve un problème) ne déclenchent pas le disjoncteur : ce n'est pas un plantage, c'est un résultat.
6. Journalisation — chaque exécution en échec est journalisée (type d'erreur, trace, correctif tenté, succès du ré-essai, compteur d'échecs consécutifs) pour permettre l'audit quotidien (§9).

Le verrouillage anti-recouvrement n'est pas systématique : le superviseur lui-même ne pose pas de verrou générique par script ; certaines tâches sensibles au recouvrement l'ajoutent explicitement, la majorité s'appuie sur le temps limite et la fréquence de planification pour éviter le chevauchement.

4. Le système de runs

4.1 La doctrine « run »

Un run est une exécution scopée pilotée par l'orchestrateur sur un périmètre donné (interne au harness, ou un tenant client) — le périmètre chargeant automatiquement son contexte (infrastructure, client, interlocuteur, boîte mail) depuis le référentiel central. C'est la voie d'exécution par défaut du harness : un run enchaîne édition → mise en production, sans cérémonial, pour tout travail scopé et réversible.

Deux portes d'entrée principales alimentent le volume de runs observés : le forward d'un email entrant classifié par intention (run / question / chantier plus lourd / bruit), et une console de chat scopée pilotée par l'orchestrateur. Une troisième porte d'entrée planifiée (cron) est prévue en doctrine mais encore peu utilisée en pratique.

4.2 L'unité d'exécution déléguée à un agent

Un run n'est pas lui-même une unité d'exécution agent : c'est l'orchestrateur qui, en déléguant, engendre une exécution déléguée à un agent (comparable à une tâche de fond exécutée par un modèle de langage sandboxé).

Le créateur le plus fréquent de ces exécutions déléguées est le rythme d'autonomie nocturne (§8), suivi par l'auto-chaînage interne du worker d'exécution, puis l'interface en ligne de commande et les appels API de mise en production automatique.

L'exécuteur principal tourne à cadence rapprochée (environ une minute) : il choisit la plus ancienne tâche en attente, la marque en cours, spawn le processus correspondant selon le type de tâche (recherche, audit, ou code), diffuse la sortie en direct, puis marque le résultat terminé ou échoué. Les permissions accordées dépendent du type de tâche : une tâche de recherche est limitée à la lecture (pas d'écriture) ; une tâche de code obtient un accès élargi mais confiné strictement au périmètre déclaré.

Le modèle de langage utilisé pour chaque tâche est désormais résolu dynamiquement selon une recommandation calculée en amont (par exemple, une tâche jugée complexe est orientée vers un modèle plus capable), avec repli sûr sur un modèle par défaut en cas d'absence ou d'erreur de lecture de cette recommandation — un câblage récemment corrigé, après avoir constaté que cette recommandation était calculée mais jamais effectivement appliquée au moment du lancement réel.

Pour les tâches dont la cible est un environnement réellement en ligne (déploiement, certificat, infrastructure), un contrôle visuel additionnel a été ajouté avant de considérer la tâche comme terminée : un navigateur réel va vérifier que la cible répond correctement, plutôt que de se fier uniquement à la déclaration textuelle de l'agent et à une relecture du code. Si la cible s'avère cassée malgré une validation textuelle positive, le verdict est rétrogradé en échec ; si le contrôle visuel lui-même est indisponible, la tâche reste autorisée à passer (échec ouvert), mais l'incident est journalisé et un garde-fou de mise en production reste le filet de sécurité final.

4.3 Le journal d'exécution des automates

Chaque exécution d'automate planifié est journalisée de façon détaillée (durée, compteurs d'étapes, erreurs, avertissements, contexte) — à distinguer du journal d'erreurs du superviseur (§3), qui ne trace que les plantages du superviseur lui-même.

5. Ordonnancement : deux planificateurs en parallèle

5.1 Planificateur applicatif

Le harness expose ses propres tâches planifiées applicatives, en plus du filet crontab système. Ces tâches couvrent notamment : le traitement de la file d'envoi email, la surveillance de disponibilité, la veille de dictionnaire technique, la veille de dépendances, un point de synthèse quotidien, la surveillance de certificats, et la veille de marque. Chaque tâche sensible est protégée par un garde qui la court-circuite si elle tourne hors du contexte interne attendu.

Deux tâches restent volontairement désactivées : la synchronisation de boîte mail et la synchronisation email côté client, car le protocole de messagerie utilisé bloque la boucle d'événements et provoque des ralentissements en cascade — à réactiver après correction du client de messagerie pour un mode non bloquant.

5.2 Filet crontab système

Le crontab système de la machine hôte porte l'essentiel de la charge planifiée et sert de filet indépendant du planificateur applicatif. Sur plusieurs centaines de lignes au total, une fraction importante (environ 40 %) est effectivement active ; le reste est un journal de bord de tâches désactivées, conservées en commentaire pour mémoire historique.

Grandes familles de tâches actives :

• Via le superviseur d'exécution — surveillance système, sauvegarde, audits quotidiens, synchronisation bancaire, facturation récurrente, traitement de boîte de réception, rêverie de consolidation mémoire, boucle de maintenance documentaire, rythme d'autonomie (câblé en exécution réelle, cadencé toutes les deux minutes, mais borné par une fenêtre horaire configurable par jour).
• Hors superviseur, modules Python directs — indexation mémoire, exécuteur de tâches déléguées (cadence d'une minute), indexation de compétences, détection de blocage automatique, alerte de fiabilité, alerte de coût, détection d'emballement, extraction d'événements de négociation, veille avis clients.
• Hors superviseur, sans wrapper — publication documentaire, test de restauration mensuel, rotation de logs, métriques mémoire, indexation de session, surveillance de propositions, synthèse quotidienne. Ces scripts ne bénéficient ni de la journalisation centralisée ni de l'auto-réparation du superviseur.
• Scripts d'infrastructure — audit de flotte, audit de dépendances, sauvegardes vers stockage objet (locales et distantes, par tenant), test de restauration, synchronisation mémoire, nettoyage de verrous orphelins.
• Appels HTTP directs — déclenchement du traitement de file d'envoi email, synchronisation de rejoue de session. Une dette de hardening est signalée à ce sujet : une des lignes embarque un jeton d'authentification en clair — à migrer vers un stockage de secrets dédié.

Un chantier de réconciliation reste à mener : le registre canonique des automates planifiés n'est pas encore automatiquement recoupé avec les lignes crontab et les tâches applicatives réellement actives — impossible aujourd'hui de savoir combien d'automates enregistrés comme « récurrents » sont en réalité orphelins (non planifiés nulle part).

6. L'automate de navigation distribué

L'automatisation de navigateur est le seul sous-système où l'exécution sort physiquement de l'infrastructure serveur. Deux raisons distinctes motivent cette sortie, donc deux topologies différentes, à ne pas confondre :

Topologie	Où tourne le navigateur	Contourne	Mode
Proxy résidentiel	Navigateur sans interface sur le serveur	La réputation de l'adresse IP	Sans fenêtre visible, avec furtivité renforcée
Poste distant avec interface	Navigateur avec fenêtre visible sur un poste résidentiel	La signature du navigateur (empreinte)	Fenêtre visible, adresse IP résidentielle directe

6.1 Pourquoi un navigateur résidentiel avec interface

Un tunnel réseau inversé établi depuis un point résidentiel permet de faire sortir le trafic par une adresse IP résidentielle plutôt que par l'adresse du serveur. C'est suffisant pour les sites qui ne discriminent que sur la réputation de l'adresse IP. Un garde-fou dédié refuse de lancer l'automatisation si le tunnel est indisponible ou si l'adresse de sortie observée correspond à celle du serveur — aucune sortie accidentelle par le mauvais chemin réseau.

Mais certains mécanismes de protection anti-robot ne jugent pas l'adresse IP : ils jugent la signature du navigateur lui-même (signaux techniques trahissant un navigateur piloté automatiquement). Un navigateur sans interface, même via un tunnel résidentiel propre, conserve une signature de robot. D'où le second mode : un vrai navigateur avec fenêtre visible, tournant sur un poste résidentiel réellement allumé, avec l'adresse IP résidentielle native — pas de tunnel nécessaire, la protection anti-robot passe naturellement.

Règle opérationnelle : classer le type de protection rencontrée avant de coder le flux d'automatisation. Une protection qui juge le navigateur, pas seulement l'adresse IP, impose le mode avec interface visible ; le mode furtif sans interface ne suffit pas.

6.2 Cycle de vie d'une tâche de navigation

Les tâches sont mises en file d'attente centralement, avec un statut (en attente / en cours / terminée / échouée), un type d'opération restreint à une liste blanche explicite, un résultat structuré et un compteur de tentatives.

Le point clé de conception est l'inversion de contrôle : le serveur n'a aucun accès entrant vers le poste résidentiel (adresse IP dynamique, pas de port ouvert). C'est le poste résidentiel qui interroge le serveur à intervalle régulier via une connexion sortante sécurisée.

  [Serveur]                              [Poste résidentiel]
  mise en file d'attente                  interrogation en boucle (toutes les ~5s)
       │                                       │  (1) mise à jour automatique du code si besoin
       ▼                                       │  (2) revendication atomique de la tâche
  file d'attente centralisée ◄──────────────────┘
       │
       │  (3) exécution : navigateur avec interface visible,
       │      routage strict par type d'opération (liste blanche)
       ▼
  file d'attente ◄──── rapport de fin (terminée/échouée, résultat structuré)

Détails de mécanisme :

• Mise en file — refuse tout type d'opération hors liste blanche, valide la charge utile avant insertion.
• Revendication atomique — la plus ancienne tâche en attente est prise de façon exclusive ; plusieurs postes distants ne peuvent pas se voler mutuellement une tâche.
• Routage strict — aucune exécution de code arbitraire à partir de la charge utile de la tâche, uniquement des paramètres métier prédéfinis vers un handler connu.
• Authentification à deux facteurs — pour les opérations qui en ont besoin, le code de vérification transite via le serveur (qui le lit dans sa propre boîte mail) plutôt que d'arriver directement sur le poste distant, et n'est jamais journalisé en clair.
• Rapport de fin — le résultat est transmis en un seul bloc structuré, jamais en argument de ligne de commande brut, pour éviter toute rupture sur un caractère spécial.
• Mise à jour automatique — le poste distant se met à jour lui-même à l'état de repos uniquement (jamais en plein traitement d'une tâche).

6.3 Le garde-fou en cas de fuite de clé d'accès

La clé d'accès du poste distant est installée côté serveur avec des restrictions strictes : pas de terminal interactif, pas de redirection de port, pas de transfert d'agent. Si le poste résidentiel est compromis, la clé volée n'ouvre pas un accès serveur libre.

Un garde dédié intercepte la commande reçue, la découpe en tokens stricts (jamais d'interprétation shell libre), et n'exécute que si le préfixe de commande correspond exactement à l'attendu, le sous-type d'opération appartient à une liste explicite, et chaque paramètre respecte un format strict prédéfini. Tout token inconnu ou valeur non conforme est refusé et journalisé. Pire cas d'une clé volée : polluer la file d'attente, jamais exécuter du code arbitraire côté serveur.

Les données personnelles retournées par certaines opérations (noms, extraits de messages) ne sont jamais journalisées en clair — seul un compteur agrégé l'est. Les captures d'écran de débogage sont purgées automatiquement en fin de traitement. Une dette latente est signalée : un temps limite de traitement par tâche existe dans le code mais n'est aujourd'hui pas réellement appliqué, ce qui peut laisser une tâche de navigation bloquer indéfiniment.

7. La boucle nocturne d'auto-maintenance de la documentation

Le harness dispose d'un sous-système qui mesure l'écart entre sa propre documentation technique et son code réel, et corrige cet écart de façon largement autonome, sous garde-fous explicites. C'est la couche d'automatisation la plus récente et la plus imbriquée du harness.

7.1 Architecture du pipeline

Un orchestrateur nocturne unique enchaîne, dans l'ordre, les étapes suivantes :

1. Mesurer l'écart — compare chaque chapitre documenté à son code lié réel.
2. Mesurer la couverture — détecte les angles morts (parties du code jamais mentionnées dans la documentation).
3. Cartographier les composants — vérifie la cohérence entre le statut déclaré d'un composant et son état réel d'activation.
4. Relier les composants — dérive les relations factuelles entre composants documentés (qui produit quoi, qui surveille quoi).
5. Réparer les références mortes — corrige de façon déterministe les pointeurs vers du code qui a bougé, sans jamais inventer.
6. Régénérer en profondeur — réécrit un chapitre entier en relisant le code réel, sous budget de temps borné.
7. Proposer la republication — met en file les chapitres modifiés pour publication.
8. Publier la documentation — pousse les chapitres validés vers le site public, sous gate anti-fuite automatisé.
9. Publier la cartographie — synchronise le statut public des composants.
10. Re-mesurer l'écart — remesure après réparation, pour que le diagnostic final reflète l'état réel de fin de cycle.
11. Établir le diagnostic — bilan de synthèse (voir §7.2 ci-dessous).
12. Publier le résumé — pousse un instantané assaini du diagnostic vers le site public.

Le diagnostic final est volontairement calculé après la re-mesure, pas juste après la mesure de couverture initiale : sinon le résumé publié restait en retard d'un cycle sur l'état réellement corrigé.

Incident non alerté à signaler ici en exemple de transparence : un chantier de nettoyage automatisé du code mort a supprimé par erreur trois scripts pourtant encore appelés par cet orchestrateur nocturne (les étapes « cartographier les composants », « proposer la republication » et « publier la cartographie »). Depuis cet incident, ces trois étapes échouent chaque nuit — l'échec est absorbé silencieusement par le garde-fou existant (seul un plantage franc de l'orchestrateur lui-même, pas l'échec d'une sous-étape isolée, remonte comme une alerte), donc aucune notification dédiée ne s'est déclenchée. Conséquence concrète : le statut/nom des composants ne se resynchronise plus automatiquement vers le site public, et la mise en file de republication passe désormais uniquement par le chemin de publication directe (étape 8). Ces scripts restent restaurables dans une fenêtre de grâce ; à défaut, les appels correspondants seront proprement retirés.

7.2 Le miroir de fidélité (mesurer l'écart)

Fonctionne en lecture seule stricte : n'écrit jamais ni le code ni la documentation, se contente d'enregistrer l'écart constaté. Trois types d'écart détectés : un fichier de code lié a été modifié après la dernière mise à jour du chapitre documenté ; le chapitre cite un chemin de code qui n'existe plus ; le chapitre publié sur le site retarde sur sa version interne. Idempotent (une mesure par chapitre par jour), et appelé deux fois par cycle (au début, et à la fin après réparation) pour que le diagnostic final reflète l'état réel.

7.3 L'auditeur de couverture (mesurer la couverture)

Complète le miroir de fidélité : là où celui-ci vérifie « ce que je dis est-il vrai ? », l'auditeur de couverture vérifie « y a-t-il une partie du système que je ne mentionne jamais ? », par différence d'ensembles entre le code documentable réel et ce qui est effectivement couvert par au moins un chapitre. Un point isolé non couvert n'est pas grave ; plusieurs points de la même famille non couverts deviennent candidats à une nouvelle section ou un nouveau chapitre. Lecture seule stricte.

7.4 Le réparateur déterministe de références mortes

Comble le trou entre le diagnostic (qui détecte un chemin mort) et la réécriture par modèle de langage (qui corrige la prose mais ne sait pas qu'un fichier a bougé) : la résolution ici est déterministe, zéro improvisation. Pour chaque référence morte, recherche le nouvel emplacement possible par le nom du fichier : un seul candidat trouvé → correction automatique ; zéro candidat → signalement humain requis ; plusieurs candidats ambigus → signalement, jamais de correction automatique à l'aveugle. Réversible (un seul geste annule tout un cycle de correction).

7.5 Le régénérateur profond

Sous un budget de temps borné, un modèle de langage headless relit le code réel d'un chapitre et (a) réécrit sa version interne, (b) produit directement sa version publique assainie, en français et en anglais. La version interne est validée avant que la version publique ne passe par un contrôle anti-fuite dédié.

7.6 L'auto-réparateur mécanique (cycle indépendant)

Tourne sur son propre rythme, indépendamment de l'orchestrateur nocturne principal. Touche uniquement les fichiers de documentation, jamais le code. Règle de sûreté stricte : une référence morte n'est corrigée que si son nom de fichier correspond à exactement un fichier suivi dans le dépôt de code — zéro candidat ou plusieurs candidats ambigus, aucune correction automatique. Réversible, plafonné en volume par exécution, avec un interrupteur d'arrêt dédié.

7.7 Le diagnostic de fin de cycle

Calculé en toute fin de cycle, après la re-mesure de l'écart. Agrège cinq dimensions indépendantes, sans en modifier aucune : l'écart doc↔code, la couverture documentaire, la dette technique ouverte, le signal issu des retours d'expérience post-incident, et la santé opérationnelle des automates planifiés (taux d'erreur récent, scripts désactivés par le disjoncteur). Le résultat alimente un point de synthèse quotidien à destination du fondateur.

7.8 La publication vers le site public

Détecte les chapitres dont la version interne a divergé de sa version publiée, les met en file d'attente de republication, avec un contrôle anti-fuite multi-couches avant toute écriture. La publication effective vers l'état public visible se fait soit par un geste humain délibéré, soit automatiquement pour les chapitres qui passent tous les contrôles machine (anti-fuite, et un contrôle spécifique anti-dérive de registre — cf. §VII de la charte éditoriale) ; les chapitres refusés restent en attente et génèrent une alerte au fondateur.

7.9 Le processus de revue externe

Dépile des revues soumises par un regard extérieur (retour d'un autre modèle de langage sur une réponse du harness), les évalue via un modèle de langage sandboxé avec délimiteurs anti-injection stricts, et n'en tire qu'un signal (pas de régénération immédiate) — la régénération effective reste consommée par l'orchestrateur nocturne principal, pour éviter la perte de calcul en cas de coupure.

8. Le rythme d'autonomie nocturne

8.1 Amorçage, fenêtre horaire, garde-fous

Le pipeline d'exécution autonome se chaîne lui-même à l'intérieur d'un travail en cours, mais rien n'amorce le tout premier pas : un travail marqué en mode autonome, avec des tâches en attente et aucune exécution en cours, resterait dormant sans un déclencheur externe. Ce rythme comble précisément ce trou : il seede une tâche en attente pour la prochaine étape éligible de chaque travail actif sans exécution en cours.

Le rythme tourne à cadence rapprochée (toutes les deux minutes), mais ne seed réellement que si l'heure courante tombe dans une fenêtre horaire configurable par jour de la semaine. Hors fenêtre, il repasse en mode observation silencieuse (il note, il n'agit pas). Un pilotage manuel explicite peut court-circuiter la fenêtre — un geste délibéré du fondateur, pas un comportement par défaut.

Garde-fous en place :

• Plafond de coût — si le coût cumulé d'un chantier atteint son plafond, il est gelé, plus aucune nouvelle tâche n'est seedée.
• Interrupteurs d'arrêt — plusieurs interrupteurs indépendants permettent de couper tout ou partie de l'autonomie sans toucher au code.
• Mise en production autonome, gouvernée par la flotte — le rythme peut exécuter un déploiement en préproduction systématiquement, et une mise en production réelle uniquement si l'infrastructure cible l'autorise explicitement (drapeau par site, activé par défaut, avec exclusions explicites décidées au cas par cas). La mise en production autonome, non surveillée, exige en plus une preuve de validation qualité positive et récente — sans cette preuve, le rythme signale sans agir.
• Filet de restauration post-déploiement — une porte de santé HTTP vérifie la cible après déploiement ; en cas d'échec, une restauration automatique de la version précédente est déclenchée. Sur les mises en production autonomes spécifiquement, l'ancienne version est conservée un cran plus longtemps que sur un déploiement manuel, pour permettre une restauration manuelle a posteriori d'un déploiement « techniquement en ligne mais fonctionnellement faux » que la seule porte de santé HTTP ne peut pas détecter.
• Plancher en dur, indépendant de la base de données — pour un site explicitement identifié comme sensible, un refus de mise en production automatique est codé en dur, testé avant même toute lecture du drapeau d'autorisation en base. Raison : ce rythme s'exécute en tâche planifiée, hors de toute session interactive protégée — un garde-fou qui ne protège que les sessions interactives ne verrait jamais cet appel. Une seule ligne de configuration corrompue ne doit jamais suffire, à elle seule, à faire passer ce site en production automatiquement. C'est le miroir, en deux surfaces de code indépendantes, du même principe de double verrou.

9. Garde-fous & dette technique

• Disjoncteur — un automate est désactivé après dix échecs consécutifs.
• Audit quotidien — relit chaque jour le journal d'erreurs et le journal d'exécution des automates.
• Coût / emballement — plusieurs surveillances indépendantes, à cadence variable (quelques minutes à une demi-heure), couvrent le coût cumulé et la détection d'emballement.
• Sauvegardes + test de restauration — dumps nocturnes (base de données, fichiers, sites clients distants) et un test de restauration réel mensuel.
• Déblocage automatique — retente les exécutions bloquées, plafonné en nombre de tentatives, avec interrupteur dédié.
• Boucle documentaire — voir §7.

Dette signalée

• Un cron mort a été nettoyé sans remplaçant : l'audit de fuite d'URL qu'il exécutait n'est aujourd'hui plus couvert, à recréer si le besoin réapparaît.
• Un jeton d'authentification apparaît en clair dans une ligne de tâche planifiée — dette de hardening à corriger (migration vers un stockage de secrets dédié).
• Une tâche de traitement de file email tourne en double (planificateur applicatif + appel HTTP direct) — redondance sans impact fonctionnel (la file elle-même est idempotente) mais à nettoyer.
• Absence de verrouillage générique dans le superviseur d'exécution planifiée : recouvrement possible sur les tâches lentes non protégées explicitement.
• Régression non alertée (détaillée au §7.1) : trois étapes de la boucle documentaire échouent chaque nuit depuis un incident de nettoyage de code mort, sans alerte dédiée déclenchée. Un quatrième composant (audit d'accessibilité) est touché par la même classe de régression.
• Bug latent : un temps limite de traitement pour les tâches de navigation automatisée existe dans le code mais n'est pas appliqué en pratique — une tâche peut bloquer indéfiniment.