Une refonte peut améliorer votre site tout en dégradant l’expérience des utilisateurs équipés de matériels anciens. Le problème est rarement visible dans les tests classiques. Pourtant, il est possible de le mesurer à partir des usages réels.
L’écoconception d’un service numérique ne consiste pas uniquement à réduire sa consommation de ressources. Elle doit aussi contribuer à prolonger la durée de vie des équipements.
C’est une dimension encore trop souvent négligée dans les projets de refonte.
Quand une évolution logicielle accélère l’obsolescence du matériel
Un ordinateur ou un smartphone peut parfaitement fonctionner et devenir progressivement difficile à utiliser pour certains services numériques.
Une interface plus exigeante, de nouveaux composants ou des traitements plus lourds peuvent dégrader l’expérience sur des équipements qui fonctionnaient auparavant correctement.
Les utilisateurs concernés subissent alors des difficultés croissantes, parfois jusqu’à ne plus pouvoir utiliser certaines fonctionnalités.
À terme, ils peuvent être incités à remplacer un équipement encore fonctionnel.
Ce phénomène mérite d’être intégré aux démarches d’écoconception, car prolonger la durée de vie du matériel constitue un levier important de réduction des impacts environnementaux du numérique.
Le RGESN recommande de préserver la compatibilité avec les équipements anciens
Le Référentiel général d’écoconception des services numériques (RGESN), dans son critère 2.2, recommande de vérifier que les services numériques restent utilisables sur des équipements anciens.
Pour un service web, il propose notamment de tester les fonctionnalités essentielles sur un équipement doté d’un microprocesseur commercialisé il y a dix ans ou plus.
Un fonctionnement dégradé peut être accepté, à condition que les fonctionnalités critiques et les contenus restent disponibles.
Il ne s’agit pas pour autant de maintenir artificiellement des systèmes d’exploitation ou des navigateurs ne bénéficiant plus des correctifs de sécurité nécessaires.
L’enjeu est de préserver la compatibilité matérielle sans compromettre la sécurité.
Mais cette recommandation pose une question essentielle : comment mesurer ce qui se passe réellement chez les utilisateurs ?
Avec appYuser, nous pouvons observer l’expérience sur les différentes générations d’équipements
Les tests sur des appareils anciens sont indispensables. Mais ils restent ponctuels et ne représentent pas nécessairement tous les contextes rencontrés par les utilisateurs.
Chez Quadran, nous avons développé avec appYuser une approche complémentaire : mesurer en continu l’expérience digitale réellement délivrée aux visiteurs.
À partir des visites observées, nous pouvons notamment analyser la qualité d’expérience selon :
- Le système d’exploitation et sa version : Windows, macOS, iOS, Android, Linux et autres environnements détectables.
- Le navigateur utilisé et sa version.
- Le type de terminal : ordinateur, smartphone ou tablette.
- Les caractéristiques d’appareil identifiables à partir des informations collectées.
- Les pages consultées, les parcours et les contextes d’utilisation.
Cette approche permet d’identifier les populations dont l’expérience se dégrade, sans se limiter aux équipements choisis pour les tests.
Par exemple, si des utilisateurs consultent encore un service depuis iOS 7, nous pouvons analyser les visites correspondantes lorsque leur environnement est correctement détecté et que la collecte fonctionne.
Nous pouvons alors déterminer quelle qualité d’expérience technique est mesurée pour ces utilisateurs, quelles pages sont concernées et comment leur situation se compare à celle d’autres environnements.
Il ne s’agit pas de recommander le maintien d’iOS 7, qui est une version ancienne ne répondant plus aux exigences actuelles de sécurité. Cet exemple illustre la finesse d’analyse possible sur les versions de systèmes d’exploitation.
La même approche est applicable à des générations d’équipements plus récentes et toujours maintenues.
Détecter les situations d’obsolescence provoquées par les évolutions du site
L’intérêt devient particulièrement important lors d’une refonte.
Imaginons qu’une nouvelle version du site soit déployée.
Les indicateurs globaux restent satisfaisants. Les tests fonctionnels sont réussis. Pourtant, les visiteurs utilisant certains environnements anciens rencontrent désormais davantage de difficultés.
En confrontant les données avant et après la refonte, il devient possible de :
- Identifier les systèmes d’exploitation, navigateurs ou catégories de terminaux dont l’expérience s’est dégradée.
- Mesurer l’ampleur de cette dégradation et la population concernée.
- Repérer les pages ou les étapes où les difficultés apparaissent.
- Vérifier si les corrections rétablissent la qualité d’expérience précédente.
Cette analyse permet de détecter des signes d’obsolescence logicielle induite par le service.
Il reste nécessaire de contrôler les autres facteurs susceptibles d’expliquer une dégradation : évolution des usages, du réseau, du navigateur ou des caractéristiques des populations observées.
Et pour démontrer la conformité au critère 2.2 du RGESN, les tests sur des équipements matériels représentatifs restent nécessaires.
La mesure des usages réels ne remplace donc pas les tests de compatibilité. Elle apporte une dimension essentielle : savoir ce que vivent effectivement les utilisateurs et combien sont concernés.
Comment vérifier l’effet d’une refonte sur les équipements anciens ?
Commencez par une question vérifiable : après une mise en production, les mêmes fonctions restent-elles utilisables dans les environnements que vous souhaitez prendre en charge ? Une analyse avant/après doit examiner à la fois la qualité technique observée et la réussite des actions essentielles.
- Définir les environnements. Identifiez les combinaisons de système, navigateur et type de terminal observables. Lorsque vous connaissez le modèle matériel ou disposez d’un appareil de test, documentez-le séparément.
- Définir les parcours essentiels. Par exemple : consulter une information, rechercher un produit, soumettre un formulaire ou terminer une commande.
- Choisir les périodes. Consignez la date de mise en production, les fenêtres de comparaison et les autres changements : acquisition, offre, contenus, réseau ou instrumentation.
- Comparer les mêmes indicateurs. Conservez la même définition des événements et les mêmes règles de collecte, avec les volumes derrière chaque résultat.
- Reproduire et corriger. Vérifiez les difficultés sur des équipements représentatifs, puis contrôlez les résultats après intervention.
| Information | À relever | Ce qu’elle permet d’examiner |
|---|---|---|
| Population observée | Sessions collectées et part du trafic observé. | Ampleur du segment et stabilité des volumes. |
| Qualité technique | appYdex et mesures disponibles, avec leur unité et leur périmètre de calcul. | Évolution du chargement et des interactions effectivement mesurées. |
| Parcours | Sessions atteignant l’étape étudiée et sessions accomplissant l’action. | Taux de réussite avec un dénominateur explicite. |
| Difficultés | Erreurs détectées, attentes ou interactions répétées sur les pages concernées. | Pistes à reproduire pour établir le diagnostic. |
| Vérification matérielle | Modèle de terminal, environnement logiciel et résultat du scénario testé. | Fonctionnement des actions essentielles sur l’équipement identifié. |
Version de système et âge du matériel : deux informations différentes
Une ancienne version d’iOS, d’Android ou d’un navigateur ne suffit pas à dater un appareil. Les informations disponibles ne permettent pas toujours d’identifier son modèle. Dans ce cas, présentez le résultat comme une comparaison entre environnements logiciels observés. Une conclusion portant sur l’âge du matériel exige une identification ou un test matériel complémentaire.
Tenir compte des utilisateurs que la collecte ne voit pas
Le RUM décrit les visites pour lesquelles la collecte fonctionne. Si une incompatibilité empêche le site ou le script de démarrer, ces utilisateurs peuvent manquer dans les résultats. Une baisse du nombre de visites collectées sur un environnement mérite donc une investigation ; elle ne prouve pas à elle seule un problème de compatibilité. Les tests sur appareils et, lorsqu’ils sont disponibles, les journaux techniques apportent des éléments complémentaires.
Pour conclure, rapprochez les observations, la reproduction de l’obstacle et les changements intervenus sur le service. Une dégradation limitée à un segment constitue un signal à expliquer ; elle ne démontre pas à elle seule que la refonte a provoqué le remplacement d’équipements.
Cette démarche complète les indicateurs de l’expérience digitale et l’analyse des dégradations masquées par une moyenne globale.
Un levier concret pour piloter l’écoconception
Cette capacité change la manière d’aborder une démarche d’écoconception.
Au lieu de vérifier uniquement que le service fonctionne sur quelques équipements représentatifs, les équipes peuvent suivre continuellement l’expérience délivrée aux différentes populations d’utilisateurs.
Elles peuvent également mesurer si une nouvelle version améliore le service pour une partie de l’audience tout en le dégradant pour une autre.
C’est particulièrement utile pour les services à forte audience, les démarches administratives, les sites marchands et les applications métiers.
Pour approfondir cette démarche, découvrez comment mesurer l’impact environnemental d’un site à partir des usages réels et comment appYplanet relie ces usages aux 16 catégories d’impact du référentiel PEF.
L’objectif est de concilier trois exigences :
- Maintenir une qualité d’expérience satisfaisante.
- Préserver autant que possible la compatibilité avec les équipements anciens.
- Éviter que les évolutions du service contribuent inutilement au renouvellement du matériel.
Mesurer l’expérience réelle pour éviter une obsolescence invisible
La compatibilité avec les équipements anciens ne doit pas devenir une simple case à cocher dans une grille d’audit.
Elle doit pouvoir être vérifiée dans la durée, notamment après chaque évolution importante du service.
Les mesures issues du trafic réel permettent de repérer des situations qu’un test ponctuel ou une moyenne globale pourrait masquer.
Un site peut parfaitement fonctionner sur les derniers équipements tout en dégradant progressivement l’expérience d’une partie de ses utilisateurs.
L’écoconception consiste aussi à rendre visibles ces situations pour pouvoir agir.
Car un service numérique réellement responsable ne devrait pas obliger ses utilisateurs à renouveler prématurément des équipements encore fonctionnels.
Source officielle : RGESN, critère 2.2 — Le service numérique est-il utilisable sur d’anciens modèles de terminaux ?
Référentiel version 2, dernière mise à jour du 24 septembre 2024.