catalogue des façades et points d'entrée du harness

Synedre orchestre CodeMyShop : Synedre est le harness agentique interne — l'ensemble des automates, scripts et points d'entrée qui font tourner l'entreprise (emails, chantiers, audits, contenu, déploiements, finance) — tandis que CodeMyShop est le produit e-commerce multi-tenant que ce harness opère. Ce chapitre documente le harness : son inventaire d'outils, ses familles fonctionnelles et les mécanismes de gouvernance qui l'encadrent. Il ne décrit pas l'architecture du produit CodeMyShop lui-même.

0. Périmètre, méthode et couverture

Le harness rassemble plusieurs centaines de scripts d'automatisation et de points d'entrée exécutables, répartis en deux grandes familles : des modules Python d'automatisation et des utilitaires shell/JS. Chaque script est décrit ici par son rôle en une ligne et son mode d'invocation type, afin qu'un ingénieur reprenant le système retrouve rapidement quel outil fait quoi sans devoir relire l'ensemble du code.

Les descriptions sont extraites programmatiquement du commentaire de tête de chaque fichier — jamais inventées. Quand un fichier ne porte qu'un en-tête de licence générique, le vrai commentaire de rôle a été recherché plus bas dans le fichier. Ce repêchage n'est pas systématique : le catalogue précise, cas par cas, quand une description reste à confirmer plutôt que de la présenter comme certaine.

La couverture est revérifiée à intervalles réguliers par croisement automatique entre l'inventaire de fichiers et le planificateur système réel (crontab), afin de détecter deux dérives : un script encore documenté comme actif alors qu'il a été retiré de l'ordonnancement, et à l'inverse un script réellement ordonnancé mais absent du catalogue.

Mode d'invocation	Signification
cron	lancé par le planificateur système, le plus souvent via un chien de garde commun
CLI	appelé à la main par un opérateur ou un agent
skill	façade derrière une compétence invocable en langage naturel
hook	déclenché automatiquement avant/après une action de l'agent IA (édition de fichier, appel shell, lecture, sous-agent, fin de session)
lib	module importé par d'autres scripts, pas un point d'entrée autonome
worker	processus de fond qui draine une file d'attente en continu

1. Familles et flux d'ensemble

Le flux général du harness suit un chemin unique : un email entrant est capté et son intention est classifiée (exécution simple, chantier structuré, question, ou bruit) ; selon le résultat, le travail est soit exécuté directement, soit ouvert comme chantier structuré avec équipe assignée, soit versé dans un espace de gestation d'idées. L'exécution proprement dite passe toujours par un cycle d'agents outillés, qui se déploient ensuite vers cinq destinations : audits de qualité, production de contenu/SEO, finance, automatisation navigateur, ou déploiement. Toutes ces branches convergent vers une base de données unique, accédée exclusivement via une façade d'accès commune — jamais de connexion directe éparpillée dans le code.

Ce choix d'une source de vérité unique est structurant : aucune donnée métier (clients, secrets, dépôts, tarification) ne vit dans un fichier statique — elle vit en base, et le code applicatif ne fait que la lire/écrire via cette façade.

2. Socle commun

Un jeu de modules transverses porte les fondations utilisées par la quasi-totalité des automates : une façade d'accès à la base de données, un chargeur centralisé des variables d'environnement, un système de journalisation structurée obligatoire, et une façade IA agnostique du fournisseur (elle route vers différents moteurs de langage selon la tâche et le budget, sans coupler le code applicatif à un fournisseur précis).

Chaque tâche planifiée passe sous un chien de garde commun qui impose un délai d'exécution par défaut et coupe tout script qui dépasserait ce plafond — avec des dérogations explicites, documentées et bornées pour les tâches légitimement longues (consolidation de mémoire nocturne, génération multi-session). Un système de journalisation d'événements alimente le tableau de bord temps réel des agents en cours d'exécution.

Le socle porte aussi un mécanisme de réflexes décentralisés : avant chaque édition de fichier, lecture, appel d'outil réseau ou spawn de sous-agent, une évaluation rapide interroge un registre de règles apprises (autoriser / avertir / refuser) et trace la décision dans un journal d'audit dédié. La loi qui gouverne ce registre est une loi d'asymétrie stricte : toute nouvelle règle ne peut que durcir le comportement, jamais l'assouplir, et les zones sensibles échouent fermées (elles bloquent par défaut) en cas d'indisponibilité de la base de règles.

3. Orchestration

La couche d'orchestration surveille en continu une boîte de réception dédiée, classe l'intention de chaque message entrant (exécution simple / chantier / question / bruit), puis déclenche l'action correspondante : pour un travail actionnable, une session d'agent headless est démarrée pour agir sur l'email classifié, avec un délai maximal généreux et des garde-fous anti-doublons pour éviter qu'un même cycle ne soit relancé deux fois. La mise en production reste un geste strictement humain ; l'orchestrateur peut proposer un envoi « via email » avec triple vérification anti-usurpation, mais jamais déclencher lui-même une bascule en production.

Un cycle de type ReAct (raisonner → agir → observer) pilote chaque tâche unitaire ; des détecteurs dédiés repèrent les tâches bloquées au-delà d'un seuil de temps ou de consommation, proposent un plan de déblocage, ou mettent en pause automatiquement une tâche qui s'emballe (durée ou coût anormal). Un résumé quotidien consolide l'activité de la nuit.

Pont session interactive → tableau de bord

Un mécanisme optionnel permet à une session interactive de se déclarer liée à un chantier en cours : l'activité de cette session (actions, messages) est alors miroitée en temps réel vers le tableau de bord de suivi de ce chantier, sans jamais interférer si aucun lien n'est actif. Un interrupteur d'urgence permet de désactiver entièrement ce pont.

Exécution multi-fournisseur

Un contrat d'exécution commun permet de router chaque unité de travail vers différents moteurs de langage selon le besoin (rapidité, coût, disponibilité) plutôt que d'être couplé à un seul fournisseur. Chaque exécution est chronométrée et son coût réel est calculé depuis une grille tarifaire centrale — jamais de prix codé en dur — puis agrégé par chantier et par marque, alimentant un contrôle budgétaire continu.

4. Chantiers

La création d'un chantier suit une procédure structurée en plusieurs étapes obligatoires : lecture complète de la demande d'origine (y compris ses pièces jointes, systématiquement passées par un scan antivirus avant toute ouverture), audit des agents disponibles pour composer une équipe pertinente au périmètre, rédaction d'une lettre de mission explicite, recrutement d'au moins deux profils distincts pour tout travail touchant un client, puis création atomique du chantier avec son premier lot de tâches — l'ensemble échoue et s'annule en bloc si une seule étape rate, jamais d'état à moitié créé.

Des outils dédiés génèrent un brouillon de lettre de mission, gèrent l'équipe recrutée par chantier, orchestrent l'explosion automatique d'une découverte en tâches d'implémentation, auditent la pertinence des chantiers actifs, et déclenchent une alerte dès qu'un chantier consomme 80 % de son enveloppe budgétaire — avant le plafond dur qui coupe le travailleur. Le pipeline commercial (prospection → négociation) partage cette même mécanique : qualification légale et de solvabilité d'un prospect via des registres publics, extraction structurée des échanges, génération d'un dossier de négociation complet.

5. Idées et gestation

Une file d'attente dédiée porte les idées en gestation ; un travailleur de fond les traite en dialoguant avec l'orchestrateur, puis un cycle de challenge séquentiel les confronte à un regard critique avant maturation. Une idée validée peut être promue en chantier structuré ; à l'inverse, un chantier peut être rétrogradé en idée si le périmètre s'avère prématuré — un pont miroir gère les deux sens.

6. Audits, qualité et sécurité

Une famille dense d'audits tourne la nuit ou en continu : audit global de tous les automates, audit du schéma de base de données contre la convention de nommage, audit de dérive entre le schéma déclaré dans le code et l'état réel de la base, surveillance quotidienne de la fraîcheur des sauvegardes, test mensuel de restaurabilité réelle d'un dump, audit sécurité des dépendances logicielles, détection des doublons et quasi-doublons de contenu éditorial.

Côté sécurité offensive, un orchestrateur de reconnaissance non-intrusive passe chaque domaine actif en revue de façon hebdomadaire, en tirant la liste des cibles depuis un référentiel central — jamais de nom de client codé en dur dans le code — et n'envoie une alerte que si de nouveaux constats de sévérité élevée apparaissent (pas d'alerte-bruit sur chaque passage). L'intrusif réel ne s'arme jamais automatiquement : c'est un geste manuel distinct. Un audit d'accessibilité vérifie la conformité aux standards WCAG 2.2 AA. Une sonde anti-fuite passe chaque point d'entrée d'administration sans cookie de session et s'attend systématiquement à un refus — toute réponse positive déclenche une alerte immédiate.

Une vigie visuelle capture réellement l'écran d'une page rendue puis demande un verdict à un modèle multimodal sur l'intention visuelle attendue, plutôt que de se contenter de vérifier que le code s'est exécuté sans erreur. Une sentinelle de santé de route surveille le taux d'erreurs 404 par type de page plutôt qu'un seuil global — un type de page entièrement cassé peut ne jamais franchir un seuil moyen tout en étant un vrai incident.

Plusieurs garde-fous mécaniques bloquent la publication de code non conforme avant même le commit : refus d'une requête SQL brute référençant une colonne non déclarée dans le schéma type, invariant statique garantissant que tout formulaire captant un contact est bien relié à la chaîne de remontée publicitaire correspondante, vérification qu'une box de production porte bien les protections anti-intrusion attendues, sentinelle anti-mort-silencieuse détectant un point de contrôle qui échouerait silencieusement contre une base de données injoignable, garde-fou pré-mise-en-production refusant la bascule d'un client tant qu'une chaîne de suivi n'a pas été prouvée fonctionnelle de bout en bout.

Un scanner d'entropie détecte les scripts orphelins (plus aucun appelant) et les met en quarantaine observée avant toute proposition de suppression — il ne supprime jamais lui-même — puis restitue un digest quotidien de l'état du système, avec un rituel hebdomadaire dédié à la question « qu'a-t-on construit qu'on supprimerait aujourd'hui ? ».

7. Mémoire, apprentissage et auto-réparation de la documentation

Le harness porte une mémoire à trois niveaux : des rappels courts injectés en début de session, un rappel sémantique par recherche vectorielle sur l'historique des décisions et incidents passés, et des notes longues organisées en réseau de concepts liés. Une boucle nocturne consolide cette mémoire : elle récolte les incidents récents depuis l'historique de code, les qualifie, les indexe, puis rafraîchit des indicateurs agrégés consommés par le tableau de bord.

Boucle nocturne de maintenance de la documentation

Chaque nuit, le harness inspecte son propre état documentaire selon un cycle en douze étapes fixes : détecter les dérives entre le texte documenté et le code réel (lecture seule), mesurer les angles morts de couverture, vérifier la cohérence entre le statut déclaré d'un composant et son état d'exécution réel, recalculer les relations entre composants, réparer mécaniquement les références cassées quand une résolution unique existe, régénérer en profondeur un chapitre dérivé (un moteur relit le code réel et réécrit le chapitre, publie une version assainie, et l'ensemble passe par une vérification anti-fuite avant toute publication — en cas de doute, publication bloquée et alerte interne plutôt que fuite), proposer par email les chapitres restants à traiter, publier automatiquement ce qui franchit tous les contrôles machine, synchroniser l'état des composants vers la page de statut publique, ré-inspecter une seconde fois après publication (pour éviter qu'un instantané public reste en retard d'un cycle), calculer un bilan de santé sur quatre dimensions, et enfin publier ce bilan.

Une revue externe optionnelle (un lecteur humain peut soumettre une critique sur un chapitre publié) est évaluée par un modèle sandboxé anti-injection avant de nourrir le cycle suivant, jamais avant confirmation. Aucun de ces mécanismes ne touche au code applicatif du produit — leur périmètre est strictement documentaire.

Immunité adaptative

Un détecteur de récurrence regroupe les incidents similaires (regroupement par densité, pas par mot-clé) et rédige des propositions de règle de garde-fou. Le modèle de menace est délibérément conservateur : aucune proposition ne s'active seule — chaque candidat reste inerte tant qu'une revue de sécurité humaine ne l'a pas validé et qu'un geste explicite ne l'a pas armé. Limite connue et assumée : le moteur d'évaluation des réflexes ne couvre aujourd'hui que l'édition de fichiers, la lecture, l'appel d'outils réseau et le spawn de sous-agents — pas les commandes shell — si bien que certaines propositions rédigées pour cibler une commande shell restent, à ce stade, sans levier d'application réel tant que cette famille n'est pas elle aussi couverte. Ce type de limite est documenté explicitement plutôt que masqué.

Un contrôle de fin de tour détecte les erreurs survenues pendant la session qui vient de se terminer, en tire une leçon de comportement immédiate quand le motif est connu, et propose (sans jamais armer) une nouvelle règle de garde-fou pour les motifs récurrents non encore couverts.

Délibération

Un composant dédié confronte plusieurs perspectives d'agents à cadres cognitifs volontairement divergents sur une décision signalée comme sensible, puis restitue une carte du désaccord au fondateur. Loi d'asymétrie : ce composant fait remonter la tension, il ne tranche jamais — la décision reste humaine, seule.

8. Personas et agents

Un référentiel central porte l'identité, le rôle et le cadre cognitif de chaque agent spécialisé du système. Un audit périodique détecte les mentions technologiques devenues obsolètes dans ces fiches (une pile technique citée qui n'existe plus, par exemple), et un cycle de rafraîchissement assisté par modèle de langage propose une mise à jour soumise à relecture humaine avant application. Les portraits visuels associés sont synchronisés en parallèle.

9. Inbox et communication client

Règle dure : aucun email n'est jamais envoyé directement à un client à l'initiative de l'IA. Toute communication externe passe par une façade unique qui impose un cycle brouillon → revue → envoi, la revue étant systématiquement adressée en interne avant tout envoi réel ; un garde-fou technique bloque toute tentative d'envoi de mail par un chemin de code parallèle. Une boîte de réception est surveillée en continu, avec une voie de secours de connexion directe en cas d'indisponibilité de la façade principale.

Le ton de rédaction se résout automatiquement par client détecté (vouvoiement/tutoiement, appellation, registre, leviers de conversation, points à éviter), enrichi d'un dossier multi-sources (échanges passés, historique technique, planification, journaux) pour interdire une réponse fondée sur un seul message hors contexte. Toute pièce jointe extraite d'un email entrant passe par un scan antivirus obligatoire avant toute ouverture ou lecture de contenu — verdict propre requis, sinon blocage et escalade.

Un digest matinal unique agrège les signaux de la nuit et les étiquette par catégorie d'action, plutôt que de forcer une relecture manuelle de chaque flux. Un gardien de clôture de boucle détecte deux types de fuite : un message reçu resté sans accusé de réception au-delà d'un délai, et un fil résolu en interne jamais notifié au client concerné. Un partage de secret à usage unique (sans service tiers, sans mot de passe en clair par email) et un document d'accès sécurisé complètent l'outillage de remise client.

10. Contenu, blog et SEO

La publication éditoriale passe par un moteur unique « base de données d'abord ». L'optimisation SEO (méta-données, description, FAQ, maillage interne) passe elle aussi par un noyau unique multilingue — règle dure du système : aucun second moteur d'écriture SEO ne doit exister en parallèle, pour garantir homogénéité, idempotence, et parité entre toutes les langues d'un site. Chaque écriture SEO est gatée par des validateurs qui refusent la publication d'un contenu insuffisant (résumé sans lien, FAQ trop courte, description sans preuve).

Autour de ce noyau gravitent : un nettoyage automatique du contenu éditorial obsolète, une génération d'images de couverture et de supports sociaux, une surveillance de l'optimisation pour les moteurs génératifs (recherche IA), un suivi du vocabulaire technique cité dans les articles, une sentinelle de santé SEO technique multi-site avec alerte sur régression, et une vigie de couverture qui détecte spécifiquement les pages restées sans méta-description dans la langue source (un angle mort que le suivi habituel des traductions ne voit pas).

La réconciliation de catégories couvre la déduplication de doublons, l'aplatissement d'arborescences trop profondes, et le respect d'une profondeur maximale imposée avant toute mise en production (contrôlé par une sentinelle bloquante).

Recherche organique

L'intégration avec la console de recherche s'exécute dans un environnement isolé qui ne détient que l'accès nécessaire à cette API précise ; les identifiants déchiffrés restent en mémoire du conteneur d'exécution et ne transitent jamais en sortie standard ni en journal. Un orchestrateur récupère le trafic organique sur des fenêtres glissantes, importe les données dimensionnelles (dates, requêtes, pages), et soumet les plans de site à l'indexation.

Traductions et internationalisation

Un pipeline de traduction couvre les catégories, produits, contenus éditoriaux et segments de route, avec des garde-fous spécifiques : rejet d'une retraduction si une quantité numérique disparaît du texte source, préservation stricte de la structure HTML, et repérage des liens internes encore pointés vers la langue source dans une page traduite pour les réécrire vers l'URL canonique correspondante.

11. Agents navigateur

L'automatisation de navigateur privilégie une réputation réseau proche de celle d'un utilisateur résidentiel réel plutôt que de chercher à contourner les défis anti-robot d'un site tiers — une distinction de doctrine assumée. Une façade générique route les actions de navigation vers une machine dédiée à cet usage via un protocole de contrôle distant, ce qui découple le pilotage applicatif de l'exécution physique du navigateur.

Un mode de pilotage direct d'un poste de travail personnel (captures d'écran et interactions clavier/souris pilotées à distance) est disponible pour les tâches strictement graphiques sans interface programmable, activé uniquement derrière un interrupteur explicite. Un adaptateur d'achat déterministe illustre une ligne rouge de conception forte : le modèle de langage décide quoi acheter, un code déterministe exécute l'action, et le passage en caisse automatisé est explicitement exclu — jamais de finalisation d'achat sans confirmation humaine.

12. Banque, facturation et finance

Le rapprochement bancaire suit un principe strict de prudence : import et catégorisation des transactions par défaut en mode simulation (aucune écriture sans confirmation explicite), catégorisation automatique par référentiel tiers→catégorie, puis rapprochement des transactions de revenu avec les factures ouvertes par correspondance de montant exact et de client — avec départage explicite en cas d'ambiguïté, jamais de rapprochement au jugé.

Le moteur de suivi fiscal pour la structure individuelle calcule en lecture seule les indicateurs déclaratifs (chiffre encaissé, charges sociales dues, provisions, seuils légaux) : il ne décide jamais rien fiscalement et n'écrit rien en base — les chiffres produits restent des brouillons indicatifs à valider avec un expert-comptable. Un récapitulatif hebdomadaire et des alertes ponctuelles (échéances, seuils dépassés) sont envoyés automatiquement, avec un anti-spam garantissant qu'une même alerte n'est jamais renvoyée deux fois.

13. Veille et surveillance de marque

Un barème de qualité vérifie automatiquement la conformité d'une page aux jetons de design de la marque et aux critères d'accessibilité (contraste, focus visible, taille de cible, structure sémantique) — utilisable en ligne de commande ou comme verrou avant mise en production. Une veille technologique et concurrentielle alimente une couche de données partagée par plusieurs axes de surveillance.

Côté publicité payante, l'outillage couvre : le téléversement des conversions hors-ligne (une commande confirmée déclenche la remontée vers la plateforme publicitaire), la lecture seule des réglages de suivi d'un compte annonceur, et des veilleurs qui alertent une seule fois lorsqu'une première conversion est confirmée puis se désarment automatiquement pour ne pas répéter l'alerte. Une veille de plateforme freelance drafte des réponses dans le ton habituel puis s'arrête : des garde-fous de compte encadrent explicitement l'automate pour qu'il reste une aide à la communication, jamais un outil d'évasion de détection.

14. Déploiement, infrastructure et sauvegardes

Règle dure d'asymétrie : la mise en production réelle est un geste strictement manuel, réservé au fondateur, jamais déclenché par l'IA. Le déploiement vers l'environnement de préproduction/rebuild, lui, est systématiquement à la charge de l'IA — jamais laissé « pour plus tard ». Avant tout déploiement, l'arbre de travail doit être commité : tout changement non commité serait perdu au déploiement suivant.

La chaîne de déploiement partagée détecte la dérive entre le schéma de base de données déclaré dans le code et l'état réel de la base, et peut appliquer automatiquement les changements additifs manquants (jamais de suppression automatique) si ce mode est explicitement activé. Elle génère aussi les segments de route localisés avant construction, exécute le build, l'empaquetage, l'envoi, le redémarrage du service, puis un contrôle de santé post-déploiement — avec un préchauffage de cache en arrière-plan pour éviter qu'un premier visiteur ne paie le coût d'un rendu lourd juste après la bascule.

Le provisionnement d'une nouvelle infrastructure client suit un scénario déclaratif à partir d'un fichier de configuration, avec bootstrap automatique des comptes d'administration, de la charte graphique déduite du logo, et du pré-remplissage des informations déjà connues. La rotation des identifiants d'accès administratifs est idempotente et propage la configuration réseau correspondante.

Sauvegardes et restauration

Les sauvegardes de bases de données et de fichiers critiques sont chiffrées et répliquées vers un stockage objet distant, avec une politique de cycle de vie et une rotation des journaux dédiés. Une restauration de test réelle (pas une simple vérification de checksum) est exécutée mensuellement pour prouver la restaurabilité effective, pas seulement la présence du fichier de sauvegarde.

15. Synchronisation open-source, refactor et migrations

Le cœur du produit e-commerce publié en open-source passe par un pipeline d'assainissement dédié avant toute publication : retrait de tout commentaire interne, traduction du reste vers l'anglais, et une liste blanche nominative de ce qui a le droit d'être publié — jamais une logique d'exclusion par défaut, toujours une logique d'inclusion explicite (cicatrice interne d'une fuite passée par bootstrap non maîtrisé). Le bootstrap de publication refuse de démarrer si cette liste blanche est absente.

Les migrations de schéma suivent une doctrine d'expansion-contraction stricte sur toute base de production payante : ajouts seulement avant bascule, jamais de suppression avant vérification complète. Un module n'installe son propre schéma que si la configuration du site concerné déclare explicitement l'étendre — un module absent de cette déclaration ne crée jamais ses tables.

Un pipeline d'extraction-transformation-chargement dédié à un fournisseur externe illustre le patron général : lecture incrémentale idempotente d'un catalogue distant, protections anti-blocage réseau, verrouillage anti-chevauchement d'exécution, puis phases avales de récupération d'image et d'import en cascade — toujours en lecture seule côté source, jamais d'écriture sur un système tiers de production.

Amorçage de démonstration

Un environnement de démonstration complet (catalogue, navigation, variantes, paniers, commandes) peut être réinitialisé en une commande vers un instantané de référence propre, utilisé pour les démonstrations commerciales sans jamais toucher à un environnement client réel.

16. Monitoring, obsolescence et outillage divers

Cette famille couvre les tests unitaires des fonctionnalités à cycle long, un pont de test vers l'environnement de base de données sandbox, un moteur de planches documentaires annotées, et la ségrégation stricte des identifiants d'un système hérité (jamais de secret affiché en clair, distinction explicite entre ce qui est montrable et ce qui reste rangé). Un outil de signature appose une signature numérisée sur un document PDF en écrivant systématiquement un nouveau fichier, sans jamais toucher ni envoyer l'original.

Les tests destructifs de gestion de version sont systématiquement isolés dans un espace de travail jetable, jamais exécutés sur la ligne principale du dépôt.

Configurateur 3D sur mesure

Une chaîne bout-en-bout transforme une image de référence (moodboard, croquis) en objet 3D exploitable : extraction des vues, génération d'un maillage 3D multi-vues, colorisation par zones géométriques, puis export dans un format standard consommable par un visualiseur web. Une variante paramétrique génère du mobilier par primitives géométriques ou à partir d'une description textuelle libre, avec un plan coté « prêt-usine » et un contrôle qualité géométrique automatisé (étanchéité du maillage, symétrie) avant livraison.

17. Gouvernance en temps réel — les garde-fous de session

Le harness applique une bonne partie de sa doctrine non pas par la documentation seule, mais par des contrôles automatiques déclenchés en temps réel avant et après chaque action de l'agent IA — édition de fichier, appel shell, lecture, appel réseau, invocation de sous-agent, fin de session. Ces contrôles forment une seconde ligne de défense qui ne dépend pas de la bonne volonté de l'agent au moment de l'action.

Parmi les mécanismes les plus significatifs : blocage de tout envoi d'email hors de la façade unique ; blocage de toute tentative de mise en production directe par l'IA (la commande de bascule réelle reste strictement humaine) ; blocage du collage de secrets en clair ou de l'ajout massif non contrôlé de fichiers à un commit ; exigence d'un scan antivirus propre avant l'ouverture de toute pièce jointe ; blocage d'une requête de base de données brute qui référencerait une colonne non déclarée dans le schéma officiel ; évaluation d'un registre de règles apprises avant édition de fichier, lecture, appel réseau ou invocation de sous-agent ; nudge de structuration obligatoire dès qu'un travail dépasse le périmètre d'une simple correction ponctuelle.

Un contrôle spécifique interdit à l'agent de poser une question de validation dans le chat pour un envoi d'email — la doctrine impose de créer directement le brouillon via la façade dédiée, dont la copie de revue interne fait déjà office de validation ; poser la question reviendrait à contourner ce circuit. Un autre garde-fou, propre au produit d'assistance familiale, bloque toute modification de code touchant à l'identité d'achat d'un foyer si elle ne porte pas explicitement l'identifiant du foyer concerné dans son voisinage immédiat — pour empêcher qu'une identité de foyer ne fuite jamais vers une autre.

À la fin de chaque session, un contrôle de clôture vérifie que l'arbre de travail reste propre (rien d'important laissé non commité), journalise les incidents détectés durant le tour qui vient de se terminer, et refuse de laisser croire qu'une mise en production a eu lieu si elle a en réalité été bloquée par le garde-fou correspondant.

18. Notes de fiabilité

Ce catalogue est généré et revérifié par un processus mixte : extraction automatique depuis le code source réel, puis relecture adverse ciblée qui confronte chaque affirmation du catalogue à l'état effectif du système (planification réelle, câblage réel des contrôles, comportement réel du code) plutôt qu'à ce que la documentation précédente affirmait. Chaque correction identifiée est journalisée avec sa source, pour que la trace de fiabilité elle-même reste auditable.

Par principe de transparence : une information déduite plutôt que directement vérifiée est signalée comme telle plutôt que présentée avec une fausse certitude, et une limite de couverture connue (par exemple un mécanisme de garde-fou qui ne couvre pas encore une famille entière d'actions) est nommée explicitement plutôt que masquée.