Quand la protection contre le pistage de Proton Mail brise les liens d’une infolettre

Je suis abonné à une infolettre de la Banque de développement du Canada (BDC) et, depuis un certain temps, j’avais remarqué un comportement plutôt étrange : certains liens vers les articles et ressources qu’elle m’envoyait aboutissaient sur une erreur 404 – page introuvable.

Au départ, j’ai simplement supposé qu’il y avait un problème avec le logiciel utilisé par la BDC pour concevoir ou envoyer ses infolettres. Un mauvais lien, une redirection expirée ou une erreur de configuration : rien de bien inhabituel.

Mais aujourd’hui, en recevant une nouvelle infolettre, j’ai décidé de tester systématiquement les différents liens qu’elle contenait.

Ils menaient tous vers des ressources introuvables.

À ce stade, l’hypothèse d’une simple erreur ponctuelle devenait beaucoup moins crédible. Si tous les abonnés de la BDC recevaient depuis un certain temps des infolettres dont les liens étaient brisés, le problème aurait vraisemblablement été signalé et corrigé depuis belle lurette.

À moins, bien sûr, que je ne sois pas tout à fait dans la même situation que la majorité des destinataires.

Mon suspect : Proton Mail

Mon environnement de messagerie se distingue effectivement de celui de bien des gens : j’utilise Proton Mail.

Proton Mail offre notamment une fonctionnalité de protection contre le pistage. En plus de bloquer certains pixels espions, la version Web peut nettoyer les liens contenus dans les courriels en retirant des paramètres identifiés comme servant au suivi.

C’est une fonctionnalité que j’apprécie beaucoup.

Les URL que l’on retrouve dans les infolettres ressemblent souvent à ceci :

https://exemple.com/article
    ?utm_source=infolettre
    &utm_medium=email
    &utm_campaign=septembre

Les paramètres utm_* ne sont généralement pas nécessaires pour afficher la page. Ils servent principalement à indiquer au site d’où vient le visiteur.

On peut donc normalement transformer ce lien en :

https://exemple.com/article

sans rien briser.

C’est exactement le genre de nettoyage que l’on souhaite obtenir d’une fonctionnalité de protection contre le pistage.

Sauf que tous les paramètres d’une URL ne sont pas nécessairement facultatifs.

Et c’est là que les choses deviennent intéressantes.

Le même courriel, deux liens différents

L’infolettre de la BDC contenait également un lien « Voir dans mon navigateur ».

Je l’ai utilisé pour ouvrir la version Web du même courriel, puis j’ai comparé l’adresse d’un des liens.

Dans Proton Mail, j’obtenais quelque chose qui ressemblait à ceci :

https://app.service.bdc.ca/e/er
    ?s=1896
    &lid=25828
    &elq=[identifiant]
    &elqcst=272
    &elqcsid=29661

Dans la version en ligne de l’infolettre, le lien était beaucoup plus long :

https://app.service.bdc.ca/e/er
    ?utm_campaign=NL-IB-2026-09-Tech-FR
    &utm_medium=email
    &utm_source=Eloqua
    &utm_term=2993
    &s=1896
    &lid=25828
    &elqTrackId=[identifiant]
    &elq=[identifiant]
    &elqaid=28704
    &elqat=1
    &elqcst=272
    &elqcsid=29661
    &elqak=[long jeton]

Et surtout :

le premier retourne une erreur 404; le second fonctionne parfaitement.

Proton avait donc bel et bien modifié le lien.

Mais ce n’était pas seulement les paramètres utm_* qui avaient disparu.

Les paramètres suivants avaient également été retirés :

elqTrackId
elqaid
elqat
elqak

Pour comprendre pourquoi cela pose problème, il faut regarder ce qui se cache derrière app.service.bdc.ca.

Ce n’est pas vraiment un lien vers l’article

La BDC utilise Oracle Eloqua, une plateforme d’automatisation marketing.

L’URL présente dans l’infolettre ne pointe donc pas directement vers l’article que je souhaite consulter.

Elle passe d’abord par une adresse comme :

https://app.service.bdc.ca/e/er?...

Eloqua reçoit la requête, peut enregistrer le clic, puis redirige le navigateur vers la véritable ressource.

Conceptuellement, nous avons donc quelque chose comme :

Infolettre
    ↓
Lien de redirection Eloqua
    ↓
Validation et suivi du lien
    ↓
Article de la BDC

C’est une distinction importante.

Dans une URL traditionnelle, supprimer un paramètre analytique comme utm_source ne change généralement rien à la destination.

Mais ici, l’URL intermédiaire elle-même possède un mécanisme de validation.

Eloqua protège maintenant ses redirections contre les modifications

En cherchant dans la documentation d’Oracle, j’ai trouvé l’élément qui explique très probablement tout le comportement.

Oracle indique que les liens de redirection générés par Eloqua reçoivent automatiquement un hash d’authentification lorsqu’un courriel est envoyé.

Son objectif est précisément d'empêcher qu'un lien de redirection puisse être modifié par un tiers.

Et Oracle est très explicite : si un lien protégé par ce hash est modifié, la redirection est bloquée.

Cette protection a été introduite avec les versions récentes d’Eloqua et est désormais appliquée aux liens présents dans les courriels.

Dans mon exemple, un paramètre ressort évidemment du lot :

elqak=[longue valeur hexadécimale]

Il disparaît complètement de la version nettoyée par Proton Mail.

Même sans connaître le détail interne de la façon dont Oracle calcule sa signature, le comportement observé correspond exactement à celui documenté par Eloqua : le lien original fonctionne, Proton en retire plusieurs paramètres, puis Eloqua refuse la redirection modifiée.

On obtient donc vraisemblablement cette chaîne :

Lien Eloqua original
        ↓
Proton Mail détecte des paramètres de pistage
        ↓
Certains paramètres sont supprimés
        ↓
Le lien Eloqua est maintenant différent
        ↓
La validation du lien échoue
        ↓
La redirection est bloquée
        ↓
404

Ironiquement, deux mécanismes conçus pour améliorer la sécurité et la vie privée entrent ici en collision.

Eloqua veut empêcher qu’un tiers modifie ses liens.

Proton veut justement modifier certains liens afin d’empêcher leur utilisation pour le pistage.

Proton reconnaît lui-même cette limite

Ce cas n’est d'ailleurs pas complètement inattendu.

Dans sa documentation sur la protection contre le pistage, Proton explique que Proton Mail retire des paramètres UTM ainsi que d’autres paramètres de suivi détectés dans les URL.

Mais Proton ajoute aussi une mise en garde importante : retirer des paramètres d’un lien peut parfois faire en sorte que celui-ci ne fonctionne plus.

C’est exactement ce qui semble se produire ici.

Le problème n’est donc pas nécessairement que Proton détecte incorrectement du pistage. Plusieurs des paramètres retirés sont effectivement liés au mécanisme de suivi d’Eloqua.

Le problème est plutôt qu’avec certains systèmes de redirection modernes, le suivi et l’intégrité technique du lien sont imbriqués.

On ne peut plus nécessairement retirer le premier sans affecter le second.

Qui est responsable?

La réponse n’est pas aussi simple qu’elle en a l’air.

On pourrait reprocher à Proton Mail d’être trop agressif. Une fonctionnalité de protection de la vie privée ne devrait idéalement pas rendre un courriel inutilisable.

Et dans mon cas, ce n’est pas un détail : pratiquement tous les appels à l’action de l’infolettre deviennent des liens morts.

Mais la conception du lien d’Eloqua mérite également d’être questionnée.

Un courriel pourrait simplement contenir :

https://www.bdc.ca/fr/articles/mon-article

éventuellement accompagné de paramètres UTM :

https://www.bdc.ca/fr/articles/mon-article
    ?utm_source=infolettre
    &utm_medium=email

Dans ce scénario, Proton pourrait supprimer les paramètres de suivi sans empêcher l'utilisateur d'accéder à l'article.

Avec le système actuel, la capacité à consulter la ressource dépend plutôt du bon fonctionnement d’un intermédiaire de suivi.

C’est plus fragile.

Des outils de protection de la vie privée, des bloqueurs de contenu, des logiciels de sécurité ou d’autres transformations de liens peuvent alors avoir des conséquences qui dépassent largement la simple disparition de données analytiques.

Protection de la vie privée ou courriel fonctionnel?

Je demeure très favorable à la fonctionnalité de Proton Mail.

Je préfère qu’un logiciel de messagerie protège par défaut ses utilisateurs contre des mécanismes de suivi dont ils n’ont pas nécessairement conscience.

Mais une protection qui transforme silencieusement des liens valides en erreurs 404 présente aussi un véritable problème d’expérience utilisateur.

Le pire est que le diagnostic n’est absolument pas évident.

Lorsque je clique sur un lien provenant de la BDC et que j’obtiens une erreur 404 sur un domaine appartenant à la BDC, ma première conclusion n’est évidemment pas :

« Mon fournisseur de messagerie a probablement supprimé un paramètre nécessaire à la validation cryptographique d’un lien de redirection Oracle Eloqua. »

Je pense plutôt :

« Le lien de la BDC est brisé. »

Et pendant des semaines, c’est exactement ce que j’ai cru.

Une bonne protection devrait échouer proprement

Le problème pourrait être atténué de plusieurs façons.

Proton pourrait, par exemple, reconnaître les URL dont certains paramètres semblent participer à une signature et éviter de les modifier lorsqu’un nettoyage rendrait la destination inaccessible.

Il pourrait également permettre plus facilement d’ouvrir le lien original lorsqu’un lien nettoyé échoue.

Du côté des expéditeurs et des plateformes d’infolettres, l’utilisation de liens directs et résilients devrait également être privilégiée chaque fois que possible. Le pistage d’un clic ne devrait idéalement pas devenir une condition nécessaire pour accéder au contenu auquel ce clic mène.

Parce qu’au bout du compte, une protection de la vie privée doit protéger l’utilisateur sans casser le Web qu’il essaie d’utiliser.

Dans ce cas-ci, Proton Mail accomplit bien la première moitié de sa mission.

Mais il reste manifestement du travail pour la seconde.