Function Calling (LLM)

Définition

Le function calling (ou tool calling) désigne la capacité d'un grand modèle de langage (LLM) à produire, en réponse à une requête, un appel de fonction structuré plutôt qu'un simple texte. Le modèle ne se contente plus de générer de la prose : il émet un objet formaté (typiquement du JSON) indiquant quelle fonction invoquer et avec quels arguments. C'est ce mécanisme qui transforme un modèle conversationnel en agent capable d'interroger une API de threat intelligence, de lancer une requête SQL sur un SIEM ou de déclencher l'isolation d'un poste compromis.

Le function calling résout deux limites structurelles des LLM : leur date de coupure de connaissances (impossible de connaître une CVE publiée hier) et leur incapacité à effectuer des actions dans un système d'information. Il constitue la brique de base des architectures agentiques et le socle de protocoles d'interopérabilité comme MCP (Model Context Protocol).

Fonctionnement technique

Le cycle se déroule en quatre temps, orchestrés par l'application appelante — jamais par le modèle lui-même :

• Déclaration des outils : l'application transmet au modèle un catalogue de fonctions décrites par un schéma (nom, description en langage naturel, paramètres typés au format JSON Schema). La qualité de la description conditionne directement la pertinence des appels.
• Décision et génération : le modèle analyse la requête utilisateur et, s'il juge qu'un outil est nécessaire, retourne un bloc structuré du type {"name": "lookup_ip_reputation", "input": {"ip": "185.220.101.5"}}. Il peut aussi émettre plusieurs appels en parallèle.
• Exécution côté application : c'est le code hôte — pas le LLM — qui exécute réellement la fonction. Cette séparation est fondamentale : le modèle propose, l'orchestrateur dispose.
• Réinjection du résultat : la sortie de la fonction est renvoyée au modèle dans le contexte conversationnel, qui formule alors une réponse en langage naturel ou enchaîne sur un nouvel appel.

Techniquement, la fiabilité du format est obtenue par du décodage contraint (constrained decoding) : lors de la génération, les tokens incompatibles avec la grammaire JSON attendue sont masqués, ce qui garantit un objet syntaxiquement valide.

Exemples concrets en cybersécurité

• Enrichissement d'alerte SOC : un analyste demande « cette IP est-elle malveillante ? ». L'agent appelle successivement virustotal_lookup(), whois() et search_siem_logs(), puis synthétise un verdict argumenté.
• Veille vulnérabilités : une fonction get_cve_details(cve_id) branchée sur la base du NVD ou du CERT-FR permet au modèle de restituer un score CVSS à jour, hors de sa mémoire d'entraînement.
• Réponse à incident : des outils isolate_host() ou revoke_session() exposés à un agent EDR — cas d'usage à très fort impact, donc à encadrer par une validation humaine systématique.
• Conformité : interrogation d'un référentiel documentaire pour vérifier la couverture d'une exigence NIS 2 ou ISO 27001.

Risques et liens avec d'autres concepts

Le function calling élargit considérablement la surface d'attaque d'une application LLM. Il figure au cœur de plusieurs entrées de l'OWASP Top 10 for LLM Applications :

• Prompt injection indirecte : un attaquant place des instructions dans une donnée que le modèle va lire (page web, e-mail, log). Si le modèle dispose d'outils, ces instructions peuvent déclencher des appels non désirés — exfiltration via une fonction send_email(), par exemple. C'est la lethal trifecta : accès à des données sensibles + exposition à du contenu non fiable + capacité d'exfiltration.
• Excessive agency : un outil doté de permissions trop larges (accès en écriture à une base entière plutôt qu'à une vue restreinte) transforme une hallucination en incident.
• Confused deputy : le backend exécute l'appel avec ses propres privilèges, sans vérifier ceux de l'utilisateur final à l'origine de la requête.

Bonnes pratiques

• Ne jamais faire confiance aux arguments générés : les valider côté serveur comme n'importe quelle entrée utilisateur (typage strict, listes blanches, requêtes paramétrées contre l'injection SQL).
• Appliquer le moindre privilège : chaque outil dispose de son propre compte de service, avec le périmètre minimal. Séparer strictement les fonctions de lecture des fonctions d'écriture ou de destruction.
• Exiger une validation humaine (human-in-the-loop) pour toute action irréversible ou à impact métier : blocage de compte, suppression, virement, modification de règle firewall.
• Propager l'identité de l'appelant : contrôler les autorisations au niveau de l'utilisateur final, pas seulement du service.
• Journaliser intégralement chaque appel — nom de fonction, arguments, résultat, horodatage — pour l'auditabilité et l'analyse post-incident.
• Limiter le rayon d'action : quotas d'appels, timeouts, plafond d'itérations pour éviter les boucles d'agent incontrôlées et les coûts associés.
• Marquer le contenu non fiable réinjecté dans le contexte, et considérer que tout ce qui revient d'un outil externe peut être hostile.