Dette technique liée à l'IA (Dette technique du code génératif)

1. Vue d'ensemble du concept et problème systémique

Le terme « dette technique », introduit par Ward Cunningham, décrivait à l'origine un compromis conscient : livrer une fonctionnalité plus rapidement aujourd'hui pour obtenir des retours business, puis revenir demain pour réécrire le code proprement.

À l'ère du codage génératif, ce concept a muté. La Dette Technique IA (AI Technical Debt) n'est pas un arbitrage délibéré d'un ingénieur expérimenté, mais une accumulation incontrôlée de code dont personne dans l'équipe ne maîtrise le modèle mental complet.

Lorsqu'une startup ou une équipe enterprise est séduite par une vitesse initiale extrêmement élevée (« nous avons écrit le backend en un week-end ! »), elle contracte un emprunt à taux élevé :

• Vitesse des premières releases : 10x.
• Vitesse de développement six mois plus tard : 0.1x.
• Toute tentative de mise à jour d'une version de bibliothèque ou d'ajout d'une nouvelle règle métier se transforme en cascade de dysfonctionnements incompréhensibles dans des coins isolés du repository.

Trajectoire de la vitesse de développement :
Vitesse
   ^
   |       /--- Culture d'ingénierie saine (Vitesse stable)
   |      /
   |  /\ /
   | /  X
   |/    \
   |      \___ Dette technique AI non maîtrisée (Démarrage rapide -> Paralysie architecturale)
   +----------------------------------------------------> Temps (mois)

2. Taxonomie architecturale et modèle mental

L'anatomie de la dette technique générative comprend quatre niveaux :

1. Dette cognitive (Cognitive / Comprehension Debt) :
   • Le code fonctionne, mais personne dans l'équipe ne comprend la mécanique interne de l'algorithme.
   • Les développeurs ont peur de toucher au code et, en cas de bug, se contentent de soumettre le fichier au modèle avec un prompt « corrige ça », aggravant ainsi la dette.
2. Dette liée à l'absence d'une source unique de vérité (Single Source of Truth Decay) :
   • Le modèle ne sait pas que la validation du numéro de téléphone est déjà implémentée dans le package @shared/validation et crée sa propre implémentation dans le module d'authentification, tandis qu'un autre modèle en génère une autre dans le module commandes.
   • Les règles métier commencent à diverger.
3. Dette liée aux invariants faibles ou absents :
   • Utilisation de types faibles (any, unknown, Record<string, any>), ignorance des conditions de concurrence (Race Conditions) et des verrouillages de transactions en base de données.
4. Dette liée à la prolifération des dépendances (Dependency Creep) :
   • Ajout de bibliothèques tierces lourdes pour effectuer des opérations élémentaires qui pourraient être résolues par trois lignes de code natif sur la version actuelle de la plateforme.

3. Pipeline technique et mécanique interne

Tableau comparatif des symptômes de la dette technique

Pipeline architectural de protection contre la dette

[Agent propose des modifications]
         |
         v
[Étape 1 : Analyse AST de la complexité cyclomatique (ESLint/Biome)]
         |
         v
[Étape 2 : Vérification des frontières architecturales (Dependency Cruiser)]
         |
         v
[Étape 3 : Vérification des types via tsc --noEmit avec le drapeau noImplicitAny]
         |
         v
[Étape 4 : Exécution des tests de mutation (Stryker Mutator)]
         |
         v
[Étape 5 : Audit architectural manuel : ce problème peut-il être résolu par une suppression de code ?]

4. Scénarios d'ingénierie pratiques en production

01. Liquidation de la dette cognitive via le refactoring "Delete-First"

Une équipe fait face à un microservice de calcul de remises de 2500 lignes, écrit par un agent lors d'un hackathon. Le service contient des dizaines de branches qui ne sont jamais exécutées. L'architecte formalise les exigences métier dans 15 tests d'intégration concis, efface complètement l'ancien fichier et force l'agent à générer une fonction de table pure (Lookup Table) de 120 lignes, éliminant ainsi 95 % du code superflu.

02. Détection des dépendances circulaires avec dependency-cruiser

En raison des recommandations chaotiques des agents, les modules du projet se sont retrouvés emmêlés dans des imports circulaires (A -> B -> C -> A), provoquant des erreurs undefined spontanées lors de l'initialisation de l'environnement en production. Les ingénieurs configurent la règle no-circular dans le CI, restructurent le code en architecture en couches (Layered Architecture) et bloquent les tentatives futures des agents de créer des liens croisés.

03. Audit des contrats de microservices via Zod / OpenAPI

Les agents généraient des appels clients vers le backend utilisant d'anciennes versions de champs. L'implémentation d'un schéma Zod strict à l'entrée de chaque endpoint API et la génération automatique de types TypeScript pour le frontend éliminent les bugs cachés de divergence de données, garantissant qu'aucune modification ne cassera l'application cliente.

5. Pièges, erreurs courantes et sécurité

1. "Fixing Slop with More Slop" (Soigner le bruit par plus de bruit) : Lorsqu'une erreur survient dans le code généré, la pire chose à faire est d'envoyer l'erreur au modèle avec l'instruction « corrige ». Le modèle ajoutera simplement un autre if ou try-catch, créant un « pansement grossier » sur une architecture pourrie. Arrêtez-vous, identifiez la cause racine (Root Cause) et simplifiez le design initial.
2. Ignorance des fuites de ressources dans les processus en arrière-plan : Les scripts générés oublient souvent de fermer les connexions à la base de données, les descripteurs de fichiers ou les pools de threads. Sur une machine locale, cela passe inaperçu, mais sous forte charge, le serveur épuise les limites de fichiers ouverts (Too many open files) et plante.
3. Mauvaise évaluation de la productivité de l'équipe : Si le management évalue les développeurs sur la vitesse de clôture des tickets ou le nombre de commits, les ingénieurs basculeront dans une génération de code IA incontrôlée. Mesurez plutôt la stabilité des releases, le nombre de régressions et la facilité de modification du système, et non le volume brut de code écrit.