Parties prenantes et gouvernance¶

Identifier qui décidé, qui subit et qui peut bloquer — avant de dessiner le moindre composant.

Pourquoi commencer par les parties prenantes¶

On ne cadre pas une architecture dans le vide. Chaque système a des utilisateurs, des sponsors, des opérateurs, des regulateurs. Chacun a des attentes différentes — et souvent contradictoires. Le sponsor veut livrer vite, la sécurité veut auditer tout, les ops veulent du simple, le métier veut du complet.

Si on ne cartographie pas ces attentes avant de concevoir, on decouvre les conflits au pire moment : en revue d'architecture, quand il est trop tard pour changer de direction sans coût significatif.

Le travail de parties prenantes n'est pas politique. C'est un travail d'ingénierie : comprendre les forces en présence pour concevoir un système qui les satisfait — ou qui documente explicitement les compromis faits.

Dans les frameworks formalisés comme TOGAF, l'identification des parties prenantes est la première activité de la phase A (Architecture Vision). Ce n'est pas un hasard : sans cette cartographie, la vision produite ne reflete que le point de vue de l'architecte.

Catégories de parties prenantes¶

Les parties prenantes d'un système se regroupent en catégories prévisibles. Les oublier est une erreur classique — surtout les parties prenantes silencieuses qui ne participent pas aux réunions mais qui peuvent bloquer un déploiement.

graph TD
    subgraph "Parties prenantes internes"
        SP[Sponsor / Direction]
        DEV[Equipe developpement]
        OPS[Operations / SRE]
        SEC[Securite / RSSI]
        ARCH[Architecture / CTO]
    end

    subgraph "Parties prenantes externes"
        USR[Utilisateurs finaux]
        LEG[Legal / DPO]
        PART[Partenaires / Fournisseurs]
    end

    SP --"budget, calendrier"--> SYS[Systeme cible]
    DEV --"maintenabilite, testabilite"--> SYS
    OPS --"operabilite, observabilite"--> SYS
    SEC --"conformite, audit"--> SYS
    ARCH --"coherence SI"--> SYS
    USR --"performance, ergonomie"--> SYS
    LEG --"reglementation"--> SYS
    PART --"stabilite interfaces"--> SYS

Matrice pouvoir-intérêt¶

La matrice pouvoir-intérêt classe les parties prenantes selon deux axes : leur pouvoir d'influence sur le projet et leur intérêt pour le résultat. Cette classification détermine la stratégie de communication pour chaque groupe.

quadrantChart
    title Matrice pouvoir-interet
    x-axis "Interet faible" --> "Interet fort"
    y-axis "Pouvoir faible" --> "Pouvoir fort"
    quadrant-1 Gerer de pres
    quadrant-2 Satisfaire
    quadrant-3 Surveiller
    quadrant-4 Informer
    Sponsor: [0.8, 0.9]
    Product Owner: [0.9, 0.7]
    RSSI: [0.4, 0.8]
    Developpeurs: [0.85, 0.4]
    Utilisateurs finaux: [0.7, 0.2]
    DPO: [0.3, 0.6]

Les quatre quadrants dictent l'approche :

L'erreur classique : traiter toutes les parties prenantes de la même manière. Un mail hebdomadaire suffit pour le quadrant "surveiller". Le sponsor exige un échange direct et régulier. Confondre les deux modes gaspille du temps ou crée des angles morts.

Construire la matrice en pratique¶

Pour chaque partie prenante identifiée :

1. Évaluer le pouvoir : peut-elle bloquer le projet ? Contrôle-t-elle le budget ou les ressources ?
2. Évaluer l'intérêt : est-elle directement impactee par le résultat ? Utilisera-t-elle le système ?
3. Placer dans le quadrant correspondant.
4. Réviser à chaque phase du projet — le pouvoir et l'intérêt evoluent.

Un sponsor desinteresse au début peut devenir très implique quand le projet approche de la mise en production. Un développeur junior peut gagner du pouvoir en devenant tech lead. La matrice est un outil vivant, pas une photo unique.

Matrice RACI¶

La matrice RACI attribue un rôle précis à chaque partie prenante pour chaque type de décision. Les quatre rôles sont :

• R — Responsible : réalisé le travail. Celui qui produit le livrable.
• A — Accountable : valide et assume la responsabilité finale. Un seul A par ligne.
• C — Consulted : donne un avis avant la décision. Communication bidirectionnelle.
• I — Informed : notifie après la décision. Communication unidirectionnelle.

Exemple : décisions d'architecture¶

Règles d'utilisation¶

La matrice RACI n'est utile que si elle est respectee :

• Ne pas confondre Consulted et Informed. Consulted implique un échange avant la décision — pas une notification après.
• Réviser la matrice à chaque changement d'équipe. Un départ non mis à jour laisse des décisions sans responsable.
• Limiter le nombre de C par ligne. Trop de consultations ralentit la prise de décision sans améliorer sa qualité.
• Si une ligne n'a que des I et un R, c'est probablement une décision opérationnelle, pas architecturale.

Variantes de la matrice RACI¶

Certaines organisations utilisent des extensions :

Pour la plupart des projets, le RACI classique suffit. Les variantes ajoutent de la précision au prix de la complexité. Ne les adopter que si le RACI standard crée des ambiguites non resolues.

Comite d'architecture¶

Le comite d'architecture est l'instance de gouvernance qui valide les décisions structurantes. Sans comite, les décisions d'architecture sont prises de manière informelle — souvent par la personne la plus senior présenté dans la salle, sans necessairement considérer toutes les perspectives.

Composition type¶

Format et fréquence¶

• Fréquence : bi-hebdomadaire pour un projet en phase active, mensuelle en phase de maintenance.
• Durée : 1 heure maximum. Au-delà, le format est inadapte.
• Input : chaque sujet est accompagne d'un ADR en statut proposed distribué 48h avant.
• Output : l'ADR passe en accepted ou est renvoyé avec des demandes de clarification.
• Décision : par consensus. En cas de blocage, l'Accountable désigné tranche.

Processus de décision type¶

graph LR
    A[Architecte redige ADR] --"48h avant"--> B[Distribution au comite]
    B --"lecture prealable"--> C[Presentation en comite]
    C --"consensus"--> D[ADR accepted]
    C --"questions ouvertes"--> E[Renvoi pour clarification]
    E --"revision"--> A
    D --"communication"--> F[Equipes informees]

Le processus fonctionne si deux conditions sont reunies : les ADR arrivent en avance (pas en seance) et les membres du comite les lisent avant la réunion. Sans lecture préalable, le comite devient un atelier de découverte, pas une instance de décision.

Plan de communication¶

Chaque type de partie prenante a besoin d'un canal et d'une fréquence adaptés. Un plan de communication explicite evite deux ecueils : le silence (les parties prenantes sont surprises par les décisions) et le bruit (trop de réunions inutiles).

Adapter le message au public¶

Le même choix technique se communique differemment selon l'interlocuteur :

• Au sponsor : "On adopte une base de données managed pour réduire les coûts ops de 30%."
• À l'équipe dev : "On passe sur Cloud SQL PostgreSQL 16 — ADR-001 documente les alternatives et le raisonnement."
• Aux ops : "Cloud SQL géré les backups, patches et failover. Voici le runbook de bascule manuelle en cas d'incident provider."
• À la sécurité : "Chiffrement at-rest actif par défaut, connexions via private IP, audit log active."

La même décision, quatre messages. Quatre niveaux de détail. Quatre preoccupations adressees.

Gestion des attentes contradictoires¶

Les conflits entre parties prenantes sont normaux et prévisibles. Le travail de l'architecte n'est pas de les éviter mais de les rendre explicites et de proposer des compromis documentes.

Pour chaque conflit, documenter la décision dans un ADR. Le compromis est le produit normal du cadrage — pas un échec.

Méthode de résolution structurée¶

Quand deux parties prenantes ont des attentes incompatibles, une approche structurée evite que la décision revienne à la personne la plus influente :

1. Expliciter le conflit : chaque partie formule son exigence en termes mesurables.
2. Évaluer l'impact : que se passe-t-il si on choisit A ? Si on choisit B ?
3. Chercher le compromis : existe-t-il une option qui satisfait partiellement les deux ?
4. Documenter : quelle que soit la décision, l'ADR capture le raisonnement.
5. Revisiter : fixer une date pour reevaluer si le compromis tient.

Anti-patterns de gouvernance¶

Chapitre suivant : Recueil des exigences — distinguer ce que le système fait de comment il le fait, et rendre chaque exigence mesurable.