X fait fermer Nitter, le front-end autohébergé qui lisait les tweets sans compte

24 août 2026. X Corp envoie une mise en demeure à Zedeus, le développeur unique de Nitter. 25 août 2026. Échéance fixée à 17 h, heure de l’Est ; le soir même, nitter.net est hors ligne et XCancel s’éteint. 26 août 2026. Le dépôt GitHub est marqué archivé, en lecture seule. Après sept ans, le front-end le plus populaire pour lire X sans compte s’arrête — et une brique entière de l’écosystème autohébergé tombe avec lui.

Ce que Nitter faisait, et pourquoi X l’a tué

Nitter était un front-end alternatif open source pour X (ex-Twitter), créé il y a sept ans par un développeur solo sous le pseudo Zedeus. Son principe était simple : lire les publications publiques de X sans créer de compte, sans publicité et sans traceurs. N’importe qui pouvait déployer sa propre instance sur son serveur — c’était précisément ce qui en faisait un pilier de l’autohébergement.

Pour l’autohébergeur, Nitter offrait plus qu’un confort de lecture : c’était un moyen de garder la main sur le rendu, d’éviter le JavaScript et les traceurs de l’interface officielle, et d’exposer un flux RSS stable là où X l’avait progressivement fermé. Autant de fonctions que l’interface officielle ne rendait plus, ou jamais — et qu’aucun service commercial ne cherchait à reproduire.

La mise en demeure de X Corp, datée du 24 août 2026, reproche au projet un scraping non autorisé et exige la fermeture des instances et du dépôt de code. Le point important est là : la demande ne vise pas un hébergeur précis, mais le projet lui-même. Ce n’est pas un retrait DMCA ciblé, c’est une injonction large qui remonte jusqu’à la source.

Zedeus a publié une note laconique indiquant qu’il cherchait un conseil juridique. Avec un développeur unique, sans structure et sans budget contentieux, la décision était pliée d’avance : un particulier ne se bat pas contre l’équipe juridique d’une plateforme.

Une chaîne d’arrêt : instances, XCancel, dépôt

L’arrêt ne s’est pas limité au site principal. nitter.net, l’instance publique historique, est passée hors ligne dès le soir du 25 août. XCancel, un miroir alternatif qui s’appuyait sur la même mécanique, s’est éteint dans la foulée. Le dépôt GitHub de Nitter, lui, est resté en ligne mais archivé en lecture seule, avec un texte explicatif ajouté au README.

Ce dernier détail a une conséquence précise pour les autohébergeurs : les dizaines d’instances Nitter privées qui tournaient encore se retrouvent orphelines. Sans dépôt actif, plus de correctifs, plus de mises à jour, plus de communauté pour maintenir le code. Une instance locale continue de fonctionner jusqu’à ce que X change une API ou durcisse ses protections — et alors, personne ne viendra la réparer.

Le même scénario s’était déjà joué pour d’autres front-ends : Invidious face à YouTube, Libreddit face à Reddit. À chaque fois, la plateforme n’a pas eu besoin de gagner un procès ; il lui a suffi de rendre la maintenance intenable.

Ce que perd l’écosystème autohébergé

Nitter remplissait plusieurs fonctions que l’interface officielle ne rend pas faciles. Il permettait de lire X au format RSS, de consulter des fils publics depuis un navigateur sans JavaScript lourd, d’archiver des publications, et de documenter des contenus pour le journalisme et l’OSINT. Les outils qui redirigeaient automatiquement les liens X vers une instance Nitter — comme LibRedirect ou certaines extensions de navigateur — perdent leur cible d’un coup.

La disparition de Nitter ne laisse pas de successeur évident. Quelques forks et projets communautaires tentent de reprendre le flambeau, mais ils héritent du même problème juridique et de la même fragilité structurelle : un ou deux mainteneurs bénévoles face à une plateforme cotée.

Le coup est particulièrement rude pour les usages qui n’avaient pas d’alternative simple. Les journalistes qui citaient des publications publiques via Nitter, les équipes d’OSINT qui surveillaient des comptes sans s’authentifier, les lecteurs qui suivaient un fil au format RSS : tous perdent un outil stable en une soirée, sans préavis de migration. Une commodité populaire n’est pas une garantie de continuité, et c’est précisément la différence entre un service dont on dépend et un service dont on se sert.

Un front-end tiers est une dépendance, pas une indépendance

La leçon dépasse Nitter. Autohéberger un front-end alternatif, ce n’est pas s’affranchir de la plateforme : c’est déplacer le calcul sur son serveur tout en dépendant toujours de la volonté de la plateforme de continuer à être lue. La donnée reste chez X ; seul le rendu change d’adresse.

C’est vrai pour toute la famille des front-ends de confidentialité : Invidious et Piped pour YouTube, Redlib pour Reddit, ProxiTok pour TikTok. Tous vivent à la merci d’un changement de politique, d’une API refermée ou d’une lettre d’avocat. Un service autohébergé qui dépend d’une plateforme hostile n’est pas un actif d’infrastructure — c’est une commodité, révocable du jour au lendemain.

La distinction vaut pour toute décision d’architecture : ce qui rend un service indépendant n’est pas l’endroit où il tourne, mais la source de sa donnée. Tant que la donnée provient d’un tiers qui peut la couper, l’indépendance est un confort, pas une garantie.

Que faire concrètement maintenant

Le premier réflexe est de ne pas attendre. Les instances privées continuent de fonctionner tant que X ne change rien, mais elles sont déjà orphelines : la prochaine modification de l’API ou des protections anti-bot les rendra muettes, et personne ne publiera de correctif. Vérifiez si un fork actif a repris le code et s’il publie des mises à jour — c’est le seul critère qui compte, pas l’existence d’un dépôt.

Ensuite, séparez le besoin du moyen. Si vous lisiez X pour suivre quelques comptes, regardez si ces comptes exposent un flux RSS ou une alternative officielle ; si c’est pour de l’archivage ou de l’OSINT, prévoyez un outil qui capture directement ce que vous consultez plutôt que de dépendre d’un front-end tiers. Si vous gérez une instance pour d’autres utilisateurs, annoncez dès maintenant la date à laquelle vous la couperez : une dépendance que l’on maintient « encore un peu » est une dépendance que l’on paiera au pire moment.

Enfin, ne pointez jamais un outil de production vers une instance unique. Une redondance entre plusieurs sources, même imparfaites, vaut mieux qu’une commodité qui disparaît en une soirée.

Verdict

Si vous utilisiez Nitter ou XCancel, migrez maintenant : le projet est archivé, les instances publiques sont hors ligne, et les instances privées deviendront inutilisables à la prochaine modification côté X. Cherchez un remplaçant, mais exigez un fork actif et assumez le risque.

Si vous autohébergez un front-end de confidentialité, traitez-le pour ce qu’il est : une commodité, pas une brique critique. Gardez une solution de repli — un flux RSS quand il existe, l’API officielle quand elle est autorisée — et ne construisez jamais un workflow de production sur un service qu’une seule mise en demeure peut tuer en une soirée.

Références

• X sends cease-and-desist to open source project Nitter over alleged scraping — TechCrunch, 25 août 2026
• Nitter no more? X sends in the lawyers to shut down open source project — The Register, 26 août 2026
• Nitter And XCancel Shutdown After ’Cease And Desist’ From X — Forbes, 26 août 2026
• Nitter Is Gone: X’s C&D Wipes Out 7-Year Privacy Tool — Byteiota, 26 août 2026
• Dépôt Nitter archivé — GitHub (zedeus/nitter)
• Self-Host Weekly (28 August 2026) — selfh.st