Chez RGS, des LLM locaux ramènent le traitement de 500 tâches de cinq jours ouvrés à deux

Avant chaque cycle de planification chez RGS, les équipes de développement apportent des centaines de tâches, et chacune doit être évaluée selon plusieurs critères de priorisation. L'un d'eux est la conformité IT : la réalisation de la tâche aide-t-elle à respecter les exigences de la législation ? Anastasia, qui dirige le pôle conformité IT, a raconté sur Habr comment elle a ramené le traitement d'environ 500 tâches de cinq jours ouvrés à deux. Elle n'avait pas de budget de développement et ne sait pas programmer : tout le pipeline repose sur des outils gratuits et tourne sur un laptop.

Pourquoi le filtre par mots-clés n'a pas convenu

Deux « trains », c'est-à-dire deux grands pôles de développement, ont participé au pilote. Dès le premier cycle, quelque 500 tâches sont arrivées, et leur traitement a mobilisé pendant une semaine le seul expert disponible. Pendant ce temps, le travail pour lequel la conformité existe est resté à l'arrêt : l'analyse des nouvelles exigences et l'accompagnement des projets complexes. Raccorder les autres trains aurait englouti l'essentiel d'un trimestre, et il était impossible d'étoffer l'équipe pour absorber les pics de charge.

La recherche par mots ne fonctionnait pas : les formulations diffèrent d'une équipe à l'autre, alors qu'il faut évaluer le sens. Anastasia a donc décidé de tester son hypothèse au moindre coût. Elle a produit un export anonymisé des tâches et l'a soumis à plusieurs modèles externes, accompagné d'une consigne détaillant les critères. Après plusieurs itérations du prompt, le résultat s'est stabilisé, mais la concordance avec les évaluations des experts n'atteignait qu'environ 60%, avec des erreurs allant surtout dans le sens de la surestimation. Cela a suffi pour démarrer : un modèle trop prudent écarte de façon fiable ce que l'expert n'a pas besoin d'examiner.

Assemblage local : n8n,

Ollama et base d'évaluations validées

La première version avait trois points faibles : la préparation manuelle des exports, la perte de sens due à l'anonymisation et la dépendance à des services externes, qui peuvent cesser de fonctionner en Russie. Une solution d'entreprise n'a pas pu être mise en place d'emblée, et Anastasia a opté pour un modèle local. Les données ne quittent pas l'ordinateur et aucun service externe n'est nécessaire. Le prix à payer, ce sont les limites du laptop : les tâches sont envoyées par lots, et les modèles trop lourds faisaient planter la machine pour de bon.

L'orchestrateur est n8n, un outil visuel de construction de workflows. Les modèles ont été lancés via LM Studio et Ollama, et le choix s'est finalement porté sur Ollama. Le pipeline se déroule ainsi : export des tâches, nettoyage du texte de ses déchets techniques, transmission au modèle avec la consigne, réponse dans un format strict (niveau sur une échelle et courte justification), enregistrement du résultat.

L'élément central est la base d'évaluations déjà validées, exploitée avec du RAG. Face à une tâche, le modèle retrouve des tâches similaires évaluées par l'expert et s'appuie sur elles. Sans cette base, les premières versions n'affichaient que 20% de précision. Après amélioration de la sélection des exemples, du prompt et du choix des modèles (Qwen et GPT-oss), l'assemblage a atteint 70–80% sur l'échantillon de test et traitait 500 tâches en 12 heures environ, soit à peu près 1,5 minute par tâche.

Pour comparer les variantes de façon honnête, Anastasia a fait écrire par une IA un programme classique. Il confronte les évaluations de plusieurs algorithmes à celles des experts et calcule quatre indicateurs : la réponse exacte, la réponse à un cran d'écart près sur l'échelle, le tri des tâches superflues et le sens des erreurs. Une surestimation entraîne une vérification inutile ; une sous-estimation fait courir le risque de laisser passer une tâche importante.

De 55–60% sur le flux réel à 78–82%

L'échantillon de test s'est révélé trop optimiste. Sur des tâches réelles, la première bonne version n'a donné que 55–60% : le flux réel contient davantage de formulations et de systèmes inédits, et une partie des tâches provient de trains qui ne font que rejoindre la priorisation. Anastasia a ensuite essayé plusieurs évaluations issues de modèles différents, ou d'un même modèle avec des paramètres différents, des connaissances supplémentaires et un contexte enrichi, notamment via MCP. Le critère de sélection était simple : si la précision d'une variante chutait lors du raccordement de nouveaux trains, elle était écartée.

Les versions retenues sont plus lentes que la version de départ, avec 12 à 24 heures pour 500 tâches, mais elles atteignent 78–82% sur des données réelles, et les erreurs de surestimation et de sous-estimation sont désormais équilibrées. Au lieu d'un filtre à l'usage de l'expert, on obtient un algorithme qui attribue lui-même les valeurs, l'expert les vérifiant en cas de besoin. La logique économique est simple : le temps de l'ordinateur coûte moins cher que celui de l'expert, et plus l'algorithme est précis, moins il faut de vérification manuelle.

Le périmètre du processus a lui aussi changé. Auparavant, seules les nouvelles tâches étaient évaluées à la main, et les tâches modifiées n'étaient pas revérifiées faute de temps. Désormais, l'algorithme exporte lui-même les nouvelles tâches et celles dont la description a changé avant le début de la réalisation, attribue les évaluations, remet un fichier pour vérification et inscrit la valeur du critère dans le champ servant au calcul de la priorité. L'enregistrement peut se faire immédiatement ou après vérification. Le processus sert neuf trains au lieu de deux.

Limites et suite

La solution a des points faibles, et l'auteure les cite. Elle dépend d'un seul laptop et d'un seul expert, et une précision de 80% est bonne pour un modèle local, mais n'exempte pas d'une vérification par sondage. Anastasia compte contrôler régulièrement que la précision ne baisse pas. Une instance d'entreprise de l'algorithme fonctionne déjà en mode restreint et offre une précision comparable six fois plus vite. Selon Anastasia, il ne reste plus qu'à lever les restrictions.

Pour les praticiens, la conclusion est la suivante. Le schéma « lire, confronter aux règles, évaluer » convient à de nombreux processus opérationnels. Le minimum viable : une base accumulée d'évaluations d'experts pour le RAG, des métriques qui tiennent compte du sens des erreurs et des tests sur le flux réel, et pas seulement sur un échantillon. Chez RGS, un processus similaire est déjà lancé en mode test. Le rôle de l'expert évolue : il pilote le processus et prend les décisions là où elles sont réellement nécessaires.