Avenir de l'IA locale : est-elle vraiment en train de mourir ?

Il y a quelque chose d’étrange avec l’IA locale.

Alors qu’il n’a jamais été aussi simple de lancer un modèle sur son PC, de plus en plus de développeurs affirment que cette idée est déjà condamnée.

Et ils ont des arguments solides : la VRAM, l’énergie, des modèles toujours plus gros, et un cloud toujours plus puissant.

Sur le papier, le verdict semble joué.

Sauf qu’un détail, presque invisible, change complètement l’histoire.

Et il pourrait décider de la façon dont on utilisera l’IA demain.

Alors, l’IA locale est-elle vraiment en train de mourir…

ou est-ce qu’on regarde simplement mourir la mauvaise chose ?

La fin du rêve de Jarvis

Pendant des années, l'objectif était assez clair : construire un Jarvis personnel.

On partait d'un modèle de langage. On ajoutait de la reconnaissance vocale, de la synthèse vocale, une mémoire à long terme, du RAG, des outils capables de manipuler le système, puis des agents capables de raisonner et d'agir.

Sur le papier, c'est séduisant. On imagine une IA qui tourne en permanence, surveille le contexte, comprend ce qui se passe sur la machine, anticipe les besoins et exécute des tâches toute seule.

Le problème, c'est que cette approche devient vite très lourde.

Un agent qui réfléchit en continu consomme du calcul. S'il doit aussi analyser l'écran, lire des fichiers, maintenir une mémoire, interroger plusieurs outils et décider régulièrement s'il doit agir, la charge augmente encore.

Sur une machine personnelle, on finit rapidement par mobiliser une grosse partie du CPU, du GPU et de la mémoire pour un assistant dont la majorité du temps consiste simplement à attendre qu'un événement intéressant se produise.

Et c'est là que le modèle économique et technique commence à casser.

Faire tourner un gros modèle en permanence est coûteux en énergie. Le GPU n'est plus disponible pour autre chose. La machine chauffe. La consommation augmente. Et si l'on bascule une partie du calcul sur le CPU pour économiser la VRAM, les performances peuvent chuter fortement.

Le résultat est assez logique : beaucoup de projets évoluent vers des assistants plus limités.

Au lieu d'un Jarvis qui fait tout, on obtient un assistant pour écrire, un autre pour coder, un autre pour classer des documents, un autre pour automatiser une tâche précise.

Autrement dit, le rêve de la conscience numérique qui tourne vingt-quatre heures sur vingt-quatre sur un vieux PC est probablement en train de s'effacer.

Mais ce n'est pas la mort de l'IA locale. C'est la fin d'une architecture trop ambitieuse.

De l'agent isolé à l'infrastructure complète

En parallèle, le marché professionnel prend exactement la direction inverse.

Créer un petit agent est devenu relativement simple. On prend un modèle, on lui donne un prompt système, quelques outils, et on peut déjà automatiser une tâche.

La valeur n'est donc plus forcément dans l'agent lui-même.

Elle est dans l'infrastructure autour.

C'est là qu'apparaissent des outils d'orchestration comme n8n, CrewAI, AutoGen ou Agent Zero. Leur rôle n'est pas simplement de lancer un modèle. Ils permettent de coordonner plusieurs étapes, plusieurs modèles et plusieurs outils.

Un modèle peut lire un document. Un autre peut extraire des informations. Un troisième peut vérifier le résultat. Un workflow peut ensuite envoyer ces données vers une base, un ERP ou une application interne.

Le changement est important.

On ne vend plus seulement un chatbot. On construit une chaîne de production automatisée.

Dans cette logique, l'utilisateur ne dialogue pas forcément avec l'IA. Il supervise un système qui travaille en arrière-plan.

Et c'est précisément un domaine où l'IA locale reste très intéressante.

Une entreprise peut conserver ses données sur ses propres serveurs, utiliser plusieurs modèles spécialisés, et ne faire appel au cloud que lorsque c'est réellement nécessaire.

Le vrai mur : la mémoire

Le principal problème de l'IA locale reste matériel.

Et le point critique, ce n'est pas seulement la puissance de calcul. C'est la mémoire.

Pour obtenir de bonnes performances, il faut idéalement charger la plus grande partie possible du modèle dans la mémoire accessible rapidement par l'accélérateur, en pratique la VRAM d'un GPU ou la mémoire unifiée sur certaines architectures.

Un petit modèle de 7 à 9 milliards de paramètres peut déjà demander autour de 8 Go de VRAM selon la quantification, le contexte et le moteur utilisé.

Pour monter vers des modèles de plusieurs dizaines de milliards de paramètres, 16 ou 24 Go deviennent rapidement beaucoup plus confortables.

Et dès qu'on augmente fortement la fenêtre de contexte, la consommation mémoire grimpe encore.

C'est un point souvent sous-estimé.

La fenêtre de contexte, c'est la quantité d'informations que le modèle peut garder disponibles pendant une requête. Si on lui donne un gros document, beaucoup de code, plusieurs conversations ou une longue mémoire, il faut stocker davantage de données intermédiaires.

Donc même lorsqu'un modèle tient théoriquement dans la VRAM, une grosse fenêtre de contexte peut provoquer un dépassement de mémoire.

Bien sûr, on peut déporter une partie du modèle vers la RAM système.

Des moteurs comme llama.cpp savent très bien répartir le travail entre GPU et CPU.

Mais on paie cette flexibilité en performances. Plus on sort du GPU, plus l'inférence peut ralentir.

C'est pour cette raison qu'on peut grossièrement distinguer plusieurs niveaux de machines.

Un PC bureautique sans GPU dédié peut exécuter de petits modèles, mais il sera vite limité pour les usages lourds.

Une machine avec 8 à 12 Go de VRAM peut déjà faire tourner correctement de nombreux modèles compacts et quantifiés.

Avec 16 à 24 Go de VRAM, on entre dans une catégorie beaucoup plus intéressante pour le code, le RAG, les modèles intermédiaires et certains usages multimodaux.

Et avec 24 Go, plusieurs GPU ou de grosses architectures à mémoire unifiée, on passe dans le domaine de la station de travail spécialisée.

L'IA locale n'est donc pas impossible. Mais elle crée une nouvelle fracture matérielle.

Tout le monde peut lancer un petit modèle. Beaucoup moins de monde peut lancer confortablement un modèle très puissant avec une grosse fenêtre de contexte.

Le cas particulier de la mémoire unifiée

Les architectures à mémoire unifiée apportent une réponse intéressante à ce problème.

Sur les machines Apple Silicon, par exemple, le CPU et le GPU peuvent partager un même grand espace mémoire.

Cela permet d'utiliser des configurations de 32, 64, 128 Go ou davantage sans avoir besoin d'une carte graphique équipée d'autant de VRAM dédiée.

Pour certains gros modèles, c'est un avantage très important.

Cela ne veut pas dire qu'un Mac remplace systématiquement une grosse carte NVIDIA. Les performances dépendent énormément du modèle, du moteur et du type de calcul.

Mais pour charger de très gros modèles localement, la quantité de mémoire disponible devient parfois plus importante que la puissance brute.

C'est probablement une direction que l'on verra de plus en plus : des machines conçues non plus seulement autour du CPU et du GPU, mais autour de la quantité de mémoire réellement exploitable par l'IA.

La quantification change complètement l'équation

Si l'IA locale reste viable malgré ces contraintes, c'est en grande partie grâce à la quantification.

Un modèle est normalement entraîné avec une précision numérique relativement élevée. Cela donne de gros fichiers et une consommation mémoire importante.

La quantification réduit la précision utilisée pour stocker les poids.

On peut par exemple passer d'un modèle en 16 bits à du 8 bits, du 6 bits ou du 4 bits.

Le modèle devient beaucoup plus léger.

C'est ce mécanisme qui permet aujourd'hui de faire tourner sur un PC des modèles qui auraient autrefois demandé des dizaines de gigaoctets de mémoire supplémentaires.

Le compromis, c'est qu'en compressant trop fortement, on peut perdre en qualité.

Mais entre un modèle impossible à charger et une version quantifiée légèrement moins précise, le choix est vite fait.

Des formats comme GGUF ont aussi simplifié énormément l'écosystème.

Avec llama.cpp, Ollama ou LM Studio, on peut télécharger un modèle, choisir une version adaptée à sa mémoire disponible et le lancer sans devoir reconstruire toute une chaîne Python.

C'est un changement majeur.

Il y a quelques années, lancer correctement un modèle local demandait des connaissances assez solides.

Aujourd'hui, on peut installer Ollama ou LM Studio, télécharger un modèle et obtenir une API locale en quelques minutes.

Cette API est souvent compatible avec les formats utilisés par les applications qui parlent déjà aux services cloud.

Et ça, c'est très important.

Une application peut être développée pour utiliser une API de type OpenAI, puis être redirigée vers un modèle local sans réécrire toute son architecture.

L'IA locale devient alors un composant remplaçable dans une infrastructure plus large.

L'IA locale devient invisible

Il y a aussi une autre raison pour laquelle on peut avoir l'impression que l'IA locale disparaît : on la voit de moins en moins.

Au début, l'IA était essentiellement un chatbot.

On ouvrait une fenêtre, on écrivait une question, et le modèle répondait.

Mais l'IA commence à se déplacer derrière les interfaces.

Dans un éditeur de code, elle peut proposer une complétion sans ouvrir de chat.

Dans un logiciel métier, elle peut classer automatiquement des documents.

Dans un système de messagerie, elle peut résumer ou catégoriser des messages.

Dans un outil de saisie, elle peut proposer la suite d'une phrase.

Dans tous ces cas, l'utilisateur n'a pas forcément conscience qu'un modèle local tourne en arrière-plan.

L'IA n'est plus l'application. Elle devient une fonction de l'application.

Et cette évolution favorise les petits modèles spécialisés.

On n'a pas toujours besoin d'un modèle géant pour détecter une intention, résumer un texte, corriger une phrase, classer un document ou extraire quelques champs.

Un petit modèle rapide et local peut parfois être plus logique qu'un énorme modèle cloud.

Le RAG reste l'un des meilleurs cas d'usage

Le RAG, ou Retrieval-Augmented Generation, est probablement l'un des cas d'usage les plus naturels pour l'IA locale.

Le principe est simple.

Au lieu de demander au modèle de tout connaître, on lui fournit uniquement les documents utiles au moment de la question.

Le système recherche les passages pertinents dans une base documentaire, puis les injecte dans le contexte du modèle.

Cela permet d'utiliser un modèle relativement compact avec des informations très spécialisées.

Une entreprise peut ainsi connecter son IA à ses contrats, sa documentation technique, ses procédures internes ou sa base de code.

Le modèle n'a pas besoin de contenir toute cette connaissance dans ses poids.

Il va la chercher au moment où il en a besoin.

Le RAG ne supprime pas magiquement les hallucinations. Il peut cependant les réduire fortement si la recherche est bonne, si les documents sont fiables et si le système oblige le modèle à s'appuyer sur les sources récupérées.

Et surtout, tout cela peut fonctionner sur une infrastructure privée.

Pour beaucoup d'entreprises, c'est là que l'IA locale prend tout son sens.

La souveraineté devient un argument central

Pour un particulier, l'IA locale peut être un choix technique ou philosophique.

Pour une entreprise, elle peut devenir un choix de sécurité.

Envoyer un texte dans un service cloud signifie que les données sortent du système local et passent par l'infrastructure d'un fournisseur.

Les conditions de conservation, d'utilisation et de traitement dépendent alors du service choisi et du contrat associé.

Pour des données banales, ce n'est pas forcément un problème.

Pour du code propriétaire, des contrats, des dossiers clients, des informations de santé ou des secrets industriels, la question change complètement.

Une architecture locale permet de garder les données dans le périmètre contrôlé par l'organisation.

Cela simplifie certains scénarios de conformité et réduit le nombre d'acteurs qui manipulent les informations sensibles.

En Europe, le RGPD renforce évidemment cette réflexion.

Il faut aussi tenir compte des contraintes juridiques liées aux fournisseurs étrangers, aux transferts de données et aux obligations spécifiques de certains métiers.

Pour un avocat, un médecin, un expert-comptable ou une entreprise qui travaille sur de la propriété intellectuelle sensible, la question n'est pas seulement : quel modèle répond le mieux ?

La question devient : où part ma donnée, qui peut y accéder, combien de temps est-elle conservée, et sous quelle juridiction ?

Dans ce contexte, l'IA locale possède un avantage structurel.

Le coût : cloud contre investissement matériel

L'économie est un autre facteur important.

Le cloud est extrêmement pratique parce qu'on paie à l'usage.

Pour quelques requêtes par jour, c'est souvent imbattable.

On n'achète pas de GPU. On ne gère pas de serveur. On ne paie que ce que l'on consomme.

Mais lorsque l'usage devient massif et permanent, l'équation change.

Une entreprise qui traite énormément de documents ou qui fait tourner des agents toute la journée peut générer une facture API importante.

À ce moment-là, acheter une machine devient comparable à l'achat d'un outil de production.

Le matériel coûte cher au départ. Ensuite, chaque requête supplémentaire ne génère plus une facture de fournisseur au token.

Évidemment, le coût n'est jamais réellement nul.

Il reste l'électricité, l'administration, la maintenance, le refroidissement, les pannes et le renouvellement du matériel.

Mais le profil économique devient différent.

Le cloud transforme le calcul en dépense variable.

Le local transforme une partie de cette dépense en investissement fixe.

À faible volume, le cloud gagne souvent.

À très gros volume, le local peut devenir intéressant.

Et dans beaucoup de cas, la meilleure solution sera simplement de combiner les deux.

Les risques de l'IA locale

Il ne faut pas non plus présenter l'IA locale comme une solution parfaite.

Donner des outils à un modèle crée de nouveaux risques.

Un chatbot qui répond à une question est relativement limité.

Un agent qui peut écrire des fichiers, lancer des commandes, accéder à des bases de données ou envoyer des messages possède beaucoup plus de pouvoir.

Si cet agent est mal configuré, une mauvaise instruction peut avoir de vraies conséquences.

C'est pour cela que les principes classiques de sécurité restent essentiels.

Moindre privilège.

Isolation.

Conteneurs.

Validation humaine pour les actions critiques.

Journalisation.

Séparation entre les données sensibles et les outils accessibles.

Docker peut aider à isoler certains environnements, mais il ne remplace pas une vraie politique de sécurité.

Et plus on donne d'autonomie aux agents, plus cette architecture devient importante.

Il existe aussi des risques liés aux données elles-mêmes.

Un système RAG peut être trompé par un document malveillant.

Un modèle peut suivre une instruction cachée dans un fichier.

Une base documentaire peut être polluée.

Et un agent autonome peut amplifier une erreur beaucoup plus vite qu'un utilisateur humain.

L'IA locale ne retire donc pas le risque. Elle déplace une partie de la responsabilité vers celui qui exploite l'infrastructure.

Il existe enfin une question plus large : celle de notre dépendance cognitive à l'IA.

Plus les assistants deviennent intégrés et personnalisés, plus la tentation est grande de leur déléguer des tâches de réflexion.

Le problème n'est pas d'utiliser une IA pour gagner du temps.

Le problème commence lorsque l'on n'est plus capable de vérifier ce qu'elle produit.

Une IA locale peut être privée, rapide et autonome. Elle peut quand même se tromper.

La confidentialité ne garantit pas la vérité.

L'avenir sera probablement hybride

C'est probablement le point le plus important.

Opposer totalement l'IA locale et l'IA cloud n'a plus beaucoup de sens.

Les deux ont des avantages différents.

Le local est intéressant pour la confidentialité, la faible latence, le fonctionnement hors ligne, les petits traitements répétitifs et les données sensibles.

Le cloud reste très efficace pour accéder aux modèles les plus puissants, aux grosses capacités de raisonnement et à une infrastructure que l'utilisateur n'a pas besoin de gérer.

L'étape suivante est donc le routage intelligent.

Un petit modèle local peut analyser une requête et décider où elle doit être traitée.

Une demande simple et sensible reste sur la machine.

Une tâche plus complexe peut être envoyée vers un modèle cloud.

Avant l'envoi, le système peut retirer ou pseudonymiser certaines informations.

On obtient alors une architecture où le local devient le premier niveau de traitement et le cloud une ressource spécialisée appelée uniquement lorsque c'est nécessaire.

C'est probablement beaucoup plus réaliste que l'idée d'un ordinateur personnel capable de remplacer tous les modèles géants du cloud.

Et c'est aussi plus efficace.

Pourquoi utiliser un modèle gigantesque pour résumer un e-mail, classer un fichier ou corriger une phrase si un petit modèle local peut le faire immédiatement ?

À l'inverse, pourquoi forcer un petit modèle à résoudre un problème complexe s'il existe un modèle cloud beaucoup plus compétent pour cette tâche ?

Le futur n'est pas local contre cloud.

Le futur, c'est local plus cloud, avec un orchestrateur qui choisit le bon outil.

Conclusion

L'IA locale ne me paraît donc pas condamnée.

En revanche, une certaine vision de l'IA locale est clairement en train de disparaître.

Le modèle du Jarvis universel, gratuit, illimité et toujours actif sur un PC grand public se heurte à des contraintes très concrètes : la mémoire, l'énergie, le coût du matériel et la complexité de l'orchestration.

Mais en parallèle, l'IA locale devient beaucoup plus crédible là où elle apporte un avantage réel.

Les petits modèles intégrés directement dans les logiciels.

Le RAG sur des données privées.

Les assistants de code.

Les traitements hors ligne.

Les automatisations internes.

Les infrastructures d'entreprise qui ne veulent pas envoyer leurs données sensibles vers un fournisseur externe.

Et surtout, les architectures hybrides capables d'utiliser le local pour ce qu'il fait bien, puis le cloud uniquement lorsque sa puissance est nécessaire.

Donc non, l'IA locale n'est probablement pas en train de mourir.

Elle est en train de sortir de sa phase de démonstration.

Elle devient moins spectaculaire, mais beaucoup plus utile.

Et paradoxalement, c'est peut-être justement le signe qu'elle commence à devenir mature.