Quelqu'un dont le métier est de décider ce que le logiciel doit faire
Vous avez des développeurs, un éditeur ou un intégrateur, et un produit qui avance mal. Ce n'est presque jamais un problème de code : c'est qu'entre le métier et l'outil, personne ne tranche. C'est ce rôle-là que nous prenons.
Product Owner en régie, à la journée. Nous écrivons le besoin, nous tenons le backlog, nous recettons ce qui est livré, et nous accompagnons ceux qui devront s'en servir. Le code reste chez vous ou chez votre prestataire — nous ne le remplaçons pas, nous lui donnons de quoi travailler.
À qui ça s'adresse
Un éditeur qui manque de bras côté produit. Les développeurs attendent des spécifications, le commerce promet des dates, et la personne qui devrait arbitrer fait déjà deux autres métiers.
Une entreprise qui fait développer un outil sur mesure. Vous payez au temps passé sans savoir dire, à la fin d'un sprint, si ce qui a été livré est conforme — parce que rien n'a jamais été écrit sous une forme vérifiable.
Un projet d'intégration qui n'a personne en interne pour le porter. Nous le disons ailleurs sur ce site : un ERP n'est pas une livraison, c'est un changement d'habitudes, et il faut quelqu'un chez vous. Quand ce quelqu'un n'existe pas encore, ce rôle peut être tenu de l'extérieur — le temps de le construire.
Ce que le rôle recouvre
Quatre gestes, et ils se tiennent : sauter le premier rend les trois autres impossibles.
Séparer la demande du besoin
Un client n'exprime presque jamais son besoin : il exprime une demande, déjà formulée en solution. Entretiens utilisateurs, observation des processus réels, note de cadrage. Un besoin mal qualifié coûte plus cher que tout le reste réuni.
Un backlog vivant, pas un cimetière à tickets
Des user stories qui portent un critère d'acceptation constatable — une phrase dont on peut dire qu'elle est vraie ou fausse en la mesurant. Une priorisation assumée et argumentée, pas une liste où tout est urgent.
Dire si c'est conforme, et le prouver
Critères d'acceptation au niveau de la story, definition of done au niveau de l'équipe, cahier de recette au niveau du livrable. Les trois ne se confondent pas, et c'est en les confondant qu'on livre des choses que personne n'a vérifiées.
La technique réussit, le changement échoue
Un outil paramétré correctement est jeté quand les utilisateurs n'ont pas voulu — ou pas pu — changer leurs habitudes. Le repérer avant la bascule fait partie du travail, pas d'une option qu'on vend en plus.
D'où ça vient
Dix ans passés à concevoir des logiciels de gestion chez un éditeur, du côté où l'on décide ce que le logiciel permettra — puis de l'autre côté, chez ceux qui s'en servent. Ce va-et-vient sert surtout à une chose : savoir quelles questions poser avant d'écrire une ligne de spécification, et reconnaître une demande qui cache un contournement.
C'est le même métier que l'intégration Odoo, vu d'un cran plus haut : là-bas nous configurons un standard, ici nous écrivons ce qu'un produit doit faire. Ce qui relie les deux.
Comment ça se vend
En régie, à la journée. Vous achetez un nombre de jours par mois, nous les tenons, et le temps passé est relevé et validé. Pas de forfait ici : un rôle de Product Owner ne se borne pas d'avance sans mentir sur ce qu'il fait.
Un rythme, pas une présence. L'engagement usuel est de quelques jours par mois, réguliers, avec un point fixe et des livrables datés. C'est ce qui rend le rôle utile : il tient dans la durée, et il se prépare entre deux séances.
Ce que vous gardez. Le besoin écrit, le backlog, le cahier de recette et la note de cadrage sont à vous et lisibles sans nous. Comme ailleurs : vous n'êtes captif de personne, y compris de nous.
Ce n'est pas pour vous si…
- Vous cherchez quelqu'un pour écrire les spécifications une fois et disparaître. Une spécification livrée puis abandonnée est fausse au bout de trois semaines. Le rôle vaut par sa continuité, ou il ne vaut rien.
- Vous voulez que le Product Owner porte aussi la décision métier. Nous arbitrons ce que le logiciel doit faire ; nous ne décidons pas à votre place ce que l'entreprise doit vendre. Il faut quelqu'un chez vous qui tranche cela.
- Le vrai sujet est un manque de développeurs. Nous n'en fournissons pas. Un backlog impeccable devant une équipe qui n'existe pas ne produit rien.
Parler de votre produit — 30 min Écrire plutôt
Votre sujet est plutôt de mettre vos flux de gestion au même endroit : la méthode d'intégration Odoo. Ou l'échéance du 1er septembre 2026 : la conformité facture électronique.