La demande d’audit informatique arrive rarement au hasard. Elle accompagne un moment précis : une reprise d’entreprise, un changement de direction, un prestataire dont on ne mesure plus la valeur, ou une non-conformité relevée par un tiers.
Ce contexte détermine ce que l’audit doit produire. Dans tous ces cas, quelqu’un doit décider quelque chose, rapidement, sur un sujet qu’il ne maîtrise pas.
Ce qu’une grille structurée couvre
- infrastructure, postes de travail, réseau
- applications métier et leur adéquation à l’usage réel
- données, sauvegardes, et test effectif de restauration
- sécurité, gestion des accès et des départs
- contrats, prestataires, engagements de service
- conformité réglementaire et traitements de données
- coûts, licences, abonnements dormants
- compétences internes et dépendance aux personnes
- continuité : que se passe-t-il si cela s’arrête
Le nombre de points compte moins que la discipline de tous les parcourir. Les angles morts d’un audit ne sont pas les sujets difficiles : ce sont ceux qu’on a sautés parce que personne ne les avait signalés.
L’entretien vaut mieux que le questionnaire
Un inventaire décrit ce que le système est censé faire. Les entretiens avec les responsables en place révèlent ce que les équipes font réellement : les tableurs parallèles, le prestataire qu’on appelle en direct, la procédure qu’on contourne depuis deux ans parce qu’elle n’a jamais fonctionné.
L’écart le plus instructif d’un audit est celui entre ce que le système est censé faire et ce que les équipes font réellement.
Cet écart n’est pas un dysfonctionnement à corriger : c’est une information. Un contournement durable signale presque toujours un outil mal choisi ou un processus mal conçu.
À qui s’adresse le rapport
C’est la question qui décide de l’utilité de tout le travail. Un livrable rédigé pour la direction informatique sera lu par elle, commenté par elle, et n’ira pas plus loin — alors qu’il évalue précisément son périmètre.
Le rapport doit être lisible par qui décide du budget. Cela suppose de hiérarchiser, de chiffrer, et de traduire chaque constat en conséquence concrète plutôt qu’en niveau de version.
Ce qu’un audit ne fait pas
La question du destinataire en recouvre une autre, plus ancienne : deux exercices distincts se vendent sous le même nom, et l’on commande souvent l’un en attendant l’autre.
Un rapport ne vaut rien s’il ne débouche pas sur un arbitrage. C’est tout l’objet d’un schéma directeur à trois scénarios chiffrés.
Il ne décide pas à la place du dirigeant, et il ne remplace pas l’expertise technique de ceux qui exploitent le système. Il met les deux en position de se parler : d’un côté des exigences formulées clairement, de l’autre des réponses que l’on peut évaluer.
Questions fréquentes
Comment rédiger un rapport d’audit informatique qui serve à décider ?
En l’écrivant pour qui décide du budget, pas pour la direction informatique. Il hiérarchise les constats, les chiffre, et traduit chacun en conséquence concrète pour l’activité plutôt qu’en niveau de version. Un rapport lisible par un seul informaticien ne permet aucune décision.
Que couvre un audit IT complet ?
Neuf domaines : infrastructure et postes, applications métier, données et sauvegardes testées, sécurité et gestion des accès, contrats et prestataires, conformité, coûts et licences, compétences internes, et continuité d’activité. La discipline de tous les parcourir compte plus que le nombre de points.
Pourquoi faire des entretiens plutôt qu’un questionnaire lors d’un audit ?
Parce qu’un questionnaire recueille ce que l’on croit faire, et un entretien révèle ce que l’on fait réellement : tableurs parallèles, prestataire appelé en direct, procédure contournée. Cet écart est l’information la plus utile d’un audit.