Resources, prompts et contexte long

Introduction

Les deux premiers chapitres techniques de cette formation ont porté sur les tools MCP : des fonctions que le modèle peut appeler pour agir. Mais un serveur MCPMCPIAModel Context Protocol : protocole permettant de brancher des outils et sources externes (docs, tickets, bases) à un agent LLM via des serveurs dédiés.Voir dans le glossaire n'a pas vocation à exposer uniquement des actions. Il expose aussi de la matière — des documents, des tickets, des extraits de base de connaissances — que le modèle doit pouvoir lire pour répondre correctement. C'est le rôle des resources. Et pour que l'usage de cette matière reste cohérent d'une session à l'autre, MCP propose une troisième primitive, les prompts, qui packagent des instructions réutilisables.

Ce chapitre couvre ces deux primitives sous l'angle qui compte le plus en entreprise : comment les exposer sans noyer le modèle sous un volume d'information ingérable. Un serveur MCP mal conçu peut techniquement fonctionner tout en dégradant sévèrement la qualité des réponses, simplement parce qu'il envoie trop de contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire, mal trié, au mauvais moment.

Les resources : exposer des documents, pas des actions

Une resource MCP est identifiée par une URI — par exemple ticket://JIRA-4521 ou docs://guide-facturation/section-3. Contrairement à un tool, une resource n'exécute pas d'action métier : elle retourne un contenu, le plus souvent du texte (Markdown, JSON, texte brut) mais potentiellement du binaire encodé.

Le serveur déclare ses resources de deux façons possibles :

• une liste statique, quand l'ensemble des documents est fini et connu à l'avance (une poignée de guides internes, par exemple) ;
• une liste dynamique paginée, quand le volume dépend de la donnée sous-jacente — un système de tickets avec des dizaines de milliers d'entrées ne peut pas être listé en une seule réponse.

Une resource n'est pas un raccourci pour "coller un fichier dans le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire". Elle porte une URI stable, un type MIME explicite, et peut être demandée à la demande par le client — ce qui permet au modèle de ne charger que ce dont il a réellement besoin, au moment où il en a besoin.

Un serveur exposant des tickets de support pourrait déclarer :

{
  "uri": "ticket://SUPPORT-8823",
  "name": "Ticket SUPPORT-8823 — Facture non reçue",
  "mimeType": "text/markdown",
  "description": "Ticket ouvert le 2026-08-14, client Grand Compte, statut: en cours"
}

Le champ description mérite un soin particulier : c'est souvent la seule information dont dispose le modèle pour décider s'il vaut la peine d'aller lire la resource en entier. Une description vague ("Ticket support") oblige le modèle soit à ignorer la resource, soit à la charger à l'aveugle — les deux comportements sont mauvais.

Resources et documentation vivante

Le cas d'usage le plus fréquent en entreprise est l'exposition d'une base documentaire : procédures internes, fiches produit, contrats types, changelog technique. L'intérêt par rapport à un simple export statique fourni une fois pour toutes est que la resource reste vivante : elle reflète l'état courant du document au moment où le modèle la consulte, sans qu'il soit nécessaire de régénérer un contexte figé à chaque mise à jour.

Un serveur MCP interne expose les procédures RH sous forme de resources : rh://conges/politique, rh://onboarding/checklist, rh://remboursement-frais/bareme. Un agentagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire répondant aux questions des employés va chercher la resource pertinente plutôt que de s'appuyer sur une version mémorisée, potentiellement obsolète, du barème de remboursement.

Les prompts : des instructions versionnées, pas de la conversation libre

Un prompt MCP est un gabarit d'instruction paramétrable, déclaré côté serveur et proposé au client. Il répond à un problème très concret : dans une organisation, plusieurs équipes finissent par écrire — chacune de son côté — des variantes légèrement différentes du même prompt ("résume ce ticket", "rédige une réponse client", "analyse ce contrat"). Ces variantes dérivent avec le temps, personne ne sait laquelle est "la bonne", et un changement de politique interne (nouveau ton, nouvelle mention légale obligatoire) doit être répercuté manuellement partout.

Exposer ces gabarits comme prompts MCP centralise le problème à un seul endroit : le serveur.

{
  "name": "resumer_ticket_support",
  "description": "Génère un résumé structuré d'un ticket support pour transfert à un niveau 2",
  "arguments": [
    { "name": "ticket_id", "required": true },
    { "name": "niveau_detail", "required": false }
  ]
}

Le client (l'application ou l'agent) appelle ce prompt avec les arguments, et reçoit en retour une séquence de messages prête à être injectée dans la conversation. Le contenu exact du gabarit — la formulation, les consignes de ton, les contraintes de format — reste sous le contrôle du serveur.

Versionner les prompts comme du code

Un prompt qui change de comportement sans prévenir casse silencieusement tous les usages qui en dépendent. La pratique qui fonctionne bien consiste à traiter les prompts MCP exactement comme des interfaces de code :

• un identifiant de version explicite dans le nom (resumer_ticket_support_v2) ou dans les métadonnées ;
• un changelog qui documente ce qui a changé et pourquoi ;
• une période de dépréciation avant suppression d'une ancienne version, pour laisser le temps aux clients de migrer.

Modifier le texte d'un prompt existant "en place", sans changer son nom ni sa version, revient à changer le comportement d'une fonction publique sans changer sa signature. Les équipes qui consomment ce prompt n'ont aucun moyen de détecter le changement avant de constater une dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire de qualité dans les réponses produites.

Pagination : ne jamais tout lister d'un coup

Dès qu'une resource ou une liste de tools dépasse quelques dizaines d'entrées, il faut paginer. MCP prévoit un mécanisme de curseur (cursor) : le client demande une page, reçoit des résultats plus un curseur vers la suite, et peut continuer tant que ce curseur est présent.

// Requête
{ "method": "resources/list", "params": { "cursor": null } }

// Réponse
{
  "resources": [ /* ... 50 entrées ... */ ],
  "nextCursor": "eyJvZmZzZXQiOjUwfQ=="
}

La tentation, côté implémentation serveur, est de renvoyer l'intégralité d'un catalogue en une seule réponse "pour simplifier". C'est une fausse économie : dès que le catalogue grossit — nouveaux tickets, nouveaux documents — la taille de la réponse grossit avec lui, sans plafond, jusqu'à saturer la fenêtre de contexte ou provoquer des temps de réponse dégradés.

Fixez une taille de page raisonnable dès la conception (20 à 100 éléments selon la nature du contenu), même si le volume actuel de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire ne le justifie pas encore. Le coût d'ajouter la pagination a posteriori, une fois des clients déployés en dépendant du comportement non paginé, est nettement plus élevé.

Taille de contexte : un budget, pas une ressource infinie

La fenêtre de contexte d'un modèle est finie, et le contexte utile qu'elle peut porter l'est encore davantage : au-delà d'un certain volume, même un modèle avec une grande fenêtre nominale voit la qualité de son raisonnement se dégrader (effet parfois appelé "lost in the middle", où l'information placée au centre d'un contexte long est moins bien exploitée que celle placée en début ou en fin).

Il faut donc raisonner en budget : combien de tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire sont disponibles pour le contexte apporté par les resources et les résultats de tools, une fois retranchés les instructions système, l'historique de conversation et la marge nécessaire à la réponse elle-même.

En pratique, cela se traduit par des règles simples mais souvent négligées :

1. Résumer avant de charger en entier. Une resource volumineuse (un contrat de vingt pages) devrait pouvoir être consultée sous forme de résumé ou de section ciblée, pas uniquement en intégralité.
2. Éviter les doublons de contexte. Si un tool a déjà renvoyé une information, ne pas la faire recharger sous forme de resource identique un peu plus tard dans la conversation.
3. Mesurer, ne pas deviner. La taille en tokens d'une resource peut être estimée côté serveur avant envoi, pour permettre au client d'arbitrer en connaissance de cause plutôt qu'après coup.

Ne pas noyer le modèle : patterns de sélection du contexte

Le risque le plus courant en production n'est pas l'insuffisance de contexte, mais son excès mal ciblé. Un agent connecté à quinze resources différentes, qui charge systématiquement tout ce qui est disponible "au cas où", produit des réponses plus lentes, plus coûteuses, et souvent moins précises qu'un agent qui sélectionne strictement ce qui est pertinent.

Quelques patterns ont fait leurs preuves :

• Recherche avant lecture. Exposer un tool de recherche (rechercher_tickets, rechercher_documentation) qui renvoie des identifiants et de courts extraits, puis ne charger la resource complète que pour les résultats effectivement pertinents. C'est le pattern le plus efficace pour des corpus volumineux.
• Filtrage par métadonnées. Permettre de filtrer les resources par date, statut, catégorie avant de les lister, plutôt que de renvoyer l'ensemble et de compter sur le modèle pour trier.
• Résumés hiérarchiques. Pour les documents longs, exposer d'abord un plan ou un résumé par section, et permettre de "descendre" dans une section précise seulement si nécessaire.
• Troncature explicite et signalée. Si une resource dépasse une taille raisonnable, la tronquer et l'indiquer clairement ("contenu tronqué, 40 000 caractères sur 120 000") plutôt que de la couper silencieusement, ce qui peut induire le modèle en erreur sur l'exhaustivité de ce qu'il a lu.

Le rôle d'un serveur MCP n'est pas de reproduire un moteur de recherche plein texte généraliste, mais de proposer une sélection déjà informée par le contexte métier — statut d'un ticket, périmètre d'un projet, droits d'accès de l'utilisateur. Un filtrage pertinent en amont vaut mieux qu'un filtrage a posteriori par le modèle sur un volume brut.

Étude de cas : un serveur de support client

Prenons un serveur MCP exposant un système de tickets pour une équipe support. Une implémentation naïve exposerait une resource par ticket et laisserait le modèle parcourir la liste complète à chaque requête. Avec dix mille tickets ouverts et clos, cette approche est intenable dès les premières semaines d'usage.

Une implémentation plus mature combine les patterns précédents :

• un tool rechercher_tickets(mots_cles, statut, client) qui renvoie une liste courte d'identifiants et de titres ;
• une resource ticket://{id} qui renvoie le détail complet, mais avec un résumé en tête de document pour les tickets à forte volumétrie d'échanges ;
• un prompt traiter_escalade_v3 versionné, qui formate systématiquement la réponse selon le gabarit validé par l'équipe qualité ;
• une pagination sur toute liste dépassant 25 éléments.

Cette combinaison garde le modèle concentré sur l'information utile à la tâche en cours, sans jamais l'exposer à un volume de données disproportionné par rapport à la question posée.

Droits d'accès et resources : un point souvent oublié

Exposer une resource ne dispense pas de vérifier les droits de la personne qui consulte l'agent. Un serveur MCP branché sur un système de tickets ou une base RH doit appliquer les mêmes règles d'habilitation que l'application d'origine : un employé ne doit pas pouvoir, via une conversation avec un agent, accéder à des tickets ou des dossiers auxquels il n'aurait pas accès dans l'outil métier lui-même.

Cette vérification doit se faire côté serveur MCP, au moment de servir la resource, et non côté client ou en comptant sur le modèle pour "refuser poliment". Un modèle de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire peut être incité, par une formulation habile de la requête, à demander une resource qu'il ne devrait pas obtenir ; seul un contrôle d'accès appliqué en amont, indépendant du comportement du modèle, offre une garantie fiable.

Un serveur MCP de prototype développé rapidement expose souvent toutes les resources sans filtrage, sous prétexte que "c'est en interne" ou que "l'utilisateur est authentifié de toute façon". Authentification et autorisation sont deux choses différentes : être identifié ne signifie pas avoir le droit de tout consulter.

Cela a une conséquence directe sur la conception des URI de resources : il est préférable d'éviter des identifiants devinables en série (ticket://1, ticket://2, ...) qui inciteraient à une énumération, et de toujours faire porter le contrôle d'accès sur l'identité de l'appelant plutôt que sur la structure de l'URI elle-même.

Checklist avant mise en production

• Toute liste de resources ou de tickets potentiellement volumineuse est-elle paginée dès la conception ?
• Les descriptions de resources permettent-elles au modèle de décider s'il doit charger le contenu complet, sans avoir à le faire à l'aveugle ?
• Les prompts exposés sont-ils versionnés, avec un changelog et une politique de dépréciation ?
• Existe-t-il un moyen de rechercher ou filtrer avant de lister intégralement un corpus ?
• Les documents volumineux disposent-ils d'un résumé ou d'un plan consultable avant lecture complète ?
• La troncature éventuelle d'un contenu est-elle signalée explicitement au modèle ?

Conclusion

Resources et prompts complètent les tools pour former les trois primitives fondamentales de MCP : agir, lire, et instruire de façon reproductible. La difficulté n'est presque jamais technique — l'implémentation d'une resource paginée ou d'un prompt versionné est un exercice de programmation ordinaire. Elle est architecturale : décider quoi exposer, à quel niveau de granularité, et selon quels critères de sélection, pour que le modèle reçoive exactement ce dont il a besoin, ni plus ni moins. C'est cette discipline de sélection du contexte qui distingue un serveur MCP réellement utilisable en production d'un serveur qui fonctionne seulement en démonstration.