Retour sur la conférence DEVOXX 2026 | SLM : les petits modèles qui font de grandes choses
Et quand les utiliser - Pierre Lepagnol, SCIAM - Devoxx France 2026
Lors de la Devoxx France 2026, parmi la multitude de talks autour de l'IA générative, l'un d'eux sortait du lot par sa promesse : non pas des grands modèles comme GPT-5 ou Claude, mais des petits modèles de langage, souvent sous-estimés.
Pierre Lepagnol, consultant chercheur chez SCIAM et doctorant en NLP à l'Université Paris-Saclay, a consacré sa conférence aux Petits Modèles de Langue (SLM - Small Language Models) : ce qu'ils sont, quand les utiliser, et surtout comment éviter de les confondre avec de simples LLM au rabais.
1. Devoxx 2026 et la montée en puissance de l'IA embarquée
La Devoxx France 2026 a confirmé une tendance de fond : l'IA ne se résume plus à un appel API vers un géant du cloud. Face à des exigences croissantes en matière de confidentialité des données, de latence, de coût et de maîtrise des systèmes, les équipes techniques cherchent des alternatives plus légères et plus contrôlées.
C'est dans ce contexte que les SLM s'imposent comme une brique essentielle de l'outillage IA moderne, notamment dans les architectures RAG (Retrieval-Augmented Generation) et les systèmes agentiques.
2. Qu'est-ce qu'un SLM ?
Un Small Language Model est un modèle de langue dont la taille - mesurée en nombre de paramètres - est significativement inférieure à celle des LLM "frontier" (GPT-5, Claude, Gemini...). On parle généralement de modèles de moins de 10 milliards de paramètres, voire beaucoup moins.
Ce qui les rend étonnamment performants, c'est une combinaison d'approches architecturales ciblées :
• Distillation : apprendre à partir d'un grand modèle "teacher"
• Fine-tuning spécialisé : entraînement sur un domaine ou une tâche précise
• Quantization : réduction de la précision des poids pour diminuer l'empreinte mémoire sans dégrader fortement la qualité
• Instruction tuning : alignement sur des formats de tâches structurées
L'idée clé : un SLM bien spécialisé peut surpasser un grand modèle généraliste sur une tâche bornée, tout en étant 10 à 100 fois moins coûteux à inférer.
3. Le workflow d'inférence SLM en production
Pierre Lepagnol a détaillé la chaîne complète qu'emprunte une requête lorsqu'elle est traitée par un SLM en production :
App métier → API (OpenAI-like) → Runtime d’inférence → Scheduler + batching
→ Kernels GPU/CPU → Streaming tokens → UX métier
Deux points clés à retenir :
1. Le prompt transite de l'application jusqu'aux kernels GPU/CPU - chaque maillon introduit de la latence. Le choix du runtime d'inférence (vLLM, llama.cpp, Ollama, TensorRT-LLM...) est donc structurant.
2. La couche d'inférence (vLLM, TensorRT-LLM, etc.) gère les poids quantisés, le KV cache et les métriques. Parmi ces composants, le KV cache est particulièrement critique : il détermine la capacité du modèle à gérer des contextes longs sans recalculer à chaque token et conditionne directement le débit et la latence perçue (TTFT - Time To First Token).
À retenir : déployer un SLM en production, c'est aussi une décision d'ingénierie, pas seulement un choix de modèle.
4. Quand choisir un SLM ? La checklist
Avant de choisir entre un LLM cloud et un SLM, Pierre Lepagnol propose une checklist pragmatique en quatre questions :
Ce soir, posez-vous ces questions 1. Mes données peuvent-elles quitter mon infrastructure ? 2. Quelle latence est acceptable pour l'UX ? 3. Quel volume de requêtes par jour/mois ? 4. La tâche est-elle bornée ou ouverte ? |
Et son conseil concret pour passer à l'action dès le lendemain :
Prenez un use case → évaluez un LLM (topline) → testez 2 SLM → mesurez qualité + TTFT + coût. Le plus petit qui passe le seuil, c'est le bon.
5. Les 3 erreurs classiques à éviter
Pierre Lepagnol a identifié trois pièges dans lesquels tombent fréquemment les équipes qui démarrent avec les SLM :
Choisir GPT-4 par défaut sans tester plus petit : réflexe compréhensible, mais souvent inutilement coûteux. Beaucoup de tâches métier sont parfaitement traitables par un modèle 3B ou 7B bien configuré.
Faire confiance aux benchmarks publics : les classements comme MMLU ou HumanEval ne reflètent pas votre cas d'usage. Construisez votre propre évaluation, sur vos propres données, avec vos propres critères.
Fine-tuner trop tôt : le fine-tuning est coûteux, long et fragile. Avant d'y recourir, explorez d'abord le prompt engineering et le RAG. Dans de nombreux cas, ces approches suffisent à atteindre le niveau de qualité souhaité.
6. Ce qu'il faut retenir
Les SLM ne sont pas des LLM au rabais. Ce sont des outils différents, conçus pour des contextes différents. Leur montée en puissance répond à des besoins réels : souveraineté des données, contraintes de latence, maîtrise des coûts.
À emporter • SLM ≠ LLM au rabais - outil différent, logique d'usage différente • Spécialisation - améliore le rapport qualité/coût sur des tâches bornées • Local ≠ cloud - contraintes différentes, mais contrôle total sur vos données |
Pour les équipes qui construisent des systèmes RAG ou agentiques, intégrer des SLM dans les workflows est une piste sérieuse à explorer - notamment pour les tâches de tri, d'extraction ou de reformulation qui n'ont pas besoin de la puissance (ni du coût) d'un modèle frontier.
Le message de cette conférence est simple : avant d'appeler systématiquement un modèle frontier, il vaut souvent la peine de vérifier si un SLM bien choisi ne peut pas faire le travail plus vite, moins cher et avec davantage de contrôle.
