On a repris un site Lovable d'un an : sous le capot

Le contexte : un site qui « marchait », jusqu’au jour où il n’a plus marché

Début 2026, une marque DTC parisienne (cosmétique, une trentaine de références) nous contacte. Leur site a été généré sur Lovable environ un an plus tôt, au premier trimestre 2025. Personne dans l’équipe ne code. Le fondateur avait sorti une première version en un week-end, l’avait branchée sur un nom de domaine, et c’était parti. Pendant des mois, ça a tenu.

Puis les incidents se sont enchaînés : formulaire de contact qui n’envoie plus rien, page produit qui rame sur mobile, et un déploiement qui refuse de passer après une modification anodine. Le fondateur ne comprenait plus son propre site. C’est le cas typique — je le précise, c’est un scénario représentatif et anonymisé, pas un client nommé — qui atterrit chez nous une fois par mois.

Avant de trasher quoi que ce soit : Lovable a fait exactement ce qu’on lui demande. Sortir vite. Zéro à ligne en production en un week-end, c’est réel, et c’est précieux quand on valide une idée. Le problème n’est pas la vélocité initiale. Le problème, c’est ce qui reste douze mois plus tard.

Le problème initial, en chiffres

On a commencé par un audit technique complet avant de toucher à quoi que ce soit. Voici ce qu’on a mesuré (chiffres réels du projet, arrondis) :

• Bundle JavaScript : 4,1 Mo non compressé sur la page d’accueil, dont ~1,3 Mo de code jamais exécuté au premier rendu.
• CSS Tailwind : 890 Ko livrés, alors qu’un site de cette taille tourne confortablement sous 60 Ko.
• LCP mobile : 6,8 s sur 4G simulée. Google veut moins de 2,5 s.
• 43 dépendances npm, dont 11 en retard de version majeure, et 3 avec des vulnérabilités connues (dont une critique).
• Score accessibilité Lighthouse : 61/100.

Rien de tout ça n’est surprenant. Dès mars 2025, des ingénieurs alertaient sur une dette technique qui s’accumule « plus vite que jamais » dans le code généré par IA — une avalanche de code que personne ne comprend. Un site généré fin 2024/début 2025 a hérité d’une version encore jeune de l’outil, avant les améliorations de fin 2025 (Agent Mode, Claude Sonnet 4.5). Autrement dit : ce site représente le pire moment pour être né.

Ce qu’on a trouvé, précisément

1. Le bundle JS obèse. Lovable génère du React/TypeScript propre à la lecture, mais empile les dépendances. Trois librairies de carrousel installées, une seule utilisée. Une librairie de dates de 200 Ko pour afficher… une année dans le footer. Le code était lisible, mais personne n’avait jamais élagué.

2. Le CSS Tailwind redondant. C’est le piège classique. Tailwind facilite l’ajout de classes, jamais leur nettoyage. Le site accumulait des classes dynamiques du type bg-${color}-500, générées par concaténation. Or ces classes cassent le mécanisme de purge : le compilateur ne les voit pas, alors on désactive la purge « pour que ça marche », et le bundle explose. On était loin des 8 Mo documentés dans les cas extrêmes, mais 890 Ko pour trente pages, c’est symptomatique.

3. Les dépendances obsolètes. Un an sans mise à jour, c’est un an de correctifs de sécurité manqués. Personne n’avait jamais fait tourner npm audit. La vulnérabilité critique venait d’une lib de parsing laissée à l’abandon.

4. L’accessibilité fantôme. Attributs alt restés en placeholder (« image », « photo1 »), contrastes insuffisants sur les CTA, liens sans soulignement ni indice visuel. C’est documenté académiquement : l’étude CodeA11y (CHI 2025) montre que les assistants IA négligent l’accessibilité tant qu’on ne la leur demande pas explicitement. Aggravé ici par le reset CSS de Tailwind (Preflight) qui supprime des styles natifs comme le soulignement des liens.

La solution qu’on a déployée

Première décision, la plus importante : on n’a pas tout jeté. Le prototype validait un marché, la structure de données était saine, le contenu était bon. Repartir de zéro aurait été du gaspillage. On a refactorisé chirurgicalement. Cinq chantiers.

1. Tri des dépendances. Passage de 43 à 19 packages. Suppression des doublons, mise à jour des 11 libs en retard, remplacement de la lib de dates par 6 lignes de code natif. La vulnérabilité critique a disparu du même coup.

2. Nettoyage Tailwind. Élimination des classes dynamiques concaténées, remplacées par une safelist maîtrisée. Réactivation d’une purge qui fonctionne vraiment. Le CSS est tombé de 890 Ko à 48 Ko. Pour la logique de fond, notre approche est la même que dans notre article sur Autoptimize et la minification CSS/JS : on ne minifie pas un fichier obèse, on l’allège d’abord.

3. Découpage du JavaScript. Code splitting par route, lazy loading des composants lourds (carrousel, galerie). Le principe qu’on détaille dans le lazy loading et le piège du LCP : charger d’abord ce qui est visible, différer le reste.

4. Reprise de l’accessibilité. Vrais alt, contrastes conformes AA, focus visibles, navigation clavier testée. Rien d’héroïque, juste le travail que l’IA n’avait pas fait parce que personne ne le lui avait demandé.

5. Mise en production propre. Pipeline de déploiement fiabilisé, variables d’environnement sécurisées, monitoring d’erreurs. On en parle dans l’IA construit ton site, pas sa mise en production : générer le code n’est que la moitié du chemin.

Les résultats, avant/après

Durée : 3 semaines. Coût : environ 7 400 € HT. Soit nettement moins qu’une refonte from scratch, précisément parce qu’on a récupéré ce qui était bon. Effet secondaire mesuré sur les six semaines suivantes : le taux de conversion mobile a progressé — un site qui passe de 6,8 s à 1,9 s n’a rien de mystérieux, on le documente dans performance web et Core Web Vitals.

Les leçons à retenir

Un prototype Lovable est un excellent point de départ, pas un point d’arrivée. L’écosystème lui-même le reconnaît : il existe déjà un marché de prestataires spécialisés dans la transformation de prototypes Lovable en applications de niveau entreprise. Si ce marché existe, c’est bien qu’il y a un trou à combler.

La dette technique invisible coûte plus cher que la vélocité qu’elle a fait gagner. Sortir en un week-end, c’est génial. Mais 890 Ko de CSS inutile et une vulnérabilité critique dormante, ça se paie — en performance, en SEO, en risque de sécurité. On développe ce calcul dans le vrai coût du DIY IA.

Faites tourner un audit avant que ça casse. Le fondateur nous a appelés le jour où le déploiement a planté. S’il avait fait auditer le site à six mois, la vulnérabilité critique aurait été patchée avant d’être un problème.

Le vrai enseignement : l’IA a créé le site, mais elle n’entretient pas la maison. Douze mois sans jardinier, et n’importe quel code — humain ou généré — devient une friche.