Depuis l’explosion des grands modèles de langage, une idée s’est installée dans de nombreuses équipes produit et data : les LLM pourraient tout faire. Rédiger, résumer, chercher, raisonner, coder, analyser, estimer, classer. Pourtant, à mesure que les entreprises passent des démonstrations aux systèmes opérationnels, une réalité devient évidente : les agents IA ont besoin de modèles de machine learning classique pour être fiables, économiques et contrôlables.
Un agent IA n’est pas seulement un chatbot plus sophistiqué. C’est un système qui combine un LLM avec des outils logiciels, des API, des bases de données, des moteurs de recherche, des calculateurs ou encore des modèles prédictifs. Le LLM sert souvent d’interface : il comprend la demande humaine, choisit les bons outils, formule les appels, interprète les résultats et produit une réponse exploitable.
Mais le LLM reste, au cœur, un modèle de génération de tokens. Il prédit la suite la plus probable d’un texte selon son contexte. Cette capacité est puissante pour dialoguer, reformuler, orchestrer et expliquer. Elle l’est beaucoup moins lorsqu’il faut produire une prédiction numérique robuste, appliquer une logique métier contrôlée ou traiter des milliers de cas à faible coût.
Agents IA : pourquoi les outils comptent autant que le modèle de langage
Dans un système agentique, la valeur ne vient pas uniquement du modèle de langage. Elle vient de sa capacité à utiliser les bons outils au bon moment. C’est déjà le cas dans les assistants modernes comme ChatGPT, Claude ou Gemini, qui ne se limitent pas à générer du texte : ils peuvent rechercher des informations, exécuter du code, interroger des sources, appeler des API ou utiliser des fonctions spécialisées.
En entreprise, ces outils prennent souvent la forme de :
- bases de connaissances RAG pour retrouver des documents internes ;
- bases de données relationnelles ou graphes de connaissances ;
- outils de validation de requêtes et de contrôle des permissions ;
- moteurs de calcul pour les tâches mathématiques ;
- API métiers pour consulter un CRM, un ERP ou un système financier ;
- modèles de classification, de scoring, de régression ou de détection d’anomalies.
C’est sur ce dernier point que le machine learning classique retrouve une place stratégique. Plutôt que de demander au LLM d’improviser une estimation, on peut lui confier le rôle qu’il remplit le mieux : comprendre l’intention, préparer les données, appeler un modèle spécialisé, puis expliquer le résultat.
Ce que le machine learning classique apporte aux agents IA
Le machine learning classique désigne ici les approches largement utilisées avant la vague des LLM : régressions, forêts aléatoires, gradient boosting, modèles de scoring, classifieurs supervisés, clustering, séries temporelles, modèles de détection d’anomalies, entre autres. Des bibliothèques comme scikit-learn, XGBoost, LightGBM ou CatBoost restent extrêmement pertinentes pour résoudre des problèmes structurés.
Dans beaucoup de cas, ces modèles sont meilleurs qu’un LLM, non pas parce qu’ils sont plus “intelligents”, mais parce qu’ils sont conçus pour une tâche précise, entraînés sur des données pertinentes et évalués avec des métriques claires.
Une meilleure précision sur les prédictions numériques
Imaginons un agent IA utilisé dans l’immobilier. Un utilisateur lui donne l’adresse d’un bien et demande une estimation du prix de marché. L’agent peut récupérer les caractéristiques du logement via une API : surface, localisation, nombre de pièces, étage, année de construction, historique des ventes comparables, distance aux transports, tension du marché local.
Deux options sont possibles. La première consiste à demander directement au LLM d’estimer un prix. C’est simple, mais risqué : le modèle génère une réponse plausible, pas nécessairement une estimation fondée sur des données empiriques. La seconde consiste à transmettre les variables structurées à un modèle de régression entraîné sur des ventes réelles. Dans ce scénario, le LLM orchestre, mais le modèle statistique fait la prédiction.
Pour une estimation de prix, un score de risque, une probabilité de churn ou une prévision de demande, cette différence est fondamentale. Une entreprise ne veut pas seulement une réponse élégante ; elle veut une prédiction mesurable, testable et améliorable.
Une interprétabilité plus exploitable
Les LLM restent difficiles à interpréter. Même lorsqu’ils fournissent une justification, celle-ci peut être une reconstruction narrative plutôt qu’une explication fidèle du raisonnement interne. Pour des décisions sensibles, cela pose un problème majeur.
Avec un modèle de machine learning classique, l’équipe data peut analyser les variables importantes, mesurer l’impact des caractéristiques, détecter les biais, comparer les performances par segment et vérifier si le modèle se comporte correctement. Selon le modèle choisi, il est possible d’utiliser des méthodes d’explicabilité comme les importances de variables, les courbes de dépendance partielle ou des approches de type SHAP.
Pour un agent IA, cette interprétabilité peut être transformée en contexte utile. Au lieu de retourner seulement “prix estimé : 420 000 €”, le modèle peut fournir une sortie enrichie : niveau de confiance, variables principales, comparaison avec le marché local, limites de l’estimation. Le LLM peut ensuite restituer ces éléments dans un langage clair.
Des coûts beaucoup plus prévisibles
Les coûts d’inférence des LLM peuvent grimper rapidement, notamment lorsque les prompts sont longs, que les réponses contiennent beaucoup de contexte ou que l’agent réalise plusieurs appels pour une seule tâche. Dans un workflow agentique, un cas utilisateur peut déclencher une recherche documentaire, une requête SQL, une validation, un appel d’API et plusieurs échanges avec le LLM.
À l’inverse, exécuter un modèle de classification ou de régression est généralement très léger. Une fois entraîné et déployé, un modèle XGBoost ou scikit-learn peut traiter de très grands volumes avec une latence faible et un coût marginal réduit. Pour des tâches répétitives, c’est souvent décisif.
Le bon arbitrage n’est donc pas “LLM ou machine learning classique”, mais plutôt : utiliser le LLM là où il apporte de la flexibilité linguistique, et utiliser le modèle classique là où il apporte de la performance prédictive.
Un meilleur contrôle des données et de l’infrastructure
Dans certains secteurs, envoyer des données à un fournisseur externe de LLM peut créer des risques de confidentialité, de conformité ou de gouvernance. Même lorsque des garanties contractuelles existent, toutes les organisations ne souhaitent pas exposer leurs données sensibles à un service tiers.
Un modèle classique peut être entraîné, hébergé et supervisé dans l’environnement contrôlé de l’entreprise. Cela réduit les dépendances externes, facilite les audits et permet de maîtriser les contraintes d’infrastructure. En cas d’indisponibilité d’un fournisseur LLM, un agent très dépendant d’un service externe peut devenir inutilisable. Une architecture hybride bien pensée limite ce risque.
Quand faut-il préférer un modèle classique à un LLM ?
Un modèle de machine learning classique est particulièrement adapté lorsque la tâche coche plusieurs de ces critères :
- les données d’entrée sont structurées ou semi-structurées ;
- la sortie attendue est un score, une classe, une probabilité, une prévision ou une estimation ;
- la performance peut être mesurée avec des métriques précises ;
- l’entreprise dispose d’un historique de données suffisant ;
- le coût par prédiction doit rester faible ;
- l’explicabilité et la traçabilité sont importantes ;
- la tâche est répétitive et doit être industrialisée.
Quelques cas d’usage typiques :
- finance : scoring de crédit, détection de fraude, risque de défaut ;
- e-commerce : prédiction de churn, recommandation, prévision de demande ;
- industrie : maintenance prédictive, détection d’anomalies, optimisation qualité ;
- immobilier : estimation de prix, scoring de rentabilité, analyse de marché ;
- RH : prévision d’attrition, matching de compétences, analyse de parcours ;
- support client : priorisation de tickets, classification d’incidents, prédiction de satisfaction.
Le LLM peut ensuite rendre ces modèles plus accessibles. Un analyste métier n’a pas besoin de connaître les variables exactes ou le nom de l’endpoint. Il peut poser une question en langage naturel, et l’agent se charge de collecter les informations, d’appeler le bon modèle et de présenter une réponse compréhensible.
Deux façons de connecter un modèle classique à un agent IA
Une fois le modèle entraîné, la question devient architecturale : comment l’agent va-t-il l’utiliser ? Deux approches reviennent souvent : l’appel direct au modèle ou l’accès à des prédictions pré-calculées en base de données.
Option 1 : l’appel direct au modèle comme outil de l’agent
La méthode la plus immédiate consiste à exposer le modèle via une API ou une fonction que l’agent peut appeler. Dans l’exemple immobilier, l’agent récupère les informations sur le bien, les formate selon le schéma attendu, puis appelle le modèle de régression pour obtenir une estimation.
Cette approche fonctionne bien lorsque la prédiction doit être réalisée en temps réel ou lorsque les données changent selon chaque demande. Elle exige cependant une documentation très claire. L’agent doit savoir :
- à quoi sert le modèle ;
- dans quels cas il faut l’appeler ;
- quelles données d’entrée sont obligatoires ;
- quel format respecter ;
- comment interpréter la sortie ;
- quelles sont les limites du modèle.
Le format de réponse est crucial. Renvoyer uniquement un nombre ou une probabilité limite l’utilité de l’agent. Une meilleure sortie inclut un résultat structuré et du contexte : score, niveau de confiance, principales variables contributives, date du modèle, éventuels avertissements.
Par exemple, pour un modèle de churn, l’agent ne devrait pas seulement recevoir “probabilité : 0,72”. Il devrait recevoir une explication opérationnelle : probabilité élevée de départ, baisse d’usage sur 30 jours, trois tickets support récents, absence de connexion depuis deux semaines. Le LLM peut alors transformer ces signaux en recommandation lisible pour une équipe commerciale ou customer success.
Option 2 : stocker les prédictions dans une base consultable
La seconde approche consiste à faire tourner le modèle en amont, à intervalles réguliers, puis à stocker les résultats dans une base de données accessible à l’agent. Celui-ci n’appelle pas directement le modèle ; il interroge la base pour récupérer une prédiction déjà calculée.
Cette architecture est pertinente lorsque le nombre de cas est fini et connu. Par exemple, une entreprise peut recalculer chaque nuit un score de santé financière pour ses 500 clients, puis permettre à l’agent IA de consulter ces scores pendant la journée. Cela réduit la latence, évite les calculs redondants et simplifie parfois l’exploitation.
Cette méthode suppose toutefois que l’agent sache que ces données existent. Il faut donc intégrer les métadonnées utiles dans son contexte : nom des tables, signification des colonnes, fraîcheur des scores, règles d’usage, limites d’interprétation. Si l’agent ignore l’existence du score, il ne l’utilisera pas au bon moment.
Les prérequis pour réussir l’intégration
Ajouter du machine learning classique à un agent IA ne consiste pas seulement à brancher un modèle existant. Pour que l’ensemble fonctionne en production, plusieurs conditions doivent être réunies.
Des données bien comprises
Un modèle classique dépend fortement de la qualité des données. Il faut comprendre leur origine, leur fraîcheur, leurs biais, leurs valeurs manquantes, leurs changements dans le temps. Le feature engineering reste une étape centrale : transformer la connaissance métier en variables utiles pour le modèle.
Si aucune donnée labellisée n’est disponible, les options sont plus limitées. L’équipe peut explorer l’apprentissage non supervisé, créer progressivement ses propres labels, utiliser des règles métier comme point de départ ou mettre en place une boucle de validation humaine.
Une évaluation rigoureuse
Un modèle intégré à un agent doit être évalué avant son déploiement. Selon le cas, cela peut inclure l’erreur moyenne, l’AUC, le rappel, la précision, le F1-score, la calibration des probabilités ou des métriques métiers spécifiques. Il faut aussi tester la robustesse par segment : clients récents, zones géographiques, catégories de produits, niveaux de risque.
L’erreur acceptable doit être définie en fonction de l’usage. Une approximation peut suffire pour prioriser des leads. Elle ne suffit pas pour prendre une décision financière automatisée.
Une sortie pensée pour le LLM
Le modèle ne parle pas naturellement le langage de l’utilisateur. Son résultat doit donc être présenté dans un format que l’agent peut exploiter sans ambiguïté. Une bonne sortie combine généralement :
- un résultat principal ;
- une unité ou une classe explicite ;
- un score de confiance ou une probabilité ;
- les facteurs explicatifs importants ;
- les limites connues ;
- la date de calcul ou la version du modèle.
Cette couche de structuration évite au LLM de surinterpréter un chiffre isolé. Elle améliore aussi la qualité de la réponse finale pour l’utilisateur.
Une surveillance après déploiement
Comme tout modèle en production, un modèle classique peut se dégrader. Les comportements clients changent, les marchés évoluent, les données d’entrée se transforment. Il faut donc surveiller la dérive des données, la dérive de performance, les erreurs d’appel, la latence, les coûts et les retours utilisateurs.
Dans un agent IA, cette surveillance doit couvrir l’ensemble du workflow : le LLM appelle-t-il le bon outil ? Les entrées sont-elles correctement formatées ? Le modèle répond-il comme prévu ? Le LLM restitue-t-il fidèlement le résultat ?
Le futur des agents IA sera hybride
La vague des LLM n’a pas rendu le machine learning classique obsolète. Elle lui donne au contraire une nouvelle interface. Les modèles de régression, de classification ou de scoring peuvent devenir des outils spécialisés dans des agents plus larges, capables de dialoguer avec les utilisateurs et d’orchestrer des workflows complexes.
Cette complémentarité est probablement l’une des clés des systèmes IA réellement utiles en entreprise. Le LLM apporte la souplesse, la compréhension du langage naturel et l’orchestration. Le machine learning classique apporte la précision, l’interprétabilité, le faible coût et le contrôle.
Pour les équipes data et IA, le message est clair : il ne faut pas abandonner les compétences classiques. Maîtriser scikit-learn, XGBoost, LightGBM, CatBoost, l’évaluation de modèles, le feature engineering et le monitoring reste un avantage compétitif. Les agents IA les plus fiables ne seront pas ceux qui demandent tout au LLM, mais ceux qui savent distribuer intelligemment le travail entre les bons composants.
À retenir
- Un agent IA est un système qui combine un LLM avec des outils, des données et parfois plusieurs modèles.
- Les LLM sont excellents pour comprendre, orchestrer et expliquer, mais moins adaptés aux prédictions numériques fiables.
- Le machine learning classique reste souvent supérieur pour les scores, estimations, classifications et prévisions structurées.
- Deux intégrations sont fréquentes : appel direct du modèle ou consultation de prédictions pré-calculées.
- La qualité des données, l’évaluation, le format de sortie et le monitoring sont essentiels pour une mise en production réussie.
À mesure que les entreprises industrialisent l’IA générative, les architectures hybrides vont devenir la norme. Et dans ces architectures, le machine learning classique n’est pas un héritage du passé : c’est l’un des meilleurs moyens de rendre les agents IA plus fiables, plus explicables et plus utiles.