Quand les gens entendent le mot « audit », ils imaginent généralement des comptables, des feuilles de calcul et la saison des impôts. En informatique, l'audit est une discipline totalement différente. Il s'agit moins d'équilibrer des grands livres que de poser des questions difficiles à votre code, à vos données et à vos contrôles. Un audit système évalue si vos actifs informationnels sont en sécurité, si vos données restent exactes et si vos ressources fonctionnent réellement comme vous le pensez.

Un système fonctionnel n'est pas forcément un système fiable. Une plateforme de dossiers académiques peut inscrire correctement les étudiants et générer des relevés de notes impeccables tout en stockant discrètement des mots de passe en texte clair. Un tableau de bord logistique peut afficher des délais de livraison parfaits tout en exposant ses identifiants de base de données dans un code source lisible publiquement. L'audit des systèmes existe pour combler cet écart.

Ce qu'un audit système couvre réellement

Fondamentalement, un audit système examine trois aspects : la confidentialité, l'intégrité et l'efficacité. La confidentialité signifie que vos dossiers d'étudiants, vos journaux de transactions ou vos dossiers de patients ne sont accessibles qu'aux personnes autorisées. L'intégrité signifie que les données ne se corrompent pas discrètement, ne perdent pas leur lignage ou ne s'éloignent pas de la réalité au fil du temps. L'efficacité signifie que vos serveurs, services et processus apportent de la valeur plutôt que de simplement consommer des ressources sans que personne ne le remarque.

Ces trois qualités doivent être vérifiables. Faire confiance à votre base de données parce qu'elle n'a pas encore planté n'est pas une vérification. Un véritable audit produit des preuves que vous pouvez présenter lorsqu'un régulateur, un client ou votre futur vous-même demande comment vous savez que le système est fiable.

Les principaux types d'audits système

Tous les audits n'examinent pas la même chose. Selon les risques auxquels vous faites face, vous pourriez avoir besoin de l'un ou plusieurs des éléments suivants :

Audit d'application. Il vérifie si la logique logicielle est correcte. Les calculs sont-ils précis ? Les machines à états gèrent-elles les cas limites ? L'autorisation est-elle appliquée dans chaque fonction qui touche à des données sensibles ? Un échec classique au niveau de l'application est un module de notation qui arrondit mal les décimales ou un contrôle d'éligibilité aux bourses qui peut être contourné en modifiant la valeur d'un menu déroulant.

Audit de sécurité. Il se concentre sur les contrôles d'accès, le chiffrement et les vulnérabilités. Il examine qui peut lire quels dossiers, si les données sont chiffrées en transit et au repos, et si votre gestion de session peut résister aux altérations. Il vérifie également si vos dépendances comportent des vulnérabilités connues qui vous exposent discrètement à une exploitation.

Audit de base de données. C'est ici que réside l'intégrité des données. Les contraintes de référence sont-elles appliquées ? Les sauvegardes sont-elles réellement restaurables, ou les avez-vous seulement programmées ? Les politiques de rétention sont-elles conformes aux exigences légales ? Un audit de base de données examine également les plans de reprise, car une sauvegarde que vous n'avez jamais testée n'est qu'une théorie.

Audit réseau. Il inspecte les serveurs, les pare-feu, le routage et la disponibilité. Il confirme que seuls les ports nécessaires sont ouverts, que les règles de pare-feu sont documentées et que votre infrastructure peut supporter des pics de trafic ou des attaques par déni de service. Il vérifie également si les systèmes d'exploitation sont mis à jour, et pas seulement la couche applicative.

Audit de conformité. Il mesure le système par rapport à des règles externes. Les plateformes étudiantes peuvent devoir respecter la FERPA. Les systèmes de santé doivent satisfaire à la HIPAA. Le traitement des paiements nécessite l'alignement sur la norme PCI-DSS. La conformité ne consiste pas seulement à être sécurisé ; il s'agit de pouvoir démontrer cette sécurité à une autorité externe.

Audit opérationnel. Le code n'est que la moitié de l'histoire. Cet audit examine les processus de maintenance, les flux de travail du support, la gestion du changement et la fraîcheur de la documentation. Une application brillante devient un risque lorsque la seule personne qui comprend son pipeline de déploiement quitte l'organisation.

Étude de cas réelle : Audit de EduManage v1.0

J'ai récemment mené un audit interne de sécurité et d'application sur EduManage v1.0, une plateforme de gestion académique. Le système gérait les inscriptions, les dossiers et les notes. Avant qu'il ne touche des données réelles d'étudiants, nous devions savoir si nous pouvions lui faire confiance. J'ai suivi un processus simple en six étapes, et je recommande cette même structure pour la plupart des audits internes.

Définir le périmètre. Les audits sans limites se transforment en corvées interminables. Nous avons défini précisément quels modules étaient inclus dans le périmètre : l'authentification, la gestion des dossiers et les flux de travail d'inscription principaux. Les intégrations tierces et l'infrastructure physique étaient explicitement hors périmètre. Nous avons alloué deux semaines et identifié les personnes clés capables de répondre aux questions. Cette clarté permet d'éviter la dérive du périmètre et de maintenir tout le monde sur la même longueur d'onde.

Rassembler les informations et la documentation. J'ai collecté des diagrammes d'architecture, la documentation de l'API, les schémas de base de données et les rapports d'incidents précédents. J'ai discuté avec le développeur principal des pratiques de déploiement et des choix de la stack technologique. On ne peut pas tester ce que l'on ne comprend pas, et les suppositions faites à ce stade empoisonneront chaque résultat ultérieur.

Exécuter les tests. Nous avons abordé le système sous trois angles. Une revue de code a permis de traquer les anti-patterns, les failles d'injection et les dépendances non sécurisées. Les tests fonctionnels ont vérifié que les règles métier — comme les plafonds d'inscription et les vérifications de prérequis — bloquaient réellement les états invalides plutôt que de simplement les masquer derrière le code frontend. Les tests d'intrusion ont simulé un attaquant externe, sondant les points de terminaison exposés et manipulant les requêtes pour voir ce qui fuyait ou se brisait.

Analyser les risques et les résultats. Les vulnérabilités brutes n'ont pas toutes la même importance. Nous avons cartographié chaque résultat en fonction de la probabilité et