Dans une administration cantonale, le projet de dématérialisation des demandes de permis avance lentement. Les développeurs attendent régulièrement deux à trois semaines pour obtenir une réponse sur les priorités. Non pas que personne ne soit responsable: un coordinateur projet a été nommé pour faire le lien entre l’équipe technique et les responsables métier. Le problème est que ce coordinateur n’a pas l’autorité pour trancher. À chaque question, il remonte la demande au chef de service, qui consulte ses collègues, qui arbitrent lors de la prochaine réunion de direction. Le coordinateur relaie la réponse, souvent trop tard pour que l’équipe n’ait pas déjà fait un choix par défaut.
Ce schéma apparaît chaque fois qu’une organisation confie la responsabilité de décisions produit à quelqu’un qui n’a ni l’autorité ni la connaissance pour les prendre. Le vocabulaire agile l’appelle “le problème du Product Owner”, mais le phénomène dépasse largement le cadre de Scrum: c’est un dysfonctionnement organisationnel universel, présent dans les administrations publiques comme dans les PME industrielles.
Comment le rôle de relais s’installe
Le mécanisme est presque toujours le même. Les véritables décideurs sont trop occupés pour interagir régulièrement avec l’équipe de réalisation. Plutôt que de réorganiser leur agenda, l’organisation crée un poste intermédiaire: coordinateur, chef de projet fonctionnel, business analyst désigné comme “voix du client”. Cette personne hérite de la responsabilité de définir les priorités et de valider les livrables, mais sans le pouvoir de décision qui va avec.
Mary Poppendieck, dans son analyse du problème du Product Owner, décrit précisément cette dynamique. L’intermédiaire devient un goulot d’étranglement non par incompétence personnelle, mais par construction organisationnelle: on lui demande de prendre des décisions qu’il n’a pas les moyens de prendre correctement.
Les trois déficits du décideur par procuration
Le décideur par procuration souffre de trois déficits structurels que la bonne volonté ne peut pas compenser. Le premier est un déficit de connaissance du terrain: les meilleures décisions produit naissent de la compréhension directe des utilisateurs, de leurs irritants et de leurs contournements. L’intermédiaire n’a accès à cette connaissance que de seconde main, à travers des documents et des comptes-rendus qui le privent des nuances que seul le contact direct permet de saisir.
Le deuxième est un déficit d’autorité. Quand une décision de priorisation implique un arbitrage entre deux directions métier, l’intermédiaire n’a pas le poids hiérarchique pour trancher. Ce délai de validation, multiplié par le nombre de décisions à prendre dans un projet, s’accumule en semaines de retard.
Le troisième est un déficit de contexte technique. Les arbitrages produit impliquent souvent des compromis entre ce qui est souhaitable et ce qui est réalisable dans les contraintes du système existant. Un intermédiaire sans compréhension technique suffisante ne peut pas évaluer correctement le coût réel d’une fonctionnalité ni identifier les alternatives qui pourraient satisfaire le besoin autrement.
Le coût caché: les décisions par défaut
Le plus grand dommage du décideur fantôme n’est pas le ralentissement visible, mais la multiplication des décisions par défaut. Quand l’équipe attend trop longtemps une réponse, elle finit par choisir elle-même, en se basant sur sa meilleure compréhension du besoin. Ces micro-décisions prises faute de mieux s’accumulent et produisent un résultat qui fonctionne techniquement mais ne répond pas aux attentes des vrais utilisateurs.
Le Lean, courant de pensée sur l’efficience des processus dont Mary Poppendieck est l’une des figures majeures, appelle ce phénomène du gaspillage (waste): du travail produit qui ne génère pas de valeur parce que la boucle de retour entre le besoin et la réalisation est trop longue ou trop indirecte.
Trois configurations qui rapprochent le décideur de l’équipe
La solution n’est pas de supprimer tout intermédiaire pour imposer un accès direct au PDG. C’est de s’assurer que la personne qui interagit avec l’équipe dispose effectivement de la connaissance du besoin, de l’autorité de trancher et de la capacité de comprendre les implications techniques. Un indicateur simple permet de diagnostiquer le problème: si le délai moyen entre une question de priorité et la réponse définitive dépasse régulièrement 48 heures, la chaîne de décision comporte un maillon faible.
Trois configurations organisationnelles permettent d’y remédier. La première est le décideur métier embarqué: le responsable opérationnel qui utilisera le résultat du projet consacre un temps défini et non négociable, typiquement deux à quatre heures par semaine, à l’équipe de réalisation. Il participe aux revues, tranche les arbitrages et valide les orientations. La deuxième est la délégation encadrée: le décideur métier définit un cadre clair (budget, contraintes, critères de succès, limites d’autonomie) à l’intérieur duquel l’équipe décide elle-même, et seules les décisions qui sortent du cadre remontent. La troisième est le binôme produit-technique: l’équipe interagit avec un duo composé d’un expert métier et d’un référent technique senior, qui peuvent ensemble évaluer les compromis entre désirabilité fonctionnelle et faisabilité.
Le rôle du chef de projet dans cette reconfiguration
Le chef de projet n’est pas nécessairement le décideur produit, et c’est parfaitement normal. Son rôle est de créer les conditions pour que les bonnes décisions soient prises au bon moment: identifier qui détient réellement le pouvoir de décision, s’assurer que cette personne est accessible à l’équipe et mettre en place des mécanismes d’escalade clairs.
Poppendieck suggère que ce rôle ne devrait pas être un poste créé de toutes pièces, mais une responsabilité portée par quelqu’un qui possède déjà la légitimité métier. Le référentiel HERMES de la Confédération suisse traite cette question sous l’angle de la gouvernance: chaque projet doit définir clairement qui assume le rôle de mandant (donneur d’ordre) et avec quelle autorité. Le Guide Scrum lui-même insiste sur le fait que le Product Owner doit être une personne unique dotée d’un pouvoir de décision réel. Quel que soit le cadre méthodologique, le principe reste le même: la vitesse de décision n’est pas un luxe, c’est un facteur de performance qui s’applique à tout projet.