La dette technique n'est que la partie émergée

Quand on me mandate en tant que freelance, la demande initiale ressemble presque toujours à la même chose : « l'équipe n'arrive pas à produire assez vite, il faut accélérer ». C'est un cadrage confortable : il pointe vers un problème technique, donc vers une solution technique. Sauf que dans la plupart des missions, ce que je découvre en creusant n'a que partiellement à voir avec le code.

La dette technique existe, bien sûr. Mais elle n'est souvent que la partie visible d'un ensemble plus large : dette organisationnelle, dette de documentation, dette de compétences. Et tant qu'on ne traite que la première, on ne fait parfois que déplacer le problème, ou pire, l'aggraver.

Je voudrais raconter ici une mission qui illustre bien ce mécanisme, parce qu'elle m'a appris quelque chose que je n'avais pas anticipé : améliorer le code peut, dans certaines conditions, empirer la situation globale d'une équipe.

Un goulot d'étranglement humain

Dès mes premiers entretiens avec les développeurs, quelques heures après mon arrivée, un pattern est apparu clairement : une seule personne assurait toute la QA de l'application. Toute. Chaque fonctionnalité, chaque correctif, chaque évolution passait par elle avant de pouvoir être livré.

Ce n'était pas qu'un problème de capacité. En discutant avec elle, j'ai perçu une vraie fatigue, un débit de parole élevé, des hésitations, une personne qui se perdait dans ses explications. Je lui ai dit, assez directement, qu'elle devait se ménager, parce qu'à ce rythme elle n'allait pas tenir. C'est exactement ce qui s'est passé peu de temps après.

Au-delà de l'aspect humain, c'était aussi un risque business direct : cette personne était la seule à connaître l'application dans son ensemble. Un classique bus factor de un. Si elle s'arrêtait, ce n'était pas juste la QA qui s'arrêtait, c'était potentiellement l'activité de l'entreprise qui se retrouvait menacée.

J'ai identifié deux priorités immédiates : mettre en place des suites de tests end-to-end pour sécuriser les workflows complexes de l'application, et lui trouver un binôme pour répartir la connaissance métier. La première action a bien avancé pendant ma mission, même si le périmètre de l'application était large et que le travail se poursuit encore aujourd'hui par l'équipe. La seconde s'est heurtée à un mur : l'absence totale de documentation du comportement attendu de l'application. Sans elle, impossible de former qui que ce soit, développeur comme QA.

Et malgré mon insistance, le binômage n'a jamais eu lieu pendant ma mission. Je pense que l'impact réel de cette situation n'a pas été pleinement mesuré côté client.

Les effets en cascade

Ce goulot d'étranglement ne se contentait pas de ralentir les livraisons, il générait des effets secondaires qui, eux, ressemblaient à s'y méprendre à de la dette technique classique.

Une fonctionnalité prête attendait parfois longtemps avant d'être prise en charge par la QA. Pendant ce temps, sa branche vieillissait, et chaque développeur devait la rebaser régulièrement sur master pour ne pas perdre le fil. C'est un travail invisible, répétitif, qui ne produit aucune valeur, mais qui devient nécessaire uniquement parce que la file d'attente en aval n'avance pas. Une dette organisationnelle qui se transforme en charge technique.

Les allers-retours entre développement et QA prenaient eux aussi énormément de temps, ce qui faisait mécaniquement déraper les deadlines. Et en bout de chaîne, la pression du calendrier poussait parfois à livrer des choses qui n'étaient pas techniquement abouties. Un comble, pour un process censé garantir la qualité.

Cette pression ne restait pas cantonnée à la QA. Elle se diffusait à toute l'équipe de développement, qui sentait bien que le rythme des livraisons ne suivait pas, sans toujours pouvoir agir dessus. Ce genre de tension continue, même quand elle reste discrète au quotidien, finit par peser sur le moral collectif : le sentiment de courir après un retard qu'on ne rattrape jamais est usant, bien au-delà de la seule personne en première ligne.

Le paradoxe de l'optimisation locale

Comment un chantier technique qui a parfaitement fonctionné a-t-il pu, au final, aggraver la situation ? C'est le point que je trouve le plus intéressant, et le plus contre-intuitif, de cette mission.

J'ai mis en place de la CI/CD et des suites de tests automatisés, avec un objectif précis : détecter les défauts en amont, avant qu'ils n'atteignent la QA, pour la décharger des livraisons de mauvaise qualité. Sur ce plan-là, ça a très bien fonctionné. Ce n'est pas la partie technique qui a échoué.

Le problème est venu d'ailleurs. En fluidifiant le pipeline de développement, ces améliorations ont aussi accéléré le rythme de production. Nous avons ensuite accompagné les développeurs sur l'usage de l'IA pour les aider dans leurs tâches. Mais l'effet net n'a pas été du meilleur code, il a été plus de code. Plus de fonctionnalités livrées, plus vite, avec une qualité de base qui ne s'améliorait pas vraiment.

Résultat : encore plus de volume à faire passer par le même goulot d'étranglement humain, désormais sous une pression accrue. Chaque optimisation locale que j'apportais au système ne faisait que déplacer la contrainte, et parfois l'intensifier, plutôt que de résoudre le vrai problème.

Bref, c'est une illustration assez nette d'un principe qu'on retrouve dans la théorie des contraintes : optimiser une étape qui n'est pas le goulot d'étranglement du système n'améliore pas le débit global, ça déplace simplement la pression vers le vrai point de blocage.

Ce qu'un freelance peut, et ne peut pas, résoudre seul

Cette mission m'a laissé une conviction assez claire. La dette technique, un freelance peut la traiter directement : refactoring, tests, CI/CD, ce sont des leviers qui dépendent largement de sa propre action. La dette organisationnelle, en revanche, demande une reconnaissance et une volonté qui appartiennent au client. On peut alerter, documenter le risque, proposer des solutions concrètes, mais on ne peut pas décider à la place de l'entreprise de réorganiser une équipe ou de recruter un binôme.

Ce n'est pas un constat pessimiste. C'est plutôt une invitation à élargir le diagnostic dès le départ d'une mission. Quand on me parle de vitesse de production, je sais d'expérience qu'il faut regarder au-delà du code : où est le vrai goulot d'étranglement, qui porte seul une connaissance critique, quelle documentation manque pour que cette connaissance puisse être transmise.

La dette technique se corrige avec du temps et de la rigueur. La dette organisationnelle, elle, ne se corrige qu'avec une décision. Et celle-ci n'appartient jamais au freelance.