DACI
Clarifiez qui décide quoi. Le framework DACI attribue 4 rôles sur chaque décision produit pour éliminer les blocages et accélérer les arbitrages.
Description
Le framework DACI est une matrice de prise de décision qui attribue quatre rôles distincts, Driver, Approver, Contributor et Informed, à chaque décision stratégique ou opérationnelle d'une équipe produit. Sa finalité : remplacer l'ambiguïté collective par une gouvernance explicite, où chacun sait exactement quel est son niveau d'influence réel sur l'arbitrage final. Sans ce cadre, la prise de décision en équipe ressemble à une réunion sans ordre du jour : tout le monde parle, personne ne tranche. Le DACI corrige ce dysfonctionnement structurel en distinguant deux rôles que les organisations confondent systématiquement, celui qui pilote le processus décisionnel (le Driver) et celui qui détient l'autorité de décision finale (l'Approver). Cette distinction n'est pas cosmétique : un Chef de Produit peut être Driver d'une décision de lancement sans en être l'Approver. Les Contributors, experts métier consultés pour leur connaissance, ont une voix mais pas un vote. Les parties Informées reçoivent la décision, elles n'y participent pas. À l'origine développé par Intuit dans les années 1980 comme alternative au RACI, le DACI a été popularisé à grande échelle par Atlassian via son Team Playbook. Là où le RACI répond à la question "qui fait quoi", le DACI répond à "qui décide quoi", un glissement sémantique qui change tout dans un contexte produit. Comme un tribunal qui distingue clairement le rôle du juge, des avocats et du jury, le DACI sépare ceux qui éclairent la décision de celui qui la rend, pour que le verdict soit rendu et non éternellement débattu.
Objectifs
- Identifier les problèmes
- Améliorer la collaboration d'équipe
- Assurer l'alignement stratégique
- Assurer l'alignement stratégique
Utilisé par
- -Intuit(créateur originel du framework dans les années 1980, adapté du RACI pour la prise de décision produit)
- -Atlassian(intégration dans le Team Playbook et popularisation dans l'écosystème Agile et Product Management)
Avantages
- Décisions sans ambiguïté. Chaque décision a un propriétaire clair : fini les discussions circulaires où personne ne tranche.
- Réduction du consensus mou. Le rôle de Contributor donne une voix sans donner un veto, ce qui fluidifie les arbitrages sans exclure les experts.
- Scalabilité sur les équipes distribuées. Le DACI fonctionne aussi bien en synchrone qu'en asynchrone, ce qui le rend efficace pour les équipes remote ou cross-fonctionnelles.
- Alignement post-décision. Les parties Informed reçoivent le contexte, pas seulement le résultat : les décisions sont mieux comprises et moins contestées.
Limites
- Résistance dans les cultures hiérarchiques. Si l'organisation valorise le consensus avant la vitesse, la règle du "un seul Approver" peut être perçue comme autoritaire. Un travail de change management est souvent nécessaire.
- Peu adapté aux décisions complexes multicritères. Pour des arbitrages à fort enjeu nécessitant une analyse quantitative, compléter avec une matrice de priorisation ou un scoring RICE.
- Risque de sur-administration. Appliquer le DACI à toutes les micro-décisions quotidiennes crée de la bureaucratie. Réservez-le aux décisions structurantes et transversales.
Comment appliquer DACI
- 1
Cartographier les décisions en suspens
Listez toutes les décisions bloquées ou en cours dans votre cycle produit actuel (roadmap, priorisation, lancement, pivot). Sélectionnez les 3 à 5 les plus critiques pour initier le DACI. Output : liste de décisions prioritaires à clarifier.
- 2
Nommer un seul Driver par décision
Désignez la personne qui va piloter le processus : collecter les informations, organiser les échanges et garantir qu'une décision sera prise dans les délais. Le Driver n'est pas nécessairement le décideur, c'est l'orchestrateur. Output : nom du Driver clairement désigné.
- 3
Identifier un seul Approver
Nommez l'unique personne habilitée à prendre la décision finale. La règle du "un seul Approver" est non négociable : deux Approvers créent un co-veto qui paralyse le processus. Si vous êtes tenté d'en nommer deux, c'est que vous avez deux décisions distinctes à clarifier. Output : Approver validé et acté.
- 4
Lister les Contributors
Identifiez les experts métier dont l'avis est nécessaire à une décision éclairée (Tech Lead, Designer, Sales, Legal...). Limitez-vous à 3-5 personnes : au-delà, vous créez une réunion de consensus, pas un processus décisionnel. Output : liste de Contributors avec leur domaine d'expertise.
- 5
Définir les parties Informed
Listez les personnes et équipes qui doivent être notifiées de la décision une fois prise, car leur travail en dépend. Elles n'ont ni voix ni vote dans le processus. Output : liste des parties à informer, avec le canal et le format de communication.
- 6
Documenter la matrice DACI
Centralisez les rôles dans un tableau partagé (Notion, Confluence, Miro) : décision, Driver, Approver, Contributors, Informed. Ce document devient la référence officielle et évite les incompréhensions a posteriori. Output : matrice DACI accessible à tous.
- 7
Collecter les inputs des Contributors
Le Driver organise les échanges nécessaires (réunion, async, Slack) pour que chaque Contributor soumette son analyse ou recommandation à l'Approver. Fixez une deadline claire et non négociable. Output : recommandations compilées et transmises à l'Approver.
- 8
Trancher et communiquer
L'Approver prend la décision finale, en explicitant si possible le raisonnement qui l'a guidée. Le Driver diffuse la décision aux parties Informed avec le contexte nécessaire pour qu'elles puissent agir. Output : décision actée, communiquée et documentée.