Un audit d’infrastructure est souvent commandé après un incident. C’est le plus mauvais moment : la question posée devient « pourquoi cela est-il arrivé », alors que la question utile est « qu’est-ce qui peut encore arriver, et dans quel ordre ».
Le premier constat d’un audit n’est presque jamais technique. Il est documentaire : personne ne sait plus qui détient tel accès, à quoi sert tel serveur, ni si telle sauvegarde a déjà été restaurée.
Six domaines, et la question qui compte dans chacun
Le périmètre technique varie peu d’une entreprise à l’autre. Ce qui varie, c’est la question à laquelle il faut avoir répondu.
- Réseau. Qui peut atteindre quoi ? Le plan d’adressage et le cloisonnement disent, en creux, ce qu’un poste compromis pourrait atteindre.
- Postes et serveurs. Quelles versions ne sont plus maintenues, et quelle fonction dépend de chacune ?
- Sauvegardes. Quand la dernière restauration a-t-elle été essayée, et combien de temps a-t-elle pris ?
- Droits d’accès. Combien de comptes appartiennent à des personnes parties ? Combien disposent de droits d’administration sans raison actuelle ?
- Sécurité. Que se passe-t-il concrètement le jour où un poste est chiffré — qui est prévenu, dans quel délai, et par qui ?
- Obsolescence. Quelles échéances de fin de support tombent dans les vingt-quatre mois, et laquelle emporte un projet d’entreprise avec elle ?
Aucune de ces questions n’exige un outillage rare. Toutes exigent qu’on accepte la réponse, y compris quand elle est « nous ne savons pas ».
Ce que révèle le comptage des accès
C’est l’exercice le plus rentable, et le plus simple : établir la liste des comptes disposant de droits étendus, puis mettre un nom en face de chacun. Sur un parc jamais audité, la proportion de comptes sans titulaire identifiable surprend systématiquement.
Elle ne traduit pas une négligence. Elle traduit une accumulation ordinaire — un prestataire parti, un projet arrêté, un dépannage jamais refermé. Le problème n’est pas qu’ils existent, c’est que personne ne sait qu’ils existent.
Un accès dont on ignore l’existence ne se révoque pas, ne se surveille pas, et ne se compte pas dans le risque.
Le point où les audits se ressemblent tous
Trente constats, un tableau, quatre couleurs. Le document est complet et inexploitable : il laisse au dirigeant le soin d’arbitrer entre des anomalies qu’il n’est pas en mesure de comparer.
Un rapport utile hiérarchise sur deux axes seulement : ce que ça coûte si cela arrive, et à quel point c’est vraisemblable. Trois lignes en tête — voilà ce qu’on traite ce trimestre, voilà ce qu’on programme, voilà ce qu’on accepte de laisser — valent mieux que trente lignes égales.
Ce qui rend un audit inutile
- Il est réalisé par celui qui vendra la correction. Le rapport nomme alors les problèmes que le prestataire sait traiter.
- Il évalue l’existant sans demander à quoi il sert. Un serveur sous-dimensionné pour un usage abandonné n’est pas un risque.
- Il ne dit pas ce qu’il n’a pas regardé. Un périmètre non énoncé se lit comme un périmètre couvert.
Le troisième point est celui qui coûte le plus cher. Un audit qui tait ses limites laisse croire à une couverture complète, et l’entreprise range le sujet pour deux ans.
À quel moment le commander
Trois situations le justifient sans incident préalable : avant de signer ou de renouveler un contrat d’infogérance, avant d’engager un projet qui s’appuiera sur l’existant, et au moment où l’interlocuteur technique historique s’apprête à partir.
Ce relevé dit ce que l’on a. Il ne dit pas ce qui vous menace en premier : pour cela, il faut hiérarchiser par scénario plutôt que par criticité théorique.
Dans les trois cas, ce qu’on achète n’est pas un diagnostic technique. C’est le fait de savoir ce dont on dispose avant de s’engager sur autre chose.
Questions fréquentes
Qu’est-ce qu’un audit d’infrastructure informatique ?
C’est l’examen de six domaines — réseau, postes et serveurs, sauvegardes, droits d’accès, sécurité, obsolescence — pour établir ce qui peut arriver et dans quel ordre. Son premier constat est souvent documentaire : ce que l’entreprise ne sait plus d’elle-même.
Comment vérifier qu’une sauvegarde fonctionne ?
En essayant de la restaurer, et en datant l’essai. Une sauvegarde jamais restaurée n’est qu’une intention. L’audit demande quand la dernière restauration a été tentée et combien de temps elle a pris.
Quand faut-il faire un audit d’infrastructure ?
Idéalement hors crise : avant de signer ou de renouveler un contrat d’infogérance, avant un projet qui s’appuiera sur l’existant, ou quand l’interlocuteur technique historique s’apprête à partir. Commandé après un incident, il répond à la mauvaise question.