Comment tester un agent IA quand le système de production est inaccessible

C'est une situation très courante : l'agent IA doit interroger un ERP, un logiciel métier ancien, un back-office sous authentification forte, ou un environnement client hébergé sur un réseau auquel l'équipe projet n'a pas accès. On ne peut donc pas « simplement » faire tourner l'agent sur le système réel avant la recette. Ce n'est pas une fatalité, mais cela impose une méthode plus rigoureuse que le simple test manuel en fin de projet.

Séparer ce qui doit être testé de ce qui ne peut pas l'être

La première erreur consiste à traiter l'ensemble du projet comme un bloc impossible à valider. En pratique, un agent se décompose en couches distinctes, et la plupart sont testables sans le système cible :

• la compréhension de la demande et la construction du raisonnement ;
• la sélection des outils et la génération des paramètres d'appel ;
• le formatage des réponses et la gestion des erreurs ;
• l'intégration technique elle-même (authentification, réseau, quotas).

Seule la dernière couche dépend réellement du système inaccessible. Les trois premières représentent souvent 80 % des risques de comportement. Les isoler permet de livrer un projet avec un haut niveau de confiance même sans accès complet.

Construire un double du système, pas une maquette approximative

Un agent qui fonctionne sur un faux système trop indulgent ne prouve rien. Le double de test doit reproduire les contraintes qui font échouer les agents en production :

• les temps de réponse lents et les timeouts ;
• les erreurs métier (identifiant inconnu, droit insuffisant, enregistrement déjà existant) ;
• les formats de données réels, y compris les champs vides, mal encodés ou ambigus ;
• les limites de débit et les réponses partielles.

Concrètement, on construit un serveur de simulation qui expose la même interface que le système cible, avec des jeux de données anonymisés ou synthétiques représentatifs. Ce simulateur devient un livrable du projet : il sert à la recette, puis reste utile pour les évolutions futures.

Constituer un jeu de cas de recette représentatif

La validation avant mise en production repose sur un jeu de scénarios écrits, versionnés et relus avec le métier. Trois catégories sont indispensables :

• les cas nominaux, ceux qui couvrent l'usage quotidien réel ;
• les cas limites, où la demande est ambiguë, incomplète ou formulée avec un vocabulaire métier imprécis ;
• les cas de refus, où l'agent doit s'arrêter, demander une confirmation ou signaler qu'il ne peut pas agir.

Cette troisième catégorie est la plus négligée et la plus critique. Un agent qui échoue proprement est acceptable ; un agent qui invente un identifiant client ou valide une opération irréversible ne l'est pas. Pour chaque scénario, on définit à l'avance le résultat attendu, y compris les actions autorisées et interdites.

Mesurer, pas seulement observer

« L'agent a bien répondu » n'est pas un critère de recette. Il faut des indicateurs simples mais suivis :

• le taux de scénarios réussis, par catégorie ;
• le taux d'actions non demandées ou hors périmètre ;
• le nombre d'hallucinations détectées sur les données (identifiants, montants, statuts) ;
• le comportement en cas d'erreur du système (message clair, pas de nouvelle tentative en boucle).

Ces mesures se comparent d'une version à l'autre. Un agent ne se valide pas une fois pour toutes : chaque modification de prompt, de modèle ou d'outil doit être repassée sur le même jeu de tests. C'est ce qui distingue une évaluation sérieuse d'une démonstration.

Tester l'intégration réelle dès que possible

Le simulateur ne remplace pas le système cible. Dès qu'un accès est possible, même restreint, il faut prévoir une fenêtre de test sur un environnement de préproduction : un compte de service dédié, des droits limités, un jeu de données de test côté client. Cette étape valide l'authentification, les permissions, les formats réels et les performances. Elle doit être planifiée tôt, car elle dépend souvent de tiers et conditionne la date de mise en production.

Si aucun accès n'est obtenu, la décision de mise en production doit être explicite : l'agent est déployé en mode observation ou en suggestion, sans action automatique, jusqu'à validation sur le système réel.

Les questions à poser à votre prestataire

Avant de signer, quelques questions révèlent la solidité de la démarche :

• Comment comptez-vous tester l'agent sans accès au système cible ?
• Le simulateur et les jeux de test seront-ils livrés avec le code ?
• Quels sont les scénarios de refus prévus, et qui les valide ?
• Comment mesurez-vous les hallucinations sur les données métier ?
• Que se passe-t-il si le système cible est indisponible ou renvoie une erreur ?
• Comment les tests sont-ils rejoués après une modification du modèle ou du prompt ?

Un prestataire qui répond « on testera en production » ou qui ne peut pas décrire ses scénarios de refus n'a pas de méthode d'évaluation. À l'inverse, une équipe qui propose un simulateur, un jeu de cas versionné et des indicateurs suivis vous donne une base de discussion solide, même si l'accès complet n'est pas encore là.

En discuter

Si votre agent IA doit travailler sur un système que vous ne pouvez pas reproduire facilement, la méthode se construit dès le cadrage, pas à la veille de la mise en production. C'est un sujet que je traite régulièrement avec des équipes qui n'ont qu'un accès partiel à leur environnement cible. Si vous voulez en parler, décrivez-moi votre contexte et vos contraintes d'accès : contact@hamzabelgacem.com.