Commencez par lister ce que les utilisateurs s’attendront à pouvoir faire avec votre plugin. Son nom, sa description, ses skills, ses outils et son lien avec un produit existant créent tous des attentes. Votre implémentation doit y répondre, ou vous devez avoir une raison délibérée de ne pas le faire.
Ce travail permet de déterminer les éléments à intégrer au plugin :
- Ajoutez une skill lorsque des instructions, des exemples ou des ressources incluses 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 contrôlés ou du code qui s’exécute sur une infrastructure que vous gérez.
- Ajoutez une interface utilisateur au serveur MCP uniquement si l’interaction visuelle améliore sensiblement une partie du workflow.
Partez des attentes des utilisateurs
Imaginez qu’une personne ait installé votre plugin sans avoir lu sa documentation. Que pourrait-elle raisonnablement lui demander de faire ?
Recensez les demandes probables à partir des éléments suivants :
- Les tâches que les utilisateurs accomplissent déjà dans 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 courants que les utilisateurs emploient pour parler de votre produit, de vos données et de vos workflows.
- Les solutions de contournement existantes qui nécessitent de copier des données d’un outil à l’autre.
- Le nom du plugin, sa fiche de présentation, ses captures d’écran et ses prompts de démarrage.
Incluez des demandes directes qui nomment votre plugin et des demandes indirectes qui expriment l’objectif. Par exemple, un plugin de gestion de projet pourrait devoir traiter aussi bien « Affichez mon tableau de lancement Acme » que « 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. Comparez-les ensuite à ce que vous pouvez prendre en charge de manière sûre et fiable.
Dressez un inventaire des cas d’utilisation
Pour chaque cas d’utilisation, consignez les éléments suivants :
| Champ | Question à laquelle répondre |
|---|---|
| Objectif de l’utilisateur | Que cherche à accomplir la personne ? |
| Exemples de demandes | Comment pourrait-elle formuler sa demande, directement ou indirectement ? |
| Résultat attendu | Qu’est-ce qui ferait de cette interaction une réussite ? |
| Contexte requis | Quelles informations, quels accès aux comptes ou quel état préalable sont nécessaires ? |
| Capacité du plugin | Une skill peut-elle traiter ce cas, ou faut-il un outil MCP ? |
| Limites de sécurité | Ce cas pourrait-il exposer des données, modifier un état, engager des dépenses ou affecter une autre personne ? |
| Décision de prise en charge | Ce cas sera-t-il pris en charge dès la première version, reporté ou volontairement exclu ? |
Regroupez les demandes qui visent le même objectif. « Listez mes tâches ouvertes », « Que dois-je faire aujourd’hui ? » et « Affichez les tâches en retard » peuvent relever d’un même cas d’utilisation de consultation des tâches, avec différents filtres, plutôt que de trois fonctionnalités sans rapport entre elles.
Vérifiez la couverture
Confrontez chaque attente aux capacités prévues du plugin :
- Assurez-vous que chaque cas d’utilisation pris en charge dispose d’un parcours complet, de la demande à un résultat utile.
- Identifiez les skills, les outils, les données et les autorisations qui manquent, ainsi que les états d’erreur non pris en compte.
- Repérez les outils qui donnent accès à des opérations techniques sans permettre d’atteindre un objectif concret pour l’utilisateur.
- Vérifiez que les actions d’écriture prévoient des mécanismes d’autorisation et de confirmation appropriés.
- Vérifiez que le plugin peut expliquer ses limites et proposer une prochaine étape utile.
Un plugin ne doit pas laisser entendre qu’il offre de vastes capacités s’il ne prend en charge qu’une petite partie du workflow attendu. Si les utilisateurs peuvent créer des projets, mais pas les lister, les consulter ou les mettre à jour, ajoutez les fonctionnalités manquantes ou restreignez le positionnement du plugin.
Documentez les exclusions volontaires
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-jacents ne permettent pas de la réaliser de manière fiable.
- Le workflow nécessite des autorisations que le plugin ne peut pas vérifier.
- Le résultat serait trompeur sans des informations auxquelles le plugin n’a pas accès.
- Le cas d’utilisation sort du périmètre de la première version, et la fiche de présentation du plugin l’indique clairement.
Consignez ces décisions. Elles doivent guider la définition du périmètre des skills, la description des outils, le comportement en cas de refus, les cas de test et le texte de la fiche publique du plugin.
Traduisez les cas d’utilisation en choix d’implémentation
Pour chaque cas d’utilisation pris en charge, choisissez l’implémentation minimale qui permet de le traiter de bout en bout :
- 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 exécuter des actions contrôlées.
- Ajoutez une interface utilisateur au serveur MCP lorsque les utilisateurs doivent consulter, comparer, modifier ou confirmer des informations structurées, ou naviguer parmi elles.
Conservez l’inventaire des cas d’utilisation comme plan de test. Ajoutez des demandes représentatives, directes et indirectes, ainsi que des cas limites et des demandes hors périmètre, puis vérifiez que le plugin terminé se comporte comme prévu pour chacune d’elles.
Si le plugin nécessite des données en temps réel ou des actions contrôlées, poursuivez avec Définissez les outils.