Ajouter une bannière cookies RGPD à Lovable en 10 minutes

Ce que Lovable livre, et ce qu’il ne livre pas

Un projet Lovable est une app Vite et React standard : un index.html à la racine, un dossier src/ que l’agent réécrit au fil des prompts et, si vous l’avez activé, un backend Supabase pour l’auth et les données. À la publication, l’app va sur your-project.lovable.app, ou sur votre propre domaine une fois connecté.

Trois choses arrivent avec cette app et ont des conséquences sur le consentement. D’abord, les statistiques de visite propres à Lovable. La doc dit qu’elles sont activées par défaut, qu’elles suivent les visiteurs, les pages vues, le taux de rebond, la durée de visite, les sources de trafic et les appareils, et qu’elles « mesurent le trafic global, pas les personnes ». Elle ne dit pas ce qu’elles stockent, le cas échéant, dans le navigateur du visiteur. Ensuite, ce que vous avez demandé : « Add Google Analytics » place le snippet GA4 dans le head, « Add the Meta pixel » fait de même pour Facebook. Enfin, les embeds : une vidéo YouTube ou une Google Map dans un composant dépose des cookies dès que l’iframe se charge.

Ce qui n’arrive pas, c’est quoi que ce soit qui retienne ces scripts jusqu’à la décision du visiteur. Et si vous promptez « add a GDPR cookie banner », Lovable fait ce que fait tout agent de codage : il écrit un joli composant React avec un bouton Accepter qui pose un drapeau dans localStorage et ne bloque rien. C’est la bannière pour laquelle la CNIL a sanctionné SHEIN de 150 millions d’euros en septembre 2025, dans une plus jolie police. Cet article est l’alternative, et cela prend environ dix minutes.

Où va la balise

Un projet Lovable est une app Vite et React avec index.html à la racine. La balise de consentement est la première chose dans son head, et la plupart des prompts ne touchent jamais ce fichier, elle survit donc à la régénération.

Le runtime de consentement est une seule balise script, et elle doit être le premier élément dans <head> de index.html. Pas dans App.tsx, pas dans un useEffect, pas dans un composant de layout. Deux raisons. Le runtime installe son intercepteur de façon synchrone, donc tout ce qui s’exécute avant peut poser un cookie que le runtime ne peut pas reprendre. Et index.html est le seul fichier qu’un prompt Lovable ne réécrit presque jamais, la balise survit donc aux cinquante prochaines itérations de votre landing page.

Étape 1 : obtenir une clé

Créez un compte gratuit, ajoutez un site et saisissez le domaine sur lequel votre app est publiée. Si vous n’avez pas encore connecté de domaine personnalisé, c’est l’adresse lovable.app ; vous pourrez la changer plus tard sans toucher la balise. Ouvrez Installation et copiez la clé de production. Chaque site a aussi une clé preview, qui sert ce que vous avez publié en prévisualisation et qu’il faut utiliser sur l’URL d’aperçu de Lovable pendant les tests.

Étape 2 : le prompt

Dans l’offre gratuite, l’onglet Code de Lovable est en lecture seule, c’est donc l’agent qui fait la modification. Avec une offre payante, vous pouvez ouvrir index.html dans l’onglet Code et coller la balise vous-même, et avec la synchronisation GitHub activée, le faire dans votre propre éditeur et pousser. Quelle que soit la voie, l’instruction est la même, et l’important est ce qu’elle interdit.

Coller dans Lovable

Add this script tag as the very first element inside <head> of index.html, unchanged:

<script src="https://app.cookiecrumbs.eu/runtime/cc.js"
        data-cc-site="pk_live_…"
        data-cc-env="production"></script>

Then, for every analytics, advertising or social script already in index.html (Google Analytics, gtag, Meta Pixel, TikTok, Hotjar, Clarity), change type to "text/plain" and add data-cc-category="analytics" or data-cc-category="marketing". Do not build a cookie banner component. Do not change anything else.

Lisez le diff avant de l’accepter. Il doit ajouter quatre lignes en haut de index.html et changer l’attribut type de vos scripts de suivi. Si l’agent crée aussi un CookieBanner.tsx, refusez le changement et répétez la dernière phrase du prompt. Puis publiez.

Étape 3 : classer ce que l’app charge

Tout ce qu’une app Lovable a tendance à charger, qui l’a mis là, et la catégorie à laquelle cela appartient. Seule la première ligne est hors de votre code, c’est pourquoi vous scannez avant de faire confiance.

Dans le tableau de bord, lancez le premier scan. Il ouvre votre app publiée trois fois dans un vrai navigateur, consentement refusé, accordé par catégorie et accordé pour tout, et liste chaque requête et chaque cookie apparus avant un choix. Cette liste est la vérité sur votre app, quoi que dise l’historique des prompts.

L’essentiel de ce qu’il trouve se classe tout seul : GA4, Hotjar et Clarity sont des statistiques ; le pixel Meta, les balises TikTok et LinkedIn sont du marketing ; la session Supabase vit dans localStorage, est strictement nécessaire pour une app avec connexion et n’a pas besoin de consentement. Les iframes YouTube et Maps intégrées sont du marketing, et le runtime les remplace par un placeholder et un bouton « Paramètres des cookies » jusqu’à ce que la catégorie soit accordée.

La seule ligne que vous ne pouvez pas verrouiller avec une balise, ce sont les statistiques de visite propres à Lovable, car l’hébergement de Lovable les ajoute hors de votre code. Si le scan montre qu’elles stockent un identifiant dans le navigateur ou appellent un tiers, vous avez deux options honnêtes : les désactiver sous Project settings, General, Publishing, ou les lister dans votre déclaration cookies et les traiter comme des statistiques chargées avant le consentement, ce qui dans l’UE pose problème. Nous recommandons l’interrupteur. Des comptages côté serveur chez votre hébergeur ou vos propres statistiques derrière le consentement donnent les mêmes chiffres sans la question.

Étape 4 : publier, scanner, prouver

L’URL d’aperçu reçoit la clé preview, l’app publiée et le domaine personnalisé reçoivent la clé de production. Le scan et la vérification d’installation tournent toujours sur les URL en ligne.

Classez chaque résultat dans sa catégorie, renseignez les liens vers votre politique de confidentialité et, si vous êtes en Allemagne, vos mentions légales, et publiez la bannière. Puis lancez la vérification d’installation. Elle charge votre URL publiée comme un visiteur et confirme que le runtime s’est exécuté en premier et que rien de non essentiel n’a tiré avant un choix. Cette coche, avec son horodatage, est l’artefact que vous conservez. Prenez aussi une capture d’écran du clic Refuser dans une fenêtre privée ; le panneau de stockage du navigateur ne doit ensuite montrer aucun cookie de statistiques ou de marketing.

Quand vous connecterez un domaine personnalisé plus tard, mettez à jour le domaine dans les paramètres du site pour que le scanner le suive. La clé ne change pas, la balise dans index.html reste donc telle quelle.

Si vous utilisez Google Analytics ou Google Ads avec des visiteurs de l’EEE, du Royaume-Uni ou de la Suisse, Google exige des signaux Consent Mode v2. Le runtime pousse les valeurs par défaut « denied » avant qu’une balise Google ne puisse s’exécuter, et les met à jour quand le visiteur décide, il n’y a donc rien à coder. Deux détails comptent spécifiquement dans une app Lovable. GA4 a besoin d’une page vue à chaque changement de route côté client, ce que gère l’habituel useEffect sur la location du routeur ; comme le script gtag lui-même est retenu jusqu’à l’accord pour les statistiques, ces appels s’empilent sans dommage d’ici là. Et gardez le snippet GA4 dans index.html, pas dans un composant, pour que le verrou text/plain s’y applique. La liste complète des signaux et le changement de juin 2026 sont dans l’article Consent Mode.

Ce qui se passe quand vous promptez de nouveau

Les prompts réécrivent src/. Ils touchent rarement index.html, mais « rebuild the landing page from scratch » ou « add the TikTok pixel » le peuvent, et un agent qui ajoute une balise l’ajoute en direct, pas verrouillée. Deux filets de sécurité couvrent cela. Le rescan planifié recharge l’app publiée consentement refusé et lève une alerte sur toute nouveauté avant le consentement, avec la date d’apparition. Et si la synchronisation GitHub est active, le diff de chaque prompt atterrit dans votre dépôt, où la vérification CLI peut bloquer un déploiement qui introduit un traceur non classé. Traitez l’alerte comme un test qui échoue : classez le nouveau fournisseur, publiez, c’est fait.

Checklist

La balise de consentement est le premier élément dans le head de index.html, avec la clé de production.
Chaque script de statistiques et de marketing dans index.html a type="text/plain" et une catégorie.
Les statistiques de visite de Lovable sont soit désactivées, soit expliquées dans la déclaration, après qu’un scan vous a dit ce qu’elles font.
Le premier scan a tourné sur l’URL publiée, chaque résultat a une catégorie, et la bannière est publiée.
La vérification d’installation est passée, et Refuser dans une fenêtre privée ne laisse aucun cookie de statistiques ou de marketing.
Les rescans planifiés sont activés, le prochain prompt ne peut donc pas ajouter un pixel en douce.

Si vous voulez la version courte avec les détails de l’offre gratuite, le guide d’intégration Lovable l’a, et le scan gratuit vous dit sans compte ce que votre app charge aujourd’hui.

Sources

Rédigé par l’équipe CookieCrumbs, publié le 5 septembre 2026. Chaque fait porte sa date ; si l’un d’eux a évolué, dites-le-nous et nous corrigerons.

Voyez ce que votre site charge avant le consentement

Le scan gratuit lit votre page d’accueil et liste les traceurs. Pas de compte, rien n’est stocké.

Lancer un scan gratuit Commencer gratuitement

Comment ajouter à une app Lovable une bannière cookies qui bloque vraiment les traceurs