Une politique de compatibilité définit les navigateurs supportés, les fonctions testées et le comportement attendu lorsqu’une version est trop ancienne.
Les utilisateurs ne travaillent pas tous avec le même navigateur. Une fonction qui marche sur un poste de développement peut échouer à cause d’un moteur, d’un réglage ou d’une politique de sécurité. La politique doit suivre les appareils réellement utilisés.
Définir le support
Listez les navigateurs et versions supportés, les systèmes et les tailles d’écran. Indiquez si une ancienne version reçoit une correction ou seulement un message invitant à mettre à jour. Le support doit connaître la date de révision de cette liste.
Tester les parcours
Testez la connexion, les formulaires, les fichiers, les exports et les tableaux. Les différences de date, téléchargement et stockage local méritent un contrôle spécifique. Les formulaires métier doivent conserver les valeurs saisies après une erreur.
Un test automatisé sur un navigateur ne couvre pas toutes les tailles. Complétez-le par une vérification manuelle des parcours critiques et du clavier. Un message de compatibilité doit expliquer la solution sans exposer de détails techniques inutiles.
Surveiller les versions
Les métriques peuvent indiquer les navigateurs encore utilisés, sans enregistrer l’identité d’un utilisateur. Une hausse d’erreurs après une mise à jour mérite une vérification par version et parcours.
Sources : MDN, compatibilité, WAI, accessibilité.
Une matrice de compatibilité peut associer chaque parcours à son niveau de support. Testez en priorité les fonctions utilisées par la majorité des comptes et celles qui touchent les fichiers ou les droits. Une exception doit avoir un propriétaire et une date de fin, sinon elle devient une règle cachée.
Ajoutez les résultats à la documentation de support et à la recette. Une personne doit pouvoir savoir si elle doit changer de navigateur, désactiver un réglage bloquant ou signaler un défaut produit.
Définir les fonctions essentielles
Chaque navigateur supporté doit permettre la connexion, la recherche, les formulaires, les fichiers, les notifications et la déconnexion. Ajoutez les parcours particuliers qui bloquent l’activité, comme une validation ou une exportation. Un navigateur peut être accepté pour la consultation tout en étant limité pour une fonction avancée, mais cette limite doit être annoncée.
Les formats de date, de nombre et de téléchargement méritent des exemples. Un fichier généré côté serveur peut avoir un comportement différent selon le navigateur et les réglages de sécurité. Conservez un petit fichier de référence pour comparer le nom, le type et le contenu téléchargé.
Tester les appareils
Les tailles d’écran, le zoom et les claviers tactiles changent l’usage. Testez les tableaux larges, les menus, les fenêtres modales et les messages d’erreur. Un écran qui fonctionne avec une souris peut devenir inutilisable lorsqu’un utilisateur doit faire défiler horizontalement ou ouvrir un menu au toucher.
Les contrôles clavier doivent être vérifiés sur les composants partagés. Le focus doit rester visible après une navigation, une pagination ou un rechargement partiel. Les messages temporaires doivent pouvoir être relus.
Gérer les mises à jour
Un navigateur peut changer son moteur ou sa politique de cookies sans modification de votre code. Surveillez les erreurs par version et par parcours. Une hausse après une mise à jour doit être reproduite dans un environnement contrôlé avant de modifier l’application.
Informez les utilisateurs lorsqu’une version cesse d’être supportée. Donnez la version minimale, la raison pratique et une procédure de mise à jour. Ne bloquez pas un accès uniquement à partir d’un identifiant de navigateur si une vérification de fonction est possible.
Documenter les limites
Une politique claire indique les fonctions qui nécessitent un navigateur récent, les problèmes connus et la date de prochaine revue. Le support peut alors distinguer un défaut produit d’un environnement non pris en charge. Ajoutez les résultats aux tests de régression afin qu’une nouvelle interface conserve les garanties déjà établies.
Contrôler les dépendances du navigateur
Les cookies, le stockage local, les téléchargements et les permissions peuvent être modifiés par le navigateur ou par une politique d’entreprise. Testez un poste avec les réglages courants des clients. Une fonction ne doit pas dépendre d’un réglage caché sans message explicatif.
Les extensions de sécurité, les bloqueurs et les proxys peuvent modifier les requêtes. Le logiciel doit distinguer une réponse refusée d’une réponse lente. Le support peut demander la version, le système et l’identifiant de diagnostic sans collecter l’historique complet de navigation.
Préparer une dégradation
Si un navigateur ne supporte pas une fonction, fournissez un parcours de secours lorsque cela est possible. Un export peut être généré côté serveur et une recherche peut proposer une liste paginée. Le message doit expliquer la limite et l’action recommandée.
Vérifiez les changements après une mise à jour majeure et conservez une date de revue. Une politique ancienne donne au support des informations incorrectes. Le propriétaire produit décide quand retirer une version et informe les utilisateurs concernés.