Décider quels navigateurs, appareils et versions une application prend en charge semble être une tâche technique, mais ses conséquences touchent le produit, l’activité et les opérations. Une liste trop vaste peut mobiliser une grande partie des ressources de développement et de test ; une liste trop restrictive risque d’exclure des utilisateurs importants ou de compromettre des engagements pris auprès des clients.
La solution ne consiste pas à courir après chaque nouvelle version ni à en choisir une par habitude. Il s’agit de documenter les environnements pris en charge, le niveau de garantie associé et les conditions dans lesquelles la décision sera réexaminée. Cette matrice transforme une discussion récurrente en un référentiel commun.
La compatibilité est une décision liée au produit et aux opérations
Un environnement compatible n’est pas simplement un environnement dans lequel l’application s’ouvre. Il faut aussi vérifier que ses principales fonctionnalités fonctionnent correctement, que l’expérience est satisfaisante et que l’équipe est en mesure de détecter et de résoudre les problèmes. La décision doit donc refléter les usages réels et la capacité à assurer la maintenance, et non une préférence technique isolée.
Commencez par déterminer les conséquences possibles d’une défaillance. Pour un outil interne, une solution de remplacement temporaire peut être acceptable ; dans un parcours d’achat ou une application indispensable au travail, l’impact peut être plus important. Des engagements contractuels, des politiques de sécurité ou des exigences d’accessibilité peuvent également imposer de prendre en compte certains environnements.
Convenez de qui propose la matrice, qui la valide et qui prend la décision finale. L’équipe produit peut hiérarchiser les besoins et les segments ; l’équipe technique, évaluer la faisabilité et les risques ; le support et les équipes commerciales, apporter des informations sur les incidents et les engagements envers les utilisateurs. Sans responsable clairement désigné, les exceptions ont tendance à se multiplier sans que personne n’en assume le coût.
Recueillez des éléments concrets avant de choisir les versions
La première source à examiner est le contexte d’utilisation. Déterminez quels navigateurs et appareils les utilisateurs emploient pour des tâches importantes, et pas seulement ceux qui apparaissent le plus souvent dans le trafic global. Distinguez, par exemple, la connexion, la réalisation d’une opération critique et la consultation de contenu. Un environnement peu fréquent peut être indispensable à un client ou à un processus donné.
Recoupez plusieurs sources d’information :
- Analyses d’utilisation : relevez les navigateurs, systèmes d’exploitation, tailles d’écran et habitudes d’utilisation disponibles. Interprétez ces données avec prudence : elles peuvent ne pas inclure les utilisateurs qui refusent la mesure d’audience ou ne terminent pas le chargement de la page.
- Support et équipes commerciales : examinez les incidents récurrents, les besoins exprimés par les clients et les accords existants. Distinguez une demande isolée d’une exigence appuyée par des éléments concrets.
- Exigences techniques : consignez les dépendances du produit, les fonctionnalités nécessaires du navigateur, les politiques de sécurité et les restrictions applicables aux appareils administrés.
- Capacité de l’équipe : estimez l’effort nécessaire au développement, aux tests, au diagnostic et à la maintenance. Ajouter un environnement implique davantage que l’inscrire sur une liste.
Si certaines données manquent, consignez cette incertitude. Vous pouvez vérifier le besoin au moyen d’entretiens, de tickets de support ou d’un test à portée limitée. Ne transformez pas l’absence d’éléments en affirmation selon laquelle personne n’utilise cet environnement.
Définissez des critères et des niveaux de prise en charge
Établissez des critères applicables de façon cohérente. Ils peuvent inclure la fréquence et l’importance des usages, le caractère critique des tâches, la compatibilité avec les technologies nécessaires, les risques de sécurité, les exigences des clients et le coût des tests à maintenir. Il n’est pas indispensable de les ramener à une note unique : une obligation contractuelle, par exemple, peut primer sur le volume d’utilisation.
Il est utile de distinguer trois niveaux :
- Prise en charge garantie : l’environnement fait partie de l’engagement publié. Les principales fonctionnalités sont testées et les défauts reproductibles sont traités selon le processus habituel du produit.
- Validé : l’équipe a vérifié un ensemble défini de parcours, sans promettre une couverture complète ni un niveau de priorité équivalent pour tous les problèmes. Précisez ce qui a été validé et les limites connues.
- Non pris en charge : l’équipe ne teste pas le fonctionnement et ne le garantit pas. Si l’application reste accessible, indiquez-le sans laisser entendre que l’expérience est couverte.
Évitez les formules ambiguës comme « compatible avec tous les navigateurs modernes ». Indiquez les noms et les versions, ou définissez une règle vérifiable pour déterminer les versions prises en charge. Si la prise en charge concerne les versions récentes, expliquez comment cette période est calculée et où l’information est publiée. Une formulation précise évite que les utilisateurs et les équipes interprètent différemment l’engagement.
Évaluez le coût du maintien des anciens environnements
La prise en charge d’anciennes versions peut nécessiter des solutions de contournement, davantage de combinaisons de test et le traitement de défauts absents des environnements actuels. Mais leur abandon a également un coût : utilisateurs touchés, opérations interrompues, perte d’accès et travail de communication ou de migration. Il faut comparer ces deux aspects, au lieu de considérer automatiquement la réduction de la maintenance comme un bénéfice.
Parmi les raisons de réexaminer un environnement figurent un usage durablement faible, l’absence d’exigences connues, des problèmes de sécurité importants, des limitations qui empêchent des évolutions nécessaires ou une charge de test disproportionnée. Aucune de ces raisons ne suffit à elle seule. Vérifiez si les données représentent bien la population concernée et s’il existe une solution de remplacement réaliste, comme mettre l’appareil à jour, utiliser un autre navigateur ou convenir d’une transition avec le client.
Avant de mettre fin à la prise en charge, déterminez les tâches susceptibles de ne plus fonctionner, le nombre et le profil des utilisateurs potentiellement touchés, les dépendances internes et la date du changement. Prévoyez, si nécessaire, un délai de prévenance, un canal de questions ou une dérogation temporaire. Toute dérogation doit avoir un responsable, un motif, un périmètre et une date de réexamen ; sinon, elle risque de devenir une prise en charge indéfinie.
Validez la matrice et communiquez-la clairement
La matrice doit correspondre aux tests réellement effectués. Pour chaque environnement bénéficiant d’une prise en charge garantie, définissez les parcours critiques à vérifier et le moment des vérifications : avant la publication, au moyen de tests automatisés lorsque cela convient, et par des contrôles manuels pour les comportements qui le nécessitent. Il n’est pas nécessaire de tester toutes les combinaisons possibles d’appareil, de version et de configuration, mais il faut expliquer la couverture retenue et les risques qui restent hors périmètre.
Donnez la priorité aux parcours ayant des conséquences importantes : accès, opération principale, formulaires, paiements s’il y en a et récupération après une erreur. Vérifiez également l’affichage sur les tailles d’écran pertinentes, la navigation au clavier et les messages présentés lorsque certaines fonctionnalités sont indisponibles. Les outils d’analyse et de mesure des performances peuvent fournir des indications, mais ils ne remplacent ni les tests fonctionnels ni l’analyse des incidents.
Publiez la matrice dans un espace accessible aux utilisateurs et aux équipes internes. Ajoutez sa date de mise à jour, les niveaux de prise en charge, les limites connues, les solutions de remplacement recommandées et un moyen de signaler les problèmes. Si un environnement non pris en charge permet d’accéder à l’application, précisez que son fonctionnement n’est pas garanti ; ne présentez pas un avertissement comme une validation.
Modèle pratique et cycle de révision
Une matrice utile peut être conservée dans un tableau interne et résumée dans la documentation destinée aux utilisateurs. Elle doit consigner au minimum les éléments suivants :
- Environnement : navigateur ou application, système d’exploitation, appareil et version ou règle de mise à jour.
- Niveau de prise en charge : garanti, validé ou non pris en charge.
- Éléments de preuve et risques : usages observés, exigences connues, limites et parcours vérifiés.
- Responsable : personne ou équipe chargée de tenir la décision à jour et de coordonner le traitement des incidents.
- Condition de réexamen : date convenue ou changement exigeant une nouvelle évaluation, comme une nouvelle dépendance, un incident ou une exigence d’un client.
Réexaminez la matrice selon une périodicité convenue et lorsqu’un changement important survient ; il n’est pas nécessaire de la modifier à chaque nouvelle version. Avant toute mise à jour, évaluez les conséquences, les tests nécessaires, la communication et les solutions de remplacement. Ensuite, conservez les raisons de la décision afin que le cycle suivant ne reparte pas de zéro.
Le résultat n’est pas une promesse de fonctionnement parfait sur tous les appareils. C’est une définition explicite des environnements dans lesquels l’équipe investit pour valider et maintenir le produit, des incertitudes qu’elle accepte et de la manière dont elle réagira si les besoins évoluent. Cette clarté permet de prendre des décisions proportionnées et de les corriger en limitant les mauvaises surprises.