Le pattern qui se répète
Depuis deux ans, je pose la même question aux DSI, directeurs R&D et responsables IA que je rencontre dans l'industrie réglementée :
"Quel est le dernier projet IA que votre organisation a arrêté — et pour quelle raison exacte ?"
Les réponses varient dans les détails. La structure est toujours la même : "Le POC était impressionnant. L'équipe technique était convaincue. Et puis ça a bloqué — le RSSI, le DPO, la Direction Qualité, le Responsable Affaires Réglementaires. Et le projet est mort."
Ce n'est pas un problème de technologie. Ce n'est pas un problème de compétences. C'est un problème de séquençage : les contraintes de production n'ont pas été intégrées dans la conception du POC.
Le problème de fond
Un POC optimisé pour convaincre maximise l'impression de performance sur des questions de démonstration, dans un environnement contrôlé, sans les contraintes réelles de production. C'est rationnel — personne ne finance un projet qui ne passe pas le stade de la démonstration. Mais cela crée un biais structurel : on démontre ce qui impressionne, pas ce qui fonctionne en conditions réelles.
Les équipes qui réussissent le passage en production font l'inverse. Elles conçoivent le POC comme une mini-production : même architecture cible, même niveau de contraintes, périmètre réduit. La démonstration est moins spectaculaire. Le passage en production est beaucoup plus fluide.
Ce qu'un POC mesure — et ce qu'il ne mesure pas
Un POC IA bien conduit mesure généralement :
- La performance sur des questions de test (précision, rappel, temps de réponse)
- La facilité d'utilisation perçue par les utilisateurs métier
- La faisabilité technique sur le corpus cible
Ce qu'il ne mesure presque jamais :
- La traçabilité de chaque réponse jusqu'à sa source primaire
- La cohérence des réponses entre deux sessions
- La conformité avec les référentiels d'intégrité des données (ALCOA+ en pharma)
- Le flux des données (où partent-elles ? qui y accède ? qui peut les lire ?)
Ces dimensions ne sont pas des contraintes secondaires. Ce sont les conditions de passage en production dans un environnement réglementé.
Les quatre blocages les plus fréquents — et leur vraie cause
Ce qu'on entend : "On ne peut pas envoyer nos données sur un service cloud externe."
La vraie cause : Le POC a été construit sur une architecture cloud (API OpenAI, Azure OpenAI, Google Vertex…) parce que c'est le chemin le plus rapide pour démontrer la performance. Le RSSI applique correctement les règles de souveraineté des données — qui existaient avant le POC et qui n'ont pas changé.
Ce qui aurait dû être fait : Partir d'une architecture on-premise dès le POC. Oui, c'est plus long. Non, ce n'est pas une raison de l'ignorer si on sait que c'est une contrainte non négociable.
Ce qu'on entend : "On ne peut pas utiliser un système dont on ne contrôle pas les données d'entrée et de sortie."
La vraie cause : Un LLM en production laisse des traces d'utilisation chez le fournisseur cloud. La politique RGPD de l'organisation interdit ce type de transfert sans garanties contractuelles spécifiques — souvent impossibles à obtenir aux conditions des grands fournisseurs cloud IA.
Ce qui aurait dû être fait : Architecture on-premise + audit trail interne des requêtes dès la conception.
Ce qu'on entend : "Un inspecteur ANSM / ASN / DGAC va nous demander d'où vient chaque information dans ce rapport. On ne peut pas répondre."
La vraie cause : Le système RAG génère des réponses qui synthétisent plusieurs sources. Il ne peut pas garantir que l'élément X provient du document Y, section Z. Structurellement incompatible avec ALCOA+ et avec les exigences d'audit des secteurs régulés.
Ce qui aurait dû être fait : Choisir une architecture qui cite ses sources de manière exacte et vérifiable — pas une architecture qui "synthétise avec références approximatives".
Ce qu'on entend : "La même question posée deux fois peut donner deux réponses différentes. On ne peut pas soumettre ça à un régulateur."
La vraie cause : Les LLM sont probabilistes par nature. La même requête avec un contexte légèrement différent peut produire une réponse différente. En environnement réglementaire, une réponse doit être reproductible et identique indépendamment de qui la pose et quand.
Ce qui aurait dû être fait : Architecture déterministe (graphe de connaissance) pour les requêtes réglementaires factuelles, LLM cantonné à la mise en forme si nécessaire.
Comment concevoir un POC qui passe en production
01Cartographier les contraintes de production avant de choisir l'architecture
Les données sont-elles soumises à ITAR ? → on-premise obligatoire. Le système sera-t-il audité ? → traçabilité exacte obligatoire. Les réponses engagent-elles la conformité ? → architecture déterministe.
02Inclure RSSI, DPO et Direction Qualité dans la phase de conception
Ces fonctions ne sont pas des obstacles. Ce sont des gardiens de contraintes que l'organisation doit respecter. Les intégrer en amont permet de concevoir une architecture compatible — pas de se heurter à un veto en phase de passage en production.
03Mesurer les critères de production pendant le POC
En plus des métriques de performance habituelles, mesurer : peut-on citer le document source exact pour chaque réponse ? La même question deux fois donne-t-elle la même réponse ? Peut-on retracer la chaîne complète lors d'un audit simulé ?
04Choisir l'architecture selon les contraintes, pas selon la vitesse de déploiement
Un RAG se déploie plus vite. Un graphe de connaissance est plus long à construire. Si les contraintes de production exigent un graphe, déployer un RAG rapidement ne fait que reculer le problème — et ajouter un coût de migration.
Les quatre questions à poser au prochain POC
- « Où tournent les modèles ? Dans le cloud de qui ? » Si les modèles tournent dans le cloud, vérifiez la compatibilité avec vos règles de souveraineté avant d'approuver.
- « Pour chaque réponse produite, peut-on citer le document source exact ? » Si non, demandez comment ce point sera résolu avant la production.
- « En posant la même question deux fois, obtient-on la même réponse ? » Si non, demandez quelle garantie de cohérence est offerte.
- « Le RSSI, le DPO et la Direction Qualité ont-ils validé l'architecture — pas juste les résultats ? » Si non, demandez qu'ils soient inclus avant le passage en production.
Ces questions ne ralentissent pas les projets qui peuvent passer en production. Elles révèlent tôt ceux qui ne le peuvent pas.