IA locale ou IA cloud : où doivent tourner vos modèles en 2026 ?

Depuis dix-huit mois, la question revient dans toutes les réunions outillage : faut-il continuer d'envoyer ses documents à une intelligence artificielle hébergée à l'extérieur, ou faire tourner le modèle sur ses propres machines ? En 2026, les deux options fonctionnent réellement — ce n'est plus une question de faisabilité technique, c'est une question d'arbitrage.

Et c'est précisément là que la plupart des entreprises se trompent de débat. Elles comparent des solutions (« tel outil cloud contre tel modèle local ») alors que la décision se prend en amont, sur la donnée. Une entreprise qui commence par classer ce qu'elle manipule obtient sa réponse en une heure. Une entreprise qui commence par comparer des offres y passe six mois et finit par un choix qu'elle devra refaire.

Quelle est la différence entre une IA locale et une IA cloud ?

Une IA cloud : votre texte, votre document ou votre enregistrement quitte votre réseau, part vers l'infrastructure d'un fournisseur, y est traité, et la réponse revient. Vous ne gérez ni le matériel, ni les mises à jour, ni la capacité. Vous payez à l'usage, généralement au jeton (unité de découpage du texte : un mot courant vaut environ 1,3 jeton en français).

Une IA locale : le modèle — ses « poids », c'est-à-dire le fichier de plusieurs gigaoctets qui contient ce qu'il a appris — est copié sur votre machine, votre serveur ou votre réseau. Le traitement se fait sur place. Rien ne sort. Vous payez le matériel une fois, puis l'électricité et l'exploitation.

Un point de vocabulaire coûte cher quand il est mal compris : « open source » et « open weights » ne sont pas synonymes. Un modèle « open weights » publie le fichier des poids, que vous pouvez donc exécuter chez vous, mais pas nécessairement sous une licence permissive, ni avec le code et les données d'entraînement. Un modèle réellement open source publie davantage. Pour l'usage quotidien, ce qui compte est la licence : elle détermine si vous avez le droit de l'utiliser commercialement, et à quelles conditions. C'est un point à vérifier avant l'installation, pas après.

La dernière ligne est celle que les directions techniques sous-estiment le plus. Passer en local ne supprime pas vos obligations de protection des données : cela supprime un maillon — la relation de sous-traitance, son contrat, son audit, sa localisation, ses transferts. Ce maillon en moins, c'est souvent plusieurs semaines de travail juridique évitées.

Que recommande la CNIL pour les données sensibles ?

La CNIL a publié en 2025 et 2026 plusieurs séries de recommandations sur le développement et le déploiement des systèmes d'IA, complétées en juillet 2026 par un document dédié à l'IA agentique. Sa position sur le mode d'hébergement est explicite lorsqu'il s'agit de fournir au système des données personnelles de clients ou de salariés, ou une documentation sensible ou stratégique.

Il est généralement plus approprié et plus sûr de privilégier les solutions de déploiement « sur site » (on premise), qui ont l'avantage de limiter les risques d'extraction des données par des tiers. — CNIL, questions-réponses sur l'utilisation d'un système d'IA générative

La CNIL ajoute immédiatement la nuance qui rend l'avis utilisable : compte tenu du coût d'installation et d'exploitation d'un système sur site, il est souvent plus simple de recourir à un système hébergé à distance — mais il faut alors sécuriser cet usage par un contrat de sous-traitance avec l'hébergeur et, le cas échéant, avec le fournisseur du système d'IA.

Autrement dit : l'autorité ne dit pas « le cloud est interdit ». Elle dit que le local supprime un risque, que le cloud le rend gérable au prix d'un encadrement contractuel, et que le choix dépend de ce que vous mettez dedans. C'est exactement l'inverse du raisonnement habituel, qui part de l'outil et cherche ensuite à le rendre conforme.

Quelles données ne doivent jamais quitter votre réseau ?

Voici la grille qui remplace utilement le débat d'architecture. Elle se remplit avec les documents réels de l'entreprise, pas avec des catégories théoriques. En pratique, une PME met une heure à la remplir et découvre presque toujours que la part réellement sensible est plus petite qu'elle ne le croyait — mais qu'elle est concentrée dans les usages les plus fréquents.

Le niveau 4 mérite un développement, parce qu'il ne relève pas de la préférence technique. Pour un avocat, un médecin, un courtier en assurance ou un expert-comptable, la question n'est pas « le fournisseur est-il sérieux ». Elle est : en cas de contestation, pouvez-vous démontrer qu'aucun tiers n'a eu accès au dossier ? Avec un traitement effectué intégralement sur le poste de travail, la démonstration est structurelle : la donnée n'a pas de trajet à documenter. Avec un traitement externalisé, il faut produire un contrat, une politique de conservation, une cartographie des sous-traitants — c'est faisable, mais c'est un travail permanent.

C'est la raison pour laquelle des outils métiers entièrement locaux se sont développés précisément sur ces professions : onKall, par exemple, traite le rendez-vous d'un courtier ou d'un professionnel de santé directement sur le poste, sans que l'enregistrement ni le compte rendu ne partent vers un service tiers. Ce n'est pas un argument de performance, c'est un argument de charge de preuve.

À partir de quel volume l'IA locale devient-elle moins chère ?

C'est la question posée le plus souvent — et celle dont la réponse déçoit le plus, parce qu'elle contredit l'intuition. L'IA locale n'est pas « gratuite après l'achat ». Elle déplace une dépense variable vers une dépense fixe. Le point de bascule dépend donc d'un seul paramètre : le volume réellement traité, pas le nombre d'utilisateurs déclarés.

L'erreur classique consiste à raisonner en licences. Dix salariés à qui l'on ouvre un accès, ce n'est pas dix fois le volume d'un salarié : dans la plupart des organisations, deux ou trois personnes concentrent l'essentiel des usages, et le reste du parc consomme des miettes. Avant tout arbitrage, il faut donc mesurer, pas estimer.

La ligne à retenir est la dernière. Pour les données de niveau 4, le calcul économique ne s'applique pas : on ne met pas en balance le coût d'un serveur et une obligation de secret. Pour les niveaux 1 et 2, le calcul est presque toujours favorable au cloud. Le vrai débat ne porte donc que sur le niveau 3 — et il est plus étroit qu'on ne le pense.

Que perd-on réellement en passant en local ?

Trois choses, et il vaut mieux les accepter d'avance que les découvrir en production.

Un peu de niveau. Les modèles exécutables localement restent en retrait des modèles les plus avancés accessibles en ligne. L'écart s'est considérablement réduit et se compte désormais en mois plutôt qu'en générations, mais il existe. Sur des tâches de reformulation, de classement, d'extraction ou de synthèse, il est aujourd'hui imperceptible pour l'utilisateur. Sur du raisonnement long, de la programmation complexe ou de l'analyse fine, il se voit encore.

La mise à jour permanente. Un service en ligne évolue sans vous. Un modèle local reste figé jusqu'à ce que quelqu'un décide de le remplacer. Ce n'est pas un défaut — c'est même un avantage en environnement réglementé, où la stabilité du comportement est une exigence — mais cela suppose d'inscrire au calendrier une revue annuelle. Sans cette revue, une installation locale vieillit en silence.

L'élasticité. Le cloud absorbe un pic sans prévenir. Une machine locale a une capacité fixe : si dix personnes lancent un traitement lourd en même temps, elles attendent. C'est le même raisonnement de dimensionnement que pour la téléphonie automatisée, où le nombre d'appels simultanés qu'un agent vocal peut absorber dépend d'un goulot bien précis, rarement celui qu'on imagine.

Comment construire une architecture hybride en 2026 ?

L'hybride n'est pas un compromis mou : c'est la conséquence directe de la grille du chapitre 3. Puisque toutes les données ne sont pas de même niveau, il n'y a aucune raison de leur imposer le même traitement.

1. Classez vos usages, pas vos outils. Listez les dix tâches où l'IA est réellement utilisée dans l'entreprise, et affectez à chacune un niveau de 1 à 4. Dix lignes suffisent.
2. Envoyez les niveaux 1 et 2 vers le cloud, avec un contrat de sous-traitance en règle et une politique claire sur la réutilisation éventuelle des contenus pour l'entraînement.
3. Traitez les niveaux 3 et 4 en local, en commençant par l'usage le plus fréquent — pas par le plus impressionnant.
4. Écrivez la règle et diffusez-la. Sans règle explicite, les salariés arbitrent seuls, et ce qui se met en place s'appelle du shadow AI : des usages hors cadre, invisibles, impossibles à sécuriser après coup.
5. Datez la revue. Une décision d'hébergement prise en 2026 doit être réexaminée en 2027 : le rapport de force entre modèles locaux et modèles distants bouge vite.

Un dernier point, souvent décisif dans les PME : commencer par le local sur un usage bien choisi coûte beaucoup moins cher qu'un projet d'architecture global. Le compte rendu de réunion, la relecture de documents contractuels, l'extraction d'informations dans des dossiers clients : ce sont des usages étroits, mesurables, et qui touchent précisément les données que vous ne voulez pas voir sortir. C'est le meilleur terrain d'apprentissage — et le seul dont le retour se constate en quelques semaines.