Coordination de plusieurs prestataires :qui répond de quoi

Une agence pour le site, un intégrateur pour le lien avec l'ERP, un hébergeur, un freelance pour les contenus : beaucoup de projets digitaux reposent sur plusieurs prestataires à la fois. Le travail de chacun avance, et pourtant le projet bloque. La coordination des prestataires échoue rarement au milieu d'un lot. Elle échoue aux frontières, là où le travail de l'un devient l'entrée de l'autre.

Je travaille seul, et en mission je me retrouve souvent au milieu de plusieurs équipes qui ne se connaissent pas. Ce qui suit est ma façon de faire : un seul responsable par livrable, un document de référence commun, un rythme unique, et une sortie préparée dès le premier jour. Rien de compliqué, mais il faut le poser avant que le premier problème tombe entre deux chaises.

01Pourquoi les problèmes tombent entre deux prestataires

Chaque prestataire a un contrat, un périmètre et un interlocuteur. À l'intérieur de son périmètre, il fait généralement bien son travail. Le problème naît dans ce que personne n'a acheté : la frontière entre deux lots.

Prenez un formulaire de contact qui n'envoie plus rien. L'agence dit que le formulaire marche. L'intégrateur dit que le connecteur reçoit bien ce qu'on lui envoie. L'hébergeur dit que le serveur répond. Les trois ont raison sur leur périmètre, et le formulaire reste cassé. Personne n'est de mauvaise foi : la frontière n'appartient à personne.

Je vois deux causes qui reviennent. La première, c'est une donnée qui change de sens en passant d'un outil à l'autre. Sur un projet, j'ai vu un mélange de centimètres et de millimètres entre deux outils déformer tout un rendu. Chaque outil était juste avec ses propres unités. Depuis, je demande que la donnée de référence soit écrite noir sur blanc à chaque frontière : format, unité, qui la produit, qui la consomme.

La seconde cause, c'est que chacun vérifie depuis sa position. J'ai vu un site sembler normal à l'équipe connectée et être cassé pour les visiteurs, à cause du cache. Chaque prestataire teste ce qu'il voit. Quelqu'un doit tester ce que voit l'utilisateur final, de bout en bout, et ce quelqu'un doit être nommé.

02Un seul responsable par livrable : la matrice RACI

L'outil que j'utilise pour nommer ce quelqu'un est la matrice RACI. Le ministère de l'Économie en donne une définition simple dans sa fiche méthode RACI : un tableau à deux dimensions, avec les activités ou livrables en lignes et les acteurs en colonnes. Chaque case reçoit une lettre :

• R pour réalise : celui qui fait le travail ;
• A pour approuve : celui qui valide et répond du résultat ;
• C pour consulté : celui dont on demande l'avis avant ;
• I pour informé : celui qu'on tient au courant après.

La règle qui compte le plus est écrite dans la même fiche : une activité ne peut avoir qu'un seul approbateur. Il peut confier le travail à un ou plusieurs réalisateurs, mais il reste responsable de l'action. Et les consultés n'ont pas d'autorité : c'est toujours l'approbateur qui décide.

Rainer Berak, de Project A, insiste sur le même point dans sa vidéo sur les quatre règles du RACI. Chaque sujet a besoin d'exactement une personne qui en répond, ni une équipe ni deux personnes, sinon chacun compte sur l'autre. Il ajoute une remarque que je trouve juste : les informés et les consultés coûtent plus qu'ils n'apportent quand on en met trop. Le Scrum Guide dit la même chose à sa manière : le Product Owner est une personne, pas un comité.

Construire la matrice pour plusieurs prestataires

Voici comment je m'y prends quand il y a plusieurs prestataires :

1. Je liste les livrables, pas les tâches internes de chacun. Je ne veux pas savoir comment l'agence découpe son travail, je veux savoir qui répond de la page de commande.
2. J'ajoute une ligne pour chaque frontière : « l'export des commandes de l'ERP vers le site », « le passage en production », « la recette de bout en bout ». Ce sont les lignes qu'on oublie.
3. Je mets les prestataires en colonnes, plus le client et moi.
4. Je place le A de chaque ligne avant tout le reste. Si personne ne veut le prendre, c'est une information : la ligne n'est couverte par aucun contrat.
5. Je relis le tableau en atelier avec tout le monde. La fiche du ministère compte 30 à 45 minutes pour 4 à 30 participants, et c'est l'ordre de grandeur que je retiens.

Pour le A des lignes de frontière, je pars de l'idée du GOV.UK Service Manual : le service owner doit avoir l'autorité de décision sur tous les aspects du projet, et la responsabilité finale de la qualité lui revient. Une frontière entre deux prestataires appartient donc au client ou à la personne qu'il mandate, pas à l'un des deux prestataires. Quand le client me confie le pilotage, je prends ces lignes-là.

03Un document de référence que tout le monde lit

La matrice dit qui répond. Elle ne dit pas de quoi. Pour ça, il faut un document que tous les prestataires lisent, et un seul.

Sur une intégration entre un ERP et un site marchand, la spécification a bougé presque à chaque réunion. Je l'ai fait évoluer version après version, pour que tout le monde parle du même document. Sans numéro de version, deux prestataires peuvent travailler sur deux états différents du même texte, chacun sûr d'avoir raison. J'ai raconté plus en détail comment j'écris une spécification d'intégration entre un ERP et un site marchand.

Ce document de référence contient au minimum :

• les livrables et leur définition de « terminé » ;
• les données échangées à chaque frontière, avec leur format et leur unité ;
• les dépendances entre prestataires, dans l'ordre ;
• un historique des versions, avec ce qui a changé et qui l'a décidé.

Les dépendances méritent une attention à part, parce qu'un retard chez l'un se paie chez le suivant. J'en parle dans l'article sur le planning d'un projet web construit à partir des dépendances.

04Un rythme commun plutôt que des réunions bilatérales

Le piège de la gestion multi-prestataires, c'est la réunion à deux. Le client voit l'agence le lundi, l'intégrateur le mercredi, l'hébergeur quand il y a un incident. Chacun repart avec sa version de la situation, et le client devient le seul à avoir la vue d'ensemble, sans avoir le temps de la tenir.

Je préfère un rythme unique, court, avec tous les prestataires concernés par les frontières du moment. On y regarde les lignes de la matrice qui bougent, les dépendances de la semaine et les questions ouvertes. Une décision qui touche deux prestataires se prend devant les deux.

Le GOV.UK Service Manual recommande de traiter prestataires et équipe interne comme des membres égaux de la même équipe, pour moins de frictions de communication. Un prestataire qui entend les contraintes de l'autre peut ajuster son travail avant que le problème arrive chez vous.

Pour le niveau au-dessus, je reste fidèle à une habitude : un rapport mensuel qui part seul et un comité qui décide valent mieux qu'un tableau de bord qu'on ne lit pas. Le comité tranche ce que le rythme hebdomadaire n'a pas pu régler. J'ai décrit comment je le prépare dans l'article sur le comité de pilotage projet.

J'ai pris cette habitude bien avant le digital. À mes débuts en production audiovisuelle, il fallait tenir un budget, un planning et une équipe avec une date qui ne bougeait pas. On apprend vite qu'une date fixe ne laisse pas de place aux sujets que personne ne porte.

05Préparer la sortie de chaque prestataire dès son arrivée

Un prestataire finit toujours par partir : fin de lot, fin de contrat, changement de fournisseur. Si sa sortie n'est pas préparée, une partie du projet part avec lui.

Le GOV.UK Service Manual est clair sur ce point. Il demande de ne travailler qu'avec des prestataires prêts à transmettre leur savoir, d'avoir un plan de transfert de connaissances, surtout quand on change de phase ou de fournisseur, et de ne donner que les accès nécessaires, à retirer dès qu'ils ne servent plus.

Concrètement, dès l'arrivée d'un prestataire, je note :

• les accès qu'il reçoit, avec qui les a donnés et quand les retirer ;
• les documents qu'il doit tenir à jour, et où ils vivent (chez le client, pas chez lui) ;
• ce qu'il doit livrer en partant : code, configuration, comptes, documentation.

Je m'applique la même règle. Mes missions sont courtes, et elles se terminent par une transmission documentée. Si je pars et que le client ne peut pas reprendre la main, c'est que j'ai mal travaillé. J'ai développé ce point pour le cas d'une ESN dans l'article sur le travail avec une ESN sans perdre la main sur son projet.

Ce que cette méthode ne règle pas

La matrice RACI ne remplace pas un contrat. Si une frontière n'est couverte par aucun bon de commande, le tableau le montrera, mais il ne la fera pas payer. Il faudra alors l'ajouter au contrat d'un prestataire, ou la prendre en interne.

Elle ne règle pas non plus un prestataire qui ne livre pas. Elle rend le problème visible plus tôt, ce qui est déjà beaucoup. Et sur un très petit projet, avec deux intervenants qui se parlent tous les jours, je ne fais pas de matrice : une liste partagée des livrables et de qui en répond suffit.

06Par où commencer cette semaine

Si vous avez plusieurs prestataires sur un projet en cours, voici ce que je ferais en premier :

1. Lister les frontières : chaque endroit où le travail d'un prestataire devient l'entrée d'un autre.
2. Pour chacune, écrire le nom de la personne qui en répond. Si vous n'en trouvez pas, vous avez trouvé votre prochain problème.
3. Vérifier qu'il existe un seul document de référence, avec un numéro de version, que tous les prestataires lisent.
4. Remplacer une réunion bilatérale par un point commun aux prestataires concernés.
5. Tester le parcours de bout en bout comme un visiteur, avant la recette et la mise en production.

C'est le genre de cadrage que je fais en début de mission, avant de piloter les prestataires au quotidien. Vous pouvez voir le détail sur la page services de SLX Management, et quelques projets dans le portfolio des missions. Si votre projet en est là, on peut en parler.