De la preuve de concept à la production : ce qui change vraiment dans un projet d'IA

Pourquoi tant de projets d'IA s'arrêtent-ils à la démo ?

Parce qu'une preuve de concept répond à une question très différente de celle de la production. La POC demande : « est-ce que le modèle peut le faire ? ». La production demande : « est-ce que l'organisation peut compter dessus, tous les jours, à un coût acceptable, et le faire évoluer ? ».

La première question se résout avec un bon modèle et un échantillon de données propres. La seconde fait intervenir tout le reste : les vraies données, les utilisateurs, les droits d'accès, la conformité, l'infrastructure, le budget et surtout l'équipe qui devra maintenir le système. Quand un projet reste bloqué après une démonstration réussie, c'est presque toujours sur l'un de ces points, rarement sur le modèle.

Qu'est-ce qui change entre une POC et un système en production ?

• Les données. L'échantillon de la démo était choisi. En production arrivent des scans de travers, des documents multilingues, des champs vides, des formats inattendus.
• Les cas limites. Un modèle peut se tromper avec assurance. En démonstration, on ne le voit pas ; en production, quelqu'un prend une décision sur cette erreur.
• Le coût. Une requête à un grand modèle coûte peu ; cent mille par mois, beaucoup plus. L'inférence devient une ligne budgétaire.
• La responsabilité. Il faut pouvoir expliquer d'où vient une réponse, qui l'a validée, et ce qui s'est passé quand elle était fausse.
• La durée. Les modèles, les données et les besoins changent. Un système qui ne peut pas évoluer devient une dette.

Comment cadrer un projet d'IA pour qu'il arrive en production ?

En traitant la production comme une exigence dès le premier jour, et non comme une étape finale. Concrètement, avant d'écrire une ligne de code, je cherche à établir quatre choses :

1. Le critère de succès métier. Pas « 95 % de précision », mais « le temps de traitement d'un dossier passe de deux heures à vingt minutes, avec validation humaine ».
2. Les contraintes. Budget, conformité, infrastructure disponible, confidentialité des données. Ce ne sont pas des obstacles : ce sont les données d'entrée de l'architecture.
3. Le périmètre minimal utile. Le plus petit système qui apporte une valeur réelle à de vrais utilisateurs.
4. Le propriétaire. Qui exploitera le système après le projet, et ce qu'il doit savoir pour le faire.

Ce cadrage prend généralement peu de temps, et il évite des mois de travail sur un système que personne ne pourra mettre en service.

Quelle architecture pour un système d'IA qui dure ?

Le principe que j'applique dans tous mes projets : l'IA dans le système, pas un système autour de l'IA. Le modèle est un composant, avec un contrat d'entrée et de sortie comme les autres. Autour de lui, des étapes déterministes préparent les données et vérifient les résultats.

Dans un système d'extraction documentaire multilingue, par exemple, plusieurs agents au périmètre étroit se partagent le travail — lire, classer, extraire — et une étape de contrôle déterministe vérifie la cohérence avant que la donnée ne soit livrée. Chaque agent se teste et se corrige séparément. C'est moins spectaculaire qu'un modèle unique « qui fait tout », mais c'est ce qui permet de fiabiliser le système.

Même logique dans un pipeline de médecine de précision : chaque étape, de l'analyse des variants jusqu'au rapport, produit un résultat intermédiaire inspectable. Le modèle de langage rédige le rapport final, il ne décide pas ; la décision reste humaine.

Qui maintiendra le système ?

C'est la question la plus souvent oubliée, et celle qui fait échouer le plus de projets. Un système d'IA livré à une équipe qui ne le comprend pas est un système en sursis.

Trois pratiques font la différence :

• Écrire les décisions d'architecture avec leur raison : pourquoi ce modèle, pourquoi ce découpage, quelles alternatives ont été écartées.
• Faire participer l'équipe dès la conception. Sur mes projets, une grande partie de l'équipe est composée de profils juniors : les impliquer tôt est ce qui les rend autonomes à la fin.
• Prévoir la passation comme un livrable à part entière, avec documentation et transfert de compétences.

Une liste de contrôle avant de dire « c'est en production »

• Le critère de succès métier est mesuré, pas seulement estimé.
• Les erreurs du modèle sont détectées par une étape de contrôle ou par un humain.
• Chaque résultat peut être retracé jusqu'à ses données d'entrée.
• Le coût d'exploitation est connu et accepté.
• Les droits d'accès aux données sont respectés de bout en bout.
• Une personne de l'équipe, autre que l'auteur, sait faire évoluer le système.

En résumé

Passer de la POC à la production n'est pas une question de meilleur modèle. C'est une question de cadrage, d'architecture et d'équipe. Une transformation IA réussie enchaîne de petits systèmes fiables plutôt qu'un grand projet spectaculaire — et elle se juge six mois après la démo, quand le système tourne toujours et que l'équipe sait pourquoi.

Pour aller plus loin : mon approche de la transformation IA et de l'architecture de systèmes d'IA.