Un prototype d’IA prouve qu’une tâche est faisable sur quelques exemples choisis. Un système en production doit traiter tous les cas qui arrivent, dans vos outils, avec des droits maîtrisés, une trace de ce qu’il a fait et une personne qui s’en occupe quand il se trompe. Ce qui manque entre les deux est rarement le modèle : c’est la description du processus, les tests, l’intégration et l’organisation de l’exploitation. Cet article liste ces éléments et propose une checklist pour décider si un prototype est prêt, à reprendre ou à abandonner.
Pourquoi les prototypes restent bloqués
Une équipe teste un assistant pour lire des bons de commande, rédiger des réponses à des clients ou préparer un commentaire de reporting. Le résultat est convaincant en réunion. Six mois plus tard, personne ne l’utilise en routine. Les causes se répètent.
Le processus n’a jamais été décrit. Le prototype a été construit à partir de ce que l’on pensait être la tâche, pas de la manière dont elle est réellement faite. Les règles implicites, les cas particuliers et les vérifications que la personne en poste fait sans y penser n’y figurent pas. Dès les premiers vrais dossiers, le système produit des résultats plausibles mais faux.
Il n’existe aucun cas de test. Le prototype a été jugé « à l’œil » sur une dizaine d’exemples. Personne ne sait dire s’il se trompe une fois sur cinquante ou une fois sur cinq, ni sur quel type de dossier. Sans cette réponse, aucun responsable ne peut raisonnablement l’autoriser à traiter des données réelles.
Il n’est pas branché aux outils. Les entrées sont copiées à la main dans une interface de discussion, les sorties recopiées dans l’ERP ou le CRM. Le gain de temps disparaît dans ces allers-retours.
Les droits d’accès bloquent. Pour fonctionner, le système doit lire une boîte mail, un dossier partagé ou une base clients. La DSI ou le responsable sécurité demande, à juste titre, avec quel compte, quels droits, où vont les données et qui détient les clés. Si personne n’a préparé la réponse, le projet s’arrête là.
Personne n’est responsable de l’exploitation. La personne qui a construit le prototype est passée à autre chose. Quand le format d’un fichier change ou qu’un fournisseur modifie son API, le système casse et il n’y a pas d’interlocuteur.
Les coûts n’ont pas été anticipés. Appels au modèle, hébergement, licences, temps de relecture humaine et maintenance : ces postes n’apparaissent pas dans une démonstration. Ils apparaissent au premier budget annuel, et la question « est-ce que ça vaut le coup ? » se pose sans données pour y répondre.
Aucune de ces causes n’est technique au sens strict. Elles relèvent de la description du travail, de la vérification et de l’organisation.
Démo et production ne répondent pas à la même question
Une démonstration répond à « est-ce possible ? ». La production répond à « peut-on s’y fier, tous les jours, sans que quelqu’un surveille chaque sortie ? ».
Cette différence change le point de départ. Un prototype part d’un outil et cherche un usage. Un système exploité part d’un processus : ses entrées, ses étapes, ses décisions, ses exceptions, ses contrôles. C’est pour cela que la méthode Klaryx commence par observer le travail réel avant de construire quoi que ce soit.
Elle change aussi la répartition des tâches. Dans une démonstration, on demande souvent au modèle de tout faire. En production, on garde en code ce qui peut être une règle stable (un calcul, un contrôle de format, un rapprochement sur un identifiant), on confie à l’IA ce qui demande de l’interprétation (lire un document mal structuré, classer une demande rédigée librement), et on laisse à un humain les décisions sensibles. Ce découpage est détaillé dans notre grille code, IA ou validation humaine.
Ce qui sépare une démo d’un système en production
Aucun de ces éléments ne peut être ignoré sur un processus qui compte.
Décrire
- Spécification des entrées et des sorties. Quels documents ou données arrivent, sous quel format, depuis quelle source ; ce que le système doit produire, où et sous quelle forme. Une sortie « un texte » n’est pas une spécification ; « une ligne dans tel onglet avec ces six champs » en est une.
- Liste des exceptions. Document illisible, donnée manquante, montant hors tolérance, client inconnu, doublon. Pour chacune : que fait le système, et vers qui renvoie-t-il le dossier ?
Vérifier
- Jeu de test. Un ensemble de cas réels anonymisés si nécessaire, avec le résultat attendu pour chacun, incluant les cas difficiles et pas seulement les cas typiques. Il sert à mesurer le taux d’erreur avant la mise en service, puis à vérifier qu’une modification n’a rien cassé.
- Critères de recette. Définis avant la construction et validés par le métier : quel niveau d’erreur est acceptable, sur quels types de cas, et quelles erreurs sont éliminatoires quel que soit leur nombre.
Brancher
- Intégration aux outils. Le système lit ses entrées là où elles arrivent et dépose ses sorties là où l’équipe travaille déjà. Le déclenchement est simple : une arrivée de fichier, une heure fixe, un bouton.
- Gestion des accès et des secrets. Un compte de service dédié, avec les droits strictement nécessaires ; des clés d’API stockées hors du code et renouvelables ; une réponse claire sur les données transmises à un fournisseur de modèle et sur leur conservation. Nos principes sont décrits sur la page sécurité et données.
Exploiter
- Journalisation. Pour chaque traitement : quelles entrées, quelle version des règles et des instructions, quelle sortie, quelle validation humaine le cas échéant. Sans journal, on ne peut ni expliquer une erreur ni prouver qu’un contrôle a eu lieu.
- Gestion des incidents. Ce qui se passe quand le système échoue : qui est prévenu, comment le travail reprend manuellement en attendant, comment l’incident est corrigé puis ajouté au jeu de test.
- Surveillance. Quelques indicateurs suivis dans le temps : volume traité, part de dossiers renvoyés à un humain, corrections apportées par les utilisateurs, coût par traitement. Une dérive se voit dans ces chiffres avant de se voir dans les réclamations.
- Documentation. Ce que fait le système, ses règles, ses exceptions, sa procédure d’incident et la façon de le relancer. Elle doit permettre à une autre personne de le reprendre.
- Responsable désigné. Côté métier, quelqu’un qui valide les règles et arbitre les cas limites ; côté technique, quelqu’un, interne ou prestataire, qui corrige et fait évoluer le système.
- Réversibilité. Pouvoir revenir à la version précédente d’une règle ou d’une instruction, changer de fournisseur de modèle, et reprendre le processus à la main si nécessaire. Le code, les règles et la documentation doivent appartenir à l’entreprise.
Checklist « prêt pour la production »
Ce tableau peut servir de revue avant toute mise en service, que le système ait été construit en interne, par un éditeur ou par un prestataire. Une réponse « non » n’interdit pas forcément de démarrer, mais elle doit être une décision explicite, pas un oubli.
| Domaine | Question à poser | Prêt si… |
|---|---|---|
| Périmètre | Le processus couvert est-il décrit étape par étape ? | Un document décrit entrées, étapes, décisions et sorties, validé par les personnes qui font le travail |
| Exceptions | Sait-on ce que fait le système face aux cas qu’il ne sait pas traiter ? | Chaque exception connue a un comportement défini et un destinataire humain |
| Tests | Dispose-t-on d’un jeu de cas réels avec résultats attendus ? | Le jeu couvre les cas courants et difficiles, et le taux d’erreur mesuré est connu |
| Recette | Les critères d’acceptation ont-ils été fixés avant la construction ? | Le métier a signé des critères, y compris les erreurs éliminatoires |
| Répartition | Chaque étape est-elle attribuée au code, à l’IA ou à un humain ? | Les règles stables sont en code ; les décisions sensibles ont une validation humaine |
| Intégration | Le système lit et écrit-il directement dans les outils existants ? | Aucun copier-coller manuel n’est nécessaire dans le fonctionnement normal |
| Accès | Avec quels comptes et quels droits le système fonctionne-t-il ? | Compte dédié, droits minimaux, secrets stockés hors du code, validation par la DSI |
| Données | Sait-on quelles données sortent de l’entreprise et vers qui ? | Les flux vers les fournisseurs sont listés et acceptés par le responsable concerné |
| Journal | Peut-on retrouver ce qui a été fait sur un dossier donné ? | Entrées, version, sortie et validation sont consultables pour chaque traitement |
| Incidents | Que se passe-t-il si le système tombe ou se trompe ? | Une procédure écrite prévoit l’alerte, le repli manuel et la correction |
| Surveillance | Quels indicateurs sont suivis, et par qui ? | Trois à cinq indicateurs sont relevés à une fréquence fixée |
| Coûts | Le coût d’exploitation annuel est-il estimé ? | Modèle, hébergement, licences, relecture et maintenance sont chiffrés |
| Documentation | Une autre personne pourrait-elle reprendre le système ? | Documentation à jour, stockée chez l’entreprise |
| Responsable | Qui répond du système côté métier et côté technique ? | Deux noms (ou fonctions) sont désignés et le savent |
| Réversibilité | Peut-on revenir en arrière ou changer de fournisseur ? | Versions conservées, dépendances identifiées, code et règles détenus par l’entreprise |
Un mot sur les « agents IA »
On appelle généralement « agent » un système auquel on donne un objectif et des outils, et qui choisit lui-même la suite d’actions pour l’atteindre : chercher une information, appeler un logiciel, rédiger, recommencer. C’est une approche utile, mais elle ne supprime aucun des éléments listés plus haut ; elle en rend plusieurs plus exigeants.
Un agent est utile quand :
- les entrées varient beaucoup et ne peuvent pas être traitées par un enchaînement fixe (demandes rédigées librement, documents hétérogènes) ;
- la tâche consiste surtout à rassembler et préparer de l’information pour qu’un humain décide ;
- ses actions sont lisibles, réversibles, ou soumises à validation avant d’avoir un effet.
Il est risqué quand :
- il peut agir directement sur des données de référence, des paiements, des commandes ou des messages envoyés à l’extérieur sans validation ;
- ses droits dépassent ce que la tâche exige, par facilité de configuration ;
- personne ne peut reconstituer après coup pourquoi il a pris telle action ;
- un enchaînement fixe d’étapes, plus simple à tester, suffirait.
Dans beaucoup de processus de PME, la bonne réponse est un flux déterministe avec une ou deux étapes confiées à un modèle, plutôt qu’un agent autonome. Le mot « agent » ne doit pas être un critère de choix ; la fiabilité mesurée sur le jeu de test, si.
Reprendre le prototype, repartir du processus ou arrêter
Face à un prototype bloqué, trois décisions sont possibles, et la checklist aide à choisir.
Reprendre le prototype si le processus est déjà bien décrit, que le taux d’erreur mesuré est acceptable et que les manques portent surtout sur l’intégration, les accès et l’exploitation. C’est le cas le plus favorable.
Repartir du processus si le prototype a été construit sans description du travail réel ni jeu de test. Le code peut parfois être réutilisé, mais il faut d’abord observer, formaliser les règles et les exceptions, puis fixer les critères de recette. Lorsque le processus est mal connu ou touche plusieurs outils, une cartographie de processus permet de trancher avant d’engager la construction.
Arrêter si le volume est trop faible pour justifier les coûts d’exploitation, si l’erreur coûte trop cher au regard du temps gagné, ou si personne n’accepte d’être responsable du système. Renoncer évite d’entretenir un outil que personne n’utilise.
Faire appel à un prestataire n’est pas toujours nécessaire. Si vous disposez d’une équipe technique qui connaît vos outils et d’un responsable métier disponible pour décrire le processus et valider les tests, la checklist ci-dessus peut suffire à mener le travail en interne. Un appui extérieur se justifie surtout quand personne n’a le temps ou les compétences pour faire le lien entre le métier et la construction.
Pour la suite
Si vous avez un prototype à mettre en service ou un processus à rendre exécutable, notre offre d’implémentation de processus détaille ce que couvre une mise en production : spécification, tests, intégration, documentation et transfert. Le suivi après livraison relève de l’offre exploitation et amélioration.