- Claude Skills, annoncé par Anthropic, est un nouveau modèle où les instructions, scripts et ressources nécessaires à l’exécution d’une tâche donnée sont fournis sous forme de dossier, avec un chargement dynamique de l’expertise par tâche
- Les Skills se composent de fichiers Markdown et de scripts optionnels ; au démarrage d’une session, seules les métadonnées de chaque skill sont chargées pour quelques dizaines de tokens, puis le contenu complet n’est récupéré qu’en cas de besoin réel, ce qui offre une très forte efficacité en tokens
- Grâce à Claude Code, les Skills dépassent le simple outil de programmation pour s’étendre à un agent d’automatisation généraliste ; dès lors qu’il dispose d’un système de fichiers et d’un environnement d’exécution de commandes, il peut automatiser une grande variété de tâches
- Contrairement à MCP, les Skills ne reposent pas sur un protocole mais sur une structure simple fondée sur Markdown et YAML, ce qui les rend immédiatement exploitables par d’autres modèles ou outils et facilite leur partage comme leur diffusion
- Grâce à cette simplicité et à cette efficacité, l’écosystème des Skills devrait s’étendre bien plus vite que celui de MCP, avec la possibilité de construire des agents spécialisés dans des domaines allant du journalisme de données aux chartes de marque, tout en évitant les problèmes de consommation de tokens et la complexité des spécifications de MCP
Concept et structure des Skills
- Anthropic a officiellement annoncé Claude Skills le 16 octobre 2025
- Un système d’extension des capacités à l’échelle du dossier contenant les instructions, scripts et ressources nécessaires pour qu’un modèle accomplisse une tâche spécifique (par ex. manipuler Excel, respecter les directives de marque d’une organisation)
- Claude n’accède au skill concerné que lorsqu’il est pertinent pour la tâche, afin d’améliorer ses capacités d’exécution spécialisée
- Le dépôt GitHub anthropic/skills propose des exemples officiels de skills
- Le concept de Skills est extrêmement simple
- Au cœur du système se trouve un fichier Markdown qui explique au modèle comment effectuer la tâche
- Il peut inclure, en option, de la documentation supplémentaire et des scripts préécrits pour aider à mener la tâche à bien
- La fonction de génération de documents annoncée par Claude en septembre a en réalité été entièrement implémentée avec des Skills
- Les skills de traitement de fichiers
.pdf, .docx, .xlsx, .pptx sont visibles dans le dépôt public
Efficacité en tokens : l’atout clé des Skills
- Au démarrage d’une session, Claude scanne tous les fichiers de skills disponibles et ne lit que la courte description présente dans le frontmatter YAML de chaque skill
- Le coût initial de chaque skill n’est que de quelques dizaines de tokens, ce qui le rend extrêmement efficace
- Le détail complet n’est chargé que lorsque l’utilisateur demande une tâche pour laquelle le skill peut être utile
- C’est ce qui en fait une véritable fonctionnalité, et pas simplement des fichiers stockés sur disque
Cas pratique : le skill de création de GIF pour Slack
- Description des métadonnées du skill slack-gif-creator
- Une boîte à outils de création de GIF animés optimisés pour Slack
- Inclut un validateur de contraintes de taille et des éléments d’animation de base combinables
- S’applique à des requêtes du type « crée-moi un GIF Slack où X fait Y »
- Déroulement du test réel
- Activation du skill slack-gif-creator dans l’application web mobile de Claude avec le modèle Sonnet 4.5
- Saisie du prompt : "Make me a gif for slack about how Skills are way cooler than MCPs"
- Claude génère automatiquement le GIF (la qualité doit encore être améliorée, mais le skill se prête bien à des itérations rapides)
- Points notables du script Python généré
- Ajout du répertoire du skill au chemin Python :
sys.path.insert(0, '/mnt/skills/examples/slack-gif-creator')
- Utilisation de la classe
GIFBuilder du répertoire core/ du skill
- Enregistrement du fichier dans
/mnt/user-data/outputs/
- Vérification du respect des contraintes grâce à la fonction de limite de taille Slack (2 Mo)
check_slack_size()
- Si la taille est dépassée, le modèle peut automatiquement tenter de régénérer un fichier plus léger
Dépendances environnementales des Skills
- Le mécanisme des Skills ne fonctionne pleinement que si le modèle peut accéder à
- un système de fichiers
- un outil de navigation dans le système de fichiers
- la capacité d’exécuter des commandes dans l’environnement
- C’est un schéma classique dans l’outillage LLM
- Le Code Interpreter de ChatGPT a constitué le premier cas massif début 2023
- Depuis, cela s’est étendu aux machines locales via des outils d’agents de code comme Cursor, Claude Code, Codex CLI ou Gemini CLI
- Cette exigence constitue la plus grande différence avec les tentatives précédentes d’extension des capacités des LLM, comme MCP ou les plugins ChatGPT
- C’est une dépendance importante, mais l’ampleur des nouvelles capacités débloquées est étonnamment grande
- Les questions de sécurité restent essentielles
- Il faut fournir un environnement de code sûr
- Il faut aussi des moyens de construire un environnement sandboxé pour limiter les dégâts d’attaques comme l’injection de prompt à un niveau acceptable
Claude Code : évolution vers un agent généraliste
- En janvier 2025, l’auteur prédisait que les « agents » échoueraient, mais il s’est complètement trompé
- 2025 est en réalité devenue « l’année des agents » (avec de nombreuses définitions possibles, mais ici définis comme « tools in a loop »)
- Claude Code porte mal son nom
- Ce n’est pas un simple outil de programmation, mais un outil généraliste d’automatisation informatique
- Il peut automatiser toute tâche réalisable en entrant des commandes sur un ordinateur
- Le décrire comme un agent généraliste est ce qu’il y a de plus juste
- Les Skills rendent ce potentiel beaucoup plus clair et explicite
- Les applications possibles sont d’une ampleur vertigineuse
- Exemple en journalisme de données : on peut constituer un dossier de skills couvrant les tâches suivantes
- comprendre les sources et la structure des données du recensement américain
- charger des données de formats variés dans SQLite/DuckDB à l’aide de bibliothèques Python
- publier des données en ligne sous forme de fichiers Parquet sur S3 ou de tables Datasette Cloud
- trouver des histoires intéressantes dans un nouveau jeu de données (avec les consignes d’un reporter de données expérimenté)
- construire des visualisations de données propres et lisibles avec D3
- Résultat : avec quelques fichiers Markdown et quelques exemples de scripts Python, il devient possible de créer un « agent de journalisme de données » capable de découvrir et publier des histoires à partir des données du recensement américain
Comparaison Skills vs MCP
- Le Model Context Protocol (MCP) a suscité un immense intérêt depuis son lancement en novembre 2024
- Toutes les entreprises avaient besoin d’une « stratégie IA », et annoncer une implémentation MCP était une façon simple de répondre à cette attente
- Les limites de MCP deviennent progressivement visibles
- Le problème le plus important est l’usage des tokens
- Le MCP officiel de GitHub consomme à lui seul plusieurs dizaines de milliers de tokens de contexte
- En en ajoutant quelques autres, il ne reste presque plus de place pour que le LLM réalise un travail réellement utile
- Depuis qu’il s’intéresse sérieusement aux agents de code, l’auteur s’intéresse moins à MCP
- Presque tout ce qu’on peut faire avec MCP peut être remplacé par des outils CLI
- Le LLM sait appeler
cli-tool --help, donc il n’est pas nécessaire de dépenser beaucoup de tokens pour lui expliquer l’usage
- Le modèle peut le déterminer lui-même au moment opportun
- Les Skills offrent exactement les mêmes avantages, et même davantage, sans exiger l’implémentation d’un nouvel outil CLI
- Il suffit de déposer un fichier Markdown expliquant comment réaliser la tâche
- On n’ajoute des scripts supplémentaires que lorsqu’ils améliorent la stabilité ou l’efficacité
Perspective d’une croissance explosive de l’écosystème Skills
- L’un des aspects les plus intéressants des Skills est leur facilité de partage
- Beaucoup de skills devraient tenir dans un seul fichier
- Les skills plus sophistiqués prendront la forme de dossiers contenant quelques fichiers
- Ressources fournies par Anthropic
- L’auteur réfléchit lui aussi à des idées de skills, comme la façon de construire des plugins Datasette
- Utilisable aussi avec d’autres modèles : c’est un autre avantage de la conception des Skills
- On peut connecter un dossier de skills à Codex CLI ou Gemini CLI et demander « lis
pdf/SKILL.md et crée un PDF qui présente ce projet », et cela fonctionne
- Cela reste possible même si l’outil ou le modèle n’a aucune connaissance intégrée du système de skills
- Prévision : une explosion cambrienne des Skills qui fera paraître bien modeste la ruée vers MCP de cette année
La simplicité comme force centrale
- Certains estiment que les Skills sont trop simples pour mériter d’être appelés une fonctionnalité
- Beaucoup expérimentaient déjà l’astuce consistant à placer des instructions supplémentaires dans des fichiers Markdown pour les faire lire à un agent de code
- AGENTS.md est un modèle déjà bien établi, et peut contenir des consignes comme « lire PDF.md avant de générer un PDF »
- C’est précisément cette simplicité fondamentale de la conception des Skills qui enthousiasme l’auteur
- MCP, lui, repose sur une spécification de protocole complète
- hôte, client, serveur, ressources, prompts, outils, sampling, racines, elicitation
- avec trois modes de transport (stdio, HTTP streamable, et à l’origine SSE)
- Les Skills, c’est du Markdown + un peu de métadonnées YAML + des scripts d’exécution optionnels
- C’est bien plus proche de la manière dont fonctionnent les LLM : on leur fournit du texte et le modèle se débrouille avec
- Les Skills externalisent la partie difficile vers le harnais LLM et l’environnement informatique associé
- C’est une stratégie très avisée au regard de tout ce que nous avons appris ces dernières années sur les capacités d’exécution d’outils des LLM
12 commentaires
Je me demande si cela pourrait aussi s’appliquer quand on utilise Claude Code pour le développement.
Actuellement aussi, j’ai mis des consignes dans
Claude.md, puis je poursuis en séparant les directives détaillées dans chaque partie.Pour réaliser beaucoup de tâches avec peu de tokens, j’ai l’impression qu’on peut régler ça assez simplement en misant sur des agents multiples et des résumés plutôt que sur l’optimisation des prompts. Je suis d’accord sur le problème, mais la solution proposée me semble avoir ses limites.
Les Skills n’utilisent-ils pas aussi des tokens ? Si c’est le cas, j’ai l’impression que le problème de consommation de tokens risque de se reposer, et je ne vois pas très bien comment on y répondra à ce moment-là.
Il semble que, dans le contexte, ce ne soit pas tout le
SKILLS.mdqui soit inclus, mais seulement la partie en haut avec le nom et la description ci-dessous qui soit toujours ajoutée d’abord.name: skill-creator
description: Guide pour créer des skills efficaces. Cette skill doit être utilisée lorsque les utilisateurs veulent créer une nouvelle skill (ou mettre à jour une skill existante) qui étend les capacités de Claude grâce à des connaissances spécialisées, des workflows ou des intégrations d’outils.
license: Conditions complètes dans LICENSE.txt
Quand on travaille avec Claude Code, on finit par lui injecter en permanence des consignes ou des règles dans le contexte, et au final on se retrouve à devoir arbitrer entre la consommation de tokens et la taille du contexte. Du coup, j’ai pensé à créer un dossier, à y écrire les détails de façon très précise dans des fichiers
.mdpar fonctionnalité, puis à ne mettre dansclaude.mdqu’une foule de pointeurs du genre « pour faire ceci, voir cela » ; et ça a plutôt bien marché pour un coût assez faible. Comme les Skills reviennent au fond à regrouper ce genre de choses, ça a l’air d’être assez utile.Et comme annoncé, si une marketplace de skills sort aussi, je me disais que ça pourrait être plutôt pas mal de ne récupérer que les skills nécessaires et de les activer quand on en a besoin.
Oh, merci pour cette explication essentielle.
Quel lien peut-il y avoir entre la gestion du contexte et les Claude Skills ? Je me suis d’abord demandé en quoi c’était différent des commandes personnalisées de Claude Code qui existaient déjà, mais en lisant la documentation, j’ai eu l’impression que la plus grande différence est surtout qu’on peut inclure et exécuter du code de script comme du Python ou du JavaScript à l’intérieur d’une même skill.
Avis Hacker News
Pour moi, Claude Skills est la preuve que le RAG a été rendu inutilement difficile du point de vue de l’expérience utilisateur. Ce n’est pas un problème de complexité technique, c’est un problème d’UX. Si on résout correctement ce point, Claude Skills lui-même pourrait devenir inutile. Ce que Claude Skills fait mieux que MCP, c’est sa facilité de création. On peut en faire juste en écrivant du texte, donc tout le monde peut l’utiliser. En revanche, cela dépend fortement de l’environnement. Par exemple, s’il faut un outil précis pour fonctionner, comment automatiser cela avec un réglage de sandbox ? Et il est même difficile d’être certain qu’on a bien la bonne version
Dans notre entreprise, on essaie quelque chose de similaire en interne. Les fichiers de contexte de notre monorepo étaient devenus trop volumineux, donc nous avons construit un arbre de fragments chargés progressivement selon la tâche. Ces documents de contexte ressemblent beaucoup à de la documentation développeur classique, mais en pratique ils sont bien plus utiles et orientés tâche. Ça me fait me demander pourquoi on n’a pas réussi à produire ce genre de documents plus tôt.
C’est en pratique un problème principal-agent avec une dimension de marshmallow test. Quand un développeur écrit de la documentation pour d’autres humains plutôt que pour une IA, il ne sait pas vraiment qui est cette personne, de quoi elle a besoin, ni même si elle lira ce document. Bien sûr, cela pourra aussi lui servir plus tard, mais il est difficile d’en avoir l’intuition, le temps ou la discipline. En revanche, si l’IA utilise cette documentation pour m’aider directement, j’ai un énorme incitatif immédiat à consigner les informations nécessaires. Et la boucle de feedback est aussi bien plus courte. À noter qu’avec les LLM, les commentaires de code ont tendance à disparaître facilement, donc en ce moment je laisse plus de documentation et beaucoup moins de commentaires
Les nouveaux développeurs se plaignent rarement d’une documentation désastreuse, de peur d’avoir l’air stupides. L’auteur, lui, a déjà le modèle mental en tête et perçoit mal le problème, et bien documenter revenait à mettre son propre poste en danger. Mais si on donne une documentation bancale à un robot stupide et que ça ne marche pas, on est obligé de s’en prendre à soi-même. Au final, je pense que c’est #2 + #3. Le grand changement, c’est que la “remplaçabilité” est passée d’un concept négatif à un concept positif (on se remplace soi-même par un agent avant qu’un agent bon marché ne prenne sa place)
C’est similaire aux raisons pour lesquelles la dette technique existe : pression business, mauvaise conception, manque de ressources. Autrefois, maintenir en permanence une bonne documentation à chaque modification du code coûtait vraiment très cher
Quand on me demande d’imaginer plusieurs skills dans un dossier, je pense à des tâches comme localiser des données du recensement américain ou interpréter leur structure. En entendant ça, j’ai immédiatement repensé à la première fois où j’ai utilisé Wolfram Alpha. Contrairement à un moteur de recherche classique, j’avais été impressionné par le fait qu’il s’agissait d’un véritable outil structuré pour résoudre des problèmes. Je viens de le réessayer, et c’est toujours aussi remarquable : interroger la population des États-Unis avec Wolfram Alpha. Dans ma tête, le modèle des Skills ressemble à l’ajout d’extensions personnalisées à Wolfram Alpha
J’ai cliqué sur le lien que vous avez posté et la requête s’ouvre dans Wolfram Alpha comme
what%27s the total population of the United States%3F. Le résultat est amusant : il affiche6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates). Je me demande bien comment cela a été calculéHonnêtement, le Wolfram Alpha d’autrefois était vraiment un accomplissement incroyable. Je trouve toujours fascinant qu’ils aient réussi, à l’époque et sans IA, à construire un système capable de traiter même des problèmes mathématiques complexes
J’ai un peu de mal à comprendre la différence entre Skills et les outils existants. Beaucoup de skills peuvent aussi être vus comme de simples outils, ou comme des ensembles d’outils avec une couche d’explication en plus. Mais la définition d’un outil et celle d’un skill ne se trouvent-elles pas à des endroits différents ? Je me demande comment exprimer les dépendances entre les deux. Si un skill indique qu’il “nécessite l’usage de la ligne de commande, Python, tool A et tool B”, est-ce que cela signifie que ces outils sont activés ensemble au chargement du skill ?
Ce qu’il faut vraiment remarquer, c’est que tout le monde s’est focalisé à l’excès sur MCP et a agi de manière dépendante du chemin. Ce qui est vraiment intéressant, c’est simplement le “tool call” lui-même. Le tool call est réellement utile et impressionnant. MCP n’est qu’un des nombreux moyens d’y parvenir. Et ce n’est même pas une méthode si exceptionnelle que ça
Je pense que si MCP s’est autant répandu, c’est avant tout une question de timing. Il existait déjà des appels d’outils avant MCP, mais les modèles étaient mauvais pour s’en servir. L’arrivée de MCP a coïncidé précisément avec le moment où les modèles ont commencé à bien utiliser les appels d’outils. Donc, au fond, l’essentiel de l’engouement autour de MCP, c’est que les gens ont découvert que les LLM pouvaient appeler des outils pour interagir avec d’autres systèmes
Un serveur MCP est en pratique un registre qui enregistre des tool calls. Qu’est-ce qui est donc moins bon que de simples tool calls ?
Ce qui donne du sens à MCP, c’est qu’il apprend aux LLM la notion d’oauth. C’est ce qui rend possibles les appels d’outils basés sur un serveur. Avant, il fallait installer séparément chaque CLI qu’on voulait utiliser et gérer l’authentification dans chacun d’eux. Le tool calling est bien le plus grand atout des LLM, mais je pense aussi que le fait de mettre en avant le message “il faut se soucier de l’authentification des outils” a une vraie valeur
À noter au passage que MCP aussi est une fonctionnalité qu’Anthropic a innovée
Même en mettant Skills de côté, je me demande ce qui ferait une meilleure approche que MCP
L’influence de MCP va bien au-delà du terminal. On peut l’utiliser dans ChatGPT, Claude Web, n8n et LibreChat, et cela intègre aussi des réflexions sur l’authentification, les ressources, voire l’UI (
apps-sdk, etc.). Si l’on raisonne surtout en workflows de code ou en agents CLI (comme Claude Code), les outils CLI ont évidemment une énorme valeur. Mais dans des domaines comme le CRM, les ventes, le support, les opérations ou la finance, les outils basés sur MCP sont une forme plus adaptée. Skills et MCP ne sont pas concurrents, ils ont des objectifs complémentaires. Le vrai saut se produit surtout quand le code Python d’un Skill peut appeler directement MCP via l’interpréteur (nous l’avons fait aussi, et cela fonctionne très bien)Par rapport aux outils basés sur le terminal, l’un des grands avantages de MCP est qu’il peut fonctionner sans sandbox de type environnement Linux totalement isolé. Et on peut aussi l’utiliser avec des modèles bien plus simples. Même un modèle tournant sur un laptop ou un téléphone peut gérer deux ou trois MCP sans problème. Honnêtement, demander à ce genre de modèle de lire des fichiers et d’exécuter
curlde façon fiable, c’est trop lui demanderIntégrer les LLM à des logiciels externes ou au monde physique donne en ce moment une impression vraiment formidable. Et tout cela devient possible en langage naturel. Le LLM peut même générer le code d’un serveur MCP, ce qui permet de créer très facilement des capacités entièrement nouvelles
Honnêtement, je pense que MCP est surévalué et que ses limites sont évidentes. Aujourd’hui, 95 % des serveurs MCP ne servent à rien et pourraient simplement être remplacés par de simples tool calls
Évidemment, un serveur MCP bien conçu, c’est vraiment bien. En revanche, un serveur MCP bâclé crée des problèmes encore plus graves. En général, toutes les équipes produit subissent la pression de devoir absolument créer un serveur MCP juste parce que “MCP est à la mode”. Les clients aussi ont forcément des objectifs liés à l’usage de l’IA, donc ils demandent ce genre de chose. Mais en pratique, ils ne savent pas vraiment ce qu’ils veulent ; il suffit juste de pouvoir dire “il y a de l’IA dedans”. Les équipes produit, elles aussi, n’observent pas forcément d’effet clair à l’adoption de l’IA, mais grâce à MCP elles peuvent rapidement promouvoir quelque chose comme “notre produit est un produit IA”. C’est un phénomène assez déconnecté de la substance réelle de l’IA
MCP oblige à faire confiance au fournisseur du serveur. En pratique, on dépend de l’honnêteté du serveur. En réalité, une entreprise comme Uber utilisera toutes sortes de prompt engineering pour pousser en permanence le LLM à considérer son service comme la meilleure option. Au final, les incitations entre l’éditeur MCP et le consommateur sont totalement désalignées
Je suis d’accord pour dire que le tool call est l’essentiel. Mais MCP a au moins deux avantages sur le CLI. D’une part, lorsque les tool-call LLM demandent une sortie structurée et doivent mettre en œuvre des interactions complexes, MCP est plus simple que le CLI. D’autre part, l’état entre les appels d’outils peut être conservé naturellement côté serveur MCP. Au départ, je me demandais moi aussi si je ne m’étais pas laissé emporter trop facilement par le hype, mais un petit démonstrateur récent que j’ai créé pour apprendre MCP (https://github.com/cournape/text2synth) a été plus simple à réaliser qu’une version CLI, et je pense que c’est un bon exemple du potentiel étonnant de MCP
Les serveurs MCP ont l’air extrêmement populaires chez les hackers. Il y a énormément d’instances mal configurées et déployées à la va-vite. Les entreprises ont pratiquement supprimé toutes leurs lignes de défense habituelles au déploiement
Notre équipe frontend tire une valeur énorme du MCP de Figma. Une tâche qui prenait trois semaines a pu être terminée en une seule journée
Moi aussi, j’ai construit quelque chose d’équivalent aux skills avec quelques fichiers Markdown. Il suffit de rappeler le skill à l’agent une fois par session environ. Je ne vois pas vraiment ce qu’il y a de si spécial au fait que Claude fasse cela
L’important, c’est aussi de mettre un nom sur un certain type de pattern. C’était déjà un pattern utile que beaucoup de gens avaient découvert et utilisaient naturellement, mais le fait de lui donner un nom permet des discussions plus avancées. Anthropic a aussi identifié que ce pattern aidait à résoudre le problème chronique de “pollution du contexte” dans les agents de code. Les anciens AGENTS.md ou MCP injectaient trop d’informations dans le contexte, au point de devenir peu pratiques, alors que le pattern skills est bien plus efficace
J’ai l’impression qu’il s’agit d’une structuration officielle d’un problème déjà résolu, avec un peu plus d’automatisation. Parmi les MCP que j’avais essayés auparavant, beaucoup n’étaient en fait qu’une recherche documentaire un peu sophistiquée ; j’espère que ce type de skills pourra les remplacer
Je me pose la même question. J’utilise déjà cela avec Aider ou CC depuis plus d’un an
C’est peut-être un peu négatif, mais j’aimerais voir si d’autres ressentent la même chose. Si on demande à un utilisateur moyen de configurer lui-même ce genre de services, sa réaction normale sera de se dire “vous êtes fous ?”. La plupart des gens veulent simplement se connecter, demander quelque chose, et que le système s’occupe du reste. MCP, Apps, Skills, Gems, etc. posent tous le mauvais problème. C’est un peu comme ces chaînes YouTube qui, tous les six mois, répètent que “ce nouveau langage ou framework est le meilleur”, recréent une todo app, puis refont pratiquement la même vidéo jusqu’à six fois. On n’a que des améliorations superficielles et répétitives, sans résoudre le problème de fond. Il y a quelque chose qui tourne mal quelque part dans ce genre de technologie ; dès que l’argent se concentre dessus, on ne voit plus que ce type d’annonces, puis la release suivante, puis les promotions et les changements de poste, sans qu’il reste de vraie valeur fondamentale
À propos de l’idée que le problème de fond ne serait pas résolu : aujourd’hui, les solutions embarquent carrément de nouveaux problèmes dans le package. On ouvre la boîte, et le problème comme la solution en jaillissent en même temps, se poursuivant mutuellement pendant qu’ils fuient l’un l’autre. Et on a l’impression d’être devenu un humain technologiquement plus avancé
Concernant l’idée que MCP, Apps, Skills, Gems, etc. travaillent tous sur le mauvais problème, mon point de vue pessimiste est qu’on fabrique davantage de documentation et d’API pour l’IA, alors qu’on aurait probablement obtenu des résultats similaires en produisant simplement de la documentation pour des humains. J’ai passé la moitié de mon temps à me faire entraîner dans du débogage de systèmes complexes dépourvus de documentation
Je me demande ce qu’est exactement ce “problème de fond”, et à quel rythme on le résolvait avant la popularisation de ChatGPT auprès du grand public en 2023
Pour reprendre l’exemple de la “todo app refaite six fois avant d’être oubliée”, je ne vois pas bien en quoi c’est un problème. La technologie progresse justement de manière incrémentale et itérative. Demain, quelqu’un publiera encore une vidéo sur “le meilleur framework frontend”, et avant c’était Nextjs, avant cela React, Angular, JQuery, PHP ou HTML, avec essentiellement la même logique. Si tout l’argent n’avait pas afflué vers l’IA, on en serait probablement encore à GPT-3 et Claude 2. Côté outils, il en sort parfois de médiocres (moi, je trouve que Skills est plutôt bon), mais ce n’est pas une raison pour dire que toute l’industrie est pourrie
Enfin, tout cela n’en est encore qu’à ses débuts et personne ne sait vraiment ce qui fonctionne. Cela ressemble à des tentatives superficielles, mais c’est en réalité la pointe de l’état de l’art
C’est un concept complètement différent. MCP sert à connecter des services externes et inclut même la gestion de l’authentification, comme oauth. Skills, au fond, c’est essentiellement une combinaison d’outils CLI et de prompts. Les domaines d’usage sont différents, donc la comparaison est difficile. À titre indicatif, avant l’arrivée de MCP, nous utilisions aussi en interne un système appelé Skillset ; avec le recul, j’ai l’impression que c’était le meilleur hybride, combinant les avantages de MCP et de Skills
C’est vraiment exagéré