Arrêtez de Chercher des Boucs Émissaires—Utilisez un Tableau RACI (avec Suze Haworth)

Lisez la transcription :

Nous testons la retranscription automatique de nos podcasts via un logiciel. Merci de pardonner d’éventuelles fautes, car l’outil n’est pas fiable à 100 %.

Ben Aston :

L’un des aspects les plus délicats de la gestion de projet, c’est que nous devons travailler avec… eh bien, des personnes, et les personnes sont d’une variabilité incroyable. Nous sommes inconstants, égocentriques, peu fiables, parfois instables, et je ne parle que de moi-même. Je me demande si vos projets ressemblent aux miens. Quand ça tourne mal — et ça arrive toujours à un moment — cela peut vite se transformer en chasse aux sorcières où tout le monde accuse tout le monde de mal faire son travail. Alors, comment diable gérer un projet avec tout ça à prendre en compte ? Aujourd’hui, vous allez le découvrir.

Merci d’écouter ce podcast. Je suis Ben Aston, et voici le Podcast du Chef de Projet Digital. Ce podcast est présenté par Clarizen, leader des logiciels de gestion de projet et de portefeuille en entreprise. Rendez-vous sur Clarizen.com pour en savoir plus. Aujourd’hui, je suis accompagné de Suze Haworth, l’une de nos expertes DPM sur The Digital Project Manager. Suze, merci beaucoup d’être avec nous aujourd’hui.

Suze Haworth :

Merci Ben, heureuse d’être ici.

Ben Aston :

Permettez-moi de présenter correctement Suze, car elle est nouvelle. C’est, je crois, notre tout premier podcast ensemble.

Suze Haworth :

Oui.

Ben Aston :

Suze est directrice de projets digitaux freelance à Londres et elle a une grande expérience, plus de 13 ans dans le secteur, en commençant par la gestion de comptes — comme moi — puis en se tournant vers la gestion de projet. Mais plutôt que de lire ta bio, Suze, peux-tu nous parler un peu des projets sur lesquels tu travailles en ce moment ?

Suze Haworth :

En ce moment ? Eh bien, en réalité, l’an dernier, je suis passée freelance, donc j’ai travaillé, comme tu l’as dit, dans différentes agences pendant plusieurs années, puis l’an dernier je suis devenue indépendante. Actuellement, j’occupe un poste dans une agence londonienne où je gère deux gros projets : un système de design pour une grande enseigne de distribution, et j’accompagne un autre programme pour une autre marque du secteur. C’est un travail assez intéressant.

Ben Aston :

Donc tu es spécialisée dans la distribution ?

Suze Haworth :

Pas uniquement, j’ai beaucoup travaillé pour la distribution, mais aussi pour un diffuseur, une association caritative, toutes sortes de clients en fait, même si en ce moment il y a effectivement un fort accent sur le retail dans mes dossiers.

Ben Aston :

Intéressant. En tant que freelance, qu’est-ce que tu trouves le plus difficile ? Quels sont tes plus grands défis actuellement ?

Suze Haworth :

Je pense que le plus gros défi — et c’est assez commun chez les chefs de projet selon mon expérience — c’est que tu as toujours tellement de choses différentes à gérer dont tu es responsable. Donc, en plus de vouloir livrer un projet dans les temps, tu gères le planning, le budget, les livrables de l’équipe, les membres de l’équipe eux-mêmes, donc il y a pas mal de problématiques humaines à gérer aussi, sans oublier bien sûr la relation client. C’est parfois compliqué de jongler avec tout ça dans la journée. J’ai souvent l’impression de mener une bataille permanente pour tout faire rentrer dans une seule journée de travail.

Ben Aston :

Oui. Est-ce que tu trouves ça plus compliqué que lorsque tu étais salariée, puisqu’à présent tu es indépendante ? Ça change ta façon de travailler ?

Suze Haworth :

Oui, c’est un peu différent, car en freelance tu gères davantage ton propre temps, tu factures en personne à l’agence. Tu ne dois pas te retrouver dans une position où tu ne peux pas dire non. J’ai appris qu’il ne sert à rien de vouloir tout accepter : mieux vaut connaître ses limites pour bien faire les choses et parfois refuser des missions.

Ben Aston :

Oui, c’est vrai. Quand j’étais contractuel, j’ai ressenti la même chose. Il y a quelque chose de plaisant à être indépendant : tu n’es pas obnubilé par la promotion et tu ne ressens pas la même pression de devoir dire oui à tout comme un salarié permanent qui craint de donner une mauvaise impression.

Suze Haworth :

Exactement. Tu veux quand même laisser une bonne impression, évidemment — le secteur est petit, tout le monde se connaît — mais c’est bien de pouvoir prendre plus de recul parfois et, à la fin de la journée, se dire « Voilà, ma journée est finie », ce qui est parfois moins évident en étant permanent.

Ben Aston :

Depuis que tu es freelance, dans combien d’agences as-tu travaillé ?

Suze Haworth :

Pas tant que ça en fait, comme j’ai commencé récemment. Cela m’a permis de passer plus de temps dans l’agence où je suis actuellement, de mieux connaître les clients et les collègues sur le long terme.

Ben Aston :

Tu travailles sur site ou majoritairement à distance ?

Suze Haworth :

Sur site, principalement. Je vends à tout le monde les bienfaits du télétravail, car je pense que ça peut être très productif pour certains, mais la plupart des agences à Londres où j’ai travaillé privilégient le présentiel.

Ben Aston :

Intéressant. Je sais qu’en plus de ton activité de contractuelle, tu écris aussi beaucoup. Tu as publié des articles sur DPM et tu participeras au DPM Summit plus tard cette année. Tu peux nous en dire plus ?

Suze Haworth :

Oui bien sûr ! L’an dernier, j’ai donné une conférence au DPM Summit à Las Vegas, et cette année j’anime un atelier. Le sujet est intéressant car, en tant que chefs de projet, nous sommes assez obsédés par les méthodologies — et notamment Agile — donc je vais parler d’approches hybrides, notamment de la méthode « double piste » que j’implémente actuellement : elle mélange certains aspects de l’Agile. Je parlerai aussi de Kanban, Lean, et de la façon de combiner différentes méthodes pour s’adapter à chaque projet — sans rester figé sur une méthodologie unique, mais en ajustant selon les besoins.

Ben Aston :

C’est top ! Suze est aussi l’une de nos expertes DPM et intervient dans notre formation Mastering Digital Project Management. Si vous ne voyez pas de quoi je parle—

Suze Haworth :

Oui, c’est moi.

Ben Aston :

C'est d'ailleurs prévu vendredi : première intervention de Suze ! Dans la formation, nous parlons notamment du fait de ne pas trop s’attacher au nom de la méthodologie ou de—

Suze Haworth :

C’est ça.

Ben Aston :

Finalement, ce qui compte, c’est de livrer et de trouver la meilleure façon de livrer, celle qui convient à l’équipe, au projet, au client — bref, du pragmatisme plutôt que du dogmatisme sur Scrum ou autre. Ce qui importe, c’est la livraison.

Suze Haworth :

Exactement, oui. Je crois qu’on se focalise trop sur le process, mais il faut vraiment regarder chaque projet ou produit et se demander « Qu’est-ce qui fonctionnera ici ? ». Chaque projet est différent, donc il faut adapter ou fusionner les approches.

Ben Aston :

Je suis d’accord. Certains critiquent le fait de « diluer la pureté » de la méthode mais, pour moi, les méthodes pures sont rarement applicables telles quelles.

Suze Haworth :

C’est vrai. Il y a beaucoup de snobisme sur les méthodes préférées, mais je suis assez ouverte et, dans le monde des agences, il est presque toujours nécessaire d’adapter plutôt que d’appliquer une méthode pure, à cause du contexte.

Ben Aston :

À côté des conférences et de l’écriture, as-tu fixé des objectifs de progression cette année ?

Suze Haworth :

Bonne question. Honnêtement, en ce moment, je me concentre surtout sur l’instant, sur le travail et le hors-travail, alors c’est parfois difficile de penser à long terme. Mais l'un de mes axes de progrès, c’est d’apprendre à dire non, à déléguer et à lâcher prise. J’ai toujours eu du mal à laisser filer certaines responsabilités, le contrôle, mais c’est un objectif à long terme.

Ben Aston :

Déléguer, c’est difficile, surtout en freelance, où tu ne sais pas si la personne à qui tu délègues va te prendre au sérieux puisqu’on ne se connaît pas de longue date, ni si elle fera bien ce que tu lui confies.

Suze Haworth :

Exactement.

Ben Aston :

Parlons maintenant des outils. En passant dans différentes boîtes, tu en as testé beaucoup. Y en a-t-il un récemment qui change la donne selon toi ?

Suze Haworth :

En tant que freelance, à force de changer d’agence (même en étant salariée), tu es confrontée à une multitude d’outils, et tu dois utiliser ceux de l’entreprise. Je n’ai jamais trouvé l’outil parfait, tous ont leurs avantages et inconvénients, il faut souvent composer. L’unique « outil » que j’adore vraiment, c’est Google Sheets : tu peux tout faire ou presque avec.

Ben Aston :

As-tu déjà essayé Monday.com ?

Suze Haworth :

Non, pas encore.

Ben Aston :

Pour quelqu’un qui aime gérer avec des tableurs, Monday pourrait bien t’intéresser...

Suze Haworth :

On dirait que je suis une geek.

Ben Aston :

L’avantage des tableurs, c’est qu’ils sont gratuits (Google Sheets notamment) et très flexibles, mais Monday apporte un supplément d’automatisation et de contrôle. Tu devrais essayer ; c’est comme un tableur survitaminé.

Suze Haworth :

J’irai voir ça, ça a l’air fait pour moi !

Ben Aston :

Parfait. Venons-en à ton article. Tu l'as écrit il y a quelque temps : comment gérer le fait que certaines personnes veulent trop s’impliquer ou fuient toute responsabilité ? Cet article parle de l’approche RACI. Pour ceux qui ne l'ont pas lu, peux-tu expliquer ce qu'est un tableau RACI ? Que signifie « RACI » ?

Suze Haworth :

RACI signifie Responsable, Autorité (Accountable), Consulté, Informé : c’est un tableau qui mappe les tâches ou livrables d’un projet selon ces rôles (membres de l’équipe ou parties prenantes), en attribuant l’une de ces quatre lettres à chaque tâche et chaque rôle. Cela permet de clarifier qui fait quoi, qui décide, qui est consulté et qui est simplement informé, pour chaque tâche ou livrable. C’est très utile pour assigner la bonne responsabilité et éviter que trop de personnes ne prennent part à chaque décision, tout en sachant précisément qui intervient et à quel niveau.

Ben Aston :

La plus grosse source de confusion, selon moi, c’est la distinction entre « responsable » et « autorité » : beaucoup ne voient pas la nuance entre celui qui fait et celui qui décide. Comment gères-tu cette confusion, et comment fais-tu comprendre la différence ?

Suze Haworth :

C’est le point qui pose souvent le plus de difficultés en RACI, et j’ai parfois eu du mal moi-même, ce qui rend la création du tableau laborieuse. Mais, pour faire simple, le « responsable » est celui qui effectue la tâche (production/livraison), tandis que « autorité » (accountable) est celui qui approuve ou supervise le livrable, sans en être l’exécutant.
La confusion provient aussi du fait que, généralement, on désigne le chef de projet ou le product owner comme autorité, car ce sont les référents du projet. Mais il est important de dissocier : par exemple, pour une tâche créative, l’autorité n’est pas le chef de projet mais plutôt un directeur artistique, côté agence ou client selon le cas. Il ne faut pas tout cumuler sur le chef de projet.

Ben Aston :

Exactement. L’erreur classique, c’est de rendre tout le monde responsable ou autorité, voire de prôner la « responsabilité collective ».

Suze Haworth :

Tout à fait, mais il faut éviter d’ouvrir la porte à trop de responsables pour une même tâche. Sinon, le principe du RACI perd son sens, qui est justement de clarifier, en général, un ou deux points de contact maximum pour chaque action/livrable. Il faut vraiment limiter les rôles et ne pas se disperser.

Ben Aston :

Déterminer qui fait le travail n’est pas toujours si difficile, mais la distinction entre « consulté » et « informé », elle, est parfois subtile. Pour moi, ceux qui sont consultés sont ceux qui peuvent influer sur le projet, alors qu’informer — c’est juste les tenir au courant.
Mais consulté, c'est différent : la personne a une voix, peut donner son avis, même si elle n’est pas responsable de la livraison dans les temps. Il y a une vraie sensibilité ici, car il y a un jeu de pouvoirs, certains veulent donner leur avis sans être en charge du résultat.

Suze Haworth :

Oui, et il faut être vigilant, car ceux qui sont « consultés » doivent effectivement avoir voix au chapitre, mais c’est à l’autorité de s’assurer que leurs retours ne viennent pas tout bouleverser et rallonger la production. C’est pour ça que bien choisir l’autorité (accountable) est crucial sur le livrable ou la tâche.

Ben Aston :

Soyons honnêtes : tu as donné un super exemple sur « Le Seigneur des Anneaux » pour illustrer le RACI, mais ce genre de documentation est-elle nécessaire à chaque projet ? Comment faire pour que ce ne soit pas un document de plus ou une sorte de structure de découpage des tâches ?

Suze Haworth :

Je cherche toujours à éviter la documentation pour la documentation. Un RACI doit vraiment servir et être utilisé, pas un simple document créé au lancement et ensuite oublié. Il faut le consulter, s’en servir à chaque étape, puis à la fin l’analyser pour s’améliorer sur le prochain projet. Sinon, il ne sert à rien.

Ben Aston :

Comment t’en sers-tu au quotidien, lors des réunions de suivi par exemple ? Utilises-tu le RACI pour rappeler à qui revient la responsabilité de telle tâche chaque semaine, ou est-ce une référence interne ?

Suze Haworth :

Je ne l’utilise pas forcément pendant les réunions, mais il me sert de point de repère pour savoir à qui attribuer les livrables ou envoyer pour retours, ou encore qui doit être informé. C'est plus un outil interne de rappel, mais il sert aussi à recadrer quand ça dévie.
Par exemple, si tu as attribué le rôle de « consulté », mais que tout le monde veut donner son avis, tu peux rappeler ce qui a été convenu au début : c’est fait pour l’efficacité, pour éviter d’alourdir le projet.

Ben Aston :

Donc, tu fais un RACI unique réunissant agence et client ou tu sépares ?

Suze Haworth :

J’ai fait les deux, ça dépend des projets. Si tu as deux grosses équipes (agence/client), mieux vaut parfois en faire deux. Quand il y a beaucoup de parties prenantes côté client, j’agrandis le RACI de leur côté. L’essentiel, c’est que le RACI doit rester pertinent pour chaque projet — par exemple pas la peine d’en faire un pour une petite équipe avec peu d’enjeux. Il faut l’adapter au contexte et à la complexité des parties prenantes.

Ben Aston :

Le principal atout du RACI, c’est d’éviter que des tâches passent entre les mailles du filet, ou que certains s’estiment ignorés après livraison. Il n’est pas toujours nécessaire que le client ait une vue sur tous les processus internes, parfois ça complexifie, mais cela reste très utile côté client, surtout si l’organisation est politique ou a du mal à prendre des décisions. Trouver la bonne ou les bonnes personnes « autorité » est primordial, et si ça change, il faut ajuster ou revoir le processus, voire le délai ou le budget.

Suze Haworth :

Oui, c’est pourquoi il est essentiel d’impliquer tes clients ou tes équipes dès la conception du RACI. Ce n’est pas un document à faire seul puis à faire valider : il faut co-construire pour que tout le monde soit aligné et ait réfléchi à la répartition des rôles. Sinon, tu risques qu’ils valident sans y prêter attention.

Ben Aston :

Quand est-ce que le RACI ne marche plus ou devient inutile ? Quels sont les signaux d’alerte ?

Suze Haworth :

Trois choses : d’abord, s’il n’y a pas d’accord clair de tous dès le départ — un RACI fait tout seul, ou en attribuant des tâches sans consultation, n’engage personne. Ensuite, ce doit être vivant : il faut l’utiliser activement, contrôler l’avancement, s’assurer que chaque tâche soit gérée par la bonne personne. Enfin, à la fin du projet, évaluer son utilité pour l’améliorer à l’avenir.

Ben Aston :

Parfois, malgré toute la documentation, des tensions apparaissent, certains se rejettent la faute, des malentendus émergent. Comment reserrer les boulons quand ça déraille ?

Suze Haworth :

C’est tentant d’utiliser le RACI comme « preuve » que d’autres ne respectent pas ce qui a été convenu, mais ce n’est pas l’esprit. Il faut plutôt rappeler que ce document a été créé pour fluidifier le projet, éviter les lourdeurs, fixer les attentes, et pointer les dérives ou les impacts si le cadre n’est pas respecté. Il faut expliquer pourquoi chacun a son rôle, et les conséquences si ça change.

Ben Aston :

Parfois, il faut rappeler la rationalité du dispositif, pourquoi il était fait ainsi au début. Ça aide à recadrer les attentes et à rappeler qui a ou non une légitimité à intervenir.

Suze Haworth :

Oui, et ça revient à faire du RACI un document vraiment utile, avec un objectif précis : optimiser le temps, le budget, les ressources. Si tu fais un RACI sans motivation claire, c’est une perte de temps.

Ben Aston :

C’est un exercice exigeant. Si vous souhaitez télécharger un modèle de RACI, Suze a créé le sien sur le site, avec un exemple « Seigneur des Anneaux » pour mieux comprendre. À l’anecdote : quand j’ai envoyé l’annonce de cet article, un lecteur m’a écrit de façon très acerbe pour dire qu’il trouvait l’approche ridicule. Puis, il m’a recontacté pour dire que l’article était excellent… il n’aimait juste pas le « Seigneur des Anneaux » !

Suze Haworth :

(Rires) Oui, c’est assez spécifique. Quand j’ai fait ce tableau, je me suis dit que j’allais forcément me tromper sur des détails ! Mais c’est pour donner vie à l’approche de façon concrète.

Ben Aston :

Ce qui est bien, c’est que la plupart connaissent l’histoire, donc ça parle à beaucoup… même si c’est clivant. Merci beaucoup Suze d’avoir été avec nous !

Suze Haworth :

Merci à vous.

Ben Aston :

Si vous souhaitez participer à la discussion, laissez un commentaire sous l’article ou rendez-vous dans la section Ressources de TheDigitalProjectManager.com pour rejoindre notre groupe Slack, où de nombreuses conversations passionnantes ont lieu. Pour retrouver Suze dans nos prochaines sessions, inscrivez-vous dès maintenant à la formation « Mastering Digital Project Management » disponible dans la section Formation du site. Merci de votre écoute et à bientôt !