Function calling : votre IA ne doit jamais parler directement à votre base de données

Le raccourci qui semble logique, et qui ne l'est pas

Quand un dirigeant décide de brancher une IA sur son système d'information, le raccourci le plus tentant consiste à lui donner un accès direct à la base de données. L'idée paraît efficace, l'IA lit les tables, comprend les relations entre elles, et répond aux questions ou déclenche des actions sans étape intermédiaire. Ce raccourci fonctionne en démonstration, sur un jeu de données propre et un scénario simple. Il devient dangereux dès que la base de données reflète, comme toutes les bases de PME réelles, des années de règles métier jamais écrites nulle part ailleurs que dans la tête de quelques personnes.

Une IA connectée directement à une base de données ne lit pas les règles métier, elle les devine à partir de la structure des tables et du contenu qu'elle observe. Si deux statuts de commande se ressemblent sans être équivalents, si un champ vide signifie autre chose qu'un champ à zéro, si une exception métier n'apparaît nulle part dans le schéma, l'IA comble le vide avec l'interprétation la plus probable statistiquement, pas la plus correcte pour votre métier.

Ce que le function calling change concrètement

Le function calling inverse ce rapport. Plutôt que de laisser l'IA consulter directement les données, on lui donne accès à une liste de fonctions documentées, chacune avec un nom explicite, des paramètres définis, et un comportement écrit dans le code, pas dans un prompt. L'IA ne peut plus inventer une requête, elle choisit parmi des actions dont le résultat est déterministe et contrôlé par votre équipe technique.

« Une IA connectée à des fonctions documentées est contrainte par des règles écrites noir sur blanc, elle ne peut pas sortir du cadre. »

Chez Leando, ce principe s'appelle codé, pas prompté, la logique métier critique d'un système IA doit vivre dans des fonctions de code documentées, jamais dans l'interprétation d'un prompt ou dans la lecture directe d'une base de données brute. Le principe exclut de confier à l'IA la responsabilité de deviner une règle que personne n'a pris le temps d'écrire explicitement quelque part.

Le même mécanisme s'applique à l'écriture, pas seulement à la lecture. Une IA autorisée à modifier directement une table peut, sur une interprétation erronée d'un cas limite, écrire une valeur incorrecte qui se propage ensuite dans tous les processus qui dépendent de cette table. Une fonction d'écriture documentée peut, à l'inverse, refuser explicitement certains cas, exiger une confirmation supplémentaire, ou journaliser chaque modification d'une façon que votre équipe a décidée à l'avance, pas que le modèle a improvisée au moment de l'exécution.

Pourquoi ce n'est pas qu'une question de sécurité informatique

La différence entre les deux architectures n'est pas seulement une question de permissions ou de risque de fuite de données. Elle porte sur la fiabilité du raisonnement métier lui-même. Une fonction nommée annuler_commande_si_non_expediee encode déjà, dans son nom et son comportement, une règle métier que personne n'a besoin de reformuler à chaque appel. Une IA qui écrirait elle-même la requête équivalente devrait, à chaque fois, redéterminer ce que signifie exactement « non expédiée » dans votre système, avec le risque de se tromper une fois sur cent, silencieusement.

Un exemple concret pour voir la différence en pratique

Prenons une IA chargée de répondre à la question « quels clients ont une facture en retard de plus de trente jours ». Branchée directement sur la base, elle doit elle-même déterminer ce que signifie « en retard », en interprétant les colonnes disponibles, une date d'échéance, un statut de paiement, parfois les deux à la fois sans cohérence garantie entre elles. Si un avoir partiel a été enregistré d'une façon inhabituelle, ou si un client bénéficie d'un délai négocié jamais tracé dans le même champ que les autres, l'IA n'a aucun moyen de le savoir autrement qu'en devinant.

Avec le function calling, la même question passe par une fonction lister_factures_en_retard, écrite et testée une fois par votre équipe technique, qui encode déjà la définition exacte du retard, les cas d'avoir partiel, et les délais négociés. L'IA n'a plus besoin de deviner cette définition à chaque appel, elle demande le résultat à une fonction qui la connaît déjà et la applique de façon identique, que ce soit la première ou la millième fois qu'on la sollicite.

Le vrai coût d'une hallucination sur une donnée métier

Une hallucination de rédaction se corrige en relisant un texte. Une hallucination sur une donnée métier se propage avant d'être détectée, elle génère une facture incorrecte, annule la mauvaise commande, ou modifie un statut client sur une interprétation erronée d'un champ ambigu. Le coût ne se mesure pas en temps de correction du texte, il se mesure en temps passé à retrouver quelles décisions en aval ont été prises sur cette erreur, et à les corriger une par une.

Sur la manière de cadrer les règles métier qui restent aujourd'hui informelles avant même de parler d'IA, l'article sur les règles métier implicites dans un projet SI détaille la méthode pour les faire remonter et les documenter, un prérequis direct à tout function calling fiable.

Pourquoi tester une fonction est plus simple que tester un prompt

Une fonction de code se teste comme n'importe quelle autre fonction de votre système, avec des cas d'entrée connus et des résultats attendus vérifiables une fois pour toutes. Un prompt qui laisse l'IA improviser sa propre requête ne s'expose jamais de la même manière à ce type de test. On peut l'évaluer sur des exemples, mais jamais garantir qu'un cas non testé se comportera comme les cas déjà vérifiés, parce que le comportement reste, par nature, une interprétation du modèle plutôt qu'une exécution déterministe de règles écrites.

Cette différence a une conséquence directe sur la confiance qu'une équipe peut accorder au système avec le temps. Une fonction testée une fois reste fiable tant que son code ne change pas. Un comportement obtenu par prompt doit être régulièrement réévalué, parce que le modèle sous-jacent évolue, et parce qu'aucune suite de tests ne couvre jamais tous les cas qu'un prompt en langage naturel peut rencontrer en production.

Ce que cette architecture n'élimine pas

Codé, pas prompté ne rend pas l'IA infaillible. Elle peut encore se tromper sur quelle fonction appeler ou quel paramètre transmettre. Ce que le principe élimine, c'est la possibilité qu'elle invente un résultat qui n'existe pas dans vos données réelles. C'est une différence de nature, pas seulement de degré, entre un système qui peut se tromper de question et un système qui peut halluciner une réponse entière.

Ce principe s'applique surtout aux actions qui engagent une donnée, un prix, un statut, une facture. Sur la question complémentaire de savoir jusqu'où pousser la formalisation d'une règle dans un prompt avant de devoir la coder, l'article sur le plafond du prompt engineering prolonge directement ce diagnostic.

Cette exigence ne relève pas d'un excès de prudence technique, elle correspond à une question de gouvernance simple, qui décide de ce que votre IA peut faire. Avec un accès direct aux données, la réponse est floue, elle dépend de l'interprétation du modèle au moment de l'exécution, potentiellement différente d'une fois sur l'autre. Avec des fonctions documentées, la réponse est explicite et se trouve dans un fichier de code que n'importe quel développeur de votre équipe peut relire et faire évoluer, sans dépendre de la personne qui a écrit le prompt initial.

Avant de valider votre prochaine intégration IA, demandez une seule chose à votre prestataire, la liste des fonctions documentées auxquelles l'IA aura accès, et ce qu'elle ne pourra jamais faire en dehors. Si cette liste n'existe pas, votre IA parle probablement déjà directement à votre base de données.