Trois machines, et surtout : des chiffres réels
La plupart des comparatifs d’outils IA tournent à l’éloge ou au trash-talk. Nous, on a fait l’inverse : on a mesuré. Plutôt que des impressions, deux sources de preuves. D’un côté, un échantillon de 8 sites de production réellement construits avec Lovable, Bolt et v0, passés au crible de Lighthouse. De l’autre, les études publiées sur l’indexation et la sécurité de ces builders. Verdict factuel, sources à l’appui — et les limites de la méthode assumées.
Pour fixer l’enjeu, gardons en tête un cas typique (hypothétique) : une PME B2B de services — disons un cabinet de conseil RH de 12 personnes en Île-de-France — qui veut un site vitrine de 5 pages, un formulaire qui marche vraiment, et être trouvable sur Google pour « cabinet conseil RH Paris ». La question n’est pas « est-ce que c’est joli ? » mais « est-ce que ça performe, c’est indexé, c’est fiable ? ».
Notre méthode (et ce qu’elle vaut)
On a identifié 8 sites publics réellement issus de ces outils — via la galerie officielle de Lovable, les gagnants badgés du hackathon Bolt, et une attribution v0 déclarée par un fondateur. Chacun a été mesuré avec Lighthouse 13.3 (profil mobile), et son indexation vérifiée via une recherche site:domaine.
Honnêteté sur les limites : ce sont des mesures lab (un run par site), pas des Core Web Vitals « terrain » (field/CrUX) — l’API publique PageSpeed était en quota dépassé au moment du test. L’échantillon (8 sites : 4 Lovable, 3 Bolt, 1 v0) est de commodité, pas statistiquement représentatif. On ne prétend donc pas à une moyenne du marché — mais à des observations concrètes, vérifiables, non inventées, recoupées avec des études tierces.
Performance : 7 sites sur 8 sous le seuil Google
Le seuil de Google pour un « bon » LCP est de 2,5 secondes. Sur nos 8 sites mesurés, 7 le dépassent, parfois très largement (jusqu’à 9,1 s). Les scores de performance Lighthouse s’étalent de 49 à 95.
| Site mesuré | Outil | Perf | LCP | CLS | Pages indexées |
|---|---|---|---|---|---|
| chromegoldmine.com | Lovable | 58 | 4,2 s | 0,732 | Oui (blog) |
| pianovst.com | Lovable | 65 | 6,3 s | 0,006 | Oui (riche) |
| estimatekit.com | Lovable | 49 | 4,6 s | 0,002 | Oui (blog) |
| unitatlas.com | Lovable | 62 | 9,1 s | 0,017 | Faible (3) |
| weight.coach | Bolt | 84 | 3,7 s | 0 | Faible (2) |
| keyhaven.app | Bolt | 95 | 2,5 s | 0,009 | 1 page |
| klinva.com | Bolt | 87 | 3,1 s | 0,001 | 1 page |
| fairpriceindex.com | v0 | 94 | 3,0 s | 0 | Oui (riche) |
Deux constats. D’abord, la performance « par défaut » est inégale et souvent insuffisante : seuls les sites Bolt et v0 atteignent un bon score, mais en échouant quand même au LCP. Ensuite, un cas d’école de mise en page non maîtrisée : chromegoldmine affiche un CLS de 0,732, soit ~7× le seuil « médiocre » de Google — typiquement des images et polices sans espace réservé, qui font « sauter » la page pendant le chargement. Sur la performance brute, voir aussi notre guide Core Web Vitals.
SEO : c’est l’architecture qui décide, pas le logo
C’est le point le plus important, et le plus mal compris. Regarde la colonne « pages indexées » du tableau : keyhaven.app et klinva.com (Bolt) n’ont qu’une seule page indexée par Google, et unitatlas (Lovable) à peine trois. À l’inverse, fairpriceindex (v0) est richement indexé, tout comme les deux Lovable pré-rendus (pianovst, estimatekit).
La différence n’est pas le talent du builder : c’est l’architecture de rendu. Lovable et Bolt produisent par défaut une SPA React rendue côté client (CSR) — au premier passage, Googlebot reçoit une coquille quasi vide (<div id="root">, parfois moins d’1 Ko et zéro <h1>) ; le contenu n’apparaît qu’après exécution du JavaScript. v0, lui, repose sur Next.js, qui permet le rendu serveur (SSR/SSG) : le HTML complet est servi directement.
« Mais Google sait exécuter le JavaScript ! » C’est vrai — et trompeur. L’étude empirique de Vercel et MERJ (vendeur de v0/Next, à prendre avec cette réserve) montre que 100 % des pages sont rendues… avec un délai médian de 10 s et un p90 de plusieurs heures. Et Onely chiffre à 9× le temps nécessaire pour crawler du JS plutôt que du HTML. Sur un gros site à fort budget de crawl, ça passe. Sur le petit site neuf de notre cabinet RH, ça se traduit concrètement par… une seule URL indexée. Le rendu existe ; la fiabilité d’indexation à l’échelle d’un petit site, non.
Sécurité : le talon d’Achille documenté
Un site pro n’est pas qu’une vitrine — dès qu’il y a un backend (formulaires, comptes, base de données), la sécurité devient non négociable. Et là, les chiffres publics sont sévères :
- CVE-2025-48757 (Lovable) : un audit a trouvé ~10 % des apps scannées (170 sur 1 645) exposant des données à cause d’une sécurité Supabase (RLS) manquante ou cassée, révélé par Matt Palmer.
- Une app vitrine générée a fui 18 697 enregistrements, dont des milliers de comptes, d’après The Register.
- Plus largement, le code généré par IA contient 2,74× plus de vulnérabilités que le code humain (Veracode, synthèse).
Nuance utile : ce risque se concentre sur les builders qui livrent un backend (Lovable, Bolt). v0, centré sur le frontend Next.js, est classé plus bas sur ce plan. La sécurité n’est pas un détail qu’on ajoute « plus tard » — c’est ce qui distingue un prototype d’un site qui encaisse des données clients.
Hébergement, domaine, sauvegardes : ce qui n’est PAS inclus
Même quand le builder héberge et fournit un sous-domaine + HTTPS, plusieurs briques d’un site « adulte » manquent par défaut, et il faut les ajouter à la main :
- Domaine personnalisé correctement configuré (DNS, e-mails), et surtout dont tu restes propriétaire.
- Sauvegardes réelles du code et du contenu (un export GitHub, pas « la confiance dans la plateforme »).
- Monitoring uptime externe pour être prévenu quand le site tombe.
- Couche réseau / sécurité (type Cloudflare) et conformité RGPD de toute la stack (où vivent les données du formulaire ?).
Aucun de ces points n’est « hors sujet » : c’est exactement ce qui fait qu’un site tient dans le temps plutôt que de casser au sixième mois — un des 5 cas où l’IA seule te met dans le mur.
Lovable, Bolt, v0 : forces et limites de chacun
Lovable — le plus « fini » visuellement, le plus fragile dessous. Premier jet le plus présentable, itération design par simple conversation. Mais SPA rendue client (SEO fragile sans pré-rendu), formulaires non connectés par défaut, et c’est lui qui concentre les alertes sécurité ci-dessus.
Bolt — le plus « développeur », le moins accessible. Génère un vrai projet exportable, propre, avec une structure de fichiers : excellent point de départ pour un dev. Pour un non-technique, mur dès la première erreur console. Et par défaut, SPA = quasi rien d’indexé (cf. keyhaven, klinva).
v0 — le plus malin sur l’architecture, le plus limité sur le « site complet ». Adossé à Next.js, donc indexable nativement (le seul de l’échantillon richement indexé hors pré-rendu manuel). Excellente qualité de code par composant. Mais assembler un site cohérent (navigation, SEO transversal, maillage) suppose, là encore, des compétences.
Le tableau qui compte
| Critère | Lovable | Bolt | v0 |
|---|---|---|---|
| Rendu visuel immédiat | Excellent | Correct | Bon (par bloc) |
| Indexable sans retouche | Faible (CSR) | Faible (CSR) | Bon (SSR Next) |
| Performance mesurée (lab) | 49–65 | 84–95 | 94 |
| Formulaire réellement connecté | Non | Manuel | Non |
| Accessible à un non-technique | Oui (au début) | Non | Non |
| Risque sécurité backend | Élevé (documenté) | Moyen | Plus faible |
Aucun ne conclut « tout pareil » : forces nettes et distinctes. Mais aucun ne livre sans intervention humaine ce que demandait notre cabinet RH : un site indexé, avec un formulaire qui envoie vraiment, performant et maintenable.
Notre recommandation honnête
- Un prototype à montrer demain ? Lovable. Rapide, beau, suffisant pour valider une direction.
- Tu es développeur et tu veux gagner du temps au démarrage ? Bolt ou v0 selon que tu penses « site » ou « composants » — et v0 si l’indexation compte dès le départ.
- Un site qui ramène réellement des clients, indexé, fiable, qui dure ? Là, l’outil n’est plus la question — c’est l’accompagnement qui fait la différence.
Chez Peechy, on utilise ces outils en interne pour accélérer. Mais ce qu’on livre, c’est ce qui vient après le premier jet : un site pensé pour convertir, indexé, sécurisé, maintenu. La machine fait le brouillon. Le métier fait le résultat.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy