Sortir du prototype : les cinq verrous

Ce qui sépare un prototype d’IA d’un système en production, ce n’est pas une marche unique mais cinq verrous distincts, deux techniques et trois organisationnels, qui se lèvent dans un ordre précis. Un verrou, ici, désigne une condition sans laquelle le système ne peut pas être exploité durablement, quelle que soit la qualité du modèle.

On décrit souvent le passage en production comme un saut : il y aurait le prototype d’un côté, la production de l’autre, et un effort à fournir entre les deux.

Cette image est fausse et elle est coûteuse, parce qu’elle laisse croire qu’on peut y aller d’un coup, avec un budget et trois mois. En réalité il y a cinq verrous distincts, chacun avec sa propre nature, et je les traite dans cet ordre pour éviter de bâtir sur une hypothèse non vérifiée.

Il faut passer aux données réelles avant tout le reste parce que, tant que le système tourne sur un corpus choisi, la performance observée ne prouve pas celle du corpus complet. C’est le premier verrou, et tous les autres dépendent de ce qu’on y découvre.

Le passage aux données réelles est brutal et il doit arriver tôt. Sur un projet documentaire, il révèle en général en quelques jours : des documents scannés que personne n’avait signalés, des doublons contradictoires, des fichiers dont les droits d’accès n’avaient jamais été formalisés, et du contenu périmé dont il faut mesurer la proportion.

Ces découvertes changent la suite du projet : le choix du découpage des documents, la nécessité d’un tri préalable, parfois le périmètre lui-même. C’est la raison pour laquelle le corpus est le projet, et non un détail d’intendance à régler après le modèle.

On sait si un système d’IA donne de bonnes réponses grâce à un jeu de tests métier : un ensemble de cas réels, chacun avec une réponse jugée acceptable par quelqu’un qui fait autorité dans le métier. C’est le deuxième verrou, et ce n’est pas un test unitaire.

Une trentaine de cas peut fournir un point de départ. Ce qui compte n’est pas le volume mais le fait que le jugement soit extérieur à l’équipe technique : c’est ce qui rend la mesure opposable, et c’est ce qui permet, six mois plus tard, de dire si un changement de modèle a amélioré ou dégradé le service.

Ce jeu de tests sert aussi à tenir le prompt dans la durée : chaque modification est mesurée avant d’être conservée, comme expliqué dans écrire un prompt système qui tient six mois.

L’intégration dans le travail, la surveillance des résultats et la reprise par une équipe interne conditionnent l’exploitation durable d’une IA au-delà de sa démonstration initiale.

• L’intégration répond à : où le travail se fait-il déjà ? Elle décide du taux d’usage, souvent plus que la qualité du modèle.
• L’exploitation répond à : qui voit que ça dérive ? Journaux consultables, alerte sur le coût, alerte sur le taux de non-réponse.
• La reprise répond à : que se passe-t-il quand je pars ? Une personne interne doit avoir modifié le système, seule, avant la fin de la mission.

Une fonction d’IA placée dans l’outil déjà utilisé réduit les changements de contexte, mais son adoption doit être vérifiée auprès des personnes concernées avant de conclure.

On peut construire un système excellent sans que son interface séparée s’intègre au travail quotidien. Déplacer la même fonction dans le logiciel déjà ouvert toute la journée peut améliorer l’usage sans changer le modèle.

L’ordre de levée des verrous compte parce que chaque verrou consomme le résultat du précédent : on ne mesure bien qu’après avoir vu les données réelles, et on n’intègre bien qu’après avoir mesuré. Inverser l’ordre revient à refaire le travail.

On ne peut pas définir une mesure pertinente sans avoir vu les données réelles. On ne peut pas décider du point d’intégration sans savoir ce que le système sait vraiment faire. On ne peut pas outiller l’exploitation sans usage réel à observer.

Les équipes qui inversent l’ordre, typiquement, qui commencent par l’interface, refont deux fois le travail. Je l’ai vu suffisamment pour en faire une règle de cadrage plutôt qu’un conseil.

Lever les cinq verrous revient à suivre une séquence courte : brancher le vrai corpus, faire juger trente cas par le métier, choisir le point d’intégration, outiller la surveillance, puis organiser la reprise interne. Chaque étape a un livrable vérifiable.

1. Brancher le vrai corpus. Toutes les sources, avec leurs droits d’accès, et un inventaire de ce qui est scanné, dupliqué ou périmé.
2. Faire juger trente cas. Une personne du métier valide la réponse attendue pour chacun ; le jeu devient rejouable en une commande.
3. Choisir le point d’intégration. Identifier l’écran déjà ouvert au moment où la question se pose, et y placer la fonction.
4. Outiller l’exploitation. Des journaux consultables par l’équipe, une alerte sur le coût, une alerte sur le taux de non-réponse.
5. Organiser la reprise. Une personne interne modifie le système seule, sous supervision, avant la fin de la mission.

Pour un projet déjà lancé qui bute sur l’un de ces points, un audit IA consiste précisément à identifier le verrou sur lequel il est bloqué.

L’absence d’un propriétaire métier nommé peut bloquer la mise en production d’une IA, parce que personne n’accepte alors de répondre de son périmètre et de ses résultats. C’est le constat qui revient le plus souvent dans les projets que j’ai suivis.

Le schéma d’échec est constant : l’équipe technique construit, présente, et découvre au déploiement qu’un responsable refuse. Il refuse à juste titre, n’ayant pas participé à la définition du périmètre.

La parade tient en une demi-journée d’atelier : lister les actions que le système accomplira, les classer selon qu’on peut ou non revenir en arrière, faire valider le classement par le responsable concerné. Le constat détaillé figure dans agents en entreprise : où s’arrêtent les projets, et ses racines sont décrites dans l’anatomie d’un POC qui ne passe jamais.

Le prototype peut sous-estimer le coût de production lorsqu’il exclut les documents longs, les recherches difficiles et les corrections humaines, qui doivent être mesurés avant la bascule.

Je ne retiens pas de multiplicateur universel entre prototype et production. L’écart dépend des tâches, des volumes et de la part des réponses réellement utilisables. Comparez les mêmes postes sur un échantillon ordinaire et sur les cas difficiles.

Mesurez les appels, la relecture, les relances et le temps d’exploitation. Fixez des limites adaptées au service et expliquez ce qui se passe quand elles sont atteintes. Lecture complémentaire : mesurer le coût par fonctionnalité.

Il faut livrer avec un système d’IA un jeu de tests, une fiche d’une page et la liste datée des décisions prises : sans ces trois pièces, le système ne survit pas au départ de celui qui l’a construit. Leur préparation dépend du périmètre et commence pendant le projet.

Le jeu de tests permet à la personne suivante de modifier sans casser. La fiche décrit finalité, données, décision servie et supervision. La liste des décisions consigne quel modèle pour quelle tâche, quel seuil, à quelle date.

Ces trois livrables sont ceux que je rends systématiquement en fin de mission, et leur contenu est détaillé dans les trois gestes qui font tenir un système. Ils correspondent à la façon de travailler décrite dans les métiers que j’exerce.

Les erreurs qui empêchent de sortir du prototype sont de commencer par l’interface, de valider sur un échantillon choisi, de laisser l’équipe technique juger seule la qualité et de découvrir le coût après l’engagement. Toutes reviennent à lever un verrou avant celui dont il dépend.

• Commencer par l’interface. Elle sera refaite quand on saura ce que le système sait réellement faire.
• Valider sur dix documents propres. Le corpus complet contient ce que l’échantillon cachait.
• Faire juger la qualité par ceux qui construisent. La mesure n’est pas opposable et ne convainc personne au moment de décider.
• Reporter la reprise à la fin. Le jour du départ du prestataire, personne ne sait modifier le système.