[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fHB3OvP117l6e4m6Wy2Q4UDGn5eR8GDLK5CpJF6nZG3o":3,"$fk1oB-e5O_BgwF2c-QwDgsx2Y7SMPhf77z9g2mrpoBuM":23},{"chapter":4,"prev":13,"next":18},{"slug":5,"chapterNum":6,"title":7,"titleEn":8,"summary":9,"summaryEn":10,"contentHtml":11,"contentHtmlEn":12},"facades","10","catalogue des façades et points d'entrée du harness","harness facade and entry-point catalogue","comment le harness synedre organise ses centaines d'automates en familles fonctionnelles, avec les garde-fous en temps réel qui encadrent chaque action.","how the synedre harness organizes its hundreds of automations into functional families, with the real-time guard-rails that frame every action.","\u003Cp>Synedre orchestre CodeMyShop : Synedre est le \u003Cstrong>harness\u003C\u002Fstrong> agentique interne — l'ensemble des automates, scripts et points d'entrée qui font tourner l'entreprise (emails, chantiers, audits, contenu, déploiements, finance) — tandis que CodeMyShop est le produit e-commerce multi-tenant que ce harness opère. Ce chapitre documente le harness : son inventaire d'outils, ses familles fonctionnelles et les mécanismes de gouvernance qui l'encadrent. Il ne décrit pas l'architecture du produit CodeMyShop lui-même.\u003C\u002Fp>\n\n\u003Ch2 id=\"perimetre\">0. Périmètre, méthode et couverture\u003C\u002Fh2>\n\u003Cp>Le harness rassemble plusieurs centaines de scripts d'automatisation et de points d'entrée exécutables, répartis en deux grandes familles : des modules Python d'automatisation et des utilitaires shell\u002FJS. Chaque script est décrit ici par son rôle en une ligne et son mode d'invocation type, afin qu'un ingénieur reprenant le système retrouve rapidement quel outil fait quoi sans devoir relire l'ensemble du code.\u003C\u002Fp>\n\u003Cp>Les descriptions sont extraites \u003Cstrong>programmatiquement\u003C\u002Fstrong> du commentaire de tête de chaque fichier — jamais inventées. Quand un fichier ne porte qu'un en-tête de licence générique, le vrai commentaire de rôle a été recherché plus bas dans le fichier. Ce repêchage n'est pas systématique : le catalogue précise, cas par cas, quand une description reste à confirmer plutôt que de la présenter comme certaine.\u003C\u002Fp>\n\u003Cp>La couverture est revérifiée à intervalles réguliers par croisement automatique entre l'inventaire de fichiers et le planificateur système réel (crontab), afin de détecter deux dérives : un script encore documenté comme actif alors qu'il a été retiré de l'ordonnancement, et à l'inverse un script réellement ordonnancé mais absent du catalogue.\u003C\u002Fp>\n\u003Ctable>\n\u003Ctr>\u003Cth>Mode d'invocation\u003C\u002Fth>\u003Cth>Signification\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>cron\u003C\u002Ftd>\u003Ctd>lancé par le planificateur système, le plus souvent via un chien de garde commun\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>CLI\u003C\u002Ftd>\u003Ctd>appelé à la main par un opérateur ou un agent\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>skill\u003C\u002Ftd>\u003Ctd>façade derrière une compétence invocable en langage naturel\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>hook\u003C\u002Ftd>\u003Ctd>déclenché automatiquement avant\u002Faprès une action de l'agent IA (édition de fichier, appel shell, lecture, sous-agent, fin de session)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>lib\u003C\u002Ftd>\u003Ctd>module importé par d'autres scripts, pas un point d'entrée autonome\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>worker\u003C\u002Ftd>\u003Ctd>processus de fond qui draine une file d'attente en continu\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftable>\n\n\u003Ch2 id=\"flux-ensemble\">1. Familles et flux d'ensemble\u003C\u002Fh2>\n\u003Cp>Le flux général du harness suit un chemin unique : un email entrant est capté et son intention est classifiée (exécution simple, chantier structuré, question, ou bruit) ; selon le résultat, le travail est soit exécuté directement, soit ouvert comme chantier structuré avec équipe assignée, soit versé dans un espace de gestation d'idées. L'exécution proprement dite passe toujours par un cycle d'agents outillés, qui se déploient ensuite vers cinq destinations : audits de qualité, production de contenu\u002FSEO, finance, automatisation navigateur, ou déploiement. Toutes ces branches convergent vers une \u003Cstrong>base de données unique\u003C\u002Fstrong>, accédée exclusivement via une façade d'accès commune — jamais de connexion directe éparpillée dans le code.\u003C\u002Fp>\n\u003Cp>Ce choix d'une source de vérité unique est structurant : aucune donnée métier (clients, secrets, dépôts, tarification) ne vit dans un fichier statique — elle vit en base, et le code applicatif ne fait que la lire\u002Fécrire via cette façade.\u003C\u002Fp>\n\n\u003Ch2 id=\"socle-commun\">2. Socle commun\u003C\u002Fh2>\n\u003Cp>Un jeu de modules transverses porte les fondations utilisées par la quasi-totalité des automates : une façade d'accès à la base de données, un chargeur centralisé des variables d'environnement, un système de journalisation structurée obligatoire, et une façade IA agnostique du fournisseur (elle route vers différents moteurs de langage selon la tâche et le budget, sans coupler le code applicatif à un fournisseur précis).\u003C\u002Fp>\n\u003Cp>Chaque tâche planifiée passe sous un \u003Cstrong>chien de garde\u003C\u002Fstrong> commun qui impose un délai d'exécution par défaut et coupe tout script qui dépasserait ce plafond — avec des dérogations explicites, documentées et bornées pour les tâches légitimement longues (consolidation de mémoire nocturne, génération multi-session). Un système de journalisation d'événements alimente le tableau de bord temps réel des agents en cours d'exécution.\u003C\u002Fp>\n\u003Cp>Le socle porte aussi un mécanisme de \u003Cstrong>réflexes décentralisés\u003C\u002Fstrong> : avant chaque édition de fichier, lecture, appel d'outil réseau ou spawn de sous-agent, une évaluation rapide interroge un registre de règles apprises (autoriser \u002F avertir \u002F refuser) et trace la décision dans un journal d'audit dédié. La loi qui gouverne ce registre est une loi d'asymétrie stricte : toute nouvelle règle ne peut que durcir le comportement, jamais l'assouplir, et les zones sensibles échouent fermées (elles bloquent par défaut) en cas d'indisponibilité de la base de règles.\u003C\u002Fp>\n\n\u003Ch2 id=\"atlas-orchestration\">3. Orchestration\u003C\u002Fh2>\n\u003Cp>La couche d'orchestration surveille en continu une boîte de réception dédiée, classe l'intention de chaque message entrant (exécution simple \u002F chantier \u002F question \u002F bruit), puis déclenche l'action correspondante : pour un travail actionnable, une session d'agent headless est démarrée pour agir sur l'email classifié, avec un délai maximal généreux et des garde-fous anti-doublons pour éviter qu'un même cycle ne soit relancé deux fois. La mise en production reste un geste strictement humain ; l'orchestrateur peut proposer un envoi « via email » avec triple vérification anti-usurpation, mais jamais déclencher lui-même une bascule en production.\u003C\u002Fp>\n\u003Cp>Un cycle de type ReAct (raisonner → agir → observer) pilote chaque tâche unitaire ; des détecteurs dédiés repèrent les tâches bloquées au-delà d'un seuil de temps ou de consommation, proposent un plan de déblocage, ou mettent en pause automatiquement une tâche qui s'emballe (durée ou coût anormal). Un résumé quotidien consolide l'activité de la nuit.\u003C\u002Fp>\n\u003Ch3>Pont session interactive → tableau de bord\u003C\u002Fh3>\n\u003Cp>Un mécanisme optionnel permet à une session interactive de se déclarer liée à un chantier en cours : l'activité de cette session (actions, messages) est alors miroitée en temps réel vers le tableau de bord de suivi de ce chantier, sans jamais interférer si aucun lien n'est actif. Un interrupteur d'urgence permet de désactiver entièrement ce pont.\u003C\u002Fp>\n\u003Ch3>Exécution multi-fournisseur\u003C\u002Fh3>\n\u003Cp>Un contrat d'exécution commun permet de router chaque unité de travail vers différents moteurs de langage selon le besoin (rapidité, coût, disponibilité) plutôt que d'être couplé à un seul fournisseur. Chaque exécution est chronométrée et son coût réel est calculé depuis une grille tarifaire centrale — jamais de prix codé en dur — puis agrégé par chantier et par marque, alimentant un contrôle budgétaire continu.\u003C\u002Fp>\n\n\u003Ch2 id=\"chantiers\">4. Chantiers\u003C\u002Fh2>\n\u003Cp>La création d'un chantier suit une procédure structurée en plusieurs étapes obligatoires : lecture complète de la demande d'origine (y compris ses pièces jointes, systématiquement passées par un scan antivirus avant toute ouverture), audit des agents disponibles pour composer une équipe pertinente au périmètre, rédaction d'une lettre de mission explicite, recrutement d'au moins deux profils distincts pour tout travail touchant un client, puis création atomique du chantier avec son premier lot de tâches — l'ensemble échoue et s'annule en bloc si une seule étape rate, jamais d'état à moitié créé.\u003C\u002Fp>\n\u003Cp>Des outils dédiés génèrent un brouillon de lettre de mission, gèrent l'équipe recrutée par chantier, orchestrent l'explosion automatique d'une découverte en tâches d'implémentation, auditent la pertinence des chantiers actifs, et déclenchent une alerte dès qu'un chantier consomme 80 % de son enveloppe budgétaire — avant le plafond dur qui coupe le travailleur. Le pipeline commercial (prospection → négociation) partage cette même mécanique : qualification légale et de solvabilité d'un prospect via des registres publics, extraction structurée des échanges, génération d'un dossier de négociation complet.\u003C\u002Fp>\n\n\u003Ch2 id=\"brainstorm\">5. Idées et gestation\u003C\u002Fh2>\n\u003Cp>Une file d'attente dédiée porte les idées en gestation ; un travailleur de fond les traite en dialoguant avec l'orchestrateur, puis un cycle de challenge séquentiel les confronte à un regard critique avant maturation. Une idée validée peut être promue en chantier structuré ; à l'inverse, un chantier peut être rétrogradé en idée si le périmètre s'avère prématuré — un pont miroir gère les deux sens.\u003C\u002Fp>\n\n\u003Ch2 id=\"audits-qualite-securite\">6. Audits, qualité et sécurité\u003C\u002Fh2>\n\u003Cp>Une famille dense d'audits tourne la nuit ou en continu : audit global de tous les automates, audit du schéma de base de données contre la convention de nommage, audit de dérive entre le schéma déclaré dans le code et l'état réel de la base, surveillance quotidienne de la fraîcheur des sauvegardes, test mensuel de restaurabilité réelle d'un dump, audit sécurité des dépendances logicielles, détection des doublons et quasi-doublons de contenu éditorial.\u003C\u002Fp>\n\u003Cp>Côté sécurité offensive, un orchestrateur de reconnaissance \u003Cstrong>non-intrusive\u003C\u002Fstrong> passe chaque domaine actif en revue de façon hebdomadaire, en tirant la liste des cibles depuis un référentiel central — jamais de nom de client codé en dur dans le code — et n'envoie une alerte que si de nouveaux constats de sévérité élevée apparaissent (pas d'alerte-bruit sur chaque passage). L'intrusif réel ne s'arme jamais automatiquement : c'est un geste manuel distinct. Un audit d'accessibilité vérifie la conformité aux standards WCAG 2.2 AA. Une sonde anti-fuite passe chaque point d'entrée d'administration sans cookie de session et s'attend systématiquement à un refus — toute réponse positive déclenche une alerte immédiate.\u003C\u002Fp>\n\u003Cp>Une \u003Cstrong>vigie visuelle\u003C\u002Fstrong> capture réellement l'écran d'une page rendue puis demande un verdict à un modèle multimodal sur l'intention visuelle attendue, plutôt que de se contenter de vérifier que le code s'est exécuté sans erreur. Une sentinelle de santé de route surveille le taux d'erreurs 404 \u003Cstrong>par type de page\u003C\u002Fstrong> plutôt qu'un seuil global — un type de page entièrement cassé peut ne jamais franchir un seuil moyen tout en étant un vrai incident.\u003C\u002Fp>\n\u003Cp>Plusieurs garde-fous mécaniques bloquent la publication de code non conforme avant même le commit : refus d'une requête SQL brute référençant une colonne non déclarée dans le schéma type, invariant statique garantissant que tout formulaire captant un contact est bien relié à la chaîne de remontée publicitaire correspondante, vérification qu'une box de production porte bien les protections anti-intrusion attendues, sentinelle anti-mort-silencieuse détectant un point de contrôle qui échouerait silencieusement contre une base de données injoignable, garde-fou pré-mise-en-production refusant la bascule d'un client tant qu'une chaîne de suivi n'a pas été prouvée fonctionnelle de bout en bout.\u003C\u002Fp>\n\u003Cp>Un \u003Cstrong>scanner d'entropie\u003C\u002Fstrong> détecte les scripts orphelins (plus aucun appelant) et les met en quarantaine observée avant toute proposition de suppression — il ne supprime jamais lui-même — puis restitue un digest quotidien de l'état du système, avec un rituel hebdomadaire dédié à la question « qu'a-t-on construit qu'on supprimerait aujourd'hui ? ».\u003C\u002Fp>\n\n\u003Ch2 id=\"memoire-apprentissage\">7. Mémoire, apprentissage et auto-réparation de la documentation\u003C\u002Fh2>\n\u003Cp>Le harness porte une mémoire à trois niveaux : des rappels courts injectés en début de session, un rappel sémantique par recherche vectorielle sur l'historique des décisions et incidents passés, et des notes longues organisées en réseau de concepts liés. Une boucle nocturne consolide cette mémoire : elle récolte les incidents récents depuis l'historique de code, les qualifie, les indexe, puis rafraîchit des indicateurs agrégés consommés par le tableau de bord.\u003C\u002Fp>\n\u003Ch3>Boucle nocturne de maintenance de la documentation\u003C\u002Fh3>\n\u003Cp>Chaque nuit, le harness inspecte son propre état documentaire selon un cycle en douze étapes fixes : détecter les dérives entre le texte documenté et le code réel (lecture seule), mesurer les angles morts de couverture, vérifier la cohérence entre le statut déclaré d'un composant et son état d'exécution réel, recalculer les relations entre composants, réparer mécaniquement les références cassées quand une résolution unique existe, régénérer en profondeur un chapitre dérivé (un moteur relit le code réel et réécrit le chapitre, publie une version assainie, et l'ensemble passe par une \u003Cstrong>vérification anti-fuite\u003C\u002Fstrong> avant toute publication — en cas de doute, publication bloquée et alerte interne plutôt que fuite), proposer par email les chapitres restants à traiter, publier automatiquement ce qui franchit tous les contrôles machine, synchroniser l'état des composants vers la page de statut publique, ré-inspecter une seconde fois après publication (pour éviter qu'un instantané public reste en retard d'un cycle), calculer un bilan de santé sur quatre dimensions, et enfin publier ce bilan.\u003C\u002Fp>\n\u003Cp>Une revue externe optionnelle (un lecteur humain peut soumettre une critique sur un chapitre publié) est évaluée par un modèle sandboxé anti-injection avant de nourrir le cycle suivant, jamais avant confirmation. Aucun de ces mécanismes ne touche au code applicatif du produit — leur périmètre est strictement documentaire.\u003C\u002Fp>\n\u003Ch3>Immunité adaptative\u003C\u002Fh3>\n\u003Cp>Un détecteur de récurrence regroupe les incidents similaires (regroupement par densité, pas par mot-clé) et rédige des propositions de règle de garde-fou. Le modèle de menace est délibérément conservateur : \u003Cstrong>aucune proposition ne s'active seule\u003C\u002Fstrong> — chaque candidat reste inerte tant qu'une revue de sécurité humaine ne l'a pas validé et qu'un geste explicite ne l'a pas armé. Limite connue et assumée : le moteur d'évaluation des réflexes ne couvre aujourd'hui que l'édition de fichiers, la lecture, l'appel d'outils réseau et le spawn de sous-agents — pas les commandes shell — si bien que certaines propositions rédigées pour cibler une commande shell restent, à ce stade, sans levier d'application réel tant que cette famille n'est pas elle aussi couverte. Ce type de limite est documenté explicitement plutôt que masqué.\u003C\u002Fp>\n\u003Cp>Un contrôle de fin de tour détecte les erreurs survenues pendant la session qui vient de se terminer, en tire une leçon de comportement immédiate quand le motif est connu, et propose (sans jamais armer) une nouvelle règle de garde-fou pour les motifs récurrents non encore couverts.\u003C\u002Fp>\n\u003Ch3>Délibération\u003C\u002Fh3>\n\u003Cp>Un composant dédié confronte plusieurs perspectives d'agents à cadres cognitifs volontairement divergents sur une décision signalée comme sensible, puis restitue une carte du désaccord au fondateur. Loi d'asymétrie : ce composant fait remonter la tension, il ne tranche jamais — la décision reste humaine, seule.\u003C\u002Fp>\n\n\u003Ch2 id=\"personas-agents\">8. Personas et agents\u003C\u002Fh2>\n\u003Cp>Un référentiel central porte l'identité, le rôle et le cadre cognitif de chaque agent spécialisé du système. Un audit périodique détecte les mentions technologiques devenues obsolètes dans ces fiches (une pile technique citée qui n'existe plus, par exemple), et un cycle de rafraîchissement assisté par modèle de langage propose une mise à jour soumise à relecture humaine avant application. Les portraits visuels associés sont synchronisés en parallèle.\u003C\u002Fp>\n\n\u003Ch2 id=\"inbox-email\">9. Inbox et communication client\u003C\u002Fh2>\n\u003Cp>Règle dure : aucun email n'est jamais envoyé directement à un client à l'initiative de l'IA. Toute communication externe passe par une \u003Cstrong>façade unique\u003C\u002Fstrong> qui impose un cycle brouillon → revue → envoi, la revue étant systématiquement adressée en interne avant tout envoi réel ; un garde-fou technique bloque toute tentative d'envoi de mail par un chemin de code parallèle. Une boîte de réception est surveillée en continu, avec une voie de secours de connexion directe en cas d'indisponibilité de la façade principale.\u003C\u002Fp>\n\u003Cp>Le ton de rédaction se résout automatiquement par client détecté (vouvoiement\u002Ftutoiement, appellation, registre, leviers de conversation, points à éviter), enrichi d'un dossier multi-sources (échanges passés, historique technique, planification, journaux) pour interdire une réponse fondée sur un seul message hors contexte. Toute pièce jointe extraite d'un email entrant passe par un \u003Cstrong>scan antivirus obligatoire\u003C\u002Fstrong> avant toute ouverture ou lecture de contenu — verdict propre requis, sinon blocage et escalade.\u003C\u002Fp>\n\u003Cp>Un digest matinal unique agrège les signaux de la nuit et les étiquette par catégorie d'action, plutôt que de forcer une relecture manuelle de chaque flux. Un gardien de clôture de boucle détecte deux types de fuite : un message reçu resté sans accusé de réception au-delà d'un délai, et un fil résolu en interne jamais notifié au client concerné. Un partage de secret à usage unique (sans service tiers, sans mot de passe en clair par email) et un document d'accès sécurisé complètent l'outillage de remise client.\u003C\u002Fp>\n\n\u003Ch2 id=\"blog-seo-contenu\">10. Contenu, blog et SEO\u003C\u002Fh2>\n\u003Cp>La publication éditoriale passe par un moteur unique \u003Cstrong>« base de données d'abord »\u003C\u002Fstrong>. L'optimisation SEO (méta-données, description, FAQ, maillage interne) passe elle aussi par un \u003Cstrong>noyau unique\u003C\u002Fstrong> multilingue — règle dure du système : aucun second moteur d'écriture SEO ne doit exister en parallèle, pour garantir homogénéité, idempotence, et parité entre toutes les langues d'un site. Chaque écriture SEO est gatée par des validateurs qui refusent la publication d'un contenu insuffisant (résumé sans lien, FAQ trop courte, description sans preuve).\u003C\u002Fp>\n\u003Cp>Autour de ce noyau gravitent : un nettoyage automatique du contenu éditorial obsolète, une génération d'images de couverture et de supports sociaux, une surveillance de l'optimisation pour les moteurs génératifs (recherche IA), un suivi du vocabulaire technique cité dans les articles, une sentinelle de santé SEO technique multi-site avec alerte sur régression, et une vigie de couverture qui détecte spécifiquement les pages restées sans méta-description dans la langue source (un angle mort que le suivi habituel des traductions ne voit pas).\u003C\u002Fp>\n\u003Cp>La réconciliation de catégories couvre la déduplication de doublons, l'aplatissement d'arborescences trop profondes, et le respect d'une profondeur maximale imposée avant toute mise en production (contrôlé par une sentinelle bloquante).\u003C\u002Fp>\n\u003Ch3>Recherche organique\u003C\u002Fh3>\n\u003Cp>L'intégration avec la console de recherche s'exécute dans un environnement isolé qui ne détient que l'accès nécessaire à cette API précise ; les identifiants déchiffrés restent en mémoire du conteneur d'exécution et ne transitent jamais en sortie standard ni en journal. Un orchestrateur récupère le trafic organique sur des fenêtres glissantes, importe les données dimensionnelles (dates, requêtes, pages), et soumet les plans de site à l'indexation.\u003C\u002Fp>\n\u003Ch3>Traductions et internationalisation\u003C\u002Fh3>\n\u003Cp>Un pipeline de traduction couvre les catégories, produits, contenus éditoriaux et segments de route, avec des garde-fous spécifiques : rejet d'une retraduction si une quantité numérique disparaît du texte source, préservation stricte de la structure HTML, et repérage des liens internes encore pointés vers la langue source dans une page traduite pour les réécrire vers l'URL canonique correspondante.\u003C\u002Fp>\n\n\u003Ch2 id=\"browser-agents\">11. Agents navigateur\u003C\u002Fh2>\n\u003Cp>L'automatisation de navigateur privilégie une réputation réseau proche de celle d'un utilisateur résidentiel réel plutôt que de chercher à contourner les défis anti-robot d'un site tiers — une distinction de doctrine assumée. Une façade générique route les actions de navigation vers une machine dédiée à cet usage via un protocole de contrôle distant, ce qui découple le pilotage applicatif de l'exécution physique du navigateur.\u003C\u002Fp>\n\u003Cp>Un mode de pilotage direct d'un poste de travail personnel (captures d'écran et interactions clavier\u002Fsouris pilotées à distance) est disponible pour les tâches strictement graphiques sans interface programmable, activé uniquement derrière un interrupteur explicite. Un adaptateur d'achat déterministe illustre une ligne rouge de conception forte : le modèle de langage décide \u003Cem>quoi\u003C\u002Fem> acheter, un code déterministe exécute l'action, et le passage en caisse automatisé est explicitement exclu — jamais de finalisation d'achat sans confirmation humaine.\u003C\u002Fp>\n\n\u003Ch2 id=\"finance\">12. Banque, facturation et finance\u003C\u002Fh2>\n\u003Cp>Le rapprochement bancaire suit un principe strict de prudence : import et catégorisation des transactions par défaut en mode simulation (aucune écriture sans confirmation explicite), catégorisation automatique par référentiel tiers→catégorie, puis rapprochement des transactions de revenu avec les factures ouvertes par correspondance de montant exact et de client — avec départage explicite en cas d'ambiguïté, jamais de rapprochement au jugé.\u003C\u002Fp>\n\u003Cp>Le moteur de suivi fiscal pour la structure individuelle calcule \u003Cstrong>en lecture seule\u003C\u002Fstrong> les indicateurs déclaratifs (chiffre encaissé, charges sociales dues, provisions, seuils légaux) : il ne décide jamais rien fiscalement et n'écrit rien en base — les chiffres produits restent des brouillons indicatifs à valider avec un expert-comptable. Un récapitulatif hebdomadaire et des alertes ponctuelles (échéances, seuils dépassés) sont envoyés automatiquement, avec un anti-spam garantissant qu'une même alerte n'est jamais renvoyée deux fois.\u003C\u002Fp>\n\n\u003Ch2 id=\"veille\">13. Veille et surveillance de marque\u003C\u002Fh2>\n\u003Cp>Un barème de qualité vérifie automatiquement la conformité d'une page aux jetons de design de la marque et aux critères d'accessibilité (contraste, focus visible, taille de cible, structure sémantique) — utilisable en ligne de commande ou comme verrou avant mise en production. Une veille technologique et concurrentielle alimente une couche de données partagée par plusieurs axes de surveillance.\u003C\u002Fp>\n\u003Cp>Côté publicité payante, l'outillage couvre : le téléversement des conversions hors-ligne (une commande confirmée déclenche la remontée vers la plateforme publicitaire), la lecture seule des réglages de suivi d'un compte annonceur, et des veilleurs qui alertent une seule fois lorsqu'une première conversion est confirmée puis se désarment automatiquement pour ne pas répéter l'alerte. Une veille de plateforme freelance drafte des réponses dans le ton habituel puis s'arrête : des garde-fous de compte encadrent explicitement l'automate pour qu'il reste une aide à la communication, jamais un outil d'évasion de détection.\u003C\u002Fp>\n\n\u003Ch2 id=\"deploy-infra\">14. Déploiement, infrastructure et sauvegardes\u003C\u002Fh2>\n\u003Cp>Règle dure d'asymétrie : la mise en production réelle est un geste \u003Cstrong>strictement manuel\u003C\u002Fstrong>, réservé au fondateur, jamais déclenché par l'IA. Le déploiement vers l'environnement de préproduction\u002Frebuild, lui, est systématiquement à la charge de l'IA — jamais laissé « pour plus tard ». Avant tout déploiement, l'arbre de travail doit être commité : tout changement non commité serait perdu au déploiement suivant.\u003C\u002Fp>\n\u003Cp>La chaîne de déploiement partagée détecte la dérive entre le schéma de base de données déclaré dans le code et l'état réel de la base, et peut appliquer automatiquement les changements additifs manquants (jamais de suppression automatique) si ce mode est explicitement activé. Elle génère aussi les segments de route localisés avant construction, exécute le build, l'empaquetage, l'envoi, le redémarrage du service, puis un contrôle de santé post-déploiement — avec un préchauffage de cache en arrière-plan pour éviter qu'un premier visiteur ne paie le coût d'un rendu lourd juste après la bascule.\u003C\u002Fp>\n\u003Cp>Le provisionnement d'une nouvelle infrastructure client suit un scénario déclaratif à partir d'un fichier de configuration, avec bootstrap automatique des comptes d'administration, de la charte graphique déduite du logo, et du pré-remplissage des informations déjà connues. La rotation des identifiants d'accès administratifs est idempotente et propage la configuration réseau correspondante.\u003C\u002Fp>\n\u003Ch3>Sauvegardes et restauration\u003C\u002Fh3>\n\u003Cp>Les sauvegardes de bases de données et de fichiers critiques sont chiffrées et répliquées vers un stockage objet distant, avec une politique de cycle de vie et une rotation des journaux dédiés. Une restauration de test \u003Cstrong>réelle\u003C\u002Fstrong> (pas une simple vérification de checksum) est exécutée mensuellement pour prouver la restaurabilité effective, pas seulement la présence du fichier de sauvegarde.\u003C\u002Fp>\n\n\u003Ch2 id=\"oss-migrations\">15. Synchronisation open-source, refactor et migrations\u003C\u002Fh2>\n\u003Cp>Le cœur du produit e-commerce publié en open-source passe par un pipeline d'assainissement dédié avant toute publication : retrait de tout commentaire interne, traduction du reste vers l'anglais, et une \u003Cstrong>liste blanche nominative\u003C\u002Fstrong> de ce qui a le droit d'être publié — jamais une logique d'exclusion par défaut, toujours une logique d'inclusion explicite (cicatrice interne d'une fuite passée par bootstrap non maîtrisé). Le bootstrap de publication refuse de démarrer si cette liste blanche est absente.\u003C\u002Fp>\n\u003Cp>Les migrations de schéma suivent une doctrine d'expansion-contraction stricte sur toute base de production payante : ajouts seulement avant bascule, jamais de suppression avant vérification complète. Un module n'installe son propre schéma que si la configuration du site concerné déclare explicitement l'étendre — un module absent de cette déclaration ne crée jamais ses tables.\u003C\u002Fp>\n\u003Cp>Un pipeline d'extraction-transformation-chargement dédié à un fournisseur externe illustre le patron général : lecture incrémentale idempotente d'un catalogue distant, protections anti-blocage réseau, verrouillage anti-chevauchement d'exécution, puis phases avales de récupération d'image et d'import en cascade — toujours en lecture seule côté source, jamais d'écriture sur un système tiers de production.\u003C\u002Fp>\n\u003Ch3>Amorçage de démonstration\u003C\u002Fh3>\n\u003Cp>Un environnement de démonstration complet (catalogue, navigation, variantes, paniers, commandes) peut être réinitialisé en une commande vers un instantané de référence propre, utilisé pour les démonstrations commerciales sans jamais toucher à un environnement client réel.\u003C\u002Fp>\n\n\u003Ch2 id=\"monitoring-divers\">16. Monitoring, obsolescence et outillage divers\u003C\u002Fh2>\n\u003Cp>Cette famille couvre les tests unitaires des fonctionnalités à cycle long, un pont de test vers l'environnement de base de données sandbox, un moteur de planches documentaires annotées, et la ségrégation stricte des identifiants d'un système hérité (jamais de secret affiché en clair, distinction explicite entre ce qui est montrable et ce qui reste rangé). Un outil de signature appose une signature numérisée sur un document PDF en écrivant systématiquement un \u003Cstrong>nouveau\u003C\u002Fstrong> fichier, sans jamais toucher ni envoyer l'original.\u003C\u002Fp>\n\u003Cp>Les tests destructifs de gestion de version sont systématiquement isolés dans un espace de travail jetable, jamais exécutés sur la ligne principale du dépôt.\u003C\u002Fp>\n\u003Ch3>Configurateur 3D sur mesure\u003C\u002Fh3>\n\u003Cp>Une chaîne bout-en-bout transforme une image de référence (moodboard, croquis) en objet 3D exploitable : extraction des vues, génération d'un maillage 3D multi-vues, colorisation par zones géométriques, puis export dans un format standard consommable par un visualiseur web. Une variante paramétrique génère du mobilier par primitives géométriques ou à partir d'une description textuelle libre, avec un plan coté « prêt-usine » et un contrôle qualité géométrique automatisé (étanchéité du maillage, symétrie) avant livraison.\u003C\u002Fp>\n\n\u003Ch2 id=\"hooks-gouvernance\">17. Gouvernance en temps réel — les garde-fous de session\u003C\u002Fh2>\n\u003Cp>Le harness applique une bonne partie de sa doctrine non pas par la documentation seule, mais par des \u003Cstrong>contrôles automatiques déclenchés en temps réel\u003C\u002Fstrong> avant et après chaque action de l'agent IA — édition de fichier, appel shell, lecture, appel réseau, invocation de sous-agent, fin de session. Ces contrôles forment une seconde ligne de défense qui ne dépend pas de la bonne volonté de l'agent au moment de l'action.\u003C\u002Fp>\n\u003Cp>Parmi les mécanismes les plus significatifs : blocage de tout envoi d'email hors de la façade unique ; blocage de toute tentative de mise en production directe par l'IA (la commande de bascule réelle reste strictement humaine) ; blocage du collage de secrets en clair ou de l'ajout massif non contrôlé de fichiers à un commit ; exigence d'un scan antivirus propre avant l'ouverture de toute pièce jointe ; blocage d'une requête de base de données brute qui référencerait une colonne non déclarée dans le schéma officiel ; évaluation d'un registre de règles apprises avant édition de fichier, lecture, appel réseau ou invocation de sous-agent ; nudge de structuration obligatoire dès qu'un travail dépasse le périmètre d'une simple correction ponctuelle.\u003C\u002Fp>\n\u003Cp>Un contrôle spécifique interdit à l'agent de \u003Cstrong>poser une question de validation dans le chat\u003C\u002Fstrong> pour un envoi d'email — la doctrine impose de créer directement le brouillon via la façade dédiée, dont la copie de revue interne fait déjà office de validation ; poser la question reviendrait à contourner ce circuit. Un autre garde-fou, propre au produit d'assistance familiale, bloque toute modification de code touchant à l'identité d'achat d'un foyer si elle ne porte pas explicitement l'identifiant du foyer concerné dans son voisinage immédiat — pour empêcher qu'une identité de foyer ne fuite jamais vers une autre.\u003C\u002Fp>\n\u003Cp>À la fin de chaque session, un contrôle de clôture vérifie que l'arbre de travail reste propre (rien d'important laissé non commité), journalise les incidents détectés durant le tour qui vient de se terminer, et refuse de laisser croire qu'une mise en production a eu lieu si elle a en réalité été bloquée par le garde-fou correspondant.\u003C\u002Fp>\n\n\u003Ch2 id=\"fiabilite\">18. Notes de fiabilité\u003C\u002Fh2>\n\u003Cp>Ce catalogue est généré et revérifié par un processus mixte : extraction automatique depuis le code source réel, puis relecture adverse ciblée qui confronte chaque affirmation du catalogue à l'état effectif du système (planification réelle, câblage réel des contrôles, comportement réel du code) plutôt qu'à ce que la documentation précédente affirmait. Chaque correction identifiée est journalisée avec sa source, pour que la trace de fiabilité elle-même reste auditable.\u003C\u002Fp>\n\u003Cp>Par principe de transparence : une information déduite plutôt que directement vérifiée est signalée comme telle plutôt que présentée avec une fausse certitude, et une limite de couverture connue (par exemple un mécanisme de garde-fou qui ne couvre pas encore une famille entière d'actions) est nommée explicitement plutôt que masquée.\u003C\u002Fp>\n","\u003Cp>Synedre orchestrates CodeMyShop: Synedre is the internal agentic \u003Cstrong>harness\u003C\u002Fstrong> — the full set of automations, scripts and entry points that run the business (email, structured projects, audits, content, deployments, finance) — while CodeMyShop is the multi-tenant e-commerce product this harness operates. This chapter documents the harness itself: its tool inventory, its functional families, and the governance mechanisms that frame it. It does not describe the architecture of the CodeMyShop product itself.\u003C\u002Fp>\n\n\u003Ch2 id=\"perimetre\">0. Scope, method and coverage\u003C\u002Fh2>\n\u003Cp>The harness gathers several hundred automation scripts and executable entry points, split into two broad families: Python automation modules and shell\u002FJS utilities. Each script is described here by a one-line role and a typical invocation mode, so an engineer picking up the system can quickly find which tool does what without reading through the entire codebase.\u003C\u002Fp>\n\u003Cp>Descriptions are extracted \u003Cstrong>programmatically\u003C\u002Fstrong> from each file's header comment — never invented. When a file only carries a generic license header, the actual role comment was pulled from further down the file. This recovery is not applied uniformly: the catalogue notes, case by case, when a description still needs confirming rather than presenting it as certain.\u003C\u002Fp>\n\u003Cp>Coverage is re-verified at regular intervals by automatically cross-checking the file inventory against the real system scheduler, to catch two kinds of drift: a script still documented as active after being removed from scheduling, and conversely a script that is actually scheduled but missing from the catalogue.\u003C\u002Fp>\n\u003Ctable>\n\u003Ctr>\u003Cth>Invocation mode\u003C\u002Fth>\u003Cth>Meaning\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>cron\u003C\u002Ftd>\u003Ctd>launched by the system scheduler, usually behind a shared watchdog\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>CLI\u003C\u002Ftd>\u003Ctd>run by hand by an operator or an agent\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>skill\u003C\u002Ftd>\u003Ctd>facade behind a natural-language-invokable capability\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>hook\u003C\u002Ftd>\u003Ctd>fired automatically before\u002Fafter an AI agent action (file edit, shell call, read, sub-agent spawn, session end)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>lib\u003C\u002Ftd>\u003Ctd>module imported by other scripts, not a standalone entry point\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>worker\u003C\u002Ftd>\u003Ctd>background process continuously draining a queue\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftable>\n\n\u003Ch2 id=\"flux-ensemble\">1. Families and overall flow\u003C\u002Fh2>\n\u003Cp>The harness's general flow follows a single path: an inbound email is captured and its intent is classified (simple execution, structured project, question, or noise); depending on the result, the work is either executed directly, opened as a structured project with an assigned team, or dropped into an idea-gestation space. Actual execution always runs through a tooled agent cycle, which then fans out to five destinations: quality audits, content\u002FSEO production, finance, browser automation, or deployment. All of these branches converge on a \u003Cstrong>single database\u003C\u002Fstrong>, accessed exclusively through one shared access facade — never a direct connection scattered across the code.\u003C\u002Fp>\n\u003Cp>This single-source-of-truth choice is structural: no business data (clients, secrets, repositories, pricing) lives in a static file — it lives in the database, and application code only reads\u002Fwrites it through this facade.\u003C\u002Fp>\n\n\u003Ch2 id=\"socle-commun\">2. Common foundation\u003C\u002Fh2>\n\u003Cp>A set of cross-cutting modules carries the foundations used by nearly every automation: a database access facade, a centralized environment-variable loader, mandatory structured logging, and a provider-agnostic AI facade (it routes to different language models depending on the task and budget, without coupling application code to a single provider).\u003C\u002Fp>\n\u003Cp>Every scheduled task runs under a shared \u003Cstrong>watchdog\u003C\u002Fstrong> that enforces a default execution timeout and kills any script that exceeds it — with explicit, documented, bounded exceptions for legitimately long-running tasks (nightly memory consolidation, multi-session generation). An event-logging system feeds the live dashboard of currently running agents.\u003C\u002Fp>\n\u003Cp>The foundation also carries a \u003Cstrong>decentralized reflex\u003C\u002Fstrong> mechanism: before every file edit, read, network tool call, or sub-agent spawn, a fast evaluation checks a registry of learned rules (allow \u002F warn \u002F deny) and traces the decision to a dedicated audit log. The law governing this registry is a strict asymmetry law: any new rule can only tighten behavior, never loosen it, and sensitive zones fail closed (block by default) if the rule database is unreachable.\u003C\u002Fp>\n\n\u003Ch2 id=\"atlas-orchestration\">3. Orchestration\u003C\u002Fh2>\n\u003Cp>The orchestration layer continuously watches a dedicated inbox, classifies the intent of every inbound message (simple execution \u002F structured project \u002F question \u002F noise), then triggers the matching action: for actionable work, a headless agent session is started to act on the classified email, with a generous maximum delay and anti-duplicate guard-rails to prevent the same cycle from firing twice. Going to production remains a strictly human gesture; the orchestrator can propose an \"email-triggered\" release with triple anti-spoofing verification, but never triggers a production switch itself.\u003C\u002Fp>\n\u003Cp>A ReAct-style cycle (reason → act → observe) drives every unit task; dedicated detectors spot tasks stuck beyond a time or consumption threshold, propose an unblocking plan, or automatically pause a runaway task (abnormal duration or cost). A daily summary consolidates the night's activity.\u003C\u002Fp>\n\u003Ch3>Interactive session → dashboard bridge\u003C\u002Fh3>\n\u003Cp>An optional mechanism lets an interactive session declare itself bound to an ongoing structured project: that session's activity (actions, messages) is then mirrored in real time onto that project's tracking dashboard, never interfering when no binding is active. A kill switch fully disables this bridge.\u003C\u002Fp>\n\u003Ch3>Multi-provider execution\u003C\u002Fh3>\n\u003Cp>A common execution contract lets each unit of work be routed to different language-model engines depending on need (speed, cost, availability) instead of being locked to a single provider. Every run is timed and its real cost is computed from a central pricing table — never a hard-coded price — then aggregated per project and per brand, feeding a continuous budget control.\u003C\u002Fp>\n\n\u003Ch2 id=\"chantiers\">4. Structured projects\u003C\u002Fh2>\n\u003Cp>Creating a structured project follows a mandatory multi-step procedure: fully reading the original request (including its attachments, always run through an antivirus scan before any opening), auditing available agents to assemble a team relevant to the scope, drafting an explicit mission statement, recruiting at least two distinct profiles for any client-facing work, then atomically creating the project with its first batch of tasks — the whole thing fails and rolls back if a single step fails, never a half-created state.\u003C\u002Fp>\n\u003Cp>Dedicated tools generate a mission-statement draft, manage the team recruited per project, orchestrate the automatic explosion of a discovery into implementation tasks, audit the relevance of active projects, and fire an alert as soon as a project consumes 80% of its budget envelope — ahead of the hard cap that kills the worker. The commercial pipeline (prospecting → negotiation) shares this same mechanic: legal and solvency qualification of a prospect via public registries, structured extraction of exchanges, generation of a complete negotiation file.\u003C\u002Fp>\n\n\u003Ch2 id=\"brainstorm\">5. Ideas and gestation\u003C\u002Fh2>\n\u003Cp>A dedicated queue carries ideas in gestation; a background worker processes them by dialoguing with the orchestrator, then a sequential challenge cycle confronts them with critical scrutiny before maturation. A validated idea can be promoted into a structured project; conversely, a project can be demoted back to an idea if its scope turns out premature — a mirror bridge handles both directions.\u003C\u002Fp>\n\n\u003Ch2 id=\"audits-qualite-securite\">6. Audits, quality and security\u003C\u002Fh2>\n\u003Cp>A dense family of audits runs nightly or continuously: a global audit of every automation, a database schema audit against the naming convention, a drift audit between the schema declared in code and the real database state, daily backup freshness monitoring, a monthly test of actual restorability from a dump, a software dependency security scan, and detection of duplicate\u002Fnear-duplicate editorial content.\u003C\u002Fp>\n\u003Cp>On the offensive-security side, a \u003Cstrong>non-intrusive\u003C\u002Fstrong> reconnaissance orchestrator sweeps every active domain weekly, pulling the target list from a central registry — never a client name hard-coded in the code — and only sends an alert when new high-severity findings appear (no alert noise on every pass). Real intrusive testing never arms itself automatically: that is a separate manual gesture. An accessibility audit checks compliance with the WCAG 2.2 AA standard. An anti-leak probe hits every administration entry point without a session cookie and always expects a refusal — any positive response fires an immediate alert.\u003C\u002Fp>\n\u003Cp>A \u003Cstrong>visual watchdog\u003C\u002Fstrong> actually captures a rendered page's screen and asks a multimodal model for a verdict against the expected visual intent, rather than only checking that the code ran without error. A route-health sentinel monitors the 404 error rate \u003Cstrong>per page type\u003C\u002Fstrong> rather than a global threshold — an entire page type can be fully broken while never crossing an average threshold, which would still be a real incident.\u003C\u002Fp>\n\u003Cp>Several mechanical guard-rails block non-compliant code before it is even committed: refusal of a raw SQL query referencing a column not declared in the canonical schema, a static invariant guaranteeing that every contact-capturing form is actually wired to its corresponding advertising-conversion pipeline, a check that a production box carries the expected intrusion protections, a silent-death sentinel catching a check that would fail silently against an unreachable database, a pre-production guard-rail refusing to switch a client live until a tracking chain has proven itself working end to end.\u003C\u002Fp>\n\u003Cp>An \u003Cstrong>entropy scanner\u003C\u002Fstrong> detects orphaned scripts (no remaining caller) and puts them into observed quarantine before any removal proposal — it never deletes anything itself — then returns a daily digest of system state, including a weekly ritual dedicated to the question \"what have we built that we would remove today?\"\u003C\u002Fp>\n\n\u003Ch2 id=\"memoire-apprentissage\">7. Memory, learning and documentation self-repair\u003C\u002Fh2>\n\u003Cp>The harness carries a three-level memory: short reminders injected at the start of a session, semantic recall via vector search over the history of past decisions and incidents, and long-form notes organized as a network of linked concepts. A nightly loop consolidates this memory: it harvests recent incidents from the code history, qualifies them, indexes them, then refreshes aggregate indicators consumed by the dashboard.\u003C\u002Fp>\n\u003Ch3>Nightly documentation-maintenance loop\u003C\u002Fh3>\n\u003Cp>Every night, the harness inspects its own documentation state through a fixed twelve-step cycle: detect drift between documented text and real code (read-only), measure coverage blind spots, check consistency between a component's declared status and its actual runtime state, recompute relations between components, mechanically repair broken references when a single resolution exists, deep-regenerate a derived chapter (an engine re-reads the real code and rewrites the chapter, publishes a sanitized version, and the whole thing goes through an \u003Cstrong>anti-leak check\u003C\u002Fstrong> before any publication — when in doubt, publication is blocked and an internal alert fires instead of a leak), propose the remaining chapters to process by email, automatically publish whatever clears every machine gate, sync component status to the public status page, re-inspect a second time after publishing (so a public snapshot never lags one cycle behind), compute a health assessment across four dimensions, and finally publish that assessment.\u003C\u002Fp>\n\u003Cp>An optional external review (a human reader can submit critique on a published chapter) is evaluated by an injection-hardened sandboxed model before feeding the next cycle, never before confirmation. None of these mechanisms ever touch the product's application code — their scope is strictly documentary.\u003C\u002Fp>\n\u003Ch3>Adaptive immunity\u003C\u002Fh3>\n\u003Cp>A recurrence detector clusters similar incidents (density-based grouping, not keyword matching) and drafts candidate guard-rail rules. The threat model is deliberately conservative: \u003Cstrong>no proposal ever activates itself\u003C\u002Fstrong> — every candidate stays inert until a human security review has validated it and an explicit gesture has armed it. Known and acknowledged limit: the reflex-evaluation engine currently only covers file edits, reads, network tool calls and sub-agent spawns — not shell commands — so some proposals drafted to target a shell command currently have no real enforcement lever until that family is covered too. This kind of limit is documented explicitly rather than hidden.\u003C\u002Fp>\n\u003Cp>An end-of-turn check detects errors that occurred during the session that just ended, draws an immediate behavioral lesson when the pattern is already known, and proposes (without ever arming) a new guard-rail rule for recurring patterns not yet covered.\u003C\u002Fp>\n\u003Ch3>Deliberation\u003C\u002Fh3>\n\u003Cp>A dedicated component confronts several agent perspectives with deliberately divergent cognitive frames on a decision flagged as sensitive, then returns a map of the disagreement to the founder. Asymmetry law: this component surfaces the tension, it never decides — the decision stays human, and human alone.\u003C\u002Fp>\n\n\u003Ch2 id=\"personas-agents\">8. Personas and agents\u003C\u002Fh2>\n\u003Cp>A central registry carries the identity, role and cognitive frame of each specialized agent in the system. A periodic audit detects technology mentions that have gone stale in these profiles (a cited tech stack that no longer exists, for example), and an assisted refresh cycle proposes an update submitted to human review before it is applied. The associated visual portraits are synced in parallel.\u003C\u002Fp>\n\n\u003Ch2 id=\"inbox-email\">9. Inbox and client communication\u003C\u002Fh2>\n\u003Cp>Hard rule: no email is ever sent directly to a client on the AI's own initiative. All external communication goes through a \u003Cstrong>single facade\u003C\u002Fstrong> that enforces a draft → review → send cycle, with the review copy systematically routed internally before any real send; a technical guard-rail blocks any attempt to send mail through a parallel code path. An inbox is monitored continuously, with a direct-connection fallback path for when the main facade is unavailable.\u003C\u002Fp>\n\u003Cp>Writing tone resolves automatically per detected client (formal\u002Finformal register, form of address, tone, conversation levers, things to avoid), enriched with a multi-source dossier (past exchanges, technical history, scheduling, logs) to forbid a reply based on a single message read out of context. Every attachment extracted from an inbound email goes through a \u003Cstrong>mandatory antivirus scan\u003C\u002Fstrong> before any opening or content read — a clean verdict is required, otherwise blocked and escalated.\u003C\u002Fp>\n\u003Cp>A single morning digest aggregates the night's signals and labels them by action category, rather than forcing a manual reread of every stream. A loop-closure guardian detects two kinds of leak: a received message left without acknowledgment past a threshold, and a thread resolved internally but never communicated back to the affected client. A one-time secret share (no third-party service, no plaintext password by email) and a secure access handoff document round out the client-handoff tooling.\u003C\u002Fp>\n\n\u003Ch2 id=\"blog-seo-contenu\">10. Content, blog and SEO\u003C\u002Fh2>\n\u003Cp>Editorial publishing goes through a single \u003Cstrong>\"database-first\"\u003C\u002Fstrong> engine. SEO optimization (meta tags, description, FAQ, internal linking) also goes through a single multilingual \u003Cstrong>core engine\u003C\u002Fstrong> — a hard system rule: no second SEO-writing engine is allowed to exist in parallel, to guarantee homogeneity, idempotence, and parity across every language on a site. Every SEO write is gated by validators that refuse to publish insufficient content (a summary with no link, a too-short FAQ, a description with no evidence).\u003C\u002Fp>\n\u003Cp>Orbiting this core: automatic cleanup of stale editorial content, cover-image and social-asset generation, monitoring for generative-engine optimization (AI search), tracking of technical vocabulary cited in articles, a multi-site technical SEO health sentinel with regression alerting, and a coverage watchdog that specifically detects pages left without a meta description in the source language (a blind spot the usual translation tracking misses).\u003C\u002Fp>\n\u003Cp>Category reconciliation covers deduplicating doubles, flattening overly deep trees, and enforcing a maximum depth cap before any production release (checked by a blocking sentinel).\u003C\u002Fp>\n\u003Ch3>Organic search\u003C\u002Fh3>\n\u003Cp>The search-console integration runs in an isolated environment that only holds the access needed for that specific API; decrypted credentials stay in the execution container's memory and never travel to standard output or logs. An orchestrator pulls organic traffic over rolling windows, imports dimensional data (dates, queries, pages), and submits sitemaps for indexing.\u003C\u002Fp>\n\u003Ch3>Translation and internationalization\u003C\u002Fh3>\n\u003Cp>A translation pipeline covers categories, products, editorial content and route segments, with specific guard-rails: rejecting a re-translation if a numeric quantity disappears from the source text, strictly preserving HTML structure, and detecting internal links still pointing at the source language inside a translated page in order to rewrite them to the matching canonical URL.\u003C\u002Fp>\n\n\u003Ch2 id=\"browser-agents\">11. Browser agents\u003C\u002Fh2>\n\u003Cp>Browser automation favors a network reputation close to a genuine residential user rather than trying to defeat a third-party site's anti-bot challenges — a deliberate doctrine distinction. A generic facade routes navigation actions to a machine dedicated to this purpose over a remote-control protocol, which decouples application-level piloting from the physical browser execution.\u003C\u002Fp>\n\u003Cp>A direct piloting mode for a personal workstation (remotely driven screenshots and keyboard\u002Fmouse interactions) is available for strictly graphical tasks with no programmable interface, enabled only behind an explicit switch. A deterministic purchasing adapter illustrates a strong design red line: the language model decides \u003Cem>what\u003C\u002Fem> to buy, deterministic code executes the action, and automated checkout completion is explicitly excluded — no purchase is ever finalized without human confirmation.\u003C\u002Fp>\n\n\u003Ch2 id=\"finance\">12. Banking, invoicing and finance\u003C\u002Fh2>\n\u003Cp>Bank reconciliation follows a strict caution principle: transaction import and categorization default to simulation mode (no write without explicit confirmation), automatic categorization against a vendor→category reference, then matching revenue transactions to open invoices by exact amount and client — with explicit tie-breaking on ambiguity, never a best-guess match.\u003C\u002Fp>\n\u003Cp>The tax-tracking engine for the sole-proprietor structure computes \u003Cstrong>read-only\u003C\u002Fstrong> filing indicators (cash received, social contributions due, provisions, legal thresholds): it never decides anything tax-related and writes nothing to the database — the figures it produces remain indicative drafts to validate with an accountant. A weekly recap and point-in-time alerts (deadlines, thresholds crossed) are sent automatically, with anti-spam guaranteeing the same alert is never sent twice.\u003C\u002Fp>\n\n\u003Ch2 id=\"veille\">13. Watch and brand monitoring\u003C\u002Fh2>\n\u003Cp>A quality scorecard automatically checks a page's compliance against brand design tokens and accessibility criteria (contrast, visible focus, target size, semantic structure) — usable from the command line or as a lock before production release. Technology and competitive watch feeds a data layer shared across several monitoring fronts.\u003C\u002Fp>\n\u003Cp>On the paid-advertising side, the tooling covers: offline conversion upload (a confirmed order triggers upload to the ad platform), read-only inspection of an advertiser account's tracking settings, and watchers that alert exactly once when a first conversion is confirmed and then disarm themselves automatically to avoid repeating the alert. A freelance-platform watch drafts replies in the usual tone and then stops there: account guard-rails explicitly frame the automation so it stays a communication aid, never a detection-evasion tool.\u003C\u002Fp>\n\n\u003Ch2 id=\"deploy-infra\">14. Deployment, infrastructure and backups\u003C\u002Fh2>\n\u003Cp>Hard asymmetry rule: an actual production release is a \u003Cstrong>strictly manual\u003C\u002Fstrong> gesture, reserved for the founder, never triggered by the AI. Deploying to the staging\u002Frebuild environment, on the other hand, is systematically the AI's own job — never left \"for later.\" Before any deploy, the working tree must be committed: any uncommitted change would be lost on the next deploy.\u003C\u002Fp>\n\u003Cp>The shared deploy pipeline detects drift between the database schema declared in code and the database's real state, and can automatically apply missing additive changes (never an automatic deletion) when that mode is explicitly enabled. It also generates localized route segments before build, runs the build, packaging, upload, service restart, then a post-deploy health check — with a background cache warm-up so the first visitor after a release doesn't pay the cost of a heavy render.\u003C\u002Fp>\n\u003Cp>Provisioning a new client's infrastructure follows a declarative scenario from a configuration file, with automatic bootstrap of admin accounts, a design system derived from the logo, and pre-filling of already-known information. Rotation of admin access credentials is idempotent and propagates the matching network configuration.\u003C\u002Fp>\n\u003Ch3>Backups and restore\u003C\u002Fh3>\n\u003Cp>Database and critical file backups are encrypted and replicated to remote object storage, with a lifecycle policy and dedicated log rotation. A \u003Cstrong>real\u003C\u002Fstrong> test restore (not just a checksum check) runs monthly to prove actual restorability, not merely the presence of a backup file.\u003C\u002Fp>\n\n\u003Ch2 id=\"oss-migrations\">15. Open-source sync, refactoring and migrations\u003C\u002Fh2>\n\u003Cp>The e-commerce product core published as open source goes through a dedicated sanitization pipeline before any publication: stripping every internal comment, translating the rest to English, and a \u003Cstrong>named allow-list\u003C\u002Fstrong> of what is permitted to be published — never a default-exclude logic, always an explicit include logic (an internal scar from a past leak caused by an unchecked bootstrap). The publication bootstrap refuses to start if this allow-list is missing.\u003C\u002Fp>\n\u003Cp>Schema migrations follow a strict expand-contract doctrine on any paying production database: additions only before switchover, never a deletion before full verification. A module only installs its own schema if the relevant site's configuration explicitly declares extending it — a module absent from that declaration never creates its tables.\u003C\u002Fp>\n\u003Cp>An extract-transform-load pipeline dedicated to one external supplier illustrates the general pattern: idempotent incremental reading of a remote catalogue, anti-ban network protections, overlap-prevention locking, then downstream phases of image retrieval and cascading import — always read-only on the source side, never a write to a third-party production system.\u003C\u002Fp>\n\u003Ch3>Demo bootstrapping\u003C\u002Fh3>\n\u003Cp>A complete demo environment (catalogue, navigation, variants, carts, orders) can be reset in a single command to a clean reference snapshot, used for sales demonstrations without ever touching a real client environment.\u003C\u002Fp>\n\n\u003Ch2 id=\"monitoring-divers\">16. Monitoring, obsolescence and miscellaneous tooling\u003C\u002Fh2>\n\u003Cp>This family covers unit tests for long-running features, a test bridge to the sandbox database environment, an annotated documentary-plate engine, and strict segregation of a legacy system's credentials (never a secret shown in plaintext, an explicit split between what is showable and what stays put away). A signing tool stamps a scanned signature onto a PDF document by always writing a \u003Cstrong>new\u003C\u002Fstrong> file, never touching or sending the original.\u003C\u002Fp>\n\u003Cp>Destructive version-control tests are systematically isolated in a disposable workspace, never run on the repository's main line.\u003C\u002Fp>\n\u003Ch3>Bespoke 3D configurator\u003C\u002Fh3>\n\u003Cp>An end-to-end pipeline turns a reference image (moodboard, sketch) into a usable 3D object: view extraction, multi-view 3D mesh generation, geometric-zone colorization, then export to a standard format consumable by a web viewer. A parametric variant generates furniture from geometric primitives or from a free-text description, with a \"manufacturing-ready\" dimensioned plan and automated geometric QA (mesh watertightness, symmetry) before delivery.\u003C\u002Fp>\n\n\u003Ch2 id=\"hooks-gouvernance\">17. Real-time governance — session guard-rails\u003C\u002Fh2>\n\u003Cp>The harness enforces much of its doctrine not through documentation alone, but through \u003Cstrong>automatic checks fired in real time\u003C\u002Fstrong> before and after every AI agent action — file edit, shell call, read, network call, sub-agent invocation, session end. These checks form a second line of defense that does not depend on the agent's good intentions at the moment of the action.\u003C\u002Fp>\n\u003Cp>Among the most significant mechanisms: blocking any email send outside the single facade; blocking any attempt by the AI to trigger a direct production release (the real release command stays strictly human); blocking the pasting of plaintext secrets or uncontrolled bulk file staging into a commit; requiring a clean antivirus verdict before any attachment is opened; blocking a raw database query that would reference a column not declared in the canonical schema; evaluating a registry of learned rules before a file edit, read, network call or sub-agent invocation; a mandatory structuring nudge as soon as a piece of work exceeds the scope of a simple one-off fix.\u003C\u002Fp>\n\u003Cp>A specific check forbids the agent from \u003Cstrong>asking a validation question in chat\u003C\u002Fstrong> for an email send — doctrine requires creating the draft directly through the dedicated facade, whose internal review copy already serves as the validation step; asking the question would bypass that circuit. Another guard-rail, specific to the household-assistant product, blocks any code change touching a household's purchasing identity unless it explicitly carries that household's identifier in its immediate vicinity — to prevent one household's identity from ever leaking into another's.\u003C\u002Fp>\n\u003Cp>At the end of every session, a closing check verifies the working tree stays clean (nothing significant left uncommitted), logs the incidents detected during the turn that just ended, and refuses to let it appear that a production release happened when it was actually blocked by the corresponding guard-rail.\u003C\u002Fp>\n\n\u003Ch2 id=\"fiabilite\">18. Reliability notes\u003C\u002Fh2>\n\u003Cp>This catalogue is generated and re-verified through a mixed process: automatic extraction from the real source code, followed by a targeted adversarial reread that checks every claim in the catalogue against the system's actual state (real scheduling, real wiring of checks, real code behavior) rather than against what the previous documentation asserted. Every correction found is logged with its source, so the reliability trail itself stays auditable.\u003C\u002Fp>\n\u003Cp>As a matter of transparency: information that is inferred rather than directly verified is flagged as such rather than presented with false certainty, and a known coverage limit (for example a guard-rail mechanism that does not yet cover an entire family of actions) is named explicitly rather than hidden.\u003C\u002Fp>\n",{"slug":14,"chapterNum":15,"title":16,"titleEn":17},"deploy","09","Déploiement & infrastructure","Deployment & infrastructure",{"slug":19,"chapterNum":20,"title":21,"titleEn":22},"skills-hooks","11","Skills, agents & hooks — harness agentique Synedre OS","Skills, agents & hooks — Synedre OS agentic harness",{"chapters":24},[25,32,39,46,53,60,67,74,81,84,85],{"slug":26,"chapterNum":27,"title":28,"titleEn":29,"summary":30,"summaryEn":31},"overview","01","Vue d'ensemble du harness agentique","Agentic harness overview","Le harness transforme une demande (courriel, console, cron) en action déployée en enchaînant classification, spawn LLM via pseudo-TTY, validation qualité à deux niveaux et boucle d'apprentissage, le tout sans état métier hors base de données.","The harness transforms a request (email, console, cron) into a deployed action by chaining intent classification, pseudo-TTY LLM spawn, two-level quality validation, and a learning loop — with no business state stored outside the database.",{"slug":33,"chapterNum":34,"title":35,"titleEn":36,"summary":37,"summaryEn":38},"data-layer","02","La couche données","The Data Layer","Décrit l'architecture données de Synedre OS : une base PostgreSQL unique (un composant interne\u002Fun composant interne), les trois chemins d'accès (Nuxt\u002FNitro, Python agentique, Drizzle ORM DDL), les familles de tables par préfixe et les conventions de nommage associées.","Describes the Synedre OS data architecture: a single PostgreSQL database (un composant interne\u002Fun composant interne), the three access paths (Nuxt\u002FNitro, agentic Python, Drizzle ORM DDL), the table families by prefix, and the associated naming conventions.",{"slug":40,"chapterNum":41,"title":42,"titleEn":43,"summary":44,"summaryEn":45},"agentic-core","03","Le cœur agentique : Atlas et les agents","The Agentic Core: Atlas and the Agents","Décrit l'architecture du moteur agentique : classification LLM des emails entrants, spawn headless de Claude Code via pseudo-TTY, injection des personas agents et orchestration post-spawn (deploy, QA, récap).","Describes the architecture of the agentic engine: LLM classification of incoming emails, headless spawning of Claude Code via pseudo-TTY, injection of agent personas, and post-spawn orchestration (deploy, QA, recap).",{"slug":47,"chapterNum":48,"title":49,"titleEn":50,"summary":51,"summaryEn":52},"chantiers","04","Chantiers, travaux & tâches — modèle de données et API","Worksites, Jobs & Tasks — Data Model and API","Décrit la hiérarchie chantier\u002Ftravail\u002Ftâche de Synedre OS, le modèle de données DB, les statuts\u002Fscopes canoniques et l'API Python associée.","Describes the worksite\u002Fjob\u002Ftask hierarchy in Synedre OS, the DB data model, canonical statuses\u002Fscopes, and the associated Python API.",{"slug":54,"chapterNum":55,"title":56,"titleEn":57,"summary":58,"summaryEn":59},"automates","05","Automates, crons & runs","Automations, crons & runs","Décrit la couche d'exécution non-conversationnelle de Synedre OS : les 209 façades Python, leur enrobage cron, le registre un composant interne et la frontière entre doctrine run et unité agent.","Describes the non-conversational execution layer of Synedre OS: the 209 Python facades, their cron wrapper, the un composant interne registry, and the boundary between run doctrine and agent unit.",{"slug":61,"chapterNum":62,"title":63,"titleEn":64,"summary":65,"summaryEn":66},"hub","06","Le Hub (\u002Fhub\u002F*)","The Hub (\u002Fhub\u002F*)","Présentation de l'interface d'administration privée Synedre OS (mothership-app), son architecture en couches Nuxt, la carte de ses modules et pages, ainsi que le système d'authentification et de session.","Presentation of the Synedre OS private administration interface (mothership-app), its Nuxt layered architecture, the map of its modules and pages, as well as the authentication and session management system.",{"slug":68,"chapterNum":69,"title":70,"titleEn":71,"summary":72,"summaryEn":73},"email","07","Inbox hub & Atlas Inbox — deux pipelines email","Inbox hub & Atlas Inbox — two email pipelines","Décrit les deux pipelines IMAP→DB du harness (contact@ trié pour le hub, atlas@ déclencheur d'actions agentiques), la façade d'envoi sortant et les doctrines bloquantes associées (scan AV, zéro contact client direct).","Describes the two IMAP→DB pipelines of the harness (contact@ sorted for the hub, atlas@ triggering agentic actions), the outbound sending facade, and the associated blocking doctrines (AV scan, zero direct client contact).",{"slug":75,"chapterNum":76,"title":77,"titleEn":78,"summary":79,"summaryEn":80},"memory","08","Mémoire & apprentissage — architecture à trois niveaux","Memory & Learning — Three-Level Architecture","Ce chapitre décrit les trois niveaux de mémoire du harness Synedre OS (réflexe, Zettelkasten, vectoriel pgvector), les automates d'indexation associés et la boucle de capitalisation des erreurs en règles réutilisables.","This chapter describes the three memory levels of the Synedre OS harness (reflex, Zettelkasten, vector pgvector), the associated indexing automata, and the loop for capitalizing errors into reusable rules.",{"slug":14,"chapterNum":15,"title":16,"titleEn":17,"summary":82,"summaryEn":83},"Décrit le pipeline de mise en ligne Synedre OS : asymétrie entre .\u002Fdeploy (IA, preprod) et .\u002Fship (Alex, production), le dispatcher YAML, le pattern build-host sans build VPS, et les règles associées (secrets, commit-avant-deploy, drift, smoke).","Describes the Synedre OS release pipeline: asymmetry between .\u002Fdeploy (AI, preprod) and .\u002Fship (Alex, production), the YAML dispatcher, the build-host pattern without build VPS, and the associated rules (secrets, commit-before-deploy, drift, smoke).",{"slug":5,"chapterNum":6,"title":7,"titleEn":8,"summary":9,"summaryEn":10},{"slug":19,"chapterNum":20,"title":21,"titleEn":22,"summary":86,"summaryEn":87},"Décrit le câblage complet du harness Claude Code de synedre-os : skills disponibles, sous-agents délégables et hooks d'événements qui imposent la doctrine commit-en-flux, garde-fous prod\u002Femail et injection mémoire.","Describes the complete wiring of the synedre-os Claude Code harness: available skills, delegatable sub-agents, and event hooks that enforce the commit-in-flow doctrine, prod\u002Femail guardrails, and memory injection."]