Audit de code : liste de contrôle pour examiner un logiciel tiers

Un audit de code est l'examen systématique d'une base de code par quelqu'un qui ne l'a pas construite. Il répond à trois questions : le logiciel est-il suffisamment sûr pour son usage, peut-il être développé avec un effort raisonnable, et quels risques reprenez-vous avec lui, sur le plan technique, des licences et de la réglementation.

Quand ai-je besoin d'un audit de code ?

Chaque fois que vous assumez la responsabilité d'un code que vous n'avez pas écrit. Cinq cas typiques :

• Reprise auprès d'un prestataire. Le cas le plus fréquent, et celui qui réserve le plus de surprises.
• Avant un achat ou une prise de participation. Due diligence technique : ici, le constat décide du prix.
• Avant la mise en production d'un prototype. Particulièrement pertinent s'il a été créé avec des outils d'IA, voir Du prototype à la production.
• Après un incident de sécurité. Pas seulement la faille exploitée, mais la question de savoir si le même motif existe ailleurs.
• Avant un investissement important. Avant d'investir un an de développement dans des fondations dont personne n'a vérifié la solidité.

La liste de contrôle : six domaines qu'un audit doit examiner

Un audit qui n'examine que le premier domaine est un scan de sécurité. Vous pouvez confronter ces six points à une offre comme liste de contrôle : s'il en manque un, posez la question.

• Sécurité. Schémas de vulnérabilités connus selon l'OWASP Top 10:2025, gestion des identifiants, authentification et autorisations, traitement des entrées.
• Maintenabilité. Structure, doublons, complexité, couverture de tests, compréhensibilité pour quelqu'un qui arrive.
• Dépendances. Quels paquets, quelles versions, quelles vulnérabilités connues, avec quelle activité de maintenance, quelle profondeur de chaîne. Depuis 2025, les défaillances de la chaîne d'approvisionnement forment une catégorie OWASP à part (A03).
• Licences. Quelles licences figurent dans l'existant, sont-elles compatibles avec votre modèle économique ? Une licence copyleft dans un produit fermé est un constat qui éclipse tout le reste.
• Exploitation. Peut-on le déployer, le surveiller, le restaurer ? Existe-t-il un environnement reproductible, ou cela ne tourne-t-il que sur une machine précise ?
• Droit et réglementation. Quelles données personnelles sont traitées, sur quelle base ? Le produit relève-t-il du Cyber Resilience Act, dont les obligations de notification s'appliquent à partir du 11 septembre 2026 ?

Comment se déroule un audit de code ?

En cinq étapes, la première décidant de la qualité de l'ensemble du résultat.

• 1. Clarifier l'objectif. Un audit avant un achat cherche d'autres choses qu'un audit après un incident. Sans cette définition, on obtient un rapport qui mentionne tout et ne décide rien.
• 2. Relever automatiquement. Analyse statique, contrôle des dépendances et des licences, doublons, complexité, couverture de tests, fréquence de modification issue de l'historique des versions. C'est la base, pas le résultat.
• 3. Lire de façon ciblée. Un humain lit les zones qui ressortent de l'étape 2, plus toujours : authentification, autorisations, paiement, accès aux données. Une lecture intégrale n'est pas finançable pour une taille réaliste et n'est pas nécessaire.
• 4. Documenter. Chaque constat avec sa localisation et un scénario concret de son impact. Un constat sans impact est une opinion.
• 5. Prioriser. Selon le dommage multiplié par la probabilité d'occurrence, avec estimation de l'effort. Une liste de 200 points de même rang n'aide personne.

À quoi reconnaît-on un audit superficiel ?

À quatre caractéristiques qui reviennent toutes à la même chose : on a lancé un outil et exporté le rapport.

• Il se compose surtout de sorties d'outils. Sans indiquer quel constat compte réellement dans ce projet.
• La logique métier est absente. Aucun outil ne juge si les règles d'autorisation correspondent au modèle économique. C'est précisément le constat le plus coûteux.
• Pas de priorisation. Tout est « moyen ».
• Aucune indication de périmètre. Un audit sérieux indique ce qui n'a pas été examiné. L'absence de limites est elle-même un signal d'alerte.

Combien coûte un audit de code ?

La réponse honnête : cela dépend presque entièrement du périmètre et de l'objectif, et les montants forfaitaires des guides relèvent de l'observation du marché, pas de valeurs fiables.

Ce que l'on peut dire sérieusement : l'effort ne dépend pas du nombre de lignes, mais du nombre de composants autonomes et de la profondeur du jugement souhaité. Un audit qui se contente de couvrir et de situer les six domaines ci-dessus avec des outils automatiques ne représente qu'une fraction d'un audit qui pénètre la logique métier des autorisations.

Ne demandez donc pas une offre forfaitaire, mais une estimation de l'effort par domaine : vous pourrez alors décider où la profondeur est nécessaire. Si vous souhaitez commander un tel examen, notre développement de logiciels et de SaaS est le point d'entrée.

Questions fréquentes sur l'audit de code

Une IA peut-elle réaliser un audit de code ?

Elle peut accélérer considérablement l'étape 2 et une partie de l'étape 3 : repérer des motifs, expliquer des liens, pré-trier les constats. Elle ne peut pas réaliser les étapes 1 et 5 : définir l'objectif et prioriser selon le risque pour l'entreprise suppose de connaître l'entreprise.

Combien de temps dure un audit ?

Pour un projet de taille moyenne, l'ordre de grandeur est habituellement de quelques jours à quelques semaines. La fourchette est large parce que l'étape 3 dépend du constat de l'étape 2 : on ne peut pas la fixer sérieusement avant.

Le prestataire doit-il auditer lui-même son propre ouvrage ?

Pour un état des lieux, c'est utilisable. Pour un jugement qui servira de base à une décision d'achat ou à une négociation contractuelle, l'indépendance de l'instance qui examine fait partie de la valeur.

Que faire du résultat ?

Traiter immédiatement les constats critiques, intégrer les coûteux à la planification, et verser le reste dans une liste traitée à la prochaine intervention sur le domaine concerné. Un audit dont le résultat devrait être traité intégralement dans un projet à part est rarement financé.

Un audit est un instantané ; le constat le plus coûteux est celui qui réapparaît six mois plus tard. Code Guardian fait tourner à chaque modification les contrôles qu'un audit réalise une seule fois.

Sources

• OWASP Top 10:2025 (cadre d'examen pour la partie sécurité), version finale de janvier 2026.
• Règlement (UE) 2024/2847 (Cyber Resilience Act), obligations de notification à partir du 11 septembre 2026, obligations principales à partir du 11 décembre 2027.
• ISO/IEC 25010:2023 (cadre de référence pour la partie maintenabilité).

Date : 27 juillet 2026. Analyse technique générale, ni conseil juridique ni engagement de prix ; les efforts sont à estimer au cas par cas.