REST et CQRS : relier les lectures de l’API aux décisions métier
GET sert souvent les vues de lecture, tandis que les écritures demandent une décision métier. REST et CQRS se combinent sans imposer le même découpage.
Article
Connecter un agent à une API : hypermédia ou MCP ?
Un agent peut suivre les liens et les actions d’une API hypermédia. Voici comment cela fonctionne, ce que MCP apporte et les critères utiles pour choisir.
Un agent doit consulter une commande, vérifier son état puis demander son annulation. Vous pouvez lui proposer un outil nommé « annuler une commande », ou lui laisser découvrir cette action dans la réponse de votre API. Ces deux approches ont des avantages. Si vous disposez déjà d'une API hypermédia, elle mérite d'être évaluée avant de construire une interface supplémentaire.
Partir d'un parcours simple
L'agent ouvre la liste des commandes avec une requête GET. Il suit le lien vers la commande concernée. La réponse contient son état et, si l'annulation est proposée, la description de cette action : destination, méthode et informations à fournir.
C'est le principe de l'hypermédia : les réponses indiquent les étapes possibles. Le client ne doit pas connaître à l'avance toutes les adresses du parcours. Il doit néanmoins comprendre le format des réponses et le sens métier des actions.
Le serveur contrôle les droits et l'état au moment de l'annulation. Une action affichée quelques secondes plus tôt peut être devenue impossible entre-temps. Le client doit donc savoir traiter un refus ou un conflit.
Ce que cette approche peut simplifier
Une API déjà utilisée par une interface humaine peut exposer les mêmes ressources à un agent, dans une représentation adaptée. Cela évite parfois de maintenir un catalogue d'outils supplémentaire. Les liens et les formulaires décrivent alors les possibilités au fil du parcours.
Les modèles connaissent généralement HTTP, les liens et les formulaires. Cette familiarité peut faciliter leur utilisation, mais elle ne prouve pas qu'un agent réussira mieux par cette voie. Cet article défend un choix d'architecture ; il ne présente pas de comparaison expérimentale établissant la supériorité de l'hypermédia sur MCP.
Le contexte chargé par l'agent dépend de ce qu'il consulte réellement. Cela peut être plus léger qu'un grand catalogue transmis dès le départ. Les réponses volumineuses et les allers-retours ont aussi un coût : il faut le mesurer sur un parcours complet.
MCP fournit un contrat commun aux outils
MCP, pour Model Context Protocol, permet à un client de découvrir et d'utiliser les capacités de différents serveurs selon un protocole commun. Il décrit notamment des outils, des ressources et des modèles de prompts.
Un outil présente une action nommée et un schéma d'entrée. Cette forme peut rendre une opération métier facile à appeler, même si les systèmes sous-jacents sont très différents. Pour intégrer plusieurs services tiers, cette homogénéité est utile.
MCP n'oblige pas à charger toutes les descriptions dans le contexte du modèle. La découverte progressive et l'appel par du code peuvent limiter ce volume. L'approche décrite par Anthropic utilise justement du code avec des serveurs MCP : les deux ne s'excluent pas.
La différence à examiner est donc concrète : que voit l'agent à chaque étape, quelles informations doit-il apprendre et combien d'interfaces l'équipe doit-elle entretenir ?
Les droits dépendent du serveur, quel que soit le protocole
Un catalogue d'outils explicite aide à comprendre ce qui est proposé. Une réponse hypermédia aide à découvrir les actions liées à une ressource. Dans les deux cas, les autorisations doivent être vérifiées lors de l'exécution.
Il faut distinguer l'audience d'un jeton, le service auquel il est destiné, de sa portée, les opérations qu'il autorise. Restreindre l'audience limite où un jeton peut être accepté ; cela ne réduit pas automatiquement ses pouvoirs dans ce service.
Je privilégie des droits délégués limités à la tâche. La journalisation doit identifier l'utilisateur, l'agent et les opérations réalisées. Cette traçabilité se construit explicitement : elle n'est pas une garantie de REST.
Le budget nécessite lui aussi ses propres limites : nombre d'appels, durée, volume ou montant maximal. Un agent peut dépenser beaucoup en répétant une action parfaitement autorisée.
Choisir selon le système que vous avez déjà
| Situation | Piste à évaluer |
|---|---|
| Une API hypermédia existe et vous la maîtrisez | Tester son utilisation directe sur un parcours représentatif. |
| Plusieurs fournisseurs exposent des serveurs MCP | Utiliser ce contrat commun pour simplifier leur intégration. |
| Le travail porte sur des fichiers ou du code local | Comparer les outils disponibles avec un environnement de commandes correctement isolé. |
| Quelques actions sensibles doivent être très encadrées | Proposer une interface étroite, avec des contrôles d'autorisation et, si nécessaire, une validation humaine. |
Pour départager les solutions, faites exécuter la même tâche : trouver une commande, vérifier qu'elle est annulable, l'annuler et confirmer le résultat. Comparez les erreurs, le coût, la lisibilité des traces et le travail de maintenance. Une interface que l'équipe comprend et surveille correctement compte davantage que son étiquette.
Sources
Explorer
Sur le même sujet
Choisis dans l’index d’après les étiquettes de cet article — les plus proches d’abord, hors de sa série. Rien n’est écrit à la main : un article publié demain avec les mêmes étiquettes y prendra place.
Outiller un agent IA : quand lui faire écrire du code
Un agent combine des appels d’API dans un script au lieu de multiplier les échanges avec le modèle. Bénéfices, limites et place de MCP dans cette approche.
Agent IA et API : éviter d’écraser une modification concurrente
Un agent peut écrire à partir d’une ancienne version. Une précondition vérifiée par le serveur permet de détecter le conflit et de reprendre sur un état relu.
Laisser un commentaire
Votre commentaire sera relu avant d'être publié.