Aller au contenu

AI Coding & Vibe Coding chez Bricks

Définition

Cadre opérationnel qui qualifie comment l'IA peut être utilisée pour produire du code chez Bricks, en fonction du rayon d'explosion d'un échec. Distingue Vibe Coding (orienté résultat) et AI-Assisted Coding (orienté ingénierie). V2 (2026-07-20) : modèle binaire Vibe / Engineer + Tech Buddy transversal (filet sur les projets sans owner tech). La V1 (matrice N1/N2/N3) est archivée pour comparaison.

Pourquoi on en parle

Bricks opère sous régulation financière européenne (PSFP / ECSP 2020/1503, MiFID II en préparation, DORA depuis janvier 2025). Le code mis en production touche les économies de nos investisseurs. Un bug dans un calcul, une dérive contractuelle ou une exposition de donnée personnelle ne sont pas des incidents techniques abstraits — ce sont potentiellement des pertes financières et un défaut réglementaire à déclarer.

À ~20 personnes dont ~7 engineers, le risque n'est pas de manquer de process : c'est d'en avoir trop. Une règle unique, deux voies, et un socle technique mutualisé qui fait le gros du travail sans réunion.

État actuel (auto)

Dernière mise à jour : 2026-08-20

  • 2026-08-20 : les PD (Rémy, Pierre) vibe-codent l'UI dans Storybook ; Hugo review le code (voie Engineer sur le merge). Hors-scope apps. Pas de rules Cursor par rôle — la codebase prime. — meeting · ADR proposed

V2 acceptée — ADR 2026-07-20 · source mémo V2. Tech Buddy démarré : premier point outil d'analyse × William (Romain viber, Denis présent). V1 N1/N2/N3 : ADR 2026-05-21 (superseded).

Définitions clés

  • Vibe Coding : la personne décrit le besoin à l'IA, valide le rendu, ne lit pas le code généré.
  • AI-Assisted Coding (agentic engineering) : le développeur oriente, lit, comprend, valide le code IA.
  • Product Builder : vibe-code jusqu'au POC / proto validé ; au-delà = engineering Tech.
  • Tech Buddy : ingénieur référent sur un projet sans owner dev — challenge le plan, pas un tampon d'approbation code.

« Vibe coding raised the floor. Agentic engineering raises the ceiling. » — Karpathy, AI Ascent 2026.

Le modèle : 2 voies, 1 question

Si ça tombe ou produit un résultat faux : quelles conséquences, et qui les subi ?

Voie Vibe Voie Engineer
Quand Échec interne ou à faible conséquence Échec à conséquences et/ou subi par un tiers (investisseur / PDP / régulateur), ou doute
Qui N'importe qui (PB inclus) Ingénieurs uniquement
Méthode Vibe coding sur le socle commun AI-Assisted coding (pas de vibe)
Garde-fous PR + review IA (bugbot / risk / security). Tech Buddy si pas de owner dev (plan ; relecture PR ponctuelle, pas systématique) Peer review humaine avant merge + tests chemins critiques + trace d'audit (DORA)

Heuristique → Engineer si : argent perdu/mal orienté · décision d'investissement faussée · PII investisseur/PDP exposée · obligation légale/contractuelle. Doute → Engineer jusqu'à un check de 2 min qui prouve l'inverse.

Îlots Engineer dans un projet Vibe : éligibilité/anti-fraude, calculs agrégés affichés, pipelines de modération, identité/session — identifiés au démarrage, confiés à un dev (ou review humaine obligatoire).

Tech Buddy (filet transversal)

  • Déclencheur : absence d'owner tech — pas un niveau de criticité.
  • Charge : 30 min/semaine par défaut (1 h si projet gros / phase active).
  • Rôle : challenger le plan (« où va la donnée ? », « quelles deps ? », « que se passe-t-il si l'API tombe / double appel ? ») ; repérer un basculement Engineer avant la prod.
  • Non-rôle : valider le code, porter la responsabilité du résultat (reste sur le viber ou le lead Engineer).
  • Rituel : créneau fixe ; plan note 3-4 lignes en entrée ; timebox + recap Slack/Linear ; journal dans la base Suivi Tech Buddy. Débordement récurrent = signal de bascule Engineer.

Attribution (base de départ — à ajuster affinités / charge)

Projet (Vibe sans owner tech) Tech Buddy Viber
Outil d'analyse — fiche projet, contrats, rédaction… William Romain
Workflow d'analyse IA (agents / Manus) Vincent D Romain + Dimitri
CRM marketing / sales / Account Managers Hugo Alban
Support client type Zendesk interne Vincent B Alban
Gestion des défauts Denis Alban

Règles : un seul buddy par projet · rotation trimestrielle possible · projet qui bascule Engineer sort du tableau (dev en lead).

Classification provisoire des projets (V2)

Projet / Outil Voie Note
EF — front + back-office investisseur Engineer User-facing, données financières, paiements
App / outil d'analyse — modalités, garanties, contrats Engineer Alimente financement & modalités ; review humaine de l'output ne capte pas un calcul faux silencieux
Outil d'analyse — fiche projet & rédaction Vibe Validation humaine systématique avant publication
Workflow d'analyse IA (agents / Manus) Vibe exploratoire → Engineer à l'intégration Engineer dès que l'output est câblé sans gate humaine vers investisseurs/PDP
Gestion défauts — pénalités / votes / échéances Engineer Paiements, user-facing PDP
Notation projets (étoiles + avis) Vibe + îlots Engineer Îlots : anti-fraude, agrégation moyenne, modération (LCEN/RGPD)
Gamification (sans cash) Vibe Engineer si cash (parrainage, cashback, classements monétisés)
Support client type Zendesk interne Vibe Engineer si actions financières déclenchables
CRM marketing / sales / AM Vibe Pas de flux financier automatisé
Tooling MCP back-office Vibe (lecture) → Engineer (écritures sensibles) Selon actions exposées
Bubble (legacy) Engineer (en sortie) Critique, en migration

Projets construits hors process : plan léger de mise en conformité (standards, review IA, passation, refactor partiel) — pas de rétro-blocage.

Socle technique mutualisé (vrai levier)

Stack commune · conventions dans bricks-standards · rules IDE partagées · libs recommandées (anti-slopsquatting) · review IA sur toutes les PR · CI (lint, types, tests) · auth robuste partout · pas de PII en clair · lecture seule ≠ safe.

Plus les standards sont mutualisés en amont, plus on peut accepter du vibe coding en aval.

Ownership engineering

La voie (Vibe / Engineer) fixe le niveau de review ; elle ne réduit pas l'ownership. Même en Vibe, le porteur reste responsable de bout en bout. Voir ownership-engineering.

Gouvernance (légère)

Escalade seulement sur doute / litige (Produit + Tech). Trio CTO / CPO / CEO pour cas Engineer ambigu ou désaccord persistant. Désaccord non tranché → voie la plus stricte (Engineer). Réévaluation dès qu'un changement de scope touche la question du rayon d'explosion.

Recrutement

  • Product Builders : voie Vibe ; rien en Engineer sans dev lead/pairing (exception = décision LT explicite).
  • Développeurs / Ingénieurs : seuls habilités Engineer ; interviennent comme Tech Buddy sur les projets Vibe sans owner tech.

Historique V1 (archivé)

Matrice N1/N2/N3, synchro adoption 21/05 — détail dans ADR 2026-05-21 et meeting. Mapping approximatif : N1≈Vibe · N2≈Vibe+Tech Buddy (désormais découplé) · N3≈Engineer.

Références externes

Décisions liées

Concepts liés

Areas impactées

Sources