GitClear : l'AI accélère les releases de code, mais accroît la 'dette de compréhension' et les risques cachés

Les assistants IA accélèrent le développement, mais laissent de plus en plus derrière eux du code qui fonctionne formellement, mais qu'essentiellement personne ne comprend. C'est ce qu'indiquent les données de GitClear et l'expérience des équipes qui ont découvert un nouveau risque caché — « la dette de compréhension ».

Ce Que GitClear a Trouvé

Dans l'étude GitClear de 2025, ils ont analysé 211 millions de lignes de code modifiées sur 2020–2024. Le signal principal : code churn, c'est-à-dire les lignes réécrites dans les deux semaines suivant un commit, par rapport à la ligne de base pré-IA de 2021, a essentiellement doublé. En même temps, la proportion de refactorisation et de réutilisation de code a diminué, et la duplication est devenue plus fréquente qu'auparavant. En termes simples, les équipes produisent plus de code, mais une part importante de ce volume revient rapidement pour être retravaillée. C'est important non seulement comme métrique de qualité, mais aussi comme problème de gestion.

En mars 2026, l'ingénieur de Google Addy Osmani a décrit cela comme une dette de compréhension — l'écart entre le volume de code dans un système et le volume de code que l'équipe comprend réellement. En surface, tout semble bien : l'IC est vert, la couverture ne baisse pas, les PR fusionnent plus vite. Mais lors du premier incident inhabituel, il s'avère que personne ne peut rapidement expliquer pourquoi la logique est organisée de cette manière.

« L'IA génère du code plus vite que les gens ne peuvent l'évaluer. »

Pourquoi les Tests Échouent

Le principal piège est que l'IA écrit souvent non seulement la fonction elle-même, mais aussi les tests pour celle-ci. En conséquence, l'équipe vérifie que la mise en œuvre correspond à la mise en œuvre, et non comment la logique métier devrait fonctionner. Avec un simple exemple de webhook, cela semble inoffensif : le test confirme qu'une commande change de statut à paid.

Mais il peut ne pas vérifier l'absence de order_id, la redélivrance d'événements, le nouveau statut dans l'API de paiement, ou une situation où le système retourne 200 bien que la commande n'ait pas été trouvée du tout. De tels tests créent une fausse impression de fiabilité. Ils augmentent la couverture, se présentent bien dans les rapports et permettent de fermer les tâches plus vite, mais ne remplacent pas la compréhension des contraintes de domaine et des cas limites.

Ceci est particulièrement notable dans les nouvelles technologies. En janvier 2026, Anthropic a publié une expérience avec 52 développeurs Python étudiant la bibliothèque Trio : le groupe avec assistance IA a montré un résultat 17 % pire au test de compréhension que le groupe sans IA. Pendant ce temps, les mieux classés n'étaient pas ceux qui ont délégué le code entièrement, mais ceux qui ont utilisé le modèle pour des questions « pourquoi » et « que se passerait-il si ».

Comment Réduire le Risque

La pratique montre que l'IA seule ne garantit ni l'échec ni le succès. Le processus qui l'entoure devient décisif. Si une équipe accepte d'énormes PR, n'exige pas d'explications et considère que les tests verts sont une base suffisante pour une fusion, elle accumulera presque inévitablement du code difficile à maintenir. Si les normes d'examen restent strictes, l'IA commence à apporter des bénéfices sans croissance brusque du chaos.

• Diviser les gros changements en petites PR qui peuvent réellement être lues et discutées
• Exiger que l'auteur explique les solutions et documente explicitement les hypothèses concernant la logique métier
• Écrire des tests avant la mise en œuvre ou du moins séparer la vérification de l'intention de la vérification du happy path généré
• Ajouter des règles modulaires, des vérifications automatisées et une documentation à jour afin que l'IA fonctionne dans le contexte du projet

Le paradoxe est que l'IA peut être non seulement une source de problèmes, mais aussi un outil pour les résoudre. Ces mêmes modèles expliquent bien le vieux code legacy, aident à trouver des conditions oubliées et mettent en évidence les points faibles de l'architecture. Autrement dit, le « code sans auteur » existait auparavant, c'est juste que l'IA a augmenté considérablement le volume de changements et a rendu cette dette notable non pas des années plus tard, mais presque immédiatement après la fusion.

Ce Que Cela Signifie

Pour les équipes, l'objectif ne change pas, mais le critère de qualité change. Gagnent non pas ceux qui produisent des lignes plus vite, mais ceux qui maintiennent la compréhension du système tout en augmentant la vitesse. Si l'IA écrit déjà une partie importante du code, la compétence principale devient non pas la génération, mais la vérification, l'explication et la capacité à corriger ce morceau la nuit sous la pression d'un incident. C'est exactement ce qui sépare l'accélération du développement de l'accélération des problèmes futurs.