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 risque porté par le projet. Distingue Vibe Coding (orienté résultat, sans lecture du code) et AI-Assisted Coding (orienté ingénierie, code lu et compris). Pose une matrice de criticité N1/N2/N3 qui détermine quelle méthode est autorisée et quelle validation est exigée.

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 de pénalités, une dérive dans l'affichage d'une fiche projet, une faille dans la gestion d'un contrat ne sont pas des incidents techniques abstraits — ce sont potentiellement des pertes financières pour des utilisateurs et un défaut réglementaire à déclarer.

Tant que Romain et Alban étaient les deux seuls à vibe-coder en mode solo, Denis a accepté ce fonctionnement sans cadre formel — choix dont il assume la responsabilité, qui a permis d'avancer vite. Mais multiplier ce mode par 2 ou 3 avec les recrutements Product Builder à venir sans cadre = niveau de dette technique et risque produit/légal non absorbable.

Ce cadre est posé avant les recrutements, pas après. Ce n'est pas un jugement rétroactif sur le mode actuel — c'est la mise à l'échelle qui change la donne.

État actuel (auto)

Dernière mise à jour : 2026-06-11

Point d'étape synchro build 11/06 (fiche) : le Tech Buddy est reconfirmé par le CTO comme la prochaine étape n°1 (1h/semaine par projet, revue du plan). Implémentation en cours mais pas démarrée : il reste à présenter le modèle à l'équipe et à assigner un référent par projet (pas encore nominatif) → démarrage visé la semaine suivante. Les next steps écrits restent dus (toujours pas envoyés). Le couplage criticité par sujet (ex. contrats à livrer = N? qui review ?) reste à faire. L'ADR reste proposed. Standard d'archi émergent observé : organisation feature-first des codebases (validée tech), candidate à intégrer dans bricks-standards.

Statut : draft Denis partagé le 21/05 matin (source brute). Synchro d'adoption tenue le 21/05 après-midi (Denis + Romain + Vincent + Alban, 70 min, fiche meeting). Cadre structurel validé sur le fond. ADR maintenue en proposed jusqu'à réception des next steps écrits promis par Denis.

Définitions clés (cadre Karpathy AI Ascent 2026)

  • Vibe Coding : la personne décrit son besoin à l'IA, valide le rendu visuel/fonctionnel, ne lit pas le code généré. Vitesse pure.
  • AI-Assisted Coding (Karpathy : agentic engineering) : le développeur oriente, lit, comprend, valide le code IA. Productivité sous contrôle.
  • Product Builder : profil qui vibe-code, sans compétences techniques approfondies.
  • Développeur / Ingénieur : profil qui dispose des compétences techniques (architecture, sécurité, edge cases) et du jugement nécessaire pour décider quand vibe-coder est acceptable.

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

Position Bricks proposée : le Product Builder qui vibe-code s'arrête au POC ou au prototype validé. Au-delà (vraie production, vrais users, vraies données) → engineering, équipe Tech, Tech Buddy ou Peer Review, stack alignée. La version intermédiaire « solo jusqu'à ce que ça scale, puis Tech reprend » produit le pire scénario : système à réécrire pour le fiabiliser.

Matrice de criticité N1 / N2 / N3

Niveau Définition Méthode autorisée Validation
N1 — Faible Outils internes isolés, scripts jetables, prototypes UX, dashboards d'affichage. Pas d'écriture en DB de prod. Aucun client externe. Vibe Coding (full IA) Aucune revue requise. Autonomie complète.
N2 — Modérée Outils internes avec écriture DB de prod, automatisation processus métier non financiers, génération documents internes non légaux. Vibe Coding supervisé Tech Buddy 1h/semaine. Revue du plan, pas du code.
N3 — Élevée Core business, flux financiers, contrats légaux, calculs de pénalités, données PII, B2C/B2B externe (PDP, investisseurs). AI-Assisted Coding (Tech uniquement) Peer Review obligatoire avant merge. Tests automatisés sur chemins critiques.

Règle de désaccord : par défaut, le niveau le plus élevé l'emporte tant que la discussion CTO/CPO/CEO n'a pas tranché. CTO = qualification du risque technique, CPO = risque produit/utilisateur, CEO = risque business/légal.

Trois finalités du Tech Buddy (N2)

  1. Filet de sécurité sur les décisions d'architecture, sans transformer le buddy en goulot de relecture.
  2. Diffusion de la connaissance Product Builder ↔ Tech (dans les deux sens).
  3. Réduction du SPOF humain : aujourd'hui chaque projet vibé vit dans la tête d'une seule personne.

Fonctionnement : 1h max/semaine, revue du plan en langage naturel (architecture, dépendances, données touchées), pas du code ligne par ligne. Escalade en revue de code obligatoire si point critique identifié.

Trois finalités de la Peer Review (N3)

  1. Contrôle qualité et sécurité (pas de bibliothèques hallucinées, pas de failles, logique métier déterministe et testée).
  2. Diffusion de connaissance dans l'équipe.
  3. Résilience de l'équipe (plus d'une personne comprend chaque partie du système).

Règle dure : pas de Vibe Coding sur du N3, même par un Développeur. La distinction Vibe / Assisted est une exigence de processus, pas de personne.

Classification provisoire des projets (à valider en synchro)

Projet / Outil Niveau proposé Denis Justification
EF — front + back-office investisseur N3 User-facing, données financières, paiements
Outil d'analyse — modalités, garanties, contrats N3 Définit ce qui est engagé contractuellement
Outil d'analyse — fiche projet & rédaction N2 Validation humaine systématique avant publication
CRM Alban — calcul des pénalités N3 Génère des paiements
CRM Alban — votes, échéances N3 User-facing PDP, intégrité du suivi
CRM Alban — vues / UX admin N2 Admin only
CRM marketing / outils Account Managers N2 Écriture en DB sans flux financier direct
Outils internes audit / extracts ponctuels N1 Lecture seule, jetable
Tooling MCP back-office (Mélanie) N1 lecture / N2 écriture Selon périmètre des actions exposées
Bubble (legacy) N3 (en sortie) Critique mais en migration

Note : plusieurs projets actuellement classés N2/N3 ont été construits sans le process correspondant. Pas immédiatement « non conformes » — un plan de mise en conformité est défini (cf §7 du mémo) : transition vers Développeur, ajout de standards, refactor partiel — pas de rétro-blocage du projet en lui-même.

Standards techniques mutualisés (à construire)

  • Stack technique commune par catégorie (back-office, tools internes, front).
  • Conventions de code partagées versionnées dans un repo bricks-standards.
  • Cursor / IDE rules partagées (le contexte injecté dans l'IA reflète les conventions).
  • Tooling automatisé : linters, type-checks, tests obligatoires en CI sur tous les projets, y compris N1 si possible.
  • Revues de code automatisées sur N2/N3 (pistes : SDK Cursor / Claude Code).
  • Mono-repo ou organisation cohérente (à arbitrer).

Principe directeur du mémo : plus les standards sont mutualisés en amont, plus on peut accepter du vibe coding en aval sans perte de maîtrise.

Implications recrutement

  • Product Builders recrutables pour des sujets N1 principalement. Ne mettent rien en production sur du N2 ou N3 sans Développeur pairé en Tech Buddy ou en lead. Toute exception nécessite une décision explicite leadership team qui assume le risque.
  • Développeurs / Ingénieurs : seuls profils habilités à mettre en production sur N3 sans autre process que la Peer Review. Indispensables comme Tech Buddies sur N2.
  • Pairing : tout Product Builder recruté pour un sujet N2 est pairé dès l'onboarding avec un Tech Buddy nominalement désigné.

Arbitrages post-synchro 21/05 PM

Synchro tenue le 21 mai après-midi (Denis + Romain + Vincent + Alban, 70 min). Cadre structurel validé sur le fond. Détail dans la fiche meeting, arbitrages dans l'ADR §Arbitrages en synchro.

Méthode de classification (apport Vincent) : « probabilité de bug × scope d'impact × irréversibilité ». Pas par état du projet (proto vs prod) ni par taille. Conséquence : un script SQL vibé peut être N3 si la décision business qu'il alimente est critique. Une app complexe peut être N1 si isolée et réversible.

Frontière Profil B Bricks ≠ frontière Karpathy. La frontière du draft (« PB s'arrête au POC ») a été assouplie : Profil B Bricks peut shipper N1 et N2 (Tech Buddy nominal sur N2), pas N3. La V1 du Profil B du 5 mai (« le PB shippe lui-même les V1 fonctionnelles ») reste valide pour une V1 d'outil interne N1 ou d'un outil métier N2. Cas concret validé : un wrapper Manus pour un Product Builder reste fine en mode vibe code par PB.

Standards mutualisés à TOUS les niveaux, y compris N1 (commentaires 2 et 3 de Romain — résolus). 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.

Tech Buddy (commentaire 9 de Romain — résolu) : pool élargi (Denis, Vincent Duong, Vincent Besnier, William, possiblement Hugo, Thomas en juin). 1 Tech Buddy nominal par projet, pas une rotation hebdo. Format 1h synchrone focus, pas async (pattern SOS Captain Cursor de l'an dernier n'avait pas marché à cause du format async). Si compétence manquante, le buddy appelle un collègue.

Plus de N3 lancé en solo par PB. Tout nouveau projet potentiellement N3 = initié produit + tech ensemble. Sujets traînés (gestion projets / défauts par Alban, outil d'analyse modalités/contrats par Romain) = reliques du passé, prioritaires pour passation. Plan évoqué : Thomas reprend gestion défauts en juin (à confirmer Denis). Passation de la gestion projets/défauts (N3) vers Thomas actée début juin (binôme avec Alban), avec un point de vigilance suivi en interne. Alban s'engage sur la mise en conformité de gestion projets dans les prochaines semaines.

Vibe coding sur N3 = exception assumée, pas la norme. Garde-fou pendant : critère opposable de « pleine conscience » non posé en séance. À expliciter dans les next steps Denis.

Cursor automation risk assessment PR (commentaire 4 de Romain — convergence) : déjà active sur le monorepo depuis le week-end (action solo Denis). Low → auto-approve, sinon review obligatoire. Extension proposée par Vincent : niveau Linear (à l'ouverture d'issue, avant code).

Workflow 2.0 Linear → code (proposition Romain) : accepté en exploration, pas en spec-to-code top-down. Co-construction Tech Day, sessions dédiées 2h.

Reclassifications spécifiques

Sujet Verdict synchro Statut
CRM Alban (commentaire 6) N2 sur l'aspect tech, îlot N3 sur la sécurité confidentialité documents. Risque qualité réponse porté par l'humain (account manager). Tranché
Workflow d'analyse IA / Manus (commentaire 5) Logique posée : N1 maintenant, bascule N2 le jour où agent Bricks internalisé. Niveau formel à acter dans next steps Denis. Logique acceptée
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

Python pour les agents IA — pas de Tech Buddy back maîtrisant Python en interne. Pistes : (a) Bug Bot Python suffit pour démarrer, (b) consultation d'un expert externe ponctuel, (c) Denis/Vincent prennent quelques heures pour creuser les bonnes pratiques. Sujet ouvert.

Next steps formels en attente (par ordre d'impact)

  1. Liste écrite des next steps par Denis (promise en clôture).
  2. Reclassifications restantes (App analyse projet immo, Notation, Gamification, critère §9 checklist).
  3. Désignation nominale Tech Buddies par projet en cours et à venir.
  4. Critère opposable « pleine conscience » sur N3 vibe codé.
  5. Scope + deadline mise en conformité gestion projets par Alban.
  6. ~~Confirmation reprise gestion défauts par Thomas (juin).~~ ✅ Confirmé début juin.
  7. Décision Python agents IA (a, b ou c).
  8. bricks-standards : initialisation repo / dossier en Tech Day.

Cas types (jurisprudence, §10 du mémo)

Type de projet Niveau Justification
App support client type Zendesk interne N2 (N3 si actions financières) Écriture en DB et réponses au client final
Gestion défauts + calcul pénalités N3 Génère des paiements, impact PDP et investisseurs
CRM sales N2 (contesté Romain → N1) Voir point à reverrouiller n°6
App analyse projet immobilier N3 (contesté Romain) Alimente décisions de financement et modalités contractuelles
Notation projets (étoiles + avis) N2 avec îlots N3 Îlots N3 : éligibilité/anti-fraude, agrégation moyenne affichée, modération (LCEN/RGPD)
Gamification investisseurs (sans cash) N2 (contesté Romain) Bascule N3 si parrainage rémunéré, cashback, classements monétisés

Pattern « îlots N3 dans un projet N2 » : un projet globalement N2 peut contenir des sous-composants N3 — éligibilité/anti-fraude, calculs agrégés affichés, pipelines de modération, gestion d'identité. Identifiés au démarrage, soit confiés à un Développeur, soit revue de code obligatoire.

Références externes (sources mémo Denis)

Décisions liées

Concepts liés

  • criticite-features — V0 abstraite Bas/Moyen/Haut, raffinée par ce concept en N1/N2/N3 avec règles opérationnelles
  • product-builder — frontière de sortie clarifiée par Karpathy (Profil B s'arrête au POC validé)
  • tooling-days — moment dédié à la mutualisation des standards techniques (point 2 Romain)
  • outil-d-analyse — classifié N3 modalités/contrats + N2 fiche projet dans la table provisoire
  • workflow-agent-linear — pipeline agent autonome qui s'inscrit dans la logique « revue automatisée sur N2/N3 » (§6 du mémo)

Areas impactées

  • areas/tech — process review, standards mutualisés, Tech Buddy
  • areas/produit — frontière Product Builder, scope des sujets vibécodés
  • areas/rh — recrutement Product Builder vs Développeur, pairing dès onboarding

Sources