Conseil

Conseil

Un référentiel d’audit, pour quoi faire ?

Lors de mes différentes missions de conseil, il m’arrive souvent de prendre connaissance de divers rapports d’audit. Force est de constater que peu de rapports répondent réellement à ce que l’on pourrait qualifier de « Rapport d’audit ». En effet, la technique de l’audit informatique relève d’une démarche très précise. De nombreuses personnes confondent souvent diagnostic et audit voire même audit et rédaction de cahier des charges.

Le succès d’une mission d’audit dépend du respect d’un certain nombre de points. Parmi ces points, il en existe un en particulier qui me semble essentiel, à savoir le référentiel d’audit.

En effet, dans le cadre d’une mission d’audit, il est notamment nécessaire d’examiner et de contrôler la mise en œuvre de procédures qu’elles soient internes ou externes, ou le respect de normes.

Dans la pratique, l’expérience montre que les procédures sont souvent incomplètes et parfois mêmes inexistantes.

L’auditeur est aussi parfois amené à détecter l’origine d’un problème connu et à fournir des recommandations.

Dans tous les cas, l’auditeur doit être en mesure d’indiquer les procédures qui devraient exister et être appliquées afin de permettre d’améliorer la situation existante.

Le premier réflexe naturel de l’auditeur est de se baser sur son expérience et le bon sens afin de déterminer ce qui devrait exister.

Bien entendu, le réflexe de l’audité sera de démontrer qu’il travaille bien et que les propositions avancées par l’auditeur ne sont pas fondées et sont donc inutiles ou ne sont pas les bonnes.

L’informatique est un monde d’ingénierie dont les différents aspects sont régis par des règles bien spécifiques. Il est toujours possible de ne pas respecter certaines des règles. Par exemple : il est possible de mener a bien un projet informatique sans tenir de planning. Il est aussi possible de développer une application informatique qui fonctionne sans respecter aucune norme de codage. Avec un peu de chance, il se peut que les travaux se déroulent correctement.

Moins on se repose sur des règles et procédures plus les risques de problèmes et d’échecs sont importants.

Evidemment, plus on souhaite que les travaux se déroulent correctement, plus il est nécessaire de se conformer aux règles de l’art.

Si l’expérience et le bon sens sont bien évidemment des éléments importants dans les missions d’audit, ils sont loin d’être suffisants et c’est ici qu’intervient la notion de référentiel d’audit.

Un référentiel d’audit correspond à un recueil de règles, procédures et/ou bonnes pratiques reconnues au plan international et sur lequel l’auditeur pourra s’appuyer pour formuler ses recommandations. Dans le domaine de l’informatique, il en existe notamment deux qui sont particulièrement répandus, à savoir COBIT et ITIL.

Pour certains domaines informatiques bien spécifiques, il est également possible de s’appuyer sur des référentiels plus ciblés tels que par exemple l’ISO/CEI 27000 pour la sécurité de l’information.

Ces éléments permettent ainsi à l’auditeur de renforcer considérablement la pertinence de ses recommandations.

Maintenant, il est clair qu’il ne s’agit pas de prendre l’état de l’art pour le recommander au client. Il existe différents degrés de mise en œuvre que l’auditeur expérimenté saura déterminer de façon pertinente par rapport au contexte de son client.

Enjeux des recettes

Tampon2

L’activité de recette est une activité particulièrement sensible dans un projet car son objectif est de définir le niveau de  qualité des produits livrés par rapport à un seuil d’acceptation défini dans un cahier des charges. En effet, pour mesurer, il faut un objet à mesurer (le logiciel développé), un outil de mesure (le cahier de recettes) et une référence pour la mesure (le cahier des charges).

Bien entendu, ce cahier des charges aura notamment intégré les critères de qualité de la norme ISO qui permettent d’évaluer la qualité des logiciels.

La recette consiste à apporter en quelques sortes une certification de la qualité. Comme toute activité d’évaluation, elle doit reposer sur une méthodologie éprouvée et être exécutée avec une très grande rigueur.

Les principaux risques

Les principaux risques liés au fait de ne pas formaliser les tests de recette sont les suivants :

  • passer l’essentiel du temps à tester des cas qui ne seront qu’exceptionnellement exécutés par les utilisateurs alors que les cas métiers les plus fréquents seront peu ou pas testés. Parfois, le désir de vouloir trouver les anomalies conduit à tester des séries de cas particuliers/ exceptionnels au détriment des cas d’utilisation usuels des utilisateurs. On récupère alors une application qui traite très bien les 20% de cas les plus rares alors qu’elle plante sur les 80% de cas les plus couramment utilisés.
  • mal répartir les cas de test et oublier des domaines importants. La formalisation des tests permet de s’assurer que tous les domaines du cahier des charges sont bien couverts.
  • être dans l’incapacité d’expliquer aux équipes de développement les conditions dans lesquelles les dysfonctionnements constatés sont apparus. Il est essentiel pour les développeurs de connaître les caractéristiques précises de survenance des anomalies. Une recette bien formalisée permet de tracer ces éléments dans des fiches dédiées ce qui représente un gain de temps considérable dans le diagnostic de l’origine du problème.
  • refaire plusieurs fois les mêmes cas de recette au sein d’une même session de recette. En effet, lorsque les cas ne sont pas écrits et si la recette dure ne serait ce que quelques heures, il est fort possible que les mêmes cas soient exécutés plusieurs fois. En effet, la personne en charge de la recette ne saura plus forcément si tel ou tel cas précis a été exécuté ou non. Cela a un double inconvénient : perte de temps au détriment d’autres cas qui ne seront probablement pas exécutés.

Dans l’idéal, pour ne pas négliger les phases de recette, qui se trouvent souvent sur le chemin critique, il faut les anticiper suffisamment à l’avance et donc les planifier dès le début du projet. Dans la pratique, il est possible de commencer à préparer la recette dès la fin de la phase de cahier des charges.

Attention toutefois, des arbitrages fonctionnels et des précisions sont apportés lors des phases d’analyse et de conception. Ces éléments ont souvent des impacts sur le descriptif des tests à réaliser. Pour ce qui est du cahier de recette, il est donc préférable d’effectuer l’essentiel de la rédaction pendant la phase de développement.

Par contre les travaux d’organisation de la recette seront à effectuer en amont du développement.

Audit des systèmes d’information

Audit des systèmes d'information

Parce que la performance de votre entreprise dépend de plus en plus de la performance de votre système d’information, nous réalisons pour vous des audits complets ou partiels afin de rechercher les dysfonctionnements en matière de système d’information, informatique ou organisation. Ces axes d’amélioration sont assortis d’une ou plusieurs recommandations.

L’audit des systèmes d’information peut porter sur :

  • Audit des applications opérationnelles,
  • Audit des projets nouveaux,
  • Audit de la maintenance,
  • Audit de la sous-traitance, …
  • Audit de la sécurité,
  • Audit de l’architecture,
  • Audit des télécommunications,
  • Audit de l’organisation générale,
  • Audit de la planification,
  • Audit de la performance et des procédures,
  • Audit des applications opérationnelles,

Nos missions s’appuient notamment sur des référentiels reconnus au niveau international tels que COBIT, ITIL, ISO 17799…et sont toujours adaptées au contexte de nos clients.

Elles se composent de trois grandes phases, une enquête préliminaire puis une analyse détaillée suivie d’une synthèse. L’enquête préliminaire permet notamment d’établir un premier contact avec le client et de dresser un planning de travail. Les investigations détaillées qui permettent de dresser un bilan de l’existant se composent des entretiens et tests ; le rapport final étant rédigé durant la phase de synthèse. Ce dernier présente généralement, les points forts, les points faibles avec les recommandations associées. Il est organisé selon un formalisme très précis.

Retour en haut