Pourquoi les agents d’IA de production échouent en silence et comment détecter des réponses erronées

La défaillance de production la plus dangereuse pour un agent IA n’est ni une panne ni un délai d’exécution. C’est une réponse qui semble correcte, passe tous les contrôles de santé et est pourtant fausse. L’étude de cas ci-dessous suit une petite entreprise de logiciels qui a mis en production douze agents en un seul trimestre et n’en a conservé que trois ; elle explique ce qui a distingué les agents survivants des autres, afin de permettre une détection préalable avant le déploiement.

L’équipe, les outils et les règles de base

L’entreprise était une société SaaS B2B comptant une quarantaine de personnes, dont neuf ingénieurs, et non un laboratoire de recherche. Entre le 6 janvier et le 27 mars 2026, l’équipe a lancé douze agents. Ceux qui fonctionnaient dans le dépôt de code tournaient sous Claude Code ; les autres étaient des agents personnalisés développés à l’aide de l’API d’Anthropic et hébergés derrière un petit service interne, de sorte que chaque agent partageait un seul journal d’audit et un seul interrupteur de mise hors service.

Du jour one, deux règles ont été appliquées et toutes deux se sont révélées utiles à maintenir :

• Chaque agent enregistre chaque action dans un canal d’audit, y compris les actions en lecture seule.
• Tout membre de l’équipe peut désactiver n’importe quel agent à tout moment, sans autorisation ni ticket requis.

Le succès a été défini de manière intentionnellement exigeante. Un agent n’était considéré comme un succès que s’il continuait de fonctionner après trente jours et si quelqu’un s’opposait à sa désactivation. Les métriques d’utilisation peuvent facilement être gonflées par la nouveauté ; il est bien plus difficile de falsifier le fait que des personnes défendent un outil dont elles dépendent.

Bilan : trois agents encore en service, neuf désactivations

À la fin du trimestre, trois agents fonctionnaient encore :

• un écrivain de descriptions pour les demandes de pull request
• un assistant à la rédaction pour le tri des tickets de support
• un collecteur d’informations sur les incidents

Nine furent désactivés en l’espace d’un mois : un outil de révision automatique de code, un système de réponse aux questions analytiques, un bot d’upgrade des dépendances, un outil de quarantaine des tests instables, un système de réponse aux e-mails des clients, un convertisseur de notes de réunion en tickets, un mises à jour de la documentation wiki, un système de réponse aux anomalies dans les journaux et un éditeur de fichier de changements.

L’instruction de sécurité qui n’a pas aidé

Comme la plupart des équipes, celle-ci a commencé par une instruction de sécurité intégrée dans le prompt système de chaque agent, indiquant au modèle d’admettre son incertitude, d’éviter les valeurs non vérifiables et de citer une source pour chaque chiffre :

If you are not confident in an answer, say "I don't know" and stop.
Never state a value you cannot verify from the tools available to you.
Cite the source of every number you report.

En pratique, cette instruction n’a eu presque aucun effet, et la raison en est la leçon la plus importante de toute cette expérience. Elle est expliquée en détail dans l’échec analytique mentionné ci-dessous.

Les permissions ont également été définies de manière conservatrice : chaque agent disposait uniquement des droits de lecture au lancement. Au cours du trimestre, quatre agents ont obtenu des droits d’écriture. Trois d’entre eux ont ensuite été désactivés.

Ce que les agents survivants avaient en commun

L’auteur de descriptions pour les demandes de fusion

Fonctionnant sur Claude Code, cet agent pouvait lire la différence de version ainsi que l’issue associée, puis écrire une description dans le corps de la demande de fusion. Un ingénieur la modifiait ensuite et effectuait la fusion. Il gérait environ 35 demandes de fusion par semaine, et les descriptions produites étaient généralement meilleures que celles écrites à la main par les ingénieurs, principalement parce qu’un développeur fatigué a tendance à écrire « corriger le bug », tandis que l’agent ne se fatigue pas.

L’auteur de résumés pour le tri des demandes d’assistance

Cet agent lisait chaque ticket reçu, y appliquait une étiquette et rédigeait une réponse sous forme de note interne au sein du service d’assistance. Il n’avait jamais la capacité d’envoyer quoi que ce soit. Environ 60 % de ses drafts étaient envoyés après une légère modification, et le temps moyen de réponse est passé d’un peu plus de quatre heures à environ quatre-vingts minutes.

Collecteur de contexte des incidents

Lorsqu’une alerte contactait quelqu’un, cet agent postait un seul message dans le canal dédié aux incidents, contenant les trois déploiements les plus récents avec leurs horodatages, l’évolution du taux d’erreurs par service, ainsi que des liens vers tout incident similaire survenu au cours des quatre-vingt-dix jours précédents. Il ne prenait aucune action ni ne proposait de diagnostic ; il se contentait de rassembler les tableaux de bord et les liens que l’ingénieur de garde aurait normalement ouverts manuellement. C’était l’agent le moins sophistiqué que l’équipe ait jamais développé, mais aussi celui qu’elle appréciait le plus.

Anatomie d’un agent qui se trompe avec assurance

En théorie, l’agent d’analyse était le mieux conçu des douze. Il disposait d’une réplique de lecture, d’un document de schéma manuscrit dans son contexte ainsi que d’une interface Slack, et sa fonction était de répondre aux questions relatives aux métriques afin que l’équipe des données cesse d’être interrompue vingt fois par jour.

Le 3 février, quelqu’un lui a demandé les revenus hebdomadaires. Il a généré une requête qui associait les commandes aux paiements, traitant au passage les lignes de remboursement comme des montants positifs. Le résultat était d’environ 12 % trop élevé, mais tout à fait crédible : l’ampleur était correcte, la tendance semaine après semaine était juste, et même le creux saisonnier suite à la fin d’une promotion en janvier était visible.

Ce chiffre exagéré est apparu dans l’article sur les indicateurs du lundi, puis également dans les deux articles suivants publiés ce même jour. L’erreur n’a été détectée que le 24 février, lors de la clôture du mois de janvier, lorsque le total établi par l’équipe financière ne correspondait pas à celui de l’agent.

Pensez à ce qui n’est pas arrivé au cours de ces trois semaines : il n’y a eu aucune exception, aucun alerte et aucune augmentation soudaine de la latence. La requête SQL était valide, les lignes de données étaient renvoyées, et l’agent a cité sa source exactement comme le demandait la procédure. La surveillance conventionnelle existe pour détecter les systèmes qui cessent de fonctionner, or celui-ci n’a jamais cessé de fonctionner.

C’est précisément là que la fonction de garde-fou échoue. Une instruction demandant de dire « Je ne sais pas » en cas d’incertitude ne fonctionne que si le modèle dispose d’un signal interne indiquant son propre doute. Ici, le modèle n’était pas incertain ; il s’est simplement trompé. De l’extérieur, se tromper avec assurance est indiscernable du fait d’avoir raison, donc une instruction ne peut pas le filtrer.

Un point général utile en découle : une opération qui modifie silencieusement le signe ou la multiplicité des lignes constitue également une erreur classique en analyse pour les humains. La différence réside dans le fait qu’un analyste humain a généralement une idée des chiffres que les services financiers vont vérifier, tandis qu’un agent n’a aucun intérêt à effectuer la conciliation à moins que vous ne lui en donniez un.

Lorsqu’un agent correct est ignoré

L’outil d’examen automatique du code a échoué d’une manière que de nombreuses équipes n’auraient pas anticipée : il n’avait pas tort. Chaque demande de fusion recevait une quarantaine de commentaires ; la plupart étaient justifiés, et beaucoup concernaient des détails mineurs liés à la nomenclature ou au style de gestion des erreurs.

Dans trois semaines, les ingénieurs résolvaient ses commentaires sans même les lire. Puis il a soulevé un problème véritablement sérieux, une requête sans filtre de locataire, et ce commentaire a été noyé parmi 38 remarques sur le style. Quelqu’un a découvert la faille deux jours plus tard en phase de test. L’outil avait raison, mais un volume excessif a étouffé son signal.

Pourquoi les neuf ont été désactivés

Ces échecs se sont présentés de manière claire :

• six ont produit des résultats fiables mais erronés
• deux ont généré des résultats que personne n’a lus
• un a été désactivé car personne ne pouvait déterminer s’il effectuait réellement quelque chose

La règle de conception : s’arrêter d’un pas avant l’intervention humaine

Les trois agents encore en fonction partagent une propriété commune, qui n’est ni le modèle, ni la instruction, ni le cadre de travail. Chacun d’eux s’arrête à un pas de l’intervention humaine. Ils produisent un brouillon, un résumé ou un ensemble de contextes, puis c’est une personne qui effectue l’étape finale. Effectuer cette étape oblige la personne à lire le travail produit.

Tous les agents qui ont été arrêtés ont soit agi de leur propre chef, soit généré des résultats qui se sont transformés en actions sans véritable contrôle. L’agent d’analyse en est l’exemple frappant : il n’avait absolument aucun droit d’édition, pourtant ses recommandations ont directement influencé les décisions commerciales grâce à la confiance que lui portaient les gens.

La limite qui en résulte est simple : permettez aux agents de rassembler des informations, mais ne leur laissez pas prendre en charge l’étape finale, où une erreur peut avoir des conséquences réelles.

Cette limite n’est pas un jugement sur les capacités du modèle, et un modèle plus performant ne la supprimera pas. Il s’agit de détection : l’échec typique d’un agent consiste en une réponse plausible plutôt qu’en un plantage, et la plupart des équipes disposent de très peu d’outils pour repérer ces réponses plausibles mais erronées.

Le coût n’a jamais été le goulot d’étranglement. Les douze agents ensemble ont consommé un peu moins de 900 dollars en tokens au cours du trimestre. La ressource rare était l’attention humaine.

Trois changements que vous pouvez apporter cette semaine

• Au préalable de la mise en production, documentez comment une réponse fausse mais présentée avec assurance pourrait être détectée. Il ne s’agit pas de savoir comment repérer un plantage, mais plutôt de comprendre comment déterminer que la sortie est incorrecte. Si vous ne parvenez pas à rédiger cette phrase, l’agent devrait se contenter de rédiger des propositions plutôt que d’agir.

Reconciliez chaque chiffre produit par un agent avec une deuxième source selon un calendrier préétabli. Une comparaison automatisée hebdomadaire avec les données financières aurait permis de détecter l’erreur sur le deuxième jour, et sa mise en place n’aurait nécessité qu’une après-midi.

Fournissez les résultats des agents là où les gens regardent déjà, et limitez leur quantité. Un nouveau canal a tendance à être ignoré, tandis qu’une série de quarante commentaires est parcourue rapidement, seuls quelques commentaires ciblés attirant réellement l’attention.

Rapprocher le chiffre d’une seconde source

Comparez le chiffre de l’agent au grand livre et arrêtez-vous si l’écart dépasse un demi pour cent ou une unité monétaire.

const reconcile = (agentRevenue: number, ledgerRevenue: number) => {
  const delta = Math.abs(agentRevenue - ledgerRevenue);
  const tolerance = Math.max(1, Math.abs(ledgerRevenue) * 0.005);
  return { ok: delta <= tolerance, delta };
};

Lancez la comparaison selon un calendrier. Le moniteur de plantage reste vert ; ce contrôle appelle une personne.

Points clés

• Un résultat erroné mais plausible, et non une panne, est le mode de défaillance à prendre en compte dans la conception ; la surveillance standard ne le détectera pas.
• Des instructions précises concernant la fiabilité ne permettront pas de détecter les erreurs que le modèle ne perçoit pas.
• L’accès en lecture seule n’est pas synonyme d’inoffensivité : les résultats utilisés pour prendre des décisions constituent en réalité une action.
• Le volume est en soi un mode de défaillance ; un signal correct noyé dans du bruit n’a aucune valeur.
• Un test utile pour tout agent consiste à se demander si quelqu’un s’y opposerait s’il était désactivé demain.