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
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.