Audit de code : combien ça coûte, ce que ça change

Un fondateur m'a contacté pour un audit de code. Son budget : 1 500 €. Il avait une app en production depuis deux mois, construite par un freelance, et un mauvais pressentiment.

L'audit a révélé une faille d'authentification. Pas une faille théorique — une faille exploitable. N'importe qui avec un navigateur et dix minutes de curiosité pouvait accéder aux données de ses 2 000 utilisateurs. Noms, emails, historique de commandes. Tout.

Correction : 3 jours de travail. Coût si la faille avait été découverte par quelqu'un d'autre, six mois plus tard : communication de crise, notification CNIL, perte de clients, refonte partielle. Minimum 20 000 €. Probablement plus.

Ce fondateur me dit souvent que ces 1 500 € sont le meilleur investissement de son année. Je vais vous expliquer pourquoi il a raison, combien ça coûte réellement, et surtout ce que vous recevez.

Un audit de code, c'est quoi concrètement ?

Imaginez que vous achetez un appartement. Vous faites venir un expert qui regarde la structure, l'électricité, la plomberie, l'isolation. Il ne vous dit pas "c'est bien" ou "c'est mal". Il vous dit : "Ce mur porte, ne le touchez pas. Cette fuite va empirer. Ce câblage n'est pas aux normes — risque d'incendie."

Un audit de code, c'est la même chose pour votre application. Un ingénieur ouvre le capot et regarde ce qui se passe sous l'interface. La sécurité, la performance, l'architecture, la qualité du code. Il cherche les risques concrets — pas les problèmes théoriques.

Ce n'est pas un examen de passage. Je ne donne pas une note sur 20. Je donne une carte des risques. Avec pour chaque risque : la gravité, l'impact business, et comment le corriger.

Une confusion revient souvent : la différence entre audit et revue de code. La revue, c'est un contrôle continu — on vérifie chaque modification au fil de l'eau. L'audit, c'est un bilan complet à un instant T. Comme la différence entre un check-up annuel et prendre sa tension tous les jours. Les deux sont utiles, mais ils ne répondent pas au même besoin.

Combien ça coûte

Parlons chiffres. Ce sont les fourchettes que je pratique et que je vois sur le marché pour des applications web ou mobile de taille standard — startup ou PME avec une app métier.

Pour une plateforme bancaire avec 200 microservices, on est sur d'autres ordres de grandeur. Mais pour 95% des fondateurs qui me contactent, c'est ce tableau qui s'applique.

Ce qui fait varier le prix, ce n'est pas le nombre de lignes de code. J'ai audité des apps de 50 000 lignes en deux jours et des apps de 5 000 lignes en une semaine. Ce qui compte, c'est la complexité métier : combien de points d'entrée, combien de flux de données sensibles, combien d'intégrations avec des services tiers. Une app avec un système de paiement, des données de santé et trois API partenaires demande plus de travail qu'un SaaS avec un CRUD classique, même si le CRUD a plus de code.

Un cas qui revient souvent : un fondateur hésite entre un audit à 2 000 € et recruter un CTO à 8 000 € par mois pour "mettre de l'ordre". Il me contacte, je fais l'audit. Résultat : le code est correct. Trois points à corriger, une semaine de travail pour un développeur senior. Pas besoin d'un CTO. Économie sur l'année : le prix d'un recrutement inutile.

Ce que vous recevez concrètement

Quand un fondateur me demande ce qu'il va recevoir, il imagine souvent un pavé de 200 pages rempli de jargon technique incompréhensible. Non.

Mon livrable tient en 15 à 25 pages. Il contient quatre choses :

L'état des lieux — une photo de votre application à l'instant T. Technologies utilisées, architecture, dépendances. En langage clair, pas en jargon.

Les failles et risques identifiés — chaque problème classé par criticité (critique, important, mineur). Pour chacun : ce que c'est, pourquoi c'est un problème pour votre business, et l'impact concret. Pas "cette variable n'est pas typée". Plutôt : "un utilisateur peut accéder aux données d'un autre utilisateur via cette URL — risque de fuite de données personnelles".

Le plan d'action priorisé — c'est le document qui a le plus de valeur. Les corrections classées par ordre de priorité, avec une estimation du temps nécessaire. Vous savez exactement quoi faire corriger en premier et combien ça va coûter.

Les recommandations d'évolution — si votre application va devoir monter en charge ou évoluer, j'indique les points qui vont poser problème et comment les anticiper.

Un rapport qui liste 47 problèmes sans les prioriser ne sert à rien. Vous ne savez pas par où commencer, et votre développeur non plus. C'est le plan d'action qui transforme un diagnostic en décisions concrètes.

L'audit qui a économisé 20 000 €

Je reviens sur cette histoire parce qu'elle illustre exactement le ROI d'un audit de code.

Ce fondateur avait une app e-commerce construite par un freelance trouvé sur Malt. L'app fonctionnait, les ventes tombaient, tout semblait rouler. Il m'a contacté parce qu'il voulait passer à l'échelle — plus de trafic, plus de fonctionnalités — et il voulait s'assurer que les fondations tenaient.

J'ai trouvé quatre problèmes. Un critique, deux importants, un mineur.

Le critique : la gestion des sessions utilisateurs. Sans entrer dans les détails techniques, n'importe qui pouvait se faire passer pour un autre utilisateur. Pas en théorie — en pratique. J'ai reproduit l'exploitation en cinq minutes dans mon rapport, captures d'écran à l'appui.

Si cette faille avait été découverte par quelqu'un d'autre :

• Notification CNIL obligatoire dans les 72 heures (RGPD)
• Communication aux 2 000 utilisateurs concernés
• Perte de clients — difficile à chiffrer, mais des utilisateurs auraient quitté la plateforme
• Refonte sécurité en urgence — facilement 10 000 à 15 000 € avec un prestataire qui sait que vous êtes pressé
• Quatre à six semaines de travail perdues au lieu de développer la roadmap prévue

Coût de l'audit : 1 500 €. Coût de la correction : environ 2 000 € (une semaine de dev). Total : 3 500 €. Coût évité : 20 000 € minimum, sans compter la perte de confiance. Le calcul est vite fait.

Ce qui arrive quand on ne fait pas d'audit

L'histoire inverse, je l'ai vue aussi. Et elle est moins agréable à raconter.

Un fondateur, une app SaaS B2B. Belle interface, bons retours utilisateurs, croissance régulière. Pas d'audit — "on n'a pas le budget, et puis ça tourne bien".

Six mois après la mise en production, un client lui signale un comportement bizarre. En creusant, l'équipe découvre que certaines données sont accessibles sans authentification via l'API. Pas toutes — juste certains endpoints que personne n'avait testés correctement. Mais suffisamment pour que des données clients soient exposées depuis le premier jour.

Deux clients ont résilié immédiatement. La correction a pris six semaines — les fondations étaient fragiles, corriger un point créait des régressions ailleurs. L'équipe a passé un mois à gérer la crise au lieu de développer la roadmap. Le fondateur a finalement recruté un CTO senior à 9 000 €/mois pour "remettre les choses en ordre".

Un audit à 2 000 € six mois plus tôt aurait identifié le problème en deux jours. Si vous avez construit votre app avec un outil comme Lovable ou Bolt, ce type de vérification n'est pas un luxe.

Quand faire un audit — et quand c'est inutile

Avant la mise en production, c'est le moment idéal. Les corrections coûtent 5 à 10 fois moins cher avant le lancement qu'après, quand de vrais utilisateurs dépendent de l'application.

Avant une levée de fonds. Les investisseurs sérieux demandent de plus en plus une due diligence technique. Arriver avec un rapport d'audit propre, c'est un signal de maturité. Et si l'audit révèle des problèmes, mieux vaut les connaître avant la négociation.

Après un développement externalisé, c'est presque indispensable. Vous avez fait construire votre app par une agence ou un freelance. Le travail est livré, ça fonctionne. Mais est-ce que c'est solide ? Un audit indépendant vous donne une réponse objective — pas celle du prestataire qui a intérêt à vous dire que tout va bien.

Et quand vous avez un doute. "L'app rame depuis qu'on a dépassé 500 utilisateurs." "Mon dev me dit que tout va bien mais les bugs s'accumulent." Si vous avez un pressentiment, il vaut probablement le coup d'être vérifié. L'intuition des fondateurs est rarement infondée.

En revanche, ne dépensez pas d'argent inutilement. Si vous avez un prototype de trois semaines que vous allez peut-être jeter, si votre app est un outil interne pour cinq personnes sans données sensibles, si vous allez tout réécrire de toute façon — gardez votre budget.

Comment choisir son auditeur

Posez une question simple : "Qu'est-ce que je reçois exactement ?" Si la réponse est vague ("un rapport"), passez votre chemin. Vous devez savoir : combien de pages, quel format, quelles sections, est-ce que ça inclut un plan d'action priorisé.

Demandez si l'auditeur a déjà travaillé sur des apps similaires à la vôtre. Quelqu'un qui connaît votre stack technique (React, Node.js, Supabase…) ira plus vite et plus profond qu'un généraliste qui découvre l'environnement.

La question de la priorisation est révélatrice. Un bon auditeur priorise par impact business, pas par sévérité technique. Un problème "mineur" techniquement peut avoir un impact majeur sur vos utilisateurs.

Et méfiez-vous des audits gratuits. Si quelqu'un vous propose un audit de code gratuit, il vend autre chose — du développement, de l'hébergement, du consulting. Un audit indépendant a un prix parce que l'auditeur n'a rien à vous vendre derrière. Juste la vérité sur votre code.

Vous avez un doute sur votre code ? Demandez un audit — je vous dis ce que je vois, sans langue de bois.