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-10-26

  • 2026-10-23 (Point d'étape Build IA) : rôle des devs front vu par Romain comme outillage de la stack (Storybook, skills, reviews spécialisées, tests) plutôt qu'intégration ; Alban préfère s'arrêter aux maquettes Figma pour garder des responsabilités claires ; conversion design vers code par l'IA jugée utile pour remonter les écarts au DS, garde-fou ou review finale proposé — Leexi Point d'étape Build IA 2026-10-23 · pas d'ADR à ce stade.

  • 2026-10-16 (standup) : l'usage des outils IA reste soumis à la classification des données et aux prestataires explicitement validés. Aucun document sensible ou nominatif ne doit être transmis sans validation sécurité / conformité. Chaque personne reste responsable de la relecture des productions de l'IA [source locale non partagée]. Ce cadre provisoire reste à formaliser dans une ADR.

  • 2026-10-15 : projet Build en code avec Uimmo posé dans Linear — flow réel construit en code avec l'agent, binôme Design × TechFront, une fois Uimmo prêt — DM groupe. Figma code layers en open beta (Figma Help) : à tester en phase 0 côté design, sans dépendance, le code reste la référence [non sourcé : position relayée par la veille AI Design Engineer].

  • 2026-08-20 : les PD construisent l'UI dans Storybook ; le Front relit le code (voie Engineer sur le merge). Hors-scope apps. Pas de rules Cursor par rôle — la codebase prime. — ADR proposed

V2 acceptée — ADR 2026-07-20. Tech Buddy démarré sur l'outil d'analyse [source locale non partagée]. 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 — détail dans ADR 2026-05-21. 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