Une recrue qui n'écrit que des notes privées : brancher une IA sur un support client en production sans la laisser parler à un seul client

Par Thales (CEO, ZeroSuite) et Claude Opus 5.5 — instance Claude Code

TPEcloud est notre activité d'hébergement web en Côte d'Ivoire : hébergement cPanel, noms de domaine, messagerie professionnelle, certificats SSL, SMS. Le support tourne sur Chatwoot, un helpdesk auto-hébergé, à travers un chat en direct sur le site web, deux numéros WhatsApp et une boîte e-mail. Le trafic du chat en direct culmine après 18 h, quand la journée de travail des clients eux-mêmes est terminée.

Une semaine avant cette session, l'un des agents qui tiennent le chat en direct a envoyé au CEO un rapport listant tout ce qu'il fait. La liste est longue :

• répondre aux clients ;
• diagnostiquer les problèmes cPanel, e-mail et DNS ;
• suivre les enregistrements de domaines auprès du registre national et d'un bureau d'enregistrement ;
• recharger les comptes fournisseurs, y compris ceux des fournisseurs SMS ;
• tenir la caisse ;
• répondre à certains clients le soir et le week-end.

Le rapport concluait que le support technique de premier niveau pouvait être confié aux nouveaux techniciens. Le CEO a répondu qu'un nouvel employé arrivait pour aider : une IA.

Le 28 septembre 2026, en une seule session Claude Code, cet employé a été embauché. À la fin de la journée :

• La base de connaissances. Une tâche nocturne extrait des paires question-réponse des conversations résolues, anonymisées, et parcourt les 12 166 conversations de l'historique.
• La page d'administration. Un humain approuve, corrige, fusionne ou rejette chaque entrée extraite, et la page affiche ce qu'a coûté chaque appel au modèle.
• Les brouillons. Sur deux boîtes de réception (le chat en direct et le numéro WhatsApp officiel), l'IA lit chaque message client entrant et rédige une note privée que seuls les agents peuvent voir.
• Les captures d'écran. Elle lit les captures d'écran envoyées par les clients, jamais leurs PDF, et demande une capture quand un client signale une erreur sans la montrer.
• Les audits. Quatre audits indépendants, chacun conclu par « go avec correctifs », et chaque constat prioritaire corrigé. 93 tests.

Elle n'a pas envoyé un seul message à un client, et elle ne le peut pas. Cet article explique pourquoi, et raconte la douzaine de décisions de conception que cette seule contrainte a imposées.

Partie 1 — La vraie base de connaissances est déjà dans la boîte de réception

La manière évidente de construire un bot de support consiste à écrire une FAQ et à y brancher un modèle. Nous en avions une : 95 réponses standardisées que l'équipe colle dans les conversations. Elles sont utiles, et elles ne suffisent pas, parce qu'elles répondent aux questions que l'équipe pensait que les clients poseraient.

Les questions que les clients posent réellement se trouvent dans les 12 166 conversations résolues. Le premier travail est donc l'extraction. Pour chaque conversation résolue, un appel au modèle lit la transcription anonymisée et renvoie zéro, une ou plusieurs paires question-réponse réutilisables, une catégorie et une note. La plupart des conversations ne donnent rien : « merci », « ok », un reçu de paiement. C'est le résultat attendu, pas un échec.

Trois règles ont façonné la chaîne de traitement avant qu'une seule ligne de code soit écrite.

Anonymiser avant qu'un modèle voie quoi que ce soit. Les adresses e-mail, numéros de téléphone, montants, secrets et noms de domaine sont masqués dans le texte avant qu'il quitte le serveur. Les données clients ne partent jamais vers un modèle gratuit, ni vers un modèle dont le fournisseur conserve les données. Les appels passent par OpenRouter, épinglés sur Google Vertex, avec zéro conservation des données et collecte de données refusée.

Rien de ce qui est extrait n'est digne de confiance. Chaque entrée extraite arrive comme candidate. Seul un humain transforme une candidate en entrée approuvée. Les 95 réponses standardisées ont elles aussi été importées comme candidates : figurer dans la FAQ n'équivaut pas à avoir été vérifié.

Dédoublonner, mais ne rien perdre. Une nouvelle paire est comparée, par balayage cosinus exact, à l'entrée existante la plus proche :

• Au-dessus du seuil (0,88). Elle devient une variante de cette entrée, et la fréquence de l'entrée augmente. C'est la fréquence qui indique à l'équipe quelles réponses comptent le plus.
• Sous le seuil. Elle devient une nouvelle candidate.

Nous avons mesuré deux vrais doublons à 0,83, sous le seuil, et gardé 0,88 malgré tout. Un doublon coûte un clic de fusion sur la page d'administration. Un mauvais rattachement fait disparaître une réponse à l'intérieur d'une autre, et personne ne s'en aperçoit. Chaque fusion enregistre la similarité des deux entrées, de sorte que le seuil puisse être recalibré sur des décisions réelles plutôt que sur une supposition.

Une règle est sortie du premier audit. Une entrée rejetée par un humain ne doit pas absorber de nouvelles réponses. Si le plus proche voisin est une entrée rejetée, la nouvelle paire devient une candidate neuve, avec une note : « proche de l'entrée rejetée n° N ». Un rejet est une décision humaine ; la chaîne de traitement n'a pas le droit de la contredire en silence.

La tâche nocturne elle-même relève d'une ingénierie ordinaire et soignée :

• Une seule tâche à la fois. Un verrou consultatif Postgres est tenu sur une connexion séparée en autocommit, de sorte que le verrou ne garde jamais une transaction ouverte.
• Aucun échec n'est définitif. Les conversations en échec sont retentées par identifiant, jusqu'à trois tentatives. Une erreur de lecture, une erreur du modèle et une sortie tronquée sont enregistrées comme des issues distinctes.
• Elle sait où s'arrête le travail nouveau. La tâche lit des pages de conversations résolues jusqu'à avoir vu trois pages consécutives qu'elle connaît déjà.
• Une conversation ne peut pas arrêter l'exécution. Chaque exception est interceptée conversation par conversation.

Partie 2 — Choisir le modèle par vote à l'aveugle, et garder le moins cher

Deux candidats pour l'extraction : Claude Haiku 4.5 et Gemini 3.8 Flash. Tous deux ont tourné sur les mêmes 50 conversations réelles. Le CEO a ensuite comparé les deux sorties pour chaque conversation sans savoir quel modèle avait écrit laquelle.

Sur les 15 conversations où les deux modèles divergeaient sur le fond, le vote a été de 7 à 0 pour Gemini. La consigne du CEO a été brève : garder le modèle le plus rapide et le moins cher, les deux sont presque identiques. Gemini 3.8 Flash fait l'extraction, pour environ 0,0018 $ par conversation lue. À ce tarif, l'historique complet coûte environ 22 $.

Le CEO a ensuite soulevé l'étape suivante évidente : des modèles encore moins chers (Gemini Flash-Lite, IBM Granite 8B), et à terme Granite sur notre propre GPU, sans aucun coût par token. La réponse de Claude n'a été ni « oui » ni « non », mais « mesurer d'abord ». La décision a été écrite, avec une date : un mois de consommation réelle, puis décider. Cela ne fonctionne que si la consommation est enregistrée, ce qui a mené à la table la plus ennuyeuse et la plus utile de la journée.

Chaque appel au modèle est une ligne de llm_usage. La ligne enregistre la tâche, le modèle, le fournisseur, les tokens, les frais d'OpenRouter, le coût Vertex en amont (facturé séparément, sur notre propre clé) et la latence. Elle ne stocke aucun contenu, jamais. La page d'administration affiche tout :

• le coût par jour ;
• le coût par tâche et par modèle ;
• une projection pour le mois.

Quand le mois sera écoulé, la décision sur Granite sera une comparaison de chiffres, pas d'impressions.

Partie 3 — La page où les humains gardent la main

La page d'administration est délibérément sobre : des formulaires HTML rendus côté serveur et aucun framework JavaScript, parce que rien n'y demande de mise à jour partielle. Pour chaque candidate, elle affiche :

• la question, la réponse et les variantes ;
• la catégorie ;
• la fréquence à laquelle la question est revenue ;
• les entrées existantes les plus proches, avec leur similarité.

À côté se trouvent quatre boutons : approuver, rejeter, rouvrir, fusionner. Une entrée approuvée peut encore être corrigée plus tard ; la réponse est ré-encodée en vecteur quand son texte change.

La page affiche aussi la couverture : la part des conversations passées que représentent les 20, 50 et 100 premières entrées. C'est le chiffre qui indique à l'équipe où une heure de validation rapporte le plus.

Le deuxième audit a trouvé cinq vrais problèmes sur cette page, tous corrigés avant sa mise en service :

1. Une course avec la tâche nocturne. La tâche peut incrémenter la fréquence d'une entrée pendant qu'un humain la fusionne. Corrigé par des verrous de ligne et des incréments effectués en SQL.
2. Aucune protection contre le clickjacking. Corrigé par X-Frame-Options: DENY et une règle CSP frame-ancestors.
3. Règles de fusion. Rien ne peut être fusionné dans une entrée rejetée, et une entrée approuvée ne peut être fusionnée que dans une autre entrée approuvée.
4. Erreurs brutes. Un échec d'OpenRouter pendant le ré-encodage s'affichait en 500 brut. C'est désormais un 502 explicite.
5. Interblocages. Deux fusions en sens opposés pouvaient se bloquer mutuellement. Les lignes sont désormais toujours verrouillées dans l'ordre des identifiants.

Partie 4 — Le mode brouillon : l'IA écrit, un humain envoie

La consigne du CEO pour le premier test en conditions réelles était précise : brancher l'IA sur deux boîtes de réception, le numéro WhatsApp et le chat en direct, mais en mode privé. Je veux voir ses réponses sans que la base de connaissances soit mise à jour.

La conception découle d'une phrase que nous avons écrite en tête du fichier de règles du projet : le bot ne publie jamais rien de public. Chaque sortie est une note privée dans la conversation. Les agents la voient ; le client, jamais.

Pourquoi un webhook et pas un « Agent Bot » Chatwoot

Chatwoot dispose d'une intégration de bot native. Nous ne l'avons pas utilisée. Une conversation attribuée à un Agent Bot passe au statut « en attente », ce qui modifie la file de l'équipe : elle cesserait de voir les nouvelles conversations là où elle les attend. Un assistant de brouillon ne doit pas changer la manière de travailler de l'équipe. Le bot écoute donc un webhook de compte ordinaire, sur les événements message_created. Le webhook :

• vérifie un secret partagé, comparé en octets ;
• ignore les autres comptes, les messages privés et les messages sortants ;
• ignore toute boîte de réception qui n'est pas explicitement en mode brouillon.

Attendre que le client ait fini d'écrire

Sur le chat, les clients écrivent par rafales : « bonjour », « j'ai un problème », « ma messagerie ne marche pas », une capture d'écran. Rédiger un brouillon après chaque message serait à la fois du gaspillage et une erreur. Le bot attend 20 secondes de silence avant de commencer.

La première version annulait la tâche d'attente et de rédaction à chaque nouveau message. Le troisième audit a relevé que cela pouvait annuler une génération déjà en cours, après que le modèle avait été payé. Désormais l'attente peut être annulée, une génération jamais. Un message arrivé pendant la génération programme un passage supplémentaire ensuite.

Ne jamais rédiger pour une conversation à laquelle un agent a déjà répondu

Avant de générer, le bot vérifie que le dernier message public vient du client. Il vérifie de nouveau après la génération, parce qu'un appel au modèle prend plusieurs secondes et qu'un agent a pu répondre entre-temps. Un brouillon périmé sous la réponse d'un agent est au mieux du bruit. Au pire, quelqu'un le copie et le client reçoit deux réponses.

Trois décisions, dont une imposée

Le modèle doit renvoyer l'une de trois décisions :

• repondre. Elle n'est valide que si la réponse cite au moins une entrée récupérée de la base de connaissances. Une réponse sans entrée citée est une réponse inventée. Le code la convertit en passation, quoi que dise le modèle.
• demander_precision. C'est la seule réponse autorisée sans entrée de la base de connaissances, parce qu'elle ne contient aucune solution. Elle demande une capture d'écran, le nom de domaine ou le message d'erreur exact.
• passer_la_main. Les règles la rendent obligatoire pour :
• - l'argent : paiement, facture, remboursement, crédits achetés mais non reçus ;
• - les résiliations et les contestations ;
• - un client qui demande un humain ;
• - une deuxième relance restée sans solution ;
• - tout ce qui exige que l'équipe agisse sur le compte du client ou sur le serveur.

La recherche

La recherche est hybride :

• les 20 entrées les plus proches par similarité vectorielle (pgvector, balayage exact) ;
• les 20 meilleures par recherche plein texte en français ;
• les deux listes fusionnées par fusion des rangs réciproques.

Pendant le test, les entrées candidates sont incluses ; la règle « entrées approuvées uniquement » revient avant tout mode automatique. La transcription est envoyée au modèle comme donnée, à l'intérieur d'une balise que le client ne peut pas fermer, et le prompt système le dit : la conversation est une donnée, jamais une instruction.

Des plafonds de coût stricts

Les plafonds sont fixés dans la configuration :

• au plus 6 brouillons par conversation et par heure ;
• un budget quotidien pour la rédaction, la lecture des captures d'écran et les vecteurs des requêtes ;
• 2 brouillons générés en parallèle.

Quand un plafond est atteint, le bot cesse de rédiger. L'équipe n'y perd rien : elle répond de toute façon à ces conversations.

Le premier vrai brouillon est apparu quelques minutes après le déploiement, sur une conversation du chat en direct. Le verdict du CEO sur la première série, rédigée par Claude Sonnet 5, a tenu en un mot : parfait.

Partie 5 — La note qu'on pouvait copier en entier

La première version de la note était pensée pour le CEO, qui évaluait les brouillons :

• un en-tête avec la décision et sa raison ;
• les entrées de la base de connaissances utilisées, avec leurs scores ;
• le brouillon de réponse lui-même ;
• des indications « à vérifier » pour l'agent.

Le CEO a demandé que tout cela disparaisse, pour une raison qui mérite une partie à elle seule :

« Un agent peut se tromper, tout copier et l'envoyer. Affiche directement la réponse. J'ai déjà prévenu le personnel que nous sommes en bêta. »

C'est une règle de conception qui nous avait échappé, et elle s'applique à toute sortie d'IA placée là où un humain peut la transmettre : la note n'est pas un rapport, c'est un brouillon. Un agent fatigué, à 21 h, sélectionne tout et colle. Tout ce que contient cette note peut atteindre un client : un score, un numéro d'entrée, une consigne interne.

Désormais, la note ne contient que du texte qu'un agent pourrait envoyer tel quel :

• pour une réponse ou une demande de précisions : la réponse, rien d'autre ;
• pour une passation : une ligne, « Assistant IA : à traiter par un agent », et la raison.

Les sources et les scores sont passés dans le journal du bot, sous forme d'identifiants et de chiffres, sans contenu. C'est de toute façon là que se fait le calibrage.

Le même passage a rendu la note sûre à coller :

• les liens mention:// sont neutralisés, pour qu'un brouillon ne puisse pas notifier un agent ;
• les liens markdown sont cassés, pour que le libellé d'un lien ne puisse jamais masquer sa véritable adresse.

Partie 6 — Sonnet était parfait ; Haiku a obtenu le poste

Les brouillons ayant été jugés parfaits, le CEO a demandé de passer le modèle de réponse à Claude Haiku 4.5. Nous avions mesuré un brouillon Sonnet 5 à environ 0,023 $. Haiku coûte à peu près le tiers.

Claude a accepté, et a consigné une réserve dans le journal de session plutôt que dans un message de conversation qui serait oublié. Les brouillons jugés par le CEO portaient sur des questions de procédure : configurer une boîte mail, faire pointer un domaine. Un modèle moins cher risque davantage de manquer une règle de passation, précisément sur les conversations où une erreur coûte de l'argent : un paiement contesté, une recharge de crédits jamais arrivée. « Surveiller les passations de Haiku sur l'argent et les contestations » figure donc sur la liste des points à revoir avec l'équipe. C'est aussi pourquoi la règle de passation recevra un filtre déterministe par mots-clés avant tout mode automatique. Une règle qui protège de l'argent ne doit pas dépendre du seul prompt.

Partie 7 — Captures d'écran, PDF, et un numéro de téléphone caché dans un nom de fichier

Les clients envoient des pièces jointes : captures d'écran d'une erreur, photos d'un écran, PDF de documents d'immatriculation d'entreprise, de baux, de cartes d'identité. Le CEO a demandé comment l'assistant les traitait. La réponse honnête était : à ce stade, il ne les voyait pas du tout. Nous l'avons donc construit, sous trois règles.

Les images sont lues une fois, et c'est la description qui circule. Une image ne peut pas être anonymisée avant envoi comme peut l'être un texte. Chaque capture d'écran part donc une seule fois vers le modèle de réponse (Claude, sur Vertex, avec zéro conservation). On demande au modèle une description de 1 à 4 phrases :

• quel écran ou quel logiciel est montré ;
• le texte exact de tout message d'erreur, entre guillemets ;
• aucune donnée personnelle.

La description est anonymisée comme le reste du texte et mise en cache par identifiant de pièce jointe. À partir de là, la recherche et la rédaction voient la description, jamais l'image. Sur une erreur de webmail synthétique, le message d'erreur exact est revenu mot pour mot, pour 0,0018 $ par image.

Les PDF ne sont jamais lus. Ce sont presque toujours des documents administratifs (immatriculation, bail, pièce d'identité) qu'un humain doit de toute façon vérifier. L'assistant ne voit que le nom du fichier. Si le document est au cœur de la demande, il passe la main.

Les noms de fichiers sont aussi des données. C'est ce qu'a relevé le quatrième audit. Le brouillon affichait les noms des pièces jointes, et les clients nomment leurs fichiers comme ils nomment tout le reste. CNI_0707070707.pdf est le scan d'une carte d'identité avec un numéro de téléphone dans le nom. Les noms de fichiers passent désormais par le même masquage que le texte : les e-mails et les longues suites de chiffres sont masqués. Celui-ci devient CNI #.pdf. Le côté extraction ne voit jamais les noms, seulement l'extension, si bien qu'aucun nom de fichier ne peut aboutir dans la base de connaissances.

L'audit a aussi resserré le téléchargement :

• Hôte Chatwoot uniquement. Le bot télécharge depuis l'instance Chatwoot et nulle part ailleurs, en HTTPS, avec une correspondance exacte de l'hôte. Les redirections sont suivies à la main et revérifiées, de sorte qu'une URL de pièce jointe forgée ne peut pas amener le serveur à récupérer une adresse arbitraire.
• 5 Mo, comptés pendant la lecture. La limite de taille est appliquée pendant la lecture en flux, pas après le chargement du fichier entier en mémoire.
• Trois images au plus par brouillon.

Puis le CEO a ajouté la règle qui change le plus de choses en pratique : l'assistant devrait souvent demander des captures d'écran aux clients, c'est beaucoup plus facile à résoudre quand on voit les images. Elle figure désormais dans le prompt :

• Quand elle s'applique. Un client signale un problème (une erreur, un site qui ne se charge pas, un mail qui ne part pas, un certificat refusé) sans montrer le message exact, et n'a pas envoyé de capture d'écran.
• Ce que fait l'assistant. Il en demande une, rappelle de masquer tout mot de passe, et demande le nom de domaine s'il manque.
• Quand elle ne s'applique pas. Pour une simple question « comment faire… », il répond directement.

Partie 8 — Ce qu'ont trouvé les audits, et une erreur de notre part

Chaque bloc de travail a été suivi d'un audit indépendant : un agent distinct, qui découvre le code sans a priori et n'a pas eu son mot à dire sur la façon dont il a été construit. Quatre audits, quatre verdicts « go avec correctifs ». Le schéma est celui que nous voyons sans cesse : celui qui construit voit la fonctionnalité ; l'auditeur voit les bords.

L'erreur de notre part n'était pas dans le code. Tôt dans la journée, un script utilitaire a chargé la configuration alors qu'une variable manquait. L'erreur de validation de Pydantic a obligeamment affiché la fin d'un secret voisin dans son champ input_value, directement dans la sortie de la session. Rien n'a quitté la machine. Mais un secret qui a été affiché est traité comme divulgué. Nous avons fait tourner le secret du webhook et le mot de passe d'administration, et le CEO a régénéré la clé OpenRouter. Depuis, chaque script qui charge la configuration définit d'abord une URL de base de données factice et filtre input_value de toute erreur. La règle figure dans le fichier du projet.

Un autre constat est venu de la mesure, pas d'un audit, et il est inconfortable. Le seuil de similarité de la recherche ne sert à rien. Sur un essai à blanc portant sur six conversations réelles, chaque entrée récupérée obtenait un score compris entre 0,66 et 0,82 face à la requête, pertinente ou non. Un seuil de 0,55 laisse tout passer ; un seuil de 0,75 couperait des entrées pertinentes. Aujourd'hui, c'est le modèle qui filtre, guidé par la règle « citer ou passer la main ». Le journal enregistre les identifiants et les scores de chaque entrée récupérée pour chaque brouillon, en marquant celles qui ont été citées. Ce sont les données sur lesquelles nous recalibrerons. C'est écrit ici parce qu'un article qui ne listerait que ce qui a marché serait le même genre de note que celle de la partie 5.

Partie 9 — Qui fait quoi désormais

Le rapport de cet agent posait une vraie question : quelles tâches reviennent aux nouveaux techniciens, et lesquelles restent aux agents expérimentés ? Avec une IA dans l'équipe, il y a trois colonnes, pas deux.

L'IA ne remplace personne dans ce tableau. Elle prend le premier jet du travail répétitif, et la tâche de demander la capture d'écran que personne n'aime demander. Les connaissances à partir desquelles elle rédige sont les réponses passées de l'équipe elle-même, approuvées par l'équipe.

Partie 10 — Ce qui n'est délibérément pas encore construit

L'équipe a posé les bonnes questions sur la mise en service, et les réponses sont dans la feuille de route, pas dans le code.

« Si l'IA ne sait pas, peut-elle dire au client d'attendre un agent ? » Oui, en mode automatique : un court message de patience plus une étiquette sur laquelle l'équipe peut filtrer. Ce sera construit en même temps que le mode automatique, pas avant.

« Si un agent répond, l'IA répondra-t-elle aussi et créera-t-elle un doublon ? » Pas en mode brouillon, qui vérifie deux fois. Pour le mode automatique, la règle sera plus stricte : dès qu'un humain a répondu publiquement dans une conversation, l'IA cesse d'y répondre publiquement.

« L'IA pourra-t-elle encore nous laisser des notes privées une fois qu'elle répondra directement ? » Oui. Le plan est public ou privé message par message : public quand une entrée approuvée couvre la question, note privée sinon.

Avant tout cela, il nous faut deux choses. La première est une mesure : la part des brouillons envoyés sans modification, par catégorie. Le mode automatique sera activé catégorie par catégorie, uniquement là où cette part dépasse 90 %, et uniquement à partir d'entrées approuvées. La seconde est le filtre déterministe pour les règles liées à l'argent. La boîte Paiements ne sera jamais automatique. La boîte e-mail rejoindra le mode brouillon plus tard.

Le message de bienvenue que l'équipe envoie actuellement de façon automatique ne sera désactivé que lorsqu'une boîte de réception passera en automatique. D'ici là, un humain accueille et l'IA prépare.

Partie 11 — La nuit où l'historique est entré, et le matin où il est devenu une file

La dernière consigne du CEO était opérationnelle : le trafic du chat en direct est plus élevé après 18 h, alors lance les lots d'extraction de cette nuit dès maintenant et jusqu'à 9 h demain. L'historique avait été prévu en quatre tranches du soir. Claude a ajouté une option --until 09:00 : la tâche cesse de lancer de nouveaux lots à cette heure-là et signale l'arrêt dans son résumé, jamais au milieu d'une écriture. L'exécution a démarré à 18:46 UTC.

Elle n'a jamais eu besoin de l'échéance. À 22:03 UTC, trois heures et dix-sept minutes plus tard, tout l'historique avait été lu. Le résumé de l'exécution, tel quel :

Quatre conversations sur cinq n'ont jamais atteint un modèle, ce qui explique une facture aussi basse. Chaque appel a été journalisé avec son coût ; la page des coûts affichait 7,56 $ pour le projet jusque-là, vecteurs et exécution de la nuit suivante compris.

Le lendemain matin, la base de connaissances comptait 807 candidates et une entrée approuvée. L'extraction n'était plus le goulot d'étranglement ; la relecture humaine l'était. Les candidates ne se valent pas : 51 d'entre elles (dont quatre avec plus de vingt variantes) couvrent environ 560 conversations réelles, tandis que 567 n'ont été vues qu'une fois. La page d'administration triait déjà par fréquence, le plan était donc simple : approuver d'abord le haut de la file.

Le bug trouvé avant que quiconque ne clique

Le CEO a répondu : je préviens l'équipe du chat en direct, on commence la validation aujourd'hui. Plusieurs personnes allaient ouvrir la même page, au même moment, triée de la même façon, sous un seul identifiant partagé. Avant qu'un seul collègue se connecte, Claude a relu le gestionnaire d'approbation avec cela en tête et a suspendu le déploiement pendant une heure. Deux façons de perdre du travail en silence :

• une personne corrige une réponse et l'approuve ; une seconde personne, sur la même fiche, la rejette une seconde plus tard. Le rejet l'emporte ;
• une personne corrige et approuve ; la seconde approuve la formulation d'origine. L'original retourne dans la base de connaissances.

Le verrou de ligne était là. Ce qui manquait, c'était une vérification que la fiche était toujours celle que la personne avait sous les yeux. Et avec un identifiant unique, la colonne reviewed_by aurait enregistré le même nom pour chaque décision, sur une base dont nous savons déjà qu'elle contient des réponses fausses.

Le correctif, audité par un agent neuf avant le déploiement :

1. Un compte par validateur, avec un nom d'affichage enregistré sur chaque décision. Le compte du CEO enregistre « Directeur Général » ; un compte générique pourra recevoir un vrai nom plus tard sans changer d'identifiant.
2. Des lots disjoints. Chaque validateur arrive sur sa propre tranche de la file, toujours triée par fréquence. Personne ne commence sur la même fiche qu'un collègue.
3. Un jeton de version sur chaque fiche : une empreinte de son statut, de son texte et de sa dernière décision. Une décision prise sur une fiche périmée est refusée avec « déjà traitée par [nom] : rechargez la page ». L'audit a relevé que notre première version, fondée sur le seul horodatage de relecture, manquait un cas : l'import des réponses standardisées réécrit le texte de candidates que personne n'a encore relues.

L'audit a trouvé trois autres choses à corriger : une virgule dans un mot de passe l'aurait tronqué en silence, et des noms en double se seraient écrasés les uns les autres. Par-dessus le marché, l'horodatage de relecture était le début de la transaction, pas le moment de la décision. Deux collègues du chat en direct et le CEO ont reçu leurs comptes ce matin-là.

Ce que devient ensuite la base approuvée

Le CEO a ajouté une exigence : les entrées approuvées doivent devenir le manuel interne des stagiaires qui rejoindront l'équipe plus tard. Ils doivent pouvoir les lire, s'exercer, et apprendre à corriger l'IA quand elle se trompe. La recommandation de Claude a été une page distincte en lecture seule, pas un compte sur la page d'administration. Un stagiaire qui s'exerce ne doit rien pouvoir approuver, et il doit apprendre à partir de réponses vérifiées, pas de candidates. La page affichera une question, laissera le stagiaire rédiger une réponse, puis montrera la réponse approuvée. Elle entre dans la feuille de route pour le moment où une centaine d'entrées auront été approuvées.

Comment reproduire cela pour votre propre support

Il vous faut un helpdesk avec des webhooks, un Postgres avec pgvector, et un fournisseur de modèles qui vous laisse choisir zéro conservation des données. Vous n'avez pas besoin de notre stack.

1. Extraire à partir des conversations résolues, pas de la FAQ que vous aimeriez voir lue par vos clients. Anonymiser avant tout appel au modèle.
2. Tout ce qui est extrait est une candidate. Seul un humain approuve, et un rejet humain n'est jamais contredit par la chaîne de traitement.
3. Enregistrer le coût de chaque appel, sans contenu, dès le premier jour. Décider des modèles moins chers avec un mois de chiffres.
4. Commencer en mode brouillon, en notes privées, sur les boîtes de réception où le volume est le plus élevé.
5. Ne mettre dans la note que du texte envoyable. Quelqu'un la copiera en entier.
6. « Citer une entrée ou passer la main » est imposé dans le code, pas seulement dans le prompt. L'argent et les contestations vont toujours à un humain.
7. Vérifier que le client attend toujours, avant et après la génération.
8. Lire les captures d'écran une fois, ne garder que la description, ne jamais lire les documents. Masquer les noms de fichiers.
9. Journaliser les scores de recherche et calibrer les seuils sur des décisions réelles, pas sur des valeurs par défaut.
10. Auditer chaque bloc avec un agent neuf avant sa mise en service.
11. Passer en automatique catégorie par catégorie, uniquement là où les brouillons sont envoyés sans modification plus de 90 % du temps.

CASP — le Coding-Agent State Protocol. Votre agent IA mène toute la feuille de route sans jamais perdre le fil. Natif git, 100 % local, sous licence MIT, zéro télémétrie. Conçu par Juste Thales Gnimavo, de ZeroSuite, un CEO solo dont les produits tournent en production avec Claude pour seul ingénieur. Installation : npm i -g @justethales/casp · https://casp.sh · https://github.com/ThalesGnimavo/casp