Situation réelle

Une entreprise lance un POC IA en janvier. En trois semaines, l’équipe data produit un prototype fonctionnel : un système de recommandation qui tourne dans un notebook Jupyter, alimenté par un dump de données statiques. La démo impressionne le board. Le CEO veut le mettre en production « avant la fin du trimestre ». Six mois plus tard, le POC est toujours un POC. L’écart entre la démo et la production s’est avéré un gouffre.

Ce que j’ai observé : le POC IA est devenu un rituel dans beaucoup d’entreprises. Tout le monde en fait. Très peu passent en production. Et l’écart n’est presque jamais technologique — il est organisationnel, architectural et économique.

Le faux problème

La question habituelle : « Notre POC a marché, comment le mettre en prod ? »

En réalité, un POC qui « marche » ne prouve presque rien. Il prouve qu’un modèle peut produire un résultat acceptable sur un jeu de données statique, dans un environnement contrôlé, sans contrainte de latence, de scalabilité, de fiabilité ou de coût. C’est un bon début. Ce n’est pas une validation.

Le vrai enjeu CTO

Le vrai enjeu est de combler l’écart entre la démo et la production. Et cet écart se mesure sur cinq axes.

1. Les données

En POC, les données sont propres, statiques, disponibles. En production, elles arrivent en continu, avec du bruit, des doublons, des retards, des formats changeants. Le pipeline de données est souvent 80 % de l’effort de mise en production — et il n’existe pas dans le POC.

2. La fiabilité

En POC, si le modèle se trompe, on ajuste et on relance. En production, une erreur affecte des utilisateurs, des revenus, une réputation. La question n’est plus « est-ce que le modèle est bon ? » mais « que se passe-t-il quand il se trompe ? ».

3. Le coût

En POC, le coût est celui d’un notebook et d’une API. En production, c’est l’infrastructure de serving, le monitoring, le retraining, l’équipe de maintenance. Le coût de production est typiquement 5 à 20 fois supérieur au coût du POC.

4. L’intégration produit

Le POC vit dans un silo. La production s’intègre dans le produit, avec des contraintes d’UX, de latence, de fallback, de versioning. L’intégration est un projet d’ingénierie à part entière.

5. La gouvernance

En POC, personne ne se soucie de la conformité, de l’explicabilité des décisions, du biais du modèle. En production, ces questions deviennent légales et réglementaires.

Cadre de décision

  1. Ne pas promettre de date de mise en production au moment du POC. Le POC sert à valider l’intérêt. La mise en production est un projet séparé, avec son propre planning, son propre budget et ses propres critères de succès.

  2. Définir les critères de passage POC → production avant de commencer. Pas après. « Le POC est validé si le modèle atteint X % de précision sur Y jeu de données, si le coût de serving estimé est inférieur à Z, et si le pipeline de données est réalisable en moins de N semaines. »

  3. Impliquer l’ingénierie dès le POC. Un POC fait uniquement par l’équipe data produit un prototype. Un POC fait avec l’ingénierie produit un plan de mise en production. La différence se joue dès le premier sprint.

  4. Budgéter la production séparément. Le POC coûte 10K à 50K. La mise en production coûte 100K à 500K. Si le budget n’est prévu que pour le POC, le projet s’arrête au POC.

  5. Prévoir le fallback. Que se passe-t-il si le modèle est indisponible ? Si sa précision se dégrade ? Si les données d’entrée changent ? Le fallback n’est pas un cas exceptionnel — c’est un cas normal en production.

Retour terrain

Ce que j’ai constaté :

  • Les entreprises qui réussissent le passage POC → production ont un point commun : le CTO est impliqué dès le début, pas seulement à la phase « mettre en prod ».
  • Les POC qui ne passent jamais en production ont souvent été lancés sans critère de succès défini. La démo impressionne, puis personne ne sait quoi faire ensuite.
  • Le facteur le plus sous-estimé est le coût humain de maintenance. Un modèle en production demande du monitoring, du retraining, de la gestion de drift — c’est un investissement continu, pas un déploiement unique.

Erreurs fréquentes

  • Confondre POC validé et produit prêt. L’écart est immense. Le communiquer au board et au CEO est la responsabilité du CTO.
  • Laisser l’équipe data faire le POC seule. Sans l’ingénierie, le POC ne sera pas productionnable. Sans le produit, il ne sera pas utile.
  • Sous-estimer le pipeline de données. Le modèle est la partie visible. Le pipeline est la partie invisible — et c’est lui qui détermine la fiabilité en production.
  • Promettre un ROI avant la production. Le ROI d’un POC est zéro. Le ROI ne se mesure qu’après la mise en production, avec de vrais utilisateurs et de vraies données.

Si c’était à refaire

  • Je refuserais de lancer un POC sans avoir défini les critères de passage en production. Si les critères ne sont pas clairs, le POC est un exercice académique.
  • Je constituerais une équipe POC mixte : data + ingénierie + produit. Pas une équipe data isolée.
  • Je présenterais au board un plan en deux phases (POC + production) avec deux budgets distincts. Pas un plan unique qui promet la production au prix du POC.

Pour approfondir