Votre POC IA marche : pourquoi n’est-il toujours pas en production ?

Ce qu’un POC IA prouve, et ce qu’il ne prouve pas

Votre POC a répondu à une question précise : sur des exemples choisis, le modèle produit-il un résultat utile ? Si la démo a convaincu, la réponse est oui, et c’est une vraie information. Vous savez que l’idée tient.

Le POC n’a pas répondu aux autres questions, parce que personne ne les lui a posées. Il a souvent tourné sur un poste de développeur, avec un compte de test, devant une équipe qui savait quoi lui demander. Personne n’a regardé ce que coûtera le traitement d’un mois de dossiers, ni qui corrigera une mauvaise réponse.

Le malentendu commence souvent avec le mot lui-même. Dans ma première réunion avec la DSI de ce client, il a fallu préciser que « POC » désignait la première version d’un vrai projet, développée hors production, et non un essai qu’on jette ensuite. La nuance a changé l’échange. Une DSI ne s’engage pas sur un prototype. Elle s’engage sur un outil qu’elle devra héberger, surveiller et faire évoluer pendant des années.

Dites-le dès le départ pour gagner du temps : « nous testons une idée, et si elle tient, elle ira en production chez vous ». La DSI pose alors ses conditions au moment où elles coûtent le moins cher, avant le premier développement.

Le mot POC

Ce que la DSI entend quand vous dites « POC »

Essai jetable VS Vrai projet

Prototype

• Tourne sur un poste de développeur
• Compte de test
• Personne ne le maintient
• On le jette après

Première version

• Tourne sur la plateforme de la DSI
• Annuaire de l’entreprise
• Un responsable nommé
• On l’étend

Dites-le dès la première réunion

Les 5 écarts entre le POC IA et la mise en production

Le cas n’a rien d’isolé. En 2024, le cabinet d’études Gartner prévoyait qu’au moins 30 % des projets d’IA générative, celle de ChatGPT, seraient abandonnés après le POC d’ici fin 2025. C’était une prévision, pas un bilan mesuré. Les causes citées : la qualité des données, la maîtrise des risques, les coûts et une valeur métier floue. Aucune ne tient seulement au modèle. Un POC qui cale bute en général sur l’un de ces 5 écarts :

• Les données réelles. Le POC a tourné sur un échantillon choisi. La production reçoit le flux complet, avec ses cas limites et ses données personnelles.
• L’intégration au système d’information. L’outil doit vivre sur la plateforme de la DSI, avec les comptes de l’entreprise et les flux existants.
• Le coût à l’échelle. Le prix d’un dossier, multiplié par le volume réel, plus tout ce qui tourne autour du modèle.
• Le seuil d’acceptation. Des chiffres fixés avec le métier, qui disent à partir de quand l’outil est assez bon pour servir. La section sur les données réelles y revient.
• Le responsable du fonctionnement. Une personne qui voit les erreurs, les corrige et répond de l’outil une fois lancé.

Chaque écart a son propriétaire. Le métier fixe le seuil et fournit les dossiers réels. La DSI fixe le cadre technique. Le prestataire construit dans ce cadre. Un écart sans propriétaire nommé reste ouvert, et le projet attend.

Les 5 écarts

Les 5 écarts, et qui doit les fermer

MétierDSIPrestataire

Fournir des dossiers réels

Métier fait

DSI valide

Prestataire informé

Intégrer l’outil au système

Métier informé

DSI valide

Prestataire fait

Chiffrer le coût par dossier

Métier valide

DSI valide

Prestataire fait

Fixer le seuil d’acceptation

Métier fait

DSI aucun rôle

Prestataire informé

Porter le fonctionnement

Métier fait

DSI informé

Prestataire aucun rôle

• fait : réalise
• valide : décide et signe
• informé : est tenu au courant
• case vide : pas concerné

Les données réelles cassent le POC IA en premier

Votre échantillon de démo a été choisi pour montrer que l’idée fonctionne. Quelqu’un l’a sorti à la main, souvent en écartant les cas bizarres sans y penser. Le flux réel, lui, arrive tous les jours sans tri, et il contient souvent 4 choses que l’échantillon n’avait pas :

• Les trous. Des champs vides que l’échantillon n’avait pas, comme une date de naissance absente sur une partie des fiches.
• Les formats imposés. Un fichier dont la structure est fixée par un tiers, que personne chez vous ne peut changer.
• Les vrais cas difficiles. Des homonymes, des abréviations maison, des dossiers incomplets, rares dans un échantillon et fréquents dans le flux.
• Les données personnelles. Elles changent les règles du jeu : où tourne le modèle, qui voit quoi, ce qui est conservé.

Sur la mission que je décris, quelques alertes sont fondées pour plusieurs milliers reçues. Une démo, elle, montre surtout des alertes fondées : la proportion est inversée, et son taux de réussite ne dit presque rien de ce que l’outil fera en production.

Rejouez votre POC sur des dossiers réels, non triés. Si vos équipes n’ont pas le droit de les ouvrir, un jeu de test réaliste permet d’avancer, comme l’explique l’article sur les tests d’une IA sans données réelles. Il ne suffit pas pour décider.

Fixez le seuil avec le métier avant de rejouer, en 2 chiffres :

• La part minimale de vraies alertes que l’outil doit repérer, par exemple 99 sur 100.
• La part de fausses alertes qu’il doit écarter correctement.

Un seul taux de réussite vous tromperait : un outil qui classe tout en fausse alerte aurait presque toujours raison.

Intégration au SI : ce que la DSI exige avant la mise en production

Votre POC a souvent tourné hors de votre système d’information. L’outil en production, lui, devra y entrer, et c’est la DSI qui en tient les portes. Ses exigences ne sont ni des caprices ni des freins : elle répond de la sécurité de l’entreprise, et elle hébergera l’outil après le départ du prestataire.

Voici ce que la DSI de ce client a demandé, dans des termes courants chez les DSI. Les noms viennent de l’écosystème Microsoft et de son cloud, Azure, très répandus dans les entreprises de taille intermédiaire et les grands groupes. Chez vous, ce seront peut-être d’autres noms, mais les mêmes questions.

L’intégration

Ce que la DSI vous demandera avant la mise en production

A

Héberger l’outil sur la plateforme de la DSI

L’outil s’installe sur la plateforme d’hébergement que la DSI administre dans le cloud Azure de l’entreprise. Cette plateforme repose sur Kubernetes, l’outil standard qui fait tourner les applications sur ces serveurs. Une copie de l’outil sert aux essais, une autre au service réel, avec un accès réservé.

Qui fait quoi

La DSI fournit la plateforme. Le prestataire livre une application qui s’y installe.

À quel moment

Dès le début du développement, pas après la démo.

Si ça manque

Une application construite ailleurs peut être à reprendre en partie pour entrer dans le moule.

B

Se connecter avec le compte de l’entreprise

Le SSO, la connexion unique, passe par Entra ID, l’annuaire Microsoft où vivent les comptes des salariés. La double authentification, ou MFA, est obligatoire. Un système de connexion maison est refusé.

Qui fait quoi

La DSI inscrit l’application dans son annuaire et remet au prestataire les codes techniques de connexion. Le prestataire branche l’application dessus.

À quel moment

Dès le cadrage : la DSI a ses propres délais.

Si ça manque

Les essais avec les vrais comptes attendent.

C

Passer devant le comité d’architecture

Le comité d’architecture, l’instance de la DSI qui valide l’organisation technique de chaque nouvel outil, demande un document de bout en bout : chaque composant de l’outil, chaque flux de données entre eux, chaque prérequis demandé à la DSI.

Qui fait quoi

Le prestataire rédige le document. La DSI le valide.

À quel moment

Avant de déployer quoi que ce soit chez elle.

Si ça manque

Le projet attend le prochain passage du comité, à la date qu’il fixe.

D

Passer par la plateforme d’IA de son fournisseur de cloud

L’outil utilise le modèle à travers le service d’IA du fournisseur de cloud de l’entreprise, sous son contrat et ses réglages. Certains modèles sont exclus d’office. D’autres restent en attente de décision tant que la DSI n’a pas tranché.

Qui fait quoi

La DSI fixe la liste des modèles autorisés et leurs règles d’usage. Le prestataire choisit dans cette liste.

À quel moment

Avant de tester sur des données personnelles.

Si ça manque

Le modèle du POC n’est parfois pas disponible : il faut refaire les essais avec un autre.

E

Respecter les flux de données existants

Le format des fichiers, l’heure des envois, les outils où la décision doit être saisie : tout est déjà fixé, parfois par un tiers.

Qui fait quoi

La DSI décrit les flux et branche ses propres outils. Le prestataire s’y adapte.

À quel moment

Au cadrage, avant d’écrire l’intégration.

Si ça manque

L’outil produit un résultat que personne ne peut faire entrer dans le système.

F

Valider chaque mise en production à la main

Une personne de la DSI autorise chaque mise en service, selon son propre calendrier.

Qui fait quoi

La DSI valide. Le prestataire prépare des livraisons petites et documentées.

À quel moment

À chaque livraison, tant que cette règle s’applique.

Si ça manque

Une correction urgente attend le prochain créneau de validation.

La connexion est l’exigence qui surprend le plus. Une DSI impose souvent son annuaire, Entra ID chez Microsoft, avec la double authentification. Pour vous, la nouvelle est bonne : vos équipes gardent leur compte habituel, sans nouveau mot de passe. Il reste à décider qui a accès à quoi. En contrepartie, vos équipes ne peuvent pas se connecter tant que la DSI n’a pas inscrit l’application dans son annuaire. Elle remet alors au prestataire les codes techniques qui relient l’application à cet annuaire. Demandez cette inscription dès le cadrage.

En attendant les codes, le prestataire développe avec une connexion de test, utilisée seulement sur ses propres postes. Si l’application est prévue pour, il la remplace ensuite par l’annuaire de l’entreprise sans la réécrire. Faites tout de même un essai complet avant la mise en service.

Le choix du modèle vous concerne aussi. Le modèle utilisé pendant le POC n’est pas forcément autorisé en production. Votre DSI peut exiger que vous utilisiez le service d’IA de son fournisseur de cloud, Microsoft par exemple, qui donne accès à plusieurs modèles sous le contrat de l’entreprise. Elle peut aussi en exclure certains d’office. Quand les données sont personnelles, cette prudence est fondée. Prévoyez de refaire les essais avec le modèle autorisé : les résultats peuvent changer.

Le système existant pose enfin la contrainte la plus concrète. Sur cette mission, la décision finale doit être saisie à la main dans un outil tiers, sur un poste séparé du reste du système. La DSI déconseille fortement que l’outil d’IA écrive directement dans la base de données du système central de l’entreprise, et ce système ne prévoit aucun moyen d’y enregistrer une décision depuis un autre logiciel. La solution retenue reste simple : l’outil prépare une proposition, l’analyste la relit, la valide et la reporte lui-même.

Une proposition que l’humain valide et reporte a l’air d’un compromis. Pour démarrer, c’est souvent la meilleure option. Vous mettez l’outil en service sans attendre un chantier d’intégration qui ne dépend pas de vous, et une personne contrôle chaque décision, à condition de lui laisser le temps de relire. Trouver ce genre de compromis est le travail de l’ingénieur qui s’installe chez le client pour transformer un besoin d’IA en outil utilisable, décrit dans l’article sur le Forward Deployed Engineer. La méthode pour obtenir l’accord de votre DSI est dans l’article sur la DSI qui refuse votre outil métier.

Combien coûte l’IA en production, par dossier traité

Pendant le POC, le coût du modèle était invisible : un petit nombre d’appels, noyés dans une facture. En production, chaque dossier traité coûte, chaque jour, et le total dépend d’un volume que la démo n’a jamais mesuré.

Le coût

Le POC ne montre que la première marche du coût

1. Ce que montre le POC

   Marche 1

   1 appel au modèle

   Une question posée au modèle, le plus souvent facturée selon la longueur du texte.

2. Marche 2

   1 dossier traité

   Plusieurs appels : chercher, comparer, rédiger, relancer.

3. Marche 3

   Le volume du mois

   Les dossiers réellement reçus, pas ceux de la démo.

4. Ce qu’il faut chiffrer

   Marche 4

   Le budget de fonctionnement

   Plus l’hébergement, la surveillance et le temps de validation.

Le volume change aussi la construction de l’outil, pas seulement la facture. Sur la mission que je décris, un seul fichier quotidien peut contenir plusieurs centaines d’alertes. L’outil doit les traiter en arrière-plan : l’utilisateur n’attend pas devant son écran. Il en traite plusieurs à la fois, dans la limite d’appels que fixe le service d’IA, et relance celles qui échouent. Ce travail est souvent absent d’un POC, et il faut le budgéter.

Comparez ensuite votre coût, obtenu avec le schéma, à votre gain visé. Si le gain est mesuré en temps, vérifiez que ce temps libéré servira à autre chose.

Le gain n’est pas toujours du temps. Sur cette mission, le temps économisé reste modeste à l’échelle de l’entreprise, trop faible pour justifier le projet à lui seul. La direction métier le porte pour une autre raison : la qualité, et la réduction du risque qu’une vraie alerte passe inaperçue. Écrivez le gain que vous visez, et mesurez celui-là.

Qui répond quand l’IA se trompe en production

Votre outil se trompera. La question est de savoir qui le verra, qui corrigera, et qui en répondra devant vous. Dans un POC, personne ne se pose la question. En production, chaque erreur engage un dossier réel.

Sur cette mission, la réponse tient dans la conception de l’outil. Il ne décide pas. Il prépare une proposition et indique à quel point il s’estime sûr de lui. Cette indication aide à choisir quoi relire en premier ; elle ne remplace pas la vérification. L’analyste valide ou corrige chaque proposition. Les propositions validées seront conservées pour une durée fixée avec la DSI et celui qui porte le RGPD chez vous, et montrées à l’outil quand un cas semblable revient. Le modèle lui-même n’est pas réentraîné : on lui montre ces exemples au moment de répondre. Un humain garde la main sur chaque décision.

Nommez un responsable du fonctionnement, côté métier ou côté DSI, avec du temps réservé. Il assure la supervision de l’outil, c’est-à-dire sa surveillance au quotidien, en 3 tâches :

• Regarder les erreurs signalées par les utilisateurs et les classer, et vérifier de temps en temps que les propositions ne sont pas validées machinalement.
• Décider de ce qui se corrige : une règle métier à préciser, une consigne donnée au modèle, un cas à exclure.
• Vérifier, après chaque mise à jour du modèle par son fournisseur, que les 2 chiffres du seuil tiennent toujours.

Sans cette personne, l’outil peut se dégrader en silence, et vos équipes cessent de lui faire confiance avant que quelqu’un s’en aperçoive. Les consignes et les contrôles qui encadrent un modèle forment ce qu’on appelle son harness, détaillé dans l’article consacré au harness. Ces consignes et contrôles sont des fichiers : gardez-les dans l’espace où est stocké le code de l’outil, chez vous, pour qu’un changement de prestataire ne les emporte pas.

Passer en production, recadrer ou arrêter le POC IA

Vous n’avez pas à choisir entre « tout investir » et « tout jeter » : votre POC a 3 issues possibles. Ces 3 questions vous y mènent, dans l’ordre :

La décision

Passer en production, recadrer ou arrêter le POC IA

1. 1Sur un lot de dossiers réels, l’outil atteint-il le seuil fixé avec le métier ?

   Si non : recadrer

   Réduisez le périmètre aux cas que l’outil traite bien, ou revoyez les règles métier qu’il applique. Si aucun périmètre utile n’atteint le seuil, arrêtez.

2. 2La DSI a-t-elle validé un chemin : hébergement, connexion, modèle autorisé, flux ?

   Si non : recadrer

   Simplifiez l’intégration. Une proposition que l’utilisateur valide puis reporte lui-même peut suffire à démarrer, sans écrire dans le système existant. Si aucun chemin n’est accepté, arrêtez.

3. 3Le gain visé justifie-t-il le coût de fonctionnement réel ? *

   Si non : arrêter

   Vérifiez d’abord qu’un périmètre plus petit ne changerait pas le calcul. Sinon, documentez ce que vous avez appris et arrêtez proprement.

   * Le retour sur investissement se calcule normalement avant le POC : le gain visé, en temps, en qualité ou en risque évité, face au coût prévu. Si personne ne l’a fait, faites-le maintenant, avant de lire les résultats. La méthode est détaillée dans l’article sur le Forward Deployed Engineer.

3 « oui » : passez en production, sur un premier périmètre réduit, avec le seuil, le budget et le responsable écrits noir sur blanc.

Un périmètre réduit qui tourne en production vaut mieux qu’un périmètre complet qui attend. Si vous arrêtez, gardez ce que le POC a appris : le seuil, les données de test, les exigences de votre DSI. Le projet suivant partira de là.

Votre système d’information a aussi son propre calendrier. Une migration ou un changement d’outil peut repousser l’intégration complète, sans rapport avec la qualité de votre projet d’IA. Démarrez alors avec une intégration légère, et branchez le reste quand le système sera prêt.

Mettre un POC IA en production : la séquence, dans l’ordre

Suivez ces étapes dans l’ordre avant de voter le budget de la suite. Elles demandent surtout des réponses écrites, et une personne pour les obtenir, plutôt qu’un profil de technicien :

1. 1Écrivez le seuil avant de rejouer quoi que ce soit. Avec le métier, fixez les 2 chiffres du seuil décrits plus haut. Sans eux, aucune décision n’est possible.
2. 2Rejouez le POC sur un lot de dossiers réels. Choisissez des dossiers que personne n’a triés, avec leurs trous et leurs cas difficiles. Comparez au seuil.
3. 3Envoyez à la DSI les 6 exigences du schéma « Ce que la DSI vous demandera ». Hébergement, connexion, comité d’architecture, modèle, flux, validation : pour chacune, demandez une réponse écrite.
4. 4Calculez le coût d’un dossier correctement traité. Montez les 4 marches du schéma sur le coût, avec votre volume du mois.
5. 5Nommez le responsable du fonctionnement. Une personne, avec du temps réservé, qui suit les erreurs et décide des corrections.
6. 6Décidez avec les 3 questions du dernier schéma. Passer en production, recadrer ou arrêter, et écrivez la raison.
7. 7Si vous passez en production, commencez petit. Un périmètre réduit, une équipe, quelques semaines de mesure, puis l’extension.

Votre prestataire et votre DSI gardent leurs rôles. Vous gagnez une décision fondée sur des faits, plutôt que sur le souvenir d’une démo réussie.

Questions fréquentes sur le POC IA et la mise en production

Sources et documentation

Les exigences de la DSI et le cas présenté viennent d’une mission en cours, volontairement anonymisée. L’outil n’était pas encore en production à la date de publication. Les références suivantes ont été consultées le 9 octobre 2026.

• Gartner, prévision sur l’abandon des projets d’IA générative après le POC, reprise par Intelligent CIO, 5 août 2024 ↗