Un audit de code, ça contient quoi (et qu'est-ce qu'il ne garantit pas) ?

Un audit de code, c'est une relecture méthodique de votre application par quelqu'un qui connaît les points fragiles. Il en ressort un état des lieux : ce qui est solide, ce qui est risqué, ce qu'il vaut mieux corriger en premier. Ce n'est pas une garantie que tout est parfait, et il est utile de savoir pourquoi.

Cet article décrit ce qu'un bon audit contient en général. Le contenu exact varie selon la personne qui le réalise et selon votre projet : c'est une bonne question à poser avant de commander quoi que ce soit.

L'analogie : l'inspection avant l'achat d'une maison

Avant d'acheter, on fait venir quelqu'un pour regarder la charpente, l'électricité, l'humidité. Il ne démonte pas tous les murs. Il observe, teste, et vous rend un avis : ce qui est sain, ce qui demande des travaux, ce qui est urgent.

Un audit de code fonctionne de la même façon. Il éclaire une décision, il ne remplace pas la vie dans la maison.

Ce qu'un bon audit contient en général

Un périmètre clair

Ce qui a été regardé, et ce qui ne l'a pas été. Par exemple le code de l'application, la configuration de l'hébergement, les services tiers connectés. Sans périmètre, impossible de savoir ce que le rapport couvre.

La sécurité

• L'accès aux données : qui peut lire ou modifier quoi, et les règles qui l'imposent.
• Les secrets : clés et mots de passe, et où ils se trouvent.
• L'authentification : la manière de reconnaître un utilisateur, de stocker ses mots de passe.
• Les entrées de l'utilisateur : ce qui se passe quand on envoie des données inattendues.
• Les dépendances : les bibliothèques utilisées, et si certaines sont connues pour des faiblesses.

La fiabilité

Que se passe-t-il quand quelque chose échoue : un paiement qui n'aboutit pas, un service qui répond mal, deux actions en même temps. Les sauvegardes existent-elles, et ont-elles été testées.

La maintenabilité

Le code est-il lisible, organisé, testé ? Un autre développeur pourrait-il le reprendre sans repartir de zéro ? C'est ce qui détermine le coût de chaque évolution future (voir la dette technique).

La performance, si elle pose question

Des lenteurs visibles, des requêtes inutiles, des pages trop lourdes.

Une synthèse et des priorités

Un bon audit ne se contente pas d'une liste. Il dit ce qui compte le plus, ce qui peut attendre, et dans quel ordre agir.

Ce qu'un audit ne garantit pas

Soyons honnêtes sur les limites :

• Il ne garantit pas l'absence de défauts. Il montre ce qui a été trouvé dans le temps et le périmètre prévus, pas tout ce qui existe.
• Il décrit un instant. Le code continue d'évoluer : de nouveaux changements peuvent introduire de nouveaux problèmes.
• Il ne remplace pas les tests ni la surveillance qui tournent en continu.
• Il ne prédit pas le comportement sous une forte charge, sauf si des essais de charge ont été prévus.
• Il ne vaut pas avis juridique ou certification, sauf si c'est explicitement ce qui a été commandé.
• Il ne corrige rien tout seul. Un rapport est un point de départ : la valeur vient de ce qu'on en fait.

Les bonnes questions à poser avant

1. Que couvre exactement l'audit, et qu'est-ce qui est hors périmètre ?
2. Comment les problèmes sont-ils classés par importance ?
3. Le rapport sera-t-il compréhensible pour quelqu'un qui n'est pas développeur ? (voir comment lire un rapport d'audit)
4. Peut-on en parler après sa remise ?

À retenir

Un bon audit éclaire vos décisions en montrant ce qui est solide, ce qui est fragile et par où commencer, mais il ne garantit pas que le code est sans défaut. Demandez toujours son périmètre et ses limites.

Et pour votre produit ?

Si votre application a été construite vite, avec ou sans l'aide d'outils d'IA, ou si vous allez bientôt accueillir de vrais utilisateurs, un audit de code est un bon moyen de savoir où vous en êtes. Nous pouvons en discuter 30 minutes pour préciser ce qui serait regardé dans votre cas.