Le développement logiciel classique pense d’abord en termes d’interfaces : liste de clients, page de projet, bouton d’upload, formulaire de facture, vue calendrier. Pour les humains, c’est logique. Pour les agents IA, les automatisations et les systèmes externes, c’est le mauvais modèle d’abstraction.
Un agent ne devrait pas avoir à savoir sur quelle page se trouve un bouton.
Ce dont un agent a vraiment besoin
Un agent ne navigue pas dans des interfaces. Il appelle des capacités. Les questions pertinentes sont :
- Quelles actions existent ?
- Quelles entrées attend une action, quelles sorties produit-elle ?
- Quels droits sont nécessaires ?
- Quelle action est risquée ou irréversible ?
- Quand faut-il interroger l’utilisateur ?
- Qu’est-ce qui est audité ?
Les logiciels UI-first ne répondent à aucune de ces questions. Les logiciels MCP-first y répondent toutes.
Klassisch
- Webapp
- Mobile App
- Admin UI
- API
- Automation
- AI-Integration
MCP-first
- Domain Model
- Action Layer
- Permission Layer
- MCP Tools
- MCP Resources
- MCP Workflows
- Audit Layer
- Webapp · Mobile · Admin · API · Automation
Thèse 1 : Les agents IA n’utilisent pas les logiciels comme les humains
Les humains cliquent, font défiler, lisent et interprètent. Les agents ont besoin de capacités structurées pouvant être appelées directement et en toute sécurité.
La deuxième voie est déterministe, typée, vérifiée par les permissions et auditable. La première produit une automatisation de navigateur fragile qui se brise à chaque mise à jour de l’UI.
-
schedule_follow_up(contactId, projectId, datetime, note) -
contacts.search(query, tenantId) -
reminders.create(contactId, datetime, note, assignedTo) -
calendar.find_free_slot(participantIds, duration, after)
Thèse 2 : L’interface utilisateur devient l’un des nombreux clients
Dans le passé, l’UI était le principal point d’accès au logiciel. À l’avenir, il y aura plusieurs points d’accès équivalents qui accèdent tous à la même couche de capacités :
- Humain via webapp
- Humain via application mobile
- Agent IA via MCP
- Automatisation via worker
- Tiers via API
- Systèmes internes via événements
- CLI via couche d’actions
Qui construit la webapp d’abord et rattrape le reste construit la même couche d’actions plusieurs fois, chaque fois légèrement différente, chaque fois avec sa propre logique de droits.
Thèse 3 : Les logiciels sans capacité agentique deviennent difficiles à intégrer
Quand un logiciel ne fonctionne que via des interfaces, des solutions de contournement fragiles apparaissent inévitablement :
- Automatisation de navigateur et screen scraping
- Imports CSV et processus manuels de copier-coller
- Workflows semi-automatiques
- Solutions spécifiques par client ou projet d’intégration
Ces contournements se cassent lors des changements d’UI, ne passent pas à l’échelle et ne peuvent pas être audités. MCP-first supprime la raison de leur existence en rendant le système structurellement contrôlable dès le départ.
Thèse 4 : La meilleure interface pour de nombreuses tâches est l’absence d’interface
De nombreuses tâches sont dialogiques, contextuelles et basées sur des workflows, elles n’ont plus besoin de page :
« Crée un résumé de toutes les transactions ouvertes. » « Quels clients devrais-je contacter aujourd’hui ? » « Vérifie si des documents manquent pour cet employé. » « Crée un rapport sur tous les projets à risque. » « Compare les deux dernières exécutions de paie. »
Pour ces tâches, un agent conversationnel avec accès à une couche de capacités est plus efficace que n’importe quelle page avec filtres et tableaux. La condition préalable : les capacités sont proprement modélisées, typées et dotées de niveaux de risque.
Low Générer un résumé, Medium Créer un document, Critical Export de paie, le système doit connaître ces différences.
Thèse 5 : MCP-first réduit le développement en double
Quand une fonctionnalité est d’abord construite comme une action, chaque client peut utiliser la même action, sans double implémentation :
create_project(name, templateId, ownerId, tenantId)Cette seule action est utilisable par :
- Webapp
- Application mobile
- Interface admin
- Agent MCP
- CLI
- Worker
- Processus d’import
- Intégration
- Suite de tests
Cela réduit non seulement l’effort, cela élimine les incohérences entre les clients qui s’accumulent autrement avec le temps.
Thèse 6 : MCP-first impose une meilleure architecture
Qui construit MCP-first doit automatiquement modéliser plus proprement. Chaque capacité nécessite :
- des domain-actions claires avec une intention utilisateur non ambiguë
- des schémas d’entrée et de sortie typés
- des droits et une gestion des erreurs clairs
- des effets secondaires définis
- des audit events et des niveaux de protection
Cela oblige à attribuer clairement les responsabilités métier avant qu’une seule ligne de code UI soit écrite.
-
Input Schema, typé, validé -
Output Schema, déterministe -
Permission Scopes, quel rôle peut appeler -
Risk Level, low / medium / high / critical / forbidden -
Side Effects, effet externe, oui ou non -
Audit Event, ce qui est journalisé -
Confirmation Policy, autonome ou approbation humaine
API-first était pour les développeurs. MCP-first est pour les agents.
Les logiciels construits d’abord comme un système de capacités entièrement décrit, vérifié par les permissions et audité sont simultanément meilleurs pour les humains, meilleurs pour les agents et meilleurs pour tout ce qui se trouve entre les deux.