- Au cours des trois dernières années, l’évolution des méthodes d’extension des LLM a progressé sous diverses formes : plugins, instructions utilisateur, mémoire, protocoles, skills, etc.
- Les premiers ChatGPT Plugins ont tenté l’usage d’outils génériques via des appels d’API, mais ont échoué en raison des limites du modèle et d’une UX complexe
- Ensuite sont apparus Custom Instructions et Custom GPTs, apportant une personnalisation simple basée sur des prompts et une structure de modèles personnalisés partageables
- Le Model Context Protocol (MCP) et Claude Code ont permis une intégration d’outils complexe mais puissante, et récemment les Agent Skills ont fait renaître cette idée sous une forme simplifiée
- Au final, une architecture d’agent qui accomplit des tâches avec des outils à usage général et des instructions en langage naturel devrait devenir la direction centrale de l’extension des LLM
Histoire et évolution de l’extension des LLM
- Les usages des LLM ont évolué d’une simple saisie de texte vers des agents capables de piloter une base de code et un navigateur
- La question de savoir comment prendre en charge la personnalisation utilisateur est devenue un enjeu central
- Des approches très diverses ont été tentées, du simple system prompt jusqu’aux protocoles client-serveur complexes
ChatGPT Plugins (mars 2023)
- OpenAI a annoncé ChatGPT Plugins, conçus pour permettre à un LLM d’appeler des endpoints REST via une spécification OpenAPI
- L’objectif était un usage d’outils génériques au niveau AGI
- Mais les limites de GPT-3.5 et des premières versions de GPT-4 ont entraîné des erreurs et des pertes de contexte lors de l’exploration de spécifications API à grande échelle
- Une UX peu pratique, comme l’activation manuelle des plugins, a également posé problème
- Malgré cela, le plugin Code Interpreter (devenu plus tard Advanced Data Analysis) a montré le potentiel d’un puissant environnement d’exécution sandboxé
Custom Instructions (juillet 2023)
- Une fonction simple de prompt personnalisé qui réduisait la complexité des plugins
- Ajoutée automatiquement à toutes les conversations, elle a résolu le problème du réglage répétitif du contexte
- Elle a ensuite servi de précurseur aux fichiers de règles dans les environnements de développement, comme
.cursorrules et CLAUDE.md
Custom GPTs (novembre 2023)
- Avec Custom GPTs, OpenAI a transformé le prompt engineering en produit
- En regroupant persona, fichiers et actions, il devenait possible de créer des liens GPT personnalisés et partageables
- Cela marquait un recul, passant de l’approche ouverte des plugins à une forme d’application à objectif unique
Memory in ChatGPT (février 2024)
- Premier exemple d’un basculement vers la personnalisation automatique
- Le système se souvient des informations mentionnées dans la conversation et les réinjecte automatiquement dans les contextes futurs
- C’est le début d’une architecture d’agent persistante maintenant un état de long terme sans réglage manuel de l’utilisateur
Cursor Rules (avril 2024)
- Cursor IDE a introduit la gestion d’instructions au niveau du dépôt via le fichier
.cursorrules
- Ex. : « utiliser des tabulations », « pas de point-virgule », « utiliser TypeScript »
- Le système a ensuite évolué vers la structure de dossier
.cursor/rules, permettant d’appliquer des règles par fichier ou par répertoire
- Une fonction a aussi été ajoutée pour que le LLM décide lui-même quand appliquer les règles
Model Context Protocol (MCP, novembre 2024)
- Introduit par Anthropic, le MCP fournit une structure permettant au modèle d’utiliser de vrais outils de manière fiable
- Il maintient une connexion client-serveur et échange définitions d’outils, ressources et prompts
- Il ne s’agit pas simplement d’ajouter du contexte, mais de fournir de véritables capacités (
capabilities)
- Ex. : lecture de dépôt, requêtes DB, déploiement Vercel
- Même si sa complexité et sa charge de configuration sont élevées, il sert de couche de base pour ChatGPT Apps (annoncé en octobre 2025)
Claude Code et les mécanismes d’extension (février 2025)
- Claude Code est un agent qui intègre plusieurs modes d’extension
- gestion des consignes du dépôt avec
CLAUDE.md
- intégration d’outils via MCP
- prise en charge de Slash Commands, Hooks, Sub-agents, Output Styles (prévu pour suppression), etc.
- Même si l’avenir de certaines fonctions reste incertain, l’ensemble est considéré comme un modèle expérimental intégré d’extension d’agent
Agent Skills (octobre 2025)
- Une forme de renaissance des ChatGPT Plugins, utilisant une structure de skills basée sur des dossiers sans protocole complexe
- Composition :
skills/, SKILL.md, scripts et fichiers d’exemple
- Le contenu complet n’est lu qu’en cas de besoin, ce qui résout le problème de surcharge de la fenêtre de contexte (
context bloat)
- Exemple : un skill de test d’application web basé sur Playwright
SKILL.md contient les métadonnées et les consignes d’usage
- Les scripts sont exécutés directement, sans que le LLM charge inutilement leur contenu dans le contexte
- L’approche suppose un accès informatique à usage général et repose avant tout sur la confiance dans des outils génériques plutôt que spécialisés
Perspectives
- Agent Skills concrétise l’idéal des premiers plugins
- Les modèles sont désormais suffisamment intelligents pour accomplir des tâches avec de simples outils génériques et des consignes
- L’agent n’est plus redéfini comme une simple boucle LLM, mais comme une entité d’exécution couplée à un ordinateur
- Ex. : Claude Code, Zo Computer, etc., intègrent LLM et ordinateur en une seule forme
- Après 2026, les applications LLM devraient se diffuser sous la forme d’architectures d’agents intégrées à l’ordinateur
- En conclusion, les extensions fondées sur le langage naturel pourraient redevenir centrales face à des protocoles complexes comme le MCP
1 commentaires
Avis Hacker News
Je pense que le langage naturel est trop ambigu pour être efficace comme langage de programmation extensible
si les mathématiques ont leur propre langage spécifique à un domaine, c’est précisément pour garantir la clarté
c’est fastidieux en anglais, mais une fois qu’on s’y habitue, on peut réduire l’ambiguïté
le concept est bien résumé dans ce document
Je pense que les Skills concrétisent enfin le rêve des ChatGPT Plugins
les modèles sont désormais assez intelligents pour que cela puisse vraiment fonctionner
Simon Willison soutient lui aussi dans ce billet que les Skills représentent un changement plus important que MCP, mais l’inertie autour de MCP semble encore limiter l’attention portée au sujet
mais leur importance est bien plus grande dans la mesure où ils éliminent le scaffolding complexe exigé par MCP
par exemple, pour traiter les transcriptions d’un compte Fathom, il a suffi de créer un script CLI et d’écrire un
SKILL.mdles tests d’API client ont été résolus de la même façon
cela dit, cette approche est moins spectaculaire et offre moins de possibilités pour construire du tooling à grande échelle, ce qui explique sans doute qu’elle attire moins l’attention
en plus, les Skills partent du principe qu’on dispose d’agents capables d’exécuter du code arbitraire, ce qui relève encore le seuil d’entrée
depuis longtemps, je demandais déjà à Claude Code « lis X et fais Y », donc je me demande ce qui le distingue réellement des Skills
devoir suivre le travail via les I/O et les instructions
printest frustrantMCP sert à construire des systèmes, tandis que les Skills sont spécifiques à Claude, avec un lock-in important
l’impossibilité de référencer ou de composer les skills entre eux est aussi une grosse contrainte
au final, dès qu’on essaie de résoudre les questions d’extensibilité, de réutilisabilité ou d’usage à distance, on risque de revenir à MCP
si toutefois les Skills s’imposent comme une autre vue de MCP, on verra peut-être apparaître plus tard quelque chose comme un convertisseur Skill→MCP
Je ne vois pas bien le lien entre l’amélioration des modèles et la Bitter Lesson
on reste dans une logique où l’on injecte de l’expertise humaine pour compenser les limites du modèle
la vraie Bitter Lesson, ce serait plutôt obtenir de meilleurs résultats simplement en augmentant les ressources de calcul, sans intervention humaine
Les Custom GPTs existent depuis longtemps, mais j’ai récemment trouvé un usage vraiment pratique
j’ai créé un Custom GPT relié à l’API Notion pour gérer les comptes-rendus de réunion et les tâches de ma femme, et en quelques heures c’était déjà assez utile
j’ai essayé de l’intégrer à l’app Reminders, mais à cause des limites de l’API et des problèmes d’autorisations UI, j’ai fini par devoir créer moi-même un serveur MCP
je l’ai fait tourner sur un ancien MacBook Pro avec Amphetamine activé, relié via Tailnet et un tunnel Cloudflare pour qu’il soit accessible depuis ChatGPT
c’est complexe, mais avoir un agent IA comme hub central avait une vraie valeur
l’implémentation est détaillée dans ce blog
Même ChatGPT 5.1 hallucine encore des API inexistantes, mais cela s’améliore malgré tout
chaque fois que l’humanité a amélioré sa capacité à traiter l’information, le monde a changé ; de la même manière, si les LLM augmentent seulement leur probabilité de donner la bonne réponse, le monde changera encore
Je comprends tout à fait l’envie de « shorter MCP »
MCP est difficile à manier, mais il existe beaucoup de tâches dans le monde qui ont besoin d’interfaces sûres
si sa conception initiale était complexe, c’est parce qu’elle exposait directement la réalité du traitement des tokens en streaming
c’est compliqué, mais je pense qu’on reste malgré tout sur la frontière de ce qu’est un système simple mais fonctionnel
cela ne pourra pas être totalement remplacé, et tant que les modèles ne savent pas vraiment gérer un environnement agentique, une structure comme MCP restera nécessaire pendant un moment
aujourd’hui, les modèles peuvent déjà interagir correctement avec une simple description d’API
si une API existe déjà, la nécessité de créer un serveur MCP diminue fortement
à l’implémentation, cela revient à un simple niveau JSON-RPC + API
l’exemple hello-world de Python FastMCP est presque identique à la version Flask
les Skills sont apparus comme une réaction à cela, et à l’avenir on évoluera sans doute vers une structure où l’espace LLM et l’espace code s’auto-assemblent
Skills.md finira sans doute lui aussi par rencontrer, comme MCP, un problème de gonflement du contexte
je préférerais qu’on ne laisse que les scripts, sans descriptions, et qu’on entraîne les LLM à chercher eux-mêmes ce dont ils ont besoin dans le dossier
par exemple, il suffirait d’avoir un sous-agent léger chargé de lire et sélectionner les skills
Les ChatGPT Apps annoncées ce mois-ci donnent presque l’impression d’être les ChatGPT Plugin d’il y a trois ans
la différence tient surtout à la manière d’appeler le plugin — avant on le choisissait dans un menu déroulant, maintenant il suffit d’en mettre le nom dans le prompt
du point de vue utilisateur, la différence semble minime
Je considère les prompts comme des programmes probabilistes, et je pense qu’il faut un shell dédié pour les invoquer
les agents de codage comme Claude Code ou Codex en sont de bons exemples
j’étudie actuellement comment détacher cette fonction de l’IDE pour en faire un shell autonome comme llm-do
Le vrai point central de l’extension des LLM, c’est l’intégration au shell
un LLM relié au shell peut pratiquement tout faire