Le MCP est-il mort ?

(quandri.io)

1 points par GN⁺ 5 시간 전 | 2 commentaires | Partager sur WhatsApp

MCP connecte les LLM à des outils externes, mais dans les workflows de développement, le coût de contexte, la stabilité opérationnelle et le chevauchement avec les CLI/API se révèlent être de lourdes contraintes
Selon les mesures de Quandri, les 77 définitions d’outils pour Linear, Notion, Slack et Postgres représentent environ 21 077 tokens, soit 10,5 % du contexte 200K de Claude
Pour consulter une issue Linear, l’approche MCP consomme environ 12 957 tokens, bien plus que l’approche CLI, qui n’en utilise qu’environ 200, car les 42 définitions d’outils sont toujours chargées
MCP implique un processus serveur séparé ainsi que de l’authentification, de l’initialisation, des conflits et de la latence due aux allers-retours externes, tandis que les CLI/API sont plus faciles à reproduire, déboguer et composer dans le terminal
Quandri a encapsulé ses CLI existantes dans des Skills, récupérant ainsi environ 21K tokens, et n’utilise MCP que lorsqu’il n’existe pas de CLI ou lorsqu’un contrôle des permissions à l’échelle de l’équipe est nécessaire

Les coûts clés mis en évidence par MCP

MCP (Model Context Protocol) connecte les LLM à des outils externes comme GitHub, Linear, Notion ou Slack, mais dans les workflows réels de développement, l’usage du contexte, la stabilité opérationnelle et le chevauchement avec les CLI/API existantes deviennent des problèmes majeurs
Depuis son lancement fin 2024, il a été présenté comme « l’USB-C de l’écosystème IA », mais pour les développeurs qui l’utilisent au quotidien, d’autres coûts apparaissent d’abord
Depuis cette mesure, Claude Code a introduit Tool Search with Deferred Loading, qui charge les schémas d’outils MCP uniquement au moment nécessaire et réduit l’usage du contexte de plus de 85 %
Dans Claude Code aujourd’hui, le problème d’explosion du contexte a été largement atténué, mais des problèmes de performance, de débogage et d’architecture subsistent

Une forte consommation de la fenêtre de contexte

La fenêtre de contexte est l’espace qu’un LLM utilise pour travailler, et lorsqu’un serveur MCP est connecté, une grande partie peut être occupée uniquement par les définitions d’outils, sans rapport avec la tâche réelle
En extrayant et en mesurant les véritables définitions d’outils des serveurs MCP connectés dans l’environnement Quandri, on constate qu’avec les 4 serveurs activés, 10,5 % de la fenêtre de contexte est consommée par les seules définitions d’outils
Taille des définitions d’outils :
- Linear : 42 outils, environ 51 229 caractères, environ 12 807 tokens
- Notion : 14 outils, environ 16 156 caractères, environ 4 039 tokens
- Slack : 12 outils, environ 15 168 caractères, environ 3 792 tokens
- Postgres : 9 outils, environ 1 755 caractères, environ 438 tokens
- Total : 77 outils, environ 84 308 caractères, environ 21 077 tokens
Consommation de contexte selon le modèle :
- Dans le contexte 200K de Claude, les définitions d’outils occupent 10,5 %
- Dans le contexte 128K de GPT-4o, les définitions d’outils occupent 16,5 %
Même Linear seul charge en permanence 42 définitions d’outils, soit plus de 12 800 tokens, et même lorsqu’on n’utilise que get_issue et save_issue, l’ensemble des définitions est embarqué
Exemples de définitions d’outils volumineuses :
- linear/save_issue : 2 479 caractères, environ 619 tokens
- slack/search_public : 1 614 caractères, environ 403 tokens
- linear/list_issues : 1 588 caractères, environ 397 tokens
- notion/fetch : 1 379 caractères, environ 344 tokens
- slack/send_message : 1 248 caractères, environ 312 tokens

Charge sur la stabilité opérationnelle et les performances

MCP oblige à démarrer et maintenir un processus séparé, ce qui peut entraîner des échecs d’initialisation et des problèmes d’authentification récurrents
Chaque appel d’outil nécessite un aller-retour vers un serveur externe, ce qui ralentit la vitesse de réponse de l’IA
Si le processus serveur MCP plante, les outils peuvent disparaître en plein milieu d’une session
Il est difficile de savoir précisément quelles permissions possède réellement chaque outil, ce qui réduit la visibilité sur les autorisations
Dans le benchmark Jira MCP de MCP is dead. Long live the CLI, MCP était 3 fois plus lent par appel qu’un appel direct à l’API REST, et le premier appel, initialisation comprise, était 9,4 fois plus lent
Cet écart de performance n’est pas propre à Jira : il découle de l’ajout d’une couche de processus MCP entre le LLM et l’API sous-jacente
Le même surcoût s’applique aussi aux serveurs Linear, Notion et Slack de la pile Quandri

Un chevauchement avec les CLI/API existantes

Les CLI/API permettent aux humains et aux LLM d’utiliser les mêmes commandes, alors que MCP n’existe qu’à l’intérieur de la conversation avec le LLM
Les CLI/API peuvent être librement combinées avec des pipes, jq, grep, etc., tandis que MCP reste lié au format renvoyé par le serveur
Les CLI/API sont immédiatement reproductibles et débogables dans le terminal, alors que MCP ne peut être reproduit que dans le contexte de la conversation
Les LLM ont déjà appris l’usage des CLI/API via les man pages et StackOverflow, tandis que MCP nécessite des définitions d’outils spécifiques
Les CLI/API sont pour la plupart déjà installées, alors que MCP exige en plus une configuration serveur, de l’authentification et de la gestion de processus

Le coût en tokens pour consulter une issue Linear

Pour consulter la même issue Linear, l’approche MCP consomme environ 65 fois plus de tokens que l’approche CLI
L’approche CLI utilise environ 200 tokens :
- prompt de commande curl : environ 50 tokens
- réponse : environ 150 tokens
L’approche MCP utilise environ 12 957 tokens :
- 42 définitions d’outils Linear toujours chargées : environ 12 807 tokens
- appel d’outil et réponse : environ 150 tokens
L’exemple CLI appelle directement l’API GraphQL de Linear :

curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \  
  -H "Content-Type: application/json" \  
  -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \  
  https://api.linear.app/graphql

Alternative : stratégie CLI d’abord et Skills

Une approche fournie dans l’ordre CLI → API → documentation est plus légère et plus directe
Les LLM ayant déjà appris l’usage des CLI via les man pages et StackOverflow, il n’est pas nécessaire d’embarquer en permanence des définitions d’outils distinctes
En utilisant directement les CLI existantes, on évite de gaspiller du contexte avec des définitions d’outils, et comme humains et IA utilisent la même interface, le débogage est plus simple
Les pipelines permettent une composition libre avec d’autres commandes
Si MCP consiste à « étaler tous les menus sur la table à l’avance », les Skills ressemblent davantage à « demander au bibliothécaire uniquement le livre nécessaire »
MCP charge toutes les définitions d’outils à la connexion et occupe donc toujours du contexte, alors que les Skills ne sont chargées qu’au besoin et n’occupent du contexte que lorsqu’elles sont utilisées
Plus il y a de serveurs, plus la pression de MCP sur le contexte augmente, tandis que les Skills n’occupent pas en permanence le contexte proportionnellement à leur nombre
L’idée clé consiste à mettre les instructions d’usage de la CLI dans des Skills, ce qui est le plus efficace lorsqu’on le combine avec une stratégie CLI-first
Exemple de Skill Linear, contenant uniquement l’URL de l’API, le mode d’authentification, une commande curl pour récupérer une issue, la méthode de recherche GraphQL et l’indication de parser le JSON avec jq :

# Linear Issue Lookup Skill  
- Linear API: https://api.linear.app/graphql  
- Auth: Bearer Token ($LINEAR_TOKEN env var)  
- Get issue: curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql  
- Search issues (GraphQL): adjust the query field for JQL-like filtering  
- Results are JSON, parse with jq

Avec cette approche, le LLM ne charge ce contenu dans le contexte qu’au moment d’appeler la Skill correspondante
Il n’est plus nécessaire de transporter en permanence les 42 définitions d’outils Linear ; seules les commandes CLI utiles sont chargées

Les cas où MCP reste pertinent

Lorsqu’un service n’a pas de CLI, MCP peut être le seul moyen de connexion
Pour des utilisateurs non développeurs qui n’utilisent pas le terminal, MCP peut être plus accessible
Pour une communication bidirectionnelle en temps réel qui dépasse un simple schéma requête-réponse, MCP peut être approprié

Critères de choix pour l’accès aux bases de données

L’accès à une base de données revient fondamentalement à exécuter des requêtes, et les LLM maîtrisent déjà bien SQL et les requêtes MongoDB
Si l’on place dans une Skill les informations sur la base et l’usage de la CLI, et qu’on fournit le schéma, le LLM peut écrire des requêtes sans MCP
Exemple de Skill Postgres, contenant uniquement l’hôte, le schéma des tables et l’usage de la CLI psql :

# Postgres Skill  
- Host: postgres://localhost:5432/myapp  
- Tables: users (id, name, email), orders (id, user_id, status)  
- CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..."

MCP présente aussi des avantages pour les bases de données :
- Sécurité des requêtes : le serveur MCP peut imposer un mode lecture seule et bloquer les requêtes dangereuses au niveau serveur
- Protection des identifiants : avec une approche CLI, la chaîne de connexion peut apparaître dans le prompt, tandis qu’un serveur MCP gère les identifiants en interne
Pour le développement local ou une base personnelle, Skills + CLI sont plus légers, plus rapides et facilitent la récupération après erreur
Pour une base de production ou un environnement d’équipe partagé, MCP est plus adapté, car des garde-fous comme la validation des requêtes et le contrôle d’accès au niveau serveur sont importants
Dans la plupart des workflows de développement, MCP a toutefois tendance à relever de la sur-ingénierie

La manière dont Quandri l’utilise

Quandri combine Bash + CLI, Skills et MCP selon le service concerné
Pour les outils utilisés tous les jours comme gh, psql ou aws, l’entreprise utilise Bash + CLI :
- aucun coût de contexte
- grande flexibilité
- débogage immédiat dans le terminal
Pour les workflows répétitifs en plusieurs étapes, comme la rédaction de commits ou la revue de PR, elle utilise des Skills :
- chargées uniquement lorsqu’elles sont appelées
Pour des services sans CLI solide comme Slack, Linear ou Notion, elle utilise MCP
Elle utilise aussi MCP lorsque l’authentification à l’échelle d’une équipe ou la définition fine des permissions est importante, comme pour l’accès aux bases de production
Lorsqu’une CLI existe déjà et qu’une authentification locale est possible, c’est généralement l’option la plus légère
Lorsqu’un service n’a pas de CLI ou qu’une authentification cohérente pour toute l’équipe est nécessaire, MCP apporte de la valeur

Conclusion et méthode de mesure

Mieux vaut bien enseigner que tout connecter
Chez Quandri, remplacer les serveurs MCP par des Skills encapsulant les CLI existantes a permis de récupérer environ 21K tokens de contexte
Dans les workflows quotidiens, les échecs d’initialisation ont disparu et le débogage reste dans le terminal
Charger uniquement les outils nécessaires, au bon moment, avec des instructions CLI, est plus efficace
MCP pourra peut-être évoluer pour résoudre ces problèmes à l’avenir, mais à ce jour, les Skills constituent un meilleur choix
Méthode de mesure :
- extraction du schéma JSON de chaque outil des serveurs MCP réellement chargés dans l’environnement Claude Code
- mesure de la taille à partir du nom de l’outil, de sa description et de ses paramètres
- estimation des tokens avec l’heuristique d’environ 1 token pour 4 caractères
- extrapolation de l’estimation serveur complète à partir de la moyenne d’un échantillon d’outils

Vous voulez continuer à recevoir des sujets tech sélectionnés ? Suivez le canal Telegram. @GeekNewsFR

2 commentaires

aer0700 3 시간 전

Je pense qu’il suffit simplement de choisir la technologie qui correspond à sa propre situation. Dire que c’est mort me paraît exagéré, vu que c’est déjà largement utilisé.

GN⁺ 5 시간 전

Avis sur Hacker News

Je dirige chez OpenAI l’équipe en charge de ChatGPT App Store, des plugins Codex et de l’ensemble de MCP, et ce que ratent les billets affirmant que « MCP est mort », c’est que le fait que MCP soit utilisé comme protocole de transport n’a pratiquement aucune importance
Si MCP n’est pas mort, c’est parce que presque toutes les entreprises sur Terre construisent des serveurs MCP, et nous le savons parce que nous sommes en contact direct avec elles
Beaucoup de ces entreprises n’ont pas de CLI, et parfois même pas d’API externe, mais elles construisent quand même des serveurs MCP
En interne, on pourrait convertir tous les serveurs MCP en CLI, utiliser le mode code ou implémenter la découverte d’outils, mais ce ne sont que des détails d’implémentation, et l’essentiel est que les agents IA accèdent à des services auxquels ils n’auraient autrement pas accès
On peut débattre du fait que MCP soit mort ou non comme couche de communication avec laquelle le modèle dialogue directement, mais dire que MCP est mort en tant que protocole est totalement faux
Cet argument est moins solide qu’avant à cause des fonctions d’usage de l’ordinateur/du navigateur dans l’app Codex, et si vous ne les avez pas encore essayées, c’est vraiment bluffant
- Je pense qu’il est fort probable que MCP meure
  La raison principale, c’est que quelle que soit l’implémentation réelle — API, web ou CLI — on ajoute par-dessus une couche supplémentaire et une personne de plus qui peuvent se désynchroniser
  L’IA ne devrait pas utiliser un protocole ou un ensemble d’instructions différent de ce à quoi les humains accèdent, qu’ils comprennent et utilisent
  En ce moment, les entreprises veulent exposer des serveurs MCP parce que c’est la mode, mais dans la réalité on voit surtout Claude construire des serveurs MCP au-dessus d’API existantes, puis on lui redemande parfois de les mettre à jour pour coller à la documentation publique
  Comme la documentation d’API est déjà publique, et que Claude Code a lui aussi construit le serveur MCP uniquement en lisant la documentation publique sur Internet, MCP donne aujourd’hui l’impression d’un contournement temporaire des limites actuelles des modèles
- MCP est au fond plus proche d’un nom de marque pour une « API utilisable par des grands modèles de langage »
  Résultat, même des entreprises peu orientées technique créent des API pour que leurs outils n’aient pas l’air dépassés à l’ère des agents
  Je suis d’accord avec l’objectif en lui-même, mais c’est autre chose de savoir si je choisirais ce protocole pour y arriver, et quoi qu’il en soit c’est devenu un protocole dont les gens ont entendu parler et qu’ils utilisent réellement
- Dire que « presque toutes les entreprises sur Terre construisent des serveurs MCP » sonne justement comme une chambre d’écho
- MCP consomme toujours une précieuse fenêtre de contexte tout en résolvant en pratique un problème qui n’existe pas
  Dire que sans MCP un agent ne peut pas accéder à un service est, au mieux, trompeur, et comme l’article le dit, l’accès est déjà possible via les seuls outils en ligne de commande et leurs entrées/sorties
  Même d’un point de vue purement technique, MCP offre une composabilité inférieure à celle des outils en ligne de commande, et je pense que ceux qui n’accordent pas d’importance à cette composabilité finiront par en payer le prix
  Pour le dire franchement, il y a un biais lié à l’investissement, et le fait qu’on vende du MCP à de nombreuses entreprises ne suffit pas à réfuter ce biais
  Il suffit de regarder Microsoft pour voir que la profondeur avec laquelle l’utilité et la technique sont enfouies n’a pas grand-chose à voir, et certains pensent même que c’est l’inverse
  Je soupçonne aussi que si OpenAI pousse autant MCP aujourd’hui, c’est en grande partie pour des raisons organisationnelles, ce qui peut être difficile à voir de l’intérieur
- Le fait d’entendre que du MCP est construit là où il n’y a pas de CLI est assez inquiétant
  Il y a une différence entre dupliquer des fonctions CLI existantes pour une meilleure intégration avec les agents, et en faire l’interface unique qui enferme tout le monde dans une spécification dont on pourra plus tard juger qu’une autre était meilleure
  Dans ce cas, il faudra ensuite rembourser la dette MCP, et au final il se peut que ne rien faire coûte moins cher
On a l’impression que cet article a été écrit par une IA
MCP est fondamentalement assez proche de JSON-RPC, avec quelques champs spéciaux à inclure
On peut avoir des inquiétudes sur JSON-RPC, mais il faut bien une couche de découverte de services avec laquelle les grands modèles de langage puissent s’intégrer
Cela doit fonctionner à plusieurs endroits — sites web, applications desktop, services backend — et la CLI n’est qu’un des points de rencontre avec ce type de systèmes
Quoi qu’on utilise à la place de MCP, même en définissant autrement le protocole de communication ou les champs de découverte d’outils, cela aura probablement une forme similaire
- Chaque fois que je lis un article sur MCP, j’ai l’impression qu’Internet ou tout HN fait une crise collective
  On dit que les API sont meilleures que MCP, mais MCP n’est en fait qu’une API avec quelques indications supplémentaires pour qu’une IA puisse découvrir comment l’utiliser
  On propose aussi d’utiliser une CLI, mais je ne vois pas exactement ce que cela veut dire
  Si les grands modèles de langage utilisent bien des outils CLI courants comme ffmpeg, c’est parce que cette connaissance est déjà figée dans leurs poids
  Si vous créez un nouvel outil CLI, il faut quand même apprendre à l’IA comment l’utiliser, et si vous voulez que cette partie « apprentissage » soit fournie par le serveur, c’est MCP ; si vous voulez la garder sous une forme statique locale, c’est une compétence
  Je ne comprends pas pourquoi il y a autant de débats autour d’un concept aussi simple
- Le problème, c’est que MCP occupe le contexte de façon relativement permanente, sans s’accompagner d’un système propre d’installation/désinstallation et de découverte
  Les compétences devraient toutes reposer sur MCP, n’être appelées qu’en cas de besoin, et être faciles à gérer et à découvrir à la fois pour les humains et pour l’IA afin que cela fonctionne correctement
  Quand on regarde le champ d’application réel, le périmètre initial était trop étroit, mais si on construit quelque chose par-dessus, cela peut peut-être encore être sauvé
Concernant l’affirmation « Problème 1 : ça dévore la fenêtre de contexte », je ne vois pas bien en quoi c’est différent d’exécuter successivement linearcli --help, notioncli --help, slackcli --help
Au contraire, avec MCP, l’environnement d’exécution peut ne mettre dans le contexte que le titre de chaque outil, puis ajouter la documentation complète par serveur MCP ou par outil seulement quand c’est nécessaire
Pour obtenir le même effet en CLI, il faudrait que tous les CLI proposent une commande du type --short-descr
Quant au « Problème 2 : faible fiabilité opérationnelle », si l’outil utilise une API REST, les protocoles se ressemblent, donc il n’y a pas de raison que MCP soit plus lent
Si c’est lent, il est probable que ce soit un problème d’implémentation, par exemple une couche MCP ajoutée au-dessus de l’API et déployée sur un serveur sous-traité dans un datacenter lointain
Que la plupart des serveurs MCP soient médiocres est possible, mais c’est un problème d’industrie, pas de protocole
Le « Problème 3 : ça fait doublon avec les CLI/API existants » est vrai quand il existe déjà un outil CLI, et un serveur MCP SQL ou un MCP pour curl ressemble alors à un gaspillage de tokens
Mais la plupart des organisations n’ont pas de CLI, et quand elles ont quelque chose, ce n’est souvent qu’une API conçue pour être utilisée par des programmes, pas par des grands modèles de langage
Dire « fournissez d’abord un CLI, puis une API, puis la documentation » revient à dire qu’au lieu d’un site web lent et gaspilleur, une entreprise devrait d’abord fournir un client natif desktop puis un client natif mobile
- Je n’ai pas exploré le sujet en profondeur, mais sauf erreur, hors des dernières releases de Claude Code, MCP était préchargé dans le contexte
  Si on n’en a pas souvent besoin, il faut le désactiver puis le réactiver quand nécessaire
  En mettant des exemples d’usage dans un fichier de skills, on peut aussi réduire le premier appel à --help, et avec un CLI il semble facile de lancer un sous-agent avec son propre contexte puis de ne récupérer que le résultat
Le texte n’a pas de date, mais il dit que le chargement différé des outils est une mise à jour récente arrivée après la rédaction
Or le chargement différé des outils a été ajouté en novembre 2025 : https://www.anthropic.com/engineering/advanced-tool-use
Ces chiffres ont donc au minimum 7 mois, et je ne vois pas pourquoi ça remonte maintenant
- Je trouve déjà étrange qu’on discute encore de ça
  Avec le chargement différé des outils, les grands contextes et le prompt caching, 2026 n’a plus rien à voir avec 2025
  Même l’argument selon lequel les CLI économisent des tokens s’effondre si la première étape consiste à lancer --help
  Si la manière d’appeler l’outil n’est pas mémorisée dans les paramètres, le problème reste le même : il faut quand même l’avoir dans le contexte
- Le texte semble même plus ancien encore, et laisse entendre que GPT-4o est le plus récent
- Le chargement différé des outils ne fait pas partie de MCP
  C’est un paramètre propre à l’API Claude que la plupart des autres API de grands modèles de langage ne prennent pas en charge
- L’article date du 29 mai 2026, et dire que cette mise à jour était un changement « récent » postérieur au texte, c’est un mensonge destiné à leur donner le beau rôle
Il me semble avoir lu un excellent article expliquant que MCP fonctionne bien à l’échelle de l’organisation quand il faut fournir un accès unifié et sûr aux API utilitaires internes pour des employés non techniques qui utilisent des outils d’agents internes
Les workflows sont codifiés sous forme de skills et partagés entre instances, tandis que MCP gère ce qui nécessite un accès API sensible au contexte
- C’est cet article ? https://chrlschn.dev/blog/2026/03/mcp-is-dead-long-live-mcp/
- Si c’est le cas, je me demande quel est l’avantage de MCP par rapport au fait de donner à l’agent un accès direct à l’API
- Je me demande si cela remplace un système d’autorisations qui protège l’API
  L’API doit de toute façon avoir un mécanisme d’autorisation sous une forme ou une autre
- C’est exact
  C’est précisément pour cette raison que des entreprises comme Runlayer croissent si vite, et sans plan de contrôle centralisé, MCP devient un champ de mines
Au-delà des points déjà mentionnés, le MCP distant, parce qu’il est piloté côté serveur, permet au producteur d’ajouter de nouvelles fonctionnalités sans avoir à mettre à jour les skills et CLI de tous les clients
De plus, le MCP distant est sûr car il ne demande pas l’autorisation d’exécuter réellement du code sur le système local
Les skills emballent souvent des scripts via npx/uvx, ce qui est en pratique presque aussi risqué que curl npm.com | bash
J’ai implémenté des skills connectés au système de gestion interne de l’entreprise, et nous avons fini par les enregistrer comme MCP
MCP n’expose que du grep sur la documentation et des appels d’API, donc en soi c’est totalement inutile, mais la raison principale de ce choix était le déploiement
Les équipes non techniques veulent une UI où il suffit d’ajouter une URL pour que tout fonctionne, avec OAuth guidé, et MCP permet cela dans Claude ou ChatGPT
La manière dont les appels MCP apparaissent dans l’UI de chat est aussi meilleure et plus claire pour l’utilisateur
Au lieu de gérer un serveur MCP et de distribuer un CLI pour toutes les plateformes, je me demande s’il ne vaudrait pas mieux exposer l’API via SSH
SSH est un protocole parfait pour les grands modèles de langage
Les agents de code savent déjà l’utiliser, et ssh api@example.com list-users suffit
Il y a de fortes chances que 90 % des utilisateurs aient déjà ssh installé, et comme l’entrée comme la sortie sont textuelles, c’est idéal pour les grands modèles de langage
On a l’authentification par clé publique, la sortie en streaming, les entrées/sorties interactives, et même le transfert de fichiers via scp/rsync si on le souhaite
Si l’utilisateur a lié son compte à Github ou GitLab, on pourrait même récupérer ses clés ssh et préconfigurer l’authentification, de sorte qu’il n’aurait qu’à se connecter pour entrer directement
- Il suffit ensuite d’étendre ça à l’échelle de toute l’organisation
La métaphore du restaurant n’est pas bonne
C’est du genre « il y a 10 menus étalés sur la table, il n’y a plus de place pour poser les plats, et à chaque commande il faut ressortir les menus », alors que dans les faits, sauf dans un restaurant de tapas, on repasse rarement plusieurs fois la même commande
On peut poser les plats sur les menus, et en général on enlève les menus après la commande pour libérer la table, c’est-à-dire le contexte
Si on veut expliquer ça par une analogie, il faudrait faire l’effort de la rendre plus pertinente