L'IA livre si vite que les équipes ne s'arrêtent plus pour concevoir. Modèle de données, règles métier, scénarios d'usage : des décisions critiques sont prises implicitement, hardcodées silencieusement, et génèrent une dette invisible jusqu'au moment où elle coûte cher à défaire.
Donatien Lefranc
Fondateur & Président, Leando
En résumé
Les risques de l'IA dans les projets IT ne viennent pas seulement du code généré en masse. Ils viennent d'une friction productive supprimée : l'IA livre si vite que les équipes ne s'arrêtent plus pour concevoir. Modèle de données, règles métier, scénarios d'usage — des décisions critiques sont prises implicitement, hardcodées silencieusement, et génèrent une dette de conception invisible jusqu'au moment où elle coûte cher à défaire.
Aujourd'hui, ce même développeur pose la question à Cursor ou à Claude Code. L'outil choisit. Il fait une hypothèse. Il la hardcode. Le ticket est fermé. L'équipe avance.
Personne n'a pris cette décision. Et personne ne sait qu'elle a été prise.
L'adoption des outils de codage IA est massive. Selon l'enquête Stack Overflow 2024, 63 % des développeurs professionnels utilisent déjà l'IA dans leur flux de travail quotidien. La promesse est réelle : moins de friction, plus de vélocité, des sprints qui livrent davantage.
Mais la vélocité n'est pas neutre. Elle amplifie ce qu'on lui donne en entrée.
Si on lui donne de la bonne conception — une vision produit claire, un modèle de données réfléchi — l'IA accélère l'exécution. Si on lui donne un brief vague, une idée de fonctionnalité sans règles métier définies, une spec incomplète : l'IA accélère aussi. Elle comble les trous. Elle invente. Elle choisit. Et elle le fait de manière opaque, dans un code qu'aucun non-développeur ne lira.
Donnée terrain : Le rapport DORA de Google note que si l'IA accélère les révisions et la documentation, elle a montré une tendance à réduire la stabilité des livraisons. Une baisse que la plupart des équipes n'attribuent pas à leur outil IA — parce que les symptômes apparaissent bien plus tard.
Dans le développement logiciel traditionnel, la friction faisait partie du processus. Non pas comme une inefficacité à éliminer, mais comme un mécanisme naturel de détection des décisions non prises. Quand un développeur ne pouvait pas avancer sans une information, il la demandait. Quand une fonctionnalité était floue dans le code, elle était floue dans la tête de tout le monde — et quelqu'un devait la clarifier.
Cette friction forçait les équipes à concevoir. Elle créait des aller-retours entre dev, produit et métier. Elle était lente. Elle était aussi précieuse.
L'IA a supprimé cette friction. Pas partiellement : structurellement.
Les modèles sont très bons pour combler les lacunes, suggérer des fonctions, éliminer les redondances. Mais ils fonctionnent indépendamment des connaissances métier de l'équipe, des normes d'ingénierie internes et des contraintes architecturales. Ils ne savent pas ce qu'ils ne savent pas. Et surtout : ils ne signalent pas leur ignorance.
Ce sont les décisions fantômes : des choix structurants pris implicitement par l'IA, encodés dans le code, invisibles pour les équipes métier et non tracés dans aucune documentation.
Trois catégories concentrent l'essentiel du risque :
La décision la plus coûteuse à défaire. Le schéma avec lequel vous démarrez façonne votre produit pendant des années. L'IA génère des schémas cohérents techniquement. Elle ne connaît pas votre vision produit à 18 mois.
Les agents d'IA dépendent des instructions explicites. Si elles sont absentes, ils inventent. Une condition d'autorisation mal posée, une règle de validation approximative, un calcul de prix hardcodé : autant de bombes à retardement.
Un outil IA code le chemin heureux. Le cas nominal. Les cas limites, les exceptions métier, les comportements aux bords : ils sont absents jusqu'à ce qu'un vrai utilisateur les déclenche en production.
Une étude Tenzai (décembre 2025) sur les outils de vibe coding (Claude Code, Cursor, Replit, Devin, Codex) est éclairante : les agents d'IA se montrent particulièrement vulnérables aux failles liées à la logique métier, précisément parce qu'ils ne disposent pas du "bon sens" contextuel qu'un développeur humain développe en comprenant son domaine.
Les données disponibles sur ce sujet datent principalement de 2024-2025, un domaine qui évolue très vite. Les tendances sont confirmées, mais certains chiffres peuvent déjà sous-estimer la réalité de 2026.
×8
blocs de code dupliqués en 2024 vs 2022
GitClear 2024
43 %
des grandes entreprises estiment que l'IA crée de nouvelles formes de dette
HFS Research, sept. 2025
50 %
des entreprises feront face à des retards ou surcoûts IA d'ici 2030
Gartner, 2025
95 %
taux d'échec estimé des projets GenAI
Omdia · McKinsey · MIT · Forrester
Ce taux d'échec de 95 % n'est pas qu'une question de technologie immature. C'est souvent le résultat de projets lancés trop vite, sur des bases de conception insuffisantes, avec des décisions fantômes enfouies dans le code depuis le premier sprint.
Terrain Leando
Dans les PME et ETI où j'interviens, les bugs n'attendent même pas trois mois. Dès qu'on sort du cas nominal — un vrai test de bout en bout, un scénario un peu hors des clous — les fissures apparaissent. Et quand il faut ouvrir le code pour corriger, c'est le début des regrets : une logique sans explication, des décisions sans contexte, une architecture qui tient par habitude plus que par intention. Rarement vu des bugs aussi peu organiques, aussi difficiles à transmettre, qu'depuis l'arrivée de l'IA dans les projets.
La bonne nouvelle : les outils IA ne sont pas le problème. L'absence de cadre autour de leur usage l'est.
Ne jamais déléguer les décisions structurantes à l'IA
Modèle de données, architecture d'API, règles métier critiques — ces décisions doivent être prises explicitement, documentées, et validées avant que l'IA ne commence à coder. L'IA propose. La décision reste humaine.
Nommer et dater les décisions (ADR)
Un journal de décisions techniques simple, daté. Quand l'équipe utilise l'IA, elle documente les choix structurants pris — pas les lignes de code, les décisions.
Traiter le code IA comme un premier jet, pas une livraison
La revue de code change de nature : il ne s'agit plus de chercher des bugs de syntaxe, mais d'identifier les hypothèses implicites que l'IA a faites sur votre contexte métier.
Réintroduire de la friction là où elle protège
Pas de la lenteur arbitraire. Des points de validation formels sur les fonctionnalités à fort enjeu : "Avant de coder cette fonctionnalité, la règle métier est-elle écrite quelque part ?" Si non, l'IA attend.
Mesurer la vélocité autrement
Le nombre de features livrées par sprint n'est plus suffisant. Ce qui compte : taux de changement en production, coût des évolutions fonctionnelles, temps passé à corriger des décisions passées.
✦ À retenir
Un diagnostic de 30 minutes permet souvent d'identifier les décisions fantômes enfouies dans votre codebase — et d'estimer ce qu'il en coûterait de les défaire maintenant plutôt que dans 6 mois.
Demander un diagnostic gratuit30 minutes chrono · Sans engagement · Plan concret inclus