Chapitre 1 — La crise d'intégration de l'IA et l'essor de l'architecture agentique

Premier billet de la tournée chapitre par chapitre de LLM Primer IV : Concevoir la cognition de l'IA avec MCP. Le chapitre où le patron dominant de l'ère 2024 — long prompt système, poignée d'outils, fenêtre de contexte unique à qui l'on demande de tout faire — échoue selon une séquence reconnaissable, et où la défaillance pointe vers une couche protocolaire que le domaine préparait discrètement depuis le début.

Pourquoi ce chapitre existe

Pendant environ deux ans, la recette standard pour une application LLM a été : écrire un long prompt système, attacher une poignée d'outils, et appeler cela un agent. La recette a livré des démos. Elle s'est aussi cassée, prévisiblement, à mesure que la surface s'étendait. Les prompts ont franchi les six mille tokens. Les inventaires d'outils ont dépassé la quarantaine. L'équipe rapiéçait, auditait, repassait les tests de régression, et a fini par remarquer qu'ajouter des fonctionnalités était devenu exponentiellement plus coûteux qu'auparavant. Le diagnostic n'était ni la paresse ni la mauvaise ingénierie. C'était une architecture qui forçait chaque préoccupation à passer par une ressource partagée — le contexte du modèle — et un problème combinatoire plus profond qui se cachait en dessous.

Ce chapitre parcourt les modes de défaillance dans l'ordre où les équipes les rencontrent vraiment, nomme chacun, puis cadre la sortie architecturale. Cette sortie, c'est une couche protocolaire qui laisse les modèles et les outils se trouver sans colle sur mesure, et une discipline — l'ingénierie de contexte — qui traite la vue du modèle comme un budget géré plutôt que comme un champ texte libre. Les deux idées mettent en place tout le reste du livre.

1.1 L'agent monolithique et pourquoi son prompt système finit par casser

La première génération d'applications LLM en production avait une forme architecturalement simple. Un prompt système de plusieurs milliers de tokens décrivait rôle, outils, contraintes, ton et cas limites. Cela marchait sur des surfaces étroites. À mesure que l'équipe ajoutait des fonctionnalités, un paragraphe à la fois, le prompt est devenu l'artefact le plus long de la base de code, édité surtout par addition parce que retirer quoi que ce soit semblait risqué.

Ce que ce prompt faisait en interne se comprend le mieux à travers l'attention. Un transformeur calcule des poids d'attention sur chaque token de son contexte, y compris chaque token du prompt système. Un prompt de six mille tokens ne se survole pas — on en fait la moyenne. Plus le prompt est long, plus la masse d'attention se disperse sur des instructions sans rapport avec l'étape en cours. Le phénomène a des noms : dilution du contexte, collision d'instructions, dérive des capacités. L'équipe observe la régression et ne sait pas localiser la cause, parce que la cause, c'est l'interaction de trois règles nouvelles avec une clause ajoutée deux sprints plus tôt.

Une défaillance apparentée apparaît au niveau des outils. Avec dix outils, le modèle choisit correctement ; avec quarante, la précision de sélection chute, parfois fortement. L'équipe rapièce en ajoutant un langage de désambiguïsation, ce qui rallonge le prompt, ce qui dilue l'attention davantage. Le système est désormais dans une boucle de rétroaction avec lui-même.

1.2 Spécialisation et courbe de maintenance qui s'incurve dans le mauvais sens

Sous le problème de prompt s'en trouve un plus profond. Les modèles généralistes de pointe sont d'excellents généralistes, mais la performance généraliste est une moyenne sur une vaste surface, et les moyennes cachent des falaises. Revue de contrats juridiques, codage médical structuré, réconciliation financière — chacun a son vocabulaire interne, ses règles internes, et une tolérance à l'erreur que l'entraînement général n'optimise pas. L'instinct consiste à spécialiser par le prompt ; le coût est plus de budget d'attention consommé pour moins de retour. Une vraie spécialisation veut son propre composant avec son propre contexte focalisé, ce que l'agent monolithique n'a nulle part où ranger.

La maintenance évolue de la même mauvaise façon. Un agent monolithique avec cinquante outils sur quatre domaines n'a pas dix fois la charge de maintenance d'un agent à cinq outils sur un domaine — il en a davantage, parce que chaque fonctionnalité interagit avec chaque autre à travers le prompt partagé. La vélocité de l'équipe est fixée par le coût de maintenir cohérente la surface existante, non par le coût de construire de la nouvelle capacité. Le coût d'inférence évolue avec la longueur du contexte ; la pression économique pour réduire le prompt et la pression d'ingénierie pour l'allonger tirent dans des directions opposées.

1.3 Le problème d'intégration N fois M

Acceptez l'argument de la décomposition. Vous avez maintenant N composants porteurs de modèle et M intégrations d'outils. Sans protocole partagé, le coût d'intégration est N fois M — chaque modèle a besoin de code d'adaptateur sur mesure pour chaque outil, les particularités de chaque modèle multipliées cartésianement par celles de chaque outil. Une nouvelle sortie de modèle signifie retester chaque outil. Un nouvel outil signifie écrire N adaptateurs.

L'histoire de l'informatique a un nom pour cette forme et un nom pour le remède. Avant LSP (2016), chaque éditeur avait besoin d'une intégration avec chaque langage — éditeurs fois langages. LSP a introduit un protocole ; la matrice s'est effondrée en un coût additif. Avant USB, chaque catégorie de périphérique avait son propre port, et chaque OS livrait ses propres pilotes. Après USB, un hôte, un périphérique, un protocole partagé entre les deux. Le Model Context Protocol est le même geste appliqué aux modèles et aux outils. Il n'élimine pas les adaptateurs ; il les standardise. La première intégration est plus lente ; la centième beaucoup plus rapide ; la millième essentiellement gratuite parce que l'outillage s'est accumulé. Tout le jeu se joue dans la courbe cumulée.

Un protocole avec découverte effondre aussi une seconde matrice plus discrète — la matrice descriptive. Le modèle n'a plus besoin que chaque outil soit énuméré dans son prompt système au démarrage ; il peut demander au protocole « qu'est-ce qui est disponible en ce moment ? » et recevoir un catalogue structuré depuis la source qui fait autorité : le serveur lui-même.

1.4 De l'ingénierie de prompt à l'ingénierie de contexte

Un glissement de vocabulaire suit le glissement architectural. En 2022-2023, la discipline s'appelait ingénierie de prompt — trouver les formulations qui orientaient le modèle vers le comportement souhaité. En 2025, le prompt n'était plus qu'une entrée parmi d'autres. Le modèle voit aussi des documents récupérés, des descriptions d'outils, des tours précédents, des résultats d'outils, des notes de scratchpad, des extraits de mémoire. Ce qui doit se trouver dans ce contexte à chaque étape ne se répond plus par la formulation. Cela se répond par une architecture qui décide, par tour, ce que le modèle doit regarder.

Le terme qui s'est installé est l'ingénierie de contexte. Elle traite la fenêtre de contexte comme un budget géré. Les modèles modernes à contexte long annoncent des fenêtres d'un million de tokens, mais la performance se dégrade de manière non linéaire à mesure que le contexte se remplit — le phénomène que l'on appelle parfois context rot. Un modèle à qui l'on tend un contexte d'un million de tokens avec la réponse enfouie dedans est souvent moins performant que le même modèle à qui l'on tend dix mille tokens soigneusement sélectionnés. Le budget qui compte, ce n'est pas la taille de la fenêtre ; c'est la densité du signal utile à l'intérieur de ce qui se trouve réellement devant le modèle.

MCP est, en partie, l'infrastructure qui rend l'ingénierie de contexte possible. Le protocole donne à l'hôte la machinerie pour demander quels outils et quelles sources de données sont disponibles, pour récupérer les bons au bon moment, pour négocier quelles capacités le modèle peut invoquer. L'hôte construit le contexte dynamiquement, par tour, en fonction de ce que la tâche en cours exige réellement.

Ce que prépare le Chapitre 1

Le diagnostic tient en trois parties : les agents monolithiques échouent parce que les longs prompts diluent l'attention ; une capacité spécialisée ne vit pas dans un prompt partagé ; sous les deux se trouve le problème d'intégration N fois M. Chaque mode de défaillance pointe dans la même direction — une couche sous le modèle qui médiatise la façon dont modèles et outils se trouvent, se décrivent et négocient ce qu'ils peuvent faire. Le Chapitre 2 introduit cette couche : les trois rôles que MCP définit, le petit ensemble de primitives conceptuelles, et le cycle de vie de session qui s'ouvre par une négociation explicite des capacités.

Prochaine étape — Chapitre 2 : Dévoiler le Model Context Protocol. Ce qu'est MCP, ce que le raccourci « USB-C pour l'IA » veut vraiment dire, le découpage en trois rôles Hôte, Client, Serveur, et pourquoi la découverte dynamique et la messagerie bidirectionnelle font de MCP autre chose qu'une API REST dans les cas qui comptent.