Compound Engineering : une philosophie d’ingénierie native IA

• Une méthodologie de développement logiciel à effet cumulatif où chaque unité de travail d’ingénierie facilite les travaux suivants, structurée autour d’une boucle en 4 étapes (planification → exécution → revue → capitalisation) pour systématiser la collaboration avec des agents IA
• Dans cette boucle itérative, 80 % du temps de l’ingénieur doit être consacré à la planification et à la revue, et 20 % à l’exécution et à la capitalisation
• Distribué sous forme de plugin incluant 26 agents spécialisés, 23 commandes de workflow et 13 skills, avec installation possible sur Claude Code, OpenCode et Codex
• Présente 8 idées reçues du développement logiciel traditionnel (le code doit être écrit à la main, chaque ligne doit être revue manuellement, etc.) comme des croyances à abandonner, au profit de nouveaux principes consistant à encoder ses préférences dans le système
• Un framework global qui classe le niveau d’adoption de l’IA par les développeurs de niveau 0 (développement manuel) à niveau 5 (exécution cloud en parallèle), avec des méthodes de progression pour chaque étape et une extension à la collaboration d’équipe, au design, à la recherche et au marketing

---

Philosophie centrale

• Le principe fondamental est que chaque unité de travail d’ingénierie doit rendre les travaux suivants plus faciles
• Dans une base de code traditionnelle, la complexité augmente à chaque ajout de fonctionnalité, au point qu’au bout de 10 ans, on passe plus de temps à lutter contre le système
• Dans Compound Engineering, une fonctionnalité apprend une nouvelle capacité au système, une correction de bug élimine toute une catégorie de bugs futurs, et les patterns sont transformés en outils, de sorte que la base de code devient avec le temps plus facile à comprendre, modifier et fiabiliser

Boucle principale : Plan → Work → Review → Compound

• Every exploite 5 produits (Cora, Monologue, Sparkle, Spiral, Every.to) avec des équipes d’ingénierie majoritairement composées d’une seule personne, rendues possibles par cette boucle en 4 étapes
• Les 3 premières étapes (planification, exécution, revue) sont classiques, mais la 4e étape, Compound, est la différence clé où s’accumulent les bénéfices cumulatifs
• Qu’il s’agisse d’un correctif de 5 minutes ou du développement d’une fonctionnalité sur plusieurs jours, la même boucle est utilisée, seul le temps alloué à chaque étape change

• Étape 1 : Plan (planification)

  • Comprendre les exigences : identifier ce qu’il faut construire, pourquoi, et sous quelles contraintes
  • Étudier la base de code : analyser le fonctionnement de fonctionnalités similaires et les patterns existants
  • Recherche externe : consulter la documentation des frameworks et les bonnes pratiques du secteur
  • Concevoir la solution : définir l’approche et les fichiers à modifier
  • Valider le plan : vérifier l’exhaustivité et la cohérence de l’ensemble du plan

• Étape 2 : Work (exécution)

  • Configurer un environnement isolé : séparer le travail via un Git worktree (copie isolée du dépôt) ou une branche
  • Exécuter le plan : l’agent implémente étape par étape
  • Lancer les validations : exécuter tests, linting (vérification automatique du code) et contrôle de types après chaque modification
  • Suivre l’avancement et ajuster le plan en cas de problème
  • Si l’on fait confiance au plan, il n’est pas nécessaire de surveiller le code ligne par ligne

• Étape 3 : Review (revue)

  • Plusieurs agents effectuent la revue de code en parallèle
  • Les constats sont classés par priorité en P1 (correction indispensable), P2 (correction recommandée), P3 (amélioration)
  • L’agent corrige les problèmes à partir des retours de revue, puis vérifie les corrections
  • Consigner les patterns : documenter ce qui a mal tourné pour éviter les récidives

• Étape 4 : Compound (capitalisation) — l’étape la plus importante

  • Le développement traditionnel s’arrête à la 3e étape, mais dans l’étape Compound, les améliorations du système s’accumulent
  • Si les 3 premières étapes produisent des fonctionnalités, la 4e produit le système qui permet de mieux créer des fonctionnalités
  • Tâches réalisées :
    • Identifier ce qui a fonctionné ou non, et quelles idées réutilisables peuvent en être tirées
    • Ajouter métadonnées, tags et catégories via le YAML frontmatter pour rendre le tout retrouvable
    • Ajouter de nouveaux patterns dans CLAUDE.md et, si nécessaire, créer un nouvel agent
    • Vérifier : « la prochaine fois, le système pourra-t-il détecter automatiquement ce problème ? »

Composition du plugin

• 26 agents spécialisés : revue (14), recherche, design, workflow, documentation, etc., chacun dédié à une tâche précise
• 23 commandes de workflow : boucle principale + utilitaires
• 13 skills : apportent une expertise métier comme l’architecture agent-native ou les guides de style
• Installation sans configuration possible sur Claude Code, OpenCode (expérimental) et Codex (expérimental)

• Structure des fichiers

  • CLAUDE.md : le fichier le plus important, lu par l’agent au début de chaque session, où sont stockés préférences, patterns et contexte projet
  • docs/solutions/ : les problèmes résolus s’y accumulent sous forme de documents consultables, constituant une connaissance institutionnelle
  • docs/brainstorms/ : stockage des sorties de la commande brainstorm
  • docs/plans/ : stockage des sorties de la commande plan
  • todos/ : suivi des tâches par priorité et statut

Commandes clés

• /workflows:brainstorm

  • Commande utilisée lorsqu’on ne sait pas clairement quoi construire
  • Après une recherche légère dans le dépôt, elle clarifie point par point l’objectif, les utilisateurs, les contraintes et les cas limites via des questions
  • L’IA propose une approche, et le résultat est enregistré dans docs/brainstorms/ puis transmis à /workflows:plan

• /workflows:plan

  • Décrivez ce que vous voulez, et la commande renvoie un plan d’implémentation
  • Exécute 3 agents de recherche en parallèle : repo-research-analyst (patterns de la base de code), framework-docs-researcher (documentation), best-practices-researcher (standards du secteur)
  • L’agent spec-flow-analyzer analyse les flux utilisateur et les cas limites
  • Quand le mode ultrathink est activé, /deepen-plan s’exécute automatiquement et lance plus de 40 agents de recherche en parallèle

• /workflows:work

  • Étape où l’agent écrit réellement le code
  • 4 phases : quick start (création d’un Git worktree et configuration de branche) → execute (implémentation par tâche avec suivi d’avancement) → quality check (activation optionnelle de plus de 5 agents reviewers) → ship it (exécution du linting, création de PR)

• /workflows:review

  • Une PR est revue simultanément en parallèle par plus de 14 agents spécialisés
  • Inclut sécurité (security-sentinel), performance (performance-oracle), architecture (architecture-strategist), intégrité des données (data-integrity-guardian), qualité du code (code-simplicity-reviewer), reviewers spécialisés par framework (DHH-rails, Kieran-rails/python/typescript), validation de déploiement, race conditions frontend et reviewer agent-native, entre autres
  • La sortie est une liste unique priorisée, classée en P1 (critique), P2 (important), P3 (mineur)
  • La commande /resolve_pr_parallel corrige automatiquement les problèmes détectés (priorité aux P1, chaque correction étant exécutée de façon isolée)
  • La commande /triage permet de filtrer les constats un par un en les approuvant, les ignorant ou les personnalisant

• /workflows:compound

  • Documente les problèmes résolus pour consultation future
  • Lance 6 sous-agents en parallèle : context analyzer, solution extractor, related docs finder, prevention strategist, category classifier, documentation writer
  • Génère un Markdown consultable avec YAML frontmatter

• /lfg

  • Décrivez une fonctionnalité, et l’agent prend en charge planification, implémentation et revue pour soumettre une PR prête à être mergée
  • Enchaîne tout le pipeline : plan → deepen-plan → work → review → resolve findings → browser tests → feature video → compound
  • Après validation du plan, l’exécution devient autonome avec plus de 50 agents mobilisés sur l’ensemble des étapes

8 convictions à abandonner

• « Le code doit être écrit à la main »

  • La vraie exigence, c’est d’écrire un bon code, maintenable et qui résout le bon problème ; peu importe qui tape

• « Chaque ligne doit être revue manuellement »

  • La revue manuelle ligne par ligne n’est qu’un moyen parmi d’autres d’assurer la qualité ; des systèmes automatisés capables de détecter les mêmes problèmes sont tout aussi valables
  • Si vous ne pouvez pas faire confiance au résultat, ne compensez pas en le faisant vous-même ; il faut corriger le système

• « La solution doit venir de l’ingénieur »

  • L’IA peut étudier les approches, analyser les trade-offs et recommander des options ; le rôle de l’ingénieur est donc d’y ajouter du goût (taste) — juger quelle solution convient à cette base de code, à cette équipe et à ce contexte

• « Le code est le livrable principal »

  • Le système qui produit le code a plus de valeur que le code pris individuellement
  • Plus qu’une implémentation brillante, ce qui compte, c’est un processus capable de produire régulièrement de bonnes implémentations

• « Écrire du code est le travail principal »

  • Le travail d’un développeur, c’est de livrer de la valeur (ship value), et le code n’est qu’un des intrants
  • La planification, la revue et la formation du système font aussi partie du travail

• « Le premier essai doit être bon »

  • Le taux d’échec du premier essai est de 95 %, et celui du deuxième de 50 %
  • Ce n’est pas un échec mais un processus ; il faut se concentrer sur des itérations rapides pour que le troisième essai soit terminé plus vite que le premier

• « Le code est une forme d’expression personnelle »

  • Le code appartient à l’équipe, au produit et aux utilisateurs ; si l’on cesse de voir le code comme une expression de soi, il devient plus facile d’accepter les retours, de refactorer et de débattre de la qualité

• « Plus on tape, plus on apprend »

  • Aujourd’hui, la compréhension compte plus que la mémoire musculaire
  • Un développeur qui revoit 10 implémentations produites par l’IA comprend davantage de patterns qu’un développeur qui en a tapé 2 lui-même

Les défis psychologiques de la transition

• Quand on tape moins, on a l’impression de moins travailler : en réalité, donner des instructions à un agent demande plus de réflexion que l’implémentation elle-même
• L’anxiété liée à l’exécution autonome : il ne s’agit pas d’abandonner le contrôle, mais d’encoder ce contrôle dans des contraintes, des règles et des processus de revue
• La question « Est-ce vraiment moi qui l’ai fait ? » : planifier, relire et garantir des critères de qualité, c’est précisément le travail ; l’IA ne fait qu’écrire

Convictions à adopter

• Extraire le goût dans le système

  • Les préférences du développeur — conventions de nommage, patterns de gestion d’erreurs, approche des tests, etc. — sont généralement peu documentées et existent dans la tête des ingénieurs seniors
  • Il faut consigner ces préférences dans CLAUDE.md ou AGENTS.md, puis construire des agents et des skills spécialisés pour la revue, les tests et le déploiement afin que l’IA produise directement du code digne d’être approuvé

• La règle du 50/50

  • 50 % du temps d’ingénierie doit être consacré au développement de fonctionnalités, et 50 % à l’amélioration du système
  • Traditionnellement, on est à 90 % fonctionnalités / 10 % reste ; mais créer un agent de revue, documenter les patterns ou construire un générateur de tests constitue un investissement qui facilitera les futures fonctionnalités
  • Une heure investie dans un agent de revue peut faire gagner 10 heures de temps de revue sur un an

• Faire confiance au processus et construire des filets de sécurité

  • Si l’assistance IA doit passer à l’échelle, il devient impossible de faire relire chaque ligne par un humain ; l’essentiel est donc de mettre en place des garde-fous comme des tests, des revues automatiques et du monitoring
  • Si vous ne pouvez pas faire confiance au résultat, ne repassez pas en revue manuelle ; ajoutez plutôt un système qui rende cette étape fiable

• Configurer l’environnement pour qu’il soit agent-native

  • Tout ce qu’un développeur peut voir ou faire, un agent doit aussi pouvoir le faire : exécuter les tests, consulter les logs de production, déboguer via captures d’écran, créer des PR, etc.
  • Toute tâche que vous n’autorisez pas à l’agent devra être faite manuellement par vous-même

• Exploiter la parallélisation

  • Autrefois, le goulot d’étranglement, c’était l’attention humaine — une seule tâche à la fois ; désormais, le nouveau goulot d’étranglement, c’est le compute (le nombre d’agents pouvant s’exécuter simultanément)
  • Faites tourner plusieurs agents et plusieurs fonctionnalités en parallèle, et exécutez revue, tests et documentation simultanément

• Le plan est le nouveau code

  • Le document de planification est désormais le livrable le plus important
  • Au lieu d’écrire le code d’abord puis de documenter ensuite, rédiger le plan en premier en fait la source de vérité que l’agent utilise pour générer, tester et valider le code
  • Corriger une idée sur le papier coûte moins cher que la corriger dans le code

• Résumé des principes clés

  • Chaque unité de travail doit rendre la suivante plus facile
  • Le goût doit être intégré au système, pas à la revue
  • Au lieu de faire le travail soi-même, il faut enseigner le système
  • Il faut construire des filets de sécurité, pas des processus de revue
  • Il faut structurer l’environnement de manière agent-native
  • Il faut appliquer une pensée de type intérêts composés partout
  • Il faut accepter l’inconfort de la délégation et préférer des résultats imparfaits mais scalables à des résultats parfaits mais impossibles à faire passer à l’échelle
  • Il faut écrire moins de code et livrer plus de valeur
  • Ces principes peuvent s’étendre au-delà de l’ingénierie à tous les domaines où la codification du goût et du contexte est utile, comme le design, la recherche ou l’écriture

Les étapes de progression du développeur (échelle en 5 niveaux)

• Stage 0 : développement manuel

  • Écrire le code ligne par ligne sans IA, faire la recherche via la documentation et Stack Overflow, déboguer avec des print
  • Cette approche a permis de produire de bons logiciels pendant des décennies, mais en 2025, elle n’est plus assez rapide

• Stage 1 : assistance par chat

  • Poser des questions à ChatGPT, Claude, Cursor, etc. pour obtenir des snippets de code, puis copier-coller ce qui est utile
  • L’IA accélère la recherche et la génération de boilerplate, mais on garde un contrôle total en relisant soi-même chaque ligne

• Stage 2 : outils agentiques + revue ligne par ligne

  • Des outils agentiques comme Claude Code, Cursor Composer ou Copilot Chat lisent les fichiers et modifient directement la base de code
  • Le développeur joue un rôle de gatekeeper, approuvant ou rejetant tout ce que propose l’agent
  • La plupart des développeurs stagnent à ce stade et ne profitent pas vraiment des bénéfices de la délégation à l’IA

• Stage 3 : plan d’abord, revue au niveau PR

  • C’est l’étape où tout change : on co-rédige avec l’IA un plan détaillé incluant exigences, approche et edge cases
  • Une fois le plan établi, l’IA implémente sans supervision, et le résultat est relu au niveau de la PR
  • Compound Engineering commence ici — à chaque cycle, la planification, l’implémentation et la revue enseignent quelque chose au système, rendant le cycle suivant plus rapide et plus simple

• Stage 4 : idée → PR (machine unique)

  • Vous fournissez une idée, et l’agent s’occupe de tout : recherche dans la base de code, planification, implémentation, tests, auto-revue, résolution des problèmes et création de la PR
  • L’intervention humaine se réduit à 3 étapes : proposer l’idée, relire la PR, merger
  • Mais tout s’exécute encore sur un seul ordinateur, une tâche à la fois

• Stage 5 : exécution cloud en parallèle (multi-device)

  • L’exécution bascule dans le cloud pour permettre une exécution parallèle
  • On peut affecter 3 agents à 3 fonctionnalités en même temps, puis relire les PR une fois prêtes
  • Les agents peuvent surveiller les retours et aller jusqu’à proposer spontanément des corrections
  • Le rôle n’est plus celui d’un contributeur individuel, mais de chef d’orchestre d’une flotte d’agents

Guide de progression

• 0 → 1 : commencer à collaborer

  • Choisissez un outil (Cursor with Opus 4.5 ou Claude Code, par exemple) et utilisez-le chaque jour
  • Avant d’écrire du code, demandez à l’IA d’expliquer le code existant pour vérifier votre compréhension
  • Déléguez d’abord le boilerplate : tests, fichiers de configuration, fonctions répétitives, etc.
  • Passez en revue chaque ligne pour apprendre
  • Travail à effet composé : consignez en continu les prompts qui ont bien fonctionné

• 1 → 2 : autoriser l’accès agentique

  • Passez en mode agentique et donnez à l’agent l’accès au système de fichiers
  • Commencez par des changements limités à un seul fichier et à un seul objectif, comme « ajouter des tests à cette fonction »
  • Construisez votre intuition de confiance en approuvant ou refusant chaque action
  • Relisez le diff pour vous concentrer sur les parties modifiées
  • Travail à effet composé : créez un fichier CLAUDE.md et ajoutez-y des notes quand l’agent se trompe

• 2 → 3 : faire confiance au plan (bascule clé)

  • Rédigez les exigences, l’approche et les cas limites sous la forme d’un plan explicite
  • Autorisez l’IA à lire la codebase, à repérer des patterns et à proposer une approche
  • Une fois le plan écrit, confiez l’implémentation à l’agent et éloignez-vous jusqu’à ce qu’il ait terminé
  • Faites la revue au niveau de la PR, pas au niveau des étapes individuelles ou des lignes de code
  • Travail à effet composé : après chaque implémentation, documentez ce que le plan a manqué

• 3 → 4 : présenter le résultat, pas les instructions

  • Fournissez un résultat (outcome), comme « ajouter une notification par e-mail pour les nouveaux commentaires », et laissez l’agent décider de la manière de l’implémenter
  • Puisque l’agent connaît la codebase et mène la recherche, le plan relève aussi de sa responsabilité
  • Passez en revue l’approche avant l’implémentation pour bloquer tôt une mauvaise direction
  • Travail à effet composé : constituez une bibliothèque d’instructions centrées sur le résultat qui ont bien marché

• 4 → 5 : tout paralléliser

  • Déplacez l’exécution vers le cloud pour supprimer les goulots d’étranglement de la machine locale
  • Assignez 3 fonctionnalités à 3 agents en même temps
  • Organisez les idées, bugs et améliorations en file d’attente afin que les agents les traitent dans l’ordre
  • Activez les agents pour qu’ils surveillent les retours utilisateurs et proposent spontanément des fonctionnalités
  • Travail à effet composé : documentez la différence entre les tâches parallélisables et celles qui sont intrinsèquement sérielles

3 questions avant d’approuver une production de l’IA

• « Quelle a été ici la décision la plus difficile ? » — pousse l’IA à révéler les passages délicats et les points de jugement
• « Quelles alternatives as-tu écartées, et pourquoi ? » — permet de vérifier les options envisagées et de repérer un mauvais choix
• « Sur quelle partie es-tu le moins sûr de toi ? » — amène le LLM à reconnaître ses faiblesses, mais il ne répond que si on le lui demande explicitement

Architecture native agent

• L’essentiel est de donner à l’agent les mêmes capacités qu’un développeur
• Si l’agent ne peut pas lancer les tests, il faut les lancer soi-même ; s’il ne peut pas voir les logs, il faut déboguer soi-même : toute capacité non accordée se transforme en travail manuel

• Checklist native agent

  • Environnement de développement : exécuter l’application en local, lancer la suite de tests, exécuter le linter et le vérificateur de types, faire les migrations DB, initialiser les données de développement
  • Opérations Git : créer une branche, commit, push vers le remote, créer une PR, lire les commentaires de PR
  • Débogage : consulter les logs locaux / de production (lecture seule), capturer des captures d’écran de l’UI, inspecter les requêtes réseau, accéder au suivi d’erreurs (Sentry, etc.)

• Adoption progressive du natif agent

  • Level 1 (développement de base) : accès aux fichiers, exécution des tests, commit Git — permet le Compound Engineering de base
  • Level 2 (tout le local) : accès au navigateur, aux logs locaux, à la création de PR — permet les stages 3 à 4
  • Level 3 (visibilité production) : logs de production (lecture seule), suivi d’erreurs, tableau de bord de monitoring — permet un débogage proactif par l’agent
  • Level 4 (intégration complète) : système de tickets, capacité de déploiement, intégration de services externes — permet le stage 5

• État d’esprit natif agent

  • Lors de la création d’une fonctionnalité : « Comment l’agent va-t-il interagir avec cela ? »
  • Lors du débogage : « Que doit pouvoir voir l’agent ? »
  • Lors de la documentation : « L’agent peut-il comprendre cela ? »

Skip Permissions

• Le flag --dangerously-skip-permissions de Claude Code désactive les demandes d’autorisation à chaque action
• Son nom est volontairement inquiétant pour pousser à réfléchir soigneusement avant de l’utiliser

• Quand l’utiliser

  • Utilisation recommandée : quand un bon système de planification et de revue est en place, quand on travaille dans un environnement sandbox, quand la vitesse est nécessaire
  • Utilisation déconseillée : en phase d’apprentissage (les demandes d’autorisation aident à comprendre), sur du code de production, quand il n’existe pas de mécanisme de rollback

• Mécanismes de sécurité en cas d’omission des permissions

  • Git sert de filet de sécurité : le travail de l’agent est enregistré dans Git et peut être restauré avec git reset --hard HEAD~1
  • Les tests détectent les erreurs : exécutez les tests avant le merge
  • Revue avant merge : on peut ignorer les permissions pendant l’implémentation, mais la revue finale reste obligatoire
  • Isoler le risque avec worktree : expérimentez les tâches risquées dans un répertoire isolé

• Calcul de productivité

  • Sans omission des permissions, un prompt apparaît environ toutes les 30 secondes, et taper « y » à chaque fois fait perdre sa concentration
  • En omettant les permissions, on peut rester en état de flow, obtenir des itérations 5 à 10 fois plus rapides, et gagner bien plus de temps que le risque occasionnel d’un rollback

Workflow de design

• Approche Baby App

  • Créez un projet jetable (baby app) qui permet d’itérer librement sans se soucier des tests, de l’architecture ou des changements cassants
  • Une fois le design satisfaisant, extrayez les couleurs, espacements, typographie et patterns de composants pour les transférer vers le projet principal

• Boucle d’exploration UX

  • Générez plusieurs versions, partagez aux utilisateurs des prototypes fonctionnels cliquables et recueillez leurs retours
  • Contrairement à une maquette Figma, on peut réellement cliquer dessus
  • Les prototypes servent à apprendre, puis on reconstruit proprement depuis zéro avec un plan adapté

• Collaboration avec les designers : flux Compound

  • Flux traditionnel : maquette du designer → interprétation par le développeur → itérations de correction
  • Flux Compound : maquette Figma du designer → transmettre le lien Figma à /plan → implémentation par l’IA → l’agent figma-design-sync vérifie que l’implémentation correspond à la maquette → le designer revoit une version live plutôt qu’une capture d’écran

• Encoder le goût design

  • En travaillant avec le designer sur quelques fonctionnalités, consignez dans un fichier de skills les patterns découverts (couleurs préférées, mise en page des formulaires, etc.)
  • L’IA peut alors produire des designs conformes aux préférences du designer, même sans sa présence

• Agents de design

  • design-iterator : analyse une capture d’écran du design actuel, itère sur les améliorations et affine progressivement le rendu
  • figma-design-sync : importe le design depuis Figma, le compare à l’implémentation et corrige automatiquement les écarts
  • design-implementation-reviewer : vérifie que l’implémentation correspond aux spécifications Figma afin d’attraper les bugs visuels avant qu’ils n’atteignent les utilisateurs

Vibe Coding

• Une approche pour les personnes qui veulent uniquement le résultat, pas le code lui-même : chefs de produit, designers, projets personnels, etc.
• Sautez les étapes de la progression et allez directement au stage 4 : décrire ce que l’on veut → l’agent gère le plan, le code, les tests, la revue et la PR
• Pertinent pour : projets personnels, prototypes, expérimentations, étude de faisabilité, outils internes, exploration UX
• Non pertinent pour : les systèmes de production avec des utilisateurs, le code que d’autres devront maintenir, les applications sensibles à la sécurité, les systèmes critiques pour les performances

• Paradoxe du Vibe Coding

  • Le Vibe Coding peut au contraire améliorer la capacité de planification
  • Quand on ne sait pas encore quoi construire, on crée un prototype, on recueille les retours des utilisateurs, puis on supprime tout et on recommence avec un plan approprié
  • Répartition optimale : découverte avec le vibe coding, construction à partir d’une spec — pour l’implémentation finale, la spec l’emporte toujours

Collaboration d’équipe

• Nouvelles dynamiques d’équipe

  • Traditionnel : la personne A écrit le code → la personne B le relit → discussion des commentaires de PR → merge après approbation
  • Compound : la personne A génère un plan → l’IA implémente → un agent IA effectue la review → la personne B review la review de l’IA → merge après approbation humaine

• Standards d’équipe

  • Approbation du plan : le silence ne vaut pas approbation, donc un sign-off explicite est nécessaire avant l’implémentation
  • Propriété de la PR : indépendamment de qui a écrit le code, la personne qui a démarré le travail possède la PR, et assume la responsabilité de la qualité du plan, de la review, des corrections et de l’impact après le merge
  • Focus de la review humaine : sur une PR déjà analysée par un agent de review IA, l’humain se concentre non pas sur les erreurs de syntaxe, la sécurité, les performances ou le style, mais sur l’intention (intent) — « Est-ce conforme à ce qui a été convenu ? », « L’approche est-elle raisonnable ? », « Y a-t-il des problèmes de logique métier ? »

• Patterns de communication

  • Asynchrone par défaut : pas besoin de réunion pour créer, relire et approuver un plan, « J’ai préparé un document de plan, merci de commenter d’ici aujourd’hui »
  • Handoff explicite : inclut l’état, ce qui a été terminé, ce qu’il reste à faire, le contexte et la manière de continuer

• Patterns de passage à l’échelle

  • Propriété claire + mises à jour asynchrones : pour chaque fonctionnalité majeure, une seule personne est responsable du plan, du suivi, de la review, du merge et des mises à jour à l’équipe
  • Feature flag + petites PR : plus tout le monde déploie vite, plus les conflits de merge augmentent ; il faut donc déployer par petites unités, merger souvent dans la branche principale et résoudre les conflits immédiatement
  • Documentation Compound = connaissance informelle (tribal knowledge) : au lieu de « Demande à Sarah, elle connaît bien l’auth », Sarah exécute /compound pour documenter la solution, qui devient alors recherchable par tout le monde

Recherche utilisateur

• Le fossé entre recherche et développement

  • Traditionnel : le chercheur mène des entretiens → rédige un rapport → le laisse sur Google Drive → les développeurs ne le consultent pas → la fonctionnalité ne reflète pas les besoins des utilisateurs
  • Compound : la recherche produit des insights structurés → ces insights servent de contexte de planification → l’IA s’y réfère lors de la planification → les données d’usage valident ces insights → les insights s’accumulent de façon cumulative

• Structuration de la recherche

  • Transformer les notes brutes d’entretien en Markdown structuré exploitable par l’IA : informations sur les participants, insights clés, citations, implications, niveau de confiance (n/5 participants)

• Documents de persona

  • Créer des documents de persona contenant objectifs, frustrations et citations, afin qu’ils puissent être référencés par l’IA

• Planification basée sur la recherche

  • Lors de l’exécution de /workflows:plan, inclure le contexte de recherche (résultats d’entretiens, patterns de persona, points de douleur actuels) afin que les insights de recherche soient directement reliés aux fonctionnalités

Extraction de patterns à partir des données

• La manière dont les utilisateurs se servent du produit est un indice de ce qu’il faut construire

• Types de patterns à surveiller

  • Patterns de surutilisation : fonctionnalités utilisées bien plus que prévu, visites répétées sur la même page
  • Patterns de difficulté : temps passé anormalement élevé sur une page simple, tentatives répétées de la même action, boucle erreur → nouvelle tentative → erreur
  • Patterns de contournement : export de données depuis un endroit pour les réimporter ailleurs, copier-coller entre écrans, plusieurs onglets ouverts en même temps pour faire des comparaisons
  • Patterns d’abandon : sorties d’un flow, fonctionnalités commencées mais non terminées

• Du pattern à la fonctionnalité

  • Les utilisateurs copient-collent des données entre des tableaux 50 fois par semaine → transformation en fonctionnalité avec un bouton « Synchroniser vers le tableau B »
  • Les utilisateurs créent des projets « template » puis les dupliquent → transformation en fonctionnalité avec une prise en charge native des templates

Copywriting

• Inclure le copy dans le plan

  • La plupart des équipes traitent le copy comme une priorité secondaire, à remplir après la construction de la fonctionnalité, alors qu’il fait partie de l’expérience utilisateur
  • Si le plan inclut dès le départ les textes visibles par l’utilisateur — objet d’e-mail, message de succès, message d’erreur, etc. — alors le copy est déjà prêt au moment de l’implémentation par l’IA

• Encoder la voix

  • Rédiger dans un fichier de skills les principes (parler comme un humain, les messages d’erreur doivent aider, phrases courtes, mots clairs) ainsi que les mots à éviter (Invalid → didn’t work, Error → expliquer ce qui s’est passé, etc.)

• Review du copy

  • Ajouter une review du copy au processus /workflows:review : un agent copy-reviewer l’examine selon 4 critères : clarté, utilité, ton, cohérence

Product marketing

• Flux Compound

  • Un ingénieur crée un plan incluant la proposition de valeur du produit → l’IA implémente la fonctionnalité → l’IA génère les release notes à partir du plan → génère des posts sociaux à partir des release notes → capture automatiquement des captures d’écran avec Playwright → l’ingénieur relit puis publie le tout ensemble
  • Tout circule au même endroit, donc aucun handoff n’est nécessaire et rien ne passe entre les mailles du filet

• Génération des release notes

  • Comme l’IA dispose du plan, des changements de code et des tests, elle peut déterminer précisément ce qui a été construit
  • Mettre en avant les bénéfices utilisateur, inclure un exemple concret, mentionner les breaking changes, rester sous 200 mots

• Génération du changelog

  • La commande /changelog vérifie les merges récents dans la branche principale, lit chaque plan/PR et génère un changelog convaincant

• Captures d’écran automatiques

  • Utiliser Playwright pour capturer automatiquement des captures d’écran marketing, sans avoir à en demander à l’ingénierie, ce qui résout le problème des captures d’écran obsolètes