Brancher un modèle de langage sur un produit prend une après-midi. Ce qui prend le reste du projet, c'est tout ce qui entoure l'appel : que faire quand la réponse arrive dans un format inattendu, quand elle met huit secondes, quand elle est plausible mais fausse, et ce que deviennent les données que vous envoyez à un tiers. L'appel est la partie facile.
8 min de lecture · mis à jour le 20 septembre 2026
La différence qui change tout : le non-déterminisme
Une fonction classique rend le même résultat pour la même entrée. Un modèle de langage, non : la même question peut produire deux réponses différentes, et rien ne garantit que la seconde respecte le format de la première.
Cela invalide une partie des réflexes de développement. On ne peut pas écrire un test qui compare la sortie à une valeur attendue. On ne peut pas supposer qu'un format observé dix fois sera respecté la onzième. On ne peut pas reproduire un bogue en rejouant l'entrée.
La conséquence pratique est simple à énoncer : traitez la sortie du modèle comme une saisie utilisateur, pas comme le retour d'une fonction. Vous ne feriez pas confiance à un champ de formulaire sans le valider ; appliquez exactement la même méfiance.
Valider la sortie avant de la croire
Si vous attendez une structure de données, demandez-la explicitement et vérifiez-la à l'arrivée. La plupart des fournisseurs proposent un mode de sortie contrainte qui réduit fortement les écarts de format — c'est la première chose à activer, et elle ne dispense pas de la vérification.
Ce que la validation doit couvrir : la forme, d'abord — les champs attendus sont-ils présents et du bon type ? Puis le fond, quand c'est vérifiable — une date est-elle dans une plage crédible, un identifiant existe-t-il réellement dans votre base, un montant est-il du bon ordre de grandeur ?
Ce second contrôle est le plus important et le plus souvent omis. Un modèle produit volontiers une référence bien formée qui n'existe pas. Le format est irréprochable, le contenu est faux, et rien ne le signale si vous ne le vérifiez pas contre vos propres données.
Prévoir la reprise : que fait le produit quand ça rate ?
Un appel à un modèle peut échouer de plusieurs façons, et chacune demande une réponse décidée à l'avance.
- La réponse ne passe pas la validation. Réessayer une fois avec la consigne d'erreur règle une bonne partie des cas ; au-delà, il faut une sortie de secours plutôt qu'une boucle.
- Le service est indisponible ou saturé. Un nouvel essai après un délai croissant est la règle, mais il doit avoir une fin — sans quoi un incident chez le fournisseur devient un blocage chez vous.
- La réponse est trop lente. Fixez un délai maximal explicite et décidez ce qui se passe après : dégradation vers une version simplifiée, mise en file d'attente, ou message honnête à l'utilisateur.
- La réponse est correcte mais inutilisable pour ce cas précis. C'est le plus délicat : il faut un chemin manuel, où un humain reprend la main sans perdre le travail en cours.
La latence n'est pas un détail d'optimisation
Un appel à un modèle se compte en secondes, pas en millisecondes. Cet ordre de grandeur, qui varie selon le modèle, la longueur de la réponse et la charge du service, transforme la conception de l'interface.
Trois conséquences. La réponse ne peut pas être attendue pendant le chargement d'une page : il faut une interface qui s'affiche d'abord et se complète ensuite. L'affichage progressif de la réponse change fortement la perception d'attente, pour un coût d'implémentation modeste. Et une action utilisateur qui déclenche plusieurs appels en chaîne additionne les latences, ce qui rend vite l'attente insupportable.
Ce dernier point mérite d'être regardé tôt : une fonctionnalité qui enchaîne trois appels séquentiels sera trois fois plus lente qu'une démonstration à un seul appel. Ce qui fonctionne en maquette peut devenir inutilisable en production sans qu'aucune ligne de code soit en cause.
Les données que vous envoyez, et où elles vont
Chaque appel transmet le contenu de la requête à un tiers, souvent hors de l'Union européenne. Si ce contenu comporte des données personnelles — un message client, une fiche, un document — le traitement entre dans le champ du RGPD.
Ce que cela implique concrètement : identifier le fournisseur comme sous-traitant et disposer du cadre contractuel correspondant ; informer les personnes que leurs données sont traitées par un modèle et par qui ; vérifier la politique de rétention du fournisseur, qui varie fortement d'une offre à l'autre ; et déterminer si les données servent à entraîner des modèles, ce qui est en général désactivable sur les offres professionnelles mais pas toujours par défaut.
Le réflexe utile est de minimiser à la source : n'envoyez que ce qui est nécessaire à la tâche. Un modèle qui doit classer un message n'a pas besoin du nom ni de l'adresse de son auteur. Retirer ces champs avant l'appel coûte quelques lignes et supprime une grande partie du problème.
Les garde-fous, avant et après
Une fonctionnalité qui expose un modèle aux entrées du public doit être protégée dans les deux sens.
En amont : limitez le nombre d'appels par utilisateur et par période. Sans cette limite, une seule personne peut consommer votre budget mensuel en une nuit, volontairement ou non. C'est la protection la plus simple et la plus souvent oubliée.
En aval : ne réinjectez jamais une sortie de modèle dans un contexte qui l'exécute — requête vers votre base, commande système, code évalué. Le texte produit peut contenir ce qu'un utilisateur y aura fait mettre, et la frontière entre la consigne et la donnée est beaucoup moins étanche qu'avec un langage de programmation.
Et journalisez les appels : entrée, sortie, durée, issue. Sans cette trace, le premier comportement anormal en production est indiagnosticable, puisqu'il n'est pas reproductible. Attention toutefois à ce que cette journalisation contient : si les entrées comportent des données personnelles, le journal devient lui-même un traitement, avec sa durée de conservation et ses règles d'accès.
Ce qui décide si l'intégration vaut le coup
La question à se poser avant de commencer n'est pas « est-ce que le modèle sait le faire » — il sait presque toujours faire quelque chose. C'est : que se passe-t-il quand il se trompe ?
Si l'erreur est visible et corrigeable par l'utilisateur — une suggestion de texte, une proposition de classement — l'intégration est confortable, et une réponse imparfaite reste utile.
Si l'erreur est invisible ou irréversible — un calcul repris tel quel, une action déclenchée automatiquement, une donnée écrite sans relecture — il faut un contrôle humain, et ce contrôle fait souvent disparaître le gain de temps recherché.
C'est le vrai critère d'arbitrage, et il se pose avant toute considération technique.