Méthode
Comment CodeBlend travaille, de J1 à la passation
Cette page est faite pour être transférée : à votre architecte, à votre sécurité, à vos achats. Elle dit comment une mission démarre, comment les décisions sont tracées, et ce que font les agents IA.
Les dix premiers jours
Nous lisons le code, les décisions déjà prises et l'organisation de l'équipe. À J10, vous avez un état des lieux et un plan à 30 jours. Les priorités se discutent sur pièces.
diagnostic/ etat-des-lieux.md plan-30-jours.md decisions-a-prendre.md
Chaque décision structurante est écrite
Une ADR tient sur une page : le contexte, la décision, les options écartées, les conséquences. Elle dit pourquoi, pas seulement quoi. Le format existe depuis 2011 et il n'a pas pris une ride. Chez Engie, des ADR introduites dans une équipe qui n'en écrivait pas sont toujours utilisées après la fin de la mission.
# ADR-001 · Design tokens obligatoires Statut : accepté Contexte : couleurs, espacements et arrondis étaient écrits en dur, composant par composant. Décision : toute couleur, tout espacement et tout arrondi passe par `design-tokens.css`. Conséquence : une nouvelle couleur est une modification de token, relue comme le reste du code.
Les agents IA codent dans vos règles
Nous développons avec des agents IA au quotidien. Ils écrivent une grande partie du volume. Chez Boiron, plus une ligne de code n'est produite sans agent : la direction, la revue et l'arbitrage restent humains.
Délégué à l'agent
Jamais délégué
Le cadre tient dans un fichier, AGENTS.md, un standard ouvert que lisent la plupart des agents de code. Il contient ce que le code ne dit pas : les règles d'interface, les décisions à lire, les commandes à ne pas lancer.
# AGENTS.md Consignes pour les agents de code, et pour les humains, qui modifient le site codeblend.fr. Ce fichier est affiché en entier sur la page /methode : il doit rester exact. ## Projet - Site de CodeBlend : Next.js 16 (App Router), React 19, Tailwind CSS 4, TypeScript strict. Node 24 (voir .nvmrc), npm. - Avant d'utiliser une API de Next.js, lire la documentation de la version installée dans node_modules/next/dist/docs/. - Commentaires de code en anglais, et seulement pour dire pourquoi, quand le code ne le montre pas. ## Commandes - npm run typecheck : vérification des types (next typegen puis tsc --noEmit). - npm run lint : ESLint. - npm test : tests unitaires (Vitest, tests/unit/). - npm run build : build de production. - npm run test:e2e : tests de bout en bout (Playwright, build et serveur sur le port 3100). - Une modification n'est terminée que si typecheck, lint et test passent. ## Interface - Couleurs, espacements, arrondis : uniquement via design-tokens.css. - Boutons : components/ui/button.tsx, variantes primary, ghost et tertiary, tailles sm et md. - Aucune ombre portée. Focus visible partout. Zéro violation serious ou critical à axe (tests/e2e/a11y.spec.ts). ## Décisions - Lire docs/adr/ avant toute modification d'interface. - Lire docs/conventions.md avant de modifier les tests, le playground ou les artefacts affichés. - Une décision qui engage la suite s'écrit en ADR, à partir de docs/adr/gabarit.md. ## Contenu - Aucun chiffre, nom, témoignage ou logo client sans source. Le test tests/e2e/content-guard.spec.ts bloque les contenus factices connus. - Textes affichés : français, vouvoiement, pas de tiret cadratin, pas de point d'exclamation. ## Données et secrets - Aucun secret dans le dépôt : les noms de variables sont dans .env.example, les valeurs restent dans l'environnement. - Pas de secret ni de donnée personnelle dans un prompt. ## Commandes à ne pas lancer - Aucune commande qui lit un fichier .env ou qui appelle l'API NocoDB ou Resend avec de vraies clés. - Pas de git commit ni de git push sans demande explicite. ## Revue - Aucun code généré n'est fusionné sans qu'un humain l'ait relu et en réponde.
Ce qui part dans un prompt
Avant le premier prompt, nous fixons avec vous ce qui peut sortir de votre réseau : quel code, quelles données, quels documents. Pas de secret ni de donnée personnelle dans un prompt. Les outils se choisissent selon votre politique, pas l'inverse.
Un humain décide, et répond du code
Chaque modification passe en revue avant d'être fusionnée. La revue ne promet pas de relire chaque ligne générée. Elle désigne qui décide, et qui répond du code en production. Les tests automatisés et les conventions font le reste.
Le problème est mesuré. En 2025, 66 % des développeurs interrogés par Stack Overflow (nouvel onglet) citent des réponses d'IA « presque justes, mais pas tout à fait ». Le rapport DORA 2025 (nouvel onglet) dit la même chose autrement : l'IA ne répare pas une équipe, elle amplifie ce qui existe déjà.
La passation commence le premier jour
Document d'accueil testé sur un vrai arrivant, conventions écrites à partir des ADR, relais au lead ou à l'équipe suivante. Le critère est simple : un nouveau développeur trouve seul comment le front est construit, et pourquoi.
Ce que j'écris chaque semaine
Orchestrateur, la newsletter de Guillaume sur le lead dev et l'IA, paraît chaque mardi. Trois numéros liés à cette page :
- Le code IA entre en prod sans contrat. Signe-le avant l'incident. (nouvel onglet) (6 octobre 2026)
- Ton senior part avec le pourquoi. L'IA, elle, devine le reste. (nouvel onglet) (13 octobre 2026)
- Tu as une CI pour ton code. Qui teste les instructions d'IA de ton équipe ? (nouvel onglet) (15 septembre 2026)
Une question sur la méthode avant de signer ?
Trente minutes pour la passer en revue, avec vous ou avec votre architecte.