Aller au contenu

Criticité des features

Définition

Échelle qui classe chaque feature / chaque tool selon son niveau de risque pour la boîte, et qui détermine le niveau de review tech requis avant mise en prod. À construire sous forme de grille partagée entre tech (Denis, Vincent) et product builders (Romain, Alban).

Pourquoi on en parle

Le mode "build solo sans review tech" qui a permis à Romain et Alban d'aller vite est en train d'atteindre ses limites : - Multiplie le risque de désalignement avec l'archi - Ne tient pas à l'échelle si on recrute d'autres profils builders - Crée des sujets critiques (paiements, échéancier, contrats) sans garde-fou

D'un autre côté, mettre tous les sujets sous le même process tech (review code ligne par ligne, PR, etc.) tuerait la vélocité sur des sujets non-critiques (UX back-office, exploration produit).

État actuel (auto)

Dernière mise à jour : 2026-05-21

V0 (cadre 30/04, abstrait) — superseded en cours

Cadre posé au meeting 2026-04-30 (ADR 2026-04-30) :

  • Grille à construire par tool ET par feature à l'intérieur d'un tool (ex : la même plateforme gestion projets contient des features non-critiques UX et des features critiques calcul de pénalités).
  • Critères de criticité (pistes initiales) : customer-facing, touche de la donnée critique, génère des effets de bord déterministes, visibilité/réversibilité.
  • 3 niveaux abstraits : Bas (pas de review) · Moyen (review du plan en langage naturel) · Haut (review tech complète plan + code, PR, tests).
  • Phase 2 : mutualisation du tooling (stack commune, rules Cursor, flags TypeScript, conventions repo).

V1 (mémo Denis 21/05 + synchro adoption 21/05 PM) — proposed, cadre validé sur le fond

Le sprint « Denis + Romain — première itération de la grille » prévu post-30/04 a été remplacé par un mémo opérationnel partagé par Denis le 21/05 matin (source brute, synthèse concepts/ai-coding-vibe-coding, ADR 2026-05-21 proposed). Synchro d'adoption tenue le 21/05 après-midi (fiche meeting) — cadre validé sur le fond, ajustements actés.

Évolutions par rapport à la V0 :

  • Renommage : Bas/Moyen/Haut → N1/N2/N3, plus opérable (vocabulaire commun équipe + classification provisoire des projets en table).
  • Méthode autorisée différenciée : N1 = Vibe Coding libre, N2 = Vibe Coding supervisé par Tech Buddy (1h/semaine, revue du plan, escalade en revue de code si point critique), N3 = AI-Assisted Coding par Tech uniquement + Peer Review obligatoire avant merge + tests automatisés.
  • Discussion CTO + CPO + CEO au démarrage de chaque projet pour fixer le niveau, et à chaque évolution de scope (downgrade comme upgrade).
  • Règle de désaccord : niveau le plus élevé l'emporte par défaut tant que la discussion à 3 n'a pas tranché. CTO porte le risque tech, CPO le risque produit/utilisateur, CEO le risque business/légal.
  • Frontière Karpathy ajoutée : le Product Builder qui vibe-code s'arrête au POC validé. Au-delà = engineering. Pas de mode intermédiaire « solo jusqu'à scale puis Tech reprend » (= pire scénario, l'équipe Tech hérite d'un système à réécrire).
  • Standards mutualisés repris de la V0 mais durcis : bricks-standards (repo dédié), Cursor rules partagées, CI commune sur tous les projets y compris N1 si possible, revues IA automatisées sur N2/N3 (SDK Cursor / Claude Code à explorer).

Arbitrages post-synchro 21/05 PM

  • Critère de classification = scope d'impact, pas état du projet (Vincent : « probabilité de bug × scope d'impact × irréversibilité »).
  • Standards mutualisés à TOUS les niveaux y compris N1 — repo bricks-standards à co-construire en Tech Days. Coût marginal très faible (les agents IA respectent les conventions directement). Permet la bascule N1 → N2 sans refonte (commentaires 2 et 3 de Romain — résolus).
  • Tech Buddy : pool élargi (Denis, Vincent Duong, Vincent Besnier, William, Hugo, Thomas en juin), 1 nominal par projet, format 1h synchrone focus (commentaire 9 de Romain — résolu).
  • CRM Alban → N2 (avec îlot N3 sécurité documents). Risque qualité réponse porté par l'humain (commentaire 6 — résolu).
  • Frontière Profil B : peut shipper N1 et N2, pas N3. Plus large que la frontière Karpathy initiale du draft.
  • Plus de N3 lancé en solo par PB. Sujets traînés (gestion projets / défauts, outil d'analyse modalités) = reliques du passé, prioritaires pour passation. Thomas reprend gestion défauts en juin (à confirmer Denis).
  • Cursor automation risk assessment PR déjà active sur le monorepo (Denis ce week-end).

Reclassifications restées ouvertes (à trancher dans next steps Denis)

  • Critère §9 checklist N2 (commentaire 1).
  • App d'analyse projet immobilier N3 (commentaire 7, contesté Romain).
  • Notation projets / îlots N3 (commentaire 7).
  • Gamification investisseurs (commentaire 8).
  • Workflow d'analyse IA / Manus — niveau formel (commentaire 5, logique posée).
  • Critère opposable « pleine conscience » sur N3 vibe codé (sujet émergent).

Détail : ADR 2026-05-21 §Arbitrages en synchro, fiche meeting 21/05 PM.

Décisions liées

Projets et areas impactés

Sources