Sber explique pourquoi le code généré par l'IA paraît fiable mais cède sous une charge réelle

Sber a attiré l'attention sur un problème que rencontrent déjà les équipes qui utilisent massivement l'IA dans le développement : le code généré paraît souvent soigné et convaincant, mais commence à s'effondrer sous une charge réelle. La cause ne tient pas seulement aux limites des modèles. Les développeurs ont aussi tendance à juger ce code sur sa vraisemblance apparente plutôt que sur la profondeur de sa logique.

Pourquoi le code convainc

Les modèles reproduisent bien les schémas familiers : fonctions correctement structurées, noms de variables soignés, schémas habituels de gestion des erreurs, et même des tests d'allure professionnelle. C'est pourquoi le code issu de l'IA franchit facilement le premier filtre visuel. Il ressemble au travail d'un ingénieur chevronné parce qu'il est assemblé à partir d'un immense corpus de solutions existantes.

Mais ressembler à du code de qualité ne signifie pas que le modèle a réellement vérifié toutes les prémisses, contraintes et scénarios de défaillance. C'est ce qui sous-tend l'idée de ce qu'on appelle l'intelligence des LLM : le modèle ne comprend pas un système comme le comprend un humain, il prédit la suite la plus probable à partir du texte, du code et du contexte. Quand la tâche est classique, cette approche fonctionne étonnamment bien. Quand surgissent des règles métier, des dépendances peu évidentes, des conditions de concurrence, des entrées rares ou des intégrations complexes, les lacunes apparaissent.

D'où la thèse principale du texte : il ne suffit pas au développeur de savoir écrire des prompts, il doit comprendre précisément comment le modèle se trompe.

Où la logique se brise

Les problèmes se manifestent le plus souvent non dans la syntaxe, mais dans les hypothèses cachées. Le modèle peut construire correctement une requête vers la base de données sans remarquer un problème de transactions. Il peut écrire une validation qui passe sur des données de démonstration mais s'effondre sur les valeurs limites. Il peut générer des tests qui couvrent le scénario principal et oublier les délais d'attente dépassés, les pannes partielles ou l'accès concurrent. Tant que la charge est faible, tout semble stable. Quand le code arrive dans un service réel, le coût de ces simplifications devient vite visible.

« L'IA ne comprend pas le code tant que le développeur ne comprend pas

sa “pensée” ».

De là découle un autre problème : la surestimation de la qualité. Si l'équipe perçoit la réponse du modèle comme une solution d'ingénierie presque finie, la vérification devient formelle. La revue de code se met à regarder le style plutôt que les invariants. Les tests confirment le fonctionnement de base, mais pas la robustesse. Dans ce contexte, la maîtrise de l'IA n'est pas la capacité d'obtenir vite un long extrait de code, mais celle de repérer où le modèle a comblé les trous avec une logique séduisante mais peu fiable.

Comment travailler avec le modèle

Sber propose de voir l'IA comme un accélérateur du travail d'ingénierie, et non comme un substitut à la réflexion d'ingénierie. Concrètement, l'équipe doit disposer d'un processus où le modèle génère un brouillon et où un humain vérifie les hypothèses, les liens entre composants et le comportement sous charge. Plus le système est complexe, plus il est dangereux de se contenter de l'impression que « le code a l'air raisonnable ». Il faut des étapes distinctes qui révèlent les failles logiques, et pas seulement le formatage et la conformité aux linters.

• Demander au modèle de lister explicitement les hypothèses et les points faibles de la solution
• Découper la tâche en petites parties plutôt que de générer un gros bloc de code d'un seul coup
• Vérifier les cas limites, les intégrations et le comportement en cas d'erreur par des tests distincts
• Comparer le code généré aux schémas déjà éprouvés dans le projet
• Distinguer la lisibilité de la réponse de la fiabilité d'ingénierie de l'implémentation

Une pratique utile consiste à traiter chaque réponse du modèle comme une hypothèse. Si l'IA propose un choix d'architecture, mieux vaut lui poser les mêmes questions qu'à une solution humaine : que se passe-t-il quand le trafic augmente, où la cohérence se rompt-elle, comment le code se comporte-t-il avec une entrée vide, comment le processus se rétablit-il après une panne. Cette approche améliore non seulement le développement assisté par l'IA, mais toute la discipline d'ingénierie de l'équipe, car elle oblige à formaliser ce qui restait souvent « dans la tête ».

Ce que cela signifie

L'adoption massive de l'IA dans le développement n'annule pas la responsabilité d'ingénierie de base, elle la durcit. Les gagnants ne seront pas les équipes qui génèrent le plus de code, mais celles qui comprennent le mieux les limites des modèles et savent transformer leurs points forts en un flux de travail maîtrisé.