COBIT 2019 gouvernance informatique : objectifs et capacité

COBIT 2019 gouvernance informatique : objectifs et capacité

COBIT 2019 est le référentiel de gouvernance de l’information et des technologies publié par l’ISACA. Il sert à répondre à une question que ni un catalogue de contrôles ni un manuel d’exploitation ne traitent : qui, au sommet, décide de ce que l’informatique doit produire, et comment ce sommet vérifie qu’il l’obtient. La page détaille ses objectifs, la façon de le tailler et la manière de mesurer sa capacité, avec le compromis qui va avec.

Explication de la marmotte

Dans un club de foot, le président ne tape pas dans le ballon : il fixe ce que le club doit gagner, choisit l’entraîneur et regarde les résultats. L’entraîneur, lui, organise les séances. Ce référentiel, c’est le règlement qui dit qui décide quoi dans l’informatique d’une entreprise, pour que personne ne joue sans savoir pour quel but.

→ Lire l’explication complète de la marmotte

COBIT 2019, ISACA et la séparation entre gouvernance et gestion

COBIT signifie Control Objectives for Information and Related Technologies. L’édition en vigueur est COBIT 2019, publiée par l’ISACA (association internationale d’audit et de contrôle des systèmes d’information, connue aujourd’hui sous son seul sigle) à partir de fin 2018. Elle succède à COBIT 5 (2012). Le corpus de base tient en quatre ouvrages : Introduction and Methodology, Governance and Management Objectives, Design Guide et Implementation Guide. Les deux derniers constituent la vraie nouveauté par rapport à COBIT 5 ; les deux premiers en sont, pour l’essentiel, une réorganisation.

Le principe structurant reste celui hérité de l’ISO/IEC 38500 : la gouvernance évalue, oriente et surveille (Evaluate, Direct and Monitor, d’où le domaine EDM) ; la gestion planifie, construit, exécute et contrôle. La direction générale et le conseil d’administration sont responsables de la gouvernance. La DSI (direction des systèmes d’information) et les métiers sont responsables de la gestion. Le schéma montre la boucle : la gouvernance n’exécute rien, elle fixe une direction et lit un retour.

Cette séparation fixe la frontière avec les référentiels voisins.

• Face à ITIL (Information Technology Infrastructure Library) : COBIT dit quoi obtenir et pourquoi, il fait rendre des comptes. ITIL dit comment opérer les services au quotidien, de la gestion des incidents au catalogue de services. Un objectif COBIT comme DSS02 (demandes de service et incidents) s’outille très bien avec les pratiques ITIL ; l’inverse ne marche pas, car ITIL ne donne pas au conseil d’administration de quoi arbitrer un budget. Le détail opérationnel est traité dans ITIL et la gestion des services numériques. Et qui veut un certificat de gestion des services à montrer à un client le cherchera en vain chez l’un comme chez l’autre : il est dans ISO/IEC 20000-1.
• Face à ISO/IEC 27001 : 27001 définit un SMSI (système de management de la sécurité de l’information) certifiable sur un périmètre déclaré. COBIT couvre toute la gouvernance du SI (système d’information), sécurité comprise, et ne se certifie pas au niveau d’une organisation. Les deux se recoupent sur les contrôles (APO13 et DSS05 recouvrent une bonne part de l’annexe A) sans répondre à la même question : 27001 prouve qu’un périmètre est géré selon une norme, COBIT montre que la direction a choisi ce périmètre en connaissance de cause. Les limites de la certification sont détaillées dans ce que garantit une certification ISO 27001.

Vingt ans de référentiels apprennent qu’une organisation qui adopte les trois en même temps, sans dire lequel commande les deux autres, obtient trois classeurs et aucune décision.

Les 40 objectifs de gouvernance et de gestion de COBIT 2019

COBIT 2019 compte 40 objectifs, répartis en cinq domaines. Le nombre a baissé par rapport à COBIT 5 (37 processus, plus trois objectifs ajoutés, notamment sur les données, les projets et l’assurance), mais la granularité a gagné en cohérence.

Domaine	Rôle	Objectifs	Exemples notables pour la sécurité
EDM (Evaluate, Direct and Monitor)	Gouvernance	5	EDM03 optimisation du risque, EDM05 engagement des parties prenantes
APO (Align, Plan and Organize)	Gestion	14	APO10 fournisseurs, APO12 risque, APO13 sécurité, APO14 données
BAI (Build, Acquire and Implement)	Gestion	11	BAI06 changements, BAI09 actifs, BAI10 configuration
DSS (Deliver, Service and Support)	Gestion	6	DSS04 continuité, DSS05 services de sécurité
MEA (Monitor, Evaluate and Assess)	Gestion	4	MEA03 conformité aux exigences externes, MEA04 assurance

Un objectif n’est pas un processus. COBIT 2019 décrit chacun selon sept composants : processus ; structures organisationnelles ; principes, politiques et procédures ; information ; culture, éthique et comportement ; personnes, compétences et aptitudes ; services, infrastructures et applications. Le piège classique consiste à n’outiller que le composant « processus », parce qu’il se documente dans un wiki. APO13 réduit à une procédure, sans structure qui l’arbitre ni compétence qui l’exécute, produit une politique de sécurité impeccable que personne n’a le mandat d’appliquer.

Deux couples demandent une attention particulière. APO13 (gérer la sécurité) pilote le système de management ; DSS05 (gérer les services de sécurité) opère les protections (antimalware, contrôle d’accès, supervision). Confondre les deux revient à confier la stratégie au SOC (Security Operations Center) ou l’exploitation au comité de direction ; dans les deux cas, l’un des deux est mal servi. Même logique pour APO12 (risque côté gestion) et EDM03 (appétence au risque fixée par la gouvernance) : sans EDM03, l’analyse de risque n’a aucun seuil pour décider de ce qui est acceptable, ce que la méthode EBIOS RM ne fournit pas non plus.

Cascade des objectifs : des parties prenantes aux objectifs COBIT

COBIT relie les attentes de la direction aux objectifs par une cascade à quatre étages. Elle sert à justifier chaque objectif retenu par un besoin nommé, et donc à écarter ceux qui ne servent personne.

On lit la chaîne de haut en bas pour concevoir, de bas en haut pour rendre compte. I&T désigne l’information et les technologies, terme que COBIT 2019 préfère à « informatique ». Les treize objectifs d’entreprise (par exemple EG03, conformité aux lois et réglementations externes) et les treize objectifs d’alignement (par exemple AG02, gestion du risque lié à l’I&T) sont génériques : la valeur vient des tables de correspondance fournies par l’ISACA, qui indiquent quels objectifs COBIT contribuent à quels objectifs d’alignement. Un indicateur qui ne remonte à aucun étage de la cascade est décoratif ; les critères pour le reconnaître sont exposés dans mesurer la sécurité : indicateurs utiles ou de façade.

Facteurs de conception : tailler le système de gouvernance

C’est l’apport majeur de COBIT 2019. COBIT 5 livrait 37 processus et laissait l’organisation se débrouiller ; COBIT 2019 fournit onze facteurs de conception (design factors) qui pondèrent l’importance de chaque objectif :

1. stratégie d’entreprise (croissance, innovation, coûts, stabilité) ;
2. objectifs d’entreprise ;
3. profil de risque ;
4. problèmes liés à l’I&T déjà constatés ;
5. paysage de menaces ;
6. exigences de conformité ;
7. rôle de l’informatique (support, usine, tournant, stratégique) ;
8. modèle d’approvisionnement (interne, externalisé, cloud, hybride) ;
9. méthodes de mise en œuvre (agile, DevOps, cycle en V) ;
10. stratégie d’adoption technologique (pionnier, suiveur, retardataire) ;
11. taille de l’entreprise.

Le Design Guide propose un déroulé en quatre étapes : comprendre le contexte et la stratégie (facteurs 1 à 4), déterminer le périmètre initial, l’affiner avec les facteurs 5 à 11, conclure en résolvant les conflits entre priorités. Le classeur d’outillage (design toolkit) distribué par l’ISACA calcule un score d’importance par objectif et propose un niveau de capacité cible.

Le compromis central de COBIT se joue ici. On gagne une couverture exhaustive, traçable jusqu’au conseil d’administration, défendable devant un auditeur ou un régulateur. On paie en effort documentaire, en évaluations récurrentes et en risque de bureaucratie. La position recommandée : tailler sévèrement. Retenir une douzaine d’objectifs prioritaires sur 40, fixer des cibles hautes sur ceux-là seulement, et laisser les autres au niveau minimal déclaré. Un système de gouvernance qui vise 40 objectifs au niveau 4 est un projet de transformation de trois ans dont le livrable principal est un rapport d’avancement.

Le facteur 6 (conformité) mérite une remarque. Pour une entité soumise à NIS2 ou à DORA (Digital Operational Resilience Act), il tire mécaniquement vers le haut EDM03, APO12, APO13, DSS04, DSS05 et MEA03. COBIT n’est cité ni par l’un ni par l’autre texte, mais ces deux règlements imposent une responsabilité de l’organe de direction que la structure EDM rend démontrable.

Niveaux de capacité et de maturité dans COBIT 2019

COBIT 2019 abandonne le modèle d’évaluation de COBIT 5 fondé sur l’ISO/IEC 15504 et adopte une échelle inspirée du CMMI (Capability Maturity Model Integration), modèle que l’ISACA détient depuis le rachat du CMMI Institute. L’échelle va de 0 à 5.

Niveau	Signification
0	Absence de capacité de base, approche incomplète
1	Activités réalisées de façon partielle ou non organisée
2	Activités de base réalisées, le but du processus est atteint
3	Activités définies, complètes et documentées à l’échelle de l’organisation
4	Performance mesurée quantitativement
5	Amélioration continue fondée sur la mesure

Chaque activité d’un processus COBIT est rattachée à un niveau, de 2 à 5. Évaluer un processus revient à noter chaque activité selon quatre degrés : entièrement, largement, partiellement ou non atteinte. Un niveau ne compte que si les niveaux inférieurs sont acquis. Le terme capacité s’applique à un processus ; le terme maturité s’applique à un domaine de focalisation (focus area) ou à un ensemble d’objectifs. Confondre les deux dans un rapport au comité de direction est l’erreur la plus fréquente, et la plus coûteuse en crédibilité devant un auditeur.

Position tranchée sur les cibles : le niveau 3 suffit pour la plupart des objectifs retenus. Le niveau 4 ne se justifie que là où une mesure quantitative change une décision (continuité DSS04, gestion des incidents DSS02, risque APO12 sous une réglementation qui exige des tests). Le niveau 5 ne se vise nulle part par défaut : il suppose un cycle d’amélioration piloté par des données fiables, que peu d’organisations produisent sur plus d’un ou deux processus. Annoncer un niveau 5 sur la sécurité est surtout un excellent moyen d’inviter l’auditeur à demander les données.

Prérequis de mise en œuvre de COBIT

Avant le premier atelier, quatre éléments doivent exister.

• Un mandat de l’organe de direction. Sans commanditaire au niveau EDM, COBIT redevient un référentiel de gestion porté par la DSI, ce qui annule sa raison d’être.
• Un inventaire des processus et des responsabilités existants, avec une matrice RACI (Responsible, Accountable, Consulted, Informed). COBIT fournit des matrices génériques par objectif ; les plaquer sans confrontation au réel produit des responsables qui découvrent leur rôle en lisant le rapport.
• Un registre des risques et un recensement des obligations réglementaires, qui alimentent les facteurs 3 et 6. Sans eux, le classeur d’outillage calcule des priorités sur des intuitions.
• Les publications ISACA et des praticiens formés. Le corpus est diffusé par l’ISACA, en partie payant pour les non-membres. Les certifications individuelles (COBIT Foundation, COBIT Design and Implementation) certifient des personnes, jamais une organisation.

Côté outillage, un tableur suffit au démarrage. Une plateforme GRC (gouvernance, risque et conformité) devient nécessaire quand les preuves d’évaluation doivent être horodatées, versionnées et rattachées aux activités, ce qui arrive dès qu’un régulateur entre dans la boucle.

Surface d’attaque d’un système de gouvernance COBIT

Un référentiel de gouvernance ne se fait pas pirater, il se fait contourner. Les modes de défaillance connus ont chacun leur contre-mesure.

• Autoévaluation complaisante. Le propriétaire du processus évalue son propre processus et trouve, ô surprise, qu’il fonctionne. Contre-mesure : évaluation par une fonction indépendante (MEA04, assurance) ou par l’audit interne, sur preuves.
• Preuves fabriquées pour l’évaluation. Une procédure rédigée la veille de la revue atteste du niveau 3 sur le papier. Contre-mesure : exiger des preuves d’exécution datées (tickets, journaux, comptes rendus) plutôt que des documents de définition, selon la logique décrite dans la preuve de conformité qu’un auditeur vérifie.
• Périmètre taillé pour éviter les sujets gênants. Les facteurs de conception servent à écarter un objectif mal maîtrisé plutôt qu’un objectif inutile. Contre-mesure : documenter, pour chaque objectif écarté, le facteur qui justifie l’exclusion et le faire valider en EDM.
• Angle mort des tiers. Le facteur 8 (approvisionnement) est sous-pondéré et APO10 reste au niveau 1 alors que l’essentiel de l’exploitation est externalisé. Contre-mesure : relier APO10 aux risques de la chaîne d’approvisionnement et aux clauses contractuelles d’audit.
• Dérive entre conception et réalité. Le système conçu en début de cycle ne reflète plus l’organisation après une fusion, une migration cloud ou un changement de méthode. Contre-mesure : réévaluer les facteurs de conception à chaque changement structurel, pas seulement à date anniversaire.

Ce que COBIT 2019 ne garantit pas

COBIT ne garantit aucun niveau de sécurité technique. Un APO13 au niveau 3 atteste qu’un système de management de la sécurité est défini et exécuté ; il ne dit rien de la robustesse d’un chiffrement, de la configuration d’un annuaire ou de la segmentation réseau. La preuve technique vient des tests d’intrusion, des audits de configuration et de la supervision.

COBIT ne vaut pas conformité réglementaire. Il structure la démonstration ; les exigences elles-mêmes se lisent dans les textes (NIS2, DORA, RGPD). Il ne fournit pas non plus de certification d’organisation : celui qui a besoin d’un certificat opposable à un client passe par ISO/IEC 27001. Enfin, il ne remplace pas une méthode d’analyse de risque : APO12 exige qu’une méthode existe, il n’en impose aucune.

Conditions d’exploitation : faire vivre le système de gouvernance

Un système COBIT se périme comme une clé : sans rotation, il finit par protéger une situation qui n’existe plus.

• Cycle de réévaluation. Le Implementation Guide décrit un cycle en sept phases, de l’identification des moteurs du changement jusqu’au maintien de la dynamique. En pratique, une évaluation de capacité annuelle sur les objectifs prioritaires, et une révision des facteurs de conception à chaque changement de stratégie, de modèle d’approvisionnement ou de cadre réglementaire.
• Rotation des évaluateurs. Le même évaluateur sur le même processus plusieurs années de suite finit par évaluer ses propres recommandations. Faire tourner, ou croiser avec l’audit interne.
• Supervision. MEA01 (performance) et MEA03 (conformité externe) sont les objectifs de supervision ; ils doivent produire un tableau de bord lu en comité, avec des écarts et des décisions, pas seulement des scores.
• Conservation des preuves. Les preuves d’évaluation (grilles, éléments probants, décisions EDM) se versionnent et se sauvegardent comme n’importe quelle donnée de conformité. Un régulateur qui demande la justification d’une priorité fixée deux ans plus tôt ne se satisfait pas d’un fichier écrasé par la version suivante.
• Coût récurrent. Le budget ne s’arrête pas à la conception : il inclut les évaluations, la formation des propriétaires de processus et l’outillage. Le calcul complet relève du coût total de possession d’un contrôle.

Exemple : d’un facteur de conception à un niveau de capacité cible

L’exemple montre la logique de décision pour un objectif, APO10 (gérer les fournisseurs), dans une organisation dont l’exploitation est majoritairement externalisée et soumise à une réglementation sectorielle sur les tiers.

Trois facteurs convergent vers une importance élevée. La bifurcation porte sur une seule question : la mesure quantitative change-t-elle une décision ? Si la réglementation exige un suivi chiffré des prestataires critiques (taux de conformité contractuelle, résultats de tests de continuité), le niveau 4 se justifie. Sinon, le niveau 3 (activités définies et documentées, contrats revus, registre tenu) suffit, et l’effort économisé va sur un autre objectif prioritaire. La dernière flèche est la seule qui compte en gouvernance : un écart remonte à l’organe de direction, qui arbitre. Un écart qui reste dans le service qui le constate n’est pas de la gouvernance, c’est un constat.

🐝 Ce qui arrive si on s’en passe

Sans séparation entre gouvernance et gestion, la DSI fixe elle-même ses priorités et rend compte à elle-même : l’organe de direction ne peut plus démontrer qu’il a fixé une appétence au risque, ce que NIS2 et DORA lui imputent pourtant. Sans facteurs de conception, l’effort se disperse sur tous les objectifs à la fois et les plus exposés (fournisseurs, continuité) restent au niveau déclaratif. Sans échelle de capacité commune, deux évaluations successives ne se comparent pas : la dégradation d’un processus passe inaperçue jusqu’à l’incident. Sans évaluation indépendante, les écarts ne remontent jamais au niveau qui détient le budget pour les corriger.

Sources

• COBIT 2019 Framework: Introduction and Methodology, ISACA.
• COBIT 2019 Framework: Governance and Management Objectives, ISACA.
• COBIT 2019 Design Guide, ISACA.
• COBIT 2019 Implementation Guide, ISACA.
• ISO/IEC 38500, ISO/IEC.
• ISO/IEC 27001, ISO/IEC.
• ISO/IEC 15504, ISO/IEC.

🦫 Explication de la marmotte 🍫

Dans une entreprise, l’informatique coûte cher et peut tout bloquer si elle tombe en panne. Ce référentiel, écrit par une association internationale d’auditeurs, organise la façon de la piloter. Il sépare deux étages. En haut, la direction : elle décide ce que l’informatique doit apporter, quel risque elle accepte, et elle vérifie les résultats. En bas, les équipes : elles planifient, construisent, font tourner et contrôlent. Le référentiel liste quarante objectifs, cinq pour la direction et trente-cinq pour les équipes, par exemple gérer la sécurité, gérer les fournisseurs ou assurer la continuité quand tout tombe. Comme personne n’a le temps de tout faire, on choisit avec onze critères : la stratégie de l’entreprise, ses risques, les lois qui s’appliquent à elle, sa taille, le fait qu’elle sous-traite ou non. Ces critères donnent une note d’importance à chaque objectif. Ensuite, on fixe pour chacun un niveau à atteindre, de 0 (rien n’est fait) à 5 (on s’améliore en continu grâce à des mesures). Un évaluateur indépendant vérifie avec des preuves datées si chaque tâche est faite entièrement, largement, partiellement ou pas du tout. Si le niveau atteint est trop bas, l’écart remonte à la direction, qui décide quoi corriger et avec quel budget. Quand ça rate, c’est souvent parce que quelqu’un s’est noté lui-même, que des documents ont été écrits juste pour l’examen, ou que l’entreprise a changé sans qu’on refasse les choix de départ.

À lire aussi

• IT4IT 3.0 : flux de valeur et modèle de données de la DSIComprendre IT4IT 3.0, le modèle opérationnel du numérique de The Open Group, avec ses sept flux de valeur autour du produit numérique, son modèle de référence fonctionnel et son modèle de données.
• AWS Well-Architected Framework : piliers, revue et limitesCe que l'AWS Well-Architected Framework exige vraiment, ses six piliers, la revue outillée, ses angles morts sécurité et ce qui se transpose hors AWS.
• TOGAF et méthode ADM : architecture d'entreprise en pratiqueTOGAF appliqué à l'architecture d'entreprise, avec la méthode ADM, les vues métier, données, applications et technologie, les feuilles de route de transition et la gouvernance d'architecture.
• FinOps Framework : responsabilité partagée des dépenses cloud et IACe que le FinOps Framework de la FinOps Foundation demande vraiment pour répartir la responsabilité des dépenses cloud, SaaS et IA entre métier, finance et ingénierie, ce qu'il coûte à tenir et ce qu'il change pour la sécurité et l'architecture.

Pages voisines

La citent

• AWS Well-Architected Framework : piliers, revue et limites
• IT4IT 3.0 : flux de valeur et modèle de données de la DSI
• Microsoft Cloud Adoption Framework : phases, landing zones, limites
• TOGAF et méthode ADM : architecture d'entreprise en pratique
• CIS Benchmarks et CIS Controls en production

COBIT 2019 gouvernance informatique : objectifs et capacité

Elle cite

• ⇄Lien dans les deux sens :ISO/IEC 20000-1 : exigences et portée réelle de la certification
• ⇄Lien dans les deux sens :ITIL : incidents, changements et problèmes vus de la sécurité
• Calculer le coût total de possession d'un contrôle de sécurité
• Ce qu’un auditeur vérifie dans les preuves de conformité
• Gérer les risques tiers et la chaîne logicielle
• Quels indicateurs mesurer pour la sécurité
• Test d'intrusion : commander, cadrer et exploiter un pentest

⇄ : les deux pages se citent l’une l’autre.