Ce qu'un audit de code n'est pas
Quand je dis "audit de code", beaucoup de gens imaginent un prof sévère qui ouvre ton projet, soupire, et te rend une copie pleine de rouge. Genre "ton code est nul, recommence".
Ce n'est pas du tout ça. Et si c'était ça, ce serait inutile.
Un audit de code, c'est une carte de tes risques. Pas un jugement de valeur, pas une note pour le plaisir de noter. L'idée n'est pas de dire "c'est bien" ou "c'est mal", mais de répondre à une question simple : qu'est-ce qui peut te faire mal, à quel point, et dans quel ordre on s'en occupe ?
C'est important si tu as vibe-codé ton produit. Parce que le code généré à l'IA a un profil très particulier : il marche, souvent il est même propre sur le cœur, mais il a des angles morts récurrents. Un audit, c'est ce qui transforme "je crois que mon app va bien" en "je sais exactement où elle est fragile, et j'ai un plan".
Voici comment je m'y prends, étape par étape.
Le bon moment pour faire un audit
Avant de rentrer dans la méthode, la question que tout le monde se pose : quand ?
Il y a trois moments où ça vaut vraiment le coup :
- Avant la mise en prod. Tu as un truc qui marche, tu t'apprêtes à le mettre entre les mains de vrais utilisateurs. C'est le moment idéal : tu fermes les portes avant que quelqu'un les pousse.
- Avant de passer à l'échelle. L'app tourne, mais tu vas accélérer (plus d'utilisateurs, une levée, un gros client). Tu veux savoir ce qui va casser quand la charge monte.
- Avant de vendre ou de te faire racheter. Un acheteur sérieux fera auditer ton code. Autant savoir ce qu'il va trouver avant lui.
Le point commun : un audit, c'est une photo prise avant que le risque devienne un problème. Après, ça s'appelle une réparation d'urgence, et ça coûte beaucoup plus cher.
Étape 1 : couvrir large, sur quatre volets
Je ne regarde pas juste "est-ce que le code est joli". Je passe l'app sur quatre angles différents, parce qu'un produit peut être nickel sur un et catastrophique sur un autre.
- L'architecture. Comment le code est organisé. Est-ce qu'on peut le faire évoluer sans tout casser, ou est-ce que tout est emmêlé au point que toucher un truc en casse trois autres ?
- La sécurité. Les portes d'entrée. Mots de passe, accès aux données, failles connues, config de déploiement. (J'ai détaillé les trous les plus fréquents dans cet article sur les risques de sécurité du vibe coding.)
- La qualité du code. La maintenabilité. Est-ce qu'un humain (toi, ou le dev que tu vas recruter) peut reprendre ce code sans y passer des semaines ? Code mort, fichiers à rallonge, duplication.
- La chaîne de déploiement. Tout ce qui entoure le code. Sauvegardes, mise en ligne, possibilité de revenir en arrière si un déploiement casse tout, tests automatiques.
Pourquoi quatre volets et pas juste "la sécurité" ? Parce que les risques ne vivent pas au même endroit. Une app peut avoir une sécurité correcte et zéro sauvegarde (le scénario le plus dangereux, parce qu'irréversible). L'inverse existe aussi. Si tu ne regardes qu'un angle, tu rates l'essentiel.
Étape 2 : lire en profondeur, pas survoler
Un audit qui se contente de faire tourner un outil automatique et de te recracher la liste, ça ne sert à rien. Les outils sortent des centaines d'alertes, dont 90% sans importance, et ratent justement les trucs subtils.
Le vrai travail, c'est de lire le code. Vraiment. Suivre ce qui se passe quand un utilisateur clique, tracer où vont les données, me demander à chaque étape "et si quelqu'un trafiquait ça, il se passe quoi ?".
C'est là que se trouvent les findings qui comptent. Le genre de truc qu'aucun outil ne voit : une fonction appelée au mauvais moment, un contrôle d'accès qu'on peut contourner par une porte de derrière, une logique métier qui part en vrille dans un cas précis. Ça, ça demande des yeux humains qui se sont déjà pris des murs.
Étape 3 : classer, parce que tout n'a pas la même gravité
C'est l'étape qui fait toute la valeur d'un audit. Trouver des problèmes, c'est facile. Te dire lesquels comptent vraiment, c'est le boulot.
Je classe chaque finding sur deux axes :
La gravité. Tous les problèmes ne se valent pas. Je range en trois niveaux :
- Critique : à corriger avant la prod. Pas négociable.
- Moyen : à planifier, mais pas une urgence.
- Mineur ou conforme : bon à savoir, ou carrément déjà bien fait (oui, un audit dit aussi ce qui va bien, c'est important).
L'effort. Un problème grave qui se règle en dix minutes, ce n'est pas le même sujet qu'un problème moyen qui demande deux semaines. Je chiffre chaque correction, pour que tu saches où est le meilleur rapport sécurité gagnée par heure passée.
Et il y a un critère que je traque en priorité : l'irréversibilité. Une faille de sécurité, tu la corriges après coup si besoin. Une donnée perdue parce qu'il n'y avait pas de sauvegarde, elle ne revient jamais. Un risque irréversible passe toujours devant, même s'il a l'air moins spectaculaire.
Étape 4 : un plan, pas une liste de reproches
Le livrable, ce n'est pas un tas de problèmes balancés en vrac. C'est un plan d'action en phases, lisible, priorisé. En général ça ressemble à ça :
- Phase 1, avant la prod. Les quelques points critiques. Souvent une poignée, souvent rattrapables en un à deux jours. C'est ce qui transforme "bon socle, pas prêt" en "déployable sereinement".
- Phase 2, la dette immédiate. Les bugs latents, la gestion d'erreur, le nettoyage du code mort. Ce qui te ralentit au quotidien sans te mettre en danger tout de suite.
- Phase 3, les chantiers de fond. L'architecture à reprendre par étapes, les tests à mettre en place. Le travail de long terme, qu'on étale.
L'idée, c'est que tu saches quoi faire lundi matin, et quoi garder pour dans trois mois. Pas que tu repartes avec une angoisse diffuse et 86 problèmes en vrac.
Étape 5 : être honnête sur les limites
Un point qui compte, et qui distingue un audit sérieux d'un audit qui se la raconte : assumer ce qu'il ne couvre pas.
Par exemple, lire le code (analyse statique), ce n'est pas la même chose que d'attaquer l'app en conditions réelles (test d'intrusion). Certaines choses ne se vérifient qu'en regardant le serveur tourner pour de vrai. Quand c'est le cas, je le dis : "voilà ce que j'ai vu dans le code, voilà ce qui reste une hypothèse à valider sur ton infra".
Un auditeur qui prétend avoir tout vu et tout garanti, méfie-toi. Celui qui borne clairement sa portée, c'est celui en qui tu peux avoir confiance. Reconnaître une limite, ce n'est pas une faiblesse, c'est de la rigueur.
Ce que tu en retires, concrètement
Au bout du compte, tu repars avec trois choses :
- Une vision claire de tes vrais risques, classés par gravité, sans le bruit des fausses alertes.
- Un plan de correction priorisé et chiffré, du "à faire avant la prod" au "ça peut attendre".
- De la sérénité. Tu arrêtes de te demander "est-ce que mon app va bien ?" et tu sais. C'est souvent ça, le vrai soulagement : pas que tout soit parfait, mais que tu saches exactement où tu en es.
Parce qu'au fond, un audit ne vend pas une refonte. Il réduit un risque qui, sinon, grandit tout seul dans le noir.
Tu veux que je passe ton app au crible ?
Si tu as vibe-codé un produit et que tu veux savoir où il est fragile avant qu'un utilisateur (ou un acheteur) le découvre à ta place, c'est exactement ce que je fais. Je lis le code et la config sur les quatre volets, je te liste les vrais risques classés par gravité, et je te donne un plan de correction priorisé. Découvre l'offre Audit.
Et si ces coulisses t'intéressent, inscris-toi à la newsletter. Pas de blabla, juste des retours d'audit utiles.
