En tant que Product Owner, je suis le garant de la valeur délivrée par l'équipe Scrum. Mon rôle est de définir la vision du produit, de gérer le backlog produit (items, priorisation) et de communiquer avec toutes les parties prenantes. Concrètement, je crée et j'ordonne les user stories du backlog en m'assurant qu'elles sont claires pour l'équipe, et je fixe les objectifs de release. Je représente la voix du client et je m'assure que les décisions sont comprises et respectées par l'équipe.

En pratiqueSituation : sur un projet précédent, le produit s'éloignait de la stratégie initiale. Tâche : retravailler la vision produit avec la direction. Action : j'ai animé un atelier avec le comité de pilotage pour clarifier la roadmap et recentrer les priorités du backlog sur les objectifs business. Résultat : l'équipe a réorienté son travail, et le produit réaligné a vu la satisfaction client progresser de 30 %.

Le Product Owner est centré sur le quoi : il définit et priorise le backlog pour maximiser la valeur du produit. Le Product Manager a un rôle plus large, souvent transverse à plusieurs équipes ou produits ; il se concentre sur la stratégie long terme et le cycle de vie global - le pourquoi du marché, la veille, le marketing. Le Scrum Master est responsable du comment : il facilite Scrum, lève les obstacles et aide l'équipe à gagner en efficacité. En résumé : le PO fait le lien avec le métier et le client, le PM porte la roadmap globale, le SM protège le fonctionnement de l'équipe.

Je définis la vision du produit en combinant étude du marché, feedback utilisateurs et objectifs de l'entreprise. J'élabore un product backlog initial qui représente cette vision globale. Puis je construis une roadmap - un plan de développement sur plusieurs releases - en détaillant les fonctionnalités qui apporteront le plus de valeur. Je m'appuie sur des ateliers de product discovery (benchmarks, prototypes, interviews clients) pour établir des hypothèses de valeur. La roadmap reste flexible : elle est revue régulièrement, chaque trimestre par exemple, avec le comité de pilotage et l'équipe, afin d'ajuster le tir selon les retours terrain.

Je priorise en croisant valeur client, impact business, effort de développement et délais. J'utilise des cadres de priorisation agiles - RICE ou MoSCoW - pour objectiver mes choix. Avec MoSCoW par exemple, je classe les fonctionnalités en Must have (indispensables au MVP), Should / Could have (importantes mais secondaires) ou Won't (pas pour cette release). En pratique, j'anime un atelier backlog avec l'équipe et les parties prenantes, où nous évaluons les items selon leur retour sur investissement et l'urgence business. Je veille aussi à maintenir la transparence des critères retenus.

En pratiqueSituation : sur un produit e-commerce, l'équipe souhaitait créer un chatbot avancé alors que le trafic mobile baissait. Tâche : arbitrer entre améliorer l'appli mobile ou développer le chatbot. Action : j'ai organisé un atelier avec les data scientists et le marketing, où nous avons estimé le ROI de chaque option. Résultat : nous avons d'abord revu l'expérience mobile ; les ventes mobiles ont progressé de 15 %. Le chatbot est venu ensuite.

La dette technique n'est pas un tabou : je l'inscris au backlog comme des stories. J'évalue son impact - risque de bug, ralentissement, dette d'architecture - et son effort. Je la traite en continu : si l'équipe termine un sprint plus tôt, nous embarquons une story de refactoring ou de mise à jour de dépendances. Je communique aussi aux parties prenantes le coût implicite de cette dette : refactoring futur, sécurité, performance. Si un élément critique affecte la release, il passe en haut du backlog. Pour le reste, je réserve 10 à 20 % de chaque sprint à la dette.

Le MVP est la version la plus simple du produit qui permette de valider une hypothèse métier ou utilisateur. Il ne contient que les fonctionnalités qui apportent de la valeur immédiate. Pour le définir, je liste tous les besoins possibles, puis j'isole ceux qui sont indispensables à la résolution du problème principal du client. J'assemble ensuite un prototype minimum pour tester. Sur une application de livraison, le MVP se limitait à la recherche d'articles et au panier, sans module de paiement complexe. Lancer tôt, corriger la trajectoire sur les premiers retours, ajouter le secondaire ensuite.

Un bon backlog item respecte le critère INVEST : Independent, Negotiable, Valuable, Estimable, Small, Testable. Par exemple : « en tant qu'utilisateur, je veux me connecter via Google pour accéder plus rapidement à mon compte ». Il doit porter des critères d'acceptation précis. Je les rédige avec les développeurs, pour m'assurer qu'ils comprennent l'objectif métier. Je veille aussi à découper les stories trop grosses en sous-stories d'un à deux jours de travail : le backlog reste transparent, et l'estimation comme le suivi deviennent possibles.

En pratiqueSur un produit télécom, une user story disait « créer un portail client ». C'était trop vague. Je l'ai reformulée en plusieurs stories concrètes - connexion, tableau de bord, gestion des factures - avec des critères d'acceptation clairs. L'équipe a pu estimer et planifier chaque story précisément.

Selon Scrum, une fois le sprint lancé, le sprint backlog doit rester stable. Si une exigence change, j'analyse d'abord sa criticité. Si elle est vraiment urgente - un défaut bloquant, par exemple - je consulte le Scrum Master et l'équipe pour en évaluer l'impact. Nous formulons en général deux options : intégrer le changement si l'urgence est critique, ou le planifier au sprint suivant. L'important est de ne pas dévier du sprint en cours à moins que ce soit vital. Ensuite, j'explique aux parties prenantes pourquoi nous tenons ou modifions le sprint, et nous ajustons le plan ensemble. C'est l'esprit Agile : s'adapter vite si nécessaire, mais avec transparence et l'accord de toute l'équipe.

En pratiqueEn plein sprint, une évolution réglementaire a imposé un nouveau champ de données. Après discussion avec les développeurs et le sponsor, nous avons inséré une tâche d'étude d'impact en fin de sprint - un spike. Les développeurs ont clarifié le besoin technique sans compromettre les stories planifiées, et la story réglementaire est entrée dans le sprint suivant.

J'entretiens une communication constante avec les développeurs. Je participe activement au refinement chaque semaine : j'y explique chaque user story, je réponds aux questions et je recueille les retours techniques. J'utilise souvent des user journey maps ou des prototypes pour illustrer le besoin. Pendant les daily, si un point d'ombre apparaît, je le clarifie immédiatement. L'idéal est un dialogue ouvert : je reçois leurs critiques sur la viabilité des spécifications, et je m'assure qu'ils comprennent l'utilisateur final. Si un développeur trouve une story mal définie, nous prenons une session de précision à deux. Résultat : chaque story prise en sprint est claire pour les deux parties, ce qui réduit les retours en arrière. Je partage aussi la vision et les objectifs en kick-off, puis je les rappelle en sprint planning et en revue, avec un tableau de bord visible de tous.

En pratiqueSur un projet mobile, certains développeurs ne voyaient pas l'usage final d'une fonctionnalité. J'ai organisé une démonstration interne : j'ai déroulé un scénario complet de l'application dans un outil de wireframe. Cette mise en contexte a clarifié l'objectif, et l'équipe a livré la fonctionnalité en respectant exactement le besoin métier.

J'utilise Jira pour le backlog produit et le suivi des user stories : j'y crée les tickets, j'ajoute les critères d'acceptation et j'organise les sprints. Confluence me sert de documentation centrale - vision produit, documentation utilisateur, rétrospectives. Pour le partage rapide d'idées et de maquettes, j'utilise Miro en atelier de brainstorming ou de user story mapping. Un canal Slack ou Teams dédié porte les échanges quotidiens avec les développeurs et les parties prenantes. Chaque sprint, j'envoie enfin un récapitulatif de release : la communication transverse ne s'improvise pas.

Avant le sprint planning, je m'assure que les user stories sont prêtes - claires et estimées. Pendant la réunion, je présente le Sprint Goal proposé avec les stories correspondantes. Je laisse l'équipe estimer et questionner chaque story. Nous décidons ensemble de la capacité du sprint, à partir de la vélocité précédente. Je ne cherche pas à surcharger : je fais confiance à l'équipe pour évaluer sa charge. Si les estimations évoluent pendant la planification, je repriorise pour rester cohérent avec l'objectif. À la fin, l'équipe et moi validons ensemble l'engagement sur le sprint backlog.

Je m'appuie sur le Design Thinking, le Lean Startup et la recherche UX. J'anime des ateliers de co-création avec des utilisateurs pour dégager les fonctionnalités clés, et j'utilise des prototypes à faible coût pour tester rapidement des hypothèses. Je mets aussi en place des enquêtes et des interviews clients pour comprendre les besoins réels. Quand c'est possible, je mesure la pertinence d'une fonctionnalité via un MVP : une version bêta sur un petit groupe d'utilisateurs, dont les retours servent à prioriser ou à ajuster avant de développer en grand.

En pratiqueSur un projet fintech, j'ai utilisé un Lean Canvas pour résumer les hypothèses clés, puis créé un prototype simple du processus de paiement. Les tests utilisateurs ont révélé que le bouton de confirmation était peu visible. Nous avons corrigé le prototype avant d'écrire la moindre ligne de code : plusieurs jours de développement économisés sur un problème de design.

Je choisis des KPI alignés sur les objectifs du produit. Selon le contexte : taux d'adoption (utilisateurs actifs), revenu généré, revenu par client, satisfaction et NPS, taux de conversion, ou délai de livraison. Sur un produit SaaS, j'ai suivi le MRR et le churn rate ; sur un site e-commerce, le taux d'ajout au panier et le panier moyen. J'établis ces métriques au lancement, puis j'analyse leur évolution à chaque revue de sprint. Ce sont elles qui guident mes arbitrages de priorisation - si le taux de conversion est bas, les fonctionnalités qui l'améliorent remontent dans le backlog.

Je crée des boucles de rétroaction régulières. Après chaque release, je collecte les retours via des enquêtes NPS ou des interviews. J'analyse aussi les tickets de support pour identifier les problèmes récurrents. Je convertis ensuite ces retours en items de backlog : corrections, améliorations UX, nouvelles demandes. En revue de sprint, j'invite parfois de vrais utilisateurs ou des clients clés pour qu'ils voient l'avancement et réagissent en direct. La roadmap évolue avec la voix du client, pas contre elle.

En pratiqueSur un site e-commerce, les enregistrements de session et les enquêtes utilisateurs montraient que le tunnel de paiement était confus. J'ai ajouté une story pour simplifier l'interface en un formulaire d'une seule page. Le taux d'abandon panier a baissé de 25 %.

Je ne livre pas une fonctionnalité LLM sans jeu de test de référence écrit avant le développement : une trentaine de cas réels, chacun avec la réponse attendue et le motif d'échec qu'on veut exclure. On mesure la part de réponses acceptables, et le seuil fait partie des critères d'acceptation de la story, pas d'un rapport annexe. Je distingue deux échecs, parce qu'ils ne se corrigent pas au même endroit : la réponse fausse se traite par le contexte fourni au modèle, la réponse hors périmètre par le prompt système et les garde-fous. Toute régression vue en production entre dans le jeu de test, qui ne rétrécit jamais.

En pratiqueSituation : une génération de texte qui convainquait en démo et décevait à l'usage. Tâche : rendre la qualité mesurable avant d'y remettre un euro. Action : un jeu de 40 cas réels, un seuil de 85 % de réponses acceptables inscrit en critère d'acceptation, et chaque signalement utilisateur versé au jeu. Résultat : deux itérations ont porté le taux de 61 % à 88 %, et l'équipe a cessé d'arbitrer au ressenti.

Je traite une hallucination comme un défaut produit, pas comme un incident technique : elle a une fréquence, une gravité et un coût pour l'utilisateur, donc une place et un rang dans le backlog. J'agis à trois endroits. La source : si le modèle doit énoncer des faits, il ne les invente pas, il les lit — c'est le rôle du RAG, et je surveille la couverture de la base plus que la finesse du prompt. Le garde-fou : un refus explicite vaut mieux qu'une réponse plausible, et « je ne sais pas » est un succès. L'interface enfin : citer la source, permettre de corriger, et sur un usage à enjeu, imposer une relecture humaine et l'assumer dans le parcours.

Ce sont trois curseurs sur un même budget, et c'est un arbitrage produit. Je pose d'abord le coût unitaire acceptable : ce qu'un appel peut coûter pour que la fonctionnalité reste rentable au prix où on la vend. Puis la latence tolérable, qui dépend du moment du parcours — trois secondes sont invisibles dans la génération d'un rapport, insupportables dans un champ de recherche. Le modèle le plus capable n'est presque jamais le bon partout : je route les cas simples vers un modèle petit et rapide et je réserve le gros modèle à ce qui le justifie. Sur build ou API, mon critère est explicite : on consomme une API tant que le coût par appel reste sous le coût d'exploitation d'un modèle à nous.

Je pars du problème, pas de la technologie. Un LLM se justifie quand l'entrée est du langage libre et que les cas ne s'énumèrent pas : classer des messages entrants, extraire d'un document dont le format varie, reformuler. Dès que les cas s'énumèrent, une règle gagne sur tous les critères qui m'intéressent — déterministe, gratuite, instantanée, testable. Je me pose donc trois questions : saurais-je écrire la règle ? une erreur est-elle tolérable ici ? la valeur justifie-t-elle un coût par appel et une part d'imprévisible ? Et même quand j'y vais, je commence souvent par la règle, en réservant le modèle à ce qu'elle n'attrape pas : moins spectaculaire, beaucoup plus solide.

Je pose la règle avant la première ligne de code, parce qu'après c'est une reprise. Trois décisions. Ce qui sort : quelles données quittent notre périmètre et sous quel contrat — un fournisseur qui s'autorise à entraîner sur nos entrées est éliminé, pas négocié. Ce qui est minimisé : on n'envoie que le nécessaire, et la plupart des cas d'usage n'ont pas besoin d'un nom pour fonctionner. Ce qui est conservé : la durée de rétention des invites et des réponses, et qui peut les relire — un historique de conversations est un fichier de données personnelles comme un autre, et il est très souvent oublié. Ces trois points figurent dans la Definition of Done de toute story IA.

En pratiqueSituation : une fonctionnalité d'assistance devait consommer des échanges clients. Tâche : la rendre acceptable pour la sécurité avant de la développer. Action : cartographie de ce qui sortait réellement, suppression des identifiants inutiles à l'usage, fournisseur contractuellement interdit d'entraîner sur nos données, rétention fixée à trente jours. Résultat : validation obtenue en une seule revue au lieu des allers-retours attendus.

Une API est une promesse faite à du code qu'on ne contrôle pas : la casser coûte plus cher que ce qu'on gagnerait à la corriger. Ma règle par défaut : on ajoute, on ne retire pas — un champ nouveau est optionnel, un comportement nouveau se choisit. Quand une rupture devient inévitable, elle passe par une version nouvelle, les deux servies en parallèle, avec une date de fin annoncée dès le premier jour et non le jour où on veut éteindre l'ancienne. Je regarde qui appelle quoi avant de déprécier : sans cette mesure, une dépréciation est une décision prise en aveugle. Et le contrat écrit et le journal des changements sont des livrables de la story, comme le code.

En pratiqueSituation : une API interne consommée par cinq équipes, dont deux hors de mon périmètre. Tâche : changer un format de réponse devenu faux. Action : ouverture d'une v2 en parallèle, instrumentation des appels pour savoir qui utilisait quoi, fin de la v1 annoncée à six mois, accompagnement des deux équipes externes. Résultat : extinction dans le délai annoncé, sans aucune interruption chez les consommateurs.

Le principe ne change pas — valeur, coût, risque — mais les signaux, oui. Un développeur ne remplit pas de questionnaire de satisfaction : il contourne. Je cherche donc les contournements : le script maison que trois équipes ont réécrit chacune de son côté, la question posée dix fois sur le même canal, l'étape que tout le monde saute. Chacun est une demande non formulée, et souvent la plus rentable du lot. Je suis le temps du premier appel réussi pour une équipe qui découvre la plateforme, parce que l'adoption se gagne ou se perd là. Et je me méfie du piège du produit interne : sans concurrent, on confond usage obligé et usage voulu.

Par ce qu'elle fait gagner, jamais par ce qu'elle contient. Trois familles. L'adoption : combien d'équipes sur combien de possibles, et si la courbe monte — un catalogue de services que personne n'appelle est un coût, pas une plateforme. La friction : temps du premier appel réussi, part des demandes réglées en self-service sans nous, nombre d'allers-retours avant l'autonomie. La fiabilité de la promesse : respect des SLO, et surtout stabilité du contrat dans le temps. J'écarte volontairement la métrique qui flatte — le nombre d'API publiées — parce qu'elle récompense la production et non l'usage. Et je publie ces chiffres aux équipes clientes.

Jamais par une note de service : une adoption imposée produit une conformité de façade et un contournement six mois plus tard. Je fais trois choses. Je rends mon chemin plus court que le leur — si intégrer notre service demande plus d'efforts que garder leur script, ils ont raison de le garder, et c'est mon problème. Je prends une équipe pilote qui a un besoin réel, je l'accompagne moi-même, et son intégration devient la preuve : un exemple qui tourne convainc mieux qu'un argumentaire. Et je nomme ce que ma plateforme ne fait pas : la crédibilité d'une plateforme interne se construit autant sur les refus que sur les promesses.

En pratiqueSituation : deux équipes maintenaient chacune leur brique là où la plateforme visait à mutualiser. Tâche : obtenir une migration sans autorité hiérarchique. Action : coût d'intégration réduit à quelques lignes, accompagnement d'une équipe pilote de bout en bout, publication de ce que la plateforme ne couvrait pas encore. Résultat : la seconde équipe a migré d'elle-même après la démonstration de la première.

Je change de rôle : pendant un incident, je n'arbitre pas la technique, je tiens la communication et je protège l'après. Un seul canal, une seule voix : les équipes bloquées ont besoin de savoir où regarder, pas d'écrire cinq fois la même question. Un état plutôt qu'une promesse : ce qu'on sait, ce qu'on ne sait pas, et quand je reparlerai — un délai annoncé et tenu vaut mieux qu'un délai optimiste. Ensuite je protège le post-mortem : sans reproche personnel, avec des actions datées, et ces actions entrent dans le backlog au même rang que les fonctionnalités — sinon elles n'existent pas et le même incident revient.

Je résiste à la moyenne, qui ne satisfait personne. En B2C, l'utilisateur décide en trente secondes et le produit doit se comprendre seul. En B2B, celui qui paie n'est pas celui qui s'en sert, le cycle est long, et une régression coûte un contrat. Concrètement je garde un socle commun — cœur fonctionnel, authentification, facturation — et deux couches de surface. Sur la priorisation, je pondère le B2B par le revenu engagé et le B2C par le volume et l'effet d'apprentissage, ce qui rend les deux comparables sans les confondre. Et je nomme les demandes qui ne servent qu'un seul client : elles se facturent ou se refusent, mais ne se déguisent pas en fonctionnalité produit.

En pratiqueSituation : un produit vendu à la fois en libre-service et à des comptes annuels. Tâche : une roadmap qui ne se renégocie pas à chaque signature. Action : séparation d'un socle commun et de deux surfaces, priorisation pondérée par revenu engagé d'un côté et par volume de l'autre, ligne nommée pour les demandes mono-client. Résultat : la roadmap a cessé d'être rouverte à chaque contrat, et le sur-mesure a trouvé un cadre.

Beaucoup plus qu'on ne le croit, et c'est pourquoi je refuse que le pricing soit décidé loin de l'équipe produit. Un palier est une frontière technique : dès qu'une offre existe, il faut savoir qui a droit à quoi, le vérifier à chaque appel, gérer le passage d'un palier à l'autre, le prorata, l'échec de paiement, la rétrogradation. C'est du travail de backlog, pas une décision de communication. J'arbitre donc le packaging en tenant compte de son coût de construction : trois offres bien découpées valent mieux que sept qui imposent un système de droits qu'on ne saura pas maintenir. Et les indicateurs de monétisation entrent dans les mêmes revues que ceux d'usage.

Je refuse de le traiter comme un événement de fin : quand un client résilie, la décision est prise depuis longtemps. Je regarde le churn par cohorte et par palier, parce qu'un taux global ne dit rien — perdre des essais gratuits et perdre des comptes annuels sont deux problèmes différents. Ensuite je cherche les signaux d'avant : chute de fréquence d'usage, fonctionnalité clé jamais atteinte, incident vécu. Le plus rentable est presque toujours l'activation : un utilisateur qui n'a jamais atteint sa première valeur ne se retiendra pas plus tard. Enfin je fais parler ceux qui partent, sans chercher à les retenir dans l'entretien.

En pratiqueSituation : un taux de résiliation stable en apparence, qui masquait deux comportements opposés. Tâche : savoir où agir. Action : découpage par cohorte d'entrée et par palier, identification d'une étape d'onboarding jamais franchie par les partants, refonte de cette seule étape. Résultat : la cohorte suivante a franchi l'étape deux fois plus souvent, et sa rétention à trois mois a suivi.

Autour d'une seule question : quelle est la première valeur, et en combien de temps l'utilisateur y arrive. Je la nomme explicitement — pas « avoir créé un compte », mais le premier moment où le produit lui a rendu un service. Puis je compte les étapes qui l'en séparent et j'en supprime sans négocier : chaque champ demandé avant la première valeur se paie en abandons. Je diffère tout ce qui peut l'être, je préfère une valeur par défaut à un choix, et un exemple pré-rempli à une page vide — un écran vide est la pire première impression qu'un produit puisse donner.

En pratiqueSituation : une inscription en cinq écrans avant le moindre usage. Tâche : raccourcir sans perdre l'information nécessaire. Action : définition explicite de la première valeur, report de trois demandes après ce moment, exemple pré-rempli à la place de l'écran vide. Résultat : la part d'inscrits atteignant la première valeur est passée de 34 % à 58 %.

Comme une contrainte de conception, pas comme un document à produire. Trois choses vivent dans mon backlog. Le registre de ce qu'on collecte : chaque champ a une finalité, et un champ sans finalité se supprime — c'est aussi la meilleure façon de simplifier un produit. Les droits des personnes rendus exécutables : accès, export, suppression doivent être des fonctionnalités et non des tickets traités à la main. Et la durée de conservation, décidée par type de donnée et appliquée automatiquement — la rétention infinie par défaut est le cas le plus courant et le plus indéfendable. J'entretiens aussi la liste des sous-traitants et de ce qui sort du périmètre européen : c'est ce qu'un acheteur B2B demandera.

J'en fais un critère d'acceptation et un objet de négociation avec le métier. La fiabilité n'est pas gratuite : viser 99,9 % ou 99,99 % ne demande ni la même équipe ni le même budget. Je pose donc la question à l'envers : combien d'indisponibilité par mois est acceptable pour cet usage, et qu'accepte-t-on de ne pas construire pour l'obtenir. Une fois le SLO fixé, le budget d'erreur devient mon meilleur outil d'arbitrage : tant qu'il n'est pas consommé, on livre des fonctionnalités ; dès qu'il est épuisé, la priorité passe à la fiabilité. Et cette bascule est décidée avant l'incident, pas pendant.

En pratiqueSituation : une équipe écartelée entre demandes fonctionnelles et incidents à répétition. Tâche : sortir de l'arbitrage à chaud. Action : SLO négocié avec le métier, budget d'erreur suivi en revue de sprint, bascule de priorité vers la fiabilité écrite avant d'en avoir besoin. Résultat : la question « fonctionnalités ou stabilité » a disparu des réunions : elle était déjà tranchée.

Comme tout coût produit : en le rapportant à ce qu'il produit. Je veux le coût par utilisateur actif et par transaction, pas la facture globale — une facture qui monte parce que l'usage monte est une bonne nouvelle, et sans ce ratio on ne peut pas le savoir. Ensuite je cherche ce qui coûte sans servir : environnements laissés allumés, données conservées par défaut, traitements qui tournent plus souvent que nécessaire. Ce sont des stories courtes, très rentables, faciles à faire accepter. Enfin je nomme le seuil au-delà duquel une fonctionnalité n'est plus rentable au prix où on la vend : un renoncement argumenté par un coût unitaire se défend devant n'importe quel comité.

En pratiqueSituation : une facture d'infrastructure qui doublait en deux trimestres sans que personne sache pourquoi. Tâche : rendre le coût lisible avant de chercher à le réduire. Action : coût par utilisateur actif et par transaction, revue mensuelle, trois stories courtes sur les environnements dormants et la rétention des données. Résultat : coût unitaire ramené sous son niveau de départ alors que l'usage continuait de croître.

En refusant deux pièges : le grand soir, et la promesse de valeur qui n'existe pas. Je ne vends pas une migration comme une fonctionnalité — je la vends par le risque qu'elle retire et le coût qu'elle évite, chiffrés : fin de support, incidents récurrents, temps perdu, facture. Ensuite je la découpe pour qu'elle soit réversible à chaque étape : deux systèmes en parallèle, bascule progressive par population, retour arrière possible tant que l'ancien tourne. Une migration qu'on ne peut pas arrêter au milieu est un pari, pas un plan. Je réserve une capacité constante plutôt qu'un sprint dédié. Et le critère de fin est le décommissionnement de l'ancien, pas la mise en service du nouveau — sinon on paie les deux.

En pratiqueSituation : un socle en fin de support, dont la reprise n'avait aucun effet visible pour l'utilisateur. Tâche : obtenir une capacité sans promettre de valeur fonctionnelle. Action : chiffrage du coût de l'inaction, bascules réversibles par population, capacité fixe réservée à chaque sprint, décommissionnement inscrit comme critère de fin. Résultat : bascule terminée sans interruption, et ancien système éteint — donc plus payé.

En les traitant comme des utilisateurs de mon produit, pas comme un service en aval : ce qu'ils vivent la nuit est la conséquence directe de mes arbitrages du jour. Je les invite au refinement dès qu'une story touche à la fiabilité ou à la volumétrie, parce que la question « qu'est-ce que ça donne sous charge » ne se pose bien qu'avant. Je fais figurer dans la Definition of Done ce qui leur sert — journalisation utile, alerte actionnable, procédure de retour arrière — et je refuse de le traiter comme du bonus qu'on coupe en fin de sprint. Et je lis leurs indicateurs comme les miens : une équipe d'exploitation noyée est un signal produit.

En choisissant des indicateurs qu'on ne peut pas améliorer en trichant, et en ne les regardant jamais seuls. La vélocité en points ne sort pas de l'équipe : elle sert à planifier, pas à comparer, et elle se gonfle en trois sprints dès qu'on en fait un objectif. Je préfère les indicateurs de flux — fréquence de livraison, délai entre le début et la mise en production, taux de retour en arrière, temps de rétablissement — parce qu'ils décrivent le système et non l'effort des personnes. Et je les lis toujours par paires : livrer plus souvent ne vaut rien si le taux d'échec monte. Enfin je dis à l'équipe ce que je mesure et pourquoi.

En pratiqueSituation : une direction qui demandait de comparer la vélocité d'une équipe à l'autre. Tâche : fournir une mesure utile sans mettre les équipes en concurrence. Action : remplacement de la vélocité par quatre indicateurs de flux lus par paires, publication ouverte à tous, explication de ce qu'ils ne mesurent pas. Résultat : la comparaison entre équipes a cessé, et les deux discussions utiles ont commencé.

Face à un désaccord, j'écoute d'abord le point de vue de la partie prenante pour comprendre ses motivations. Je cherche ensuite à aligner ce besoin avec la vision produit. J'apporte souvent des données factuelles - études utilisateurs, ROI - pour appuyer mes choix de priorisation. Si un sponsor exige une fonctionnalité urgente, j'explique l'impact sur le planning et je propose un compromis, par exemple un MVP simplifié. Mon but est une solution gagnant-gagnant : intégrer la demande tôt, ou la planifier plus tard. Je reste transparent et ouvert au dialogue, et je fais respecter le cadre Scrum - in fine, seul le PO décide du backlog.

En pratiqueSituation : un client VIP voulait un module personnalisé non prévu. Tâche : décider de l'inclure ou non en plein sprint. Action : j'ai réuni l'équipe et le client, présenté l'impact sur le sprint en cours, et proposé un pilote après le sprint. Résultat : le client a accepté de décaler sa demande en échange d'un correctif immédiat. L'équipe a livré son sprint, et le module est entré dans la release suivante sans surcharge.

Sur un produit B2B, les ventes baissaient et l'équipe proposait d'ajouter une grosse fonctionnalité demandée par un seul client. J'ai dû choisir entre répondre à ce client ou renforcer une fonctionnalité plus stratégique. J'ai analysé les données : la nouvelle demande représentait trois mois de développement pour 5 % de chiffre d'affaires potentiel, quand une amélioration du funnel client bénéficiait à l'ensemble des ventes. J'ai retenu la seconde option. Pour gérer le client, je l'ai informé de notre priorité stratégique et lui ai proposé un module complémentaire dans la roadmap. Au final, les ventes globales ont augmenté de 12 %, et le client a obtenu un prototype à tester en avant-première.

Je maintiens une communication transparente et régulière. Je partage la vision et les objectifs produit en kick-off, puis je les rappelle en sprint planning et en revue. J'utilise un tableau de bord visible de tous pour que chacun suive l'avancement. Je rédige un récapitulatif mensuel des réalisations clés, et j'organise une démonstration de l'incrément livré à chaque revue de sprint : c'est l'occasion pour l'équipe de présenter son travail et pour les parties prenantes de poser leurs questions. En interne, j'encourage l'équipe à donner son avis sur la vision - c'est ce qui la garde impliquée.

Je présente une analyse coûts / bénéfices chiffrée. D'un côté, j'évalue l'investissement - développement, marketing. De l'autre, je projette les gains : ventes supplémentaires, rétention, temps économisé. Si je propose un moteur de recherche amélioré, j'estime le gain de conversion et je le traduis en euros par an. Je montre aussi l'alignement avec la stratégie : en quoi cela renforce la position sur le marché. Quand c'est possible, je m'appuie sur des tests A/B ou des benchmarks sectoriels. L'objectif est de traduire une fonctionnalité en impact concret, pas de plaider qu'elle est intéressante.

En pratiqueLors d'une revue de roadmap, j'ai défendu un outil de recommandation produit personnalisée en l'estimant à au moins 100 k€ de chiffre d'affaires supplémentaire par trimestre, benchmarks sectoriels à l'appui. L'analyse a convaincu le comité d'investissement ; six mois plus tard, nous mesurions +15 % de ventes sur le segment ciblé.

J'ai piloté le développement d'une application mobile de gestion de finances personnelles. J'ai d'abord mené des ateliers avec les utilisateurs finaux pour établir la vision. J'ai ensuite rédigé le backlog produit et organisé les releases par ordre de valeur : suivi des dépenses, budgets, conseils d'épargne. Tout au long du projet, j'ai animé les revues de sprint. Au déploiement, nous avons recueilli un NPS de 70, doublé le nombre d'inscrits en trois mois et réduit le churn de 15 %. Les parties prenantes ont estimé que la roadmap avait fortement contribué à la valeur business - +20 % de chiffre d'affaires récurrent.

Sur un projet précédent, nous avons lancé une fonctionnalité de chat client sans validation préalable. Les utilisateurs ont été peu réceptifs et l'usage est resté faible. J'avais mal évalué le besoin réel et bâclé le prototype. En post-mortem, j'ai identifié que je n'avais pas fait assez de tests utilisateurs avant la mise en production. J'en ai tiré deux règles : intégrer systématiquement un groupe pilote avant tout déploiement général, et mettre en place les indicateurs d'usage dès le sprint suivant. Les fonctionnalités suivantes ont été bien mieux alignées avec l'attente client.