Inside Stainless: The Developer Tools Startup Anthropic Just Bought for $300 Million

Le monde numérique repose sur la communication entre ordinateurs, mais son architecture a été conçue avant l'avènement de l'intelligence artificielle. Aujourd'hui, on cherche à intégrer l'IA à Internet via le MCP (Model Context Protocol), qui transforme sites web et services en outils utilisables nativement par les IA. Les entreprises maîtrisant le MCP sont appelées à prospérer. Alex Ratray, fondateur et PDG de Stainless, une entreprise spécialisée dans les API pour des géants comme OpenAI et Anthropic, est l'invité pour discuter de cette révolution. Stainless développe également des serveurs MCP, et ses réflexions portent sur l'avenir du MCP, sa conception, ses défis de scalabilité, sa sécurité, et les modèles alternatifs pour l'accès des IA à Internet. Ratray, dont l'entreprise a débuté avant l'ère de l'IA, explique que les API (Application Programming Interface) sont le moyen par lequel les programmes informatiques communiquent, formant les "dendrites de l'Internet". Elles sont essentielles à l'automatisation et aux interactions inter-entreprises. L'arrivée des LLM (Large Language Models) introduit une nouvelle forme d'acteur dans ce paysage. Le MCP est présenté comme le système permettant aux LLM d'interagir avec les ordinateurs, mais son déploiement actuel révèle des difficultés. La vision du MCP est de permettre aux IA d'interagir avec des interfaces logicielles comme le ferait un humain, via des tableaux de bord, des formulaires et des clics. Cependant, les implémentations actuelles sont souvent limitées, offrant peu d'outils aux modèles. L'exemple concret d'une tâche courante, comme le remboursement d'un client et l'envoi d'un code de réduction, illustre la complexité des opérations actuelles. Un humain devrait naviguer dans plusieurs applications (système d'administration, tableau de bord Stripe, outil d'envoi d'e-mails, etc.), effectuer de nombreux clics et attendre les chargements. L'IA agentique promet de réaliser ces tâches de manière autonome. Pour cela, le MCP doit exposer une gamme d'outils aussi vaste que l'interface utilisateur ou l'API sous-jacente. Le défi majeur réside dans la taille de ces définitions d'outils, qui excèdent rapidement la fenêtre de contexte des LLM actuels. De plus, l'intégration de multiples services dans une seule interaction pose des problèmes de sécurité et de permissions. Les difficultés actuelles du MCP ne proviennent pas uniquement de ces limites de contexte, mais aussi de la manière dont les outils sont conçus. Beaucoup d'entreprises exposent l'intégralité de leur API, mais pour que les LLM fonctionnent efficacement, il faut souvent "tailler sur mesure" les outils MCP, en tenant compte de la manière dont le modèle pense. C'est un problème de recherche nouveau, car il est difficile de comprendre et d'adapter son approche à la "pensée" d'un LLM, contrairement à l'apprentissage du développement Python. Stainless travaille sur des solutions pour ces problèmes, notamment la gestion de chaînes d'actions complexes et la navigation dans de grandes quantités de données retournées par les API. L'un des défis est de trouver des informations spécifiques (comme les chaussettes rayées de Dan) dans une liste exhaustive de transactions. Concernant la conception de bons serveurs MCP, les principes clés incluent : 1. **Limiter le nombre d'outils :** Il est préférable d'avoir un ensemble restreint d'outils précis plutôt qu'une multitude d'outils génériques. 2. **Précision des noms et descriptions d'outils :** Les noms et descriptions doivent être clairs et spécifiques pour guider le LLM. 3. **Simplicité du schéma d'entrée :** Réduire le nombre de paramètres dans les requêtes et les décrire de manière concise. 4. **Minimalisme des données de réponse :** Retourner uniquement les informations strictement nécessaires au modèle. La gestion des données de réponse est complexe, car il est difficile de prévoir à l'avance quelles données le modèle recherchera. L'utilisation de filtres JQ pour le traitement du JSON est une technique employée. Le problème de la découverte d'outils est également crucial. Stainless propose un mode "dynamique" avec trois outils (lister les points de terminaison, obtenir des informations sur un point de terminaison, exécuter un point de terminaison) qui permet de gérer de grandes API, mais au prix de plusieurs tours de conversation pour chaque action. Ratray utilise lui-même les serveurs MCP, non pas pour le codage, mais pour des tâches métier. Il interroge sa base de données en lecture seule, HubSpot et Notion pour identifier des clients intéressants, analyser leur activité et croiser ces informations. Ces requêtes, bien que parfois instables en raison de la nouveauté de la technologie, fournissent des informations précieuses. Il utilise également un système de collecte de notes par l'IA, stockées dans un dépôt Git, pour pré-charger des informations utiles (citations clients, requêtes SQL) et éviter des recherches répétées. Cloud Code est utilisé pour alimenter ce dépôt. Le processus de création de contenu pour ce dépôt est encore en développement, mais il comprend des citations clients, des requêtes SQL pour des analyses de croissance, et des tentatives de résolution de tickets de support par l'IA. Bien que ces dernières ne soient pas toujours efficaces, elles améliorent l'efficience globale. La vision de Ratray pour l'avenir de l'IA est celle des "cyborgs" : une fusion entre les LLM et le code traditionnel (CPU) exécuté dans des environnements contrôlés. Plutôt que de proposer une multitude d'outils MCP, l'idée est de donner aux modèles un outil d'exécution de code (par exemple en TypeScript, utilisant le SDK de l'API) et un outil de recherche dans la documentation. Cela réduit considérablement l'impact sur la fenêtre de contexte, car le modèle écrit du code, qui est ensuite exécuté par le fournisseur de l'API. Les résultats de cette exécution sont ensuite interprétés par le modèle. Un avantage de cette approche est la rapidité d'exécution, car le code tourne directement à côté de l'API. Cependant, cela soulève la question : pourquoi ne pas laisser le modèle écrire le code que l'utilisateur exécuterait lui-même ? Ratray explique que les LLM ont encore du mal avec les bibliothèques, la gestion des versions et l'itération en cas d'erreurs. L'exécution du code par le fournisseur de l'API permet d'utiliser des SDK typés, qui offrent une vérification statique pour attraper les erreurs avant l'exécution. Le fournisseur de l'API peut également intégrer des sous-agents spécialisés pour aider le modèle à naviguer dans la documentation et à suggérer des corrections. La sécurité est un point crucial. Ratray estime que la sécurité doit être implémentée au niveau de l'API, idéalement via OAuth avec des permissions granulaires. L'idée est de créer un environnement d'exécution de code isolé ("sandbox") qui ne permette des connexions réseau qu'aux API autorisées. Stainless travaille sur une telle solution, commençant par des fournisseurs d'API uniques pour garantir la sécurité, puis envisageant d'étendre cela à des environnements multi-API. L'extension de cette capacité à générer du code exécutable pourrait transformer la manière dont les outils sont construits. Plutôt que de créer des outils MCP spécifiques, les développeurs pourraient se concentrer sur l'ingénierie des prompts pour guider le LLM dans l'utilisation du code et des API. Cette approche pourrait également automatiser des tâches répétitives identifiées lors d'interactions ponctuelles, transformant ainsi des "one-off" en logiciels automatisés. Le débat aborde également la tension entre la prudence nécessaire pour les grandes entreprises et l'approche "YOLO" (You Only Live Once) qui a souvent propulsé les innovations dans l'IA, comme avec Stable Diffusion pour la génération d'images ou Cloud Code pour le développement. Ratray envisage de proposer une version de cet environnement de code exécutable pour les développeurs individuels. Concernant les API les plus utilisées par les équipes de développement, l'API Gmail est citée comme un exemple majeur pour les assistants d'e-mails, permettant de créer des outils pour archiver, rédiger ou catégoriser des e-mails. L'approche basée sur l'exécution de code rendrait la création de nouveaux outils plus flexible et moins susceptible de casser les anciens. En conclusion, la vision est que la seule façon de réellement "construire des outils" sera via des instructions et des prompts, en exploitant la puissance complète des API. L'ingénierie des prompts deviendra centrale, bien que complexe. Stainless développe des MCP qui permettent aux développeurs de composer et d'écrire leurs propres outils en mélangeant les fonctionnalités des API sous-jacentes. Pour en savoir plus, les intéressés sont invités à visiter stainless.com.