Accueil › Glossaire › API Calling LLM

API Calling LLM

Un API calling LLM est un grand modèle de langage capable d’interagir avec des API externes (REST, GraphQL, SOAP) pour lire des données, déclencher des actions et orchestrer des workflows dans des services tiers comme les CRM, les outils de gestion de projet, la messagerie, le paiement ou toute application exposant une interface programmatique.

C’est la catégorie la plus large de tool-augmented LLM. La navigation web, l’exécution de code, le database access et le file management sont tous des formes spécifiques d’API calling. Mais le terme désigne plus couramment la capacité du LLM à interagir avec des services SaaS et des systèmes d’entreprise : créer un ticket Jira, envoyer un message Slack, mettre à jour un contact Salesforce, lancer un paiement Stripe, réserver un vol.

C’est cette capacité qui transforme un LLM de « chatbot qui donne des conseils » en « agent qui exécute des tâches ». Quand vous dites à un agent IA « crée une tâche haute priorité dans Jira pour le bug de l’écran de login », le LLM ne vous donne pas la marche à suivre : il appelle l’API Jira et crée le ticket.

Comment un LLM appelle une API

Le mécanisme repose sur le function calling. Le LLM ne fait jamais d’appel HTTP lui-même : il génère une intention structurée que votre code exécute.

Le flux complet

1. Définition de l’outil : vous décrivez l’API comme un outil avec un nom, une description et des paramètres (JSON Schema). Par exemple, un outil create_jira_ticket avec les paramètres summary (string), priority (enum: High/Medium/Low) et description (string).

2. Décision du LLM : face à la requête utilisateur (« ouvre un ticket haute priorité pour le bug de login »), le modèle analyse les outils disponibles et produit un objet JSON structuré : {"tool": "create_jira_ticket", "arguments": {"summary": "Bug de l'écran de login", "priority": "High"}}.

3. Exécution côté application : votre code backend reçoit ce JSON, authentifie la requête (token OAuth2, API key), formule la requête HTTP vers l’API Jira, gère les headers, le body, et les erreurs réseau.

4. Gestion de la réponse : votre code parse la réponse de l’API (code HTTP, body JSON), gère les cas d’erreur (401 Unauthorized, 429 Rate Limited, 503 Service Unavailable), et retourne un résultat lisible au LLM.

5. Synthèse : le LLM intègre le résultat dans sa réponse : « J’ai créé le ticket PROJ-1234 en priorité haute. Voici le lien : [url] ».

Les cinq patterns d’intégration

L’écosystème a convergé vers cinq patterns d’intégration, classés du plus simple au plus scalable.

1. Appels directs

Le LLM génère directement le payload HTTP (URL, headers, body) et votre code l’envoie tel quel. Ce pattern offre un contrôle maximal et zéro couche intermédiaire, mais il est extrêmement fragile : tout changement dans l’API cible casse le code. Réservé au prototypage ou aux intégrations uniques et stables.

2. Function calling / Tool use

Le pattern standard décrit plus haut : vous définissez des outils structurés, le LLM choisit lequel appeler, et votre code exécute l’appel réel. C’est le pattern natif supporté par OpenAI, Anthropic et Google. Plus fiable que les appels directs car le LLM travaille avec des schémas structurés, mais vous gérez toujours l’authentification, les erreurs et la maintenance de chaque intégration.

3. MCP Gateway

Le Model Context Protocol standardise la découverte et l’exécution des outils. Au lieu de coder chaque intégration, vous installez des serveurs MCP prêts à l’emploi pour chaque service (Slack, GitHub, Jira, Google Drive, Salesforce…). Le LLM découvre les outils disponibles via le protocole, et les appelle de manière standardisée.

En mars 2026, le registre MCP officiel liste des centaines de serveurs pour les services SaaS les plus courants. Des outils comme FastMCP peuvent convertir automatiquement n’importe quelle API avec une spécification OpenAPI en serveur MCP, éliminant le code d’intégration manuel.

4. Unified API

Les plateformes comme Composio, Merge ou Nango fournissent une API unifiée qui abstrait les différences entre fournisseurs d’une même catégorie. Au lieu de coder trois intégrations CRM (Salesforce, HubSpot, Pipedrive), vous utilisez une seule API « CRM » qui route vers le bon fournisseur. L’authentification, les mises à jour de schéma et la maintenance sont gérées par la plateforme.

Composio, par exemple, gère l’authentification OAuth pour plus de 200 services et expose les outils via MCP et les frameworks agents (LangChain, CrewAI, AutoGen). C’est la solution la plus scalable quand vous devez intégrer 10 à 100+ services SaaS.

5. Agent-to-Agent (A2A)

Le pattern le plus récent : un agent délègue des tâches à d’autres agents spécialisés plutôt que d’appeler directement les API. Un agent « chef de projet » délègue à un agent « Jira » qui connaît l’API Jira en détail, et à un agent « Slack » pour les notifications. Ce pattern est prometteur pour les workflows complexes mais encore en phase expérimentale.

MCP et les services SaaS

Le MCP a radicalement simplifié l’API calling pour les LLM. Avant MCP, connecter Claude à Jira nécessitait de coder un connecteur spécifique. Maintenant, vous installez le serveur MCP Jira et c’est fait.

Serveurs MCP SaaS populaires

De OpenAPI à MCP automatiquement

FastMCP peut convertir n’importe quelle API avec une spécification OpenAPI (ou Swagger) en serveur MCP en quelques lignes de code. Chaque endpoint de l’API devient un outil MCP appelable par le LLM. C’est la méthode la plus rapide pour rendre une API interne « agent-ready » sans coder de wrapper manuel.

Le processus : chargez la spécification OpenAPI, configurez un client HTTP authentifié, et FastMCP génère automatiquement les outils MCP avec les descriptions, les paramètres typés et la validation. Les requêtes GET peuvent être exposées comme des Resources MCP (données en lecture) et les POST/PUT/DELETE comme des Tools (actions avec effets de bord).

Défis en production

Authentification et tokens

La plupart des API SaaS utilisent OAuth 2.0 avec des access tokens qui expirent. Votre couche d’exécution doit gérer le cycle complet : autorisation initiale, stockage sécurisé des tokens, refresh automatique, et re-autorisation quand le refresh token expire. C’est la tâche la plus complexe et la plus sujette aux bugs. Les plateformes comme Composio gèrent ce cycle pour vous.

Pagination

Un LLM qui demande « tous les clients » recevra la page 1 d’un résultat de 500 pages. Si votre couche d’exécution ne gère pas la pagination automatiquement, l’agent produira des conclusions basées sur un échantillon partiel sans le savoir. Implémentez une abstraction de pagination qui retourne l’ensemble des résultats (ou un sous-ensemble explicite avec un avertissement).

Rate limiting

Les API SaaS imposent des limites de requêtes (typiquement 100 à 1000 requêtes par minute). Un agent enthousiaste qui enchaîne les appels peut atteindre ces limites en quelques secondes. Implémentez du backoff exponentiel, du retry avec jitter, et un budget de requêtes par session agent.

Évolution des API

Les API SaaS changent : nouveaux champs obligatoires, endpoints dépréciés, modifications de schéma. Un connecteur qui fonctionnait hier peut casser demain. C’est l’argument principal en faveur des Unified API et des serveurs MCP maintenus par des communautés : la maintenance est mutualisée plutôt qu’à votre charge exclusive.

Sécurité et gouvernance

Un agent avec accès à l’API Salesforce peut potentiellement lire ou modifier n’importe quel enregistrement client. Un agent avec accès à l’API Stripe peut initier des paiements. Les garde-fous sont indispensables :

Principe du moindre privilège : ne donnez à l’agent que les permissions API strictement nécessaires à sa tâche.

RBAC (Role-Based Access Control) : différents utilisateurs doivent avoir accès à différents outils. Un agent de support n’a pas besoin de créer des paiements.

Confirmation humaine pour les actions destructives : suppression de données, envoi d’emails, modifications financières doivent requérir une validation explicite.

Audit trail : chaque appel API effectué par l’agent doit être journalisé avec l’identité de l’utilisateur, l’outil appelé, les arguments et le résultat.

Cas d’usage concrets

Automatisation de workflows

« Quand un ticket Jira passe en ‘Done’, envoie un message Slack dans le canal #releases et mets à jour le Notion. » Ce type de workflow multi-service est le terrain de jeu naturel de l’API calling LLM. Les plateformes comme Make et Zapier intègrent des LLM pour orchestrer ces workflows en langage naturel.

Agents de support client

Un agent connecté au CRM (Salesforce), au système de ticketing (Zendesk) et à la base de connaissances peut résoudre une demande de bout en bout : identifier le client, consulter son historique, créer un ticket, appliquer un remboursement et envoyer un email de confirmation.

Agents de développement

Claude Code et Codex utilisent l’API calling pour interagir avec GitHub (créer des PRs, lire des issues), les systèmes CI/CD (déclencher des builds), et les bases de données. L’agent de code ne se contente pas d’écrire du code : il interagit avec l’écosystème de développement complet.

Agents e-commerce

Un agent connecté à Shopify, Stripe et un service de livraison peut traiter des commandes, vérifier des stocks, initier des remboursements et suivre des expéditions. Chaque action est un appel API orchestré par le LLM.

Rendre vos API « agent-ready »

Si vous développez des API internes et souhaitez qu’elles soient utilisables par des LLM, plusieurs principes s’appliquent :

Descriptions sémantiques claires : les descriptions d’endpoints et de paramètres doivent être en langage naturel, pas en jargon technique interne. « Récupère le statut de livraison d’une commande par son identifiant » est meilleur que « GET order status ».

Spécification OpenAPI complète : une spec OpenAPI bien documentée peut être convertie automatiquement en serveur MCP via FastMCP. C’est l’investissement le plus rentable pour rendre une API agent-compatible.

Réponses structurées et prévisibles : les réponses doivent être en JSON avec des schémas cohérents. Les messages d’erreur doivent être explicites (pas juste un code HTTP) pour que le LLM puisse comprendre et corriger.

Gestion des erreurs gracieuse : des messages d’erreur descriptifs permettent au LLM de s’adapter. « Le champ ’email’ est requis et doit être une adresse valide » est exploitable ; « 400 Bad Request » ne l’est pas.

La recherche académique (RestGPT, τ-Bench) souligne que les API REST existantes n’ont pas été conçues pour les agents IA. Les défis de schema mismatch, d’interprétation des inputs et de gestion des réponses restent significatifs. Enrichir les définitions d’outils avec des exemples et des métadonnées supplémentaires réduit considérablement les hallucinations.

Évolutions et tendances

La tendance dominante est la convergence MCP + Unified API. Le MCP standardise la découverte et l’exécution des outils. Les Unified API (Composio, Merge) standardisent l’accès aux services SaaS. Ensemble, ils forment une couche d’intégration composable qui rend l’API calling scalable et maintenable.

L’adoption du MCP par OpenAI, Google, Microsoft et des centaines de développeurs indépendants crée un effet réseau : chaque nouveau serveur MCP publié bénéficie à tous les clients MCP existants. Le registre officiel MCP grandit de plusieurs serveurs par semaine.

FastMCP et les outils similaires automatisent la création de serveurs MCP à partir de spécifications OpenAPI existantes, réduisant le coût de mise en compatibilité à quelques minutes par API. À terme, toute API bien documentée sera automatiquement accessible aux agents IA.