Limites des modèles IA locaux : d'Ollama à Claude

J'écris sur l'IA depuis début 2023. Au fil du temps, j'ai vu cette technologie transformer ma façon de coder, de penser le contenu, et d'envisager l'avenir du travail.

Ceci est l'histoire d'un pas de plus — de l'utilisation de l'IA comme outil à la tentative de construire quelque chose d'autonome par-dessus. Ça ne s'est pas passé comme prévu.

POURQUOI J'AI ESSAYÉ DE FAIRE TOURNER L'IA EN LOCAL

Avant d'avoir une vraie expérience en la matière, l'IA locale me semblait être le choix le plus intéressant. Pas seulement pour la flexibilité ou la sécurité — même si les deux comptaient — mais parce que ça me paraissait être l'approche la plus honnête de la technologie.

Au milieu de tout ce qui se passe autour de l'IA, faire tourner un modèle en local, le configurer, le connecter à des données, et voir où il casse — ça semblait fondamentalement différent d'utiliser une interface cloud bien finie. C'était la différence entre utiliser un outil et comprendre comment cet outil fonctionne réellement.

En même temps, ce n'était pas une expérience purement technique. J'avais un cas d'usage précis en tête dès le départ.

Le premier domaine où je voulais l'appliquer, c'était le SEO. Le SEO est une discipline documentée, relativement exacte. Il a une structure, des règles, des patterns et des résultats mesurables. En théorie, c'est idéal pour l'automatisation. Un agent peut scanner des centaines de sous-pages en quelques minutes, identifier des problèmes structurels, détecter des éléments manquants, et s'il a aussi accès aux données de tendances de recherche, il peut produire des recommandations de contenu pertinentes.

Ce n'est pas une idée abstraite. C'est un workflow réel avec une valeur business claire.

La vision plus large était plus ambitieuse. Je voulais construire un agent qui récupère des données à partir d'automatisations configurées, propose des étapes en fonction de ce qu'il trouve, envoie ces propositions quelque part pour révision, et à travers cette boucle de feedback, s'améliore progressivement. À un certain stade, une fois que ses propositions correspondent systématiquement à ce que je considère comme de bonnes décisions, il commencerait à exécuter ces actions de manière autonome.

Pas juste assister. Agir.

C'était l'objectif.

MAC MINI, OLLAMA, N8N

L'installation en elle-même était simple. J'ai utilisé un Mac Mini, fait tourner un modèle local via Ollama, et géré l'orchestration de base avec n8n.

Faire fonctionner Ollama a été étonnamment simple. Bien plus simple que ce que j'imaginais. En peu de temps, j'avais un modèle actif, qui répondait, et se comportait comme un chatbot. D'un point de vue purement technique, la barrière à l'entrée était basse.

En quelques heures, j'avais un pipeline basique en place. Le modèle était capable de récupérer des données, de faire une analyse marketing basique, et j'avais un chemin clair vers l'automatisation d'alertes dans Slack en fonction de la sortie. À ce stade, tout semblait prometteur. Le système fonctionnait, et il fonctionnait en local.

Ce que je ne comprenais pas encore pleinement, c'est à quelle vitesse j'allais toucher ses limites.

Puis j'ai testé sur des données représentatives conçues pour simuler des conditions réelles.

LA FENÊTRE DE CONTEXTE

C'est là que la vraie limitation est devenue évidente.

Le modèle pouvait gérer quelques pages de texte. Il pouvait traiter un petit tableau, ou un jeu de données de quelques kilo-octets. Dans cette plage, il se comportait de manière apparemment fonctionnelle.

Mais au moment où je lui ai donné des données SEO représentatives — le volume qu'il faut réellement analyser pour produire un résultat significatif — le système s'est effondré.

Il traitait ce qui rentrait dans sa fenêtre de contexte et ignorait le reste. Il produisait une sortie qui, en surface, semblait structurée, mais quand on regardait de plus près, elle n'avait presque aucune valeur. Il captait un chiffre quelque part dans les données et le répétait. Il ne combinait pas les signaux. Il ne priorisait pas correctement. Il ne comprenait pas les relations à travers le jeu de données.

Et la raison était simple. Il ne pouvait pas en voir assez.

Je l'ai remarqué immédiatement lors de la première vraie analyse. La qualité de la sortie était à peu près comparable à ce que les modèles cloud produisaient en 2023. Ce n'est pas une critique du modèle en soi. C'est un reflet des contraintes.

Le problème n'était pas la configuration. Ce n'était pas le prompting. Ce n'était pas un manque d'effort.

Le matériel déterminait quel modèle je pouvais faire tourner. Et le modèle que je pouvais faire tourner ne pouvait tout simplement pas contenir la quantité d'information requise pour la tâche.

CE QUE « AUTONOME » SIGNIFIE RÉELLEMENT

À ce stade, il est devenu clair ce que « autonome » exige réellement en pratique — et où le système échouait.

Un agent autonome n'est pas juste une boucle qui appelle un modèle de manière répétée. Il nécessite la capacité de raisonner sur une grande quantité de contexte, de maintenir la cohérence à travers plusieurs étapes, et de produire des résultats suffisamment précis pour agir dessus sans supervision constante.

Cela signifie qu'il doit retenir non seulement l'entrée courante, mais l'état accumulé de l'ensemble du workflow. Quelles données ont été récupérées, quelles actions ont été proposées, quelles décisions ont été prises, ce qui a échoué, ce qui a réussi, et quel est l'objectif global.

C'est là que la limitation devient structurelle.

Un modèle avec une fenêtre de contexte contrainte ne peut pas maintenir cet état. Il ne peut pas connecter les décisions dans le temps. Il ne peut pas évaluer ses propres productions de manière significative parce qu'il manque de visibilité sur l'ensemble du processus.

La vision du système n'était pas le problème.

L'infrastructure en dessous l'était.

LE PASSAGE À CLAUDE CODE

À ce stade, je suis passé à une solution cloud et j'ai commencé à travailler avec Claude Code d'Anthropic.