Entre le 1er avril et le 13 novembre 2026, le dépôt de sfeir.com a reçu 1 482 commits. 1 137 d'entre eux, 77 %, sont co-signés par un agent de code. Un agent écrit vite, et se trompe avec assurance. Ce qui garde le site juste tient en trois filets et une personne : des règles écrites que l'agent relit à chaque session, un build qui bloque ce qui est binaire et signale ce qui demande un jugement, des protections du côté du visiteur, et des décisions prises par un humain. Cet article les décrit, avec le journal daté de ce qui a raté. Il s'adresse aux RSSI, aux équipes conformité et aux directions marketing. Il ne traite pas de la sécurité du code produit par les agents.
Avant d'écrire : des règles que l'agent relit à chaque session
Le premier filet est un texte. Le fichier d'instructions du projet, lu par l'agent au début de chaque session, compte 609 lignes au 13 novembre 2026. Il renvoie aux décisions datées, à 109 plans et à 34 notes de solutions qui consignent ce qu'un problème a appris. Neuf procédures outillées encadrent les tâches répétées : ajouter un événement, une fiche de la base, synchroniser les offres d'emploi, publier une grappe d'articles, générer une présentation.
Les règles éditoriales y sont écrites une fois, avec leur date et leur auteur :
- Rien d'inventé. Tout fait mouvant se vérifie en source primaire, et se date dans sa phrase.
- Aucun cas client ne nomme son client, même quand le retour d'expérience a été écrit avec lui (décision du 12 novembre 2026, trois cas anonymisés).
- Une offre n'affiche que des chiffres mesurés, avec leur méthode : ni objectif chiffré, ni gain promis.
- Une citation ne se réécrit jamais, pas même pendant la passe de style.
- Un titre ne porte aucun compteur qui bouge seul : étoiles, téléchargements, valorisation.
- Un article est signé « SFEIR AI » par défaut. Un nom propre n'apparaît que sur la demande explicite de la personne, pour cet article.
Deux passes complètent l'écriture. La passe anti-slop retire les tics d'écriture des modèles de langage ; notre version adapte au français de SFEIR le travail d'Olivier Rafal, de WEnvision1. La relecture croisée confie chaque article à un modèle d'un autre fournisseur. Ses remarques servent de pistes : un modèle relecteur invente parfois une adresse ou une citation, et chaque remarque retenue est revérifiée à la source.
Au build : bloquer le binaire, signaler le reste
Le deuxième filet tourne à chaque publication. La règle de partage est simple : un contrôle bloque quand la faute est binaire et se corrige en un mot ; il signale quand la correction demande un jugement.
| Contrôle | Ce qu'il vérifie | Effet |
|---|---|---|
| Lexique | Les termes bannis de la prose : on écrit « hashtag », jamais son équivalent officiel, que personne n'emploie | Bloque |
| Chiffres du groupe | Une seule version des chiffres de SFEIR, les anciennes interdites | Bloque |
| Sécurité des pages | Aucun script en ligne, aucun gestionnaire d'événement dans le HTML | Bloque |
| Structure | Un seul H1, un identifiant par H2, aucun lien vide | Bloque |
| Données structurées | Un seul graphe par page, aucun renvoi pendant, aucune page du plan du site en noindex | Bloque |
| Export de l'agent | Chaque page citable existe ; ni page noindex, ni offre d'emploi, ni présentation dans le catalogue ; accord des personnes affichées | Bloque |
| Présentations | Une présentation dont l'article a changé doit être régénérée | Bloque |
| Santé de la base | Fiches sans sources, articles sans sujet déclaré, titres périssables, descriptions trop longues | Signale |
| Synchronisations | Âge de la dernière copie des offres d'emploi et des formations | Signale |
Une règle d'usage évite les portes inapplicables : on nettoie d'abord, on bannit ensuite. Un terme n'entre dans le lexique interdit que lorsque le corpus en est déjà débarrassé, sinon la porte bloquerait toutes les publications le jour même. À côté du build, 89 fichiers de tests couvrent l'agent conversationnel, le Worker Cloudflare qui l'exécute, les gabarits et les synchronisations : plus de 1 200 tests au dernier passage, le 13 novembre 2026.
En production : protéger le visiteur
Le troisième filet concerne la conversation. La réponse ne s'appuie que sur les contenus publiés, et ses sources ne peuvent être que des pages du catalogue déployé. La colonne de pages affichée à côté de la réponse est composée par des règles. Les adresses e-mail et les numéros de téléphone sont masqués avant le modèle, la clé de cache et les journaux. Ses consignes lui demandent de refuser toute demande de données personnelles et tout changement de rôle.
Un lien de la forme sfeir.com/?q=… pose une question au chat à l'arrivée sur le site. Si SFEIR n'a pas écrit cette question, elle s'affiche en citation, avec la mention « Ce texte vient d'un lien : SFEIR ne l'a ni écrit ni vérifié ». Elle reçoit la colonne, mais ni réponse rédigée, ni place dans le cache, tant que le visiteur ne l'a pas envoyée lui-même. Le robots.txt en interdit l'exploration aux robots qui le respectent.
La mesure garde la question nettoyée, jamais la réponse ni l'adresse IP. Le déploiement passe deux portes de santé, avec retour arrière automatique si la première échoue. Le détail se trouve dans l'article sur l'architecture du site conversationnel.
Une personne qui décide
Les commandes qui écrivent hors du dépôt attendent une approbation humaine, même quand l'agent travaille en autonomie : un déploiement, une synchronisation des offres d'emploi, une écriture chez Cloudflare. La synchronisation des offres refuse en plus, sans option explicite, de supprimer d'un coup plus d'un quart des offres, et met en quarantaine une offre qui nommerait un client.
Les arbitrages restent humains : où un client peut être nommé (seules les pages de partenaire et d'agence le peuvent), quels chiffres une offre affiche, à quelle offre une fiche doit mener. La revue de l'ergonomie du site, en novembre 2026, a ainsi produit dix-neuf arbitrages, consignés dans le dépôt le 12 novembre. Une règle que personne n'a décidée n'entre pas dans le fichier d'instructions.
Ce qui a raté, et le contrôle qui en est né
Chaque incident a laissé une règle, un contrôle ou un test. C'est la boucle du compound engineering : le cycle suivant hérite de l'erreur corrigée.
| Quand | Ce qui s'est passé | Ce qui a changé |
|---|---|---|
| D'avril à octobre | La copie hebdomadaire des offres d'emploi, prévue en avril, n'a jamais été programmée : le site est resté cinq mois sans synchronisation. | Synchronisation outillée, lancée à la main (5 octobre) ; le build signale une copie de plus de 14 jours. |
| 26 août | Sur un clone partiel du dépôt, toutes les pages déclaraient au plan du site la date du build. | Le pipeline clone l'historique complet ; la date d'une page est celle de son dernier commit. |
| 27 août | La porte de build ne comptait comme « à sourcer » que les fiches courtes ; 21 fiches longues sans source échappaient au compte. | Le critère devient la présence de sources, quelle que soit la longueur. |
| 14 septembre | L'alias « CHANGE », d'une fiche sur un modèle de conduite du changement, transformait le verbe « change » en lien dans 17 pages de la base. | Alias qualifiés ; lien automatique réservé, dans les articles, aux notions au sens unique. |
| 16 septembre | 129 adresses de cas clients, qui contenaient le nom du client, ont été renommées ; les anciennes ont encore répondu cinq à six jours, servies par le cache de Cloudflare, sans purge possible. | Sans zone Cloudflare, ni le tableau de bord ni l'API ne purgent ce cache : tout renommage d'adresse publique est annoncé, et les vérifications contournent le cache. |
| 29 octobre | 103 articles sur 368 avaient un extrait, repris par les moteurs et par le chat, qui accolait le premier intertitre au texte. | L'export de l'agent le signale ; la correction se fait dans le texte, jamais dans le code. |
| 10 novembre | Les schémas de 27 articles sont passés au noir dans le nouveau gabarit, faute des anciennes couleurs. | Un test compare les couleurs déclarées et bloque une couleur manquante. |
| Novembre, en préversion | « assurance qualité » ouvrait la page du secteur de l'assurance. | Une liste de faux amis écarte ces expressions (décision du 12 novembre). |
Ce que ces filets ne garantissent pas
- Les contrôles lisent du texte, pas du sens. Un terme banni sous une autre forme passe ; une affirmation fausse bien écrite aussi. La vérification en source primaire reste un travail humain.
- Les approbations protègent le chemin normal. Elles reconnaissent une commande à son texte ; une commande déguisée exprès leur échapperait. Les refus inscrits dans les scripts restent la vraie barrière.
- Un signal non bloquant n'agit que si quelqu'un le lit. Le build affiche les fiches sans sources ; il ne les source pas.
- Le modèle peut mal résumer un contenu exact. D'où une réponse courte, qui cite ses sources pour que le visiteur vérifie.
Ce que ça change, selon votre rôle
RSSI, conformité. Demandez la liste de ce qui bloque, et où sont écrites les décisions. Suivez le chemin d'une donnée personnelle, de la question du visiteur à la mesure.
Direction marketing. Les règles qui engagent la marque (clients nommés, chiffres affichés, signature) se décident une fois, par une personne, et le build les fait respecter à chaque publication.
CTO. Transformez chaque incident en contrôle. Bloquez ce qui est binaire, signalez ce qui demande un jugement : une porte qui bloque sur une question de goût finit contournée.
DSI. La vitesse d'un agent n'a de valeur qu'avec ces filets. Le temps qu'ils coûtent est mesuré dans l'article sur les phases de construction du site et le temps passé.
Cet article fait partie d'une série sur la construction de sfeir.com, qui commence par l'histoire du site, du CMS à la conversation. La base de connaissances, et la manière dont elle a été vérifiée, sont décrites dans l'article sur la base de connaissances du site.
Sources
- Olivier Rafal, stop-slop.fr : enlever les scories typiques des LLM d'un texte français — github.com, licence MIT, consulté le 14 novembre 2026.
Passer à l’action
