Dette technique et risques

Pourquoi ce chapitre compte

Un assistant IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire bien utilisé multiplie la quantité de code produite par unité de temps. Ce gain est réel et mesurable : moins de temps passé à écrire du code répétitif, des squelettes de fonctions générés en quelques secondes, des tests unitaires esquissés automatiquement. Ce que ce gain ne dit pas, c'est ce qui se passe dans la tête des développeurs pendant que le code défile.

La vélocité d'une équipe et sa compréhension du système qu'elle construit ne progressent pas au même rythme. Historiquement, ces deux courbes restaient proches : écrire du code prenait du temps, et ce temps servait aussi à le comprendre. L'assistance par IA découple les deux. On peut désormais accepter, lire en diagonale et merger un bloc de code fonctionnel en quelques minutes, sans jamais avoir reconstruit le raisonnement qui l'a produit. Ce chapitre traite de l'écart qui se creuse dans cette situation, et des deux risques qui en découlent directement : le code opaque et l'over-reliance.

Le risque n'est pas que l'IA écrive du mauvais code. Elle en écrit souvent du correct. Le risque est que l'équipe humaine perde, progressivement et sans s'en apercevoir, la capacité à l'expliquer, le déboguer et le faire évoluer sans l'assistant.

Le code opaque : quand le fonctionnement précède la compréhension

Un code est opaque non pas parce qu'il est mal écrit, mais parce que personne dans l'équipe n'est en mesure de reconstruire, sans l'assistant, le raisonnement qui a mené à son écriture. C'est une propriété relationnelle entre le code et l'équipe, pas une propriété intrinsèque du code.

Le mécanisme est simple à observer. Un développeur demande à un assistant de générer une fonction de validation de formulaire, ou un middleware d'authentification, ou une requête d'agrégation complexe sur une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire. Le résultat fonctionne : les tests passent, le comportement observé correspond à l'attente. Le développeur le merge. Ce qu'il n'a pas fait, c'est reformuler mentalement pourquoi cette implémentation-là plutôt qu'une autre, quelles hypothèses elle porte sur les données en entrée, et ce qu'il faudrait changer si une de ces hypothèses devenait fausse.

Ce déficit ne se voit pas immédiatement. Le code fonctionne, les métriques sont bonnes, les revues de code passent parce que le relecteur, lui aussi pressé, se fie au fait que les tests sont verts. Le problème émerge plus tard : lors d'un incident en production, lors d'une évolution fonctionnelle qui touche cette zone du code, ou lors du départ d'un développeur qui avait, lui, une intuition du fonctionnement que personne d'autre n'avait formalisée.

Une équipe fait générer par un assistant un module de calcul de remise commerciale, avec des règles de cumul complexes. Le code passe tous les tests écrits — également générés par l'assistant, sur la base des mêmes hypothèses que le code lui-même. Six mois plus tard, un cas limite non couvert (remise négative sur un abonnement résilié en cours de mois) produit un montant erroné en production. Aucun développeur de l'équipe ne peut expliquer la logique de cumul sans relire le code ligne par ligne, parce que personne n'a jamais eu besoin de la comprendre pour la livrer.

Ce piège est aggravé par un biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire spécifique : les tests générés par le même système que le code testé partagent souvent les mêmes angles morts. Un assistant qui a mal interprété une règle métier produira un code cohérent avec cette interprétation erronée, et des tests tout aussi cohérents avec elle. La suite verte ne prouve alors rien sur la conformité au besoin réel — seulement une cohérence interne entre deux artefacts issus de la même source.

Over-reliance : la dépendance qui s'installe sans déclencheur visible

L'over-reliance, ou sur-dépendance, désigne la perte progressive de la capacité d'une équipe à produire, déboguer ou faire évoluer son système sans l'assistance d'un outil IA. Contrairement au code opaque, qui concerne un fragment de code précis, l'over-reliance est une propriété de l'équipe dans son ensemble, qui s'installe par accumulation de petites décisions individuellement raisonnables.

Le schéma se répète : face à un problème, le réflexe devient de demander à l'assistant avant de chercher à comprendre soi-même. Ce réflexe est efficace à court terme — il fait gagner du temps sur des tâches ponctuelles. Répété des centaines de fois sur plusieurs mois, il produit un effet d'atrophie : les compétences de diagnostic, de lecture de stack trace, de compréhension d'un système legacy, s'exercent moins et se dégradent. L'équipe devient plus rapide avec l'outil et significativement plus lente sans lui, y compris dans des situations où l'outil est indisponible, mal calibré, ou simplement moins pertinent que l'expérience humaine.

Si une panne de l'outil IA (indisponibilité de service, dépassement de quota, restriction réseau) génère une chute de productivité disproportionnée par rapport au temps qu'il faisait gagner en temps normal, l'équipe est probablement déjà en zone de sur-dépendance critique.

L'over-reliance a aussi une dimension plus subtile : la dilution de la vigilance en revue de code. Quand un contributeur sait que son code a été généré ou fortement assisté par IA, il a tendance à le relire moins attentivement — projetant sur l'outil une fiabilité qu'il n'a pas garantie. Symétriquement, un relecteur qui sait que le code vient d'un assistant applique parfois un niveau d'exigence plus faible, sous l'hypothèse implicite que « l'IA a dû bien faire les choses ». Ces deux biais se renforcent mutuellement et abaissent le niveau de rigueur collectif sans qu'aucune décision explicite n'ait été prise en ce sens.

Dette technique classique vs dette générée par IA

La dette technique n'est pas un concept nouveau : elle existait avant l'assistance par IA, sous forme de raccourcis pris sous pression de délai, de code non refactorisé, de documentation absente. Ce qui change avec l'IA, c'est la vitesse d'accumulation et la nature du déficit.

Cette dernière ligne mérite d'être développée. Rembourser une dette technique classique consiste à revenir sur des zones identifiées comme fragiles. Rembourser une dette générée par IA suppose d'abord de découvrir où elle se trouve, ce qui est nettement plus coûteux : il faut auditer du code qui, en apparence, ne présente aucun signe de fragilité.

Lors de chaque revue de pull request contenant du code généré ou fortement assisté par IA, demandez à l'auteur d'expliquer oralement ou par écrit, en une ou deux phrases, la logique métier centrale — sans relire le code. S'il ne peut pas le faire sans revérifier, la revue n'est pas terminée, même si les tests passent.

Repérer les signaux avant l'incident

Certains indicateurs, suivis dans la durée, permettent de détecter une dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire avant qu'elle ne se traduise par un incident coûteux.

• Temps de revue en baisse alors que le volume de code croît — signe que la relecture devient superficielle plutôt que réellement plus efficace.
• Incapacité à expliquer un module sans le rouvrir — testée simplement en demandant à un développeur de décrire, de mémoire, la logique d'un fichier qu'il a mergé récemment.
• Concentration du savoir sur peu de personnes, voire sur l'outil lui-même — si le seul moyen de comprendre une zone du code est de redemander à l'assistant de la réexpliquer, le savoir n'a jamais été transféré à l'équipe.
• Absence de commentaires sur les décisions de conception — un code généré rapidement documente rarement le pourquoi, seulement le comment, ce qui rend les révisions futures plus coûteuses.
• Multiplication des correctifs superficiels sur une même zone — souvent le signe qu'un problème structurel n'a jamais été compris, seulement contourné patch après patch.
• Chute de productivité disproportionnée en cas d'indisponibilité de l'outil — déjà mentionnée plus haut, c'est le signal le plus direct d'over-reliance installée.

Ces dérives touchent aussi des équipes expérimentées. Le mécanisme n'est pas un manque de rigueur personnelle, mais un effet structurel : la vitesse de production dépasse le temps disponible pour l'assimilation, quel que soit le niveau des personnes impliquées.

Construire une gouvernance du code généré

La réponse à ces risques n'est pas de limiter l'usage des outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire IA, mais d'organiser le processus autour de leur usage pour que la compréhension collective progresse au même rythme que la production. Quelques principes opérationnels :

1. Distinguer explicitement le code assisté du code entièrement autonome. Un tag ou une convention dans le message de commit suffit à rendre visible ce qui mérite une attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire de revue renforcée.
2. Imposer une reformulation orale ou écrite pour toute logique métier non triviale, comme décrit plus haut — un test simple, peu coûteux, qui révèle rapidement les zones de compréhension fragile.
3. Planifier des sessions de ré-appropriation périodiques sur les modules critiques, où l'équipe relit collectivement et documente le fonctionnement d'un composant produit rapidement plusieurs semaines auparavant.
4. Mesurer le temps de revue effectif, pas seulement le nombre de pull requests fusionnées, pour détecter une dilution progressive de la vigilance.
5. Simuler périodiquement l'indisponibilité de l'outil sur des tâches de diagnostic, pour évaluer objectivement le niveau de dépendance de l'équipe.
6. Documenter le pourquoi, pas seulement le comment, en particulier pour les décisions de conception issues d'un échange avec l'assistant — la conversation elle-même contient souvent des arbitrages qui disparaissent si seul le code final est conservé.

Ces pratiques ne ralentissent pas fondamentalement le développement ; elles déplacent une partie du temps gagné par la génération de code vers la consolidation de la compréhension. Le solde reste positif, mais il n'est plus artificiellement gonflé par un déficit qui se paiera plus tard, avec intérêts.

Ce qu'il faut retenir

Le code opaque et l'over-reliance ne sont pas des défauts d'outils mal utilisés par des équipes négligentes. Ce sont des conséquences prévisibles d'un découplage entre vitesse de production et temps d'assimilation, un découplage que l'assistance par IA rend possible à une échelle inédite. Traiter ce risque suppose de le mesurer activement — via des indicateurs concrets de compréhension d'équipe, pas uniquement via des métriques de vélocité — et d'accepter qu'une partie du gain de temps apparent doit être réinvestie dans la consolidation du savoir collectif. C'est ce réinvestissement, plus que la prudence dans l'usage de l'outil lui-même, qui détermine si la dette technique générée reste gérable ou devient structurellement irrécupérable.