Pourquoi la plupart des projets IA meurent entre le POC et la production

Le secret mal gardé de l’IA en entreprise : les modèles fonctionnent. Les systèmes autour, non.

Le scénario typique. Une démo brillante au printemps. Un pilote en été. À l’automne, l’agent hallucine devant les clients, les coûts sont 4× supérieurs aux estimations, personne n’est d’astreinte quand ça casse à 2h du matin, et le projet disparaît discrètement du prochain comité.

Les modèles ne sont pas le problème. Les systèmes qui les entourent le sont.

Ce que « production-grade » veut vraiment dire

Quand on parle d’IA production-grade, on parle d’un système IA qui :

• A une disponibilité mesurable — et quelqu’un de responsable quand ça casse
• A un modèle de coût qui tient à 10× le trafic actuel
• A des évaluations qui détectent les régressions avant qu’elles n’atteignent les utilisateurs
• A de l’observabilité sur chaque appel modèle, chaque tool-use, chaque retry
• A un processus de release — prompts versionnés, modèles versionnés, rollback en une commande

Ce n’est pas glamour. C’est précisément pour ça que la plupart des équipes le sautent.

Le gap

La plupart des initiatives IA bloquent à la même frontière : le prototype fonctionne sur un dataset de démo, dans un scénario contrôlé, sans vrais utilisateurs. Puis l’équipe essaie de le déployer.

C’est là que la réalité atterrit. Cas limites. Drift. Pics de coût. Hallucinations dans les flux orientés client. Aucun moyen de déboguer « pourquoi a-t-il fait ça ? » trois semaines plus tard.

Le correctif n’est pas un meilleur modèle. C’est l’infrastructure ennuyeuse autour du modèle.

Les symptômes qu’on rencontre sur le terrain

Trois schémas reviennent presque à chaque fois.

Le modèle de coût qui ne survit pas au monde réel. Une équipe choisit un prompt qui marche à 100 appels par jour. À 10 000 appels par jour, la facture LLM devient un sujet de comité de direction. Personne n’avait prévu le batching, le caching, le model routing, ou un budget de contexte — parce qu’à l’échelle du POC, rien de tout ça n’avait d’importance.

Le trou dans les évaluations. Personne n’a de définition claire de « l’agent fait correctement son travail ». Donc quand les prompts changent, les modèles changent, ou les données amont bougent, le système se dégrade silencieusement. Les utilisateurs s’en rendent compte avant l’équipe. À ce moment-là, deux semaines de mauvaises sorties sont déjà parties en production.

La question de 2h du matin. Quand l’agent fait quelque chose de bizarre en prod, l’ingénieur d’astreinte n’a aucun moyen de reconstruire ce qui s’est passé. Pas de traces, pas de logs par appel, pas d’historique de tool-use. Le « correctif » : « on relance et on voit ». Ce n’est pas un système, c’est une prière.

À quoi ça ressemble une fois que ça marche

Un vrai système IA en production est ennuyeux exactement comme il faut. Chaque appel modèle a une trace. Chaque prompt et chaque modèle est versionné. Une suite d’évaluations de régression tourne dans la CI avant le moindre changement de prompt. Le coût par résultat métier est mesuré, pas le coût par token. Une procédure de rollback existe, écrite, testée au moins une fois.

Vous ne remarquez pas qu’elle est là. C’est précisément le but.

Par où commencer

Si vous avez un projet IA bloqué entre POC et production, le diagnostic prend environ une semaine. On regarde :

1. Ce que le système fait réellement, de bout en bout — pas seulement l’appel modèle
2. La surface d’échec, et le coût quand ça échoue
3. Le modèle de coût sous une charge réaliste
4. La stratégie d’évaluation — et s’il y en a une
5. Le plan de rollout, et le plan de rollback

C’est le pont entre « on a un modèle » et « on a un système ».

Si ça résonne, parlons-en. Premier échange offert.