A laptop showing an AI assistant generating alt text for a photograph, with bounding boxes around detected objects — the visual marker for AI-and-alt-text reporting.
Image description: A laptop showing an AI assistant generating alt text for a photograph, with bounding boxes around detected objects — the visual marker for AI-and-alt-text reporting.

Guide technique · IA + texte alternatif

IA et texte alternatif : ce que la technologie produit réellement en 2026

Un guide technique sur l'état de la génération automatique de texte alternatif par IA en 2026. Nous avons testé GPT-4o, Claude 3.7 Sonnet, Gemini 2.0, Llama-Vision-3 et Pixtral sur quatre catégories d'images et documenté exactement où la technologie tient ses promesses et où elle fabrique.

IA et texte alternatif
ce que la technologie produit réellement en 2026

Les modèles de vision-langage peuvent désormais décrire une photo informative avec une fluidité qui aurait semblé impossible en 2022. Ils hallucinent encore du texte sur les captures d’écran, attribuent un genre erroné aux sujets visiblement handicapés et inventent des noms de marque absents de l’image. Ce guide cartographie la frontière entre les deux.

5
modèles de vision évalués
4
catégories d’images testées
approx. 62%
plafond d’utilisabilité au premier passage
11 min de lecture
Mis à jour en mai 2026

1. La nature du problème en 2026

Le critère de succès 1.1.1 des WCAG 2.2 n’a pas changé depuis 2008. Toute image non textuelle qui véhicule un sens nécessite un texte alternatif ; toute image décorative doit être marquée comme telle. Ce qui a changé, entre la version de cet article que nous aurions rédigée en 2022 et celle que nous rédigeons en mai 2026, c’est que produire une phrase plausible à partir d’un tableau de pixels n’est plus le goulot d’étranglement. Produire une phrase exacte, contextuellement appropriée et exempte de détails fabriqués l’est encore.

Ce glissement est important car la plupart des CMS de production en 2026 proposent un bouton « texte alternatif automatique ». Ce bouton appelle un modèle de vision-langage via une API fournisseur et écrit le résultat directement dans l’attribut alt. La conséquence sur l’accessibilité est directe : si le bouton a raison, une image qui arrivait auparavant sans alt est désormais décrite à l’utilisateur d’un lecteur d’écran. Si le bouton a tort, l’utilisateur reçoit une phrase formulée avec assurance à propos de quelque chose qui n’est pas dans l’image.

Ce guide s’adresse aux ingénieurs qui possèdent ce bouton. Il passe en revue les cinq modèles de vision qui représentent l’écrasante majorité des intégrations vendeur en 2026, teste chacun d’eux sur les quatre catégories d’images canoniques, documente les modes d’échec récurrents et se termine par un flux de travail hybride que nous considérons comme le seul défaut défendable jusqu’à ce que le comportement sous-jacent évolue.

approx. 41%
des images d’un crawl représentatif de 500 grandes pages e-commerce américaines n’ont pas d’attribut alt ou ont un alt vide (analyse interne DW, mars 2026).
approx. 18%
des alts restants sont des noms de fichier générés automatiquement ou des formules par défaut comme « image » ou « produit » — présents, mais inutiles pour un utilisateur de lecteur d’écran.
approx. 11%
des alts sont générés par IA et non édités — identifiables par leur structure caractéristique en trois propositions sous-ordonnées (classifieur interne DW).
Ce que nous entendons par « tient ses promesses »

Un texte alternatif candidat généré par IA « tient ses promesses » si un relecteur humain l’accepterait tel quel, ou avec une modification d’un seul mot. Tout ce qui nécessite une réécriture est un échec. Il s’agit d’une barre plus haute que la métrique académique CIDEr ou BLEU qu’un modèle pourrait citer — c’est la barre qu’un bouton de CMS doit franchir.

« La conséquence sur l’accessibilité est directe : si le bouton a raison, une image qui arrivait auparavant sans alt est désormais décrite à l’utilisateur d’un lecteur d’écran. Si le bouton a tort, l’utilisateur reçoit une phrase formulée avec assurance à propos de quelque chose qui n’est pas dans l’image. »

— cet article, section 1

2. Le paysage des modèles en 2026

Cinq modèles de vision-langage dominent les intégrations que nous observons en production : deux modèles frontière fermés (GPT-4o vision, Claude 3.7 Sonnet vision), un modèle fermé très utilisé dans les produits Google et les extensions Workspace en aval (Gemini 2.0), et deux modèles à poids ouverts qui s’intègrent dans les plugins CMS auto-hébergés là où les règles de résidence des données excluent les API fermées (Llama-Vision-3, Pixtral). Chacun présente un profil distinct sur le test en quatre catégories ci-dessous.

Les fiches combinées ici résument le comportement pratique que nous avons observé sur approx. 600 images de test en mars et avril 2026, non les promesses marketing. Les coûts sont par image à résolution typique en mai 2026 et excluent la marge fournisseur.

GPT-4o vision
OpenAI · gpt-4o (build mai 2026)
Défaut d’API fermée le plus courant dans les CMS de marché intermédiaire
Point fortPhotos informatives, composition de scène
Point faibleHallucine le texte à l’écran
Coût approx. / imageapprox. 0,004 USD
Claude 3.7 Sonnet vision
Anthropic · claude-3-7-sonnet
Courant dans les CMS d’entreprise où la relecture éditoriale fait partie du flux de travail
Point fortRefuse d’inventer du texte illisible ; graphiques
Point faibleVerbeux ; nécessite une consigne de longueur explicite
Coût approx. / imageapprox. 0,005 USD
Gemini 2.0
Google · gemini-2.0-pro vision mode
Défaut dans les extensions Workspace, CMS liés à Google
Point fortCaptures d’écran, identification d’éléments d’interface
Point faibleIdentifie mal les aides à la mobilité, fabrique des noms de marque
Coût approx. / imageapprox. 0,003 USD
Llama-Vision-3
Meta · 90B vision, poids ouverts
Plugins CMS auto-hébergés, déploiements à résidence de données dans l’UE
Point fortPhotos, classification décorative
Point faibleGraphiques ; devine les valeurs d’axe
Coût approx. / imagecoût d’inférence auto-hébergée
Pixtral
Mistral · pixtral-large, poids ouverts
Auto-hébergement européen ; plugins à modèle léger
Point fortSorties concises ; respecte le budget de longueur
Point faibleRappel de composition de scène inférieur sur les photos complexes
Coût approx. / imagecoût d’inférence auto-hébergée

3. Le test en quatre catégories

Les recommandations WCAG pour le contenu non textuel se réduisent en pratique à quatre catégories : photos informatives (une personne, une scène, un objet porteur de sens) ; graphiques et diagrammes (un graphique à barres, un organigramme, une carte annotée) ; captures d’écran et interfaces (un tableau de bord, un état d’erreur, un panneau de paramètres) ; et décoratives (un dégradé d’en-tête, un séparateur, une illustration de remplissage). Nous avons constitué un jeu de test de 600 images en prélevant 150 images par catégorie dans des contextes d’actualité sur le handicap, des rapports d’associations, de la documentation logicielle et du remplissage éditorial. Chaque modèle a produit un texte alternatif candidat par image ; trois relecteurs humains ont classé chaque candidat en accepté, à modifier ou rejeté. La matrice ci-dessous indique le taux d’acceptation.

Ces chiffres ne visent pas à désigner un vainqueur. Ils visent à indiquer quelle catégorie est la plus risquée pour publier un candidat IA sans relecture.

ModèlePhotos informativesGraphiques & diagrammesCaptures d’écran & interfacesDécoratives (correctement null)
GPT-4o vision71%34%52%41%
Claude 3.7 Sonnet vision68%49%61%58%
Gemini 2.066%38%64%44%
Llama-Vision-3 (90B)62%21%47%53%
Pixtral large57%26%42%48%
Les deux colonnes à surveiller

Pour tous les modèles, les deux colonnes les plus faibles sont graphiques & diagrammes et décoratives (correctement null). La première échoue parce que le modèle invente des valeurs qu’il ne peut pas lire ; la seconde échoue parce que le modèle rédige une phrase alors que la bonne réponse est le silence. Ces deux erreurs sont invisibles pour un relecteur voyant qui ne vérifie que la colonne des photos.


4. Les quatre modes d’échec qui comptent

Les taux d’acceptation agrégés masquent la texture des erreurs. En examinant les candidats rejetés dans l’ensemble de test, quatre modes d’échec reviennent avec une fréquence suffisante pour rendre compte de la grande majorité des ratés. Nous les nommons ici afin que tout éditeur relisant une sortie IA sache quels schémas rechercher en premier.

1

Texte à l’écran halluciné

Le modèle écrit que l’axe d’un graphique est intitulé « Chiffre d’affaires T3 2024 » alors que le graphique affiche en réalité des comptages de pages vues ; le modèle écrit que le bouton d’une capture d’écran indique « Soumettre » alors qu’il indique « Enregistrer et continuer ». GPT-4o est le plus fautif ici ; Claude 3.7 Sonnet refuse le plus souvent, renvoyant une formule du type « un graphique dont l’étiquette d’axe n’est pas lisible à cette résolution ». Ce refus est le comportement correct, et ce qu’un bouton de CMS devrait exposer.

2

Identification erronée des sujets handicapés

Un fauteuil roulant motorisé devient « un scooter motorisé » ; une canne blanche devient « un bâton de marche » ; un sujet visiblement handicapé sur une photo de rassemblement militant est décrit comme « une personne assise sur une chaise regardant le défilé ». Ce schéma d’erreur reflète la composition des données d’entraînement. Aucun des cinq modèles testés n’a géré l’identification des aides à la mobilité à un taux que nous qualifierions de prêt pour la production, et la modification corrective est presque toujours nécessaire.

3

Perte de nuance contextuelle

Une photo de deux personnes pratiquant la langue des signes américaine est décrite comme « deux personnes gesticulant » ; une photo d’un chien d’assistance sous une table de restaurant est décrite comme « un chien dormant sous un meuble ». Les pixels sont décrits avec précision. Le sens que l’éditeur a voulu conférer à l’image ne l’est pas. La perte de nuance contextuelle est le mode d’échec que la matrice ne peut pas mesurer, et la raison pour laquelle un texte alternatif IA sans relecture éditoriale est, en pratique, un mauvais défaut.

4

Fabrication de noms de marque

Le modèle écrit qu’une photo de stock représentant un ordinateur portable est « un Apple MacBook » alors que l’ordinateur est un châssis générique sous Windows ; le modèle écrit qu’une tasse de café sans marque est « une tasse Starbucks ». Gemini 2.0 est le plus enclin à cette catégorie d’erreur dans notre jeu de test. La correction passe par une contrainte dans le prompt : il faut demander au modèle de refuser toute identification de marque à moins qu’un logo ou une marque déposée ne soit sans ambiguïté visible. Même avec cette contrainte, une vérification par échantillonnage reste nécessaire.

« Les pixels sont décrits avec précision. Le sens que l’éditeur a voulu conférer à l’image ne l’est pas. »

— cet article, mode d’échec 3

5. Le flux de travail hybride que nous recommandons

Traiter le texte alternatif IA comme « entièrement automatisé » ou « irresponsable » est un faux dilemme. Les chiffres par catégorie disent quelque chose de plus utile : les candidats IA sont utilisables comme premier jet dans la colonne photos et comme source de refus dans la colonne graphiques, et ils constituent un risque actif dans la colonne décorative à moins que le flux de travail ne dispose d’une option explicite « marquer comme décoratif ». Le bon défaut est un hybride, et les étapes ci-dessous constituent l’hybride que nous recommandons.

1

Router par catégorie d’image avant de générer

Un petit classifieur (quelques milliers de paramètres suffisent) détermine si l’image est une photo, un graphique, une capture d’écran ou décorative. La décision de routage détermine le prompt, le modèle et si l’on génère ou non. Les images décoratives ne doivent pas être envoyées au modèle : elles doivent être directement marquées décoratives et publiées avec un alt vide.

2

Utiliser Claude 3.7 Sonnet pour les graphiques et les captures d’écran

La matrice montre que Claude est en tête sur les deux colonnes où le refus est le comportement correct. Configurer le prompt pour exiger un refus explicite quand le texte n’est pas lisible, et pour signaler tout graphique dont les valeurs d’axe ne sont pas lisibles plutôt que de deviner. Exposer le refus dans le CMS comme un état « description humaine requise », et non comme un alt vide.

3

Utiliser GPT-4o ou Gemini 2.0 pour les photos, avec une contrainte sur les noms de marque

Pour la colonne photos informatives, l’un ou l’autre modèle produit des taux d’acceptation supérieurs à approx. 65%. Ajouter une instruction dans le prompt pour ne jamais identifier un nom de marque à moins qu’un logo ou une marque nominale ne soit sans ambiguïté dans le cadre. Limiter la longueur de sortie à 125 caractères pour décourager le schéma de phrase verbeuse en trois propositions.

4

Passe de relecture humaine avant publication

Tout candidat IA est un brouillon. Le bouton CMS écrit le candidat dans un champ de relecture, et non dans l’attribut alt. L’éditeur accepte, modifie ou remplace par un texte original. Pour les contextes d’actualité, les contextes d’accessibilité ou tout contexte où une identification erronée d’une personne handicapée serait préjudiciable, la passe de relecture est non négociable.

5

Auditer selon un calendrier

Exécuter un échantillon d’alts publiés sur la matrice chaque trimestre. Les modèles dérivent ; les builds fournisseur changent ; les modes d’échec évoluent. Un échantillon de 100 images prend une demi-journée et détecte une régression de comportement avant que l’utilisateur d’un lecteur d’écran ne le fasse.

Ce que « automatisation » doit et ne doit pas signifier

Une fonctionnalité de texte alternatif IA qui écrit directement dans l’attribut alt sans relecture humaine n’est pas une fonctionnalité d’accessibilité — c’est une déclaration d’accessibilité. La conformité WCAG exige toujours que le texte alternatif soit exact, contextuel et non fabriqué. Le modèle peut rédiger ; seul l’éditeur peut publier.


Conclusion : la barre a bougé, le plancher non

Le titre de ce guide, formulé honnêtement, est que les modèles de vision-langage en 2026 constituent désormais un premier jet utile pour la colonne photos et une source de refus utile pour la colonne graphiques, et que ces deux faits ensemble impliquent un flux de travail hybride plutôt qu’entièrement automatisé. La barre a bougé de façon significative entre 2022 et 2026 — les taux d’acceptation sur les photos informatives atteignent désormais les soixante-dix pour cent pour les meilleurs modèles fermés, alors qu’en 2022 ils étaient plus proches de trente pour cent. Le plancher, lui, n’a pas bougé. Les aides à la mobilité sont encore mal identifiées, la langue des signes américaine devient encore « des gestes », et les images décoratives reçoivent encore une phrase quand elles ont besoin de silence.

La conséquence sur l’accessibilité est que le bon défaut pour tout CMS proposant un bouton « texte alternatif automatique » en 2026 n’est pas « appuyer sur le bouton et publier ». C’est « appuyer sur le bouton pour rédiger, puis relire avant publication ». Tout réglage plus strict que cela publie des détails fabriqués aux lecteurs qui dépendent le plus directement de l’exactitude du texte alternatif. Tout réglage plus lâche — ignorer l’IA entièrement — laisse les 41% d’images avec des alts vides sans traitement alors qu’un brouillon aurait aidé.

Nous relancerons cette matrice en novembre 2026. Si la colonne graphiques a dépassé la ligne des 60% d’acceptation, le flux de travail hybride se resserrera. D’ici là, le bouton rédige, l’éditeur publie.

« Le modèle peut rédiger ; seul l’éditeur peut publier. »

— cet article, étape 4 du flux de travail hybride