Passer de la méthode Waterfall aux contrats de Durée & Prix (Avec Tucker Sauer-Pivonka de Crema)

Lisez la transcription :

Nous testons la transcription de nos podcasts via un logiciel. Merci de pardonner les éventuelles fautes de frappe, le robot n'est pas exact à 100 % du temps.

Ben Aston :

Bienvenue dans le Podcast DPM, où nous allons au-delà de la théorie pour vous donner des conseils pratiques pour mieux piloter vos projets numériques. Merci d'être avec nous, je suis Ben Aston, fondateur du Digital Project Manager. Les projets ne se passent quasiment jamais comme prévu, et quand un plan change, cela génère souvent beaucoup de stress. Il faut passer des appels, organiser des réunions, remettre les plans à jour, recalculer les estimations et, généralement, émettre des demandes de modification. Mais, et s’il existait une autre manière de gérer le changement sur vos projets ? Dans ce podcast, nous allons soulever le couvercle et découvrir une approche différente de la gestion du changement à travers les contrats agiles. Continuez à écouter pour comprendre comment faire fonctionner les contrats agiles à votre avantage et appréhender les avantages et défis liés à cette approche.

Aujourd’hui, je suis accompagné de Tucker Sauer-Pivonka, il est le Directeur de la gestion de produit chez Crema, où il accompagne les chefs de produit et les aide à grandir et se développer. Il est aussi chargé de faire évoluer les bonnes pratiques de l’équipe. Bonjour, Tucker.

Tucker Sauer-Pivonka :

Bonjour Ben, ravi de t’entendre aujourd’hui.

Ben Aston :

Oui, moi aussi. Une première question, d’ailleurs, en commençant : je sais qu’une partie de ton rôle porte sur le développement de l’équipe, et j’aimerais que tu partages quelques-unes de tes observations sur ce qui fonctionne vraiment pour aider ton équipe à évoluer. Peut-être autour des contrats que vous expérimentez. Mais comment fais-tu grandir l’équipe ? Qu’est-ce qui marche chez toi ?

Tucker Sauer-Pivonka :

Oui. Je pense qu’il faut d’abord reconnaître que chacun apprend différemment, que tout le monde a besoin d’un style de coaching différent. L’une des premières choses que je fais avec chacun des membres de mon équipe, c’est m’asseoir avec eux et évaluer leur mode d’apprentissage. Comment aiment-ils recevoir des retours ? Comment aiment-ils recevoir des félicitations ? Je note tout cela afin d’adapter mon approche à chacun afin d’être le plus efficace possible. Je passe beaucoup de temps en entretiens individuels. Nous abordons différents sujets, de nouvelles pistes de développement. Je les coach sur tout ce qui peut leur poser problème sur le moment. Les défis surgissent, on les traite au fur et à mesure. Nous avons aussi actuellement une étude de livre chez Crema, autour d’un ouvrage nommé “Multipliers”.

C’est important pour la progression de notre équipe. Et puis il y a les conférences. Nous en avons une prévue, je crois, fin septembre, qui portera également sur la gestion de produit. Nous y allons ensemble, non seulement pour la cohésion d’équipe, mais aussi pour découvrir de nouveaux sujets.

Ben Aston :

Sympa ! Tu connais le nom de la conférence ?

Tucker Sauer-Pivonka :

Industry: The Product Conference, c’est son nom, cela se passe à Cincinnati, si je me souviens bien.

Ben Aston :

Fête à Cincinnati, si vous voulez rejoindre Tucker et l’équipe. Tu avais évoqué différents thèmes abordés avec l’équipe. Peut-être peux-tu partager les points sur lesquels tu les aides à avancer ? Quels sont les défis que vous surmontez ?

Tucker Sauer-Pivonka :

Encore une fois, c’est différent selon les personnes et leurs niveaux d’expérience. Certains sujets, en groupe, tournent beaucoup autour de la gestion client : “Mon client a dit ceci”, “Le client demande qu’on fasse ça alors qu’on ne l’avait pas prévu. Comment réagir ?” J’extrapole parce que je n’ai pas d’exemple parfait en tête, mais c’est ce type de situations.

La gestion de la relation client est souvent le sujet le plus complexe à enseigner, donc on discute de cas : “J’étais mal à l’aise sur ce coup, j’ai bien fait ? J’aurais dû m’y prendre autrement ?” Ce sont généralement les pistes de nos discussions.

Ben Aston :

C’est vrai. Il y a tout un aspect compétences humaines en gestion client et d’équipe, non ? Il n’y a jamais de réponse unique, cela dépend… Mais on peut toujours s’améliorer. Tu as mentionné aller en équipe à une conférence, ce qui est top. Comment fais-tu pour rester inspiré, te tenir au courant de tout ce qui se passe ?

Tucker Sauer-Pivonka :

J’utilise pas mal de choses. Je lis des livres, beaucoup d’articles… Medium est l’une de mes sources d’inspiration sur la gestion de produit, la gestion d’équipe, sur ce à quoi cela pourrait ressembler. Mais il faut se rappeler que Medium est une bonne ressource mais n’importe qui peut publier, donc prendre parfois avec du recul. Ça permet cependant d’obtenir du contexte et différentes façons de gérer certaines situations.

Puis, je lis aussi pas mal de magazines du secteur, comme Wired, pour rester au fait des tendances technologiques au sens large.

Ben Aston :

Génial. Sur la technologie, tu es toujours à la pointe ? Quel est le dernier gadget que tu as acheté ?

Tucker Sauer-Pivonka :

Bonne question. J’aurais aimé avoir une réponse incroyable mais je dois avouer que je ne suis pas tout à fait à la pointe. Je suis un early adopter, mais pas plus que ça. J’essaie de tester les nouveaux produits quand ils sortent. Là, je lorgne sur le nouvel iPad. J’ai déjà un iPad Pro qui fonctionne parfaitement mais j’aimerais la nouvelle version… sans vraie justification, mon appareil fonctionne même très bien ! C’est la magie des produits Apple.

Mais récemment, ce qui m’a marqué, c’est la dernière version d’iOS, d’iPadOS, et toutes les annonces du WWDC. Leur impact sur l’industrie, sur nos produits, m’intéresse. Et je suis un peu geek de Zelda aussi… la suite de Breath of the Wild a été annoncée, je suis à fond.

Ben Aston :

Super. Moi en ce moment, je rêve du DGI Rover. Je ne sais plus si c’est le vrai nom, mais ils ont annoncé cette caméra sur forme de mini-tank à construire soi-même, ça a l’air génial. C’est sur ma liste d’achats.

Tucker Sauer-Pivonka :

Ça a l’air amusant.

Ben Aston :

Oui. Encore une fois, on se demande toujours si c’est utile… Mais ce sera pour les enfants, ils aimeront. Tu aimes ton iPad Pro ; côté matériel/logiciel, tu as découvert autre chose récemment qui t’a changé la vie ?

Tucker Sauer-Pivonka :

J’ai beaucoup cherché à équilibrer la prise de notes manuscrites, informatisées, le suivi des tâches… Je retiens mieux en écrivant qu’en tapant. J’ai longtemps tout noté sur mon iPad avec le Pencil. Récemment, j’ai adopté une approche hybride : je garde un petit carnet où je note mes tâches et informations au fil de la journée, puis je transfère dans Todoist, mon app de to-do, à la fin de chaque journée.

C’est mon nouveau système. Je remarque que je retiens mieux ce que je fais, et je gère aussi mieux mes tâches – moins d’impulsivité, meilleure organisation, donc même du point de vue gestion du temps, c’est positif.

Ben Aston :

Intéressant, donc tu es retourné au papier, puis tu passes ensuite au digital. C’est ça ?

Tucker Sauer-Pivonka :

Oui, mais tout finit dans l’espace numérique. J’aime l’instantanéité du carnet papier, alors qu’avec l’iPad, il faut ouvrir la bonne application, trouver le bon carnet, s’assurer que le stylet est chargé… Plein de petits obstacles qui freinent l’écriture immédiate.

Je me retrouvais avec l’iPad et des post-its partout. Ce n’était pas viable, d’où l’adoption du carnet.

Ben Aston :

Même combat ici. Ma dernière trouvaille : Evernote. J’utilise un carnet pour la todo, un autre pour le vrac. J’ai aussi un mini carnet pour des rappels courts, histoire de ne pas tout disperser. Ça ressemble à ton système !

Passons à l’article/cas d’étude que tu as rédigé : passer du modèle contrat waterfall au contrat durée & prix. Les contrats agiles nous intéressent au DPM et, dans le DPM school, on a eu la demande d’un exemple récent. Pour ceux qui ne connaissent pas, peux-tu décrire ce qu’est un contrat durée & prix et comment cela fonctionne ?

Tucker Sauer-Pivonka :

Oui. Je vais expliquer comment ça marche chez Crema, que je connais le mieux. Ce qu’on appelle un “contrat durée & prix”, c’est centrer un projet sur une équipe dédiée. Par exemple : deux développeurs à plein temps, un testeur mi-temps, un designer quart ou mi-temps, un chef de produit mi-temps. Et peut-être un stratège, également à quart-temps chacun.

C’est bien plus orienté équipe et objectifs à atteindre que liste d’éléments livrables ou de fonctionnalités évaluées exactes. On a constaté que le logiciel est trop complexe pour être estimé précisément en amont avec une prévision horaire fiable. Cela n’arrive jamais vraiment comme voulu !

Ce type de contrat permet de déplacer l’effort sur ce qui a le plus de valeur métier, même au fil du projet et de ses cycles itératifs. À la fin, on a travaillé sur ce qui était prioritaire, contrairement à un forfait classique où on peut livrer ce qui ne sert plus l’entreprise.

Ben Aston :

Tu as évoqué pour quels types de projets cela marche. Y a-t-il des contextes où ce modèle n’a pas fonctionné ?

Tucker Sauer-Pivonka :

Oui, selon la nature du projet. Si on fait un site web standard, processus répétable, là un forfait fixe a du sens. Nous n’en faisons pas, mais c’est plus prédictible. C’est vraiment une question de prévisibilité versus imprévisibilité.

Ben Aston :

Justement, il y a les discussions sur la tarification basée sur la valeur, très différente du modèle durée & prix. Comment compares-tu cela à la rentabilité, marge, simplicité de pilotage ? Vous ne traquez plus les heures… avez-vous des mauvaises surprises ?

Tucker Sauer-Pivonka :

Pour moi ce sont deux choses différentes. Avec la durée & prix, on ne sait pas toujours le résultat final exact, il peut évoluer. La valeur fonctionne mieux pour des choses prévisibles : un sprint de design, par exemple. Niveau rentabilité, c’est très intégré : comme on vend une équipe, la rentabilité est maîtrisée car l’allocation est claire. Pas de dépassement d’heures – la valeur est apportée sprint par sprint, sans souci de quota d’heures atteint ou non.

Ben Aston :

Donc, le client loue une équipe pour une durée. Mais que se passe-t-il si, après quelques sprints, le client dit “je ne vois pas la valeur” ? Comment gérez-vous ce cas-là ?

Tucker Sauer-Pivonka :

Cela arrive rarement car nous veillons à l’alignement client, à chaque début de sprint et tout au long du cycle. Beaucoup de communication et gestion de la relation client. Dès qu’un blocage ou changement apparaît, on explique, on expose les faits, on enlève l’affect afin que le client comprenne rationnellement et puisse décider.

Pendant chaque sprint et avant de démarrer, l’équipe et le client s’accordent sur le contenu. Démonstration à la fin, discussion sur tout report éventuel. Cela limite les surprises et les incompréhensions.

Ben Aston :

Parlons du cas d’étude et du calendrier. Tu estimais sept mois d’effort. Comment arrives-tu à ce chiffre si le produit cible n’est pas connu dès le départ ?

Tucker Sauer-Pivonka :

Très bonne question. Après une phase amont de prototypage et de tests techniques, souvent sur six semaines. Cela permet d’évaluer techniquement et d’avoir un premier cadrage. On développe le feeling de ce qui prendra du temps, selon la complexité. Puis, en équipe de production, on ne détaille pas toutes les user stories, mais on découpe les lots, on estime la complexité et on propose la taille de l’équipe. Puis, on regarde l’appétit budgétaire du client, les objectifs métiers et la réalité : un projet logiciel n’est jamais “terminé”, mais on s’aligne sur un objectif minimal atteignable dans la période proposée.

Ben Aston :

Je suppose que, lors de la vente, tu t’assures de la capacité du client à prolonger le contrat si besoin.

Tucker Sauer-Pivonka :

Exact. Si le client ne souhaite que trois mois, c’est possible. On applique le même principe d’équipe allouée, priority-driven, pour produire le plus de valeur possible dans la période.

Ben Aston :

La première étape est donc le prototypage et la validation. Est-ce un forfait, ou durée & prix également ? Et qu’en est-il des livrables à l’issue des six semaines ?

Tucker Sauer-Pivonka :

Techniquement, c’est toujours en durée & prix, mais plus proche d’un forfait : on promet, par exemple, un prototype haute fidélité, les fichiers Sketch, les comptes-rendus de tests utilisateurs… mais si on doit pivoter en cours de route, c’est possible. Ce n’est pas fix lié à un nombre d’écrans, toujours basé sur la durée.

Ben Aston :

C’est bien, car le prototypage donne souvent lieu à des ajustements. Donc après six semaines, on obtient un prototype, tests utilisateurs, puis tu annonces environ sept mois d’effort. Est-ce une estimation bottom-up ou top-down, liée au budget du client ?

Tucker Sauer-Pivonka :

Heureusement, ici, on avait défini les lots, la complexité, une idée des plans techniques, construit une feuille de route. On précise toujours que cela peut évoluer. Nous présentons une proposition, détaillant les étapes, le roadmap, le contenu estimé à chaque phase, puis l’équipe et le client affinent selon l’appétit budgétaire et priorités. C’est cette démarche qui a mené à sept mois d’effort.

Ben Aston :

Super.

Tucker Sauer-Pivonka :

Et si cela devait changer à cause d’un calendrier ou d’un budget différent, on s’adapte. Nous avions la maturité côté client pour dialoguer là-dessus, ajuster la roadmap si besoin.

Ben Aston :

Parlons de méthodologie. Dans le cas présenté, tu évoques une approche agile/Scrum, mais pas dogmatique. Quelles adaptations faites-vous à Scrum, notamment le rôle de “product owner”, “scrum master” ?

Tucker Sauer-Pivonka :

Chez nous, on préfère “l’humain avant le process”. On pratique le “scrum avec un s minuscule” : on offre assez de flexibilité pour que les équipes adaptent leur processus selon le client. Dans une agence, c’est complexe d’avoir tous les rôles de Scrum. Typiquement, le product owner est notre interlocuteur client au quotidien. Si nous avons un stratège, il coache parfois le product owner client, qui ne connaît pas toujours l’univers logiciel. Le product manager peut aussi endosser une partie du rôle, quand le client n’est pas disponible chaque jour. PM et Scrum Master sont fusionnés chez nous. Cela va à l’encontre de Scrum “by the book”, mais ça marche bien. Nous menons toutes les cérémonies Scrum (stand-ups – souvent automatisés –, planning, rétrospectives, démos, etc.), généralement regroupées le mercredi lors d’un “kick-off”.

Ben Aston :

Parfois, le client est product owner, parfois le PM côté agence. Je veux parler de la gestion du changement. Dans le cas, le client devait garder opérationnel l’ancien produit (paiement), donc deux projets en parallèle, priorité variable, scope qui grandit. Comment accompagnez-vous concrètement le client dans ces enjeux de priorisation et de gestion du backlog ?

Tucker Sauer-Pivonka :

Première chose, être empathique envers la source du changement côté client. Souvent, le client n’a pas envie de changer d’objectif, mais n’a pas le choix. Il faut comprendre “pourquoi”. Une fois ce contexte posé, bien expliquer l’impact que chaque changement a, en étant ultra clair sur ce que cela décale (autre fonctionnalité reportée, etc.). Informer l’équipe, expliquer les raisons, enlever l’émotion, c’est essentiel. Cela aide l’équipe à comprendre et à accepter.
Puis, à chaque étape, rendre évident au client qu’un changement modifie le planning : “OK, mais cela décale telle fonctionnalité, en êtes-vous conscient ?” Cela évite les incompréhensions et permet de décider rationnellement. On utilise tous les outils visuels possibles (Jira, etc.) pour faciliter la compréhension des impacts.

Ben Aston :

Le client a-t-il accès à Jira, à vos outils ?

Tucker Sauer-Pivonka :

Oui, nous prônons la transparence totale : ils accèdent à tous nos outils, sont parfois invités dans notre Slack, mais surtout sur Jira. Ils supervisent les priorités, valident les exigences, s’assurent de la cohérence. Cette transparence réduit fortement les surprises en cours de sprint.

Ben Aston :

As-tu rencontré des clients dépassés par le nombre d’informations et la technique (backlog, tickets Jira, etc.) ? Comment gérer cela tout en gardant la confiance ?

Tucker Sauer-Pivonka :

Une partie de la confiance se construit sur la transparence et l’humilité face à nos erreurs. Admettre ses erreurs humblement accélère la confiance. Plus tu le fais, plus le client se dit qu’il est en face de vrais partenaires.
Pour l’outil, rien n’est imposé : nous faisons des captures vidéos pour expliquer Jira, guider les clients, indiquant ce qu’ils doivent regarder et ce qu’ils peuvent ignorer. S’ils se sentent perdus, ils doivent nous le dire, on aide rapidement. C’est rare, parfois sur la validation de design (il y a parfois des centaines d’écrans…), donc on livre par itérations, de façon à ne pas tout livrer d’un coup, et on prévient si une accumulation menace.

Ben Aston :

Quel reporting fournissez-vous au client ? Des timesheets ?

Tucker Sauer-Pivonka :

Non, nous axons le reporting sur les résultats livrés à chaque sprint : avancement, travail accompli, vélocité, explications sur d’éventuels retards, etc. Nos propres suivis d’allocation servent à assurer l’équilibre des ressources, pas à fournir au client les heures passées précisées. Si un profil dépasse son allocation, on en parle avec le client pour ajuster ses tâches ou l’allocation. Mais il n’y a pas de reporting d’heures – on se concentre sur la valeur délivrée.

Ben Aston :

Pour conclure, dans quels cas ces contrats échouent-ils ? Comment repérer et traiter un client sous-impliqué ou déçu ?

Tucker Sauer-Pivonka :

Les échecs surviennent surtout en cas de désalignement ou de sous-communication. Si le client semble insatisfait, il faut provoquer la discussion très honnêtement, sans attendre la fin du contrat sinon il ne sera pas renouvelé et la confiance impossible à restaurer. On n’a jamais connu de vrai échec total, mais parfois des renégociations à cause de réalignements, des imprévus ayant fait dériver le projet. Il faut alors bien expliquer l’origine, remettre en perspective : si on pivote deux mois pour telle priorité business, il faut accepter ce qui glisse. L’important, c’est que le client comprenne cette relation itérative et reste impliqué dans la gouvernance. Sinon, peut-être n’est-il pas le bon profil de client, et ce n’est pas grave, autant le savoir vite.

Ben Aston :

Mon grand enseignement, c’est que ce système requiert des clients matures, ouverts à l’idée que les priorités et coûts évoluent avec le temps. Ce n’est pas toujours évident, surtout en compétition d’agence ou sous contraintes budgétaires. Le processus d’avant-vente, d’éducation du client durant la phase prototypage/validation, est donc crucial pour installer les bonnes attentes. Le résultat, c’est plus de valeur délivrée, en phase avec les vrais besoins du client, sans raccourcis risqués pour tenir un prix ou un délai. Grand merci Tucker pour ton retour d’expérience.

Tucker Sauer-Pivonka :

Avec plaisir, c’était vraiment un super échange. Merci de m’avoir invité.

Ben Aston :

À vous qui nous écoutez, j’aimerais savoir si vous avez tenté un contrat agile. Dites-nous comment ça s’est passé, commentez ce post et venez sur TheDigitalProjectManager.com pour nous rejoindre sur Slack. Il y a plein de discussions sur la livraison de projet, et un canal agile pour approfondir le sujet ensemble.

Si ce podcast vous a plu, merci de vous abonner et de prendre deux minutes pour laisser un avis honnête sur le podcast DPM sur Apple Podcasts. Vos avis comptent beaucoup pour nous. À bientôt et merci pour votre écoute.