Produit · prototype
BAO (docAgency)
34 écrans
13 étapes, 10 PRD, du cabinet médical au dossier bancaire.
SYS/PROTO
Le proto est le contrat.
Prototypage : PRD, maquette HTML et proto cliquable en quelques jours
Un prototype cliquable met tout le monde d'accord avant d'écrire une ligne de code. On part d'un PRD par étape, on génère des écrans HTML fidèles, puis on les rend manipulables avec des données réalistes.
Le prototypage fait partie de notre expertise Produits digitaux — prototypage, SaaS et landing pages.
SYS/FOR
Pour qui
Fondateur qui doit montrer avant de lever ou vendre
Une démo cliquable vaut mieux qu'un deck : on rend l'idée tangible pour convaincre un investisseur ou un premier client.
Équipe métier avec un outil interne à cadrer
Avant de mobiliser des devs, on fige les parcours et les écrans pour éviter de construire le mauvais outil.
Agence qui veut un livrable testable
Un prototype documenté à remettre au client ou à passer en production, plutôt qu'une maquette morte.
SYS/SCOPE
Ce que ça couvre
Six livrables. Dépliez une carte pour voir ce qu'elle contient concrètement.
Cadrage et user flows
Le problème, les personas et les parcours, posés avant tout écran.
Ce que ça donne
Un schéma de parcours par persona, la liste des écrans à produire et les cas limites identifiés avant de dessiner. Sur BAO, ce cadrage a donné les 13 étapes du parcours guidé — du cabinet médical au dossier bancaire.
PRD par étape
Une spécification écrite, découpée, auditée — la source de vérité du proto.
Ce que ça donne
Un document par étape : objectif, données affichées, actions possibles, règles métier, états d'erreur. Écrit avec des agents puis audité en cohérence — 10 PRD sur BAO. C'est ce document, pas une capture, qui sert de contrat.
Maquette HTML (Tailwind) fidèle
Des écrans en HTML, responsive, proches du produit final — pas des images.
Ce que ça donne
Des écrans qui s'ouvrent dans un navigateur, se redimensionnent et se partagent par un simple lien. 34 écrans sur BAO. Le HTML est repris par le build : rien n'est redessiné une seconde fois.
Proto cliquable avec données réalistes
Un parcours qu'on manipule vraiment, alimenté par des données crédibles.
Ce que ça donne
Les écrans sont reliés entre eux et remplis de données plausibles, jamais de faux texte de remplissage. On met le parcours entre les mains d'un utilisateur réel et on regarde où il hésite — c'est là que le cadrage se corrige, avant le code.
Décisions UX documentées
Chaque choix d'interface est tracé, pour arbitrer et transmettre.
Ce que ça donne
Pour chaque écran : l'option retenue, celles écartées et pourquoi. Six mois plus tard, personne ne rejoue le même débat, et une nouvelle personne comprend le produit sans réunion.
Passage au build (SaaS)
Le proto devient la base du développement, pas un livrable jetable.
Ce que ça donne
PRD, écrans et décisions partent tels quels vers le développement — modèle de données, API, front. C'est le chemin du levier SaaS sur mesure.
SYS/AI
Ce que l'IA change ici
BAO : 10 PRD rédigés et audités avec des agents, 34 écrans HTML générés depuis les PRD puis corrigés à la main. Les mockups de ce site (quatre architectures A–D en une journée, puis C2) suivent le même protocole.
Avant
La spécification tenait dans un document unique que personne ne relisait en entier, et la maquette était une image : jolie, figée, impossible à manipuler. Chaque écran supplémentaire coûtait une journée de design, donc on en faisait le moins possible — et on découvrait les trous du parcours pendant le développement, au pire moment.
Coût de l'écran
Un écran dessiné à la main, puis re-dessiné à chaque changement d'avis. Le nombre d'écrans devient une contrainte budgétaire, pas un choix produit.
Jetable
La maquette finissait à la poubelle une fois le build lancé : tout était redessiné en code, avec les écarts que cela suppose.
Avec des agents
La spécification est découpée en PRD courts, un par étape, rédigés et audités en cohérence avec des agents. Les écrans HTML sortent de ces PRD en quelques heures, puis sont repris à la main. BAO : 10 PRD, 13 étapes, 34 écrans — un volume qui n'aurait pas tenu dans un budget de maquettage classique.
Spécifier
Les PRD et les audits de cohérence sont écrits avec des agents, relus avant génération.
Générer
Les écrans sortent des PRD en quelques heures, puis sont corrigés à la main pour tenir la barre.
Ce qui reste humain
Un agent produit vite ce qu'on lui décrit ; il ne sait pas si c'est le bon produit. Le problème à résoudre, l'arbitrage entre deux parcours, le passage devant un vrai utilisateur et le refus d'un écran de trop restent des décisions de studio. Les quatre architectures A–D de ce site ont été prototypées en une journée — le choix de C2, lui, a pris une relecture humaine.
Décider
Choisir le parcours, trancher entre deux options d'interface, assumer ce qu'on ne construira pas.
Confronter
Mettre le proto devant des utilisateurs et accepter que le cadrage change. Aucun agent ne fait ce travail à votre place.
SYS/BUILD
Comment on fait
Quatre temps, du cadrage au produit.
- 01Cadrage + PRD — clarifier le problème, les parcours, puis écrire un PRD par étape.
- 02Maquette HTML — des écrans fidèles en HTML et Tailwind, générés puis repris à la main.
- 03Proto cliquable / tests — rendre le parcours manipulable, données réalistes, le confronter à des utilisateurs.
- 04Build — passer le proto validé au développement du SaaS.
SYS/PROOF
Preuves
| Livrable | Quantité |
|---|---|
| Écrans HTML | 34 |
| Étapes du parcours | 13 |
| PRD rédigés | 10 |
Axe : nombre d'éléments livrés. Parcours guidé en 13 étapes, 34 écrans HTML, 10 PRD, export PDF banque.
Preuve vivante
Ce site : 4 mockups A–D → C2 → HI-FI
Quatre architectures prototypées en une journée, départage sur C2, puis ce wireframe haute-fidélité. Le même protocole que pour un produit client.
SYS/TOOLS
Outils
- HTML / Tailwind
- Motion
- GSD
- Cursor
- Claude Code
- Sans Figma
SYS/FAQ
Questions fréquentes
Prototype ou maquette ?
Une maquette (Figma, Sketch, un PDF) est une image : on la regarde. Un prototype, ici, se manipule : écrans HTML cliquables, données réalistes, parcours qu'on peut faire échouer. On teste un produit, pas une capture d'écran.
PlusMoins
C'est volontairement plus proche du build que d'un moodboard. Les décisions UX (où va le bouton, que voit tel rôle, que se passe-t-il si le champ est vide) sont déjà dans le HTML, pas dans un commentaire de fichier.
Si vous avez déjà des maquettes, on peut les partir en proto cliquable. Si vous n'avez qu'un problème métier, on part du PRD et des parcours — c'est le cas BAO : 34 écrans, 10 PRD.
Combien de temps pour un prototype ?
Quelques jours pour un parcours ciblé (un tunnel, un back-office mince). 2 à 3 semaines pour un produit de l'ordre de 30 écrans, comme BAO. Les agents accélèrent la production des écrans ; le cadrage et la relecture des parcours restent le facteur limitant.
PlusMoins
Ce n'est pas « un site vitrine ». Un proto métier a des états vides, des erreurs, des rôles. Le temps va là, pas dans un hero animé.
Un délai plus court est possible si le périmètre est tranché sans pitié. Un délai plus long, si le métier n'a pas encore décidé ce que le produit est. L'appel sert à le voir.
Que devient le prototype ensuite ?
Il sert de base au build, pas de brouillon jetable. PRD, écrans et décisions UX passent au développement du SaaS (ou à une série de landing instrumentées) sans être redessinés une seconde fois « pour de vrai ».
PlusMoins
C'est tout l'intérêt du HTML plutôt que d'une image : le développeur (souvent le même studio, levier SaaS) hérite d'une spec vivante. Moins de « ah, en fait ce flux n'existait pas ».
Si vous faites construire ailleurs, vous partez avec le proto et les PRD. Ils vous appartiennent. Le studio n'enferme pas le cadrage dans un format propriétaire.
Faut-il un designer ?
Pas nécessairement pour cadrer et valider un parcours : le studio conçoit et code directement en HTML. Un designer peut intervenir ensuite sur la direction artistique, l'identité, un design system plus large.
PlusMoins
Ce n'est pas du « webdesign freelance » au sens d'une refonte esthétique. C'est de l'UX produit : rôles, états, clarté. Si vous cherchez uniquement une belle vitrine, le levier n'est pas celui-ci — plutôt les landing pages, ou un studio créa.
Le responsive est natif : on prototype des parcours qui tiennent sur mobile, pas une version desktop à « décliner plus tard ».
Quelles sont les étapes, concrètement ?
Cadrage (problème, utilisateurs, hors-scope) → parcours et PRD → écrans HTML cliquables → recette avec le métier → itérations. Les agents produisent beaucoup d'écrans ; chaque parcours critique est relu avant d'être montré comme « ready ».
PlusMoins
On ne commence pas par choisir une palette. On commence par « qui fait quoi, dans quel ordre, qu'est-ce qui casse ». La couleur vient après, ou avec votre charte.
La recette se fait dans le navigateur, pas dans un appel de slides. C'est le test avant le build.
Comment on teste le prototype avant de construire ?
On le fait jouer : vous, un utilisateur réel, un collègue métier. Les clics morts, les impasses, les libellés opaques apparaissent tout de suite — c'est le but. Mieux vaut casser un HTML en semaine 2 qu'un SaaS en mois 4.
PlusMoins
Ce n'est pas toujours un test utilisateur formel. Parfois un atelier de recette suffit. L'important est de décider sur le proto, pas de le commenter poliment.
Accessibilité de base (titres, focus, contrastes raisonnables) : on la tient dans le HTML. Un audit RGAA complet n'est pas le livrable par défaut ; on peut l'ajouter si c'est un critère métier.
Le prototype est-il responsive ?
Oui : on prototype dans le navigateur, donc le mobile n'est pas une phase 2. Un parcours métier qui ne tient que sur un écran 27 pouces n'est pas validé.
PlusMoins
Ça n'empêche pas des vues spécifiques (un tableau dense reste plus à l'aise en desktop). On le dit, on ne fait pas semblant qu'un back-office complexe soit « parfait au pouce ».
La perf de base (poids des pages, pas d'images décoratives à outrance) est déjà un geste d'éco-conception. Ce n'est pas un label ; c'est du HTML sobre.
Peut-on partir d'un existant (Figma, site, outil) ?
Oui. Figma, un outil interne moche mais utilisé, un site qui « fait déjà un peu produit » : on part de là. Le proto n'exige pas une page blanche. Il exige un problème et quelqu'un qui peut valider.
PlusMoins
Parfois l'existant est le vrai produit, et le proto sert à extraire le parcours propre avant un rebuild. Parfois c'est l'inverse : rien n'existe, on spécifie en écrans.
Apportez ce que vous avez à l'appel. On vous dira si ça accélère ou si ça pollue.
SYS/NEXT
Prochaine étape
Décrivez le produit à cadrer : on identifie le plus court chemin vers un proto testable. Cadrage écrit sous 48 h, sans engagement.
Les autres leviers de Création de produits digitaux