Faire dialoguer différents systèmes logiciels est un défi classique pour les développeurs. Pendant des années, nous avons utilisé des API avec des règles bien définies pour y parvenir. Mais aujourd'hui, les grands modèles de langage (LLM) changent la donne, en offrant aux systèmes une nouvelle façon d'interagir basée sur la compréhension du langage, et pas seulement sur des formats stricts. Cela ouvre des possibilités passionnantes, mais présente également un nouvel ensemble de problèmes à résoudre - ce qui prouve une fois de plus que le travail d'un développeur n'est jamais vraiment terminé !
Voyons ce que cela signifie pour les développeurs.
Comment nous avions l'habitude de connecter les systèmes : Les API traditionnelles
Pensez à la manière dont nous connectons habituellement les systèmes. Nous utilisons des éléments tels que :
- API REST : Utilisant souvent JSON, éventuellement avec une spécification OpenAPI (Swagger), les API précisent exactement quelles données entrent et sortent d'un système, y compris les types de données (comme les chaînes de caractères ou les nombres).
- RPC (Remote Procedure Call) : Des outils tels que gRPC permettent aux systèmes d'appeler des fonctions les uns sur les autres via des éléments tels que des tampons de protocole pour définir exactement ce dont une fonction a besoin et ce qu'elle renvoie.
- SOAP/WSDL : il s'agit d'une méthode plus ancienne, mais qui repose également sur une description détaillée (WSDL) du service.
- Les files d'attente de messages (par exemple, Kafka, RabbitMQ) : Ces systèmes envoient des messages dans les deux sens, généralement selon un format spécifique convenu.
L'essentiel est que ces méthodes reposent sur des règles et des formats explicites. Les machines vérifient si les données correspondent à la structure prédéfinie (le schéma ou la définition du type). Les développeurs lisent la documentation pour comprendre ce que font les API, puis écrivent le code pour les appeler dans l'ordre voulu, en traitant les données qu'elles renvoient. C'est une danse à laquelle les développeurs se livrent depuis l'avènement de l'informatique.
Paradigmes émergents : MCP, cadres d'agents et API renforcées par des invites
Le passage des API traditionnelles définies de manière rigide aux interactions fluides et basées sur le langage des LLM n'est pas toujours un saut direct vers un langage naturel pur et sans contrainte pour chaque composant du système. Au contraire, nous assistons à la montée en puissance de paradigmes et de cadres intermédiaires puissants conçus pour combler ce fossé, permettant aux systèmes existants et aux nouveaux services de devenir "consommables en LLM".
Au cœur de ces approches émergentes se trouve le concept d'API augmentées par des invites. Plutôt que d'exiger d'un LLM qu'il comprenne la fonctionnalité à partir de zéro, ou d'un développeur qu'il écrive un code d'adaptation complexe, nous "décorons" ou "enveloppons" nos API - qu'il s'agisse de vénérables services REST ou de nouveaux points d'extrémité gRPC - avec des descriptions riches en langage naturel. Ces descriptions agissent comme un manuel d'utilisation spécifique à un LLM, expliquant l'objectif de l'API, comment l'appeler, quels paramètres elle attend (et dans quel format), et ce qu'elle renvoie.
Le protocole de contexte de modèle (MCP), par exemple, illustre une manière plus structurée d'exposer un ensemble diversifié de capacités à un plan de contrôle basé sur LLM. Les systèmes peuvent déclarer leurs services et les actions qu'ils prennent en charge, avec des métadonnées et des descriptions en langage naturel. Un LLM peut alors interroger ce "menu" de capacités déclarées et orchestrer des appels à ces services sous-jacents sur la base de demandes d'utilisateurs ou d'objectifs de plus haut niveau, en comprenant ce qu' ils font et comment les utiliser par le biais de leurs interfaces déclarées, semblables à des messages-guides.
Ceci est étroitement lié à l'évolution rapide du monde des cadres d'agents. Ces cadres fournissent souvent l'échafaudage nécessaire à la construction d'un agent de contrôle primaire, alimenté par LLM. Cet agent central agit comme un orchestrateur ou un "cerveau", capable de raisonner, de planifier et de déléguer des tâches. Le véritable pouvoir se manifeste lorsque cet agent de contrôle a accès à une série d'"outils" ou de sous-agents.
Ces sous-agents peuvent varier considérablement :
- Certains pourraient être d'autres agents spécialisés basés sur le LLM, conçus pour des tâches spécifiques telles que l'analyse de données complexes ou la génération de contenu créatif.
- D'autres peuvent être des modules logiciels plus simples ou, ce qui est essentiel, des interfaces de programmation (wrappers) autour d'API traditionnelles existantes. Dans ce scénario, un développeur crée un wrapper léger autour, par exemple, d'une API interne de gestion des commandes. Ce wrapper ne se contente pas d'exposer les points de terminaison techniques ; il inclut des invites soigneusement conçues qui décrivent les fonctions de l'API en langage naturel : "Cet outil vous permet d'obtenir l'état d'une commande. Il nécessite un 'order_id' en entrée et renvoie l'état actuel, la date de livraison estimée et les articles de la commande."
Le fil conducteur de ces paradigmes est clair : l'API, qu'il s'agisse d'un tout nouveau microservice ou d'un système existant exposé via un wrapper, n'est plus seulement un contrat technique. Elle est complétée par une couche d'invites descriptives. Cela permet à un LLM consommateur (généralement un agent de contrôle) de découvrir, de comprendre et d'utiliser dynamiquement une vaste gamme d'outils et de capacités. Le LLM n'a pas besoin de connaître les détails complexes de la mise en œuvre de chaque outil ; il lui suffit de comprendre la description basée sur les messages-guides de la manière de l'utiliser. Ce changement modifie fondamentalement la façon dont nous concevons l'intégration des systèmes et met encore plus l'accent sur la clarté, la précision et l'exhaustivité de ces messages-guides descriptifs, que nous examinerons plus loin.
L'avenir est... différent
Passer d'API strictes, basées sur le format, et même de ces interfaces émergentes augmentées d'invites, à des interactions véritablement répandues basées sur le langage avec les LLM est un grand changement. En tant que développeur, je me suis habitué à avoir une définition claire des entrées, sorties et messages d'erreur possibles. Travailler avec des LLM apporte une quantité énorme de capacités que nous n'avons jamais eues. Mais il est également sur le point de redéfinir la façon dont vous avez interagi avec d'autres systèmes. En tant que développeurs, il devient de plus en plus important de comprendre comment élaborer des messages-guides précis et complets pour décrire les capacités, en particulier lorsque nous construisons des systèmes dans lesquels plusieurs agents d'intelligence artificielle peuvent être amenés à collaborer.
Commentaires