Dans un projet Finance ou SI, la matrice RACI est souvent présentée comme la réponse aux difficultés de gouvernance.
Elle permet d’associer les activités ou les livrables aux personnes qui réalisent le travail, portent la responsabilité finale, sont consultées ou doivent être informées.
Cette clarification est utile. Elle évite les zones totalement orphelines, les contributions implicites et les malentendus sur les responsabilités.
Pourtant, une matrice RACI peut être parfaitement renseignée et laisser les décisions à l’arrêt.
Le problème ne vient pas nécessairement du tableau. Il vient de ce que l’on attend de lui.
Une matrice d’affectation des responsabilités décrit principalement qui intervient. Elle ne définit pas, à elle seule, comment une décision doit être instruite, dans quel délai elle doit être rendue, comment un désaccord est arbitré ni ce qui se passe lorsque l’autorité désignée ne répond pas.
Pour devenir un véritable outil de gouvernance, le RACI doit donc être relié à une mécanique de décision explicite.
À quoi sert réellement une matrice RACI ?
Dans sa convention la plus courante, RACI distingue quatre rôles :
- R — Responsible : la personne ou l’équipe qui réalise le travail ;
- A — Accountable : l’autorité qui porte la responsabilité finale de l’objet ;
- C — Consulted : les acteurs dont l’avis ou l’expertise doit être recueilli ;
- I — Informed : les acteurs qui doivent recevoir l’information utile.
Certaines méthodes utilisent une variante RASCI, qui ajoute le rôle S — Supportive pour les contributeurs apportant un soutien à la réalisation.
La méthode PM² de la Commission européenne inscrit ce type de matrice dans un modèle plus large de gouvernance. Elle rappelle que la gouvernance constitue le cadre dans lequel les décisions sont prises et que les rôles doivent être reliés à des responsabilités et à un niveau d’autorité. PM² Project Management
La déclinaison PM² pour les programmes présente également une Responsibilities Assignment Matrix pour clarifier les responsabilités, les domaines d’intervention et l’autorité des différents rôles. PM² Programme Management
Le RACI est donc un outil de clarification. Il n’est pas, à lui seul, une procédure d’arbitrage.
Pourquoi les décisions restent-elles bloquées malgré le RACI ?
Plusieurs « A » apparaissent sur la même ligne
Cette configuration traduit souvent une volonté de ne froisser personne.
Le métier, la Finance, la DSI et parfois l’intégrateur sont tous désignés comme responsables finaux. La matrice donne alors l’impression d’une responsabilité partagée, mais elle masque l’absence d’une autorité clairement identifiée.
Lorsque la décision devient difficile, chaque acteur attend que l’autre assume le choix.
La règle la plus utile consiste à conserver un seul « A » pour chaque objet suffisamment précis.
Si deux autorités semblent nécessaires, il faut probablement décomposer la ligne :
- la Finance décide de la règle métier ;
- la DSI décide de l’architecture technique ;
- le sponsor arbitre lorsque les deux décisions produisent une incompatibilité de coût, de délai ou de risque.
La qualité du RACI dépend ainsi du bon niveau de granularité.
Le « A » n’a pas l’autorité réelle
Une personne peut être désignée comme « A » dans le tableau sans disposer du mandat nécessaire pour engager un budget, modifier une règle de gestion, accepter un risque ou imposer une priorité.
Le rôle est alors théorique.
La personne instruit le sujet, anime les échanges et prépare une recommandation, mais doit rechercher ailleurs l’autorité réelle. Cette étape supplémentaire n’est pas toujours visible dans la matrice.
Avant de valider le RACI, il faut vérifier non seulement le nom du rôle, mais aussi son niveau d’autorité :
- peut-il décider dans le périmètre prévu ?
- quelle limite financière ou opérationnelle s’applique ?
- doit-il obtenir une validation complémentaire ?
- quel comité détient l’autorité au-delà de ce seuil ?
Un rôle clairement nommé mais sans mandat explicite ne sécurise pas la décision.
Les personnes consultées disposent d’un veto implicite
Le rôle « C » est régulièrement interprété comme une obligation d’obtenir l’accord de toutes les parties consultées.
La consultation se transforme alors en recherche d’unanimité.
Cette dérive est particulièrement fréquente dans les projets transverses : Finance, Achats, Fiscalité, Sécurité, Juridique, DSI et opérations peuvent tous apporter une expertise légitime. Mais toutes ces contributions ne doivent pas nécessairement devenir des validations successives.
Le projet doit préciser ce qui est attendu de chaque consultation :
- un avis ;
- une donnée ;
- une analyse de risque ;
- une vérification réglementaire ;
- une proposition ;
- une validation formelle lorsque le texte ou le contrôle interne l’exige réellement.
Un avis défavorable doit être documenté et traité. Il ne doit pas devenir automatiquement un veto lorsque l’acteur consulté ne détient pas l’autorité de décision.
Aucun délai de décision n’est défini
La matrice indique qui doit intervenir, mais pas toujours quand.
Le sujet reste alors dans la colonne « à valider » pendant plusieurs semaines. Les équipes poursuivent parfois les travaux sur la base d’hypothèses, ce qui crée de la reprise, de la dette de validation et des arbitrages tardifs.
Chaque décision importante doit posséder une échéance reliée au jalon qu’elle protège.
La bonne date n’est pas celle du prochain comité par habitude. C’est la dernière date à laquelle la décision peut être prise sans affecter le planning, le coût ou le niveau de risque accepté.
La différence entre réaliser et décider
La confusion entre « R » et « A » constitue l’un des défauts les plus courants.
Le « R » prépare, analyse, coordonne ou produit. Il peut construire le dossier de décision et formuler une recommandation.
Le « A » assume le choix final dans le périmètre prévu. Il accepte les conséquences de la décision et s’assure que celle-ci est mise en œuvre.
Dans un projet de transformation Finance, l’AMOA peut par exemple :
- recueillir les besoins ;
- analyser les variantes ;
- documenter les impacts ;
- organiser la consultation ;
- formuler une recommandation ;
- préparer l’arbitrage.
Cela ne signifie pas qu’elle doit décider à la place du directeur financier, du responsable de processus, du sponsor ou de l’autorité de gouvernance.
L’AMOA sécurise la décision. Elle ne se substitue pas au décideur.
Du RACI au protocole de décision
Pour les décisions structurantes, sept informations doivent compléter la matrice.
1. L’objet exact
La décision doit être formulée comme une question précise.
« Valider le processus P2P » est trop large.
« Décider si les factures sans commande supérieures à 10 000 euros sont bloquées ou orientées vers un circuit d’exception » constitue un objet plus exploitable.
Le périmètre, les hypothèses et les exclusions doivent être visibles.
2. L’autorité finale
Une seule autorité doit porter la décision pour cet objet.
Il peut s’agir d’un rôle plutôt que d’un nom lorsque l’organisation doit rester stable dans le temps. Il faut toutefois identifier la personne qui occupe ce rôle au moment de l’arbitrage.
3. Les contributeurs et la contribution attendue
La liste des personnes consultées doit rester proportionnée.
Pour chaque acteur, le projet doit préciser la contribution recherchée : estimation, avis métier, contrôle, analyse de sécurité, validation réglementaire ou mesure de l’impact.
Cette précision évite les consultations génériques auxquelles personne ne sait réellement comment répondre.
4. L’échéance
La date limite doit être calculée à partir des dépendances du projet.
Elle doit laisser suffisamment de temps pour appliquer la décision : mise à jour d’une spécification, paramétrage, développement, préparation d’un jeu de données, communication ou test.
5. La règle en cas de désaccord
Le projet doit définir si l’autorité décide après avoir recueilli les avis, si une validation conjointe est réellement imposée, ou si un niveau supérieur doit arbitrer certains conflits.
L’objectif n’est pas d’ignorer les désaccords. Il est d’éviter qu’ils deviennent une suspension indéfinie.
6. L’escalade
Une escalade doit être déclenchée selon une règle connue :
- absence de réponse à la date prévue ;
- conflit entre deux domaines d’autorité ;
- dépassement d’un seuil financier ;
- création d’un risque critique ;
- impact sur un jalon majeur ;
- non-respect d’une exigence réglementaire ou de contrôle interne.
L’instance d’escalade doit être identifiée avant que le blocage ne se produise.
7. La preuve et la mise en œuvre
Une décision n’est pas pleinement clôturée lorsqu’elle a seulement été annoncée en réunion.
Le projet doit conserver :
- la décision rendue ;
- sa date ;
- son autorité ;
- les réserves éventuelles ;
- les actions qui en découlent ;
- les exigences ou risques impactés ;
- la preuve que la décision a été appliquée.
Exemple dans un projet P2P
Une entreprise déploie une nouvelle solution de traitement des factures fournisseurs.
Le sujet suivant doit être tranché :
Les factures sans commande supérieures à un seuil donné doivent-elles être bloquées ou admises dans un circuit d’exception ?
Une matrice trop vague peut désigner la Finance, les Achats et le Contrôle interne comme « A ».
Les trois directions ont un intérêt légitime dans la décision :
- la Finance évalue l’impact sur la comptabilisation et le paiement ;
- les Achats analysent le respect de la politique de commande ;
- le Contrôle interne mesure le risque et les contrôles compensatoires ;
- la DSI et l’intégrateur évaluent la faisabilité de la règle dans la solution.
Mais ces contributions ne constituent pas toutes l’autorité finale.
Une organisation plus robuste pourrait retenir :
- R : l’AMOA prépare les scénarios, les données et la recommandation ;
- A : le directeur financier ou le propriétaire du processus P2P décide ;
- C : Achats, Contrôle interne, Fiscalité, DSI et intégrateur apportent leurs analyses ;
- I : Comptabilité fournisseurs, responsables opérationnels et support sont informés ;
- échéance : avant le gel du paramétrage ;
- escalade : sponsor ou COPIL si le risque résiduel dépasse le niveau accepté ;
- preuve : décision enregistrée, règle mise à jour, paramétrage testé et scénario de recette validé.
Le tableau n’a pas disparu. Il a été complété par les éléments qui permettent au projet d’avancer.
À quel niveau faut-il construire le RACI ?
Un RACI trop global produit des responsabilités abstraites.
Un RACI trop détaillé devient impossible à maintenir.
Le bon niveau se situe généralement autour des objets qui nécessitent une coordination ou une décision identifiable :
- livrables majeurs ;
- règles métier structurantes ;
- jalons et passages de phase ;
- processus transverses ;
- données de référence ;
- interfaces critiques ;
- acceptation des risques ;
- validation de la recette ;
- autorisation de mise en production.
Il n’est pas nécessaire d’affecter quatre lettres à chaque tâche quotidienne.
L’objectif est de rendre visibles les responsabilités là où leur ambiguïté pourrait créer un retard, une mauvaise décision ou un risque non assumé.
Le rôle de l’AMOA et du PMO
L’AMOA et le PMO ne doivent pas seulement produire la matrice.
Ils doivent vérifier sa cohérence avec la gouvernance réelle.
Leur contribution consiste notamment à :
- identifier les décisions et livrables qui nécessitent une autorité explicite ;
- proposer un niveau de granularité exploitable ;
- distinguer réalisation, contribution, consultation et validation ;
- vérifier que le « A » dispose du mandat nécessaire ;
- relier les échéances aux jalons ;
- préparer les dossiers de décision ;
- organiser l’escalade ;
- tracer la décision et ses impacts ;
- mettre à jour les actions, risques et exigences liés.
Cette approche complète le pilotage de projets Finance et SI et évite qu’un compte rendu de réunion soit le seul endroit où l’arbitrage reste visible.
Elle réduit également la dette de validation des livrables en donnant à chaque validation une autorité et une échéance.
Les contrôles à réaliser avant de valider la matrice
Une revue rapide peut s’appuyer sur huit questions :
- chaque ligne décrit-elle un objet suffisamment précis ?
- existe-t-il au moins une personne chargée de réaliser ou coordonner le travail ?
- un seul « A » porte-t-il la responsabilité finale ?
- cette autorité possède-t-elle réellement le mandat nécessaire ?
- les consultations sont-elles justifiées et leur résultat attendu est-il défini ?
- les acteurs informés reçoivent-ils l’information au bon moment ?
- une échéance et une règle d’escalade existent-elles pour les décisions critiques ?
- la décision et sa mise en œuvre produisent-elles une preuve vérifiable ?
Si plusieurs réponses restent négatives, le projet ne dispose pas encore d’un dispositif de gouvernance. Il dispose principalement d’un tableau de répartition.
La matrice clarifie les rôles ; la gouvernance fait avancer
Le RACI reste un outil simple et utile.
Il oblige le projet à rendre visibles les responsabilités et à distinguer les personnes qui réalisent, décident, contribuent ou doivent être informées.
Mais son efficacité dépend de ce qui l’entoure.
Une autorité sans mandat, une consultation sans règle, une décision sans date ou un arbitrage sans escalade continuent de bloquer le projet, même lorsque toutes les cases sont remplies.
La question à poser n’est donc pas seulement :
« Avons-nous défini qui est R, A, C et I ? »
Elle devient :
« Avons-nous donné à l’autorité désignée les informations, le mandat, l’échéance et le mécanisme nécessaires pour décider ? »
BAZIRE CONSULTING accompagne les directions Finance, les métiers et les DSI dans la structuration de la gouvernance, la clarification des responsabilités et le pilotage opérationnel de leurs projets de transformation Finance & SI.
