Aller au contenu

ADR : Cadre opérationnel AI Coding & Vibe Coding chez Bricks (V1)

Statut : proposed. Draft Denis partagé le 21 mai 2026 matin, synchro d'adoption tenue le 21 mai 2026 après-midi (Romain + Denis + Vincent + Alban, 70 min — voir meeting). Le cadre structurel est validé sur le fond. Passage en accepted après réception de la liste de next steps écrite promise par Denis en clôture, qui doit consolider : 1. Reclassifications restantes (App d'analyse projet immo, Notation projets, Gamification, workflow agents IA / Manus) 2. Désignation nominale Tech Buddies par projet 3. Critère opposable « pleine conscience » sur vibe coding N3 4. Scope + deadline mise en conformité gestion projets par Alban 5. Confirmation reprise gestion défauts par Thomas (juin) 6. Critères opposables checklist §9 mémo (commentaire 1 Romain)

Contexte

L'ADR 2026-04-30 grille de criticité a posé un cadre abstrait Bas / Moyen / Haut qui n'a jamais été instancié de façon opérationnelle. La grille concrète était à construire (sprint Romain + Denis) mais n'a pas abouti à un document partagé entre la décision (30/04) et aujourd'hui (21/05).

Pourquoi maintenant — le déclencheur

  • Recrutement Product Builder imminent : Romain s'apprête à recruter un PM Squad Investisseur (cadrage TPC 11/05, weekly TPC 19/05 — 8 candidats shortlistés). D'autres recrutements Product Builder vont suivre.
  • Mode actuel non scalable : tant que Romain et Alban étaient les deux seuls à vibe-coder en solo, Denis a accepté ce mode sans cadre formel. Multiplier ce mode par 2 ou 3 sans cadre = niveau de dette technique et risque produit/légal non absorbable.
  • Cadre réglementaire : Bricks opère sous PSFP (ECSP 2020/1503), DORA depuis janvier 2025, MiFID II en préparation. La criticité, la classification des projets et la frontière du Product Builder ne sont pas des préférences techniques — ce sont des transpositions opérationnelles d'obligations réglementaires et fiduciaires.
  • Industrie : Faros AI 2026 documente le pattern Acceleration Whiplash — vélocité de surface +33,7 %, mais incidents/PR plus que triplés, code-churn +861 %. Le code IA superficiellement convaincant contient des défauts structurels subtils. L'enjeu n'est pas la production, c'est le discernement comme système organisationnel.

Position Karpathy (AI Ascent 2026)

Karpathy, qui a coiné le terme vibe coding en février 2025, clarifie sa position : vibe coding et engineering ne sont pas deux points sur un continuum, ce sont deux modes distincts. Le vibe coding raises the floor (démocratise le proto). L'agentic engineering raises the ceiling (discipline professionnelle, correctness/security/taste/maintainability). Conséquence : la version « solo jusqu'à ce que ça scale, puis Tech reprend » tombe entre les deux modes et produit le pire scénario — la Tech hérite d'un système à réécrire.

Options envisagées

Option A : Process tech uniforme pour tout ce qui va en prod

  • Avantages : sécurité maximale, cohérence.
  • Inconvénients : tue la vélocité produit, charge tech insoutenable, ne reflète pas la réalité des trade-offs (refonte Retool faite en 1 semaine sans revue ligne par ligne).
  • Coût : élevé en vélocité.

Option B : Pas de cadre formel (statu quo)

  • Avantages : vélocité actuelle préservée pour Romain et Alban.
  • Inconvénients : non scalable. Avec les recrutements Product Builder à venir, multiplier le mode solo crée une dette ingérable.

Option C : Cadre opérationnel à 3 niveaux N1/N2/N3 + frontière Karpathy + standards mutualisés

  • Description : matrice de criticité N1/N2/N3 définie au démarrage de chaque projet par discussion CTO + CPO + CEO, avec règles différenciées (Vibe libre / Tech Buddy / Peer Review) et frontière de sortie du Product Builder au POC validé. Standards techniques mutualisés progressivement (bricks-standards, conventions partagées, Cursor rules, CI commune).
  • Avantages : aligne charge tech avec risque réel ; conserve la vélocité où possible ; capture les sujets critiques ; absorbe les futurs recrutements ; pose le cadre avant les recrutements, pas après.
  • Inconvénients : nécessite discipline (classification au démarrage, signalement des évolutions de scope qui changent le niveau) ; risque de « déjouer la grille » en sous-estimant la criticité ; charge initiale pour mutualiser les standards.

Décision

Option retenue (proposée) : C — Cadre opérationnel N1/N2/N3 + frontière Karpathy + standards mutualisés.

Définitions et règles formalisées dans le concept dédié ai-coding-vibe-coding. Mémo source de référence : inbox/manual/2026-05-21-memo-denis-ai-coding-vibe-coding.md.

Cette ADR supersede la version V0 abstraite Bas/Moyen/Haut de ADR 2026-04-30 grille de criticité, une fois passée en accepted.

Arbitrages en synchro 2026-05-21

Synchro tenue le 21 mai après-midi (70 min, présents : Denis, Romain, Vincent, Alban). Détail dans la fiche meeting. Résumé des arbitrages ci-dessous.

Arbitrages structurels actés

  1. Critère de classification = scope d'impact, pas état du projet. Posé par Vincent : « probabilité de bug × scope d'impact × irréversibilité ». Conséquence : la frontière Karpathy « PB s'arrête au POC » est implicitement remplacée par « PB peut faire N1 et N2, pas N3 ». Voir §Frontière Profil B Bricks ci-dessous.

  2. Standards mutualisés à TOUS les niveaux, y compris N1. Position défendue par Romain (commentaire 2 et 3 du draft), confirmée par Vincent et Denis. Repo / dossier bricks-standards à co-construire en Tech Days. Coût marginal très faible parce que les conventions sont respectées par les agents IA directement. Point lié au commentaire 3 (bascule N1 → N2 sans refonte) — résolu par cette décision.

  3. Frontière Profil B Bricks ≠ frontière Product Builder Karpathy.

  4. Profil B Bricks = vibe-codeur produit-first, peut shipper N1 et N2 (avec Tech Buddy nominal sur N2).
  5. Frontière Karpathy « stop POC » = applicable au profil Karpathy générique, pas au Profil B Bricks tel que recruté.
  6. Cohérence restaurée avec la V1 du Profil B du 5 mai (« le PB shippe lui-même les V1 fonctionnelles »).

  7. Cas concret validé : un wrapper Manus pour un PB freelance reste fine en mode vibe code par PB.

  8. Tech Buddy — pool élargi, allocation par projet, format 1h synchrone. Réponse au commentaire 9 du draft :

  9. Pool : Denis, Vincent Duong, Vincent Besnier, William, possiblement Hugo, Thomas (juin). Pas restreint à Vince + Denis.
  10. Si compétence manquante : le tech buddy appelle un collègue (ex : front sur sujet back).
  11. Allocation : 1 Tech Buddy nominal par projet, pas une rotation hebdo (la prise de contexte hebdo serait trop coûteuse).
  12. Format : 1h synchrone focus, pas async. Le pattern « SOS Captain Cursor » de l'an dernier n'avait pas marché à cause du format async.

  13. Pré-requis pour démarrer : conformité minimale du repo amorcée par le porteur, pas conformité parfaite. « On commence le truc, on commence à parler. »

  14. Vibe coding sur N3 = exception assumée, pas la norme. Denis : « si on fait le choix de vibe coder sur du N3, on le fait en conscience. » Garde-fou à expliciter dans les next steps Denis : critère opposable de « pleine conscience » non posé en séance — sinon porte de sortie sans cliquet.

  15. Plus de N3 lancé en solo par PB. Tout nouveau projet potentiellement N3 = initié produit + tech ensemble. Les sujets N3 actuellement portés en build solo (gestion projets / défauts par Alban, outil d'analyse modalités/contrats par Romain) sont des reliques du passé, prioritaires pour passation. Plan évoqué : Thomas reprend gestion défauts en juin (à confirmer Denis). Alban prend l'engagement de mise en conformité de gestion projets dans les prochaines semaines.

  16. Cursor automation risk assessment déjà active depuis ce week-end (action solo Denis) sur les PR du monorepo : low → auto-approve, sinon review obligatoire. Extension proposée par Vincent : automation au niveau Linear (à l'ouverture d'issue, avant code). Lien direct avec la proposition Romain (commentaire 4 du draft, agent évaluateur de criticité) — convergence.

  17. Workflow 2.0 Linear → code = co-construction Tech Day. Position Romain (1 itération = 1 Linear, étapes définies, qualité homogène) acceptée en exploration mais pas validée comme décision tech top-down. Denis : « il faut qu'on s'intègre là-dedans, sinon on fait un workflow qui ne vous convient pas et ça n'a aucun sens. » Format : sessions dédiées 2h pendant les Tech Days.

Arbitrages classifications spécifiques

Sujet Verdict synchro Statut
CRM Alban (commentaire 6) N2 sur l'aspect tech, îlot N3 sur la sécurité confidentialité documents (cloisonnement entre porteurs). Le risque qualité réponse est porté par l'humain (account manager). Tranché
Standards à tous niveaux (commentaires 2-3) Tranché — voir arbitrage structurel n°2. Tranché
Tech Buddy opérationnel (commentaire 9) Tranché — voir arbitrage structurel n°4. Tranché
Review IA récurrente repos (commentaire 4) Convergence avec la cursor automation Denis déjà active. À étendre à Linear (proposition Vincent). Trajectoire posée
Workflow d'analyse IA / agents Manus (commentaire 5) Logique posée (N1 maintenant, bascule N2 le jour où agent Bricks internalisé). Niveau formel à acter. Logique acceptée, formalisation pendante
Critère §9 checklist N2 (commentaire 1) Non discuté en séance. Ouvert
App d'analyse projet immobilier (commentaire 7) Non discuté en séance. Reste N3 dans le draft, contesté Romain. Ouvert
Notation projets / îlots N3 (commentaire 7) Non discuté en séance. Reste N2 + îlots N3 dans le draft. Ouvert
Gamification investisseurs (commentaire 8) Non discuté en séance. Reste N2 (N3 si automatisation cash). Ouvert

Sujet émergent en synchro (hors mémo et hors commentaires Romain)

  1. Python pour les agents IA — pas de tech buddy back direct. Sujet du projet d'automatisation analyse (techno Python). Aucun Tech Buddy back ne maîtrise Python en interne. Pistes évoquées : (a) Bug Bot Python suffit pour démarrer, (b) consultation d'un expert externe ponctuel, (c) Denis ou Vincent prennent quelques heures pour creuser les bonnes pratiques Python. Sujet ouvert, pas tranché.

Conséquences

Positives attendues

  • Vélocité préservée sur N1 (vibe full IA, autonomie complète).
  • Sujets critiques (paiements, échéancier, votes, contrats, calcul pénalités, données PII) sécurisés en N3.
  • Cadre clair pour les recrutements Product Builder : pairing dès l'onboarding avec un Tech Buddy nominalement désigné.
  • Mutualisation progressive des standards = autorise plus de vélocité en aval.
  • Frontière Karpathy explicite = évite le scénario « solo jusqu'à scale puis réécriture par Tech ».

Négatives acceptées

  • Discipline supplémentaire (discussion CTO/CPO/CEO au démarrage, signalement des évolutions de scope).
  • Bandwidth Tech Buddy (Vincent / Denis) à dimensionner — risque de goulot si point 9 non tranché.
  • Le Profil B Product Builder (recherché par Romain) voit sa frontière de sortie resserrée par rapport à l'évolution V1 du 5 mai — à articuler proprement avec ADR 2026-04-30 rôles product builder et Product Builder Career Path V1.
  • Plusieurs projets actuels classés N2/N3 ont été construits hors process : plan de mise en conformité (transition Développeur, ajout standards, refactor partiel) — pas de rétro-blocage des projets eux-mêmes.

Reversibilité

  • Coût d'annulation : moyen. Le cadre lui-même est réversible (retour à statu quo possible). Mais une fois les recrutements Product Builder lancés sous ce cadre, revenir en arrière implique des renégociations RH.

Plan d'implémentation

  • [x] Draft Denis partagé le 21 mai 2026 (source)
  • [x] Lecture async + commentaires Romain (consolidés ci-dessus, points 1-9)
  • [x] Synchro d'adoption tenue le 21 mai après-midi (70 min, Denis + Romain + Vincent + Alban) — voir meeting
  • [x] Cursor automation risk assessment PR activée par Denis (week-end 17-18/05, monorepo)
  • [ ] Liste des next steps écrits par Denis (promise en clôture). À recevoir.
  • [ ] Reclassifications restantes (App analyse projet immo, Notation projets, Gamification, workflow agents IA / Manus, critère §9 checklist) — async ou Tech Day dédié.
  • [ ] Désignation nominale Tech Buddies par projet (en cours + à venir).
  • [ ] Critère opposable « pleine conscience » sur vibe coding N3.
  • [ ] Mise en conformité gestion projets par Alban — scope + deadline à formaliser.
  • [ ] Confirmation reprise gestion défauts par Thomas (juin, à confirmer par Denis).
  • [ ] Initialisation bricks-standards : repo / dossier, conventions code, Cursor rules partagées, scaffold projet par catégorie (back-office / tools internes / front). Sujet Tech Days.
  • [ ] Workflow 2.0 : co-construction Tech Day, sessions dédiées 2h.
  • [ ] Cursor automation Linear (extension proposée par Vincent) — risk assessment à l'ouverture d'issue.
  • [ ] Sujet Python agents IA : trancher entre Bug Bot suffisant / expert externe ponctuel / interne creuse les bonnes pratiques.
  • [ ] Aligner les fiches de poste Product Builder sur la matrice : Profil B Bricks peut faire N1 et N2 (avec Tech Buddy nominal), pas N3.
  • [ ] Une fois next steps Denis reçus : passage status: accepted + supersession explicite de ADR 2026-04-30 grille de criticité.

Métriques de succès

  • Cadre adopté avant le démarrage des prochaines missions Product Builder.
  • Aucun incident critique sur des features classées N1 (sinon = mauvaise classification).
  • Tous les contributeurs build (Romain, Alban, futurs recrutements) connaissent et appliquent la matrice.
  • Bandwidth Tech Buddy (Vincent / Denis) reste acceptable à 3 mois (subjectif, à mesurer en synchro Denis/Vincent).
  • Au moins un projet vibécodé reprenable par la Tech sans réécriture intégrale (validation indirecte de l'efficacité des standards mutualisés).

Sources

Révisions

  • 2026-05-21 matin : créée en status: proposed après partage du draft Denis et lecture async + commentaires Romain.
  • 2026-05-21 PM : synchro d'adoption tenue (Denis + Romain + Vincent + Alban). Cadre structurel validé sur le fond, 8 arbitrages structurels actés, 5 reclassifications restées ouvertes. Maintien proposed en attendant les next steps écrits Denis.