Un audit technique ne se résume pas à passer un outil automatisé sur un site ou une application. Le périmètre réel varie selon le type de produit audité (application web, infrastructure cloud, système embarquant de l’IA) et selon le cadre réglementaire applicable. Avec l’entrée en vigueur de DORA en janvier 2025 et les obligations NIS2 qui se précisent, le contenu attendu d’un audit technique a sensiblement évolué ces deux dernières années.
Audit technique : ce que couvre réellement l’analyse du code source
L’examen du code reste le socle de tout audit technique logiciel. Il ne s’agit pas simplement de vérifier que le code compile ou que les tests passent.
Lire également : Que signifie l'autorité SEO ?
L’auditeur examine la qualité structurelle du code : lisibilité, respect des conventions, modularité. Un code techniquement fonctionnel peut masquer une dette technique lourde, avec des dépendances obsolètes, des blocs dupliqués ou des couplages excessifs entre modules.
L’analyse porte aussi sur les dépendances tierces. Chaque librairie open source utilisée représente un vecteur de risque potentiel, surtout si elle n’est plus maintenue ou si elle embarque des vulnérabilités connues. NIS2 inclut explicitement la sécurité de la chaîne d’approvisionnement logicielle parmi les mesures attendues.
A lire également : Qu'est-ce qu'un audit technique SEO on-page ?
Les éléments concrets passés en revue lors de cette phase incluent :
- La couverture de tests (unitaires, d’intégration, end-to-end) et la pertinence des scénarios couverts, pas seulement leur pourcentage brut
- Les vulnérabilités détectées dans les dépendances via des outils d’analyse statique (type SonarQube, Snyk ou Trivy)
- La gestion des secrets et des variables d’environnement, pour vérifier qu’aucun mot de passe ou clé API ne se retrouve en dur dans le code
- L’historique de versioning, qui révèle la fréquence des livraisons, la taille des commits et la discipline de l’équipe
Infrastructure et résilience cloud dans un audit technique
L’audit d’infrastructure a changé de nature. Il ne suffit plus de vérifier la configuration des serveurs ou la politique de sauvegarde.
La résilience des dépendances cloud et fournisseurs TIC fait désormais partie du périmètre standard. Depuis l’application de DORA le 17 janvier 2025, les entités financières doivent notamment tenir un registre de leurs prestataires, évaluer la concentration chez un même fournisseur et disposer de scénarios de sortie testés.
Cette logique s’étend au-delà du secteur financier. Un audit technique sérieux vérifie si l’organisation a identifié ses points de défaillance unique (single points of failure) dans sa chaîne de prestataires. Héberger son application, sa base de données et son CDN chez le même fournisseur cloud, sans plan de bascule, constitue un risque documenté lors de l’audit.
Tests de continuité en conditions réelles
DORA prévoit un programme de tests au moins annuel pour les systèmes soutenant des fonctions critiques. L’audit vérifie l’existence de ces tests, mais aussi leurs résultats concrets : temps de bascule mesuré, données effectivement restaurées, procédures de reprise suivies par l’équipe.
Un plan de reprise d’activité jamais testé en conditions opérationnelles ne vaut rien. L’auditeur cherche des preuves de tests de bascule et de restauration, pas un document PDF rangé dans un dossier partagé.
Sécurité et conformité réglementaire dans le diagnostic technique
La dimension sécurité d’un audit technique va au-delà du scan de vulnérabilités. Elle inclut l’évaluation des droits d’accès, la politique de mots de passe, la segmentation réseau et la gestion des certificats.
Pour les systèmes intégrant de l’intelligence artificielle, le périmètre s’élargit encore. L’AI Act impose une documentation technique et une traçabilité des données d’entraînement pour les usages classés à haut risque. Un audit technique doit alors vérifier la classification de l’usage IA, la qualité des jeux de données, les journaux de décision et l’historique des modifications apportées au modèle.
Les retours terrain divergent sur la profondeur réelle de ces vérifications IA dans les audits actuels. Les méthodologies se stabilisent progressivement, mais aucun référentiel unique ne fait consensus à ce stade.
Tests de pénétration fondés sur la menace
DORA prévoit des tests de pénétration fondés sur la menace (threat-led penetration testing) au moins tous les trois ans pour les entités concernées. Ces tests simulent des attaques réalistes, calibrées sur les menaces spécifiques au secteur de l’organisation.
L’audit technique documente si ces tests ont été réalisés, par qui, et quelles remédiations ont suivi. Un test de pénétration sans plan de remédiation traçable est un signal d’alerte.
Livrables et périmètre organisationnel de l’audit
Un audit technique ne produit pas qu’un rapport de bugs. Le livrable principal est un état des lieux structuré qui cartographie les risques par niveau de criticité, avec des recommandations priorisées.
La dimension organisationnelle fait partie du diagnostic. L’auditeur évalue comment l’équipe technique gère ses processus : revues de code, gestion des incidents, documentation des choix d’architecture. Une base de code propre maintenue par une équipe désorganisée ne résistera pas longtemps.
Les droits d’audit contractuels avec les fournisseurs tiers entrent aussi dans le périmètre. L’organisation dispose-t-elle du droit de faire auditer les systèmes de ses prestataires critiques ? Sans clause d’audit contractuelle, la visibilité sur la chaîne de sous-traitance reste aveugle.
Le contenu d’un audit technique dépend du contexte réglementaire, du type de produit et du niveau de maturité de l’organisation. Les cadres DORA, NIS2 et AI Act ont élargi le périmètre bien au-delà du code source et de l’infrastructure. Un audit mené en 2026 qui se limiterait à la performance et à la qualité du code passerait à côté de la majorité des risques documentés par ces réglementations.
