IA locale ou cloud : que choisir selon son besoin et son budget

En bref

• Il n'y a pas « une » bonne réponse : il y a trois options (API cloud, abonnement, modèle ouvert chez soi) et chacune gagne sur un critère différent.
• Pour la qualité brute sur des tâches difficiles, les grands modèles cloud restent devant. Pour la confidentialité et le fonctionnement hors ligne, le local est imbattable.
• Le coût d'une API se calcule : tokens × prix × volume. Faites le calcul avant de décider, avec l'outil calculateur de coût d'API IA.
• Le « gratuit » du local est trompeur : matériel, électricité, maintenance et sécurité ont un coût réel.
• Dans la plupart des PME, la meilleure architecture est hybride : les données sensibles restent en local, le reste part dans le cloud.
• Un serveur d'inférence exposé sur Internet sans authentification est une faille, pas un détail.

Pourquoi ce guide

Chaque semaine, un client me pose une variante de la même question : « Est-ce qu'on peut utiliser ChatGPT avec nos données clients ? », « Est-ce qu'on ne devrait pas plutôt installer notre propre IA ? », « Combien ça va coûter par mois ? ».

Les réponses qu'on trouve en ligne sont souvent tranchées pour de mauvaises raisons : les vendeurs de cloud vous expliquent que le local est un hobby, les passionnés de modèles ouverts vous expliquent que le cloud est une prison. Moi, je n'ai rien à vendre dans un camp ou dans l'autre : je construis des sites, des applications et des automatisations, et j'utilise les deux selon le cas. Ce guide est la grille que j'applique réellement avant de recommander une solution.

Si vous cherchez l'IA sur téléphone sans connexion, j'ai écrit un guide dédié : une IA sur votre téléphone, sans Internet. Ici, on parle d'usage professionnel : entreprise, développement, automatisation.

Les trois options réelles

1. L'API cloud

Vous envoyez une requête (un texte, une image, un document) à un fournisseur, il renvoie une réponse, et vous payez à l'usage, généralement au nombre de tokens (des morceaux de mots) en entrée et en sortie.

• Pour qui : les développeurs et les entreprises qui intègrent l'IA dans un produit, un site, une automatisation.
• Points forts : accès aux modèles les plus performants, aucune machine à gérer, montée en charge immédiate, paiement proportionnel à l'usage.
• Points faibles : vos données quittent votre infrastructure, la facture dépend du volume (et peut surprendre), dépendance à un fournisseur et à ses changements de modèles ou de prix.

2. L'abonnement (grand public ou professionnel)

C'est l'assistant en ligne avec un forfait mensuel par utilisateur : l'interface de chat, éventuellement une offre « équipe » ou « entreprise ».

• Pour qui : les personnes qui travaillent avec l'IA au quotidien (rédaction, analyse, code, recherche), sans l'intégrer dans un logiciel.
• Points forts : prix prévisible, rien à développer, outils intégrés (fichiers, recherche web, projets).
• Points faibles : ce n'est pas une brique que vous pouvez brancher dans vos automatisations ; les conditions sur l'utilisation de vos données varient fortement entre offres gratuites, individuelles et professionnelles. Lisez-les.

3. Le modèle ouvert, en local ou sur votre serveur

Vous téléchargez les poids d'un modèle publié ouvertement et vous le faites tourner sur un ordinateur, une station de travail avec carte graphique ou un serveur que vous contrôlez.

• Pour qui : les données très sensibles, les usages hors ligne, les volumes élevés et réguliers, les équipes techniques qui veulent la maîtrise complète.
• Points forts : les données ne sortent pas, pas de facture à la requête, fonctionnement hors ligne, aucune dépendance à un fournisseur qui change ses règles.
• Points faibles : qualité généralement inférieure aux meilleurs modèles cloud sur les tâches complexes, matériel à acheter, maintenance et sécurité à votre charge.

Mon avis. Opposer ces trois options est une erreur. Une agence ou une PME bien organisée en utilise souvent deux, parfois les trois, chacune pour ce qu'elle fait le mieux.

Les six critères qui décident vraiment

1. Confidentialité et conformité

C'est le critère qui tranche le plus souvent, et c'est celui qu'on traite le plus mal.

• En Europe (RGPD) : si vous envoyez des données personnelles à un fournisseur d'IA, il agit en principe comme sous-traitant. Il vous faut un contrat de traitement des données, savoir où les données sont traitées, et encadrer les transferts hors de l'Union européenne.
• Au Maroc (loi 09-08) : la loi relative à la protection des personnes physiques à l'égard du traitement des données à caractère personnel est contrôlée par la CNDP. Le transfert de données personnelles vers un pays étranger est encadré : il n'est permis que vers un État qui assure un niveau de protection suffisant, et il relève d'une procédure auprès de la CNDP. Concrètement, envoyer des données de clients marocains vers une API hébergée à l'étranger n'est pas un geste anodin.
• Dans le Golfe : plusieurs pays ont adopté leurs propres lois de protection des données, avec des règles sur la localisation et le transfert. Vérifiez le texte applicable à votre pays et à votre secteur.

Je ne suis pas juriste et ce guide n'est pas un avis juridique. Mais la règle pratique que j'applique est simple : une donnée personnelle ou confidentielle qui n'a pas besoin de partir ne part pas. Soit on l'anonymise avant l'envoi, soit on la traite en local.

Deux réflexes avant de choisir un fournisseur cloud :

1. Vérifier, dans les conditions de l'offre exacte que vous utilisez, si vos données servent à entraîner les modèles et combien de temps elles sont conservées.
2. Vérifier la région de traitement et l'existence d'un contrat de sous-traitance.

Pour aller plus loin sur ce qu'il ne faut jamais coller dans une IA : sécurité, ce qu'il ne faut jamais confier à une IA.

2. Qualité des réponses

Soyons honnêtes : sur le raisonnement complexe, le code difficile, l'analyse longue ou les langues moins dotées, les meilleurs modèles cloud restent devant les modèles qu'on peut faire tourner sur une machine raisonnable.

Mais la question utile n'est pas « quel est le meilleur modèle ? ». C'est « quel est le modèle suffisant pour ma tâche ? ». Classer des e-mails, extraire des champs d'une facture, résumer un compte rendu, reformuler un texte : un modèle ouvert de taille moyenne fait souvent très bien le travail.

Ma méthode. Je prépare 20 à 30 exemples réels de la tâche, avec la réponse attendue. Je les fais passer dans un modèle local et dans un modèle cloud. Je compare. Cette demi-journée de test vaut mieux que n'importe quel classement publié.

Point d'attention pour nos marchés : la qualité en arabe, et encore plus en darija, varie énormément d'un modèle à l'autre. Testez avec vos vrais textes, pas avec des exemples en anglais.

3. Latence et expérience utilisateur

• Une API cloud ajoute un aller-retour réseau, mais tourne sur du matériel très puissant.
• Un modèle local répond sans réseau, mais sa vitesse dépend entièrement de votre matériel. Sur un ordinateur portable sans carte graphique dédiée, un modèle moyen peut être nettement plus lent qu'une API.

Pour un chatbot client, la vitesse ressentie compte beaucoup. Pour un traitement de nuit de 5 000 documents, elle compte peu.

4. Coût réel

C'est le critère qui génère le plus d'illusions, dans les deux sens. Je lui consacre une section entière plus bas.

5. Fonctionnement hors ligne

Un chantier sans réseau, un bureau avec une connexion instable, un appareil terrain, un environnement isolé pour raison de sécurité : si l'IA doit fonctionner sans Internet, la question est réglée, c'est du local.

6. Maintenance et compétences

Une API, c'est une clé et quelques lignes de code. Un serveur d'inférence, c'est une machine à surveiller, des mises à jour, des modèles à remplacer, de la sécurité réseau. Si personne dans l'équipe n'a le temps ni les compétences, le local « gratuit » coûtera cher en incidents.

Tableau de décision par cas d'usage

Le matériel pour faire tourner un modèle en local

La règle de calcul qui évite les mauvaises surprises

La contrainte principale, c'est la mémoire : mémoire vidéo de la carte graphique (VRAM), ou mémoire unifiée sur les ordinateurs dont le processeur et la puce graphique la partagent.

Un modèle est décrit par son nombre de paramètres (en milliards, noté B). Chaque paramètre occupe un certain nombre de bits selon la quantification (la précision avec laquelle les poids sont stockés) :

• en 16 bits : environ 2 octets par paramètre ;
• en 8 bits : environ 1 octet par paramètre ;
• en 4 bits : environ 0,5 octet par paramètre.

Ce qui donne une estimation de départ :

mémoire des poids (Go) ≈ paramètres (en milliards) × bits / 8

Il faut ensuite ajouter une marge pour le contexte (la conversation et les documents en cours) et le fonctionnement du logiciel. Plus le contexte est long, plus cette marge grossit.

Des ordres de grandeur prudents

Ce sont des estimations pour se repérer, pas des garanties : la vitesse et la consommation réelles dépendent du logiciel, de la longueur du contexte et de l'architecture du modèle.

Deux nuances importantes :

• Les modèles « mixture d'experts » (MoE) n'activent qu'une partie de leurs paramètres à chaque mot généré. Ils sont plus rapides qu'un modèle de même taille totale, mais il faut quand même pouvoir charger tous les poids en mémoire.
• Descendre trop bas en quantification (3 bits, 2 bits) fait gagner de la mémoire mais dégrade la qualité. Le 4 bits est le compromis le plus courant pour un usage local.

Exemple concret. OpenAI a publié en 2025 des modèles ouverts, la famille gpt-oss, sous licence Apache 2.0. Le plus petit (environ 20 milliards de paramètres) est présenté comme pouvant tourner avec environ 16 Go de mémoire, grâce à une quantification native en 4 bits sur une partie du modèle. C'est une bonne illustration : un « 20 B » bien optimisé tient sur une machine de développeur correcte.

Les outils pour faire tourner un modèle chez soi

Pour démarrer, mon conseil est simple : LM Studio si vous voulez tester sans terminal, Ollama si vous voulez brancher le modèle dans une application ou une automatisation.

Un exemple avec Ollama, qui illustre à quel point le démarrage est rapide :

ollama pull <nom-du-modèle>
ollama run <nom-du-modèle> "Résume ce texte en trois points : ..."

Attention à un changement récent : Ollama propose aussi des modèles exécutés dans son propre cloud. Sa documentation indique qu'en mode local, l'éditeur ne voit pas vos requêtes, et qu'on peut forcer un fonctionnement strictement local avec la variable OLLAMA_NO_CLOUD=1. Si votre raison d'être en local est la confidentialité, activez-la et vérifiez quel modèle vous utilisez réellement.

Les grandes familles de modèles ouverts

Le paysage bouge tous les mois, donc je ne vous donne pas un classement qui serait périmé dans trois mois. Voici les familles que je rencontre le plus souvent chez les clients et dans les outils :

• Llama (Meta) : très répandue, large écosystème, licence propre à Meta.
• Gemma (Google) : modèles de petite et moyenne taille, efficaces en local.
• Qwen (Alibaba) : large gamme de tailles, bon niveau multilingue, dont plusieurs versions sous licence Apache 2.0.
• Mistral (entreprise française) : plusieurs modèles ouverts, mais licences différentes selon les modèles.
• DeepSeek : modèles très performants, souvent de grande taille.
• gpt-oss (OpenAI) : modèles ouverts sous Apache 2.0.

Le piège des licences « ouvertes »

« Open weight » ne veut pas dire « open source », et encore moins « faites-en ce que vous voulez ». C'est le piège que je vois le plus souvent chez les entreprises qui passent au local.

• Apache 2.0 ou MIT : licences permissives, usage commercial autorisé, avec quelques obligations de mention.
• Licences maison : certaines familles imposent leurs propres conditions. La licence Llama, par exemple, contient une politique d'usage acceptable et une limite pour les très grands services (plus de 700 millions d'utilisateurs actifs mensuels). Les conditions d'utilisation de Gemma ont aussi leurs propres règles d'usage interdit.
• Licences par modèle : chez certains éditeurs, deux modèles de la même famille n'ont pas la même licence, et certaines interdisent l'usage commercial sans accord séparé.

La règle : lisez la licence du modèle exact que vous déployez, pas celle de la famille en général, et gardez une trace de cette vérification dans la documentation du projet.

Calculer le coût, sans se raconter d'histoires

Le coût d'une API

La formule est toujours la même :

coût mensuel ≈ (tokens d'entrée × prix d'entrée + tokens de sortie × prix de sortie) × nombre de requêtes par mois

Trois remarques qui changent tout :

1. L'entrée coûte souvent plus que prévu. Si vous envoyez un long document ou tout l'historique d'une conversation à chaque requête, ce sont les tokens d'entrée qui dominent la facture.
2. La sortie est généralement plus chère par token que l'entrée. Demander des réponses courtes et structurées est une économie directe.
3. Le choix du modèle fait varier la facture d'un facteur très important. Un petit modèle bien choisi pour une tâche simple coûte une fraction d'un grand modèle.

Je ne mets volontairement aucun prix dans ce guide : ils changent trop souvent. J'ai créé un outil pour faire ce calcul avec des tarifs datés et modifiables : le calculateur de coût d'API IA. Entrez votre volume, la taille moyenne de vos requêtes et de vos réponses, et comparez plusieurs modèles.

Le coût du local, le vrai

Le local n'est pas gratuit. Voici ce que je fais entrer dans le calcul :

• Le matériel : la machine ou la carte graphique, amortie sur sa durée de vie utile (souvent deux à quatre ans dans ce domaine qui évolue vite).
• L'électricité : une carte graphique sous charge consomme beaucoup ; un serveur allumé 24 h sur 24 aussi.
• L'hébergement si vous louez un serveur avec carte graphique : c'est souvent la ligne la plus lourde, et elle tourne même quand personne n'utilise l'IA.
• Le temps humain : installation, mises à jour, surveillance, changement de modèle, dépannage. C'est le coût caché numéro un.
• La sécurité : pare-feu, authentification, sauvegardes, journalisation.

Le point de bascule

La logique générale est la suivante :

• Faible volume ou volume irrégulier : l'API est presque toujours moins chère. Vous ne payez que ce que vous consommez.
• Volume élevé, régulier et prévisible, sur une tâche qu'un modèle ouvert fait bien : le local peut devenir rentable, parce que le matériel s'amortit.
• Données qui ne peuvent pas sortir : le calcul financier passe au second plan, le local s'impose.

Pour savoir si l'automatisation elle-même vaut l'investissement, indépendamment de la technologie, utilisez le calculateur de ROI de l'automatisation.

Le scénario hybride que j'utilise en pratique

Dans la plupart des projets de PME, je finis par proposer une architecture en deux étages :

1. Un modèle local ou sur un serveur maîtrisé reçoit en premier les données sensibles. Il fait le travail qui touche aux données personnelles : extraction, anonymisation, classification, résumé interne.
2. Un modèle cloud reçoit seulement ce qui peut sortir : des textes anonymisés, des contenus publics, des tâches de rédaction ou de traduction où la qualité compte beaucoup.

Exemple réel de schéma pour un cabinet qui traite des dossiers clients :

Dossier client (PDF)
  → modèle local : extraction des champs + remplacement des noms, numéros, adresses par des codes
  → modèle cloud : rédaction d'une synthèse claire à partir du texte anonymisé
  → modèle local : réinjection des vraies valeurs dans la synthèse
  → validation humaine

L'outil d'automatisation au milieu (n8n, par exemple) orchestre les étapes. J'en parle en détail dans le guide automatiser avec n8n et l'IA.

Ce schéma a trois avantages : la donnée identifiante ne sort jamais, on profite de la qualité du cloud là où elle compte, et on peut changer de fournisseur cloud sans toucher à la partie sensible.

La sécurité d'un serveur d'inférence

C'est le point que les tutoriels oublient, et c'est celui qui m'inquiète le plus quand j'audite une installation.

Ollama, par exemple, écoute par défaut uniquement sur la machine elle-même (127.0.0.1, port 11434). Pour le rendre accessible depuis le réseau, sa documentation explique comment changer l'adresse avec OLLAMA_HOST. Le problème : l'API n'a pas d'authentification intégrée. Des chercheurs en sécurité ont régulièrement trouvé des milliers de serveurs de ce type ouverts sur Internet, que n'importe qui pouvait utiliser.

Ce que j'applique systématiquement :

• Ne jamais exposer le port du serveur d'inférence directement sur Internet.
• Accès à distance uniquement via un VPN ou un tunnel privé, ou derrière un proxy inverse avec authentification.
• Pare-feu qui bloque le port, et attention à Docker : publier un port dans un conteneur peut contourner certaines règles de pare-feu. Liez le port à 127.0.0.1 dans la configuration.
• Mises à jour du logiciel d'inférence : ce sont des logiciels jeunes, des failles sont découvertes et corrigées régulièrement.
• Journalisation des accès, pour détecter un usage anormal (quelqu'un qui consomme votre carte graphique à votre place, par exemple).

Les pièges que je vois le plus souvent

Ma checklist de décision

Avant de recommander une solution, je réponds par écrit à ces questions :

1. Quelles données passent dans l'IA ? Y a-t-il des données personnelles, médicales, financières, du code propriétaire ?
2. Ces données ont-elles le droit de quitter notre infrastructure, et sous quelles conditions (RGPD, loi 09-08, contrat client) ?
3. Quelle qualité est suffisante ? Ai-je testé sur 20 à 30 exemples réels, dans les bonnes langues ?
4. Quel volume par mois, et est-il régulier ou en pics ?
5. Combien coûte l'API à ce volume ? (calcul fait avec des prix datés)
6. Combien coûte le local, matériel, électricité et temps humain compris ?
7. L'IA doit-elle fonctionner hors ligne ?
8. Qui maintient la solution, et a-t-il le temps et les compétences ?
9. La licence du modèle ouvert envisagé autorise-t-elle mon usage ?
10. Si j'ai un serveur, est-il inaccessible depuis Internet sans authentification ?
11. Que se passe-t-il si le fournisseur ou le serveur tombe ?

Quand ces onze réponses sont écrites, la décision est presque toujours évidente.

FAQ

Un modèle local est-il vraiment confidentiel ?

Oui, si le modèle tourne réellement sur votre machine et que le logiciel n'envoie rien ailleurs. Vérifiez deux choses : que vous n'utilisez pas par erreur une version cloud proposée par le même outil, et que votre serveur n'est pas accessible depuis Internet. La confidentialité dépend de toute l'installation, pas seulement du modèle.

Puis-je utiliser une API d'IA avec des données de clients marocains ?

C'est possible, mais pas sans précaution. La loi 09-08 encadre le transfert de données personnelles vers l'étranger et la CNDP en est l'autorité de contrôle. Le plus simple et le plus sûr est souvent d'anonymiser les données avant l'envoi, ou de traiter la partie sensible en local. Pour un projet important, faites valider le montage par un juriste.

Quel ordinateur acheter pour commencer en local ?

Pour tester des modèles de 7 à 9 milliards de paramètres, une machine avec une carte graphique de 8 Go de mémoire vidéo, ou un ordinateur avec au moins 16 Go de mémoire unifiée, est un bon point de départ. Pour des modèles plus grands, la quantité de mémoire est le critère principal, avant la puissance brute. Testez d'abord sur votre machine actuelle avec un petit modèle avant d'acheter quoi que ce soit.

Les modèles ouverts sont-ils aussi bons que les modèles cloud ?

Sur des tâches simples ou moyennes (résumé, classification, extraction, reformulation), les bons modèles ouverts sont souvent suffisants. Sur le raisonnement complexe, le code difficile ou certaines langues, les meilleurs modèles cloud gardent généralement une avance. La seule réponse fiable est un test sur vos propres exemples.

Comment estimer ma facture d'API avant de me lancer ?

Estimez le nombre de requêtes par mois, la taille moyenne du texte envoyé et de la réponse, puis multipliez par les tarifs du modèle choisi. Le calculateur de coût d'API IA fait ce calcul pour vous et compare plusieurs modèles. Ajoutez une marge, car l'usage réel dépasse souvent les estimations.

Un abonnement suffit-il pour une petite entreprise ?

Pour un usage individuel (rédaction, analyse, recherche), oui, c'est souvent le meilleur rapport qualité-prix. Dès que vous voulez intégrer l'IA dans un site, une application ou un processus automatique, il vous faut une API ou un modèle local. Vérifiez aussi que l'offre choisie n'utilise pas vos données pour l'entraînement.

Que faire si mon fournisseur d'API change ses prix ou retire un modèle ?

Concevez votre application pour pouvoir changer de modèle facilement : une seule couche de code qui appelle l'IA, des prompts stockés à part, et un jeu de tests pour vérifier rapidement qu'un nouveau modèle donne des résultats acceptables. C'est aussi un argument pour l'architecture hybride.

---

Vous hésitez entre local, cloud ou hybride pour votre activité ? Je peux auditer vos usages, chiffrer les options et mettre en place une solution sécurisée. Découvrez le service IA et automatisation ou contactez-moi pour en parler.