La démo client faite par le développeur, pas par le chef de projet

Ce qui se perd quand le chef de projet parle à la place du développeur

Un vendredi après-midi, un développeur termine un écran de gestion des droits. Le chef de projet dit « je m'en occupe pour lundi » et prépare seul un slide pour la présenter au métier. Il traduit l'explication technique en langage business, il perd une nuance dans un sens et une contrainte dans l'autre. Le mercredi suivant, une demande de changement arrive qui ignore une limite technique que le développeur avait pourtant signalée, mais qui ne s'est jamais retrouvée dans la salle où elle comptait.

Ce scénario n'est pas une exception, c'est le mode de fonctionnement par défaut de la majorité des projets digitaux en PME et en grand groupe. Le chef de projet existe pour absorber la complexité et protéger le temps des développeurs. Le problème n'est pas son rôle en général, c'est qu'il devient, sur la démo elle-même, un relais entre deux personnes qui pourraient se parler directement. Chaque relais coûte une nuance.

La démo n'est pas une présentation, c'est une vérification

Une démo réussie n'a pas pour objectif de plaire, elle a pour objectif de faire remonter un écart entre ce qui a été codé et ce que le métier attendait vraiment. Un chef de projet qui présente un écran qu'il n'a pas construit peut décrire ce qu'il voit, il ne peut pas expliquer pourquoi une contrainte technique a forcé un choix précis. Le métier pose une question de second niveau, le chef de projet répond « je vérifie et je reviens vers vous », et l'écart continue d'exister jusqu'à la prochaine itération.

Ce que change une démo tenue par celui qui a codé

Confier la démo directement au développeur produit un retour métier non filtré, qui responsabilise le développeur sur la qualité perçue de son travail, pas seulement sur la conformité au ticket qu'on lui a donné. Ce déplacement change la nature de l'échange : le métier ne parle plus à un porte-parole, il parle à la personne qui peut modifier le comportement du système la semaine suivante.

Chez Leando, on appelle ce principe la démo directe. Il désigne une posture précise, le développeur qui a construit une fonctionnalité la présente lui-même au métier, sans relais qui reformule le retour dans les deux sens. La démo directe n'exclut pas le chef de projet, elle change son rôle, il prépare le terrain relationnel avant la démo, il ne parle plus pendant.

Le retour immédiat vaut plus que le retour poli

Un développeur qui entend directement « ça ne correspond pas à ce qu'on fait le lundi matin » ajuste son modèle mental du métier sur-le-champ. Un chef de projet qui reçoit la même phrase la retransmet souvent adoucie, parce qu'il ne mesure pas toujours ce qui est un détail et ce qui est un signal fort. La perte n'est pas volontaire, elle est structurelle, personne ne peut retransmettre fidèlement ce qu'il n'a pas produit lui-même.

« Notre approche produit qu'on applique chez les startups, quels sont tes utilisateurs, quel est leur quotidien, quel problème tu dois résoudre, le user flow, le job-to-be-done, tout ça a vraiment fait écho dans des systèmes plus complexes, plus organisés avec une DSI. »

Cette méthode produit-first, pensée pour des startups où chaque développeur est proche de l'utilisateur final, se transpose directement dans un grand groupe où les couches de relais sont pourtant plus nombreuses. Le paradoxe n'en est pas un, une organisation complexe a plus besoin de démos directes qu'une petite équipe, précisément parce que les canaux indirects y sont déjà saturés.

Un exemple grand groupe où le relais a été volontairement supprimé

Une direction artistique d'un grand groupe du luxe portait un projet d'outillage pour ses architectes mondiaux, bloqué depuis douze à dix-huit mois par des tensions politiques avec la DSI. Une fois le mapping terrain posé, Leando a fait manipuler un prototype dynamique aux développeurs avant même le kickoff officiel, puis leur a confié directement les démos bimensuelles auprès du métier plutôt que de les faire passer par un chef de projet. Le projet a été livré en sept mois et demi à huit mois, avec un mois d'avance sur la deadline. Dans leur bilan de fin de projet, les développeurs eux-mêmes ont identifié le kickoff, celui où ils avaient présenté directement leur travail, comme le moment de rupture nette avec leurs habitudes antérieures de gestion de projet.

Ce que révèle ce cas, ce n'est pas qu'un prototype complexe a besoin d'un expert pour être expliqué. C'est l'inverse, plus le système est complexe, moins un relais peut se permettre d'approximer. Pour aller plus loin sur ce qui a débloqué ce projet en amont de la démo, l'article sur le déblocage d'un projet SI par mapping visuel détaille la méthode utilisée en amont du kickoff.

Ce que ça exclut, et pourquoi certaines équipes ne peuvent pas encore le faire

La démo directe suppose une préparation, pas une improvisation. Un développeur qui n'a jamais reçu d'explication sur le contexte métier derrière son ticket ne peut pas répondre correctement à une question qui déborde du périmètre technique. Dans ce cas, le principe exclut de le mettre seul face au métier sans filet, le chef de projet prépare le terrain relationnel, il n'occupe simplement plus la parole une fois la démo commencée.

L'objection la plus fréquente porte sur l'engagement de délai, un développeur pourrait promettre une date qu'il ne tient pas. C'est un vrai risque, il se gère par un cadre clair posé avant la démo, pas par l'absence du développeur. Le chef de projet reste seul responsable du planning et des engagements, la démo porte sur la fonctionnalité livrée, jamais sur la feuille de route. Un désalignement fréquent entre COMEX et prestataire technique vient justement de ce type de confusion de rôle, documenté dans l'article sur le désalignement CODIR et prestataire sur un projet SI.

Comment organiser la première démo directe sans improviser

La transition ne se décrète pas en une réunion, elle se prépare sur une démo précise. Le chef de projet choisit une fonctionnalité limitée, il briefe le développeur sur qui sera présent, quel problème métier motive cette fonctionnalité, et quelles questions reviennent habituellement à ce stade du projet. Le développeur présente, le chef de projet observe et n'intervient que si une question sort franchement du périmètre technique.

Le brief compte plus que la démo elle-même

La plupart des échecs de première démo directe ne viennent pas d'un développeur mal à l'aise à l'oral, ils viennent d'un brief bâclé en amont. Quinze minutes suffisent pour transmettre l'essentiel, qui est dans la salle, quel problème concret cette fonctionnalité résout dans leur quotidien, et quelles décisions ont déjà été tranchées ailleurs pour éviter de les rouvrir en séance. Un développeur bien briefé sur le contexte répond mieux qu'un chef de projet qui connaît la fonctionnalité sans connaître le métier, parce que la question qui bloque vient rarement de la technique, elle vient de l'écart entre ce qui a été codé et ce que le quotidien du métier exige réellement.

Sur les deux ou trois premières démos, il est utile que le chef de projet reste dans la salle sans reprendre la parole, uniquement pour repérer les questions auxquelles le développeur n'a pas su répondre. Ce repérage sert de matière pour affiner le brief suivant, pas pour reprendre la main sur la démo d'après. Une équipe qui répète cet exercice sur cinq ou six démos voit généralement le développeur gagner en aisance plus vite qu'un chef de projet junior n'en gagnerait sur le même nombre de présentations, parce que le développeur parle d'un travail qu'il connaît de l'intérieur.

Si votre organisation ressent l'usure d'un projet où les développeurs restent invisibles derrière un chef de projet qui parle à leur place, l'article sur le pont métier/tech prolonge cette question sur un terrain plus large, celui de la traduction entre les deux mondes au-delà de la seule démo.

Ce que la démo directe révèle avant même d'être organisée

Une équipe incapable de mettre un développeur devant le métier révèle souvent un problème antérieur à la démo elle-même, un cadrage qui n'a jamais donné aux développeurs le contexte nécessaire pour en parler. La démo directe n'est pas seulement une pratique de gestion de projet, c'est un test de la qualité du cadrage qui l'a précédée.

À la prochaine démo prévue dans votre projet, changez un seul paramètre, laissez le développeur qui a codé la fonctionnalité la présenter lui-même, et observez ce que cela change dans les questions posées par le métier.