L'IA générative s'impose progressivement dans les outils métier : chatbots internes, analyse documentaire,assistance RH, génération de rapports. Mais à mesure que ces usages deviennent critiques, une question architecturale s'impose : pourquoi solliciter systématiquement un Large Language Model (LLM) généraliste, hébergé dans le cloud et facturé à l'usage, pour des tâches souvent répétitives et bien délimitées ?

Les applications RH concentrent certaines des données les plus sensibles de l'entreprise — dossiers salariés, données de paie, absences, évaluations. Ce contexte exige une approche IA différente : maîtrisée,souveraine, et conforme. C'est précisément ce que permettent les Small Language Models (SLM).

Pourquoi les LLM cloud ne sont pas toujours adaptés aux RH

Les LLM généralistes via API cloud présentent trois limites structurelles dans un contexte RH :

• Coûts imprévisibles. Des coûts variables indexés surle volume de tokens, difficiles à budgéter sur desusages récurrents.

• Souveraineté fragilisée. Une dépendance à desplateformes externes incompatible avec les exigencesde souveraineté des DSI et des obligations RGPD.

• Risque de conformité. Une exposition des données personnelles sensibles à des serveurs tiers, mêmelorsque les conditions contractuelles semblent protectrices.

À noter : la hausse continue des incidents liés à l'IA 362 incidents IA documentés en 2025, contre 233 en2024 — soit une hausse de 55% en un an (Stanford HAI, AI Index Report 2026, données AIID) renforce l'impératif de gouvernance. Exécuter un modèle localement réduit la surface d'exposition, mais ne suffit passeul à garantir la conformité — les choix d'architecture, de contrôle d'accès et de traçabilité sont tout aussi déterminants.

Ce que les SLM apportent concrètement

Un SLM est un modèle de langage plus compact qu’un LLM généraliste, conçu pour traiter des tâches ciblée savec moins de ressources. Il peut être exécuté localement ou dans un environnement contrôlé, ce qui permet de mieux maîtriser les flux de données, les coûts d’usage et l’intégration avec les systèmes internes.Contrairement à un LLM généraliste, un SLM ne vise pas l’exhaustivité. Sa valeur apparaît surtout sur unpérimètre métier restreint

Limites à connaître avant de se lancer

• Hallucinations : les SLM peuvent générer des réponses plausibles mais incorrectes. Une température basse (0.2–0.4) réduit ce risque, mais ne l'élimine pas. Un dispositif de validation ou de supervision humaine reste nécessaire sur les cas à fort enjeu.
• Fenêtre de contexte réduite : les SLM traitent moins de tokens simultanément que les grands modèles. Les documents longs (contrats, rapports multi-pages) nécessitent une stratégie dedécoupage adaptée.
• Maintenance opérationnelle : déployer un modèle en local implique de gérer les mises à jour, lamontée en charge et la surveillance des performances — une charge DevOps à anticiper.
• Qualité variable selon le modèle : Mistral 7B, Phi-3, Qwen2 ou Gemma offrent des niveaux de performance différents selon les tâches. Un benchmark sur vos cas d'usage réels est indispensable avant tout choix définitif.

Cas d'usage : Assistant RH pour les insights opérationnels

Prenons l’exemple d’une organisation qui souhaite accélérer l’accès aux indicateurs RH du quotidien : taux de retard, absences récurrentes, couverture des équipes, tendances par site ou signaux nécessitant un suivimanagérial. Ces informations existent déjà dans les outils RH, mais leur consultation demande souvent denaviguer entre plusieurs tableaux de bord, filtres et rapports, ce qui ralentit l’analyse et la prise de décision.

Solution déployée : assistant conversationnel basé sur un SLM local, intégré à l’application RH etconnecté aux services existants via une architecture Spring Boot + Spring AI + Ollama.

Périmètre : consultation d’indicateurs RH, analyse rapide des retards et absences, synthèse detendances opérationnelles, orientation vers les rapports ou processus adaptés.

Gouvernance : chaque outil exposé au modèle est borné, audité et soumis aux règles d’accès del’utilisateur connecté. Le modèle ne touche jamais directement la base de données.

Résultats :

1. Réponse immédiate : Demandes RH traitées sans attente,sans mobiliser l'équipe RH
2. Analyse facilitée : Tendances retards et absence saccessibles sans changer d'outil
3. Données mieux contrôlées : Conformité RGPD facilitée par l’architecture

_{Résultats à valider sur périmètre pilote — variables selon la qualité des données et le paramétrage retenu.}

Architecture & gouvernance : les décisions clés

Dans une architecture entreprise, le SLM local ne remplace pas toujours les LLM cloud. Il peut traiter les requêtes RH fréquentes et sensibles, tandis qu'un modèle plus puissant, appelé ponctuellement via API etavec anonymisation des données, peut être réservé aux analyses complexes. Cette approche hybridepermet d'équilibrer souveraineté, coût et qualité de réponse.

Contrôle backend strict

Le modèle ne touche jamais directement les données RH. Ilidentifie l’intention et suggère un appel d’outil, mais c’est le backend qui valide les paramètres, vérifie les droits de l’utilisateur et exécute la requête. Chaque fonction exposée au modèle doit être spécifique, bornée et traçable.

Outils métier déclarés explicitement

Les méthodes accessibles au modèle doivent être décrite savec précision : nom, périmètre, format d’entrée attendu etrègles d’usage. Un outil trop générique — comme une fonction execute SQL () libre — créerait un risque majeur en exposant indirectement l’ensemble du système d’information RH.

Traçabilité et auditabilité

Chaque appel d’outil doit être journalisé avec l’identité de l’utilisateur, le contexte de la demande et le résultat retourné. Cette traçabilité contribue à la gouvernance IA, facilite les contrôles internes et renforce la maîtrise des traitements sensibles.

Point de méthode We Are Beebay

Sur nos déploiements, la décision architecturale la plus déterminante n'est pas le choix du modèle —c'est la définition précise des outils exposés au modèle. Un périmètre mal borné dès la conception estla principale source d'incidents en production. Nous recommandons de traiter cette étape avant mêmele benchmark des modèles.

Recommandations pour démarrer

1. Identifier un périmètre pilote à fort volume et faible valeur ajoutée humaine : FAQ collaborateurs, synthèse de plannings, extraction de documents administratifs. Ces cas limitent les risques tout en générant un ROI rapide et mesurable.
2. Benchmarker les SLM sur vos données réelles avant de choisir un modèle : Les performances varient significativement selon les modèles (Mistral, Phi-3, Qwen2, Gemma) et les types de tâches. Un benchmark ciblé sur vos cas d'usage évite les mauvaises surprises en production.
3. Définir les outils exposés au modèle dès la phase de conception : C'est la décision architecturale la plus structurante. Chaque outil doit être spécifique, audité et soumis aux règles d'accès de l'utilisateur. La gouvernance se construit dès le design, pas après.
4. Planifier la maintenance opérationnelle dès le départ : Un SLM en production n'est pas un service managé. Définir dès le départ les processus de mise à jour des modèles, de monitoring des performances et de gestion des dérives est indispensable pour tenir dans ladurée.