Comment auditer un système sans effrayer les équipes

Quand j’annonce un audit en début de mission, les réactions sont presque toujours les mêmes. Regards fermés, sourires crispés, soupirs discrets. Dans certaines entreprises, “audit” rime avec “sanction”. C’est vécu comme une chasse aux coupables, une remise en cause, voire un prélude à des départs.

Et pourtant, un audit bien mené est l’acte fondateur d’un redressement réussi. Encore faut-il le conduire avec doigté. Pas comme un contrôle fiscal, mais comme une exploration collective.

Voici ma méthode, affinée sur 12 ans de terrain, pour auditer un système sans provoquer un effet bunker — et au contraire, gagner la confiance de ceux qui devront porter le changement.

Définir un cap clair et rassurant dès l’annonce

Je commence toujours par une communication directe. Pas un mail. Une réunion. Avec un message simple :

“Je suis là pour comprendre comment fonctionne votre SI, avec objectivité, sans a priori. Ce n’est pas une enquête, ni un jugement. C’est une photographie utile pour améliorer ensemble.”

Je précise le périmètre : technique, organisationnel, contractuel, humain. Et surtout, j’annonce la durée. L’audit ne doit pas sembler sans fin.

“10 jours. Pas plus. Et je vous restitue mes constats, sans filtre.”

Cela désamorce la peur du flou.

Ne jamais commencer par les documents

Je ne demande pas de documentation dès le début. Parce qu’elle est souvent :

– obsolète

– dispersée

– défensive (“On écrit pour se couvrir”)

– incomplète

Je commence par parler avec les gens. Je demande à voir :

– Le responsable infra

– Le chef de projet ERP

– Le support

– Le métier utilisateur le plus critique

Et je pose des questions concrètes :

– “Quand avez-vous dû improviser récemment ?”

– “Quel bug vous épuise au quotidien ?”

– “Qu’aimeriez-vous qu’on vous enlève ?”

Ces échanges me donnent la vérité d’usage. Et ils montrent que je ne suis pas là pour épingler.

Auditer sans microgérer

Je ne demande pas de justifier chaque choix passé. Je regarde le fonctionnement, pas les intentions. Si un outil est bancal mais utilisé, je le note comme tel. Je ne dis pas “c’est un mauvais choix”. Je dis “c’est un choix qui crée ces contraintes”.

Je rédige mes constats au fil de l’eau, sans vocabulaire accusatoire :

– “Le processus de ticketing est partiellement maîtrisé.”

– “Le contrat de sauvegarde n’est pas piloté activement.”

– “La cartographie des flux applicatifs est incomplète, mais les personnes clés sont identifiées.”

Mon objectif : rendre visible sans accuser.

Impliquer les équipes dans la lecture de l’audit

Je ne restitue jamais mon audit seul. Je prépare une session collaborative. Je présente les constats, je laisse les équipes réagir, corriger, nuancer. Et je note les points d’accord.

Cela change tout. Le document devient un outil partagé, pas une sentence. Et les résistances tombent.

Je demande aussi aux équipes de prioriser avec moi les constats les plus urgents. Cela me donne :

– Le point de départ du plan d’action

– Un soutien implicite

– Une dynamique d’engagement

Restituer au COMEX avec pédagogie

Enfin, je prépare une synthèse claire pour la direction. Pas un rapport technique. Une page, trois colonnes :

– Forces du SI

– Points de vigilance

– Recommandations immédiates

Je mets toujours en avant les équipes impliquées. Je souligne les talents, les bonnes pratiques. Parce qu’un audit doit valoriser autant que corriger.

En 12 ans de missions, cette approche m’a permis :

– D’éviter les blocages internes

– De gagner la confiance des équipes IT

– De produire des audits utiles, lisibles, actionnables

– De démarrer les transformations sur une base saine

Un bon audit ne dit pas seulement ce qui ne va pas.

Il révèle ce qui peut devenir un levier de progrès, si on le regarde sans peur.

Un DSI de transition n’est pas là pour juger.

Il est là pour comprendre, clarifier, et transformer avec ceux qui font.