COBIT : origines et description (partie 1)

Les origines de COBIT

Cette étude a été produite par un groupe de travail du club des maîtres d’ouvrage des systèmes d’information. Il s’agit ici d’une version préliminaire, soumise à la validation par les membres du club.
COBIT est le résultat d’un travail approfondi ; il est mis en œuvre par des experts qualifiés. Nous n’avons pas ici la prétention d’en savoir plus qu’eux. Il se peut que certaines de nos remarques leur paraissent infondées : nous sommes prêts à recevoir leurs commentaires.

COBIT est produit par le IT Governance Institute (États-Unis), institut de recherche indépendant créé en 1998 et qui rassemble des universitaires, des consultants et des représentants des entreprises qui utilisent les TIC. On peut télécharger gratuitement le texte de COBIT à partir du site indiqué ci-dessus.

Nous décrivons ici le contenu de COBIT et formulons chemin faisant quelques remarques. Pour que l’on puisse distinguer la description des remarques, ces dernières sont éditées en italique.

COBIT relie les objectifs du SI à ceux de l’entreprise afin d’évaluer la maturité de celle-ci envers son SI: c’est un outil pour les auditeurs. Il représente un consensus entre experts sur les bonnes pratiques en matière de gouvernance du SI et en ce qui concerne les investissements en SI et le service que rend le SI. Il fournit une échelle de mesure qui permet de diagnostiquer d’éventuels dérapages.

Il décrit 34 processus répartis en quatre catégories (planifier, construire, exploiter, contrôler) [1]. Les première et dernière catégories font intervenir les acteurs stratégiques de l’entreprise (direction générale, directeurs), tandis que la seconde et la troisième sont à caractère plus technique et concernent essentiellement la DSI.
Pour chacun de ces 34 processus COBIT indique les ressources nécessaires (applications, informations, infrastructure, ressources humaines) et les indicateurs utiles (tableaux de bord, alertes et benchmark).

La liste des indicateurs est toujours intéressante.

1) Plan du document

Le document commence par une présentation pour dirigeants (Executive Overview), suivi par un schéma de contrôle (Control Framework). Ensuite la plus grande partie du texte est consacrée à la description des 34 processus.

Le mot « processus » est utilisé dans COBIT non pour désigner la succession des activités qui conduit à la fourniture d’un produit (sens qu’a ce mot dans des expressions comme « processus de production » ou « approche du SI par les processus »), mais pour désigner une tâche particulière, une activité.

Chaque processus est décrit selon une présentation en quatre pages :
1) High-Level control objective : définition du processus et description succincte des besoins qu’il satisfait, des moyens qu’il utilise et des indicateurs de contrôle ; les indicateurs sont classés en KPI (Key performance indicators), Process KGI (Process Key goal indicators) et IT KGI (IT Key goal indicators).

2) Detailed control objectives : liste des fonctions que le processus doit remplir, décrites chacune en quelques lignes ;

3) Management guidelines : tableaux indiquant les relations avec d’autres processus, la répartition des responsabilités (selon la liste RACI : Responsible, Accountable, Consulted et Informed), les buts et les indicateurs associés ;

4) Maturity model : décrit ce que font des entreprises types classées selon six niveaux de maturité.
Les pages 1 et 2 éclairent le contenu du processus, la page 4 éclaire les priorités.
Dans la page 3 la liste des indicateurs permet de préciser la compréhension. L’examen des relations entre les processus sera utile lors d’une mise en œuvre.

A la lecture, il apparaît que les pages les plus utiles pour la compréhension d’un processus sont la description résumée des objectifs et le modèle de maturité.

2) Le framework

Les auteurs de COBIT estiment qu’un « schéma de contrôle » (control framework) est nécessaire pour assurer l’alignement stratégique du SI et son adéquation aux besoins et priorités de l’entreprise. Ce schéma décrit les qualités que le SI doit posséder (pertinence, efficacité, confidentialité, intégrité, accessibilité, conformité à la réglementation, exactitude pour la prise de décision).
Le SI doit « permettre d’automatiser les processus de l’entreprise tout en produisant une information sur leur déroulement » [2]. Il est donc composé d’applications informatiques, de procédures manuelles et d’informations prenant la forme de données de toutes natures.

La qualité du SI doit donc être évaluée, en définitive, selon la qualité du processus de production que le SI outille : contrôler un processus, c’est d’une part contrôler la qualité du produit élaboré lors de ce processus, d’autre part contrôler l’efficacité de sa production (que l’on peut évaluer en mesurant son coût). Le SI outille le processus en l’automatisant autant qu’il est nécessaire ; ce faisant, il fournit les informations pour le contrôle du processus.

COBIT s’ingénie cependant, tout en mentionnant l’alignement stratégique parmi les critères de qualité, à définir des critères de qualité intrinsèques au SI en le distinguant du processus de production de l’entreprise.
Il y a là un danger : si la finalité du SI est de fournir la « doublure informationnelle » du processus de production, on ne peut pas évaluer sa qualité séparément de celle de la réalisation de ce processus.
Pourtant COBIT les sépare explicitement : « COBIT assumes the design and implementation of automated application controls (…) The operational management and control responsibility for application control is not with IT, but with de business process owner (…) Therefore, the COBIT processes cover general IT controls, but not application controls, because theses are the responsibility of business process owners and are integrated into business processes » (p. 16).

Dans chacun des processus [3] COBIT identifie quatre rôles qu’il condense dans l’acronyme RACI : Responsible, Accountable, Consulted et Informed.

En anglais, responsible et accountable sont à peu près synonymes ; dans COBIT, celui qui est accountable est celui qui indique les priorités et donne les directives, alors que celui qui est responsible est celui qui fait en sorte que le travail soit effectivement réalisé (p. 15). En français l’accountable serait donc le directeur de l’entité qui doit accomplir le processus et le responsible serait, au sein de cette entité, celui qui exécute le travail que le processus implique. Il n’est cependant pas certain que cette distinction soit très claire dans la suite des documents de COBIT.

COBIT répartit ces quatre rôles entre les personnes suivantes : le CEO (DG de l’entreprise en français), le CFO (directeur financier de l’entreprise), les business executives (directeurs de l’entreprise), le CIO (DSI), le business process owner (maître d’ouvrage), le head operations (directeur de l’exploitation à la DSI), le chief architect (directeur de l’architecture à la DSI), le head IT administration (contrôleur de gestion à la DSI), le project management office (direction des études à la DSI), enfin compliance, audit, risk and security (la direction de l’audit de l’entreprise).

Dans les modèles de maturité, le schéma est toujours le même :
0 – Inexistant : l’entreprise n’est pas consciente du besoin.
1 – Initial / ad hoc : l’entreprise commence à être consciente du besoin mais rien n’existe pour le satisfaire.
2 – Répétitif mais intuitif : l’entreprise traite le besoin au cas par cas, de façon informelle, en s’appuyant sur les compétences de quelques individus.
3 – Défini : les procédures ont été standardisées et documentées mais les responsabilités restent individuelles ; il n’existe ni reporting formel, ni suivi de la qualité.
4 – Géré et mesurable : les responsabilités sont claires, la qualité est suivie, les personnels sont formés, les outils sont automatisés.
5 – Optimisé : l’entreprise est au niveau « géré et mesurable » et en outre elle assure une veille afin de mettre à jour ses méthodes et de se tenir en permanence à la pointe de l’état de l’art.

Des outils qui seraient à leur place au niveau 4, comme les workflows, soient mentionnés au niveau 5.
Dans l’ensemble, le niveau 4 paraît déjà un bon niveau de maturité. Les formulations relatives au niveau 5 semblent excessives : l’entreprise qui fait effort pour atteindre un optimum ne risque-t-elle pas d’adhérer à des méthodes qui lui paraissent excellentes mais de manquer de souplesse (même si la souplesse et l’attention à l’état de l’art sont mentionnées parmi les critères de l’optimum) ?

A la lecture, les niveaux les plus intéressants sont les niveaux 2 à 4.

3) Les processus

I – Plan and Organize (planifier et organiser)

Cette première partie couvre les activités qui doivent être réalisées par l’entreprise si elle souhaite se doter d’un SI convenable. On note cependant que COBIT ne propose pas dès cette première partie la mise en place les entités nécessaires à la gouvernance du SI.
L’accent est mis sur la communication interne, que les entreprises négligent souvent par manque de volonté politique ; la nécessité de disposer des bonnes ressources au bon moment est rappelée avec insistance.

Cette partie décrit les dix processus suivants :
– Définir un plan stratégique pour le SI
– Définir l’architecture en information
– Déterminer l’évolution technique
– Définir les processus et l’organisation du SI
– Gérer les investissements en SI
– Communiquer les buts et orientations de la direction
– Gérer les ressources humaines du SI
– Gérer la qualité
– Evaluer et gérer les risques du SI
– Gérer les projets

1) Le plan stratégique pour le SI doit « améliorer la compréhension des apports et des limites du SI, conforter la performance et mettre en évidence le niveau des investissements requis. La stratégie et les priorités de l’entreprise doivent se refléter dans ce plan dont les étapes doivent être comprises et acceptées à la fois par les personnels de l’informatique et par ceux des métiers » (p. 29, traduction libre). L’exploitation du SI doit faire l’objet de SLA (service level agreements).

La stratégie est concrétisée, au niveau tactique, par des plans de projet et par un portefeuille d’investissements.

Le mot « portefeuille » est ainsi associé à des investissements alors qu’on devrait plutôt l’appliquer à l’actif que représente le SI et dont les projets assurent l’évolution (quand on parle d’un « portefeuille d’actions », on ne considère pas les achats et les ventes mais le stock des actions détenues).

Dans le modèle de maturité on ne trouve pas mention de l’appropriation du plan par l’entreprise. Par ailleurs COBIT n’insiste peut-être pas assez sur la nécessité d’une mise à jour du plan pour l’adapter aux évolutions de l’entreprise, de son environnement et des solutions disponibles.

2) L’architecture en information désigne ce que nous appelons « administration des données » : construire et partager des référentiels de qualité comportant la définition des identifiants, des données et identifiant leur propriétaire.

Les critères de qualité indiqués par COBIT relèvent tous de la cohérence et non de la pertinence des données : il ne s’interroge pas sur la qualité de la définition des données que contient le SI en regard des priorités et besoins de l’entreprise, il ne mentionne pas la démarche qui permet de sélectionner les populations que l’entreprise va observer (clients, fournisseurs, produits etc.), d’identifier les individus appartenant à ces populations, de sélectionner les attributs que l’on observera sur ces individus. Or si la cohérence du référentiel est nécessaire, elle n’est pas suffisante (et même elle est secondaire par rapport à la pertinence).

3) L’évolution technique concerne la définition de la plate-forme informatique. Cela suppose une veille technologique ainsi qu’un dialogue entre la DSI et les métiers utilisateurs.

Il faudra cependant agir différemment selon que l’entreprise est en retard ou non par rapport à l’état de l’art : l’évolution technique n’apparaît pas sous le même jour si l’entreprise est en retard ou en équilibre, si elle appartient à un secteur très évolutif (et où la compétition se définit autour du SI) ou non.

Si elle est en équilibre, c’est-à-dire si elle a trouvé une solution raisonnable (et une solution peut rester « raisonnable » pendant plusieurs années successives) il n’est pas prioritaire de planifier une évolution – toutefois la veille technologique devra rester attentive.

4) Les processus et l’organisation du SI concernent dans COBIT non les processus de production de l’entreprise (business process) mais seulement les processus propres au SI (IT process).
Il s’agit d’organiser et de superviser la DSI, de gérer ses ressources humaines (y compris les ressources que lui procurent les fournisseurs), de gérer ses relations avec les autres métiers de l’entreprise.

Pour assurer sa propre gestion, l’informatique doit donc être elle-même informatisée.

5) Gérer les investissements en SI suppose que l’on sache évaluer leur coût et leur rentabilité : ici arrivent les anticipations en termes de TRI [4], VAN [5] et délai de retour sur l’investissement, ainsi que la vérification de ces anticipations a posteriori.

L’évaluation de la rentabilité du SI suppose une implication de la maîtrise d’ouvrage (seule capable d’évaluer l’effet du SI en termes de chiffre d’affaires, part de marché, productivité etc.) que COBIT ne mentionne pas ici.

6) Communiquer les buts et les orientations de la direction : l’accent est mis sur l’alignement stratégique. Il s’agit de faire connaître les objectifs de l’entreprise et du SI.

On ne voit pas apparaître le besoin d’une visibilité sur le moyen terme (trois à cinq ans). Par ailleurs le contrôle des risques, tel qu’il est mentionné, porte essentiellement sur les risques internes au SI (perte de qualité des données etc.) et non sur les risques que le SI fait courir à l’entreprise (coût d’une interruption du service, etc.).

7) Gestion des ressources humaines du SI : COBIT recommande de réduire la dépendance par rapport à des individus clés qui monopoliseraient les compétences critiques et aussi de limiter le turn-over.
La mise en place d’une politique de ressources humaines est préconisée ; elle doit permettre à l’entreprise de disposer d’équipes compétentes et motivées.

8) Gestion de la qualité : il s’agit encore de la qualité du SI et non de celle des processus de production de l’entreprise. C’est pourquoi rien n’est dit sur pertinence des expressions de besoin (requirements).

Le « customer focus » se réduit à la résolution des conflits entre les utilisateurs et l’informatique et, qui pis est, à « l’alignement des expressions de besoin sur les standards du SI », formulation périlleuse !
S’il est vrai que les expressions de besoin doivent s’appuyer sur une connaissance de l’état de l’art en informatique et tenir compte des contraintes particulières au SI de l’entreprise, il ne convient pas de suggérer que l’informatique puisse « aligner » les expressions de besoin sur ses propres standards : s’il faut « aligner » la forme des expressions de besoin (et les solutions d’architecture retenues pour leur répondre), leur contenu doit correspondre aux besoins des métiers utilisateurs.

9) Évaluer et gérer les risques du SI : ici on voit enfin apparaître les effets du SI sur l’entreprise. Il faut identifier tous les événements qui peuvent avoir des conséquences négatives ou positives sur le fonctionnement de l’entreprise en incluant tous ses aspects : production, réglementation, partenariats, ressources humaines etc. ; il faut préparer la réponse aux incidents, et gérer un plan d’action.

10) Gérer les projets : ce thème est le dernier mentionné sous la rubrique « Plan and Organize ».

C’est là une excellente chose : on a trop tendance, dans les entreprises, à voir dans la « conduite de projet » l’élément essentiel pour la réussite d’un SI.

Le thème comprend d’abord la « gestion du programme », autrement dit la sélection des projets à retenir en s’appuyant sur des études et sur l’explicitation des priorités ; puis la gestion de projet en tant que telle. Il insiste sur l’implication des parties prenantes (stakeholders), sur la prise en compte des interdépendances entre projets divers, sur l’attention qu’il faut accorder aux changements qui surviennent dans la définition du projet (coût, calendrier, contenu et qualité).

Ce processus semble être, dans COBIT, l’un des mieux définis et balisés. Toutefois la gestion du projet s’arrête à la livraison du produit : on ne s’intéresse pas ici à la façon dont le produit sera utilisé.

(1) « Plan and Organize », « Acquire and Implement », « Deliver and Support », « Monitor and Evaluate ».
(2) « The IT organization is a clearly defined set of processes that use people skills and technology infrastructure to run automated business applications while leveraging business information », p.12.
(3) En prenant le mot « processus » au sens qu’utilise COBIT et qu’il faut distinguer de celui qu’il a dans l’expression « processus de production ».
(4) « Taux de rentabilité interne », en anglais ROI « Return on investment ».
(5) « Valeur actuelle nette ».

Lire la seconde partie de l’article

Michel Volle
Source : www.volle.com

COBIT : origines et description (partie 1)