31 décembre 2006

Version imprimable

Pour poster un commentaire

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 oeuvre 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 (http://www.itgi.org/, Etats-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 sur une trame jaune clair.

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.

COBIT 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.

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, sont 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é
- évaluer 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 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 la 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é.

II - Acquire and Implement (acheter et mettre en exploitation)

Cette partie couvre les processus concernant la mise en oeuvre des outils informatiques.

Cette partie décrit les sept processus suivants :
- Définir les solutions automatisées
- Acquérir et entretenir les logiciels applicatifs
- Acquérir et entretenir la plate-forme technique
- Permettre l'exploitation et l'utilisation
- Gérer les achats
- Gérer les évolutions
- Installer et recetter les solutions et les changements

1) Définir les solutions automatisées : il s’agit d’équiper les agents opérationnels en outils automatiques et de fournir des indicateurs de contrôle aux managers opérationnels. Pour cela, il faut trouver des solutions faisables et économiques : cela suppose des études de faisabilité.

COBIT ne mentionne pas le besoin d’une réflexion sur le travail des agents opérationnels : elle est pourtant nécessaire pour délimiter le contour de l’automatisation. L’analyse des risques est ici limitée au SI : les risques considérés sont ceux qui concernent la qualité des données, la sécurité, la conformité à la réglementation, et non ceux qui concernent le fonctionnement de l’entreprise : conséquences d’une panne, d’un défaut de mise à jour etc.

Les décisions sont prises par le « business sponsor », personnage qui n’a pas été défini jusque-là mais qui est sans doute le MOAS. Le « business manager » formule des recommandations, sans doute d’agit-il du MOAD (voir « Fonctions dans la maîtrise d’ouvrage »).

Lorsque l’on est au stade « managed and measurable » de la maturité, l’entreprise fait une veille SI ainsi qu'une veille technologique, et elle dispose d’une méthode d’étude et d’évaluation des solutions.

2) Acquérir et entretenir les logiciels applicatifs : il s’agit ici de rédiger les spécifications (générales, détaillées puis techniques), de définir les habilitations et règles de sécurité, d’intégrer les acquisitions sur la plate-forme de l’entreprise, de réaliser ou faire réaliser les logiciels spécifiques, d’assurer le suivi de la réalisation et des modifications des exigences, de mettre en place la gestion de configuration et la maintenance.

Lorsque l’entreprise est immature, ses décisions ne font que répondre aux propositions des fournisseurs. Les projets sont conduits un par un et il en résulte une architecture d’ensemble incohérente. Dans les entreprises plus avancées la maintenance pose encore souvent problème. Les méthodes existent mais comme elles sont trop rigides elles ne sont pas exactement appliquées. Lorsque les entreprises sont mûres, les méthodes sont bien adaptées et bien appliquées.

3) Acquérir et entretenir la plate-forme technique : il s’agit de fournir à l’entreprise une plate-forme matérielle et logicielle convenable en regard des besoins des applications et de l’état de l’art technique. Cette plate-forme doit pouvoir satisfaire les besoins applicatifs connus et elle devra dans le futur satisfaire les besoins que l’on anticipe ; elle doit être convenablement dimensionnée (taille des processeurs et des mémoires, débit des réseaux) et mettre en œuvre des solutions d’architecture bien choisies : bref, il faut qu’elle soit convenable au plan qualitatif comme quantitatif.

Elle doit comporter les outils de contrôle et de sécurité et les responsabilités doivent avoir été définies. Son entretien doit être assuré. Elle doit comporter un environnement pour tester les modifications qui lui sont apportées. Elle doit être équipée d’une gestion de configuration.

Lorsque l’entreprise est immature, les décisions concernant la plate-forme sont prises au coup par coup, et les tests (si l’on peut dire) sont réalisés « à chaud » - c’est-à-dire que l’on découvre les problèmes lors de la mise en œuvre.

4) Permettre l’exploitation et l’utilisation : il s’agit dans ce processus de documenter les applications afin de former les exploitants comme les utilisateurs.

Il faut documenter tous les aspects : technique, opérationnel, niveaux de service.

Tous les aspects, c’est évidemment trop dire puisque toute documentation doit être sélective. La diversité des destinataires de la documentation suppose une segmentation de cette population et une activité éditoriale gérant une dissémination sélective.

COBIT ne considère que le transfert de connaissances relatif au SI, aux applications ; or il convient de considérer aussi le processus de production que le SI outille, et les connaissances doivent porter autant sur l’organisation du travail humain que sur le fonctionnement du SI.

Les applications et les solutions techniques doivent être intégrées sans couture dans les processus de production.

Cette dernière phrase est importante mais elle est énoncée incidemment. Elle implique que les diverses applications soient appelées par l’IHM en fonction des besoins de l’utilisateur, sans que celui-ci ait à se connecter/déconnecter ni à faire des doubles saisies. L’expression « sans couture » suppose ainsi que le Graal du SI ait été atteint : chaque utilisateur dispose sur son écran-clavier, à chaque instant, des données, espaces de saisie et commandes dont il a exactement besoin.

L’entreprise sans maturité en est au stade de la documentation sur papier, peu commode et non à jour. Lorsque la maturité croît, l’entreprise met la documentation sur l’Intranet et la formation est organisée. Si elle s’améliore encore, elle recherche le feedback des utilisateurs et met en place une gestion automatisée de la documentation.

COBIT situe au niveau 5 la mise en œuvre de workflows et la tenue à jour de la documentation : elles devraient être assurées dès le stade « managed and measurable ».

5) Gérer les achats : il s’agit d’équiper le SI d’une direction des achats. Elle y appliquera la politique de l’entreprise en matière d’achats, gèrera les contrats avec les fournisseurs, les droits de propriétés sur le logiciel et contrôlera la qualité des fournitures (développements et infrastructure).

Si l’on progresse dans l’échelle de maturité la DSI commence par gérer les achats au coup par coup, elle se concentre sur les gros achats ; ensuite elle assure une politique d’achats semblable à celle de l’entreprise et elle gère les contrats, enfin elle gère dans la durée la relation avec les fournisseurs.

6) Gérer les évolutions : il ne s’agit pas de la « gestion du changement », qui concernerait aussi l’organisation du travail humain, mais de la gestion des évolutions du SI interne à la DSI. Il s’agit donc de documenter, autoriser, suivre et faire connaître les changements techniques.

Lorsque l’entreprise n’est pas mûre, la gestion de configuration est souvent trop négligée.

7) Installer et recetter les solutions et les changements : ce processus concerne les opérations de recette, d’essai sur site pilote et de déploiement d’un nouveau produit.

Il faut un « plan de test », qui définisse le site de test et le cahier de recette, et un plan de déploiement. L’environnement de test est un atelier qui utilise une génération artificielle de données ou un site pilote utilisant de vraies données. Il faut prévoir la migration des données, l’interfaçage avec les autres outils et l’intégration dans le SI.

Les tests comportent deux étapes, technique et fonctionnelle. Puis il faut procéder au déploiement et à la mise en place. Enfin le nouvel outil doit être soumis à une gestion de configuration. 

III – Deliver and support (produire et gérer le service)

Cette partie couvre les treize processus suivants :
- définir et gérer les niveaux de service
- gérer les services fournis par l’extérieur
- gérer les performances
- assurer la continuité du service
- assurer la sécurité du SI
- identifier et imputer les coûts
- former et entraîner les utilisateurs
- gérer les incidents et le service desk
- gérer la configuration
- gérer les problèmes
- gérer les données
- gérer l’environnement physique
- gérer l’exploitation

Que la partie « deliver and support » soit dans COBIT la plus détaillée, c’est une excellente chose : on a trop tendance, lorsqu’on pense à la qualité d’un SI, à se focaliser sur les projets et à négliger l’exploitation et l’utilisation.

1) définir et gérer les niveaux de service : ce processus concerne la qualité du service rendu aux utilisateurs, les « service level agreements » etc.

Le SLA doit être défini en fonction des exigences et associé à un OLA (« operating level agreement ») qui précise le niveau que doivent atteindre les services techniques en vue de répondre aux SLA (on pense ici au débit des réseaux, à la dimension des mémoires etc.). Le suivi des SLA doit faire apparaître les tendances en cours.

Dans les entreprises immatures, le reporting sur les niveaux de service est souvent incomplet, non pertinent ou fallacieux (on pense ici à ces rapports qui font apparaître le pourcentage de temps CPU disponible mais n’informent pas sur la qualité du service de bout en bout). Lorsque l’entreprise est mûre, la satisfaction des utilisateurs est évaluée périodiquement et les mesures de performance reflètent les besoins des utilisateurs plutôt que les buts propres au SI.

2) gérer les services fournis par l’extérieur : il s’agit ici de documenter les relations avec les fournisseurs, de gérer les risques (engagements de confidentialité, pérennité du fournisseur et du produit, pénalités etc.) et de mettre en œuvre un suivi de la performance des fournisseurs.

Les entreprises immatures ne gèrent pas les fournisseurs, n’introduisent pas d’obligation de reporting dans le contrat etc.

3) gérer les performances : ce processus concerne la physique du SI. Il s’agit de le mettre en mesure de fournir la charge de travail anticipée, de minimiser le risque de blocage, de gérer la pénurie en cas de sous-capacité (prioriser les tâches, tolérance de faute, allocation de ressources). Toute panne doit faire l’objet d’un rapport se concluant par des recommandations.

Dans les entreprises immatures, la mesure des performances considère les besoins du SI et non ceux des utilisateurs.

4) assurer la continuité du service : il s’agit d’assurer une exploitation en continu minimisant le risque de panne sur les fonctions cruciales.

Le service que l’on considère ici est celui qui est rendu de bout en bout à l’utilisateur final : on considère donc l’enchaînement des serveurs, réseaux, applications et postes de travail et non le seul fonctionnement de la CPU. Il faut prévoir une gestion de crise en cas d’incident et des solutions de repli ; il faut identifier les fonctions à restaurer en priorité, les classer selon la durée de panne tolérable ; le dispositif doit faire l’objet de tests périodiques, les personnes qui en sont chargées doivent être formées ; des plans d’action doivent avoir été préparés pour faire face aux diverses situations de crise, un back-up des ressources critiques doit être prévu sur un autre site. Le responsable est le directeur de l’exploitation.

5) assurer la sécurité du SI : on doit trouver à l’intérieur de la DSI une équipe spéciale chargée de la sécurité. Elle met en œuvre un plan de sécurité. Elle définit la gestion des identifications et habilitations, détecte les attaques, documente les incidents, assure le chiffrement, met en œuvre les antivirus, firewalls et autres outils de protection. Elle protège les données sensibles.

6) identifier et imputer les coûts : il s’agit ici d’évaluer le coût du SI et de l’imputer aux utilisateurs. Une fonction de coût du SI doit être établie.

Connaître la fonction de coût du SI suppose (mais COBIT ne le dit pas clairement) que l’on sache relier ce coût au volume des unités d’œuvre qu’il fournit, ce qui implique de savoir définir ces unités d’œuvre.

COBIT dit qu’il faut savoir ventiler « de façon équitable » les dépenses du SI pour les faire porter par les entités utilisatrices, mais il ne mentionne pas les pièges que comporte une telle ventilation. Si en effet certaines des dépenses sont clairement imputables à des services de l’entreprise, d’autres correspondent à une infrastructure que se partagent plusieurs services et la clé de ventilation que l’on utilisera pour en répartir le coût sera toujours arbitraire, donc péniblement négociée et susceptible en outre d’avoir des effets pervers[6].

Il ne suffit donc pas de dire « un processus d’affectation des coûts aux divers services utilisateurs a été défini » : encore faut-il qu’il soit convenable, et qu’il n’entraîne pas d’effet pervers.

Une bonne règle pourrait être de ne faire supporter à chaque service que les coûts qui résultent de ses propres décisions. Cela conduit en pratique à ne lui imputer que les coûts affectables sans ambiguïté ainsi que le coût marginal de l’infrastructure et des services transverses, le coût fixe, lui, devant être imputé à la DG.

7) former et entraîner les utilisateurs : COBIT recommande de distinguer des segments différents dans la population des utilisateurs.

C’est une excellente chose : les divers segments d’utilisateurs n’ont pas les mêmes besoins en information et en formation. Mais COBIT ne dit pas comment on peut réaliser cette segmentation.

Il s’agit de former le personnel en tenant compte des besoins de l’entreprise, de ses valeurs, du contenu du SI (infrastructure et applications), des besoins de compétence et des méthodes de formation (cours magistral, Intranet etc.).

COBIT ne mentionne pas la nécessité d’élucider les processus de l’entreprise (voir élucider) ; il n’évoque pas la contrainte de synchronisme entre le déploiement d’un nouvel outil et la formation, le besoin de piqûres de rappel, les apports de l’Intranet et de la GED en complément du service desk téléphonique.

Dans les entreprises mûres, les managers se forment en même temps que les agents opérationnels.

8) gérer les incidents et le service desk : il s’agit de fournir un dépannage en cas d’incident. Le service desk reçoit les appels téléphoniques et les oriente vers l’équipe compétente. Il assure la traçabilité de la réponse à l’incident.

En cas de difficulté particulière, il enclenche une démarche d’escalade et met en place, s’il le faut, des procédures de contournement. Des statistiques sont produites sur la qualité et le délai de la résolution des incidents.

9) gestion de configuration : il faut établir un référentiel du matériel, du logiciel, des paramètres, de la documentation, comportant des identifiants, des numéros de version, des détails sur les licences etc. Ce référentiel doit être tenu à jour et être utilisé pour prévenir la mise en place de logiciels non autorisés. Une procédure doit être mise en œuvre pour vérifier sur le terrain son exactitude.

10) gestion des problèmes : par « problème », COBIT désigne la cause d’incidents répétés. Traiter un problème, cela suppose donc que l’on ait su remonter des incidents à leur cause, et que l’on sache passer « de l’intervention du pompier à l’amélioration du fonctionnement de l’entreprise » (p. 140).

11) gestion des données : il ne s’agit pas ici de l’administration des données, qui traite de la sémantique, mais de la gestion physique des données : back-up et restauration des données, disponibilité, dispositifs de saisie et traitements, sécurité etc. On considère ici le stockage, l’accessibilité, l’archivage, le back-up et la reprise de service en cas d’incident.

12) gestion de l’environnement physique : il s’agit de la gestion des locaux, des accès (périmètre de sécurité), de l’alimentation électrique et télécoms, des risques sismiques etc.

13) gestion de l’exploitation : on considère ici la chorégraphie des opérateurs, la supervision de la plate-forme, etc. Le passage des consignes d’une équipe à la suivante doit avoir été organisé.

COBIT n’évoque pas les alertes que la supervision peut utilement envoyer aux utilisateurs pour éviter les mauvaises pratiques ou prévenir les incidents : taux d’encombrement des espaces disques, des réseaux etc.

IV – Monitor and evaluate (contrôler et évaluer)

Cette partie considère quatre processus :
- Suivre et évaluer la performance du SI
- Suivre et évaluer le contrôle interne
- Assurer la conformité à la réglementation
- Assurer la gouvernance du SI

1) Suivre et évaluer la performance du SI : il s’agit de définir des indicateurs de performance du SI (coût, rentabilité, niveau de service, alignement stratégique) et d’agir si l’on constate des dérapages.

La liste de ces indicateurs est difficile à établir et COBIT ne formule pas ici de recommandation précise. Il n’aurait pas été mauvais d’indiquer une démarche, par exemple en s’appuyant sur les modèles de maturité que COBIT comporte.

Le modèle de maturité associé à ce processus est assez formel. Comme COBIT se concentre sur l’évaluation interne du SI, il lui aurait sans doute été difficile d’énoncer des critères d’efficacité (comme la qualité du poste de travail, du tableau de bord etc.) concernant le service rendu aux utilisateurs.

2) Suivre et évaluer le contrôle interne : il s’agit de définir un contrôle interne au SI puis de rendre compte de son efficacité. Il est conseillé de se référer aux meilleures pratiques de la profession, de faire des benchmarks, de faire procéder à des audits externes[7], de faire porter le contrôle également sur les fournisseurs, de définir et mettre en œuvre les actions pour remédier aux défauts constatés.

3) Assurer la conformité à la réglementation : le SI doit être conforme à la réglementation notamment dans les domaines du commerce électronique, des échanges de données, de la confidentialité, du contrôle interne, du reporting financier, de la propriété intellectuelle, de l’hygiène et de la sécurité, enfin des régulations spécifiques au secteur d’activité.

La liste ci-dessus peut utilement alimenter une check-list.

Il est conseillé de faire vérifier la conformité par un auditeur externe indépendant et d’évaluer le coût éventuel des non-conformités.

4) Assurer la gouvernance du SI : il s’agit de définir les structures de l’organisation, les processus, les pouvoirs de décision, les rôles et responsabilités de façon à pouvoir s’assurer que le SI est conforme aux priorités et à la stratégie de l’entreprise. Il est conseillé de faire appel à un auditeur externe pour valider cette organisation.

La liste des objectifs détaillés, ainsi que le modèle de maturité, fournissent des indications utiles. L’alignement du SI sur le « business », c’est-à-dire sur les besoins des métiers de l’entreprise, est évidemment mentionné mais COBIT n’insiste pas sur le partage des responsabilités et sur le contenu du dialogue entre maîtrise d’œuvre et maîtrise d’ouvrage.

Il faut que les rôles et responsabilités dans le programme d’investissement et les projets soient définis sans ambiguïté ; le conseil d'administration et le comité de direction doivent partager une vue claire du rôle du SI, des possibilités techniques, de la contribution potentielle du SI à la stratégie de l’entreprise.

Cela implique (mais COBIT ne le dit pas explicitement) que l’entreprise se soit dotée d’un plan d’urbanisme du SI et qu’elle ait accompli, autour de ce plan, l’effort de communication nécessaire vers les décideurs.

Il faut organiser un comité stratégique du SI et encourager la co-responsabilité entre les métiers et la DSI.

C’est tout ce qui est dit dans COBIT sur la relation entre maîtrise d’œuvre et maîtrise d’ouvrage.

Il faut maîtriser l’économie du SI : suivre les produits tout au long de leur cycle de vie, s’assurer a posteriori que les objectifs de rentabilité du SI ont bien été atteints (nouveaux services, gains de productivité, meilleure réponse aux besoins des clients) ; il faut s’assurer que l’on utilise des technologies standard et que l’on respecte les contraintes d’interopérabilité. On doit vérifier que les ressources humaines et la politique d’achat permettent à l’entreprise de disposer des compétences nécessaires.

Suivre les produits au long de leur cycle de vie implique de connaître la dynamique qui relie le coût de maintenance et d’exploitation au coût d’acquisition, mais COBIT ne le dit pas explicitement.

Les risques liés au SI doivent être évalués et pondérés, en prenant en considération leur impact sur l’entreprise.

On doit mesurer la progression de l’entreprise vers les buts qu’elle s’est fixée. Les mesures de performance doivent être présentées et discutées devant le conseil d'administration et le comité de direction. Un comité d’audit indépendant doit assurer la conformité du SI à la politique de l’entreprise.

COBIT insiste, de façon opportune, sur la nécessité de faire remonter la discussion sur le SI aux plus hauts niveaux de décision de l’entreprise.

Dans le modèle de maturité, à l’étape « managed and measurable », on sait qui est l’utilisateur ; les responsabilités sont définies et gérées à travers les SLA, les propriétaires des processus sont identifiés (NB : COBIT ne dit pas ici s’il s’agit des processus de l’entreprise ou de ceux du SI) ; les parties prenantes sont averties des risques et possibilités qu’offre le SI. La gouvernance du SI a été intégrée dans la planification stratégique et opérationnelle, des indicateurs de performance sont disponibles.

Conclusion