Une nouvelle approche émerge dans le domaine des systèmes agents : l’utilisation de petits modèles linguistiques (SLM, Small Language Models) comme pilotes principaux, tandis que les grands modèles (LLM) ne sont activés qu’en cas de besoin. Un récent rapport synthétise cette tendance, mettant en lumière l’efficacité des SLM dans l’utilisation d’outils, la production de sorties structurées et les stratégies de déploiement. L’objectif ? Remplacer les LLM comme point d’entrée par défaut, en les réservant comme sauvegarde. Au cœur de ces workflows agents se trouve un routeur frontal ou classificateur qui reçoit toutes les requêtes utilisateur. Il les analyse selon plusieurs critères : intention, coût, latence, incertitude et nature de la tâche. Ce système devient ainsi le véritable contrôleur du trafic, décident quel modèle doit intervenir. Les workflows agencés privilégient les SLM pour les tâches récurrentes, grâce à un registre de capacités (décrit dans l’étude) qui attribue à chaque SLM des spécialités précises : détection d’intention, extraction d’entités, utilisation d’outils, rédaction de code, etc. Seules les tâches complexes ou ambiguës sont transférées aux LLM. L’avenir des systèmes agents ne réside pas dans des modèles plus gros, mais dans une orchestration plus intelligente. Imaginez un agent recevant une requête : le premier modèle à interagir est un SLM de 3 à 8 milliards de paramètres. Ce petit modèle fait presque tout : décider quels outils appeler, extraire les informations clés, produire des sorties strictes (JSON ou YAML) conformes à un schéma prédéfini, et orchestrer des plans en plusieurs étapes. Les LLM ne s’activent qu’en cas d’échec. L’activation se déclenche de manière explicite : le LLM reçoit un prompt rigoureusement contraint, incluant l’historique complet de la conversation, les tentatives échouées du SLM, et des instructions claires. Une fois la sortie produite, elle passe par les mêmes validateurs. Si elle échoue, le cycle se répète — ou une intervention humaine est requise. Pour les opérations sensibles — paiements, transformation de données personnelles, suppression de données de production — le système ne procède jamais automatiquement. Deux modes de fonctionnement sont prévus : soit un SLM propose une solution, puis un second SLM ou un LLM la valide ; soit, si le score d’incertitude ou de risque politique est élevé, un humain est alerté pour approuver, rejeter ou corriger. Chaque intervention humaine devient une trace oraculaire précieuse, enregistrée et utilisée pour l’apprentissage. Le modèle apprend ainsi des erreurs passées, en se basant sur les moments où un humain a dû le sauver. Tout est logging : prompts, sorties, latence, coût, erreurs de validation, taux d’escalade, scores d’incertitude. Cette télémétrie devient la matière première pour entraîner de nouveaux adaptateurs. Au fil des semaines, les SLM s’améliorent sur les tâches concrètes de votre produit, car ils ne sont formés qu’avec des données réelles, dépersonnalisées, propres à votre usage. Le plan en cinq étapes pour passer d’agents GPT-4 exclusifs à une architecture SLM par défaut : 1. Log tout pendant 1 à 2 semaines — exploitez votre LLM actuel. 2. Regroupez les tâches — vous découvrirez que 80 % relèvent d’extraction, de routage ou d’appels d’outils simples. 3. Fine-tunez des spécialistes minuscules avec LoRA, sur 10 000 à 50 000 traces (déidentifiées), quantifiés à 4 ou 8 bits. 4. Remplacez-les derrière un routeur avec une fonction de sauvegarde par incertitude — observez une baisse immédiate de 20 à 100 fois du coût en tokens. 5. Itérez sans relâche : évaluation humaine, garde-fous, et mises à jour régulières basées sur les échecs. Le futur n’est pas dans la taille, mais dans la sagesse de l’orchestration.