MCP-first n’est pas le battage médiatique autour d’un nouveau protocole. C’est un changement d’architecture. Les logiciels modernes ne sont plus d’abord conçus comme des webapps, mais comme un système de capacités entièrement contrôlable, lisible par les machines et sécurisé. La webapp, l’application mobile, le CLI et les interfaces d’administration ne sont ensuite que des interfaces secondaires sur le même cœur.
Un écran n’est qu’une interface. Le véritable logiciel, c’est sa capacité.
1 · Capacités plutôt qu’interfaces
Une fonctionnalité n’est pas une page. Une fonctionnalité est une capacité. Qui décrit d’abord la capacité peut l’offrir partout, dans l’UI, dans l’agent, dans le worker.
2 · Outils plutôt que boutons
Un bouton n’est que la représentation humaine d’un outil. L’outil, typé, vérifié par les permissions, audité, est l’essentiel.
3 · Ressources plutôt que tableaux
Un tableau n’est qu’une représentation visuelle d’une ressource. Les agents ont besoin de la ressource avec son contexte, pas du tableau rendu.
4 · Workflows plutôt que navigation
Les agents n’ont pas besoin de navigation. Ils ont besoin de workflows clairs qui guident à travers des processus complexes.
5 · Policies plutôt que confiance
6 · Confirmation plutôt qu’automatisme aveugle
Les actions risquées nécessitent le consentement humain. MCP-first signifie entièrement contrôlable, pas entièrement automatique.
7 · Audit plutôt qu’opacité
Chaque action d’un agent doit être traçable : qui, quoi, quand, avec quelle approbation.
8 · Contexte plutôt que données brutes
Les agents ont besoin d’un contexte pertinent et préparé, pas de bases de données complètes. La rédaction et le filtrage de contexte sont obligatoires.
9 · Interface humaine comme client
La webapp et l’application mobile sont des clients, pas le cœur. Ils appellent les mêmes actions que l’agent.
10 · 100 % contrôlable, pas 100 % autonome
Tout doit être contrôlable. Tout ne peut pas se produire de manière autonome.
Si ton logiciel peut le faire, MCP doit pouvoir le décrire. Si un agent peut l’appeler, la Policy doit pouvoir le contrôler.
Exemples de skills
Les principes ne sont pas une fin en soi. Ils se manifestent mieux là où les agents gèrent eux-mêmes le serveur MCP, le créer, le piloter et l’auditer. Ces skills sont des workflows encapsulés qui respectent exactement les mêmes règles qu’ils appliquent : chaque étape risquée porte un niveau de risque, les étapes critiques sont soumises à une approbation, et chaque action est auditée.
mcp.scaffold_server Bootstrap un serveur MCP orienté capacités : les domain-actions d'abord, les schémas typés, le moteur de politique, les métadonnées de risque et l'audit, avant qu'une interface soit créée.
trigger "Crée un serveur MCP pour …" Créer
Ablauf
- Modéliser les domain-actions, la logique métier reste dans le domaine. Low
- Générer des schémas d'entrée, de sortie et d'erreur typés. Low
- Assigner un niveau de risque et une politique de confirmation à chaque outil. Medium
- Générer le serveur comme adaptateur : découverte, vérifications de politique, audit. High
- Enregistrer les outils critiques uniquement après approbation explicite. Critical ⏸ Freigabe
mcp.audit_trail Revue en lecture seule : lit la piste d'audit et la couverture des risques, parcourt la liste de contrôle et signale les lacunes. Ne modifie rien.
trigger "Vérifie le serveur MCP contre MCP-first" Auditer
Ablauf
- Lire l'inventaire des capacités et les niveaux de risque. Low
- Vérifier l'exhaustivité des audit-events et la rédaction. Low
- Marquer les outils sans classification de risque. Low
- Produire les résultats sous forme de rapport structuré, aucune action d'écriture. Low
D’autres exemples, ajouter une capacité, contrôler la visibilité des outils, connecter des clients, renforcer la sécurité, sur la page Exemples de skills.
L’avenir appartient aux logiciels qui ne sont pas seulement utilisables, mais sûrement contrôlables.