Beaucoup d'entreprises veulent un agent IA qui travaille dans un logiciel métier fermé (ERP, plateforme interne, outil éditeur sans API de test). Voici comment évaluer un prestataire qui sait réellement tester ce genre d'agent avant de le mettre en production.
Beaucoup de projets d'agents IA échouent non pas parce que le modèle est mauvais, mais parce que personne n'a sérieusement testé l'agent dans l'environnement réel. Le problème devient aigu quand le logiciel cible est fermé : un ERP propriétaire, une plateforme interne sans API documentée, un outil éditeur dont on ne peut pas cloner la base. Comment vérifier qu'un prestataire sait réellement évaluer ce type d'agent avant la mise en production ?
Pourquoi le logiciel fermé change tout
Un agent IA qui travaille dans un logiciel fermé n'a pas de bac à sable évident. On ne peut pas instancier un environnement de test identique, on ne peut pas rejouer facilement une transaction, et les erreurs ont des conséquences réelles : un devis mal rempli, un dossier client écrasé, une facture émise à tort.
La tentation est de tester « en observant » : on laisse l'agent tourner sur des cas réels et on corrige au fil de l'eau. C'est exactement ce qu'il faut éviter. Un agent en production sans jeu de tests sérieux, c'est un stagiaire à qui on confie la comptabilité le premier jour.
La bonne question à poser à un prestataire n'est donc pas « quel modèle utilisez-vous ? » mais « comment prouvez-vous que l'agent se comporte correctement avant de le brancher sur notre système ? ».
Les quatre stratégies de test à exiger
1. Le double de l'interface, pas le logiciel lui-même
Si le logiciel expose une interface graphique, on peut construire un environnement de test qui imite les écrans et les réponses attendues : un « mock » du logiciel. L'agent interagit avec ce double, qui vérifie chaque action. On peut ainsi rejouer des centaines de scénarios sans toucher au système réel.
Demandez au prestataire s'il a prévu ce double, qui le maintient, et comment il garantit que le double reste fidèle au logiciel quand celui-ci est mis à jour.
2. Le mode observation seule
Une étape intermédiaire utile : l'agent reçoit les mêmes informations qu'un utilisateur, propose une action, mais ne l'exécute pas. Un humain compare la proposition à ce qu'il aurait fait. On collecte ainsi des dizaines de cas réels, y compris les cas limites, sans risque.
C'est lent, mais c'est la seule façon de découvrir les situations que personne n'avait anticipées : champs vides, doublons de clients, unités de mesure incohérentes, dates au mauvais format.
3. Les garde-fous vérifiables
Un agent sérieux dans un logiciel fermé doit être encadré par des règles explicites : montants maximum, types d'actions autorisées, champs en lecture seule, confirmation humaine obligatoire pour toute écriture sensible. Ces garde-fous doivent être testés un par un, y compris en essayant de les contourner.
Un prestataire qui répond « le modèle est assez intelligent pour ne pas se tromper » n'a pas compris le problème. La fiabilité vient du cadre, pas de la promesse du modèle.
4. Le test de régression à chaque changement
Dès qu'on modifie le prompt, le modèle ou une règle, il faut rejouer la batterie de scénarios. Sans cela, une amélioration apparente casse silencieusement un cas validé la semaine précédente. Exigez un jeu de tests versionné et un rapport clair à chaque itération.
Ce qu'un bon prestataire vous montrera
Lors de l'évaluation d'un prestataire pour un agent IA sur logiciel fermé, demandez des preuves concrètes, pas des intentions :
- Une liste de scénarios de test écrite avant le développement, avec les cas normaux et les cas limites.
- Une description de l'environnement de test et de ses limites assumées.
- Un plan de retour arrière : que se passe-t-il si l'agent se trompe en production ? Peut-on annuler une action ?
- Une stratégie de journalisation : chaque décision de l'agent doit être traçable, avec l'entrée, la sortie et la règle appliquée.
- Un calendrier où la mise en production arrive après une phase de validation mesurable.
Méfiez-vous des réponses vagues sur le « monitoring » ou des démonstrations qui ne montrent que le cas qui marche. Un bon professionnel vous parlera spontanément de ses échecs de test : c'est le signe qu'il en a fait.
Le piège de l'intégration sans API
Quand le logiciel n'a pas d'API, l'agent doit souvent passer par l'interface, ce qui est fragile : un bouton qui change de place casse tout. Le prestataire doit expliquer comment il détecte ces ruptures et comment il alerte. Une intégration IA sur un ERP sans API n'est pas impossible, mais elle exige une surveillance active et un plan de maintenance réaliste.
Posez aussi la question de la responsabilité : qui intervient si l'agent bloque un processus métier un lundi matin ? La réponse doit être écrite, pas implicite.
En résumé
Un agent IA sur logiciel fermé se juge sur sa capacité à être testé, pas sur la puissance du modèle. Double de l'interface, mode observation, garde-fous testés, régression systématique : ces quatre briques distinguent un projet maîtrisé d'une démonstration. Si un prestataire ne peut pas décrire précisément comment il valide l'agent avant la production, le risque est déjà visible.
Vous avez un projet d'agent IA sur un logiciel métier fermé et vous voulez en discuter ? Écrivez-moi à contact@hamzabelgacem.com : nous pouvons passer en revue vos contraintes et voir ce qui est raisonnablement testable avant de vous engager.