IA locale vs IA en ligne : laquelle choisir ?
Confidentialité, coût, latence : on compare l'inférence en local et via API cloud pour vous aider à décider.
~ 12 min de lecture

Quand on parle d'« IA », on imagine souvent un service en ligne auquel on envoie une question et qui renvoie une réponse. Mais il existe une autre voie, de plus en plus populaire : faire tourner l'IA soi-même, sur sa propre machine. Chaque approche a ses forces et ses faiblesses, et le bon choix dépend surtout de votre cas d'usage, de vos contraintes de confidentialité, et de votre budget — tant en matériel qu'en tokens consommés.
Ce guide est le point d'entrée du centre de ressources : il pose les bases du débat, et chacun des guides suivants creuse une facette (infrastructure, vocabulaire, matériel, stations de travail). Pour les prix des API cloud, le comparateur de la page d'accueil reste l'outil de référence.
L'IA en ligne (API cloud)
Vous appelez un modèle hébergé chez un provider (OpenAI, Anthropic, Google, Mistral, Cohere, DeepSeek…) ou un agrégateur (OpenRouter, Together AI, Fireworks). Vous payez par million de tokens — souvent un prix différent pour l'entrée (prompt, « in ») et la sortie (complétion, « out »). C'est exactement ce que compare le comparateur de prix de la page d'accueil.
Le provider gère tout l'ingénieurie : serveurs, GPU, scaling, mise à jour des modèles, disponibilité. Vous n'avez qu'à envoyer une requête HTTP et récupérer du texte. Le SDK est souvent trivial à intégrer.
Avantages
- Aucun matériel à acheter : un simple script ou curl suffit. Idéal pour prototyper.
- Modèles toujours à jour : les versions « frontier » (GPT-5, Claude Opus, Gemini 2.5…) sont disponibles immédiatement, sans rien réinstaller.
- Scalabilité immédiate : de 1 à 10 000 requêtes simultanées sans rien dimensionner.
- Qualité maximale : les meilleurs modèles du marché sont exclusivement disponibles via API, car ils ne tiendraient pas sur une machine personnelle.
- Fonctionnalités avancées : tools/function calling, vision, embeddings, fine-tuning managé, guardrails — tout est déjà branché.
Inconvénients
- Vos données transitent chez un tiers. Selon le provider, elles peuvent être stockées, loggées, voire utilisées pour l'entraînement (vérifiez les CGU et les options « zero data retention »).
- Coût qui s'accumule : à l'usage massif (agents qui bouclent, gros contextes), la facture grimpe vite. Un agent qui envoie 200k tokens par exécution coûte cher.
- Dépendance à la disponibilité : une panne ou une limitation de débit chez le provider, et votre app est en panne.
- Latence réseau : chaque requête subit un aller-retour réseau (souvent 200 ms à plus d'1 s selon la charge du modèle).
- Verrouillage : changer de provider implique souvent de retoucher prompts et gestion d'outils.
L'IA locale
Vous téléchargez un modèle (souvent au format GGUF, parfois SafeTensors) et vous le faites tourner avec un moteur d'inférence comme llama.cpp, Ollama, LM Studio, vLLM ou mlx (sur Apple Silicon). Tout reste sur votre machine : le texte ne quitte jamais votre disque.
Avantages
- Confidentialité totale : données sensibles, code propriétaire, dossiers clients — rien ne sort. Critique pour la santé, la finance, le juridique, la défense.
- Coût marginal : une fois le matériel amorti, l'inférence ne coûte que de l'électricité. Pas de surprise sur la facture.
- Pas de limite de débit : vous êtes le seul client. Pas de rate limit, pas de queue.
- Fonctionnement hors-ligne : utile en déplacement, en environnement sécurisé, ou simplement pour ne pas dépendre d'internet.
- Contrôle total : choix exact du modèle, de la quantization, des paramètres de génération, du contexte. Reproductibilité parfaite.
Inconvénients
- Investissement matériel : il faut du GPU et surtout de la VRAM. Une configuration correcte démarre à ~1 500 €, une station pro dépasse 10 000 €.
- Qualité plafonnée : les meilleurs modèles « frontier » (200B+ paramètres) ne tiennent pas en local. On se limite aux 70B et moins.
- Configuration technique : pilotes CUDA/ROCm, compilation de moteurs, gestion de la VRAM, quantization — une courbe d'apprentissage réelle.
- Mise à jour manuelle : pour avoir le dernier modèle, il faut le télécharger et parfois le re-quantizer.
- Énergie et bruit : une machine qui infère à plein régime chauffe et fait du bruit ; en 24/7 ça compte.
Le critère décisif : la VRAM
La taille du modèle que vous pouvez faire tourner en local dépend directement de la mémoire vidéo (VRAM) de votre carte graphique — pas de sa puissance de calcul brute. Un modèle de 7B en quantization 4-bit tient dans ~5 Go de VRAM ; un 70B demande ~40 Go. C'est pour cela que les cartes à grosse VRAM (RTX 4090 24 Go, RTX 5090 32 Go, ou un Mac avec mémoire unifiée) sont si prisées : la VRAM est le goulot d'étranglement, pas les TFLOPS.
Règle de pouce : un modèle quantifié en 4-bit occupe environ 0,6 Go par milliard de paramètres. Un 13B → ~8 Go, un 70B → ~40 Go, un 120B → ~72 Go. En 8-bit, comptez ~1,1 Go par milliard.
Quand le modèle dépasse la VRAM, des moteurs comme llama.cpp « débordent » (offload) les couches excédentaires en RAM système, puis sur CPU. Ça marche, mais la vitesse s'effondre : on passe de 40 tokens/s à 3-5 tokens/s. La bande passante mémoire (GDDR6X, HBM, mémoire unifiée Apple) est donc le second facteur clé.
Comparaison chiftrée : un cas concret
Imaginons un assistant qui traite 100 000 requêtes par mois, chacune consommant ~2 000 tokens en entrée et ~500 tokens en sortie. Voici comment les deux approches se comparent, avec un modèle type GPT-4o-mini (~0,15 $/M in, ~0,60 $/M out) :
| Métrique | API cloud (GPT-4o-mini) | Local (Llama-3-8B sur RTX 4090) |
|---|---|---|
| Tokens in / mois | 200 M | 200 M |
| Tokens out / mois | 50 M | 50 M |
| Coût API | ~30 $ + ~30 $ = ~60 $/mois | 0 $ (électricité incluse) |
| Coût matériel amorti (3 ans) | 0 € | ~2 500 € → ~70 €/mois |
| Latence par requête | ~400-800 ms (réseau) | ~150-300 ms (local) |
| Confidentialité | Données chez le provider | Totale, sur disque |
| Qualité du modèle | Très bonne | Bonne (8B), inférieure sur tâches complexes |
Sur ce volume, l'API reste moins chère que l'amortissement matériel. Le point de bascule se situe généralement au-delà de 500k-1M requêtes/mois, ou dès que la confidentialité entre en jeu. Pour un usage occasionnel ou de prototypage, l'API gagne ; pour un usage massif ou sensible, le local devient rentable.
Le spectre des cas d'usage
| Usage | Volume | Confidentialité | Recommandation |
|---|---|---|---|
| Prototypage, test d'idée | Faible | Standard | API cloud (zero setup) |
| Données sensibles / NDA | Quelconque | Critique | Local (obligatoire) |
| Volume massif, 24/7 | Élevé | Standard | Local ou GPU loué (Vast.ai/RunPod) |
| Qualité maximale (frontier) | Quelconque | Standard | API cloud (pas d'alternative locale) |
| Agent qui boucle longtemps | Élevé | Standard | Local (sinon la facture explose) |
| Budget matériel limité | Quelconque | Standard | API cloud ou GPU à l'heure |
| Hors-ligne / embarqué | Faible | Critique | Local (via llama.cpp / Colibri) |
Une troisième voie : louer du GPU à l'heure
Entre le tout-local (acheter) et le tout-API (payer au token), il existe un compromis : louer une machine avec GPU à l'heure, chez Vast.ai, RunPod, Lambda Labs ou les hyperscalers. Vous obtenez un GPU dédié pour quelques dizaines de centimes par heure, vous y lancez votre propre moteur d'inférence, et vous ne payez que le temps d'utilisation. C'est l'option reine pour le fine-tuning ponctuel, les batchs massifs, ou pour tester un modèle sur un gros GPU sans investir. Le guide suivant détaille ces infrastructures.
Le piège du coût caché du cloud
Attention : le prix « par million de tokens » ne raconte pas toute l'histoire. Un agent autonome peut enchaîner 20 appels avec de longs contextes ; un RAG peut réinjecter des morceaux de documents entiers. Le vrai coût est tokens consommés × prix unitaire × nombre d'exécutions. Sur un workload agentique, la facture mensuelle peut dépasser le coût d'une RTX 4090 en quelques semaines. C'est précisément pour anticiper ce point que le comparateur de prix de ce site existe — et que les guides sur le matériel et les infrastructures suivent.
En résumé
- API cloud = simplicité, scalabilité, qualité frontier, mais vos données sortent et le coût grimpe à l'usage.
- Local = confidentialité, coût marginal, contrôle, mais investissement matériel et qualité plafonnée.
- GPU loué = le meilleur des deux mondes pour les usages ponctuels ou intensifs sans acheter.
- La VRAM est le critère n°1 du local ; le volume de tokens est le critère n°1 du cloud.
Pour aller plus loin : consultez le guide sur l'infrastructure (VPS, Vast.ai, RunPod) pour la location de GPU, celui sur le vocabulaire (LLM, modèles, harnais) pour comprendre les termes, et celui sur le matériel pour dimensionner une machine.