ITIL

ITIL

Cohérence des analyses de risques

S’il est bien un problème qu’il est nécessaire d’éviter c’est de solliciter plusieurs fois des personnes pour poser les mêmes questions.

Pourtant c’est bien ce qui se passe dans de nombreuses entreprises lorsque d’un côté l’on sollicite des utilisateurs dans le cadre d’une analyse de risques et que de l’autre on les sollicite dans le cadre d’un plan de continuité d’activité. Cela est d’autant plus gênant que ces démarches sont assez consommatrices de temps. De plus, le fait de solliciter deux fois les utilisateurs sur des sujets identiques donne un peu un sentiment de désorganisation.

En effet, l’analyse de risque va généralement s’attacher à qualifier les impacts de la perte des critères suivants :

  • Disponibilité
  • Intégrité
  • Confidentialité
  • Preuve (traçabilité)

Dans le cadre de la démarche d’élaboration de PCA/PRA, une analyse de risque va également être menée au niveau de la phase dite d’analyse d’impacts. Elle va aussi s’attacher à déterminer les impacts de la perte des moyens de production mais de façon beaucoup plus fine. Elle va notamment évaluer le temps pendant lequel il est possible de se passer de ces moyens.

Dans les analyses de risques, le problème est que les analyses de perte de disponibilité qui sont menées restent assez générales et ne sont pas suffisantes pour déterminer de façon précise les moyens de continuité/ reprise d’activité. En effet, dans le cadre des PCA/PRA relatifs au sinistre des moyens informatiques, il existe deux éléments absolument fondamentaux dans ce domaine qui sont :

  • La Durée d’indisponibilité maximale autorisée (DIMA)
  • Perte de données maximale admissible (PDMA)

Ce sont ces éléments qui vont permettre de dimensionner les solutions techniques à mettre en œuvre.

Or les analyses de risques du type EBIOS, MEHARI, …ne rentrent pas dans ce niveau de détail et ne peuvent pas être utilisées telles quelles pour déterminer les solutions de continuité ou reprise d’activité.

Il existe donc une nécessaire mise en cohérence des analyses de risques avec les démarches de plans de continuité d’activité avant de solliciter les utilisateurs.

Il est d’ailleurs regrettable que cette problématique de cohérence ne soit pas abordée dans le référentiel ITIL.

Pourquoi est-il nécessaire de rédiger un cahier des charges ?

Telle est la question

Plans roulés et pont1

La question pourrait être la même lorsqu’il s’agit de construire un immeuble, une voiture ou n’importe quel autre objet : pourquoi faut-il faire des plans ? Il faut faire des plans parce que cela permettra déjà de savoir quel est le produit fini attendu et surtout, cela permettra de faire une estimation de coûts et de délais.

En d’autres termes, si votre budget et vos délais sont très extensibles (ce qui est plutôt rare), il est possible de ne pas réaliser de cahier des charges. Cela signifie que vous avez les moyens de payer pour demander aux réalisateurs de

casser tout ou partie de ce qui a été élaboré pour le refaire d’une autre façon. Réaliser un cahier des charges nécessite du temps et de la réflexion. Cela requiert donc un effort et il est en effet très séduisant de penser que par miracle, il serait possible de s’affranchir de formaliser ses besoins. Personnellement, je ne connais aucun métier dans lequel il est possible d’obtenir quelque chose pour un délai et un coût donné sans l’avoir préalablement décrit avec un minimum de précisions.

Si les besoins ne sont pas précisément décrits, le risque est bien évidemment d’obtenir un service qui ne répond pas aux besoins ou qui y répond mais de façon partielle. Comment expliquer et démontrer alors que les besoins attendus ne sont pas pris en compte si aucun cahier des charges n’a été rédigé. Ainsi à la question « Pourquoi est-il nécessaire de faire un cahier des charges ?», il est possible de répondre avec une autre question « Comment puis-je faire pour vérifier que mes besoins ont bien été pris en compte et comment démontrer qu’il existe des manques le cas échéant ?».

Les bonnes pratiques

Ne pas réaliser de cahier des charges va à l’encontre des bonnes pratiques reconnues au plan international. Cf  ITIL service design : Identifying service requirements : “The need for accurate and representative information from the business is paramount”.

Il ne faut cependant pas confondre cahier des charges et carcan. Si certains considèrent parfois le cahier des charges comme un carcan trop rigide, ce n’est pas le cahier des charges en lui-même qui est trop rigide mais bien souvent le budget du projet et le délai associé.

En effet, tant que le cahier des charges n’est pas validé, il est toujours possible de modifier les besoins qui le composent (en réajustant le délai de livraison associé). Après validation du cahier des charges, il doit toujours être possible d’apporter des modifications au projet pour autant que cela ait été prévu dans le projet. Ces modifications seront alors à traiter en tant qu’évolutions. Cependant, pour que tout cela soit possible, encore faut-il l’avoir prévu en amont. Ainsi, dès le début du projet, en plus du coût du projet lui-même, il convient de prévoir un coût d’évolutions.

Prévoir que le projet évoluera

Deux grandes erreurs sont souvent commises : le refus des évolutions en cours de projet (après rédaction du cahier des charges) et le refus des évolutions à l’issue de la mise en production. Cela provient essentiellement du fait que l’on pense que les personnes qui rédigent le cahier des charges disposent d’une boule de cristal qui leur permettra de préciser 100% des besoins. Dans la pratique, ce n’est jamais le cas. En 20 ans d’expérience, je n’ai jamais vu un projet aboutir sans un minimum d’évolutions.

Lorsque les enveloppes de budget d’évolutions ne sont pas prévues au début du projet, cela génère systématiquement des tensions entre maîtrise d’œuvre et maîtrise d’ouvrage avec des personnes qui finissent parfois par travailler les unes contre les autres. Or, comment est-il possible de réussir un projet lorsque les parties prenantes travaillent les unes contre les autres au lieu de travailler ensemble ? Bien entendu, toute nouvelle application induit un changement et il existe toujours des utilisateurs réfractaires. Si les évolutions ne sont pas possibles ou trop limitées, ils vont alors trouver là une aubaine formidable pour enterrer définitivement le projet.

Le fonctionnement basé sur la prévision des évolutions s’apparente un peu au fonctionnement des méthodes agiles avec 3 itérations. Une première qui couvre 80% des besoins et qui découle du cahier des charges initial.

Une seconde qui devrait couvrir environ 10% de besoins supplémentaires découverts après la rédaction du cahier des charges. Une troisième qui doit permettre de mettre en œuvre les 10% restants. Ainsi, dans ce type de démarche, le nombre d’itérations est connu et fixé d’avance, ce qui permet un bon cadrage du budget global.

Gérer le risque

Il existe également un risque très important lié au fait de ne pas (ou mal) faire de cahier des charges : il se peut tout simplement qu’une fonction fondamentale ne soit tout simplement pas réalisable avec l’outil de développement retenu. Si cette fonction est identifiée par les utilisateurs alors que 80% du projet est déjà réalisé, tout peut alors être mis à la poubelle… Si le choix d’un outil est généralement fait en amont du cahier des charges, dans le cadre d’une étude d’opportunité par exemple, c’est pendant ou à l’issue du cahier des charges (tant que rien n’a été construit) qu’il est encore temps de changer d’outil de construction si nécessaire. En l’absence de cahier des charges, cette nécessité de changement risque fort d’intervenir trop tard.

Enfin, le cahier des charges permet aussi de détecter si le besoin est suffisamment mûr ou non. En effet, le simple fait de mettre les besoins par écrit permet parfois de détecter des avis divergents ou des changements d’avis intempestifs. Il est bien entendu nettement préférable de traiter ces divergences et incertitudes dans le cadre de la rédaction d’un cahier des charges plutôt que de construire directement pour tout casser ensuite.

Comment décrire un besoin ou comment rédiger un cahier des charges ?

Le cahier des charges

Fondations3

Bien entendu, les utilisateurs peuvent exprimer leurs besoins comme ils le souhaitent. Cependant le document qui servira de référence en la matière correspondra au cahier des charges.

La phase de rédaction du cahier des charges correspond en quelques sortes à la phase dans laquelle sont posées les fondations du projet.

Les phases qui suivent le cahier des charges visent à construire le projet à partir des éléments qui ont été définis dans le cahier des charges. Le contenu du cahier des charges est en ce sens tout particulièrement important.

En effet, l’expérience montre que plus les erreurs produites dans le cahier des charges sont détectées tardivement dans les phases qui suivent, plus leur correction à un coût élevé.

Il est clair que dans la construction d’un pont ou d’un immeuble, il coûte très cher de corriger un défaut dans les fondations lorsque les ouvriers sont en train de faire les finitions ou la toiture.

L’expérience montre également que les descriptions de fonctions souffrent facilement de très nombreux maux lorsqu’elles ne sont pas écrites de façon professionnelle et structurée comme par exemple :

  • manque de clarté,
  • ambiguïtés,
  • absence de traçabilité,
  • manque de cohérence,
  • oublis,
  • etc..

Le cahier des charges se doit également d’être précis. Lorsqu’il existe des imprécisions qui subsistent à l’issue du cahier des charges et des spécifications (ce qui arrive parfois), cela se transforme souvent en source de litige.

La maîtrise d’ouvrage aura tendance à dire « C’était évident ». L’expérience montre cependant que rien n’est évident.

Exemple :

Dans un projet de base documentaire, nous avions demandé un moteur de recherche avancée qui selon le cahier des charges devait permettre des recherches sur mot clés.

Dans la première livraison, le moteur permettait des recherches sur mots clés à condition de tous les saisir dans l’ordre où ils avaient été saisis lors du dépôt du document dans la base. Inutile de préciser que c’était inutilisable.

Dans la seconde livraison, il n’était possible de saisir qu’un seul mot clé dans la zone de mots clés du moteur de recherche avancée. Cette version était déjà mieux mais plutôt très limitée pour un moteur de recherche dit « avancé ».

Enfin, la troisième version fut la bonne.

Le bon équilibre

Bien entendu, le cahier des charges ne doit pas tout préciser. Il ne faut pas non plus tomber dans le syndrome de l’excès de précisions qui risque d’être trop consommateur de temps et de budget. En effet, dans les projets, la hiérarchie attend des résultats concrets et de façon « rapide ». Passer trop de temps sur la phase de cahier des charges agace souvent assez vite les managers, ce qui peut conduire dans certains cas à l’abandon du projet avec pertes et fracas.

La rédaction d’un cahier des charges repose de plus sur un savoir faire qui couvre plusieurs domaines :

  • savoir cadrer le besoin (objectifs, périmètre,…),
  • savoir le recueillir,
  • savoir le comprendre,
  • savoir trouver le bon niveau de détail,
  • savoir le formaliser.

Qualité

Enfin, étant donné que le cahier des charges va devoir servir de référence (lors de la phase de recette) pour vérifier si les besoins ont bien été pris en compte et si la qualité est assurée, il doit prendre en compte les grands critères de qualité des logiciels décrits dans la norme ISO 9126 (maintenant intégrée dans la famille des normes ISO 25000).

Autant dire que les risques de défauts dans les fondations des projets sont nombreux si le cahier des charges ne tient pas compte des éléments qui précèdent. Dans la pratique, il est considéré que 80% des problèmes rencontrés dans les applications trouvent leur origine dans la phase de rédaction du cahier des charges (ITIL).

De plus, tous les référentiels de qualité s’accordent pour dire que la qualité se forge le plus en amont possible des projets.

Bien entendu, pour permettre de produire un cahier des charges de qualité qui soit en mesure de servir de fondations aux projets, AMJ a produit un référentiel méthodologique complet qui détaille chacun de ces aspects. De la même façon qu’il existe des techniques pour construire les fondations d’une maison, il existe aussi des techniques pour élaborer les fondations d’un projet.

Conseil en informatique et systèmes d’information

Le conseil en organisation et systèmes d’information fait partie des toutes premières activités de AMJ GROUPE depuis la création de la société en 1986.

Aujourd’hui, nous assistons nos clients aussi bien dans leurs choix stratégiques en matière d’organisation et de systèmes d’information que dans la formalisation de leurs besoins, soit en maîtrise d’ouvrage soit en maîtrise d’œuvre.

Nous sommes principalement reconnus pour nos compétences dans le domaine de l’assistance à maitrise d’ouvrage et en particulier pour ce qui est des études d’opportunités, rédactions de cahiers des charges, assistance au pilotage de projets et recette. Domaines sur lesquels notre capitalisation depuis 20 ans nous apporte un réel savoir-faire que nous vous ferons partager. Nos méthodes d’intervention adaptées au contexte de nos clients et l’approche pragmatique de nos consultants expérimentés nous permettent de vous assurer le succès de nos missions. Par ailleurs, notre indépendance vis-à-vis de tout fournisseur de matériels et logiciels nous permet de vous garantir la totale objectivité de nos travaux et recommandations..

De façon plus ponctuelle, nous intervenons également dans d’autres domaines tels que la sécuritél’audit, les sélections de progiciels ainsi que les schémas directeurs et la rationalisation des systèmes d’information,

Nos prestations en matière de sécurité sont principalement tournées vers la rédaction de procédures, les PCA/ PRA ainsi que les cellules de crises et analyses de risques.

Enfin, nous intervenons dans le domaine de l’intégration de progiciels de façon générale mais avec des compétences plus spécifiques sur la gamme des produits SAGE.

Notre savoir faire est basé sur notre expérience mais pour chacun de ses domaines d’application respectifs il tient bien entendu aussi compte de l’état de l’art en la matière comme par exemple ITIL, l’IEEE 830, SWEBOK, COBIT,…. Les démarches éléborées par AMJ-groupe au fil de son expérience restent avant tout pratiques, opérationnelles et adaptables.

Nos clients sont essentiellement des grands comptes du secteur privé et public avec quelques PME.

Notre indépendance vis à vis des constructeurs et des éditeurs de logiciels ainsi que notre connaissance des organisations, renforcées par notre approche globale des architectures, nous permet d’orienter vos choix vers une meilleure intégration de vos objectifs d’entreprise. Ceci vous permettra de mieux rentabiliser et optimiser vos investissements informatiques, ce qui reste notre préoccupation première.

Audit informatique

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.

Nous intervenons 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.

Les missions pour un audit informatique sont très structurées et reposent à la fois sur des entretiens et des tests. Ces derniers sont particulièrement importants car ce sont eux qui devront systématiquement permettre de justifier les points faibles relevés.

Les missions de diagnostics sont moins formelles que les audits et visent à dégager des axes d’amélioration à la suite d’une analyse de l’existant. Ce type de mission se base essentiellement sur des entretiens individuels et des études de documents.

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.

Retour en haut