D2 — Conception d'outils et intégration MCP (18 %)

Deux outils, tous deux correctement implémentés, tous deux connectés, tous deux testés. Et l'agent continue d'appeler le mauvais. Rien n'est cassé — le modèle a choisi à partir de la seule chose dont il disposait, et cette chose était deux phrases qui disaient la même chose.

C'est le premier point de connaissance du guide, et c'est la phrase sur laquelle tout le domaine repose : les descriptions d'outils sont le mécanisme principal qu'un LLM utilise pour sélectionner un outil, et des descriptions minimales conduisent à une sélection peu fiable parmi des outils similaires. Le modèle ne lit pas votre implémentation. Il lit name, description et input_schema, et il décide.

La paire du guide lui-même est celle à mémoriser, parce qu'elle est délibérément banale :

{ "name": "analyze_content",  "description": "Analyzes content and extracts key information." }
{ "name": "analyze_document", "description": "Analyzes documents and extracts key information." }

Rien ici n'est faux. Les deux phrases sont vraies. Et aucune propriété de l'une ou de l'autre ne permet à un modèle de préférer celle-ci à celle-là : la décision de routage retombe alors sur ce que la formulation de la requête fait résonner.

Ce qu'une description doit porter

Le guide nomme quatre choses qui y ont leur place — les formats d'entrée, des exemples de requêtes, les cas limites et l'explication des frontières — et la documentation de l'API pose un plancher de volume : viser trois à quatre phrases au minimum, couvrant ce que fait l'outil, quand l'utiliser et quand ne pas l'utiliser, ce que signifie chaque paramètre, ce qu'il retourne, et ses limites.

{
  "name": "extract_web_results",
  "description": "Extracts the ranked result list from a fetched search-engine
    results page: title, URL, snippet and rank for each entry. Use this AFTER a
    page has been retrieved, and only on a SERP — for the body text of an
    ordinary article or a PDF, use extract_data_points instead. Returns an empty
    list, not an error, when the page carries no results. Does not follow the
    result links.",
  "input_schema": {
    "type": "object",
    "properties": {
      "html": { "type": "string", "description": "Raw HTML of the results page" },
      "max_results": { "type": "integer", "description": "Cap on entries returned; default 10" }
    },
    "required": ["html"]
  },
  "input_examples": [
    { "html": "<html>…</html>", "max_results": 25 },
    { "html": "<html>…</html>" }
  ]
}

Deux détails de ce bloc coûtent peu et sont souvent négligés. input_examples montre des appels types dont un où le paramètre optionnel est omis, et c'est ainsi que le modèle apprend que l'omettre est légitime plutôt qu'un oubli. Et la clause négative — « pour un article ordinaire, utiliser extract_data_points à la place » — est l'explication de frontière : elle nomme l'outil voisin, si bien que c'est la description qui lève l'ambiguïté au lieu de la laisser à la requête.

Les trois réparations, et le symptôme qui appelle chacune

Les compétences du guide sont trois gestes distincts. Lire l'énoncé pour savoir lequel il décrit est l'essentiel du travail sur ce task statement.

La division mérite un second regard, parce que c'est celle qui ressemble à du travail en plus. Un outil nommé analyze_document n'a aucun contrat de sortie : « analyser » peut vouloir dire un résumé, un tableau de chiffres ou un verdict sur une affirmation, et le modèle choisit en devinant. Trois outils aux trois noms portent chacun une promesse implicite sur ce qui revient, et c'est cette promesse qui rend la sélection décidable.

Diviser n'est pas gratuit, et 2.3 est le contrepoids : un jeu d'outils qui dépasse quatre ou cinq dégrade la sélection pour une autre raison. On divise un outil parce que ses métiers ont des contrats de sortie différents, pas parce que plus d'outils fait plus rangé.

Nommer, pour que le nom travaille avec la description

Deux habitudes venues de la documentation de l'API, toutes deux mécaniques :

• Namespacer avec le service. github_list_prs, slack_send_message. Un search nu dans une session qui tient quatre serveurs est une invitation au misrouting.
• Regrouper les opérations liées derrière un paramètre action plutôt que de livrer create_pr, review_pr et merge_pr en trois outils. La même économie que réclame la règle de comptage de 2.3, appliquée dès la conception.

Le nom lui-même doit respecter ^[a-zA-Z0-9_-]{1,64}$, ce qui autorise lettres, chiffres, tiret bas et tiret, jusqu'à soixante-quatre caractères.

Le system prompt peut l'emporter sur une bonne description

C'est le quatrième point de connaissance du guide et celui qu'on manque, parce que c'est du côté des définitions d'outils qu'on regarde. Une instruction sensible aux mots-clés dans le system prompt crée des associations d'outils non voulues.

# Le system prompt
You are a support assistant. ALWAYS verify the customer's identity before
answering anything.

Rien dans cette phrase ne nomme un outil. Mais « verify the customer » ressemble assez à get_customer, et « always » porte plus loin que n'importe quelle formulation propre à un tour : le modèle appelle désormais get_customer sur des tours où l'identité n'est pas en jeu, y compris « quels sont vos horaires d'ouverture ». Les descriptions d'outils sont bonnes. C'est l'instruction au-dessus d'elles qui a routé le tour.

La compétence du guide est une relecture, pas une réécriture : relire le system prompt pour y trouver les instructions sensibles aux mots-clés qui pourraient l'emporter sur des descriptions d'outils bien écrites. Le correctif consiste à cadrer l'absolu — « vérifier l'identité du client avant de divulguer des données de commande ou de compte » — pour que le mot-clé cesse de s'attacher à chaque tour.

Un outil échoue. L'agent doit maintenant décider une chose : le rappeler, changer les arguments, prévenir l'utilisateur, ou passer la main à un humain. Chacune de ces décisions se prend à partir de la charge utile que l'outil a retournée — et voici ce que cette charge utile dit d'habitude :

{ "isError": true, "content": [{ "type": "text", "text": "Operation failed" }] }

Le point de connaissance du guide en est la conséquence : des réponses d'erreur uniformes empêchent l'agent de prendre les décisions de récupération appropriées. L'agent fera quand même quelque chose. Il réessaiera quatre fois un refus de permission, ou renoncera sur un timeout qui se serait dissipé à la deuxième tentative, parce que rien dans la charge utile ne les distingue.

isError est le drapeau que MCP vous donne : il dit à l'agent que l'appel a échoué au lieu de retourner des données. Tout ce qui rend cet échec actionnable, c'est vous qui le posez à côté.

{
  "isError": true,
  "content": [{
    "type": "text",
    "text": "{\"errorCategory\": \"transient\", \"isRetryable\": true, \"description\": \"Order service timed out after 5s. Retry in a few seconds.\", \"attempted_query\": \"order_id=12345\"}"
  }]
}

Deux mécanismes d'erreur, et un seul est le vôtre

Avant les catégories, une frontière que le protocole trace et dont un distracteur raffole. MCP signale les échecs à deux endroits différents, et ils ne sont pas interchangeables.

Relisez la seconde ligne deux fois, parce qu'elle est contre-intuitive et qu'elle résume à elle seule ce task statement. Une règle métier violée n'est pas une erreur de protocole. L'appel est parvenu à l'outil, l'outil a tourné, et il a décidé que l'opération ne devait pas avoir lieu. La réponse revient donc comme un résultat normal dont isError vaut vrai et dont l'agent peut lire le contenu. Une réservation au-delà de l'horizon de 90 jours n'est pas une requête malformée : c'est une requête que l'outil a comprise et refusée.

C'est pourquoi tout ce qui suit porte sur le contenu d'un résultat plutôt que sur des codes d'erreur. Les erreurs de protocole sont l'affaire du transport et vous n'avez rien à y concevoir. Les erreurs d'exécution sont les vôtres, et la décision de récupération de l'agent se prend entièrement à partir de ce que vous y mettez.

Les quatre catégories, et la décision que chacune rend possible

Les deux colonnes de droite sont tout l'enjeu. La retryabilité est une affirmation sur la possibilité qu'une répétition de l'appel réussisse, et elle est connaissable au niveau de l'outil, pas au niveau de l'agent. Des métadonnées structurées évitent les tentatives de retry gaspillées. C'est la formulation du guide, et le gaspillage se facture à la tentative.

La ligne la plus mal lue est validation. Elle est retryable, et son retry n'est pas une répétition : l'agent répare ses propres arguments et rappelle. La classer à côté de permission parce que « l'appel a échoué pour une raison que l'outil a donnée » vous coûte une récupération que l'agent pouvait faire seul.

Les erreurs métier réclament une phrase qu'un client peut entendre

Le guide demande deux choses sur une violation de règle métier : retriable: false et une explication compréhensible par le client. La seconde n'est pas de l'ornement. L'agent va relayer cela à quelqu'un, et « BOOKING_RULE_4171 » se relaie mal.

{
  "isError": true,
  "content": [{
    "type": "text",
    "text": "{\"errorCategory\": \"business\", \"retriable\": false, \"description\": \"Appointments cannot be booked more than 90 days ahead. The earliest available slot inside that window is 12 March.\", \"policy\": \"booking_horizon_90d\"}"
  }]
}

Le code lisible par la machine reste, pour les journaux et pour le routage. La phrase posée à côté est ce qui permet à l'agent de répondre au client sans inventer la règle.

Un échec d'accès n'est pas un résultat vide

La dernière compétence du guide sur ce task statement est une distinction, et c'est celle qui produit des réponses fausses silencieuses plutôt que bruyantes.

Confondez-les et vous obtenez l'un des deux défauts. Signalez le résultat vide comme une erreur et l'agent réessaie une question à laquelle il a déjà été répondu. Signalez le timeout comme un résultat vide et l'agent conclut, de bonne foi, qu'il n'y a rien à trouver, et le trou n'apparaît jamais dans la réponse finale.

// Pas une erreur : le catalogue a bien été interrogé, il ne contient aucune correspondance.
{ "isError": false, "content": [{ "type": "text",
  "text": "{\"results\": [], \"searched\": \"parts_catalog\", \"query\": \"part_no=88-2210\"}" }] }

Récupération locale, et ce qui franchit la frontière

Le guide demande une récupération locale des erreurs à l'intérieur des subagents : un subagent traite lui-même ses échecs transitoires et ne propage au coordinateur que ce qu'il ne peut pas résoudre localement, accompagné de ses résultats partiels et de ce qu'il a tenté.

{
  "status": "partial",
  "completed": ["order_lookup", "customer_profile"],
  "failed": [{
    "step": "shipping_status",
    "errorCategory": "permission",
    "isRetryable": false,
    "attempted": "carrier_api.track(tracking_id=1Z999) — 3 attempts, 403 each time",
    "description": "The carrier account has no tracking scope. A human must grant it."
  }]
}

Trois propriétés rendent cette charge utile exploitable en amont : les résultats partiels survivent, l'étape en échec nomme sa catégorie pour que le coordinateur ne retente pas un refus de permission, et attempted dit ce qui a déjà été essayé pour que le budget de retry ne soit pas dépensé deux fois sur le même appel.

Chaque outil que vous ajoutez à un agent est une branche qu'il doit évaluer à chaque tour. Le guide met un chiffre là où cela cesse de fonctionner : donner à un agent l'accès à trop d'outils — 18 au lieu de 4-5 — dégrade la fiabilité de la sélection d'outil en augmentant la complexité de la décision.

C'est la dette de D1, et il vaut la peine d'être précis sur ce qu'elle affirme. Rien ne se dégrade dans le modèle ; ce qui se dégrade, c'est la décision. Dix-huit descriptions, dont certaines voisines, produisent un problème de sélection qu'aucune description individuelle ne peut résoudre, ce qui explique pourquoi le remède de 2.1 est la mauvaise réponse ici, et pourquoi lire l'énoncé compte plus que connaître les deux remèdes.

L'accès aux outils cadré sur le rôle

Le deuxième point de connaissance explique ce qui se passe mal au-delà du nombre : les agents dotés d'outils hors de leur spécialité tendent à en faire un mauvais usage. Le cas du guide lui-même est un agent de synthèse qui se met à faire des recherches web. L'outil est là, le tour est difficile, et y recourir est un geste localement sensé qui produit un travail que personne n'a demandé.

Chaque subagent reçoit donc les outils dont son rôle a besoin, et pas d'autres :

Un outil que vous laissez de côté n'est pas dans la session de l'agent du tout. Il n'y a pas d'instruction à ignorer ni de refus à journaliser : l'agent travaille simplement sans lui. C'est ce qui rend l'omission plus forte que l'instruction.

Contraindre l'outil plutôt qu'instruire autour

La deuxième compétence du guide est une substitution : remplacer fetch_url par load_document, qui valide que l'URL pointe vers un document. Le scénario qui la motive est un subagent d'analyse de documents qui, disposant d'un outil capable de récupérer n'importe quelle URL, finit par télécharger des pages de résultats de moteur de recherche au lieu de documents.

{
  "name": "load_document",
  "description": "Fetches a document by URL and returns its text. Accepts PDF,
    DOCX, TXT and Markdown URLs only; rejects any other URL with a validation
    error. Use this to read a document you already have the address of — it does
    not search, and it does not follow links inside the document.",
  "input_schema": {
    "type": "object",
    "properties": {
      "url": { "type": "string", "description": "Direct URL to a .pdf, .docx, .txt or .md file" }
    },
    "required": ["url"]
  }
}

Les outils cross-role, cadrés plutôt qu'ouverts

Le cadrage strict a un coût, et le guide en nomme le cas : l'agent de synthèse a constamment besoin de vérifier une affirmation ponctuelle. Renvoyer chaque vérification par le coordinateur — qui invoque l'agent de recherche web, attend, et relaie la réponse — paie deux ou trois allers-retours pour ce qui est le plus souvent une date ou un nom.

La réponse du guide n'est ni « donnez-lui la recherche web » ni « continuez à tout renvoyer ». C'est un outil cross-role limité, pour un besoin fréquent et précis :

{
  "name": "verify_fact",
  "description": "Verifies one specific claim against a named source document
    and returns a confidence level (high/medium/low) with the supporting
    excerpt. Use this only to check a claim you can already state and whose
    source you can already name — for open-ended research, route the request
    through the coordinator to the web research agent.",
  "input_schema": {
    "type": "object",
    "properties": {
      "claim":     { "type": "string", "description": "The single claim to verify" },
      "source_id": { "type": "string", "description": "Id of the source document to check against" }
    },
    "required": ["claim", "source_id"]
  }
}

Deux propriétés en font un outil cross-role cadré plutôt qu'un trou dans le cadrage. Il est plus étroit en capacité que l'outil qu'il remplace : il confronte une affirmation à une source nommée, il ne cherche pas. Et sa description dit où s'arrête son mandat, si bien que les cas complexes continuent de passer par le coordinateur. Le cas simple et fréquent obtient un chemin direct ; le reste préserve l'architecture.

tool_choice, et ce qu'il garantit ici

tool_choice est le champ de requête qui décide si appeler un outil est facultatif, obligatoire, ou obligatoire et nommé. Le champ lui-même — ses quatre valeurs, leur comportement sous extended thinking, et leur usage pour la sortie structurée — est enseigné en D4.3, qui le possède. Ce qui appartient à ce task statement, ce sont les deux usages que le guide nomme, et une chose qu'il ne répare pas.

{
  "tools": [ /* extract_metadata, enrich_entities, score_relevance */ ],
  "tool_choice": { "type": "tool", "name": "extract_metadata" }
}

Notez ce que l'appel forcé achète et ce qu'il n'achète pas. Il fixe la première action du tour. Séquencer le reste est affaire de traiter le résultat et d'émettre une autre requête. L'ordonnancement vit dans votre boucle, pas dans un paramètre unique.

Tout ce que ce task statement configure est une connexion à un serveur MCP. MCP déplace la charge de la définition et de l'exécution des outils hors de votre application, vers des serveurs dédiés. Sans lui, exposer GitHub à Claude signifie écrire, tester et maintenir un schéma et une fonction pour chaque opération sur les dépôts, les pull requests et les issues que vous voulez couvrir. Avec lui, vous vous connectez à un serveur MCP GitHub qui les porte déjà.

C'est aussi la réponse à la question que le cours signale comme confusion courante : MCP et le tool use ne sont pas la même chose. Le tool use, c'est la manière dont Claude appelle un outil. MCP, c'est d'où l'outil vient : quelqu'un d'autre l'a déjà écrit.

Les deux portées

Un serveur se déclare à l'une de deux portées, et le choix tient à une seule question : est-ce que toute l'équipe en a besoin ?

claude mcp add --scope user écrit dans ce second fichier : la commande et son effet sont le même fait vu de deux côtés, et sur ce point le libellé du guide et le comportement de l'outil concordent.

Les deux coexistent. Les outils de tous les serveurs MCP configurés sont découverts à la connexion et disponibles simultanément à l'agent, quelle que soit la portée qui les a déclarés. Mettre un serveur personnel dans ~/.claude.json ne vous coupe pas des serveurs projet. Vous avez l'union.

Cette propriété de découverte-à-la-connexion mérite d'être tenue comme un mécanisme et pas seulement comme un fait. Le client demande à chaque serveur ce qu'il fournit — un ListToolsRequest, auquel répond un ListToolsResult — et les définitions d'outils collectées sont ce qui accompagne la requête de l'utilisateur jusqu'à Claude. Rien n'est découvert paresseusement en cours de tour : un serveur qui n'a pas démarré n'a simplement aucun outil dans le jeu, et l'agent travaille sans eux exactement comme si vous ne l'aviez jamais déclaré.

Les secrets, par substitution de variables d'environnement

.mcp.json est suivi par le VCS. Les tokens, non. Le mécanisme du guide est la substitution de variables d'environnement :

{
  "mcpServers": {
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

${GITHUB_TOKEN} se résout au lancement, depuis l'environnement propre au développeur. Le fichier peut être committé et partagé ; chaque coéquipier fournit son propre credential, et le dépôt n'en porte jamais aucun. type dit comment le serveur est joint : "stdio" pour un processus lancé par command, "http" pour un serveur joint à une url.

Deux propriétés de la substitution méritent d'être retenues. Elle accepte une valeur par défaut, écrite ${VAR:-default}, ce qui permet à un réglage optionnel d'être livré avec une valeur pendant qu'un credential reste obligatoire. Et elle s'applique à plus que env : command, args, env, url et headers y passent tous, ce qui permet à l'adresse d'un serveur ou à son en-tête d'autorisation d'être eux aussi propres à chaque développeur.

"env": {
  "GITHUB_TOKEN": "${GITHUB_TOKEN}",
  "GITHUB_API_URL": "${GITHUB_API_URL:-https://api.github.com}"
}

Les resources, et pourquoi elles existent à côté des tools

Les serveurs MCP exposent trois primitives, et le guide est explicite sur les deux qu'il teste. Son annexe nomme les MCP tools et les MCP resources ; la liste in-scope dit « MCP tool and resource design ». Les prompts figurent ici pour que vous les reconnaissiez comme distracteur.

Une resource est plus proche d'un handler HTTP GET que d'un outil : une URI entre, des données sortent, et c'est votre application qui décide quand la lire. Le modèle ne l'appelle pas. Une resource directe a une URI statique ; une resource templatée porte des paramètres dans l'URI, que le SDK analyse et passe à votre fonction en arguments nommés.

@mcp.resource("docs://documents", mime_type="application/json")
def list_docs() -> list[str]:
    return list(docs.keys())            # le catalogue

@mcp.resource("docs://documents/{doc_id}", mime_type="text/plain")
def fetch_doc(doc_id: str) -> str:      # une entrée, par paramètre d'URI
    if doc_id not in docs:
        raise ValueError(f"Doc with id {doc_id} not found")
    return docs[doc_id]

Quand l'agent ignore votre outil MCP et utilise Grep

Vous branchez un serveur exposant un outil de recherche de code bien plus capable que Grep — il comprend la structure, suit les imports, renvoie du contexte. L'agent continue d'appeler Grep. Le serveur tourne, l'outil est listé : ce n'est pas un défaut de configuration.

La cause est celle de 2.1, vue du côté de l'intégration. Les outils intégrés arrivent avec des descriptions détaillées et éprouvées. Beaucoup d'outils MCP portent une ligne générée à partir d'un nom de fonction. Face à "Search files" d'un côté et à la description complète de Grep de l'autre, le modèle prend celle qu'il comprend.

La compétence du guide est la réparation : enrichir la description de l'outil MCP pour qu'elle explique ses capacités et ses sorties en détail, afin qu'elle cesse de perdre la comparaison.

# Avant — perd contre Grep à tous les coups
Search files.

# Après — énonce la capacité, la sortie, et ce que l'outil intégré ne sait pas faire
Searches the indexed codebase semantically. Given a symbol or a natural-language
description, returns the definition site, every caller with its file and line,
and the import chain that connects them. Unlike a textual search, it resolves
re-exports and aliases, so a function reached through a wrapper module is still
found. Use it to trace how a symbol is used across the repository; use Grep for
a literal string you can spell exactly.

Serveur communautaire ou serveur sur mesure

La dernière compétence est une décision « acheter ou construire » assortie d'un défaut : utiliser un serveur MCP communautaire existant pour les intégrations standard — Jira, GitHub, Slack — et réserver un serveur sur mesure aux workflows spécifiques à votre équipe que personne d'autre n'a implémentés. N'importe qui peut écrire un serveur, et les fournisseurs de services en publient souvent d'officiels : l'intégration standard que vous vous apprêtez à écrire existe probablement, maintenue, avec ses schémas déjà éprouvés.

Les six outils intégrés sont ceux dont un agent dispose déjà avant qu'aucun serveur MCP ne soit connecté, et le guide teste une chose à leur sujet : choisir le bon. Deux paires font l'essentiel des questions.

Grep contre Glob est la première paire, et le piège est que les deux sont décrits comme « cherchant ». Glob n'ouvre jamais un fichier : il fait correspondre des chemins. Grep se moque du nom de fichier : il fait correspondre du contenu. « Trouve tous les fichiers de test du parcours de commande », c'est Glob. « Trouve tous les appelants de applyDiscount », c'est Grep.

Quand Edit échoue, Read + Write est le repli documenté

Edit fonctionne en faisant correspondre un texte qui doit être unique dans le fichier. Quand l'ancre apparaît plus d'une fois, la modification est refusée, et le refus est délibéré : l'outil ne peut pas savoir de quelle occurrence vous parliez.

Le guide nomme le repli : Read le fichier en entier, amender le contenu, et le Write en retour.

# runbooks/db-failover.yaml — la ligne « owner: unassigned » apparaît 23 fois.
Edit(old_string="owner: unassigned", new_string="owner: sre-oncall")
  → refusé : l'ancre n'est pas unique.

# Repli
Read("runbooks/db-failover.yaml")        # le fichier entier, avec sa structure
→ amender la seule étape 14
Write("runbooks/db-failover.yaml", …)    # le fichier amendé, écrit en entier

La raison pour laquelle cela marche là où Edit ne pouvait pas, c'est que le contenu complet porte la position que l'ancre ne savait pas exprimer : l'étape 14 est identifiable dans son contexte, même si son texte est identique à celui de vingt-deux autres.

Construire la compréhension par incréments

La stratégie du guide pour un codebase inconnu est explicite, et sa valeur tient autant au contexte qu'à la justesse : commencer par Grep pour trouver les points d'entrée, puis Read pour suivre les imports et tracer les flux, plutôt que de lire tous les fichiers d'emblée.

1. Grep "createCheckoutSession"    → la définition, et trois sites d'appel
2. Read src/checkout/session.ts    → ce qu'elle fait, et ce qu'elle importe
3. Grep "from './session'"         → qui la consomme
4. Read les consommateurs          → comment elle est utilisée
5. Répéter jusqu'à ce que le flux soit complet

Tout lire d'abord remplit la fenêtre de contexte de fichiers qui se révèlent sans rapport, et les fichiers pertinents entrent alors en concurrence d'attention avec eux. Chaque Grep de la boucle ci-dessus est un filtre qui décide de ce qui mérite un Read.

Tracer une fonction à travers des modules d'enrobage

La dernière compétence est un échec précis de l'approche naïve, et elle vaut d'être connue comme procédure. Un seul Grep sur un nom de fonction rate tous les appels passant par un alias ou un ré-export.

# Rate les appelants indirects
Grep "analyzeDocument"

# Deux passes, comme le guide les décrit
1. Grep "export.*analyzeDocument"   → trouver tous ses noms exportés
     export { analyzeDocument }
     export { analyzeDocument as analyze }
     export { analyzeDocument as docAnalyze }
2. Grep chacun de ces noms           → analyzeDocument, analyze, docAnalyze
                                     → tous les appelants sont maintenant trouvés

L'ordre est la substance : identifier d'abord tous les noms exportés, puis chercher chaque nom à travers le codebase. Chercher le nom d'origine seul répond à une question plus étroite que celle qui était posée.