COBIT

Suite du petit tour d’horizon des bonnes pratiques.
Nous allons aujourd’hui nous pencher sur COBIT.

Le but de COBIT est de vérifier si les processus IT mis en place permettent aux métiers et à l’entreprise d’atteindre les objectifs visés (Cf. stratégie de l’entreprise).
Et de choisir les projets à mener en fonction.

Je vous propose la reprise d’un article que j’avais réalisé sur un forum.

La maison des normes

L’AFAI a publié une représentation des normes pour la gestion des systèmes d’information : La maison des normes.

Toutes ces normes reposent sur le socle de la gestion de projet.

La partie production étant le fer de lance du référentiel ITIL, la partie développement et acquisition logiciel celui de CMMI alors que COBIT est lié à la gouvernance des systèmes d’information.
Le tout dans le respect des normes sécuritaires (ISO 13335, 15408, 17799, 27001-6).

Tous ces référentiels ne sont pas compartimentés exclusivement à leur domaine (Cobit et Itil font allusion à l’acquisition logiciel qui est le coeur de CMMI par ex.). 


Forcement, du point de vue système d’information, il y a des points imparables et donc des similitudes entre référentiels : la sécurité des données pour n’en citer qu’un.

C’est d’autant plus vrai depuis ITIL V3, qui a l’air de vouloir étendre son périmètre. 

Il faut dire que l’OGC (fondateurs d’ITIL) semble vouloir s’accaparer le périmètre des autres référentiels (ITIL étendu à certains points de la gouvernance ou même à la gestion de projet avec Prince2). 

Itil V3 est d’ailleurs assez critiqué sur la qualité des points liés à la gouvernance par ex.

Reprenons simplement quelques bases pour replacer COBIT dans son contexte.

A quoi sert un système d’information ?

Un système d’information (SI) est l’ensemble des moyens et des ressources informatiques dont dispose une entreprise pour recueillir, traiter, stocker et diffuser les données nécessaires à son activité. 

(Larousse) 
 


La raison d’être d’un SI est donc l’activité de l’entreprise. 

Encore faut il que le système mis en place corresponde aux besoins de celle-ci. 


Pour vérifier, voir mettre en œuvre, l’alignement du SI sur les besoins et la stratégie de l’entreprise, nous disposons d’outils.

Un outil, dans quel but ?

Lorsque l’on veut transporter 20 personnes d’un point A à un point B, il va de soit qu’un car est plus adapté qu’un coupé cabriolet. 
 


Donc tout est assez simple : 

- La stratégie : utiliser un véhicule motorisé, 

- Le choix technologique: un car pouvant accueillir 20 personnes, 

- La mise en place du choix : louer un car avec chauffeur, 

- Les modes de contrôles : vérifier l’accréditation du loueur, vérifier que tout le monde est au départ et à l’arrivée (par ex.). 
 


Cela ne va pas de soit dans une organisation voulant mettre en place un SI, surtout lorsque le contexte est évolutif (concurrence, développement…). 
 

- Comment choisir le SI le mieux adapté à l’organisation ? 

- Comment mettre en place ce SI ? 

- Comment vérifier que ce qu’on a mis en place correspond à ce qui était attendu ? 

- Comment vérifier périodiquement que le SI correspond toujours aux besoins, puisqu’au fil de l’eau l’organisation évolue ? 



Jusqu’à encore récemment, un SI était un jeu de construction dont les briques étaient empilées les unes sur les autres en fonction des demandes. 

Au final, un joli patchwork informatique couteux et pas forcement efficace. 


Voilà pourquoi des outils ont été mis en place, afin de nous aider face à ces questionnements. 
 


Je vais donc vous présenter Cobit (pour Contrôle Objectives for Information and related Technology) développé par l’ISACA est dont le but est de fournir aux gestionnaires, auditeurs et utilisateurs de TIC, des indicateurs, des processus et des meilleures pratiques pour les aider à maximiser les avantages issus du recours aux technologies de l’information et à l’élaboration de la gouvernance et du contrôle d’une entreprise.

Pourquoi Cobit ?

Je vais vous présenter la valeur de COBIT au travers d’un exemple.

Je suis arrivé dans un service où aucune documentation, procédure, suivi/indicateurs étaient en place. 

Cerise sur le gâteau, mon prédécesseur est parti en supprimant son répertoire de travail, vidant ses tiroirs et en ne laissant aucune consigne à ses futurs ex-collaborateurs.

Il m’a juste laissé un système d’information bancale, puisque tout le monde s’en plaignait.

Tous étaient insatisfaits, mais incapables de dire pourquoi en dehors de « ça marche pas ou très mal».

Un audit Cobit plus tard (2 jours de travail), le « ça marche pas/très mal » était scoré selon les processus Cobit : 
Les points forts et points faibles ressortaient sur les rapports d’analyse. 


Nous étions en mesure de voir ce qu’il fallait travailler pour améliorer le SI.

Voici l’intérêt de Cobit : avoir une photographie du système d’information existant afin de voir les points à travailler en fonction de la stratégie de l’entreprise. 
 


L’audit Cobit 


Je me base sur la version 4.1 de COBIT.

La version 5 ayant intégré d’autres domaines (Val IT et Risk IT), l’approche de COBIT aurait été plus complexe.

Attention : contrairement à d’autres référentiels (comme ITIL), COBIT dit quoi faire mais pas comment.

Les processus COBIT (V4.1), au nombre de 34, sont regroupés en 4 étapes successives décomposant tout système d’information comme suit : 
 


Planification et Organisation (PO) 
Contient 11 processus. 
Dans ce domaine nous cherchons à savoir comment utiliser les technologies afin que l’entreprise atteigne ses objectifs.

Acquisition et Installation (AI ou AMP) 
Contient 6 processus 
Ici CobiT cherche à définir, acquérir et mettre en œuvre des technologies en les alignant avec les processus métiers de l’entreprise. 


Distribution et Support (DS) 
Contient 13 processus 
L’objectif est de garantir l’efficacité et l’efficience des systèmes technologiques en action. 


Monitoring (M) 
Contient 4 processus 
Il convient ici de vérifier si la solution mise en place soit en adéquation avec les besoins de l’entreprise dans une vision stratégique. 


Il convient donc de mettre en place un questionnaire couvrant le champ des 34 processus Cobit afin de réaliser la photographie de son système d’information. 
 


Pour chaque groupe de processus, le choix de l’interviewé est primordiale.
La pertinence sur le choix de l’acteur rendra votre audit d’autant plus près de la réalité. 
 


Le Questionnaire

Voici un exemple de questions pour le processus DS4( Assurer la continuité du service : plan de secours) 
 

- Avez-vous établi quelque chose qui défini les rôles, les responsabilités, la méthodologie de gestion des risques à adopter, les règles et les structures pour documenter le plan de secours ? 

- Avez-vous un guide d’utilisation du plan de secours ? 

- Avez-vous un moyen de revenir en arrière si vous avez rencontré un incident grave dans votre SI ? (Recharger une image par exemple) 

- Avez-vous des procédures pour sauvegarder et reconstruire tout ou partie du SI ? 

- Avez-vous des procédures de contrôle de changement afin de s’assurer de la mise à jour du plan de secours ? 

- Afin d’avoir un plan de secours efficace, avez-vous des procédures de tests de ce plan ? 

- Réalisez-vous des entrainements réguliers en suivant les procédures définies afin de lutter efficacement contre des incidents ou des désastres ? 


La liste de questions n’est pas exhaustive. Mon questionnaire de base, par ex, contient environ 300 questions. 
 


Pour chaque réponse, vous octroyez une note comme suit : 
 

- Non applicable ou non géré par la partie interviewer : 0 point 

- Rien est définit sur le point abordé (non applicable) : 0 point 

- Quelques allusions mais rien de formalisé : 0.3 point
- La demande est formalisée mais non assimilé/maitrisé : 0.7 point 

- La demande est formalisée et assimilée par les acteurs : 1 point 
 


Vous obtiendrez ce genre de résultat : 


Ce graphe radar (qui est une comparaison entre 2 audits sur le même SI) permet d’avoir une vue d’ensemble de votre Système d’Information tel que COBIT le conçoit. 
 



Ici, on peut (par ex) en priorité travailler les processus DS5 et DS11 qui sont des processus dédiés à la stratégie de sécurité et à la protection des données. 


Je vous le rappelle encore une fois, Cobit dit quoi faire (ici travailler sur les processus faibles) mais pas comment. 
 


C’est donc à vous, à partir de cette analyse, de votre contexte et des choix technologiques et organisationnelles de mettre en oeuvre le changement.