Sans équipe ML : qui exploite après le lancement un système LLM pour les tickets de support et les documents sur vos propres serveurs ?

Un système LLM qui trie les tickets de support et lit des documents sur vos propres serveurs a toujours besoin, après le lancement, de quelqu'un pour l'exploiter. LLM signifie large language model, ou grand modèle de langage, le type d'IA sur lequel repose ChatGPT. Une entreprise sans équipe d'apprentissage automatique (ML) a trois voies. Le prestataire qui a construit le système peut continuer à l'exploiter dans le cadre d'un contrat de support. Après une passation, votre équipe informatique peut le reprendre à sa place, ou se partager le travail avec le prestataire. Quelle que soit la voie, quelqu'un doit vérifier régulièrement la qualité des réponses et approuver chaque changement de modèle avant sa mise en production.

En quoi consiste l'exploitation d'un système LLM après le lancement ?

Après le lancement, l'exploitation d'un système LLM se résume à ces tâches récurrentes :

• Les serveurs, souvent équipés de GPU (les puces sur lesquelles tournent les modèles de langage), et les mises à jour du logiciel qui fait tourner le modèle
• La version du modèle utilisée, et la décision du moment où la changer
• La notation régulière des réponses sur un échantillon fixe de vos propres tickets et documents
• La file de revue, c'est-à-dire les éléments que le logiciel confie à une personne, et le personnel qui la traite
• Les changements de votre côté, comme un nouveau formulaire, une nouvelle catégorie de tickets ou une nouvelle règle métier
• Les logs, qui enregistrent ce que le système a fait, et les droits d'accès aux tickets et aux documents
• Les pannes de nuit, et la personne qu'on appelle alors

vLLM est un programme open source qui permet de faire tourner des modèles sur vos propres serveurs. Sa page de sécurité sur GitHub, consultée le 20 octobre 2026, recense un avis du 6 octobre 2026 sur une faille corrigée dans la version 0.31.0. Le titre de l'avis est : « Un min_tokens surdimensionné dans une seule requête bloque le moteur vLLM alors que /health reste au vert ». Dans ce titre, min_tokens est un paramètre de requête qui fixe la longueur minimale de la réponse.

Un outil de supervision interroge une adresse comme /health pour vérifier qu'un serveur est en vie. Dans le cas que décrit l'avis de vLLM, le serveur semble en bonne santé alors qu'il a cessé de répondre aux requêtes. La supervision d'un système LLM doit envoyer de vraies requêtes de test et vérifier que les réponses reviennent.

En quoi notre propre système diffère-t-il d'un outil de support avec IA intégrée ?

Avec un outil de support vendu en logiciel en tant que service (SaaS), un outil que vous louez via Internet, l'éditeur exploite le service, et le modèle tourne sur les serveurs de l'éditeur ou sur ceux d'entreprises avec lesquelles il travaille. Vos tickets partent chez l'éditeur et chez ces entreprises. L'article consacré au logiciel d'IA documentaire ou au pipeline LLM sur mesure traite du choix entre un tel outil et votre propre système.

Zendesk, un éditeur d'outils de support, indique sur sa page consacrée à l'IA générative, consultée le même jour, que « Zendesk intègre les LLM dans les Services de deux manières ». La première utilise des modèles hébergés sur des plateformes « telles qu'AWS Bedrock, Microsoft Azure, Groq ou Fireworks AI », et Zendesk précise que dans ce cas « le fournisseur du LLM n'accède jamais à vos Données de service ». La seconde utilise des modèles « directement hébergés par le fournisseur du modèle », comme OpenAI et Google Gemini. Pour ceux-ci, Zendesk indique que le texte envoyé au modèle et ses réponses « ne sont conservés dans aucun mécanisme de journalisation ».

Intercom, un autre éditeur d'outils de support, publie une liste de sous-traitants ultérieurs, les entreprises qui traitent des données pour son compte. Cette liste, en vigueur depuis le 25 juin 2026 et consultée le même jour, cite notamment OpenAI, Anthropic, Google et Microsoft pour le « traitement par IA ». La page précise que les listes « peuvent être mises à jour par Intercom de temps à autre ».

Le prestataire qui a construit notre système LLM peut-il continuer à l'exploiter ?

Le prestataire qui a construit le système peut proposer un contrat de support, un contrat par lequel il maintient le système en fonctionnement après le lancement. Vérifiez ce que dit le contrat sur ces points :

• Ce qui compte comme un incident, par exemple l'arrêt du système ou un champ mal lu sur de nombreux documents, et en combien de temps quelqu'un réagit à chaque type d'incident
• Qui peut se connecter à vos serveurs, avec quels comptes, et comment cet accès est tracé
• Qui paie les serveurs, et qui décide quand il faut plus de capacité
• Ce qu'est une demande de changement, par exemple l'ajout d'un type de document ou d'une catégorie de tickets, et comment elle est facturée
• Les rapports que vous recevez chaque mois, comme les scores de qualité, les volumes de la file de revue et les incidents

Laisser le système au prestataire est ce qui demande le moins à votre personnel. Le savoir-faire reste alors chez le prestataire, et votre entreprise dépend de lui pour la plupart des changements. Ce que vous devez détenir lorsque le prestataire s'en va est traité dans l'article sur les questions qu'un directeur des opérations doit poser avant de signer.

Notre équipe informatique n'a aucune expérience en ML. Peut-elle reprendre le système ?

Une équipe informatique qui gère déjà les serveurs de votre entreprise peut généralement ajouter à son travail les serveurs, les droits d'accès, les sauvegardes et la supervision du système LLM. Les tâches propres aux modèles de langage, comme lire les scores de qualité et tester une nouvelle version du modèle, demandent d'abord une formation.

Pour la passation, l'équipe informatique a besoin de runbooks, des guides pas à pas pour les tâches quotidiennes et pour chaque panne connue, comme une file de revue qui sature. L'équipe a aussi besoin de l'échantillon de test de vos tickets et documents avec les bonnes réponses, et du script qui note le système sur cet échantillon. Le code et les fichiers du modèle doivent être stockés sur un espace que votre entreprise contrôle.

Un environnement de test, c'est-à-dire une copie du système où les changements sont essayés avant d'atteindre de vrais tickets, doit exister avant le lancement. La formation peut s'y dérouler : votre équipe effectue les tâches courantes sur la copie, et les ingénieurs du prestataire vérifient le travail.

Les modifications de prompts et de règles ont besoin d'un responsable. Un prompt est le texte qui indique au modèle ce qu'il doit faire. Quand un formulaire change ou qu'une nouvelle catégorie de tickets apparaît, quelqu'un doit mettre à jour le prompt ou les règles et relancer la notation sur l'échantillon de test. Décidez si cette personne se trouve à l'informatique, chez le prestataire ou dans l'équipe responsable du processus, comme le support.

Comment fonctionnerait un partage entre notre équipe informatique et le prestataire ?

Dans un partage, votre équipe informatique garde les serveurs et les accès, et le prestataire est sollicité pour les changements de modèle et les problèmes de qualité.

Un partage peut laisser une zone grise. Quand la qualité baisse, l'informatique peut accuser le modèle et le prestataire les serveurs : le contrat doit donc préciser par écrit qui décide de quoi.

Par exemple, votre entreprise approuve chaque nouvelle version du modèle après que le prestataire l'a notée sur l'échantillon de test. Corriger un problème de qualité revient au prestataire, tandis que l'accès aux serveurs reste une décision de votre équipe informatique. Désignez aussi la personne qui intervient en premier quand une alerte se déclenche la nuit, et la façon dont elle joint l'autre partie.

Pourquoi la qualité des réponses baisse-t-elle parfois après le lancement ?

La précision peut dériver, c'est-à-dire changer lentement sans aucun message d'erreur. De nouveaux sujets de tickets après le lancement d'un produit, un formulaire modifié ou une nouvelle version du modèle peuvent chacun provoquer une dérive. Les serveurs tournent comme avant, si bien que la supervision des serveurs ne montre pas la baisse.

La dérive apparaît quand le même échantillon de vos tickets et documents, avec les bonnes réponses, est noté à nouveau. Cela doit se faire selon un calendrier, par exemple tous les mois, et après chaque changement du modèle, du prompt ou des règles. Comparez chaque score à celui enregistré au lancement.

Les articles sur un pilote d'IA resté bloqué et sur les questions d'un directeur des opérations expliquent comment constituer l'échantillon de test. Quelle que soit la voie choisie, le contrat doit désigner la personne qui refait la notation et préciser qui voit les résultats.

Qui décide quand le modèle change ?

Avec un modèle à poids ouverts sur vos propres serveurs, c'est votre entreprise qui décide quand changer. Un modèle à poids ouverts est un modèle dont l'éditeur publie les fichiers pour que chacun puisse les télécharger et les faire tourner selon sa licence. La licence s'applique toujours, et une version plus récente peut être publiée sous une autre licence.

Les modèles Gemma de Google en sont un exemple. La page de Gemma 3 sur le site de modèles Hugging Face, consultée le même jour, renvoie aux Gemma Terms of Use, qui intègrent une Prohibited Use Policy. Le blog open source de Google indiquait le 2 avril 2026 que « les modèles Gemma 4 sont les premiers du Gemmaverse à être publiés sous la licence Apache 2.0 approuvée par l'OSI. » Passer de Gemma 3 à Gemma 4 change donc la licence que lisent vos juristes : des conditions propres à Google, on passe à Apache 2.0, une licence open source.

Un système sur vos propres serveurs peut tout de même appeler un modèle via une API hébergée, une connexion par Internet aux serveurs d'une autre entreprise. Ce modèle est retiré selon le calendrier de cette entreprise. La page d'Anthropic sur l'abandon des modèles, consultée le même jour, indique : « Les requêtes adressées aux modèles après la date de retrait échoueront. » Anthropic dit donner aux clients ayant des déploiements actifs « un préavis d'au moins 60 jours avant le retrait des modèles rendus publics ». La page ajoute que ses dates s'appliquent aux plateformes propres d'Anthropic, et qu'Amazon Bedrock et Google Cloud « fixent leurs propres calendriers de retrait ».

Chaque changement implique de noter la nouvelle version sur votre échantillon avant sa mise en production, en gardant l'ancienne prête au cas où les scores baisseraient. La page d'Anthropic recommande de « tester minutieusement vos applications avec les nouveaux modèles bien avant la date de retrait. »

Un ticket de support peut-il piéger le système ?

L'injection de prompt (prompt injection) est une attaque dans laquelle un texte envoyé au système contient des instructions destinées au modèle. Les tickets de support viennent de l'extérieur de votre entreprise : un système qui les lit reste donc exposé tant qu'il fonctionne. L'OWASP Top 10 for LLM Applications 2025, une liste de risques publiée par le projet de sécurité OWASP et consultée le même jour, place l'injection de prompt en premier. Un exemple indique : « Un attaquant injecte un prompt dans un chatbot de support client, lui ordonnant d'ignorer les consignes précédentes, d'interroger des bases de données privées et d'envoyer des e-mails, ce qui conduit à un accès non autorisé et à une élévation de privilèges. »

Les règles de conception contre l'injection de prompt, comme ne pas donner au système plus d'accès que sa tâche n'en exige, figurent dans l'article sur un pilote resté bloqué. L'OWASP cite aussi une mesure à répéter tant que le système tourne : « Effectuez régulièrement des tests d'intrusion et des simulations de compromission, en traitant le modèle comme un utilisateur non fiable ». Lors d'un test d'intrusion, des testeurs tentent délibérément de pénétrer dans le système, avec votre autorisation.

Les tests d'intrusion ont leur place dans le calendrier des tâches d'exploitation, et le contrat doit préciser quelle partie les commande et corrige ce qu'ils révèlent. Les logs peuvent contenir le texte intégral des tickets : décidez donc qui peut les lire et combien de temps ils sont conservés.

Combien coûtera l'exploitation du système chaque mois, et que demander avant de signer ?

Sur vos propres serveurs, les coûts mensuels commencent par les serveurs et leurs GPU, achetés ou loués, et par le temps que le personnel passe sur la file de revue. Un contrat de support s'y ajoute si le prestataire garde un rôle, de même que les nouveaux tests après chaque changement. Aucun chiffre n'est donné, car chacun dépend de vos volumes et de votre configuration.

La répartition des coûts dépend de la voie choisie. Quand le prestataire exploite le système, une grande partie du coût se trouve dans le contrat de support. Après une passation, une plus grande part correspond au temps de votre propre personnel, formation comprise.

Posez les mêmes questions à chaque société qui propose de construire et d'exploiter le système :

• Quelles tâches d'exploitation prendrez-vous en charge après le lancement, et lesquelles fera notre équipe informatique ?
• À quelle fréquence noterez-vous le système sur notre échantillon de test ?
• Qui paie les nouveaux tests quand une version de modèle que nous utilisons est retirée ?
• Que reçoit notre équipe informatique lors de la passation, et comment vérifierez-vous qu'elle peut exploiter le système seule ?

Les conditions de licence varient d'un modèle à l'autre, et les règles de protection des données varient selon les pays. Cet article ne constitue pas un conseil juridique : vérifiez donc avec un avocat les conditions qui s'appliquent à vous.

Où se situe amBrain ?

Le seul projet de modèle de langage qu'amBrain décrit publiquement est le suivant : « Nous avons mené une intégration de LLM jusqu'en production dans le périmètre FinTech d'un client : extraction et normalisation d'avis non structurés de courtiers et de places de marché — opérations sur titres, changements d'instruments et de marges — en enregistrements structurés consommés par le système de trading. »

Cet article n'est pas une étude de cas et ne décrit aucun travail pour un client. La phrase citée ne dit pas qui exploite ce système aujourd'hui, où tourne son modèle ni lesquelles des étapes de cet article il comprenait. Les tickets de support, les documents et les voies d'exploitation de cet article sont des exemples généraux et ne sont tirés ni de ce projet ni d'aucun autre travail d'amBrain.

Les éditeurs, les créateurs de modèles et les projets logiciels cités ici sont des exemples tirés de pages publiées, et l'article n'affirme aucune relation entre amBrain et l'un d'eux. L'article ne donne ni prix, ni délais, ni conditions d'amBrain.

amBrain développe des logiciels depuis 2019. Elle travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Sur la propriété, sa formule est : « Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables. » Si amBrain figure sur votre liste restreinte, posez-lui les mêmes questions qu'à n'importe quelle autre société.