Une explication claire du passage des agents IA de la simple réponse aux questions à la livraison d'applications qui fonctionnent : ce que fait réellement le Model Context Protocol, comment les jetons délimités gardent les agents sous contrôle, la boucle exacte qu'un agent exécute pour créer, valider et publier une application, et ce qui distingue les plateformes agent-native des adaptations après coup.
Fondateurs, développeurs et équipes opérationnelles qui veulent comprendre ou utiliser des agents capables de construire et maintenir de vrais logiciels, pas seulement de discuter.
- Un modèle mental simple de MCP et la raison pour laquelle tous les grands labos d'IA l'ont adopté
- Une vision honnête du modèle de sécurité : ce qu'un jeton délimité permet et ne permet pas
- La boucle en six étapes qu'un agent exécute, du brief à l'application publiée
Un agent IA qui répond aux questions est utile. Un agent qui construit une application fonctionnelle, la connecte à une base de données et la publie sur un vrai domaine est un outil d'une tout autre nature. Le pont entre les deux est un petit standard volontairement ennuyeux appelé MCP, plus un modèle de permissions qui rend l'ensemble suffisamment sûr pour être utilisé. Voici comment cela fonctionne réellement, sans jargon.
MCP, le Model Context Protocol, est un standard ouvert qui permet à un agent IA d'utiliser des outils externes. Un service publie un menu d'actions qu'il sait exécuter (créer une app, modifier un fichier, lancer une validation) et tout agent compatible MCP peut lire ce menu et appeler ces actions. On le décrit souvent comme l'USB-C de l'IA : un connecteur unique qui fonctionne avec tous les modèles et tous les services, au lieu d'un câble sur mesure pour chaque paire.
Un modèle de langage seul ne peut que produire du texte. Il n'a pas de mains : il ne peut pas toucher une base de données, appeler une API ni publier un site web. Anthropic a publié MCP comme standard ouvert fin 2024 pour lui donner des mains de façon standardisée, et l'adoption a été exceptionnellement rapide. En deux ans, tous les grands labos d'IA l'avaient adopté, le registre public dépassait plusieurs milliers de serveurs et les SDK étaient téléchargés des dizaines de millions de fois par mois.
Si le protocole s'est répandu, la raison est économique, pas technique. Avant un protocole commun, connecter N modèles à M services signifiait construire et maintenir N fois M intégrations sur mesure. Avec un standard unique, un service livre un seul serveur MCP et fonctionne aussitôt avec chaque agent compatible, et un agent gagne l'accès à tous les services le jour où il parle le protocole. Le même calcul a porté l'USB, et l'histoire s'est terminée de la même façon : le connecteur a gagné.
La première réaction sensée face à une machine capable de créer et publier des logiciels est la méfiance, et la réponse honnête est que la sécurité dépend entièrement du modèle de permissions. Le mécanisme qui rend tout cela contrôlable est le jeton délimité, et il mérite d'être compris avec précision, car il fait la différence entre délégation et imprudence.
Quand vous connectez un agent à une plateforme, vous ne lui confiez pas votre compte. Vous créez un jeton, une clé aux permissions spécifiques et limitées, et l'agent opère strictement à l'intérieur de cette clôture. Tout ce qu'il fait est attribuable à ce jeton, et c'est vous qui tracez la clôture.
Un fondateur veut qu'un agent corrige le formulaire d'inscription de son application de réservation. Il génère un jeton limité à cette seule app, avec les permissions de modification et de validation, mais sans publication. L'agent effectue le changement et lance la validation ; le fondateur relit le diff, publie lui-même, puis révoque le jeton. Exposition totale : une app, deux permissions, vingt minutes. Voilà à quoi ressemble une délégation avec clôture.
Un agent qui construit un vrai logiciel ne produit pas le tout en une seule génération héroïque. Il exécute une boucle qui ressemble beaucoup à la façon de travailler d'un ingénieur rigoureux, simplement compressée de plusieurs jours à quelques minutes.
Un modèle peut toujours produire du code qui a l'air correct. Ce qui rend un logiciel construit par un agent digne de confiance, c'est le contrôle après chaque changement : un vrai portique qui dit soit que cela fonctionne, soit exactement ce qui a cassé. Sans lui, les agents dérivent avec assurance vers des états cassés. Avec lui, les erreurs sont attrapées à l'intérieur de la boucle, exactement comme les bons ingénieurs humains évitent de les livrer.
Beaucoup de produits ont greffé un serveur MCP sur une interface conçue pour des humains qui cliquent sur des boutons. Techniquement, cela fonctionne, mais ce n'est pas la même chose qu'une plateforme pensée pour les agents. Trois signes les distinguent.
Le test de symétrie est le filtre le plus rapide : sur une plateforme agent-native, un agent muni d'un jeton correctement délimité peut faire pratiquement tout ce qu'une personne peut faire via l'interface, c'est-à-dire créer une application, changer ses fichiers, valider, versionner et publier. Si le chemin agent est une porte latérale étroite avec la moitié des capacités, la plateforme traite l'automatisation comme une fonction de démonstration, et vous sentirez ce plafond au bout d'un mois d'usage réel.
Quand transformer un besoin décrit en logiciel fonctionnel ne demande plus à un humain de cliquer dans un builder, l'économie du petit logiciel change. Une équipe opérationnelle peut avoir son outil interne le jour où elle sait le décrire, au lieu du trimestre qui suit une bataille de priorisation. Un fondateur peut confier un brief sommaire à un agent le soir et relire une première version fonctionnelle le matin. Une entreprise peut s'offrir un logiciel taillé exactement pour un workflow, parce que le tailler ne coûte plus davantage que ce que vaut le workflow.
Rien de tout cela ne supprime le jugement humain. Quelqu'un décide toujours de ce qui mérite d'être construit, relit ce qui revient et assume le résultat. Ce qui change, c'est le coût de la distance entre une description claire et un produit qui fonctionne. Cette distance se mesurait en semaines et en factures. Elle se mesure désormais en minutes et en une relecture, et les entreprises qui l'intègrent tôt auront tout simplement plus de logiciels, mieux ajustés à leur façon de travailler, que celles qui attendent.
Le Model Context Protocol est un standard ouvert qui permet aux agents IA de découvrir et d'appeler les outils qu'un service propose (créer une app, modifier un fichier, lancer un contrôle), si bien que tout agent compatible peut travailler avec tout service qui publie un serveur MCP.
Oui, quand la plateforme lui donne de vrais outils avec un portique de validation : l'agent crée le projet, construit le modèle de données et les pages, valide après chaque changement, corrige ce que le contrôle détecte et publie. La partie fiable, c'est la boucle avec vérification, pas une génération géante.
Le jeton délimité sous lequel il opère. Vous le restreignez à des applications et des actions précises, chaque appel est enregistré, et vous pouvez le révoquer instantanément. Un agent doté d'un jeton de modification et de validation pour une app ne peut ni supprimer d'autres projets ni publier sans vous.
Appliquez le test de symétrie : avec un jeton correctement délimité, l'agent peut-il faire pratiquement tout ce qu'une personne peut faire, c'est-à-dire créer, modifier, valider, versionner, publier ? Si le chemin agent est un sous-ensemble étroit de l'interface humaine, l'automatisation était une réflexion après coup et vous atteindrez vite son plafond.