Votre assistant IA local peut-il remplacer celui de l’API ? Le choc des résultats

UN TEST RÉALISTE : 27 TÂCHES RÉELLES, PAS DES EXERCICES DE LABORATOIRE

Pour savoir si un modèle local peut remplacer une IA comme Claude comme cerveau d’un assistant personnel, l’auteur a repris 27 tâches réelles exécutées par son agent Jarvis. Ces tâches proviennent de logs réels collectés sur 90 jours, couvrant sept catégories : calendrier, code, emails, fichiers, général, messagerie et notes. Chaque tâche a été rejouée deux fois : une première fois avec un modèle local sur une seule carte graphique, puis une seconde fois avec un matériel plus puissant et un modèle plus gros.

Le baseline reste inchangé : les réponses historiques de Claude, telles qu’elles ont été enregistrées dans Langfuse, servent de référence. Pas de simulation, pas de données inventées. Les réponses locales sont évaluées dans les mêmes conditions que celles de l’API, avec les mêmes données réelles.

PREMIÈRE TENTATIVE : UN MODÈLE DE 30 MILLIARDS DE PARAMÈTRES SUR UNE SEULE CARTE GRAPHIQUE

Le premier essai utilise un qwen3-coder:30b, un modèle de 30 milliards de paramètres, sur une seule carte graphique RTX 3090 partagée avec d’autres tâches du labo. Résultat : un échec cuisant. Sur les 27 tâches, le score moyen atteint seulement 22,8/100, contre 89,4/100 pour Claude. Pire encore, le modèle a généré des appels d’outils mal formatés dans 7 réponses sur 27 (25,9 %). Au lieu d’émettre un appel d’outil correct comme send_email(.), il a affiché du texte brut comme <function=send_email>.</function> directement dans la réponse finale, une erreur rédhibitoire pour un assistant réel.

L’overlap des outils (la capacité à choisir les bons outils) était de seulement 14,8%. Dans deux cas, l’agent s’est retrouvé bloqué en boucle, appelant sans cesse le même outil déjà utilisé. Une catastrophe.

Pourtant, ce même modèle avait obtenu 100 % de réussite dans un benchmark contrôlé de 17 tâches, avec un outil réduit et un environnement simplifié. La différence ? Jarvis utilise près de 90 outils réels, avec des schémas complexes et un contexte personnel chargé. Un modèle excellent sur un petit jeu de tests ne garantit pas sa fiabilité dans un environnement de production réel.

DEUXIÈME TENTATIVE : TROIS CARTES GRAPHIQUES ET UN MODÈLE DE 122 MILLIARDS DE PARAMÈTRES

Pour la seconde tentative, le matériel change radicalement : trois cartes RTX 3090 (72 Go de VRAM au total) permettent de charger un modèle bien plus gros : un mixture-of-experts de 122 milliards de paramètres, soit environ 53 Go de poids, entièrement sur GPU. Surtout, le contexte passe de 16 384 à 256 000 tokens, une multiplication par 16.

Résultat : le score moyen atteint 80,0/100, contre 89,4 pour Claude. Sur 14 des 27 tâches, le modèle local est à égalité ou dépasse l’API. Dans la catégorie général, il bat même Claude (90 contre 85). Les appels d’outils mal formatés disparaissent totalement : zéro erreur sur 27 tâches. L’overlap des outils grimpe à 38,0%, soit une amélioration de 2,6 fois, même si le modèle choisit encore souvent des outils différents de ceux utilisés historiquement.

Le coût énergétique ? 0,1573 kWh pour les 27 tâches, soit 0,000969 $ par tâche, contre 0,763 $ pour l’API. Un rapport de 787 fois moins cher.

Pourtant, un problème persiste : une tâche de 281 190 tokens ne tient toujours pas dans les 256 000 tokens disponibles. Ollama la rejette avec un message clair : request (281190 tokens) exceeds the available context size (256000 tokens). Le contexte reste une limite mouvante.

CE QUI A VRAIMENT CHANGÉ : LE CONTEXTE, PAS SEULEMENT LA TAILLE DU MODÈLE

Deux variables ont changé entre les deux essais : la taille du modèle (30B → 122B) et la taille du contexte (16K → 256K tokens). Impossible de savoir lequel des deux facteurs a le plus influencé les résultats. L’auteur suppose que le contexte joue un rôle majeur, car les erreurs caractéristiques de la première tentative (appels d’outils mal formatés, mauvais choix d’outils, boucles) correspondent exactement à ce qu’on observe quand les schémas d’outils sont tronqués en milieu de définition.

Le fait que les appels d’outils mal formatés aient disparu à 100 % après l’augmentation du contexte renforce cette hypothèse : le modèle a maintenant accès à la totalité des schémas d’outils, sans coupure. Mais ce n’est qu’une hypothèse, non vérifiée par un test contrôlé.

Autre limite : le juge automatique utilisé pour évaluer les réponses est un modèle Claude (claude-opus-4-8). Ce biais d’auto-préférence est bien documenté : un modèle a tendance à noter plus favorablement les réponses de sa propre famille. Ce biais est moins problématique en première tentative, où l’écart de score est énorme, mais il devient significatif en seconde tentative, où le modèle local est compétitif.

Pire encore, le juge retourne un score de 70,0 en cas d’erreur d’infrastructure. Dans la seconde tentative, huit tâches sur 27 ont obtenu ce score. L’auteur a vérifié manuellement : ces huit scores correspondent à des jugements réels (3/5), pas à des erreurs de parsing ou des scores par défaut. Un score qui correspond à une valeur d’erreur mérite une vérification supplémentaire.

COÛT : L’ÉLECTRICITÉ, UNE FACTURE DÉRISOIRE POUR UNE PERFORMANCE DÉCENTE

Le coût énergétique a été mesuré avec précision grâce à HomeLab Monitor, un outil open source développé par l’auteur. En première tentative, le coût par tâche était quasi nul : la carte graphique partagée ne consommait presque rien en plus. En seconde tentative, les trois cartes consomment 107 W en idle (juste pour garder le modèle chargé en permanence) et 0,1573 kWh pour les 27 tâches.

À ce coût brut s’ajoute le fait que le modèle de 122B coûte 6,6 fois plus cher par tâche que le modèle de 30B. Passer d’un modèle « inutilisable et quasi gratuit » à un modèle « utilisable et quasi gratuit » a un coût réel… mais il reste dérisoire : quelques centimes par tâche.

Attention : ces chiffres incluent la consommation en idle. Si le modèle n’est chargé qu’à la demande, le coût marginal par tâche diminue, mais la latence augmente.

LE VERDICT : L’ASSISTANT PASSE AU LOCAL, MAIS CLAUDE RESTE LE ROI

Après une semaine de test, Jarvis tourne désormais sur le modèle local de 122B. L’abonnement Claude Max a été annulé, mais l’abonnement Claude Pro est conservé. Pourquoi ? Parce que même si le modèle local est compétitif (80,0 contre 89,4), l’écart de qualité reste significatif, surtout sur les tâches complexes.

Les tâches où l’écart persiste sont claires : les manipulations de fichiers (64 contre 89) et le choix des outils (38 % d’overlap contre un idéal à 100 %). Le modèle est bon pour raisonner sur les données qu’on lui donne, mais moyen pour décider quels outils utiliser. Une règle simple : les tâches multi-étapes restent confiées à Claude, les autres peuvent passer au local.

CE QU’IL FAUT RETENIR AVANT DE SE LANCER

Si vous envisagez de remplacer une API par un modèle local, voici les leçons à appliquer :

1. Testez d’abord le contexte : donnez au modèle accès à la totalité de vos schémas d’outils et de votre contexte personnel. Un modèle de 30B avec 256K de contexte peut donner de meilleurs résultats qu’un modèle de 122B avec 16K.

2. Mesurez le coût réel : l’électricité, c’est de l’argent. Un modèle qui consomme 100 W en idle peut coûter cher si vous le laissez tourner en permanence.

3. Vérifiez la qualité avec un juge externe : un juge automatique peut biaiser les résultats. Si possible, faites évaluer les réponses par des humains ou des outils indépendants.

4. Anticipez les limites : même avec 256K de contexte, certaines tâches dépassent la limite. Prévoyez un mécanisme de gestion des erreurs ou de découpage des requêtes.

5. Comparez systématiquement : ne vous fiez pas aux benchmarks théoriques. Testez avec vos propres données et vos propres outils avant de prendre une décision.

LE PIÈGE À ÉVITER : CONFONDRE « MOINS CHER » ET « MEILLEUR »

Un modèle local peut coûter 787 fois moins cher qu’une API… mais il n’est pas forcément meilleur. La qualité reste un critère prioritaire, surtout pour des tâches critiques comme l’envoi d’emails ou la gestion de fichiers sensibles.

L’auteur a annulé son abonnement Max, mais garde Pro pour les tâches où la précision est cruciale. Le modèle local est désormais utilisé pour les tâches « simples » : répondre à des messages, prendre des notes, gérer des rappels. Pour le reste, il reste une alternative économique et confidentielle, mais pas encore un remplacement universel.

La question n’est plus « Peut-on remplacer une API par un modèle local ? », mais « Quelles tâches peut-on confier à un modèle local sans risque ? ».

LE FUTUR : VERS DES AGENTS IA 100 % LOCAUX ET ÉCONOMIQUES ?

Ce test montre qu’un modèle local peut désormais rivaliser avec une API sur des tâches variées, à condition d’y mettre les moyens. Avec des cartes graphiques toujours plus puissantes et des modèles toujours plus optimisés, la frontière entre local et API s’amenuise.

Pour les utilisateurs prêts à investir dans du matériel et à accepter quelques compromis, l’autonomie et la confidentialité deviennent des avantages majeurs. Pour les autres, les API restent la solution la plus simple et la plus fiable.

Une chose est sûre : l’ère des agents IA 100 % cloud est peut-être en train de laisser place à une ère hybride, où le local et le cloud coexistent selon les besoins.

EN RÉSUMÉ : CE QUE LES CHIFFRES DISENT VRAIMENT

Voici les résultats bruts des deux tentatives :

• Première tentative (30B, 16K contexte) :
• Score moyen : 22,8/100 (Claude : 89,4)
• Appels d’outils mal formatés : 7/27 (25,9 %)
• Overlap des outils : 14,8 %
• Coût par tâche : quasi nul (carte partagée)
• Fiabilité : catastrophique (boucles, erreurs)
• Deuxième tentative (122B, 256K contexte) :
• Score moyen : 80,0/100 (Claude : 89,4)
• Appels d’outils mal formatés : 0/27 (0 %)
• Overlap des outils : 38,0 %
• Coût par tâche : 0,000969 $
• Fiabilité : bonne (quelques erreurs mineures)

Le matériel et le contexte ont fait la différence. La taille du modèle a joué, mais le contexte a été déterminant.

COMMENT REPRODUIRE CE TEST ?

Si vous voulez tester vous-même, voici la marche à suivre :

1. Préparez vos données : exportez les logs de votre agent (ou utilisez des tâches réelles) dans un format exploitable (JSON, CSV).

2. Configurez un environnement de test : un sandbox qui intercepte les appels d’outils réels (emails, fichiers, etc.) pour éviter les accidents.

3. Choisissez vos modèles : commencez par un modèle local de taille moyenne (30B-70B) et testez-le avec un contexte suffisant pour couvrir vos schémas d’outils.

4. Mesurez tout : temps de réponse, consommation énergétique, qualité des réponses, coût. Utilisez un outil comme HomeLab Monitor pour l’énergie.

5. Comparez avec une baseline : utilisez les réponses réelles de votre API actuelle comme référence, pas une simulation.

6. Itérez : augmentez la taille du contexte ou du modèle si les résultats ne sont pas satisfaisants.

LES LIMITES DE CE TEST (ET COMMENT LES DÉPASSER)

Ce test n’est pas une étude scientifique. Il mesure un système spécifique (Jarvis) dans un environnement spécifique (un labo personnel). Voici les limites à garder en tête :

1. Biais du juge automatique : le juge est un modèle Claude, ce qui favorise les réponses de l’API. Un juge indépendant (humain ou autre modèle) donnerait probablement des résultats différents.

2. Pas de contrôle isolé : les deux variables (taille du modèle et taille du contexte) ont changé en même temps. Impossible de savoir laquelle a le plus influencé les résultats.

3. Environnement spécifique : Jarvis utilise près de 90 outils et un contexte personnel complexe. Les résultats ne s’appliquent pas à tous les agents.

4. Coût énergétique sous-estimé : les chiffres incluent l’idle et un tarif domestique. En entreprise, le coût de l’électricité et du matériel serait bien plus élevé.

5. Pas de test de latence : le temps de réponse n’a pas été mesuré, alors qu’il est crucial pour l’expérience utilisateur.

Pour aller plus loin, il faudrait :

• Tester plusieurs modèles locaux (pas seulement qwen3-coder)
• Isoler l’impact du contexte et de la taille du modèle
• Utiliser un juge indépendant pour éviter le biais
• Mesurer la latence et la consommation réelle en conditions d’usage
• Tester sur d’autres types d’agents (pas seulement Jarvis)

CE QUE CE TEST NOUS APPREND SUR L’IA LOCALE EN 2025

En 2025, l’IA locale n’est plus une curiosité pour hobbyistes. Avec des cartes graphiques grand public capables de charger des modèles de 100 milliards de paramètres, et des outils comme Ollama ou LM Studio qui simplifient le déploiement, l’IA locale devient une option viable pour de nombreux usages.

Mais cette viabilité dépend de trois facteurs :

1. Le matériel : un modèle de 30B tient sur une seule carte RTX 3090, mais un modèle de 122B nécessite trois cartes ou plus. Le coût du matériel reste un frein pour beaucoup.

2. Le contexte : sans un contexte suffisant, même le meilleur modèle échouera. Les schémas d’outils, les prompts personnalisés et les données historiques doivent tenir dans la fenêtre de contexte.

3. La fiabilité : un modèle local peut être moins cher et plus confidentiel, mais il doit être suffisamment fiable pour être utilisé en production. Les erreurs (appels d’outils mal formatés, boucles) sont rédhibitoires.

L’IA locale n’est pas une solution universelle, mais elle devient une alternative crédible pour les utilisateurs prêts à investir du temps et de l’argent. Pour les autres, les API restent la solution la plus simple.

POUR ALLER PLUS LOIN : RESSOURCES ET OUTILS

Si vous voulez explorer l’IA locale par vous-même, voici quelques ressources utiles :

Outils de déploiement :

• Ollama : pour charger et exécuter des modèles locaux facilement.
• LM Studio : une interface graphique pour gérer les modèles locaux.
• HomeLab Monitor : pour mesurer la consommation énergétique de vos expériences locales (outil open source de l’auteur).

Modèles à tester :

• qwen3-coder:30b et qwen3-coder:122b : des modèles open source optimisés pour le code et les agents.
• Mixtral-8x22B : un autre modèle performant pour les agents.
• Llama-3.1-70B : un modèle polyvalent et optimisé.

Tutoriels :

• Comment configurer un agent LangGraph avec un modèle local.
• Comment mesurer la consommation énergétique de vos expériences.
• Comment optimiser le contexte pour vos agents.

LE MOT DE LA FIN : L’IA LOCALE EST UNE QUESTION DE TRADE-OFF

Remplacer une API par un modèle local, c’est faire un arbitrage entre trois critères :

1. Le coût : l’IA locale est bien moins chère à l’usage, surtout sur le long terme.

2. La confidentialité : vos données ne quittent jamais votre machine.

3. La qualité : l’API reste souvent plus fiable, surtout pour les tâches complexes.

Le choix dépend de vos priorités. Si la confidentialité et le coût sont vos principaux critères, l’IA locale est une option sérieuse. Si la qualité et la simplicité priment, les API restent la meilleure solution.

Une chose est sûre : l’IA locale n’est plus une option marginale. Elle devient une alternative crédible, et les tests comme celui-ci montrent qu’elle peut rivaliser avec les API… à condition d’y mettre les moyens.

La question n’est plus « Peut-on remplacer une API par un modèle local ? », mais « Quand et comment le faire ? ».