Craft et technique
Quels appareils et quelles conditions faut-il prévoir pour tester un site créatif ?
Les appareils à tester doivent être choisis selon le public, les fonctions du site et les risques de son expérience. Une matrice utile couvre des différences de navigateur, de puissance, d’écran et de commande. Elle ne consiste pas à accumuler des modèles sans savoir ce que chacun permet de vérifier.
L'essentiel.
La matrice de tests doit couvrir les situations qui peuvent changer l’expérience : moteur de navigateur, puissance, écran, commandes et connexion. On choisit des cas représentatifs du public et du projet, puis on documente ce qui a réellement été vérifié.
- Choisir les environnements en fonction des usages attendus et des données disponibles.
- Inclure au moins les familles de situations qui peuvent modifier le parcours ou le rendu.
- Combiner simulation, appareils réels et tests avec les modes de commande utiles.
- Documenter les scénarios exécutés, leurs résultats et les limites de couverture.
Les conditions comptent autant que le matériel : premier chargement, cache déjà rempli, réseau ralenti, texte agrandi ou interruption de visite. Un site créatif peut sembler abouti sur l’ordinateur de production et rencontrer des difficultés dans une combinaison que personne n’a réellement essayée.
Partir des parcours et des risques
Identifiez les séquences essentielles : découvrir la promesse, manipuler la scène, consulter une information et contacter l’entreprise. Ajoutez les particularités du projet : grand média, formulaire, scène 3D, navigation libre ou reprise d’une sélection.
Une boutique de mobilier avec un configurateur n’a pas exactement les mêmes besoins qu’un portfolio principalement photographique. Le premier demande des contrôles de sélection et de cohérence d’état. Le second peut concentrer davantage de tests sur les images, les cadrages et la consultation de projets.
Si des données d’usage fiables existent, elles peuvent aider à prioriser les environnements. En leur absence, la sélection reste une hypothèse de couverture à documenter. Il faut éviter de présenter une liste choisie par habitude comme une représentation démontrée de tous les visiteurs.
Construire une matrice limitée mais justifiée
Le tableau suivant propose une base à adapter. Il ne constitue ni une norme de recette ni une affirmation sur la répartition du trafic du projet.
| Environnement proposé | Ce qu’il permet d’examiner | Parcours prioritaire |
|---|---|---|
| Téléphone sous iOS | Tactile, clavier et comportement sur ce système | Découverte puis formulaire |
| Téléphone Android contraint | Charge graphique et ressources limitées | Scène principale et navigation |
| Ordinateur Windows ou macOS selon le public | Composition, pointeur et navigateurs retenus | Parcours complet et liens directs |
| Fenêtre étroite et texte agrandi | Robustesse des règles d’adaptation | Lecture et accès aux commandes |
| Environnement avec technologie d’assistance | Sémantique et modes de commande | Compréhension et actions essentielles |
Une tablette, un écran très large ou un navigateur intégré à une application peuvent être ajoutés lorsque leur usage est pertinent. Chaque ligne doit avoir une raison, un scénario et un responsable de vérification.
Exemple pédagogique : tester un site de produit interactif
Imaginons une marque fictive dont le site présente un produit en 3D et permet d’envoyer une demande. La matrice retient une visite mobile complète, une manipulation sur appareil contraint et une consultation au clavier sur ordinateur. Elle ajoute une scène indisponible afin de vérifier l’alternative.
Pour chaque environnement, le test suit le même objectif : comprendre le produit, choisir une variante et préparer la demande. Les conditions changent ensuite : première visite sans cache, reprise, réseau ralenti et rotation du téléphone pendant la consultation.
Croiser les situations qui comptent
- EnvironnementsAppareils et navigateurs choisis selon les usages et les risques.
- ConditionsPremier accès, réseau contraint, zoom et interruption de visite.
- CommandesSouris, tactile, clavier et technologies d’assistance pertinentes.
- ScénariosComprendre, explorer, choisir et contacter avec un résultat attendu.
- PreuvesStatut, conditions et observations permettent de reproduire les constats.
Le compte rendu distingue une fonction non vérifiée d’une fonction vérifiée et défaillante. Cette différence évite de considérer implicitement comme validées toutes les combinaisons qui n’ont produit aucun signal, simplement parce qu’elles n’ont jamais été essayées.
Combiner les moyens de test
Le mode appareil de Chrome DevTools permet de simuler plusieurs conditions, mais sa documentation précise les limites de cette approximation. Il est utile pour explorer des largeurs, ralentir certaines ressources et diagnostiquer. Il ne reproduit pas entièrement le matériel ni le geste d’un téléphone.
Les appareils physiques servent à apprécier les commandes, les interruptions et le comportement réel. Les tests avec des personnes apportent une autre dimension : compréhension, repères et difficultés liées à leur usage. Le W3C souligne l’intérêt de cette participation pour l’accessibilité, en complément des contrôles techniques.
Il faut également distinguer les essais visuels et les essais de fonctionnement. Une capture peut confirmer un cadrage, mais pas la réponse à un glissement. Une vidéo peut montrer une animation, mais pas toujours la capacité à l’interrompre. Le support de preuve doit correspondre à la question examinée.
Fermer la recette avec des résultats lisibles
Chaque scénario peut comporter un point de départ, des actions, un résultat attendu et un statut. Ajoutez les conditions nécessaires pour reproduire un défaut. « Le bouton disparaît lorsque le clavier est ouvert après la sélection d’une variante » est plus utile que « problème mobile ».
Après correction, rejouez le cas concerné et les parcours qui partagent le même composant. Ne multipliez pas indistinctement les tests : élargissez la vérification lorsque la modification peut affecter d’autres usages ou lorsqu’un risque précis reste ouvert.
La livraison doit enfin indiquer les environnements testés et les éventuelles limites acceptées. Cette trace permet de planifier les contrôles suivants lorsque le site évolue. Elle ne garantit pas un fonctionnement éternel sur tous les appareils, mais donne un état de qualité concret et réutilisable.
Questions fréquentes
Faut-il posséder tous les appareils du marché ?
Non. Une sélection justifiée, des outils de simulation et des moyens d’accès à certains environnements peuvent couvrir les besoins prioritaires. L’important est d’identifier les risques et les limites de la matrice. Ajouter des appareils sans scénario précis augmente le travail sans nécessairement améliorer la couverture.
Peut-on tester uniquement les versions les plus récentes des navigateurs ?
La réponse dépend du public et du périmètre de prise en charge défini. Il faut examiner les usages connus et les contraintes du projet, puis documenter les versions retenues. Une sélection limitée peut être cohérente si elle est explicite et accompagnée d’un socle utilisable dans les situations prévues.
À quel moment commencer les tests sur téléphone ?
Dès qu’une interaction ou une composition importante peut être évaluée. Attendre la fin expose à découvrir des problèmes structurels difficiles à corriger. Un premier prototype permet d’orienter les choix ; la recette finale vérifie ensuite les contenus, les états et les parcours réellement livrés.
Sources
LVX : définir une recette proportionnée à l’ambition
LVX peut construire la matrice de tests à partir des moments où le site doit être particulièrement convaincant et fiable. Les appareils, les conditions et les modes de commande sont reliés à des parcours précis, puis les résultats sont documentés pour guider les corrections. Cette méthode rend la qualité vérifiable sans prétendre tout couvrir indistinctement. Elle aide le client à comprendre ce qui a été contrôlé, les adaptations retenues et les situations à surveiller lors des prochaines évolutions. Découvrir notre approche.
