La vraie raison pour laquelle votre équipe d’ingénierie est lente n’est pas les personnes, mais la base de code

• Le Codebase Drag désigne l’état d’une base de code qui fait prendre plus de temps que nécessaire à chaque tâche, sans apparaître dans les tableaux de bord ou les rapports de sprint, ce qui pousse la direction à l’interpréter à tort comme un « problème humain » dans un cercle vicieux
• Après des années d’audits de bases de code, les mêmes 5 signaux sont apparus de façon répétée, ce qui a mené à la proposition d’une grille de diagnostic quantifiée de 0 à 2, baptisée « audit du codebase drag »
• Gonflement des estimations, peur du déploiement, fichiers qu’il ne faut pas toucher, mensonge de la couverture, temps jusqu’au premier commit : ces 5 signaux proviennent tous de problèmes de qualité de la base de code et se distinguent d’un manque de compétence des personnes
• Plus un·e ingénieur·e est expérimenté·e, mieux il ou elle perçoit les risques de la base de code et plus il ou elle avance avec prudence, ce qui crée le paradoxe d’avoir l’air plus lent ; si on le confond avec un problème de talents, on n’obtient qu’un effet contre-productif avec davantage de processus
• À partir de 4 points, un investissement direct dans la base de code est nécessaire, et au-delà de 7 points, le niveau exige une intervention structurelle immédiate

---

Qu’est-ce que le codebase drag ?

• Le Codebase Drag est le phénomène par lequel la base de code fait prendre plus de temps que nécessaire à tout travail, sans apparaître dans les rapports de sprint ni dans les tableaux de bord
  • Exemple : une équipe côté client a passé une semaine à deux ingénieurs pour ajouter une exportation CSV au panneau d’administration — le travail réel représentait une journée, le reste du temps ayant été consacré à comprendre le code existant pour le modifier en toute sécurité
• Quand le ralentissement de l’équipe se répète, la direction conclut à un problème de talents et répond par une réorganisation, l’ajout de processus ou le remplacement de personnes, mais l’équipe suivante se heurte au même mur
• La racine du problème n’est ni un bug, ni une fonctionnalité manquante, ni même ce qu’on appelle habituellement de la dette technique, mais la base de code elle-même

Les 5 signaux du codebase drag

1. Estimation d’excuse (Apology Estimate)

• Situation où un·e ingénieur·e annonce 2 semaines pour une fonctionnalité qui devrait réellement prendre 3 jours, ce que la direction interprète à tort comme un gonflement du planning
• La vraie raison est le couplage entre modules — par exemple, modifier le module de billing affecte aussi le système de notification — ainsi qu’une structure qui empêche de savoir jusqu’où s’étendra l’impact d’un changement
  • Avec un hidden default scope ou des callbacks profondément imbriqués, il est impossible de prévoir le blast radius d’un changement sans lire la moitié du code
• Si les estimations prennent systématiquement 2 à 3 fois plus de temps que prévu, le problème n’est pas la façon d’estimer, mais le coût de la base de code

2. Peur du déploiement (Deploy Fear)

• On observe des équipes qui évitent de déployer le vendredi, ou qui regroupent les déploiements pour faire des releases plus grosses et plus rares
• Une équipe cliente appliquait même une règle officieuse interdisant tout déploiement après le mercredi — une habitude née après que 3 déploiements du jeudi ont provoqué des incidents durant le week-end
  • Les causes : absence de stratégie de rollback, tests peu fiables et pipeline de déploiement de 45 minutes
• Selon les critères DORA, une équipe élite a un taux d’échec des changements inférieur à 5 % et peut déployer immédiatement si nécessaire ; ici, l’équipe en est réduite à un déploiement par semaine en attendant avec angoisse

3. Le fichier « n’y touche pas » (Don't Touch That File)

• Dans presque tous les cas, on entend dans les deux premiers jours : « ne touche pas à ce fichier »
  • Par exemple, un contrôleur de billing avec 30 before_action, ou un modèle en tête du git log mais structurellement inchangé depuis des années
• Si on exécute git log --oneline --since="2 years ago", le fichier le plus souvent modifié est toujours celui qui avait été signalé — si l’on ne fait que de petits correctifs sans travail structurel, on traite les symptômes en laissant la maladie intacte
• Le vrai coût, c’est que les fonctionnalités qui devraient vivre dans ce module sont implémentées ailleurs, et les nouvelles recrues apprennent dès leur première semaine à éviter ce fichier — la base de code se met à croître de façon difforme autour de zones mortes

4. Le mensonge de la couverture (Coverage Lie)

• Un chiffre de 80 % de couverture de tests a l’air rassurant, mais en pratique il est souvent soutenu par des tests de serializers, de helpers ou d’utilitaires qui cassent rarement, tandis que les 3 modèles critiques qui manipulent l’argent n’ont aucun test
• La suite de tests existe alors non pas pour attraper les régressions, mais pour faire bien dans les métriques — les tests passent, mais la production casse quand même
• Quand la CI dure 40 minutes, les développeurs cessent d’exécuter les tests en local → le taux de couverture ment à double titre : il ne couvre pas les parties importantes, et même les tests existants ne sont plus exécutés
• La vraie question n’est pas le chiffre de couverture, mais : « à quand remonte la dernière fois où un test a détecté un bug avant la production ? »

5. Temps jusqu’au premier commit (Time to First Commit)

• Il s’agit du temps nécessaire, pour un·e nouvel·le ingénieur·e à qui l’on remet un laptop, avant d’ouvrir une PR contenant une vraie correction de bug ou une petite fonctionnalité
  • Base de code saine : 1 à 2 jours
  • Base de code en drag : plus de 2 semaines
• Chez un client, il fallait plusieurs semaines pour configurer l’environnement de développement, mais après correction, un nouveau développeur pouvait le faire en 15 à 20 minutes
• La cause principale est le setup rot : le script bin/setup n’a pas été mis à jour depuis le dernier changement d’environnement, les données de seed référencent des tables ou colonnes qui n’existent plus, et 3 variables d’environnement non documentées ne se révèlent qu’au moment où l’application échoue au démarrage
• Les ingénieurs déjà en place ont intériorisé une procédure non documentée, ce qui fait que seules les nouvelles recrues révèlent précisément l’ampleur du savoir implicite exigé par la base de code

Pourquoi de bons ingénieurs semblent lents dans une mauvaise base de code

• Les 5 signaux agissent ensemble et ajoutent à tout travail un surcoût qu’on ne peut pas pointer du doigt pendant le standup
  • Un·e ingénieur·e qui livrait une fonctionnalité en deux jours dans son entreprise précédente met une semaine dans cette base de code, et toute tentative d’explication ressemble à une excuse
• Une étude METR de 2025 a montré que des développeurs expérimentés étaient 19 % plus lents lorsqu’ils utilisaient des outils d’IA — preuve que la saisie n’était pas le goulot d’étranglement
• Les meilleur·es ingénieur·es perçoivent mieux les risques, avancent plus prudemment et prévoient des estimations plus larges — à l’inverse, des profils moins expérimentés ne voient pas les risques, déploient plus vite puis provoquent des incidents en production, ce qui pousse toute l’équipe à devenir encore plus prudente
• Un client a remplacé 6 équipes en 10 ans (dont 2 reprises complètes) — schéma répété : exigences fonctionnelles de la direction → traitement de la dette sauté → code devenu irrécupérable → proposition de réécriture ou de découpage en microservices → aggravation avec deux systèmes au lieu d’un
• Quand la direction lit le ralentissement comme un problème de talents, elle ajoute seulement du processus à une équipe déjà usée par les frictions, ce qui aggrave la situation — la seule intervention réellement utile consiste à corriger le chemin lui-même

Audit du codebase drag : comment diagnostiquer

• Noter chacun des 5 signaux de 0 à 2 :
  • 0 point : aucun problème
  • 1 point : problème partiel
  • 2 points : problème grave
• À partir de 4 points, un investissement direct dans la base de code doit passer avant toute autre mesure

Que faire quand la dette technique freine l’équipe

• Commencer par le signal qui a le score le plus élevé — ne pas essayer de tout corriger en même temps
  • Peur du déploiement à 2 points : prioriser la vitesse de la CI, l’automatisation du rollback et l’amélioration de la granularité des déploiements
  • Estimation d’excuse en tête : prioriser le découplage du module ayant le blast radius le plus large
  • Temps jusqu’au premier commit à 2 points : une journée investie pour corriger bin/setup et documenter l’environnement est rentabilisée sur tous les recrutements suivants
• Si la version de Rails a plusieurs versions de retard, une mise à niveau de version peut servir de forcing function justifiant l’investissement
• Mesurer par cycles de 2 semaines : choisir le signal au score le plus élevé → sprint ciblé → mesure de chiffres concrets (fréquence des déploiements, précision des estimations, temps jusqu’à la première PR, etc.)
• Si l’approbation de l’investissement est difficile à obtenir, c’est parce que le coût de l’inaction reste invisible — dire « il y a de la dette technique » convainc beaucoup moins que « le couplage de ces trois modules fait presque doubler le temps de chaque fonctionnalité »
• Au-delà de 7 points, on est généralement à un niveau qui justifie de commencer par une semaine d’audit de la base de code