Votre prototype IA fonctionne : voici ce qu’il faut prouver avant la mise en production

IA en production · 6 min

La démonstration s’est bien passée. Le prototype a lu un dossier, extrait les bonnes informations, rédigé une synthèse propre. Le comité a hoché la tête, quelqu’un a demandé « quand est-ce qu’on le met en service ? », et l’équipe projet a répondu « bientôt ».

Puis le projet s’enlise. La DSI demande comment l’outil sera surveillé. Le juridique demande qui est responsable si une information est fausse. L’équipe métier essaie l’outil sur ses propres dossiers et tombe sur des réponses qu’elle ne sait pas vérifier. Le prototype n’a pas changé ; ce sont les questions qui ont changé.

Un prototype prouve qu’une chose est possible. La mise en production demande de prouver qu’elle est fiable, contrôlée et assumée par quelqu’un. C’est là que commence le vrai travail, et c’est le moment où beaucoup de projets s’arrêtent.

Ce qu’une démonstration ne montre pas

Une démonstration se fait sur des dossiers choisis, souvent propres, souvent préparés par la personne qui a construit l’outil. Elle montre les cas où tout se passe bien. Elle ne dit rien de ce qui arrive quand un document est mal scanné, quand une pièce manque, quand deux documents se contredisent, ou quand l’outil n’a simplement pas la réponse.

Or c’est exactement ce qui fait la vie réelle d’une direction achats, d’un service financier ou d’un cabinet. Les dossiers imparfaits ne sont pas l’exception ; ils sont le quotidien. Un outil qui répond avec aplomb sur un document illisible est plus dangereux qu’un outil qui ne répond pas, parce que son erreur ne se voit pas.

La question à poser devant un prototype n’est donc pas « est-ce que ça marche ? ». C’est « comment saurons-nous quand ça ne marche pas ? ».

Première preuve : une justesse mesurée sur vos documents réels

Avant toute décision de mise en production, l’outil doit être testé sur un ensemble de vos propres documents, avec la bonne réponse établie à l’avance par vos équipes. Pas sur des exemples de démonstration, pas sur des documents publics : sur ce que l’outil traitera vraiment.

Ce jeu de test doit contenir les cas difficiles. Si votre équipe sait qu’un type de dossier pose toujours problème, il doit y figurer. Le résultat n’est pas une impression (« ça a l’air bien ») mais une mesure : sur ces dossiers, combien de réponses justes, combien de fausses, combien de cas où l’outil a correctement signalé qu’il ne savait pas.

Cette mesure a une seconde utilité, souvent négligée : elle permet de vérifier qu’une amélioration n’a rien cassé. Chaque modification de l’outil doit repasser sur le même jeu de test. Une consigne qui paraît raisonnable peut améliorer un cas et en dégrader deux autres ; sans mesure, personne ne s’en aperçoit.

Deuxième preuve : des contrôles qui ne dépendent pas de l’IA

Un outil d’IA ne peut pas faire le travail et certifier lui-même qu’il l’a bien fait. Les règles métier qui ne se discutent pas doivent être vérifiées par un programme classique, indépendant de l’IA : un total qui doit se recouper, une pièce obligatoire qui doit être présente, une date qui doit correspondre à l’exercice, un montant qui doit être identique à celui du document source.

Ma règle de travail tient en une phrase : un document, un contrôle, une preuve. L’agent fait le travail, le code vérifie les règles du métier, chaque chiffre renvoie au document dont il vient, et c’est le client qui décide.

Quand un contrôle échoue, l’outil ne doit pas passer outre. Il doit corriger, recommencer, ou s’arrêter et signaler le cas à une personne. Un système qui ne refuse jamais rien ne vérifie probablement rien.

Troisième preuve : chaque information renvoie à sa source

Votre équipe ne peut pas faire confiance à une information qu’elle ne peut pas vérifier. Chaque chiffre, chaque constat produit par l’outil doit pouvoir être relié au document, à la page, au passage dont il vient.

Cette traçabilité change la relecture. Sans elle, la personne qui valide doit tout reprendre depuis les documents d’origine, et l’outil ne fait gagner que la première rédaction. Avec elle, la relecture se concentre sur les points signalés et sur les décisions de fond. Une analyse de candidatures d’appel d’offres, par exemple, n’est utilisable par un acheteur public que si chaque constat renvoie à la pièce du dossier qui le justifie.

Quatrième preuve : qui valide quoi

La dernière question n’est pas technique, et c’est souvent elle qui bloque le plus longtemps. Il faut écrire noir sur blanc :

quelles décisions l’outil peut préparer, et lesquelles il ne prend jamais seul ;
qui relit, à quel moment, et sur quels éléments ;
qui tranche les cas que l’outil a signalés comme ambigus ;
qui est responsable du document qui sort, et sous quelle signature ;
ce qui se passe quand l’outil est indisponible ou quand il se trompe.

Tant que ces réponses ne sont pas écrites, la mise en production reste une promesse. Une fois écrites, la DSI, le juridique et l’équipe métier savent chacun ce qu’ils assument.

Les signaux qui montrent qu’un prototype n’est pas prêt

Personne ne peut dire sur combien de vos documents il a été testé, ni avec quel résultat.
Les tests ont été faits par l’équipe qui l’a construit, sur des dossiers qu’elle a choisis.
L’outil répond toujours, même quand l’information n’est pas dans le document.
On ne peut pas savoir d’où vient un chiffre sans refaire le travail à la main.
Les règles métier sont rappelées à l’IA sous forme de consignes, mais rien ne vérifie qu’elle les respecte.
Aucun responsable métier n’a signé les critères de réussite.
Une modification de l’outil est mise en service sans repasser les tests.

Ce qu’il faut avoir avant de dire oui

Un jeu de test constitué de vos documents réels, cas difficiles compris, avec les bonnes réponses établies par vos équipes.
Une mesure de justesse sur ce jeu, repassée à chaque modification.
Des contrôles automatiques, indépendants de l’IA, sur les règles métier non négociables.
Un comportement défini quand l’outil ne sait pas : il le dit, il ne devine pas.
Une source citée pour chaque information produite.
Un circuit de validation écrit, avec un responsable nommé côté métier.
Un suivi en service : erreurs remontées, cas signalés, évolution des résultats.
Une équipe interne capable de faire évoluer l’outil après le départ de ceux qui l’ont construit.

Ce dernier point compte autant que les autres. Un outil que personne ne sait modifier finit abandonné à la première évolution du métier.

Continuer ou arrêter, preuves à l’appui

Toutes ces preuves ont un avantage qu’on oublie : elles permettent aussi de décider d’arrêter. Un prototype qui n’atteint pas les critères fixés sur vos documents réels n’est pas un échec s’il permet de le savoir clairement, avant d’avoir engagé l’intégration, la formation et le support. C’est une décision prise sur des faits, et non sur l’impression laissée par une démonstration.

C’est ainsi que je construis les prototypes que je réalise : sur les documents réels du client, avec leurs contrôles et une mesure de justesse, pour qu’à la fin la décision de continuer ou d’arrêter repose sur des preuves. Puis j’accompagne le passage dans l’environnement du client, jusqu’à ce que son équipe sache faire évoluer l’outil.

Votre prototype attend sa mise en production ? Si vous voulez vérifier ce qu’il reste à prouver, prenons trente minutes pour en parler.