Votre agent IA plante en prod ? Normal, vous ne le testez pas

La regression silencieuse : le tueur invisible

En développement logiciel classique, quand vous cassez quelque chose, ça plante. Erreur 500. Ecran rouge. Le client appelle. Vous savez immédiatement que c'est casse.

Un agent IA, c'est différent. Il ne plante pas - il dérive. Vous modifiez un prompt pour ameliorer les réponses sur un cas précis. L'agent répond mieux sur ce cas. Vous etes content. Mais cette modification a un effet secondaire : le JSON qu'il génère pour les appels d'outils est maintenant 5% plus verbeux. Assez pour depasser la fenêtre de contexte dans certains cas. Le parsing échoue silencieusement. L'outil n'est pas appele. L'agent improvise une réponse sans les donnees reelles.

Resultat : des réponses plausibles mais fausses. Le client ne détecte rien immédiatement. Vous ne detectez rien dans les logs parce que techniquement, il n'y a pas d'erreur. C'est seulement quand quelqu'un vérifie manuellement les chiffres - si quelqu'un les vérifie - que le problème emerge.

Des chercheurs de Stanford ont documente ce phénomène : les performances des LLM fluctuent de maniere significative entre les versions, et une amelioration sur une tâche s'accompagne souvent d'une degradation sur une autre. Ce qui est vrai pour les modeles l'est aussi pour les prompts.

Le golden dataset : votre contrat qualité

La solution est connue en genie logiciel depuis 40 ans : les tests de regression. Adaptee aux agents IA, ça donne le golden dataset.

Un golden dataset, c'est une collection de cas d'utilisation réels - pas inventes, pas simplifies - avec les résultats attendus. Pour un agent de relance commerciale, ça ressemble a :

Cas 1 - Relance standard J+7 : Input : client Dupont, devis #2456, montant 12500 EUR, envoyé il y a 7 jours, pas de réponse. Attendu : email de relance template "relance_devis_j7", ton cordial, montant correct, lien vers le devis.

Cas 2 - Client VIP avec historique : Input : client Martin (CA annuel > 100k), devis #2489, 3 jours sans réponse, 2 achats précédents. Attendu : relance personnalisee, référence aux achats précédents, proposition d'appel téléphonique.

Cas 3 - Devis expire : Input : client Petit, devis #2301, expire depuis 15 jours. Attendu : pas de relance automatique, notification au commercial pour action manuelle.

10 a 20 cas suffisent pour commencer. Couvrez le cas normal d'abord, puis les cas limites : montants a zero, clients sans email, devis avec erreurs, doublons.

Hard vs soft : deux niveaux de vérification

Tous les tests ne se valent pas. La distinction hard/soft est fondamentale :

Tests hard (non-negociables) : - Le JSON génère est validé (parseable sans erreur) - Les champs obligatoires sont presents (destinataire, montant, template) - Le bon outil est appele (email, pas SMS ; relance, pas premier contact) - Les types sont corrects (montant = nombre, date = date)

Si un test hard échoue, l'agent est casse. Pas de discussion. On corrige ou on revient en arriere.

Tests soft (surveillance) : - Le ton de l'email correspond a la relation client - Les chiffres cites sont plausibles (pas de montant negatif, pas de date dans le passe) - La longueur de la réponse est dans la fourchette attendue - Les références contextuelles sont pertinentes

Un échec soft ne bloque pas le déploiement mais déclenche une alerte. Deux échecs soft sur le même sujet deviennent un hard. Trois échecs soft sur des sujets différents declenchent un audit complet.

Le workflow qui sauve des clients

Le processus est brutal de simplicite :

1. Modifier le prompt 2. Lancer la suite d'evals (golden dataset complet) 3. Si PASS : commiter la modification 4. Si FAIL : corriger ou reverter. Pas de compromis.

C'est du développement logiciel standard. Aucune innovation. Aucune IA nécessaire pour le processus de test lui-même. Et pourtant, sur les projets d'agents IA que nous auditons, moins de 10% ont une suite d'evals en place.

Les excuses sont toujours les mêmes : "l'IA est non-déterministe, on ne peut pas tester", "les réponses varient a chaque fois", "c'est trop complexe". Toutes fausses.

Oui, un LLM est non-déterministe. Mais la structure de la réponse peut être déterministe (JSON validé ou pas). Le choix de l'outil peut être déterministe (bon outil ou mauvais outil). Les contraintes métier peuvent être deterministes (montant positif ou pas). On ne teste pas la creativite de l'agent - on teste sa fiabilité.

Actions atomiques : le parachute de secours

Les evals verifient que l'agent prend les bonnes décisions. Les actions atomiques garantissent que même une mauvaise décision ne cause pas de catastrophe.

Le principe : chaque action de l'agent est decomposee en opérations minimales, typees et validees avant execution.

Si le montant est negatif : l'action ne s'execute pas. Si le template n'existe pas : l'action ne s'execute pas. Si l'adresse email n'est pas validé : l'action ne s'execute pas.

Le coût de cette validation est négligeable - quelques millisecondes. Le coût d'un email errone envoyé a un client : inestimable.

Telemetrie : voir ce que l'agent fait réellement

Derniere piece du puzzle. Vous avez les evals en pre-déploiement. Vous avez les actions atomiques en runtime. Il vous manque la visibilité post-déploiement.

La télémétrie d'un agent IA, c'est : - Chaque décision loguee avec le contexte qui l'a motivee - Chaque action tracee avec ses parametres et son résultat - Chaque erreur (y compris les validations refusees) enregistree - Les métriques : temps de réponse, nombre de boucles par requete, taux d'utilisation des outils

Sans télémétrie, vous découvrez les problèmes quand les clients se plaignent. Avec télémétrie, vous voyez le taux de validation refusee augmenter de 2% a 15% le lendemain d'un déploiement - et vous investigez avant que quiconque ne s'en apercoive.

Le projet Agents from Scratch consacre sa derniere lecon a ce sujet. Pas parce que c'est optionnel - parce que c'est la couche finale qui rend tout le reste observable.

La checklist de déploiement agent IA

Avant de mettre un agent IA en contact avec vos clients, verifiez :

• **Golden dataset** de 10+ cas réels avec résultats attendus
• **Tests hard** sur la structure (JSON, champs, types, outils)
• **Tests soft** sur la pertinence (ton, chiffres, contexte)
• **Actions atomiques** avec validation pre-execution
• **Conditions d'arret** documentees (max_steps, timeout)
• **Telemetrie** en place (décisions, actions, erreurs, métriques)
• **Procedure de rollback** testee (revenir a la version précédente en <5 min)
• **Humain dans la boucle** pour les actions a haut risque (montants > seuil, nouveaux clients)

Si vous cochez moins de 6 cases sur 8, votre agent n'est pas prêt pour la production. Il est prêt pour une demo.