Le retour à la ligne dans la variable d'environnement

Les comptes organisateurs marchaient en local depuis une semaine : inscription, e-mail de confirmation, clic, tableau de bord. J’ai déployé le 17 février et je me suis inscrit depuis mon téléphone, pour voir. L’e-mail n’est jamais arrivé. Ni dans la boîte, ni dans les indésirables, ni le lendemain.

Ce que je croyais

Qu’un service d’envoi était mal configuré, ou qu’un domaine n’était pas vérifié. C’est la cause habituelle des e-mails qui n’arrivent pas, et c’est celle que l’outil d’IA m’a proposée en premier. J’ai vérifié la configuration de Supabase, qui gère l’authentification. Tout était en ordre. L’e-mail n’était pas perdu en route : il n’était jamais envoyé.

Ce que c’était

Trois problèmes l’un sur l’autre, découverts dans l’ordre.

D’abord, le formulaire d’inscription appelait Supabase sans lui dire où renvoyer l’utilisateur après confirmation. Sans cette adresse, pas d’e-mail. Une ligne à ajouter, emailRedirectTo, et l’e-mail est parti.

Ensuite, l’e-mail est parti, mais le lien à l’intérieur était cassé. Il pointait vers https://sync-buzzer.vercel.app%0A/auth/confirm. Ce %0A, c’est un retour à la ligne, encodé. Quand j’avais collé les variables d’environnement dans l’interface de Vercel, j’avais emporté un saut de ligne à la fin de la valeur. Invisible dans l’interface, invisible dans les journaux, présent dans chaque URL construite avec.

// la valeur contenait "https://sync-buzzer.vercel.app\n"
const base = process.env.NEXT_PUBLIC_APP_URL.trim();

Enfin, une fois le lien valide, la confirmation échouait quand même. Parce que la production ne parlait pas à la même base de données que mon poste : deux projets Supabase distincts, créés à des moments différents, et les variables de Vercel pointaient vers l’ancien. Le compte se créait d’un côté, la confirmation cherchait de l’autre.

Le 17 février, j’ai ajouté une vérification des variables au démarrage du serveur, qui refuse de lancer l’application si une valeur est absente ou mal formée. Elle m’a déjà arrêté deux fois depuis.

Ce que j’en retiens

Aucun de ces trois problèmes n’était dans le code que l’outil avait écrit. Ils étaient dans ce qui l’entoure : un paramètre que je n’avais pas demandé, un copier-coller, une configuration qui avait dérivé. C’est exactement la zone que la vitesse de génération ne couvre pas, et c’est celle où je passe désormais le plus de temps.

Le retour à la ligne, en particulier, m’a rappelé une règle que j’appliquais dans une autre vie : ne jamais faire confiance à une valeur qui a transité par un presse-papiers. On la nettoie à l’entrée, ou on la vérifie au démarrage. De préférence les deux.

Trois bugs, zéro dans le code. Tous dans l’espace entre le code et le monde.