Les risques de l'IA dans les projets IT en 2026 : quand la vélocité masque la dette
Ton équipe accélère grâce à Copilot et Cursor. Les features sortent vite. Mais 6 mois plus tard, quelque chose cloche : les modifications simples prennent des jours, personne ne peut expliquer comment le code fonctionne, et le coût de maintenance explose.
Donatien Lefranc
Fondateur & Président, Leando
En résumé
L'IA dans les projets IT accélère la génération de code, mais elle crée un risque majeur : elle hardcode des décisions (modèle de données, règles métier, architecture) que personne n'a prises consciemment. Résultat : dette technique silencieuse, perte de compréhension du système, et coût de maintenance qui explose 6 à 12 mois après le lancement.
Si tu es CTO, lead dev ou chef de projet IT dans une PME ou une startup, tu as peut-être déjà senti cette tension : l'IA accélère le code, mais elle opacifie les décisions. Ce qui ressemble à un gain de vélocité devient, 6 à 12 mois plus tard, une bombe à retardement technique.
Cet article décortique les 4 risques sous-estimés de l'IA dans les projets IT en 2026 — et comment utiliser l'IA sans perdre le contrôle technique de ton produit.
Le paradoxe de la vélocité IA : coder plus vite, mais pour aller où ?
Avant l'IA, le code était un filtre de clarté. Si ta spec était floue, si le modèle de données n'était pas pensé, si les règles métier n'étaient pas définies — ton développeur revenait te voir, mécontent, en te disant : "Je peux pas coder, il manque des infos." C'était chiant, mais c'était sain. Le code forçait la confrontation avec les questions non résolues.
Maintenant, l'IA est un opacificateur de dette. Elle code quand même. Elle devine ce qui manque. Elle comble les blancs avec des "choix par défaut raisonnables". Sauf qu'en métier, il n'y a pas de défaut raisonnable. Chaque règle, chaque relation entre entités, chaque scénario edge doit être explicitement validé.
Mais comme le code fonctionne — il compile, les tests passent, la démo marche — personne ne relit. Et les décisions fantômes restent cachées jusqu'au jour où elles créent un bug critique ou rendent une évolution impossible.
Cas terrain
Un client SaaS B2B (80 salariés) a refondu son backoffice métier en 8 semaines avec Copilot et Cursor. L'outil marchait. Les utilisateurs validaient. Tout semblait parfait. 3 mois plus tard, besoin de modifier un workflow simple — estimation : 2 heures. Réalité : 3 jours. Pourquoi ? Parce que l'IA avait hardcodé des règles métier que personne n'avait validées. Les développeurs ont passé 2 jours à comprendre pourquoi le code faisait ce qu'il faisait avant de pouvoir le modifier.
La vélocité qu'on gagne en génération de code, on la perd (avec intérêts) en maintenance, évolution, et compréhension du système. La dette projet (décisions non prises) devient dette technique (code qui existe sans raison claire).
3-5×
Temps de debug multiplié
Pour le code IA non documenté (Observation terrain, 2025-2026)
6-12 mois
Délai d'apparition de la dette
Entre génération IA et première refonte (Retours clients Leando, 2025)
2-3×
Coût de maintenance vs génération
Estimation terrain projets PME/startup (Expérience Leando, 2026)
Les 4 risques sous-estimés de l'IA dans les projets IT
Risque #1
La dette structurelle invisible
Quand l'IA devine ton modèle de données
Signal d'alerte
"L'IA a généré un modèle de données complet en 2 jours. Tout marche. Mais 2 mois plus tard, ajouter un workflow métier simple nécessite de refondre 3 tables."
Le modèle de données est la colonne vertébrale d'un projet IT. Une erreur structurelle ici, et tout le reste vacille. Le problème avec l'IA : elle génère un modèle de données qui fonctionne pour le prompt, pas qui est évolutif pour le métier. Elle optimise pour "ça compile et ça tourne", pas pour "dans 6 mois on pourra ajouter X sans tout casser". Les relations entre entités, la normalisation, les contraintes métier — tout ça est "deviné" depuis le contexte du prompt.
Ce que ça coûte de ne pas corriger à temps
- Chaque nouvelle feature devient un chantier de migration de données
- Coût de développement qui explose (10x le temps prévu pour des modifications simples)
- Risque de bugs métier graves (données orphelines, incohérences)
- Équipe démoralisée : 'On aurait dû mieux concevoir dès le début'
✓ L'approche qui évite cette dette
Modéliser les entités métier à la main avant génération. Utiliser des ADR (Architecture Decision Records) pour tracer les choix structurants. L'IA génère le code SQL, les migrations, les ORMs — mais l'humain définit la structure. Séparation claire : l'IA exécute, l'humain décide.
Risque #2
Les règles métier fantômes
Quand l'IA interprète ce que tu n'as pas dit
Signal d'alerte
"Une feature métier complexe (calcul de prix, workflow d'approbation) est générée par l'IA et fonctionne. Mais personne dans l'équipe ne peut expliquer exactement ce qui se passe dans certains cas limites."
L'IA interprète les besoins métier depuis un prompt en langage naturel. Elle comble les blancs avec des "règles par défaut raisonnables". Le problème : en métier, il n'y a pas de défaut raisonnable. Chaque règle doit être explicitement validée par le métier. Mais comme le code fonctionne, personne ne relit. Les règles fantômes restent cachées jusqu'au jour où elles créent un bug critique.
Conséquences
- Bugs métier critiques découverts en production
- Perte de confiance des utilisateurs (ils contournent l'outil)
- Coût de correction élevé (il faut relire tout le code métier généré)
- Risque juridique ou financier selon le métier
✓ L'approche qui évite cette dette
Spécifications métier exhaustives avant génération. Tous les scénarios, y compris les edge-case, doivent être explicitement documentés. Code review focalisée sur la question : "Quelles décisions l'IA a-t-elle prises que je n'ai pas demandées ?" Tests métier avec des cas limites. Pas de merge si quelqu'un dans l'équipe dit "je sais pas ce qui se passe dans ce cas-là".
Risque #3
La perte de compréhension collective
Quand personne ne sait pourquoi ça marche
Signal d'alerte
"L'IA a généré 80 % du code. Ça marche. Mais quand un nouveau dev arrive, ou quand il faut débugger un comportement inattendu, personne dans l'équipe ne peut expliquer pourquoi certaines parties du code sont écrites comme elles le sont."
Le code généré par IA n'a pas d'historique de décision. Dans un projet classique, chaque choix technique a un contexte : une pull request, une discussion, un commit message explicatif. Avec l'IA, le code apparaît "tout fait". Il n'y a pas de trace du pourquoi. Résultat : l'équipe utilise le code mais ne le comprend pas. La dette de compréhension s'accumule.
Conséquences
- Temps de debug multiplié par 3 à 5 (il faut d'abord comprendre le code)
- Onboarding des nouveaux devs ralenti (base de code incompréhensible)
- Risque de régressions (on corrige sans comprendre les effets de bord)
- Équipe frustrée : 'On travaille sur du code qu'on ne maîtrise pas'
✓ L'approche qui évite cette dette
Documentation obligatoire du "pourquoi", pas juste du "quoi". Code review systématique du code IA par un humain qui le reformule en langage naturel : "Ce code fait X parce que Y". Pas de merge si personne dans l'équipe ne peut expliquer le fonctionnement. Refactoring régulier pour rendre le code lisible et maintenable.
Risque #4
Le coût de maintenance différé
La vélocité qui s'effondre après 6 mois
Signal d'alerte
"L'IA nous a permis de livrer le MVP en 6 semaines au lieu de 3 mois. Succès. Mais 6 mois plus tard, chaque nouvelle feature prend 2 à 3 fois plus de temps que prévu. L'équipe passe plus de temps à comprendre ce qui existe qu'à coder du nouveau."
C'est le risque le plus pernicieux, parce qu'il est invisible au départ. La vélocité initiale (génération rapide) masque le coût futur (maintenance lente). Le code généré par IA fonctionne, mais il n'est pas maintenable par défaut. Pourquoi ? Parce que l'IA optimise pour "ça marche maintenant", pas pour "dans 6 mois quelqu'un pourra le modifier sans tout casser". Les abstractions sont faibles, les couplages sont forts, la logique est dispersée.
Conséquences
- Vélocité qui s'effondre après 6 à 12 mois (alors que c'était l'argument initial de l'IA)
- Coût de développement qui explose (chaque feature simple devient complexe)
- Décision de refonte complète = perte de l'investissement initial
- Frustration équipe + management : 'On nous avait vendu de la rapidité, on se retrouve bloqués'
✓ L'approche qui évite cette dette
Architecture explicite avant génération : découpage en modules, interfaces claires, séparation des responsabilités. L'IA génère dans une structure pensée par l'humain. Budget temps pour "rendre le code maintenable" après génération. Refactoring régulier du code IA (ne pas laisser la dette s'accumuler). Accepter de ralentir au début pour accélérer durablement.
Ce que ces 4 risques ont en commun
Ils partagent tous la même cause racine : l'IA supprime le feedback loop naturel entre conception floue et réalité du code. Avant, le code forçait la confrontation avec les questions non résolues. Maintenant, l'IA opacifie les décisions non prises.
La vélocité qu'on gagne en génération de code, on la perd (avec intérêts) en maintenance, évolution, et compréhension du système. La dette projet (décisions non prises) devient dette technique (code qui existe sans raison claire).
La vraie question à se poser
Si ton équipe repousse les décisions structurantes en disant "on verra après" — c'est déjà trop tard. L'IA va combler les blancs. Et tu vas payer la dette 6 mois plus tard.
Comment utiliser l'IA sans perdre le contrôle technique
L'IA est un outil puissant. Mais elle ne remplace pas la réflexion. Voici 4 pratiques concrètes pour tirer parti de l'IA sans générer de dette à taux d'usure.
Concevoir avant de générer
Architecture Decision Records (ADR), specs détaillées, diagrammes de modèle de données — tout ça avant de lancer l'IA. L'IA génère le code. L'humain définit les décisions structurantes. Temps investi en conception = temps économisé en maintenance.
Segmenter : IA pour le mécanique, humain pour les décisions
Tout le code n'a pas le même poids. Un CRUD simple, un composant UI standard — l'IA peut générer ça les yeux fermés. Mais les règles métier, le modèle de données, l'architecture — ça doit être pensé par un humain. Segmente ton backlog selon ce critère.
Code review augmentée : chercher les décisions implicites
La code review classique cherche les bugs. La code review IA doit chercher les décisions implicites. Questions à poser : Quelles décisions l'IA a-t-elle prises que je n'ai pas demandées ? Est-ce que ce code fait des hypothèses métier non validées ? Si on doit modifier ce code dans 6 mois, est-ce que quelqu'un comprendra pourquoi c'est écrit comme ça ?
Documentation du pourquoi, pas juste du quoi
Le code IA est souvent bien commenté sur le quoi (ce que fait chaque fonction). Mais il manque le pourquoi (pourquoi cette approche, pourquoi cette structure). Impose une règle simple : chaque décision structurante doit avoir un ADR ou un commentaire explicatif. Le code doit raconter une histoire.
Pour aller plus loin
À retenir
- L'IA opacifie les décisions non prises : elle hardcode des choix (modèle de données, règles métier) que personne n'a validés consciemment
- La vélocité initiale masque le coût de maintenance : ce qu'on gagne en génération, on le perd (avec intérêts) en évolution et compréhension du système
- Les 4 risques majeurs : dette structurelle invisible, règles métier fantômes, perte de compréhension collective, coût de maintenance différé
- Concevoir avant de générer : ADR, specs détaillées, modèle de données explicite — l'IA exécute, l'humain décide
- Segmenter le backlog : IA pour le code mécanique (CRUD, UI simple), humain pour les décisions structurantes (modèle de données, règles métier, architecture)
- Code review augmentée : chercher les décisions implicites, pas juste les bugs — pas de merge si personne ne peut expliquer le pourquoi
- Documentation du pourquoi : chaque décision structurante doit avoir un ADR ou un commentaire explicatif
Voici les questions qu'on nous pose tout le temps
Questions fréquentes
Non, elle en crée différemment. Un dev humain crée de la dette par manque de temps ou de compétence. L'IA crée de la dette par opacification : elle hardcode des décisions qu'on n'a jamais prises consciemment. Le problème n'est pas la qualité du code ligne par ligne — c'est que l'IA transforme les lacunes de conception en dette technique silencieuse. Avant, le dev revenait te voir si la spec était floue. Maintenant, l'IA devine et code quand même.
Passez à l'action
Tu veux adopter l'IA sans perdre le contrôle technique ?
Chez Leando, on accompagne les PME et startups pour tirer parti de l'IA dans leurs projets IT — sans générer de dette à taux d'usure. Cadrage, conception, gouvernance IA, audit technique.
Demander un diagnostic gratuit