Audit informatique de PME : ce qu’il couvre, ce qu’il doit produire

Un audit informatique de PME est un état des lieux du système d’information — matériel, logiciels, sécurité, contrats, conformité — mené par un regard extérieur, pour permettre à la direction de décider. La dernière partie de la phrase est celle qu’on oublie. Beaucoup d’audits se concluent par un rapport complet, exact et inutilisable : une longue liste de constats, sans ordre, que personne n’a le temps de transformer en décisions.

Un audit utile fait l’inverse. Il se conclut par un petit nombre de décisions, classées par ordre de priorité, chacune assortie de son coût, de son délai et du risque qu’elle traite. Le reste du rapport sert à justifier ce classement.

Quand lancer un audit informatique

Un audit informatique n’est pas un contrôle périodique qu’on fait par principe. Il répond à une décision à prendre, et c’est elle qui fixe son périmètre et son niveau de détail. Quatre moments reviennent :

• Avant d’investir. Un nouveau logiciel de gestion, une migration vers le cloud, un renouvellement du parc : savoir ce qui existe évite de payer deux fois.
• Avant de changer de prestataire. Comprendre ce que fait réellement le prestataire actuel, ce qu’il détient et ce qu’il faudra reprendre.
• Après un incident. Une panne, une fuite, une tentative d’intrusion : établir ce qui a failli, et ce qui pourrait faillir ensuite.
• Lors d’un changement de direction ou d’actionnaire. Un nouveau dirigeant, une cession, une levée de fonds : quelqu’un demande un état fiable, et personne n’est en mesure de le donner.

Dans chaque cas, la question posée au départ détermine ce qu’on regarde en priorité. Un audit sans question précise regarde tout avec la même attention, et c’est ainsi qu’il produit un rapport sans ordre.

Il vaut aussi de dire ce qu’un audit informatique n’est pas. Ce n’est pas une certification, qui atteste la conformité à une norme. Ce n’est pas un test d’intrusion, qui éprouve techniquement la résistance d’un système à une attaque. Et ce n’est pas un avis juridique. Il peut recommander l’un ou l’autre quand ses constats l’exigent ; il ne les remplace pas.

Le périmètre d’un audit informatique de PME

Le périmètre couvre quatre domaines. Ils s’examinent ensemble, parce que les risques les plus sérieux se trouvent souvent à leur frontière — une sauvegarde prévue au contrat mais jamais testée, un accès donné à un prestataire et jamais retiré.

Infrastructure et postes

Serveurs, réseau, postes de travail, téléphones, logiciels installés : leur état, leur âge, leur niveau de mise à jour, et la date à laquelle ils cesseront d’être maintenus. Cette partie s’appuie sur l’inventaire du parc, quand il existe — et le constituer est souvent le premier résultat de l’audit. C’est l’objet de la gestion de parc informatique, et le terrain d’un audit d’infrastructure quand il faut aller plus loin.

Sécurité et sauvegardes

Comptes et droits d’accès, mots de passe et authentification, mises à jour de sécurité, protection des postes, et surtout sauvegardes : existent-elles, sont-elles séparées du système qu’elles protègent, et quelqu’un a-t-il déjà vérifié qu’on sait les restaurer ? Le guide d’hygiène informatique de l’ANSSI fournit un référentiel reconnu pour cette partie ; il vaut mieux s’y mesurer qu’à une liste improvisée.

Contrats et prestataires

Qui fait quoi, selon quel contrat, avec quels engagements, jusqu’à quand. Cette partie révèle presque toujours des surprises : des prestations payées mais non rendues, des engagements de délai jamais mesurés, des clauses de réversibilité absentes, des accès détenus par des prestataires partis. Elle éclaire aussi la question de la dépendance : l’entreprise pourrait-elle changer de prestataire demain sans perdre la maîtrise de son système ?

Conformité

Registre des traitements, contrats de sous-traitance au sens du RGPD, conservation des données, information des salariés sur les outils de contrôle, et obligations propres au secteur quand il y en a. L’audit ne remplace pas une analyse juridique, mais il établit les faits sur lesquels elle s’appuiera : quels traitements existent, où sont les données, et quels prestataires y ont accès.

À ces quatre domaines s’ajoute une question transversale, que seuls les entretiens permettent de traiter : comment les outils sont-ils réellement utilisés ? Les contournements — le fichier partagé hors de l’outil officiel, le service en ligne souscrit par une équipe, le mot de passe commun à tout un service — ne figurent dans aucun document. Ils disent pourtant où le système ne répond pas au besoin, et c’est souvent là que se trouvent les risques les plus concrets.

Le déroulé d’un audit du système d’information

Un audit du système d’information d’une PME se déroule en quatre temps. Leur durée varie avec la taille et la complexité de l’entreprise ; leur ordre ne varie pas.

• Le cadrage. La question à éclairer, le périmètre, les interlocuteurs, les documents à rassembler. Une heure bien employée ici en économise dix plus tard.
• La collecte. Entretiens avec la direction, les utilisateurs et les prestataires ; lecture des contrats et des factures ; relevés techniques sur les équipements et les comptes.
• L’analyse. Rapprocher ce qui est dit, ce qui est écrit et ce qui est constaté. Les écarts entre les trois sont les constats les plus utiles.
• La restitution. Présenter à la direction les décisions à prendre, dans l’ordre, et en débattre — pas seulement remettre un document.

L’entreprise auditée a sa part du travail. Elle rassemble les contrats, les factures et les accès aux consoles d’administration ; elle rend disponibles quelques personnes clés pour des entretiens courts ; et elle prévient ses prestataires, qui seront interrogés. Un audit qui attend ses documents pendant des semaines coûte plus cher et conclut moins bien.

La question de celui qui mène l’audit n’est pas secondaire. Un auditeur qui vendra ensuite les corrections n’a pas le même intérêt qu’un auditeur qui n’en vendra aucune : un audit informatique vaut ce que vaut l’indépendance de celui qui le mène.

Les livrables à exiger

Quatre livrables, pas davantage. Leur forme importe moins que leur usage : chacun doit pouvoir être repris par quelqu’un d’autre que l’auditeur.

• Une note de synthèse pour la direction : la situation en une page, les risques principaux, et ce qu’il faut décider.
• Une liste de décisions priorisées, chacune avec son coût estimé, son délai, le risque qu’elle traite, et qui doit la porter.
• La cartographie de l’existant : applications, équipements, prestataires, contrats, accès — un document qui reste utile après l’audit.
• Les constats détaillés, en annexe, pour justifier le classement et servir aux équipes techniques.

Le classement repose sur trois questions posées à chaque constat : quelle serait la gravité si le risque se réalisait, quelle est la probabilité qu’il se réalise, et que coûte la correction ? Un risque grave et probable qui se corrige à peu de frais passe en tête ; un risque théorique dont la correction mobiliserait un budget important attend le plan pluriannuel. Écrire ces trois réponses pour chaque décision rend le classement discutable — au bon sens du terme : la direction peut le contester point par point.

La liste de décisions est le cœur du livrable. Elle distingue ce qui doit être fait dans le mois — souvent peu coûteux et très protecteur — de ce qui relève d’un plan sur plusieurs années. Ce second ensemble est la matière première d’un schéma directeur informatique.

Reste à savoir qui mettra ces décisions en œuvre. Une PME sans direction informatique peut confier ce pilotage à un DSI à temps partagé ; sans quelqu’un pour porter la liste, le meilleur audit finit dans un tiroir. C’est pourquoi, chez Maeliom Consulting, un audit se termine par une restitution et une décision sur la suite — pas par l’envoi d’un fichier.

Questions fréquentes