FOCUSED en action : notre processus de conception de plugins
Le framework FOCUSED applique a la conception de plugins Claude Code. 7 etapes concretes, 7 livrables, un processus reproductible pour chaque client.
Concevoir un plugin sans méthode, c'est coder a l'aveugle. Tu ouvres ton éditeur, tu empiles des skills, des hooks, des agents, et trois semaines plus tard le client te dit "ce n'est pas ce qu'on avait en tête". Le problème n'est pas technique. Le problème, c'est l'absence de processus en amont.
Rémi Guyot et Tristan Charvillat ont formalise ce constat dans Discovery Discipline : FOCUSED, un framework en 7 étapes pour transformer l'intuition en preuves avant d'écrire la moindre ligne de code. Kohavi et Thomke le confirment dans HBR : chez Microsoft, seulement un tiers des idées testees ameliorent réellement les metriques visees. Chez PluginFactory, on a adopté ce cadre pour chaque mission client. Voici comment chaque étape se traduit en livrable concret.
Les 7 étapes FOCUSED chez PluginFactory
L'acronyme structure notre service de bout en bout. Chaque lettré est une phase avec un livrable que le client valide avant de passer a la suivante. Pas de zone grise.
F - Frame : le brief client
Tout commence par le cadrage. Quel problème resout le plugin ? Quelle équipe l'utilisera ? Quelles sont les contraintes techniques (stack, CI/CD, accès repo) ? Le Frame produit un document d'une page : le brief de mission. Il aligne tout le monde sur ce qu'on cherche, et surtout ce qu'on ne cherche pas. C'est le même réflexe que quand on construit un bon processus : définir le périmètre avant de plonger.
Ô - Observe : l'audit de codebase
On ne devine pas les besoins. On les observe. L'Observe, chez nous, c'est l'audit technique : lecture du code existant, observation des workflows dev, entretiens avec les developpeurs. Péter Drucker écrit que l'innovation commence par l'analyse des opportunités, pas par l'inspiration. On passe 2 a 3 jours a lire du code et a écouter l'équipe avant de formuler la moindre hypothèse.
Pourquoi un processus change tout
FOCUSED fonctionne pour nous parce qu'il impose une discipline la ou la plupart improvisent. Le client voit chaque livrable. Il valide a chaque étape. Il n'y a pas de surprise a la livraison finale. Le framework est aussi un langage commun entre nous et l'équipe dev : quand on est en phase Observe, personne ne propose de solutions. Quand on est en Unfold, personne ne juge.
Pour une équipe de 2 a 15 devs, FOCUSED s'adapte parfaitement. Les entretiens sont 3 a 5 sessions de 30 minutes. Le prototype est un plugin fonctionnel teste en conditions reelles. Le Decide est une semaine de mesure sur les metriques définies au Frame. Le cadre reste le même, l'échelle s'ajuste.
En resume
- FOCUSED structure notre service en 7 étapes : Frame, Observe, Claim, Unfold, Steal, Execute, Decide.
- Le Frame aligne client et équipe : un brief d'une page avant de toucher au code.
- L'Observe est un audit, pas une devinette : 2-3 jours de lecture de code et d'entretiens.
- Chaque étape a un livrable vérifiable : pas de phase floue, pas de "on verra".
- Le framework est itératif : un Decide négatif renvoie au Claim, pas a la poubelle.
La meilleure façon de livrer le bon plugin, c'est de prouver que le bon problème existe avant d'écrire la première ligne de code.