Site créé avec l’IA ?

Avec les créateurs de sites par IA comme Lovable, Bolt ou v0, vous décrivez un site dans une fenêtre de discussion et le voyez apparaître en quelques minutes. Vous tapez « une page d’accueil pour mon studio de yoga avec un formulaire de réservation », et l’outil écrit le code, généralement en React (une façon très répandue de construire des pages web) mis en forme avec Tailwind CSS. Mais l’outil fait surtout ce que vous lui demandez. Si l’accessibilité ne figure pas dans vos instructions, elle est laissée au hasard, et un site peut sembler soigné tout en restant difficile à utiliser pour les personnes qui naviguent au clavier, qui utilisent un lecteur d’écran (un logiciel qui lit l’écran à voix haute) ou qui ont besoin d’un contraste plus fort. Quelques instructions claires au départ et une vérification simple ensuite évitent la plupart des problèmes courants. Cet article vous donne les deux, prêts à copier.

Pourquoi l’accessibilité passe à la trappe

Créer un site en discutant avec une IA s’appelle souvent le « vibe coding », un terme lancé par Andrej Karpathy en février 2025. Lovable, Bolt (bolt.new) et v0 de Vercel font partie des outils les plus connus pour cela. Tous trois permettent d’enregistrer des instructions permanentes, appliquées à chaque demande : Lovable et Bolt appellent cela « knowledge » et les rangent dans les paramètres du projet, et v0 permet d’enregistrer des instructions (via le bouton + de la zone de saisie) qui s’appliquent à chaque discussion tant que vous ne les désactivez pas. Certains outils s’appuient sur des composants prêts à l’emploi comme shadcn/ui, dont les menus et fenêtres de dialogue fonctionnent déjà au clavier, et la documentation de Lovable cite les vérifications d’accessibilité parmi ses compétences intégrées. Ce sont de bonnes bases, mais elles ne couvrent que ce que l’IA décide d’utiliser.

La raison de fond est que les modèles d’IA apprennent à partir du code web existant, et la majorité du web n’est pas accessible. Selon l’analyse 2026 de WebAIM portant sur le million de pages d’accueil les plus visitées, 95,9 % présentaient des erreurs détectables par des tests automatiques. Un texte trop peu contrasté figurait sur 83,9 % des pages, des images sans texte alternatif sur 53,1 % et des champs de formulaire sans étiquette sur 51 %. Un outil qui apprend du site web moyen en reprend aussi les habitudes.

Les schémas à surveiller

Ces schémas apparaissent souvent dans les sites générés. Ce ne sont pas des affirmations sur un outil en particulier, et des instructions claires en évitent la plupart.

Des blocs cliquables qui ne sont pas de vrais boutons. Une carte ou un simple bloc (une « div » dans le code) réagit au clic de souris, mais la touche Tab ne l’atteint pas et un lecteur d’écran n’annonce pas qu’on peut l’activer.
Des palettes tendance mais peu contrastées. Des demandes comme « minimaliste » ou « tons pastel » produisent souvent du texte gris clair sur fond blanc, difficile à lire pour beaucoup de personnes.
Des boutons avec une simple icône, sans nom. Une icône de menu, une croix de fermeture ou une icône de réseau social qu’un lecteur d’écran annonce seulement comme « bouton ». WebAIM a trouvé des boutons vides sur 30,6 % et des liens vides sur 46,3 % des pages d’accueil.
Des champs avec un simple texte indicatif. Le texte gris à l’intérieur du champ disparaît dès que vous tapez, et aucune étiquette n’indique à quoi sert le champ.
Des images sans texte alternatif. Le texte alternatif est une courte description écrite d’une image, lue à voix haute par les lecteurs d’écran. Les sites générés l’oublient souvent ou y mettent « image » ou un nom de fichier.
Des animations partout. Apparitions en fondu, effets de parallaxe et carrousels qui défilent seuls. Le mouvement peut donner des vertiges à certaines personnes, c’est pourquoi les appareils proposent un réglage pour réduire les animations.
Des fenêtres qui perdent le clavier. Une fenêtre s’ouvre, mais Tab passe derrière, Échap ne fait rien ou il est impossible d’en sortir.
Pas de langue de page et des titres en désordre. Sans langue définie, un lecteur d’écran risque de lire votre texte français avec un accent anglais. Des titres choisis pour leur taille cassent la structure de la page.

Les instructions d’accessibilité à coller en premier

Collez le bloc ci-dessous dans les instructions permanentes de votre outil avant de générer la première version, ou en tête de votre premier prompt si l’outil n’en propose pas. Il fait référence aux WCAG, les règles pour l’accessibilité des contenus web publiées par le W3C, la norme internationale sur laquelle reposent la plupart des exigences d’accessibilité.

Nous donnons volontairement ces instructions en anglais. Les créateurs de sites par IA comprennent le français, mais des instructions en anglais donnent en général les résultats les plus prévisibles, car les termes correspondent exactement à ceux du code. Votre site reste bien en français : les points 6 et 8 demandent à l’outil de définir le français comme langue de la page et d’écrire les noms des boutons en français.

Accessibility requirements for this whole project. Aim for WCAG 2.2 level AA. Follow these rules in every change, and tell me when a request would conflict with them. All visible text on the site is in French.

1. Use real buttons for actions and real links for navigation. Never make a div, span or card clickable on its own. If a whole card should be clickable, put a real link inside it.
2. Every form field has a visible label that stays visible while typing. A placeholder is never the only label. Error messages appear in text next to the field and explain how to fix the problem.
3. Every meaningful image has alt text in French that describes what it shows or does. Decorative images get an empty alt (alt=""). Ask me when you cannot know what an image means.
4. Text has a contrast ratio of at least 4.5:1 against its background. Large text (24px, or about 19px bold) and icons, field borders and focus indicators need at least 3:1. This includes dark mode and text on images or gradients.
5. Every link, button and form field has a clearly visible keyboard focus style. Never remove the focus outline without a visible replacement.
6. Every icon-only button or link has a name in French that says what it does, such as "Ouvrir le menu" or "Fermer la fenêtre".
7. Each page has one h1 that describes it, and headings follow in order (h2, then h3) without skipping levels. Never choose a heading level for its size.
8. Set the page language on the html element to French (lang="fr") and give every page a unique, descriptive title.
9. Everything works with a keyboard alone. Tab moves in a logical order, Enter and Space activate buttons, menus open and close with the keyboard, and Escape closes dialogs and menus. When a dialog opens, move focus into it, keep it there until it closes, then return focus to the button that opened it.
10. Respect the prefers-reduced-motion setting by turning off parallax, auto-playing carousels and large movement when it is on. Nothing moves automatically for more than five seconds without a way to pause it.
11. Tap targets are at least 24 by 24 pixels, and main buttons and menu items at least 44 by 44 pixels on mobile, with space between them.
12. Use header, nav, main and footer, and add an "Aller au contenu principal" skip link as the first item on every page.
13. Never use colour alone to convey meaning, such as red for errors. Add text as well.
14. Keep the built-in keyboard and screen reader behaviour of the components you use.

Le rapport de contraste compare la luminosité du texte à celle de son arrière-plan, de 1:1 (aucune différence) à 21:1 (noir sur blanc). La taille minimale de 24 sur 24 pixels pour les zones à toucher fait partie des exigences ajoutées par les WCAG 2.2 ; 44 sur 44 est plus exigeant et plus confortable pour les doigts.

Des prompts pour corriger des problèmes précis

Après une vérification, demandez une seule correction à la fois : des prompts courts et ciblés donnent des résultats plus fiables qu’une longue liste. Ces prompts sont eux aussi en anglais. Remplacez les parties entre crochets par ce qu’indique votre rapport.

Boutons sans nom : « The report says buttons have no name. Give every icon-only button an accessible name in French that says what it does, such as 'Ouvrir le menu'. Do not change how they look. »
Contraste insuffisant : « The report says text in [the footer] has too little contrast. Adjust the colours until all text reaches at least 4.5:1, or 3:1 for large text. Stay close to the brand colours and tell me the new values. »
Étiquettes manquantes : « The report says form fields have no label. Add a visible label in French above every field in [the contact form], connected to its field. »
Texte alternatif manquant : « The report says images have no alt text. List every image on this page and suggest alt text in French for each. Mark decorative images for an empty alt. Wait for my approval before applying. »
Accès au clavier : « I cannot reach [the pricing cards] with the Tab key. Replace clickable divs with real buttons or links so everything works with the keyboard, in a logical order. »
Focus invisible : « When I press Tab, I cannot see where I am. Add a clear focus style to every link, button and field, with at least 3:1 contrast against the background. »
Fenêtres surgissantes : « The [booking] pop-up does not work with the keyboard. Move focus into it when it opens, keep Tab inside, close it with Escape and return focus to the button that opened it. »
Langue et titres : « The report says the page language is missing and headings skip levels. Set the page language to French and fix the heading order without changing how the headings look. »

Une méthode qui fonctionne : prompter, publier, vérifier, recommencer

Inutile de savoir lire le code pour garder votre site en bon état. Il vous faut une boucle à répéter jusqu’à ce que les problèmes importants aient disparu.

Promptez avec les instructions. Ajoutez le bloc avant toute génération, ou demandez à l’outil de vérifier un projet existant par rapport à ces règles.
Publiez une version de prévisualisation. Mettez le site ou une préversion à une adresse web publique. Une vérification ne peut pas atteindre une page visible seulement dans l’outil ou derrière une connexion.
Vérifiez avec ibin. Le rapport indique ce qui ne va pas, qui est concerné et où cela se trouve sur la page, avec des gros plans.
Recollez les problèmes dans l’outil. Utilisez la description en langage clair ou les prompts ci-dessus. Les détails techniques sous « Code pour votre développeur » peuvent aussi être collés dans l’outil.
Vérifiez à nouveau jusqu’à ce qu’il ne reste plus de problème marqué « Critique », puis traitez le reste. Connectez-vous ensuite pour vérifier jusqu’à 200 pages du même site, car ces outils répètent le même en-tête, le même pied de page et les mêmes formulaires partout.
Faites le test au clavier et relisez votre propre contenu, comme décrit ci-dessous.

Le test au clavier en dix minutes

Les vérifications automatiques trouvent beaucoup de problèmes courants, en gros un tiers à la moitié de tous les problèmes, mais pas tout. Mettez la souris de côté et faites ce test sur votre page d’accueil et votre formulaire le plus important.

Appuyez sur Tab en haut de la page. « Aller au contenu principal » est-il la première chose atteinte, et voyez-vous toujours où vous êtes ?
Continuez avec Tab. Atteignez-vous chaque lien, bouton et champ, dans un ordre qui suit la page ?
Ouvrez et fermez le menu avec Entrée et Échap.
Remplissez et envoyez le formulaire uniquement au clavier. Les messages d’erreur sont-ils clairs ?
Ouvrez une fenêtre surgissante. Pouvez-vous la fermer avec Échap et reprendre là où vous étiez ?
Activez la réduction des animations dans les réglages d’accessibilité de votre appareil et rechargez la page. Les grandes animations s’arrêtent-elles ?
Zoomez à 200 %. Tout le texte reste-t-il lisible ?

Ce que l’IA ne peut pas savoir

Certaines choses échappent à tout outil et à toute vérification automatique, parce qu’elles dépendent de votre objectif et de votre public.

Si la description d’une image est juste. L’IA écrira peut-être « femme souriante devant un ordinateur », mais elle ne sait pas que la photo montre votre fondatrice, ni qu’un graphique doit montrer que les réservations ont doublé.
Si les textes de liens ont du sens. Six liens « En savoir plus » déroutent la personne qui se fait lire la liste des liens. « En savoir plus sur nos cours de yoga » fonctionne partout.
Si votre texte est clair. Des phrases courtes et des mots courants aident tout le monde, y compris les personnes qui lisent dans une langue seconde.
Si les étapes sont logiques. Un parcours de réservation peut réussir tous les tests automatiques et rester déroutant.

Il en va de même pour tout ce que vous ajoutez après la mise en ligne : chaque nouvelle image a besoin d’un texte alternatif, chaque nouveau lien d’un texte qui dit où il mène. Le second regard de l’IA, proposé en option par ibin, note les descriptions d’images, les textes de liens, l’utilisation au clavier et la clarté du langage de 1 à 5, pour vous montrer où regarder en premier. C’est toujours une personne qui tranche, et si possible, demandez à quelqu’un qui utilise chaque jour un clavier ou un lecteur d’écran d’essayer votre site.

Vérifiez votre site créé avec l’IA

Publiez une version de prévisualisation et vérifiez gratuitement une page avec ibin. Collez les problèmes décrits en langage clair dans votre outil avec les prompts ci-dessus, vérifiez à nouveau et consultez les guides d’accessibilité pour comprendre une correction. Une fois votre page d’accueil en bon état, connectez-vous pour vérifier gratuitement jusqu’à 200 pages du même site.

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.

Site créé avec l’IA ? Rendez-le accessible dès le premier prompt