Le diagnostic SI en amont : ce qu'un audit 360° regarde vraiment

Un audit SI n'est pas un audit de conformité

La confusion la plus fréquente, avant de lancer un diagnostic, est de le réduire à un contrôle : vérifier que tel logiciel est à jour, que telle procédure existe sur le papier. Un audit de conformité coche des cases par rapport à un référentiel. Un diagnostic SI 360° a un objectif différent : donner à une direction une vue d'ensemble suffisamment fiable pour arbitrer un budget avant d'engager quoi que ce soit — pas produire un rapport qui dort dans un tiroir.

Cette distinction change la façon de mener l'exercice. Un audit de conformité peut être mené presque mécaniquement, référentiel en main. Un diagnostic utile suppose de comprendre l'activité de l'organisation avant de regarder l'infrastructure — sans quoi il produit une liste de constats sans hiérarchie, aussi vraie qu'inutilisable.

Les quatre couches que couvre un diagnostic complet

• L'infrastructure et le parc — matériel, réseau, niveau d'obsolescence, dépendance à un fournisseur unique. C'est la couche la plus visible, souvent la seule regardée quand on parle d'« audit informatique », alors qu'elle ne dit presque rien du risque réel si elle est isolée du reste.
• Les applications et les données — cartographie applicative, dépendances entre systèmes, dette technique accumulée. C'est souvent la couche la moins documentée, alors qu'elle conditionne directement la faisabilité de tout projet de transformation.
• L'organisation et la gouvernance — qui décide, qui maintient, qui documente, et ce qui se passe si cette personne quitte l'organisation demain. Une infrastructure moderne pilotée par une seule personne non remplaçable est un risque aussi sérieux qu'un serveur obsolète.
• La sécurité — exposition réelle, gestion des accès, sauvegardes testées, pas seulement programmées. Cette couche recoupe la démarche EBIOS RM sans s'y substituer : le diagnostic identifie l'exposition, la méthode de gestion des risques la qualifie et la hiérarchise dans un second temps.

L'erreur la plus fréquente : confondre inventaire et diagnostic

Beaucoup d'organisations qui ont déjà « fait un audit » ont en réalité fait un inventaire — une liste de serveurs, de logiciels, de licences, souvent produite par l'équipe technique elle-même. Cet inventaire est une donnée d'entrée utile, pas un diagnostic. La différence tient dans un mot : la priorisation. Un diagnostic relie chaque constat technique à un impact business et à une urgence relative, pour qu'une direction non technique puisse arbitrer sans avoir à retraduire elle-même une liste de deux cents lignes.

Ce qu'un bon diagnostic doit produire

Un diagnostic qui se termine par un document exhaustif mais sans hiérarchie a manqué sa cible. Ce qu'il doit produire, concrètement :

• une distinction claire entre ce qui est urgent (risque de rupture à court terme) et ce qui est important mais non urgent (dette technique à traiter avant qu'elle ne devienne un incident) ;
• une feuille de route priorisée, pas une liste plate — chaque action reliée à un ordre de grandeur de coût et de délai, suffisant pour arbitrer sans attendre un chiffrage détaillé ;
• une base commune de discussion entre la direction et les équipes techniques, qui parlent rarement le même langage sur ces sujets faute d'un document de référence partagé.

Combien de temps ça prend, et pourquoi ça ne doit pas traîner

Un diagnostic sérieux se mène en quelques semaines, pas en plusieurs mois — au-delà, le risque est que la photographie prise au début du diagnostic ne corresponde plus à la réalité au moment de sa restitution. La tentation d'un diagnostic exhaustif à l'infini est réelle mais contre-productive : mieux vaut une vue d'ensemble fiable et rapide, complétée si besoin par des zooms ciblés sur les points les plus sensibles, qu'un audit qui s'étire au point de retarder les décisions qu'il devait justement éclairer.