← Retour à toutes les analyses
Employés IA · 4 min de lecture

Une API donne des données à l’IA. Qui décide de ce qu’elle en fait ?

Une requête, une réponse, puis un contrôle : comprendre comment une IA consulte un outil métier par API sans lui donner le droit d’agir seule.

Publié le · Par Équipe Pulse

Lundi matin, la responsable d’un cabinet veut savoir quels dossiers commerciaux doivent être relus avant la réunion. La liste existe dans le CRM. Pourtant, demander à une IA « prépare-moi les dossiers urgents » ne lui donne pas accès au CRM — et ne définit pas ce qui est urgent.

Exemple fictif, avec données simulées et aucune action externe. Dans un pilote à définir avec le cabinet, Pulse pourrait préparer une fiche de revue à partir des échéances et statuts accessibles en lecture seule. La responsable vérifierait les sources et choisirait les dossiers à traiter. Ce scénario décrit une méthode, pas une fonction disponible chez tous les clients.

L’API ne parle pas à l’IA toute seule

Une API — interface de programmation — fixe la manière dont un logiciel demande des informations à un autre. L’application interroge le CRM ; celui-ci renvoie une réponse structurée, par exemple un identifiant de dossier, un statut et une échéance. C’est le principe requête → réponse des API Web, expliqué par MDN.

Avec une IA, il faut distinguer deux échanges :

  1. La responsable pose sa question dans l’application. Celle-ci peut communiquer avec le modèle par l’API du fournisseur d’IA et lui présenter les outils autorisés.
  2. Le modèle peut proposer d’utiliser l’outil « lire les dossiers à revoir ». Le programme qui l’encadre vérifie les droits, puis appelle l’API du CRM.
  3. Le CRM répond. Le programme ne transmet au modèle que les champs utiles et autorisés. Le modèle prépare une fiche ; la responsable la relit.

La documentation d’OpenAI sur l’appel d’outils décrit ce partage des rôles : le modèle demande l’usage d’une fonction, mais c’est l’application qui exécute le code et lui retourne le résultat. Une suggestion du modèle n’est pas une permission d’agir.

« La requête a réussi » ne veut pas dire « la décision est bonne »

Imaginons que le CRM renvoie deux dossiers : A, dont l’échéance est vendredi, et B, dont la date a été renseignée il y a plusieurs mois. L’appel à l’API peut avoir parfaitement fonctionné, alors que l’information sur B n’est plus fiable. Une échéance proche ne prouve pas non plus qu’un prospect souhaite signer ou doit être relancé.

La fiche de revue des appels API garde donc les éléments nécessaires à la décision :

À conserver Ce que la responsable voit
La demande « Quels dossiers relire avant la réunion ? »
La source CRM consulté et date de lecture
La réponse utile Identifiant, statut, échéance et lien vers chaque dossier autorisé
L’incertitude Champ absent, date ancienne ou source contradictoire
La suite proposée Dossier à vérifier, motif et personne qui tranche

L’IA peut rapprocher et reformuler ces éléments. Elle ne doit pas inventer une date manquante. Si l’API refuse l’accès ou ne répond pas, la fiche indique « source indisponible », plutôt que de présenter un classement assuré.

La permission se règle dans le système, pas seulement dans la consigne

Ce pilote n’aurait besoin que d’une lecture ciblée. Les droits et les paramètres doivent être contrôlés par l’application et par l’outil appelé. Une phrase adressée au modèle — « ne modifie rien » — ne remplace pas cette protection. OWASP recommande de limiter les fonctions et permissions disponibles et de faire approuver les actions importantes par une personne.

Aucun email envoyé, aucune tâche Cockpit créée, aucun statut CRM modifié ni aucune société fusionnée sans validation humaine explicite. Une proposition reste corrigeable ou supprimable. Toute action approuvée doit laisser une trace et permettre une correction ou un retour arrière lorsque c’est possible. Un email envoyé ne s’annule pas : son contrôle doit précéder l’envoi. Les signaux faibles ne justifient aucune déduction d’émotion, d’attribut personnel ou de donnée sensible.

Un premier essai utile : choisissez une question de lecture, trois champs CRM autorisés et un cas où la réponse manque. Vérifiez si une personne peut retrouver la source et refuser la conclusion. Si la fiche ne le permet pas, réduisez le périmètre avant de connecter davantage d’outils.

Pour comprendre ce qu’ajoute une passerelle d’outils destinée à l’IA, lisez « Un serveur MCP, c’est quoi ? ». Pour cadrer les données accessibles et la validation d’un pilote, demandez un Diagnostic Pulse.