Commencez par dresser la liste de ce que les utilisateurs s’attendront à pouvoir faire avec votre plugin. Son nom, sa description, ses skills, ses outils et sa connexion à un produit existant contribuent à créer ces attentes. Votre implémentation doit y répondre. Si vous choisissez d’en écarter certaines, vous devez pouvoir expliquer pourquoi.
Cette réflexion vous aide à choisir les éléments à intégrer au plugin :
- Ajoutez une skill lorsque des instructions, des exemples ou des ressources fournies avec le plugin peuvent guider le modèle tout au long du workflow.
- Ajoutez un serveur MCP lorsque le workflow nécessite des données en temps réel, une authentification, des outils dont vous contrôlez l’utilisation ou du code qui s’exécute sur une infrastructure que vous exploitez.
- Ajoutez une interface utilisateur au serveur MCP uniquement si une interaction visuelle améliore nettement une étape du workflow.
Partez des attentes des utilisateurs
Imaginez qu’une personne ait installé votre plugin sans en avoir lu la documentation. Que pourrait-elle raisonnablement lui demander de faire ?
Pour recenser les demandes probables, appuyez-vous sur les éléments suivants :
- Les tâches que les utilisateurs accomplissent déjà avec votre produit ou service.
- Les entretiens avec les utilisateurs, les demandes d’assistance, les requêtes de recherche et les demandes de fonctionnalités.
- Les termes que les utilisateurs emploient couramment pour parler de votre produit, de vos données et de vos workflows.
- Les solutions de contournement qui obligent aujourd’hui les utilisateurs à copier des données d’un outil à l’autre.
- Le nom du plugin, sa fiche de présentation et les exemples de prompts proposés pour démarrer.
Incluez des demandes directes qui mentionnent votre plugin et des demandes indirectes qui expriment l’objectif. Par exemple, un plugin de gestion de projet pourrait devoir répondre aussi bien à « Affiche mon tableau de suivi du lancement d’Acme » qu’à « Qu’est-ce qui bloque le lancement ? ».
Ne limitez pas votre réflexion aux workflows compatibles avec votre API actuelle. Recensez d’abord les attentes des utilisateurs, puis comparez-les à ce que vous pouvez prendre en charge de manière sûre et fiable.
Dressez l’inventaire des cas d’usage
Pour chaque cas d’usage, consignez les éléments suivants :
| Champ | Question à se poser |
|---|---|
| Objectif de l’utilisateur | Que cherche à accomplir la personne ? |
| Exemples de demandes | Comment pourrait-elle formuler sa demande, directement ou indirectement ? |
| Résultat attendu | À quel résultat jugerait-elle l’interaction réussie ? |
| Contexte requis | Quelles informations, quels accès aux comptes ou quel état préalable sont nécessaires ? |
| Fonctionnalité du plugin | Une skill suffit-elle ou faut-il un outil MCP ? |
| Limites de sécurité | L’action pourrait-elle exposer des données, modifier un état, engager des dépenses ou avoir des répercussions sur une autre personne ? |
| Décision de prise en charge | Allez-vous prendre en charge ce cas dès la première version, le reporter ou l’exclure délibérément ? |
Regroupez les demandes qui visent le même objectif. « Liste mes tâches ouvertes », « Que dois-je faire aujourd’hui ? » et « Affiche les tâches en retard » peuvent relever d’un même cas d’usage : consulter ses tâches avec différents filtres. Il est alors inutile d’en faire trois fonctionnalités distinctes.
Vérifiez que le plugin répond aux attentes
Comparez chaque attente aux fonctionnalités prévues pour le plugin :
- Vérifiez que, pour chaque cas d’usage pris en charge, le plugin peut traiter la demande de bout en bout et fournir un résultat utile.
- Repérez les skills, les outils, les données ou les autorisations qui manquent, ainsi que les situations d’erreur que vous n’avez pas prévues.
- Repérez les outils qui donnent accès à des opérations techniques sans permettre à l’utilisateur d’atteindre un objectif identifiable.
- Vérifiez que les actions d’écriture nécessitent les autorisations et les confirmations appropriées.
- Assurez-vous que le plugin peut expliquer ses limites et proposer une suite utile à l’utilisateur.
La présentation du plugin doit refléter la part du workflow attendu qu’il prend réellement en charge. Si les utilisateurs peuvent créer des projets sans pouvoir en afficher la liste, en consulter les détails ou les mettre à jour, ajoutez les fonctionnalités manquantes ou présentez le plugin comme un outil de création de projets.
Documentez les exclusions délibérées
Vous n’avez pas à prendre en charge toutes les demandes imaginables. Chaque exclusion importante doit toutefois avoir une bonne raison, par exemple :
- L’action présenterait un risque inacceptable pour la sécurité ou la confidentialité.
- Le produit ou l’API sous-jacente ne permet pas d’exécuter l’action de manière fiable.
- Le workflow nécessite des autorisations que le plugin ne peut pas vérifier.
- Le résultat serait trompeur sans certaines informations auxquelles le plugin n’a pas accès.
- Le cas d’usage sort du périmètre de la première version, et la fiche de présentation du plugin le précise.
Consignez ces décisions. Appuyez-vous sur elles pour délimiter le rôle des skills, décrire les outils, définir la réponse du plugin en cas de refus, concevoir les cas de test et rédiger la fiche de présentation publique.
Choisissez une implémentation pour chaque cas d’usage
Pour chaque cas d’usage pris en charge, choisissez l’implémentation la plus simple qui permette d’atteindre l’objectif :
- Créez une skill pour fournir des instructions et des ressources réutilisables.
- Créez un serveur MCP pour accéder à des données en temps réel et contrôler l’exécution des actions.
- Ajoutez une interface utilisateur au serveur MCP lorsque les utilisateurs doivent consulter, comparer, modifier ou confirmer des informations structurées, ou naviguer parmi elles.
Utilisez l’inventaire des cas d’usage comme plan de test. Ajoutez des exemples représentatifs de demandes directes et indirectes, ainsi que de cas limites et de demandes hors périmètre. Une fois le plugin terminé, vérifiez qu’il réagit comme prévu à chacun de ces exemples.
Si le plugin a besoin de données en temps réel ou doit contrôler l’exécution d’actions, passez à l’étape suivante : Définissez les outils.