L’audit IT répond à la question « mon système d’information sert-il ma croissance ? », l’audit de sécurité à la question « mon système résiste-t-il à une attaque ou à une panne ? ». Le premier examine l’adéquation des outils, les coûts et la dette technique, le second les failles, les accès et la capacité de reprise. Une PME en transformation digitale a besoin des deux.
Deux questions, deux diagnostics
Les deux démarches se ressemblent de loin : un intervenant extérieur, des entretiens, un rapport et une liste de recommandations. Leur objet diffère pourtant du tout au tout, et les confondre conduit à acheter l’un en croyant obtenir l’autre.
L’audit IT regarde le système d’information comme un outil de production. Les logiciels couvrent-ils les besoins des équipes ? Les données circulent-elles sans ressaisie ? L’infrastructure suivra-t-elle le doublement des effectifs ? Son horizon est la performance et la trajectoire, et il se lit avec un regard d’organisation autant que de technique. Le déroulé complet de cette démarche est présenté dans notre article sur l’audit IT pour préparer son système d’information à la croissance.
L’audit de sécurité regarde le même système comme une cible. Qui peut y entrer, avec quels droits, par quelles portes ? Que se passe-t-il si un poste est compromis, si un compte administrateur fuite, si le serveur de fichiers est chiffré par un rançongiciel ? Son horizon est le risque, et il se lit avec un regard d’attaquant.
- L’audit IT produit une trajectoire : quoi garder, quoi remplacer, dans quel ordre.
- L’audit de sécurité produit une liste de vulnérabilités hiérarchisées et un plan pour les fermer.
- Le premier se juge sur la pertinence des arbitrages, le second sur la réalité des preuves.
Qui mène chaque audit
L’audit IT se confie souvent à un consultant en organisation des systèmes d’information, à un directeur informatique de transition ou à un cabinet de conseil en transformation digitale. Ce qui compte, c’est sa connaissance des métiers de l’entreprise et sa capacité à arbitrer entre des besoins concurrents.
L’audit de sécurité exige une autre compétence et, surtout, une autre position. Il doit être conduit par un intervenant indépendant de ceux qui exploitent le système au quotidien : un infogérant qui audite son propre travail n’a aucun intérêt à mettre ses erreurs en évidence. Il se confie donc à un cabinet spécialisé en cybersécurité, comme Ad Confirma, cabinet de conseil et d’audit basé près de Lyon et intervenant dans toute la France, qui mène les audits organisationnels et fait conduire les tests d’intrusion par des partenaires, sans vendre l’outil ou l’exploitation qui corrigera les écarts.
Pour certains marchés publics et opérateurs sensibles, l’ANSSI qualifie des prestataires d’audit de la sécurité des systèmes d’information selon un référentiel public. Pour une PME, cette qualification n’est pas exigée, mais elle donne une idée précise de ce qu’un audit sérieux doit contenir : périmètre écrit, méthode connue, auditeurs identifiés, confidentialité des résultats.
Ce que chacun examine
Le périmètre dit mieux que tout la différence entre les deux diagnostics.
L’audit IT passe en revue :
- l’infrastructure et le parc, leur âge, leur fin de support éventuelle ;
- les applications réellement utilisées et leurs intégrations ;
- la qualité et la circulation des données entre les outils ;
- les coûts, les contrats et la dépendance aux fournisseurs ;
- l’organisation informatique : qui fait quoi, avec quelles compétences.
L’audit de sécurité informatique se concentre sur :
- les accès : comptes, droits d’administration, comptes orphelins, authentification ;
- la configuration des équipements exposés : pare-feu, accès à distance, messagerie ;
- les correctifs de sécurité et les systèmes vulnérables ;
- les sauvegardes, leur isolement et leur capacité réelle de restauration ;
- la sensibilisation des utilisateurs et les procédures en cas d’incident ;
- la conformité aux obligations applicables, dont la sécurité des données personnelles.
Les deux listes se croisent sur les sauvegardes et le parc, mais la question posée n’est pas la même. L’audit IT vérifie qu’une sauvegarde existe et coûte ce qu’elle doit ; l’audit de sécurité vérifie qu’un attaquant installé sur le réseau ne pourrait pas la supprimer avant de chiffrer le reste.
La méthode : entretiens d’un côté, preuves de l’autre
L’audit IT repose surtout sur des entretiens, l’analyse de documents et une cartographie. Il reconstitue le système tel qu’il fonctionne, le compare aux besoins exprimés et en déduit des scénarios d’évolution.
L’audit de sécurité ajoute une dimension de vérification active. Trois niveaux coexistent, souvent combinés :
- l’audit organisationnel, qui examine les politiques, les procédures et la gouvernance, en s’appuyant sur des référentiels comme la norme ISO 27001 ou le guide d’hygiène informatique de l’ANSSI ;
- l’audit de configuration, qui contrôle poste par poste et serveur par serveur les réglages de sécurité ;
- le test d’intrusion, qui tente de pénétrer le système dans un cadre fixé par écrit, pour démontrer ce qu’un attaquant pourrait réellement faire.
Ce dernier volet change la nature du rapport. Une recommandation d’audit IT se discute ; une vulnérabilité démontrée par un test d’intrusion se corrige. Le périmètre et les techniques autorisées se fixent toujours dans une convention signée, sans laquelle l’intrusion constituerait une infraction.
Les livrables : feuille de route contre plan de remédiation
À la fin d’un audit IT, la direction reçoit une cartographie, un registre des risques et une trajectoire d’évolution, avec des priorités et des ordres de grandeur. C’est un document de décision stratégique, qui alimente le budget et la feuille de route de la transformation.
À la fin d’un audit de sécurité, elle reçoit deux niveaux de lecture. Une synthèse pour la direction, qui résume le niveau de risque et les priorités sans jargon. Un rapport détaillé pour les équipes techniques, qui décrit chaque vulnérabilité, sa gravité, la manière de la reproduire et la correction recommandée.
Un bon plan de remédiation distingue ce qui se corrige en quelques jours, souvent des réglages et des comptes à fermer, de ce qui demande un projet, comme la segmentation du réseau ou la refonte des sauvegardes. Il prévoit enfin une contre-vérification, pour s’assurer que les corrections ont réellement fermé les failles.
À quel moment d’un projet de transformation
L’ordre le plus fréquent place l’audit IT au début. Il éclaire les choix d’outils et de priorités, conformément à la démarche décrite dans notre article sur la transformation digitale d’une PME et par où commencer.
L’audit de sécurité intervient ensuite à plusieurs moments clés :
- avant la mise en service d’une application ou d’un service exposé sur internet ;
- après une migration importante, par exemple vers des outils hébergés dans le cloud ;
- après un incident, pour comprendre la faille et vérifier qu’elle est fermée ;
- de façon périodique, pour mesurer l’évolution du niveau de sécurité.
Le déploiement de nouveaux outils collaboratifs illustre bien l’articulation. L’audit IT choisit la suite qui convient aux équipes ; l’audit de sécurité vérifie ensuite le partage externe, les droits et la localisation des données, points développés dans notre article sur les outils collaboratifs en entreprise.
Enchaîner les deux sans payer deux fois
Les deux diagnostics partagent une matière première : la connaissance du système. Une cartographie à jour, une liste des applications, des comptes et des prestataires, un schéma du réseau servent aux deux. Les produire une fois, proprement, puis les transmettre au second intervenant réduit sensiblement la durée de sa mission.
L’erreur inverse consiste à demander à l’auditeur IT de « regarder aussi la sécurité ». Il le fera avec bonne volonté, mais sans les tests ni l’indépendance qui donnent sa valeur à un audit de sécurité. Le résultat rassure sans rien prouver. Un diagnostic de sécurité sérieux commence précisément là où l’audit IT s’arrête : à la preuve.
Le budget de chaque démarche dépend du périmètre, du nombre de sites et d’applications, et de la profondeur des tests. Le poste le plus souvent sous-estimé n’est pas l’audit lui-même, mais le temps des équipes internes pour préparer, répondre et corriger ensuite.
Les signaux qui justifient un audit de sécurité sans attendre
Certains événements devraient déclencher un audit sécurité PME sans attendre le calendrier habituel :
- un client ou un donneur d’ordres qui envoie un questionnaire de sécurité avant de signer ;
- le départ d’un salarié ou d’un prestataire qui disposait de droits d’administration étendus ;
- un incident, même contenu : compte de messagerie piraté, virement frauduleux évité de justesse, poste infecté ;
- l’ouverture d’un accès à distance pour le télétravail ou pour un prestataire extérieur ;
- la mise en ligne d’un site ou d’une boutique qui collecte des données clients, dont la maintenance conditionne directement la sécurité, comme le rappelle notre article sur le budget réel d’un site WordPress ;
- une attaque subie par un partenaire proche ou une entreprise du même secteur.
Aucun de ces signaux ne signifie que le système est compromis. Chacun indique en revanche que les hypothèses sur lesquelles reposait la sécurité ont changé, et qu’il est temps de les vérifier. L’audit arrive alors au bon moment : avant l’incident, tant que les corrections restent un projet et pas une urgence.
Prochaine étape
Écrivez sur une page les deux questions : notre système sert-il la croissance prévue, et résisterait-il à la perte d’un poste, d’un compte ou d’un serveur ? La question à laquelle vous ne savez pas répondre indique le premier audit à commander.