De la preuve de concept à la production

La plupart des initiatives d’IA d’entreprise n’échouent pas parce que le modèle était mauvais. Elles échouent dans le fossé entre une démo convaincante et un système sur lequel l’organisation peut réellement compter.

Le schéma est connu. Une équipe construit une preuve de concept en quelques semaines. Ça marche en réunion. La direction est impressionnée. Puis le projet entre dans le long couloir entre le pilote et la production, et n’en ressort jamais. Le modèle qui éblouissait dans un notebook ne peut pas répondre aux questions d’une revue de sécurité, ne peut pas être surveillé et n’a pas de responsable clair. Le pilote devient discrètement un logiciel qui prend la poussière.

Le fossé relève d’une discipline d’ingénierie, pas d’une diapositive

Une démo optimise une seule chose : montrer qu’une idée est possible. Un système de production optimise tout autre chose : que l’idée soit fiable, gouvernée, observable et prise en charge. Ce ne sont pas le même problème, et le second est plus difficile que le premier.

C’est pourquoi le conseil en IA générative qui s’arrête au prototype apporte si peu à l’entreprise. Le prototype n’a jamais été la contrainte. La contrainte, c’est tout ce qui doit être vrai pour qu’une organisation réglementée place le système devant ses clients et assume ses décisions.

Le prototype n’a jamais été la contrainte. La contrainte, c’est tout ce qui doit être vrai pour le placer devant les clients.

Quatre artefacts qui font aboutir un système

01. Une piste d’audit

Chaque décision du système doit être journalisée, de façon immuable, avec les entrées et le raisonnement joints. Quand l’équipe sécurité demande « pourquoi a-t-il fait ça », la réponse doit être une requête, pas une réunion. La piste d’audit est aussi ce qui vous permet de déboguer, d’améliorer et de défendre le système après le lancement.

02. Une conception d’escalade

Un système de production connaît la limite de sa propre autorité. Il résout ce qu’il est autorisé à résoudre et achemine tout le reste vers une personne, avec tout le contexte. L’autonomie délimitée est ce qui rend un agent d’IA acceptable pour une fonction risques d’entreprise.

03. Un harnais d’évaluation

Avant le lancement, il vous faut un moyen propre à la tâche de mesurer si le système est assez bon ; et après le lancement, un moyen de prouver qu’un changement de modèle ou de prompt ne l’a pas discrètement dégradé. L’évaluation, c’est la différence entre livrer avec confiance et livrer avec espoir.

04. Un responsable nommé et un runbook

Quelqu’un dans l’organisation doit être responsable du système en production : ses SLA, ses modes de défaillance, son astreinte. Le passage de l’équipe de construction à l’équipe d’exploitation est l’endroit où de nombreux systèmes par ailleurs bons se dégradent. Rédigez le runbook avant d’en avoir besoin.

Budgétez le chemin, pas seulement le pilote

Le moyen le plus fiable de combler le fossé est de refuser de le traiter comme une réflexion après coup. Planifiez le chemin vers la production dès la première semaine. Construisez par incréments fonctionnels déployés dans l’environnement du client, testés face au harnais d’évaluation, revus avec les équipes sécurité et plateforme au fil de l’eau. Le travail de socle (orchestration, évaluation, surveillance, intégration) n’est pas une surcharge par-dessus le vrai travail. C’est le vrai travail.