RASCI : définition et exemple de matrice pour une équipe produit

RASCI : la définition

RASCI est une matrice qui attribue, pour chaque activité ou décision, un rôle à chaque personne concernée. Le sigle reprend les cinq rôles :

• R, Responsible : la ou les personnes qui réalisent le travail.
• A, Accountable : la personne qui répond du résultat et tranche. Une seule par activité.
• S, Support : les personnes qui apportent une aide ou des ressources au responsable.
• C, Consulted : les personnes dont l’avis est demandé avant la décision.
• I, Informed : les personnes tenues au courant après la décision.

La matrice RACI, plus répandue, est la même sans le S. Le rôle de support est utile dans les petites équipes, où une même personne aide sur de nombreux sujets sans en être responsable.

L’intérêt de la méthode tient en un mot : la clarté. Chacun sait ce qu’il doit faire, et surtout ce dont il n’est pas responsable.

RACI ou RASCI ?

Prenez RACI si les contributions annexes sont rares et que la matrice doit rester très lisible. Prenez RASCI dès qu’une même personne ou une même équipe aide sur beaucoup de sujets sans en porter aucun : un designer partagé, une équipe data transverse, un juriste sollicité ponctuellement. Sans le S, ces personnes finissent classées en R par défaut, et l’on ne sait plus qui fait vraiment le travail.

Le problème qu’elle résout

Scène classique : un commercial discute avec un développeur d’une fonctionnalité qu’un client réclame. La conversation est saine, on ne veut pas de silos. Mais sans rôles clairs, elle devient une demande officielle que le développeur priorise au détriment de la roadmap. Le product manager doit ensuite expliquer pourquoi ce n’est pas la priorité. Le commercial se sent ignoré, le développeur se sent simple exécutant.

La même scène se produit avec un dirigeant qui impose une demande à l’équipe technique. Chaque fois, la roadmap perd en crédibilité.

J’ai découvert RASCI chez TIAO, quand une définition floue de mon rôle de product manager créait des tensions. Nous l’avons utilisée pour clarifier les rôles du CEO, du CTO, du product manager et des développeurs. Les tensions ne disparaissent pas, mais elles se règlent vite, parce qu’on sait qui tranche.

Exemple de matrice pour une équipe produit

Comment la lire

La roadmap : le product manager la construit et en répond. Il doit consulter les développeurs, et peut leur demander du soutien pour décrire la partie technique. Elle est publique, donc tout le monde est informé.

Le développement : les développeurs réalisent, le product manager répond du résultat. C’est lui qui formule la demande et la priorise. Il peut être sollicité en support, par exemple pour des maquettes, et consulté en cas de doute sur l’implémentation.

La technique : les choix de stack et la maintenance relèvent du CTO. Le product manager est consulté si l’expérience utilisateur risque d’être affectée. Je n’irai jamais expliquer aux développeurs comment gérer leur stack ; ils iront rarement prioriser la roadmap à ma place.

Construire la matrice en un atelier

Une matrice se construit en une heure à une heure et demie, avec les personnes qui y figurent. Le déroulé que j’utilise :

1. Lister les activités qui créent des frictions aujourd’hui, pas toutes les activités de l’entreprise. Dix à quinze lignes suffisent.
2. Attribuer les A d’abord, ligne par ligne. C’est là que se concentrent les désaccords, et c’est là qu’il faut passer le temps.
3. Puis les R, en vérifiant que chaque R a la capacité de faire le travail.
4. Puis les C et les S, en se demandant à chaque fois si l’avis de cette personne peut changer la décision.
5. Les I en dernier, souvent par équipe plutôt que par personne.
6. Relire à voix haute chaque ligne litigieuse avec un cas récent : « la semaine dernière, qui aurait dû trancher ? »

Le dernier point est le plus utile. Une matrice qui ne résiste pas à un cas réel ne résistera pas au suivant.

Les règles pour qu’elle serve

1. Un seul A par ligne. Deux personnes qui répondent du résultat, c’est personne.
2. Des activités concrètes, pas des domaines vagues comme « le produit ».
3. Peu de C. Consulter tout le monde ralentit tout. Réservez ce rôle à ceux dont l’avis change la décision.
4. Construite ensemble, pas imposée : la discussion est aussi utile que le tableau.
5. Revue quand l’organisation change : arrivée d’une personne, nouveau produit, levée de fonds.

Dans une jeune entreprise, chacun porte plusieurs casquettes, et c’est normal. C’est justement pour cela que la matrice est utile : elle rend visibles les casquettes, et évite qu’elles se superposent.

Petite équipe ou grande organisation

Dans une équipe de moins de quinze personnes, une seule matrice suffit, sur une page, revue deux fois par an. Les noms y figurent directement. Dans une organisation plus grande, raisonnez par rôle plutôt que par nom (« responsable produit », « équipe data »), et tenez une matrice par périmètre : un produit, un processus, un système. Une matrice unique pour toute l’entreprise devient illisible et personne ne la consulte.

Les erreurs fréquentes, et comment les repérer

• Des A en cascade. Le même directeur est A sur toutes les lignes. Signal : il devient le goulet d’étranglement de toutes les décisions, et les projets attendent son agenda.
• Des lignes sans A. Signal : la question « qui décide ? » reçoit une réponse au pluriel, ou un nom d’instance (« le comité »).
• Des C partout. Signal : chaque décision demande une réunion, et les délais s’allongent sans que la qualité progresse.
• Des R sans capacité. Signal : la même personne est R sur une dizaine de lignes et ne livre rien à temps.
• Une matrice figée. Signal : elle mentionne une personne partie depuis six mois.

Une matrice pour un système IA en production

Un système IA en production pose la question des rôles de façon aiguë. Qui répond d’une mauvaise réponse donnée à un client ? Qui décide de faire évoluer le modèle ? Qui tient l’inventaire nécessaire à la conformité AI Act ? Dans les projets qui stagnent, la réponse est souvent « personne en particulier ».

Exemple fictif, construit sur le cas d’un assistant IA qui répond aux demandes des clients d’un service support, avec reprise par un agent humain quand il ne sait pas.

Comment la lire

Les sorties du modèle ont un A métier. Le responsable du service client répond de la qualité des réponses, pas l’équipe data. C’est lui qui subit les conséquences d’une mauvaise réponse, c’est donc lui qui fixe le seuil acceptable et qui peut demander l’arrêt.

Les données ont un S identifié. Les experts métier qui rédigent les contenus de la base de connaissances sont en support : sans eux, l’équipe data ne peut pas corriger une réponse fausse, seulement la masquer.

La conformité est consultée, pas contournée. Juridique et DPO sont C sur les lignes qui touchent aux données personnelles et à la classification. Leur avis peut changer la décision, c’est la définition même du C.

Les équipes terrain sont informées des évolutions. Un changement de prompt qui modifie le ton ou le périmètre des réponses doit être connu des agents avant que les clients ne le découvrent.

Remarquez qu’aucun A n’est attribué à un outil ou à un agent automatique. Un système peut exécuter, il ne répond pas du résultat. C’est l’une des traductions les plus concrètes de la thèse que je défends : une transformation IA réussie est d’abord, à 70 %, une transformation organisationnelle. J’y reviens dans du POC IA à la production, et les indicateurs qui permettent à l’A de juger la qualité sont détaillés dans mesurer un assistant IA de support.

Garder la matrice vivante

Une matrice IA se périme plus vite qu’une matrice produit, parce que le système change souvent. Cinq règles :

1. Un propriétaire de la matrice, généralement le responsable produit, chargé de la tenir à jour.
2. Des déclencheurs de revue écrits : changement de modèle ou de fournisseur, nouvel usage, nouvelle source de données, réorganisation.
3. Une question systématique en analyse d’incident : qui était A, et a-t-il été prévenu à temps ? Si la réponse hésite, la matrice est à revoir.
4. Une date de dernière revue visible en haut du document.
5. Un lien avec le registre AI Act : chaque système inventorié pointe vers sa matrice, et inversement.

Avec le recul

Quand j’ai écrit cet article en 2022, je voyais RASCI comme un outil de startup pour régler des tensions entre quelques personnes. Je le vois aujourd’hui comme l’un des outils les plus utiles d’un projet IA, et de loin le moins coûteux.

Ce que je garde

Un seul A par ligne, et une matrice construite ensemble. Sur un système qui répond directement à des clients, comme celui que nous avons déployé pour le contact center de Home Partners of America, la question « qui répond de la réponse donnée ? » n’est jamais secondaire. Elle se règle avant la mise en production, pas après le premier incident.

Ce que je nuance

J’écrivais qu’il fallait réserver le C à peu de personnes. C’est toujours vrai, avec une exception : sur un système IA, la conformité et la protection des données doivent être consultées tôt, même si cela ralentit. Les découvrir tard coûte bien plus qu’une réunion de plus.

Je nuance aussi l’idée qu’une même personne peut sans difficulté tenir R et A. Sur un sujet produit, oui. Sur la qualité d’un système IA, je préfère séparer : l’équipe qui construit n’est pas la mieux placée pour juger seule si le résultat est acceptable pour les clients.

Ce que les assistants IA ont changé

Les assistants accélèrent le travail des R : rédiger, synthétiser, prototyper. Ils ne prennent aucun rôle dans la matrice. Une synthèse produite par un assistant a toujours un R humain qui l’a relue, et un A qui en répond. C’est la règle que je transmets en formation : vérifier les sorties, et savoir qui les signe. Pour démarrer avec une équipe, le guide premiers usages de l’IA en équipe reprend cette logique.

Le reste n’a pas changé. Les tensions viennent rarement de la technique ; elles viennent de rôles flous. C’est le cœur des 70 % organisationnels.

Questions fréquentes

Quelle différence entre Responsible et Accountable ?

Le Responsible fait le travail ; l’Accountable répond du résultat et tranche en cas de désaccord. Une même personne peut tenir les deux rôles, mais il n’y a jamais plus d’un Accountable par activité.

Peut-on avoir plusieurs Responsible sur une activité ?

Oui, plusieurs personnes peuvent réaliser le travail. C’est le rôle Accountable qui doit rester unique, pour qu’il y ait toujours quelqu’un qui décide.

Où tenir la matrice RASCI ?

Là où l’équipe travaille déjà : dans l’outil de gestion de projet ou dans la documentation partagée, à côté de la roadmap. Une matrice rangée dans un dossier oublié ne règle aucun conflit.

Qui doit être Accountable pour un système IA en production ?

Le responsable métier qui subit les conséquences des réponses du système, par exemple le responsable du service client pour un assistant de support. L’équipe technique est Responsible de la construction, pas du résultat pour les clients.

À quelle fréquence revoir la matrice ?

À chaque changement d’organisation, de modèle ou d’usage, et au moins deux fois par an. Une analyse d’incident où personne ne sait qui était Accountable est le signal qu’elle est périmée.