Lovable transforme une conversation en site web ou en application qui fonctionne. Il écrit un code solide et moderne, mais il construit ce que vous demandez : si l’accessibilité ne fait pas partie de la demande, quelques problèmes reviennent de projet en projet. Ce guide montre ce que Lovable génère, quels problèmes surveiller, où placer des instructions pour que Lovable les suive à chaque modification et comment vérifier le résultat.
Ce que Lovable construit
Lovable écrit du React (une façon très répandue de construire des pages web) en TypeScript, mis en forme avec Tailwind CSS. Depuis le 13 mai 2026, les nouveaux projets reposent sur TanStack Start, un framework React qui prépare les pages sur le serveur pour qu’elles se chargent plus vite et soient mieux lues par les moteurs de recherche. Les projets plus anciens sont en général des applications d’une seule page construites avec Vite. Pour les données, les connexions et les fichiers, Lovable utilise Supabase, directement ou via Lovable Cloud.
La plupart des éléments d’interface viennent de shadcn/ui, une collection de composants prêts à l’emploi construits sur Radix. Les menus, boîtes de dialogue, onglets et listes déroulantes de cette collection fonctionnent au clavier et donnent les bonnes informations aux lecteurs d’écran (des logiciels qui lisent l’écran à voix haute). C’est un bon départ, mais cela n’aide que là où Lovable utilise vraiment ces composants et conserve leur comportement.
Les problèmes fréquents
Ces schémas reviennent souvent dans les sites générés. Ce ne sont pas des défauts de chaque projet Lovable, et des instructions claires en évitent la plupart.
- Des boutons réduits à une icône. Lovable utilise le jeu d’icônes Lucide pour les menus, les croix de fermeture, la recherche, les réseaux sociaux et « ajouter au panier ». Sans nom dans le code, un lecteur d’écran annonce seulement « bouton ».
- Des erreurs affichées uniquement dans un toast. Un toast est le petit message qui apparaît dans un coin et disparaît après quelques secondes. Quand une erreur de formulaire ne s’affiche que là, on la manque, et rien à côté du champ n’explique quoi corriger.
- Un texte atténué trop peu contrasté. Le thème par défaut utilise un gris doux pour le texte secondaire. Sur du blanc, et surtout sur des cartes gris clair, il passe souvent sous le contraste minimal.
- Une langue de page absente ou erronée. La langue de la page indique au lecteur d’écran quelle prononciation utiliser. Un site en français qui se déclare « anglais » est lu avec un accent anglais.
- Des cartes et des blocs cliquables. Une fiche produit ou un bloc tarifaire qui réagit au clic de souris sans être un vrai lien ou un vrai bouton reste inaccessible avec la touche Tab.
- Des champs avec un simple placeholder. Le texte gris d’exemple dans un champ disparaît dès qu’on commence à taper.
Où placer des instructions permanentes
Lovable appelle ses instructions permanentes Knowledge. Elles accompagnent chaque demande : vous n’écrivez vos règles d’accessibilité qu’une fois.
- La knowledge du projet s’applique à un seul projet. Ouvrez les paramètres du projet en cliquant sur son nom dans la barre du haut puis sur Settings, ou appuyez sur Ctrl+. (Cmd+. sur Mac), puis allez dans la section Knowledge. La documentation de Lovable décrit ce chemin.
- La knowledge de l’espace de travail (workspace) s’applique à tous les projets de votre espace. Si vous construisez plusieurs sites, mettez-y les règles d’accessibilité et gardez la knowledge du projet pour les couleurs de marque et le contenu.
Gardez la knowledge courte, sous forme de puces. Les noms de menus changent de temps en temps : cherchez « Knowledge » si le chemin ci-dessus a bougé.
Lovable propose aussi des skills, des procédures réutilisables que l’on lance en tapant une barre oblique dans la discussion. L’une des skills intégrées est /accessibility, qui passe en revue et corrige des problèmes d’accessibilité courants. Pratique pour une séance de relecture, mais ce n’est pas un remplacement de la knowledge : une skill agit quand vous l’appelez, la knowledge compte à chaque modification.
Instructions pour Lovable
Collez ce texte dans la knowledge du projet ou de l’espace de travail. Adaptez la langue si votre site n’est pas en français.
Règles d’accessibilité pour chaque modification (objectif : WCAG 2.2 niveau AA) : - Utilise des éléments sémantiques : header, nav, main, footer, un vrai <button> pour les actions et un vrai <a> ou Link du routeur pour la navigation. Ne mets jamais onClick sur un div, un span ou une Card. Si une carte entière est cliquable, place un vrai lien à l’intérieur. - Chaque Button réduit à une icône (Lucide) reçoit un aria-label dans la langue du site, par exemple "Ouvrir le menu". L’icône elle-même est aria-hidden. - Chaque Input, Select et Textarea a un Label visible qui lui est lié. Un placeholder n’est jamais la seule étiquette. - Les erreurs de formulaire apparaissent en texte à côté du champ et lui sont liées. N’affiche jamais une erreur uniquement dans un toast. - Le contraste du texte est d’au moins 4,5:1, 3:1 pour les grands textes. Vérifie text-muted-foreground sur chaque fond, y compris les cartes et le mode sombre, et fonce-le si nécessaire. - Garde l’anneau de focus visible sur tous les éléments interactifs. Ne le supprime jamais. - Mets lang="fr" sur l’élément html et donne à chaque page un titre unique. - Un seul h1 par page, titres dans l’ordre. Ne choisis pas un niveau de titre pour sa taille. - Conserve le comportement clavier des composants shadcn/ui et Radix. Les boîtes de dialogue se ferment avec Échap et rendent le focus. - Les images porteuses de sens ont un texte alternatif qui décrit leur rôle ; les images décoratives ont alt="". - Respecte prefers-reduced-motion pour les animations.
Prompts de suivi pour les problèmes courants
Après une vérification, demandez une correction à la fois. Remplacez les parties entre crochets.
- Boutons-icônes : « Donne à chaque bouton réduit à une icône dans [l’en-tête et le pied de page] un nom clair en français qui dit ce qu’il fait. Ne change pas leur apparence. »
- Erreurs dans un toast : « Dans [le formulaire de contact], affiche chaque erreur en texte sous le champ concerné, liée à ce champ. Garde le toast seulement en complément. »
- Texte atténué : « Le texte secondaire gris manque de contraste sur [les cartes de tarifs]. Fonce la couleur du texte atténué jusqu’à atteindre au moins 4,5:1 sur chaque fond où il apparaît, en mode clair et sombre. »
- Langue de la page : « Indique le français (fr) comme langue sur chaque page. »
- Cartes cliquables : « Je n’atteins pas [les cartes de projets] avec la touche Tab. Remplace la fonction de clic sur la carte par un vrai lien autour du titre, pour que la carte fonctionne au clavier. »
Après une modification plus importante, vous pouvez aussi lancer /accessibility, puis revérifier la page avec ibin.
Publier et vérifier
ibin vérifie les pages sur le web public : il lui faut une adresse que tout le monde peut ouvrir.
- Publiez. Cliquez sur Publish en haut à droite de l’éditeur. Lovable propose une adresse en lovable.app, que vous pouvez modifier. Les liens d’aperçu partagés servent à montrer un travail à une personne et expirent après sept jours : utilisez l’adresse publiée pour vos vérifications.
- Assurez-vous que le site est public. Avec certaines formules, vous pouvez limiter l’accès au site publié aux membres de votre espace. Un outil de vérification ne peut pas se connecter : choisissez Public pendant vos vérifications.
- Vérifiez la page avec ibin. Commencez par la page d’accueil, puis votre formulaire le plus important.
- Collez la correction dans Lovable. Chaque problème du rapport a un bouton « Copier les instructions pour un outil d’IA ». Collez le résultat dans la discussion Lovable. Il demande une correction dans le site lui-même.
- Republiez et revérifiez. Les modifications n’arrivent à l’adresse publique qu’après publication.
- Vérifiez davantage de pages. Connectez-vous pour vérifier jusqu’à 200 pages du même site, et activez les vérifications hebdomadaires pour repérer les problèmes qui reviennent.
Les vérifications automatiques trouvent environ un tiers à la moitié des problèmes. Faites donc aussi le test clavier en dix minutes.
Ce que Lovable ne peut pas juger
Certaines choses dépendent de connaissances que vous seul avez. Lovable décrira peut-être une photo comme « équipe au travail dans un bureau », sans savoir qu’elle montre vos trois fondateurs. Il ne peut pas juger si « En savoir plus » se comprend quand un lecteur d’écran énumère tous les liens d’une page, ni si votre texte se lit facilement. Relisez vous-même les descriptions d’images et les textes de liens à chaque ajout de contenu. Le second regard de l’IA, proposé en option par ibin, les note de 1 à 5 pour vous montrer par où commencer, mais c’est une personne qui tranche.
Pour la démarche générale, valable dans tous les outils, consultez la vue d’ensemble pour les créateurs IA. Les guides de correction expliquent chaque problème en langage clair, par exemple les boutons sans nom et le contraste des couleurs.
Vérifiez votre site Lovable
Publiez votre projet et vérifiez gratuitement une page avec ibin. Copiez les instructions de chaque problème dans Lovable, republiez et revérifiez jusqu’à ce que les problèmes urgents aient disparu.
Voyez où en est votre site
Vérifiez gratuitement une page, sans compte. Vous recevez une liste claire de ce qu’il faut corriger en premier, avec des images de l’endroit où se trouve chaque problème.