Pourquoi toutes les tâches d’IA ne méritent pas le plus grand modèle : conception tenant compte des ressources.

Un système de fraude, quatre tâches différentes

Regardez ce qu’un seul système de détection des fraudes doit gérer. Un nom de domaine peut nécessiter une vérification par rapport aux informations sur les menaces connues. Une facture peut devoir être comparée aux détails de paiement établis du fournisseur. Un e-mail ambigu exige une interprétation dans son contexte, et des audio ou vidéo manipulés peuvent nécessiter un modèle analytique bien plus complexe. Tous ces cas relèvent du travail de sécurité, mais d’un point de vue computationnel, ce ne sont pas les mêmes problèmes.

Néanmoins, les systèmes d’IA modernes offrent un raccourci tentant : diriger tout vers le plus grand modèle polyvalent disponible et le laisser prendre la décision. C’est certainement simple. Cela peut aussi s’avérer inutilement coûteux, lent, intrusif pour la vie privée, difficile à contrôler, ou tout simplement inadapté à la tâche. Ici, « le plus grand » désigne le modèle polyvalent le plus puissant ou le plus complexe proposé, et non simplement celui qui possède le plus grand nombre de paramètres.

Ainsi, la question de conception pertinente change. Au lieu de se demander quel est le modèle le plus puissant disponible, il faut se demander quel est le mécanisme le moins complexe qui répond encore aux exigences de qualité et de risque liées au travail à effectuer. Parfois, il s’agit d’un modèle général puissant ; parfois, d’un modèle plus petit et spécialisé. Et parfois, le modèle idéal n’est aucun modèle du tout.

Benchmarks contre environnement de production

Les benchmarks indiquent ce qu’un modèle peut faire. L’architecture de production doit trancher une question différente : ce que le système doit réellement utiliser. La qualité n’est qu’une des dimensions parmi plusieurs. Les systèmes réels doivent également tenir compte des objectifs de latence, des budgets d’inférence, des règles de confidentialité, des ressources de calcul limitées, des conditions réseau, des objectifs de fiabilité et des coûts opérationnels.

Un modèle qui excelle dans des tests de référence peut donc ne pas être adapté à une tâche spécifique. Lorsqu’une comparaison exacte et déterministe permet de trancher, disposer d’une capacité de raisonnement supplémentaire ne sert presque à rien. Lorsque les données doivent rester sur site, les envoyer vers un service distant modifie complètement la situation en matière de confidentialité et de sécurité. Et lorsque un processus métier doit répondre dans un délai strict, le choix ne peut pas reposer uniquement sur la qualité du modèle.

On peut le formuler ainsi : un mécanisme approprié combine une qualité suffisante, un niveau de risque acceptable et des coûts d’exploitation acceptables. Cela ne signifie pas choisir l’option la moins chère, car un mécanisme bon marché qui échoue à la tâche n’est pas adapté. Cela signifie plutôt que les capacités supplémentaires doivent justifier leurs coûts supplémentaires.

Ce que montrent les recherches sur le routage

Cette idée devient de plus en plus visible dans la recherche sur l’optimisation des itinéraires de modèles. Plutôt que d’assumer que chaque demande est destinée à un modèle premium, les chercheurs ont développé des systèmes capables de choisir un modèle en fonction de la demande et des performances requises.

L’étude FrugalGPT de Chen, Zaharia et Zou (2024) a évalué des cascades de modèles linguistiques variés. Leur combinaison minutieuse a permis de réduire considérablement les coûts de traitement tout en maintenant les performances visées, et dans certains scénarios testés, les économies réalisées ont atteint 98 %. RouteLLM (Ong et al., 2025) est allé encore plus loin en apprenant quand une requête doit être envoyée à un modèle plus puissant ou moins puissant. Sur ses benchmarks publics, il a indiqué des économies supérieures à deux fois sans perte de qualité par rapport à son système de comparaison.

Ces chiffres ne constituent pas de garanties pour la production. Ils dépendent des modèles, des benchmarks, des structures de prix et des méthodes de routage utilisés dans chaque expérience. Cependant, le principe architectural reste valable : la capacité maximale n’a pas nécessairement à être le point de fonctionnement par défaut.

Spécialistes, règles et comparaisons précises

Mélanger des modèles ne signifie pas seulement choisir entre deux LLM polyvalents. Lorsqu’une tâche est fortement définie, la spécialisation peut parfois remplacer la simple taille. Pecher, Srba et Bielikova (2025) ont comparé de petits modèles spécialisés à de grands modèles généraux sur huit tâches de classification de texte, et avec une quantité relativement faible de données étiquetées dans le domaine concerné, les petits modèles ont égalé ou dépassé les grands modèles pour certaines problématiques spécifiques.

Cependant, il existe une limite. Un classificateur compact entraîné pour une seule finalité ne peut pas remplacer un modèle général puissant lorsque le travail exige un raisonnement étendu, des situations inconnues, une interprétation entre modalités ou des connaissances dépassant ses données d’entraînement. En revanche, des problèmes restreints et répétitifs modifient la situation mathématique : si un système effectue sans cesse une opération bien définie, il n’a peut-être pas besoin de disposer de capacités plus larges qu’il n’utilise jamais. La recherche en routage évolue également dans cette direction. BEST-Route (Ding et al., 2025) se demande non seulement quel modèle doit traiter une requête, mais aussi quelle quantité de calcul en temps de test cette requête mérite.

L’idée de base est simple. Différents types de charges de travail se situent dans des régions de capacités distinctes, et l’architecture s’avère utile lorsqu’elle peut les distinguer.

Considérons encore des opérations plus simples :

• déterminer si deux identifiants de compte normalisés correspondent
• vérifier si une transaction dépasse un seuil prédéfini
• tester si un domaine peut appartenir à un ensemble mémorisé
• détecter si un champ obligatoire manque dans un enregistrement structuré

Aucune de ces tâches n’est intrinsèquement sémantique. Envoyer une comparaison exacte à un modèle de langage transforme une tâche déterministe en une tâche probabiliste, ajoute des coûts liés à l’inférence et crée une nouvelle source d’échec. C’est l’une des raisons pour lesquelles les architectures combinant mécanismes déterministes et apprentissage automatique semblent plus convaincantes que l’intégration de l’IA dans chaque composant. Les travaux neurosymboliques en cybersécurité vont dans le même sens : les parties apprises contribuent au reconnaissance de motifs, tandis que les parties symboliques ou basées sur des règles apportent un raisonnement et un contrôle explicites (Bizzarri et al., 2025).

Les règles ne sont bien sûr pas universellement meilleures. Elles deviennent fragiles lorsque le langage est ambigu, lorsque le comportement change, lorsque les attaquants utilisent des paraphrases inattendues, ou lorsque le système doit généraliser au-delà de ce que ses concepteurs avaient prévu. La véritable distinction ne réside pas dans des règles contre l’IA, mais dans le fait de savoir si la tâche nécessite réellement une inférence. Lorsqu’une condition peut être exprimée avec précision, une logique déterministe constitue une excellente solution technique. Lorsque le sens, l’incertitude ou la généralisation sont importants, les modèles appris trouvent leur place. Une architecture mature sait s’adapter aux deux cas.

La même discipline pour les systèmes multi-agents

Les systèmes multi-agents méritent une analyse similaire. Une fois qu’une équipe admet qu’un seul grand modèle ne devrait pas gérer tout le travail, il est facile de corriger excessivement en divisant tout en agents, car cela semble plus sophistiqué. Le nombre d’agents n’est pas une justification valable. Une conception multi-agents est pertinente lorsque les responsabilités sont véritablement distinctes : compétences différentes, outils, permissions ou sources de données variées, ou des tâches pouvant réellement être exécutées en parallèle. Shen et al. (2024) ont exploré une conception multi-LLM pour l’utilisation d’outils, dans laquelle la planification, l’appel des outils et la synthèse étaient séparées, et l’amélioration provenait justement de cette séparation fonctionnelle.

Les agents supplémentaires entraînent également des coûts de coordination. Wang et al. (2024) ont étudié les discussions multipartites sur des tâches de raisonnement et ont constaté qu’elles ne surpassaient pas toujours les modèles uniques performants, ce qui remet en question l’idée selon laquelle l’ajout de conversations entre modèles améliore automatiquement le raisonnement. La topologie joue également un rôle important. Li et al. (2024) ont montré que la manière dont les agents communiquent influence à la fois leurs performances et leurs coûts de calcul.

La règle de conception qui en découle est que les agents devraient se spécialiser en fonction des exigences du travail à effectuer. Si plusieurs agents analysent essentiellement le même contexte, utilisent les mêmes outils et exécutent des variations successives du même raisonnement, l’architecture ne fait probablement qu’augmenter les coûts inutiles. Un seul agent doté d’outils bien conçus peut constituer la solution la plus efficace.

Où a lieu le calcul

Choisir un mécanisme n’est que la moitié du problème, car il doit également fonctionner quelque part. Les appareils locaux, les infrastructures de périphérie et les plateformes cloud présentent chacun des forces et des limites, et la recherche sur l’inférence collaborative a exploré la possibilité de répartir les calculs entre eux plutôt que d’imaginer qu’une charge de travail appartient entièrement à un seul endroit (Zhou et al., 2019 ; Ren et al., 2023).

Rien ici ne fonctionne systématiquement. L’exécution locale n’est pas automatiquement plus rapide, car le matériel des points d’extrémité peut être faible, tandis qu’un service cloud optimisé effectue le travail plus rapidement. L’exécution dans le cloud n’est pas non plus automatiquement meilleure, car la latence réseau, la bande passante, la sensibilité des données ou les exigences de disponibilité peuvent faire basculer l’équilibre. La confidentialité est plus complexe que l’idée selon laquelle « local signifie privé ». Conserver les données brutes sur le dispositif réduit la quantité de données brutes transférées, mais les représentations intermédiaires générées par des inférences décomposées ou collaboratives peuvent encore révéler des détails sensibles. Higgins et al. (2025) examinent les risques de reconstruction et d’inférence dans les environnements d’apprentissage décomposé.

Le choix du lieu d’exécution relève donc d’une décision systémique et non d’une préférence technologique. La question n’est pas de savoir s’il s’agit d’un edge computing ou d’un cloud computing : il s’agit plutôt de déterminer quel environnement répond de manière adéquate aux exigences du travail à effectuer.

Une étude de cas en matière de protection contre la fraude

La question est devenue concrète lors de la conception d’une architecture de cybersécurité visant à explorer des solutions de protection contre la fraude pour les petites et moyennes entreprises. Se demander quel modèle d’IA devrait détecter la fraude n’a jamais été la bonne approche. Ce concept englobait des tâches très différentes : des vérifications techniques rapides, une comparaison structurée des données financières, une interprétation sémantique, une analyse d’anomalies et éventuellement des analyses forensiques plus complexes sur les médias. Les traiter comme un seul problème informatique n’aurait eu que peu de sens.

Le résultat a été une architecture hybride à trois niveaux basée sur des multi-agents, organisée selon un degré d’analyse croissant. Une distinction est importante ici : la conception à trois niveaux représente une architecture cible, tandis que la démonstration de concept plus restreinte, élaborée pour un projet de fin d’études, ne valide qu’un sous-ensemble de celle-ci. Elle ne prouve pas que chaque composant proposé pour la mise en production existe ou a été validé.

Niveau 0 : filtrage et tri

Le premier niveau correspond à la partie peu coûteuse et rapide. Les tâches proposées incluent la normalisation, les vérifications de l’expéditeur et du domaine, les signaux d’authentification, les tests de membership du filtre Bloom en mémoire, l’examen des métadonnées des pièces jointes ainsi que des indicateurs déterministes relatifs au risque financier. Une grande partie de ces opérations ne fait pas appel à l’IA, par conception. Un filtre Bloom est une structure de membership probabiliste rapide et non un classificateur de fraude ; un résultat positif signifie simplement qu’un élément pourrait faire partie de l’ensemble, ce qui nécessite encore une confirmation. Les autres indicateurs déterministes servent également de preuves pour une escalade, mais ne constituent pas un jugement définitif. Ce niveau existe afin d’éviter que des analyses coûteuses ne soient utilisées là où des preuves plus simples peuvent trancher ou faire monter un dossier en priorité.

Niveau 1 : orchestration et explication

La deuxième couche assure un flux de travail contrôlé. Dans la conception cible, LangGraph gère l’état, les nœuds, le routage conditionnel ainsi que le flux des preuves. Un petit modèle de langage pourrait éventuellement aider à une interprétation sémantique limitée ou à la rédaction de textes pour les utilisateurs, mais il n’est pas conçu pour décider du routage, du degré de gravité ou des actions à fort impact.

Cela est important car l’utilisation d’un modèle de langage au sein d’un système ne nécessite pas de lui conférer le contrôle du système. La couche d’orchestration peut limiter les domaines d’opération des modèles, les preuves qu’ils peuvent consulter et les actions ultérieures auxquelles ils ont accès. Elle peut également séparer l’analyse de l’explication : établir d’abord des preuves structurées, puis transformer les résultats obtenus en un langage lisible.

Couche 2 : agents analytiques spécialisés

La troisième couche contient l’analyse plus approfondie. La conception cible sépare l’analyse du texte et celle de la facture, la détection d’anomalies ainsi que l’analyse audio ou visuelle exigeante en calculs. Ces fonctions n’ont pas nécessairement besoin du même modèle, du même accès aux données ni du même environnement d’exécution. C’est là que l’idée des multi-agents devient utile, non pas en prétendant que plus d’agents signifie plus d’intelligence, mais comme moyen de représenter des responsabilités analytiques véritablement différentes.

Ce qui est intéressant, ce n’est pas tant le nombre de trois couches que l’idée qu’elles incarnent : la capacité de calcul doit être proportionnelle au problème à résoudre.

Ce que la démonstration de concept a montré

La démonstration de concept mise en œuvre était délibérément plus restreinte. Elle utilisait des scénarios de compromission d’e-mails de fournisseurs synthétiques et de détournement de factures, avec un LangGraph StateGraph déterministe. Le flux de travail conservait un état centralisé, suivait des chemins de routage explicites, extrayait des indicateurs de risque structurés à partir de textes et de factures, agrégeait de manière déterministe le niveau de gravité et générait des avertissements fondés sur des preuves. Il couvrait un scénario suspect, un scénario de référence sûr ainsi qu’un chemin d’erreur contrôlé, avec des tests automatisés et une exécution locale.

Plusieurs éléments ont été omis : le flux de travail complet de production au niveau 0, l’intégration en temps réel avec Microsoft 365 ou Google Workspace, l’OCR en production, l’apprentissage fédéré, la détection d’anomalies locales basée sur des VAE, l’inférence par calcul confidentiel sur les médias, ainsi que la détection de deepfake audio ou vidéo. La portée a de l’importance. La démonstration de concept montre que le flux de travail est réalisable. Elle ne prouve rien quant à la précision en production, à la scalabilité ou à la supériorité d’un design complet à trois niveaux.

Une leçon plus ciblée a néanmoins été renforcée. Dans ce flux de travail, aucun modèle de langage n’était nécessaire pour guider chaque décision. Les preuves sous forme structurée arrivaient en premier, une logique explicite les évaluait, puis seulement ensuite elles étaient réécrites sous forme d’avertissement compréhensible par les utilisateurs. Séparer la capacité de raisonnement de l’autorité dans le flux de travail faisait partie des enseignements architecturaux les plus utiles.

La complexité a un prix

Une architecture hétérogène n’est pas gratuite :

• N’importe quel routeur peut choisir la mauvaise route.
• Une cascade peut ajouter du retard avant de passer au modèle coûteux qui était nécessaire depuis le début.
• Plusieurs modèles entraînent plus d’évaluations, de hébergement et de gestion des versions.
• Les architectures multi-agents génèrent des coûts liés aux messages et à la coordination.
• Les composants exécutés près de l’utilisateur doivent être distribués, mis à jour et surveillés sur une variété d’extrémités.
• La dispersion des données élargit la surface susceptible de présenter des failles de sécurité, des points aveugles et des pannes.

Il existe un argument contraire sérieux : parfois, un seul modèle puissant représente la conception la plus simple et la meilleure. S’il répond aux exigences en matière de qualité, de latence, de confidentialité, de fiabilité et de coûts, l’ajout de routeurs, de modèles spécialisés ou d’agents supplémentaires peut créer plus de complexité opérationnelle que cela n’en vaut la peine. Cela ne contredit pas le principe de prise en compte des ressources ; il en fait partie, car la complexité doit également se justifier.

L’objectif n’est pas de réduire la taille des modèles, d’augmenter au maximum le nombre d’agents ou de déplacer les calculs vers le périphérique simplement parce que le calcul en périphérie est intéressant. L’objectif est d’éviter de payer, en argent, en termes de latence, de risques pour la confidentialité ou d’efforts d’ingénierie, pour des capacités dont la charge de travail n’a pas besoin.

Partir de la charge de travail

Avant de choisir un modèle, il est préférable de se poser une série de questions plus simples :

• Une règle précise, une comparaison ou une recherche pourrait-elle suffire ? Si c’est le cas, l’inférence n’est peut-être même pas nécessaire.
• La tâche est-elle suffisamment spécifique et récurrente pour justifier l’intervention d’un spécialiste ?
• A-t-elle réellement besoin de raisonnement sémantique ou de généralisation large ?
• Où peut-on traiter les données sans enfreindre les limites de latence, de sécurité ou de confidentialité ?
• Que se passe-t-il si le mécanisme choisi est inadapté, et le flux de travail peut-il être géré en toute sécurité ?
• Si plusieurs agents sont envisagés, ont-ils des responsabilités, des outils ou des données distincts, ou bien une tâche est-elle divisée simplement parce que cela semble plus avancé ?

Ce n’est qu’une fois ces questions répondues que le choix d’un modèle devient pertinent. Cela inverse une habitude courante, où l’on choisit d’abord le modèle le plus impressionnant et où l’on cherche ensuite des tâches pour lui. Commencez par la charge de travail, et laissez ses contraintes déterminer le mécanisme à utiliser.

Les grands modèles polyvalents restent des outils remarquables, et une conception tenant compte des ressources n’est pas une invitation à les éviter. C’est plutôt un appel à utiliser leurs capacités là où elles sont vraiment utiles. Les opérations déterministes devraient rester déterministes si cela suffit. Les modèles spécialisés devraient pouvoir le rester. Le modèle général le plus puissant devrait être chargé des problèmes qui nécessitent réellement sa capacité de raisonnement. De même, un système multi-agents ne devrait exister que lorsque une spécialisation réelle l’exige. En une phrase : utilisez le mécanisme le plus simple qui répond de manière adéquate aux exigences de qualité et de risque du travail à effectuer.

Lorsque le modèle le plus puissant cesse d’être la destination prévue, une autre question devient inévitable : comment le système doit-il décider où chaque travail va ? Cette question de routage, c’est-à-dire l’affectation des ressources de calcul en fonction du travail, constitue le problème suivant naturel.

Recherches mentionnées

• Chen, Zaharia et Zou (2024) : FrugalGPT, utilisation de modèles de langage en cascade pour réduire les coûts
• Ong et al. (2025) : RouteLLM, apprentissage de la routage entre modèles à partir de données de préférences
• Ding et al. (2025) : BEST-Route, routage adaptatif avec utilisation des ressources en temps de test
• Pecher, Srba et Bielikova (2025) : modèles spécialisés de petite taille versus modèles généraux de grande taille pour la classification de texte
• Bizzarri et al. (2025) : étude de l’IA neurosymbolique pour la détection d’intrusions réseau
• Shen et al. (2024) : agent multi-LLM pour l’apprentissage d’outils
• Wang et al. (2024) : savoir si les discussions entre agents améliorent le raisonnement des LLM
• Li et al. (2024) : topologie de communication sparsa dans les débats multi-agents
• Zhou et al. (2019) et Ren et al. (2023) : études sur l’intelligence aux marges et l’inférence collaborative de réseaux de neurones

Higgins et al. (2025) : apprentissage segmenté préservant la vie privée face à l’inférence adverse