Le Double Diamond applique a la conception de plugins

La plupart des projets de plugins echouent parce qu'on a resolu le mauvais problème. Un CTO demande un plugin de review de code. On le construit. Trois semaines plus tard, personne ne l'utilise. Le vrai problème n'était pas la review. C'était le manque de contexte partage entre les devs au moment de pousser du code.

MIT Sloan estime que le taux d'échec des nouveaux produits se situe entre 30 et 80% selon la maturité de l'entreprise. La cause principale ? L'absence de validation du problème avant la construction. Chez PluginFactory, on utilise le Double Diamond pour éviter ce piège. Et le framework se mappe parfaitement sur notre workflow de conception de plugins.

Deux diamants, un service

Le Design Council UK a formalise le Double Diamond en 2005. Le principe : deux phases de divergence (explorer large) suivies de deux phases de convergence (focaliser). Le premier diamant trouve le bon problème. Le second trouve la bonne solution.

Chez PluginFactory, le premier diamant correspond a notre phase d'audit et de discovery call. Le second correspond a la conception et au déploiement. On ne code pas un plugin avant d'avoir traverse les deux diamants. C'est plus lent au départ. Mais ça evite de jeter trois semaines de travail parce qu'on a mal compris le besoin.

Diamant 1 : trouver le bon problème

Découvrir (diverger) : l'audit codebase

La première phase est une exploration délibérément large. On audite le codebase du client, on observe les workflows existants, on fait des entretiens avec les devs. Pas pour confirmer l'hypothèse du CTO, mais pour la remettre en question.

Péter Drucker écrit dans HBR que l'innovation systématique commence par l'analyse des sources d'opportunités, pas par l'inspiration. En pratique, ça veut dire : observer comment l'équipe travaille réellement, pas comment elle dit travailler. On cherche les frictions invisibles, les étapes manuelles repetitives, les connaissances tacites qui vivent dans la tête d'un seul dev.

C'est la même logique que documenter ses processus : rendre visible ce qui est implicite. Sauf qu'ici, on documente pour comprendre, pas encore pour résoudre.

Définir (converger) : formuler l'hypothèse plugin

On a explore. Maintenant on choisit. Quel est le problème spécifique que le plugin doit résoudre ? Pour qui ? Dans quel contexte ?

Cette phase produit un énoncé de problème précis : "Les devs backend perdent 45 minutes par PR a vérifier manuellement la cohérence des schemas API parce que la validation n'est pas intégrée au workflow Claude Code." C'est spécifique, mesurable, et vérifiable.

Si on ne peut pas formuler le problème en une phrasé, on n'a pas fini le premier diamant. On retourne en phase de découverte. Ce n'est pas un échec. C'est le processus.

Diamant 2 : trouver la bonne solution

Développer (diverger) : explorer les architectures

Le problème est clair. On genere des solutions. Au pluriel. Un skill unique qui couvre tout le workflow ? Plusieurs hooks specialises ? Une intégration MCP avec un outil externe ? Un agent personnalise qui orchestre le tout ?

Cagan insiste : le prototype de discovery n'est pas le produit. C'est un outil jetable pour apprendre vite. Chez PluginFactory, ça se traduit par des skills minimaux qu'on teste avec l'équipe du client pendant une semaine. Pas de déploiement complet. Juste assez pour valider l'approche.

La solution n'est pas forcément du code complexe. Parfois, un simple hook de pre-commit qui verifie un format resout 80% du problème. Le même principe que construire un bon processus : la meilleure solution est souvent la plus simple.

Délivrer (converger) : valider avec l'équipe

On teste les prototypes avec les vrais utilisateurs, les devs qui vont utiliser le plugin au quotidien. Pas le CTO qui a passe la commande. Les personnes qui vivent le problème.

Le test répond a trois questions. Est-ce que ça resout la friction identifiee ? (Désirabilité.) Est-ce que ça s'integre dans le workflow existant sans le casser ? (Faisabilité.) Est-ce que le gain de temps justifie la maintenance du plugin ? (Viabilité.) Si les trois réponses sont positives, on passe au déploiement complet. Sinon, on retourne en phase de développement ou on reformule le problème.

Cette validation terrain distingue un plugin qui sera adopté d'un plugin qui sera ignore. Et c'est ce qui transforme un outil technique en intégration IA réellement utile.