Pourquoi les POC IA n’arrivent jamais en production ?
Un POC d’IA s’arrête parce qu’il a été conçu pour convaincre, pas pour tourner : pas de jeu d’évaluation, pas de règles d’exploitation, pas de propriétaire. Gartner prévoyait qu’au moins 30 % des projets d’IA générative seraient abandonnés après la preuve de concept. La production se prépare dès le cadrage, ou elle n’arrive pas.
Combien de POC meurent, et pourquoi, selon ceux qui ont regardé ?
Deux sources, toutes deux datées, toutes deux publiques.
Gartner a publié le 29 juillet 2024 une prédiction : au moins 30 % des projets d’IA générative seraient abandonnés après la preuve de concept d’ici fin 2025. Quatre causes nommées : qualité des données insuffisante, contrôle des risques inadéquat, coûts qui dérapent, valeur métier floue. Le même communiqué note que les coûts de l’IA générative sont moins prévisibles que ceux des autres technologies, et que les directions financières supportent mal d’investir aujourd’hui pour une valeur indirecte demain.
RAND a publié le 13 août 2024 une étude fondée sur 65 entretiens avec des ingénieurs et data scientists ayant au moins cinq ans de pratique. Elle rappelle une estimation courante, plus de 80 % des projets d’IA qui échouent, soit deux fois le taux des projets informatiques sans IA, et dégage cinq causes racines. Les deux premières suffisent à décrire la plupart des POC que j’ai vus passer : le problème à résoudre est mal compris ou mal communiqué, et le modèle est optimisé pour la mauvaise mesure ou ne s’insère pas dans le flux de travail réel ; l’organisation n’a pas l’infrastructure pour gérer ses données et déployer le modèle terminé.
Aucun de ces rapports ne dit que les modèles sont mauvais. Ils disent que le problème est mal posé, que les données ne sont pas prêtes, et que personne n’a prévu l’exploitation. Trois défauts qui existent avant la première ligne de code.
Pourquoi la démonstration ment-elle sans mentir ?
Un POC est optimisé pour la réunion où on le montre. Les questions ont été choisies parce qu’elles marchent. Le corpus a été nettoyé la veille. La personne qui tape sait ce qu’il faut demander et comment le formuler. Rien de tout cela n’est une tromperie : c’est ce qu’on fait quand on prépare une démonstration.
En production, les questions viennent de gens pressés, formulées avec les mots de leur métier, souvent avec une faute ou un sigle interne. Les documents sont ceux qui existent, avec leurs doublons, leurs versions contradictoires et leurs PDF scannés de travers. Le système qui répondait juste à dix questions préparées répond à côté sur la onzième, et personne ne sait pourquoi, parce que rien n’a été mesuré.
La démonstration a prouvé que la technologie peut fonctionner. Elle n’a rien dit sur ce qu’il faut pour qu’elle fonctionne chez vous, sur vos documents, pour vos utilisateurs, un mardi à 9 h.
Qu’est-ce qu’un système en production, vu de l’exploitation ?
J’ai passé neuf ans en support, en exploitation et en ITSM dans de grands groupes, dans les médias puis les télécoms, avant de faire de l’IA. Un système en production, vu de là, n’est pas un système qui marche : c’est un système dont on sait quoi faire quand il ne marche plus.
Il a un propriétaire, quelqu’un dont c’est le travail de répondre. Il a une fenêtre de changement : on ne le modifie pas un vendredi soir. Il a une supervision qui dit s’il est vivant, et une journalisation qui dit ce qu’il a fait. Il a une procédure de reprise, testée, et une documentation que quelqu’un d’autre que son auteur peut suivre. Et quelqu’un décroche quand ça casse un lundi matin.
Un POC n’a rien de tout ça, et c’est normal : ce n’est pas son rôle. Le problème n’est pas qu’il en soit dépourvu, c’est que personne n’ait prévu de le lui donner. Le passage en production n’est pas une étape après le POC. C’est un ensemble de conditions qui se décident avant, et qui coûtent : quand elles n’ont pas été budgétées, le POC reste un POC, et il finit par être éteint sans bruit.
Une DSI qui a déjà mis en production un outil métier sait tout cela. Ce qui change avec l’IA, c’est qu’un modèle ne se comporte pas de façon déterministe, et qu’il faut donc ajouter à la liste une chose que les applications classiques n’ont pas : une mesure de la justesse des réponses, rejouée à chaque changement.
Que se passe-t-il quand un système d’IA tourne sans garde-fou ?
Je peux le raconter sur un système que je fais tourner moi-même. Ce site publie des brouillons d’articles produits par un pipeline automatisé, à partir de mes dépôts de code publics. Lors d’un essai, le pipeline a produit un article à partir d’un seul commit. Le résultat était fluide, structuré, et inventé : le modèle avait comblé le vide avec du plausible. Personne ne l’a lu avant moi, parce que rien n’est publié sans relecture, mais le texte existait, et il avait l’air vrai.
La correction n’a pas été un meilleur prompt. Elle a été une condition d’entrée, au moins trois commits avant de rédiger, et un contrôle de sortie, une relecture de fidélité qui confronte chaque phrase factuelle à sa source et retire celles qui n’en ont pas. Le tout est consigné dans le registre des systèmes d’IA que je tiens pour ce site.
C’est la différence entre un système génératif en démonstration et le même système en production. En démonstration, on regarde la sortie et on la trouve bonne. En production, on définit ce qui a le droit d’entrer, ce qui a le droit de sortir, et ce qui se passe quand la sortie n’est pas conforme. Un modèle sans ces trois choses n’est pas en production, quel que soit l’endroit où il tourne.
Pourquoi le jeu d’évaluation est-il la frontière entre POC et production ?
Parce que sans lui, personne ne peut répondre à la question la plus simple : la version de lundi est-elle meilleure que celle de vendredi ?
Un jeu d’évaluation, c’est une liste de questions réelles, la réponse attendue, le document qui la contient, validés par les utilisateurs. Sur Mnemo, mon moteur de recherche sur mes propres notes, j’ai écrit vingt requêtes avant de comparer deux modèles d’embeddings, et un script qui mesure si le bon passage arrive en tête. Le banc est rejoué à chaque changement, et chaque exécution laisse un rapport daté. C’est un projet personnel, à petite échelle, mais c’est exactement le geste qui manque à la plupart des POC : la mesure est écrite avant, pas après, et elle survit à la démonstration.
Ce jeu d’évaluation a une autre vertu : il oblige à parler aux utilisateurs avant de construire. Un POC spécifié par la direction seule produit un outil que personne n’ouvre. Trente questions validées par les personnes qui les poseront valent plus que trente pages de cahier des charges.
À quoi ressemble un prototype conçu pour la production ?
À un service, pas à une démonstration. Mnemo, toujours lui, a une sonde de santé qui vérifie ses quatre dépendances en parallèle et rend leur latence, des métriques exposées à un outil de supervision, des instantanés quotidiens de la base, un tableau de bord, et un service qui réindexe une note modifiée en quelques secondes. Rien de tout cela n’améliore la qualité des réponses. Tout cela fait la différence entre quelque chose qu’on montre et quelque chose qui tourne sans qu’on le surveille.
Le prototype conçu pour la production est restreint dans son périmètre, un corpus limité, un groupe d’utilisateurs identifié, mais complet dans sa forme : branché sur les vraies sources avec les vrais droits d’accès, mesuré, supervisé, documenté. On peut l’éteindre sans regret s’il ne convainc pas. On peut l’étendre sans le réécrire s’il convainc.
Comment cadrer pour que le POC ait une suite ?
Cinq conditions, à écrire avant de commencer. Si l’une manque, le POC s’arrêtera après la réunion, et ce sera prévisible.
- Un propriétaire côté métier, nommé, qui répond de l’utilité de l’outil et qui a du temps pour valider.
- Un jeu d’évaluation validé par les futurs utilisateurs, avant tout développement.
- Les sources et les droits d’accès réels, sur un périmètre restreint mais vrai.
- Le mode d’exploitation cible : qui supervise, qui reprend, dans quelle fenêtre, avec quel budget d’inférence.
- Un critère d’arrêt chiffré : le seuil de justesse en dessous duquel on n’industrialise pas, et la date à laquelle on décide.
C’est le contenu d’un cadrage de quelques jours, et son livrable reste utile même si la réponse est de ne pas poursuivre. La plupart des POC morts n’ont pas échoué : ils n’ont jamais eu de suite prévue. Si vous en avez un qui dort, ou un projet qui commence, décrivez votre cas d’usage : la première question sera de savoir laquelle des cinq conditions manque.