Dans un projet, les retards viennent rarement d’un manque d’idées ; ils viennent plus souvent d’un flou sur qui décide, qui exécute et qui doit être consulté. La matrice RACI répond précisément à ce problème : elle rend visibles les rôles et les responsabilités, ce qui devient vite décisif dès qu’un projet implique plusieurs équipes, des métiers et l’IT. Dans cet article, je détaille son fonctionnement, les cas où elle apporte vraiment de la valeur, la méthode pour la construire et les erreurs qui la font dérailler.
Les points à garder en tête avant de l’intégrer à votre gouvernance
- Un seul acteur doit être A par tâche ou livrable ; sinon, la validation se dilue.
- Le tableau fonctionne surtout sur les projets transverses, multi-équipes ou multi-sponsor.
- Je préfère l’écrire avec des rôles, pas avec des noms, pour éviter de le refaire à chaque mouvement d’équipe.
- Au-delà d’environ 20 à 30 lignes, il vaut mieux le découper par lot, phase ou chantier.
- RACI clarifie l’exécution et la responsabilité ; pour les décisions, DACI ou RAPID peuvent être plus adaptés.
- La vraie valeur n’est pas dans le tableau lui-même, mais dans le dialogue qu’il impose au cadrage.
À quoi sert le tableau RACI dans un projet
Je le vois comme un outil de clarification, pas comme une formalité de gouvernance. Son intérêt est simple : sur chaque tâche, jalon ou livrable, il précise qui fait quoi, qui porte la validation finale, qui est consulté et qui doit être tenu informé. C’est particulièrement utile quand les responsabilités se chevauchent entre chef de projet, sponsor, métiers, DSI, prestataires et sécurité.
| Lettre | Rôle | Ce que cela signifie concrètement |
|---|---|---|
| R | Responsible | La personne ou l’équipe qui réalise le travail ou produit le livrable. |
| A | Accountable | Le redevable final, celui qui valide et assume le résultat. Je recommande de n’en garder qu’un seul par ligne. |
| C | Consulted | Les experts ou parties prenantes dont l’avis est utile avant décision. |
| I | Informed | Les personnes qui doivent être tenues au courant, sans participer activement à la décision. |
En français, je préfère souvent traduire A par “redevable” plutôt que par “responsable”, parce que le mot responsable crée vite de la confusion avec R. Cette nuance est minuscule en apparence, mais elle évite beaucoup de malentendus au moment des arbitrages. Et comme le rappelle le PMI, ce type de tableau doit idéalement être posé dès la phase de planification, pas quand les blocages ont déjà commencé. Reste à voir dans quels contextes il apporte réellement quelque chose.
Quand il apporte vraiment de la clarté
Je réserve RACI aux situations où les zones grises coûtent cher. Dans un petit projet très resserré, une discussion orale suffit souvent ; dans un projet transversal, elle ne suffit plus. Le tableau devient utile dès qu’il faut aligner plusieurs métiers, plusieurs sites, un prestataire externe ou plusieurs niveaux de validation.
| Contexte | Intérêt du tableau | Mon avis |
|---|---|---|
| Projet transverse IT / métiers | Réduit les allers-retours et les “ce n’était pas à moi de le valider”. | Très pertinent. |
| Déploiement d’un outil numérique | Clarifie les interfaces entre intégration, sécurité, conduite du changement et recette. | Très pertinent. |
| Projet simple avec 2 ou 3 personnes | Apporte peu si tout le monde se parle déjà en continu. | Souvent inutile. |
| Projet surtout centré sur des décisions complexes | Éclaire moins bien l’arbitrage que l’exécution. | Je regarde plutôt DACI ou RAPID. |
La bonne question n’est donc pas “faut-il faire un tableau RACI ?”, mais “ai-je un risque réel de confusion entre exécution, validation et information ?”. Si la réponse est oui, l’outil est pertinent. Si la réponse est non, il risque surtout d’ajouter de la paperasse. Une fois le bon contexte identifié, la vraie difficulté est de le construire sans le rendre lourd.
Comment le construire sans le transformer en usine à gaz
Je recommande de partir des livrables majeurs, pas des micro-actions. Si vous descendez trop bas dans le détail, le tableau devient illisible et personne ne l’ouvre plus. À l’inverse, si vous restez trop haut niveau, il ne sert à rien.
- Lister les livrables, jalons ou décisions à cadrer en priorité.
- Identifier les rôles plutôt que les personnes : sponsor, chef de projet, DSI, RSSI, métier, prestataire, etc.
- Attribuer un seul A par ligne, puis un ou plusieurs R si nécessaire.
- Limiter les C aux vrais experts ou valideurs utiles ; tout le monde n’a pas besoin d’être consulté.
- Réduire les I au strict nécessaire pour éviter l’effet “copie carbone”.
- Valider le tableau avec l’équipe avant de le figer dans le cadrage ou la charte projet.
- Le revoir à chaque changement de périmètre, de gouvernance ou d’équipe.
Mon seuil pratique est simple : si la matrice dépasse 20 à 30 lignes, je la scinde par phase, lot ou chantier. Sinon, elle devient un bloc trop dense pour être utile. Et je l’intègre volontiers au document de cadrage ou au plan de communication, parce qu’elle sert de référence commune. Pour voir à quoi cela ressemble concrètement, prenons un cas de projet numérique.
Exemple concret sur un projet de transformation numérique
Imaginons une refonte d’intranet collaboratif dans une entreprise française. Le projet touche l’IT, les métiers, la sécurité, l’expérience utilisateur et la communication interne. Sans cadre de responsabilités, les points de friction arrivent très vite : qui valide l’arborescence ? Qui tranche sur la sécurité ? Qui signe la recette ?| Livrable ou décision | Sponsor | Chef de projet | Métier | DSI | RSSI | UX |
|---|---|---|---|---|---|---|
| Cadrage fonctionnel | A | R | C | I | I | C |
| Choix de l’architecture cible | I | C | I | A | C | I |
| Validation sécurité | I | C | I | R | A | I |
| Recette utilisateur | I | C | A | I | I | R |
| Go-live | A | R | C | R | C | I |
Ce type de lecture est précieux parce qu’il montre immédiatement où se trouvent les arbitrages. Par exemple, la sécurité n’est pas “juste consultée” si son feu vert conditionne la mise en production ; elle devient alors un acteur redevable sur ce point. C’est exactement ce que j’attends d’un bon tableau : qu’il rende visibles les points de passage obligés, pas qu’il aligne des initiales. Une fois cela posé, il reste à éviter les erreurs classiques.
Les erreurs que je vois le plus souvent
La première erreur, c’est de mettre trop de responsables. Dès qu’une ligne a trois ou quatre A implicites ou plusieurs personnes censées “porter” la même validation, l’outil perd sa fonction. La deuxième, c’est de vouloir consulter tout le monde sur tout. Résultat : les décisions ralentissent et les acteurs importants ne savent plus où concentrer leur énergie.
- Confondre R et A : celui qui exécute n’est pas forcément celui qui signe.
- Utiliser des noms à la place des rôles : le tableau devient obsolète dès qu’une personne change.
- Multiplier les C : on finit avec une pseudo-consultation générale qui ne tranche rien.
- Remplir la matrice après coup : elle doit servir au cadrage, pas à justifier l’existant.
- Ne jamais la réviser : un projet change, donc la responsabilité doit parfois évoluer aussi.
Je conseille un test simple : si une personne lit la ligne d’un livrable et ne comprend pas quand elle doit agir, la matrice est mal écrite. Si, au contraire, elle peut dire en dix secondes qui fait quoi et qui valide, elle joue son rôle. Et quand les besoins deviennent plus orientés “qui décide ?”, il faut parfois passer à une variante mieux adaptée.
Quand choisir RASCI ou DACI à la place
Il ne faut pas traiter RACI comme une réponse universelle. Pour certaines équipes, une variante fait mieux le travail. J’utilise surtout cette logique : RACI pour les tâches et livrables, DACI pour les décisions, RASCI quand le support doit être explicite.
| Modèle | Ce qu’il clarifie le mieux | Quand je le privilégie | Limite |
|---|---|---|---|
| RACI | Rôles, exécution, validation, consultation, information. | Projets transverses, livrables multiples, gouvernance classique. | Peut rester flou sur les mécanismes de décision s’ils sont nombreux. |
| RASCI | Ajoute la notion de support. | Quand une équipe d’appui intervient souvent sans être consultée formellement. | Ajoute une couche de complexité si le support est déjà clair dans l’organisation. |
| DACI | Le circuit d’arbitrage. | Quand le sujet principal est “qui tranche ?” plutôt que “qui fait ?”. | Moins utile pour détailler les responsabilités opérationnelles. |
Cornell rappelle d’ailleurs que RASCI ajoute un rôle de support lorsqu’il faut expliciter l’aide apportée par certaines équipes sans leur donner de responsabilité formelle. C’est une nuance utile, mais je ne la sors que si elle résout un vrai problème de gouvernance. Mon principe est simple : ne complexifiez pas le modèle si le problème de départ est déjà bien traité par RACI. Pour finir, voici la manière la plus pragmatique de l’utiliser dès le prochain cadrage.
Ce que je recommande pour l’utiliser dès le prochain cadrage
Si je n’avais qu’une heure pour sécuriser un projet, je ferais trois choses : je listerais les 5 à 10 livrables qui créent le plus de risques, j’identifierais un seul redevable par ligne, puis je validerais le tableau en réunion de lancement avec les acteurs clés. C’est court, mais c’est souvent suffisant pour lever les ambiguïtés les plus coûteuses.
Je recommande aussi de conserver la matrice au même endroit que la charte projet ou le plan de gouvernance, afin qu’elle ne devienne pas un document oublié dans un dossier partagé. Et surtout, je la traite comme un outil vivant : si le périmètre, les équipes ou les arbitrages changent, je la mets à jour sans attendre la fin du projet. Utilisée de cette façon, elle ne produit pas de bureaucratie ; elle réduit les frictions, accélère les décisions et donne au projet une structure beaucoup plus lisible.
