Ton app Lovable est bloquée chez tes clients : 5 points à vérifier

Ton app tourne, la démo a plu, et puis un client t'écrit : « le lien ne s'ouvre pas chez nous » ou « ton invitation est arrivée en quarantaine ». Bonne nouvelle : ce n'est presque jamais ton code. C'est l'adresse à laquelle ton app vit et l'adresse depuis laquelle elle écrit. Les deux se corrigent en quelques heures, à condition de vérifier les bons points dans le bon ordre.

Le problème existe-t-il vraiment ?

Oui, et il est documenté. Depuis février 2025, Proofpoint détecte chaque mois des dizaines de milliers d'URL en *.lovable.app utilisées dans des campagnes de phishing ; une seule d'entre elles a envoyé des centaines de milliers de messages à plus de 5 000 organisations. En avril 2025, Guardio a montré qu'on pouvait faire générer et héberger une fausse page de connexion Microsoft sur un sous-domaine lovable.app en quelques prompts. Lovable a réagi : détection en temps réel depuis juillet 2025, plus de 300 sites retirés en deux semaines en août, moteur de navigation sécurisée Guardio intégré en novembre 2025.

Le hic, c'est que les filtres d'entreprise ont de la mémoire. Les passerelles mail (Microsoft Defender, Proofpoint, Mimecast) et les proxys web (Zscaler, Cisco Umbrella, Netskope) peuvent classer les hébergements partagés dans des catégories à risque, et Proofpoint recommande explicitement aux entreprises des politiques d'autorisation autour des « outils fréquemment abusés ». Ton app partage son domaine avec ces campagnes : elle hérite de leur réputation, pas de la tienne.

Côté email, même logique. Par défaut, les emails d'authentification d'une app Lovable Cloud partent de no-reply@auth.lovable.cloud, un domaine mutualisé entre tous les projets, avec une politique DMARC en p=none (vérifié dans le DNS le 11 septembre 2026). Sur Supabase, le service par défaut est limité à 2 emails par heure et n'écrit qu'aux membres de l'équipe. Et depuis mai 2025, Microsoft rejette les expéditeurs à volume sans SPF, DKIM et DMARC, comme Gmail et Yahoo depuis février 2024.

1. Quelle adresse as-tu partagée ?

Demande au client une capture du message de blocage. Une page Zscaler, Umbrella ou Defender indique la catégorie retenue (« Newly Registered and Observed Domains », « Web hosting », « Phishing »), et c'est cette catégorie qui te dit quoi corriger. Si l'adresse partagée finit en .lovable.app, tu as déjà la réponse : ce n'est pas ton app qui est bloquée, c'est le quartier. Et le quartier compte des dizaines de milliers de mauvais voisins par mois.

2. L'app vit-elle sur un sous-domaine de ton entreprise ?

Lovable permet de brancher un domaine personnalisé sur les plans payants : un enregistrement A vers 185.158.133.1, un TXT de vérification _lovable, et le certificat SSL est émis automatiquement. Choisis un sous-domaine de ton domaine principal, par exemple app.tonentreprise.be, et déclare-le comme domaine primaire. Les filtres qui bloquent les « domaines récemment vus » regardent le domaine enregistré : app.tonentreprise.be hérite de l'âge et de la réputation de tonentreprise.be.

À noter : l'URL xxx.lovable.app continue d'exister et redirige de façon temporaire (Lovable ne fait pas de 301). Arrête donc de la partager, dans les emails comme dans les présentations.

3. Depuis quelle adresse partent les emails de l'app ?

Envoie-toi une invitation et ouvre l'en-tête complet (« Afficher l'original » dans Gmail, « Afficher la source » dans Outlook). Si l'expéditeur est no-reply@auth.lovable.cloud ou une adresse Supabase par défaut, tes clients reçoivent un mail d'un inconnu contenant un lien vers un domaine surveillé. Deux corrections possibles : sur les plans payants, la fonction Emails de Lovable envoie depuis ton domaine et configure SPF, DKIM et DMARC (50 000 emails transactionnels par mois inclus) ; avec Supabase, branche un SMTP dédié (Resend, Postmark, SendGrid) sur un domaine que tu contrôles.

4. Ta propre boîte mail est-elle bien configurée ?

C'est le point qu'on oublie. Dès que l'app écrit au nom de tonentreprise.be, c'est la configuration DNS de ton domaine qui décide si le message passe, pas celle de Lovable. Trois enregistrements à vérifier (MXToolbox, dmarcian ou Google Postmaster suffisent) :

• SPF : un seul enregistrement v=spf1, qui inclut le service d'envoi de l'app (Resend, Mailgun ou Lovable) et reste sous la limite de 10 recherches DNS ;
• DKIM : le sélecteur publié par le service, sinon la signature échoue ;
• DMARC : au minimum p=none avec une adresse rua pour recevoir les rapports.

Deux cas fréquents. Ton domaine a déjà un DMARC en p=reject (très bien), mais l'app envoie sans alignement : elle est rejetée par ta propre politique. Ou le SPF a été édité à la main et contient deux enregistrements v=spf1, ce qui l'invalide entièrement.

5. Les liens des emails pointent-ils vers le bon domaine, et survivent-ils au scanner ?

Deux vérifications. D'abord, la Site URL et les redirect URLs de l'authentification doivent utiliser ton sous-domaine. Sinon l'email part bien depuis ton domaine, mais renvoie vers un lien .lovable.app que Defender Safe Links réécrit ou bloque.

Ensuite, les scanners d'entreprise (Safe Links, Barracuda, Mimecast) « cliquent » sur les liens avant l'utilisateur. Un lien magique ou un lien de réinitialisation à usage unique est consommé avant d'être ouvert, et le client voit otp_expired. Supabase documente le problème et deux parades : passer le jeton dans un fragment d'URL (#) que les scanners ne suivent pas, ou basculer sur un code OTP à saisir.

La solution, dans l'ordre

1. Brancher app.tonentreprise.be comme domaine primaire dans Lovable, et ne plus partager que celui-là.
2. Faire partir tous les emails de l'app depuis ton domaine (Lovable Emails ou SMTP dédié), avec SPF, DKIM et DMARC alignés.
3. Mettre à jour Site URL et redirect URLs pour que chaque lien pointe vers ton sous-domaine.
4. Tester avec une boîte Microsoft 365 et une boîte Gmail : en-têtes SPF, DKIM et DMARC en pass, lien ouvert sans avertissement, lien magique encore valable.
5. Si un client reste bloqué, envoyer à son service informatique une demande d'autorisation courte : ton sous-domaine, ton domaine d'envoi, l'usage. Ne demande jamais d'autoriser *.lovable.app en entier : son IT refusera, et il aura raison.

Aucune de ces étapes ne demande de réécrire l'app. Le domaine à ton nom figure déjà dans la checklist de lancement, et la propriété des emails transactionnels fait partie des garanties à vérifier avant d'ouvrir une app Lovable. Le Scan contrôle ces points sur ton projet réel, avec la preuve et l'action pour chacun.