Un audit informatique vaut ce que vaut l’indépendance de celui qui l’écrit

Un audit informatique se commande rarement par curiosité. Il arrive après un incident, avant un changement de prestataire, ou parce qu’un tiers — assureur, client, banque — a demandé à voir quelque chose.

Dans les trois cas, le commanditaire n’est pas en position d’évaluer le travail qu’il achète : c’est précisément parce qu’il ne sait pas qu’il commande. La seule chose qu’il peut évaluer avant de signer, c’est la situation de celui qui va écrire.

Ce que couvre un audit informatique

Le périmètre standard tient en trois blocs, et le troisième est celui qu’on oublie de demander.

• L’existant technique. Parc, réseau, sauvegardes, accès, sécurité, niveaux de support et échéances de fin de vie.
• Les engagements contractuels. Ce que disent les contrats en cours : périmètre réel de la maintenance, délais engagés, conditions de sortie, propriété des développements.
• L’organisation. Qui décide, qui exécute, qui est prévenu. Un système correctement outillé et sans interlocuteur désigné tombe aussi sûrement qu’un système obsolète.

Le deuxième bloc est le plus rentable et le moins demandé. Une PME découvre régulièrement, à cette occasion, que sa maintenance ne couvre pas ce qu’elle croyait, ou que sortir de son contrat suppose une prestation jamais chiffrée.

La question du conflit d’intérêt

Elle ne se pose pas en termes de probité. Elle se pose en termes de structure : un auditeur qui vend aussi la solution voit d’abord les problèmes qu’il sait résoudre, et évalue mal ceux qu’il ne saurait pas traiter.

Trois questions permettent de situer un prestataire avant de lui confier un audit :

• Revendez-vous du matériel ou des licences, et sur quelle marge ?
• Êtes-vous rémunéré par un éditeur ou un constructeur au titre d’un partenariat ?
• Si l’audit conclut qu’il ne faut rien changer, quelle est votre rémunération ?

Aucune réponse n’est disqualifiante en soi. Une réponse évasive l’est.

On ne demande pas à un auditeur d’être désintéressé. On lui demande de dire ce dont il vit.

Les quatre étapes d’un audit qui sert

• Cadrer. Ce qu’on regarde, ce qu’on ne regarde pas, et à quelle décision le rapport doit servir.
• Relever. Sur pièces et par entretien. L’entretien révèle ce que les outils ne voient pas : les contournements, les dépendances à une personne, les usages abandonnés.
• Hiérarchiser. Par conséquence et par vraisemblance, pas par domaine technique.
• Trancher. Le rapport propose ; le dirigeant arbitre. Un audit qui ne se termine pas par une décision écrite n’a pas produit son effet.

Ponctuel ou récurrent

Un audit ponctuel répond à « où en sommes-nous ». Il se justifie à un moment de décision : renouvellement, incident, changement d’échelle, cession.

Un accompagnement récurrent répond à « restons-nous au niveau ». Il ne se justifie que si l’entreprise a effectivement des choses à décider régulièrement — sinon il produit des rapports qui se ressemblent et que plus personne ne lit.

L’erreur consiste à souscrire un suivi permanent pour éviter d’avoir à trancher une fois. La récurrence ne remplace pas la décision, elle la reporte à intervalle régulier.

Ce qui devrait figurer en première page

Trois lignes, avant tout tableau : ce qui doit être traité ce trimestre, ce qui est programmé dans l’année, ce que l’entreprise choisit d’assumer en l’état. La troisième ligne est la plus importante — c’est celle qui transforme une liste de risques en décision.

Reste à savoir lequel des deux exercices on achète, car ils portent le même nom : audit technique et audit de décision ne s’adressent pas au même lecteur.

Un rapport qui ne comporte pas cette troisième ligne suppose que tout doit être corrigé. Aucune entreprise ne fonctionne ainsi, et le document finit dans un dossier partagé.

Questions fréquentes