Les deux. En direct, c'est plus simple : un seul interlocuteur, les arbitrages tranchés avec la personne qui porte le budget, et aucun filtre entre ce que l'équipe constate et ce que la direction entend. Mais une ESN qui m'apporte une mission a fait un travail réel, et ce travail se paie. Si vous passez par un intermédiaire, mon tarif ne change pas - ce que l'intermédiaire ajoute, il le facture au-dessus. Le marché mesure 20 à 30 % d'écart entre les deux canaux : c'est sa marge, pas la mienne, et je n'ai pas à la financer.

Ce que vous achetez, c'est un Technical Product Owner sur six domaines : AI & GenAI, API, Platform, Cloud, DevOps, B2B & B2C SaaS. Le tarif se lit là, et pas sur celui d'un proxy qui note les décisions des autres. 500 € HT le jour, tout compris : en Île-de-France, pas de frais de déplacement, pas de réunions ni de trajets facturés à part, pas de forfait de démarrage. Ailleurs, je travaille à distance. Si votre produit n'a besoin d'aucun des six domaines, dites-le : vous paierez pour une compétence que vous n'utiliserez pas, et ce n'est pas une bonne mission pour vous.

Vous payez un Technical Product Owner. Je décide du quoi et de l'ordre ; l'équipe conçoit le comment, et c'est sa prérogative, pas la mienne. Ce que « technique » ajoute : j'ouvre le dépôt, je lis ce que fait le code, j'écris des critères d'acceptation qu'un développeur n'a pas à retraduire, et je sais reconnaître un coût d'architecture quand on me le décrit. Ce que je ne fais pas, c'est prendre des stories dans le sprint que j'ai priorisé : un Product Owner qui code son propre backlog s'arbitre lui-même, et cesse d'arbitrer. Si c'est un développeur qu'il vous faut, c'est un autre métier, une autre page et un autre tarif.

Trois mois minimum, cinq jours par semaine par défaut. Trois ou quatre jours se discutent très bien si le produit n'en demande pas plus - je préfère un temps partiel assumé à un plein temps où l'on m'invente des réunions. En dessous de trois mois, je décline : un cadrage tient en quelques semaines, mais le premier arbitrage difficile arrive rarement avant le deuxième mois, et partir juste avant revient à vous laisser le plus dur. En dessous de deux jours par semaine aussi : un Product Owner absent le jour où l'on tranche n'est pas un Product Owner, c'est un rédacteur de comptes rendus.

Immédiatement - c'est ce qu'annonce la carte de tarif, et c'est vrai au jour où vous lisez cette page. Sur une mission en Île-de-France, je peux être sur site pour le lancement et passer en remote ensuite : les premiers jours sont ceux où l'on rencontre les gens, et ça se fait mal derrière un écran. Le reste s'organise selon ce dont le produit a besoin.

À vous, intégralement. Cession pleine et entière des droits au paiement, et elle couvre tout ce que la mission produit : le code, mais aussi le backlog, les spécifications, les schémas, la documentation et les comptes rendus de décision. Je n'en garde aucun droit d'usage et je ne réemploie rien chez un autre client. Ce qui reste à moi, c'est le savoir-faire - la manière de faire, pas ce qu'elle a produit chez vous. Un accord de confidentialité se signe sans difficulté, et je le signe avant le premier échange détaillé si vous le souhaitez.

Je facture via OMBREMIMS, ma société - vous contractez avec une SASU immatriculée, pas avec un particulier. Un contrat de prestation est signé avant le premier jour : il porte le périmètre, le tarif, le rythme et le préavis, et rien ne commence sans lui. Facturation mensuelle, à terme échu, payable à 30 jours, sur relevé des jours travaillés que vous validez ; TVA en sus au taux en vigueur. Kbis et attestation de vigilance URSSAF sont fournis à votre service achats sur simple demande.

Parce que ce n'est pas le statut qui décide, c'est la durée du besoin : une prestation se justifie quand le besoin a une fin, un poste quand il n'en a pas - et il y a des produits qu'on ne prend pas en main pour six mois. Trois choses changent, et rien d'autre. Le tarif : il n'y a pas de TJM en salariat. Le chiffre affiché sur ce site est un prix de prestation, il ne se convertit pas ; la prétention se discute au premier échange, sur ce que le poste vaut. Le contrat : les réponses qui suivent - préavis, exclusivité, assurance - ainsi que la facturation et la propriété des livrables plus haut décrivent la prestation. En CDI comme en CDD, c'est le droit du travail qui s'applique, et je n'ai rien de particulier à y ajouter. Et OMBREMIMS : la société ne ferme pas, elle change de rôle. Elle cesse toute activité de prestation intellectuelle le temps du contrat de travail - c'est la clause d'exclusivité que tout employeur écrit, et je la signe sans discuter. Restent la photographie et les produits, hors temps de travail et déclarés à l'embauche.

Un mois de préavis, de part et d'autre, sans motif à donner. C'est symétrique exprès : une clause qui ne protège qu'un côté finit toujours par se retourner. Mais le préavis est le filet, pas le dispositif. Le vrai dispositif est en amont : à la fin du premier mois, je provoque un point qui ne parle pas du produit - est-ce que ça marche, est-ce que j'occupe la place que vous attendiez, qu'est-ce qui vous gêne et que vous n'avez pas dit. Il est séparé des revues exprès, parce qu'un désaccord de fond glissé dans une revue de sprint ne se dit jamais. Un désaccord qu'on tait coûte plus cher qu'une mission qui s'arrête.

Non. Une mission, à temps plein, du début à la fin. C'est la contrepartie du plancher de trois mois : quelqu'un qui arbitre pour deux produits arbitre mal pour les deux, parce que le coût d'un mauvais arbitrage ne se voit qu'au sprint suivant - et il est ailleurs à ce moment-là. OMBREMIMS porte deux autres activités que vous verrez sur ce site, trois produits en construction et une activité de photographie : elles vivent en dehors des jours de mission, et aucune ne prend un jour que vous payez. Si vous voulez la règle écrite, elle entre dans le contrat.

Oui. Responsabilité civile professionnelle souscrite au nom d'OMBREMIMS, en cours de validité. L'attestation vous parvient avec le Kbis et l'attestation de vigilance URSSAF, sur simple demande - et avant le premier jour si votre service achats en fait une condition d'entrée. Ce sont les trois pièces que réclame à peu près tout donneur d'ordre : autant les avoir prêtes plutôt que de les chercher la semaine où vous vouliez démarrer.

Elle se prépare, elle ne s'annonce pas. Un mois avant le terme, je fais la liste de ce qui ne vit que dans ma tête : les arbitrages en attente, les interlocuteurs qu'il faut connaître pour trancher, et les raisons derrière des choix qui n'ont laissé aucune trace écrite. Ce qui manque s'écrit là où votre équipe ira le chercher - dans le backlog, dans le dépôt, dans vos outils - et non dans un document de passation que personne ne rouvre. S'il y a un successeur, nous nous recouvrons : il mène les rituels pendant que je suis encore là et que je peux répondre. Le critère de fin n'est pas mon dernier jour, c'est le premier arbitrage rendu sans moi. Une rupture en cours de route, elle, ne relève pas de cette question mais du préavis.

Oui. Des personnes avec qui j'ai travaillé sur la suite d'applications d'ingénierie acceptent d'être appelées. Je donne leurs coordonnées au stade de l'offre, quand la conversation est engagée des deux côtés - pas au premier message : une référence n'est pas une pièce de dossier qu'on distribue, c'est quelqu'un à qui l'on prend du temps. Ce que je demande en retour est symétrique, et il m'arrive de le demander en premier : pouvoir parler à la personne qui tenait le poste avant moi, ou à défaut à l'équipe. On apprend plus sur une mission en dix minutes avec elle qu'en lisant la fiche de poste.

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. Elle est 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. Les signaux, eux, changent. 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.

Une API est un engagement qui survit à l'écran : on peut redessiner une interface le mardi, on ne retire pas un champ d'API le mardi. Je regarde donc qui consomme, et pourquoi. Si une seule équipe a besoin de la donnée une fois, un export ou un écran coûte dix fois moins. Une API se justifie quand un tiers veut composer la capacité dans son propre flux, quand le volume d'intégration dépasse ce qu'un humain cliquerait, ou quand la capacité doit survivre à la refonte de l'interface. Publier une API avant de connaître ses consommateurs, c'est acheter une contrainte sans acheter un utilisateur.

En pratiqueSituation : une restitution de données demandée par deux équipes clientes. Tâche : trancher entre un écran et un point d'entrée d'API. Action : livré l'écran d'abord, instrumenté les exports, attendu la troisième demande avant d'ouvrir le contrat. Résultat : l'API est sortie trois mois plus tard avec un contrat déjà écrit par l'usage réel, et n'a jamais eu besoin d'une v2.

Un quota est une décision produit, pas un réglage d'exploitation. Je pars de l'unité qui coûte vraiment : l'appel, le token, la ligne rendue. Un palier gratuit doit permettre de réussir une fois, sinon il ne sert qu'à faire fuir. Les paliers payants s'indexent sur cette unité, et une limite dure protège la plateforme, pas la facture. Une limite atteinte doit rendre quelque chose d'actionnable : laquelle, et quand elle se réarme. Sur l'abus, je sépare la boucle par erreur de la boucle par intention : la première est un défaut de documentation, et se corrige dans la documentation.

En pratiqueSituation : un point d'entrée dont le coût par appel valait dix fois celui des autres. Tâche : arrêter la dérive sans fermer l'accès. Action : quota par clé, réponse 429 portant la date de réarmement, et documentation qui nomme le coût de l'appel. Résultat : consommation divisée par quatre en deux semaines, sans un seul ticket, parce que le coût était devenu visible.

C'est la première interface du produit pour un développeur, et elle se juge à un seul critère : quelqu'un d'extérieur réussit un appel sans poser de question. D'où l'ordre : un exemple exécutable avant la référence, les erreurs documentées avec autant de soin que les succès, et le contrat généré depuis la source plutôt que retapé, sinon il ment au premier changement. Qui l'écrit : l'équipe, dans la story, jamais « plus tard ». Une documentation écrite après coup décrit ce qui a été construit ; une documentation écrite avec la story attrape les fautes de contrat pendant qu'elles sont encore gratuites.

En pratiqueSituation : une API consommée par trois équipes, documentée dans une page de wiki mise à jour deux fois par an. Tâche : faire baisser la charge de support. Action : contrat généré depuis le code, exemples exécutables, catalogue des erreurs, et documentation entrée dans la Definition of Done. Résultat : les questions sur le canal se sont taries, et deux incohérences de contrat sont apparues pendant la rédaction.

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.

On construit ce qui différencie, on achète ce qui est devenu une commodité. Mais la vraie question est la seconde : ce que ça coûte de la maintenir dans trois ans. Une brique de plateforme n'est jamais finie. Je ne compare donc pas un prix à des jours de développement, je compare des totaux : intégration, migration, astreinte, et coût de sortie. Ce dernier décide plus souvent que le prix. Une brique que je peux remplacer en un trimestre vaut mieux qu'une brique moins chère qui m'enferme, et c'est pour ça que j'isole toujours le fournisseur derrière notre propre interface.

En pratiqueSituation : une équipe qui voulait écrire son propre SSO d'entreprise. Tâche : arbitrer. Action : chiffré les trois ans en incluant l'astreinte et la conformité, comparé à un fournisseur managé, et nommé ce qu'on perdait en contrôle. Résultat : acheté, avec l'intégration isolée derrière une interface à nous : le fournisseur reste remplaçable.

Une plateforme interne dont chaque demande passe par son équipe a déjà échoué : elle a remplacé un problème technique par une file d'attente. La mesure qui compte est donc la part de ce que les équipes font sans nous. D'où trois réflexes : le self-service avant la fonctionnalité, les portes de sortie documentées plutôt qu'interdites (une équipe qui doit contourner le fera de toute façon, autant savoir comment), et un chemin de contribution pour qu'une équipe qui a besoin de quelque chose puisse l'ajouter. Et la roadmap dit tout haut ce que la plateforme ne fera pas, pour que personne ne l'attende.

En pratiqueSituation : une équipe plateforme avec six semaines de file d'attente. Tâche : réduire l'attente sans recruter. Action : pris les trois demandes les plus répétées et transformées en self-service, ouvert un chemin de contribution avec revue, publié la liste de ce qu'on ne ferait pas. Résultat : file d'attente effondrée, et deux équipes ont livré leurs propres ajouts.

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é.

Le cloud n'est pas un changement d'hébergement, c'est un changement de modèle d'exploitation : qui paie, qui est réveillé la nuit, qui a le droit de créer une ressource. Je ne commence donc pas par la migration, je commence par une charge réelle, petite et réversible, et je laisse l'équipe y apprendre la facture, le modèle d'identité et l'astreinte. La formation est une charge de travail, pas une session. Et le critère de succès au départ n'est pas le coût, c'est l'autonomie : est-ce que l'équipe déploie sans nous.

En pratiqueSituation : une équipe entièrement sur site à qui on demandait le cloud en un an. Tâche : ne pas rater la première charge. Action : choisi un service interne non critique, donné à l'équipe son budget et ses alertes dès le premier jour. Résultat : une charge en production en trois mois, et une équipe capable de discuter la suite avec des chiffres au lieu d'un avis.

C'est une contrainte qui décide de l'architecture, donc elle entre dans le backlog avant la conception, pas dans une revue à la fin. Je pose trois questions à toute fonctionnalité qui stocke quelque chose : quelle donnée, dans quelle région, pour combien de temps. Les réponses deviennent des critères d'acceptation, vérifiables, et pas une ligne de politique que personne ne relit. Et j'écris ce qu'on refusera de faire : une règle de conformité qui n'a jamais rien bloqué n'a jamais été éprouvée.

En pratiqueSituation : un client exigeant une résidence européenne pour une fonctionnalité qui appelait un fournisseur de modèles américain. Tâche : garder la fonctionnalité. Action : identifié ce qui sortait réellement, basculé ce flux vers un fournisseur hébergé en Europe, documenté l'écart de qualité, et mis la région en critère d'acceptation. Résultat : fonctionnalité livrée, contrainte contractuelle tenue, et l'écart de qualité nommé plutôt que caché.

Managé par défaut, et il faut une raison pour en sortir. La raison est rarement le prix à la première facture : c'est une contrainte réelle, résidence, latence, ou une fonctionnalité que personne ne propose. L'auto-hébergement est un engagement permanent, pas une installation : correctifs, astreinte, capacité, montées de version. Je le chiffre donc en coût d'équipe récurrent, jamais en jours de mise en place. Et je tranche avec ceux qui porteront le téléphone, parce que ce sont eux qui paient la décision.

En pratiqueSituation : une base de données dont le coût managé avait triplé avec le volume. Tâche : décider. Action : mesuré ce que l'auto-hébergement demanderait en temps d'exploitation, posé la question à l'équipe concernée, et comparé avec la réduction du volume lui-même. Résultat : resté managé, rétention divisée par trois, facture en baisse de 40 % sans aucune migration.

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.

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é.

Comme tout le reste : par ce que ça change pour quelqu'un. Une chaîne qui prend quarante minutes coûte à l'équipe plusieurs ruptures d'attention par jour, et ça, c'est un chiffre. Je refuse donc la rubrique « technique » du backlog, parce qu'une rubrique séparée est une rubrique qu'on coupe en premier. Ces sujets s'écrivent en stories avec un effet observable et se priorisent contre les fonctionnalités, sur le même tableau. Ce que je ne fais pas : les promettre pour un sprint « plus tard », qui n'arrive jamais.

En pratiqueSituation : une chaîne d'intégration à 42 minutes, des mises en production groupées le vendredi. Tâche : remonter la fréquence de livraison. Action : écrit la chaîne en trois stories avec une cible mesurée, priorisées contre les fonctionnalités, et montré la courbe de fréquence à chaque revue. Résultat : 11 minutes, et le déploiement passé de l'hebdomadaire au quotidien.

Je n'arbitre pas « la dette contre les fonctionnalités », parce que posée comme ça elle perd à tous les coups. J'arbitre un effet contre un effet. Une dette qui ne coûte rien d'observable attend, et je le dis. Une dette qui se voit dans le délai de livraison, dans le taux d'échec des changements ou dans ce que plus personne n'ose toucher devient une story, avec cet indicateur-là en critère d'acceptation. Et je garde une part de capacité permanente plutôt que de la renégocier chaque sprint : une part qu'on renégocie est une part qu'on perd.

En pratiqueSituation : une suite de tests si lente que plus personne ne la lançait en local. Tâche : la remettre dans la boucle. Action : nommé l'effet (des défauts trouvés en revue plutôt qu'au commit), pris une part de capacité permanente, et découpé la suite. Résultat : suite repassée sous les trois minutes en local, et le taux de reprise en revue en baisse.

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.

Le Scrum Guide ne connaît pas ce titre, et c'est la première chose à dire : « Technical Product Owner » n'est pas un rôle Scrum, c'est une façon d'occuper celui de Product Owner. Le rôle ne bouge pas - l'ordre du backlog, la valeur, la décision du quoi. Ce qui change, c'est le terrain sur lequel les arbitrages tombent. Un Product Owner généraliste arbitre entre des fonctionnalités ; sur les six domaines que je prends - AI & GenAI, API, Platform, Cloud, DevOps, B2B & B2C SaaS - la moitié des arbitrages n'ont pas la forme d'une fonctionnalité : un seuil de qualité de réponse, une date de fin de vie d'API, un budget d'erreur, un coût par utilisateur actif. Ce sont des décisions produit rédigées en vocabulaire technique, et elles se prennent mal quand il faut trois réunions pour comprendre l'énoncé. Cela ne veut pas dire que je code votre produit - cette frontière-là est plus haut, dans « La mission ». Cela veut dire que je lis un contrat d'API, un tableau de latences ou une facture cloud sans intermédiaire, et que je sais ce que coûte un oui.

Les trois ne se recouvrent pas, et c'est justement quand ils sont tous les trois là qu'on le voit. Le Product Manager porte le pourquoi : la stratégie, le marché, le cycle de vie global, souvent en travers de plusieurs équipes ou produits. Le Scrum Master porte le comment : il facilite Scrum, lève les obstacles, protège le fonctionnement de l'équipe. Le Product Owner porte le quoi - et surtout le dans quel ordre : transformer une intention de marché en un backlog ordonné dont chaque item est assez clair pour être pris demain matin. Ce que j'apporte à cette configuration précise, c'est quelqu'un qui décide, et qui est là au moment où il faut décider : un Product Manager à cheval sur quatre produits n'a pas le temps d'arbitrer un désaccord de refinement, et ce n'est pas le travail du Scrum Master de le faire à sa place. Quand cette place est vide, ce n'est pas le backlog qui souffre en premier - c'est le délai entre une question et sa réponse.

Professional Scrum Product Owner I (PSPO I), délivrée par Scrum.org. C'est l'examen qui demande 85 % de bonnes réponses, sans formation obligatoire préalable, et qui ne se renouvelle pas : elle ne se périme pas et ne se rachète pas tous les deux ans. Ce qu'elle prouve est précis et limité - que je connais le cadre Scrum tel qu'il est écrit, et ce qu'il dit de la maximisation de la valeur et du coût total de possession d'un produit. Ce qu'elle ne prouve pas, c'est qu'on sache arbitrer sous contrainte : aucun questionnaire ne mesure ça, et c'est pour cette partie-là que le reste de cette page existe.

Pas de train SAFe ni de PI Planning, et je ne vais pas le prétendre. Ce que j'ai tenu est une autre forme du même problème : cinq applications interconnectées, une équipe de huit, et un référentiel de données partagé par les cinq. La difficulté d'un environnement scalé n'est pas le rituel, c'est la dépendance - une décision prise dans un périmètre casse le périmètre voisin, et personne ne s'en aperçoit avant la mise en production. J'en ai tiré deux règles que je porte toujours : la liste des consommateurs sur toute story qui touche un bien commun, et une personne par application dans le groupe qui valide. Si votre organisation tourne en SAFe, je m'y plie sans difficulté : ce n'est pas là qu'est le travail.

Oui, les deux, et au quotidien : rituels, backlog et spécifications en anglais, avec des interlocuteurs qui ne sont ni sur le même site ni dans le même pays. TOEIC 945/990, niveau C1 - mais un score dit ce qu'on comprend, pas ce qu'on tient dans une revue où deux personnes ne sont pas d'accord. Ce que le distribué change vraiment n'est d'ailleurs pas la langue, c'est que le couloir n'existe plus : ce qui se réglait en trente secondes debout doit s'écrire, et une story mal rédigée ne coûte plus une question, elle coûte un décalage horaire. J'écris donc davantage, et je décide moins en réunion.

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 %.

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 Product Owner 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é.

Huit ans chez GTT, sur une suite de cinq applications web d'ingénierie interconnectées par API, autour des données de navires et de cuves GNL. Équipe de huit : quatre développeurs, deux QA, un AMOA. Ce qui fait la difficulté d'un produit pareil n'est pas une fonctionnalité, c'est le couplage : cinq applications lisent le même référentiel, donc une décision prise dans l'une se paie dans les quatre autres. L'essentiel de mon travail y a consisté à tenir un ordre - quelle application avance, laquelle attend, et ce qu'on refuse de dupliquer pour aller plus vite. Particularité de ce terrain : les utilisateurs étaient des ingénieurs, pas des clients anonymes. Ils savaient exactement ce qu'ils voulaient, ce qui rend le cadrage plus rapide et l'arbitrage bien plus dur.

Une évolution du référentiel de données navires. Je l'avais cadrée avec l'équipe qui la demandait, et validée avec elle seule : le changement était juste, et il était petit. Il a cassé la lecture de deux des quatre autres applications, dont une utilisée le jour même. Ce que j'avais raté n'était pas la décision, c'était le périmètre de la conversation : sur un socle partagé, l'interlocuteur n'est jamais l'équipe qui demande, ce sont toutes celles qui lisent. Deux règles depuis : toute story qui touche le référentiel porte la liste des applications qui le consomment, et elle ne part pas sans un groupe pilote d'une personne par application - pas un comité, juste quelqu'un qui dira « chez moi ça casse » ; et je regarde les indicateurs d'usage des consommateurs après la bascule, pas seulement le test de la story.