Catalogue des automatismes du harness Synedre

0. Périmètre et méthode

Synedre orchestre CodeMyShop : le harness est le système d'ingénierie interne — orchestration d'agents, files de tâches, garde-fous automatiques — qui fait tourner la plateforme e-commerce multi-enseignes CodeMyShop et la petite flotte d'automates qui l'entoure (audits, contenu, finance, navigation web, déploiement). Ce chapitre recense les points d'entrée exécutables de ce harness : tâches planifiées, outils en ligne de commande, garde-fous déclenchés automatiquement à chaque action, compétences invocables en conversation, et bibliothèques partagées.

Méthode : chaque rôle décrit ici est extrait du commentaire d'en-tête du fichier source correspondant, jamais deviné. Le harness compte aujourd'hui plusieurs centaines de points d'entrée d'automatisation — quelques centaines de scripts et une centaine d'utilitaires en ligne de commande — répartis dans les familles ci-dessous.

1. Vue d'ensemble des familles et du flux

Le flux général part d'une demande entrante (email ou interface interne), passe par une classification d'intention (tâche courante, projet structuré, question, bruit), puis par une couche d'orchestration qui déclenche/suit/valide l'exécution d'agents. Cette exécution alimente ensuite les familles fonctionnelles : audits, contenu/SEO, finance, navigation web automatisée, déploiement. Toutes les familles convergent vers une base de données unique, accédée exclusivement via une façade d'accès commune — jamais de secret en clair dans le code.

2. Socle commun (bibliothèques transverses)

Une couche de bibliothèques partagées porte les fonctions transverses utilisées par toutes les familles : accès base de données, chargement centralisé de configuration, journalisation structurée obligatoire, routage vers plusieurs fournisseurs de modèles de langage, chargement des profils d'agent, persistance des événements pour le tableau de bord temps réel, et outillage de sécurité git (commit isolé sous verrou pour éviter qu'une session concurrente ne fasse fuiter des fichiers non voulus dans le même commit, espaces de travail persistants par client pour éliminer toute collision entre sessions parallèles).

Deux mécanismes protègent spécifiquement le coût et la fiabilité des appels au modèle de langage : un filet qui borne ce que le modèle reçoit comme résultat d'un outil (la majorité du coût observé venait de sorties d'outils non bornées réinjectées telles quelles dans le contexte), et — ajout récent — un plafond de contexte appliqué à chaque sous-agent invoqué par un agent principal : au-delà d'un budget de tokens, le sous-agent perd la possibilité d'appeler un nouvel outil et doit conclure. Ce second mécanisme comble un angle mort : un sous-agent imbriqué n'émet jamais l'événement de fin de session que la boucle de fractionnement de session (§7) surveille au niveau supérieur, donc rien ne le limitait jusqu'ici.

Mécanisme	Ce qu'il fait
Accès données	Façade unique vers la base — aucune requête directe hors façade
Sécurité git	Commit isolé sous verrou, espaces de travail persistants par client, anti mass-staging
Coût / contexte	Bornage des sorties d'outils, plafond de contexte par sous-agent, routage multi-fournisseur avec coût tracé (jamais de prix en dur)

3. Orchestration

Une couche d'orchestration surveille la boîte de réception dédiée, classe l'intention de chaque message entrant, puis déclenche au besoin un agent en tâche de fond pour agir dessus — avec un traitement renforcé des pièces jointes (extraction + scan antivirus systématique) et un envoi client qui passe toujours par une machine à états à plusieurs étapes : composition, revue humaine, puis envoi verrouillé par jeton à usage unique et vérifié par triple correspondance anti-usurpation. Rien ne part au client sans validation explicite.

Un worker dédié fait tourner les tâches de projet en parallèle (avec un plafond de concurrence) et surveille les exécutions bloquées pour les libérer sans jamais couper une tâche encore dans son propre délai — une version antérieure de ce filet coupait des exécutions saines trop tôt, corrigé depuis. Le contexte d'une tâche chaînée est réinjecté à chaque étape pour ne pas reperdre le travail de découverte déjà fait, et une session peut reprendre exactement où elle s'est arrêtée après une coupure. Une passerelle optionnelle permet à une session de terminal interactive de déclarer quel projet elle pilote, pour animer un tableau de bord temps réel côté interface — sans effet si aucune session n'est ainsi liée.

Une seconde sous-couche route l'exécution d'un travail vers différents moteurs de langage selon le projet, avec un contrat commun et un suivi de coût centralisé (jamais de prix codé en dur) ; un mécanisme de rejeu reprend automatiquement un travail basculé sur un moteur de secours dès que le moteur premium redevient disponible.

4. Chantiers — méthode de projet structuré

Un chantier est l'unité de travail structurée du harness quand une demande est trop transverse, irréversible ou non testable pour rester une simple tâche courante. La création depuis une demande entrante suit une procédure fixe : rédaction d'une lettre de mission, constitution d'équipe, puis passage automatisé d'un périmètre flou à une découverte structurée exploitable.

Un contrôle de complétude conditionne strictement l'admission d'un chantier au mode autonome : un chantier vague ou incomplet est rejeté ou automatiquement enrichi, jamais armé tel quel — c'est la porte d'entrée obligatoire avant toute exécution de nuit sans supervision. Un détecteur de dérive repère les chantiers dont le statut ment (marqué « en cours » alors que le code a bougé ailleurs, ou mort sans avoir été refermé), et un suivi terminal filtre le bruit pour ne montrer que le signal réel. Le suivi budgétaire distingue deux modes de facturation (équivalent-abonnement simulé vs API directe), commutables par chantier, avec alerte à 80 % du budget engagé.

Pour les changements légers ne justifiant pas un chantier complet, un filet de sécurité alternatif prend un instantané réversible de l'état du dépôt avant modification, laisse le changement s'exécuter, rejoue un vrai test de non-régression, et restaure automatiquement l'état antérieur si ce test échoue.

Deux sous-mécanismes ferment la boucle : une orbite de contrôle qualité qui ne referme automatiquement un chantier que si la preuve à trois axes (chemin de code réellement exécuté, verdict visuel, état de base de données) est intégralement verte — jamais de faux vert sur un axe non vérifiable — et un moteur d'auto-optimisation qui relit après coup le déroulé d'un chantier terminé pour repérer les frictions récurrentes de méthode et alimenter un backlog transverse ; transformer une ligne de ce backlog en chantier correctif reste toujours un geste explicite, jamais automatique.

5. Brainstorm

Une file dédiée porte les idées en gestation, drainée par un travailleur de fond : conversation de maturation, confrontation séquentielle de l'idée à un regard critique, puis promotion vers un chantier structuré (ou rétrogradation symétrique si le chantier s'avère prématuré).

6. Audits, qualité, sécurité

Une large famille d'audits tourne en tâche de fond ou à la demande : sécurité des dépendances, fraîcheur et restaurabilité réelle des sauvegardes (testée mensuellement, pas seulement supposée), reconnaissance de sécurité programmée sur l'ensemble du parc (cibles lues depuis un inventaire central, jamais codées en dur) exécutée dans un conteneur jetable détruit après chaque passe pour ne laisser aucune surface d'attaque permanente, sonde anti-fuite sur les interfaces d'administration, contrôle d'accessibilité et de qualité de page, surveillance de disponibilité, et cohérence entre les règles de doctrine écrites et les garde-fous qui sont censés les faire respecter.

Une chaîne de contrôle qualité visuel rend une page (sans session, ou via une session distante contrôlée pour les interfaces authentifiées) et demande un verdict à un modèle capable de voir l'image, comparé à une intention énoncée — pas une simple vérification de code HTTP. Un assembleur de preuve à trois axes (code réellement exécuté, verdict visuel, état de base vérifié) est la condition obligatoire avant tout envoi d'email de livraison à un client. Plusieurs invariants statiques tournent en continu : par exemple, qu'un contact capté est bien relié au dispositif de suivi de conversion, ou qu'un modèle de langage effectivement utilisé porte bien une entrée de tarification (sinon son coût réel disparaît silencieusement des tableaux de suivi).

Catégorie	Ce qu'elle couvre
Infrastructure	Dépendances, sauvegardes, disponibilité, durcissement, fuite d'endpoints admin
Contenu / accès	Accessibilité, liens morts, cohérence SEO technique
Preuve d'exécution	QA visuelle par modèle multimodal, preuve à trois axes avant livraison client
Invariants métier	Doctrine ↔ garde-fou réellement câblé, tarification ↔ usage réel, capture ↔ suivi de conversion

7. Mémoire, incidents, apprentissage

La mémoire du harness est organisée en trois niveaux : un index court et curé rechargé à chaque appel, une base de connaissance de type carnet de notes liées synchronisée avec un outil externe de prise de notes, et une couche de recherche sémantique par similarité vectorielle sur l'ensemble, y compris l'historique d'incidents.

Chaque incident ou leçon technique est consigné dans un registre structuré, récolté automatiquement depuis l'historique de code, dédupliqué, et réinjecté au démarrage d'une session ainsi qu'au lancement de chaque agent — pour qu'une leçon apprise une fois ne soit jamais réapprise à la dure. Un mécanisme de classement, fondé sur la fréquence réelle de rappel plutôt que sur un jugement manuel, décide quelles leçons restent en tête de l'index toujours chargé. Une passe de consolidation nocturne relit et synthétise la mémoire accumulée.

Un filet de sécurité coupe une session avant que son coût ne devienne quadratique (au-delà d'un certain volume de contexte accumulé), produit un résumé structuré, et le réinjecte automatiquement au tour suivant — étendu récemment aux sous-agents imbriqués via un mécanisme jumeau, puisqu'un sous-agent n'émet jamais l'événement de fin de session que le mécanisme principal surveille (⚠️ à confirmer : ce mécanisme jumeau affiche encore aujourd'hui une divergence non résolue entre ce qu'il annonce être et la façon dont il est effectivement branché).

Boucle nocturne de maintenance de la documentation. Une séquence orchestrée tourne chaque nuit pour garder la documentation interne alignée sur le code réel : elle perçoit l'écart entre la doc et le code réel, audite la couverture (ce qui existe en code mais n'est décrit nulle part), répare mécaniquement les références cassées (uniquement quand un unique fichier candidat porte le même nom — sinon elle rapporte sans deviner), régénère le contenu d'un chapitre via une passe de relecture dédiée, et ne republie qu'après le feu vert d'une porte de sécurité anti-fuite automatisée. Elle se relit une seconde fois après publication pour ne jamais laisser un instantané public en retard d'un cycle. Un digest hebdomadaire résume ce qui a été réparé, avec une question rituelle : « qu'a-t-on construit qu'on supprimerait aujourd'hui ? ».

Immunité adaptative. Les incidents récurrents sont regroupés automatiquement par similarité, et un garde-fou candidat est proposé — mais aucune proposition ne s'active jamais toute seule : chaque candidat exige une revue de sécurité humaine explicite avant de pouvoir bloquer quoi que ce soit.

Délibération. Un mécanisme confronte plusieurs perspectives d'agents à cadres cognitifs distincts sur une décision signalée comme sensible, et remonte la carte du désaccord — il ne tranche jamais lui-même ; décider reste un geste humain.

8. Personas et agents

Les profils canoniques des agents internes vivent en un seul endroit et sont synchronisés vers les surfaces qui en ont besoin plutôt que réinventés à chaque fois. Une mise à jour de profil passe par une comparaison à trois voies et une revue humaine avant d'être adoptée, et un audit périodique signale tout profil qui décrit encore un choix technique retiré depuis.

9. Boîte de réception et email client

Règle dure : aucun email n'est jamais envoyé à un client de la seule initiative du système. Tout envoi passe par une façade unique en deux temps — brouillon, puis envoi — et un garde-fou bloque toute tentative de transport d'email direct qui contournerait cette façade. Les identifiants d'accès ne sortent jamais d'un environnement protégé.

10. Blog, SEO, contenu

Un moteur de publication unique, piloté par la base de données, gère le contenu éditorial. Un seul moteur d'optimisation SEO par page (méta-données, description, FAQ, maillage interne) évite la dérive de plusieurs scripts ad hoc qui feraient double emploi ; des sentinelles comparent en continu la couverture déclarée à la couverture réelle. Les outils de nettoyage d'URL associent systématiquement tout changement de slug à une redirection, jamais un changement sec. Le contenu source en langue principale reste toujours rédigé à la main — le pipeline ne le réécrit jamais silencieusement — tandis que les langues secondaires sont complétées automatiquement.

Un pipeline d'import de maquettes visuelles rapatrie les écrans validés via une API dédiée, avec un repli par capture navigateur quand l'accès API est restreint — les deux voies produisent le même format de sortie, consommé de façon identique en aval. Les connecteurs d'audience (recherche, analytics) restent en lecture seule par défaut ; la variante en écriture, plus rare, est isolée séparément.

11. Navigation web automatisée

Une couche d'automatisation de navigateur pilotée par file d'attente s'appuie sur une sortie réseau à réputation résidentielle : la détection anti-robot est avant tout un problème de réputation d'adresse IP, pas seulement de comportement, donc l'automatisation la plus exposée tourne visible sur une machine résidentielle dédiée plutôt que masquée derrière un centre de données. Un canal de pilotage à distance générique commande cette machine et expose un instantané en lecture seule (joignabilité, santé de la session navigateur, état matériel) au tableau de bord interne.

Un moteur d'assistant d'achat personnel navigue en direct dans le contexte réel d'un site marchand pour proposer de vraies fiches produit filtrées — un simple appel serveur nu se ferait bloquer comme robot. Une frontière stricte protège le paiement : l'assistant peut chercher et déposer des articles dans un panier, jamais payer ; la main est rendue à une personne via un lien de reconstruction de panier, jamais via un identifiant ou une session partagée. Des adaptateurs couvrent les principales familles de plateformes marchandes, génériques quand la plateforme expose une lecture publique stable, sur-mesure sinon. Un mécanisme d'auto-guérison surveille les sessions de navigateur automatisées : il détecte une session tombée et la relance, et alerte si l'échec se répète.

12. Finance — banque, facturation, comptabilité

Import et déduplication de relevés bancaires, catégorisation automatique par règles (toujours en mode simulation par défaut, écriture explicite requise), rapprochement des encaissements avec les factures ouvertes (correspondance exacte d'abord, puis une règle de départage déterministe, jamais une estimation floue), outil interactif de facturation et de devis, facturation récurrente. Un assistant fiscal en lecture seule, dédié au régime simplifié d'une entreprise individuelle, calcule des indicateurs indicatifs (charges dues, provisions, seuils légaux) sans jamais rien décider ni rien écrire — chaque chiffre reste un brouillon à confirmer avec un comptable — avec récapitulatifs hebdomadaires et alertes de seuil, et un calcul de montant transférable qui ne déclenche jamais lui-même un virement.

13. Veille et recherche de marque

Une veille concurrentielle et marché alimente des rapports réguliers. Un parcours de recherche de nom de marque vérifie la disponibilité de domaine et l'antériorité dans les registres de marques concernés, prépare une estimation de coût de dépôt par territoire — et ne dépose ni n'achète jamais rien de lui-même, il propose. Un parcours de recherche de logo pilote une session de navigateur authentifiée réelle pour générer des pistes fondées sur des principes de design explicites (sobriété, lisibilité), assemblées en document de synthèse pour revue.

Ajout récent : une façade de vectorisation transforme un logo ou croquis raster en tracé vectoriel propre, une seule couleur, courbes lissées — un pipeline de seuillage et de nettoyage géométrique fait maison, avec une boucle de rétroaction qualité automatisée (quelques itérations au plus, chacune jugée par un examen visuel séparé qui propose un réglage borné : plus doux, plus net, moins de bruit, plus de détail, trait plus épais ou plus fin). Le pipeline détecte correctement une image en négatif (encre claire sur fond sombre) en échantillonnant les bords de l'image pour décider s'il faut inverser le masque, et règle l'épaisseur du trait indépendamment du nettoyage anti-bruit.

14. Déploiement, infrastructure, sauvegardes

Règle de gouvernance : la mise en production d'un site client externe est décidée site par site via un indicateur en base de données — ce n'est pas une règle générale « humain seul », c'est un indicateur consulté au cas par cas — avec un site maintenu bloqué en dur quoi qu'il arrive, en exception permanente. Toute publication non supervisée (de nuit) exige en plus un verdict de contrôle qualité automatisé au vert. Les mises à jour de la plateforme interne, elles, sont toujours appliquées par le système, sans exception. Avant tout déploiement, un travail non validé en dépôt est traité comme non déployable.

Une bibliothèque de déploiement partagée détecte la dérive de schéma de base de données et applique automatiquement les ajustements strictement additifs et sûrs (jamais de suppression automatique), génère les segments de route localisés, et préchauffe le cache après bascule en parcourant doucement les pages clés en arrière-plan pour que le premier visiteur réel n'attende pas un rendu à froid. Font aussi partie de cette famille : la gestion DNS, la configuration réseau (avec une porte d'accès administrateur à chemin secret rotatif), l'initialisation d'un nouveau site client et de sa charte visuelle depuis son propre logo, et les sauvegardes chiffrées vers un stockage objet externe avec un essai de restauration réel mené chaque mois.

15. Synchronisation open source et migrations

Une synchronisation à sens unique, par instantané compressé, extrait la partie éligible du socle applicatif privé vers un dépôt open source public séparé — le dépôt public reste la référence pour ce qui y existe déjà. Une passe de nettoyage retire les commentaires internes de cet instantané avant publication. Des outils de migration de schéma appliquent uniquement des changements additifs et réversibles, jamais destructifs. Une porte d'installation de module ne crée les tables d'un module que si le site client l'a explicitement déclaré, ce qui évite tables orphelines ou manquantes.

Plusieurs connecteurs de catalogue fournisseur et de comparaison de prix concurrents partagent désormais un même socle de politesse HTTP (limitation de débit, montée progressive des délais, détection de blocage) — factorisé une fois pour que chaque nouveau connecteur hérite des mêmes garde-fous anti-bannissement au lieu d'en réinventer une version plus faible.

16. Supervision et outillage divers du harness

Un ensemble d'utilitaires transverses complète le tableau : briefing de session, extraction stricte d'un coffre d'identifiants hérité qui sépare le non-sensible (affiché) du secret (jamais montré en clair), apposition de signature sur PDF qui écrit toujours un nouveau fichier de sortie et ne touche ni n'envoie jamais l'original, espaces de travail git jetables pour isoler les tests destructifs loin de la branche principale, et un journal de coût unique pour les tâches planifiées consommant un modèle de langage payant en dehors de tout projet suivi.

Une chaîne de génération d'objets et de personnages 3D transforme une planche de concept 2D en maillage 3D coloré, avec une variante de mobilier paramétrique produisant un plan coté prêt pour fabrication, un contrôle qualité géométrique (étanchéité, symétrie), et une synchronisation de livraison vers le site client concerné.

17. Garde-fous automatiques

Plutôt que de faire confiance à chaque action, le harness câble une série de gardes automatiques directement dans le chemin d'exécution de tout outil : avant qu'une commande sensible ne s'exécute, et après qu'un fichier a changé. Chaque garde est accompagné d'une preuve de non-régression automatisée, pour qu'aucun garde ne puisse être discrètement affaibli sans faire échouer un test.

Catégorie	Ce qu'elle empêche
Sécurité git	Staging de masse, commit sec sur un index partagé, rebase sur une branche partagée, artefact généré suivi par erreur
Secrets	Impression d'une valeur secrète en sortie, collage inline d'un secret
Infrastructure	Exécution privilégiée non voulue dans un conteneur, copie de dossier entier vers un conteneur, test d'authentification faussé par une configuration résiduelle
Données / SQL	Motif d'échappement dangereux, entrée passée en clair sur la ligne de commande plutôt que par canal sûr
Discipline documentaire	Absence de documentation minimale, nouvelle sortie d'outil non bornée
Gouvernance des tâches planifiées	Consommation silencieuse d'un modèle payant en tâche planifiée, chemin relatif fragile, écart entre déclaration et planification réelle
Communication client	Proposition d'appel téléphonique, envoi non revu, ajustement de solde sans autorisation explicite
Confinement de périmètre	Modification hors du périmètre déclaré d'un chantier, sous-agent dépassant son budget de contexte

18. Auto-réparation de la documentation

Ce catalogue n'est pas maintenu de mémoire — il est vérifié mécaniquement contre le code réel et la configuration de garde-fous réellement active, selon un rythme nocturne récurrent, contre un miroir qui signale trois types d'écart : une référence documentée qui n'existe plus, un fichier réel modifié plus récemment que ce que le catalogue en dit, et un instantané public qui accuse un retard sur la dernière régénération interne.

Quand un écart est détecté, les réparations mécaniques s'appliquent là où c'est sûr (résolution d'une référence cassée uniquement quand un unique fichier porte le même nom) ; tout ce qui demande un jugement est proposé, jamais appliqué automatiquement. Une relecture délibérément adverse et récurrente complète le miroir mécanique, précisément parce que ce dernier ne détecte que ce pour quoi il a été conçu — plusieurs passes précédentes ont revendiqué l'exhaustivité d'une section pour se révéler ensuite incomplètes, ce qui est désormais un mode de défaillance documenté et attendu : un catalogue statique se re-périme dès qu'un garde-fou ou un automatisme de plus est ajouté après la dernière vérification. La discipline n'est donc pas une passe « définitive », mais une re-vérification répétée contre l'état réel du système.