Réponse en bref
Un client est mieux servi par un spécialiste nommé, qui a l’autorité de décider des priorités, du périmètre et de l’acceptation, et qui répond du résultat. Les référentiels publics du travail numérique, du Digital Services Playbook américain au Guide Scrum, disent la même chose : une personne, pas un comité. Avant de signer, demandez qui est cette personne, ce qu’elle peut décider sans autorisation, qui la remplace et en combien de temps arrivera une décision, et non une simple réponse.
Une boîte partagée peut vous répondre ; elle ne peut pas décider
Beaucoup de sociétés de services donnent au client une adresse qui n’appartient à personne en particulier : une boîte projets, un formulaire d’assistance, une file de tickets. Elle a de vraies qualités. Les messages ne se perdent pas quand quelqu’un est en congé, plusieurs personnes voient l’historique et le client a toujours un endroit où écrire. Pour les demandes courantes, c’est exactement ce qu’il faut.
La faiblesse apparaît à la première question qui demande du jugement. Peut-on décaler la mise en ligne d’une semaine ? Cette modification est-elle comprise dans le prix ? Laquelle de ces deux options choisiriez-vous ? Une boîte peut accuser réception d’un tel message en quelques minutes. Elle ne peut pas y répondre, parce qu’une réponse est une décision, et qu’une décision suppose quelqu’un qui a le droit de la prendre et qui est prêt à l’assumer.
La distinction utile ne passe donc pas entre une personne et une boîte aux lettres. Elle passe entre un canal, qui transporte les messages, et un propriétaire, qui les tranche. Un projet peut avoir les deux, et le doit souvent. Ce dont il ne peut pas se passer, c’est du second : un spécialiste nommé, qui répond du résultat et détient l’autorité correspondante.
Trois référentiels publics aboutissent à la même règle : une personne
Le Digital Services Playbook du gouvernement américain fait de cette règle le titre de sa sixième recommandation : confiez la direction à une seule personne et tenez-la pour responsable. Le texte demande un product owner unique, doté de l’autorité et de la responsabilité d’attribuer les tâches, de prendre les décisions commerciales, de produit et techniques, et de répondre du succès ou de l’échec du service dans son ensemble.
Le Guide Scrum (Scrum Guide), dans lequel Ken Schwaber et Jeff Sutherland définissent le cadre Scrum, est plus bref encore : le Product Owner est une personne, pas un comité. Il ajoute une condition que l’on néglige facilement. Pour que cette personne réussisse, toute l’organisation doit respecter ses décisions, et ceux qui veulent modifier l’ordre du travail peuvent le faire en essayant de convaincre le Product Owner.
Le GOV.UK Service Manual dit du service owner, le responsable du service, qu’il doit avoir l’autorité de décision nécessaire pour mener à bien tous les aspects d’un projet. Ces trois documents ont été écrits pour des équipes qui construisent des logiciels et des services publics, pas pour un studio qui conçoit une marque ni pour une agence qui mène une campagne. Le raisonnement se transpose tel quel, car il porte sur la manière dont les décisions se prennent et non sur ce que l’on construit.
Répondre du résultat ne signifie pas faire tout le travail seul
L’objection habituelle à un nom unique est que personne ne peut tout savoir. C’est vrai, et hors sujet. Le Guide Scrum sépare précisément les deux idées : le Product Owner peut accomplir le travail ou en déléguer la responsabilité à d’autres et, dans tous les cas, il en reste comptable. Les designers conçoivent, les développeurs construisent, les analystes mesurent. Une personne répond de ce que l’ensemble correspond à ce qui a été promis.
Le Service Manual trace la même ligne pour la qualité. Il fait de la qualité d’un service numérique la responsabilité de toute l’équipe et place la responsabilité finale chez le responsable du service. Pour un client, c’est le sens pratique de cette responsabilité : il existe une personne qui ne peut pas répondre que cela relevait d’un autre service lorsqu’un point tombe entre deux spécialistes.
Cela explique aussi pourquoi la personne nommée doit être un spécialiste et non un relais de messages. La liste de contrôle du Playbook attend du product owner une expérience de la gestion de produit et les connaissances techniques nécessaires pour évaluer les options et arbitrer les compromis. Celui qui se borne à transmettre les questions à ceux qui les comprennent ajoute une étape à chaque réponse et n’enlève rien au risque du client.
Les décisions que la personne nommée doit pouvoir prendre sans demander
Un nom dans un contrat vaut ce que vaut l’autorité qui le soutient. Le Playbook fournit le test sous la forme d’une question clé : que faut-il pour que le product owner ajoute ou retire une fonctionnalité du service ? Si la réponse honnête est une réunion de cinq personnes et un courriel à un directeur, le projet a un porte-parole, pas un propriétaire.
Dans un projet commercial, quatre types de décision comptent. Les priorités : ce que l’on fait d’abord quand le temps manque. Le périmètre : une demande entre-t-elle dans l’accord, et que retire-t-on si l’on ajoute quelque chose. L’acceptation : un élément du travail est-il terminé, tâche que le Service Manual confie au product manager lorsqu’il parle d’accepter les récits utilisateur une fois achevés. Et les arbitrages entre date, coût et qualité quand les trois ne peuvent pas être tenus.
Aucun prestataire sensé ne donne à un salarié un pouvoir illimité, et un client ne devrait pas s’y attendre. L’essentiel est que les limites soient énoncées. Dans un dispositif viable, le responsable unique du projet décide de tout ce qui tient dans le budget et le délai convenus, et l’on nomme la personne qui valide au-delà. Une limite écrite est une force. Une limite découverte la troisième semaine, c’est la boîte anonyme sous un autre nom.
La continuité quand la personne nommée est malade, en congé ou partie
L’argument sérieux en faveur de la boîte partagée est la continuité. Les gens tombent malades, prennent des congés et changent d’emploi, et un projet qui vit dans une seule tête s’arrête quand cette tête est absente. La crainte est fondée. Le remède n’est pas de rendre tout le monde également responsable, ce qui revient en pratique à ce que personne ne le soit, mais de prévoir l’absence à l’avance.
Trois éléments rendent un responsable nommé remplaçable sans rendre la fonction anonyme. Un suppléant, nommé lui aussi, qui suit suffisamment le travail pour prendre le relais. Un registre écrit des décisions, tenu là où le client peut le lire, afin qu’un successeur hérite des raisons et pas seulement des fichiers. Et des comptes, des fichiers et des accès qui appartiennent à l’entreprise ou au client, jamais à l’identifiant personnel d’un individu.
C’est ici que la boîte partagée mérite sa place. Mise en copie, elle donne l’historique au suppléant et une adresse de secours au client, tandis que la question de savoir qui décide reste réglée. Demandez que tout changement de responsable vous soit annoncé par écrit, avec une période de passation lorsque c’est possible. Un prestataire qui y a réfléchi répond aussitôt, parce que le dispositif existe déjà.
Deux horloges : le délai de réponse et le délai de décision
Les promesses de service décrivent souvent la première horloge : en combien de temps un message reçoit un accusé de réception. Une boîte lue par plusieurs personnes s’en tire bien sur ce critère. Le calendrier du client dépend de la seconde horloge : combien de temps s’écoule avant que la question soit réellement tranchée. Un projet peut accumuler des réponses rapides et courtoises pendant quinze jours et ne pas avancer.
Le GOV.UK Service Standard en donne la raison dans son point sur les équipes pluridisciplinaires : il importe que les personnes qui participent à la prise de décision fassent partie de l’équipe, afin qu’elles lui rendent des comptes et que l’équipe entière puisse réagir vite à ce qu’elle apprend. Quand le décideur se tient hors de la conversation, chaque réponse fait un aller-retour. Quand le décideur est la personne à qui vous écrivez, ce détour disparaît.
Convenez des deux horloges par écrit. À titre d’illustration seulement : un jour ouvré pour accuser réception, trois pour trancher une question qui demande l’avis d’autres personnes, et un numéro de téléphone pour tout ce qui bloque une mise en ligne. Vos chiffres seront différents. Ce qui ne devrait pas l’être, c’est que les horaires, le fuseau horaire, le canal d’urgence et la voie d’escalade soient connus avant la première échéance, et non pendant.
Les questions qui révèlent l’organisation avant la signature
Commencez par la première question clé du Playbook, avec vos mots : qui est le product owner de notre projet ? Vous attendez un nom et une fonction, pas « l’équipe ». Demandez ensuite à parler à cette personne avant de signer le contrat. Si le responsable n’apparaît qu’après la vente, vous avez rencontré le processus commercial et non le projet.
Poursuivez avec quatre autres. Que peut décider cette personne sans consulter quiconque ? Qui la remplace en son absence, et puis-je le rencontrer ? Sous quel délai dois-je attendre une décision, ce qui n’est pas la même chose qu’une réponse ? Que se passe-t-il si le responsable quitte l’entreprise en cours de projet ? Des réponses claires prennent quelques minutes. Des réponses vagues sont aussi une information.
Observez le comportement du candidat pendant cet échange. Un véritable responsable unique du projet s’enquiert de vos objectifs avant de décrire un processus, refuse ou reporte au moins une demande en donnant un motif, et précise ce qui échappe à son contrôle. Cherchez ensuite les mêmes faits sur le papier : le responsable et le suppléant nommés dans le contrat ou dans le compte rendu de lancement, et une ligne sur la manière dont un changement de responsable est géré.
Le client a lui aussi besoin d’un seul nom, et la boîte garde son rôle
La règle vaut dans les deux sens. Un prestataire doté d’un responsable unique piétine quand même si le client répond en comité, avec trois collègues qui envoient des remarques contradictoires. La phrase du Guide Scrum s’applique en miroir : le Product Owner peut représenter les besoins de nombreuses parties prenantes et demeure une seule personne. Désignez votre propre décideur et dites au prestataire de qui il s’agit.
Rien de tout cela ne met l’adresse partagée à la retraite. Les factures, les demandes d’accès, les mises à jour courantes de contenu et les pannes hors horaires sont mieux traitées par une file que plusieurs personnes surveillent, parce que la rapidité et la couverture y comptent davantage que le jugement. L’erreur consiste à faire passer les décisions par la file, ou à traiter le responsable nommé comme un service d’assistance.
Un bon dispositif comporte donc deux éléments, et un client peut demander les deux : un canal qui ne perd jamais un message, et une personne qui ne peut pas dire que la décision n’était pas la sienne. Si une offre ne vous donne que le premier, vous achetez des réponses. Si elle vous donne les deux, avec des limites d’autorité écrites, vous savez qui répondra du résultat le jour où quelque chose tournera mal.
Checklist pratique
- Demandez le nom et la fonction de la personne qui répond de votre projet, et parlez-lui avant de signer.
- Faites écrire par le prestataire ce que cette personne peut décider seule sur les priorités, le périmètre et l’acceptation, et qui décide au-delà.
- Obtenez le nom d’un suppléant et vérifiez où sont consignés les décisions et les accès, afin qu’une absence n’arrête pas le travail.
- Convenez par écrit de deux délais, l’un pour accuser réception d’un message, l’autre pour parvenir à une décision, ainsi que d’un canal d’urgence.
- Désignez un seul décideur de votre côté et faites passer par lui seul les retours consolidés.
Questions et réponses
Un interlocuteur unique est-il la même chose qu’un responsable de projet ?
Pas nécessairement. Un interlocuteur reçoit et transmet des messages ; un responsable a l’autorité de décider et répond du résultat. La différence se voit à la première question difficile. Si votre contact doit porter à quelqu’un d’autre chaque demande sur les priorités, le périmètre ou l’acceptation, vous avez un intermédiaire, et le véritable décideur est une personne que vous n’avez pas rencontrée.
Que doit pouvoir décider un chef de projet sans validation ?
Au minimum l’ordre du travail, l’appartenance d’une demande au périmètre convenu, l’acceptation d’un livrable et l’arbitrage entre date, coût et qualité dans le budget et le délai convenus. Les décisions qui dépassent ces limites peuvent revenir à un supérieur nommé. L’essentiel est que les limites et ce second nom soient écrits avant le début du travail.
Que devient mon projet si le spécialiste nommé s’en va ?
Avec de la préparation, presque rien ne change. Demandez à l’avance un suppléant nommé qui suit le travail, un registre des décisions que vous pouvez lire, et des comptes et des fichiers détenus par l’entreprise ou par vous plutôt que par un individu. Demandez aussi à être prévenu par écrit de tout changement de responsable et, si possible, une période de passation pendant laquelle les deux personnes sont disponibles.
Une boîte de projet partagée est-elle toujours mauvais signe ?
Non. Une adresse partagée est le bon outil pour les factures, les demandes d’accès, les mises à jour courantes et les pannes urgentes hors horaires, là où la couverture compte plus que le jugement. Elle ne devient un signal d’alerte que lorsqu’elle est la seule voie pour les questions qui exigent une décision et que personne ne sait vous dire qui la prendra.
Comment vérifier la responsabilité avant de signer un contrat ?
Demandez qui répondra du résultat et insistez pour vous entretenir avec cette personne, pas seulement avec l’équipe commerciale. Posez la question que suggère le Digital Services Playbook américain : que faudrait-il à cette personne pour ajouter ou retirer une fonctionnalité ? Vérifiez ensuite que le contrat ou le compte rendu de lancement nomme le responsable, le suppléant et la procédure de remplacement de l’un comme de l’autre.