Pourquoi partir des besoins Business pour l’audit du S.I.

Cartographie ou Audit du système d’information : est-ce la même chose ?

Dans les deux cas, l’objectif est de savoir quelle est l’adéquation entre les différents éléments du système d’information et les services rendus pour atteindre les objectifs de l’entreprise.

Pour gérer, utiliser et comprendre un S.I, il est nécessaire de disposer :

• d’une architecture matériel (physique ou virtuel via un cloud) ;
• d’une architecture d’administration système ;
• d’un ensemble de logiciel / progiciel (en propre ou via des services) ;
• d’une cartographie des données ;
• d’un ensemble de clients (PC, mobile, IoT, … ) pour y accéder et/ou le mettre à jour ;
• d’un inventaire des traitements.

Bien souvent, le résultat d’un audit ou d’une mission de cartographie ressemble à un inventaire agrémenté de quelques critères de qualité, robustesse, réponse aux attentes des utilisateurs, … ainsi que quelques recommandations pour les prochaines évolutions. Et c’est au lecteur (demandeur) d’essayer de le traduire en intérêt business. C’est bien pour cela qu’on entend encore de temps en temps après la lecture d’un inventaire pareil: « Le S.I, qu’est ce que ça coûte !! « 

L’entreprise bouge, évolue et donc ses besoins aussi. Il est simple et rapide de faire un tour d’horizon des besoins actuels. Tout auditeur commence par cela afin de comprendre l’entreprise. Il doit aller plus loin que leur simple compréhension en les formalisant (si cela n’est pas déjà fait) de manière synthétique. Cette liste présentera la ou es destinations à atteindre grâce à la cartographie du S.I.

L’informatique, comme de multiples autres domaines, a ses propres modes. Il faut donc que l’auditeur fasse la part entre « être à la page » et être efficace. Il ne faut pas occulter le ressenti des utilisateurs du S.I, même quand leurs besoins / usages ne sont pas forcément en cohérence avec les objectifs de l’entreprise, car c’est grâce aux utilisateurs (ayant des outils qui leur plaît) que l’ensemble fonctionne et atteindra les objectifs attendus 😉

Il arrive, certaine fois, qu’une évolution soit décidée pour être « à jour » sur le plan technologique ou sur le plan esthétique. Y a t’il vraiment un apport pour les utilisateurs ou juste un effet de mode. Même si le changement fait toujours peur, il me semble impératif de convaincre direction et utilisateurs avant d’acter une évolution. L’audit doit donc prendre en compte de manière distinct pour chaque chaque processus/application, d’une part l’efficacité et d’autre part son ergonomie / facilité d’usage.

Un audit est souvent utilisé pour planifier les évolutions, il doit donc contenir les valeurs de références pour les indicateurs qui seront utilisés pour mesurer la validité et la réussite de chaque évolution.

Cartographier l’ensemble d’un Système d’Information demande de l’expérience et une capacité à parler plusieurs « langues » : technique, business / métier client et informatique. Il doit permettre aux lecteurs des délivrables (de l’audit, donc orienté métier) de comprendre chacun des éléments de l’ensemble (donc technique), de manière à :

1. bien appréhender l’existant, (ses apports et sa complexité)
2. faciliter le dialogue avec tous les intervenants (direction, utilisateurs, informaticien interne, externe, …)
3. trouver les bonnes priorités (Business, confort utilisateur, contrainte techniques/légale, dette technique)

Olivier Heintz
Directeur de projet, Architecte applicatif et fonctionnel