Audit de dette technique : quoi regarder, quoi corriger d’abord

Un audit de dette technique répond à deux questions : qu’est-ce qui, dans votre application, fait perdre du temps à l’équipe ou vous expose à un incident, et par quoi faut-il commencer. Il se mène en lecture seule sur le code, la base de données, les comptes et l’historique des incidents. Il se termine par une liste de corrections classées selon le risque pour votre activité et l’effort qu’elles demandent, avec une décision par module : conserver, corriger ou remplacer.

Qu’est-ce que la dette technique, concrètement ?

L’image vient de Ward Cunningham, en 1992 : livrer un premier code écrit vite revient à s’endetter, et chaque minute passée ensuite à travailler avec ce code imparfait est un intérêt payé sur la dette (Cunningham, OOPSLA 1992). S’endetter n’est pas une faute. Martin Fowler distingue la dette prise volontairement, pour tenir une échéance en sachant ce que l’on reporte, de celle que l’on accumule sans s’en rendre compte (Technical Debt Quadrant). La première se pilote. L’audit sert surtout à mettre au jour la seconde.

Pour un dirigeant, la dette se lit rarement dans le code. Elle prend des formes plus concrètes :

• une bibliothèque ou un framework qui n’est plus maintenu, donc qui ne reçoit plus de correctifs de sécurité ;
• une partie du code que personne n’ose modifier, faute de tests ;
• une règle d’accès écrite trop vite, qui laisse un utilisateur lire les données d’un autre ;
• une mise en production manuelle, que seule une personne sait faire ;
• une architecture pensée pour quelques centaines d’utilisateurs, dont le coût grimpe à chaque nouveau client.

Quels signes montrent qu’un audit devient utile ?

Ces signes se constatent sans lire une ligne de code :

• chaque nouvelle fonctionnalité prend plus de temps que la précédente, à taille comparable ;
• les mêmes bugs reviennent après avoir été corrigés ;
• une seule personne sait mettre en production, ou connaît une partie du code ;
• vous ne savez pas combien l’application coûte par mois, ni pourquoi la facture augmente ;
• un prestataire s’en va, ou une nouvelle équipe arrive ;
• un investisseur, un acquéreur ou un gros client pose des questions techniques auxquelles personne ne sait répondre ;
• l’application a été générée avec Lovable, Bolt ou un outil proche, et elle va accueillir de vrais clients.

Si c’est une levée de fonds ou un rachat qui déclenche l’audit, lisez aussi ce que vérifie une due diligence technique. Si c’est un client qui pose des questions de sécurité, l’article sur la sécurité et le RGPD d’un SaaS détaille le socle attendu.

Que regarde un audit de dette technique ?

Une partie de la dette se trouve autour du code : dans les comptes, les sauvegardes ou les dépendances. Un audit sérieux couvre au moins ces dix points.

• Ce qui marche vraimentChaque fonctionnalité annoncée est opérationnelle, partielle ou absente.
• Accès aux donnéesUn utilisateur ne voit que ses données, vérifié côté serveur.
• Clés secrètesAucune clé dans le code envoyé au navigateur ni dans l’historique.
• DépendancesDes versions encore maintenues, sans vulnérabilité connue laissée ouverte.
• Structure du codeUn autre développeur peut reprendre le projet sans son auteur.
• Tests et livraisonLes parcours critiques sont testés et le retour en arrière est possible.
• SauvegardesUne restauration a déjà été testée sur une copie de la base.
• Propriété des comptesDépôt, hébergeur, base et domaine sont au nom de la société.
• Coûts mensuelsConnus poste par poste, aujourd’hui et à 10 fois plus d’utilisateurs.
• DocumentationL’architecture et les opérations courantes sont écrites quelque part.

Quatre de ces points méritent une explication plus détaillée.

Les dépendances et leurs versions

Une application s’appuie sur de nombreuses bibliothèques écrites par d’autres. Quand l’une d’elles n’est plus maintenue, elle ne reçoit plus de correctifs de sécurité. Exemple daté : Node.js 20, une version du moteur JavaScript utilisé côté serveur, est en fin de vie depuis le 30 avril 2026 (calendrier des versions Node.js). Node.js recommande de n’utiliser en production que des versions encore suivies, dites LTS active ou de maintenance (Node.js).

L’OWASP, la fondation de référence en sécurité des applications web, place les défaillances de la chaîne d’approvisionnement logicielle (les risques qui viennent des composants tiers) au troisième rang de son classement 2025 (OWASP Top 10:2025). Sur GitHub, les alertes Dependabot signalent les dépendances qui ont une vulnérabilité connue (documentation GitHub).

L’accès aux données et les clés secrètes

Le premier risque du même classement est le contrôle d’accès défaillant : un utilisateur peut voir ou modifier des données qui ne lui appartiennent pas. L’audit vérifie que chaque règle est appliquée par le serveur ou par la base de données, et pas seulement masquée dans l’interface. Sur Supabase, par exemple, cela passe par les règles de sécurité au niveau des lignes, appelées RLS (documentation Supabase).

Pour les clés secrètes (paiement, e-mails, IA), la détection de secrets de GitHub analyse tout l’historique du dépôt (documentation GitHub). Une clé supprimée du code reste lisible dans cet historique : il faut donc la remplacer par une nouvelle clé.

La livraison et le retour en arrière

Le programme de recherche DORA propose des indicateurs simples pour suivre la livraison d’une équipe : le délai entre une modification et sa mise en production, la fréquence des mises en production, la part de celles qui demandent une intervention immédiate, et le temps nécessaire pour se rétablir après une mise en production ratée (DORA). L’audit regarde aussi si l’équipe sait revenir à la version précédente en quelques minutes, et si les changements de structure de la base sont enregistrés dans le dépôt.

Les comptes, les sauvegardes et les coûts

Le dépôt de code, l’hébergeur, la base de données et le nom de domaine doivent être au nom de votre société. Une sauvegarde n’a de valeur que si une restauration a déjà été testée. Enfin, le coût mensuel se calcule poste par poste, aujourd’hui et à dix fois plus d’utilisateurs : c’est à cette échelle qu’une architecture inadaptée devient visible sur la facture.

Comment se déroule l’audit ?

Les cinq étapes d’un audit de dette technique

1. 01Accès en lecture seuleDépôt de code, base de données, hébergeur et suivi des erreurs.
2. 02CadrageCe que l’application doit faire, ce qui inquiète, les incidents récents.
3. 03AnalyseChaque point vérifié dans le code, avec des exemples précis.
4. 04NotationUn feu vert, orange ou rouge par point, et l’effort estimé.
5. 05RestitutionUn plan conserver, corriger, remplacer, dans l’ordre de traitement.

Vous donnez un accès en lecture seule au dépôt de code et aux outils (base de données, hébergeur, suivi des erreurs), puis vous décrivez ce que l’application doit faire, ce qui vous inquiète et les derniers incidents. Un accord de confidentialité peut être signé avant l’ouverture des accès.

Vous recevez un rapport lisible par un dirigeant comme par un développeur : un point par ligne, un feu vert, orange ou rouge par point, des exemples tirés de votre code et un plan. Chez Techvisor, le diagnostic express prend environ 3 jours ouvrés pour 1 200 € HT. L’audit complet, qui ajoute l’inventaire de ce qui marche vraiment et une feuille de route chiffrée, prend environ 5 jours ouvrés pour 2 400 € HT. La page de l’audit d’application montre un exemple fictif de rapport.

Comment prioriser les corrections ?

Chaque point relevé reçoit deux notes.

• Le risque pour l’activité. Que se passe-t-il si l’on ne fait rien ? Du plus grave au moins grave : fuite ou perte de données clients, argent perdu ou bloqué (paiement, facturation), application indisponible, vente ou levée de fonds bloquée, équipe ralentie.
• L’effort de correction, en jours de travail, estimé par la personne qui corrigera.

Le croisement des deux place chaque correction dans l’une des quatre cases ci-dessous.

Classer chaque correction selon le risque et l’effort

FaibleRisque pour l’activitéFort

Au fil de l’eauPlus tard, ou jamaisTout de suiteÀ planifierClé secrète exposéeRègle d’accès ouverteSauvegarde jamais restauréePaiement sans testsFramework en fin de supportDocumentation absenteCode dupliquéRefonte de l’interface

FaibleEffort de correctionFort

• Tout de suite (risque fort, effort faible) : avant toute nouvelle fonctionnalité. Une clé exposée ou une règle d’accès ouverte entre dans cette case.
• À planifier (risque fort, effort fort) : à découper en étapes, chacune avec une date et un responsable.
• Au fil de l’eau (risque faible, effort faible) : à corriger quand l’équipe retouche la zone concernée.
• Plus tard, ou jamais (risque faible, effort fort) : à noter et à assumer. Une dette qui ne coûte rien peut rester.

Pour chaque module, la décision finale se prend avec ces critères.

Comment réduire la dette sans arrêter les nouveautés ?

• Traitez les urgences en une fois, avant de reprendre les développements prévus.
• Réservez une part fixe de chaque cycle de développement à la dette, décidée avec l’équipe et tenue même quand le planning est chargé.
• Consolidez là où vous allez construire : avant d’ajouter une fonctionnalité dans un module fragile, on le stabilise et on le couvre de tests.
• Tenez un registre de la dette : chaque raccourci volontaire y est noté, avec sa raison et la date prévue de son remboursement.
• Suivez peu d’indicateurs, toujours les mêmes : délai de mise en production, mises en production ratées, incidents et coût mensuel.

Que demander à un prestataire d’audit ?

Avant de signer, posez ces questions :

1. Les accès sont-ils en lecture seule, et retirés à la fin ?
2. Le rapport cite-t-il des exemples tirés de mon code, ou des généralités ?
3. Le prix est-il fixe et connu avant de commencer ?
4. Le rapport donne-t-il une décision par point, lisible sans être développeur ?
5. Dans quels cas conseillez-vous de conserver le code existant ? Un prestataire qui recommande la refonte à chaque fois ne vous apprend rien sur votre application.
6. Mon équipe ou une autre agence pourra-t-elle se servir du rapport ?

Mon avis de CTO

J’ai cofondé Welco en 2019 et j’en suis le CTO ; je suis aussi associé et CTO de Jo’s Burger depuis 2024. Dans ces deux entreprises, un mauvais choix technique coûte à ma propre société, et c’est avec ce réflexe que je lis la dette des autres. Chez Axiome Avocats, j’ai comparé plusieurs scénarios d’évolution du système d’information, avec leurs coûts et leurs risques, avant de proposer une feuille de route progressive. Je procède de la même façon pour la dette : je ne recommande de refaire que ce qui doit l’être, et je commence toujours par ce qui expose les données ou l’argent de vos clients. Une dette connue, chiffrée et remboursée selon un plan n’inquiète ni une équipe ni un investisseur. Celle que l’on découvre pendant un incident se règle dans l’urgence, au plus mauvais moment.

Questions fréquentes

Combien coûte un audit de dette technique ?

Chez Techvisor, 1 200 € HT pour le diagnostic express (sécurité, code, données et coûts) et 2 400 € HT pour l’audit complet avec feuille de route chiffrée. Les corrections ne sont pas incluses : votre équipe peut les mener avec le plan, ou la formule de reprise et mise en production démarre à 5 000 € HT.

Combien de temps dure l’audit ?

Environ 3 jours ouvrés pour le diagnostic express et environ 5 pour l’audit complet. Ce sont des estimations : la taille du code et le nombre d’outils connectés les font varier.

Faut-il arrêter les développements pendant l’audit ?

Non. L’audit se fait en lecture seule et ne touche pas à l’application. Il est même utile que l’équipe continue à livrer : l’auditeur voit ainsi comment elle travaille réellement.

Un outil d’analyse automatique ne suffit-il pas ?

Les outils (alertes sur les dépendances, détection de secrets, analyse statique du code) repèrent des symptômes et méritent de tourner en continu. Ils ne disent pas ce qui compte pour votre activité, ni si les fonctionnalités annoncées marchent vraiment, ni à qui appartiennent vos comptes. L’audit part de leurs résultats, puis tranche.

Mon application a été créée avec Lovable ou Bolt. La méthode change-t-elle ?

La méthode reste la même, les priorités changent : règles d’accès à la base, clés présentes dans le code envoyé au navigateur, séparation entre test et production, propriété des comptes de l’outil. La page reprise d’application détaille ces points outil par outil.

Prochaine étape

Pour un premier tri sans être développeur, la checklist « Votre app est-elle prête pour de vrais clients ? » pose 30 questions fermées sur les accès aux données, les secrets, les comptes, les sauvegardes, les paiements et le RGPD. Chaque « je ne sais pas » devient une question à poser à votre équipe.

Pour un regard extérieur sur votre code, l’audit d’application applique cette méthode : un feu par point, un plan conserver, corriger, remplacer, et une heure de restitution en visio. Si vous hésitez entre les formules, réservez un échange de 15 minutes. Cet échange est gratuit et sans engagement.

Sources

• Ward Cunningham, « The WyCash Portfolio Management System », OOPSLA 1992
• Martin Fowler, « Technical Debt Quadrant »
• OWASP, Top 10:2025
• Node.js, calendrier des versions et page des versions publiées
• GitHub Docs, alertes Dependabot et détection de secrets
• Supabase, Row Level Security
• DORA, les métriques de livraison logicielle