Tes devs utilisent Claude ou ChatGPT. Les sprints sont plus rapides. Sauf qu'à la mois 4, tu découvres que le code est un puzzle — cohérent sur le papier, fragile en bas. Comment éviter la facture de la vitesse.
Donatien Lefranc
Fondateur & Président, Leando
En résumé
L'IA ne crée pas de risques techniques. Elle amplifie les manques de conception. Avant, si tu n'avais pas réfléchi à l'architecture, le code te forçait à poser des questions. Maintenant, l'IA répond à ta place — avec des suppositions. Ça paraît aller vite. C'est une bombe à retardement. Les solutions ? Formaliser la conception avant le code, documenter les décisions, garder l'humain sur l'architecture.
Tu reconnais cette conversation ?
DSI: "Avec l'IA, on peut sortir ce feature en 2 semaines."
Toi: "Super. On lance."
[4 mois après]
Dev senior: "On ne peut plus ajouter de clients là-dedans. Il faudrait tout refactoriser."
Toi: "Quoi ? Ça a pris 2 semaines à l'époque."
Dev senior: "Ouais, mais à l'époque on n'avait pas posé les bonnes questions."
Voilà le problème. L'IA accélère l'implémentation. Elle ne remplace pas la conception. Et quand il n'y a pas de conception, elle code les manques. Le code marche, il passe les tests, mais il encode des suppositions qu'on n'avait pas énoncées.
Exemple réel : une PME qu'on connaît a lancé 3 MVP avec Claude en 1 mois. Vraiment impressionnant. Mais à la mois 4, le modèle de données était un zoo — la notion d'« utilisateur » avait 7 variantes implicites selon la feature. Refactoriser ça a pris 8 semaines. La prétendue économie de 2 semaines avait coûté 6 semaines de plus tard.
💡 La vraie dépense ce n'est pas l'implémentation rapide. C'est le refactoring imprévu quand on découvre que rien ne s'emboîte.
Quand tu dis à l'IA "crée une API pour gérer les factures", elle va implémenter 50 petites décisions : Comment représenter une facture ? Qu'est-ce qui rend deux factures identiques ou différentes ? Qu'est-ce qu'on doit savoir sur le client attaché à la facture ?
L'IA répond à ces questions. Mais elle les répond seule. Et son choix dépend du style du prompt, de son interprétation du jargon métier, de ce qu'elle a vu dans son data d'entraînement.
Résultat : chaque feature a fait des suppositions légèrement différentes. Et personne ne les a documentées. Avant, sans IA, tu aurais dû écrire une spec BD avant le code. C'est ennuyeux, mais ça force une conversation : "Une facture, c'est quoi pour nous ?" Maintenant, tu ne vois rien. Juste du code.
Le symptôme
Tes devs disent : "Je comprends pas pourquoi c'est codé comme ça. Ça aurait pu être différent." → C'est ta phase de conception qui n'a pas eu lieu.
Prenons un exemple courant. Règle métier : "Un client ne peut avoir plus de 5 commandes en attente."
Tu dis ça à l'IA, elle met ça dans le handler de création de commande, directement. C'est du code, validé par les tests, en production. Sauf qu'à la mois 8, le product manager dit : "Pour certaines catégories de clients, on veut monter à 10."
Maintenant tu dois faire un refactoring pour extraire cette limite du code. Pourquoi ? Parce que personne n'a dit qu'elle était flexible. Multiplié par 30 règles métier en 3 mois, c'est une base de code qui a zéro agilité commerciale.
✓ Ce qui fonctionne mieux
Les règles métier vivent ailleurs que le code. Dans une config, un moteur de règles, ou une feuille versionée. L'IA génère du code qui lit cette règle, ne l'encode pas.
L'IA génère du code qui passe les tests. Les tests se passent dans un environnement contrôlé : une requête à la fois, pas de pics de trafic, pas de conditions limites bizarres.
Mais en production, c'est une autre histoire. Tu mets 100 factures à créer simultanément ? Peut-être que l'IA a impliqué un cache local qui marche pas bien en concurrence. Elle a généré un timeout qui est trop court. Elle a supposé qu'une valeur ne serait jamais nulle.
Les tests unitaires passent. Ça crash en prod le jeudi soir avant le week-end. Et tu dois caler un senior pendant 2-3 jours pour debugger du code qu'il n'a pas écrit.
Signal d'alerte
Ton équipe te dit : "Ça marche en local, mais en prod c'est flou." → Vous avez ignoré le code review "architectural".
Avant l'IA, il fallait vraiment réfléchir avant de coder. Tu ne peux pas implémenter une logique métier complexe sans te poser des questions. Ça prenait du temps, ça créait des frictions, mais ça forçait une conversation.
Maintenant ? Tu dis : "Implémente ça" à l'IA. L'IA code. Ça marche. Les frictions ont disparu. Et c'est là le piège. Les frictions, c'était pas des obstacles. C'était des garde-fous.
Les prompts isolent les décisions — Ton CTO demande à l'IA : "Crée une API pour les commandes." Un autre dev : "Crée une API pour les paiements." Chacun écrit un prompt isolé. Chacun obtient du code cohérent — mais cohérent à l'intérieur de ce prompt. Il n'y a rien pour les relier.
Cas terrain : Une startup SaaS, 5 mois d'IA, 4 micro-services. Aucun n'avait le même modèle de données pour "compte client". Comment on doit les synchroniser ? Personne ne savait. C'est 2 semaines de refactoring.
47%
des équipes IA rapportent une dette technique inattendue en 3-6 mois
GitHub State of Coding 2025
3×
plus long : refactoring après IA vs. rédaction initiale
Composite terrain
5j
coût moyen d'une conception initiale qui évite 5 semaines de refactoring
Estimation Leando
Tu essaies d'unifier les logs de deux features et elles représentent le même concept — l'ID client — de deux façons différentes. L'une c'est un UUID, l'autre un numéro. L'une peut être nulle, l'autre non. C'est pas le code qui est mauvais. C'est la conception qui n'a pas eu lieu.
Coût : 1-2 semaines de refactoring BD
Un nouveau senior rejoint. Il voit une architecture bizarre et demande pourquoi. Les devs disent : 'L'IA l'a généré comme ça.' Pas de décision documentée. Juste du code qu'on doit garder.
Coût : 3-5 jours de reverse-engineering par onboarding
Un bug de concurrence. Un timeout trop court. Une edge case que personne n'avait couverte. Les tests passent. La prod brûle.
Coût : 2-3 jours de debug d'urgence
Tu veux tester une tarification différente. Ça devrait être un paramètre de config. Mais c'est hardcodé dans 3 fichiers et implémenté différemment à chaque endroit.
Coût : 3-5 jours au lieu de 2 heures
Avant de lancer ton équipe sur l'implémentation avec l'IA, passe 3-5 jours en conception. Réfléchis à haute voix. 'Qu'est-ce qu'un client pour nous ? Qu'est-ce qu'une facture ? Comment ça s'attache ?' Formalise ça sur un document. Une page. Schéma simple, décisions explicites. Ensuite, tes prompts IA référencent ce document. L'IA le respecte. Tu gagnes 2 jours de conception et tu évites 5 semaines de refactoring.
Les règles métier, ce n'est pas du code. C'est des données. Mets-les à part. Une config. Une feuille versionée. Un petit moteur de règles. L'important : ce n'est pas du code qu'on doit refactoriser. L'IA génère du code qui lit cette règle, ne l'encode pas.
Le code peut être généré. Les décisions architecturales, non. Après que l'IA ait écrit le code, un senior te demande : 'Pourquoi ce design ? Ça va scaler ? Comment ça s'emboîte avec le reste ?' Ce n'est pas un code review classique. C'est une revue 'composabilité et cohérence'. Ça prend 1-2h par feature majeure. C'est 5 % du sprint, ça évite 50 % du refactoring.
Les prompts qui génèrent du code, c'est de la documentation. Versionnez-les. Notez pourquoi tu as choisi ce style d'implémentation. Pourquoi ? Parce que 'pourquoi ça a été codé comme ça' devient une question qu'on peut répondre.
Ton équipe IT t'a vendu l'IA comme un multiplier de productivité. C'est vrai sur 3-6 mois. Sauf que sans rigueur de conception, tu gagnes du temps maintenant et tu le perds — exponentiellement — plus tard.
Les winners en 2026 n'utilisent pas plus d'IA que les autres. Ils l'utilisent mieux. Conception claire, décisions documentées, revues architecturales, règles métier externalisées.
C'est moins sexy que "code 10× plus vite". C'est moins cher que "on refactor tout à la fin".
À retenir
Voici les questions qu'on nous pose tout le temps
Non. Elle remplace le 30 % du code qui est du boilerplate / CRUD. Les devs disparaissent si tu n'as pas de conception. Mais pas parce que l'IA les remplace — c'est parce que tu as mal utilisé l'IA.
Passez à l'action
Leando audite ta stack IA et ton processus — sans bullshit, avec du terrain.
Demander un diagnostic gratuit