Surveillance Lovable : vérifier la vitesse de votre app depuis le chat Lovable après chaque changement

Ce que vous mettez en place

Une boucle en quatre temps : vous construisez dans Lovable, vous publiez, vous demandez à Lovable de lancer le moniteur Core Web Vitals de Relvato sur l’app publiée, et Lovable lit le résultat et corrige ce qui a reculé. Les chiffres viennent de Relvato, qui charge votre page dans un vrai Chrome, sur un téléphone bridé et sur ordinateur — pas d’une estimation de Lovable.

Il vous faut un compte Relvato (l’offre gratuite suffit : les exécutions lancées depuis le chat sont manuelles, et l’offre gratuite en inclut 100 par mois), un compte Lovable sur n’importe quelle offre (les serveurs MCP personnalisés sont disponibles sur toutes les offres Lovable, gratuite comprise) et une app publiée. Relvato mesure l’adresse publiée — le sous-domaine lovable.app ou votre domaine personnalisé —, jamais l’aperçu de l’éditeur, car c’est l’adresse publiée que chargent vos visiteurs.

Si « MCP server » est grisé à l’étape 2, un administrateur a désactivé les serveurs MCP personnalisés pour votre espace de travail Lovable ; demandez-lui de les autoriser.

Étape 1 — Créer une clé d’API Relvato pour Lovable

Dans Relvato, ouvrez le menu du compte → API access. Donnez à la clé un nom que vous reconnaîtrez, par exemple « Lovable ». Sous What the key may do, choisissez Full access : une clé Read-only peut lire les résultats mais pas lancer un moniteur, et c’est justement le but ici.

Cliquez sur + Create API key et copiez la clé tout de suite : Relvato ne l’affiche qu’une fois. Elle commence par rlv_. Vous pouvez la révoquer à tout moment depuis la même page, ce qui coupe Lovable sans toucher au reste.

Étape 2 — Ajouter Relvato comme connecteur de chat dans Lovable

Dans Lovable, ouvrez Connectors (depuis la barre latérale du tableau de bord ou dans un projet), cliquez sur le bouton + en haut à droite du catalogue et choisissez MCP server. Renseignez Server name : « Relvato », et Server URL avec l’adresse ci-dessous. Pour l’authentification, choisissez Bearer token or API key, collez votre clé rlv_ et cliquez sur Add server.

La connexion est personnelle : vous vous êtes connecté avec votre propre clé, vous seul pouvez l’utiliser, et elle ne fait jamais partie de l’app que vous publiez — vos visiteurs ne peuvent pas atteindre Relvato par ce biais. Les coéquipiers qui veulent la même boucle ajoutent Relvato eux-mêmes, avec leur propre clé.

https://app.relvato.com/api/mcp

Étape 3 — Ajouter votre app à Relvato depuis le même chat

Si l’app est déjà dans Relvato, passez cette étape. Sinon, inutile de quitter Lovable. Demandez : « Avec Relvato, ajoute mon app https://votre-app.lovable.app comme site (plateforme : other). » Relvato répond avec une balise de vérification qui prouve que le site vous appartient, comme la ligne ci-dessous.

Demandez à Lovable de placer cette balise dans le head de la page (dans index.html pour les apps créées avant mai 2026, dans le layout racine pour les plus récentes), publiez avec Publish → Publish changes, puis demandez « Vérifie mon site dans Relvato. » Dès que Relvato trouve la balise, le site est prêt. Si l’app a un domaine personnalisé, ajoutez cette adresse plutôt que celle en lovable.app : c’est celle qu’utilisent vos visiteurs, et Lovable n’y redirige les autres que de façon temporaire.

<meta name="relvato-site-verification" content="…">

Étape 4 — Ajouter le moniteur Core Web Vitals

Demandez : « Ajoute le moniteur Core Web Vitals de Relvato à mon site. » Lovable appelle l’outil add_checks de Relvato avec le moniteur web-vitals. Il mesure une page — l’accueil, sauf si vous en choisissez une autre dans les réglages du moniteur dans Relvato.

Chaque exécution charge la page trois fois sur un téléphone au réseau et au processeur bridés (le même profil Slow 4G et 4× CPU que PageSpeed) et trois fois sur ordinateur, et garde la médiane : Largest Contentful Paint, Cumulative Layout Shift, Time to First Byte, First Contentful Paint, Total Blocking Time et une estimation en laboratoire de l’Interaction to Next Paint, plus un score de 0 à 100 par appareil.

Étape 5 — Après chaque publication, demander une exécution

Prenez l’habitude : publiez d’abord (Publish → Publish changes), puis envoyez un prompt comme « Lance le moniteur Core Web Vitals de Relvato sur mon site, attends la fin et compare le LCP, le CLS et le TTFB sur mobile avec l’exécution précédente. » Lovable lance l’exécution avec trigger_scan, puis la lit avec get_run jusqu’à la fin — en général en une minute environ.

Lovable demande avant d’utiliser un outil MCP, sauf si le serveur le marque en lecture seule. Relvato marque ainsi ses outils de lecture (site_overview, list_runs, get_run, get_fix_prompt) : seuls le lancement d’une exécution ou une modification demandent confirmation. Choisissez Always allow pour trigger_scan si vous ne voulez pas la question à chaque fois.

Chaque exécution compte dans les exécutions mensuelles de votre offre Relvato, et Lovable décompte les appels d’outils de vos crédits comme pour tout autre connecteur.

Étape 6 — Laisser Lovable corriger ce qui a ralenti

Les détails de l’exécution disent à Lovable pourquoi un chiffre a bougé, pas seulement qu’il a bougé : l’élément qui a fait le Largest Contentful Paint et la durée de chacune de ses phases, les éléments qui ont décalé la mise en page, les scripts qui ont bloqué le rendu, les images trop lourdes et la part de JavaScript inutilisée. De quoi faire modifier la bonne ligne au lieu de deviner.

Essayez : « Utilise les détails de cette exécution Relvato pour corriger le recul du LCP sur mobile, puis publie et relance le moniteur. » Pour une exécution qui a échoué, « Récupère le brief de correction Relvato pour cette exécution » renvoie le même brief que Suggest a fix dans Relvato. Relisez la modification de Lovable comme n’importe quelle autre, publiez, et laissez l’exécution suivante confirmer la correction.

Anciennes apps Lovable : ce que le navigateur attend vraiment

Les apps Lovable créées à partir du 13 mai 2026 sont rendues côté serveur. Les plus anciennes sont des applications monopage rendues côté client : le navigateur reçoit une page presque vide et attend le bundle JavaScript avant de pouvoir afficher le contenu principal. Lovable ne sert une copie pré-rendue qu’aux robots d’exploration vérifiés des moteurs de recherche, si bien que les scanners qui ne récupèrent que le HTML peuvent voir une page vide.

Relvato ne se contente pas du HTML : il charge la page dans Chrome comme un visiteur, donc son LCP inclut cette attente du bundle. Si le LCP mobile d’une ancienne app est élevé et que l’élément LCP n’apparaît qu’après l’exécution du JavaScript, c’est le bundle qu’il faut alléger — et le découper est une modification que Lovable peut faire pour vous.

Le faire tourner sans demander (facultatif)

Les exécutions depuis le chat ont lieu quand vous les demandez. Pour que Relvato relance de lui-même tous les moniteurs actifs à chaque changement de code, connectez le dépôt GitHub avec lequel Lovable se synchronise — voir connecter votre site à GitHub. Ce déclencheur nécessite l’offre Pro de Relvato ou supérieure.

Une nuance : Lovable pousse vers GitHub pendant que vous modifiez, parfois avant que vous publiiez, si bien qu’une exécution déclenchée par le push peut mesurer la version encore en ligne. L’exécution que vous lancez depuis le chat après Publish changes mesure exactement ce que vous avez publié.