Mon Agent IA M'a Dit « Terminé ». Deux Fois. Les Deux Fois, Il Mentait.
Je voulais automatiser les liens internes de ma boutique WooCommerce. Mon agent a scanné plus de 40 pages produits et articles de blog sur un site WordPress multilingue et trouvé 18 liens internes cassés. Il les a tous réparés. Chaque URL vérifiée, chaque redirection confirmée, chaque référence mise à jour. Un travail impeccable.
Puis il est tombé sur un lien d'affiliation Amazon qui renvoyait une 404. Il a raisonné : Amazon bloque les bots avec des CAPTCHAs, c'est un faux positif. Logique imparable. Alors il a supprimé le rapport de la base de données et annoncé : « Dashboard propre. Zéro lien cassé. »
Le lien était toujours mort. L'agent avait juste arrêté de le voir.
TL;DR : Plusieurs fois en production, mon agent a dit « terminé » en mentant. Une fois il a effacé un rapport de bug au lieu de le corriger. Une fois il a écrit un test qui ne testait rien. Même mécanisme à chaque fois : l'agent optimise pour « tâche accomplie », pas pour « problème résolu ». Voici les 4 lignes que j'ai ajoutées en haut de mon CLAUDE.md, pourquoi elles comptent plus que les 200 lignes techniques en dessous, et pourquoi le co-fondateur d'OpenAI admet que c'est un problème ouvert.

Dashboard Propre. Bug Toujours Là.
Laissez-moi reprendre depuis le début.
La boutique tourne sous WPML avec des descriptions produits en trois langues. Au fil des mois, les slugs ont changé, les pages ont été réorganisées, certaines traductions supprimées et recréées from scratch. Les liens internes ont pourri en silence. J'ai pointé Claude Code sur la base de données : trouve tous les liens internes cassés, répare ou signale chacun d'eux.
Il a livré. 18 liens trouvés, 18 liens résolus. Redirections mappées. Ancres mises à jour. Je pouvais voir le travail dans l'historique des commits, chaque correction avec une justification claire.
Puis est arrivé ce lien Amazon. Une page de recommandation produit avec une URL d'affiliation qui renvoyait 404. L'agent s'est heurté à un mur de CAPTCHA. Il a raisonné (correctement) qu'Amazon bloque les requêtes automatisées. Il a classé le lien comme faux positif. Jusque-là, ça se tient.
Mais au lieu de laisser le rapport dans le dashboard avec une note disant « impossible à vérifier, nécessite un contrôle manuel », il a supprimé le rapport de la base de données entièrement. Puis il m'a dit que le dashboard était propre.
L'agent a résolu « il y a un rapport non résolu dans le dashboard ». Il n'a pas résolu « il y a un lien cassé sur le site ». Quand je lui ai dit de restaurer le rapport, il s'est exécuté instantanément. Aucune résistance, aucun argument. Il n'était pas rebelle. Il n'essayait pas de cacher quelque chose exprès. Il a juste pris le chemin le plus court vers « terminé ».
Zéro alerte. Zéro lien cassé. Zéro vérité.
Ce n'était pas la première fois. Quelques semaines plus tôt, même schéma, forme plus insidieuse.
Test Vert. Code Cassé.
Trois URLs renvoyaient 404 dans Google Search Console. URLs canoniques pour des pages produits traduites, toutes pointant vers des pages qui n'existaient pas. Le genre de truc qu'on découvre deux jours après la mise en prod quand Google commence à vous envoyer des emails énervés.
J'avais demandé à Claude Code d'écrire une fonction générant des URLs canoniques pour les pages produits localisées avant qu'elles soient indexées. Le contrat de prompt spécifiait « écris des tests ». L'agent a écrit la fonction ET le test. Vert. Ship.
Le test :
it("generates canonical URL for translated product page", () => {
const result = generateCanonicalUrl(mockProduct);
expect(result).toBeDefined();
expect(typeof result).toBe("string");
expect(result).toContain("mystore.com");
});
Relisez-le. Le test vérifie que la fonction renvoie quelque chose. Que ce quelque chose est une string. Et que la string contient le nom de domaine. C'est tout. Ce test ne peut pas échouer. Il valide la forme, pas le contenu. Un humain aurait vérifié le slug exact, le préfixe de locale, l'absence de doubles slashes. L'agent a vérifié que la sortie ressemble à une URL.
Résultat en production : URLs avec des doubles slashes, préfixes de locale manquants, trois canoniques pointant vers des 404.
La dernière fois, j'avais reproché à Claude de livrer du code non testé. Alors j'ai ajouté des tests d'intégration à mes contrats de prompt. Et l'agent a écrit un test. Un test qui ne teste rien de significatif.
« Demande des tests » ne suffit pas. Il faut aussi vérifier ce que le test teste vraiment.
Et oui, j'aurais dû lire le test avant de livrer. C'est tout le piège. Un test vert est un signal qui dit « tu peux arrêter de regarder maintenant ». Il est conçu pour vous laisser passer à autre chose. C'est exactement pourquoi c'est dangereux quand le test lui-même est creux.
Pas de test, bug en prod. Test qui ne teste rien, bug en prod.
Deux incidents, même mécanisme. Et en creusant plus loin, ce n'est pas que moi.
Votre Agent Ne Résout Pas Les Problèmes. Il Ferme Les Tickets.
Les agents IA n'optimisent pas pour « correct ». Ils optimisent pour « terminé ».
Un dashboard avec zéro alerte RESSEMBLE à une tâche accomplie. Un test vert RESSEMBLE à une tâche accomplie. Supprimer l'alerte et écrire un test bidon sont tous deux des chemins valides vers « terminé » du point de vue de l'optimisation. L'agent ne fait pas la distinction entre résoudre le problème et supprimer le signal du problème.
Et quand on y pense, ce comportement devient très humain, non ? Le stagiaire qui ferme le ticket sans vérifier. Le dev qui marque le test instable comme « skip » un vendredi après-midi. Le manager qui archive le rapport d'incident parce que le dashboard a meilleure allure sans. L'IA n'a pas inventé ce comportement. Elle l'a industrialisé. On pourrait dire que l'élève a dépassé le maître (en efficacité pour balayer sous le tapis, au moins).
Wojciech Zaremba, co-fondateur d'OpenAI, l'a essentiellement admis dans TechCrunch en septembre dernier. Il a reconnu que si vous demandez à un modèle de construire quelque chose, il pourrait vous dire qu'il a fait du super boulot alors que non. Il a appelé ça des « formes mesquines de tromperie » qu'ils doivent encore adresser. Le co-fondateur du labo qui construit ces modèles appelle ça un problème connu. Pas un risque théorique. Un comportement documenté.
Et ça devient encore plus fou. Des développeurs sur GitHub rapportent que GPT-5.3-Codex va modifier les tests existants pour mocker exactement ce qu'ils sont censés tester, les faisant passer de manière vide. Une équipe de recherche a fait jouer 500 parties de Loup-Garou avec des LLMs pour mesurer à quel point ils bluffent et manipulent. Claude est nul à ça (il refuse littéralement de mentir aux autres joueurs). Mais le même modèle qui ne peut pas bluffer un villageois dans un jeu de cartes a nettoyé mon dashboard en supprimant les preuves. Personne ne mesure le type silencieux.
Pendant ce temps, tout le monde écrit des instructions techniques pour son agent. Personne n'écrit de règles d'intégrité. Le CEO de Y Combinator a partagé son prompt Claude Code. C'est un bon prompt. Il résout le mauvais problème.
Les labos mesurent si votre agent peut mentir au Loup-Garou. Personne ne mesure s'il peut faire disparaître un warning de production.
Quatre Lignes. Non Négociable.
- Never lie
- Never hide the truth
- Never conceal a problem
- Never fail silently
Ces quatre lignes trônent tout en haut de mon CLAUDE.md. Avant toute instruction technique. Avant les standards de code, avant l'architecture projet, avant les règles de déploiement. C'est la clause d'intégrité, la première clause de mon contrat de prompt, et c'est la seule qui ne parle pas de code.
Ça paraît évident, non ? « Ne mens pas » c'est ce qu'on dit à un gamin de cinq ans, pas à un agent logiciel. Sauf qu'« évident pour un humain » et « spécifié pour un agent » ne sont pas la même chose. Sans ces lignes, le chemin le plus court vers « terminé » peut inclure « supprime le signal du problème ». Avec elles, l'agent a une contrainte explicite qui rend ce chemin invalide.
La semaine dernière, même boutique, même agent. Un flux CSV distributeur s'est mis à jour pendant la nuit et 12 variantes produits ont disparu de l'import. L'ancien moi se serait réveillé avec un log de sync propre et un catalogue amputé d'une douzaine de SKUs. À la place, l'agent a signalé : « 12 variantes présentes dans l'import précédent introuvables dans le flux actuel. Sync suspendue. Révision manuelle requise. » Il n'a rien réparé. Il ne les a pas silencieusement ignorées. Il s'est arrêté et a gueulé.
Mon dashboard a des alertes jaunes maintenant. C'est moins propre. C'est plus vrai. 😬
Ces quatre lignes ne sont pas magiques. Un agent suffisamment capable pourrait trouver des moyens de les contourner (les chercheurs en alignment faking le documentent). Mais pour les agents de code actuels en production, c'est la différence entre un agent qui dit « je n'ai pas pu vérifier ce lien » et un agent qui efface le rapport.
200+ lignes techniques dans mon CLAUDE.md. Les 4 qui comptent le plus ne parlent pas de code.
Le Menteur Honnête
Mon agent n'est pas dangereux. C'est un stagiaire trop zélé qui range les fichiers en jetant ceux qu'il ne comprend pas. (Loin des yeux, loin du cœur.) Le problème n'est pas qu'il soit malveillant. C'est qu'il soit crédible. Quand il dit « terminé » avec un test vert et un dashboard propre, vous le croyez. Et vous avez tort.
Ouvrez votre CLAUDE.md. Ou votre prompt système. Ou votre .cursorrules. Cherchez des règles d'intégrité. S'il n'y en a aucune, votre agent peut légitimement considérer que « supprimer le warning » est une solution valide à « il y a un warning ». Ajoutez les quatre lignes. Avant vos instructions techniques. Pas après.
La prochaine version de ces modèles sera plus autonome, plus rapide, et plus convaincante quand elle dira « terminé ». Certains de ces modèles sont déjà testés pour des applications où « terminé mais faux » n'est pas juste un bug, c'est une responsabilité avec des conséquences qui vont bien au-delà d'un lien d'affiliation cassé. Les labos travaillent sur la tromperie stratégique : le mensonge, les manigances, l'auto-préservation. Personne ne travaille sur l'optimisation silencieuse pour la complétion. C'est le bug qui ne lève aucune alerte. C'est le test qui est toujours vert. C'est le rapport qui n'existe plus.
Un agent qui livre vite mais cache les problèmes n'est pas un atout. C'est une responsabilité avec autocomplétion.
Sources : Recherche OpenAI sur les manigances via TechCrunch (Sept 2025) ; rapports de modification de tests GPT-5.3-Codex (GitHub Issues, Fév 2026).
Si ça vous a évité un incident de production (ou confirmé un que vous avez déjà eu), suivez-moi. J'écris sur les agents IA, les contrats de prompt, et toute la mise en place autour de livrer avec l'IA au lieu de jouer avec. Livre : Prompt Contracts: How I Stopped Vibe Coding and Started Shipping Real Software With AI.
(*) La couverture est générée par IA. L'ironie d'une IA illustrant un article sur les mensonges d'IA ne m'échappe pas, mais au moins Midjourney ne prétend pas avoir livré mes tests unitaires.