On nous demande régulièrement si un LLM local — un modèle d'IA qui tourne sur nos propres serveurs, sans rien envoyer à un tiers — peut remplacer un modèle hébergé pour des tâches métier. Plutôt que de répondre à l'instinct, nous avons mesuré. Au 20 mai 2026, après avoir confronté 6 modèles locaux (via Ollama) à plusieurs tâches RDEM réelles — de la génération de contenu à l'audit de code, jusqu'au conseil en second avis —, voici nos conclusions, et le pourquoi de chacune.
Le résultat tient en une phrase : le format tient, la fidélité factuelle s'effondre. La capacité à rédiger et à structurer est bien là ; mais dès qu'on quitte le meilleur modèle de chaque tâche, le défaut n'est pas la forme — c'est l'hallucination de faits. La réponse n'est pourtant pas binaire : tout dépend d'où atterrit l'erreur. Voici comment nous l'avons vérifié.
Pourquoi tester l'IA locale
Le local n'est pas une lubie : il répond à deux contraintes que l'hébergé ne sait pas toujours adresser.
Souveraineté des données
Certaines données ne doivent jamais quitter votre infrastructure — secret industriel, données de santé, contraintes RGPD ou contractuelles. Un modèle local exécuté sur des serveurs que vous maîtrisez supprime le transfert vers un tiers.
Coût marginal quasi nul
Une fois le matériel amorti, chaque génération est gratuite. Sur un volume massif et répétitif, l'argument économique devient sérieux — à condition que la qualité suive.
La vraie question n'est donc pas « est-ce possible ? » mais « est-ce fiable sans relecture humaine ? ». C'est ce que le protocole cherche à trancher.
Le protocole : deux tâches métier réelles, fact-checkées
Pas de benchmark académique : deux tâches que nous faisons pour de vrai, avec la même consigne pour chaque modèle, puis confrontation systématique à une vérité-terrain vérifiée. C'est ce fact-check qui sépare une démo flatteuse d'un résultat exploitable.
Audit de code d'une application métier (Laravel)
Consigne : « audit complet — qualité, sécurité, duplication, tests, performances ». Sortie confrontée à la réalité du dépôt, ligne par ligne.
Génération de fiches produits e-commerce (SEO)
6 sections imposées (description HTML, meta, titre SEO, H1, mots-clés, tags), sur 5 produits choisis pour leurs pièges factuels (éditeur, année, licence à ne pas inventer).
Résultats — audit de code
Un seul modèle s'est révélé exploitable, et seulement en relecture : Gemma 26B (contexte 128k). Il a identifié le vrai point d'architecture du projet — un service monolithique de plus de 5 000 lignes — et qualifié correctement la posture de sécurité. Les coquilles dans les noms (effet de la quantization) restaient mineures.
| Modèle | Références fichier/ligne réelles | Affirmations fausses | Exploitable |
|---|---|---|---|
| Gemma 26B (128k) | Oui | Quasi nulles | Oui, en relecture |
| Qwen (v2) | Partiel | Peu, mais génériques | À nuancer |
| Qwen (v1) | Non | Nombreuses | Non |
| Qwen 27B | Non | Quasi toutes | Non |
L'exemple le plus parlant
Un modèle a inventé l'absence de protection CSRF, de tests automatisés et de limitation de débit — toutes bien présentes — ainsi qu'un dossier de tests Selenium et un fichier de configuration qui n'existent pas. Une « lacune » hallucinée a l'apparence d'un constat sérieux : sans relecture, on corrige un problème inexistant.
L'angle mort commun : personne n'a lu la CI
Tous les modèles ont recommandé d'ajouter de l'analyse statique, des scanners de sécurité et des tests… déjà en place dans la chaîne d'intégration continue. Aucun n'avait lu le fichier de CI. C'est le premier réflexe de fact-check : le modèle a-t-il regardé ce qui tourne vraiment, ou a-t-il halluciné un projet générique ?
Résultats — génération SEO de fiches produits
Ici, aucun modèle local n'est exploitable en l'état. Le plus frappant : Qwen3-coder produit un format parfait (6 sections, slugs valides, structure respectée) mais des faits désastreux — sur un jeu, il a inventé la franchise, le studio de développement et l'année de sortie.
| Modèle | Format | Fidélité des faits | Verdict |
|---|---|---|---|
| Qwen3-coder | Excellent | Mauvaise | Format top, faits faux |
| Gemma 27B (offload CPU) | Moyen | La moins pire | Semi-supervisé seulement, lent |
| Mistral | Absent | Variable | 2/5 produits, inutilisable |
| deepseek-r1 | Markdown imposé | Bon raisonnement | Supprime la description |
| Gemma e4b | Fuites de gabarit | La pire | Non |
Le piège : une hallucination au slug valide
Le pire cas n'est pas le format cassé — il se voit. C'est l'hallucination dont la forme est valide : un slug de licence bien formé, mais faux, franchit le filtre serveur sans alerter. C'est exactement le type d'erreur qu'aucune validation syntaxique ne rattrape, et qui finit en ligne sur la boutique.
Pourquoi un fait faux coûte plus cher qu'un fait manquant
Sur un catalogue indexable, l'hallucination factuelle n'est pas un simple défaut de qualité : c'est la dimension la plus coûteuse de l'expérience, parce que ces faits finissent indexés et structurés. C'est notre angle d'expertise — voici pourquoi.
1. Données structurées = hallucination lisible par la machine
Une fiche produit porte du schema Product / Offer. Un éditeur, une année ou une licence inventés ne sont pas qu'une faute de texte : ils sont sérialisés en JSON-LD et lus tels quels par Google. Risque : perte d'éligibilité aux rich results (« Misleading structured data »). Or le local échoue précisément sur les champs qui alimentent le balisage.
2. Risque GEO / E-E-A-T amplifié
Une part croissante du trafic vient de l'AI search. Une fiche qui affirme un fait faux devient une source que les LLM citent puis propagent : l'erreur se « blanchit » en réponse IA, et l'atteinte à l'E-E-A-T devient durable, difficile à corriger une fois ingérée.
3. Pollution taxonomique — le pire cas
L'hallucination « au slug valide » franchit le filtre serveur et associe le produit à une mauvaise licence / un mauvais tag. Le maillage interne crée alors de faux clusters thématiques : produit rangé sous la mauvaise franchise, pages de catégorie diluées, cannibalisation. Invisible à la relecture humaine de la fiche.
4. Sur-optimisation et contenu mince à l'échelle
Mots-clés « spammy » et titres hors-gabarit sont des signaux négatifs et dégradent le CTR. Et un modèle non ancré tend à produire des descriptions quasi-dupliquées entre produits proches — thin content + cannibalisation. Or la valeur SEO d'une fiche vient justement du fait différenciant exact (édition, région, année) : ce que le local invente.
Implication : le garde-fou n'est pas « relire le texte » mais ancrer les faits avant génération et valider le balisage et la taxonomie côté serveur — pas seulement la validité du slug. Une fiche sans année ne ment pas à Google ; une fiche avec une mauvaise année, si.
Le constat commun : le format tient, les faits s'effondrent
Sur les deux tâches, l'échec a la même signature. Les modèles locaux savent structurer ; ils ne savent pas garantir un fait. Et plus le modèle est compressé pour tenir en mémoire, plus la fidélité chute.
Deux mécanismes l'aggravent : la quantization (compression du modèle) qui dégrade la précision, et un contexte mal maîtrisé — un bloc de données trop gros sature la fenêtre et contamine la sortie, le modèle piochant dans ce qu'on lui affiche. Pré-filtrer le contexte côté applicatif corrige une partie du problème.
Conclusion : sur une tâche où un fait faux a un coût (un audit qui oriente une décision, une fiche produit publiée), le local n'atteint pas le seuil du non-supervisé. La relecture humaine reste obligatoire — ce qui annule une bonne partie du gain.
La vraie ligne de partage : où atterrit l'erreur ?
Nos résultats les plus durs portent sur un usage précis : la production d'une sortie publiée telle quelle — un rapport qui oriente une décision, une fiche qui finit indexée. Là, une hallucination est fatale. Mais nous avons aussi exercé le local sur l'usage opposé : le second avis, le sparring sur une analyse, où la sortie est relue par un humain et où rien n'est publié.
Le résultat s'inverse. Là, le risque d'hallucination est borné : le défaut fatal disparaît. Mieux, les modèles n'ont pas seulement confirmé l'analyse — ils ont fait émerger des pistes que nous n'avions pas anticipées. En conseil, le coût d'un faux positif, c'est quelques secondes de tri ; pas une page polluée et indexée. Un modèle local imparfait qui sort une seule piste juste est déjà rentable.
Exemple vécu : deux modèles locaux en tandem
Sur une revue de positionnement commercial, un premier modèle local (Gemma) a proposé un angle que nous n'avions pas centré : plutôt que de chercher à remplacer l'outil que le prospect technique opère déjà lui-même, le vendre comme le complément de cet outil.
Un second modèle, DeepSeek, lancé en stress-test, a fait surgir une piste que nous n'avions pas envisagée : présentée ainsi, l'offre devient une commodité qu'un utilisateur avancé peut reproduire à bas coût. D'où une conclusion affinée — mettre en avant ce qui n'est justement pas reproductible en bricolage : garanties d'immuabilité réelles, restaurations vérifiées, souveraineté.
Ce n'est pas un cas isolé : sur plusieurs de nos audits SEO, le raisonnement explicite de DeepSeek a révélé des pistes que nous n'avions pas envisagées — précisément la valeur d'un second avis, là où l'erreur éventuelle est filtrée par l'humain avant toute décision.
Aucune de ces sorties n'a été publiée : elles ont nourri la réflexion, et un faux pas de positionnement a été évité avant qu'il ne coûte. Le motif est réutilisable — un modèle pour générer les angles, un autre pour les attaquer, en séquentiel.
La ligne de partage n'est donc pas « local vs hébergé », mais : « la sortie est-elle publiée telle quelle ? »
- Publiée telle quelle (contenu indexé, livrable client) → modèle hébergé.
- Interceptée par un humain (second avis, brainstorming, tri) → le local apporte de la valeur, à coût marginal nul.
Ce que nous n'avons pas (encore) testé
Honnêteté de méthode : notre protocole testait le modèle « nu », en une seule passe, sans outils. C'est le périmètre le plus défavorable au local. Deux architectures que nous n'avons pas encore explorées pourraient rebattre les cartes — et toutes deux partagent la propriété qui rend le local viable : l'erreur y est interceptée ou corrigée avant qu'elle ne compte.
Les agents (tool-use)
Un modèle local équipé d'outils — recherche, accès à une API, exécution de code — peut aller chercher le fait au lieu de le deviner. Des modèles orientés agents (type Hermes) pourraient compenser par l'outillage exactement la faiblesse factuelle qui plombe la génération en une passe.
Le pré-traitement en cascade
Un petit modèle local, même de moindre qualité, peut assurer le pré-traitement à coût nul (extraction, classification, désambiguïsation, brouillon de mise en forme), avant d'escalader vers un modèle plus expert — un local plus gros, ou un hébergé — pour la seule partie critique. On ne paie l'expert que là où il compte vraiment.
Nos conclusions valent donc pour le cas le plus exigeant — un modèle seul, en une passe, sans filet. Architecturé en agent ou en cascade, le local pourrait reprendre nettement de l'intérêt. C'est notre prochaine étape de test.
Quand l'IA locale se justifie quand même
Deux cas, et une condition impérative : le pipeline bridé.
- Souveraineté absolue : la donnée ne peut juridiquement pas sortir de votre infrastructure.
- Volume massif à coût marginal nul, où même un taux d'erreur résiduel reste économiquement gérable après relecture ciblée.
Le pattern qui fonctionne : ancrer les faits, brider le modèle
On ne demande jamais au LLM local de connaître les faits. On lui demande de mettre en forme des faits déjà vérifiés :
- Les faits viennent d'une source déterministe (API métier, base de données interne, référentiel). Le modèle ne sert qu'à désambiguïser l'entité, pas à inventer ses attributs.
- Le LLM est utilisé comme moteur de rendu bridé : « voici les faits vérifiés, mets-les en forme, n'ajoute rien ».
- Le contexte est pré-filtré côté applicatif, et la sortie validée côté serveur (syntaxe et cohérence).
Coût : un modèle hébergé reste imbattable
Quand la souveraineté n'est pas en jeu, l'arbitrage économique penche nettement vers l'hébergé. Sur notre profil de génération SEO (~3 500 tokens d'entrée dont ~3 100 statiques, ~1 200 de sortie), avec prompt caching :
| Modèle | Par fiche (avec cache) | 1 000 fiches |
|---|---|---|
| Claude Haiku 4.5 | ~0,006 € | ~6,5 € |
| Claude Sonnet 4.6 | ~0,018 à 0,02 € | ~18 € |
| Claude Opus 4.7 | ~0,09 € | ~92 € |
Sonnet 4.6 est le point d'équilibre fiabilité / coût ; Haiku 4.5 tient le plancher. Le coût est dominé par la sortie — d'où l'intérêt de ne mettre en cache que le prompt système stable. Surtout, ces centimes sont à mettre en face de l'investissement matériel du local : un serveur GPU capable de faire tourner ces modèles, c'est plusieurs milliers d'euros à amortir, plus l'électricité et l'exploitation — que des appels facturés 0,02 € ne « remboursent » qu'à très gros volume, et encore. À ces tarifs, le local ne se justifie donc pas par l'économie seule : il se justifie par la souveraineté.
FAQ
Un LLM local peut-il remplacer un modèle hébergé en production ?
Pas en autonomie sur une tâche factuelle. Dans nos tests de mai 2026 (6 modèles via Ollama), aucun n'a atteint le seuil du non-supervisé. La rédaction et le formatage sont au rendez-vous, mais la fidélité factuelle s'effondre dès qu'on quitte le meilleur modèle de chaque tâche. Le défaut n'est pas la forme, c'est l'hallucination de faits.
Quand l'IA locale se justifie-t-elle malgré tout ?
Sous deux contraintes : la souveraineté des données (interdiction d'envoyer la donnée à un tiers) ou un volume massif à coût marginal quasi nul. Et même alors, uniquement en pipeline bridé : les faits sont ancrés par une source déterministe et le LLM est réduit à un moteur de mise en forme qui n'invente rien.
L'IA locale est-elle inutile pour les tâches factuelles ?
Non. Notre verdict négatif ne vaut que pour la production de contenu publié tel quel. En mode second avis ou sparring — quand un humain relit avant publication — l'IA locale est exploitable et apporte de la valeur à coût marginal nul : dans nos tests, elle a même fait émerger des pistes que nous n'avions pas anticipées. La ligne de partage est : la sortie est-elle publiée telle quelle, ou interceptée par un humain ?
Quel modèle local a été le moins mauvais ?
Pour l'audit de code, Gemma 26B (contexte 128k) est le seul que nous avons jugé exploitable, en relecture humaine obligatoire. Pour la génération SEO, aucun modèle local n'est exploitable en l'état : Qwen3-coder produit le meilleur format mais avec des faits faux.
Pourquoi les modèles locaux hallucinent-ils autant sur les faits ?
Deux facteurs cumulés. La quantization (compression du modèle pour tenir en VRAM) dégrade la précision et introduit des coquilles. Et un contexte mal maîtrisé : un bloc de données trop gros sature la fenêtre et contamine la sortie. Le pré-filtrage du contexte côté applicatif corrige une partie du problème.
Ce qu'il faut retenir
- Le format tient, la fidélité factuelle s'effondre — le défaut est l'hallucination de faits, pas la forme.
- La vraie question n'est pas « local vs hébergé » mais « la sortie est-elle publiée telle quelle ? ».
- En production de contenu publié, aucun modèle local n'atteint le non-supervisé (Gemma 26B reste l'exception en audit-relecture) → modèle hébergé.
- En second avis relu par un humain, le local devient exploitable à coût marginal nul — il a même fait émerger des pistes non anticipées.
- Agents (tool-use) et cascade de pré-traitement non encore testés — ils pourraient redonner de l'intérêt au local. Sans souveraineté en jeu, l'hébergé (Sonnet 4.6 / Haiku 4.5) reste le meilleur rapport fiabilité / coût / risque en production.
Un projet d'IA souveraine ou de génération à grande échelle ?
On vous aide à arbitrer entre local et hébergé, à concevoir un pipeline bridé fiable, et à ancrer les faits pour éviter les hallucinations. Décrivez votre cas, on vous répond concrètement.