LLMOps

Du prototype au service

Un prototype de modèle de langage se construit en quelques jours : une consigne, un modèle, un exemple de document. Le passage en service prend beaucoup plus de temps. Il faut gérer les erreurs, les délais, les coûts, les changements de version du fournisseur et les questions hors périmètre. Le LLMOps désigne le travail qui comble cet écart, par analogie avec l'exploitation logicielle, en tenant compte des spécificités des modèles : comportement variable, dépendance à un service externe, qualité difficile à spécifier.

La première décision porte sur le périmètre. Un assistant qui répond à tout est impossible à évaluer ; un assistant qui traite trois types de demandes bien définies se mesure. Délimiter les cas d'usage, écrire les réponses attendues et prévoir le comportement en cas de doute constituent la base. Ces choix se font avec les métiers, pas seulement avec l'équipe technique, car eux seuls savent ce qu'une réponse acceptable signifie dans leur travail quotidien.

Ce que l'on mesure

Les indicateurs se répartissent en trois familles. La qualité, évaluée sur un jeu de cas annotés, avec des critères explicites : exactitude, complétude, absence d'invention. La fiabilité, mesurée par le taux d'erreurs, les délais de réponse et la disponibilité. L'usage, suivi par le nombre de demandes, le taux de reprise par un humain et les motifs d'abandon. Ces mesures se prennent avant et après chaque changement, sinon elles ne sont pas interprétables.

L'évaluation humaine reste nécessaire. Les modèles automatiques notent mal les nuances de ton, la pertinence locale ou la conformité à une procédure interne. Un panel restreint de relecteurs, avec une grille commune, donne des résultats plus utiles qu'un score unique. Prévoir un échantillonnage régulier des échanges réels permet de détecter les dérives que les cas de test ne couvrent pas, notamment l'arrivée de formulations ou de demandes nouvelles. Un relevé mensuel de ces retours suffit à orienter les corrections les plus utiles.

Versions et coûts

Les fournisseurs modifient leurs modèles sans préavis long. Un service qui fonctionnait peut changer de ton, de format ou de qualité sur un type de demande. Figer une version quand c'est possible, tester avant de migrer et conserver un mode de retour arrière sont des précautions élémentaires. Tenir un journal des versions utilisées, avec les résultats d'évaluation associés, permet d'expliquer une régression et de la corriger sans tâtonner pendant plusieurs jours.

Le coût ne se limite pas aux appels. Il comprend l'intégration, la préparation des données, la relecture humaine, la supervision et la maintenance. Les appels peuvent devenir la part visible d'une dépense plus large. Un suivi par usage, avec un plafond et une alerte, évite les surprises de fin de mois. Comparer le coût complet à celui du traitement actuel, temps passé inclus, reste la seule base sérieuse de décision budgétaire.

Organisation et responsabilités

Un dispositif minimum tient en quatre rôles : un responsable du produit qui arbitre les cas d'usage, un référent technique qui suit les modèles et les intégrations, un référent métier qui valide la qualité, et un responsable de la conformité pour les données personnelles. Ces rôles peuvent être cumulés dans une petite structure, mais ils doivent être nommés. L'absence de responsable identifié est une cause fréquente des projets qui s'arrêtent sans décision claire.

La documentation compte autant que le code. Consigner les consignes employées, les données envoyées, les résultats des tests et les incidents connus permet à une autre personne de reprendre le service. Elle facilite aussi les réponses à un client ou à un contrôleur. Un espace interne suffit, à condition d'être à jour. C'est un investissement modeste qui évite de reconstituer l'historique à chaque changement de prestataire ou de salarié. Mieux vaut un document court et daté qu'un dossier exhaustif que personne n'ouvre.