L'Enshittification d'Ollama - 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 interface CLI simple et sa gestion des modèles optimisée l’ont rendu l’option de prédilection 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 en cloud, consultez LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared. Mais comme c’est souvent le cas avec de nombreuses plateformes prometteuses, des signes d’Enshittification apparaissent déjà :
- le processus progressif par lequel un logiciel ou un service se dégrade au fil du temps, alors que les intérêts des utilisateurs sont progressivement subordonnés aux priorités commerciales, architecturales ou internes.
Dans cet article, je vais explorer les tendances récentes et les plaintes des utilisateurs concernant Ollama qui suggèrent cette dérive, ainsi que leur importance pour l’avenir de la plateforme.
Pour les détails des commandes et paramètres les plus fréquents d’Ollama - veuillez consulter Ollama cheatsheet.
Pour des interfaces utilisateur utiles avec Ollama, consultez - Open-Source Chat UIs for LLMs on Local Ollama Instances
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 lors du démarrage du système — particulièrement sous Windows.
- Il n’y a 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 le réactiver silencieusement.
- Sous macOS, l’application de bureau démarre également par défaut lors de la connexion, sauf si vous installez explicitement la version uniquement CLI.
Ce comportement — un logiciel s’insérant dans votre routine de démarrage sans consentement explicite — est un drapeau rouge classique. Il érode la confiance des utilisateurs et crée des frottements pour ceux qui valorisent le contrôle sur leur système.
Préoccupations liées à 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 administrateurs ont indiqué que cela était lié aux vérifications de mise à jour, et non aux entrées utilisateur — mais il n’y a pas de commutateur simple pour ceux qui souhaitent 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é crée des doutes. La transparence et les options de désactivation sont essentielles si Ollama souhaite maintenir sa crédibilité.
Régressions de performance avec le nouveau moteur
Les mises à jour récentes ont introduit un nouveau moteur d’inférence, mais au lieu d’améliorations de performance, certains utilisateurs ont signalé l’inverse :
- La génération de tokens 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 modèles plus volumineux comme Qwen3:30B fonctionnent maintenant significativement moins bien, avec une latence plus élevée et un débit plus faible.
Ce changement soulève des préoccupations quant aux priorités. Si les mises à jour rendent les modèles moins utilisables sur du matériel réel, les développeurs pourraient se sentir contraints d’upgrader leur matériel ou d’accepter une performance dégradée — une autre manière subtile de déprioriser l’expérience utilisateur.
Risques de sécurité dus à des instances mal configurées
Des chercheurs en sécurité ont découvert des serveurs Ollama exposés fonctionnant sans authentification. Des vulnérabilités comme le parcours de chemins et les vecteurs de déni de service ont été révélées, certaines étant corrigées et d’autres disputées.
Bien que beaucoup de cela repose sur une mauvaise configuration des déploiements par les utilisateurs, le manque de défauts sécurisés augmente le risque. La responsabilité d’une plateforme inclut de rendre le chemin sûr le chemin le plus facile.
Turbo : changements de modèles de mise en œuvre et de monétisation
Le lancement de Ollama Turbo — un service d’accélération en cloud — a représenté un moment clé. La différenciation originale d’Ollama était sa focalisation sur le contrôle local, la confidentialité et la distribution open-source. Turbo, en revanche, introduit une dépendance à l’infrastructure d’Ollama elle-même.
- L’utilisation de Turbo nécessite une connexion, éloignant ainsi de l’expérience locale sans friction.
- Certaines fonctionnalités clés de l’application Mac dépendent maintenant 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 présenté cela comme le début de l’enshittification, avertissant que la commercialisation pourrait finalement introduire des murs à paiement pour des fonctionnalités actuellement gratuites.
Cela ne signifie pas que Ollama a abandonné ses principes — Turbo peut être précieux pour les utilisateurs souhaitant une inférence plus rapide sans acheter de nouveaux matériels. Mais l’optique compte : une fois qu’un outil local-first nécessite des services centralisés pour « l’expérience la meilleure », il risque de diluer les qualités qui l’ont d’abord distingué d’OpenAI ou Anthropic.
Le modèle : contrôle utilisateur vs. défauts du fournisseur
Individuellement, ces problèmes pourraient sembler mineurs. Ensemble, ils suggèrent un modèle :
- Le comportement de démarrage par défaut est activé, non désactivé.
- Les vérifications de mise à jour se produisent automatiquement, non par opt-in.
- Les changements de performance servent de nouveaux objectifs architecturaux, même s’ils dégradent l’utilisabilité actuelle.
- La monétisation introduit maintenant une dépendance serveur, non seulement des binaires locaux.
C’est ainsi que l’enshittification commence — pas par un seul mouvement hostile, mais par une série de petits changements qui échangent subtilement le contrôle utilisateur pour la commodité ou le revenu du fournisseur.
Ce qui n’est pas encore arrivé (pour le moment)
Pour être juste, Ollama n’a pas encore franchi les territoires les plus graves :
- Aucune publicité ou promotion à l’intérieur de l’interface utilisateur.
- Aucun mur à paiement agressif limitant les fonctionnalités locales centrales.
- Aucun verrouillage dur autour des formats propriétaires ; les modèles de la communauté restent accessibles.
Cela dit, la vigilance est nécessaire. 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’une des meilleures façons d’exécuter des modèles volumineux localement. Pour voir comment Ollama s’intègre parmi d’autres options locales, auto-hébergées et en cloud pour les LLM, consultez notre LLM Hosting: Local, Self-Hosted & Cloud Infrastructure Compared.
Mais les signes précoces sont clairs : le comportement de démarrage automatique, l’opacité de la télémétrie, les régressions de performance, les défauts insécurisés et le déplacement cloud-first de Turbo indiquent tous un éloignement progressif de l’éthos original de l’outil.
Pour que Ollama reste fidèle à sa promesse, les administrateurs doivent prioriser la transparence, la conception par opt-in et les principes d’abord local. Sinon, la plateforme risque de compromettre les valeurs qui l’ont d’abord rendue attrayante. Mais je ne retiens pas mon souffle.
