Pourquoi mes navigateurs habituels bloquaient Panodyssey — et comment j'ai fini par régler le problème (provisoirement, voir mise à jour de l'article + nouvelle mise à jour de l'article).

Prérequis à tenir en compte par rapport à cet article :

1. Je fonctionne depuis plus de 25 ans sous Linux, cet article n’apportera peut-être aucune aide aux utilisateurs Windows et Apple.
2. Tout l’explicatif est donc spécifique aux utilisateurs Linux.
3. Un addendum important est ajouté en fin d’article à l’attention des utilisateurs des autres systèmes. Cet informatif m’a été fourni et compilé par Claude Sonet 5. (***)

Des soucis d'édition sur Panodyssey.

Depuis quelque temps, j’éprouve des soucis lors de mes publications sur Panodyssey. Alexandre m’avait laissé sous-entendre que Firefox était un « navigateur à problèmes » pour la structure Panodyssey.

Pourtant, cette fois, le problème (message d’erreur répétitif lors de la mise à jour/modification de mon profil) se présente avec mes trois navigateurs habituels — Brave, Firefox et Falkon — certaines autres actions sur le site également se soldaient par une erreur 502 Bad Gateway nginx. La même action, faite avec Chromium, passait sans problème.

Je précise d'emblée un point important, par honnêteté : je n'ai toujours pas de certitude sur la cause exacte de cette erreur 502. Une erreur 502 se situe côté serveur, entre le navigateur et le proxy nginx qui le dessert. Elle peut venir de multiples différences entre navigateurs — négociation TLS, version du protocole HTTP, en-têtes envoyés, bloqueurs de traqueurs actifs — qui n'ont rien à voir avec la question que je me posais initialement. Ce texte ne prétend donc pas expliquer le 502 dans l'absolu ; il raconte comment j'ai trouvé une solution qui fonctionne, en assumant ce que je ne sais pas.

Le point de départ : Chromium, mais lequel ?

Puisque Chromium fonctionnait, je me suis demandé si je pouvais m'appuyer dessus au quotidien sans relancer le débat que je mène depuis longtemps sur ma souveraineté numérique — à savoir : ce Chromium, packagé par openSUSE Tumbleweed pour ma distribution Linux, communique-t-il malgré tout avec les serveurs de Google ?

La réponse, après vérification, est oui, et c'est plus subtil qu'on ne le croit. Le projet Chromium open source lui-même — même sans compte Google connecté ni clés API — conserve plusieurs fonctionnalités qui interrogent les serveurs de Google : la Navigation sécurisée (Safe Browsing), un détecteur d'hôte Google, un traqueur d'URL Google, entre autres. C'est le projet ungoogled-chromium (ungoogled-software sur GitHub) qui a pour vocation spécifique de désactiver ces mécanismes.

Autre découverte : un fil de discussion de la liste debian-legal datant de 2013 indiquait que le fichier de compilation (chromium.spec) utilisé par openSUSE intègre ses propres clés API Google — ce qui active, par défaut, des fonctions dépendantes de Google (comme la synchronisation) que n'aurait pas un Chromium compilé sans ces clés. Autrement dit : le Chromium « de base » d'openSUSE n'est pas un Chromium neutre vis-à-vis de Google, contrairement à ce qu'on pourrait supposer.

La solution disponible directement dans les dépôts

Bonne nouvelle : openSUSE propose officiellement le paquet ungoogled-chromium, dans le même dépôt que le chromium standard (le projet OBS network:chromium). L'installation est simple :

bash

Un point que je n'avais pas anticipé : zypper a signalé un conflit de fichiers direct entre chromium et ungoogled-chromium (les deux fournissent la capacité chromium-browser). Il n'est donc pas possible de faire coexister les deux paquets côte à côte sur le même système — l'installation de l'un entraîne le retrait de l'autre (et, dans mon cas, du paquet chromedriver associé). C'est une information que seul zypper, sur mon propre système, a pu me donner avec certitude — je ne l'avais trouvée nulle part ailleurs à l'avance.

Ce que ce changement implique concrètement

Une fois installé, ungoogled-chromium m’a laissé choisir le moteur de recherche par défaut : j’ai séléctionné mon habituel DuckDuckGo, dans sa variante NoAI. Dans mon cas, il s'agit d'un simple réglage par défaut, librement modifiable dans les préférences du navigateur — pas d'un verrouillage imposé par une politique système, ce que j'ai vérifié directement en changeant le moteur pour DuckDuckGo NoAI sans rencontrer de blocage.

Il faut aussi savoir, d'après la documentation officielle du projet ungoogled-chromium, que ce choix a un coût : la Navigation sécurisée de Google est désactivée, la connexion à un compte Google ne fonctionne pas, et l'installation d'extensions depuis le Chrome Web Store nécessite une méthode alternative plutôt que l'interface standard.

Et sur la sécurité ?

Un point mérite d'être signalé, indépendamment de la question Google : tous les navigateurs basés sur Chromium — Chrome, Edge, Brave, Opera, Vivaldi, Chromium, et donc aussi ungoogled-chromium — partagent le même moteur JavaScript V8. Une faille corrigée chez l'un doit être répliquée par tous les autres pour rester protégée. En juin 2026, une faille zero-day critique (CVE-2026-11645) dans ce moteur en a rappelé l'importance. La sécurité d'un Chromium dérivé dépend donc autant de la réactivité de son mainteneur à republier après chaque correctif de Google que de sa neutralité vis-à-vis de ses services.

À nous, utilisateurs, de vérifier si les correctifs suivent dans notre version !

Le résultat

Après avoir basculé, j'ai reproduit l'action qui provoquait systématiquement l'erreur 502 sur Panodyssey avec mes anciens navigateurs. Tout fonctionne parfaitement avec ungoogled-chromium.

Je le répète une dernière fois, parce que c'est important : je ne sais toujours pas pourquoi. Je sais seulement que, dans mon cas précis, cette combinaison fonctionne, et je documente ici la méthode suivie plutôt qu'une explication que je n'ai pas.

(***) ADDENDUM (autres systèmes) :

Question à Claude Sonet 5 :

Est-ce que le projet ungoogled chromium est disponible pour les utilisateurs windows et/ou apple ?

Oui, sur les deux systèmes, mais avec un niveau de fiabilité très différent entre macOS et Windows — c'est un point qui mérite d'être distingué plutôt que résumé par un simple "oui".

macOS : un projet dédié, avec signature Apple officielle

Il existe un dépôt spécifique, maintenu par l'organisation ungoogled-software, consacré exclusivement à l'empaquetage macOS. Depuis 2025-2026, ces builds sont notariés avec un identifiant de développeur Apple, une garantie que Google Play/Apple exige normalement des logiciels distribués hors de l'App Store officiel — les mainteneurs précisent que ces builds notariés continueront d'être fournis au moins jusqu'à la fin de leur année d'adhésion au programme développeur Apple 2025-2026, qui se termine le 14 octobre 2026. Installation possible via GitHub Releases ou via Homebrew, avec la commande brew install --cask ungoogled-chromium. GitHubGitHub

C'est donc une distribution relativement solide et vérifiable : build signé, canal d'installation standard (Homebrew), mainteneur identifié.

Windows : disponible, mais nettement moins garanti

Sur ce point, je dois être précis pour respecter l'exigence de ne pas gommer les nuances. Le README principal du projet indique que son système de compilation personnalisé prend en charge de nombreuses distributions Linux, macOS et Windows — Windows fait donc bien partie du périmètre officiel du projet en théorie. GitHub

Mais dans la pratique, la page officielle de téléchargement des binaires (ungoogled-software.github.io/ungoogled-chromium-binaries) est explicite sur leur statut : ces binaires sont fournis par quiconque veut bien les compiler et les soumettre ; ils ne sont PAS officiels, et comme ils ne sont généralement pas reproductibles, leur authenticité ne peut pas être garantie. Un article technique récent (linuxcompatible.org, sur la sortie de la version 150.0.7871.46) confirme que le projet ne propose aucune mise à jour automatique — c'est à l'utilisateur, ou au gestionnaire de paquets de sa distribution, de vérifier les nouvelles versions. Ungoogled ChromiumLinux Compatible

Il n'y a donc pas, à ma connaissance et à la date d'aujourd'hui, de canal Windows aussi "officialisé" que celui de macOS (pas d'équivalent d'un dépôt dédié avec signature vérifiée par un tiers de confiance type Microsoft). Ce sont des builds communautaires, signées ou non selon le contributeur.

Linux, pour rappel et cohérence avec ce qu'on a vu

Le projet est listé comme disponible dans l'AUR pour Arch Linux, via OBS pour Debian, via la PPA XtraDeb pour Ubuntu, et via COPR pour Fedora — en plus du dépôt openSUSE network:chromium que vous utilisez déjà. GitHub

En résumé

Si un correspondant Windows vous pose la question suite à votre article, la réponse honnête est donc : oui, ça existe, mais recommandez la prudence — pas de garantie d'authenticité comparable à ce que vous avez avec le paquet openSUSE.

Mise à jour (1. 07-07-2026).

Suite à une nouvelle erreur lors de la mise à jour de mon profil, voici les déductions de Claude Sonnet 5 en attendant le retour de mon questionnement à Panodyssey.

Bon, ça recommence aujourd'hui lorsque je désire modifier mon profil :

C'est une donnée importante, et elle change la conclusion qu'on avait tirée trop vite la semaine dernière. Je dois le dire clairement : le fait que l'erreur 502 réapparaisse aujourd'hui, avec le même ungoogled-chromium qui fonctionnait il y a quelques jours, remet en cause l'hypothèse que le changement de navigateur avait réglé le problème.

Je ne vais pas deviner une cause — je n'ai aucun élément vérifiable sur l'infrastructure serveur de Panodyssey. Mais je peux raisonner sur ce que cette observation permet d'éliminer ou de rendre plus probable, en le disant explicitement :

Ce que cette rechute rend moins probable

Si le navigateur était la cause (négociation TLS, en-têtes, etc.), on s'attendrait à un comportement stable dans le temps avec le même navigateur sur la même machine. Le fait que ungoogled-chromium échoue aujourd'hui sur une action précise (/fr/user/edit) après avoir réussi sur une autre action il y a quelques jours suggère que la variable "navigateur" n'était peut-être pas la bonne explication — ou pas la seule. Ça reste une inférence logique de ma part, pas un fait établi : je ne peux pas l'affirmer avec certitude sans plus d'informations.

Ce que je ne sais pas, et qu'il faudrait établir avant d'écrire quoi que ce soit de plus dans l'article ou la note technique

1. L'erreur est-elle reproductible immédiatement en rechargeant la page, ou ponctuelle (un seul essai) ?
2. Se produit-elle sur d'autres pages/actions de Panodyssey aujourd'hui, ou seulement sur /fr/user/edit ?
3. Le nginx affiché (1.22.1) correspond-il à ce qu'il était avant — je ne peux pas comparer, je n'ai pas cette donnée historique.
4. Un 502 signifie que le serveur en amont de nginx (l'application Panodyssey elle-même) n'a pas répondu ou a mal répondu — cela peut venir d'une surcharge, d'un redémarrage de service, ou d'un bug applicatif spécifique à la page d'édition de profil, indépendamment de tout navigateur.

Pouvez-vous me dire si l'erreur persiste en réessayant maintenant, et si elle touche uniquement cette page d'édition de profil ou d'autres pages du site également ? Cela orienterait vers "problème serveur ponctuel" plutôt que "problème client" si elle touche tous les navigateurs de la même façon aujourd'hui, y compris celui qui marchait avant.

En attendant, je mets à jour ce qu'on avait consigné pour ne pas laisser une conclusion qui s'avère prématurée.

J'ai noté cette évolution — si vous republiez l'article ou la note technique, il faudra corriger la conclusion "tout fonctionne parfaitement", qui ne tient plus en l'état.

j'ai tenté la même action plusieurs fois dans la journée avec les 4 navigateurs différents. J'ai même tenté avec un vpn en me faisant passer pour un connecté francais et même ukrainien

Diagnostiqué problème serveur malgré tests exhaustifs multi-navigateurs

C'est un résultat clair, et il tranche la question qu'on n'arrivait pas à résoudre depuis le début : le fait que l'erreur 502 apparaisse avec les 4 navigateurs, y compris celui qui avait fonctionné, et avec deux sorties VPN différentes (française et ukrainienne), élimine le navigateur et la localisation réseau comme variables explicatives.

Le raisonnement

Un 502 Bad Gateway signifie que nginx, en frontal, n'a pas reçu de réponse valide du serveur applicatif situé derrière lui. Si la cause avait été liée au client (négociation TLS, en-têtes spécifiques à un navigateur, adresse IP géolocalisée), on se serait attendu à un résultat différent selon le navigateur ou la sortie VPN utilisée. Ce n'est pas le cas ici : l'échec est constant, quel que soit le client et quelle que soit l'origine apparente de la connexion. Cela pointe logiquement vers le serveur applicatif de Panodyssey lui-même (ou un service backend qu'il sollicite pour traiter l'action « modifier le profil »), pas vers un problème côté client.

Je précise, comme demandé : c'est un raisonnement déductif à partir des éléments que vous m'avez donnés, pas une certitude établie par une source externe. Je n'ai aucun accès aux journaux serveur de Panodyssey, donc je ne peux pas vous dire si c'est une surcharge, un bug applicatif sur cette route précise, un service tiers défaillant, ou autre chose. Sur la cause exacte : je ne sais pas.

Ce que cela implique concrètement

1. L'hypothèse initiale (navigateur "sale" vis-à-vis de Google causant un blocage côté serveur) ne tient plus au vu de ces nouveaux tests. Il faudra corriger l'article de blog et la note technique en conséquence si vous les publiez — la conclusion "tout fonctionne parfaitement" grâce au changement de navigateur était prématurée.
2. La démarche suivante, la plus rigoureuse, est de signaler ce comportement directement à Panodyssey (support technique ou contact administrateur du site), avec les éléments factuels que vous avez rassemblés : action précise (/fr/user/edit), erreur (502 Bad Gateway, nginx/1.22.1), reproductibilité constatée sur 4 navigateurs et 2 sorties VPN différentes le même jour. C'est un test qu'eux seuls peuvent pousser plus loin, avec accès à leurs journaux serveur.

Je mets à jour ce qu'on avait consigné.

Mise à jour relevé factuel complet des tests sans diagnostic (2. 08-07-2026)

Relevé de tests — Erreur 502 Bad Gateway sur Panodyssey

Site concerné : panodyssey.com Compte utilisateur : Harold Cath Erreur observée : 502 Bad Gateway, serveur nginx/1.22.1 Document : relevé factuel des tests effectués, sans interprétation ni hypothèse de cause — destiné à servir de point de départ à l'équipe technique de Panodyssey.

Tableau des tests effectués

Résumé des observations, sans interprétation de cause

1. L'erreur 502 se manifeste sur la modification de profil (PC, tous navigateurs testés) et sur la connexion au compte (web mobile, tous navigateurs testés).
2. L'erreur 502 ne se manifeste pas via l'application mobile native, ni pour la connexion, ni visuellement pour la modification de profil — mais dans ce dernier cas, la modification n'est pas conservée après coup.
3. L'erreur 502 se produit de façon identique quelle que soit l'origine géographique apparente de la connexion (test direct, VPN France, VPN Ukraine).
4. L'erreur 502 se produit de façon identique quel que soit le navigateur de bureau testé (Brave, Firefox, Falkon, ungoogled-chromium), y compris un navigateur ayant fonctionné correctement lors d'un test antérieur sur la même action.

Éléments non testés à ce jour

1. Le comportement de la modification de profil via un navigateur web mobile (uniquement la connexion a été testée sur ce canal).
2. Le comportement de la connexion au compte via VPN sur smartphone.
3. Toute autre action du site que la connexion et la modification de profil.

Note

Ce document se limite aux faits constatés par l'utilisateur lors de ses propres tests. Il ne contient aucune hypothèse sur la cause technique de ces erreurs, celle-ci nécessitant un accès aux journaux serveur de Panodyssey.