Appel de fonctions

Du texte à l'action

Un modèle de langage ne fait qu'une chose : produire du texte. Pour autant, il peut indiquer qu'il souhaite consulter un calendrier, chercher une commande ou créer un ticket. Il émet alors une structure — un nom de fonction et des paramètres — que le programme appelant lit et exécute. Le résultat est renvoyé au modèle, qui poursuit son raisonnement avec cette information nouvelle. Rien dans ce mécanisme n'est magique : c'est un format de réponse parmi d'autres.

Le point important est la séparation. Le modèle ne touche pas directement au système : il demande, le programme décide. C'est là que se placent les contrôles — vérifier les droits, valider les paramètres, refuser une action hors périmètre, journaliser l'appel. Un appel de fonctions bien conçu ressemble moins à une délégation qu'à un guichet avec un agent derrière, qui répond oui, non, ou demande une précision avant d'agir. Cette répartition dit qui répond d'une erreur : jamais le modèle, toujours l'application qui l'a laissé faire.

Concrètement, dans un outil de gestion

Un artisan demande à son assistant quels devis sont en attente depuis plus de deux semaines. Le modèle ne connaît pas la base. Il appelle une fonction de recherche avec un filtre de date, reçoit une liste, puis la met en forme. La même mécanique sert à créer un rendez-vous, envoyer un rappel ou calculer une marge à partir de plusieurs lignes. La valeur vient de la répétition, pas de la sophistication de l'appel lui-même.

La qualité du résultat dépend de la description des fonctions. Un nom explicite, des paramètres documentés, des exemples d'usage améliorent nettement le taux de bons appels. À l'inverse, une fonction aux paramètres ambigus produit des appels plausibles mais faux, difficiles à diagnostiquer parce que le modèle ne signale pas son erreur. Il faut alors lire le journal pour comprendre ce qu'il a réellement demandé, et corriger la description plutôt que le modèle.

Les risques à couvrir

Trois familles d'incidents reviennent. L'action non voulue, quand le modèle appelle une fonction de suppression alors qu'on demandait une lecture. Le paramètre inventé, quand un identifiant est fabriqué de toutes pièces pour satisfaire la forme attendue. Et l'enchaînement, quand plusieurs appels corrects pris isolément produisent ensemble un effet indésirable, par exemple une modification suivie d'une notification envoyée au mauvais contact du dossier. Ces trois cas relèvent de la même discipline : un contrôle avant l'exécution, jamais une correction après coup.

Les réponses sont techniques et organisationnelles : valider les paramètres côté serveur, distinguer les fonctions de lecture et d'écriture, exiger une confirmation pour les actions sensibles, conserver un journal lisible. Ce journal sert autant à corriger le système qu'à expliquer, plus tard, ce qui s'est réellement passé. Sans lui, un incident se discute en termes d'impressions, et le prestataire comme le client restent sans preuve partageable. Un droit de lecture suffit pour une consultation ; une écriture demande un compte dédié et une trace nominative.