Vision produit : définition, exemples et comment la définir

La vision produit, ou product vision, est la description du futur que l’on cherche à créer avec un produit : ce à quoi ressemblera l’expérience de ses utilisateurs dans deux à cinq ans, et pourquoi ce futur mérite d’être construit. Elle fixe un cap, pas un plan.

C’est aussi l’une des notions les plus malmenées du product management, confondue tour à tour avec la mission de l’entreprise, la stratégie ou la roadmap. Voyons ce qu’elle est, comment la distinguer de ces trois voisines, à quoi se reconnaît une vision réellement utile, et comment en formuler une.

Qu’est-ce qu’une vision produit ? Définition

La vision produit décrit le futur que l’équipe cherche à créer autour de son produit. Elle n’énumère pas les fonctionnalités à livrer : elle énonce l’état du monde de ses utilisateurs une fois le produit devenu ce qu’il doit être — ce qu’ils réussiront à faire, ce qu’ils n’auront plus à subir.

Sa fonction première est d’être un critère de décision. Un produit reçoit en permanence plus de demandes qu’il ne peut en absorber : clients, commerciaux, direction, support. Sans cap explicite, chaque arbitrage se règle au rapport de force, et le backlog produit devient l’agrégat des demandes de ceux qui insistent le plus.

Qui définit la vision produit ?

Le Product Owner ou le Product Manager en est le rédacteur, rarement l’auteur unique. La matière première vient du terrain — product discovery, entretiens utilisateurs, voice of customer — et l’arbitrage final remonte à la direction produit, au Chief Product Officer ou au dirigeant dans une structure plus petite. Une vision rédigée seule dans un coin ne circule pas.

Sur quel horizon de temps se projette-t-elle ?

L’usage dominant, formulé notamment par Marty Cagan du Silicon Valley Product Group, place la vision produit à deux à cinq ans, et plutôt cinq à dix ans pour un produit matériel. L’horizon n’est pas décoratif : trop court, la vision se confond avec la roadmap ; trop long, elle devient invérifiable et personne ne l’utilise pour décider. Annoncer l’horizon explicitement évite les deux écueils.

Vision, mission, stratégie, roadmap : ne plus les confondre

C’est le point où les contenus francophones dérapent le plus souvent : les quatre notions y sont employées l’une pour l’autre, et un même article peut appeler « vision » une mission d’entreprise en introduction, puis une roadmap trimestrielle trois paragraphes plus loin. Elles répondent pourtant à quatre questions distinctes, sur quatre horizons distincts.

Notion	À quelle question elle répond	Horizon	Ce qui la fait changer
Mission	Pourquoi l’entreprise existe-t-elle ?	Aucun terme fixé	Presque jamais
Vision produit	Quel futur veut-on créer pour les utilisateurs de ce produit ?	2 à 5 ans	Un pivot
Stratégie produit	Quels problèmes résoudre, pour qui, dans quel ordre, pour atteindre ce futur ?	6 à 18 mois	Un apprentissage majeur
Roadmap	Que livre-t-on, et quand ?	1 à 3 trimestres	En continu

La lecture est descendante : la mission cadre la vision, la vision oriente la stratégie, la stratégie alimente la roadmap. Chaque étage réduit le champ des possibles de celui du dessous, et sauter un étage se paie plus tard — une roadmap sans stratégie n’est qu’une liste de souhaits rangée par ordre d’arrivée.

La mission n’est pas une vision

La mission énonce la raison d’être de l’entreprise, en une formule courte et volontairement large — du type « organiser l’information mondiale ». Elle est faite pour être vraie longtemps et pour couvrir plusieurs produits. C’est ce qui la rend inutilisable comme vision : elle ne dit rien de ce produit-là. Marty Cagan relève d’ailleurs que la plupart des organisations à qui l’on demande leur vision produit présentent en réalité leur mission.

La roadmap n’est pas une vision

Le symptôme est facile à repérer : si votre « vision » contient des dates de livraison, des numéros de version ou des noms de modules, c’est une roadmap déguisée. La roadmap répond au quoi et au quand ; la vision répond au vers quoi. Entre les deux se logent la stratégie et les OKR, qui traduisent la trajectoire en résultats attendus sur un trimestre.

Le test du non : à quoi reconnaît-on une vision utile ?

La plupart des méthodes évaluent une vision produit à sa capacité à inspirer. Le critère est réel mais inexploitable : personne ne sait mesurer l’inspiration, et une phrase creuse bien rythmée passe le test sans difficulté. Il en existe un plus simple, et praticable en réunion : une vision produit vaut ce qu’elle permet de refuser.

Le mode opératoire tient en trois minutes. Prenez trois demandes récentes — pas des demandes absurdes, au contraire : trois demandes plausibles et défendables, du genre que l’on accepte par lassitude. Confrontez chacune à la vision. Si elle ne tranche aucune des trois, elle n’oriente rien : elle décore une page de Confluence.

Une vision correctement formulée rend en général trois familles de refus évidentes, sans qu’il soit nécessaire d’invoquer l’autorité de qui que ce soit :

• Le segment hors cible — la demande vient d’un utilisateur réel et payant, mais son besoin n’appartient pas au futur décrit. On peut le servir un jour ; pas maintenant, et on sait dire pourquoi.
• La fonctionnalité qui change la catégorie du produit — chaque ajout de ce type déplace le produit vers un autre marché. La vision permet de nommer le glissement avant qu’il ait eu lieu.
• Le revenu de court terme qui abîme la promesse — le cas le plus difficile : le gain est chiffré et immédiat, le coût diffus. C’est là qu’un cap écrit change la conversation.

Le contre-test : la vision passe-partout

Le symétrique du test du non est encore plus rapide : collez la vision sur le produit d’un concurrent. Si rien ne cloche, elle ne décrit rien. « Devenir la référence de notre marché », « offrir la meilleure expérience utilisateur du secteur » : aucune demande, jamais, ne contrevient à ces formules. C’est ce que je vérifie en premier quand une vision me paraît confortable — une vision qui ne coûte rien à personne n’engage personne.

Vision, OKR et objectif de sprint : trois échelles pour dire non

Le même mécanisme se rejoue à trois échelles emboîtées, et c’est ce qui en fait un système. La vision arbitre à l’échelle de l’année et écarte les directions ; les OKR arbitrent au trimestre et écartent les chantiers ; le sprint goal, l’objectif unique d’une itération en Scrum, arbitre à la semaine et écarte les tickets. Un filtre absent laisse tout passer à l’étage suivant. Le classement des demandes qui restent relève, lui, du scoring ICE ou d’un modèle équivalent : la vision décide s’il faut faire, le scoring dans quel ordre.

Comment définir une vision produit ? La méthode en cinq étapes

Une vision produit ne se trouve pas par introspection : elle se déduit d’un matériau, puis se taille par élimination. Cinq étapes suffisent, dans cet ordre — l’inversion des deux premières est l’erreur la plus fréquente.

1. Rassembler le matériau — entretiens utilisateurs, verbatims du support, données d’usage, contraintes du marché. Une vision écrite sans données décrit les préférences de son rédacteur.
2. Nommer le problème durable — celui qui existera encore dans cinq ans, quelle que soit la technologie du moment. Le cadre Job to be Done aide à le formuler en progrès recherché plutôt qu’en solution.
3. Décrire le futur des utilisateurs, pas le produit — ce qu’ils réussissent à faire dans ce futur, et non l’inventaire des écrans qui le permettront.
4. Fixer l’horizon — deux, trois ou cinq ans. Le dire dans la formulation la rend discutable, donc utile.
5. La soumettre au test du non — et la resserrer jusqu’à ce qu’elle refuse au moins trois demandes plausibles.

Deux gabarits de formulation : elevator pitch et product vision board

Deux formats se sont imposés, et ils ne servent pas au même usage. Le premier est un elevator pitch, popularisé par l’ouvrage Crossing the Chasm de Geoffrey Moore : une phrase à trous qui force la précision.

Pour [utilisateurs cibles] qui [besoin ou problème], [nom du produit] est un [catégorie] qui [bénéfice clé]. Contrairement à [alternative principale], notre produit [différence décisive].

Le second est le product vision board de Roman Pichler : un canevas d’une page qui range la vision et ses hypothèses en quatre colonnes — groupe cible, besoins, fonctionnalités clés, objectifs business. Il sert moins à formuler qu’à rendre les hypothèses visibles, donc testables. Les deux se complètent : le board pour travailler, la phrase pour trancher.

L’atelier vision produit

L’atelier est le format habituel des étapes trois et quatre. Il réunit l’équipe produit, une ou deux parties prenantes métier et, idéalement, quelqu’un qui parle régulièrement aux utilisateurs. La règle qui fait la différence est la contrainte de longueur : la vision doit tenir en une phrase avant la fin de la séance, quitte à être imparfaite. Effet secondaire utile — les désaccords sur le cap, souvent latents, apparaissent enfin. Et si la discussion s’enlise sur le périmètre de la première version, c’est la définition du MVP qu’il faut traiter, pas la vision.

En vidéo : à quoi sert la vision produit et comment la construire (chaîne Scrum Life).

Exemples de vision produit et contre-exemples

Un avertissement s’impose. Les « visions produit » d’entreprises célèbres qui circulent dans les articles francophones sont presque toujours des missions ou des accroches marketing récupérées sur une page institutionnelle, pas la vision réellement utilisée en interne pour arbitrer. Les formulations ci-dessous sont donc volontairement hypothétiques : elles n’appartiennent à aucune entreprise et servent à montrer la mécanique.

• Hypothèse, outil de gestion de stock pour commerces indépendants — « Dans trois ans, un commerçant indépendant sait ce qu’il doit commander cette semaine sans avoir ouvert un carton, en dix minutes le lundi matin. » Un utilisateur nommé, un résultat observable, un horizon.
• Hypothèse, plateforme de facturation pour indépendants — « Faire de la relance d’impayés une tâche que nos utilisateurs n’ont plus jamais à décider d’accomplir. » La promesse porte sur la disparition d’une charge, pas sur une fonctionnalité.
• Hypothèse, application de mobilité régionale — « Permettre à un habitant d’une commune sans gare d’atteindre son travail sans voiture personnelle, en un seul trajet réservé. » Le refus est intégré : tout ce qui sert d’abord les centres-villes bien desservis sort du cap.

Les contre-exemples sont plus instructifs encore, parce qu’ils ressemblent à des visions et se glissent partout :

• « Devenir la plateforme de référence de la gestion de stock. » → un objectif de position, aucun futur utilisateur décrit, aucune demande refusable.
• « Livrer les modules facturation, relance et export comptable d’ici fin 2027. » → une roadmap, avec des dates et des noms de modules.
• « Devenir le leader européen tout en restant l’outil le plus simple du marché. » → deux caps qui s’opposeront tôt ou tard, donc aucun critère d’arbitrage.

S’il ne fallait retenir qu’une chose : une vision produit ne se juge pas à la relecture, mais à la première réunion où quelqu’un demande quelque chose de raisonnable et où elle permet de répondre non, calmement, en une phrase. Le reste n’est qu’un moyen d’y arriver.

FAQ — Tout savoir sur la vision produit

C’est quoi la vision produit ?

La vision produit est la description du futur que l’on cherche à créer pour les utilisateurs d’un produit, généralement à deux à cinq ans. Elle énonce un résultat souhaité, pas une liste de fonctionnalités, et sert de critère pour arbitrer les demandes reçues par l’équipe.

Quelle est la différence entre vision produit et roadmap ?

La vision décrit le futur visé, sans dates ni livrables : elle répond au « vers quoi ». La roadmap planifie ce qui sera livré et quand, sur un à trois trimestres : elle répond au « quoi » et au « quand ». Une vision contenant des dates est une roadmap déguisée.

Quelle est la différence entre vision produit et mission ?

La mission énonce la raison d’être de l’entreprise, sans terme fixé et souvent pour plusieurs produits à la fois. La vision produit concerne un seul produit et un horizon donné. Utiliser la mission comme vision revient à n’avoir aucun critère pour arbitrer sur ce produit.

Existe-t-il un template de vision produit ?

Deux gabarits dominent. L’elevator pitch est une phrase à trous qui force à nommer l’utilisateur, le besoin, la catégorie, le bénéfice et la différence. Le product vision board de Roman Pichler est un canevas d’une page en quatre colonnes : groupe cible, besoins, fonctionnalités clés, objectifs business.

La vision produit fait-elle partie de Scrum ?

Non. Le Guide Scrum 2020 n’emploie pas le terme : il définit un Product Goal, l’objectif de moyen terme attaché au product backlog. La vision produit lui est antérieure et supérieure en horizon ; elle relève du product management, pas du framework Scrum.

Comment savoir si ma vision produit est bonne ?

Appliquez le test du non : listez trois demandes plausibles et défendables, puis vérifiez que la vision permet d’en refuser au moins une sans invoquer d’autorité. Si elle n’écarte rien, ou si elle s’applique telle quelle au produit d’un concurrent, elle est trop large.