Ollama et l’enshittification – les premiers signes
Ma vision de l’état actuel du développement d’Ollama
Ollama est rapidement devenu l’un des outils les plus populaires pour exécuter des LLM localement. Son CLI simple et sa gestion de modèles optimisée en ont fait une option incontournable pour les développeurs souhaitant travailler avec des modèles d’IA en dehors du cloud.
Si vous comparez Ollama à d’autres options locales ou cloud, consultez Hébergement de LLM : Infrastructure locale, auto-hébergée et cloud comparée. Mais comme pour de nombreuses plateformes prometteuses, les signes d’une Enshittification sont déjà visibles :
- le processus progressif par lequel un logiciel ou un service se dégrade au fil du temps, les intérêts des utilisateurs étant progressivement subordonnés aux priorités commerciales, architecturales ou internes.
Dans cet article, j’explorerai les tendances récentes et les plaintes des utilisateurs concernant Ollama qui indiquent cette dérive, et pourquoi elles sont importantes pour son avenir.
Pour les détails des commandes et paramètres Ollama les plus fréquents - veuillez consulter l’Aide-mémoire Ollama.
Pour des interfaces utilisateur utiles pour Ollama, consultez - Interfaces de chat open source pour LLM sur instances locales Ollama
Démarrage automatique et contrôle en arrière-plan
L’un des problèmes les plus clairs signalés par les utilisateurs est le démarrage automatique d’Ollama au boot du système — en particulier sur Windows.
- Il n’existe aucun paramètre clair pour désactiver ce comportement.
- Même si vous le désactivez manuellement, les mises à jour ou les réinstallations peuvent réactiver silencieusement le démarrage.
- Sur macOS, l’application de bureau se lance également par défaut à la connexion, à moins que vous n’installiez spécifiquement la variante CLI uniquement.
Ce schéma — un logiciel s’insérant dans votre routine de démarrage sans consentement explicite — est un signal d’alarme classique. Il érode la confiance des utilisateurs et crée des frictions pour ceux qui valorisent le contrôle de leur système.
Préoccupations concernant la télémétrie et la collecte de données
Un autre problème récurrent est le comportement réseau d’Ollama. Les utilisateurs ont remarqué du trafic sortant même lorsque toutes les opérations devraient être locales. Les mainteneurs ont déclaré que cela est lié aux vérifications de mise à jour, et non aux entrées des utilisateurs — mais il n’y a pas d’option simple pour ceux qui veulent une expérience strictement hors ligne.
Pour une plateforme qui se présente comme un outil local, axé sur la confidentialité, ce manque de clarté suscite des doutes. La transparence et les options de désactivation sont essentielles si Ollama veut maintenir sa crédibilité.
Rétrocessions de performance avec le nouveau moteur
Les dernières mises à jour ont introduit un nouveau moteur d’inférence, mais au lieu d’améliorations de performance, certains utilisateurs ont signalé l’effet inverse :
- La génération de jetons est jusqu’à 10 fois plus lente dans certains scénarios.
- L’utilisation du GPU est incohérente par rapport au moteur précédent.
- Les grands modèles comme Qwen3:30B fonctionnent désormais de manière nettement moins bien, avec une latence plus élevée et un débit plus faible.
Ce changement soulève des inquiétudes quant aux priorités. Si les mises à jour rendent les modèles moins utilisables sur du matériel réel, les développeurs peuvent se sentir obligés de mettre à niveau leur matériel ou d’accepter des performances dégradées — une autre manière subtile dont l’expérience utilisateur est dépriorisée.
Risques de sécurité liés aux instances mal configurées
Les chercheurs en sécurité ont découvert des serveurs Ollama exposés fonctionnant sans authentification. Des vulnérabilités telles que la traversée de chemin et les vecteurs de déni de service ont été divulgués, certaines ayant été corrigées et d’autres faisant l’objet de débats.
Bien qu’une grande partie de cela retombe sur les utilisateurs qui malconfigurent leurs déploiements, le manque de valeurs par défaut sécurisées augmente le risque. La responsabilité d’une plateforme inclut le fait de rendre le chemin sûr le chemin facile.
Turbo : Monétisation et changements de modèle économique
Le lancement de Ollama Turbo — un service d’accélération cloud — a représenté un moment charnière. La différenciation originale d’Ollama était son accent sur le contrôle local, la confidentialité et la distribution open source. Turbo, cependant, introduit une dépendance aux propres infrastructures d’Ollama.
- L’utilisation de Turbo nécessite une connexion, s’éloignant de l’expérience locale sans friction.
- Des fonctionnalités clés de l’application Mac dépendent désormais des serveurs d’Ollama, soulevant des inquiétudes quant à la quantité de fonctionnalités pouvant rester utilisables hors ligne.
- Les discussions sur Hacker News ont qualifié cela de début de l’enshittification, avertissant que la commercialisation pourrait éventuellement introduire des murs payants pour des capacités actuellement gratuites.
Cela ne signifie pas qu’Ollama a abandonné ses principes — Turbo peut être précieux pour les utilisateurs qui veulent une inférence plus rapide sans acheter du nouveau matériel. Mais l’apparence compte : une fois qu’un outil axé sur le local nécessite des services centralisés pour “la meilleure” expérience, il risque de diluer les qualités mêmes qui le distinguaient d’OpenAI ou d’Anthropic en premier lieu.
Si la dérive cloud-first de Turbo est le facteur décisif pour vous, llama-server est l’alternative sans upsell hébergé à craindre — consultez llama.cpp vs Ollama en 2026 pour savoir ce que vous gagnez et perdez en transférant le catalogue de modèles et l’ordonnanceur hors des mains d’Ollama.
Le schéma : Contrôle utilisateur vs. Valeurs par défaut du fournisseur
Individuellement, ces problèmes peuvent sembler mineurs. Ensemble, ils suggèrent un schéma :
- Le comportement de démarrage est activé par défaut, et non désactivé.
- Les vérifications de mise à jour se font automatiquement, et non sur option.
- Les changements de performance servent de nouveaux objectifs architecturaux, même s’ils dégradent l’utilisabilité actuelle.
- La monétisation introduit désormais une dépendance serveur, et non seulement des binaires locaux.
C’est ainsi que l’enshittification commence — non par un mouvement hostile unique, mais par une série de petits changements qui échangent subtilement le contrôle utilisateur contre la commodité du fournisseur ou les revenus.
Ce qui ne s’est pas encore produit
Pour être juste, Ollama n’a pas encore franchi le pas vers les territoires les plus graves :
- Aucune publicité ou promotion dans l’interface utilisateur.
- Aucun mur payant agressif limitant la fonctionnalité locale de base.
- Aucun verrouillage dur autour de formats propriétaires ; les modèles communautaires restent accessibles.
Cela dit, la vigilance est de mise. Le passage d’« un outil qui respecte votre contrôle » à « un outil qui fait ce que le fournisseur veut par défaut » se produit souvent progressivement.
Conclusion
Ollama reste l’un des meilleurs moyens d’exécuter de grands modèles localement. Pour voir comment Ollama se positionne parmi les autres options de LLM locales, auto-hébergées et cloud, consultez notre article Hébergement de LLM : Infrastructure locale, auto-hébergée et cloud comparée.
Mais les premiers signes sont clairs : le comportement de démarrage automatique, l’opacité de la télémétrie, les rétrocessions de performance, les valeurs par défaut non sécurisées et la dérive cloud-first de Turbo indiquent tous un lent éloignement de l’éthos original de l’outil.
Pour que Ollama reste fidèle à sa promesse, les mainteneurs doivent prioriser la transparence, la conception sur option, et les principes axés sur le local. Sinon, la plateforme risque de miner les valeurs mêmes qui l’avaient rendue attractive au départ. Mais je retiens mon souffle.
