Catalogue des façades & entrypoints de Synedre OS

Catalogue des façades & entrypoints — Synedre OS

Ce chapitre recense les points d'entrée exécutables du harness agentique avec, pour chacun, sa famille, son rôle en une ligne et son mode d'invocation type (cron / CLI / skill / hook / lib), afin qu'un ingénieur reprenant le dépôt retrouve rapidement quel script fait quoi sans relire des centaines de fichiers.

Principe directeur : les façades email, scan et déploiement sont déclarées façades uniques obligatoires dans la doctrine d'orchestration de l'agent Atlas. Tout appel à ces fonctionnalités doit passer par la façade exposée — jamais par un accès direct aux composants internes.

Périmètre, méthode et couverture du catalogue

Ce chapitre documente l'intégralité des composants actifs de la plateforme Synedre : façades d'automatisation, scripts d'infrastructure et programmes d'orchestration. La méthode de production est programmatique : le premier docstring ou commentaire de tête de chaque fichier est extrait par analyse syntaxique (ast.get_docstring() pour Python, première ligne de description pour les scripts shell), puis croisé avec l'historique des commits récents et le planificateur de tâches actif. Aucun rôle n'est inventé ; quand un fichier ne comporte qu'un en-tête générique, le docstring fonctionnel est repêché quelques lignes plus bas.

Décompte couvert

Historique des recomptages. Les totaux ont évolué rapidement au fil des chantiers : de 391 façades au départ, le dépôt est passé à 720, puis 774, 831, 864, 889, 901, 917, 926, 930, 938, 948 et enfin 949. Chaque saut correspond à une fournée de chantiers documentée dans le journal de régénération ci-dessous. Les anciens totaux (391, 720, 774) ne sont conservés qu'à titre de traçabilité historique et ne reflètent plus l'état courant.

Boucle de régénération miroir

Un mécanisme de détection de dérive compare en continu la date de dernière modification de chaque composant à la date de la dernière documentation. Quand le code est plus récent que la doc, un signal code-newer est émis. Les références documentées comme absentes du dépôt sont exclues de ce calcul de dérive ; elles restent citées à titre de traçabilité historique.

À chaque passe de régénération, la méthode appliquée est la suivante :

1. Recomptage réel des fichiers de premier niveau.
2. Recoupement par nom de base de chaque fichier contre le texte du chapitre — tout fichier absent est catalogué dans la fournée.
3. Croisement avec l'historique des commits récents : seuls les fichiers dont le comportement a réellement changé voient leur ligne de tableau réécrite.
4. Vérification de chaque invocation planifiée contre le planificateur de tâches actif.
5. Scan des chemins cités : tout chemin absent du dépôt est annoté comme référence morte documentée.

Journal des fournées récentes

Les paragraphes qui suivent résument, fournée par fournée, les composants nouvellement catalogués, les lignes réalignées et les anomalies relevées. Les références mortes (composants supprimés ou déplacés) sont signalées explicitement et exclues du calcul de dérive.

Fournée du 16 octobre 2026

Une façade neuve cataloguée (moteur de génération de couvertures photo, famille §10). Quatre lignes réalignées sur les commits de la veille. Une nouvelle sous-famille créée : import de catalogue depuis une plateforme e-commerce tierce (§15). Signal code-newer : le moteur de génération de couvertures photo avait été mis à jour la veille sans que la doc suive — la cause est un changement de méthode de résolution d'un chemin binaire interne. Soixante-huit références mortes documentées comme telles, exclues du drift.

Points à confirmer : cadence planifiée de deux composants (boucle de réinitialisation de la démo nocturne, audit SEO mensuel) — absents du planificateur au moment de la vérification, seule la migration de déclenchement du second existe.

Fournée du 15 octobre 2026

Douze façades neuves et un garde de session catalogués. Douze lignes réalignées. Nouvelle sous-famille : reprise d'une version majeure d'une plateforme e-commerce open source (§15). Signal code-newer sur le composant de traitement des commandes humaines.

Nouveautés documentées :

• Courrier interne et copies (§9) : canal dédié vaisseau-mère → responsable (boîte canonique, reply-to configuré, identifiant de message réel) ; module de copie unique par brouillon à valider.
• Reprise plateforme e-commerce v9 (§15) : quatre façades couvrant la charte graphique, la migration, les modules et les redirections.
• DNS et hébergement (§14) : appel à l'API de panneau de contrôle d'hébergement via session sécurisée sans identifiant en clair ; comparaison de deux zones DNS avant bascule ; provisionnement de l'espace privé des fondateurs.
• Vigies (§10, §15) : lecture paginée du blog pour le dictionnaire ; audit SEO mensuel par client ; réinitialisation nocturne de la démo.
• Diffusion Medium (§10) : le publieur de contenu gagne un canal Medium par navigation (deux articles par mois au plus, après validation manuelle).
• Garde de session (§17) : un garde bloquant intercepte les écritures Bash sur les clients en production et exige une confirmation explicite.

Fournée du 13 octobre 2026

Huit façades neuves, trois scripts d'infrastructure et deux gardes de session catalogués. Nouvelle sous-famille : comptes système de recette par client (§6).

Nouveautés documentées :

• Comptes système de recette par client (§6) : registre des comptes, garde d'entrée et vigie, pose du mot de passe sans boîte mail, preuve live de refus d'accès non autorisé. Table de registre dédiée. Le moteur de navigation bucéphale porte huit profils de recette (ports distincts) et une entrée d'autorisation par hôte exact.
• Dossier client (§9) : liste blanche de projets et de fils, assainissement mécanique, rattachement des personnes par adresse exacte.
• Visuels AutoBlog (§10) : point d'entrée cron borné (six visuels par passe, liste fermée de clients, option sonde) ; priorisation des articles déjà publiés ; détection des slots visuels absents.
• Popularité produit (§10) : recopie du signal Search Console dans la table de popularité de la boutique.
• Sauvegarde du coffre humain (§14) : sauvegarde vers stockage objet et restauration de test ; garde empêchant toute exposition publique du coffre.
• Garde du tronc (§14) : script sourcé par les commandes de déploiement pour protéger la branche principale.

Fournée du 12 octobre 2026

Quatre façades neuves cataloguées. Six lignes de tableau réalignées. Un garde de déploiement recensé.

Nouveautés documentées :

• Liaison ventouse In-Situ (§3) : service SSE sortant avec requêtes signées ; coupe-circuit de garde des coûts du compte public ; relais et réponse par connexion distante sécurisée. Tables de demande et d'état dédiées.
• Garde des coûts (§10) : les composants de génération d'images et de données SEO appellent désormais une vérification de quota payant avant tout appel réseau.
• Gate live et préproductions (§14) : une préproduction derrière authentification HTTP n'est plus considérée comme défaillante sur un code 401.
• Vue Machines (§14) : table recensant les équipements de la flotte (box de navigation, serveur tampon, postes et appareils) ; route hub mise à jour.
• Déploiement (§14) : le garde post-commit redéploie aussi l'atelier de préproduction de la démo quand un fichier concerné change ; un verrou par four empêche deux déploiements simultanés au même instant.

Fournée du 11 octobre 2026

Neuf façades neuves, trois scripts d'infrastructure et un garde pre-commit catalogués. Environ trente lignes réalignées. Nouvelle sous-famille : cinquième harnais natif de tentacule.

Nouveautés documentées :

• Harnais natif supplémentaire (§3) : lanceur borné (garde anti-contributeur externe, modèle dédié) ; sortie résidentielle via le moteur de navigation (refus des adresses de datacenter par le fournisseur et de SOCKS par la CLI) ; client de suivi de quota (la commande de service rend quota et tokens que la commande d'exécution ne rend pas). Câblage sur les profils d'harnais, le routeur d'appels agents, la vision CLI, la consommation CLI, l'index des gardes, le méta-harnais portable et le fractionnement de session.
• Traitement email par ventouse (§9) : veille par indicateur, traitement à la minute, accord sur mot-clé de validation, règles de rédaction avec promesses du fil, rejeu à blanc avec deux juges, taux de validation suivi chaque semaine. Tables de scénarios et de simulation dédiées.
• Journal des livraisons (§14) : appelé en fin de déploiement pour dater une mise en production sans dépendre d'un bouton d'interface.
• SEO (§10) : vigie technique multilingue en lecture seule ; marquage de statut SEO ; classification des écarts d'indexation par cause ; lecture d'un vecteur de recherche stocké (gain de performance significatif).
• Sécurité et flotte (§14/§16) : rôle de lecture seule en base sans repli sur le propriétaire ; suppression d'un plancher codé en dur dans le pilote d'autonomie ; garde pre-commit sur la synchronisation des fiches agents ; cible de dérive Drizzle étendue à l'atelier de préproduction de la démo ; plafond des ventouses en aspiration relevé de 30 à 40.

Fournée du 10 octobre 2026

Seize façades neuves et un script JavaScript catalogués. Environ trente lignes réalignées. Trois gardes câblés recensés.

Nouveautés documentées :

• Comptes tiers (§2) : mot de passe généré, chiffré et saisi dans le même processus (dix invariants de sécurité) ; empreinteur HMAC lu par un garde de session ; migration de métadonnées avec retour arrière ; vigie des invariants (seuil zéro écart). Garde bloquant interceptant toute saisie en clair. La commande /password consulte le registre sans jamais restituer de valeur.
• Secrets des serveurs clients (§2) : la fiche de flotte déclare l'emplacement des secrets ; un collecteur les remonte au registre toutes les quinze minutes.
• Déploiement — four et secrets hors build (§14) : déport de la compilation sur une machine locale dédiée (défaut : tous les clients, avec garde sur les secrets figés) ; analyse de sortie bloquante par défaut depuis cette date ; refus de deux clients dont les secrets ne vivaient que dans le build ; file FIFO (un seul build à la fois) ; repli disque sur les assets statiques en cas de 404 ; scripts de provisionnement de nouveaux serveurs (Ubuntu, protection SSH, fail2ban) ; rétention de sauvegardes allongée.
• SRE (§14/§16) : médecin du vaisseau-mère (liste fermée de soins, journal d'actes, cadence régulière) ; sonde de comptage JavaScript initial ; vigie de stock VPS ; optimisation CPU de la barre d'état.
• SEO et marché (§10) : règle immuable « on adapte au marché, on ne traduit pas » (garde bloquant + fichier de règles strictes) ; rédaction de fiches EN/DE depuis un brief de marché en base ; critère de fiches maigres relu en base ; invariants de locale ; inspection et vérification Search Console.
• Tentacules et acquisition (§3/§9) : réponse automatique périodique d'une ventouse (plafond en tours, jamais une validation) ; promotion prospect → client ; garde de portée de session.

Fournée du 8 octobre 2026

Six façades neuves cataloguées. Onze lignes de tableau réalignées.

Nouveautés documentées :

• Vue Retoucher des courts métrages (§11) : mesure du rythme plan par plan ; options d'assemblage par plan (avant/après/silence) ; bouton « Rejouer » incrémentant le numéro de version sans écraser les fichiers précédents ; presets de jeu récoltés sur les plans gardés. Deux opérations de daemon et deux migrations dédiées.
• AutoKUR (§10/§15) : noms lisibles pour les motorisations homonymes ; nombres dans les textes de catégorie remplacés par des gabarits paramétrables ; seed de rattachements seuls ; guides de catégorie générés ; refus d'un précalcul périmé.
• Acquisition, ton et devis (§9/§12) : comptage séparé des relances dans le registre de prospection ; ton de rédaction par membre de l'équipe ; devis à la charte avec annexes en base.
• Recette plateforme e-commerce (§14) : mesure du mode debug sans lecture du fichier d'environnement ; refus de l'ambiguïté de nom de module.

Fournée du 7 octobre 2026

Une façade neuve cataloguée. Neuf lignes de tableau réalignées.

Nouveautés documentées :

• Rappel de rendez-vous (§9) : envoi d'un email une heure avant chaque rendez-vous, destinataire unique.
• Mesure d'indexation (§10) : comptage limité aux catégories actives ; exclusion des pages auto-fermées en noindex du calcul du manque ; inspection par lots avec rejeu des lots défaillants ; mesure de la demande sur plusieurs requêtes candidates.
• Diffusion et courts métrages (§10/§11) : étiquette IA obligatoire et relue (refus fermé) sur YouTube et TikTok ; partage de reel Instagram en pleine longueur (borné à 60 s) ; vérification de la vidéo sur le téléphone avant publication ; plan « off » muet ; prise retournée sans écrasement ; mélodie repliée d'octave.
• SEO et commercial (§10/§12) : lecture Search Console sous la propriété, pas sous l'URL du site ; option de proposition commerciale sans méthode jointe.

Fournée du 6 octobre 2026

Cinq façades neuves cataloguées. Quatorze lignes de tableau réalignées.

Nouveautés documentées :

• Pool de tentacules (§3) : gestionnaire de pool avec spawn borné.
• Registre des credentials (§2) : pose d'une clé de client sans terminal, par dépôt du coffre détruit à la lecture ; sens entrant du composant de transmission de secrets.
• Communauté (§9) : publication des forums par file à créneaux (toutes les cinq minutes) — plus jamais en rafale.
• Diffusion et courts métrages (§10/§11) : courts métrages du blog comme troisième source de l'exception vidéo ; atelier avec identifiant et bouton de suppression ; un seul setup de style ; doublage en boucle fermée sur la mesure du juge ; carton gris clair.
• Blog et SEO (§10) : politique client inactive respectée par le réassort ; publication de couverture purgeant le cache SSR ; détection de doublon de titre sans virgule ; juge des visuels signalant sa propre panne.
• Migrations, email et session (§14/§9/§3) : refus des DDL concurrents par nom ; porte de recette email sans citations du correspondant ; relance fiable du superviseur de session (fils directs uniquement).

Fournée du 5 octobre 2026

Dix façades neuves cataloguées (dont un garde de version POS dans les scripts d'infrastructure). Vingt lignes de tableau réalignées. Deux gardes de session recensés.

Nouveautés documentées :

• Diffusion image Instagram (§10) : plan de scènes vers images vers file ; statistiques des posts lus sur le téléphone (lecture seule) ; taille des hashtags candidats relevée sur le téléphone (plafond 30 tags distincts sur 7 jours) ; classement bayésien des hashtags (exploration/exploitation, conseil en sortie). Le moteur de diffusion sociale gagne la règle des 14 jours par réseau et le sceau du média validé.
• Communauté (§9) : trois réponses de forum par jour (sujets sans réponse des forums de support retenus) ; fil relu en direct avant rédaction ; refus du Markdown ; relance de rédaction sur refus de forme ; refus de publication conservé en base.
• Rapport SEO (§10) : indice de confiance A/B/C/D par mesure ; deuxième source de rang indépendante.
• Assistant IA des boutiques (§16) : vigie des questions sans bonne réponse avec recette de nuit ; purge datée des données obsolètes.
• Déploiement (§14) : arbre stable pendant le build ; traîne des assets statiques bornée par l'âge ; variable de design system obligatoire dans le bloc de configuration du gestionnaire de processus.
• Vigies et gardes (§16) : vigie de disponibilité des créneaux de rendez-vous ; garde de version majeure du socle fiscal de la caisse.

Fournée du 3 octobre 2026

Dix-neuf façades neuves cataloguées. Trente et une lignes de tableau réalignées. Quatre gardes câblés recensés. Quatre références ligne-de-fichier recalées.

Nouveautés documentées :

• Autoblog et blog (§10) : rédaction par un seul fournisseur IA dédié, sources d'autorité, visuels du corps avec abandon au troisième refus, seuil de tête mensuel, profil « avatars » pour site vitrine sans catalogue, garde de cadence (trois articles par semaine maximum).
• Rédaction SEO catalogue sous sceau (§10) : fiches de marché rédigées en anglais et en allemand depuis un brief en base ; rappel de l'indexation en fin d'import fournisseur.
• Lisibilité par les assistants d'achat (§10) : pont entre le moteur de fiche produit et la sentinelle SEO.
• Courts métrages en base (§10/§11) : bible vidéo en base, montage sur bande son, doublage de voix, publication via le téléphone et file de validation.
• Publication X (§10) : reprise après éditeur non refermé.
• Tentacules (§3) : second regard du réconciliateur ; délai de démarrage relevé ; script d'ouverture de ventouse.
• Déploiement (§14) : cache SSR conservé, préchauffage puis balayage, option --cache-buster de la garde de navigation.
• OVH (§14) : reprise sur défaillance passagère (jamais sur POST) ; option de retrait d'adresse IP.
• Import Search Console (§10) : flotte étendue, secrets hors arguments de commande.
• Audits (§6) : arbre CMS orphelin, registre des égalités de locale, lots natifs multilingues d'un client catalogue.

Fournée du 1er octobre 2026

Trente-trois façades neuves cataloguées. Diffusion sociale, pool de tentacules et délégations réalignés. Sept gardes de session recensés.

Sous-systèmes ayant réellement bougé et relus dans le code :

• Diffusion sociale (§10) : quatre sources, file de validation, trois créneaux par jour, garde « une voix » 48 h, source vidéo.
• Pool de tentacules (§3) : plafonds, dégel, échéance du critère, délais d'attente, recrutement par le chef, réconciliateur.
• Délégations (§9) : nouvelle sous-famille dédiée.
• Communauté (§9) : forum élargi, relevé de statistiques de page, relevé LinkedIn.
• Blog (§10) : rédaction par fournisseur dédié, sources d'autorité, visuels du corps, traduction du blog retirée du relais.
• Maillage des sites (§10) : pôles SEO, Performance et Sécurité ; audit à la demande.
• Iso-Figma (§6) : navigateur local sans le moteur de navigation principal.

Fournée du 27 septembre 2026 — régénération complète

Quatre cent cinquante-trois lignes de catalogue ajoutées. Quarante-cinq composants code-newer réalignés. Références ligne-de-fichier recalées. Section des gardes recomptée.

Cette fournée constitue la première régénération exhaustive : chaque fichier de premier niveau du dépôt a été confronté au chapitre par nom de base — 397 façades d'automatisation et 42 scripts d'infrastructure n'y figuraient pas encore. Trente-neuf nouvelles sous-familles ont été créées, couvrant notamment :

• Registre des credentials et MCP
• Résolution de portée de session
• Harnais Codex et méta-harnais portable
• Iso-Figma et communauté e-commerce
• Permanence vocale et emails système
• Autoblog, FAQ blog, couvertures de catégorie
• Forum de dialogues entre agents
• Indexation par vagues et maillage interne
• Glossaire multilingue et netlinking
• AutoKUR (deux déclinaisons), diffusion sociale
• Moteur de navigation (bucéphale), Figma
• FinOps, dépenses fournisseurs, budget de modèle
• Bascule entre serveurs, approvisionnement OVH
• Regroupement de variantes, connecteurs e-commerce
• Gouvernance des automates, vigies de rendu

Points saillants des réalignements code-newer :

• Le moteur SEO principal : ses trois lignes de planificateur sont toutes désactivées (usage effectif = CLI ou appelants) ; exceptions de nommage de slug, barrière de sécurité rétablie, normalisation JSON des valeurs du modèle de langage, FAQ multilingue.
• Le moteur de génération de fiches produit : coupe de titre sans mot de liaison orphelin, clause catégorie/caractéristiques alimentaire.
• Le moteur de travaux : harnais choisi par tâche puis par agent, clé de reprise de session, fenêtre de log tête+queue pour la recette.
• La porte de courrier entrant : vérification DKIM alignée sur le domaine de l'expéditeur, refus fermé.
• L'import Search Console : clé de déchiffrement essayée parmi deux variables d'environnement.
• Le démon CLI : profils autorisés désormais issus du registre des profils d'harnais.
• Le méta-harnais : Codex et le second harnais reçoivent réellement les gardes de session.

Anomalies relevées lors du cataloguage (non corrigées dans cette passe) : treize docstrings ou commentaires de planificateur périmés ; quinze façades conçues pour tourner en planificateur mais sans ligne active ; hôte ou conteneur codé en dur dans cinq scripts ; deux scripts défaillants.

Fournées antérieures — résumé

Les fournées de juillet et septembre 2026 ont constitué les premières grandes vagues de cataloguage. En voici les points marquants :

• Nettoyage des composants morts (juillet 2026) : soixante-deux références supprimées du dépôt ont été annotées comme telles (corbeille traçable, grâce de trente jours) plutôt que retirées silencieusement. Deux faux négatifs détectés : deux composants appelés dynamiquement par le moteur de maintenance nocturne étaient invisibles au grep statique malgré la passe de repêchage.
• Atelier 3D (septembre 2026) : expansion massive — vingt façades de production de planches techniques et anatomiques, treize helpers de qualité de ressemblance. Nouvelle sous-famille de pool de tentacules avec tables dédiées.
• Harnais multi-profil (juillet→septembre 2026) : le démon CLI est passé de mono-profil à multi-profil (flag de sélection de profil, whitelist de valeurs réseau jamais interpolées sans validation préalable). Mécanisme de mise en veille douce d'une ventouse (0 % CPU, RAM libérée, transcripts conservés) distinct de la fermeture définitive.
• Fractionnement de session (juillet→septembre 2026) : six commits en une journée ont affiné le comportement : état posé en base à chaque franchissement de seuil, compteur de tours remis à zéro sur chaque compaction, camp de relance pour les ventouses de pool, sidecar d'adresse pour éviter la reprise du handoff d'une autre ventouse, réalignement du modèle en base sur le modèle réellement utilisé, horodatage en heure locale pour la lisibilité humaine.
• Comptes tiers et secrets (octobre 2026) : voir fournée du 10 octobre ci-dessus.
• Planificateur propre (revérifié) : croisement du planificateur actif avec le catalogue — zéro entrée morte dans les lignes actives. Nouvelles entrées actives depuis juillet 2026 : moteur de travaux 3D, synchronisation de taxonomie, suivi de rang, réconciliation des réponses, audit de crontab, détection de récidive de cicatrice, fractionnement de session, et une dizaine d'autres.

Légende des modes d'invocation

Familles de composants et flux d'ensemble

Le système s'organise en plusieurs familles fonctionnelles qui collaborent autour d'un bus central. Le schéma ci-dessous illustre le cheminement d'un signal depuis son entrée jusqu'à son exécution.

Vue d'ensemble du flux

                  ┌─────────────────────────────────────────┐
 email entrant ──►│  Réception & ingestion des messages      │
                  └──────────────────┬──────────────────────┘
                                     │ classification d'intention
                                     ▼
                  ┌─────────────────────────────────────────┐
 /hub, CLI   ───► │  Orchestration  (spawn, react, qa)       │
                  └──────┬──────────────────┬───────────────┘
                         │                  │
             chantiers   │                  │  exploration
                         │                  │
                         ▼                  ▼
      ┌──────────────────────────────────────────────────────┐
      │          Exécution des agents et des tâches           │
      └──────┬───────────────────────────────────────────────┘
             │
  ┌──────────┼────────────┬─────────────┬──────────────────┐
  ▼          ▼            ▼             ▼                   ▼
audits    blog/seo    finance       navigateur           déploiement
  │          │            │             │                   │
  └──────────┴────────────┴─────────────┴───────────────────┘
                          │
                          ▼
               Base de données relationnelle
               (façade d'accès centralisée)

Familles fonctionnelles

• Réception & ingestion — surveille les boîtes de réception, normalise les messages entrants et en extrait l'intention avant de les transmettre à l'orchestrateur.
• Orchestration — point de convergence entre les requêtes issues du hub web, de la ligne de commande et des emails. Il décide du composant suivant : ouverture d'un chantier, lancement d'une exploration ou délégation à un agent.
• Exécution des agents et des tâches — couche qui appelle les agents nommés (Mitnick, Turing, Brunel, Eames, Lovelace, etc.) et gère le cycle de vie de chaque tâche (run, retry, statut).
• Audits — analyse la qualité technique et éditoriale des livrables produits par les agents.
• Blog / SEO — pilote la génération et la publication d'articles optimisés pour les moteurs de recherche.
• Finance — gère la facturation et le suivi des paiements liés aux chantiers.
• Navigateur automatisé — contrôle un navigateur headless pour les tâches nécessitant une interaction avec des interfaces web.
• Déploiement — orchestre la mise en production des livrables via les commandes ./deploy et ./ship.

Modèle de données

L'ensemble du système s'appuie sur une base de données relationnelle unique, accessible exclusivement via une façade Python centralisée. Toutes les familles de composants passent par cette façade : aucun module n'interroge la base directement sans passer par cette couche d'abstraction.

Un second module centralise le chargement des variables d'environnement, garantissant que les secrets (clé API du fournisseur IA, mot de passe de base de données, jetons d'intégration…) ne transitent jamais en clair dans le code source. Ces valeurs sont déclarées dans des fichiers d'environnement exclus du contrôle de version.

Principe de sécurité : aucun secret n'est écrit dans le code ou dans la documentation. Toute valeur sensible est référencée par son nom de variable et chargée à l'exécution depuis l'environnement de la machine hôte.

Socle commun — bibliothèques et façades transverses

L'ensemble des automates et agents Synedre s'appuie sur un jeu de bibliothèques partagées : façades de base de données, journalisation structurée, abstraction IA, contrôle des secrets, résolution de tenant et outillage de déploiement. Cette section décrit chaque composant par son rôle fonctionnel.

Infrastructure de base

Supervision des crons

Le gardien de timeout des crons enveloppe chaque automate planifié avec un délai d'expiration par défaut de 300 secondes. Des dérogations par script sont déclarées pour les tâches longues : par exemple, la boucle de maintenance nocturne bénéficie d'un plafond étendu à 12 600 secondes, la boucle de compaction mémoire à 3 600 secondes. Une dérogation supplémentaire couvre la recette nocturne de l'assistant IA d'un client (32 questions, pause de 10 secondes entre chaque cas pour respecter le plafond de débit du fournisseur ; durée mesurée : 384 secondes en conditions normales, pire cas estimé à 3 200 secondes).

Le battement de cœur des crons prouve qu'un automate s'est réellement exécuté (et pas seulement lancé) : chaque passage commis écrit un horodatage dans la table de supervision. Ce mécanisme est appelé depuis une vingtaine de modules au minimum, couvrant notamment les automates WhatsApp, le collecteur de messagerie, le détecteur d'entropie, la vigie de quotas et le détecteur de silence. Le détecteur de silence lui-même se bat à chaque sweep réussi (hors mode simulation), avec un intervalle attendu de 5 minutes et un seuil de silence de 15 minutes.

Façade IA agnostique

La façade IA agnostique route les appels LLM vers le fournisseur approprié (Mistral, Claude, OpenAI, DeepSeek, Gemini, ou le forfait CLI Google) sans que les automates aient connaissance du fournisseur sous-jacent. La clé API du fournisseur IA est lue depuis l'environnement et n'est jamais journalisée.

• Le canal CLI Google (forfait) exécute le binaire CLI dans un répertoire temporaire vide créé pour l'occasion et supprimé après l'appel. Ce confinement empêche le processus d'écrire des fichiers dans le dépôt de l'appelant — comportement observé sans cette mesure. Un répertoire de travail explicite peut être fourni par l'appelant ; les autres fournisseurs ignorent ce paramètre.
• Le canal API Google utilise une clé API dédiée lue depuis l'environnement ; en l'absence de clé valide, le système bascule automatiquement sur le canal CLI.
• La tarification par fournisseur est centralisée dans la façade, y compris les modèles à coût marginal nul du forfait CLI.

Point à confirmer : le câblage exact du routage autoblog vers le canal CLI n'a pas été relu dans cette version de la documentation.

Invocation d'agents

La façade d'invocation d'agents permet à tout automate d'appeler un agent Synedre, quel que soit le harnais sous-jacent. Le harnais peut être spécifié explicitement ou déduit de la variable d'environnement de session ; la valeur par défaut est Claude. Un harnais inconnu provoque une erreur immédiate.

Chaque harnais fonctionne en lecture seule — un appel d'agent rend du texte, n'écrit rien. Pour les harnais alternatifs (Codex, CLI Google, Muse Code), la commande est construite avec les drapeaux appropriés :

• Codex : mode éphémère, dépôt ignoré, sortie JSON, lecture seule.
• CLI Google : mode plan, sortie JSON, exécuté dans un répertoire temporaire neutre avec une consigne explicite « n'utilise aucun outil » (sans quoi le processus tente des commandes et rend une réponse vide).
• Muse Code : appel via le client MSP dédié, écriture et accès shell désactivés, quota consommé enregistré localement. Les sorties réseau de Muse transitent par un proxy d'émission dédié ; Codex et le CLI Google sortent en direct.

Le coût LLM de chaque appel est enregistré dans le journal des agents avec le nom du harnais utilisé. Le journal écrit le codename interne de l'agent même si l'appelant fournit un nom affiché différent.

python3 -m <invocateur-agent> --harness <claude|codex|antigravity|muse> --agent <codename>

Autres façades transverses

Moteur de réflexes décentralisés

Le moteur de réflexes est branché sur les événements d'outils (lecture, écriture, édition, navigation web, appels d'agents). Il lit un événement JSON sur l'entrée standard, consulte la table de réflexes, prend une décision (autoriser, avertir ou refuser) et trace l'audit. Le code de sortie 0 signifie autorisation, 2 signifie refus.

La loi d'asymétrie gouverne l'ajout de réflexes : tout nouveau réflexe durcit les permissions ou maintient le statu quo — jamais d'autorisation large. Les zones sensibles sont fail-closed (refus en cas d'incertitude).

Un script de seed idempotent initialise les réflexes du tronc commun en base de données. Il est descriptif uniquement ; la source de vérité du câblage reste le fichier de configuration des hooks.

Détecteur de silence et d'échec des crons

Le détecteur de silence s'exécute toutes les 5 minutes. Il lit la table de battements de cœur et ouvre (ou incrémente) un incident de supervision sur deux sondes distinctes :

1. Silence : aucun battement reçu depuis plus longtemps que le seuil configuré. Un cron mort-né (jamais exécuté) compte. Un épisode n'alerte qu'une fois.
2. Échec installé : le dernier battement indique un état d'échec depuis au moins deux passages consécutifs. Cette sonde n'a pas de garde d'alerte unique — elle signale à chaque passage tant que l'échec persiste.

Lorsqu'un cron reprend (battement reçu, ou battement reçu en état OK), l'incident est refermé avec un motif daté. Si la base de données est inaccessible, le passage est ignoré sans erreur. Le mécanisme peut déclencher une escalade vers Atlas (une fois par épisode).

Outillage de déploiement

La bibliothèque de déploiement partagée fournit les helpers communs à toutes les cibles de déploiement :

• Détection de mutation du dépôt pendant le build : si une source du build (pages, dépendances, lockfile) est modifiée entre le départ et la fin d'un build (par un merge-back concurrent par exemple), le build est recompilé ou refusé. En cas d'impossibilité de lire l'état Git, le comportement est fail-open.
• Gestion de la traîne de cache : les fichiers statiques de l'ancienne version sont conservés un nombre de jours configurable (7 par défaut) pour éviter les erreurs 404 des robots d'indexation qui accèdent aux pages longtemps après leur lecture. Un fichier déjà repris est supprimé quand son horodatage dépasse l'âge maximal.
• Propagation de variables d'environnement : l'étape de déploiement propage certains jetons depuis l'environnement du vaisseau-mère vers l'environnement runtime du tenant. Cette propagation ne suffit pas si le gestionnaire de processus ne liste pas explicitement la variable dans son bloc d'environnement.

Le script de préchauffage et balayage du cache SSR s'exécute en arrière-plan après chaque déploiement conservant le cache. Il recalcule les pages pendant que les visiteurs continuent de voir l'ancienne version, puis supprime les entrées de cache antérieures au swap qui n'ont pas été recalculées — à l'exception des sitemaps et des pages devenues des erreurs. Le balayage s'exécute même si le préchauffage échoue, pour qu'aucune entrée de l'ancien build ne survive.

Le parseur de manifeste de déploiement lit et valide le fichier de configuration de déploiement au format YAML, puis émet les paires clé/valeur correspondantes sous forme de variables shell correctement échappées.

Isolation de travail multi-client (worktrees)

Le système de worktrees persistants affecte à chaque client un espace de travail Git isolé (index, HEAD et fichiers propres). Plusieurs terminaux peuvent ainsi travailler sur plusieurs clients simultanément sans collision sur le tronc partagé. La branche de chaque client est réintégrée automatiquement dans la branche de pré-production après chaque commit (hook Git natif).

Un garde-fou de confinement vérifie avant chaque commit que les fichiers modifiés appartiennent bien au couloir du client actif. Ce garde-fou reconnaît deux topologies de dossier client : le modèle tenant standard et les clients legacy hors modèle tenant.

La commande wt gc (ramasse-miettes des worktrees) retire les espaces de travail des tentacules inactives. Elle normalise les noms de sessions tmux pour tous les harnais (Claude, Codex, CLI Google) et traite correctement le cas d'un worktree supprimé puis recréé au même chemin.

Le merge-back (réintégration de la branche client dans le tronc) est protégé contre les verrous d'index Git tenus par des sessions sœurs : si un git merge --abort est refusé, il est rejoué jusqu'à un nombre maximal de tentatives configurable, avec une pause entre chaque essai.

Cicatrice 2026-09-26 : un verrou d'index tenu par une session sœur avait laissé le tronc en état de merge partiel pendant 25 minutes, paralysant toutes les sessions. Le mécanisme de rejeu a été introduit pour prévenir cette situation.

Filet de borne des sorties LLM

Le filet de borne des sorties d'outils limite ce que le modèle voit dans le contexte de la conversation : la sortie brute d'un outil est tronquée avant d'être injectée dans le contexte, mais le journal complet reste disponible sur disque. Ce mécanisme réduit significativement le coût LLM — environ 72 % du coût provenait de l'accumulation non bornée des résultats d'outils dans le contexte. Il est câblé comme hook et importé directement par plusieurs automates.

Plafond de contexte des sous-agents

Le hook de plafond de contexte sous-agent surveille la taille du contexte dans les sessions imbriquées (sous-agents). Lorsque le nombre de tokens dépasse le seuil configuré (80 000 par défaut), tout nouvel appel d'outil est refusé, forçant le sous-agent à conclure. En cas d'erreur du hook, le comportement est fail-open. Un interrupteur d'urgence permet de désactiver ce mécanisme.

Ce hook est câblé en phase avant l'outil (PreToolUse). Un câblage erroné en phase après l'outil avait laissé passer plusieurs milliers de refus non appliqués sur deux cents sous-agents — certains recevant jusqu'à 114 refus ignorés — avant d'être corrigé.

Journal des agents

La façade de journal des agents écrit en base de données, de façon atomique et best-effort (sans jamais lever d'exception), les événements suivants :

• Réunion quotidienne (upsert atomique par CTE)
• Activité générale d'un agent
• Résolution d'un élément de réunion
• Battement de cœur d'un agent

Charte visuelle des artifacts

La charte visuelle des artifacts fournit un CSS autonome embarqué (police Courier Prime, mode sombre par défaut avec bascule vers le mode clair, sans dépendance CDN, compatible avec une politique de sécurité de contenu stricte) et une fonction d'encapsulation qui pose le shell HTML de chaque artifact : barre haute sticky, identifiant de tentacule, version, lien et bouton de bascule de thème.

Commandes éphémères et vérification de copiabilité

La commande éphémère permet à une session IA d'enregistrer en base de données une commande à exécuter, sans demander à l'opérateur de la copier manuellement depuis le chat. Le Hub l'affiche sous forme de bouton dans le pied de page. Modes disponibles : enregistrement, liste, exécution, rejet.

Le vérificateur de copiabilité s'assure qu'une commande destinée à l'opérateur est copiable d'un seul geste : une seule ligne (sans continuation), sous la largeur du terminal, sans verbe destructif non nommé, sans piège d'isolation de worktree. Il ne réécrit rien — il signale uniquement.

Contexte de démarrage de session

Le module de contexte de démarrage fournit un contexte initial identique aux sessions Claude, Codex et CLI Google :

• Pour Codex (qui n'a pas de mémoire native) : injection de l'index mémoire au démarrage de session.
• Pour le CLI Google : au premier événement de conversation, les producteurs de contexte (mémoire, cicatrices, brief de session) sont lancés et leurs sorties injectées.

En cas d'erreur, le comportement est fail-open.

Lecture de partition de skill

Le lecteur de partition de skill est un module pur (sans base de données, disque ni réseau) : il extrait et valide la section Partition d'un fichier de définition de skill (bloc YAML de cues typés), source d'une conduite. L'absence de partition retourne None ; une partition invalide lève une erreur de partition.

Façade de vision par CLI

La façade de vision par CLI interroge un agent IA (Claude, Codex, CLI Google ou Muse) pour analyser des images, selon une table de routage lue en base de données. En l'absence de route configurée, le système échoue de façon fermée — aucun repli implicite. En cas de panne, le message d'erreur indique le code retour, le détail JSON et la fin de la sortie d'erreur.

Muse Code est un fournisseur valide pour ce canal : l'appel utilise le mode lecture d'image, avec écriture, shell et outils web désactivés, dans un espace de travail non approuvé (aucun hook ni skill chargé).

Contrat canonique des événements de harnais

Le contrat canonique des événements définit le schéma stable des événements produits par les différents harnais (Claude Code, Codex, CLI Google, Muse Code). Il traduit les payloads natifs de chaque harnais vers un ensemble de capacités normalisées :

• Cycles de vie : démarrage de session, soumission de prompt, avant/après outil, échec d'outil, événements d'agent, arrêt de run.
• Pour chaque décision, le contrat encode la réponse dans le format attendu par le harnais cible — sans jamais élargir les permissions de l'hôte.
• Le CLI Google n'a pas de canal de retour après l'exécution d'un outil ; ce comportement est documenté à partir d'une sonde réelle.

Le tick de mesure de contexte s'exécute après les outils de Codex et Muse via ce dispatcher ; le payload porte le harnais et le transcript natif.

Dispatcher portable des gardes de sécurité

Le dispatcher portable des gardes normalise les événements entrants via le contrat canonique, applique les gardes, et rencode la décision pour le harnais appelant. Il distingue trois familles :

1. Gardes de plancher (P0) : fail-closed. Une sortie inattendue, un timeout ou une garde absente équivaut à un refus.
2. Gardes de cicatrices : réflexes issus d'incidents passés documentés, identifiés par leur libellé.
3. Gardes dérivées : pour les harnais non-Claude uniquement (Claude les exécute nativement), les gardes sont dérivées du fichier de configuration des hooks Claude et exécutées en parallèle (jusqu'à 16 workers). Un résultat ambigu est traduit en refus.

Après l'exécution d'un outil, les gardes de plancher sont ignorées ; seules les gardes dérivées post-outil s'appliquent.

Tout refus nomme sa règle : l'identifiant de la règle, le fichier qui la définit et la « voie » recommandée sont inclus dans le message de refus. Aucun octet du payload ni du message du hook n'entre dans ce message — il est statique. Cela évite qu'un agent parte inspecter son propre état de façon récursive.

Cicatrice 2026-09-25 : un refus sans indication de voie avait conduit un agent à lancer une recherche récursive dans son propre état, consommant 580 % de CPU et 3,9 Go de RAM.

Les gardes de lecture, de navigation web et d'appel d'agents sont portées vers Codex, le CLI Google et Muse Code via projection vers le contrat Claude. Les gardes de skill et de question à l'utilisateur restent propres à Claude.

Registre des credentials — source de vérité chiffrée

Le registre chiffré des credentials est la source de vérité unique pour tous les secrets de la plateforme. Les fichiers d'environnement (.env*) en sont des dérivés, conformément à une doctrine à cinq niveaux. Aucun secret ne doit exister dans un fichier d'environnement sans avoir été préalablement enregistré dans le registre.

Composants du registre

Gestion des comptes web tiers

Les comptes web tiers (identifiants de connexion sur des services externes) sont gérés par un ensemble de composants dédiés qui appliquent des invariants stricts :

• Le mot de passe naît dans le processus (généré de façon cryptographiquement sûre), est chiffré immédiatement et ne sort jamais en clair.
• Aucune option ne reçoit le mot de passe en argument.
• La ligne de registre est créée en état pending avant la saisie, pour éviter toute fenêtre sans trace.
• La rotation conserve l'ancienne valeur chiffrée jusqu'à confirmation explicite.
• La révocation date le compte et vide ses blobs chiffrés.
• Chaque opération génère une ligne d'audit sans valeur ni hash.

Un empreintier de mots de passe calcule une empreinte HMAC (dérivée de la clé maître) stockée dans un fichier local protégé. Cette empreinte permet à un hook de détection de détecter une saisie en clair sans jamais avoir accès au mot de passe réel.

Une vigie de cohérence vérifie à la demande (jamais en cron automatique) que le registre, l'empreintier et l'audit sont cohérents. Elle contrôle notamment que les comptes révoqués ont bien leurs blobs vidés et que l'empreintier n'est pas plus ancien que la dernière écriture.

Un collecteur de secrets serveur remonte automatiquement les secrets nés sur un serveur client vers le registre central. Chaque ligne de flotte déclare où vivent ses secrets ; le collecteur les lit côté serveur (en mémoire, sans affichage), chiffre et upsert uniquement si la valeur a changé.

Pont MCP — SEO en lot, tokens tenant, serveur d'outils multi-harnais

Trois façades gravitent autour du protocole MCP (Model Context Protocol) : un client HTTP pour les opérations SEO en lot vers un client, un émetteur de token tenant sécurisé, et un serveur d'outils partagé entre tous les harnais.

Transport SQL et accès en lecture/écriture gardé

Un ensemble de façades assure l'accès contrôlé à la base de données de la flotte :

Résolution de tenant — scope de session et cible d'écriture

La vérité unique sur l'identité d'un client, la session qui le pilote et la machine sur laquelle on écrit est centralisée dans le registre de la flotte. Aucun identifiant en dur, aucune adresse IP codée directement dans les scripts.

Composants de résolution

python3 -m <resolveur-tenant> <nom-du-client> --needs db,nuxt,prestashop

Commit isolé et intégrité de l'index Git

Le commit isolé par verrou protège l'index Git partagé contre les collisions entre sessions parallèles : chaque commit est réalisé sous un verrou global, ce qui empêche une session de corrompre l'index d'une autre session travaillant simultanément.

Famille orchestration — Vue d'ensemble

Ce groupe de composants forme le cœur opérationnel de l'orchestration agentique : réception et classification des demandes entrantes, spawn des agents, suivi des tâches, gestion des coûts et coordination des équipes de ventouses.

Doctrine d'invocation : tout spawn d'agent headless passe obligatoirement par le pont de spawn node-pty. L'invocation directe du CLI de l'agent est interdite. Cette règle est contrôlée mécaniquement.

Composants principaux

Sous-famille — Pont CLI vers cockpit

Pipeline ajouté pour relier la session interactive de l'agent au cockpit de suivi en temps réel. La session peut déclarer quel chantier elle pilote ; un ensemble de composants anime alors la vue du chantier via la table des événements d'agent. Un kill-switch désactive l'ensemble sans interférer avec les runs.

Le pont de spawn node-pty reste le seul moyen autorisé de spawner un agent headless. Toutes les invocations programmatiques passent par lui.

Sous-famille — AgentRunner multi-LLM

Architecture d'exécution agentique provider-agnostique : un contrat commun AgentRunner et N backends routés par travail. Tous les événements alimentent la table des événements d'agent (cockpit) ; les coûts sont tracés via la table de coûts croisée au catalogue de tarification (zéro prix en dur dans le code).

Sous-famille — Pool de ventouses (fan-out)

Une équipe de ventouses peut être spawnée d'un geste depuis le cockpit terminal. Le pool porte une enveloppe commune avec deux bornes distinctes : un plafond de tours (messages échangés) et un plafond de coût en euros — aucun des deux ne remplace l'autre. Les messages échangés entre ventouses d'un même pool sont typés et conservés en base ; seuls des champs courts voyagent dans le payload, les données volumineuses passent par une référence d'artefact.

Sous-famille — Adaptateurs du harnais Codex

Chaîne d'adaptateurs pour le harnais Codex : transport JSON-RPC → registre de sessions → démon de pilotage ; brief d'agent et garde de contexte branchés au lancement et en hook.

Sous-famille — Meta-harnais portable (Claude / Codex / Antigravity)

Registre de profils, paquet transportable de skills, relais des hooks vers les harnais alternatifs et sentinelle de leurs sessions. Le paquet et le registre sont des artefacts de transport et de découverte — jamais des commandes d'activation.

Sous-famille — Muse Code, 5e harnais natif de ventouse

Muse Code (Muse Spark 1.3, abonnement Power) rejoint les quatre harnais existants comme CLI de ventouse. Le fournisseur refuse les adresses IP de datacenter : tout appel sans interface résidentielle passe par un relais local, jamais directement. Les hooks P0 sont projetés vers le fichier de hooks Muse ; la parité est mesurée automatiquement (zéro manquant sur les quatre harnais).

Sous-famille — Liaison ventouse du cockpit In-Situ

Le cockpit In-Situ d'un site client est relié à la mothership : une demande tapée dans le cockpit est remise à la ventouse du tenant, qui la traite avec le LLM de son harnais et répond dans le cockpit. La mothership n'expose aucun port public : elle ouvre une connexion SSE sortante vers chaque site client et répond par des POST signés (clé partagée stockée dans la configuration du tenant, jamais affichée). Aucun LLM dans le transport. Une demande dont l'identifiant est déjà connu ne sera remise qu'une seule fois, même en cas de rejeu.

Wrapper tmux multi-profil

Le wrapper tmux de pilotage CLI sélectionne la session tmux et le binaire au lancement selon le profil demandé :

• claude : session synedre-claude, binaire agent principal via variable d'environnement.
• glm : session synedre-glm, proxy local vers le modèle GLM (jamais le service Z.ai en direct).
• codex : session synedre-codex, CLI Codex natif.
• antigravity : session synedre-antigravity, CLI Antigravity (agy, Gemini), effort low / medium / high.
• muse : session synedre-muse, lanceur borné Muse Code.

Sous-commandes disponibles : start, status, list, send-keys, send-ctrl, send-special, capture, stop, stop-keep. La sous-commande stop-keep tue la session tmux en conservant l'espace de travail et les transcripts (conçue pour la bascule de harnais, réutilisée par le bouton « Relâchement » du cockpit). La reprise --continue est ignorée lors d'une bascule vers ou depuis Codex/Antigravity (formats de transcript incompatibles — toujours une nouvelle conversation). Plafond actuel : 40 ventouses en aspiration simultanée.

Camp des harnais à forfait fixe : les profils Codex et Antigravity n'appartiennent ni au camp occident ni au camp orient — le registre de camps ne les connaît pas, et le garde cross-camp se tait plutôt que d'inventer un verdict sur un catalogue vide.

Famille Chantiers — workflow en sept étapes

La famille Chantiers regroupe l'ensemble des composants qui gouvernent le cycle de vie d'un chantier : de sa création depuis un email entrant jusqu'à sa clôture automatique après validation QA. Le point d'entrée officiel est la commande bin/chantier-from-email, exposée également via le skill /chantier.

Composants principaux

Sous-famille — Orbite QA et auto-clôture des chantiers

Cette sous-famille automatise la validation finale et la clôture des chantiers arrivés en phase de test. Elle repose sur deux agents distincts opérant en pipeline.

Sous-famille — Auto-optimisation post-chantier

Cette boucle ferme le cycle sur les chantiers marqués pour analyse automatique (comportement activé par défaut depuis mi-2026) : à la clôture, le moteur relit le flux d'exécution et alimente un backlog agrégé de frictions de workflow. Un second composant, jamais automatique, transforme une ligne de ce backlog en chantier de correction — sur geste explicite uniquement.

Famille Brainstorm

Cette famille regroupe les composants dédiés à la maturation d'idées : de la collecte initiale jusqu'à la promotion en chantier opérationnel, en passant par la validation et la narration.

Le traitement repose sur une file de travaux dédiée drainée par un worker continu. Ce mode daemon étant fragile par nature, un filet de sécurité cron en mode ponctuel garantit qu'aucun travail ne reste bloqué indéfiniment.

Fiabilité du worker continu. Le daemon en boucle longue peut s'interrompre silencieusement. Le cron en mode ponctuel constitue le filet de sécurité opérationnel : il traite les travaux en attente même si le worker principal est tombé, sans risque de double traitement grâce à la sémantique de la file.

Famille : audits, qualité et sécurité

Cette famille regroupe l'ensemble des automatismes qui surveillent, mesurent et protègent la flotte : intégrité des données, couverture SEO, sécurité périmétrique, qualité visuelle et conformité des dépendances. Chaque outil est soit déclenché en tâche planifiée, soit disponible en ligne de commande, soit importé comme bibliothèque par d'autres automates.

Vue d'ensemble des outils

Sous-famille : compte système QA par tenant

Une session de QA authentifiée par instance de la flotte, en lecture seule, sans jamais passer par le profil personnel de l'opérateur. Les familles de back-office couvertes sont : hub CodeMyShop (famille A), PrestaShop (famille B), et instances sans back-office client (famille C). Le registre ne porte que des noms de comptes — jamais une valeur de secret ; le mot de passe vit dans le coffre de credentials via le gestionnaire de comptes tiers. Un compte n'est marqué active que sur preuve live d'une réponse 403. Ordre des gestes : garde (« à créer ») → compte créé par un geste externe sous l'accord écrit de l'opérateur → pose du mot de passe → preuve live.

Sous-famille : mesure maquette ↔ rendu (iso-Figma)

Outils déterministes qui remplacent le verdict en prose du juge multimodal par des mesures rejouables : rythme vertical, blancs, contraste du voile, assertions structurelles DOM, catalogue des sections CMS. Ces outils bornent la mesure ; le juge multimodal qualifie ensuite.

Mémoire, cicatrices et apprentissage

Cette famille regroupe les composants qui gèrent les trois niveaux de mémoire du système : un répertoire de fiches structurées, un Zettelkasten de notes longues, et une couche de recherche sémantique par vecteurs. Les cicatrices — traces formelles d'incidents résolus — alimentent une boucle de rétroaction continue : détection, qualification, déduplication, injection au bon moment dans le contexte de l'agent.

Qualification et injection des cicatrices

• Qualification par lot : un outil en ligne de commande soumet les cicatrices à un modèle de langage pour les reclasser. Il accepte des options de limite de volume, de ciblage par identifiant et de simulation à sec (dry-run). Aucune planification cron active n'est déclarée pour cet outil.
• Injection au démarrage de session : un garde-fou de type SessionStart rebranche automatiquement la mémoire active dès l'ouverture d'une nouvelle session de l'agent.
• Injection contextuelle par type d'outil : deux garde-fous distincts injectent les cicatrices pertinentes respectivement avant l'invocation d'un sous-agent, et avant toute opération de lecture, d'édition ou d'écriture de fichier.
• Rafraîchissement des indicateurs : un processus planifié recalcule chaque jour les indicateurs agrégés des cicatrices.

Déduplication et détection de récidive

Deux scripts de rattrapage (backfill) ont comblé un angle mort identifié en juillet 2026 : le moteur de réaction automatique regravait des doublons par récurrence, car l'ancienne logique d'idempotence reposait sur une signature variable. Ces scripts ont fusionné rétroactivement les doublons accumulés, d'abord pour les cicatrices générées automatiquement, puis pour celles issues d'événements non automatiques (task_failed, runaway, autonomie). Depuis, chaque site d'écriture appose une signature canonique commune.

Un capteur de récidive, planifié quotidiennement, détecte les cas où une cicatrice pertinente existait en mémoire mais n'a pas été servie à l'agent — et où l'erreur s'est pourtant reproduite. Ce signal est un prérequis au bornage fin du contexte injecté : on ne peut réduire ce qui est injecté sans risque qualité que si l'on mesure d'abord ce qui manque.

Consolidation nocturne et rappel sémantique

• Consolidation nocturne : un processus planifié à 4 h du matin compacte jusqu'à trente transcripts par passage et consolide la mémoire de long terme. Il est actuellement désactivé dans le planificateur (quota LLM épuisé) ; la ligne reste commentée jusqu'au renouvellement du forfait.
• Rappel sémantique : le moteur de recherche interroge la couche vectorielle pour retrouver les cicatrices et fiches mémoire proches d'une requête. Une optimisation mise en place en octobre 2026 a réduit le temps de requête lexicale de 7,1 s à 0,13 s grâce à un index GIN sur un champ vectoriel textuel précalculé.
• Synchronisation des vecteurs : un processus cron maintient la cohérence entre la base de documents et la couche de recherche vectorielle.

Zettelkasten et index des sessions

• Un indexeur planifié ingère les notes du Zettelkasten dans la couche base de données, permettant leur recherche croisée avec les cicatrices et les compétences.
• Une synchronisation bidirectionnelle toutes les trente minutes maintient la cohérence entre le Zettelkasten local et son miroir distant, récupérant les notes rédigées depuis un poste Mac (via l'extension Obsidian Git) et poussant les productions de l'agent (consolidation nocturne, sorties de garde-fous).
• Un indexeur distinct traite les sessions de conversation au format .jsonl et les enregistre dans la couche base de données pour consultation ultérieure.

Index et publication des compétences

L'indexeur de compétences (skills) tourne toutes les quinze minutes. À chaque passage, il lit les fiches de compétences du dépôt et effectue cinq passes successives et isolées — l'échec d'une passe n'emporte pas les autres :

1. Publication gatée : recalcule à chaque run si chaque compétence est publiable. Un nouveau client signé peut retirer de la vitrine les compétences qui le citaient, sans qu'aucun fichier ne soit modifié manuellement.
2. Mode de listage : projette les arbitrages d'exposition au listing déclarés dans la configuration, évitant la troncature silencieuse au-delà d'un budget.
3. Orchestration : transforme les déclarations de méta-compétences en liens ordonnés ; un enfant introuvable n'est jamais inséré (mieux vaut une chaîne incomplète qu'un lien mort en vitrine).
4. Tags et descriptions éditoriales FR/EN : chaque élément est jugé séparément par le même filtre de publication — un pitch anglais citant un client est refusé seul, sans emporter la fiche française.
5. Partitions : les compétences qui déclarent une section de partition sont projetées dans la table de conduites.

Les compétences orphelines (supprimées du dépôt) sont retirées de l'index uniquement sur la branche principale ; un répertoire de travail en retard liste ses orphelins sans les toucher.

Des mécanismes complémentaires gèrent la génération automatique de propositions de compétences après une victoire, la surveillance des propositions en attente de validation humaine, et le suivi des renommages (réconciliation de l'historique d'invocation après un renommage de fichier).

Gestion du contexte de session

• Chargement contextuel déclaratif : une couche lit le type de tâche déclaré et sélectionne les blocs mémoire pertinents parmi les fiches disponibles. Elle constitue la deuxième couche au-dessus du plancher de contexte obligatoire, avec repli sécurisé.
• Plancher obligatoire : un composant valide que les blocs immuables du contexte sont bien présents avant chaque session.
• Journalisation de la taille injectée : un garde-fou SessionStart enregistre la taille estimée du contexte injecté en base, en mode fail-open (une erreur d'écriture ne bloque pas l'agent).
• Suivi en cours de session : un garde-fou PostToolUse met à jour l'estimation du budget consommé après chaque outil.

Fractionnement et relance de session

Le coût d'une longue session croît de façon quadratique : l'historique et les résultats d'outils sont renvoyés au modèle à chaque tour. Le mécanisme de fractionnement mesure le contexte réel (consommation déclarée par le modèle) et le nombre de tours, et déclenche un transfert (handoff) persistant dès qu'un seuil est franchi (130 000 tokens).

Ce composant est câblé sur trois événements distincts :

• Fin de session (Stop) : pose l'état de bascule en base (table observable par le tableau de bord) plutôt qu'un simple message texte. Un signal de relance est émis si les conditions sont réunies.
• En cours de tour (PostToolUse, option --tick) : mesure le contexte à intervalles réguliers, avec un garde-temps de soixante secondes entre deux mesures.
• Avant compaction native (PreCompact, option --precompact) : mesure juste avant qu'une compaction automatique ne s'exécute.

Un quatrième point d'entrée (--emit-now), non câblé comme garde-fou, permet à l'agent lui-même de poser le stub de transfert lors d'une bascule de harnais (arrêt immédiat sans passage par les événements habituels).

La séparation des pouvoirs est stricte dans ce mécanisme : le module de décision de relance déclare une sentinelle sans rien tuer ; la politique de relance (plafond glissant, anti-boucle, délai de validité) est écrite en Python testable, jamais dans le shell. Un seul processus peut consommer la sentinelle (section critique avec création exclusive). Des garde-fous empêchent une session fille d'un agent worker de déclencher une relance (le worker gère sa propre reprise).

Le superviseur de session vit dans le même panneau tmux que l'agent. Il est l'exécutant extérieur qui comble l'intervalle entre l'écriture du transfert et le démarrage de la session suivante — car un agent ne peut pas se terminer lui-même. Il ne respawn que s'il a lui-même mis fin à l'enfant sur sentinelle consommée. Une mort spontanée de l'agent (commande /exit, crash, signal) n'entraîne jamais de relance automatique.

Le mécanisme de reprise de transfert (garde-fou SessionStart) réinjecte automatiquement le dernier transfert produit par le fractionnement. Des filtres anti-boucle (délai minimum de vingt-quatre heures) et un mécanisme de séparation par slug de tentacule évitent qu'une session reprenne le transfert destiné à une autre instance du même pool.

Hotset mémoire et métriques

Un classeur déterministe recalcule quotidiennement la section « réflexes quotidiens » du fichier de cache mémoire principal, en utilisant une formule de décroissance exponentielle pondérée par le nombre d'accès récents. Ce fichier est un cache repayé à chaque appel, plafonné en volume par un garde-fou dédié. Les sections de plancher obligatoire (priorité maximale) et les travaux en cours restent gérés manuellement. Un collecteur distinct agrège les métriques globales du répertoire mémoire.

Élagage des cicatrices

Un moteur d'élagage applique trois opérations sur le registre des cicatrices :

• Backfill de contexte : dérive le lien de contexte pour les cicatrices dont le fichier source a bougé.
• Promotion : passe les cicatrices résolues et appliquées cinquante fois ou plus au statut « acquises ».
• Archivage : archive les cicatrices dont le contexte est mort — jamais sur un signal d'état inconnu.

Un orchestrateur de revue périodique pilote cet élagage en mode --apply, remonte au backlog humain les cicatrices non résolues rappelées cinquante fois ou plus, et émet un signal de présence (heartbeat). Il est entièrement déterministe, sans appel à un modèle de langage.

Graphe de connaissances et glaneur de préférences

Un graphe de connaissances expérimental relie de façon déterministe (expressions régulières, JSON, colonnes de base) les garde-fous, cicatrices, doctrines et fichiers. Il offre des sous-commandes de construction, de requête par chemin ou commande, et d'évaluation (rappel@5 comparé au rappel sémantique). Il est chargé de façon paresseuse et non invasive par certains garde-fous.

Un glaneur de préférences parcourt les transcripts de sessions locaux pour extraire les consignes d'usage et préférences de l'opérateur que ni les cicatrices ni le Zettelkasten ne capturent. Il est entièrement déterministe (pas de modèle de langage) et ne s'exécute qu'en session interactive, jamais en cron.

Vigilance chatbot et purge juridique

Un sentinelle surveille les journaux de l'assistant IA des boutiques clientes. À chaque passage, il lit les nouvelles lignes depuis son dernier état mémorisé et envoie un email groupé lorsque des requêtes visiteurs sont restées sans réponse, n'ont rien trouvé, ou ont rencontré une indisponibilité. Les interactions issues de la recette de validation automatique sont isolées dans une section dédiée et ne polluent pas les alertes visiteurs. Aucun modèle de langage n'est utilisé ; le composant ne corrige rien.

Un processus de purge applique chaque nuit les durées de conservation légales sur ces journaux : les textes (questions, réponses) sont effacés après quatre-vingt-dix jours, les conversations après quatre-vingt-dix jours depuis le dernier message, les lignes techniques après treize mois. Une seule instruction SQL transactionnelle par boutique. Ce mécanisme a été mis en place après le constat qu'une durée de conservation écrite sans mécanisme applicatif ne protège personne.

Vigie des créneaux de rendez-vous

Un composant vérifie chaque jour ce que voit réellement un visiteur qui clique sur un bouton « Prendre rendez-vous » : le site pointe-t-il bien vers la page de réservation ? L'API renvoie-t-elle des créneaux disponibles dans les quatorze prochains jours ? En dessous d'un seuil minimal, une alerte interne est envoyée à l'équipe — jamais au client du tenant. Le silence n'est pas considéré comme un succès.

Garde de version fiscale

Un composant scelle l'empreinte du code portant les fonctions fiscales critiques de la caisse (registre, chaînage, clôtures, archivage, export). Tout changement sur ces fichiers constitue une version majeure et invalide l'attestation en cours. Trois sous-commandes : vérification de l'empreinte courante, recalcul du sceau, et lecture de la racine et de l'empreinte enregistrées par le registre d'attestation.

Boucle de maintenance et auto-réparation de la documentation

Un orchestrateur quotidien enchaîne douze étapes en un seul passage nocturne (déclenchement à 5 h du matin). Il opère sous verrou et peut être mis en pause via un interrupteur en base de données. Les codes de retour 1 et 2 des sous-étapes sont des statuts informatifs (dérive détectée, santé critique) et non des échecs fatals ; l'orchestrateur ne sort en erreur que sur un vrai crash.

Les douze étapes du passage nocturne

L'auto-réparation mécanique des références et liens cassés tourne indépendamment de cet orchestrateur (toutes les six heures). Elle traite trois classes de problèmes réversibles : références de catalogue mortes résolues par nom de base unique, liens markdown cassés résolus par nom de base unique, et stubs de navigation en langue anglaise absents. Chaque classe est validée par un gate fail-closed : une classe absente du registre n'est jamais auto-appliquée.

Le traitement des revues externes suit un schéma découplé : les revues soumises par l'opérateur humain sont évaluées par un modèle sandboxé (délimiteurs anti-injection, champs hors spec ignorés, injection détectée → log sans action). Si la revue est valide, le composant signale la régénération à l'orchestrateur sans la déclencher directement. Ce composant est actuellement désactivé dans le planificateur (quota LLM épuisé).

Après chaque régénération profonde, un composant de triage réévalue les critiques externes encore ouvertes face au nouveau contenu HTML et les classe en trois catégories : résolues par la régénération (aucune action), survivantes et escaladées au backlog humain, ou hors périmètre (attentes multi-tenant plaquées sur un système mono-base).

Publication synchronisée vers le site public

• Un composant synchronise le snapshot de santé et de dérive vers la base du VPS public, alimentant le cadran de maintenance en temps réel. Un seul snapshot par jour, aucune écriture sur la base centrale.
• Un synchroniseur de liturgie calcule les horaires d'activité des automates et pousse un snapshot vers le VPS public. Un libellé qui échoue au scan anti-fuite est comptabilisé sans être nommé.
• Un synchroniseur de compétences pousse les fiches publiables (nom, pitch, taille, date — jamais le corps des fiches) vers le VPS public, en remplaçant l'ensemble en une seule transaction après sauvegarde de l'état précédent.
• Un synchroniseur de garde-fous pousse les entrées publiables de l'inventaire des garde-fous (fichier relatif, organe, événement, déclencheur, caractère bloquant, raison FR/EN, incidents — jamais la commande ni le chemin absolu).
• Un composant de snapshot éditorial synchronise les tables de contenu de la base centrale vers la base locale du VPS public, avec vérification de parité de colonnes et transaction unique.

Inventaire des garde-fous multi-harnais

Un indexeur lit les configurations de câblage de tous les harnais d'agents actifs, retrouve le fichier derrière chaque commande déclarée, extrait la raison d'être du garde-fou et maintient un miroir en base (avec empreinte SHA-256 pour détecter les dérives). Il inclut depuis octobre 2026 le cinquième harnais. Un rapport de parité vérifie qu'aucune politique de sécurité prioritaire n'est absente sur l'un des harnais.

Immunité adaptative

Ce sous-système détecte les cicatrices qui se répètent selon des schémas similaires, formule des propositions de réflexes préventifs, et les soumet à une validation humaine avant tout armement. Le modèle de menace est strict : aucune proposition ne peut s'armer seule — la table de staging ne contient pas de colonne d'activation, et le moteur de réflexes actifs ne lit jamais cette table de propositions.

Détection et proposition

• Détecteur de clusters : applique un algorithme de densité (DBSCAN, distance cosinus, seuil serré pour éviter un blob unique regroupant la quasi-totalité des paires) sur les vecteurs de cicatrices. Produit une liste de clusters avec leur pureté. Aucune planification cron propre ; utilisable en ligne de commande avec options de simulation et de paramétrage.
• Assembleur de propositions : combine les clusters en projets de réflexes enforçables et les place en staging inerte après validation par le contrat de sûreté. Alimente également la section immunité du digest quotidien de l'élagueur. Aucune planification cron propre.
• Contrat de sûreté : valide chaque proposition avant staging — action limitée à deny ou warn, niveau de déclenchement borné, motif anti-ReDoS, preuve obligatoire. N'écrit jamais dans la table des réflexes actifs.

Détecteur d'erreurs en fin de session

Un garde-fou de fin de session lit le transcript de la session courante, isole le delta du dernier tour et filtre les erreurs bénignes connues. Il distingue deux cas :

• Commande de livraison bloquée : une commande de déploiement réellement exécutée et bloquée par le garde-fou de livraison → leçon comportementale émise sur la sortie d'erreur, code de retour 2, trace en base d'audit.
• Autres erreurs (tracebacks, vraies erreurs applicatives) → proposition de réflexe en staging inerte via le contrat de sûreté.

Des garde-fous internes évitent les boucles : interrupteur d'urgence, détection du contexte worker, marqueur de session anti-récursion. Le composant est entièrement en dégradation gracieuse (exit 0 par défaut).

Note sur le périmètre d'évaluation des réflexes : le moteur de réflexes actifs est câblé sur les outils d'édition, de lecture, d'invocation d'agent et de navigation web — mais pas sur les commandes shell directes. Deux des trois gabarits de propositions du système sont marqués comme enforçables sur commandes shell. Sans câblage correspondant, un réflexe armé sur ce déclencheur resterait non évalué en pratique malgré son statut actif — écart à confirmer et corriger.

Moteur d'entraînement et outils de session

• Moteur d'entraînement : pilote des exercices structurés pour les agents, en ligne de commande.
• Générateur de cicatrice : produit un rapport structuré et un brouillon d'email après verdict, utilisable depuis la compétence d'apprentissage.
• Leçon post-chantier : rédige automatiquement une rétro pédagogique après la clôture d'un chantier.
• Harness d'évaluation du rappel : mesure les performances du mécanisme de rappel sémantique (rappel@k, MRR@10, comparaison à une baseline figée) et échoue si une régression est détectée.
• Injecteur de cicatrices au spawn d'agent : comble une asymétrie du harnais — le sous-agent reçoit le cadre cognitif synchronisé mais pas les cicatrices. Ce composant effectue une requête vectorielle et produit un bloc « écueils déjà appris » prêt à être inséré dans le prompt de spawn.
• Glaneur de préférences : recense dans les transcripts locaux les consignes et préférences de l'opérateur que les autres couches ne capturent pas. Entièrement déterministe, sans modèle de langage. La rédaction des notes issues de ce glanage se fait en session interactive.
• Synthèse des notes par tenant : recense l'ensemble des éléments portant l'état d'un client (chantiers, notes mémoire, notes Zettelkasten), vérifie chaque référence citée contre la source vivante, et peut poser un bloc structuré dans un chantier sur demande.
• Affichage rapide du dernier transfert : commande shell qui affiche immédiatement la carte du dernier transfert du répertoire courant, sans appel au modèle — utile juste après un effacement de contexte où la bannière du garde-fou de démarrage n'apparaît pas.
• Publication des cicatrices publiques : extrait les cicatrices validées, les assainit via un modèle de langage et les pousse vers la base publique. L'activation est un geste humain délibéré. Actuellement désactivé (quota LLM épuisé) ; la commande CLI reste utilisable manuellement.

Format canonical du cache mémoire principal

Un composant maintient la forme canonique du fichier de cache mémoire principal, à partir d'un manifeste YAML déclarant les zones, leurs budgets en octets, leurs marqueurs de délimitation et les invariants à vérifier. Il protège la répartition entre zones, pas seulement le total — deux incidents ont montré qu'une conformité globale pouvait masquer un débordement zonal. Ce composant est conçu avec des dépendances minimales car il est sur le chemin critique de plusieurs garde-fous.

Famille personas / agents — entretien

Cette famille regroupe les scripts dédiés à la maintenance du référentiel d'agents : synchronisation, régénération des profils, mesure du poids cognitif et tests de validation. Chaque outil agit sur une facette précise du cycle de vie d'un agent sans empiéter sur les responsabilités des autres.

Note sur la planification des tâches récurrentes. Deux corrections de calendrier ont été apportées lors d'une relecture contradictoire en septembre 2026 : le synchroniseur d'agents canoniques et le passe-plat du régénérateur étaient antérieurement documentés avec des horaires matinaux. Les horaires du soir indiqués dans ce tableau sont les valeurs corrigées et en vigueur.

Note sur l'auditeur de poids cognitif. Ce composant n'est pas raccordé à une tâche planifiée. Son exécution doit être déclenchée manuellement ou intégrée dans un pipeline de validation explicite. L'absence de cron est un état délibéré documenté, non un oubli.

Famille Messagerie client

Règle fondamentale : aucun email client n'est envoyé directement par l'IA. Tout passe par la façade d'envoi email, en deux temps obligatoires — brouillon (--draft) puis envoi (--send). Un garde actif bloque toute tentative d'envoi SMTP direct hors de cette façade. Les identifiants de messagerie (compte IMAP, serveur, mot de passe, paramètres SMTP) sont stockés dans les variables d'environnement de l'hôte — leurs valeurs ne figurent jamais dans ce document.

Protections transversales

Garde RGPD art. 21 : avant d'écrire un brouillon, la façade vérifie si le destinataire (adresse ou domaine) figure dans la liste d'opposition. Cette liste est conservée sans limite de durée et n'est jamais purgée. Le principe est fail-closed : si la base est indisponible ou en erreur, le brouillon est refusé par défaut.

Liens de note de mesure : un lien de type /note/<jeton> inséré dans un brouillon programmé doit être couvert par un identifiant de note valide enregistré en base. Sans cela, la commande de programmation refuse le brouillon. Cette protection évite qu'un lien collé manuellement contourne le contrôle de statut et la détection de contenu suspect.

Zéro message client programmé automatiquement : toute réponse dans un fil déjà ouvert (détecté par les en-têtes de fil) ou adressée à un contact ou domaine reconnu comme client est bloquée à la programmation. Seul un premier contact vers un inconnu peut être programmé (démarchage) ; tout message destiné à un client existant est toujours envoyé manuellement, après validation explicite du fondateur. Cette règle est fail-closed : si la base ne répond pas, l'envoi est refusé.

Composants de la messagerie client

Sous-famille Prospection et note de mesure

Le démarchage suit un protocole en quatre étapes : (1) constater un fait technique vérifiable pour un prospect précis (vitesse, faille, technologie), (2) figer le texte après validation du fondateur, (3) choisir une heure de dépôt plausible côté destinataire, (4) mesurer ce que ça rapporte. Quatre façades distinctes interviennent — aucune ne contacte le client seule. La liste d'opposition RGPD (art. 21, conservation permanente) est vérifiée par la façade email elle-même, pas par un hook séparé.

Sous-famille Délégations acquisition (B4) et communication (B8)

Les deux seules exceptions à la règle « zéro communication automatique » côté prospects et Page Facebook. Une table de délégation (une ligne par bureau, inactive par défaut) et un journal append-only horodaté enregistrent chaque décision. L'activation n'appartient qu'au fondateur — elle se fait en session directe, aucune commande du module ne peut l'activer. La désactivation est ouverte à tous. Des variables d'environnement permettent de couper chaque délégation immédiatement.

Sous-famille Traitement email par ventouse

Une ventouse déjà ouverte pour un client peut traiter les emails de ce client sans nouvelle session : lot unique par client, brouillon soumis au fondateur, départ seulement sur « valide <jeton> ». L'envoi reste sous validation manuelle — ce n'est pas une exception supplémentaire à la doctrine « zéro communication automatique ». Chaîne : veille → contexte de fil → brouillon → accord → envoi → preuve par le dossier Envoyés.

Sous-famille WhatsApp professionnel

Calque du triptyque brouillon → relecture → envoi appliqué au canal WhatsApp Cloud API (Meta). Un garde actif bloque tout envoi sans brouillon préalablement validé.

Sous-famille Communauté PrestaShop et réseaux sociaux

Veille et réponse publique aux marchands (forum PrestaShop et forums européens associés, groupes Facebook, Page Facebook, commentaires LinkedIn, forum WooCommerce, Shopify Community). La publication n'est jamais déclenchée en tâche planifiée directe : un garde vérifie systématiquement que le texte est scellé et que l'identité du valideur est connue avant toute publication.

Sous-famille Protection de majeur — boîte sécurisée

Dossier de protection d'un majeur, dans un schéma de base de données cloisonné hébergé seul. Ingestion IMAP 100 % déterministe (aucun modèle de langage, fail-closed sur la liste blanche), contrôle antivirus des pièces jointes, puis traitement à la demande sous la règle : « le modèle propose, le fondateur tranche, l'outil écrit et trace ».

Sous-famille Permanence vocale IA

Permanence téléphonique pour un artisan client : le standard téléphonique (garde AGI et pont audio tenus dans un seul processus pour un fail-closed structurel) route vers l'agent IA qui tient la conversation et produit la fiche d'appel. Sur échec de décrochage, la messagerie est relevée par IMAP. Seul le module de rapport a le droit d'appeler la façade email — cette contrainte est un invariant de conception.

Sous-famille Emails système et triage automatique

Ménage de la boîte du fondateur : les emails auto-adressés à préfixe normalisé (vigies, alertes automates) sont triés automatiquement ; tout le reste (tiers, réponses, transferts) reste dans la boîte principale.

Famille Blog, SEO & Contenu

Cette famille regroupe l'ensemble des automates qui produisent, optimisent et surveillent le contenu éditorial et les signaux SEO de la flotte : moteur de publication, optimisation multilingue des méta-données, génération d'articles, couvertures visuelles, forum de dialogues d'agents, diffusion sociale et sous-systèmes connexes (Search Console, indexation par vagues, maillage interne, traductions i18n, netlinking).

Moteur de publication et optimisation SEO

Hygiène du blog et similarité

Générateurs visuels

Surveillance du dictionnaire et couverture SEO source

Intégrations de données : Instagram et Search Console

Rapport et suivi SEO

Connecteur Figma (Shyrka)

Connecteurs Analytics

Catégorisation et taxonomie

Optimisation de contenu produit et de slugs

Carte statique et vidéo

Lecteur du blog interne et audit SEO mensuel

Sous-famille — Mesh des sites : pôles SEO, Performance et Sécurité

Chaque site de la flotte est noté sur trois pôles (/100) dans le tableau de bord, chacun lié à un objectif cible (/10). Tout est mesuré sans modèle de langage, ce qui autorise l'exécution planifiée. La preuve d'un objectif et la note du pôle partagent une seule source de vérité.

Sous-famille — Google Search Console (GSC)

Architecture en deux couches : les modules JavaScript tournent dans le conteneur d'exécution applicatif (accès à l'API GSC, identifiants déchiffrés depuis l'environnement). Les orchestrateurs Python invoquent ces modules et effectuent les écritures en base. Les identifiants déchiffrés restent en mémoire vive — jamais en sortie standard, journaux ou base de données.

Traductions i18n (blog et contenu)

Sous-famille — Autoblog (rédaction, relais, semis et réassort)

Chaîne quotidienne : semis → rédaction (06 h 30) → scènes (06 h 45) → parution par le worker du tenant → relais avec couverture (09 h xx) → vigie de file. Les tâches impliquant un modèle de langage portent une autorisation explicite dans la liste de contrôle des crons LLM.

Sous-famille — FAQ des articles blog

Sous-famille — Couvertures de catégorie

La cible de dépôt est lue dans la configuration du VPS client, jamais codée en dur.

Sous-famille — Couvertures blog (photo réaliste)

Sous-famille — Forum de dialogues d'agents

Chaîne « un fil ne part pas sans son texte » : le composant de demande remplit la file sans LLM, la résolution de source propose une URL d'autorité, le cadrage valide sous gate, le dialogue joue et publie, le scanner filtre les fuites. Aucun cron : le tirage reste un geste à la demande.

Sous-famille — Indexation par vagues

Un domaine neuf n'est pas indexé d'un coup : un mécanisme de paliers ferme les pages minces en noindex jusqu'à leur vague. Un seul composant écrit cette table ; un autre mesure le taux d'indexation via l'inspection d'URL ; la commande d'ouverture de vague ne passe que si la vague précédente atteint le seuil.

Sous-famille — Maillage interne

Le maillage se mesure sur la Search Console au lieu de s'estimer. Les cibles sont lues depuis le sitemap et les données de trafic ; un candidat ambigu est abandonné ; chaque cible est vérifiée en HTTP avant usage.

python3 -m <module-import-n26> <chemin-du-dump> [--apply]

python3 -m <module-categorisation> [--apply] [--normalize] [--account <ID-compte>]

python3 -m <module-rapprochement> [--apply] [--account <ID-compte>]

python3 -m <module-proposition-commerciale> <spec.json> <sortie.pdf>

python3 -m <module-veille-seuils> [--dry-run] [--force] [--annee <AAAA>]

# Invocation typique
python3 -m <module-vectorisation> --input logo_raster.png --color "#1A2B3C" --output logo.svg

# Exemple de structure d'appel (verbes du wrapper)
<wrapper-four> build <cible>
<wrapper-four> fetch <cible>
<wrapper-four> ping

# Invocation du worker de déploiement (modes)
python3 -m <worker-deploy> --once
python3 -m <worker-deploy> --loop
python3 -m <worker-deploy> --preflight

python3 -m <sonde-js-initial> --url <url> [--json]

python3 -m <sentinel-tls> --domain <domaine> [--dry-run] [--status] [--strict]

python3 -m <audit-infra-canon> [--json] [--host <hôte>] [--canon <image>]

python3 -m <medecin-systeme> [--apply] [--alert]

python3 -m <audit-bascule-mothership> [--json]

python3 -m <sante-systeme-mothership> [--json] [--quiet] [--alert]

python3 -m <audit-bascule-mothership> [--json]

python3 -m <gestionnaire-cron> --lister
python3 -m <gestionnaire-cron> [--retirer <nom>] [--dry-run]

python3 -m <provision-organisation> [--apply]

python3 -m <purge-cache-ssr> --site <cible> --path <chemin> [--all] [--verify]