Audit de la dette technique : quelle dette vous ralentit, et laquelle vous pouvez laisser où elle est

L’audit est une analyse de la dette technique faite sur le code réel, avec les personnes qui le modifient chaque jour. Les outils d’analyse nous aident à repérer les points à regarder ; les conclusions, elles, naissent de la lecture de ces points avec l’équipe.

La cartographie reste utile même si nous ne retravaillons plus ensemble. Le choix dépend de l’ampleur et de l’emplacement de la dette, et c’est vous qui décidez, cartographie en main.

Faut-il vous donner accès au code ?

Oui, au repository et à l’historique des modifications. Sans le code réel, l’audit deviendrait un questionnaire, ce que nous voulons justement éviter.

Quelle est la durée ?

Le format standard dure environ quatre semaines, avec une première cartographie des points critiques dès la deuxième ou la troisième. Pour les grandes codebases ou les équipes distribuées, il existe un format approfondi, jusqu’à deux mois, qui observe plusieurs cycles de release et un historique de modifications plus long.

Sur quelles technologies travaillez-vous ?

Nous sommes agnostiques vis-à-vis du langage. Nous travaillons avec votre stack actuel et adoptons les technologies que votre équipe utilise déjà. Historique des modifications, couplage, testabilité et flux de release se lisent dans n’importe quel stack.

Nous utilisons déjà SonarQube ou CodeScene : l’audit sert-il quand même ?

Ces outils indiquent où le code est complexe ou change souvent, et leurs données nous sont utiles. Ils ne disent pas quelle dette pèse sur le métier, laquelle peut rester où elle est, ni dans quel ordre intervenir. C’est pourquoi il faut les entretiens, la lecture du code avec l’équipe et la connaissance de la roadmap.

Quelle différence entre un audit de code classique et un audit de la dette technique ?

Un audit de code classique vérifie la qualité par rapport à des règles et des standards, et produit une liste de problèmes. L’audit de la dette technique part du même code, mais répond à une autre question : quelle dette ralentit les modifications qui comptent pour le métier, et dans quel ordre les traiter. Pour cela, il croise le code avec l’historique des modifications et les entretiens avec l’équipe. Si vous cherchez un conseil ou une évaluation de votre dette technique, c’est généralement par là qu’on commence.

Que se passe-t-il si la dette est partout ?

Il est rare qu’elle pèse partout de la même façon. En général, quelques zones concentrent l’essentiel de la friction, parce que ce sont celles qui changent le plus souvent ; la cartographie sert justement à les isoler du reste et à décider par laquelle commencer.

Est-ce utile avant de décider une réécriture ?

C’est le moment où c’est le plus utile. La réécriture a du sens dans peu de cas : une technologie qui ne reçoit plus de mises à jour de sécurité, ou un couplage qui rend impossible d’isoler quoi que ce soit. L’audit vous dit si votre système fait partie de ces cas, ou si un refactoring incrémental arrive plus vite et avec moins de risque.

Quelle différence avec une tech due diligence ?

La tech due diligence s’adresse à ceux qui évaluent un logiciel qu’ils ne possèdent pas encore, avant un investissement ou une acquisition. L’audit de la dette technique s’adresse à ceux qui développent déjà leur logiciel, et veulent savoir où intervenir pour recommencer à le modifier facilement.