Google bloque le site Immich

C’est le scénario que redoutent tous les propriétaires, développeurs ou administrateurs de sites : votre site fonctionne parfaitement, puis devient soudainement inaccessible. Les utilisateurs ne voient plus votre contenu mais un inquiétant écran d’alerte en pleine page. On pense naturellement à une panne serveur, une attaque DDoS ou un piratage. Mais si le responsable n’était pas un attaquant externe, plutôt une décision silencieuse et automatisée d’un des plus puissants gardiens du web ?

C’est exactement ce qui est arrivé à l’équipe derrière Immich, une solution auto‑hébergée de sauvegarde photo et vidéo, récemment. Leur domaine entier a été brusquement signalé comme « dangereux », les effaçant de fait pour la majorité des utilisateurs. Leur parcours frustrant pour en identifier la cause révèle une zone aveugle dangereuse dans les systèmes automatisés qui s’érigent en shérifs du web — une faille qui peut toucher n’importe qui.

À retenir : Un gardien opaque peut vous effacer du web

Un seul signalement peut vous faire disparaître

Google Safe Browsing est un service gratuit intégré directement dans les principaux navigateurs comme Chrome et Firefox. Son objectif : protéger les utilisateurs en identifiant et bloquant les sites qui hébergent malwares, logiciels indésirables ou pratiquent « l’ingénierie sociale ». Lorsqu’un site est signalé, les visiteurs sont confrontés à un écran rouge vif. Pour l’équipe Immich, cette expérience fut un ajout non désiré à leur « liste de connaissances maudites ».

L’impact est immédiat et dévastateur. Comme ils l’ont découvert : « votre site devient essentiellement indisponible pour tous les utilisateurs ». Seule une petite frange de profils très techniques osera franchir les multiples avertissements pour accéder au « site non sûr ». Pour le reste de votre audience, votre site cesse d’exister. Le processus réel qui mène à l’étiquette « dangereux » n’est pas transparent, faisant de ce système un arbitre puissant mais opaque de l’accessibilité.

À retenir : L’effet domino alarmant d’un seul sous‑domaine

Un « mauvais » lien interne peut abattre tout votre domaine

Après inspection de la Google Search Console, l’équipe Immich a trouvé la source : leurs environnements internes de prévisualisation non publics. Des sites temporaires générés automatiquement pour le développement, avec des URLs comme main.preview.internal.immich.cloud. Les systèmes automatisés de Google auraient exploré ces sites temporaires et conclu qu’ils étaient « trompeurs ».

La découverte la plus critique et contre‑intuitive fut le dommage collatéral. Le signalement d’un unique sous‑domaine interne n’est pas resté isolé. Le système de Google a appliqué l’étiquette « dangereux » à tout le domaine immich.cloud, mettant hors ligne services de production et pages d’information. Même leur serveur de tuiles en production (tiles.immich.cloud) a été impacté. Heureusement, les requêtes vers ce serveur passent par JavaScript et ne sont pas visibles côté utilisateur, il semblait donc fonctionner normalement.

Le plus alarmant : réaliser qu’un seul sous‑domaine signalé peut invalider tout le domaine.

À retenir : La « réparation » devient une boucle sans fin frustrante

Être désignalé peut devenir une tâche de Sisyphe

Le recours officiel : créer un compte Google, enregistrer votre site dans la Search Console et soumettre une demande de réexamen. L’équipe Immich l’a fait, expliquant que les sites marqués étaient leurs propres déploiements. Un ou deux jours plus tard, la révision est acceptée et le domaine à nouveau propre ! 🎉

Mais la victoire est de courte durée. Ils se retrouvent coincés dans un purgatoire algorithmique. Leur processus de développement crée de nouveaux environnements de prévisualisation pour les pull requests GitHub. Dès qu’une nouvelle URL de preview apparaît dans un commentaire, les robots de Google la trouvent, explorent le site et re‑signalent immédiatement tout immich.cloud comme dangereux. Le cycle recommence — un jeu futile de « tape‑taupe » numérique.

Face à cette boucle sans fin, l’équipe a imaginé un contournement : déplacer toutes les préversions vers un domaine dédié — immich.build — mettant en quarantaine le développement afin de protéger les services de production des futures mises à l’index globales.

À retenir : Le système semble aveugle au développement open source

Ce n’est pas juste le problème d’un projet ; c’est une menace pour l’open source

Cette expérience n’est pas propre à Immich. Elle met en lumière un problème systémique plus large qui menace gravement les projets open source et auto‑hébergés. De nombreux projets populaires — Jellyfin, YunoHost, n8n, NextCloud — ont connu exactement le même souci. Le problème a même touché les utilisateurs d’Immich, « quelques-uns commençant à se plaindre que leurs propres déploiements Immich étaient signalés ».

Le workflow qui définit le développement open source moderne — créer des environnements publics de prévisualisation pour revue communautaire — est interprété à tort par les systèmes automatisés de Google comme une activité trompeuse. Ce n’est pas un bug ; c’est une cécité de conception fondamentale.

Google Safe Browsing semble avoir été construit sans considération pour les logiciels open source ou auto‑hébergés.

Quand un flux de développement standard et transparent est perçu comme une menace, il punit les communautés mêmes qui bâtissent les outils libres et ouverts dont nous dépendons.

Conclusion : Le dilemme d’un web centralisé

L’histoire d’Immich rappelle que des gardiens centralisés détiennent un pouvoir immense — souvent arbitraire — pour rendre de larges pans du web inaccessibles. Bien que des services comme Safe Browsing partent d’une intention louable, leur approche automatisée uniforme peut causer des dommages significatifs et involontaires à des projets légitimes. Cela nous force à une question difficile.

Alors que nous cédons davantage de contrôle à des gardiens opaques automatisés, devons‑nous nous demander : construisons‑nous réellement un Internet plus sûr, ou pavons‑nous involontairement les espaces vivants et collaboratifs où naît la prochaine génération de logiciels open source ?