Document de référence
Sortir un POC IA du purgatoire.
Le marché vend le pilote. Ce qui coûte cher arrive après : le pilote tourne depuis six mois sans passer en production, et personne ne tranche.
Romain Mougel · Ingénierie produit et systèmes IA · 29 juillet 2026
Le problème n’est presque jamais le modèle
Un pilote qui ne passe pas en production échoue rarement sur la performance du modèle. Il échoue sur les données réelles, sur l’intégration aux systèmes existants, sur l’exploitation continue, et sur l’adoption par des utilisateurs qui n’étaient pas dans le pilote.
Ces quatre sujets ont un point commun : aucun n’avait à être traité pour réussir la démonstration. Ils sont donc tous découverts après.
01
Les données réelles
Le pilote a tourné sur un extrait choisi, souvent nettoyé à la main. En production, la donnée arrive incomplète, mal typée, en retard, ou dans un référentiel auquel le compte de service n’a pas accès. L’écart entre les deux n’est presque jamais mesuré avant d’engager la suite.
- Rejouer le pilote sur un échantillon de production non retouché, et écrire ce qui casse.
02
L’intégration aux workflows
Le système fonctionne à côté du travail au lieu d’y entrer. Tant que l’utilisateur doit ouvrir un autre outil, copier un identifiant et recoller le résultat, l’usage se limite à ceux qui ont participé à la démonstration.
- Nommer l’écran, le formulaire ou l’étape exacte où le résultat apparaît.
03
L’exploitation
Personne n’a défini qui regarde le système, à quelle fréquence, sur quel signal, ni ce qui se passe quand le modèle change de version, quand l’API renvoie une erreur, ou quand la donnée source change de format. Le coût récurrent est rarement chiffré avant la mise en service.
- Désigner une personne, un signal, un seuil et une procédure de repli, avant le déploiement.
04
L’adoption
Les utilisateurs du pilote étaient volontaires et informés. Les suivants ne le sont pas. Rien n’a été prévu pour ce que le système change dans leur travail, ni pour ce qu’ils font quand il se trompe.
- Identifier la population réelle et ce que le système lui retire, pas seulement ce qu’il lui apporte.
Ce qu’il faut décider pour sortir
Une décision de passage en production tient en six points. S’ils sont écrits, la suite est chiffrable. S’ils ne le sont pas, aucun budget ne sera voté, et le pilote sera reconduit une fois de plus.
- Le cas d’usage retenu, un seul, et la métrique économique attendue
- L’écart mesuré entre les données du pilote et celles de production
- Le point d’entrée dans le workflow existant
- Le propriétaire métier et le superviseur du système en service
- Le coût récurrent estimé et le volume à partir duquel il devient un problème
- Ce qui se passe quand le système se trompe, et qui le corrige
Une définition vérifiable de « en production »
Un système est en production lorsque quatre conditions sont réunies en même temps : il est utilisé par de vrais utilisateurs dans leur travail, il est supervisé par une personne nommée, il est exploité (journaux, reprise sur erreur, coût suivi) et une métrique est relevée.
Une démonstration hebdomadaire, un accès réservé à l’équipe projet ou un pilote reconduit n’en remplissent aucune. Cette définition n’est pas une posture : elle détermine ce qu’il reste à financer.
Décider ne demande pas six mois
L’examen de ces points ne demande ni prototype, ni exploration exhaustive du système d’information. Un cas d’usage, quelques entretiens, l’analyse documentaire de l’existant, et la décision est rendue.
Voir le périmètre de la mise en production