Responsabilités du Product Builder

Un Product Builder relie plusieurs étapes qui sont souvent réparties entre le métier, le produit, le design et la construction. Sa responsabilité commune consiste à conserver le fil entre un problème observé, les choix effectués, la réponse construite et ses effets réels. Les référentiels publics et les descriptions d’employeur consultés montrent toutefois des périmètres différents : certains postes couvrent toute cette boucle, tandis que d’autres se concentrent sur une partie ou s’appuient sur des spécialistes. [S1] [S2]

Porter une responsabilité ne signifie donc pas tout exécuter seul. Selon le contexte, le Product Builder peut réaliser une activité, la coordonner, demander une revue ou transmettre le travail. Les preuves et points de contrôle ci-dessous sont des repères possibles. Leur profondeur augmente avec les données concernées, le nombre d’utilisateurs, la difficulté de reprise et les conséquences d’une erreur.

Comprendre le problème et le métier

Le travail commence par une situation réelle, pas par une fonctionnalité déjà choisie. Le Product Builder observe le processus, échange avec les personnes concernées et distingue le symptôme, la cause, les contraintes et la solution demandée. [S1]

• Activités possibles : étudier un cas récent, reconstruire un processus, recueillir les besoins des parties prenantes et examiner les données ou retours disponibles.
• Preuves utiles : un exemple réel, les acteurs et passages de relais, les irritants observés, les règles métier et les risques connus.
• Point de contrôle : le problème est formulé avec des faits observables et ne repose pas seulement sur une préférence d’outil ou une demande de fonctionnalité.

Cadrer et arbitrer

Le cadrage transforme le problème en décision à prendre. Il précise le résultat attendu, le périmètre, les non-objectifs, les hypothèses à vérifier et les contraintes qui peuvent rendre une solution inadaptée. Le Product Builder peut aussi recommander de conserver l’existant, d’acheter ou d’assembler une solution plutôt que de construire. [S1]

• Activités possibles : hiérarchiser les besoins, comparer les options, borner une première version et identifier les dépendances ou responsabilités.
• Preuves utiles : une note de cadrage, une hypothèse prioritaire, des critères d’arrêt et un arbitrage explicite entre les options.
• Point de contrôle : la construction prévue répond à une incertitude ou à un résultat identifiable, avec un effort proportionné à l’enjeu.

Concevoir la solution

La conception relie l’expérience attendue au fonctionnement du système. Elle peut couvrir les parcours, les états d’interface, les règles métier, les données, les droits, les flux et les dépendances. Le niveau de détail dépend de ce qui doit être testé ou transmis. [S1]

• Activités possibles : décrire les parcours, modéliser les données, définir les rôles et permissions, puis représenter les flux ou les interfaces utiles.
• Preuves utiles : une maquette, un modèle de données, des règles métier explicites, une description des accès ou une architecture fonctionnelle.
• Point de contrôle : les parcours, les données et les contraintes techniques restent cohérents, et les limites de la solution sont visibles avant la construction.

Construire à un niveau proportionné

Le Product Builder construit juste assez pour répondre à la question du moment. Une maquette peut suffire pour vérifier la compréhension d’un parcours. Un flux connecté ou une application déployée demande davantage de contrôles, de documentation et de responsabilités. [S1]

• Activités possibles : configurer, intégrer, automatiser ou développer une version qui représente les comportements à vérifier.
• Preuves utiles : un prototype manipulable, un workflow, une application, une fonctionnalité ou un historique des décisions et limites connues.
• Point de contrôle : l’état réel de l’artefact est nommé et son niveau de qualité correspond à l’usage annoncé, sans présenter une démonstration comme un produit prêt à durer.

Tester et évaluer

Les tests vérifient plus que le scénario attendu. Selon le produit, ils examinent aussi les erreurs, les droits, les données, les intégrations, la sécurité, l’accessibilité et la reprise. Le cadre NIST rappelle que les pratiques de sécurité doivent être intégrées au cycle de développement. Pour l’accessibilité web, le W3C précise que les outils automatiques assistent l’évaluation sans remplacer le jugement humain. [S1] [S3] [S5]

• Activités possibles : préparer des cas représentatifs, exécuter les scénarios normaux et dégradés, recueillir des retours d’utilisateurs et faire relire les risques spécialisés.
• Preuves utiles : un plan de test, des résultats conservés, une recette, des observations d’usage et les décisions prises après les écarts constatés.
• Point de contrôle : les preuves portent sur les conditions réelles prévues et permettent de corriger, limiter, faire revoir ou arrêter la solution.

Livrer, faire adopter et exploiter

Mettre une solution à disposition ne suffit pas à créer un usage durable. La livraison peut inclure les accès, la migration, un retour arrière, la documentation, la formation et l’accompagnement. L’exploitation, aussi appelée run, désigne ensuite le support et le suivi nécessaires pendant que la solution est utilisée. [S1]

Le niveau de support dépend de l’importance du produit. Microsoft distingue par exemple l’auto-support, le support partagé par une équipe et le support formalisé pour les solutions Power Platform. Cette gradation est propre à cet environnement, mais elle illustre un contrôle plus général : une solution qui gagne en portée doit avoir un propriétaire, une voie d’escalade et un dispositif de support adaptés. [S4]

• Activités possibles : préparer le déploiement et la reprise, accompagner les utilisateurs, suivre les incidents et l’usage, puis corriger, transmettre ou retirer la solution.
• Preuves utiles : une procédure de déploiement, un propriétaire identifié, des supports accessibles, un canal de support et une décision documentée de maintien ou d’arrêt.
• Point de contrôle : l’adoption, la maintenance et la fin de vie ne reposent pas implicitement sur une seule personne.

Pour une exploration jetable, cette phase peut se limiter à conserver l’apprentissage et à supprimer proprement l’artefact. Pour un produit en service, elle exige des responsabilités explicites de support, de supervision et de reprise.

Comment reconnaître une responsabilité bien tenue ?

Le nombre de fonctionnalités, de prototypes ou d’automatisations livrés ne suffit pas à juger le travail. Les critères utiles relient la construction à une décision, à un usage et à la capacité de maintenir ou d’arrêter la solution. Le référentiel Uncode diffusé par France Compétences associe lui aussi le cadrage à des résultats attendus, les tests à des arbitrages, l’adoption à l’autonomie des utilisateurs et le pilotage à une charge soutenable. [S1]

Dimension	Question utile	Exemples de preuves sans objectif chiffré imposé
Apprentissage et décision	Une incertitude importante a-t-elle été réduite ?	Résultat d’un test, hypothèse confirmée ou invalidée, décision de poursuivre, modifier ou arrêter
Usage et valeur	Les personnes concernées utilisent-elles la solution pour le résultat visé ?	Observation d’une tâche, retours d’usage, adoption, contournements ou résultat métier constaté
Qualité et exploitation	La solution fonctionne-t-elle dans ses conditions prévues et peut-elle être reprise après un échec ?	Résultats de tests, incidents, capacité de retour arrière, coûts récurrents et limites connues
Soutenabilité	Le produit et la charge de support peuvent-ils être transmis ou partagés ?	Propriétaire, documentation à jour, voie d’escalade, passation et temps de support rendu visible

Ces dimensions ne fixent aucune cible universelle. Une équipe choisit les indicateurs qui correspondent au produit, à son stade et à son rayon d’impact. Elle évite ainsi de remplacer un résultat attendu par un volume de production.

Où s’arrête la description du métier ?

Cette fiche décrit ce qui peut devoir être couvert et les preuves qui aident à en juger. Elle ne prescrit ni l’ordre exact des activités, ni les modèles de documents, ni la cadence, ni les outils à employer.

La fiche liée sur les livrables du Product Builder détaille les artefacts qui peuvent matérialiser chaque preuve. La future méthode Product Builder de bout en bout présentera une méthode personnelle avec son contexte, sa version et ses limites. Un futur standard de livraison et de maintenance transformera certains contrôles de fin de cycle en procédure vérifiable. Ces deux procédures restent en prose tant que leurs fiches canoniques n’existent pas.

Sources et limites

Le référentiel Uncode diffusé par France Compétences décrit un Product Builder no-code et fournit la couverture la plus complète des activités présentées ici. Il ne définit pas tous les Product Builders. PayFit documente un rôle interne construit autour d’une plateforme low-code et confirme la diversité du périmètre, sans constituer une norme professionnelle. [S1] [S2]

Les sources NIST, Microsoft et W3C complètent les points de contrôle sur la sécurité du développement, le support et l’accessibilité web. Elles ne définissent pas le métier de Product Builder. Cette fiche en fait une synthèse prudente et laisse à chaque organisation la répartition réelle des responsabilités. [S3] [S4] [S5]