Du dialogue à l’intégration
Utiliser un grand modèle de langage (LLM) dans une interface de conversation est une chose. L’intégrer à un script, une application ou un flux automatisé en est une autre : il faut alors gérer les erreurs, les données, les coûts et les conséquences de chaque sortie.
Une API permet d’envoyer une requête à un modèle et de recevoir sa réponse dans un format exploitable par un programme. Elle donne accès au modèle ; elle ne fournit pas à elle seule un système fiable. Cette fiabilité dépend de tout ce qui l’entoure.
Appeler un modèle par API
La plupart des services exposent une API HTTP. Voici un appel minimal à l’API de Mistral, volontairement limité à l’essentiel :
curl https://api.mistral.ai/v1/chat/completions
-H "Authorization: Bearer $MISTRAL_API_KEY"
-H "Content-Type: application/json"
-d '{
"model": "mistral-small-latest",
"messages": [
{
"role": "user",
"content": "Résume ce message en une phrase : le service web a dépassé son seuil de mémoire."
}
]
}'
La clé est lue depuis une variable d’environnement et n’apparaît pas dans le code. Le nom du modèle, les paramètres et la forme exacte de la réponse dépendent du fournisseur et peuvent évoluer : une intégration doit toujours s’appuyer sur sa documentation à jour.
Une chaîne fiable autour du modèle
Dans un système de production, l’appel au LLM n’est qu’une étape :
entrée → contrôle → préparation → appel du modèle → validation → décision → action
Chaque étape joue un rôle différent :
- le contrôle d’entrée vérifie le format, la taille et la sensibilité des données ;
- la préparation filtre ou structure les informations utiles ;
- le modèle réalise la tâche linguistique ou sémantique ;
- la validation contrôle le schéma et les règles métier ;
- la décision détermine si le résultat peut être utilisé automatiquement ;
- l’action reste confiée à du code dont les permissions sont explicites.
Le modèle ne doit pas remplacer un calcul ou une règle déterministe. Pour compter des lignes, vérifier un seuil ou valider une adresse IP, du code classique est plus prévisible. Le LLM devient intéressant lorsqu’il faut interpréter un texte ambigu, classer un message ou reformuler une information.
Sorties structurées et contrôles
Lorsqu’une réponse doit être consommée par un programme, un schéma structuré est préférable à un paragraphe libre. On peut par exemple demander :
{
"gravite": "faible | moyenne | critique",
"resume": "texte",
"indices": ["extrait exact du log"]
}
Respecter ce schéma ne suffit pas. Le programme doit encore vérifier que gravite contient une valeur autorisée, que les extraits existent réellement dans la source et que les champs obligatoires sont présents.
Résister aux incidents ordinaires
Une API distante peut ralentir, refuser une requête ou devenir temporairement indisponible. Une intégration robuste prévoit notamment :
- un délai maximal d’attente ;
- des reprises espacées pour les erreurs transitoires, sans répéter aveuglément une action ;
- la gestion des limites de débit ;
- une limite de tokens et de coût ;
- des journaux techniques qui n’exposent pas les contenus sensibles ;
- un comportement de repli lorsque le modèle ne répond pas.
La mise en cache peut réduire la latence et le coût pour des demandes stables. Elle exige cependant une durée de validité, une protection adaptée aux données stockées et une clé de cache qui tient compte du modèle, du prompt et de ses paramètres.
Évaluer avant de déployer
Une impression favorable sur quelques exemples ne mesure pas la fiabilité d’un système. Constituez un petit jeu de cas représentatifs avec les résultats attendus, notamment des entrées ambiguës, incomplètes ou hostiles. À chaque changement de modèle ou de prompt, rejouez ces évaluations afin de repérer les régressions.
Les critères peuvent porter sur l’exactitude, le taux de réponses exploitables, le coût, la latence et la proportion de cas transmis à une personne pour validation.
Sécurité et confidentialité
Protéger les secrets
Les clés d’API doivent être conservées dans un gestionnaire de secrets ou un mécanisme équivalent. Utilisez des clés différentes selon les environnements, limitez leurs droits et prévoyez leur rotation.
Maîtriser les données
Avant tout envoi, classez les données et vérifiez les règles de l’organisation, le contrat du fournisseur, la durée de conservation et les usages éventuels des contenus transmis. Supprimez les secrets et les données personnelles qui ne sont pas nécessaires.
Se méfier des instructions cachées
Un document, un courriel ou une page web peut contenir une instruction destinée à détourner le modèle : c’est une injection de prompt. Les données externes doivent être traitées comme non fiables. Une phrase trouvée dans un document ne doit jamais pouvoir modifier les permissions du système.
Ne pas exécuter une sortie brute
Une commande, une requête SQL ou une URL produite par le modèle reste une donnée non fiable. Avant toute exécution, elle doit être contrôlée par des règles déterministes, limitée à une liste d’opérations autorisées et, lorsque les conséquences sont importantes, soumise à une validation humaine.
Workflows avec ou sans code
Les plateformes d’automatisation peuvent relier une messagerie, un stockage documentaire et une API de LLM sans développement important. Elles simplifient l’orchestration, mais ne suppriment aucune exigence : les données, permissions, erreurs et sorties doivent être contrôlées de la même manière.
À retenir
Une bonne intégration ne consiste pas seulement à obtenir une réponse du modèle. Elle encadre cette réponse par des contrôles, des évaluations et des permissions minimales. Le LLM traite l’ambiguïté ; le logiciel conserve la maîtrise des règles et des actions.
L’article suivant examine le cas particulier où le système choisit lui-même la prochaine étape : l’IA agentique.