Pourquoi les CLIs, Agent Frameworks, MCP Apps et Agent Skills sont l'avenir du développement logiciel
L'ancien modèle applicatif est en train de mourir. Voici ce qui le remplace.
Le changement que personne n'avait vu venir : 11 393 outils d'agents IA en 12 mois
Les outils d'agents IA — CLIs, frameworks, serveurs MCP et skills permettant aux agents d'interagir avec le monde réel — ont explosé en passant d'une poignée d'expérimentations à un écosystème de 11 393 outils d'agents IA indexés en seulement douze mois. C'est ce que révèle le rapport de SkillsIndex de février 2026, qui suit les outils d'agents IA sur cinq grands écosystèmes : serveurs MCP (4 133), OpenClaw Skills (2 471), GPT Actions (1 818), plugins IDE (1 760) et Claude Skills (1 211).
Il y a douze mois, si vous aviez dit à la plupart des développeurs que les interfaces en ligne de commande allaient faire un retour en force, que les outils d'agents IA allaient absorber les logiciels via des protocoles standardisés, et que les « skills » remplaceraient les plugins traditionnels — on vous aurait ri au nez. Et pourtant, nous y sommes.
Les chiffres racontent une histoire de transformation profonde. 92 % des développeurs américains utilisent désormais des outils de codage IA au quotidien — un chiffre si stupéfiant que le dictionnaire Collins a nommé le « vibe coding » son Mot de l'Année 2025. Le marché du vibe coding a atteint 4,7 milliards de dollars. Nous n'assistons pas à une tendance. Nous assistons à une transition de phase.
Le logiciel se reconstruit autour des agents IA, et non des humains. L'interface graphique — le paradigme dominant depuis les années 1980 — devient une préoccupation secondaire. Ce qui compte désormais, c'est de savoir si un agent peut invoquer votre logiciel, comprendre ses résultats et l'intégrer dans des workflows plus larges.
Ce n'est pas de la spéculation. C'est en production aujourd'hui. Et si vous développez des logiciels en 2026 sans comprendre ce changement, vous construisez pour un monde qui disparaît rapidement.
Les quatre piliers du nouveau stack
Avant d'entrer dans les détails, posons l'architecture. Le nouveau stack logiciel pour le développement IA-natif repose sur quatre piliers interdépendants :
Les interfaces en ligne de commande (CLIs) — Le paradigme d'interface le plus ancien, aujourd'hui réincarné comme la façon la plus efficace pour les agents IA d'interagir avec les outils. Zéro surcharge d'interface. Efficacité maximale des tokens. Les modèles savent déjà les utiliser.
Les Agent Frameworks — La couche d'orchestration qui se situe entre les modèles IA et le monde extérieur. Pensez-y comme au système d'exploitation des agents : gestion de la mémoire, planification des tâches, routage des skills et gestion des canaux.
Le Model Context Protocol (MCP) — Le standard universel pour l'intégration d'outils qui a accompli ce que des années d'approches fragmentées n'avaient pas réussi : une véritable interopérabilité entre les fournisseurs d'IA.
Les Agent Skills — Des packages déclaratifs qui enseignent aux agents de nouvelles capacités sans nécessiter de modifications du code du modèle ou du framework d'agent sous-jacent.
Ces quatre piliers ne se font pas concurrence — ils se composent. Un setup d'agent IA en production combine généralement les quatre : un agent framework orchestrant plusieurs skills, dont certains invoquent des outils CLI, d'autres se connectent via MCP, le tout travaillant ensemble pour accomplir des tâches qui auraient nécessité un développement sur mesure il y a encore un an.
Examinons chaque pilier en détail.
CLIs : pourquoi le terminal est de retour
Le terminal n'a jamais vraiment disparu. Il s'est simplement effacé de l'attention grand public pendant que les interfaces graphiques dominaient le logiciel grand public. Mais les agents IA n'ont pas d'yeux. Ils ne cliquent pas sur des boutons et ne naviguent pas dans des hiérarchies visuelles. Ils traitent du texte. Et la ligne de commande, c'est du texte pur.
C'est d'une importance capitale pour l'efficacité. L'analyse de Jannik Reinhard de février 2026 fournit le chiffre le plus parlant : accomplir la même tâche (lister les appareils Intune non conformes) a consommé environ 145 000 tokens via MCP contre 4 150 tokens via CLI. Soit une réduction de 35 fois.
Pourquoi une différence si frappante ? MCP requiert une négociation de schéma, des formats structurés requête/réponse et des définitions d'outils explicites. Les CLIs n'ont besoin de rien de tout cela. L'agent invoque simplement une commande et analyse le résultat. Tous les grands modèles de langage ont été entraînés sur des millions de pages de manuel, de fichiers README et de réponses Stack Overflow portant sur les outils CLI. Ils savent déjà comment fonctionne grep. Ils comprennent déjà jq. Ils n'ont pas besoin d'un schéma pour cela.
Les grands laboratoires d'IA l'ont bien compris. Claude Code 2.1 (sorti en janvier 2026) fonctionne principalement via des commandes terminal, avec le rechargement à chaud des skills et des sous-agents en fork construits autour de workflows CLI-first. GPT-5.3-Codex, lancé le 5 février 2026, est disponible via CLI en plus de l'intégration IDE — et la version CLI est souvent préférée par les utilisateurs avancés pour ses performances supérieures de 25 %. Gemini 3.1 Pro, sorti le 19 février 2026, atteint 77,1 % sur les benchmarks ARC-AGI-2 et excelle dans les tâches de raisonnement basées sur CLI.
L'implication concrète : si vous développez un outil pour développeurs en 2026, le CLI-first n'est plus optionnel. Votre outil sera utilisé par des agents. Ces agents seront beaucoup plus efficaces — et donc moins coûteux à faire fonctionner — lorsqu'ils pourront utiliser un CLI bien conçu plutôt que de naviguer dans une interface web ou même dans une API structurée.
# Ce qu'un agent IA exécute réellement
gh pr list --state open --json number,title,author | \
jq '.[] | select(.author.login != "dependabot[bot]")'
# vs. naviguer dans l'interface web de GitHub
# vs. plusieurs appels d'outils MCP avec surcharge de schéma
Le CLI n'est pas de la nostalgie. C'est l'interface la plus pratique pour les utilisateurs non humains.
Agent Frameworks : le système d'exploitation des agents
Les modèles de langage bruts sont sans état. Ils traitent un prompt, génèrent une réponse et oublient tout. C'est un avantage pour certains cas d'usage et une limitation catastrophique pour d'autres. Si vous voulez un agent qui se souvient de vos préférences, planifie des tâches, gère plusieurs canaux de communication et coordonne des workflows complexes, il vous faut quelque chose entre le modèle et le monde.
Ce quelque chose, c'est un agent framework.
Les Agent Frameworks fournissent l'infrastructure qui transforme un modèle de langage en agent opérationnel :
-
Mémoire — Stockage persistant qui survit entre les sessions. Court terme (contexte de conversation), long terme (préférences apprises, informations sur l'utilisateur) et épisodique (ce qui s'est passé et quand).
-
Planification — Capacités de type cron pour les tâches récurrentes. Consulter les e-mails chaque matin. Résumer les actualités à 18h. Effectuer des audits de sécurité chaque semaine.
-
Routage des Skills — Dispatch intelligent vers le bon outil pour chaque tâche. Quand l'utilisateur demande la météo, router vers le skill météo. Quand il parle de son calendrier, router vers le skill calendrier.
-
Gestion des canaux — Interface unifiée sur les plateformes de communication. Le même agent accessible via Telegram, Discord, Slack ou e-mail.
-
Orchestration des outils — Gestion de l'exécution des commandes CLI, des appels MCP et des intégrations API directes, avec gestion des erreurs, des tentatives et du contexte.
OpenClaw est un exemple d'agent framework en production, avec plus de 500 skills sur ClawHub et 53 skills officiels pour les tâches courantes. Mais le pattern est plus important que n'importe quelle implémentation spécifique. Des entreprises comme Context Studios font tourner des setups d'agent framework en production qui combinent systèmes de mémoire, cron jobs, multiples intégrations de canaux et des dizaines de skills pour créer des expériences d'agent cohérentes.
L'agent framework est le système d'exploitation. Le modèle n'est que le CPU.
Sans agent framework, vous avez un chatbot. Avec un agent framework, vous avez un agent capable de vraiment accomplir des tâches — planifier des réunions, surveiller des systèmes, gérer des pipelines de contenu, répondre aux incidents — sans nécessiter qu'un humain déclenche chaque action.
MCP : le protocole qui a gagné
Dans le monde fragmenté des outils IA d'avant 2024-2025, chaque plateforme avait sa propre approche pour l'intégration d'outils. OpenAI avait le function calling. Anthropic avait le tool use. Google avait ses propres patterns d'API. Connecter un outil à plusieurs fournisseurs d'IA signifiait implémenter la même logique plusieurs fois, avec des incompatibilités subtiles.
Le Model Context Protocol (MCP) a changé la donne. Développé initialement par Anthropic, MCP a été cédé à l'Agentic AI Foundation sous l'égide de la Linux Foundation début 2026, avec le soutien fondateur d'Anthropic, Block et OpenAI. Ce choix de gouvernance a signalé clairement que MCP n'était pas un outil propriétaire — c'était une infrastructure.
Les chiffres d'adoption sont vertigineux. Les téléchargements du SDK MCP ont atteint 97 millions par mois en février 2026 — une augmentation de 970 fois en douze mois. Des SDK existent désormais pour Python, TypeScript, C#, Java et .NET. Plusieurs registres ont émergé : Smithery répertorie plus de 2 200 serveurs MCP, MCP.so en suit plus de 3 000, et le registre officiel propose des options sélectionnées avec soin.
Que fournit concrètement MCP ? D'après l'aperçu technique d'IBM :
-
Définitions d'outils standardisées — Un format de schéma qui décrit ce que fait un outil, les paramètres qu'il accepte et ce qu'il retourne.
-
Ressources de contexte — Un moyen pour les outils d'exposer des données lisibles par les modèles, permettant aux outils de partager état et informations.
-
Abstraction du transport — À l'origine, prise en charge de stdio et SSE, recommandant désormais le Streamable HTTP comme mécanisme de transport principal.
-
Prompts — Templates de prompts réutilisables que les outils peuvent fournir aux modèles.
MCP a transformé l'intégration d'outils, faisant passer d'une charge d'implémentation par fournisseur à un pattern « écrire une fois, fonctionner partout ». Construisez un serveur MCP et il fonctionne avec Claude, GPT, Gemini et tout autre système parlant le protocole.
// Un exemple minimal de serveur MCP
import { Server } from "@modelcontextprotocol/sdk/server";
const server = new Server({
name: "example-server",
version: "1.0.0"
});
server.setRequestHandler("tools/list", async () => ({
tools: [{
name: "get_weather",
description: "Get current weather for a location",
inputSchema: {
type: "object",
properties: {
location: { type: "string", description: "City name" }
},
required: ["location"]
}
}]
}));
server.setRequestHandler("tools/call", async (request) => {
if (request.params.name === "get_weather") {
const location = request.params.arguments.location;
// ... récupération effective de la météo
return { content: [{ type: "text", text: `Weather in ${location}: 22°C, sunny` }] };
}
});
C'est la fondation. Mais MCP a évolué bien au-delà des simples appels d'outils vers quelque chose de bien plus ambitieux.
MCP Apps : quand les outils s'dotent d'une interface
Le 26 janvier 2026, l'équipe MCP a annoncé les MCP Apps — une extension qui change le paradigme en permettant aux outils de retourner des composants d'interface interactive directement dans les conversations.
Jusqu'alors, les outils MCP retournaient du texte ou des données structurées. Le modèle formatait ensuite ces données pour les présenter à l'humain. Les MCP Apps changent cette équation : les outils peuvent désormais retourner des tableaux de bord, des formulaires, des visualisations et des éléments interactifs qui s'affichent directement dans l'interface de conversation.
Imaginez ce que cela signifie :
- Un outil de base de données ne retourne pas seulement des résultats de requête en JSON — il affiche un tableau interactif avec tri, filtrage et édition en ligne.
- Un outil d'analyse ne décrit pas seulement des métriques — il affiche des graphiques qui se mettent à jour en temps réel.
- Un workflow riche en formulaires ne nécessite pas que le modèle pose les questions une par une — il présente une interface de formulaire complète que l'utilisateur remplit.
Cela redéfinit ce que signifie « une application ». Les applications traditionnelles sont des expériences autonomes avec leurs propres fenêtres, leur navigation et leur gestion d'état. Les MCP Apps sont des capacités qui émergent dans les conversations au besoin. L'interface de chat devient un conteneur d'applications universel.
Les implications pour le développement logiciel sont profondes. Construire « une application » signifie de plus en plus construire un serveur MCP qui retourne des composants d'interface appropriés, et non un frontend autonome. Le canal de distribution n'est pas un app store — c'est n'importe quel assistant IA prenant en charge les MCP Apps.
Nous en sommes encore aux débuts. La spécification des MCP Apps évolue et la prise en charge côté client varie. Mais la trajectoire est claire : la frontière entre « outils » et « applications » se dissout.
Agent Skills : du logiciel sans code
Là où MCP fournit la couche protocolaire pour l'intégration d'outils, les Agent Skills représentent une abstraction de plus haut niveau : des packages déclaratifs qui enseignent aux agents de nouvelles capacités.
D'après l'enquête exhaustive de la communauté DEV, SKILL.md s'impose comme un standard de facto pour Claude Code, Codex CLI et Gemini CLI. Un skill est généralement un fichier markdown qui décrit :
- Quand le skill doit être activé
- Quels outils/commandes il peut utiliser
- Comment accomplir des tâches spécifiques
- Des exemples et cas particuliers
# SKILL.md - Weather Skill
## Description
Get current weather and forecasts for any location.
## When to Use
- User asks about weather, temperature, or forecasts
- User mentions going outside or planning activities
## Tools
- `curl wttr.in/{location}` — Quick weather lookup
- `weather-cli --json` — Structured weather data
## Examples
User: "What's the weather in Berlin?"
→ Run: curl wttr.in/Berlin?format=3
→ Parse output, respond conversationally
User: "Should I bring an umbrella tomorrow?"
→ Run: curl wttr.in/Berlin?format=%C+%t+%w
→ Check for rain indicators, advise accordingly
C'est du logiciel sans code traditionnel. Le skill n'implémente pas une fonctionnalité météo — il apprend à l'agent comment utiliser les outils existants pour accomplir des tâches liées à la météo. La connaissance est déclarative, non procédurale.
L'écosystème a évolué rapidement. SkillsIndex rapporte 11 393 outils sur les cinq grands écosystèmes. Des marketplaces ont émergé : SkillsMP héberge environ 96 000 skills, ClawHub environ 5 700, SkillHub environ 7 000, et la liste sélectionnée awesome-oc en recense près de 3 000.
Les skills représentent un changement de paradigme dans notre façon de concevoir la distribution logicielle. Au lieu d'installer des applications, les utilisateurs installent des capacités. Au lieu de maintenir des bases de code, les développeurs maintiennent des packages de connaissance. L'agent fournit le runtime ; les skills fournissent les instructions.
La crise de qualité
La croissance rapide de l'écosystème d'outils a créé un problème prévisible : la qualité est extrêmement variable.
L'analyse de SkillsIndex de février 2026 a relevé un score de qualité moyen de seulement 44,7 sur 100 sur l'ensemble des outils indexés. Ce n'est pas surprenant — nous avons déjà vu ce pattern avec les packages npm, les extensions de navigateur et les applications mobiles. Des barrières d'entrée faibles signifient une grande variance de qualité.
Mais les enjeux sont plus élevés avec les outils d'agents. Un package npm de mauvaise qualité peut avoir des bugs. Un serveur MCP de mauvaise qualité peut avoir des failles de sécurité qui exposent des données utilisateurs, exécutent du code arbitraire ou divulguent des identifiants à des tiers.
Les préoccupations sont concrètes :
-
Pas de standard de sandboxing — Les serveurs MCP s'exécutent généralement avec les mêmes permissions que le processus hôte. Un serveur malveillant pourrait accéder au système de fichiers, au réseau et aux identifiants.
-
Modèle de confiance flou — Quand un agent invoque un outil MCP, qui est responsable du résultat ? L'utilisateur qui l'a installé ? L'agent qui l'a appelé ? Le développeur qui l'a construit ?
-
Adoption enterprise bloquée — De nombreuses organisations ne déploieront pas d'outillage agent tant que ces questions de sécurité n'auront pas de réponses claires.
La solution n'est pas de freiner la croissance de l'écosystème — ce train est parti. La solution réside dans une meilleure curation, des standards de sécurité plus clairs et des outils qui facilitent l'audit de ce que les outils d'agents font réellement.
Certains progrès s'opèrent. Le registre MCP officiel applique une vérification de base. Les agent frameworks enterprise mettent en place des systèmes de permissions et des journaux d'audit. Mais l'écart de qualité entre les meilleurs outils et les outils médians reste énorme.
Si vous construisez des outils d'agents pour un usage en production, la qualité est un avantage concurrentiel. Si vous les consommez, la curation importe plus que l'abondance du choix.
CLI vs MCP : le grand débat
Un débat animé a émergé dans la communauté du développement d'agents : faut-il utiliser des outils CLI ou des serveurs MCP ? Des articles comme "Why CLI is the New MCP for AI Agents" d'OneUptime et l'analyse de l'efficacité des tokens de Jannik Reinhard ont alimenté le débat.
La réponse est : ce n'est pas l'un ou l'autre. Les deux approches ont des atouts distincts, et les agents sophistiqués utilisent les deux.
Avantages du CLI :
- Efficacité des tokens — 35 fois moins de tokens pour des tâches équivalentes dans l'analyse de Reinhard
- Zéro surcharge de schéma — Aucune définition d'outil requise ; les modèles connaissent déjà les CLIs courants
- Écosystème existant — Des milliers d'outils en ligne de commande matures et bien testés
- Composabilité — Les pipes Unix et le scripting shell permettent des combinaisons puissantes
Avantages du MCP :
- Découvrabilité — Les définitions structurées d'outils indiquent exactement aux agents ce qui est disponible
- Typage fort — Les schémas d'entrée préviennent les requêtes mal formées
- Retours riches — Les MCP Apps permettent des composants d'interface, pas seulement du texte
- Cohérence multi-fournisseurs — Le même serveur fonctionne sur tous les agents compatibles MCP
L'approche hybride utilise les CLIs pour les outils bien connus où l'efficacité est primordiale (git, curl, jq, utilitaires Unix standards) et MCP pour les intégrations personnalisées, les API propriétaires et les cas où une interaction riche est nécessaire.
Un skill d'agent bien conçu pourrait ressembler à ceci :
# SKILL.md - Kubernetes Management
## CLI Tools (prefer for efficiency)
- kubectl — All standard k8s operations
- helm — Package management
- k9s — Interactive cluster exploration (if TTY available)
## MCP Servers (for rich integrations)
- k8s-mcp-server — Dashboard views, resource graphs, anomaly detection
- prometheus-mcp — Metrics visualization with interactive charts
## Routing Logic
- Simple queries (get pods, describe service) → kubectl
- Complex visualizations (cluster health dashboard) → k8s-mcp-server
- Metric exploration → prometheus-mcp
Le débat passe à côté de l'essentiel. La question n'est pas de savoir quelle approche l'emporte — c'est comment les combiner intelligemment.
Architecture réelle : à quoi ça ressemble en production
Ancrons tout cela dans une architecture concrète. Un setup d'agent IA en production en 2026 comprend généralement :
Couche 1 : l'Agent Framework
- Mémoire persistante (store sémantique pour les faits, store épisodique pour les événements)
- Planificateur cron pour les tâches récurrentes
- Support multi-canaux (Telegram, Slack, Discord, e-mail)
- Moteur de routage des skills
- Gestion du contexte (historique des conversations, préférences utilisateur)
Couche 2 : les Skills
- 20 à 50 skills couvrant les domaines courants (calendrier, e-mail, météo, notes, etc.)
- Skills personnalisés pour les workflows spécifiques au domaine
- Les skills routent vers les outils appropriés (CLI ou MCP) selon la tâche
Couche 3 : la couche Outils
- Outils CLI installés sur l'hôte (git, curl, jq, ripgrep, etc.)
- Serveurs MCP tournant en local ou à distance
- Intégrations API directes pour les services sans support MCP
Couche 4 : le Modèle
- Modèle principal pour le raisonnement complexe (Claude Opus 4.6, GPT-5.3)
- Modèle plus rapide/moins coûteux pour les tâches simples (Claude Sonnet 4.6, GPT-5.3 mini)
- Modèles spécialisés pour des domaines spécifiques selon les besoins
Le flux de données :
- Le message de l'utilisateur arrive via un canal (Telegram, Slack, etc.)
- L'Agent Framework charge le contexte pertinent (historique de conversation, profil utilisateur, mémoires récentes)
- Le routeur de skills détermine quel(s) skill(s) s'appliquent
- Les instructions du skill sélectionné guident l'approche du modèle
- Le modèle génère des appels d'outils (commandes CLI ou requêtes MCP)
- L'Agent Framework exécute les outils, gère les erreurs et les tentatives
- Les résultats reviennent au modèle pour interprétation
- Le modèle génère une réponse
- L'Agent Framework persiste les informations pertinentes en mémoire
- La réponse est délivrée à l'utilisateur via le canal d'origine
Cette architecture tourne en production dans de nombreuses organisations. Les implémentations spécifiques varient, mais le pattern est constant : agent framework + skills + outils + modèle.
Ce que ça signifie pour les développeurs
Si vous êtes développeur en 2026, le paysage a fondamentalement changé :
Les SaaS traditionnels seront consommés via MCP. Toutes les grandes plateformes SaaS construisent ou ont déjà des intégrations MCP. Salesforce, HubSpot, Jira, GitHub — tous. Si votre workflow implique de cliquer dans des interfaces web, ces clics seront de plus en plus des actions d'agents via MCP.
Les CLIs deviennent l'interface principale. Pas pour vous — pour les agents qui travaillent en votre nom. Des CLIs bien conçus avec des formats de sortie clairs et une aide exhaustive ont plus de valeur que jamais.
Les Skills deviennent les nouveaux packages npm. Au lieu d'importer des bibliothèques à utiliser dans du code, vous installez des skills que les agents utilisent pour accomplir des tâches. L'écosystème de skills est le nouvel écosystème de packages.
Votre rôle évolue de la construction d'interfaces à la construction de capacités. Le frontend compte moins quand les utilisateurs interagissent via des agents conversationnels. Ce qui compte, c'est ce que votre logiciel peut faire, pas son apparence.
Cela ne signifie pas que le développement d'interfaces disparaît. Les MCP Apps ont besoin d'interfaces. Certains workflows bénéficieront toujours de la manipulation directe. Mais le centre de gravité se déplace vers des capacités consommables par les agents.
Implications pratiques :
- Construisez des interfaces CLI pour vos outils, pas seulement des API
- Implémentez des serveurs MCP pour les intégrations complexes
- Rédigez une documentation exhaustive — les agents la lisent
- Concevez pour la composabilité — votre outil fera partie de workflows plus larges
- Pensez du point de vue de l'agent — de quelle information a-t-il besoin pour utiliser votre outil efficacement ?
Ce que ça signifie pour les entreprises
Les implications business sont tout aussi significatives :
Les structures de coûts changent. Si les outils CLI sont 35 fois plus efficaces en tokens que MCP pour des tâches équivalentes, et si les coûts de tokens représentent une dépense opérationnelle significative, le choix des outils impacte directement les marges. Optimiser les workflows d'agents pour l'efficacité devient une vraie préoccupation business.
La vitesse s'accélère. Avec 92 % des développeurs américains utilisant des outils de codage IA au quotidien, la vélocité de développement a augmenté de façon spectaculaire. Les entreprises qui n'adoptent pas ces outils livrent plus lentement que leurs concurrents.
De nouvelles catégories de services émergent :
- Développement de serveurs MCP — Construire des intégrations pour les entreprises qui en ont besoin
- Création de skills — Packager l'expertise métier sous forme de skills d'agent
- Personnalisation d'Agent Frameworks — Configurer et étendre l'infrastructure des agents
- Opérations d'agents — Gérer, surveiller et optimiser les agents en production
Les catégories existantes évoluent :
- Le DevOps devient agent ops — Déployer et maintenir l'infrastructure des agents
- La rédaction technique devient la rédaction de skills — La documentation comme connaissance exécutable
- Le SaaS devient un SaaS agentique — Des applications consommées par des agents, pas seulement par des humains
Pour les entreprises qui adoptent ces technologies, les bénéfices se cumulent. Développement plus rapide, coûts opérationnels réduits et capacités qui évoluent avec l'écosystème des agents plutôt qu'avec les effectifs.
Les 12 prochains mois
Les prédictions sont risquées, mais la trajectoire semble claire :
Les MCP Apps vont engendrer un nouveau paradigme d'app store. On verra émerger des marketplaces spécifiquement pour les MCP Apps — des capacités interactives qui s'affichent dans les interfaces de chat. La distinction entre « installer une app » et « donner une nouvelle capacité à son agent » s'estompera complètement.
Les Skills vont converger vers SKILL.md (ou quelque chose d'équivalent). La fragmentation entre écosystèmes (Claude Skills, GPT Actions, OpenClaw Skills) se consolidera autour de standards partagés. Probablement SKILL.md ou quelque chose de très proche.
Le développement CLI-first dépassera le développement IDE-first. Claude Code, Codex CLI, Gemini CLI et leurs successeurs deviendront l'interface de développement par défaut pour une part significative des développeurs. L'IDE ne disparaîtra pas, mais le terminal sera le principal point d'interaction.
L'orchestration d'agents deviendra le nouveau DevOps. Tout comme nous avons développé des pratiques pour déployer et gérer des applications conteneurisées, nous développerons des pratiques pour déployer et gérer des systèmes d'agents. Observabilité, sécurité, fiabilité — toutes ces préoccupations se transposent au contexte des agents.
L'écart de qualité va se creuser avant de se résorber. À mesure que l'écosystème grandit, la variance de qualité va augmenter. Des collections d'outils premium et sélectionnés émergeront comme catégorie de produit. Les « serveurs MCP grade enterprise » seront un marché à part entière.
Les capacités des modèles de fondation compteront moins. À mesure que les agents accèdent à des outils, la valeur marginale des améliorations de modèles diminue. Un agent avec de bons outils et un modèle plus petit surpasse souvent un agent sans outils et un modèle plus grand. La compétition se déplace vers l'outillage.
Comment démarrer
Si vous avez lu jusqu'ici et voulez vous salir les mains, voici un point de départ pratique :
Étape 1 : installer un agent de codage CLI
# Option A : Claude Code
npm install -g @anthropic/claude-code
# Option B : Codex CLI
npm install -g @openai/codex-cli
# Option C : Gemini CLI
npm install -g @google/gemini-cli
Donnez-lui une vraie tâche dans une base de code que vous connaissez. Observez comment il utilise les outils.
Étape 2 : explorer les agent frameworks Jetez un œil à OpenClaw ou à des projets similaires. Comprenez comment ils gèrent la mémoire, le routage et le support multi-canaux. Essayez d'en configurer un pour votre propre usage.
Étape 3 : construire votre premier serveur MCP Commencez simplement — peut-être un serveur qui encapsule une API que vous utilisez déjà. Suivez l'excellent guide de démarrage de Neo4j ou la documentation officielle MCP.
Étape 4 : créer un skill personnalisé Rédigez un SKILL.md pour un workflow que vous effectuez régulièrement. Testez-le avec l'agent de votre choix. Itérez jusqu'à ce qu'il fonctionne de façon fiable.
Étape 5 : explorer l'écosystème Parcourez Smithery, MCP.so ou ClawHub. Voyez ce que d'autres ont construit. Trouvez l'inspiration. Identifiez les manques.
La courbe d'apprentissage est réelle mais gérable. Commencez par un élément, faites-le fonctionner, puis élargissez.
Conclusion
Le développement logiciel traverse son plus grand changement de paradigme depuis l'essor du web. Ce changement ne porte pas seulement sur de nouveaux outils — il s'agit d'une refonte fondamentale de la façon dont le logiciel est construit, distribué et consommé.
Les CLIs ne sont pas du passé — ils sont l'interface efficace pour les agents IA. Les Agent Frameworks ne sont pas une surcharge — ils sont le système d'exploitation des agents persistants et capables. MCP n'est pas juste un autre protocole — c'est le standard universel qui permet enfin l'interopérabilité des outils. Et les skills ne sont pas de simples automatisations — ce sont des logiciels déclaratifs qui enseignent aux agents de nouvelles capacités.
Les 11 393 outils indexés par SkillsIndex en février 2026 ne sont que le début. Les 97 millions de téléchargements mensuels du SDK MCP indiquent la direction que prend l'industrie. Les 92 % de développeurs utilisant des outils de codage IA au quotidien montrent que nous avons déjà franchi le seuil d'adoption.
C'est le nouveau stack. Apprenez-le, construisez avec, ou regardez depuis les gradins pendant que d'autres le font.
L'avenir du développement logiciel ne consiste pas à écrire du code. Il consiste à composer des capacités que les agents exécutent.
Vous souhaitez construire des logiciels IA-natifs ? Suivez notre blog pour des analyses approfondies sur le développement d'agents, l'intégration MCP et l'évolution de l'écosystème d'outils.