Audit organisationnel vs audit SI : quelle différence ?

Pourquoi la confusion est fréquente

La confusion est logique, car dans la réalité de l'entreprise, organisation et système d'information sont étroitement liés.

Un même problème peut se manifester de plusieurs façons :

• lenteurs entre services
• ressaisies
• validations peu fluides
• manque de visibilité
• outils mal utilisés
• données peu fiables
• règles de gestion peu claires
• responsabilités diffuses

Selon l'angle retenu, ce même sujet peut être lu :

• comme un problème de méthode ou de coordination
• comme un problème de processus
• comme un problème d'outil
• comme un problème de contrôle
• comme un problème de sécurité et de maîtrise du SI

Un audit d'organisation peut inclure une dimension SI, mais il ne devient pas pour autant un audit SI. Inversement, un audit SI peut constater des effets organisationnels, mais il ne remplace pas un audit organisationnel.

Ce qu'est réellement un audit organisationnel

Un audit organisationnel cherche à comprendre comment l'entreprise fonctionne dans sa réalité concrète.

Il porte sur des questions comme :

• comment le travail s'organise-t-il réellement ?
• comment les rôles se répartissent-ils ?
• où se situent les points de blocage ?
• quelles étapes génèrent des pertes de temps ?
• où les décisions ralentissent-elles ?
• quelles interfaces entre équipes sont fragiles ?
• quels écarts existent entre ce qui est prévu et ce qui se passe effectivement ?

L'audit organisationnel s'intéresse donc au fonctionnement réel :

• méthodes de travail
• organisation opérationnelle
• circulation de l'information utile
• interfaces entre services
• responsabilités
• coordination
• règles de fonctionnement
• processus au sens large

Son but n'est pas d'abord de contrôler un système. Son but est de produire une lecture plus claire d'un fonctionnement et d'identifier ce qui doit être clarifié, ajusté, structuré ou revu.

Ce qu'est réellement un audit SI

L'audit SI, lui, se concentre sur le système d'information.

Il peut porter selon les cas sur :

• la sécurité
• la conformité
• les dispositifs de contrôle
• la gestion des risques
• la gouvernance du SI
• les accès
• la qualité des dispositifs de protection
• l'adéquation entre le SI et les besoins métiers
• la robustesse globale du système

Dans sa version la plus classique, l'audit SI cherche donc à répondre à des questions comme :

• le système est-il maîtrisé ?
• les contrôles sont-ils suffisants ?
• les risques sont-ils identifiés et traités ?
• la sécurité est-elle au niveau attendu ?
• le SI répond-il correctement aux exigences de conformité ou de gouvernance ?
• les procédures et dispositifs informatiques soutiennent-ils correctement l'activité ?

Autrement dit, on est ici plus proche :

• du contrôle
• de la maîtrise des risques
• de la sécurité
• de la conformité
• de la gouvernance du système d'information

La vraie différence de point de départ

La différence la plus utile à retenir n'est pas seulement une différence de définition. C'est une différence de point de départ analytique.

L'audit organisationnel part de la question :

Comment l'entreprise fonctionne-t-elle réellement, et où cela produit-il des écarts, des blocages ou des inefficacités ?

L'audit SI part de la question :

Le système d'information est-il maîtrisé, sûr, cohérent, conforme et adapté à ce qu'il doit soutenir ?

Les deux peuvent se croiser. Mais ils ne regardent pas la situation avec la même focale.

Ce que chaque audit cherche à produire

L'audit organisationnel produit généralement :

• une lecture plus claire du fonctionnement
• une identification des points de blocage
• une analyse des rôles, interfaces et responsabilités
• une mise en évidence des pertes de temps ou incohérences
• des priorités d'ajustement ou de structuration
• une base de cadrage pour un projet plus large

L'audit SI produit généralement :

• une évaluation du niveau de maîtrise du SI
• une lecture des risques
• une analyse des contrôles et vulnérabilités
• un niveau de conformité ou de sécurité
• des recommandations de renforcement
• un plan d'actions orienté SI, sécurité, gouvernance ou contrôle

On voit donc bien que le résultat attendu n'est pas le même :

• d'un côté, on clarifie un fonctionnement
• de l'autre, on évalue un système et les risques qui lui sont liés

Dans quels cas privilégier un audit organisationnel

Un audit organisationnel devient plus pertinent quand le sujet se formule d'abord comme :

• une difficulté de fonctionnement
• une perte de fluidité entre services
• un problème de coordination
• un besoin encore flou
• une organisation qui compense trop par des contournements
• un projet à structurer sur une base métier plus claire

Quelques signaux typiques :

• les équipes perdent du temps sans savoir précisément où
• les responsabilités sont partiellement implicites
• les étapes d'un processus se chevauchent mal
• le problème semble plus large qu'un simple outil
• le besoin doit être clarifié avant toute décision structurante

Dans ce type de situation, partir directement sur un audit SI risque de déplacer le sujet trop vite vers la technique.

Dans quels cas privilégier un audit SI

Un audit SI devient plus pertinent quand le sujet se formule d'abord comme :

• une question de sécurité
• un risque de conformité
• une faiblesse de contrôle
• un besoin d'évaluer la robustesse du système
• une interrogation sur la gouvernance du SI
• une difficulté clairement située dans la maîtrise informatique

Quelques signaux typiques :

• inquiétudes sur la sécurité ou la conformité
• besoin de vérifier les contrôles et protections
• niveau de risque SI mal identifié
• gouvernance du système insuffisamment clarifiée
• besoin d'évaluer la qualité des politiques ou procédures internes SI

Dans ce cas, un audit organisationnel seul serait trop large ou pas assez précis.

Les zones de recouvrement

La réalité n'est pas binaire. Il existe une zone de recouvrement importante entre les deux.

Par exemple :

• un mauvais fonctionnement entre services peut être aggravé par un SI mal configuré
• un manque de visibilité peut venir autant d'un problème d'organisation que de qualité de donnée
• une procédure peu claire peut produire un défaut de coordination et un défaut de contrôle
• une faiblesse de gouvernance SI peut être autant technique qu'organisationnelle

Dans certains cas, il faut :

• commencer par un angle principal
• puis intégrer la dimension connexe au bon niveau

Autrement dit :

• un audit organisationnel peut faire apparaître qu'un approfondissement SI est nécessaire
• un audit SI peut faire apparaître qu'un problème plus large de gouvernance doit être travaillé

L'erreur classique : partir par le mauvais angle

Quand une entreprise ressent une difficulté, elle nomme souvent le sujet à partir de ce qui est le plus visible :

• on a un problème d'outil
• le SI n'est pas bon
• il faut revoir l'organisation
• on manque de fluidité
• on a un sujet de contrôle

Mais la formulation initiale n'est pas toujours la bonne porte d'entrée.

Si l'on part trop vite sur un audit SI alors que le besoin est d'abord organisationnel, on risque de documenter correctement le système tout en laissant intacts les vrais problèmes de fonctionnement.

Si l'on part à l'inverse sur un audit organisationnel alors que le cœur du problème est la sécurité, la conformité ou la gouvernance SI, on risque de produire une lecture partielle sans traiter le niveau réel de risque.

Comment savoir lequel vous avez réellement besoin de lancer

Vous avez probablement besoin d'un audit organisationnel si :

• le sujet se manifeste surtout par des frictions de fonctionnement
• les pertes de temps sont visibles dans le travail quotidien
• le besoin est encore flou et doit être clarifié
• les interfaces entre services sont au cœur du problème
• le projet à venir demande d'abord une lecture métier ou opérationnelle

Vous avez probablement besoin d'un audit SI si :

• le sujet porte d'abord sur la sécurité, conformité, contrôle ou gouvernance du SI
• le niveau de risque informatique doit être évalué
• la robustesse des dispositifs SI est la question centrale
• vous cherchez à évaluer la maîtrise du système d'information lui-même

Vous avez peut-être besoin des deux si :

• le sujet est clairement hybride
• les symptômes sont organisationnels mais la cause est partiellement SI
• ou l'inverse

Dans ce cas, l'enjeu est de ne pas mélanger les niveaux, mais de séquencer correctement l'analyse.

Les erreurs les plus fréquentes

• 1. Réduire trop vite un problème de fonctionnement à un sujet d'outil. Le SI devient alors l'explication par défaut, alors que le problème porte parfois d'abord sur les règles, les rôles ou les interfaces.
• 2. Faire un audit organisationnel trop large pour un sujet d'abord SI. On produit un état des lieux intéressant, mais insuffisant sur le cœur du risque.
• 3. Confondre gouvernance SI et organisation générale. Les deux se recoupent, mais ne se traitent pas au même niveau.
• 4. Chercher un seul audit pour répondre à tout. Il vaut mieux choisir l'angle principal, puis approfondir le second si nécessaire.
• 5. Utiliser le terme audit sans préciser son objet réel. Un audit n'a de valeur que si son périmètre, son objectif et sa focale sont clairement définis.