L'audit "pratique" des systèmes d'information, c'est quoi ?

Il y a bien des situations où l'audit peut favoriser le progrès, la mise à niveau, l'efficience, la maturité des systèmes d'information... Quelles que soient les situations, l'audit "pratique" est utilisé comme un outil de mesure.

L'audit des systèmes d'information est souvent vu sous l'angle "audit financier". Est-ce la seule approche ? Il y a pourtant bien des situations où l'audit peut favoriser le progrès, la mise à niveau, l'efficience, la maturité des systèmes d'information ... et donc avec une approche plus "pratique". Quelles que soient les situations, l'audit "pratique" est utilisé comme un outil de mesure.

L'audit se présente alors comme un examen méthodique et indépendant permettant de mesurer une situation par rapport à un référentiel. Les caractères "méthodique" et "indépendant" sont essentiels. Mais l'auditeur et sa nécessaire maîtrise opérationnelle des systèmes d'information sont fondamentaux.

L'audit financier sinon rien ?
L'audit des systèmes d'information est souvent vu sous l'angle des audits financiers :

* Qui est demandeur de ce type d'audit ?

Le demandeur peut être interne (direction financière, maison mère, etc.) ou externe (la Commission Européenne, OSEO, la DGI, mission de commissaire aux comptes, etc.).

* Quelles informations sont importantes?

Toutes les informations (financières ou non) liées à la pertinence des dépenses peuvent être importantes. Des audits et expertises techniques font souvent partie d'un audit financier. Une information isolée n'est pas significative. Ce sont les associations d'informations qui permettent de tirer des conclusions

* Quels sont les objectifs, conséquences (et sanctions) d'un audit financier ?

L'objectif n'est pas de "punir", mais d'identifier des risques et des faiblesses, et d'en tirer des recommandations pour des actions correctives. Cependant, il est vrai qu'il y a souvent des conséquences financières (Crédit Impôts Recherche, subventions européennes, approbation des comptes, etc.)

Y-a-t-il d'autres approches que "financière" de l'audit des systèmes d'information ?

L'audit dit "pratique" est souvent aussi un préalable à une majorité d'actions liées aux systèmes d'information, comme par exemple :

* pour une PME: pour mesurer l'adéquation des services internes en systèmes d'information utilisés par les salariés pour leur utilisation opérationnelle quotidienne et pour améliorer ces services

* pour une TPE proposant des produits et services en systèmes d'information : pour qualifier et améliorer l'offre d'outils et services destinée aux clients de la société

* pour une banque : pour s'assurer de la conformité de la production informatique aux standards iso 9001, iso 20000-1 et iso 27001

* pour les DSI de moins de 100 personnes de divers secteurs (énergie, jeux, hôpitaux, ...) : pour l'amélioration et la validation des éléments organisationnels, fonctionnels et techniques des processus de Service Management.

* pour un éditeur de logiciel de paye : pour s'assurer de la conformité de l'application aux exigences réglementaires (Sarbanne Oxley...)

* pour un opérateur téléphonique international : pour s'assurer du déploiement homogène des méthodes de conception, production, administration, supervision (...) des systèmes d'information


Audit comme outil de mesure, ça fonctionne comment ?

Que peut-on bien mesurer ? L'audit "pratique" sert à mesurer :

* si les activités et les résultats satisfont aux dispositions préétablies

* si ces dispositions sont mises en œuvre de façon efficace, efficiente...

* si elles sont aptes à atteindre les objectifs.

Comme tout outil de mesure, un audit n'a de réel intérêt que si il permet de réaliser une mesure fiable. Quel crédit peut-on donner à la température restituée par un thermomètre défaillant ?


Alors comment fiabiliser la mesure restituée par leurs audits "pratiques" ? * respect des normes et standards reconnus en matière de maîtrise des techniques d'audit comme l'iso 19011 "Lignes directrices pour l'audit des systèmes de management : conseils pour le management d'un programme d'audit, les activités de l'audit et les compétences des auditeurs".

* utilisation de bases d'expériences partagées entre auditeurs :

- techniques d'échantillonnage des thèmes, sites, activités... audités

- consolidation, croisement et complétude des échantillonnages sur la durée pour avoir la mesure la plus complète et la plus fiable possible,

- check-lists d'audit par secteurs d'activité (SI et banque, SI et nucléaire, SI et TPE...) et par thématique des systèmes d'information (conception, développement, infrastructure, production....)

* adaptation des étapes de l'audit et de l'équipe d'audit à la taille de la DSI auditée (audit pour DSI de moins de 10, 50, 100 et plus de 100 opérationnels)

* mobilisation d'un réseau d'experts techniques sectoriels (banque, industrie...) et métiers (production de services, production informatique, conception, tierce-maintenance applicative) en appui des auditeurs selon leurs besoins pour garantir le caractère opérationnel de l'audit.


Quels sont les objectifs d'un audit pratique ? Les objectifs de la mesure sont divers et complémentaires selon les contextes :

* Proposer des améliorations (par exemple, sur les logiciels, matériels, réseaux,.. mais aussi les méthodes de travail, les processus...)

* Vérifier la conformité à un point précis ou un référentiel restreint et défini souvent unilatéralement (par exemple, audit des commissaires aux comptes en milieu informatisé, audit d'un processus ITIL...)

* Vérifier la conformité, révéler les non-conformités, Mesurer les écarts de la mise en œuvre d'un système (par exemple, audit iso 20000-1, iso 27001...)

* Mesurer l'efficacité, l'efficience ou la maturité (par exemple audit CMM,..) selon une échelle de maturité donnée

* Certifier au sens produit ou service (par exemple, certification Microsoft, certification SAP...)

Quel que soit l'objectif de la mesure, l'audit "pratique" s'attachent à rendre l'audit opérationnel, efficient (atteindre l'objectif en mobilisant les moyens les plus pertinents, dans la durée la plus limitée possible) et utile tant pour l'audité que pour le commanditaire de l'audit.


Méthodique, pourquoi et comment ?

 Pourquoi faut-il être méthodique ?
- Pour être efficient avant tout.

* On n'a jamais assez de temps. Donc, éviter d'en perdre.

* Ne rien oublier. Donc, tout planifier (plan, programme....)


- Pour voir le maximum de thèmes en un minimum de temps (L'audit est un échantillonnage. On ne voit pas tout. Il faut rationaliser son temps)

* Faire un audit de 20, 30 ou 40 jours n'a pas de sens. Il est nécessaire de travailler en couche progressive, échantillonner, croiser.... pour assurer la couverture la plus complète possible en auditant le juste nécessaire (principe de Pareto, loi des 20-80)

* Mobiliser les bons auditeurs sur les bons thèmes, au bon moment, aux bons endroits

* Croiser les sources d'information

- Pour garantir la qualité des observations (croisement des sources d'information, notion de rebouclage et de cycle de vie Plan-Do-Check-Act, ...)


Comment être méthodique ?

- Travailler sur les 4 niveaux d'analyse possible, de la vision stratégique jusqu'aux outils :

* stratégie : d'abord connaitre la stratégie de l'entreprise... et de la DSI

* process : identifier les process clés (planification, diffusion d'information, amélioration, mesure, prévention, pilotage...)‏

* humain : bien déterminer le rôle de chacun, les forces en présence, les circuits de décision, les responsabilités et autorités

* technologies-outils-moyens : procédures, modes opératoires, applicatifs, logiciels de tests, de supervision.... infrastructures....


- Planifier l'audit pour mobiliser les bons acteurs, aux bons endroits, sur les bons sujets, au bon moment. Pour cela mobiliser des auditeurs intervenant sur site pour tout ou partie des thèmes, appuyés par des experts consultables ponctuellement à distance sur une thématique précise donnée


- Intégrer l'ensemble des objectifs (financier, technique, outils, stratégique, ...) et référentiels (iso 9001, Cobit, ...) pour en tenir compte lors d'un seul et même audit. Pour ne pas juxtaposer des séries d'audits, chacun centré sur une thématique donnée



Indépendant, comment ?

En définissant clairement et précisément la mission de l'audit (activité, sites, durée, charge, livrable, contraintes, pré-requis...)

En mobilisant des auditeurs qui ne peuvent être "juge" et "partie", c'est-à-dire indépendant du domaine audité.

En séparant bien les intérêts personnels de l'auditeur (à oublier pendant l'audit) des intérêts de l'audit (objectifs du commanditaire à satisfaire, obtention de l'adhésion des audités). L'auditeur ne réalise pas l'audit pour son besoin personnel, sa culture, son business... mais pour mener à bien la mission qui lui est confiée.

En faisant suivre et coordonner le travail des auditeurs et les livrables par un tiers expérimentés, aguerri aux techniques d'audit, et digne de confiance.


Un référentiel. Lequel choisir ?

Pour un audit donné, une SEUL référentiel ou PLUSIEURS référentiels (dans le cas d'audits intégrés) peuvent être utilisés.

Selon le type d'audit, les référentiels sont de natures diverses :

* Audit de système > normes, standards, recueil de bonne pratique

* Audit de processus ou Audit de procédé > fiche process, fiches méthodes...

* Audit de produit/ service > spécification technique / de services‏

* Audit de procédure > procédure, mode opératoire ...


Un référentiel peut être constitué sur mesure, par l'expérience, selon les spécificités de l'organisme...

Par exemple, un référentiel d'audit de niveau global permettant d'appréhender le système d'information d'un organisme aborde des thèmes du type : périmètre et contexte de l'audit, architecture du système d'information, réseau et télécom, Web et Internet, matériels (couvrant le périmètre), caractéristiques par type de matériel, logiciels par type de matériel (poste client, serveurs...), applications logicielles développées ou du commerce ou libre, description fonctionnelle du besoin des applications logicielles, description de la solution technique retenue, critères de choix/ sélection des matériels, logiciels, réseaux..., coûts, sécurité, organisation & responsabilités...

Concernant les normes et standards en matière de systèmes d'information, plusieurs référentiels existent. Ils s'appliquent à des domaines distincts et sur des périmètres divers : développement logiciel, services de production informatique, gestion globale du système d'information, sécurité...

Par exemple :

* iso 9001 (créée en 1987). Norme de type système (structurée selon le cycle Plan-Do-Check-Act). Définit des règles standards à respecter pour tout organisme souhaitant fournir ses produits et ses services de qualité.

* iso 20000-1. Norme de type système. Définit des règles standards à respecter pour tout organisme fournissant des services et souhaitant atteindre un excellent niveau de maîtrise de ses activités en vue de satisfaire ses clients.

* iso 27001. Norme de type système. Définit des règles standards en matière de sécurité (confidentialité, intégrité, disponibilité) des systèmes d'information à respecter pour tout organisme souhaitant en garantir la maîtrise dans la réalisation de ses activités en réponse à ses propres exigences internes ou à celles de ses clients.

* Cobit, Control Objectives for information and Related technologies (développé en 1996) permet de maîtriser les risques attachés aux systèmes d'information & de contrôler les investissements.

* CMMi, Capability Maturity Model Integrated. Ensemble de bonnes pratiques permettant d'évaluer le degré de maturité d'un organisme ou d'un service.

* ITIL, IT Infrastructure Library (20 ans d'existence et d'expérience), référentiel de bonnes pratiques de la Gestion des Services Informatiques,

* Six Sigma est une discipline d'analyse basée sur des faits vérifiables statistiquement pour améliorer les processus clés de l'organisme (processus d'amélioration orienté client).

Autour du même sujet