COBIT

Il représente un consensus entre experts sur les bonnes pratiques en matière de catégories (planifier, construire, exploiter, contrôler Les premiere et dernière catégories font intervenir les acteurs stratégiques de l’entreprise (directlon 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 é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 « rocessus de production » ou « approche du SI par les processus y), 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). ) Detailed control objectives : liste des fonctions que le processus doit remplir, dé n quelques PAGF OF 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 indlcateurs associés , 4) Maturio,’ model : décrit ce que font des entreprises types classées selon six niveaux de maturité. of 11 Les pages 1 et 2 éclairent le contenu du processus, la page 4 éclaire les priorités.

Dans la page 3 la liste des indlcateurs permet de préciser la compréhension. L’examen des relations entre les processus sera utile lors d’une mse 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 Il est donc composé d’applications informatiques, de procédures manuelles et d’informatlons 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 art contrôler la qualité du produit élaboré lors de ce utre part PAGF 3 OF lors de ce processus, d’autre part contrôler l’efficacité de sa production (que fon peut évaluer en esurant 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. Ily 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. urtant 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. [3] Dans chacun des processus 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 raccountable serait donc le directeur de l’entité qui doit accomplir le processus et le responsible serait, a 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 rè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 (Dsl), le business process awner (maître d’ouvrage), le head operations (directeur de l’exploitation à la Dsl), le Chief architect (directeur de l’architecture à la DSI), le head IT administration (contrôleur de gestion à la OSI), le project management office (direction des études à la DSI), enfin compliance, audit, risk and security (la direction de l’audit e l’entreprise).

Dans les modèles de maturité, le schéma est toujours le même O – 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 : Pentreprise 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é. 0f11 – Géré et mesurable : les responsabilités sont claires, la qualité est sulvie, 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 s PAGF s OF 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 aturité. Les formulations relatives au niveau 5 semblent excessives : rentreprise 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 roptimum) ? A la lecture, les niveaux les plus intéressants sont les niveaux 2 ? 4. ) 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 onvenable. 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 Parchitecture 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 risqu 6 OF 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 ‘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 ohé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 7 OF pertinence des données : il ne 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 popu ations que [‘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 uffisante (et même elle est secondaire par rapport à la pertinence). 3 of 11 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 équllibre, 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. ) 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 com ris les ressources que lui rocurent les fournisseurs relatio PAGF 8 OF (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, finformatique 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 , VAN 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 aî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. II s’agit de faire connaître les objectifs de l’entreprise et du SI On ne voit pas apparaitre 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. ). ) 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. Cest p PAGF q OF 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 la 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 ! Sil est vrai que les expressions de besoin doivent s’appuyer sur une connaissance de rétat de l’art en informatique et tenir compte des contraintes particulières au SI de l’entreprise, l 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 apparaitre 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 n 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’exp