Mettre un modèle de langage en production : tout ce qui change

Il n’a jamais été aussi facile de faire une démonstration impressionnante. Quelques appels à une API, un prompt bien tourné, et l’on tient en une journée quelque chose qui épate une réunion.

L’écart entre cette journée et une fonctionnalité qui tourne pendant deux ans devant de vrais utilisateurs est le sujet le plus mal évalué que je rencontre en avant-vente. Ce n’est pas un écart de qualité de modèle. C’est un écart de nature : presque tout ce qu’on sait faire pour fiabiliser un logiciel classique ne s’applique pas tel quel.

Je détaille ici ce qui change réellement, poste par poste, parce que c’est la liste que j’aurais aimé avoir avant de le découvrir en exploitation.

1. Le non-déterminisme n’est pas un défaut à corriger

Un logiciel classique, sur la même entrée, produit la même sortie. C’est l’hypothèse implicite de toute notre culture d’ingénierie : les tests, les recettes, la reproduction de bugs, les correctifs.

Un modèle de langage n’offre pas cette garantie. Deux appels identiques peuvent produire deux formulations différentes, et parfois deux décisions différentes. Réduire la température aide, mais ne supprime pas le phénomène — et une température nulle dégrade les tâches qui demandent de la nuance.

La conséquence pratique est brutale : on ne peut plus reproduire un incident à volonté. Un utilisateur signale une réponse aberrante, on rejoue exactement le même appel, tout se passe bien. Le réflexe est de conclure que l’utilisateur s’est trompé. C’est presque toujours faux.

Ce qu’il faut mettre en place à la place :

• Journaliser l’entrée exacte de chaque appel — pas seulement la requête utilisateur, mais le prompt complet réellement envoyé, contexte inclus. Sans lui, un incident est indiagnosticable.
• Raisonner en taux, pas en cas. La bonne question n’est pas « pourquoi cette réponse était-elle mauvaise » mais « sur cent cas semblables, combien le sont ». La première mène à une chasse au fantôme, la seconde à une décision.
• Accepter un taux d’erreur cible. C’est le changement culturel le plus difficile à faire passer, notamment côté client : une fonctionnalité IA n’est pas juste ou fausse, elle a un taux. Le travail consiste à le connaître, à le rendre acceptable, et à faire en sorte que les erreurs restantes soient rattrapables.

2. L’évaluation remplace le test unitaire

Un test unitaire assert une égalité. Il n’y a pas d’égalité à asserter sur une réponse en langue naturelle : deux formulations correctes sont toutes deux correctes.

Ce qui remplace le test, c’est un jeu d’évaluation : un ensemble de cas représentatifs, avec pour chacun ce qu’on attend — non pas le texte exact, mais la propriété à vérifier. Le dossier est-il bien identifié ? Le montant extrait est-il le bon ? La réponse reste-t-elle dans le périmètre autorisé ?

Trois choses à savoir avant de s’y mettre.

Le jeu de cas est l’actif principal, pas le prompt. Un prompt se réécrit en une heure. Un jeu de deux cents cas représentatifs, construit à partir d’usages réels, c’est des semaines de travail — et c’est lui qui permet de changer de modèle sans peur. Les équipes qui n’en ont pas sont prisonnières de leur fournisseur, non par contrat mais par ignorance de ce qu’un changement casserait.

Une partie de l’évaluation peut être automatisée, pas toute. Sur les propriétés vérifiables — un montant, une référence, un choix parmi une liste — la comparaison est mécanique. Sur la qualité d’une formulation, on utilise un second modèle comme juge. C’est efficace et il faut connaître la limite : un juge a ses propres biais, il est indulgent avec les réponses qui ressemblent à ce qu’il aurait produit. Un échantillon relu par un humain reste nécessaire.

L’évaluation doit tourner en continu, pas avant les livraisons. Un modèle évolue côté fournisseur, parfois sans annonce. Une chaîne qui passait à 94 % peut passer à 88 % sans qu’une seule ligne de code ait changé. Si l’évaluation ne tourne qu’au moment des mises en production, la dégradation se découvre par une réclamation client.

3. Le coût devient variable, et il faut le modéliser

Un serveur applicatif coûte à peu près la même chose qu’il traite mille ou dix mille requêtes. Une fonctionnalité IA coûte proportionnellement à son usage, et le prix se paie à la quantité de texte échangée.

Trois effets qu’on découvre tard.

Le contexte coûte plus cher que la réponse. On se concentre sur ce que le modèle produit, alors que la facture vient surtout de ce qu’on lui envoie. Un prompt qui embarque tout un historique de conversation, un catalogue ou une documentation coûte à chaque appel — et cette part croît avec la durée de la session.

Les mécanismes de cache de contexte proposés par les fournisseurs changent l’ordre de grandeur sur ce poste, à condition de structurer les prompts pour que la partie stable soit réellement réutilisable. Cela impose de mettre l’invariant en tête et le variable en fin, ce qui n’est pas la façon naturelle de rédiger.

Le succès est un risque budgétaire. Une fonctionnalité adoptée trois fois plus que prévu coûte trois fois plus. Sur un logiciel classique, c’est une bonne nouvelle sans contrepartie. Ici, il faut plafonner : par utilisateur, par session, par jour — et décider à l’avance ce qui se passe quand le plafond est atteint. Le décider en urgence, en production, produit toujours la mauvaise réponse.

Le coût doit être attribuable. Sur une plateforme multi-clients, savoir combien consomme chaque client n’est pas un confort comptable : c’est ce qui permet de facturer correctement et de repérer un usage anormal. Cela s’instrumente dès le premier jour, parce que reconstituer l’historique après coup est impossible.

4. Les pannes ne ressemblent pas à des pannes

C’est le point qui m’a le plus surpris en exploitation.

Un service classique tombe : il renvoie une erreur, l’alerte part, on intervient. Une fonctionnalité IA se dégrade sans rien signaler. Elle répond. Ses réponses sont simplement moins bonnes.

Les modes de défaillance qu’on rencontre réellement :

• La lenteur soudaine. Le fournisseur ralentit, sans erreur. Sur une interaction synchrone — a fortiori vocale — c’est perçu comme une panne alors que tous les indicateurs sont au vert.
• La dérive silencieuse. Une mise à jour de modèle change les formulations, et une règle métier qui reposait sur une formulation stable cesse de fonctionner.
• La réponse hors périmètre. Le modèle répond à côté, avec assurance. C’est le pire cas, parce qu’un utilisateur non expert ne peut pas le détecter.
• La coupure franche. Le seul cas qui ressemble à une panne classique, et le plus facile à traiter.

La supervision doit donc porter sur des indicateurs métier, pas techniques. Un taux de succès disponible ne dit rien. Ce qui dit quelque chose : la part de réponses où le modèle a déclaré ne pas savoir, la part de conversations reprises par un humain, la longueur moyenne des échanges — qui monte quand le modèle comprend mal. Ces trois courbes bougent avant les réclamations.

Photo : domaine public (CC0).

5. La résilience se conçoit, elle ne s’ajoute pas

Puisque le service dont on dépend peut ralentir, se dégrader ou disparaître, la chaîne doit être conçue pour continuer à rendre un service réduit plutôt que de s’arrêter.

Trois mécanismes que nous mettons systématiquement.

Le repli entre fournisseurs. Les composants — transcription, génération, synthèse — sont derrière une interface, et le fournisseur se choisit par configuration. Ce n’est pas seulement de la réversibilité contractuelle : c’est ce qui permet de basculer en quelques minutes quand un fournisseur a un incident, et de comparer deux modèles en conditions réelles plutôt que sur des classements publics.

Le chien de garde. Un appel qui ne revient pas doit être abandonné, et l’abandon doit produire quelque chose d’utile pour l’utilisateur. Sans délai maximal explicite, une lenteur côté fournisseur se propage jusqu’à saturer votre propre service.

La dégradation annoncée. Quand la génération prend trop de temps, il vaut mieux dire « un instant » que laisser un silence. C’est un détail d’interface, et c’est ce qui fait la différence entre « c’est lent » et « c’est cassé » dans la tête de l’utilisateur. Avec une réserve que nous appliquons : meubler l’anomalie, jamais le fonctionnement normal — une interjection systématique s’entend au bout de trois échanges.

Photo : domaine public (CC0).

6. Les prompts sont du code, avec de moins bons outils

Un prompt détermine le comportement du produit aussi sûrement qu’une fonction. Il mérite le même traitement, et il l’obtient rarement, parce que sa forme — du texte — invite à le modifier vite.

Ce que nous imposons :

• Versionner dans le dépôt, jamais dans une base de configuration modifiable en production sans trace. Un changement de comportement doit être attribuable à un commit.
• Relire. Un prompt modifié passe en revue comme du code. C’est là qu’on repère la formulation ambiguë ou l’instruction contradictoire ajoutée pour régler un cas particulier.
• Évaluer avant de fusionner. Le jeu de cas de la section 2 tourne sur la nouvelle version. Corriger un cas en dégradant dix autres est l’erreur la plus fréquente, et elle est invisible sans mesure.

Un mot sur une tentation courante : accumuler les instructions. Chaque cas particulier ajoute deux lignes au prompt, et six mois plus tard il fait trois pages dont personne ne connaît la raison d’être. Un prompt long n’est pas seulement coûteux — il dilue les instructions importantes. Quand un cas particulier revient trop souvent, c’est généralement le signe qu’il faut le traiter en code, en amont, plutôt que de demander au modèle d’y penser.

Photo : domaine public (CC0).

7. L’observabilité pose une question qu’on n’avait pas

Diagnostiquer suppose de conserver les échanges. Or ces échanges contiennent ce que les utilisateurs ont écrit ou dit — souvent des données personnelles, parfois sensibles.

Les décisions à prendre explicitement, et à écrire :

• Que conserve-t-on, et pendant combien de temps ? Une durée courte suffit pour diagnostiquer la plupart des incidents ; une durée longue est nécessaire pour construire un jeu d’évaluation. Ce ne sont pas les mêmes finalités, et elles ne justifient pas la même durée.
• Qui peut lire ? L’accès aux conversations est une porte ouverte sur les échanges des utilisateurs. Il se restreint, se journalise, et se justifie.
• Que part-il chez le fournisseur ? Les conditions varient d’un fournisseur à l’autre, et changent. C’est une question à poser à chaque contrat, pas une fois pour toutes.

Ces questions ne sont pas des formalités juridiques ajoutées à la fin : elles déterminent des choix d’architecture. Décider qu’aucune donnée nominative ne doit sortir impose une étape d’anonymisation en amont, avec son propre taux d’erreur — et donc son propre jeu d’évaluation.

8. La reprise par un humain se conçoit dès le début

Puisqu’un taux d’erreur subsiste par construction, la question n’est pas de l’annuler mais de décider ce qui arrive quand il se manifeste. C’est une décision de conception, et elle se prend avant le développement — la greffer après revient à réécrire le parcours.

Trois points à trancher.

Le modèle doit pouvoir dire qu’il ne sait pas. C’est plus utile qu’une réponse produite avec une confiance moyenne, et cela ne va pas de soi : un modèle est spontanément disert. L’obtenir demande de le prévoir dans le prompt, et surtout de le vérifier dans le jeu d’évaluation — le taux d’abstention justifiée est un indicateur au même titre que le taux de bonne réponse.

Le passage à l’humain doit exister et être atteignable. Sans porte de sortie disponible, une demande simple se transforme en réclamation. Et cette porte doit être ouverte en permanence, pas enfouie derrière un parcours qu’il faut deviner.

Ce qui est repris doit revenir dans l’évaluation. Chaque cas transmis à un humain est un cas d’apprentissage gratuit : c’est exactement la matière qui manque au jeu de cas. Les équipes qui ne bouclent pas cette boucle réévaluent indéfiniment sur les mêmes exemples de départ, pendant que les vrais échecs passent inaperçus.

9. Ce qui ne change pas

Après cette liste, un rééquilibrage utile : la plupart des difficultés d’un projet contenant de l’IA ne viennent pas de l’IA.

Elles viennent de l’accès aux données — une information qui n’est exposée nulle part reste inaccessible, quel que soit le modèle. Elles viennent du périmètre mal cadré, des décisions qui tardent, de la reprise des données existantes. Ce sont exactement les mêmes difficultés que sur un projet sans IA, et elles pèsent toujours plus lourd.

C’est pourquoi nous refusons de traiter un projet IA comme une catégorie à part. C’est un projet logiciel, avec une brique supplémentaire qui a ses propres règles. Les équipes qui l’abordent comme une aventure technologique se retrouvent avec un prototype impressionnant et rien en production ; celles qui l’abordent comme un projet ordinaire, en apprenant les quelques règles spécifiques, livrent.

La liste avant de se lancer

Si vous vous apprêtez à mettre une fonctionnalité IA en production, ces sept questions révèlent en une réunion si le sujet a été traité :

1. Quel est le taux d’erreur acceptable, et comment le mesure-t-on ?
2. Existe-t-il un jeu de cas d’évaluation, et qui le maintient ?
3. Que se passe-t-il quand le fournisseur ralentit ? Quand il tombe ?
4. Quel est le coût par utilisateur et par mois, et qu’arrive-t-il si l’usage triple ?
5. Comment saura-t-on que la qualité s’est dégradée, avant les réclamations ?
6. Où vivent les prompts, et qui valide leurs modifications ?
7. Que conserve-t-on des échanges, combien de temps, et qui y accède ?

Aucune de ces questions ne porte sur le choix du modèle. C’est volontaire : c’est la décision la plus réversible de la liste, et de loin la moins structurante.