FOCUSED en action : notre processus de conception de plugins

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.

C - Claim : l'hypothèse plugin

A partir de l'audit, on formule une conviction testable. Pas une vague "on va améliorer la DX". Une affirmation precise : "cette équipe a besoin d'un security hook qui bloque les commits contenant des secrets hardcodes" ou "un agent specialise qui genere les tests d'intégration reduirait de 40% le temps de review". La Claim est spécifique, mesurable, falsifiable. Si on ne peut pas la tester, elle est trop floue.

U - Unfold : les architectures candidates

Maintenant seulement, on explore les solutions. Au pluriel. Le réflexe naturel est de foncer sur la première idée (un skill, parce que c'est simple). FOCUSED obligé a en générer plusieurs : skill vs agent vs MCP server vs hook de sécurité. L'Unfold produit 2 a 4 architectures candidates, chacune avec ses compromis en complexité, maintenance et coût.

S - Steal : réutiliser ce qui marche

Pas besoin de tout réinventer a chaque mission. On maintient une bibliothèque de patterns eprouves : hooks de sécurité, skills de commit, agents de review, intégrations MCP. Le Steal, c'est de l'intelligence appliquee. On identifie ce qui a fonctionne dans des contextes similaires et on l'adapte. C'est aussi la logique qu'on retrouve quand on integre l'IA dans des processus existants : répartir de ce qui marche plutôt que de répartir de zéro.

E - Execute : le prototype en conditions reelles

On construit un prototype fonctionnel. Pas une maquette, pas un slide. Un plugin qui tourne sur le vrai codebase du client. L'exécution en discovery se mesure en jours, pas en semaines. Le prototype répond a une seule question : est-ce que l'équipe comprend, adopté et utilise cette solution au quotidien ?

D - Decide : les metriques de validation

La dernière étape est la décision. Pas au feeling, pas au consensus, mais sur trois metriques concretes : le temps economise par semaine, le nombre d'erreurs detectees avant merge, et le taux d'adoption par l'équipe. Kohavi et Thomke montrent que les organisations les plus performantes testent systématiquement avant de déployer a grande échelle.

Mais attention : FOCUSED n'est pas un tunnel rigide de 6 mois. C'est un cadre itératif adapte a des missions de 2 a 6 semaines. Si le Decide invalide la Claim, on retourne a l'Observe. L'échec d'un cycle est un apprentissage, pas une perte de temps. C'est la même logique que dans le Double Diamond : diverger, converger, recommencer si les données le demandent.