Le POC IA qui ne passera jamais en prod tel quel

C’est un signal qui revient régulièrement chez des entreprises sous SI Microsoft : un data scientist a construit un POC IA, la démonstration a convaincu en réunion, et six mois plus tard, ce POC tourne toujours exactement là où il a été créé, dans un notebook, sur le poste de son auteur. Personne d’autre ne peut le faire fonctionner. Ce n’est pas un problème de qualité du modèle. C’est un problème d’architecture.

Trois blocages reviennent systématiquement dans cette situation.

Le notebook n’est l’environnement de personne d’autre

Un POC construit dans un notebook s’appuie souvent sur des dépendances installées à la main, au fil des essais, sans fichier de configuration reproductible. Ça ne pose aucun problème tant que le POC reste une démonstration. Ça devient bloquant dès que quelqu’un d’autre, dans l’équipe qui gère l’application .NET en production, doit le déployer : reconstituer cet environnement à l’identique, sans documentation, prend souvent plus de temps que d’écrire une nouvelle version.

Le modèle attend une donnée que personne ne produit automatiquement

La plupart des POC fonctionnent sur un jeu de données déjà nettoyé à la main par le data scientist avant l’entraînement ou l’inférence. C’est un raccourci raisonnable en phase d’exploration. Mais rien, dans le système d’information existant, ne produit cette donnée propre automatiquement en production. Le POC suppose une étape de préparation qui n’a jamais été construite comme un vrai flux applicatif.

Le résultat ne parle à personne d’autre

Un POC affiche généralement son résultat dans la console, un fichier CSV, ou un graphique. Rien de tout ça n’est directement consommable par l’application .NET qui, elle, a réellement besoin de ce résultat pour agir : afficher une information à un utilisateur, déclencher une règle métier, alimenter un tableau de bord.

La méthode qui fonctionne

Le réflexe le plus courant, face à ces trois blocages, est de vouloir tout réécrire en C# pour que ça rentre proprement dans le SI existant. C’est rarement la bonne réponse : ça double le travail, et ça introduit un risque de divergence entre le comportement du modèle d’origine et sa réécriture.

La méthode qui fonctionne consiste à exposer le code Python tel quel derrière une API, dans un service conteneurisé indépendant, et à laisser l’application .NET l’appeler exactement comme elle appelle n’importe quel autre service du système d’information : mêmes contrats d’interface, mêmes journaux, même supervision, même cycle de déploiement que le reste. Le modèle garde son langage d’origine. Ce qui change, c’est qu’il entre dans les mêmes règles que tout le reste du SI, au lieu de rester une exception tolérée sur un poste individuel.

Industrialiser un POC IA, ce n’est pas migrer du code Python vers .NET. C’est faire entrer ce code, tel qu’il est, dans les mêmes règles que le reste du système.