Aller au contenu
gorkha.io

RACI, DACI ou RAPID : ce dont votre équipe a vraiment besoin

Trois cadres de responsabilité, trois problèmes différents. Ce que chacun a été conçu pour corriger, où chacun échoue, et un test court pour choisir entre eux.

L’équipe Gorkha11 min de lecture

Matrice RACI → Désignez qui réalise, approuve, est consulté et est informé pour chaque tâche, et repérez les manques.

Il existe un type de réunion bien particulier qui révèle qu’une équipe a un problème de droits de décision. Un choix a été fait il y a six semaines. Quelqu’un qui n’était pas dans la salle a depuis soulevé une objection, et le choix est en train d’être refait, avec un autre groupe, depuis le début. Personne ne se comporte de façon déraisonnable. Il n’y a simplement jamais eu d’accord sur qui avait le droit de décider.

Trois cadres existent pour éviter cette réunion : RACI, DACI et RAPID. Ils ont l’air interchangeables (quatre ou cinq lettres, des personnes placées sur des rôles) et les équipes choisissent plus ou moins au hasard, généralement selon ce qu’un employeur précédent utilisait. Ils ne sont pas interchangeables. Chacun a été bâti contre un échec différent, et utiliser le mauvais produit un document qui, au mieux, est une occupation.

Les trois échecs

Il est utile de nommer l’échec contre lequel chaque cadre a été conçu, car c’est ce qui les distingue réellement.

RACI est pour un travail continu et réparti. Son mode d’échec est la propriété diffuse sur de nombreuses tâches, le projet où vingt choses sont en cours et où plusieurs se révèlent, tard, n’avoir appartenu à personne.

DACI est pour une décision unique. Son mode d’échec est la décision qui ne se referme jamais, le choix qui reste ouvert parce que personne n’avait convenu à l’avance qui le trancherait.

RAPID est pour une décision importante et transverse dans une grande organisation. Son mode d’échec est la décision prise puis défaite, celle où quelqu’un disposant d’un vrai droit de veto a été traité comme un conseiller, a découvert le résultat après coup et l’a rouvert.

Si vous pouvez nommer lequel de ces trois se produit dans votre équipe, vous avez déjà choisi votre cadre.

RACI : une carte du travail continu

RACI attribue quatre rôles à chaque tâche : Responsible (fait le travail), Accountable (en répond, exactement une personne), Consulted (est consulté avant la fin) et Informed (est prévenu après). Le Project Management Institute traite le diagramme RACI comme un exemple de matrice d’affectation des responsabilités, la famille générale de grilles qui placent des personnes sur des lots de travail.

Sa forme dit à quoi elle sert : une grille, beaucoup de lignes, beaucoup de colonnes. Elle décrit un corps de travail dans le temps, pas un instant. Une mise en production, une migration, une phase de chantier, un audit.

Là où ça marche. Chaque fois que la question est « dans tout ça, qui fait quoi ? ». La forme matricielle rend visibles deux choses que la prose ne peut pas : la ligne sans porteur accountable, et la colonne avec un porteur accountable sur chaque ligne, le goulot d’étranglement dont tout le monde se plaint et que personne ne peut désigner.

Là où ça échoue. RACI n’a aucune notion de quand. Elle dit que le responsable QA est responsible des tests ; elle ne dit rien sur le fait que les tests aient lieu avant ou après la validation. Elle se dégrade aussi mal avec le détail : à quarante lignes d’activités individuelles, elle devient un document que personne n’entretient, et une matrice non entretenue est pire que pas de matrice, parce que les gens s’y fient.

Et elle est vraiment mauvaise pour les décisions uniques. On peut en forcer une (une ligne, des lettres dessus) mais le vocabulaire est faux. « Consulté » ne distingue pas entre quelqu’un dont l’avis est bienvenu et quelqu’un qui peut vous bloquer.

DACI : une décision, refermée

DACI remplace les lettres par quatre rôles tournés vers un choix : Driver (coordonne le processus de décision et le fait avancer), Approver (tranche, une personne), Contributors (apportent expertise et analyse) et Informed (sont prévenus du résultat). Atlassian le publie comme play de son Team Playbook et l’utilise en interne.

Le geste important est de séparer Driver d’Approver. Dans RACI, on suppose souvent que la personne accountable est aussi celle qui pousse le processus. DACI dit que ce sont deux métiers différents, et sur une vraie décision c’est généralement le cas : une product manager mène le processus, une direction tranche.

Là où ça marche. Toute décision avec une échéance et plus de trois personnes qui ont un avis. Choisir un fournisseur. Trancher entre deux architectures. Fixer une date de lancement. L’artefact est un document d’une page, pas une grille, et il se termine par une décision écrite et une date.

Là où ça échoue. DACI n’a pas de vocabulaire pour le veto. Tous ceux qui ne sont pas l’Approver sont Contributors, qu’il s’agisse d’un ingénieur serviable ou de la directrice juridique qui peut tout arrêter. Dans une petite organisation, cette distinction peut rester informelle. Dans une grande, c’est exactement ce qui explose plus tard.

Il est aussi inadapté au travail continu. Un DACI par décision, très bien ; quarante DACI décrivant un projet, ce n’est pas un plan.

RAPID : des droits de décision dans une grande organisation

RAPID®, développée par Bain and Company et popularisée par l’article de 2006 de la Harvard Business Review « Who Has the D? » de Paul Rogers et Marcia Blenko, attribue cinq rôles : Recommend (fait l’analyse et propose), Agree (doit donner son accord, un véritable veto), Perform (exécute la décision), Input (est consulté, sans veto) et Decide (la seule personne qui engage l’organisation).

Deux choses la rendent différente, et les deux viennent des organisations pour lesquelles elle a été bâtie.

D’abord, Agree est séparé d’Input. C’est tout l’enjeu. La plupart des cadres ont un seul panier pour « les gens qu’on consulte ». RAPID le scinde entre les personnes dont l’accord est requis et celles dont l’avis est souhaité, et vous force à dire qui est qui à l’avance. C’est le contrôle qui empêche les décisions d’être défaites.

Ensuite, Perform est un rôle nommé dans la décision elle-même. Les personnes qui vont devoir vivre avec le choix sont identifiées pendant qu’il se fait, ce qui tend à améliorer le choix.

Là où ça marche. Les décisions importantes et transverses dans des organisations assez grandes pour avoir un vrai pouvoir de veto fonctionnel, la tarification, l’entrée sur un marché, un engagement de plateforme. C’est la plus précise des trois.

Là où ça échoue. C’est lourd. Faire un RAPID sur une décision qu’une personne aurait pu prendre en dix minutes est une taxe, et les équipes qui l’adoptent partout cessent vite de l’utiliser nulle part. Dans une entreprise de douze personnes, le rôle Agree se confond généralement avec le rôle Decide, et vous entretenez alors un cadre à cinq lettres pour exprimer une situation à deux.

Côte à côte

RACIDACIRAPID
Conçu pourTravail continuUne décisionUne décision importante
FormeGrille de nombreuses tâchesDocument d’une pageDocument d’une page
Porteur uniqueAccountableApproverDecide
Le veto est expliciteNonNonOui (Agree)
Qui fait le travailResponsibleNon traitéPerform
Pilote du processus nomméNonOui (Driver)Recommend, en pratique
Taille typique6 à 20 lignes1 décision1 décision
Faible surDécisions uniques, séquenceDroits de veto, travail continuPetites équipes, petites décisions

Choisir, en trois questions

1. Est-ce un corps de travail ou un choix ? Un corps de travail veut dire RACI. Un choix veut dire DACI ou RAPID. Cette seule question règle la plupart des cas, et les équipes se trompent étonnamment souvent, en général en construisant une RACI pour quelque chose qui était une décision déguisée en projet.

2. Quelqu’un hors de la salle peut-il arrêter ça ? Si oui, et que vous ne pouvez pas simplement lui demander de décider, il vous faut RAPID, parce qu’il vous faut le rôle Agree. Si non, DACI est plus léger et sera réellement utilisé.

3. Quelqu’un le lira-t-il dans trois mois ? Si non, n’en construisez aucun. Écrivez qui décide, en une phrase, dans le document où vit le travail. Les cadres servent quand la réponse doit survivre au contact de gens qui n’étaient pas là.

Ce qu’aucun ne corrige

Il vaut la peine d’être franc là-dessus, car ces cadres sont vendus comme des remèdes à des problèmes qu’ils ne touchent pas.

Ils ne créent pas d’autorité. Écrire le nom de quelqu’un sous Accountable, Approver ou Decide ne lui donne pas le pouvoir de décider. Si cette personne ne peut pas dire non et le faire tenir, le document décrit une organisation qui n’existe pas. La bonne réaction est de mettre dans la case le nom de celle qui peut dire non, même quand c’est politiquement inconfortable, cet inconfort est l’information.

Ils ne remplacent pas une décision. Une matrice terminée n’est pas une décision ; c’est un accord sur qui en prend une. Il arrive que des équipes terminent le cadre, ressentent un progrès, et ne tranchent jamais.

Et ils ne survivent pas à l’abandon. Les trois sont des instantanés. Attachez-les au document qu’ils gouvernent et revoyez-les quand vous revoyez ce document. L’échec n’est jamais spectaculaire, personne n’annonce que la matrice est désormais fausse. Elle cesse simplement, en silence, de correspondre à la réalité, et puis quelqu’un s’appuie dessus.

Les utiliser

Les quatre variantes (RACI, RASCI, DACI et RAPID) sont des modes du même document dans le constructeur de matrice RACI. Changer de mode conserve vos lignes et renomme les lettres : il ne coûte donc rien d’essayer une décision en DACI puis en RAPID pour voir quel vocabulaire colle à ce qui se passe réellement.

Si vous construisez la vôtre pour la première fois, la méthode est dans comment construire une matrice RACI, y compris l’astuce d’ordre qui fait remonter les désaccords au début plutôt qu’à la fin.

Sources

  1. Who Has the D? How Clear Decision Roles Enhance Organizational Performance, Harvard Business Review, Paul Rogers et Marcia Blenko, janvier 2006
  2. RAPID: Bain’s decision-making tool, Bain and Company
  3. DACI: a framework for group decisions, Atlassian Team Playbook
  4. Stakeholder management and the RACI matrix, Project Management Institute