Livrables du Product Builder

Un livrable utile matérialise une question, une décision ou une condition de reprise. Il peut s’agir d’un exemple réel, d’une maquette, d’un prototype, d’un résultat de test ou d’une procédure de support. Le Product Builder choisit le format le plus léger qui rend la preuve compréhensible et vérifiable par les personnes concernées.

Cette référence ne constitue pas une liste de documents obligatoires. Le référentiel Product Builder no-code diffusé par France Compétences associe lui-même les artefacts attendus à des critères observables : conformité des parcours, résultats de tests, arbitrages, plan de déploiement, autonomie des utilisateurs ou suivi de la solution. [S1]

Choisir un livrable pour décider, construire ou transmettre

Avant de produire un artefact, trois questions permettent d’en préciser l’utilité :

1. Quelle décision doit-il éclairer ? Par exemple, poursuivre une hypothèse, choisir une architecture ou autoriser une mise à disposition.
2. Quelle preuve doit-il rendre visible ? Par exemple, un irritant observé, un parcours compris, une intégration faisable ou un scénario testé.
3. Qui doit pouvoir agir après sa lecture ? Par exemple, une personne qui arbitre, construit, utilise, contrôle ou maintient la solution.

Un même artefact peut répondre à plusieurs usages. Une cartographie de processus aide à cadrer le problème, puis sert de repère pendant la conception. Un prototype facilite une recherche utilisateur, mais il ne devient pas pour autant une preuve de sécurité ou de tenue en charge. Le GOV.UK Service Manual recommande justement de choisir le type de prototype adapté au besoin du moment et rappelle que le code d’un prototype ne respecte pas nécessairement les exigences de la production. [S2]

Preuves de compréhension et de cadrage

À ce stade, le livrable doit montrer que l’équipe comprend la situation avant de choisir une solution.

Décision à éclairer	Artefacts possibles	Preuve attendue
Le problème mérite-t-il d’être traité ?	Exemple réel, observation, récit du dernier cas traité	Les personnes, les effets et les difficultés sont identifiables dans une situation concrète
Où se trouve la difficulté ?	Cartographie du processus actuel, acteurs et passages de relais	Le fonctionnement réel, ses exceptions et ses contraintes sont visibles
Que faut-il vérifier en premier ?	Note de problème, hypothèse prioritaire, critère de réussite	L’incertitude principale et le résultat qui permettra d’arbitrer sont explicites
Quel périmètre engager ?	Non-objectifs, conditions d’arrêt, analyse acheter-assembler-construire	Les limites, dépendances et options écartées sont assumées

La preuve n’est pas la présence d’un modèle rempli. Elle apparaît quand une personne peut confronter le contenu à un cas réel, contester une hypothèse ou prendre une décision sans reconstruire tout le contexte.

Preuves de conception

Les artefacts de conception relient l’expérience attendue au fonctionnement de la solution. Un parcours ou une maquette aide à discuter des étapes, des informations et des états d’interface. Un modèle de données rend visibles les objets, leurs relations et les règles de cohérence. Un schéma fonctionnel montre les systèmes traversés, les flux et les responsabilités.

Le format dépend de la question. Une représentation simple suffit pour discuter d’un enchaînement. Une intégration qui manipule des données sensibles demande aussi de préciser les accès, les transformations et les limites. Le référentiel France Compétences relie ainsi parcours, modèles de données, flux, droits et contraintes réglementaires à des critères de conformité vérifiables. [S1]

Une conception utile permet notamment de décider :

• si les parcours couvrent le cas nominal et les exceptions importantes ;
• si les règles métier et le modèle de données restent cohérents ;
• si les droits et les flux exposent un risque à faire relire ;
• si la solution peut être construite ou si une incertitude exige d’abord une expérience.

Artefacts de construction

L’artefact construit doit correspondre à l’incertitude traitée. Une automatisation isolée peut vérifier un mécanisme. Un prototype interactif peut mettre un parcours devant des utilisateurs. Une première version en usage peut confronter une proposition de valeur au terrain.

Pour conserver la preuve, il faut décrire les conditions de l’essai : version utilisée, données représentatives, scénario observé, environnement, résultat et limite connue. Une démonstration réussie dans un cadre contrôlé ne prouve pas le comportement avec tous les volumes, toutes les erreurs ou tous les utilisateurs.

Le NIST présente son cadre de développement sécurisé comme une approche fondée sur les risques, à adapter au contexte et non comme une checklist. Il distingue notamment la préparation de l’organisation, la protection des composants, la production de versions sécurisées et la réponse aux vulnérabilités résiduelles. Un artefact destiné à être livré demande donc des preuves plus larges qu’une construction exploratoire. [S4]

Preuves de test, de livraison, d’adoption et de run

Le run désigne la période pendant laquelle la solution est utilisée, suivie et maintenue. Les preuves utiles évoluent à mesure que l’artefact s’approche de cet usage réel.

Moment	Artefacts possibles	Décision ou preuve soutenue
Test	Cas de test, jeu d’évaluation, résultats conservés, anomalies et arbitrages	La solution répond aux scénarios visés et ses écarts connus sont acceptés, corrigés ou bloquants
Livraison	Recette, plan de déploiement, stratégie de retour arrière, sauvegarde et reprise	La mise à disposition peut être exécutée et interrompue dans des conditions maîtrisées
Adoption	Support utilisateur, formation, observation d’une tâche, retours et contournements	Les personnes concernées comprennent la solution et peuvent obtenir le résultat attendu
Run	Indicateurs d’usage et de qualité, journal d’incidents, propriétaire, canal de support	Le service peut être surveillé, soutenu, amélioré, transmis ou retiré

Pour un service en production, le GOV.UK Service Standard demande des tests réguliers supervisés par l’équipe, un environnement proche du réel, un suivi adapté et un plan soutenable de réponse aux problèmes. Microsoft décrit plusieurs niveaux de support Power Platform, de l’auto-support à une équipe dédiée, et recommande de faire évoluer le dispositif avec la portée et la criticité de la solution. Ces cadres ne s’appliquent pas tels quels à tous les produits, mais ils montrent pourquoi les preuves de production dépassent le simple fonctionnement d’une fonctionnalité. [S5] [S6]

Nommer honnêtement l’état de l’artefact

Les mots varient selon les organisations. Dans cette fiche, ils servent à distinguer la question testée et le niveau de confiance obtenu.

État annoncé	Ce qu’il peut prouver	Ce qu’il ne prouve pas à lui seul
Maquette	La compréhension d’une structure, d’un contenu, d’un parcours ou d’une interface	Le comportement réel du système, la faisabilité technique ou l’usage réel
Prototype	Une interaction, une règle ou une expérience dans un cadre contrôlé	La sécurité, la fiabilité, la performance ou la maintenabilité en production
Preuve de concept	La faisabilité d’une technologie, d’une intégration ou d’un mécanisme	La valeur pour les utilisateurs, l’adoption ou la capacité d’exploitation
MVP	La valeur d’un périmètre minimum auprès d’utilisateurs réels et les apprentissages qui en découlent	La couverture de tous les usages, volumes et contraintes futurs
V1	Le fonctionnement d’une première version livrée sur un périmètre nommé, avec ses tests et limites connus	Une qualité définitive, une maintenance illimitée ou l’absence de dette
Produit en production	Une solution réellement utilisée, avec des responsabilités de déploiement, de surveillance, de support et d’évolution organisées selon son risque	Une pérennité automatique ou l’absence d’incident et d’investissement futur

Le GOV.UK distingue explicitement le prototype du service réel et déconseille de copier son code directement en production. Atlassian distingue la preuve de concept, centrée sur la faisabilité, du MVP, mis devant de vrais utilisateurs pour apprendre sur la demande. Les termes « V1 » et « production » n’imposent quant à eux aucun niveau universel : leur périmètre, leurs contrôles et leurs responsabilités doivent être déclarés. [S2] [S3] [S5] [S6]

Écarter la documentation décorative

Un livrable mérite d’être créé ou conservé s’il satisfait au moins un de ces critères :

• il soutient une décision encore ouverte ou explique un arbitrage déjà pris ;
• il fournit une preuve que quelqu’un peut examiner ou reproduire ;
• il réduit un risque de construction, de déploiement, d’usage ou de maintenance ;
• il permet à une autre personne de poursuivre, contrôler, soutenir ou arrêter le travail ;
• il répond à une obligation réelle du contexte.

À l’inverse, un document peut être supprimé, fusionné ou allégé lorsqu’il répète une autre source, n’a plus de destinataire ou ne change aucune décision. Sa qualité se juge aussi à sa fraîcheur : un support non maintenu peut donner davantage de confiance à tort qu’une limite clairement déclarée.

Les preuves doivent enfin respecter la confidentialité. Un exemple réel peut être anonymisé. Un jeu de test peut utiliser des données synthétiques. Les secrets, accès, identifiants personnels et données sensibles n’ont pas à apparaître dans un dossier partagé. Le niveau de détail conservé doit permettre le contrôle sans élargir inutilement l’exposition des informations. [S1] [S4]

Préparer la recette et la passation

La future fiche consacrée à la recette, à la livraison et à la passation expliquera comment assembler les preuves nécessaires avant un transfert. Elle précisera notamment les responsabilités, les résultats de tests, le déploiement, le retour arrière, les accès, le support, les limites et les décisions encore ouvertes.

Cette future procédure ne sera pas une relation canonique tant que sa fiche n’existe pas. Dès maintenant, un dossier de passation reste utile seulement si l’équipe qui reçoit la solution peut l’utiliser pour agir, et non parce qu’il reproduit mécaniquement tous les livrables du projet.

Sources et limites

Le référentiel Uncode diffusé par France Compétences décrit un contexte no-code et un dispositif de certification. Il fournit des exemples précis d’artefacts et de critères, mais il ne définit ni tous les Product Builders ni une liste universelle de livrables. [S1]

Les guides GOV.UK relèvent des services publics numériques. Atlassian expose une pratique professionnelle du MVP. Le NIST traite du développement sécurisé et Microsoft du support Power Platform. Ces sources éclairent chacune une partie du sujet ; la classification proposée ici est une synthèse destinée à mieux nommer les preuves et les limites dans différents contextes. [S2] [S3] [S4] [S5] [S6]