Notre practice logiciel & IA traite les applications LLM comme toute autre surface de production : SLO, ownership et évaluation—pas seulement le prompt. Les thèmes MLOps sérieux s’appliquent : frontières de données, reproductibilité et monitoring qui explique pourquoi une mauvaise réponse est apparue.
Périmètre orienté valeur. Partir de flux à gain mesurable—déviation support, recherche interne, rédaction documentaire avec relecture humaine—et non de « discuter avec toute notre base de connaissances » comme science-fiction.
Données sécurisées. Masquage PII, contraintes de résidence et isolation multi-locataire sont des inputs de conception. La couche de retrieval doit respecter l’autorisation des systèmes sources, pas seulement l’UI.
Évaluation exécutable par les ingénieurs. Jeux de données gold, régression auto sur prompts et contrôles en ligne (toxicité, fuite) vivent dans la CI avec les tests unitaires. Si seuls les chercheurs lancent les evals, elles ne tourneront pas au release.
Agent dans la boucle. Pour les domaines à enjeux, coupler automatisation et points de contrôle humains explicites, avec télémétrie sur le taux de contournement—ces signaux disent si le modèle ou le processus dérive.
RAG, outils et fine-tuning ont chacun leur place ; la discipline est de choisir la plus petite combinaison qui tient la barre, puis durcir. Les modèles fancy compensent rarement une ingestion bancale ou une observabilité absente.
À lire aussi : stratégie IA & MLOps, conseil DevOps et ressources.
Un exemple concret : verrouiller une fonctionnalité de déviation support
Prenons un assistant support qui rédige des réponses aux tickets entrants pour qu’un agent humain les valide. Avant de dépasser le stade pilote, nous construisons un jeu de données gold de deux cents à cinq cents tickets réels, annotés à la main avec la réponse qu’un agent expérimenté aurait donnée, répartis selon les catégories qui comptent le plus pour le métier—remboursements, accès au compte et questions produit dominent en général. Chaque changement de prompt ou de retrieval passe sur ce jeu avant merge, et une baisse de qualité sur une seule catégorie bloque la release, pas seulement un score agrégé qui glisse d’un point ou deux.
Le garde-fou le plus difficile est celui que personne ne veut construire : un contrôle en ligne qui échantillonne un petit pourcentage du trafic réel, le note selon la même grille de façon asynchrone, et alerte un relecteur humain quand le score descend sous un seuil pendant une fenêtre soutenue. Cela capture ce que les évaluations hors ligne ne peuvent pas voir : une mise à jour de base de connaissances trois semaines après le lancement qui dégrade silencieusement la couche de retrieval pour une ligne de produit que le jeu gold ne couvre pas bien. Nous avons vu ce scénario exact coûter à un client deux semaines de réponses discrètement fausses avant qu’un lead support ne remarque une hausse des plaintes dans la file de tickets.
La télémétrie de contournement compte autant que le score automatisé. Si les relecteurs humains rejettent ou corrigent lourdement plus de quinze pour cent environ des brouillons d’une catégorie, c’est un signal que le modèle n’est pas prêt pour cette catégorie, quoi que dise l’évaluation hors ligne, et la démarche honnête est de repasser cette catégorie en traitement entièrement manuel jusqu’à ce que l’écart se referme.
Les pièges que nous voyons revenir
Le premier est de traiter le jeu de données gold initial comme permanent. Les équipes construisent deux cents exemples au lancement, verrouillent chaque release dessus pendant un an, et surajustent lentement le prompt à ce jeu précis pendant que le trafic réel dérive vers des formulations et des cas limites que le jeu n’a jamais couverts. Nous rafraîchissons les jeux gold chaque trimestre avec un échantillon d’échecs réels de production ; les exemples retirés sont archivés plutôt que supprimés pour que les régressions restent détectables.
Le deuxième est de confondre une réponse qui sonne utile avec une réponse correcte. Le scoring LLM-as-judge est utile pour capter les régressions de ton et de format, mais c’est un piètre substitut à la relecture par un expert métier sur la justesse factuelle, en particulier dans les catégories réglementées comme la facturation ou l’éligibilité. Nous couplons les juges automatisés à un échantillon tournant envoyé chaque semaine à un expert du domaine, spécifiquement pour attraper les cas où une réponse fluide se trompe avec assurance.
Le troisième est de sauter le travail d’infrastructure ennuyeux parce que le modèle semble être la partie intéressante. Un versionnage de prompt non lié à un commit git, des runs d’évaluation non reproductibles parce que la température ou la version de l’index de retrieval n’étaient pas fixées, et des tableaux de bord qui affichent un taux de réussite agrégé sans détail par catégorie—tout cela ressort plus tard comme la raison pour laquelle personne ne peut expliquer pourquoi la qualité a discrètement chuté mardi dernier.
Décider quand un garde-fou est assez strict pour se lancer derrière
Les clients demandent souvent un seuil de qualité unique, comme si 95 pour cent de précision était une barre universelle. Nous contestons ce cadrage. Le bon seuil dépend du coût des deux types d’erreur, et ils sont rarement symétriques. Un brouillon support trop prudent qui renvoie vers un humain coûte quelques secondes de relecture. Un brouillon qui affirme avec assurance une politique de remboursement incorrecte coûte un rétrofacturation, une plainte, ou dans les secteurs réglementés un constat de non-conformité. Nous fixons des seuils séparés pour la fausse confiance et la fausse prudence, et nous serrons nettement plus le seuil de confiance, car le risque est asymétrique même quand les chiffres de précision agrégée se ressemblent.
Nous insistons aussi sur un déploiement par paliers lié aux résultats d’évaluation plutôt qu’un seul feu vert ou rouge. Une fonctionnalité qui passe le jeu gold arrive à cinq pour cent du trafic réel avec le contrôle en ligne actif, puis à vingt-cinq pour cent après une semaine de scores en ligne propres, puis au trafic complet. Chaque palier a son propre déclencheur de rollback, et reculer d’un palier est un changement de config, pas un incident. Les équipes qui sautent le déploiement par paliers finissent souvent par découvrir une régression via un pic d’escalades support plutôt que via leur propre monitoring, ce qui est une pire façon d’apprendre la même leçon.
Enfin, nous inscrivons les critères de passage du garde-fou dans le même document qui définit les critères de lancement de la fonctionnalité, revu conjointement par le produit et l’ingénierie avant qu’une seule ligne de prompt ne soit écrite. Rattraper un cadre d’évaluation sur une fonctionnalité déjà livrée à de vrais utilisateurs est possible, mais coûte plus cher que de construire le garde-fou d’abord, et entre-temps la fonctionnalité tourne sans le filet de sécurité dont elle a toujours eu besoin.