L'audit dit qu'il faut tout refaire. Faut-il le croire ?
Un audit de code examine la sécurité, l'architecture, la maintenabilité et le déploiement, puis classe les problèmes par gravité. Son prix, quand le lancer, comment lire le rapport, et cinq questions à poser avant de tout refaire.
Sommaire
« On ne dit jamais ça, mais là, il faut tout casser. » Peu de fondateurs oublient le jour où un auditeur leur a sorti cette phrase. Parfois, il a raison. Souvent, la réponse est plus nuancée.
Un audit de code est l'examen d'une application par un expert extérieur : il lit le code source, l'architecture et l'infrastructure, puis classe ce qu'il trouve par gravité. Ce guide explique ce qu'un audit vérifie, combien il coûte, quand le lancer, et surtout comment lire ses conclusions sans paniquer. Il s'adresse aux fondateurs et aux dirigeants qui ne lisent pas de code mais doivent décider sur la base du rapport.
Qu'est-ce qu'un audit de code vérifie ?
Un bon audit ne se contente pas de dire si le code est « propre ». Il répond à une question d'entreprise : ce produit peut-il tenir la croissance prévue, et à quel prix ? Il couvre en général six domaines.
| Domaine | Ce que l'auditeur regarde |
|---|---|
| Sécurité | Failles connues, gestion des mots de passe et des clés, droits d'accès, données personnelles exposées. |
| Architecture | Découpage du code, dépendances entre modules, choix de base de données, ce qui empêche d'évoluer. |
| Maintenabilité | Lisibilité, tests automatisés, documentation, temps qu'il faudrait à un nouveau développeur pour être efficace. |
| Performance | Lenteurs, requêtes coûteuses, tables qui grossissent sans limite, ce qui cassera quand le trafic doublera. |
| Déploiement | Comment le code part en ligne, séparation préversion et production, sauvegardes, retour arrière possible. |
| Dépendances | Bibliothèques obsolètes, services tiers critiques, comptes au nom d'anciens prestataires. |
Combien coûte un audit de code ?
Le prix dépend surtout de la taille du code et du périmètre : un audit de sécurité avec tests d'intrusion coûte plus cher qu'une revue d'architecture. Les fourchettes ci-dessous sont publiées par un prestataire d'audit français. Elles donnent un ordre de grandeur, pas un prix de marché.
| Taille du code | Prix indicatif |
|---|---|
| Moins de 20 000 lignes | 4 000 à 5 500 € HT |
| 20 000 à 80 000 lignes | 6 000 à 9 000 € HT |
| Plus de 80 000 lignes | 9 000 à 12 000 € HT |
Fourchettes relevées le 29 octobre 2026, publiées par un prestataire d'audit. Source : Kolonell, prix d'un audit de code en 2026.
Le même prestataire annonce deux à quatre semaines de travail. Demandez toujours deux ou trois devis sur le même périmètre écrit : les écarts disent beaucoup de la profondeur réelle de l'examen.
Quand faut-il faire auditer son code ?
Un audit coûte quelques milliers d'euros. Il se justifie quand une décision plus chère en dépend. Cinq moments reviennent.
Avant de changer d'équipe ou de prestataire
Vous saurez ce que vous transmettez, et la nouvelle équipe ne pourra pas tout mettre sur le dos de l'ancienne.
Quand votre CTO ou votre développeur principal part
La connaissance s'en va avec lui. Un audit fait pendant son préavis fixe ce qui doit être documenté en priorité.
Quand le produit ralentit sans explication claire
Lenteurs, pannes à répétition, factures d'hébergement qui grimpent. Un regard extérieur trouve souvent la cause en quelques jours.
Avant une levée de fonds ou un rachat
Les investisseurs feront leur propre examen. Mieux vaut connaître les problèmes avant eux, et avoir un plan pour chacun.
Quand un nouveau profil arrive et doute
Un nouveau responsable produit ou technique sent que « quelque chose ne va pas » sans pouvoir le prouver. L'audit transforme une intuition en liste.
Si l'audit est déclenché par un départ, commencez par sécuriser les accès : départ du CTO ou du développeur, que faire et dans quel ordre.
Comment lire le rapport : trois piles
Un rapport d'audit liste souvent des dizaines de points. Tous ne se valent pas. Classez-les en trois piles avant de décider quoi que ce soit.
Urgent : ce qui met l'entreprise en danger
Failles de sécurité, données exposées, absence de sauvegarde, accès au nom d'une personne partie. Ça se traite tout de suite, quel que soit le reste du plan. C'est rarement le plus gros chantier.
Structurel : ce qui freine la croissance
Une base de données qui ne tiendra pas la charge, une architecture qui rend chaque évolution lente, un front qui met des secondes à charger. Ça se planifie, par étapes, à côté des nouvelles fonctionnalités.
Confort : ce qui gêne sans bloquer
Conventions de nommage, code dupliqué, tests manquants sur des parties stables. Ça s'améliore au fil de l'eau, quand on touche la zone concernée. Pas avant.
L'audit dit « il faut tout refaire » : cinq questions à poser
La réécriture totale est la recommandation la plus chère et la plus risquée. Elle est parfois justifiée. Avant de l'accepter, posez ces cinq questions, à l'auditeur et à vous-même.
Qu'est-ce qui casse concrètement aujourd'hui ?
Pas « le code est sale ». Quelles pannes, quelles lenteurs, quelles évolutions impossibles ? Si personne ne peut nommer un problème vécu par vos clients, la refonte répond à une gêne de développeur.
Peut-on isoler la partie malade ?
Dans la plupart des produits, les problèmes se concentrent sur une ou deux zones : la base de données, un module central. Les refaire en gardant le reste coûte une fraction d'une réécriture complète.
Combien de mois sans nouveauté pour vos clients ?
Pendant une réécriture, le produit en ligne ne bouge plus, ou très peu. Vos concurrents, eux, continuent. Chiffrez ce gel avant de chiffrer la refonte.
Celui qui recommande la refonte la vend-il ?
Un auditeur qui propose ensuite de réaliser la réécriture a un intérêt à la recommander. Ça ne le rend pas malhonnête. Ça justifie un second avis.
Qu'est-ce qui garantit que la version 2 sera meilleure ?
Le code est rarement mauvais par hasard : délais intenables, équipe qui tourne, demandes floues. Si ces causes restent, la nouvelle version vieillira de la même façon, juste plus tard.
La grille de décision complète entre refondre et faire évoluer est dans notre article sur la dette technique.
Après l'audit : le plan des trente premiers jours
Un audit utile se termine par un plan, pas par un PDF rangé dans un dossier. Voici un enchaînement réaliste.
Semaine 1 : tout ce qui est urgent
Corriger les failles, récupérer les accès, vérifier qu'une sauvegarde se restaure vraiment. Ce sont souvent quelques jours de travail.
Semaine 2 : découper le structurel
Transformer chaque problème structurel en demandes livrables, avec un résultat mesurable : « la page met moins de deux secondes à charger », pas « refaire le front ».
Semaines 3 et 4 : alterner
Une demande structurelle, une nouveauté pour vos clients, et ainsi de suite. Le produit s'assainit sans s'arrêter.
Si le code vient d'un prestataire dont vous vous séparez, la liste de ce qu'il faut récupérer est ici : reprendre le code d'un prestataire. Si votre application a été construite avec une IA, voyez aussi la checklist de sécurité avant la mise en production.
Note de transparence : chez Figue, nous regardons le code au premier échange et nous commençons chaque reprise par un état des lieux de la sécurité et de l'infrastructure. Nous ne poussons pas à la réécriture. Le détail de l'offre : reprise de code et maintenance applicative.
FAQ
Questions fréquentes
Ce qu'on nous demande avant et après un audit.
Qu'est-ce qu'un audit de code ?
C'est l'examen d'une application par un expert extérieur, qui lit le code source, l'architecture et l'infrastructure. Il couvre la sécurité, la maintenabilité, la performance, le déploiement et les dépendances, et classe les problèmes par gravité.
Combien coûte un audit de code ?
Les fourchettes publiées en 2026 par un prestataire français vont de 4 000 à 12 000 € HT selon la taille du code, pour deux à quatre semaines de travail. Un audit de sécurité avec tests d'intrusion coûte plus cher.
Combien de temps dure un audit de code ?
En général deux à quatre semaines entre l'ouverture des accès et la remise du rapport. Un audit limité à un module précis peut prendre quelques jours.
Faut-il tout refaire si l'audit le recommande ?
Pas forcément. Demandez ce qui casse concrètement, si la partie malade peut être isolée, combien de mois sans nouveauté la refonte imposerait et ce qui garantit que la nouvelle version sera meilleure. Un second avis est utile si l'auditeur vend aussi la refonte.
Qui doit faire l'audit de son code ?
Un expert extérieur à l'équipe qui a écrit le code, sans intérêt direct à recommander une solution plutôt qu'une autre. Demandez des exemples de rapports anonymisés et deux ou trois devis sur le même périmètre.
