L’appel d’outils (tool calling ou function calling) permet à un modèle de demander l’exécution d’une action : calculatrice, recherche, agenda, API. Ce n’est plus seulement du texte généré. Voici ce que ça désigne, ses limites, et comment l’aborder sans confusion ni permissions trop larges dès le premier essai.
Définition
Sans outils, un modèle de langage ne produit que du texte. Avec l’appel d’outils, le runtime (l’application qui héberge le modèle) lui expose une liste de fonctions disponibles : « calculer », « lire un fichier autorisé », « créer un événement », « interroger une API ». Le modèle peut alors répondre non par une phrase finale, mais par une demande structurée : quel outil, avec quels arguments. L’application exécute, renvoie le résultat, et le modèle formule ensuite la réponse utile.
Ce que le mot ne désigne pas : ce n’est pas automatiquement MCP, même si MCP sert souvent à brancher des outils de façon standardisée. Ce n’est pas non plus une preuve que le modèle « comprend » votre métier. C’est un protocole de coopération entre génération de texte et actions. Sans garde-fous, un outil mal choisi peut envoyer un e-mail, modifier une base, ou appeler un service payant.
On parle aussi de function calling. L’idée est la même : le modèle choisit parmi des fonctions déclarées. La qualité dépend du modèle (certains sont entraînés pour ça), de la clarté des descriptions d’outils, et du prompt système qui précise quand agir ou seulement proposer. En local comme dans le cloud, le principe reste : texte + exécuteur d’outils + permissions.
Un exemple du quotidien
Vous demandez à un assistant : « combien font 17,5 % de 2480 € pour cette facture ? ». Sans outil, le modèle peut approximer et se tromper. Avec une calculatrice branchée, il appelle l’outil, reçoit le résultat exact, puis rédige la phrase. L’intelligence utile ici, c’est de savoir qu’il faut calculer, pas de faire l’arithmétique de tête dans les poids du réseau.
Autre scène : « ajoute un rappel mardi 10 h pour appeler le fournisseur ». L’assistant ne « pense » pas dans votre téléphone : il propose un appel à l’outil agenda. Si vous avez autorisé l’écriture, l’événement est créé ; sinon, l’outil refuse. L’appel d’outils transforme une intention en action contrôlée — à condition que les permissions soient explicites et minimales.
Un exemple en Hauts-de-France
À Armentières, un garagiste veut un assistant pour estimer des délais à partir d’un planning interne (fichier partagé en lecture seule). L’outil « lire le planning du jour » est branché ; l’outil « modifier le planning » n’existe pas. Le modèle reformule pour le client, mais ne peut pas écraser les créneaux. La productivité vient du bon périmètre d’outils, pas d’un modèle géant sans bornes.
Lors d’une démo IAHDF à proximité, on compare une réponse purement textuelle (« je dirais que c’est disponible ») et une réponse après lecture d’un fichier fictif d’atelier. La différence pédagogique est immédiate : sans outil, c’est de la vraisemblance ; avec outil, c’est une lecture bornée. On rappelle aussi le matériel et la confidentialité : brancher un outil fichier, c’est exposer ce que le runtime peut lire.
On confond souvent
Première confusion : croire que tool calling = le modèle a un accès Internet libre. Non. Il n’a accès qu’aux outils que vous (ou le fournisseur) avez déclarés. Une recherche web n’existe que si un outil de recherche est branché. Sinon, le modèle invente ou refuse. Demandez toujours la liste des outils actifs avant de faire confiance à une « vérification ».
Deuxième confusion : confondre appel d’outils et RAG. Le RAG injecte des passages dans le contexte pour répondre. L’appel d’outils déclenche une action ou une requête au moment voulu. Les deux peuvent se combiner, mais ce ne sont pas des synonymes. Autre mélange : penser que l’outil « sécurise » tout. Un outil mal permissionné augmente le risque, surtout s’il écrit ou envoie des données.
En pratique, que faire avec ce mot
Quand vous choisissez un outil ou un modèle, regardez s’il gère le tool calling, quels outils sont proposés, et qui valide les actions sensibles. Préférez la lecture seule au début. Décrivez chaque outil en une phrase claire : nom, but, paramètres, effets de bord. Testez des cas où l’outil doit être refusé (demande hors périmètre).
Pour une structure en Hauts-de-France, documentez la cartographie des outils comme une fiche de postes techniques. Croisez avec MCP si vous standardisez les branchements, et avec le prompt système pour dire quand proposer plutôt qu’exécuter. Ne branchez jamais une API de production sans journalisation et sans revue humaine sur les écritures.
Termes voisins
| Terme | Rôle utile |
|---|---|
| MCP | Standard pour exposer outils et données à une IA. Voir MCP. |
| Prompt système | Cadre qui dit quand et comment utiliser les outils. Voir prompt système. |
| RAG | Injecte des documents ; n’exécute pas forcément d’action. Voir RAG. |
| API | Service externe souvent appelé via un outil déclaré et permissionné. |
Pour aller plus loin
Pour standardiser les branchements, lisez MCP. Pour cadrer le comportement, lisez le prompt système. Les ateliers IAHDF sont dans l’agenda ; pour rejoindre la communauté, passez par l’inscription.
Questions fréquentes
Comment l’IA peut-elle agir ?
Elle n’agit pas toute seule dans le vide : une application lui propose des outils, le modèle choisit éventuellement d’en appeler un, puis le logiciel exécute selon vos permissions. Sans runtime et sans outil déclaré, il ne reste que du texte. Pour « agir », il faut donc un modèle compatible, des outils décrits, et une politique claire sur ce qui est autorisé en lecture, écriture ou envoi. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
Tous les modèles locaux savent appeler des outils ?
Non. Certains modèles sont mieux entraînés pour le function calling que d’autres. Même avec un bon modèle, l’application (Ollama, un agent, une interface) doit implémenter la boucle d’appel. Lisez la fiche du modèle et testez un outil simple (calculatrice) avant de brancher des actions sensibles. La compatibilité se vérifie par essai, pas par slogan. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.
L’appel d’outils est-il dangereux ?
Il l’est surtout si les permissions sont larges : écrire des fichiers, envoyer des e-mails, appeler des API payantes, modifier une base. Commencez en lecture seule, journalisez les appels, exigez une confirmation humaine pour les écritures. Traitez la liste d’outils comme une surface d’attaque et un périmètre RGPD, pas comme un gadget amusant. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant. Conservez la version d’outil et du modèle pour pouvoir expliquer la décision à un collègue.
Quelle différence avec un simple plugin ?
Le vocabulaire varie selon les éditeurs. Conceptuellement, un plugin est souvent un outil empaqueté. L’appel d’outils désigne le mécanisme général : le modèle demande, le runtime exécute. MCP, plugins propriétaires ou fonctions API sont des façons différentes d’exposer ces capacités. Ce qui compte pour vous : description, permissions, audit. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant. Conservez la version d’outil et du modèle pour pouvoir expliquer la décision à un collègue.
Faut-il des outils pour une IA utile en TPE ?
Pas forcément. Beaucoup d’usages (reformuler, résumer, préparer un plan) restent du texte. Les outils deviennent intéressants quand vous avez une action répétée et bornée : lire un stock, calculer, créer un brouillon d’événement. Commencez sans outil, mesurez le gain, puis ajoutez une fonction à la fois. Moins d’outils bien choisis valent mieux qu’une usine à gaz. Notez le choix, testez sur vos textes, et faites relire un humain avant tout envoi engageant.