RACI en gestion de projet : un seul approbateur pour éviter les validations bloquées
Une tâche avance, mais personne ne sait qui doit la valider. Une autre reste en attente parce que chacun pensait qu’un collègue s’en occupait. En gestion de projet, la matrice RACI clarifie ces situations : elle indique qui réalise le travail, qui en porte la responsabilité finale, qui doit être consulté et qui doit être informé. Son intérêt tient moins au tableau lui-même qu’aux accords qu’il rend explicites.
Quatre rôles pour distinguer action, décision et communication
La matrice RACI est un tableau d’attribution des responsabilités. Elle croise des tâches, des activités ou des livrables avec les acteurs concernés : personnes, fonctions, métiers ou services. Chaque lettre précise la participation attendue pour une ligne donnée. Un même acteur peut donc changer de rôle selon l’activité.
Testez vos connaissances sur la matrice RACI
Répondez aux six questions, puis validez pour découvrir votre score et les corrections expliquées.
| Lettre | Terme anglais | Rôle en français | Contribution attendue |
|---|---|---|---|
| R | Responsible | Réalisateur | Exécute la tâche et produit le résultat. |
| A | Accountable | Approbateur | Porte la responsabilité finale et valide le livrable. |
| C | Consulted | Consulté | Apporte son expertise avant la décision ou la réalisation. |
| I | Informed | Informé | Reçoit les informations utiles sur l’avancement ou le résultat. |
Le réalisateur produit, l’approbateur répond du résultat
La distinction entre R et A est essentielle. Un prestataire peut développer une fonctionnalité sans avoir l’autorité pour accepter sa livraison. Inversement, l’approbateur n’exécute pas nécessairement le travail : il doit pouvoir accepter le résultat ou demander une correction. Le A n’est donc pas automatiquement le supérieur hiérarchique du R, mais il doit disposer d’un pouvoir de décision réel sur le périmètre concerné.
Être consulté ne signifie pas disposer d’un droit de veto
Le C participe à un échange : son avis est attendu suffisamment tôt pour être utile. Le I reçoit une information sans devoir contribuer à la décision. Prévenir un expert après validation ne constitue pas une consultation. À l’inverse, solliciter l’accord de toutes les personnes informées transforme inutilement une communication en circuit d’approbation.
Construire une matrice à la bonne échelle
Établissez le RACI pendant la phase de planification, avant que les premiers désaccords opérationnels apparaissent. Il est particulièrement utile lorsque plusieurs équipes, prestataires ou services interviennent. Il convient aussi à un processus récurrent, comme le traitement d’une réclamation ou la publication d’un contenu.
- Délimitez le périmètre. Choisissez le projet, le processus ou la phase à organiser et identifiez les résultats attendus.
- Listez les activités en lignes. Utilisez des formulations observables : « rédiger le cahier des charges » plutôt que « gérer le besoin ».
- Placez les acteurs en colonnes. Privilégiez des fonctions stables, puis associez-les à des personnes identifiées.
- Attribuez les lettres ensemble. Commencez par le A et les R, puis ajoutez uniquement les C et I nécessaires.
- Faites confirmer les engagements. Vérifiez que chacun comprend son rôle, possède les moyens nécessaires et accepte la répartition.
Le bon niveau de détail correspond à une activité dont le résultat et la validation sont compréhensibles. Une ligne « réaliser le site » masque trop de responsabilités. À l’inverse, détailler chaque correction typographique rend le tableau pénible à maintenir. Scindez une activité lorsque son réalisateur, son approbateur ou son circuit de consultation change réellement.
Pensez la granularité comme un soufflet : elle doit pouvoir se déployer autour d’une zone risquée, puis se resserrer sur les opérations courantes. Pour une migration informatique, détaillez les responsabilités de sauvegarde, de bascule et de retour arrière ; pour une publication habituelle, une seule ligne peut suffire. Vous rendez ainsi visibles les points de rupture sans transformer toute l’activité en procédure lourde.
Si vous utilisez déjà un WBS, reprenez son découpage du travail. Le RACI précise ensuite qui intervient ; le planning de Gantt positionne les activités dans le temps et le PERT aide à organiser leurs dépendances. La matrice ne remplace pas le planning.
Un exemple de RACI à reprendre dans votre tableur
Voici un modèle appliqué à la refonte d’un site vitrine. Les fonctions sont volontairement distinctes pour rendre les arbitrages visibles. Vous pouvez copier ce tableau dans Excel ou Google Sheets, remplacer les acteurs et adapter les lignes à vos livrables.
| Activité ou livrable | Sponsor | Chef de projet | Marketing | Prestataire web | Référent informatique |
|---|---|---|---|---|---|
| Définir les objectifs et le budget | A | R | C | C | I |
| Rédiger le cahier des charges | I | A | R | C | C |
| Produire les contenus | I | C | A/R | C | — |
| Développer le site | I | A | C | R | C |
| Effectuer la recette fonctionnelle | I | A | R | C | C |
| Mettre le site en production | I | A | I | R | C |
Dans cet exemple, le chef de projet valide le développement, tandis que le prestataire l’exécute. Le marketing réalise et approuve les contenus : le cumul A/R est possible lorsque l’organisation autorise cette autonomie. Le tiret indique qu’aucune participation particulière n’est attendue. Il n’est pas nécessaire de remplir toutes les cases.
Pour rendre ce modèle opérationnel, associez chaque ligne à un livrable identifiable, à une échéance et à des critères d’acceptation dans votre outil de suivi. Pour la recette, précisez par exemple les parcours à tester et la manière de traiter les anomalies. Une lettre A ne suffit pas à définir ce qu’est un résultat acceptable.
Éviter les blocages et maintenir les responsabilités à jour
Une matrice cohérente respecte deux règles : au moins un R et un seul A par tâche. Plusieurs réalisateurs peuvent contribuer, mais leurs contributions doivent être explicites. Si deux approbateurs semblent indispensables, vérifiez si la ligne rassemble deux décisions différentes et doit être divisée.
- Lisez chaque ligne : qui produit, qui valide, quels avis sont indispensables ?
- Lisez chaque colonne : une même personne concentre-t-elle trop de réalisations ou d’approbations ?
- Réduisez les consultations : un C doit apporter une expertise utile, pas simplement souhaiter suivre le sujet.
- Organisez les validations : convenez des délais de réponse et de la procédure en cas d’absence.
Un grand nombre de A dans une colonne signale un risque de goulot d’étranglement, mais ne mesure pas à lui seul la charge : une validation complexe peut demander davantage d’effort que plusieurs accords courants. En cas de désaccord entre R et A, utilisez les critères d’acceptation convenus, puis le circuit d’arbitrage du projet si nécessaire.
Confiez la maintenance du document à une personne identifiée, généralement le chef de projet. Réexaminez-le lorsqu’un acteur change, qu’un livrable apparaît ou que le périmètre évolue. La version partagée doit rester la référence : une répartition connue seulement dans un ancien compte rendu ne protège pas l’équipe des malentendus.
RACI, RASCI ou simple répartition : choisir sans alourdir
RACI rend les responsabilités visibles, facilite la délégation et aide à repérer les oublis ou les chevauchements. Il ne crée cependant ni compétence, ni disponibilité, ni autorité. Une matrice imposée sans discussion peut donner une impression de clarté tout en laissant les désaccords intacts.
La RAM, pour Responsibility Assignment Matrix, désigne la famille des matrices d’attribution des responsabilités : RACI en est un type. RASCI ajoute un rôle S, Support, pour les acteurs qui assistent concrètement le réalisateur. Cette variante est utile lorsque l’aide opérationnelle doit être distinguée d’un simple avis d’expert.
Dans une petite équipe sur un projet simple, une liste de livrables avec leur responsable et leur validateur peut suffire. En environnement Agile, réservez plutôt le RACI aux interfaces entre équipes, aux décisions transverses ou aux obligations de validation. L’objectif reste de clarifier les engagements sans figer la collaboration ni soumettre chaque geste quotidien à une approbation.