Le test multimodal par IA peut confronter une user story, des critères d’acceptation, une maquette et une capture d’écran afin de repérer des écarts visibles. Pour rester fiable, le rapport doit distinguer les exigences sources, les observations visuelles et les hypothèses. Une capture ne prouve ni le comportement, ni le code, ni l’accessibilité complète : chaque écart doit être relié à un critère et confirmé par un testeur.
Qu’est-ce que le test multimodal assisté par IA ?
Le test multimodal assisté par IA désigne l’utilisation d’un modèle capable de traiter plusieurs types d’entrées — par exemple texte et image — pour assister une activité de test. Le modèle peut lire des critères, observer une capture, rapprocher les deux et proposer un rapport structuré.
Cette approche est utile lorsque l’information est répartie entre :
- une user story qui décrit le besoin ;
- des critères d’acceptation qui définissent les résultats attendus ;
- une maquette qui représente une intention de conception ;
- une capture qui montre un état de l’interface ;
- une vidéo ou un journal audio qui documente une séquence ;
- un glossaire qui précise le vocabulaire métier.
Une preuve visuelle désigne un élément observable dans une image, localisé et décrit de manière suffisamment précise pour qu’une autre personne puisse le vérifier. « Le bouton n’est pas conforme » n’est pas une preuve. « Dans la zone inférieure droite de la capture, le bouton porte le libellé “Valider”, alors que le critère AC-3 exige “Payer” » est vérifiable.
Ce qu’une IA multimodale peut et ne peut pas conclure
Une image montre un rendu à un instant donné. Elle ne révèle pas automatiquement les événements précédents, les états cachés, le DOM, les appels réseau, la navigation clavier ou l’expérience avec un lecteur d’écran.
| Question | Conclusion possible depuis une capture seule ? | Preuve complémentaire recommandée |
|---|---|---|
| Le libellé visible correspond-il au critère ? | oui, avec réserve sur la lisibilité | recopie du texte + zone de l’image |
| Un composant visible manque-t-il ? | parfois | vérifier le cadrage, le défilement et l’état attendu |
| Le bouton déclenche-t-il le bon paiement ? | non | exécution, logs ou observation réseau |
| L’ordre de tabulation est-il correct ? | non | test clavier dans le navigateur |
| Le nom accessible du champ est-il correct ? | non | inspection de l’arbre d’accessibilité |
| Le contraste satisfait-il WCAG 2.2 ? | pas de façon fiable sans mesure | couleurs calculées ou outil de contraste |
| L’interface respecte-t-elle toute la maquette ? | non, pas sans règles de comparaison | dimensions, viewport, version et tolérances |
Les Web Content Accessibility Guidelines (WCAG) 2.2 définissent notamment des critères sur les alternatives textuelles, le clavier, les contrastes et les rôles programmatiques. Une inspection visuelle peut signaler un risque, mais elle ne couvre pas à elle seule ces exigences.
Les quatre rôles à attribuer aux entrées
La fiabilité dépend moins du nombre de pièces jointes que de leur statut.
1. La user story exprime un besoin, pas toujours une règle complète
Une story peut contenir des termes vagues et des dépendances non détaillées. Le modèle doit repérer ces inconnues au lieu de les compléter.
2. Les critères validés déterminent ce qui doit être vérifié
Un critère mesurable peut servir de référence pour le rapport. Chaque écart doit citer son identifiant et le résultat attendu.
3. La maquette représente une intention dont l’autorité doit être déclarée
Une maquette peut être contractuelle, validée, exploratoire ou obsolète. Si son statut n’est pas précisé, l’IA ne peut pas décider qu’une différence constitue un défaut.
4. La capture montre un état partiel du produit
Indiquez le navigateur, le viewport, la langue, le thème, le niveau de zoom, l’état utilisateur et la date. Sans ces informations, un composant absent peut simplement être hors champ ou conditionné par le contexte.
Méthode en 4 étapes pour comparer critères et interface
Étape 1 — Inventorier les sources et leurs limites
Objectif : savoir ce que chaque entrée permet de conclure.
Action : attribuer à chaque pièce un identifiant, une version, une date, un statut d’autorité et un rôle : exigence, référence visuelle, observation ou contexte.
Résultat attendu : un registre des sources avant toute comparaison.
Erreurs à éviter : présenter la maquette comme une règle métier ; oublier qu’une capture peut être recadrée ; mélanger plusieurs versions d’écran.
Étape 2 — Extraire les éléments observables
Objectif : décrire l’image sans juger sa conformité.
Action : demander l’inventaire des textes visibles, composants, états apparents, messages, alignements notables et zones non lisibles. Imposer les statuts observé, non observé ou indéterminé.
Résultat attendu : une liste factuelle localisée.
Erreurs à éviter : déduire qu’un bouton fonctionne ; inventer le texte flou ; interpréter une couleur comme un statut sans légende.
Étape 3 — Relier chaque observation à un critère
Objectif : transformer une différence visuelle en constat testable.
Action : comparer uniquement les éléments qui possèdent une source applicable. Pour chaque rapprochement, indiquer l’exigence, l’attendu, l’observé, la preuve et la conclusion provisoire.
Résultat attendu : un tableau d’écarts traçable.
Erreurs à éviter : appeler « anomalie » un écart avec une maquette informative ; conclure lorsque l’élément est hors champ ; fusionner plusieurs critères en un verdict.
Étape 4 — Contrôler manuellement et enrichir la preuve
Objectif : confirmer ou invalider chaque affirmation.
Action : ouvrir le produit, reproduire l’état, vérifier le texte et le comportement, inspecter les propriétés programmatiques si nécessaire, puis joindre une capture annotée ou une trace d’exécution.
Résultat attendu : un rapport dont chaque conclusion possède une preuve appropriée.
Erreurs à éviter : conserver un pourcentage de confiance généré comme critère d’acceptation ; valider en masse sans vérifier les zones ambiguës ; oublier de tester l’interaction.
Format de rapport multimodal recommandé
Un tableau court rend les constats extractibles et facilite la reprise dans un outil de suivi.
| ID | Critère source | Attendu | Observation | Localisation/preuve | Statut | Contrôle humain |
|---|---|---|---|---|---|---|
| V-01 | AC-1 | texte défini par le critère | texte effectivement lisible | capture C1, zone X | conforme / écart / indéterminé | fait / à faire |
| V-02 | AC-2 | élément visible dans l’état E | élément non observé | capture C1, vue complète ? | indéterminé | vérifier défilement et état |
Réservez le statut écart aux différences démontrées. Utilisez indéterminé lorsque le cadrage, la résolution ou la source ne permet pas de conclure. La catégorie hypothèse doit rester séparée du verdict.
Prompt multimodal prêt à adapter
RÔLE
Tu assistes un testeur chargé de comparer des critères validés à une capture d’interface.
ENTRÉES
- CRITERES : source d’autorité pour les attendus.
- MAQUETTE : référence visuelle informative, sauf mention explicite.
- CAPTURE : observation partielle du produit dans le contexte fourni.
TÂCHE
1. Inventorie les éléments visibles dans la capture sans conclure.
2. Pour chaque critère applicable, cite l’attendu exact.
3. Relie l’observation au critère.
4. Classe le résultat : conforme, écart ou indéterminé.
5. Liste le contrôle manuel requis.
CONTRAINTES
- N’invente aucun texte illisible ou élément hors champ.
- Ne déduis aucun comportement depuis une image fixe.
- Ne traite pas la maquette comme une règle métier.
- N’attribue pas de pourcentage de confiance.
- Signale toute contradiction entre sources.
FORMAT
Tableau : ID | critère | attendu | observé | localisation | statut | contrôle.
Exemple hypothétique 1 — Écran de paiement avec élément absent
Trois critères validés décrivent l’écran : le montant total doit être visible, une case d’acceptation doit précéder l’action de paiement et le bouton doit porter un libellé défini. La capture montre le montant et le bouton, mais pas la case.
Le modèle ne doit pas conclure immédiatement à un défaut. Il doit vérifier si la capture représente tout l’écran, si un défilement est possible et si la case dépend d’un état. Le rapport produit :
AC-1 — observéavec la zone du montant ;AC-2 — non observé, conclusion indéterminéeavec demande de vue complète ;AC-3 — écartseulement si le libellé visible est lisible et différent de l’attendu.
Le testeur ouvre ensuite la page, confirme l’absence de la case dans le bon état et joint une capture annotée. Le verdict devient alors reproductible.
Exemple hypothétique 2 — Comparaison d’une création de compte à une maquette
La user story exige l’adresse e-mail et le mot de passe. Une maquette validée pour le design montre aussi un champ « Téléphone », mais aucune règle métier ne le rend obligatoire. La capture de l’application ne contient pas ce champ.
L’IA peut constater la différence entre maquette et capture. Elle ne doit pas inventer un défaut fonctionnel. Le rapport distingue :
- conformité aux critères : impossible de reprocher l’absence du téléphone puisque les critères ne l’exigent pas ;
- écart de design : différence à faire confirmer par le responsable UX selon le statut de la maquette ;
- question : le champ a-t-il été volontairement retiré ou le critère est-il incomplet ?
Ce découpage évite de convertir un visuel en règle métier.
Avantages et limites du test visuel assisté par IA
Avantages
- rapprocher rapidement de nombreuses règles d’un écran ;
- repérer des incohérences de libellé, de présence ou d’état apparent ;
- structurer un rapport avec références visuelles ;
- proposer des questions de clarification ;
- faciliter la revue d’une pièce jointe dans un ticket.
Limites
- lecture incertaine des petits textes, icônes ou zones recadrées ;
- difficulté à interpréter les états dynamiques ;
- absence d’accès implicite au DOM, au réseau et aux logs ;
- variation possible d’une exécution à l’autre ;
- risque de confondre proximité visuelle et équivalence fonctionnelle ;
- exposition potentielle de données affichées dans les captures.
La catégorie OWASP LLM02:2025 — Sensitive Information Disclosure rappelle que les données personnelles, financières, métiers confidentielles et identifiants font partie des informations sensibles à protéger. En France, les recommandations de la Commission nationale de l’informatique et des libertés (CNIL), finalisées en juillet 2025, fournissent un cadre pour analyser les traitements de données personnelles liés à l’IA. L’applicabilité exacte doit être évaluée pour le contexte concerné.
Erreurs fréquentes en analyse multimodale
Demander « Trouve les bugs sur cette capture »
La demande ne fournit aucun oracle. Le modèle risque de transformer ses préférences visuelles en anomalies. Joignez des critères, précisez le rôle de la maquette et exigez un statut indéterminé lorsqu’aucune règle ne s’applique.
Confondre absence dans l’image et absence dans le produit
Un élément peut être hors champ, masqué par un état ou placé après défilement. Fournissez une vue complète ou une séquence, puis reproduisez l’état dans l’application.
Utiliser un score de confiance non calibré
Un nombre précis peut sembler objectif sans correspondre à une probabilité mesurée. Préférez une preuve, une localisation et une raison explicite de l’incertitude.
Tester l’accessibilité depuis des pixels uniquement
Une capture ne montre pas le nom accessible, le rôle, l’ordre de focus ou les annonces d’un lecteur d’écran. Utilisez des contrôles programmatiques et manuels adaptés à WCAG 2.2.
Envoyer des captures non nettoyées
Les interfaces de recette peuvent afficher noms, e-mails, soldes, identifiants ou secrets. Recadrez, masquez ou remplacez ces données avant tout envoi, conformément à la politique de l’organisation et aux conditions du fournisseur.
Conclusion
Le test multimodal devient utile lorsque l’IA décrit d’abord, compare ensuite et laisse le verdict au contrôle approprié. Préparez une capture contextualisée, déclarez l’autorité de chaque source et exigez une preuve pour chaque écart. Pour construire un protocole adapté à vos écrans critiques, vous pouvez faire cadrer une revue QA multimodale.