Article
Pourquoi vos POC d'IA ne passent pas en production
Depuis deux ans, la plupart des entreprises que je rencontre ont lancé au moins une expérimentation d’IA générative : un assistant interne branché sur la documentation, un outil de synthèse de contrats, un agent qui qualifie les demandes clients. La démonstration est convaincante. Le comité de direction est enthousiaste. Six mois plus tard, le POC tourne toujours sur le poste de celui qui l’a construit.
Ce scénario est si fréquent qu’il ne relève plus de la malchance. Il a des causes, et elles sont presque toujours les mêmes. Aucune ne tient à la qualité du modèle.
1. Le POC a prouvé la mauvaise chose
Un POC répond à la question « est-ce que ça peut marcher ? ». La production pose une autre question : « est-ce que ça marche assez bien, assez souvent, pour assez de gens, à un coût acceptable ? »
La différence est énorme. Un assistant qui donne une bonne réponse huit fois sur dix fait une excellente démonstration. En production, les deux réponses fausses arrivent chez de vrais utilisateurs, qui perdent confiance en quelques jours.
Ce qu’il faut faire : fixer les critères de succès avant de construire. Quel taux de réponses correctes est acceptable ? Sur quel jeu de questions, représentatif de l’usage réel ? Qui juge ? Sans ces réponses, le POC ne prouve rien d’autre que l’enthousiasme de son équipe.
2. Les données n’étaient pas les vraies
Le POC a été construit sur un export propre, préparé à la main : quelques centaines de documents bien choisis, sans doublons, sans versions contradictoires, sans droits d’accès à gérer.
En production, il faut se connecter aux sources réelles : une GED avec quinze ans d’historique, un SharePoint où chaque service a sa logique, des documents confidentiels qu’un stagiaire ne doit pas pouvoir interroger. C’est souvent là que le projet s’arrête, parce que personne n’avait chiffré ce travail.
Ce qu’il faut faire : prototyper sur un échantillon des données réelles, avec leurs défauts, et traiter la question des droits d’accès dès le cadrage. Un assistant qui ignore les habilitations n’est pas un système en devenir : c’est une fuite de données en attente.
3. Personne n’a pensé à l’intégration
Le POC vit dans une application à part. Pour être utilisé, il doit pourtant s’insérer dans les outils du quotidien : authentification unique, interface déjà connue des utilisateurs, flux de données avec les applications métier, journalisation pour l’audit.
Chacun de ces points est un petit projet d’intégration. Ensemble, ils représentent souvent plus de travail que le POC lui-même.
Ce qu’il faut faire : dessiner l’architecture cible dès le cadrage, même grossièrement. Où le système s’insère-t-il ? Quelles API appelle-t-il ? Qui gère les identités ? Une heure passée sur ce schéma évite des mois de surprises.
4. Les coûts n’ont jamais été calculés
Pendant le POC, la facture de l’API du modèle est anecdotique. Multipliée par mille utilisateurs, par des documents longs injectés dans chaque requête, par des agents qui enchaînent dix appels pour une seule tâche, elle peut devenir le premier poste de dépense du projet.
Ce qu’il faut faire : estimer le coût par usage dès la phase de preuve, puis le concevoir : choix de modèles adaptés à chaque tâche, mise en cache, limitation du contexte, et parfois hébergement d’un modèle ouvert. Le coût d’un système d’IA se conçoit ; il ne se découvre pas sur la facture.
5. Il n’y a pas de propriétaire
Le POC a été porté par un sponsor enthousiaste et une petite équipe. Mais qui exploitera le système ? Qui surveillera la qualité des réponses dans le temps ? Qui décidera de changer de modèle quand le fournisseur en publiera un nouveau ? Qui répondra au DPO, au RSSI, puis demain aux exigences de l’AI Act ?
Sans réponse à ces questions, la DSI refuse — à raison — de mettre en production un système qu’elle ne saura pas maintenir.
Ce qu’il faut faire : désigner un propriétaire avant la mise en production, et lui donner les outils : observabilité, évaluation continue de la qualité, procédures d’exploitation.
Partir de la production, pas du prototype
Le point commun de ces cinq causes est simple : elles sont toutes prévisibles. On peut les traiter au moment du cadrage, avant d’avoir écrit une ligne de code, à condition de raisonner en architecte plutôt qu’en démonstrateur.
C’est la logique de la démarche que je propose : cadrer, prouver, architecturer, industrialiser, dans cet ordre, avec à chaque étape un livrable concret et la possibilité de s’arrêter si la valeur n’est pas au rendez-vous. Un projet arrêté au bon moment est aussi un succès : il a coûté peu et appris beaucoup.
Si vous avez un POC qui attend son passage en production, ou plusieurs dont vous ne savez pas lequel prioriser, c’est exactement le sujet d’un échange de cadrage.