Gouvernance IT¶

La gouvernance IT est l'art de prendre les bonnes décisions sans paralyser la delivery.

Pourquoi la gouvernance IT existe¶

Sans gouvernance, chaque équipe prend ses décisions localement. Le résultat est prévisible : architectures divergentes, risques non maîtrise, portefeuille projets incoheren, investissements redondants, et une direction générale incapable de comprendre ce que fait l'IT ni d'en piloter la valeur.

La gouvernance IT est le système par lequel les décisions sont prises, par qui, selon quelles règles, avec quelle traçabilite. Ce n'est pas de la bureaucratie — c'est le mécanisme qui permet à une organisation d'agir de manière cohérente sur son capital technologique.

Le DSI est le premier responsable de ce système. Il ne prend pas toutes les décisions — il conçoit le cadre dans lequel elles sont prises correctement par les bonnes personnes au bon niveau.

COBIT : le référentiel de gouvernance IT¶

COBIT (Control Objectives for Information and Related Technologies) est le référentiel le plus complet pour la gouvernance et le management de l'IT. Publie par l'ISACA, il est à la gouvernance IT ce qu'ITIL est à la gestion des services.

Les 5 principes fondateurs de COBIT 2019¶

1. Répondre aux besoins des parties prenantes — L'IT existe pour créer de la valeur. Chaque décision doit pouvoir se justifier par son impact sur les parties prenantes : actionnaires, clients, employes, regulateurs. La gouvernance traduit ces besoins en objectifs IT mesurables.

2. Couvrir l'entreprise de bout en bout — La gouvernance IT ne se limite pas au département IT. Elle couvre tous les processus qui touchent l'information et la technologie, y compris ceux pilotes par les métiers.

3. Appliquer un référentiel unique et intégré — COBIT s'intégré avec les autres standards (ISO 27001, ITIL, PMBOK, TOGAF) plutôt que de les remplacer. Il fournit le cadre de gouvernance, les autres apportent les pratiques opérationnelles.

4. Permettre une approche holistique — La gouvernance ne peut pas se réduire a des processus isoles. COBIT identifié sept "enablers" interdependants : principes/politiques/cadres, processus, structures organisationnelles, culture/ethique/comportement, information, services/infrastructure/applications, personnes/compétences.

5. Distinguer gouvernance et management — La gouvernance (EDM : Evaluate, Direct, Monitor) est du ressort du Conseil d'administration et du COMEX. Le management (APO, BAI, DSS, MEA) est du ressort du DSI et de ses équipes. Cette distinction est fondamentale et souvent bafouee dans les organisations.

Vue d'ensemble des 40 processus COBIT¶

COBIT organisé ses processus en cinq domaines :

Les processus les plus critiques pour un DSI :

• APO02 — Gestion de la stratégie IT
• APO06 — Gestion des budgets IT
• APO12 — Gestion des risques
• BAI01 — Gestion du portefeuille programmes
• BAI06 — Gestion des changements
• DSS01 — Gestion des opérations
• MEA01 — Suivi de la performance

La cascade d'objectifs COBIT¶

COBIT propose une cascade qui relie les objectifs de gouvernance des parties prenantes jusqu'aux objectifs opérationnels IT :

flowchart TD
    A["Besoins\ndes parties prenantes\n(actionnaires, clients, regulateurs)"]
    B["Objectifs d'entreprise\n(croissance, conformite, qualite)"]
    C["Objectifs d'alignement\n(valeur IT, risque IT, transparence)"]
    D["Objectifs de gouvernance\nCOBIT (EDM)"]
    E["Objectifs de management\nCOBIT (APO/BAI/DSS/MEA)"]

    A --> B --> C --> D --> E

Cette cascade evite le piege classique : des objectifs IT définis par l'IT pour l'IT, deconnectes des enjeux business. Chaque objectif IT doit pouvoir se lire comme la contribution a un objectif métier explicite.

Métriques COBIT : piloter par les bons indicateurs¶

COBIT distingue deux types de métriques :

• Lag indicators (métriques de résultat) : ce qui s'est passe. Taux de disponibilité, nombre d'incidents, ROI des projets.
• Lead indicators (métriques predictives) : ce qui va se passer. Couverture des tests, dette technique, taux de changements réussis.

Les DSI mesurent souvent trop de lag indicators et pas assez de lead indicators. Quand le problème est visible dans les lag indicators, il est trop tard pour l'éviter.

ITIL governance : la couche strategique¶

ITIL est souvent assimile à la gestion opérationnelle des services (incidents, changements, CMDB). Mais ITIL 4 inclut une dimension gouvernance que peu d'organisations exploitent.

Service Strategy : aligner IT et métier¶

La Service Strategy ITIL définit pourquoi un service existe, pour qui, et quelle valeur il créé. Elle répond a quatre questions :

1. Quels services proposer ?
2. A quels clients / utilisateurs ?
3. Comment créer de la valeur par rapport aux alternatives ?
4. Quels sont les investissements et les retours attendus ?

Sans cette réflexion strategique, le catalogue de services devient une liste d'offres techniques que personne ne comprend.

Service Portfolio Management¶

Le portefeuille de services ITIL structure les services en trois catégories :

Le DSI doit piloter les trois en même temps. La plupart gèrent uniquement le catalogue (ce qui tourne). Très peu ont une vue claire du pipeline et du retired — ce qui conduit à des investissements non maîtrise et à l'accumulation de dette technique.

Demand Management : anticiper la demande¶

Le demand management ITIL vise à comprendre et a influencer la demande des clients de service. Il repose sur deux concepts :

Patterns of Business Activity (PBA) : modèles de consommation des services selon les cycles métier (periode fiscale, campagne marketing, ouverture de nouveaux pays). Connaître les PBA permet d'anticiper les pics de charge et de planifier la capacité.

User Profiles : profils types d'utilisateurs avec leurs comportements et besoins spécifiques. Un commercial itinerant n'a pas les mêmes besoins qu'un analyste financier sedentaire.

Les comites de gouvernance¶

CAB : Change Advisory Board¶

Le CAB est le comite qui valide les changements avant leur mise en production. Son rôle est de réduire le risque d'incident lie aux changements en s'assurant qu'ils sont correctement prepares, testés, et planifies.

Composition typique :

• Responsable des opérations IT
• Representants des équipes techniques impactees
• Representants des métiers clés
• Responsable sécurité (pour les changements sensibles)
• Gestionnaire du changement (president du CAB)

Fréquence : hebdomadaire pour les changements normaux, ad hoc pour les changements urgents.

Périmètre : le CAB ne valide pas tous les changements — seulement ceux classi es comme "normaux" ou "majeurs". Les changements "standard" (pre-approuves, procédures connues) passent sans CAB. Les changements "urgents" passent par un ECAB (Emergency CAB) réduit.

Architecture Board¶

Le comite d'architecture valide les décisions architecturales importantes avant qu'elles soient implementees. Il assure la cohérence du paysage technique et evite la proliferation de technologies non maitrisees.

Rôle :

• Valider les choix technologiques significatifs (nouveaux langages, nouveaux frameworks, nouveaux fournisseurs)
• S'assurer de la conformité aux standards d'architecture de l'entreprise
• Gérer les exceptions et waivers pour les cas justifies
• Maintenir les Architecture Décision Records (ADR)

Fréquence : bi-mensuel ou à la demande pour les décisions urgentes.

Composition : architectes d'entreprise, lead architects des domaines, représentant sécurité, DSI ou délégué.

Security Board¶

Le comite sécurité traite les sujets de sécurité transverses qui depassent les équipes individuelles.

Agenda typique :

• Bilan des incidents de sécurité du mois
• Avancement des projets sécurité (mise en conformité RGPD, ISO 27001)
• Revue des risques de sécurité ouverts
• Approbation des politiques de sécurité
• Sensibilisation et formation

Fréquence : mensuel, avec des sessions extraordinaires en cas d'incident majeur.

Anti-patterns des comites¶

Flux de décision : de la demande métier à l'implémentation¶

flowchart TD
    A["Demande metier\n(besoin exprime)"]
    B{"Qualification\nDSI / Business"}
    C["Refus argumente\navec alternative"]
    D["Estimation\n(effort, cout, risque)"]
    E{"Priorisation\nportefeuille"}
    F["File d'attente\nbacklog"]
    G["Comite architecture\n(si impactant)"]
    H["CAB\n(si changement prod)"]
    I["Implementation\n& delivery"]
    J["Mise en production\n& suivi"]

    A --> B
    B -->|"Hors perimetre\nou infaisable"| C
    B -->|"Recevable"| D
    D --> E
    E -->|"Prio faible\nou capacite pleine"| F
    E -->|"Prio haute"| G
    G --> H
    H --> I
    I --> J
    F -->|"Prochaine iteration\nde priorisation"| E

Ce flux garantit que chaque demande est traitee, que les refus sont argues, et que les décisions de priorisation sont explicites et tracables.

Gestion du portefeuille projets¶

La priorisation : valeur vs effort vs risque¶

La priorisation d'un portefeuille projets doit intégrer trois dimensions :

Valeur — quel benefice le projet apporte-t-il ? Chiffre d'affaires incremental, réduction de coût, conformité reglementaire, réduction de risque, satisfaction client. Tout peut être value, même approximativement.

Effort — quelle est la charge nécessaire ? Jours/hommes, budget, durée. L'effort permet de calculer le retour sur investissement et d'identifier les quick wins.

Risque — quelle est la probabilite d'échec ou de derapage ? Complexité technique, dépendances extérieures, maturité de l'équipe, stabilité des exigences.

Un outil simple : la matrice de priorisation en 9 cases (valeur haute/moyenne/basse x effort haut/moyen/bas). Les projets haute valeur / faible effort sont des priorités absolues. Les projets faible valeur / fort effort sont des candidats au abandon.

Capacity management du portefeuille¶

Le capacity management ne se limite pas aux serveurs. Il s'applique aussi aux équipes : combien de projets peuvent elles absorber en parallèle ?

La loi de Little s'applique aux équipes comme aux files d'attente : Encours = Debit x Duree. Pour réduire le temps de delivery, il faut réduire l'encours (nombre de projets en parallèle), pas augmenter la durée.

Les organisations IT font l'erreur inverse : elles lancent 20 projets en parallèle pour satisfaire tous les demandeurs, et chaque projet avance a 10% de sa vitesse potentielle. Résultat : tout est en retard, les équipes sont eparpillees, et rien ne sort.

Pipeline vs backlog : la distinction essentielle¶

Pipeline : projets en cours d'exécution, avec équipe affectee, budget alloue, date de livraison attendue.

Backlog : projets identifiés, estimés, priorises, mais en attente de capacité. Le backlog n'est pas une corbeille — c'est un stock manage avec une discipline de revue régulière.

Sans cette distinction, le backlog devient un cimetiere de demandes que personne ne relecte et que tout le monde cite pour justifier que "l'IT ne livre pas assez vite".

Architecture Décision Records dans la gouvernance¶

Qu'est-ce qu'un ADR¶

Un Architecture Décision Record est un document court (1-2 pages) qui formalise une décision architecturale importante : le contexte dans lequel elle a été prise, les options considérées, la décision retenue, et les conséquences attendues.

Un ADR type contient :

• Titre : [numéro] [titre court de la décision]
• Statut : Propose / Accepte / Deprecie / Remplacé
• Contexte : pourquoi cette décision est-elle nécessaire ?
• Options considérées : quelles alternatives ont été evaluees ?
• Décision : quelle option a été retenue et pourquoi ?
• Conséquences : quels sont les impacts positifs et negatifs ?

L'ADR comme outil de gouvernance¶

Dans un contexte de gouvernance, les ADR servent plusieurs fonctions :

Traçabilite — dans 2 ans, quand quelqu'un demande "pourquoi on utilisé PostgreSQL et pas MongoDB ?", la réponse existe et est documentee. Sans ADR, la connaissance est dans les tetes des personnes qui etaient la à l'epoque — et qui ne sont peut-être plus la.

Onboarding — un nouveau membre de l'équipe peut lire les ADR pour comprendre les choix structurants du système et leur contexte, sans avoir a recreer la connaissance par interrogation des anciens.

Éviter la régression — quand quelqu'un propose de revenir sur une décision passee, l'ADR permet de rappeler pourquoi cette décision avait été prise. Si le contexte a change, la décision peut changer. Si le contexte est le même, la régression est evitee.

Alimentation du comite d'architecture — les décisions importantes passent par le comite d'architecture. Un ADR sert de support de discussion et devient le compte-rendu de la décision après validation.

Format et stockage¶

Les ADR sont stockes dans le repository de code (généralement docs/adr/ ou architecture/decisions/), au format Markdown, sous contrôle de version. Ils evolvent avec le système et sont versionnes comme le code.

Anti-patterns de gouvernance¶

La gouvernance qui bloque¶

Symptomes :

• Chaque changement nécessité 3 validations et 2 semaines de délai
• Les comites se reunissent pour reporter les décisions à la prochaine réunion
• Les équipes contournent le processus "pour avancer"
• Le backlog de demandes au CAB dépassé 3 mois
• Les réunions durent 3h pour des décisions qui auraient du prendre 20 minutes

Causes :

• Trop de parties prenantes avec droit de veto
• Absence de critères de décision clairs
• Comites consultatifs traites comme des comites decisionnels
• Processus conçus pour le pire cas, appliques a tous les cas

Remedes :

• Classifier les changements (standard / normal / majeur / urgent) avec des processus differencies
• Déléguer au niveau le plus bas compétent
• Fixer des SLA de réponse pour les comites
• Introduire le principe du "silence vaut acceptation" après X jours

La gouvernance fantome¶

Symptomes :

• Les décisions sont prises dans les couloirs ou par message instantané
• Les réunions formelles ratifient des décisions déjà prises
• Certains individus ont un pouvoir de blocage informel non documente
• Les comptes-rendus ne reflettent pas ce qui s'est vraiment passe
• Les équipes savent qu'il faut "avoir la bonne conversation avec la bonne personne" avant de passer en comite

Causes :

• Processus formels trop lents ou trop lourds
• Confiance insuffisante dans les instances formelles
• Culture organisationnelle favorisant les relations informelles
• Manque d'autorité réelle des comites formels

Remedes :

• Rendre les processus formels suffisamment rapides pour qu'ils soient utiles
• Documenter systematiquement les décisions, même informelles
• S'assurer que les comites ont un mandat réel et des décisions executoires
• Former et coacher les managers sur les processus de gouvernance

Piloter la gouvernance IT : indicateurs clés¶

La gouvernance se pilote comme tout processus : avec des métriques, des cibles, des revues périodiques et des plans d'action quand les indicateurs derivent.