ADR : faire de Build en code le passage à l'échelle du pilote Uimmo¶
Contexte¶
Le projet Build en code avec Uimmo (P-BRI-519) avait été écrit avant le recadrage d'Uimmo. Il reprenait le même brief, le même objectif (4 écrans conformes sur 5) et la même mesure avec un PM que le pilote du projet Uimmo AI+Human Ready (P-BRI-518). Il décrivait encore un binôme design + Front partant de Figma, alors que le modèle visé est un PM qui build avec le Front, le PD en QA design [source locale non partagée].
Déclencheur : la répartition des issues de P-BRI-518 a fait apparaître le doublon [source locale non partagée].
Options envisagées¶
Option A : garder Build en code comme second pilote¶
- Description : conserver le périmètre initial (brief, cible 4/5, mesure avec un PM).
- Avantages : aucun changement de découpage.
- Inconvénients : doublon avec le milestone Pilote de P-BRI-518 ; deux projets mesurent la même chose [source locale non partagée].
- Coût estimé : [non sourcé].
Option B : en faire le passage à l'échelle après le go du pilote¶
- Description : le pilote prouve que la méthode marche sur un parcours ; Build en code en fait une routine : les PM buildent en code, avec l'agent, de vrais flows de la roadmap jusqu'en prod — P-BRI-519.
- Avantages : pas de doublon ; le 4/5, l'avant/après et les hypothèses restent côté pilote (BRI-2532, BRI-2572) — P-BRI-519 § Hors de ce projet.
- Inconvénients : démarrage conditionné au go du pilote et à sa mise en prod (BRI-2571).
- Coût estimé : [non sourcé].
Décision¶
Option retenue : B — validée en séance le 2026-10-16 [source locale non partagée] et écrite dans P-BRI-519. Statut proposed : projet en Backlog, sans date.
Découpage (1 milestone « Builder en routine et décider »)¶
- Choisir 2 ou 3 flows réels de la roadmap — BRI-2573
- Mettre en place le garde-fou AMF — BRI-2575
- Builder les flows jusqu'en prod (binôme PM + Front, PD en QA design) — BRI-2541
- Faire évoluer Uimmo à la source à partir des retouches et des demandes des PM — BRI-2544
- Écrire la recette PM — BRI-2574
- Faire le bilan et décider l'extension aux autres squads — BRI-2545
Garde-fous¶
- Pas de prod sans revue : aucune PR ne part sans relecture du Front et QA design du PD ; la mise en production reste sous contrôle du Front — P-BRI-519 § Garde-fous.
- AMF : une revue humaine conformité reste obligatoire tant que les règles et le contrôle automatique ne sont pas implémentés, testés et formellement validés — BRI-2575.
- Non-régression : chaque flow passe la non-régression de BRI-2570.
- Pas de composant créé dans l'écran : le PM demande sous la forme qu'il veut (PR, piste Figma, message) ; le designer valide, puis le Front pour la partie code — P-BRI-519 § Garde-fous.
- Critère d'arrêt : si les retouches ne baissent pas d'un flow à l'autre, ou si la charge de relecture augmente, pause et revue — BRI-2545.
Écartés en séance¶
- Budget de temps Front / PD par sprint [source locale non partagée].
- Issue de suivi de la charge Front : absente de Linear
[à vérifier].
Conséquences¶
Positives attendues¶
- Un seul lieu pour prouver la méthode (pilote P-BRI-518), un seul pour l'installer (P-BRI-519) — P-BRI-519.
- Chaque retouche devient une règle Uimmo ou une consigne agent, pas une correction d'écran isolée — BRI-2544.
Négatives acceptées¶
- Aucun démarrage avant le go du pilote et sa mise en prod — BRI-2571.
- Revue humaine conformité maintenue jusqu'à validation formelle du contrôle automatique — BRI-2575.
Reversibilité¶
- Coût d'annulation : bas (découpage Linear modifiable, projet en Backlog).
Plan d'implémentation¶
- [x] Recadrer P-BRI-519 et ses issues dans Linear — fait le 2026-10-16 (P-BRI-519).
- [x] Lead du projet : Pierre (P-BRI-519).
- [ ] Répartir les issues et poser les dates ; issues non assignées au 2026-10-19.
- [ ] Trancher où buildent les PM (Storybook ou autre support pour les prototypes de flow) avec le Front et le Product ; owner et date
[à vérifier]. - Risques / edge cases : support de build des PM non tranché (impacte BRI-2574 et BRI-2541) ; synchro Figma hors prérequis — P-BRI-519 § Démarrage.
Métriques de succès¶
Mesures listées : flows livrés en prod, retouches par écran, temps entre le brief et la prod, autonomie du PM ; grille issue de BRI-2568 — P-BRI-519 § Ce qu'on mesure. [outcome non formulé] : pas de cible chiffrée ni de fenêtre.
Vérification post-implémentation¶
Bilan dans BRI-2545 ; date de follow-up [à vérifier].
Review design¶
- Parcours user impactés :
[parcours non spécifié](flows à choisir dans BRI-2573). - États / edge cases couverts :
[états non listés]. - Critères de QA design : QA design du PD bloquante avant prod ;
[accessibilité non vérifiée]. - Impact DS : évolutions d'Uimmo à la source via demandes des PM, validées par le designer puis le Front (BRI-2544).
Sources¶
- P-BRI-519 Build en code avec Uimmo (lu le 2026-10-19)
- P-BRI-518 Uimmo AI+Human Ready
- Issues : BRI-2573 · BRI-2575 · BRI-2541 · BRI-2544 · BRI-2574 · BRI-2545 · BRI-2570 · BRI-2571 · BRI-2568
- ADR 2026-10-15 Uimmo structure et découpage
Révisions¶
- 2026-10-19 : créée (status: proposed)