Introduction
Une matrice RACI (Responsible, Accountable, Consulted, Informed) clarifie qui est Responsable, Reddable des comptes, Consulté et Informé pour chaque décision et livrable. Dans la transformation numérique, elle prévient le mode d'échec courant où tout le monde a un avis mais personne ne possède le résultat. Cet article montre comment appliquer RACI à une décision technologique concrète — la migration d'une plateforme SaaS monolithique sur site vers une architecture cloud-native sur AWS EKS — pour passer d'un cadre abstrait à une gouvernance actionnable.
Le lecteur visé est un CTO, VP Ingénierie, Responsable de plateforme ou gestionnaire de programme de transformation qui doit aligner les parties prenantes, documenter les arbitrages et établir des points de contrôle mesurables. À la fin, vous disposerez d'un exemple RACI travaillé que vous pouvez adapter, ainsi que d'une liste de contrôle de gouvernance avec des critères de validation explicites pour votre prochain cycle de planification.
Contexte de gestion
Commencez par rédiger l'énoncé de décision en une phrase. Pour ce guide, la décision est : "Migrer l'application principale orientée client du monolithe sur site vers des microservices conteneurisés sur AWS EKS en 12 mois, avec basculement sans interruption et conformité SOC 2 maintenue tout au long."
De cet énoncé, dérivez les quatre entrées que le RACI doit servir :
- Contraintes : échéance de 12 mois, plafond budgétaire de 2,5 M$, certification SOC 2 Type II existante qui ne doit pas expirer, équipe actuelle de 45 ingénieurs répartis sur 6 escouades.
- Signaux de succès : latence P99 ≤ 200 ms post-migration, fréquence de déploiement ≥ une fois par jour, coût d'infrastructure par transaction ≤ 1,2x l'actuel, zéro constat critique de sécurité au prochain audit.
- Catégories de risques : perte de données pendant la migration, écarts de conformité durant la transition, surcharge de capacité de l'équipe, verrouillage fournisseur sur les services spécifiques AWS.
- Cadence de gouvernance : revue de pilotage mensuelle, synchronisation d'architecture bimensuelle, points quotidiens d'escouade hebdomadaires avec les propriétaires RACI présents.
Traitez ce contexte comme un document vivant. Mettez-le à jour quand de nouvelles preuves arrivent — changement de tarification fournisseur, départ d'un ingénieur clé, ou constat d'un auditeur de conformité — plutôt que de le figer au lancement.
Exemple travaillé : migration de plateforme cloud-native
Scénario
Acme SaaS (pseudonyme) exploite une plateforme d'analytique B2B sur un cluster Kubernetes unique sur site (auto-géré, v1.24) avec une base de données PostgreSQL monolithique. Le CTO a mandaté la migration vers AWS EKS avec RDS PostgreSQL et un pattern strangler-fig pour décomposer le monolithe en six services à contextes bornés. La migration doit s'achever avant l'expiration du bail du centre de données actuel dans 12 mois.
Matrice RACI
| Décision/Livrable | CTO (A) | VP Eng (R) | Resp. Plateforme (R) | Resp. Sécurité (C) | Dir. Produit (C) | Gestionnaires Ing. (I) | Resp. SRE (R) | Resp. Conformité (C) | Dir. Finance (I) |
|---|---|---|---|---|---|---|---|---|---|
| Validation de l'architecture cible | A | R | R | C | C | I | C | I | I |
| Séquençage des vagues de migration | I | A | R | C | C | C | R | I | I |
| Structure des comptes AWS & landing zone | I | A | R | C | I | I | R | C | C |
| Stratégie de migration des données (CDC + basculement) | I | A | R | C | C | I | R | C | I |
| Cartographie des contrôles SOC 2 pour le cloud | I | I | C | R | I | I | C | A | I |
| Modèle de coûts & suivi budgétaire | A | R | C | I | I | I | C | I | R |
| Plan de capacité & recrutement de l'équipe | A | R | C | I | C | R | I | I | C |
| Critères de retour arrière & seuils go/no-go | I | A | R | C | C | I | R | C | I |
| Négociation fournisseur (AWS Enterprise Support) | A | R | C | I | I | I | I | I | R |
| Ligne de base d'observabilité post-migration | I | A | R | C | I | I | R | I | I |
Légende : A = Accountable / Reddable des comptes (un seul propriétaire, autorité finale), R = Responsible / Responsable (fait le travail), C = Consulted / Consulté (apport bidirectionnel avant décision), I = Informed / Informé (notification unidirectionnelle après décision).
Comment lire cette matrice
- Le VP Ingénierie est Reddable des comptes pour le séquençage des vagues de migration car il possède le calendrier de livraison et la capacité des escouades. Le Responsable Plateforme et le Responsable SRE (Site Reliability Engineering : ingénierie de la fiabilité des sites) sont conjointement Responsables de l'exécution des vagues et de la mécanique du basculement.
- Le Responsable Sécurité est Consulté sur l'architecture et la migration des données, mais Reddable des comptes sur rien — il conseille, il ne décide pas. Le Responsable Conformité est Reddable des comptes uniquement pour la cartographie des contrôles SOC 2, assurant l'existence des preuves d'audit pour chaque contrôle dans le nouvel environnement.
- Le Directeur Produit est Consulté sur le séquençage et le basculement car les gels de fonctionnalités affectent les engagements de feuille de route. Il est Informé sur le modèle de coûts et la négociation fournisseur.
- Les Gestionnaires Ingénierie sont Responsables de la planification de la capacité d'équipe (ils connaissent la vélocité des sprints et le pipeline de recrutement) mais seulement Informés sur les détails d'architecture technique.
- Le Directeur Finance est Reddable des comptes pour la négociation fournisseur (autorité de signature contractuelle) et Responsable du suivi budgétaire, mais seulement Consulté sur les implications de coûts de la landing zone.
Utilisation de la matrice en pratique
- Affichez la matrice dans la salle de guerre (physique ou virtuelle). À chaque revue de pilotage, parcourez chaque ligne : « Le propriétaire Reddable des comptes a-t-il validé ? Toutes les parties Consultées ont-elles été entendues ? Les parties Informées ont-elles été notifiées ? »
- Signalez les écarts immédiatement. Si le Responsable Sécurité n'a pas revu le design de la landing zone d'ici la semaine 3, le Responsable Plateforme escalade au VP Ingénierie — pas au CTO.
- Mettez à jour les rôles quand la réalité change. Si le Responsable SRE part, réassignez ses cases R au Responsable Plateforme et ajoutez une nouvelle recrue SRE comme R une fois intégrée. Documentez le changement dans le journal des décisions.
Liste de contrôle pour la décision et la gouvernance
Utilisez la liste suivante à chaque revue de pilotage mensuelle. Chaque item doit avoir une réponse binaire oui/non avec preuve jointe. Si un item est « Non », la vague de migration n'avance pas.
Définition de la décision
- [ ] L'énoncé de décision est rédigé, versionné et lié dans le wiki du programme.
- [ ] Les signaux de succès sont quantifiés avec mesures de référence capturées.
- [ ] Les contraintes (budget, échéance, conformité, capacité) sont explicites et signées par les propriétaires Reddables des comptes.
Intégrité du RACI
- [ ] Chaque livrable a exactement un propriétaire Reddable des comptes.
- [ ] Aucun individu ne détient la reddition de comptes sur plus de trois livrables simultanés.
- [ ] Toutes les parties Consultées ont fourni un apport écrit (commentaire sur doc de design, réunion enregistrée, ou courriel signé) dans les 30 derniers jours.
- [ ] Toutes les parties Informées ont reçu la notification de la dernière décision dans les 48 heures.
Risques et preuves
- [ ] Les 5 principaux risques ont chacun un propriétaire nommé, une action d'atténuation avec échéance, et un déclencheur d'escalade.
- [ ] Essai à blanc de migration des données complété sur l'environnement de staging avec taux de divergence ≤ 0,01 %.
- [ ] Cartographie des contrôles SOC 2 revue par le Responsable Conformité ; zéro écart ouvert pour les contrôles dans le périmètre du prochain audit.
- [ ] Modèle de coûts AWS validé contre les 90 derniers jours de trafic de production ; dépenses mensuelles projetées dans les 15 % du budget.
Seuils Go/No-Go (par vague de migration)
- [ ] Déploiement canary automatisé réussit avec taux d'erreur ≤ 0,1 % sur 24 heures.
- [ ] Procédure de retour arrière testée et complétée dans le RTO (Recovery Time Objective : objectif de temps de rétablissement) de 15 minutes.
- [ ] Directeur Produit confirme la fenêtre de gel de fonctionnalités respectée ; aucun changement de feuille de route non engagé.
- [ ] Directeur Finance confirme les dépenses cumulées ≤ seuil de taux de consommation budgétaire.
Revue et adaptation
- [ ] Procès-verbal de la revue de pilotage capturé, actions assignées avec propriétaires et échéances.
- [ ] Matrice RACI mise à jour pour tout changement de rôle depuis la dernière revue.
- [ ] Date de prochaine revue calendrée avec tous les propriétaires Reddables des comptes et Consultés requis.
Comment appliquer cette liste : Imprimez-la. Au début de chaque revue de pilotage, le VP Ingénierie lit chaque ligne. La salle répond oui/non. Tout « Non » devient une action avec un propriétaire et une échéance avant la prochaine vague. Aucune vague ne progresse avec des items « Non » ouverts.
Conclusion
Une matrice RACI prouve sa valeur quand elle force l'appartenance explicite, fait émerger les apports manquants avant qu'ils ne deviennent bloquants, et donne au comité de pilotage un langage partagé pour « qui décide quoi, d'ici quand ». L'exemple travaillé ci-dessus n'est pas un modèle à copier — c'est un patron à adapter. Remplacez les livrables, rôles et signaux de succès par ceux de votre propre décision.
Prochaine étape : choisissez une initiative active — sélection fournisseur, réécriture de plateforme, sortie de centre de données, ou restructuration organisationnelle — et construisez son RACI cette semaine. Rédigez l'énoncé de décision. Nommez le propriétaire Reddable des comptes pour chaque livrable. Planifiez la première revue de gouvernance. Utilisez ensuite la liste ci-dessus pour vérifier que la structure tient.
Revisitez le RACI à chaque cycle de planification. Quand les preuves changent — nouveaux termes fournisseur, échéance réglementaire déplacée, réorganisation d'équipe — mettez à jour la matrice et relancez la liste. La discipline n'est pas de créer le graphique une fois ; c'est de le garder honnête tandis que les conditions évoluent.