La dette technique ne dépend pas de l'auteur du code, mais du coût de sa modification. Un module parfaitement fonctionnel, mais incompréhensible pour tous les membres de l'équipe, représente une dette technique, même sans le moindre bug, car toute modification future nécessitera de reconstruire le raisonnement initial, élaboré par personne.
Cela est plus important que jamais car une méthode rapide d'accumulation de code correct et mal compris a émergé : accepter ce qu'un modèle génère sans comprendre pourquoi il est ainsi.
Lorsqu'une équipe modifie un système, le véritable travail ne consiste pas à écrire de nouvelles lignes de code. Il s'agit de répondre à trois questions avant de les écrire : que fait ceci actuellement, pourquoi est-ce fait ainsi et qu'est-ce qui risque de se casser si je le modifie ?.
Ce travail s'appelle la compréhension, et il absorbe la majeure partie du temps nécessaire à toute modification d'un système mature. Si personne n'a compris le code lors de sa première introduction, la facture ne disparaît pas : elle est reportée et majorée d'intérêts, car celui qui la paie n'aura même pas accès au contexte des discussions initiales.
Il existe une asymétrie gênante : Générer est plus rapide que comprendre.. Un modèle peut produire en quelques secondes quelque chose qu'une personne met vingt minutes à comprendre. Lorsque la génération s'accélère sans que la compréhension suive, le déséquilibre s'accumule dans la base de données.
Personne ne sait si une pièce est utilisée. Du code apparaît, dont l'utilité est incertaine, et en cas de doute, il est conservé. Le système s'encombre alors de données que personne n'ose supprimer.
Les critiques deviennent superficielles. Lorsque des changements majeurs surviennent fréquemment, le processus d'examen passe de « Je comprends et j'accepte » à « Cela me semble raisonnable ». C'est un changement discret mais décisif.
On résout deux fois les mêmes problèmes. Trois fonctions apparaissent qui font presque la même chose, car personne ne savait que les autres existaient.
Les erreurs sont corrigées en les dissimulant, pas en les réparant. On ajoute une condition au problème au lieu de le résoudre, car toucher à l'original est effrayant.
GitClear a quantifié le troisième symptôme : le nombre de blocs de code dupliqués a été multiplié par huit en 2024, et son rapport ultérieur a indiqué que la duplication continuait de croître. La duplication est la signature statistique d’une mauvaise compréhension : on copie ce que l’on ne comprend pas suffisamment pour le réutiliser efficacement.
Nous n'en proposons qu'une seule, et elle est facile à défendre dans n'importe quelle équipe :
Personne ne fusionne du code qu'il ne pourrait pas expliquer sur un tableau blanc.
Cela ne nécessite pas de comprendre chaque détail de la mise en œuvre. Il faut simplement pouvoir répondre à trois questions : quel problème cela résout, pourquoi on a choisi cette solution plutôt qu’une autre, et que se passerait-il si cela cessait d’exister ?.
Correctement appliquée, cette règle ne ralentit pas le processus ; elle le réorganise. Générer le code 80% avec assistance reste valide. En revanche, l'intégrer sans l'avoir lu au préalable n'est plus valide.
|
Pratique |
Avant |
Avec génération assistée |
|---|---|---|
|
Ampleur du changement |
Limité par le temps disponible pour l'écrire |
Elle peut croître sans limite naturelle. |
|
Objet de l'analyse |
Trouver les erreurs |
Vérifier la compréhension et l'adéquation |
|
Risque principal |
Une défaillance spécifique |
Accepter une structure que personne n'a décidée |
|
Contrôle efficace |
Évaluation par les pairs |
Modification de la limite de taille et des tests obligatoires |
La taille des lignes explique la conclusion de DORA de 2024 : à mesure que l’adoption de l’IA augmentait, la stabilité de la livraison diminuait de 7,21 TP3T. La cause n’est pas la qualité du code généré, mais plutôt la disparition du frein naturel à son écriture. Une modification de mille lignes n’est pas examinée de la même manière qu’une modification de cinquante lignes, aussi compétent soit le relecteur.
Par conséquent, le contrôle le plus efficace n'est pas un outil, mais une norme de processus : limiter l'ampleur des changements. C'est simple et ça marche.
Tests rédigés par une seule personne. Il est logique que le modèle génère l'implémentation ; il est également logique qu'il génère le test qui valide cette implémentation, bouclant ainsi la boucle. Le test doit exprimer les attentes métier, et seule une personne peut les connaître.
Documenter la décision, pas le code. Il n'est pas nécessaire de commenter chaque ligne. Un paragraphe expliquant le choix de cette approche et l'alternative écartée suffit. Cela permet de la modifier dans l'année sans avoir à refaire l'analyse.
Une limite de taille par changement. Toute limite raisonnable convient. Son intérêt ne réside pas dans le nombre lui-même, mais dans le fait qu'elle oblige à décomposer le travail en unités compréhensibles.
Les trois sont peu coûteux et ne nécessitent aucun nouvel outil. C'est la même logique sous-jacente qui motive les normes d'ingénierie que nous appliquons à chaque livraison : contrats explicites, environnements isolés et documentation transférée au client. Le code et sa documentation sont la propriété de celui qui les paie.
Lors d'un audit, une question permet d'établir un diagnostic plus rapidement que n'importe quel indicateur : Choisissez un module au hasard et demandez à un membre de l'équipe d'expliquer pourquoi il est conçu ainsi..
Si une explication cohérente est fournie, le système reste maintenable malgré ses défauts. En revanche, si l'on se contente d'affirmer qu'il fonctionne sans en comprendre vraiment la raison, le coût de chaque modification future sera supérieur à toute estimation, et cet écart ne fera que s'accroître.
Voilà le véritable indicateur de la dette technique. Ni le nombre de lignes de code, ni l'ancienneté, ni l'outil utilisé pour son développement : l'écart entre ce que fait le système et ce que l'organisation en comprend.
Il s'agit du coût supplémentaire engendré par chaque modification ultérieure, conséquence des décisions prises pour accélérer le processus. Ce coût ne dépend pas de l'ancienneté du code ni de son auteur, mais de celui de sa modification sécurisée.
Non pas en raison de sa qualité intrinsèque, mais parce que la contrainte naturelle de l'écriture disparaît : les modifications prennent de l'ampleur, les révisions deviennent superficielles et les doublons se multiplient. GitClear a constaté que le nombre de blocs dupliqués avait été multiplié par huit en 2024.
Une règle simple : personne n’intègre de code sans pouvoir l’expliquer au tableau, en précisant le problème qu’il résout, la raison de ce choix et les conséquences de sa suppression. Il n’est pas nécessaire de comprendre chaque détail d’implémentation.
Trois éléments : une preuve écrite d'une seule personne exprimant les attentes de l'entreprise, une documentation de la décision et de l'alternative rejetée, et une limite de taille par modification qui oblige à décomposer le travail en unités compréhensibles.
Car copier est la réaction habituelle lorsqu'on ne comprend pas suffisamment bien ce qui existe déjà pour le réutiliser. Chaque copie multiplie le nombre d'endroits où la même correction devra être appliquée à l'avenir.
Demander à un membre de l'équipe d'expliquer pourquoi un module choisi au hasard est conçu de cette manière. Si l'explication est cohérente, le système reste maintenable malgré ses défauts ; si la réponse est simplement « ça fonctionne et personne ne sait pourquoi », chaque modification coûtera plus cher que prévu.
Dans quelle mesure votre équipe comprend-elle votre système aujourd'hui ? Nous auditons l'architecture, le code, la dette technique et la sécurité, et fournissons le diagnostic écrit sous 10 jours ouvrables, à prix fixe. Demander l'audit →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
