Module 10 — Projet : assistant spécialisé sur poste de travail
Nous assemblons les neuf modules précédents en un projet concret : un assistant de classification et de résumé de tickets d'assistance, exécuté localement sur les postes de 40 agents, comparé sur 200 tickets réels à un grand modèle en API. La question à laquelle nous répondons est simple : est-ce que ce projet vaut son investissement ?
La pile technique retenue
Les décisions prises au fil des modules donnent la pile suivante.
Modèle de base. Ministral 3B Instruct, licence Apache 2.0. Choisi au module 2 pour sa qualité en français, sa taille compatible avec un GPU d'entrée de gamme, et l'absence de contrainte de licence commerciale.
Adaptation. Un adaptateur LoRA affiné sur 600 tickets internes annotés par un binôme d'agents seniors (module 7). Rang 16, deux époques, QLoRA avec base en 4 bits. L'adaptateur pèse 52 Mo et se distribue séparément du modèle de base.
Format. Modèle de base et adaptateur fusionnés puis convertis en GGUF Q4_K_M (module 5), soit un fichier unique de 2,1 Go signé et versionné.
Moteur. Ollama sous Windows, macOS et Ubuntu (module 8), servi sur localhost:11434, appelé par une extension navigateur intégrée à l'outil de ticket existant.
Matériel. Postes équipés d'une RTX 3050 6 Go ou d'une carte équivalente, 16 Go de RAM. Coût de mise à niveau : 260 euros par poste sur les 30 postes qui n'étaient pas déjà équipés.
Le protocole d'évaluation final
Les 200 tickets réels intouchables passent dans deux systèmes en aveugle :
- Notre assistant local (Ministral 3B affiné, Q4_K_M, RTX 3050).
- Un grand modèle en API (référence commerciale largement adoptée dans l'entreprise).
Trois experts métier reçoivent les 400 réponses mélangées et notent chaque triplet (ticket, catégorie proposée, résumé) sur trois axes : catégorie correcte, résumé fidèle, résumé lisible. Les notes sont agrégées à la médiane inter-évaluateurs.
Nous mesurons en parallèle la latence 95ᵉ centile et le coût par 1 000 requêtes.
Ce que la mesure montre
Sur les 200 tickets, agrégés :
| Système | Catégorie correcte | Résumé fidèle | Résumé lisible | Latence p95 | Coût / 1 000 req. |
|---|---|---|---|---|---|
| Assistant local | 96 % | 89 % | 92 % | 1,1 s | ~0 € |
| Grand modèle API | 97 % | 94 % | 96 % | 1,8 s | 4,20 € |
L'écart de qualité est de 1 point sur la catégorie, 5 points sur la fidélité du résumé et 4 points sur la lisibilité. Sur ces trois axes, notre assistant local est suffisant pour le flux principal, avec une latence perçue meilleure et un coût marginal nul.
Le coût total sur un an
L'assistant sert 40 agents qui traitent en moyenne 60 tickets par jour, soit ~500 000 requêtes par an.
Solution locale. Matériel de mise à niveau : 260 € × 30 postes = 7 800 €, amorti sur trois ans = 2 600 €/an. Coût d'affinage (une itération par trimestre pour tenir compte des nouveaux produits) : 4 × 2 € = 8 €. Coût d'exploitation (temps informatique consacré aux mises à jour) : 30 h × 65 €/h = 1 950 €. Total : 4 560 €/an.
Solution API. 500 000 requêtes × 4,20 €/1 000 = 2 100 €/an. Coût d'exploitation quasi nul, à l'inverse. Total : 2 200 €/an environ.
Sur ce seul critère financier, l'API est deux fois moins chère. Le local n'est justifié que si l'on valorise, en euros, les autres bénéfices : confidentialité (pas de sortie des tickets vers un fournisseur externe), résilience (aucune dépendance à la disponibilité de l'API), maîtrise (contrôle des mises à jour du modèle, absence de changement tarifaire imposé), et souveraineté (aucune donnée hors UE). Pour un cabinet d'avocats, une caisse d'assurance-maladie ou un service RH interne, ces quatre points font pencher la décision vers le local malgré l'écart de coût direct.
Le routage : quand renvoyer vers le grand modèle
Un système hybride tire parti des deux extrêmes. La règle appliquée dans le projet livré est simple.
Traitement par défaut : le petit modèle local. 95 % des tickets sont traités entièrement sur le poste, en 1 seconde, sans appel externe.
Renvoi vers l'API si : la catégorie proposée par le petit modèle a une probabilité inférieure à un seuil (par exemple 0,7) ; ou le ticket dépasse 3 000 jetons, longueur au-delà de laquelle le petit modèle perd en cohérence (module 6) ; ou l'agent a marqué le ticket comme « juridique » ou « escalade direction ».
Cette règle envoie environ 8 % des tickets vers l'API, soit 40 000 requêtes par an à 4,20 €/1 000 = 170 €/an. Le coût API total tombe alors à 340 €/an tout compris, contre 2 100 € en tout-API. Le budget local reste stable à 4 560 €. Le hybride coûte plus cher que l'API pure, mais moins cher que si l'on payait toute la confidentialité comme option contractuelle, et il produit la meilleure qualité perçue moyenne des trois configurations.
Livrables du projet
Le projet documenté remet six éléments à l'entreprise, tous versionnés dans un même dépôt interne :
- Le GGUF signé et sa recette de reproduction (module 5).
- L'adaptateur LoRA avec ses hyperparamètres et son journal d'entraînement (module 7).
- Les 200 tickets d'évaluation anonymisés, avec leurs annotations expertes.
- Le rapport de comparaison local/API en aveugle par trois évaluateurs.
- La fiche d'exploitation : matériel requis, procédure de mise à jour, gouvernance du canari, contact d'assistance.
- La grille de décision de routage entre petit et grand modèle, avec justification chiffrée.
Un rapport qui oserait conclure « le local ne vaut pas le coup ici » en justifiant chiffres à l'appui est un projet réussi. Il fait gagner du temps à toute l'entreprise sur les projets suivants. Le pire livrable est un rapport qui masque des faiblesses pour justifier a posteriori la voie choisie au départ.
En résumé
- La pile retenue tient sur trois lignes : Ministral 3B en Apache 2.0, affinage QLoRA sur 600 tickets, GGUF Q4_K_M servi par Ollama.
- Sur 200 tickets réels, le local atteint 96 % de la qualité de l'API avec une latence meilleure et sans coût marginal.
- Le coût total sur un an favorise l'API sur le seul critère financier ; le local se défend par confidentialité, résilience, maîtrise et souveraineté chiffrables.
- Un routage hybride envoie 5 à 10 % des tickets difficiles vers l'API et produit la meilleure qualité perçue moyenne des trois configurations.
Module suivant : le récapitulatif et l'examen final de 40 questions.