Pourquoi les prototypes IA ne deviennent pas des produits : les trois barrières à franchir

Chaque jour, on voit des démonstrations spectaculaires : une seule invite génère une application complète, quelques lignes en langage naturel et voila – un produit apparent surgit. Pourtant, malgré ces tendances virales et des investissements massifs, cela n’a pas entraîné l’explosion d’innovations en production que beaucoup attendaient.

Un vice-président engineering de Google a récemment déclaré : « People would be shocked if they knew how little code from LLMs actually makes it to production. » Cette vérité illustre l’ecart considérable entre prototypes générés par l’IA et systèmes prêts pour la production. Trois défis fondamentaux expliquent ce fossé.

1 – Greenfield versus piles technologiques existantes

Les grands modèles de langage excellent dans la création sans contraintes, dans des environnements ‘greenfield’. Mais l’exploitation en production exige d’intégrer des réalités hétérogènes : code legacy, frontières de services, contrats de données, middleware d’autorisation, schemas protobuf, pipelines CI/CD, observabilite, objectifs de niveau de service, budgets de performance, etc. Tout cela précède l’interaction imprévisible des utilisateurs.

Quand on construit du logiciel, on suit un processus presque artistique : on imagine un chemin de transformation des donnees et un control flow précis. L’IA est remarquable pour cette generation creative. Mais la production demande du code qui respecte des parametres stricts et nuancés – et transmettre ces parametres a un LLM est loin d’etre simple.

2 – Le probleme ‘Dory’ : memoire et diagnostic

Pourquoi l’IA ne peut-elle pas simplement depanner le code qu’elle produit ? Parce que depanner exige une comprehension globale de l’architecture, comment les donnees circulent reellement, et la capacite a retroconcevoir un systeme a partir d’un defaut. Il faut consommer des architectures massives et compliquees, reconnaitre des comportements emergents, des dependances implicites et des contournements historiques.

La plupart des LLM se comportent comme le personnage Dory dans ‘Finding Nemo’ : peu de contexte d’une requete a l’autre et memoire tres courte. Or des entreprises manipulent des bases de code accumulees sur 20, 30 ou 40 ans. Sans vision d’ensemble des depots, des decisions passées et des historiques de deploiement, il est pratiquement impossible de resoudre des incidents complexes.

3 – Maturite inegale des outils du cycle de vie logiciel

Le troisieme obstacle tient a la maturation inegale des outils qui supportent le SDLC. Les outils de generation de code ont evolue tres vite – pensons a l’autocompletion amelioree de l’IDE ou a des interfaces conversationnelles de seconde generation. Mais les fonctions essentielles pour la mise en production – deploiement, maintenance, revue de code, assurance qualite, support client – n’ont pas encore atteint la meme vitesse d’innovation.

Autrement dit, nous avons rapide progress pour ‘prendre la photo’ du code, mais beaucoup moins pour repenser l’ensemble du processus de livraison et d’exploitation du logiciel.

Vers une approche operationnelle et systemique

On peut obtenir des gains progressifs avec des outils d’IA pour la revue de code ou des agents SRE, mais les avancées majeures viendront d’outils qui repensent l’operation logicielle dans son ensemble, pas seulement un maillon du flux. Les outils qui reussiront seront capables de :

• retroconcevoir des systemes complexes et en comprendre les etats de maniere systematique,
• enumerer les conditions qui produisent un comportement inattendu,
• assumer a la fois un role creatif pour generer du code et un role d’enquete scientifique pour diagnostiquer et regler les causes profondes.

Jusqu’a ce que ces capacites existent, on continuera de voir des prototypes impressionnants et des experiences de production frustrantes. Ce decalage cognitif est fondamental a la maniere dont ces systemes fonctionnent, et il ne disparaitra pas du jour au lendemain.