L'Enshittification d'Ollama - Les premiers signes

Ma vision de l'état actuel du développement d'Ollama

Sommaire

Ollama a rapidement devenu l’un des outils les plus populaires pour exécuter localement des LLM (Large Language Models). Son interface CLI simple et sa gestion des modèles optimisée ont fait de lui une option privilégiée pour les développeurs souhaitant travailler avec des modèles d’IA hors du cloud. 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, les intérêts des utilisateurs étant progressivement subordonnés aux priorités commerciales, architecturales ou internes.

enshittification and decay

Dans cet article, j’explorerai 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 sur 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.
  • Sur macOS, l’application de bureau démarre également par défaut à l’ouverture de session, sauf si vous installez explicitement la version uniquement CLI.

Ce modèle — un logiciel s’insérant dans votre routine de démarrage sans consentement explicite — est un signal 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 concerne 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 indiqué que cela était lié aux vérifications de mise à jour, et non aux entrées utilisateur — mais il n’y a aucun interrupteur 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é, cette absence 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 se comportent 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 dégradation des performances — 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 la traversée de chemins et les vecteurs de déni de service ont été divulguées, avec certains correctifs et d’autres contestés.

Bien que beaucoup de cela incombe aux utilisateurs qui configurent mal les déploiements, l’absence de paramètres sécurisés par défaut augmente les risques. La responsabilité d’une plateforme inclut de rendre le chemin sûr le plus simple.

Turbo : changements de modèles d’exploitation et de monétisation

Le lancement de Ollama Turbo — un service d’accélération en cloud — a représenté un moment clé. L’originalité d’Ollama résidait dans son accent 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 payants 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 « la meilleure » expérience, il risque de diluer les qualités qui l’ont d’abord distingué d’OpenAI ou Anthropic.

Le modèle : contrôle utilisateur vs. paramètres par défaut 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é, pas désactivé.
  • Les vérifications de mise à jour se produisent automatiquement, pas sur demande.
  • 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, pas seulement des binaires locaux.

C’est ainsi que l’enshittification commence — pas avec un seul mouvement hostile, mais avec 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 l’instant)

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 payant agressif limitant les fonctionnalités locales essentielles.
  • Aucun verrouillage dur autour des 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.

city enshittification trend

Conclusion

Ollama reste l’une des meilleures façons d’exécuter localement des grands modèles. Mais les premiers signes sont clairs : le comportement de démarrage automatique, l’opacité de la télémétrie, les régressions de performance, les paramètres par défaut insécurisés et la dérive vers le cloud de Turbo indiquent tous un lent éloignement de l’ethos original de l’outil.

Pour Ollama rester fidèle à sa promesse, les mainteneurs doivent prioriser la transparence, la conception par défaut opt-in et les principes local-first. Sinon, la plateforme risque de compromettre les valeurs qui l’ont d’abord rendue attrayante. Mais je ne retiens pas mon souffle.

Liens utiles