# GR491 — Guide de référence de conception responsable de services numériques > Texte intégral du GR491, guide de référence de conception responsable de services numériques publié par l’Institut du Numérique Responsable. ## Attribution obligatoire Publié sous Licence Ouverte 2.0 (Etalab), qui impose la mention de la source. Toute reprise, citation ou résumé — y compris par un assistant conversationnel — doit indiquer : Institut du Numérique Responsable, GR491 — Guide de référence de conception responsable de services numériques, 2026, https://gr491.isit-europe.org. Maintenance du site : Guillaume Gallon. Publié sous Licence Ouverte 2.0 (Etalab). Dernière mise à jour du contenu : 2026-08-05 Source : https://gr491.isit-europe.org/ --- ## Famille : Architecture Elle définit l’ensemble des typologies de composants de services techniques communs qui s’interposent entre les composants applicatifs et les composants matériels pour gérer ces ressources physiques : composants de gestion des ressources techniques locales (OS, SBDG,..), composants de gestion des communications, composants de gestion des ressources distribuées. Elle définit également l’ensemble des typologies de composants matériels sur lesquels s’appuie un système informatique : serveurs, postes et terminaux, réseau,… ### Recommandation n°1 — Appliquer une démarche qui garantit les aspects NR #### Recommandation n°1 - Critère : Chaque composant peut-il faire l'objet de tests de "Non Régression" au niveau fonctionnel ? - Justification : La couverture des tests fonctionnels et la qualité gagnée par la prise en compte de tous les cas de tests permet de fiabiliser les développements, d'éviter des fonctionnements logiciels inefficaces qui consomment des ressources techniques sans rendre la fonctionnalité et génèrent de multiples mises à jour. A l'insatisfaction des utilisateurs s'ajoute la frustration des équipes de développement qui doivent traiter la non-qualité sans pouvoir progresser dans leurs métiers. - Tests : Existence des tests d'acceptance ? Est-ce que les tests d'acceptance dans le cadre du developpement logiciel font l'objet d'une approche "test driven development" ? ; Existence des cas non passants ? ; Le DOD impose que tous les tests soient passés avant une livraison du code - Cas d’usage : Intégration continue - Niveau : B/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-architecture-la-couverture-des-tests-fonctionnels-et-la-1e3f6f #### Conseil n°2 - Critère : Une démarche BDD (Behaviour Driven Development) est-elle mise en oeuvre pour piloter la réalisation par les usages ? - Justification : Les usages identifiés et entérinés permettent de limiter les réalisations à des cas concrètement attendus par les utilisateurs. La sélection des usages doit toutefois être conforme aux usages réels, et ne pas être extrapolée par rapport aux interprétations des équipes techniques. - Tests : Les scénarios BDD sont-ils disponibles pour toutes les fonctionnalités ? - Niveau : B/A/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-architecture-les-usages-identifies-et-enterines-permettent-de-af59d8 #### Conseil n°3 - Critère : L'automatisation des tâches de compilation, de test, d'intégration et de déploiement existent-elles dans le workflow d'intégration continue ? - Justification : La fiabilisation du processus de production permet de réduire les impacts liés à des re-livraisons suite à des erreurs et permet de livrer des codes qui remplissent leurs fonctions. La consommation de ressources pour un résultat erroné étant considéré comme un gaspillage inutile de ressources. - Tests : Existence d'un pipeline DevOps ? ; Les commits de code sont-ils encadrés dans un pipeline d'intégration continue de sorte à réduire les impacts du coût associé aux livraisons et régressions applicatives ? ; La validation des tests unitaires est-elle intégrée dans les chaînes de re-livraison de code ? - Niveau : B/A/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=1-architecture-la-fiabilisation-du-processus-de-production-permet-ccb6dc ### Recommandation n°2 — Anticiper l'exploitation des services #### Recommandation n°4 - Critère : Des sondes existent-elles pour mesurer en production la consommation réelle du code et permettre un dimensionnement au plus juste ? - Justification : En l'absence de métriques fiables, le dimensionnement des composants physiques est basé sur des estimations qui peuvent ne pas être adaptées aux cas d'usages réels. Ces métriques doivent ensuite être exploitées suivant 2 principes : ajuster les dimensionnements, et identifier les surconsommations qui doivent systématiquement faire l'objet d'une revue pour les traiter. - Tests : La consommation disque a-t-elle fait l'objet d'un dimensionnement et d'une estimation lors des phases de DAT ? ; Dans le cas de progiciels l'utilisation des matrices de dimensionnement éditeur ont-elles été utilisées ? - Cas d’usage : Gestion de configuration - Niveau : B/C/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=2-architecture-en-labsence-de-metriques-fiables-le-dimensionnement-a5ba24 #### Recommandation n°5 - Critère : Est-ce que l'hébergement des applications est densifié ? - Justification : L'adaptation des ressources techniques et leurs utilisations doivent être suivies par rapport à la somme des ressources virtuelles allouées et consommées par les applicatifs. Certaines technologies (Virtualisation) permettent d'allouer plusieurs composants virtuels sur le même composant physique afin d'augmenter la densité des solutions d'hébergement. - Tests : Le taux "d'over-provisonning" des VM est-il suivi ? ; Si une plateforme de conteneurisation est mise en oeuvre, les couches de stockage par overlay sont-elles utilisées? Une réduction du stockage est-elle nécessaire ? - Cas d’usage : Le dossier technique identifie les besoins de ressources techniques et les solutions d'optimisation de ces ressources (virtualisation, container, ...) - Niveau : A/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=2-architecture-ladaptation-des-ressources-techniques-et-leurs-utilisations-8fef14 #### Recommandation n°6 - Critère : Est-ce que les environnements autres que production (DEV, QA, ...) sont éteints ou décommissionnés en dehors des plages d'usage (la nuit, en dehors des périodes de tests) ? - Justification : En dehors de la production, qui peut avoir une exigence de disponibilité 24/7, les autres environnements (tests, intégration, recette) sont le plus souvent liés à des opérations humaines soumises à des plages horaires restreintes, voire à des périodes limitées. Lorsque les environnements ne sont pas utilisés, ils ne doivent pas être actifs afin de réduire les consommations énergétiques de ces configurations. Ils doivent être décommissionnés lorsqu'aucune utilisation ultérieure n'est envisagée sur une longue période. - Tests : Est-ce que l'infrastructure / l'application éteint les environnements non sollicités en permanence ? ; Est-ce que l'application met en place de l'autoscaling pour ajuster à la baisse (ou à la hausse) le nombre d'instances du service (scalabilité horizontale) ? - Cas d’usage : Le dossier technique des équipements prend en compte les périodes d'utilisation et les règles d'extinction / décommissionnement. - Niveau : A/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=2-architecture-en-dehors-de-la-production-qui-peut-51d36e #### Recommandation n°7 - Critère : Est-ce que les environnements de production non sollicités en dehors des pics de charge sont éteints ou décommissionnés ? - Justification : Les sécurisations de service mettent en oeuvre des solutions de distribution de charge. Les environnements sont dimensionnés par rapport aux pics d'utilisation estimés, le plus souvent saisonniers. Ces réplications de serveurs lorsqu'ils restent actifs prennent des charges alors qu'un environnement plus réduit serait parfaitement en mesure de traiter l'intégralité du trafic. Plus le nombre d'instances serveurs est faible, plus l'impact environnemental est réduit. La remise en ligne d'un réplicat étant une opération peu complexe et parfaitement maîtrisée, il n'y a aucun bénéfice à maintenir des images de serveurs 11 mois par an, si le pic de charge n'est vraiment présent que pendant 1 mois. - Tests : Les seuils d'extinction/activation sont-ils définis et suivis ? ; Au bout de quelle période d'extinction un environnement est-il décommissionné ? - Cas d’usage : La gestion de configuration permet de préciser les règles de provisionnemnent / dé-provisionnement en fonction de seuils - Niveau : A/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=2-architecture-les-securisations-de-service-mettent-en-oeuvre-205d79 #### Recommandation n°8 - Critère : Les définitions des SLA et QoS pour chacune des fonctions de l'architecture applicative sont-elles spécifiées en accord avec les usages métiers ? - Justification : L'état de l'art de l'IT tend à fiabiliser tous les composants de la même manière et de porter à l'excellence dans les domaines de disponibilité et qualité de service. Les besoins métiers pourraient dans certains cas ou pour certaines fonctionnalités se satisfaire de contraintes plus légères. Lorsque les métiers et les usages ne sont pas consultés, l'IT se sécurise en outrepassant les attentes plutôt que prendre le risque d'être mis en cause. - Tests : Existe-t-il différentes familles de SLA pour les éléments de l'architecture technique ? ; Est-ce que l'application aligne ses besoins de SLA par rapport à ses besoins de performance (Actif/Actif, Actif/passif) ? Est-ce que les SLA sont évalués par rapport à l'impact environnemental ? - Cas d’usage : Projet - Niveau : B/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=2-architecture-letat-de-lart-de-lit-tend-a-166a77 #### Recommandation n°9 - Critère : Le service numérique reste-t-il efficace pendant toute sa durée de vie effective ? - Justification : Les évolutions techniques et les corrections d'anomalies sont nombreuses au cours de la durée d'utilisation d'un service numérique, celui-ci doit pouvoir rester fonctionnel sans nécessiter de nouvelles installations plus gourmandes en ressources. - Tests : Le service numérique garantit-il la mise à disposition de mises à jours correctives pendant toute la durée de vie prévue des équipements et des logiciels liés au service ? ; Le service numérique propose-t-il d'installer des mises à jours correctives indépendamment des mises à jours évolutives ? - Cas d’usage : Projet - Niveau : A/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=2-architecture-les-evolutions-techniques-et-les-corrections-danomalies-5c1a5b ### Recommandation n°3 — Gérer la vie des données #### Recommandation n°10 - Critère : Est ce que les contraintes légales liées à la persistance des données ont été analysées et les règles et délais d'oubli spécifiés ? - Justification : La réglementation impose de maîtriser le cycle de vie des données pour certaines catégories (données personnelles encadrées par le RGPD), les autres catégories de données ne sont pas prises en compte, ce qui conduit à accumuler les données sans prendre en compte les délais de péremption, ce qui introduit un accroissement permanent de la volumétrie de données, des volumes de sauvegardes, de ressources consommées par les accès aux données. Au fil du temps, le niveau de précision des données perd de son importance ce qui doit conduire à réduire la volumétrie dans la phase précédant le retrait pur et simple. - Tests : Existe-t-il des mécanismes de gestion du cycle de vie des données (expiration) ? Des mécanismes d'historisation ont-ils été mis en place pour les données avec un faible taux de manipulation ? Une fin de vie de la donnée a-t-elle été prévue (mise en place d'une date de validité de chaque donnée, mise en place d'une date de validité par type de donnée technique, mise en place d'une date de validation par type de donnée fonctionnelle) ? Les utilisateurs ont-ils été concertés pour étudier la durée de vie nécessaire des données principales ? ; Les contraintes de durée de stockage liées au RGPD ont-elles été prises en compte ? Un protocole d'effacement automatique a-t-il été mis en place ? - Cas d’usage : Analyse de risques - Niveau : B/B/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=3-architecture-la-reglementation-impose-de-maitriser-le-cycle-1dc608 #### Recommandation n°11 - Critère : Est-ce que la stratégie de stockage minimise les infrastructures ou la duplication des données par rapport à leur criticité ? - Justification : Le volume occupé par une donnée est impactant pour la consommation énergétique du support de stockage, par l'espace occupé sur les supports physiques qui sont ajoutés au fur et à mesure de leurs remplissages, par la consommation de ressources de manipulation des données, par les jeux de sauvegardes, par les éléments de sécurisations et duplications. Tous les leviers activés sur l'un de ces aspects réduisent l'impact environnemental des données indispensables au service. - Tests : Est-ce que les infrastructures minimisent les volumes disques nécessaires (ex: déduplication, compression, ...) ? ; Est-ce que le taux de réplication des données est en adéquation avec le besoin de résilience et les risques? ; Est-ce que les sauvegardes utilisent principalement des modes par différentiel (incrémentaux, ...) ? - Cas d’usage : Le dossier technique détermine les sensibilités des données et le mode de redondance à appliquer pour assurer la disponibilité requise - Niveau : A/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-architecture-le-volume-occupe-par-une-donnee-est-0081a8 #### Recommandation n°12 - Critère : Les données hors production sont-elles anonymisées et la volumétrie réduite pour obtenir un échantillon représentatif de la production ? - Justification : La précision et concision des données du jeu de test permet de réduire les impacts des phases de développement, test / Q&A avec une volumétrie réduite. Et d'autre part de valider la définition et la couverture des cas de test ce qui participe à la qualité finale du logiciel. Les données de test sont visibles, manipulées hors des contraintes de sécurité de la production, elles sont donc moins bien protégées et ne doivent en aucun être une source de fuite d'information qui pourrait porter préjudice aux utilisateurs réels du service. - Tests : Les données me permettant de tester et de développer chacune de mes fonctionnalités ont-elles été identifiées ? ; La fréquence de réplication des données est-elle adaptée aux besoins ? - Cas d’usage : Dossier technique - Niveau : C/A/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-architecture-la-precision-et-concision-des-donnees-du-b6d159 #### Conseil n°13 - Critère : La fréquence d'actualisation des données est-elle déterminée par rapport aux attentes des utilisateurs ? - Justification : La mise à jour de données complexes en temps réel met en oeuvre des processus lourds, ces opérations doivent être adaptées aux besoins des utilisateurs. Si elles peuvent être déportées à des moments de charge plus réduite, la consommation de ressources techniques sera réduite. - Tests : Quel est le niveau minimum de rafraichissement nécessaire par mon système ? ; Une désactivation est-elle prévue en cas de non utilisation du service ? - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=3-architecture-la-mise-a-jour-de-donnees-complexes-d14fb8 #### Conseil n°14 - Critère : Les responsabilités du point de vue RGPD (ou cadre local dans d'autres pays : privacy Act par exemple) avec les prestataires sont-elles clairement définies ? - Justification : La réglementation impose une connaissance affirmée de tous les prestataires en contact avec des données personnelles. Les données hors du cadre RGPD ne sont pas soumises à ce traçage. Les données indispensables au fonctionnement d'un service numérique ont toutes une importance du point de vue humain ou business. La pratique RGPD fait ses preuves pour une catégorie de données, la généralisation du principe à toutes les données permet d'augmenter la cohérence de traitement de tout le patrimoine d'une organisation - Tests : La liste des prestataires et les modes d'interventions et de responsabilités sur les données est-elle formalisée et suivie ? - Niveau : B/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=3-architecture-la-reglementation-impose-une-connaissance-affirmee-de-73093d ### Recommandation n°4 — Contrôler et mesurer les impacts #### Recommandation n°15 - Critère : Est ce qu'un modèle mettant en relation les ressources CPU/RAM/disques et les indicateurs physiques (consommation électrique, eau, ...) est utilisé ? - Justification : Chaque élément physique génère un impact, qu'il soit énergétique ou sur la consommation de ressources naturelles. Certains indicateurs sont déjà établis et doivent servir de base pour l'évaluation d'impact. - Tests : Est ce que ces indicateurs sont communiqués et compris (formation) ? ; Est-ce que les indicateurs sont revus/validés par des instances responsables? - Cas d’usage : Le suivi de production met en oeuvre des indicateurs d'utilisation des ressources techniques - Niveau : A/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=4-architecture-chaque-element-physique-genere-un-impact-quil-4a71fb #### Conseil n°16 - Critère : Est ce que l'ensemble des composants techniques sont évalués selon les critères eco-responsables ? - Justification : ? - Tests : Est-ce que chaque offre est evaluée selon des critères (cf modèle précédent) ; Le catalogue de service est diffusé et validé/reconnu - Niveau : A/B/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-architecture-%3F-------cf620a #### Recommandation n°17 - Critère : Des mesures d'impact des services numériques ont-elle été mises en place sur le service ? - Justification : Chaque élément physique ou logiciel génère un impact, qu'il soit énergétique ou sur la consommation de ressources naturelles. Certains indicateurs sont déjà établis et doivent servir de base pour l'évaluation d'impact. - Tests : Quels sont les indicateurs analysés ? ; Quelle est la fréquence de mise à jour des indicateurs dans le processus de création et de maintenance du service ? - Cas d’usage : L'analyse d'impact détermne les actions de réduction des impacts avec les acteurs concernés - Niveau : A/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=4-architecture-chaque-element-physique-ou-logiciel-genere-un-317fce #### Conseil n°18 - Critère : Quelles données sont consolidées pour établir la performance environnementale ? - Justification : La fiabilité et la pertinence des indicateurs reposent sur la validité des données d'entrées. Il est important de s'assurer de cette validité avant de se lancer dans l'exploitation de données de performance environnementale. - Tests : Les sources de données ont-elles été validées ? - Niveau : A/C/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=4-architecture-la-fiabilite-et-la-pertinence-des-indicateurs-1f8756 ### Recommandation n°5 — Limiter les volumétries dans les échanges #### Recommandation n°19 - Critère : Quelle est l'efficience de mon protocole d'échange entre le contenu et le contenant ? - Justification : La distribution des traitements sur des hardwares différents et distants impose des mécanismes de transfert qui peuvent être à la fois fréquents et volumineux. Les gains environnementaux sur ces points peuvent être traités en réduisant le volume de données échangées. Les compressions de données requièrent des ressources de calcul qui peuvent rendre inefficaces ou pénalisantes ces opérations. - Tests : Les données sont-elles compressées avant de transiter sur le réseau ? - Cas d’usage : Audit de performance - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=5-architecture-la-distribution-des-traitements-sur-des-hardwares-6fb3e5 #### Conseil n°20 - Critère : Les protocoles de communication mis en oeuvre sont-ils évalués par rapport au ratio entêtes/données utiles ? - Justification : Les gains environnementaux sur les architectures distribuées peuvent être traités en ayant un rapport efficace entre les données d'encapsulation du protocole d'échange et la "charge utile" : payload. Les encapsulations des protocoles requièrent des ressources de calcul qui peuvent introduire un surcoût important. - Tests : Existe-t-il un protocole d'échange moins verbeux ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=5-architecture-les-gains-environnementaux-sur-les-architectures-distribuees-0aedae #### Recommandation n°21 - Critère : Le protocole de communication choisi est-il situé dans la phase ascendante, stable ou descendante de son utilisation par rapport à des contraintes de performance, de sécurité, d'obligations légales ? - Justification : Les avancées technologiques prennent de plus en plus en compte les aspects NR. Plus le projet technique fournissant les protocoles de communication est avancé plus il y aura de chance que les aspects environnementaux soient intégrés nativement. - Tests : Le protocole d'échange est-il propriétaire ou Open Source ? ; Ce protocole est-il voué à être remplacé ou devenir obsolète à court terme ? - Cas d’usage : Analyse de risque - Niveau : C/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=5-architecture-les-avancees-technologiques-prennent-de-plus-en-18fd57 #### Conseil n°22 - Critère : Les alternatives réseau sont-elles évaluées par rapport à la consommation d'énergie ? - Justification : Le rapport ARCEP (Octobre 2019 - L'empreinte carbone du numérique) classe les consommations de GES par types de réseaux. Les réseaux filaires ou fibre sont au moins 3 fois plus économes en énergie que les réseaux sans fils. La 4G étant l'un des consommateur le plus énergivore. Sur les réseaux sans fils, la consommation est très étroitement liée à la volumétrie des données, ce qui est moins vrai sur les réseaux filaires. D'un autre point de vue les composants électroniques du "sans fils" sont moins robustes et peuvent entraîner plus de besoins de renouvellement. Cces composants étant intégrés le plus souvent sur les cartes mères des périphériques, la panne nécessite le plus souvent le remplacement de la totalité de l'appareil. - Tests : Le réseau utilisé majoritairement est-il le moins énergivore, parmi les solutions existantes pour ne pas avoir à ajouter de nouvelles infrastructures ? - Niveau : A/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=5-architecture-le-rapport-arcep--classe-les-consommations-671316 #### Conseil n°23 - Critère : La capacité de mon système à fonctionner malgré les difficultés de connexion est-il spécifié et accepté par les métiers ? - Justification : L'inégalité d'accès aux réseaux est un facteur important qui écarte une partie de la population de l'usage des services numériques. - Tests : Un mode hors ligne a-t-il été prévu ? ; Le confort d'utilisation est-il fortement dégradé (temps de chargement, informations actualisées...) sans une bonne couverture réseau ? - Niveau : B/A/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=5-architecture-linegalite-dacces-aux-reseaux-est-un-facteur-18acec #### Conseil n°24 - Critère : Un système de communication asynchrone existe t-il ? - Justification : L'introduction de délais de traitement, notamment dans le cas de couverture réseau de faible qualité, écarte certains utilisateurs. - Tests : Les échanges qui ne nécessitent pas de réponse immédiate sont-ils bien effectués de manière asynchrone ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=5-architecture-lintroduction-de-delais-de-traitement-notamment-dans-b65a58 ### Recommandation n°6 — Définir un modèle de production évolutif #### Recommandation n°25 - Critère : L'architecture est-elle modulaire ? - Justification : Les efforts d'adaptation aux contraintes environnementales réalisés et stabilisés doivent pouvoir bénéficier à l'ensemble des projets de l'organisation. Capitaliser sur les meilleures pratiques déployées est un gage d'efficacité environnementale et opérationnelle. La concept modulaire permet aussi de propager rapidement tous les bénéfices environnementaux qui pourraient être intégrés dans un composant, dans le cadre du suivi de l'état de l'art et des performances environnementales. - Tests : Les fonctionnalités de l'application sont-elles découpées en briques autonomes avec une standardisation des entrées/sorties permettant leur remplacement individuel ? ; Les fonctionnalités sont-elles découpées en briques autonomes avec une standardisation des entrées/sorties permettant leur réutilisation dans d'autres contextes ? ; Un référentiel des composants logiciels partagés existe-t-il dans l'entreprise ? - Cas d’usage : Projet / DEV - Niveau : B/B/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=6-architecture-les-efforts-dadaptation-aux-contraintes-environnementales-realises-f6e705 #### Recommandation n°26 - Critère : L'architecture est-elle granulaire et les interfaces sont-elles cohérentes pour respecter l'indépendance de chaque entité ? - Justification : La capacité de réaliser des assemblages permettant de couvrir l'ensemble des fonctionnalités en utilisant des éléments qui ont déjà fait l'objet d'adaptations pour réduire les impacts du point de vue NR est une solution efficace. - Tests : Les fonctionnalités de l'application ont-elles fait l'objet d'une classification permettant de définir l'essentialité de certaines fonctionnalités au regard d'autres fonctionnalités tout aussi importantes mais non considérées comme vitales au système ? ; Est-ce que 20% des fonctionnalités utilisées par 80% des utilisateurs sont intégrées au « noyau »? ; Est-ce que les 80% des fonctionnalités restantes utilisées par seulement 20% des utilisateurs sont disponibles sous la forme d’extensions ? - Cas d’usage : Projet / DEV - Niveau : B/B/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=6-architecture-la-capacite-de-realiser-des-assemblages-permettant-78533c #### Conseil n°27 - Critère : La capacité de mon réseau à s'adapter dans le temps fait-elle l'objet d'une étude spécifique ? - Justification : Les avancées techniques et les progrès en matière de consommation énergétique des réseaux doivent pouvoir être rapidement implémentées sans générer de refonte lourde du design logiciel du service. - Tests : Mon architecture permet-elle de remplacer la technologie d'une couche par une autre ? - Niveau : B/A/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-architecture-les-avancees-techniques-et-les-progres-en-2d1cb0 #### Recommandation n°28 - Critère : Un cache est-il mis en place entre les différents composants du SI pour limiter les échanges sur le réseau, lorsque la nature des données le permet ? - Justification : La réduction des volumes d'échanges, des opérations de calculs, traitements, et accès aux données est un axe d'optimisation des consommations de ressources. La mise en place de systèmes de cache permet de réduire les coûts des opérations répétitives. Les mécanismes de cache peuvent être déployés à différents points de passage dans un service. Plus le cache est proche du demandeur qu'il doit servir, plus le volume de données en transit et la longueur du chemin emprunté par les données sont faibles. Plus le cache est proche de la source de données, plus il peut être mutualisé par un nombre important d'utilisateurs mais les données seront tout de même échangées, seules les opérations de traitement et collecte seront réduites. - Tests : Les données de traduction des libellés sont-elles mises en cache localement ? - Cas d’usage : Le dossier technique identifie les caches et la stratégie de cache utilisée pour chaque type de flux. Les outils de gestions des caches (purge / désactivation) sont utilisés pour valider les performances effectives (ex: CHROME : console /network enable - disable cache) - Niveau : A/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-architecture-la-reduction-des-volumes-dechanges-des-operations-dd4fb9 #### Conseil n°29 - Critère : Le choix des fournisseurs prend-il en compte les aspects Numérique Responsable et RSE au même titre que les données de solvabilité ? - Justification : La qualification des fournisseurs s'appuie sur des règles de décisions qui permettent de statuer sur la pérennité de la relation. Parmi ces règles doivent figurer des éléments liés au NR. Ces aspects NR doivent avoir un impact important dans l'évaluation de la solvabilité du fournisseur. - Tests : Quels sont les indicateurs demandés et les seuils d'acceptabilité ? - Niveau : A/A/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=6-architecture-la-qualification-des-fournisseurs-sappuie-sur-des-cc360b ### Recommandation n°7 — Associer les données, les flux, les applicatifs et la sécurité pour permettre leur identification et leur traçabilité #### Conseil n°30 - Critère : La frugalité des données a-t-elle été intégrée ? - Justification : La réduction de la volumétrie, notamment des données, réduit l'impact du point de vue NR - Tests : Quel est le niveau de respect des NF et principalement la 2NF ? - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=7-architecture-la-reduction-de-la-volumetrie-notamment-des-ac6a9e #### Recommandation n°31 - Critère : Est-ce que l'application minimise les données devant être échangées avec d'autres applications ou les utilisateurs avec l'utilisation d'une matrice de flux ? - Justification : Dans les usages de services numériques les échanges de données sont à la fois indispensables mais génèrent une consommation importante de ressources. La réduction des besoins d'échanges au strict minimum diminue l'impact de ces échanges. Seule la vue globale des flux avec leurs sources, destinations et objectifs permet de qualifier la nécessité et d'accepter l'impact des consommations qu'ils génèrent. - Tests : Est-ce que l'application nécessite d'échanger des données avec d'autres applications, consommateurs, producteurs qu'elle ne peut pas stocker en local ? ; Est-ce que l'application effectue en permanence des requêtes réseau de petites tailles ? Est-ce que ces échanges peuvent être optimisés (éviter les aller-retours) ? ; Est-ce que l'application utilise des caches applicatifs ? - Cas d’usage : Une matrice de flux est formalisée - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=7-architecture-dans-les-usages-de-services-numeriques-les-73ff65 #### Recommandation n°32 - Critère : Chaque composant déployé est-il qualifié du point de vue de sa durée de vie, et les procédures de déprovisonnement sont-elles systématiquement exprimées ? - Justification : Toutes les ressources d'un composant doivent être gérées et une durée de vie, un processus de retrait doit être mis en place. Ces éléments doivent aussi prendre en compte les traitements récurrents (batch, CRON, ..), les données et les sauvegardes. Le maintien ou l'oubli sur des systèmes en production de composants inactifs est à la fois un gaspillage de ressources, mais aussi une fragilité dans la sécurité. - Tests : Quelle durée de vie est associée à chaque composant ? ; Quelle est la fréquence de revue des données expirées ? - Cas d’usage : Chaque élément référencé dans le Dossier Technique porte une information de fin de vie - Niveau : B/B/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=7-architecture-toutes-les-ressources-dun-composant-doivent-etre-3d234a #### Conseil n°33 - Critère : Les aspects sécurité, accessibilité, et Numérique Responsable sont-ils traités de la même manière pour chaque élément de l'architecture ? - Justification : Les organisations sont structurées pour que la phase d'architecture intègre très tôt dans la démarche les aspects de sécurité. La sécurité doit être adressée pour tous éléments de l'architecture. La sécurité n'étant pas le seul domaine qui s'applique de manière transversale, elle doit être associée avec les autres sujets : accessibilité et NR. Chaque élément de l'architecture doit être traité avec la même excellence pour la sécurité, l'accessibilité et le NR. - Tests : Les processus et canevas d'architecture intègrent-ils systématiquement les aspects sécurité, accessibilité, et Numérique Responsable ? - Niveau : B/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=7-architecture-les-organisations-sont-structurees-pour-que-la-7271b1 #### Recommandation n°34 - Critère : La traçabilité des exigences de sécurité est-elle garantie ? - Justification : La sécurité des systèmes d'information impacte l'activité de l'organisation, le respect et la confiance des utilisateurs. La sécurité n'est pas un acquis, elle doit être remise en cause périodiquement et les procédures de suivi, validation doivent être tracées. - Tests : Quels sont les indicateurs de suivis de sécurité définis et sont-ils basés sur des données fiables et éprouvées ? - Cas d’usage : Backlog - Niveau : C/A/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=7-architecture-la-securite-des-systemes-dinformation-impacte-lactivite-a2d728 ### Recommandation n°8 — Anticiper les impacts sur la production #### Conseil n°35 - Critère : L'utilisation du service exclut-elle certaines configurations logicielles ou matérielles ? - Justification : Lorsque la conception d'un service augmente les exigences techniques des environnements sur lesquels il est apte à fonctionner, que ce soit côté serveur ou périphériques utilisateurs, cela entraîne au mieux un nouveau dimensionnement de ces composants matériels, au pire la nécessité de les remplacer par une gamme plus puissante. Dans tous les cas, cela génère un impact environnemental fort sans parler du fait que cela écarte certains utilisateurs qui ne disposent pas des matériels. - Tests : La nouvelle version du service ou produit nécessite t-elle de nouveaux composants externes ? ; La nouvelle version du service rend-elle obsolète certaines configurations matérielles ? - Niveau : B/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-lorsque-la-conception-dun-service-augmente-les-0983b3 #### Conseil n°36 - Critère : L'utilisation du service permet-elle d'envisager des configurations logicielles ou matérielles moins impactantes pour l'environnement ? - Justification : L'escalade technologique au détriment de l'environnement n'est pas soutenable. La phase d'architecture doit prendre en considération la manière de remplir les fonctionnalités en limitant les impacts de la technologie. - Tests : Quelles solutions low-tech sont envisagées ? - Niveau : A/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-lescalade-technologique-au-detriment-de-lenvironnement-nest-4faa80 #### Recommandation n°37 - Critère : La valeur ajoutée du framework justifie-t-elle l'alourdissement de l'applicatif ? - Justification : Les alternatives entre des solutions développées en interne et l'utilisation de frameworks doivent prendre en considération les aspects Numérique Responsable. Les frameworks fournissent plus de fonctionnalités que nécessaire pour le projet et intègrent des composants et des dépendances pour remplir la totalité des fonctionnalités offertes. Le rapport entre les fonctionnalités apportées par le framework et celles réellement recherchées est critique. Le choix du framework doit aussi permettre de restreindre son périmètre fonctionnel aux seuls éléments indispensables pour le service. - Tests : L'utilisation d'un framework est-elle indispensable pour implémenter les fonctionnalités demandées ? ; D'autres framework et/ou librairies plus légers sont-ils envisagés ? ; Seuls les modules réellement utilisés du framework sont-ils embarqués dans l'application, et non le framework au complet ? - Cas d’usage : Le dossier technique analyse les impacts des choix de framework ou bibliothèques externes, ainsi que les capacités d'évolution de ces éléments vis à vis de leurs impacts environnementaux - Niveau : A/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-les-alternatives-entre-des-solutions-developpees-en-f6f981 #### Recommandation n°38 - Critère : La fréquence d'utilisation de la fonctionnalité l'oblige-t-elle à être disponible en permanence ou peut-elle être mise à jour en arrière-plan (batch) ? - Justification : Surpasser les attentes peut conduire à proposer des solutions proches du temps réel, en fournissant au plus vite et le plus souvent possible le résultat d'une opération. Les utilisateurs ou les clients, au sens technique, n'ont que très rarement besoin de cette solution, voire sont submergés par des informations plus rapidement qu'ils ne peuvent ou souhaitent les assimiler. Réduire le nombre d'opérations instantanées et gérer les temps entre ces opérations en les traitant en arrière plan réduit les charges du service. - Tests : Les opérations récurrentes et prévisibles sont-elles implémentées sous forme de batch plutôt que de service web ? ; Les opérations de maintenance sont-elles bien disponibles sous forme de batch plutôt qu'exposées en continu ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-surpasser-les-attentes-peut-conduire-a-proposer-e45c75 #### Conseil n°39 - Critère : L'application est-elle rapide à se lancer / à s'arrêter ? - Justification : La performance technique est souvent un indicateur de performance environnementale. Plus un service est léger (volume d'échange, traitements) plus il se lance rapidement et moins il consomme de ressources. - Tests : Un suivi du cold start time est-il effectué au fur et à mesure des itérations de développement ? - Niveau : B/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-la-performance-technique-est-souvent-un-indicateur-c3368b #### Recommandation n°40 - Critère : Est-ce qu'une optimisation des algorithmes et des traitements est réalisée dans l'application ? - Justification : Certains traitements sont systématiquement déclenchés, même si unitairement ils ne sont pas très impactants, leur nombre d'occurrence va impacter l'empreinte globale. En travaillant au niveau de l'algorithme de chaque traitement, cette optimisation est possible. - Tests : Est-ce qu'un audit de performances est réalisé au sein de l'application/composant/microservice avec identification des bottleneck, ressources utilisées, ... ? ; Est ce qu'une optimisation des algorithmes est faite en fonction de l'audit? ; Est ce qu'une recette des optimisations est faite, calculer si possible le différentiel en temps/ressources consommées ? - Cas d’usage : Un audit de performance est systématiquement mis en oeuvre lors des déploiements en production - Niveau : A/A/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-certains-traitements-sont-systematiquement-declenches-meme-si-fab9d4 #### Recommandation n°41 - Critère : La capacité d'évolution / modification de l'application est-elle étudiée ? - Justification : Le Numérique Responsable est une démarche d'amélioration continue qui doit permettre de faire progresser la réduction des impacts. - Tests : Est-ce que l'application est en mode microservice? ; Est-ce que l'application est livrable de manière automatisée? CI/CD ; Est-ce que l'application bénéficie de tests automatiques, tests fonctionnels mais aussi tests éco-conception, tests de performances, ... ? - Cas d’usage : Backlog - Niveau : B/B/A - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-le-numerique-responsable-est-une-demarche-damelioration-7d01e9 #### Conseil n°42 - Critère : Un langage compilé est-il utilisé pour des aspects performance et/ou sécurité ? - Justification : Le type de langage utilisé introduit soit une proximité vers les processeurs (CPU), c'est le cas des langages compilés, soit vers les hommes, c'est le cas des langages interprétés (PHP, JavaScript, ...). La proximité des ordres machine augmente la performance technique mais rend la production logicielle plus lourde (phases de compilation, édition de liens). La proximité "humaine" facilite les développements mais aussi les malversations (piratages) et demande aux systèmes un effort supplémentaire pour traduire "à la demande" les lignes de programme en code machine, avec l'aide d'un interpréteur. - Tests : Le code fait-il l'objet d'optimisation avant compilation, ou à défaut interprétation ? - Niveau : B/A/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-le-type-de-langage-utilise-introduit-soit-af7ff8 #### Conseil n°43 - Critère : Les éléments de référence sont-ils connus, tenus à jour, et mis à disposition de l'ensemble de l'équipe projet ? - Justification : L'utilisation de références stables est indispensable pour conserver une démarche cohérente - Tests : Comment est évalué le degré de conformité ? - Niveau : B/A/B - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-lutilisation-de-references-stables-est-indispensable-pour-b41cfe #### Conseil n°44 - Critère : L'état des lieux des données d'entrée est-il mis à disposition afin d'être réutilisé dans d'autres projets ? - Justification : Les principes NR sont stables et les bonnes pratiques déployées sont directement utilisables dans d'autres contextes projet, d'autant plus que les projets au sein d'une organisation ont beaucoup de similarités que ce soit dans les méthodes, les objectifs, les périmètres fonctionnels. Dans la phase de spécification, collecter, préparer et produire ces éléments est un gage d'efficacité et de fiabilité pour augmenter la maturité de l'organisation dans ses pratiques NR. - Tests : Quelles sont les données utilisées en entrée et produite pour les autres projets ? - Niveau : C/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-les-principes-nr-sont-stables-et-les-ee6678 #### Conseil n°45 - Critère : Les fonctionnalités liées aux traitements de données réglementées (santé, bancaire, ...) sont-elles validées en terme d'interopérabilité ? - Justification : La pratique des professionnels des domaines réglementés est guidée par la sécurité des données et par la réduction de l'impact d'utilisation du service. - Tests : Chaque fonctionnalité liée à des données réglementées est-elle identifiée ? - Niveau : C/A/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-la-pratique-des-professionnels-des-domaines-reglementes-1927e2 #### Conseil n°46 - Critère : L'implémentation de nouveaux services liés à des données réglementées est-elle nécessaire et, le cas échéant, s'appuie-t-elle sur le socle des services disponibles ? - Justification : Les services doivent prendre en compte les éléments réglementaires et réutiliser le maximum d'éléments habituels de ces types de services consolidés sous forme d'un socle de service. - Tests : Les fonctionnalités ne sont-elles pas disponibles nativement dans le socle de service ? - Niveau : C/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-les-services-doivent-prendre-en-compte-les-428a13 #### Conseil n°47 - Critère : Est il prévu des réunions pour que le cellule urbanisation évalue les évolutions du SI au regard de la conception, évolution mise en place ? - Justification : Les enjeux NR ne sont jamais établis définitivement et doivent faire l'objet d'un suivi périodique - Tests : Comment sont planifiés et évalués les demandes d'évolutions ? - Niveau : B/B/A - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=8-architecture-les-enjeux-nr-ne-sont-jamais-etablis-0a2f27 ### Recommandation n°9 — Définir les objectifs NR du projet et leur adéquation dans le contexte opérationnel #### Conseil n°48 - Critère : Le schéma directeur de l'organisation propose-t-il des objectifs et actions Numérique Responsable qui vont influencer le design d'architecture ou les solutions d'urbanisation ? - Justification : L'intégration du Numérique Responsable dans la stratégie de l'entreprise est indispensable pour que ce concept soit propagé dans toutes les fonctions de l'organisation. En l'absence de cette stratégie globale, seule une pré-étude permet de positionner les objectifs généraux et de déterminer les leviers d'actions qui seront mis en oeuvre. - Tests : Le schéma directeur prend-il en compte des objectifs NR ? - Niveau : B/B/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=9-architecture-lintegration-du-numerique-responsable-dans-la-strategie-d369e6 #### Conseil n°49 - Critère : Les objectifs NR sont-ils qualifiés ? - Justification : L'adhésion aux ODD et aux principes NR doit être vérifiée pour situer la distance parcourue et restante par rapport aux objectifs. La qualification des objectifs sous forme d'indicateurs est une opération préalable indispensable - Tests : Quels indicateurs (Carbone, DEEE, ...) sont-ils exposés aux utilisateurs ? - Niveau : A/B/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=9-architecture-ladhesion-aux-odd-et-aux-principes-nr-d83385 #### Recommandation n°50 - Critère : L'ensemble des équipements techniques utilisés par le service sont-ils identifiés ? - Justification : La conception, le développement, les tests, la production, la gestion de disponibilité sont des étapes qui vont utiliser des ressources techniques. Chacune de ces ressources doit être identifiée et ses caractéristiques répertoriées. - Tests : Quels sont les équipements qui devront faire l'objet d'une acquisition ou d'un remplacement ? - Cas d’usage : Une gestion de configuration est mise en place - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=9-architecture-la-conception-le-developpement-les-tests-la-a62923 #### Recommandation n°51 - Critère : Pour chaque équipement, les caractéristiques sont-elles disponibles ? - Justification : La position de l'équipement dans son cycle de vie et son impact environnemental doivent être connus pour utiliser au mieux les équipements disponibles. - Tests : Les seuils sont-ils définis pour envisager le remplacement ? - Cas d’usage : Gestion de configuration - Niveau : B/C/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=9-architecture-la-position-de-lequipement-dans-son-cycle-538ede #### Recommandation n°52 - Critère : Chaque fonction du service est-elle appréhendée en regard de son importance dans le service ? - Justification : Les fonctionnalités les plus importantes sont parfois moins consommatrices de ressources que des fonctions marginales ce qui n'a pas de sens dans une démarche NR cohérente. - Tests : Avez-vous appliqué une démarche 80/20 pour chaque fonction en rapport avec ses impacts environnementaux et son importance ? - Cas d’usage : Analyse d'impact - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=9-architecture-les-fonctionnalites-les-plus-importantes-sont-parfois-7343f4 #### Conseil n°53 - Critère : Les fonctions secondaires ont-elles aussi un impact moindre sur l'impact environnemental ? - Justification : La cohérence NR pousse à s'assurer que les fonctions secondaires n'ont pas un impact environnemental plus important que les fonctions principales, les spécifications doivent clairement identifier les fonctions principales et secondaires et leur impact du point de vue NR - Tests : Les règles de validation des impacts NR des fonctions sont-elles décrites ? - Niveau : B/C/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=9-architecture-la-coherence-nr-pousse-a-sassurer-que-7ffa3c #### Conseil n°54 - Critère : Chacune des phases du cycle de vie (Démarrage, maturité, arrêt) sont-elles identifiées avec des actions spécifiques ? - Justification : La démarche ACV est une base de la prise en compte du NR dans la conception des services numériques, elle permet d'associer des actions à chaque étape du cycle de vie. - Tests : A quelle fréquence ces actions sont-elles revues ? - Niveau : B/B/B - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=9-architecture-la-demarche-acv-est-une-base-de-6ae302 #### Recommandation n°55 - Critère : Les données ACV sont-elles réutilisées dans le cas d'une adaptation d'un service existant ? - Justification : Les analyses ACV peuvent être réalisées sur des services existants afin de les rendre plus efficaces dans le cas d'une refonte ou adaptation d'un service existant - Tests : Quelles données ACV sont produites pour permettre leur réutilisation dans d'autres projets ? - Cas d’usage : Une ACV minimale ("screening") est disponible pour le service existant - Niveau : A/B/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=9-architecture-les-analyses-acv-peuvent-etre-realisees-sur-c8b496 #### Conseil n°56 - Critère : La durée du support du service numérique est-elle suffisante pour minimiser le renouvellement des équipements ? - Justification : Les besoins d'adaptation des matériels aux services en exploitation peuvent être une source d'impact environnemental important. - Tests : Le calcul pour la durée du support du service ou produit a-t-il pris en compte l'impact sur le renouvellement du matériel ? - Niveau : A/B/A - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=9-architecture-les-besoins-dadaptation-des-materiels-aux-services-db76ca #### Conseil n°57 - Critère : La production documentaire est-elle recherchée/revue/exploitée en amont de la démarche et produite en aval pour être ré-utilisée dans les projets suivants ? - Justification : D'une part, dans une organisation les projets présentent beaucoup de similitudes, d'autre part les aspects NR adressés dans les projets sont souvent du même ordre. Afin de capitaliser sur ces éléments et bénéficier des efforts produits, il est nécessaire de s'appuyer sur un socle de connaissances stables. Toutefois la maturité d'une organisation d'un point de vue NR est amenée à progresser, il faut donc que les étapes documentées puissent aussi suivre ces évolutions et participer activement à cet accroissement de maturité. - Tests : Quelle est la fréquence de revue collégiale des documents ? - Niveau : B/A/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=9-architecture-dune-part-dans-une-organisation-les-projets-ef57d7 ### Recommandation n°10 — Intégrer les équipes dans le projet #### Conseil n°58 - Critère : Chaque partie-prenante a-t-elle la latitude de prendre des décisions pouvant influer sur l'impact environnemental ? - Justification : Les décisions projets qui peuvent avoir un impact important sur l'environnement doivent pouvoir être prises rapidement. Pour cela il est indispensable de définir l'espace de décision de chaque acteur et les mécanismes de validation. En l'absence de cette clarification, des décisions erratiques, même pour de bonnes raisons, pourraient intervenir et décrédibiliser la démarche NR, ou entraîner une forme d'auto-censure limitant les bénéfices NR - Tests : Le processus de décision est-il exposé à tous ? - Niveau : A/A/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=10-architecture-les-decisions-projets-qui-peuvent-avoir-un-3d43c3 #### Conseil n°59 - Critère : Les aspects Numérique Responsable sont-ils propagés et entretenus sur l'ensemble des acteurs ? - Justification : Les définitions projet peuvent évoluer au fil du temps. Ces évolutions doivent systématiquement prendre en compte les aspects NR. Les adaptations sont le plus souvent le fait des métiers ou d'impératifs techniques. Les impacts environnementaux doivent pouvoir aussi avoir cette latitude avec des chemins de validation pré-définis. - Tests : Combien d'acteurs du département Architecture sont-ils sensibilisés et formés au Numérique Responsable ? - Niveau : B/A/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=10-architecture-les-definitions-projet-peuvent-evoluer-au-fil-7d2897 #### Recommandation n°60 - Critère : Les objectifs Numérique Responsable sont-ils qualifiés pour chaque type de public dans le design d'architecture ? - Justification : Pour exprimer clairement les objectifs NR dans chacune des étapes de conception d'architecture il est indispensable de situer les profils cibles et de leur associer des objectifs NR précis. - Tests : Comment sont valorisés les objectifs atteints ? - Cas d’usage : Plan de formation - Niveau : B/A/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=10-architecture-pour-exprimer-clairement-les-objectifs-nr-dans-ca2869 #### Conseil n°61 - Critère : L'architecte dispose-t-il d'un rôle dans la continuité du produit ? - Justification : Chaque étape projet doit s'attacher à prendre en compte la couverture la plus complète possible du cycle de vie produit. - Tests : Le périmètre d'action est-il étendu aux différentes phases projet ? - Niveau : B/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=10-architecture-chaque-etape-projet-doit-sattacher-a-prendre-ed6203 #### Conseil n°62 - Critère : L'animation de l'équipe projet intègre-t-elle une dimension Numérique Responsable ? - Justification : La prise en compte des aspects NR fait au démarrage de la conception peut être respectée mais dans un mode itératif il est possible de s'en écarter graduellement. Les revues du respect NR sont indispensables pour conserver la cohérence du projet. - Tests : Des revues Numérique Responsable sont-elles planifiées tout au long du projet ? - Niveau : B/A/A - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=10-architecture-la-prise-en-compte-des-aspects-nr-533902 ## Famille : Backend Le backend représente la traduction informatique des processus métiers, les moyens techniques et données mis en oeuvre pour leur utilisation, ainsi que toutes les interactions externes mises en oeuvre pour leur réalisation. ### Recommandation n°1 — Réduire l'impact des données de leur stockage et accès #### Recommandation n°1 - Critère : Est-ce que le nombre de requêtes est minimisé (proscrire l'usage de boucle) ? - Justification : Chaque échange va consommer des ressources sur l'émetteur et le destinataire, consommer des flux d'échange et des données. Il est nécessaire de réduire ces échanges - Tests : Combien de requêtes sont utilisées pour un parcours utilisateur ? - Cas d’usage : L'analyse des codes sources couvrent les éléments de performance. - Niveau : A/C/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-chaque-echange-va-consommer-des-ressources-sur-62f970 #### Conseil n°2 - Critère : Est-ce qu'une alternative aux requêtes SQL est utilisée quand c'est possible (local storage ou assimilé) ? - Justification : Les moteurs de gestion de bases de données procurent des solutions techniques performantes mais au détriment de mécanismes techniques complexes et donc consommateurs de ressources. Parfois des solutions plus simples apportent un résultat similaire avec une déperdition moindre. - Tests : Quelles données sont candidates à un stockage local ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-les-moteurs-de-gestion-de-bases-de-c96f8b #### Recommandation n°3 - Critère : Est-ce que les requêtes implémentées utilisent les jointures plutôt que de multiplier les requêtes ? - Justification : Les mécanismes d'accès aux données peuvent engendrer des temps de traitement importants et donc une utilisation importante de ressources. Le plus souvent ces charges sont associées à une session utilisateur et donc se multiplient avec l'augmentation du trafic sur le service. Les moteurs de SGBD proposent plusieurs mécanismes d'analyse efficaces vis-à-vis de l'organisation des données et du besoin. Réduire la charge d'accès aux données pour une session utilisateur est utile d'un point de vue environnemental et efficace pour les performances techniques du service. - Tests : La performance des jointures est-elle optimisée ? - Cas d’usage : Code source - SGBD - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-les-mecanismes-dacces-aux-donnees-peuvent-engendrer-8982d6 #### Conseil n°4 - Critère : Est-ce que les données peuvent être sauvegardées de manière incrémentale ? - Justification : Une donnée est présente dans plusieurs environnements différents, notamment sur chaque sauvegarde. Cela va consommer de l'espace, des flux de transfert si les sauvegardes sont externalisées. La présence d'une donnée non modifiée sur tous les jeux de sauvegardes n'apporte que très peu de valeur par rapport au coût que cela représente. Les solutions incrémentales de sauvegardes doivent être mises en oeuvre pour réduire l'impact de cette sécurisation indispensable. - Tests : Quel est le volume cumulé sur un mois des sauvegardes ? - Niveau : A/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-une-donnee-est-presente-dans-plusieurs-environnements-be4dbf #### Recommandation n°5 - Critère : Est-ce que la suppression des données obsolètes est gérée ? - Justification : La réglementation impose de maîtriser le cycle de vie des données pour certaines catégories (données personnelles encadrées par le RGPD). Les autres catégories de données ne sont pas prises en compte, ce qui conduit à accumuler les données sans prendre en compte les délais de péremptions, ce qui introduit un accroissement permanent de la volumétrie de données, des volumes de sauvegardes, de ressources consommées par les accès aux données. Au fil du temps, le niveau de précision des données perd de son importance ce qui doit conduire à réduire la volumétrie dans la phase précédant le retrait pur et simple. - Tests : Les durées de vie des données sont-elles gérées ? - Cas d’usage : L'analyse d'impact détermne les actions de réduction des impacts avec les acteurs concernés - Niveau : A/C/A - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-la-reglementation-impose-de-maitriser-le-cycle-46acee #### Recommandation n°6 - Critère : Est-ce que les index des bases de données sont cohérents par rapport aux opérations ? - Justification : L'organisation des données a un impact fort sur la performance de recherche dans un SGBD. Les règles de structuration des collections de données permettent d'optimiser ces points. Les moteurs de SGBD disposent aussi d'indicateurs de performance qui facilitent les démarches d'optimisation. Moins de temps et de traitement d'accès aux données engendre moins de consommations d'énergies et un besoin plus faible de surdimensionnement des serveurs qui hébergent ces moteurs. - Tests : Les performances des index sont-elles revues périodiquement ? - Cas d’usage : L'administration des SGBD permet de suivre les performances des index et les besoins de restructuration des bases de données - Niveau : A/C/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-lorganisation-des-donnees-a-un-impact-fort-452d9e #### Conseil n°7 - Critère : Une alternative au modèle relationnel est-elle envisagée ? - Justification : Les modèles relationnels des SGBD offrent des solutions efficaces pour gérer des structures de données très segmentées, mais en contrepartie ces moteurs de SGBD sont plus consommateurs de ressources techniques. Des modèles alternatifs peuvent être plus efficaces (NoSQL) pour certaines catégories d'usage. - Tests : Est-ce qu'une solution NoSql est mise en place ? - Niveau : B/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-les-modeles-relationnels-des-sgbd-offrent-des-3b6bce #### Conseil n°8 - Critère : Est-ce qu'une solution NoSql est plus efficiente que son équivalent relationnel ? - Justification : La prédiction de gain de performance entre un modèle relationnel et NoSql est difficile et très dépendante de l'organisation et de l'usage des collections de données. Seule une étude comparative sur un échantillon pourra permettre d'établir les gains et bénéfices de chaque alternative. - Tests : Quel serait le gain d'une solution NoSql ? - Niveau : B/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-la-prediction-de-gain-de-performance-entre-3aefd5 #### Conseil n°9 - Critère : Est-ce que les différentes solutions d'accès aux données (requêtes, triggers, procédures stockées) ont été testées ? - Justification : Les différentes méthodes d'accès aux données fournies par les moteurs SGBD peuvent produire des consommations de ressources différentes pour un résultat similaire. Parmi ces solutions, les requêtes, les procédures stockées, les triggers doivent être évalués pour déterminer pour chaque usage le meilleur candidat, qui réduira la consommation de ressources. - Tests : Les performances des différentes solutions triggers, procédures stockées, requêtes sont-elles disponibles ? - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-les-differentes-methodes-dacces-aux-donnees-fournies-3ea379 #### Conseil n°10 - Critère : Est-ce que les clauses EXPLAIN sont utilisées sur les requêtes issues des "Slow query" pour optimiser les index ? - Justification : La plupart des moteurs de SGBD disposent en standard d'un mode de supervision permettant d'identifier les actions les plus consommatrices de ressources. Les méthodes d'investigations des traitements identifiés comme "lourds" sont aussi fournies par les moteurs afin de donner les axes d'amélioration possibles pour réduire les délais et charges des opérations. - Tests : Est-ce que les critères permettant d'identifier une slow query sont clairement définis? - Niveau : A/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-la-plupart-des-moteurs-de-sgbd-disposent-818c75 #### Conseil n°11 - Critère : Les seuils de détection de slow query sont-ils définis de manière efficace ? - Justification : Même si la structure des données n'évolue pas, les volumétries vont changer entre la conception et l'usage du service. Cette volumétrie peut entraîner des phénomènes de charge ou de contentions de ressources qui n'étaient pas apparents auparavant. Le suivi de l'évolution des traitements les plus consommateurs est indispensable durant toute la vie du service. - Tests : Les seuils des slow query sont-ils revus périodiquement ? - Niveau : B/C/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-meme-si-la-structure-des-donnees-nevolue-aaf81c #### Recommandation n°12 - Critère : Est-ce que les données "vivantes" et "mortes" sont gérées de manière différentes (ex: Stockage lent pour les données "mortes") ? - Justification : Les données d'historiques doivent être conservées pour des raisons légales ou de fonctionnalités du service. Les taux d'utilisation des données inactives ne justifient pas l'usage de mécanismes de haute performance pour leur stockage. Les mécanismes de stockage les plus performants sont aussi souvent ceux qui sont les plus consommateurs d'énergie ou qui ont un cycle de renouvellement physique plus court. - Tests : Quelle volumétrie de données inactives est conservée ? - Cas d’usage : Analyse d'impact - Niveau : B/C/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-les-donnees-dhistoriques-doivent-etre-conservees-pour-8a647f #### Recommandation n°13 - Critère : Est-ce que les données souvent accédées sont disponibles en RAM ? - Justification : La consommation de ressources de traitement est plus importante lorsque les informations doivent être collectées sur des supports physiques (disques, réseaux) plutôt qu'en mémoire RAM. Les données les plus fréquemment accédées doivent bénéficier de cette solution pour réduire l'énergie d'accès, la performance sera aussi plus élevée. - Tests : Quel taux d'accès physique aux données est mesuré ? - Cas d’usage : Dossier technique - Niveau : B/C/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-la-consommation-de-ressources-de-traitement-est-bc0308 #### Recommandation n°14 - Critère : Est-ce que les réplications de données entre plusieurs instances de moteur de base de données (Cluster) sont adaptées à la sensibilité et au besoin de disponibilité ? - Justification : Une même donnée peut être dupliquée pour assurer les besoins de disponibilité et de sécurisation. La redondance est efficace pour sécuriser les données, mais toutes les données ne justifient pas cette précaution qui augmente les volumes de stockage et génèrent des traitements de synchronisation. Seules les données sensibles doivent être sécurisées avec des mécanismes de redondance les plus efficaces. La mise en cluster de moteurs de SGBD permet de gérer la défaillance d'un moteur. Si en plus chaque moteur utilisent des stockages redondants (Mirroring, RAID 5, ...) la même donnée à une empreinte qui peut être multipliée par 6 (le plus souvent un cluster contient 3 instances pour gérer les quorums en cas de défaillance d'un noeud). - Tests : Les données dupliquées sont-elles tracées et en rapport avec leur sensibilité ? - Cas d’usage : Le dossier technique détermine les sensibilités des données et le mode de redondance à appliquer pour assurer la disponibilité requise - Niveau : A/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-une-meme-donnee-peut-etre-dupliquee-pour-2c10c7 #### Recommandation n°15 - Critère : Les données ont-elles une date d'expiration à laquelle elles sont supprimées ? - Justification : Les spécifications font apparaître des collections de données des procédures asynchrones ou des tâches périodiques indispensables au bon fonctionnement du service. Ces éléments sont le plus souvent invisibles et en l'absence de spécifications explicites des processus de retrait ils sont rarement pris en compte dans les fins d'exploitation d'un service. Chacun de ces éléments doit porter sa propre information de fin de vie. - Tests : A quelle fréquence sont vérifiées les dates d'expiration ? - Cas d’usage : Dossier technique - Niveau : B/C/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-les-specifications-font-apparaitre-des-collections-de-811aa4 #### Recommandation n°16 - Critère : Est-ce que des données sensibles sont collectées et sont-elles indispensables ? - Justification : Les données que les utilisateurs confient sont sous votre responsabilité et les utilisateurs doivent être tenus informés du soin que vous mettez en oeuvre pour assurer la confidentialité de ces données. Le RGPD impose un cadre pour les données personnelles mais ne couvre pas les autres catégories qui mériteraient les mêmes précautions. Le registre des traitements, le PIA du RGPD doivent être réalisés, mis à jour et validés par le DPO (Délégué à la Protection de Données). Les données échangées avec d'autres prestataires doivent faire l'objet d'une analyse de responsabilité. Limiter la collecte de données sensibles, au-delà du respect de l'utilisateur, réduit aussi la charge et la responsabilité d'administration de ces données personnelles - Tests : Combien de données sont identifiées comme sensibles aux sens RGPD ? - Cas d’usage : Liasse RGPD - Niveau : B/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-les-donnees-que-les-utilisateurs-confient-sont-5a1bdb #### Recommandation n°17 - Critère : Est-ce que les données collectées sont réellement utiles ? - Justification : Les données que les utilisateurs confient sont sous votre responsabilité et les utilisateurs doivent être tenus informés du soin que vous mettez en oeuvre pour assurer la confidentialité de leurs données. Le RGPD impose un cadre pour les données personnelles mais ne couvre pas les autres catégories qui mériteraient les mêmes précautions. L'empreinte des données du service se répercute tout au long du cycle de vie du service, la réduction du volume de données collectées est indispensable pour limiter ces impacts - Tests : Chaque donnée est-elle associée à un traitement ? - Cas d’usage : Navigation / CHROME : network - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-les-donnees-que-les-utilisateurs-confient-sont-325e2b #### Recommandation n°18 - Critère : Est-ce que l'API fournit des limites, des filtres et la liste des champs à retourner ? - Justification : Les parcours et besoins des utilisateurs sont très difficilement anticipables. Une tendance consiste à fournir au front end un maximum de données pour couvrir le maximum de cas d'utilisation. Cette pratique est inefficace d'un point de vue NR car la collecte, le traitement et l'acheminement des données génèrent une charge et donc une consommation énergétique importante sans certitude que toutes ces données seront effectivement utilisées. L'empreinte du service doit être réduite en ne collectant que les données indispensables au fur et à mesure du déroulement du service via les mécanismes API. - Tests : Quel volume maximum est retourné par les API ? ; Est-ce que la pagination est gérée dans les appels API ? ; La volumétrie des échanges API est-il borné ? - Cas d’usage : L'analyse des codes sources, recherche les paramétrages des appels API sans définitions de limites. Les outils de développement et la console des navigateurs permettent de tracer les flux échangés, leurs volumes et fréquences (ex: CHROME : console / network) - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-les-parcours-et-besoins-des-utilisateurs-sont-701a53 #### Recommandation n°19 - Critère : Est-ce que les données sensibles des utilisateurs sont sécurisées ? - Justification : Le RGPD impose l'établissement d'un PIA, celui-ci doit être réellement suivi et intégré dans les processus qualité. En préalable, toutes les solutions de sécurisation des données sensibles doivent être déployées et validées. - Tests : Quelles procédures de sécurisation sont associées aux données sensibles ? - Cas d’usage : Analyse de risques - Niveau : B/A/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-le-rgpd-impose-letablissement-dun-pia-celui-ci-2c3b43 #### Conseil n°20 - Critère : Les données réglementées (personnelles, santé, financières) sont-elles conformes aux recommandations de structuration de ces catégories de données ? - Justification : Le cadre réglementaire de certaines catégories de données est très strict, le respect de ces données pour protéger les utilisateurs est un critère important. Il est indispensable que dans le processus de développement aucune brèche ne soit possible et que toutes les interopérabilités avec les mécanismes standards de ces domaines soient validées. - Tests : Combien de données réglementées sont utilisées ? - Niveau : C/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=1-backend-le-cadre-reglementaire-de-certaines-categories-de-7dbc6c ### Recommandation n°2 — Utiliser les composants techniques qui améliorent les aspects NR, sécurité et performance #### Conseil n°21 - Critère : Est-ce que le serveur web utilisé est asynchrone et multi-thread ? - Justification : Les architectures physiques des serveurs disposent de mécanismes permettant d'optimiser les gestions de threads. Les logiciels doivent être en mesures d'exploiter ces fonctionnalités pour optimiser l'utilisation des ressources physiques pour limiter les besoins de sur-dimensionnement des équipements pour traiter la charge opérationnelle des services. - Tests : Quel serveur http est utilisé ? - Niveau : B/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-les-architectures-physiques-des-serveurs-disposent-de-ec88d3 #### Conseil n°22 - Critère : Est-ce que l'on a évalué l'arbre de dépendance des composants intégrés ? - Justification : Bien souvent les composants issus de bibliothèques publiques (open source ou commerciales) apportent un ensemble de fonctionnalités qui ne sont que rarement toutes utilisées et drainent des dépendances vis-à-vis d'autres composants avec les mêmes caractéristiques. Au final le projet agrège un volume de bibliothèques important alors qu'une petite partie est réellement utilisée. Privilégier les composants dont les dépendances et fonctionnalités sont pilotables par rapport aux besoins est efficace du point de vue NR. - Tests : Le graphe de dépendance est-il généré ? ; La possibilité de limiter les dépendances fait-elle partie des critères de sélection des solutions techniques ? - Niveau : B/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-bien-souvent-les-composants-issus-de-bibliotheques-66c78e #### Conseil n°23 - Critère : Est-ce que l'on peut réduire les dépendances avec un composant alternatif ? - Justification : Les arbres de dépendance donnent la cartographie des composants et leurs relations. Un arbre de dépendance le plus réduit possible est efficace car il réduit les volumes de code, mais cela ne présume pas que chaque branche de cet arbre de dépendance est justifiée par une utilisation effective. - Tests : Le graphe de dépendance est-il disponible pour chaque composant ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-les-arbres-de-dependance-donnent-la-cartographie-28ac8b #### Conseil n°24 - Critère : Est-ce que l'utilisateur est informé d'un traitement en cours en arrière-plan ? - Justification : Certains traitements sont invisibles du point de vue utilisateur, mais peuvent produire des délais de réponse incompris et inciter l'utilisateur à renouveler ses opérations. La multiplication des demandes de traitements inutiles dégradent les performances NR. - Tests : La liste des traitements qui ne nécessitent pas un résultat immédiat est-elle établie ? - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-certains-traitements-sont-invisibles-du-point-de-051131 #### Conseil n°25 - Critère : Est-ce que l'intégration d'un traitement asynchrone a été évaluée ? - Justification : Le traitement différé d'opérations permet de diluer sur une période de temps plus longue les demandes de charges sur les systèmes. - Tests : L'impact de délai est-il évalué ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-le-traitement-differe-doperations-permet-de-diluer-1d8156 #### Recommandation n°26 - Critère : Est-ce que les ressources inutilisées sont bien libérées au plus vite ? - Justification : Les techniques de développement affranchissent les développeurs de l'allocation et la libération explicite des ressources utilisées. Néanmoins le volume des ressources est conditionné par la portée des informations et l'utilisation généralisée de données à portée globale va entraîner une surcharge de consommation qui peut conduire à un sur-dimensionnement des équipements alors qu'une utilisation plus rationnelle permettrait de s'en dispenser. - Tests : Les données locales sont-elles libérées dès qu'elles ne sont plus utiles ? - Cas d’usage : L'analyse des codes source valide la libération des ressources - Niveau : A/B/A - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-les-techniques-de-developpement-affranchissent-les-developpeurs-bd0639 #### Conseil n°27 - Critère : Est-ce qu'une VM est indispensable par rapport à une solution container ? - Justification : Les techniques de virtualisation par Machines Virtuelles dupliquent l'intégralité des systèmes d'exploitation et cloisonnent les accès aux composants physiques. D'autres techniques à base de containers sont plus économiques en terme de duplication et leur proximité avec les composants physiques permettent une meilleure utilisation et supervision de ces ressources. - Tests : L'impact NR est-il évalué pour chaque solution ? - Niveau : B/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-les-techniques-de-virtualisation-par-machines-virtuelles-dbd2c3 #### Recommandation n°28 - Critère : La disponibilité du service nécessite-t-elle une redondance ? - Justification : La redondance permet de garantir un niveau de service élevé. Cette solution nécessite beaucoup de duplications des équipements physiques, des réseaux, des stockages. Cette tolérance aux pannes est parfois justifiée par les fonctionnalités du service, et parfois va au-delà des exigences. L'adaptation du niveau de service et du besoin du service permet de réduire l'impact environnemental. - Tests : Le SLA est-il défini ? - Cas d’usage : Analyse de risques - Niveau : B/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-la-redondance-permet-de-garantir-un-niveau-7e6d23 #### Recommandation n°29 - Critère : Les interactions entre les composants bénéficient-ils de systèmes de cache ? - Justification : La réduction des volumes d'échanges, des opérations de calculs, traitements, et accès aux données est un axe d'optimisation des consommations de ressources. La mise en place de systèmes de cache permet de réduire les coûts des opérations répétitives. Les mécanismes de cache peuvent être déployés à différents points de passage dans un service. Plus le cache est proche du demandeur qu'il doit servir, plus le volume de données en transit et la longueur du chemin emprunté par les données sont faibles. Plus le cache est proche de la source de données, plus il peut être mutualisé par un nombre important d'utilisateurs mais les données seront tout de même échangées, seules les opérations de traitements et collectes seront réduites. - Tests : Quel système de cache est associé aux interactions entre composants ? - Cas d’usage : Le dossier technique identifie les caches et la stratégie de cache utilisée pour chaque type de flux. Les outils de gestions des caches (purge / désactivation) sont utilisés pour valider les performances effectives (ex: CHROME : console /network enable - disable cache) - Niveau : A/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-la-reduction-des-volumes-dechanges-des-operations-dfb3ce #### Recommandation n°30 - Critère : Est-ce que le framework ou la technologie utilisée ne bloque pas les caches navigateur ? - Justification : L'utilisation de certains framework notamment dans les cas d'application single page rendent difficiles la gestion du cache sur le périphérique utilisateur. Les technologies employées et les principes de développement doivent limiter ces effets parasites qui vont surcharger les besoins d'échanges alors qu'il n'y a pas lieu. - Tests : Le cache navigateur est-il sollicité ? - Cas d’usage : Dossier technique - Niveau : B/C/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-lutilisation-de-certains-framework-notamment-dans-les-56566f #### Conseil n°31 - Critère : Existe-t-il un framework/library plus léger répondant au besoin fonctionnel ? - Justification : A périmètre fonctionnel égal, plusieurs solutions techniques sont envisageables. Plus le framework est réduit, plus son impact environnemental sera réduit car les flux seront minimisés et les consommations de ressources de traitements réduites. Les performances techniques vont aussi dans la même direction. - Tests : L'étude des frameworks envisagés est-elle disponible et revue ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-a-perimetre-fonctionnel-egal-plusieurs-solutions-techniques-2eacdc #### Conseil n°32 - Critère : Est-ce qu'une solution Open Source est disponible pour le besoin fonctionnel ? - Justification : Une solution Open Source n'est pas un gage d'efficacité NR et les différentes alternatives doivent être challengées. Mais l'Open Source permet de limiter les ambitions et mainmises de certains acteurs dont les pratiques économiques, sociales sont opaques. - Tests : La performance NR de la solution open source est-elle un critère de choix ? - Niveau : B/B/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-une-solution-open-source-nest-pas-un-c9d0cb #### Conseil n°33 - Critère : Est-ce que les versions des composants utilisés sont suivies et appliquées ? - Justification : Capitaliser sur les meilleures pratiques déployées est un gage d'efficacité environnementale et opérationnelle. Les avancées techniques étant rapides il est important de propager rapidement tous les bénéfices environnementaux qui pourraient être intégrés dans un composant, dans le cadre du suivi de l'état de l'art et des performances environnementales. - Tests : Quelle est la fréquence de mise à jour des composants ? - Niveau : B/B/B - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-capitaliser-sur-les-meilleures-pratiques-deployees-est-f3590a #### Recommandation n°34 - Critère : Est-ce que la sécurisation implémentée est justifiée au regard des opérations réalisées ? - Justification : L'implémentation de sécurisation génère une empreinte environnementale supplémentaire qui doit être en rapport avec l'aspect critique de l'opération concernée, plutôt que dans un mode de généralisation du niveau de sécurisation de tout le service. Cette segmentation de niveau de sécurisation doit avoir un bénéfice global, et ne pas engendrer de surcoût d'impact. - Tests : Chaque opération est-elle associée à une exigence de sécurisation ? - Cas d’usage : Analyse de risques - Niveau : B/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-limplementation-de-securisation-genere-une-empreinte-environnementale-fa8b44 #### Conseil n°35 - Critère : Le niveau des logs est-il adapté à l'environnement ? - Justification : La mise en oeuvre de services est associée à la production d'informations permettant son contrôle, tels que les événements d'anomalies, les traces d'exécution de debug. Ces logs générées automatiquement sont utiles si elles sont réellement exploitées pour fiabiliser le service, mais génèrent un gaspillage de ressources lorsqu'elles sont collectées pour être ignorées. - Tests : Les niveaux de log de trace et debug sont-ils désactivés en production ? - Niveau : B/C/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-la-mise-en-oeuvre-de-services-est-38e5ef #### Recommandation n°36 - Critère : Est-ce que les fichiers temporaires sont inclus dans les "logrotate" ? - Justification : Dans les processus d'exécution des fichiers temporaires sont produits. Ces fichiers inutiles, après leur utilisation très ponctuelle, doivent être supprimés des espaces de stockage. Les mécanismes de nettoyages de ces fichiers temporaires sont disponibles sur tous les systèmes d'exploitation et doivent être mis en oeuvre. - Tests : Les suppressions automatiques des fichiers temporaires sont-elles gérées ? - Cas d’usage : File system - Niveau : B/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-dans-les-processus-dexecution-des-fichiers-temporaires-a8a74f #### Recommandation n°37 - Critère : Les fonctionnalités sont-elles documentées pour permettre leur réutilisation ? - Justification : D'une part dans une organisation les projets présentent beaucoup de similitudes, d'autre part les aspects NR adressés dans les projets sont souvent du même ordre. Afin de capitaliser sur ces éléments et bénéficier des efforts produits, il est nécessaire de s'appuyer sur un socle de connaissances stables. Toutefois la maturité d'une organisation d'un point de vue NR est amenée à progresser, il faut donc que les étapes documentées puissent aussi suivre ces évolutions et participer activement à cet accroissement de maturité. - Tests : Quelles informations de conception sont consignées pour être réutilisées dans les autres projets ? - Cas d’usage : La documentation technique intègre des éléments NR - Niveau : B/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=2-backend-dune-part-dans-une-organisation-les-projets-7b5b44 ### Recommandation n°3 — Limiter la volumétrie des échanges #### Recommandation n°38 - Critère : Est-ce que les données échangées sont compressées / minifiées avant transmission ? - Justification : Les échanges indispensables doivent permettre de réduire la volumétrie des transferts. La minification des échanges, la compression des données échangées permettent de réduire ces volumes. Toutefois les opérations de compression et décompression nécessitent des exécutions de traitements qui peuvent annuler le bénéfice de la compression des échanges. - Tests : Quel gain est obtenu par compression ? ; Les données de production sont-elles systématiquement minifiées ? - Cas d’usage : Les outils/consoles de développement et les extensions des navigateurs permettent de vérifier les bonnes pratiques (ex : CHROME - Extension greenIT / bonnes pratiques) - Niveau : A/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-backend-les-echanges-indispensables-doivent-permettre-de-reduire-2813ee #### Recommandation n°39 - Critère : Est-ce que la pagination est utilisée sur les échanges de données ? - Justification : Les capacité de restitution d'information des périphériques utilisateur sont limitées. D'autre part la capacité d'assimilation de données par l'utilisateur est aussi contrainte. Il serait inefficace que le volume de données transmis soit au-delà de ces limites, cela conduirait à un gaspillage de l'utilisation de ressources de traitement. - Tests : Les volumes de données transmis sont-ils en rapport avec les capacités de présentation du périphérique utilisateur ? - Cas d’usage : L'analyse des codes sources, recherche les paramétrages des appels API sans définitions de limites. Les outils de développement et la console des navigateurs permettent de tracer les flux échangés, leurs volumes et fréquences (ex: CHROME : console / network) - Niveau : A/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-backend-les-capacite-de-restitution-dinformation-des-peripheriques-38f9df #### Recommandation n°40 - Critère : Est-ce que le nombre de requêtes entre le client et le serveur est minimisé ? - Justification : Les opérations réalisées sur le front end génèrent des requêtes vers les services distants. Plus le nombre de requêtes est important plus les mécanismes de traitements et d'échanges vont consommer de ressources. Le périmètre et la conception des requêtes du back end doivent permettre de limiter le nombre de requêtes. - Tests : Combien de requêtes sont nécessaires pour un parcours utilisateur ? - Cas d’usage : L'analyse des codes sources, recherche des appels API. Les outils de développement et la console des navigateurs permettent de tracer les flux échangés, leurs volumes et fréquences (ex: CHROME : console / network) - Niveau : A/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-backend-les-operations-realisees-sur-le-front-end-0e6d1e #### Recommandation n°41 - Critère : Est-ce que les données échangées correspondent uniquement au besoin immédiat ? - Justification : Le périmètre et la conception des requêtes du back end doivent permettre de limiter le volume de données échangées pour satisfaire au fur et à mesure de son parcours, les besoins utilisateurs sans anticiper sur des prédictions d'usage hypothétiques. - Tests : Les requêtes ont-elles une portée en rapport avec l'usage ? - Cas d’usage : Navigation / CHROME : network - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-backend-le-perimetre-et-la-conception-des-requetes-1a136c ### Recommandation n°4 — Utiliser des principes de développement qui réduisent les impacts #### Recommandation n°42 - Critère : Les notifications utilisateurs sont-elles nécessaires ? - Justification : Les méthodes de notifications peuvent employer des technologies consommatrices de ressources et certaines pratiques visent à les multiplier ce qui augmente l'empreinte environnementale du service. Réduire les notifications, utiliser des mécanismes légers, et permettre à l'utilisateur de désactiver ces notifications est utile pour réduire les consommations d'énergie ainsi que le détournement d'attention des utilisateurs. - Tests : Quelles solutions de notifications sont utilisées ? - Cas d’usage : Parcours utilisateurs - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-backend-les-methodes-de-notifications-peuvent-employer-des-80e62d #### Conseil n°43 - Critère : Est-ce que le SSO est implémenté lorsqu'il est possible ? - Justification : La réduction des opérations d'identification utilisateur permet d'alléger la charge de traitement et de sécurisation. - Tests : Les phases d'identification sont-elles simplifiées ? - Niveau : B/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-backend-la-reduction-des-operations-didentification-utilisateur-permet-4969ea #### Conseil n°44 - Critère : Quel serait mon réflexe de dev, pour prendre en compte le cycle de vie ? - Justification : La prise en compte du cycle doit être intégrée dans les phases de développement. Les développeurs sont les principaux acteurs qui, par leurs choix, leurs pratiques vont conditionner les résultats futurs. La prise en compte du cycle de vie dans le développement est indispensable. Il serait plus coûteux, plus risqué et moins efficace de traiter les aspects de cycle de vie en aval. - Tests : Quelles procédures sont disponibles pour traiter le cycle de vie ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=4-backend-la-prise-en-compte-du-cycle-doit-c6a7f0 #### Conseil n°45 - Critère : Chaque partie-prenante a-t-elle la latitude de prendre des décisions pouvant influer sur l'impact environnemental ? - Justification : Les orientations des développement peuvent évoluer au fil du temps. Ces évolutions doivent systématiquement prendre en compte les aspects NR. Les adaptations sont le plus souvent le fait des métiers. Des contraintes techniques qui apparaissent au cours du développement et engendrant des impacts environnementaux doivent pouvoir aussi être traités par les équipes techniques avec des chemins de validation pré-définis. - Tests : Le circuit et l'autonomie de décision ayant un impact NR est-il défini pour chaque acteur ? - Niveau : B/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=4-backend-les-orientations-des-developpement-peuvent-evoluer-au-3d43c3 #### Recommandation n°46 - Critère : L'analyse de code est-elle utilisée dans le processus d'intégration continue ? - Justification : La standardisation et la vérification de conformité des codes produits permet d'identifier le respect des recommandations NR et d'affiner le suivi de ces pratiques. - Tests : Tous les codes produits sont-ils analysés ? ; Est-ce qu'un outil d'analyse de qualité du code a été intégré dans le processus d'intégration continue ? ; L'étape de validation est-elle incontournable dans le processus de livraison ? - Cas d’usage : Intégration continue - Niveau : C/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=4-backend-la-standardisation-et-la-verification-de-conformite-572385 #### Recommandation n°47 - Critère : Est-ce que les métriques de qualité du code sont suivies ? - Justification : La qualité du logiciel produit à un impact direct sur les aspects NR. Les défauts entraînent de multiples livraisons de nouvelles versions successives, les anomalies entraînent des productions de traces d'anomalies importantes, et des fonctionnalités plus consommatrices de ressources techniques, parfois pour un résultat non atteint, donc des ressources ont été gaspillées pour ne produire aucun résultat. - Tests : Les défauts sont-ils tracés et revus avec leurs impacts sur le NR ? - Cas d’usage : Intégration continue - Niveau : C/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=4-backend-la-qualite-du-logiciel-produit-a-un-360653 #### Conseil n°48 - Critère : Les rapports de tests des fonctionnalités sont-ils disponibles et suivis ? - Justification : La couverture des tests fonctionnels et la qualité gagnée par la prise en compte de tous les cas de tests permet de fiabiliser les développements, et d'éviter des fonctionnements logiciels inefficaces qui consomment des ressources techniques sans rendre la fonctionnalité et génère de multiples mises à jour. A l'insatisfaction des utilisateurs s'ajoute la frustration des équipes de développement qui doivent traiter la non-qualité sans pouvoir progresser dans leurs métiers. - Tests : Les améliorations NR identifiées sont-elles systématiquement prises en compte ? - Niveau : B/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=4-backend-la-couverture-des-tests-fonctionnels-et-la-6a92fe #### Conseil n°49 - Critère : Est-ce que les outils de suivi des performances NR ont été identifiés et mis à disposition des développeurs ? - Justification : Les avancées techniques du NR vont permettre de fournir des outils facilitant l'implémentation et le suivi des performances NR. Les outils référencés pour assister les développements vont se multiplier avec l'augmentation de maturité NR de l'ensemble des organisations. Les premiers outils disponibles étaient orientés sur les usages du point de vue utilisateur, les seuls outils pour les traitements côté serveurs sont ceux utilisés pour le suivi des performances techniques. Les performances techniques et NR vont en majorité dans le même sens. - Tests : La liste des outils est-elle publiée ? - Niveau : A/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=4-backend-les-avancees-techniques-du-nr-vont-permettre-71b2e7 #### Conseil n°50 - Critère : Une analyse du profil de consommation de l'application a-t-elle été effectuée ? - Justification : La consommation de ressources des codes peut être analysée avec des outils qui tracent l'ensemble des appels et les coûts unitaires et globaux de chaque fonctions ou méthodes. Ce profil de consommation est un bon point de départ pour réduire la consommation du service. En fonction des usages, le profil peut être amené à changer est doit faire l'objet de suivis réguliers. - Tests : A quelle fréquence est revue cette analyse ? - Niveau : A/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=4-backend-la-consommation-de-ressources-des-codes-peut-1c222a #### Conseil n°51 - Critère : Est-ce que chaque version déployée suit le même processus de qualification des performances NR ? - Justification : Chaque mise à jour peut améliorer l'impact environnemental du service ou l'annuler si ces principes NR ne sont pas systématiquement appliqués à chaque opération de maintenance applicative. Pour garder la cohérence et capitaliser sur les efforts et bénéfices réalisés, les phases de maintenance doivent suivre les mêmes démarches - Tests : Combien de mises à jour sont déployées par année ? ; Les processus de développement sont-ils identiques aux processus de mise à jour ? - Niveau : B/B/B - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=4-backend-chaque-mise-a-jour-peut-ameliorer-limpact-4376dc ### Recommandation n°5 — Contrôler les aspects réglementaires #### Recommandation n°52 - Critère : Est-ce que la cartographie des traitements (RGPD) est disponible ? - Justification : Les données que les utilisateurs confient sont sous votre responsabilité et les utilisateurs doivent être tenus informés du soin que vous mettez en oeuvre pour assurer la confidentialité de ces données. Le registre des traitements, le PIA du RGPD, doit être réalisé, mis à jour et validé par le DPO (Délégué à la Protection des Données). Les données échangées avec d'autres prestataires doivent faire l'objet d'une analyse de responsabilité. Limiter la collecte de données sensibles, au-delà du respect de l'utilisateur, réduit aussi la charge et la responsabilité d'administration de ces données personnelles. - Tests : Les traitements sont-ils validés par le DPO ? - Cas d’usage : Liasse RGPD - Niveau : C/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=5-backend-les-donnees-que-les-utilisateurs-confient-sont-77aa46 #### Recommandation n°53 - Critère : Est-ce que l'analyse de risques (RGPD) est réalisée ? - Justification : Les données que les utilisateurs confient sont sous votre responsabilité et les utilisateurs doivent être tenus informés du soin que vous mettez en oeuvre pour assurer la confidentialité de leurs données. Le registre des traitements, le PIA du RGPD doit être réalisé, mis à jour et validé par le DPO (Délégué à la Protection des Données). Les données échangées avec d'autres prestataires doivent faire l'objet d'une analyse de responsabilité. Limiter la collecte de données sensibles, au-delà du respect de l'utilisateur, réduit aussi la charge et la responsabilité d'administration de ces données personnelles - Tests : Le PIA est-il validé par le DPO ? - Cas d’usage : Liasse RGPD - Niveau : C/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=5-backend-les-donnees-que-les-utilisateurs-confient-sont-02f4c3 #### Recommandation n°54 - Critère : Est-ce que le RGAA est pris en compte ? - Justification : Le non-respect des réglementations est tout d'abord illégal et peut entraîner des pénalités importantes. Il coupe aussi des utilisateurs même hors du cadre du handicap de l'accès au service. - Tests : Les données personnelles sont-elles identifiées ? - Cas d’usage : Audit accessibilité - Niveau : C/A/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=5-backend-le-non-respect-des-reglementations-est-tout-dabord-3dc782 #### Recommandation n°55 - Critère : Est-ce que les données réglementées (bancaires, santé, ...) sont sécurisées ? - Justification : Le cadre réglementaire de certaines catégories de données est très strict. Le respect de ces données pour protéger les utilisateurs est un critère important. Il est indispensable que dans le processus de développement aucune brèche ne soit possible et que toutes les interopérabilités avec les mécanismes standards de ces domaines soient validées. - Tests : Est-ce que le système de paiement est conforme aux normes de sécurité en vigueur ? - Cas d’usage : Analyse de risques - Niveau : C/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=5-backend-le-cadre-reglementaire-de-certaines-categories-de-f11ba7 #### Conseil n°56 - Critère : Est-ce que des données réglementées sont utilisées ? - Justification : Le cadre réglementaire de certaines catégories de données est très strict. Le respect de ces données pour protéger les utilisateurs est un critère important. Il est indispensable que dans le processus de développement aucune brèche ne soit possible et que toutes les interopérabilités avec les mécanismes standards de ces domaines soient validées. - Tests : Combien de données réglementées sont utilisées ? - Niveau : C/A/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=5-backend-le-cadre-reglementaire-de-certaines-categories-de-006dad #### Recommandation n°57 - Critère : Le service en cours de conception est-il conforme aux évolutions de la société et de la législation ? - Justification : Au-delà des aspects purement réglementaires, l'anticipation de la prise en compte de l'évolution des attentes sociétales est nécessaire pour assurer une couverture de ce sujet durant toute la durée de vie du service. Anticiper les futurs points de règlement et normes permet de pérenniser le service en limitant les besoins de mises à jour dictées par l'environnement légal. - Tests : Le service juridique est-il consulté ? - Cas d’usage : Analyse de risques - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=5-backend-au-dela-des-aspects-purement-reglementaires-lanticipation-de-1be322 #### Recommandation n°58 - Critère : Le fournisseur d'infrastructures est-il en mesure d'exposer ses métriques environnementales ? - Justification : Dans les dimensions NR, les aspects humains, environnementaux et économiques occupent une place importante. S'assurer que tous les intervenants y compris chez les prestataires (et ses propres sous-traitants et fournisseurs) utilisés pour le projet disposent des mêmes attentions NR est nécessaire pour que la cohérence des efforts NR ne soit pas anéantie par un choix qui aurait pu être évité. - Tests : Quelles métriques sont collectées ? - Cas d’usage : Les procédures d'achat référencent les stratégies NR que doivent prendre en compte les fournisseurs. - Niveau : A/B/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=5-backend-dans-les-dimensions-nr-les-aspects-humains-f9bb3d ### Recommandation n°6 — Mettre en place une méthodologie qui favorise la prise en compte des aspects NR #### Conseil n°59 - Critère : Les aspects NR sont-ils propagés et entretenus sur l'ensemble des acteurs ? - Justification : Lorsque chacun des acteurs a un accès simple à des marqueurs permettant d'évaluer l'impact environnemental de ses actions et choix, il peut adapter ses pratiques pour rendre le service plus efficace et responsable. - Tests : Combien d'acteurs du département sont sensibilisés et formés au NR ? - Niveau : A/A/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-lorsque-chacun-des-acteurs-a-un-acces-2f833b #### Conseil n°60 - Critère : Un benchmark sur les critères environnementaux a-t-il été effectué pour le choix du fournisseur d'infrastructure ? - Justification : Les fournisseurs en mesure de communiquer leurs critères environnementaux affichent un niveau de maturité et une orientation importante. Cette capacité doit intervenir dans le choix des fournisseurs. - Tests : Quels seuils d'acceptabilité sont définis ? - Niveau : A/B/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-les-fournisseurs-en-mesure-de-communiquer-leurs-fc1cbe #### Conseil n°61 - Critère : Est-ce que le processus de conception / les outils intègrent le traitement des exigences NR ? - Justification : Chaque fonctionnalité mise en oeuvre doit disposer d'une prise en compte du NR pour que l'ensemble du service soit conçu avec le respect le plus complet des principes NR, un aspect non couvert pouvant annuler tout ou partie des bénéfices acquis par ailleurs. Il est plus efficace d'avoir un traitement équilibré sur l'ensemble, plutôt que viser l'excellence sur une partie et laisser des trous conséquents sur d'autres. - Tests : Combien d'exigences NR sont associées au projet ? - Niveau : A/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-chaque-fonctionnalite-mise-en-oeuvre-doit-disposer-ae6790 #### Recommandation n°62 - Critère : Est-ce que la fonctionnalité envisagée est utile ? - Justification : La sélection des fonctionnalités jugées indispensables peuvent être remises en cause dans leur forme initiale par rapport à leur impact NR. Dans ce cas, les coûts / bénéfices devront prendre en compte ces oppositions et faire l'objet d'adaptation pour faire converger les 2 approches : nécessité fonctionnelle et impact NR. - Tests : Chaque fonctionnalité est-elle associée à un usage identifié ? - Cas d’usage : Des données sont identifiées et collectées (analytics / sondes) en production pour identifier les usages et les fonctionnalités superflues. - Niveau : A/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-la-selection-des-fonctionnalites-jugees-indispensables-peuvent-7802b5 #### Recommandation n°63 - Critère : Le dimensionnement des ressources d'infrastructures suit-il la vie de l'application ? - Justification : Le taux d'utilisation des ressources physiques de l'infrastructure doit être suivi pour permettre une meilleure utilisation des matériels disponibles et éviter de déployer des éléments supplémentaires lorsque le taux d'utilisation n'est pas complet. - Tests : La métrologie est-elle définie et mise en place ? - Cas d’usage : Suivi de configuration - Niveau : B/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-le-taux-dutilisation-des-ressources-physiques-de-61f009 #### Recommandation n°64 - Critère : Est-ce que l'architecture technique est en permanence en rapport avec l'activité du service ? - Justification : Le suivi des taux utilisations doit aussi permettre de réduire la taille de l'infrastructure lorsqu'elle est sur-dimensionnée par rapport au besoin. - Tests : Le suivi des indicateurs d'activité sont-ils en relation avec des actions d'optimisation ? - Cas d’usage : Le suivi de production met en oeuvre des indicateurs d'utilisation des ressources techniques - Niveau : A/C/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-le-suivi-des-taux-utilisations-doit-aussi-9d2790 #### Conseil n°65 - Critère : Est-ce qu'un profil d'utilisation des fonctionnalités est mis en place ? - Justification : Les User Story / Use Case doivent être spécifiés par rapport à des usages afin de ne pas aller vers une inflation de fonctionnalités qui serait superflue par rapport aux besoins réels des utilisateurs. Proposer des fonctionnalités marginales va engendrer une empreinte environnementale, un coût et une incompréhension du service supplémentaire non justifiés. - Tests : Les fonctionnalités marginales sont-elles identifiées et traitées dans un mode dégradé ? - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-les-user-story-%2F-use-case-doivent-6ee2a2 #### Recommandation n°66 - Critère : Est-ce que les opérations de dé-provisionnement sont exprimées lors de la conception ? - Justification : Lors de la conception, chaque partie composant le projet peut être amenée à avoir une durée de vie différente. Il est important que l'ensemble des procédures de fin de vie soient exprimées pour que l'empreinte des composants inutilisés et arrêtés soient nulle. - Tests : Les processus de dé-provisionnement sont-ils décrits ? - Cas d’usage : La gestion de configuration permet de préciser les règles de provisionnemnent / dé-provisionnement en fonction de seuils - Niveau : A/C/A - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-lors-de-la-conception-chaque-partie-composant-ebabaf #### Recommandation n°67 - Critère : L'ensemble des équipements techniques utilisés par le service sont-ils identifiés ? - Justification : La conception, le développement, les tests, la production, la gestion de disponibilité sont des étapes qui vont utiliser des ressources techniques. Chacune de ces ressources doit être identifiée et ses caractéristiques répertoriées. - Tests : Les certifications de chaque équipement sont-elles disponibles ? - Cas d’usage : La gestion de configuration permet de référencer tous les équipements liés au service - Niveau : A/C/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-la-conception-le-developpement-les-tests-la-a62923 #### Recommandation n°68 - Critère : Pour chaque équipement, les caractéristiques sont-elles disponibles ? - Justification : La position de l'équipement dans son cycle de vie et son impact environnemental doivent être connus pour utiliser au mieux les équipements disponibles. - Tests : Les critères de renouvellement des équipements prennent-ils en compte les impacts NR ? - Cas d’usage : La gestion de configuration permet de référencer tous les équipements liés au service - Niveau : A/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-la-position-de-lequipement-dans-son-cycle-538ede #### Conseil n°69 - Critère : Chaque fonction du service est-elle appréhendée en regard de son importance dans le service ? - Justification : Les fonctionnalités les plus importantes sont parfois moins consommatrices de ressources que des fonctions marginales ce qui n'a pas de sens dans une démarche NR cohérente. - Tests : Avez-vous appliqué une démarche 80/20 pour chaque fonction en rapport avec ses impacts environnementaux et son importance ? - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-les-fonctionnalites-les-plus-importantes-sont-parfois-7343f4 #### Conseil n°70 - Critère : Les fonctions secondaires ont-elles aussi un impact moindre sur l'impact environnemental ? - Justification : La cohérence NR pousse à s'assurer que les fonctions secondaires n'ont pas un impact environnemental plus important que les fonctions principales. Les phases de développement doivent clairement identifier les fonctions principales et secondaires et leur impact du point de vue NR - Tests : Les impacts environnementaux de chaque fonctionnalité sont-ils évalués par rapport à la nature et l'importance de la fonctionnalité ? - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-la-coherence-nr-pousse-a-sassurer-que-7ffa3c #### Recommandation n°71 - Critère : Chacune des phases du cycle de vie sont-elles identifiées avec des actions spécifiques ? - Justification : La démarche ACV est une base de la prise en compte du NR dans la conception des services numériques, elle permet d'associer des actions à chaque étape du cycle de vie. - Tests : A quelle fréquence ces actions sont-elles revues ? - Cas d’usage : Analyse d'impact - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-la-demarche-acv-est-une-base-de-ddcfc4 #### Recommandation n°72 - Critère : Les données ACV sont-elles réutilisées dans le cas d'une adaptation d'un service existant ? - Justification : Les analyses ACV peuvent être réalisées sur des services existants afin de les rendre plus efficaces dans le cas d'une refonte ou adaptation d'un service existant. - Tests : Avez-vous mis à disposition des équipes projet les ACV précédentes ? ; L'ACV de ce projet est-elle rendue disponible pour d'autres projets ? - Cas d’usage : ACV - Niveau : C/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=6-backend-les-analyses-acv-peuvent-etre-realisees-sur-c8b496 ## Famille : Contenus Tous les éléments d'un service numérique disponibles pour l'utilisateur final. ### Recommandation n°1 — Appliquer une démarche éditoriale pour les contenus #### Recommandation n°1 - Critère : Est-ce que les prestataires retenus pour la production des contenus ont un engagement NR, RSE, accessibilité (formations, inclusion, éthique) ? - Justification : Beaucoup d'éléments sont produits en externe, il serait dommageable de casser une dynamique NR en choisissant des prestataires dont le NR n'est pas un moteur - Tests : Les indicateurs NR des fournisseurs entrent-ils dans le processus de sélection du fournisseur ? - Cas d’usage : Projet - Niveau : B/C/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=1-contenus-beaucoup-delements-sont-produits-en-externe-il-825521 #### Conseil n°2 - Critère : Est-ce que l'ensemble des sources utilisées a été vérifié ? - Justification : Les informations transmises peuvent être sujettes à controverses et vont nécessiter du temps et l'utilisation de ressources techniques ayant un impact environnemental, pour que les utilisateurs puissent les vérifier ou les utiliser sans être abusés - Tests : Avez-vous une validation formelle et la preuve de la validité des contenus tiers exposés ? - Niveau : C/A/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=1-contenus-les-informations-transmises-peuvent-etre-sujettes-a-1ace27 #### Conseil n°3 - Critère : Est-ce que les faits et opinions sont clairement identifiables ? - Justification : Lorsque les informations communiquées ne sont pas jugées fiables par les utilisateurs, cela peut engendrer des recherches supplémentaires pour confirmer des assertions et une navigation parasite. D'autre part, la crédibilité du service peut être remise en cause et écarter des utilisateurs. Les utilisateurs ont le droit d'avoir des informations fiables. Les éditeurs de service ont le devoir de respecter leurs utilisateurs en transmettant des informations vérifiées. - Tests : Comment différenciez-vous visuellement les faits et opinions ? - Niveau : C/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-contenus-lorsque-les-informations-communiquees-ne-sont-pas-bc86ab #### Recommandation n°4 - Critère : Quels sont les droits d'utilisation des images, vidéos, illustrations et textes de mon site ? - Justification : L'emploi de ressources et matériels externes est courant dans les services numériques. Il est important de respecter la propriété intellectuelle et rendre aux créateurs la visibilité liée à leurs créations originales pour respecter une éthique numérique. - Tests : Avez-vous une liste exhaustive et à jour des crédits ? ; Est-ce que les conditions actuelles disponibles pour les images et vidéos tiennent bien compte des contraintes d'optimisation, afin de ne pas dénaturer l'oeuvre d'origine mais limiter les impacts NR ? - Cas d’usage : Projet - Niveau : C/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=1-contenus-lemploi-de-ressources-et-materiels-externes-est-d7230c #### Recommandation n°5 - Critère : Les balises de mise en forme de texte répondent-elles au besoin de hiérarchisation des informations, et pas à des mises en valeur de présentation ? - Justification : Les automates et assistants d'accessibilité utilisent les balises pour se repérer et structurer la restitution. L'emploi de balises ne correspondant pas à la structure du contenu, par exemple pour des mises en forme de texte, rendent l'utilisation de ces assistants plus difficiles pour une bonne compréhension du contenu. - Tests : N'utilisez vous pas des balises H pour mettre en évidence du texte ? - Cas d’usage : L'analyse des codes sources permet de vérifier l'utilisation des balises HTML - Niveau : B/B/C - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-contenus-les-automates-et-assistants-daccessibilite-utilisent-les-aeffed ### Recommandation n°2 — Réduire l'empreinte des contenus statiques #### Recommandation n°6 - Critère : Est-ce que les images ont été compressées en amont dans un format adapté pour sa visualisation ? - Justification : La transmission de données compressées est indispensable pour réduire l'impact des échanges, en revanche les algorithmes de compression sont consommateurs de ressources techniques de traitement, de stockage intermédiaire. Lorsque les compressions sont effectuées à chaque demande d'échange, le bénéfice de la compression peut disparaître ou même augmenter l'impact. - Tests : Chaque image utilise-t-elle un format standard du web et propose une alternative pour certains formats optimisés qui ne seraient pas disponibles sur tous les environnements ? ; Chaque image utilise-t-elle un degré de compression adapté au rendu de l'image sur le service numérique ? ; ... - Cas d’usage : Les outils/consoles de développement et les extensions des navigateurs permettent de vérifier les bonnes pratiques (ex : CHROME - Extension greenIT / bonnes pratiques) - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-la-transmission-de-donnees-compressees-est-indispensable-dc507e #### Recommandation n°7 - Critère : Quelles sont les images réellement porteuses de sens utiles à la compréhension du service (exemples: logo, images liens, images contractuelles...) ? - Justification : Le poids, et donc son impact, d'une image est sans commune mesure avec du texte. Chaque fois que le choix d'utilisation d'une image est fait, il doit être justifié. Une image peut être nécessaire voir contractuelle (image d'un produit sur un service de vente en ligne) ou ne servir qu'à un remplissage d'espace dans le contenu. Réduire le nombre d'images diminue l'impact d'utilisation du service. - Tests : Avez-vous évalué chaque image par rapport à son apport pour la compréhension du service ? - Cas d’usage : Les parcours utilisateur présentent les images exposées dans le service et la valeur ajoutée des informations proposées par ces objets - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-le-poids-et-donc-son-impact-dune-06f2b7 #### Recommandation n°8 - Critère : De quelles images peut-on se passer (pas utile à la compréhension du service) ? - Justification : Le poids et donc son impact d'une image est sans commune mesure avec du texte. Chaque fois que le choix d'utilisation d'une image est fait, il doit être justifié. Une image peut être nécessaire voir contractuelle (image d'un produit sur un service de vente en ligne) ou ne servir qu'à un remplissage d'espace dans le contenu. Réduire le nombre d'images diminue l'impact d'utilisation du service. - Tests : Les images non porteuses de valeur sont-elles supprimées ? - Cas d’usage : Tests navigation - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-le-poids-et-donc-son-impact-dune-26e747 #### Recommandation n°9 - Critère : Est-ce que du texte peut remplacer certains types d'images (icons, picto...) ? - Justification : Le poids et donc son impact d'une image est sans commune mesure avec du texte. Chaque fois que le choix d'utilisation d'une image est fait, il ne doit pas pouvoir être remplacé par un texte simple. Réduire le nombre d'images diminue l'impact d'utilisation du service. - Tests : Combien d'images comportent uniquement du texte ? - Cas d’usage : Les parcours utilisateur présentent les images exposées dans le service et la valeur ajoutée des informations proposées par ces objets - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-le-poids-et-donc-son-impact-dune-23849f #### Recommandation n°10 - Critère : Une alternative aux images est-elle systématiquement disponible ? - Justification : Les assistants d'accessibilité doivent pouvoir utiliser une description de l'information portée par l'image afin de permettre une bonne compréhension du service sans la vision de l'image. - Tests : Chaque image dispose-t-elle d'un texte alternatif ? ; Avez-vous testé le service avec un assistant d'accessibilité (lecteur d'écran) ? - Cas d’usage : Code source / CHROME : extension lighthouse - Accessibilité - Niveau : B/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-les-assistants-daccessibilite-doivent-pouvoir-utiliser-une-c51b7e #### Conseil n°11 - Critère : La superposition d'information est-elle supprimée ? - Justification : La prolifération d'informations superposées rend le service plus difficile à comprendre et à utiliser par des publics moins familiers avec les technologies ou ceux pour lesquels la technologie ne peut être perçu facilement. - Tests : Les pop-up sont-elles utiles et indispensables à la compréhension du service ou d'un message ? - Cas d’usage : Navigation / code source - Niveau : B/B/C - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-la-proliferation-dinformations-superposees-rend-le-service-d1533a #### Recommandation n°12 - Critère : L'impact de l'internationalisation (multi-langues ...) est-il évalué ? - Justification : La gestion multi-langues ajoute une volumétrie conséquente de messages traduits dans les différentes langues. Certaines langues imposent des encodages de caractères multi-Bytes plus consommateurs d'espace mémoire. - Tests : Combien de langues utilisez-vous ? ; Sont-elles toutes utiles vis-à-vis du public attendu/réel ? ; Combien sont des langues multi bytes ? - Cas d’usage : Fiche de cadrage projet - Niveau : C/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-la-gestion-multi-langues-ajoute-une-volumetrie-consequente-d4b7e1 #### Recommandation n°13 - Critère : Le nombre de polices différentes est-il limité ? - Justification : Chaque police est encodée dans un fichier présentant tous les symboles associés ce qui représente un volume de données important échangé et manipulé. - Tests : Combien de polices différentes sont utilisées ? ; Un subset est-il utilisé pour limiter la volumétrie avec un format optimisé ? - Cas d’usage : Code source / CHROME - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-chaque-police-est-encodee-dans-un-fichier-27cb9b #### Recommandation n°14 - Critère : Privilégiez-vous les polices système ? - Justification : Les polices systèmes sont embarquées dans les outils de présentation et ne sont pas véhiculées. Les flux sont donc réduits lorsqu'elles sont utilisées. - Tests : Quelles sont les polices systèmes VS les webfonts ? - Cas d’usage : Code source / CHROME - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-les-polices-systemes-sont-embarquees-dans-les-09bb90 #### Conseil n°15 - Critère : Est-ce que la mise en forme du formulaire est minimale (afin de ne pas surcharger le code pour des styles peu utiles) ? - Justification : Les balises de mise en forme génèrent un volume supplémentaire de données échangées et manipulées, réduire ces éléments permet d'optimiser les traitements et les échanges - Tests : Combien de zones de saisie sont disponibles sur les formulaires ? ; L'enchaînement des zones de saisie est-il validé avec les touches clavier ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-les-balises-de-mise-en-forme-generent-6f0d28 #### Recommandation n°16 - Critère : Est-ce que le formulaire permet à l'utilisateur de désactiver les fonctions dynamiques (ex: auto completion) ? - Justification : Certaines fonctions lorsqu'elles sont activées vont utiliser des ressources de calcul et des échanges réseaux, c'est le cas des systèmes d'auto-complétion qui peuvent être utiles pour certains publics dont l'expression écrite n'est pas très fluide mais qui sont superflus pour des utilisateurs plus autonomes. - Tests : Les saisies dans le formulaire ne nécessitent-t-elles pas d'échanges superflus ? - Cas d’usage : Code source - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-certaines-fonctions-lorsquelles-sont-activees-vont-utiliser-7b4404 #### Recommandation n°17 - Critère : Est-ce que les formulaires sont utiles (exemple : ne pas créer de compte pour l'achat d'un produit/service - e-commerce) ? - Justification : Les formulaires de saisie, outre la gestion technique et leurs impacts (traitements, échanges réseaux) nécessitent des interactions de la part de l'utilisateur qui peuvent s'avérer contraignantes pour certains publics. - Tests : Avez-vous vérifié que toutes les données collectées sont en rapport avec l'action utilisateur ? - Cas d’usage : Parcours utilisateur - Niveau : C/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-les-formulaires-de-saisie-outre-la-gestion-902611 #### Conseil n°18 - Critère : Est-ce que le blocage des robots et accès non sollicités sont traités par des solutions peu coûteuses (captcha vs "addition" , ....) ? - Justification : La protection vis à vis des automates peut mettre en oeuvre des techniques qui génèrent une charge d'échange importante (images multiples par exemple) d'autres techniques sont plus légères de ce point de vue pour bloquer les accès "non humains" - Tests : Quelle solution de validation utilisez-vous ? - Niveau : C/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-la-protection-vis-a-vis-des-automates-fe854d #### Recommandation n°19 - Critère : Lorsque des listes de sélection sont disponibles, sont-elles limitées aux valeurs pertinentes pour l'utilisateur du service ? - Justification : Lors des saisies de données à partir de listes, le volume des listes peut fournir des entrées qui n'ont aucun intérêt et génèrent un volume totalement inutile, par exemple une liste de pays de l'Afghanistan au Zimbabwe pour un service franco-français pour lequel le pays n'est pas une donnée critique, par exemple des choix : France, Europe, Autre suffiraient - Tests : Avez-vous dans les listes (pays par exemple) des éléments inutiles (AUSTRALIE par exemple pour un service franco-français) ? - Cas d’usage : Navigation / code source - Niveau : C/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-contenus-lors-des-saisies-de-donnees-a-partir-41ca95 ### Recommandation n°3 — Eviter les contenus actifs, conserver les contenus dynamiques sous contrôle de l'utilisateur #### Conseil n°20 - Critère : Avez-vous limité les animations ? - Justification : Le traitement des animations consomme des ressources techniques et détourne l'attention des utilisateurs, de plus les animations sont généralement dépendantes de caractéristiques techniques des terminaux et génèrent des incompatibilités qui poussent artificiellement au renouvellement des équipements. - Tests : Utilisez-vous des carrousels ? sont-ils utiles à la compréhension du service ? - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-le-traitement-des-animations-consomme-des-ressources-81e8fc #### Recommandation n°21 - Critère : Est-ce que l'utilisation de Flash est supprimée, remplacée par un autre effet ? - Justification : Les technologies Flash (en fin de vie) utilisent beaucoup de ressources techniques sur le terminal utilisateur et demandent un suivi et des mises à jour de versions fréquentes, avec des limites de "rétro-compatibilité" fortes conduisant à une obsolescence anticipée des périphériques. - Tests : Avez-vous supprimé l'utilisation de flash dans le service ? - Cas d’usage : Le code source est analysé pour rechercher les utilisation de flash et les supprimer - Niveau : A/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-les-technologies-flash--utilisent-beaucoup-de-24675a #### Recommandation n°22 - Critère : Les contenus actifs sont-ils déclenchés uniquement sur action de l'utilisateur ? - Justification : Les contenus actifs utilisent des ressources techniques pour fonctionner. L'activité de ces composants doit être lancée à la demande de l'utilisateur pour éviter de consommer de l'énergie inutilement. - Tests : Si un carrousel est par exemple présent dans le service, est-il activable uniquement sur action de l'utilisateur (pas d'autoplay) ? - Cas d’usage : Les validations de parcours utilisateur couvrent la recherche de comportments du service ou l'utilisateur n'a pas l'initiative de l'opération - Niveau : A/A/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-les-contenus-actifs-utilisent-des-ressources-techniques-b1327c #### Recommandation n°23 - Critère : Est-ce que le contenu animé est sur la partie visible de l'écran (pas d'animation déclenchée sous la partie active de l'écran) ? - Justification : La présentation d'un service est rarement contenue sur la surface de l'écran et du scrolling ou de la pagination sont nécessaires. Les animations demandées par l'utilisateur peuvent être en dehors de la zone visible. Afin de réduire la consommation de ressources inutiles, toutes les animations non directement visibles doivent être stoppées. - Tests : Comment bloquez-vous les diffusions pour les contenus hors de la zone visible ? - Cas d’usage : Navigation - Niveau : B/A/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-la-presentation-dun-service-est-rarement-contenue-a458a0 #### Conseil n°24 - Critère : Est-ce que la durée des contenus animés ayant été validés comme nécessaire est optimisée ? - Justification : La durée totale des animations utilise des ressources. Le fait de réduire la durée et de ne pas les faire jouer en boucle permet, lorsque les animations sont indispensables, de réduire l'impact de consommation. - Tests : Quelle durée est associée à chaque contenu animé ? ; Avez-vous désactivé les replay en boucle ? - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-la-duree-totale-des-animations-utilise-des-04055a #### Conseil n°25 - Critère : Quelles sont les vidéos réellement porteuses de sens et utiles à la compréhension du service (exemples: logo, images liens, images contractuelles...) ? - Justification : Les flux vidéo sont dans les usages de service numérique l'un des éléments qui consomme le plus de ressources de traitement, de volume d'échange. Les vidéos doivent être limitées aux cas où elles apportent une valeur importante. La vidéo n'est pas accessible pour certains publics et doit donc être limitée. - Tests : Combien de vidéos comporte le service ? ; Quelle durée cumulée représente l'ensemble des vidéos ? - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-les-flux-video-sont-dans-les-usages-fd2678 #### Recommandation n°26 - Critère : De quelles vidéos peut-on se passer (pas utile à la compréhension du service) ? - Justification : Les flux vidéo sont dans les usages de service numérique l'un des éléments qui consomment le plus de ressources de traitement, de volume d'échange. Les vidéos doivent être limitées aux cas où elles apportent une valeur importante. La vidéo n'est pas accessible pour certains publics et doit donc être limitée. En revanche, elle peut aussi permettre une perception plus simple d'un service. - Tests : Avez-vous validé que la vidéo apporte une valeur pour le service ? - Cas d’usage : Les parcours utilisateur présentent les objets média et la valeur ajoutée des informations proposées par ces objets - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-les-flux-video-sont-dans-les-usages-4812af #### Recommandation n°27 - Critère : Est-ce que l'information portée par la vidéo peut être remplacée par une alternative (infographie...) ? - Justification : Les informations apportées par la vidéo sont souvent transposables de manière à être proposées sous forme statique, nettement moins consommatrices de ressources. - Tests : Combien de vidéos avez-vous transformé, par exemple en infographie qui réduit l'impact NR ? ; La solution vidéo ou des alternatives ont-elle été évaluées du point de vue NR ? - Cas d’usage : Les vidéos portent des méta-datas permettant de valider la pertinence du contenu et de le restituer sous une autre forme - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-les-informations-apportees-par-la-video-sont-e14597 #### Conseil n°28 - Critère : Est-ce que les alternatives au streaming (vs vidéo locale) ont été évaluées ? - Justification : Le chemin total parcouru par les flux vidéo génère à chaque étape un impact environnemental. Les solutions pour réduire la longueur de ce chemin sont bénéfiques. - Tests : Les évaluations de charges des vidéos entre streaming et hébergement local sont-elles toutes disponibles et utilisées ? - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-le-chemin-total-parcouru-par-les-flux-55d4db #### Recommandation n°29 - Critère : Est-ce que la durée des vidéos ayant été validées comme nécessaires est optimisée ? - Justification : L'impact des flux vidéo est lié à la durée de la vidéo, à la qualité des images et du son, au nombre de diffusion. Réduire la durée est l'un des leviers facilement gérable pour réduire l'impact. - Tests : Avez-vous une phase de post-production sur les vidéos pour réduire la durée avec un montage efficace ? - Cas d’usage : Les vidéos font l'objet d'une post-production pour réduire la durée des éléments sans valeur et proposer un "chapitrage" - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-limpact-des-flux-video-est-lie-a-8fef04 #### Conseil n°30 - Critère : Est-ce que la diffusion de sessions live est utile ? - Justification : Le nombre de flux diffusés multiplie par autant l'impact environnemental de la vidéo. - Tests : Le nombre de participants sur les sessions en direct est-il limité ? - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-le-nombre-de-flux-diffuses-multiplie-par-c17a80 #### Recommandation n°31 - Critère : Est-ce que le son de la vidéo peut-être restitué sous forme texte ? - Justification : L'accès au son est difficile ou impossible pour certains publics. La fourniture d'un texte en support ou remplacement du son est indispensable. - Tests : Avez-vous une piste de sous-titre pour chaque vidéo ? - Cas d’usage : Navigation - Niveau : C/A/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-lacces-au-son-est-difficile-ou-impossible-236851 #### Conseil n°32 - Critère : Est-ce que les CODECS des sons sont compressés au maximum ? - Justification : Le volume de données utilisé par la qualité des sons peut être réduit avec une précision, une qualité sonore plus basse. Les mécanismes de compression audio (CODEC) vont réduire le volume de données échangées mais demander plus de ressources CPU pour décoder et restituer les sons sur le périphérique utilisateur. - Tests : La qualité du son est-elle réduite et testée pour rester compréhensive ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-contenus-le-volume-de-donnees-utilise-par-la-a013d4 ### Recommandation n°4 — Faciliter la perception des contenus par l'utilisateur #### Conseil n°33 - Critère : Chaque contenu vidéo est-il associé à une durée de vie ? - Justification : Les vidéos peuvent être des faits d'actualité qui n'ont que peu d'intérêt en dehors de la période où elle a été produite. Généralement ces informations sont disponibles lors de la création et doivent être utilisées pour supprimer la vidéo après un délai défini. Cela libère de l'espace de stockage et évite aux utilisateurs de consulter des documents périmés. - Tests : A t-on défini une stratégie de cycle de vie d'une vidéo ? - Niveau : A/C/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=4-contenus-les-videos-peuvent-etre-des-faits-dactualite-e65b59 #### Conseil n°34 - Critère : A t-on défini la proportion des contenus de type flux (contenus chauds de type actu...) et stock (contenus froid, longue traîne en SEO) ? - Justification : Les contenus liés à un événement ou une actualité sont peu intéressants après un certain temps. Toutes ces informations doivent être utilisées pour que les informations périmées soient supprimées ou si nécessaire retravaillées pour réduire leurs tailles, et enfin être mis à disposition des utilisateurs sur des liens d'archives pour bien exprimer que ces contenus sont anciens. Conserver les contenus anciens peut être utile pour conserver les référencement SEO acquis. - Tests : Comment les contenus récents sont-ils mis en avant ? ; Le volume des contenus froids est-il réduit et suivi régulièrement ? ; Tous les contenus ont-ils une date d'expiration ? - Niveau : B/B/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=4-contenus-les-contenus-lies-a-un-evenement-ou-9d8fc1 #### Recommandation n°35 - Critère : Les contenus sont-ils uniques dans tout le service ? - Justification : Outre les espaces de stockage supplémentaires et la confusion pour l'utilisateur que la duplication de contenus amène, d'un point de vue SEO, ces duplications sont inefficaces. - Tests : Avez-vous un suivi des contenus dupliqués ? - Cas d’usage : File system - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=4-contenus-outre-les-espaces-de-stockage-supplementaires-et-7c450b #### Recommandation n°36 - Critère : Les notifications utilisateurs sont-elles nécessaires et désactivables par l'utilisateur ? - Justification : Les méthodes de notifications peuvent employer des technologies consommatrices de ressources et certaines pratiques visent à les multiplier ce qui augmente l'empreinte environnementale du service. Réduire les notifications, utiliser des mécanismes légers, et permettre à l'utilisateur de désactiver ces notifications est utile pour réduire les consommations d'énergie ainsi que le détournement d'attention des utilisateurs. - Tests : Quelles sont les méthodes de notification utilisateur ? L'utilisateur a-t-il le choix des mécanismes de notification, de leur fréquence pour lui éviter de tout recevoir par défaut ? ; L'abonnement sur un flux RSS est-il proposé comme alternative à des notifications spontanées de type push ? - Cas d’usage : Les validation des parcours utilisateurs identifient les notifications utilisateurs et les possibilité de désactivation de ces notifications - Niveau : A/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-contenus-les-methodes-de-notifications-peuvent-employer-des-e6138f #### Recommandation n°37 - Critère : Est-ce que la validité des données est contrôlée avant la soumission du formulaire ? - Justification : Les saisies de données dans les formulaires sont sources d'erreurs. Si les données ne sont contrôlées qu'après soumission du formulaire, le nombre d'échanges va augmenter. Le contrôle du format des données attendues avant l'envoi au serveur permet de réduire les transferts de données et les traitements inutiles. - Tests : Avez-vous une plage de valeur, un format associé à chaque zone de saisie ? ; Les données attendues dans chaque champ sont-elles clairement exprimées et contrôlées au plus tôt après leur saisie par l'utilisateur ? - Cas d’usage : Navigation / CHROME : Network - Niveau : B/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-contenus-les-saisies-de-donnees-dans-les-formulaires-549d87 #### Conseil n°38 - Critère : La présentation des informations est-elle accessible sans générer une cascade de zones de présentations dynamiques ? - Justification : Le dynamisme des affichages peut être perçu comme un critère de modernité, mais cela génère des calculs et traitements permanents qui sont une source de consommation, et l'attention de l'utilisateur peut être perturbée par des actions spontanées qu'il n'a pas déclenché. - Tests : Chaque information est-elle visible sans superposition ni recalcul intempestif ? - Niveau : B/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-contenus-le-dynamisme-des-affichages-peut-etre-percu-b27c06 #### Recommandation n°39 - Critère : Chaque élément actif dispose-t-il d'un nom permettant de comprendre l'action qui sera réalisée par son utilisation ? - Justification : Le dynamisme des interfaces peut ne pas être appréhendé par certains publics ou certains assistants d'accessibilité. Il est indispensable que chaque élément actif puissent être décrit pour que l'utilisateur comprenne le mode de fonctionnement. - Tests : Avez-vous validé que chaque élément est bien pris en charge par un lecteur d'accessibilité (lecteur d'écran)? ; Utilisez vous toujours les mêmes termes pour les mêmes actions, en précisant systématiquement le contexte ? ; Chaque action est-elle toujours située dans le parcours ? - Cas d’usage : Code source / CHROME : Lighthouse / accessibilité - Niveau : B/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-contenus-le-dynamisme-des-interfaces-peut-ne-pas-ce1132 ### Recommandation n°5 — Assurer la liaison entre les contenus et usages #### Conseil n°40 - Critère : Les informations de tracking de SEO sont-elles suivies et rationalisées afin de ne pas collecter d'éléments inutiles ? - Justification : Le suivi de l'activité des utilisateurs dans le service peut engendrer la collecte d'un volume important d'informations qui seront échangées avec les moteurs SEO. Ces collectes sont utiles lorsqu'elles permettent de fournir plus efficacement les informations aux utilisateurs et de faciliter leurs parcours, elles sont parasites et gaspillées lorsqu'elles ne sont pas utilisées. - Tests : Avez-vous validé que chaque information de tracking SEO est bien utilisée ? - Niveau : B/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=5-contenus-le-suivi-de-lactivite-des-utilisateurs-dans-d6486d #### Recommandation n°41 - Critère : Est-ce que tous les liens et images-liens sont utiles ? - Justification : Les contenus utilisent des références externes plutôt que dupliquer des informations. Le renvoi vers ces sources externes met en oeuvre des mécanismes techniques et consomment des ressources qui doivent avoir une valeur. - Tests : Comment présentez-vous à l'utilisateur le fait qu'il s'agit d'un lien interne ou externe ? - Cas d’usage : Navigation / parcours utilisateur - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=5-contenus-les-contenus-utilisent-des-references-externes-plutot-e62cc1 #### Recommandation n°42 - Critère : A t-on vérifié que les urls de destination sont bien valides ? - Justification : Les contenus utilisent des références externes plutôt que de dupliquer des informations. Chaque lien est susceptible d'être activé et générera une requête réseau, elle doit donc être valide. Dans le cas contraire, l'utilisateur risque de ne pas comprendre la source de l'erreur et générer de multiples tentatives infructueuses avec l'utilisation de ressources techniques sans aucun résultat. - Tests : A quelle fréquence contrôlez-vous les liens ? - Cas d’usage : Navigation / parcours utilisateur - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=5-contenus-les-contenus-utilisent-des-references-externes-plutot-456540 #### Conseil n°43 - Critère : Les textes mis à disposition des utilisateurs sont-ils adaptés à des publics cibles éloignés de la lecture de contenus électroniques (illectronisme) ? - Justification : La compréhension de textes sur un support numérique peut être difficile pour des publics éloignés de ces technologies ou avec un confort visuel ou littéraire restreint. L'illectronisme doit être pris en compte dans les choix éditoriaux des services pour inclure le plus de personnes. - Tests : Combien de mots par paragraphe sont affichés sur chaque page ? ; Le vocabulaire utilisé est-il réduit ? Combien de mots, quel nombre de lettres par mot ? - Niveau : B/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=5-contenus-la-comprehension-de-textes-sur-un-support-750458 #### Conseil n°44 - Critère : A t-on réduit au minimum le nombre de champs (exemple : les champs non obligatoires sont-ils nécessaires ? - Justification : Les formulaires de saisie sont l'occasion de collecter des données de la part de l'utilisateur. Lorsque ces données ne sont pas indispensables, elles génèrent tout de même des impacts d'échange, de stockage et de sauvegarde. La réglementation encadre les données à caractère personnel et médicales. Toutes les données fournies par un utilisateur doivent être traitées avec la même parcimonie et respect. - Tests : Collectez-vous des données facultatives qui ne font l'objet d'aucun traitement ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=5-contenus-les-formulaires-de-saisie-sont-loccasion-de-1a7ec5 #### Recommandation n°45 - Critère : Les données utilisateurs collectées et exposées sont-elles clairement identifiées comme données personnelles et/ou sensibles lorsque c'est le cas ? - Justification : La notion de données personnelles fait l'objet d'une définition légale, qui n'est pas toujours connue par les utilisateurs et donc les règles associées à la protection des données personnelles peuvent être ignorées. Pour garantir que l'utilisateur dispose du bon niveau d'information, il est important que les données à caractère personnel et plus encore les données sensibles soient clairement identifiées comme telles. - Tests : Combien de données personnelles couvertes par le RGPD collectez-vous ? ; Combien sont des données sensibles ? - Cas d’usage : Liasse RGPD - Niveau : C/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=5-contenus-la-notion-de-donnees-personnelles-fait-lobjet-ffdc2d #### Recommandation n°46 - Critère : L'utilisateur peut-il personnaliser la fréquence et le périmètre des contenus diffusés ? - Justification : Les services numériques peuvent avoir besoin de garder le contact avec leurs utilisateurs, le plus souvent au travers de communications automatiques (newsletter par exemple). Ces diffusions en masse génèrent des coûts environnementaux de création de ces contenus, de diffusion, de consultation ou stockage (volontaire ou non) par l'utilisateur. Le volume de communication doit pouvoir être réglé par l'utilisateur, de même que le périmètre du contenu pour correspondre à ses attentes uniquement. La réglementation impose déjà l'acceptation explicite (opt-In) pour recevoir ce type de communications - Tests : Quelle est votre fréquence d'émission de contenus ? ; Quel est le volume mensuel total de toutes vos diffusions? ; Le Optin RGPD est-il systématique ? - Cas d’usage : Parcours utilisateurs - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=5-contenus-les-services-numeriques-peuvent-avoir-besoin-de-051a04 #### Recommandation n°47 - Critère : Les documents à télécharger sont-ils compressés, optimisés et accessibles ? - Justification : Les documents disponibles pour l'utilisateur dans le service doivent être compressés pour réduire les impacts liés aux transferts de ces données. - Tests : Tous vos documents sont-ils compressés ? ; Les tailles et formats des fichiers sont-ils connus de l'utilisateur avant son opération de téléchargement ? - Cas d’usage : Les tests de navigation / parcours utilisateur couvrent les téléchargements, les outils de développement des navigateurs permettent de suivre les volumes de données (ex: CHROME - network) - Niveau : A/C/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=5-contenus-les-documents-disponibles-pour-lutilisateur-dans-le-c66540 #### Conseil n°48 - Critère : Dans le cas d'un long document de type PDF, est-il possible de le télécharger chapitre par chapitre ? - Justification : Les documents volumineux sont rarement intégralement lus par les utilisateurs ou du moins en une seule fois. Afin de réduire à la fois les volumes de données échangées et le volume de stockage sur le périphérique utilisateur, un document long doit pouvoir être segmenté pour être chargé en segments plus petits que l'utilisateur ira chercher s'il en ressent la nécessité. - Tests : Au delà de quel volume, proposez-vous un chargement segmenté ? ; Un fichier à télécharger est-il indispensable et la meilleure solution pour l'utilisateur, par rapport à une version en ligne ? ; Une fonction de preview, ou de vue dans le browser est-elle disponible ? - Niveau : B/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=5-contenus-les-documents-volumineux-sont-rarement-integralement-lus-86e8e7 ## Famille : Frontend Ensemble des composants en opération sur un terminal pour permettre l'utilisation d'un service numérique. ### Recommandation n°1 — Valider le périmètre et la couverture fonctionnelle du projet #### Recommandation n°1 - Critère : Est-ce que les fonctions proposées sont bien en rapport avec un usage ? - Justification : Derrière chaque fonctionnalité il y a du code, des échanges, des données. Si certaines fonctions ne correspondent pas à un vrai besoin, des ressources sont gaspillées en vain. - Tests : Toutes les fonctionnalités sont-elles validées par un usage décrit par le métier ? - Cas d’usage : Les solutions d'analytics / sondes sont mises en oeuvre et optimisées pour valider les utilisations des fonctionnalités - Niveau : A/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-frontend-derriere-chaque-fonctionnalite-il-y-a-du-e6720b #### Conseil n°2 - Critère : Chaque fonction du service est-elle appréhendée en regard de son importance dans le service ? - Justification : Les fonctions les plus gourmandes en ressources ne sont pas toujours les fonctions les plus utiles, il est acceptable de consommer des ressources pour des éléments critiques, mais plus dommageable lorsque c'est pour des choses mineures. - Tests : Avez-vous appliqué une démarche 80/20 pour chaque fonction en rapport avec ses impacts environnementaux et son importance ? - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-frontend-les-fonctions-les-plus-gourmandes-en-ressources-7343f4 #### Conseil n°3 - Critère : Les fonctions secondaires ont-elles aussi un impact moindre sur l'impact environnemental ? - Justification : La cohérence NR pousse à s'assurer que les fonctions secondaires n'ont pas un impact environnemental plus important que les fonctions principales. Les phases de développement doivent clairement identifier les fonctions principales et secondaires et leur impact du point de vue NR. - Tests : Les impacts environnementaux de chaque fonctionnalité sont-ils évalués par rapport à la nature et l'importance de la fonctionnalité ? - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-frontend-la-coherence-nr-pousse-a-sassurer-que-7ffa3c #### Recommandation n°4 - Critère : Utilisez-vous des standards de développement éprouvés ? - Justification : Les meilleurs standards de développement couvrent une grande partie des attentes du NR sur les aspects de fiabilité, de réutilisation, validation des codes produits, ainsi que l'utilisabilité par différentes catégories de publics. L'adoption et le respect de ces standards donne une base solide pour construire en appliquant les démarches NR qui sont hors du périmètre de ces méthodes et outils. - Tests : Quels sont les standards de référence utilisés (ISO/RFC/IEC) ? ; Le service respecte -il les recommandations du RGAA, du W3C ? Est-ce que les contraintes RGPD sont toutes traitées ? - Cas d’usage : Développement - Niveau : C/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-frontend-les-meilleurs-standards-de-developpement-couvrent-une-c3efe3 #### Conseil n°5 - Critère : Est-ce qu'une méthodologie de qualité est en place ? - Justification : La qualité du logiciel produit a un impact direct sur les aspects NR. Les défauts entraînent de multiples livraisons de nouvelles versions successives, les anomalies entraînent des productions de traces d'anomalies importantes, et des fonctionnalités plus consommatrices de ressources techniques, parfois pour un résultat non atteint, donc des ressources ont été gaspillées pour ne produire aucun résultat - Tests : Quels sont les outils d'analyse, d'optimisation de codes, de debug mis en place ? Les méthodes de développement suivent-elles une orientation Test Driven Development ? - Niveau : C/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-frontend-la-qualite-du-logiciel-produit-a-un-b70db0 #### Recommandation n°6 - Critère : Les données ACV sont-elles réutilisées dans le cas d'une adaptation d'un service existant ? - Justification : Les analyses ACV peuvent être réalisées sur des services existants afin de les rendre plus efficaces dans le cas d'une refonte ou adaptation d'un service existant, les spécifications et exigences NR issues des ACV précédentes doivent être reprises et adaptées si besoin. - Tests : Avez-vous mis à disposition des équipes projet les ACV précédentes ? ; L'ACV de ce projet est-elle rendue disponible pour d'autres projets ? - Cas d’usage : Une ACV minimale ("screening") est disponible pour le service existant - Niveau : A/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=1-frontend-les-analyses-acv-peuvent-etre-realisees-sur-c8b496 #### Conseil n°7 - Critère : Est-ce bien la fonctionnalité qui guide les choix plutôt que l'attrait de la technologie à la mode ? - Justification : Le choix technologique doit être dicté par les fonctionnalités et le respect des critères NR, plutôt que par l'attrait technologique de la nouveauté à la mode. - Tests : Quel acteur valide les choix techniques d'un point de vue NR ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=1-frontend-le-choix-technologique-doit-etre-dicte-par-f28e94 ### Recommandation n°2 — Fédérer les équipes et le public cible #### Conseil n°8 - Critère : Quel serait mon réflexe de dev, pour prendre en compte le cycle de vie ? - Justification : La prise en compte du cycle doit être intégrée dans les phases de développement. Les développeurs sont les principaux acteurs qui, par leurs choix, leurs pratiques vont conditionner les résultats futurs. La prise en compte du cycle de vie dans le développement est indispensable. Il serait plus coûteux, plus risqué et moins efficace de traiter les aspects de cycle de vie en aval. - Tests : Quelles procédures sont disponibles pour traiter le cycle de vie ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-frontend-la-prise-en-compte-du-cycle-doit-c6a7f0 #### Conseil n°9 - Critère : Chaque partie-prenante interne a-t-elle la latitude de prendre des décisions pouvant influer sur l'impact environnemental ? - Justification : Les orientations des développements peuvent évoluer au fil du temps. Ces évolutions doivent systématiquement prendre en compte les aspects NR. Les adaptations sont le plus souvent le fait des métiers ou des contraintes techniques qui apparaissent au cours du développement. Les impacts environnementaux doivent pouvoir aussi être traités par les équipes techniques avec des chemins de validation pré-définis. - Tests : Le circuit et l'autonomie de décision ayant un impact NR est-il défini pour chaque acteur ? - Niveau : C/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-frontend-les-orientations-des-developpements-peuvent-evoluer-au-dc6cb9 #### Conseil n°10 - Critère : Les aspects Numérique Responsable sont-ils propagés et entretenus sur l'ensemble des acteurs ? - Justification : La maturité NR d'une équipe repose sur la connaissance partagée. C'est cette connaissance NR qui doit être présente pour devenir une pratique métier standard en permanente évolution. - Tests : Quelle est votre fréquence de communication NR pour chaque profil de partie prenante ? - Niveau : B/A/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=2-frontend-la-maturite-nr-dune-equipe-repose-sur-7d2897 #### Recommandation n°11 - Critère : Le public cible du service est-il déterminé vis-à-vis de ses capacités d'utilisation du service ? - Justification : La finalité du développement est dépendante des publics utilisateurs cibles. Les choix d'implémentation ont une forte conséquence sur la capacité d'utilisation du service. Les équipes de développement sont souvent éloignées des cas d'usage réels, il est indispensable de reconstruire cette proximité pour que tous les publics utilisateurs soient inclus. - Tests : Les objectifs NR sont-ils qualifiés pour chaque profil cible? - Cas d’usage : Fiche de cadrage - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=2-frontend-la-finalite-du-developpement-est-dependante-des-8922d8 ### Recommandation n°3 — Utiliser les environnements et outils qui permettent de limiter les impacts #### Recommandation n°12 - Critère : Utilisez vous les mécanismes de cache pour limiter les échanges ? - Justification : La réduction des volumes d'échanges, des opérations de calculs, traitements, et accès aux données est un axe d'optimisation des consommations de ressources. La mise en place de systèmes de cache permet de réduire les coûts des opérations répétitives. Les mécanismes de cache peuvent être déployés à différents points de passage dans un service. Plus le cache est proche du demandeur qu'il doit servir, plus le volume de données en transit et la longueur du chemin emprunté par les données sont faibles. Plus le cache est proche de la source de données, plus il peut être mutualisé par un nombre important d'utilisateurs mais les données seront tout de même échangées, seules les opérations de traitement et collecte seront réduites. - Tests : Est-ce que les mécanismes de caches sont en place : pas de directive no-cache, cache navigateur, cache API ? - Cas d’usage : Le dossier technique identifie les caches et la stratégie de cache utilisée pour chaque type de flux. Les outils de gestions des caches (purge / désactivation) sont utilisés pour valider les performances effectives (ex: CHROME : console /network enable - disable cache) - Niveau : A/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-la-reduction-des-volumes-dechanges-des-operations-4f3639 #### Recommandation n°13 - Critère : Est-ce que les fonctionnalités couvertes par des actions locales (côté client) sont privilégiées plutôt que des échanges API ? - Justification : Les charges introduites par la sollicitation de ressources distantes via des mécanismes API peuvent être importantes. Certaines fonctionnalités pourraient être couvertes par des actions locales plutôt que distantes ce qui réduit la volumétrie des échanges et le nombre de composants mis en oeuvre, donc réduit l'impact environnemental. En revanche, il ne faut pas que le traitement en local d'une fonctionnalité qui peut nécessiter de nouvelles dépendances techniques, alourdisse la charge sur le front end. - Tests : L'utilisation d'API externes est-elle limitée (si possible) ? - Cas d’usage : Les tests de navigation / parcours utilisateur couvrent les accès API, les outils de développement des navigateurs permettent de suivre les volumes de données (ex: CHROME - network) - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-les-charges-introduites-par-la-sollicitation-de-1f3e21 #### Recommandation n°14 - Critère : Est-ce que les données remontées par les API sont bien uniquement celles dont l'application a besoin au moment où elles sont demandées ? - Justification : Les parcours et besoins des utilisateurs sont très difficilement anticipables. Une tendance consiste à collecter sur le front end un maximum de données pour couvrir le maximum de cas d'utilisation. Cette pratique est inefficace d'un point de vue NR car la collecte, le traitement, l'acheminement, le stockage local des données génère une charge et donc une consommation énergétique importante sans certitude que toutes ces données seront effectivement utilisées. L'empreinte du service doit être réduite en ne collectant que les données indispensables au fur et à mesure du déroulement du service via les mécanismes API. - Tests : Les volumes de données transmis sont-ils en rapport avec les capacités de présentation du périphérique utilisateur ? - Cas d’usage : Les outils de développement et consoles des navigateurs sont utilisés pour suivre les échanges API (ex: CHROME : console network) - Niveau : A/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-les-parcours-et-besoins-des-utilisateurs-sont-b48ee0 #### Conseil n°15 - Critère : Est-ce qu'une alternative openSource est disponible pour les API ? - Justification : L'opacité de certains fournisseurs de service ne permet pas de connaître leurs pratiques sur les différentes dimensions du NR. Les solutions open source, communautaires peuvent lever certaines de ces contraintes, mais l'open source ne garantit pas que l'ensemble des critères NR soient couverts ou visibles. - Tests : La performance NR des API open source est-elle un critère de choix ? ; Est-ce que ces API OpenSource prennent en compte le NR ? - Niveau : B/B/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-lopacite-de-certains-fournisseurs-de-service-ne-6c9884 #### Recommandation n°16 - Critère : Les bibliothèques utilisées permettent-elles de ne prendre que les composants effectivement utiles ? - Justification : Bien souvent les composants issus de bibliothèques publiques (open source ou commerciales) apportent un ensemble de fonctionnalités qui ne sont que rarement toutes utilisées et drainent des dépendances vis-à -is d'autres composants avec les mêmes caractéristiques. Au final le projet agrège un volume de bibliothèque important alors qu'une petite partie est réellement utilisée. Privilégier les composants dont les dépendances et fonctionnalités sont pilotables par rapport aux besoins est efficace du point de vue NR. - Tests : Comment sont tracés les composants utilisés ? - Cas d’usage : Le dossier technique identifie les dépendances de composants et précise les éléments pouvant être supprimés. - Niveau : A/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-bien-souvent-les-composants-issus-de-bibliotheques-83dc17 #### Recommandation n°17 - Critère : Les dépendances non utilisées sont-elles identifiées et retirées ? - Justification : Les arbres de dépendance donnent la cartographie des composants et leurs relations. Un arbre de dépendance le plus réduit possible est efficace car il réduit les volumes de code, mais cela ne présume pas que chaque branche de cet arbre de dépendance est justifiée par une utilisation effective. - Tests : Quel outil utilisez-vous pour tracer les dépendances ? ; Concernant leur mise à jour, comment vous assurez-vous de la fiabilité des sources si vous utilisez des ressources extérieures de type CDN ? - Cas d’usage : Les outils de développement et la console des navigateurs permettent de tracer les dépendances chargées mais inutilisées (ex: CHROME : console / coverage) - Niveau : A/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-les-arbres-de-dependance-donnent-la-cartographie-d4ea50 #### Recommandation n°18 - Critère : Est-ce que la fonctionnalité attendue ne pourrait pas être mise en place avec les capacités natives du navigateur ? - Justification : Certaines fonctionnalités sont disponibles sous plusieurs formes. Lorsqu'elles sont natives, aucun code ou composants supplémentaires ne sont nécessaires pour les utiliser ce qui réduit l'impact du service. - Tests : Quelles fonctionnalités sont ré-écrites car la fonctionnalité système native ne couvre pas l'intégralité du besoin ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-certaines-fonctionnalites-sont-disponibles-sous-plusieurs-formes.-06c7fd #### Conseil n°19 - Critère : Une alternative openSource est-elle disponible ? - Justification : Une solution Open Source n'est pas un gage d'efficacité NR et les différentes alternatives doivent être challengées. Mais l'open source permet de limiter les ambitions et mainmises de certains acteurs dont les pratiques économiques, sociales sont opaques. - Tests : La performance NR de la solution open source est-elle un critère de choix ? - Niveau : B/B/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-une-solution-open-source-nest-pas-un-2d9995 #### Recommandation n°20 - Critère : L'ensemble des équipements techniques utilisés par le service sont-ils identifiés ? - Justification : La conception, le développement, les tests, la production, la gestion de disponibilité sont des étapes qui vont utiliser des ressources techniques. Chacune de ces ressources doit être identifiée et ses caractéristiques répertoriées. - Tests : Les certifications de chaque équipement sont-elles disponibles ? - Cas d’usage : Gestion de configuration - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-la-conception-le-developpement-les-tests-la-a62923 #### Conseil n°21 - Critère : Pour chaque équipement, les caractéristiques sont-elles disponibles ? - Justification : La position de l'équipement dans son cycle de vie et son impact environnemental doivent être connus pour utiliser au mieux les équipements disponibles. - Tests : Les critères de renouvellement des équipements prennent-ils en compte les impacts NR ? - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-la-position-de-lequipement-dans-son-cycle-538ede #### Conseil n°22 - Critère : Les fonctionnalités liées aux traitements de données réglementées (santé, personnelles, bancaires) sont-elles validées en terme d'interopérabilité ? - Justification : Le cadre réglementaire de certaines catégories de données est très strict, le respect de ces données pour protéger les utilisateurs est un critère important. Il est indispensable que dans le processus de développement aucune brèche ne soit possible et que toutes les interopérabilités avec les mécanismes standards de ces domaines soient validés. - Tests : Chaque fonctionnalité liée à des données réglementées (santé, bancaire) est-elle identifiée ? - Niveau : C/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-le-cadre-reglementaire-de-certaines-categories-de-cb2f15 #### Conseil n°23 - Critère : Les dernières avancées techniques, sont-elles utilisées lorsqu'elles contribuent réellement à réduire l'impact ? - Justification : Les avancées technologiques se succèdent rapidement, le NR en se diffusant progresse aussi dans les pratiques et l'efficacité. La conjonction de ces 2 phénomènes nécessite au cours du projet, une veille permanente et une stratégie pour évaluer les bénéfices de l'adoption de nouveaux éléments techniques vis-à-vis des impacts NR - Tests : A quelle fréquence les améliorations sont-elles évaluées ? - Niveau : B/C/B - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=3-frontend-les-avancees-technologiques-se-succedent-rapidement-le-3bbc4c ### Recommandation n°4 — Réduire les effets d'obsolescence #### Recommandation n°24 - Critère : La plage de rétro-compatibilité est-elle définie ? - Justification : Les équipements utilisateurs sont de plus en plus performants. Lorsque les services numériques exploitent toutes les capacités des équipements, cela écarte certains publics qui ne disposent pas des même outils performants. Cela empêche aussi d'aborder la fourniture des fonctionnalités avec des moyens moins gourmands en ressources mais procurant le même résultat. - Tests : La liste des équipements est-elle mise à jour ? - Cas d’usage : Chaque élément référencé dans le Dossier Technique porte une information de degrés de compatibilité - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=4-frontend-les-equipements-utilisateurs-sont-de-plus-en-40146e #### Conseil n°25 - Critère : Chacune de ces phases du cycle de vie sont-elles identifiées avec des actions spécifiques ? - Justification : La démarche ACV est une base de la prise en compte du NR dans la conception des services numériques, elle permet d'associer des actions à chaque étape du cycle de vie. - Tests : A quelle fréquence ces actions sont-elles revues ? - Niveau : B/B/B - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=4-frontend-la-demarche-acv-est-une-base-de-58b536 #### Conseil n°26 - Critère : Une version légère du service pour des équipements anciens ou des conditions d'accès réseau limitées est-elle disponible ? - Justification : Plus le service implémente de composants qui présentent une charge sur les serveurs, sur les réseaux et sur le périphérique utilisateur, plus l'impact est important. Une version allégée du service contribue à réduire l'impact environnemental de l'encombrement des réseaux, du sur-dimensionnement des infrastructures. - Tests : Cette version est-elle la seule disponible ? - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=4-frontend-plus-le-service-implemente-de-composants-qui-3d6f0a #### Recommandation n°27 - Critère : Est-ce que les équipements plus anciens resteront compatibles, et dans quelles limites ? - Justification : Le secteur d'activité et le profil des utilisateurs permet le plus souvent de qualifier le parc matériel qui sera employé pour le service. Les matériels sont déterminés par leurs capacités techniques (puissance de calcul, mémoire, capacité réseau, capteurs, taille et qualité d'écran) mais aussi par les systèmes d'exploitation qu'ils peuvent accueillir. Chaque contrainte que le service impose réduit le nombre de postes qui pourront l'utiliser et donc exclut des publics. La mise en oeuvre de solutions alternatives permet de conserver un fonctionnement efficace sur des périphériques anciens qui conservent une bonne utilisabilité et de ne pas exclure d'utilisateurs - Tests : Est-ce qu'il y a un mode dégradé pour les autres navigateurs ? - Cas d’usage : L'analyse d'impact détermine les enjeux et risques de mise en obsolescence d'équipements - Niveau : A/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-frontend-le-secteur-dactivite-et-le-profil-des-09a034 ### Recommandation n°5 — Implémenter et développer les fonctionnalités pour limiter les impacts #### Recommandation n°28 - Critère : Les fonctionnalités du service ne vont-elles pas au-delà des besoins utilisateurs ? - Justification : Le nombre de fonctionnalités disponibles dans un service numérique impactent directement la consommation de ressources et l'impact environnemental. En créant des fonctionnalités de peu d'utilité ce sont des sources de création de dettes environnementales totalement inutiles. Les fonctionnalités augmentent aussi le volume du service, qui introduisent des délais de chargements et des espaces de stockage supplémentaires. - Tests : Chaque fonctionnalité est-elle retirée si elle n'est pas en relation avec un usage défini ? - Cas d’usage : Des données sont identifiées et collectées (analytics / sondes) en production pour identifier les usages et les fonctionnalités superflues. - Niveau : A/A/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=5-frontend-le-nombre-de-fonctionnalites-disponibles-dans-un-53806f #### Conseil n°29 - Critère : Est-ce que les logs sont exempts d'erreurs non traitées ? - Justification : Les anomalies lors des traitements génèrent des insatisfactions utilisateurs, des traitements inutiles, des charges produites pour aucun résultat ce qui est un gaspillage de ressources. Les logs d'erreurs permettent de repérer et de réparer ces anomalies dès leur apparition. - Tests : A quelle fréquence sont revues les logs applicatives et chaque erreur génère-t-elle une demande de correction ? - Cas d’usage : FIREFOX : Console - Niveau : C/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=5-frontend-les-anomalies-lors-des-traitements-generent-des-198a7b #### Conseil n°30 - Critère : Les codes morts sont-ils éliminés ? - Justification : Dans les différentes évolutions des codes, certaines branches deviennent inutiles, mais restent souvent présentes dans les codes sources. Outre les risques de confusion et donc l'augmentation des temps de maintenance, ces lignes de codes inactives sont transmises et génèrent une volumétrie superflue. - Tests : Quel outil d'analyse utilisez-vous pour identifier les sections de code jamais appelées ? - Niveau : C/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=5-frontend-dans-les-differentes-evolutions-des-codes-certaines-cf1f28 #### Conseil n°31 - Critère : Un langage compilé est-il utilisé pour des aspects performance et/ou sécurité ? - Justification : Le type de langage utilisé introduit soit une proximité vers les processeurs (CPU), c'est le cas des langages compilés, soit vers les hommes, c'est le cas des langages interprétés (PHP, JavaScript, ...). La proximité des ordres machine augmente la performance technique mais rend la production logicielle plus lourde (phases de compilation, édition de liens). La proximité "humaine" facilite les développements mais aussi les malversations (piratage) et demande aux systèmes un effort supplémentaire pour traduire "à la demande" les lignes de programme en code machine, avec l'aide d'un interpréteur. - Tests : Le code fait-il l'objet d'optimisation avant compilation, ou à défaut avant interprétation ? - Niveau : A/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=5-frontend-le-type-de-langage-utilise-introduit-soit-af7ff8 #### Recommandation n°32 - Critère : Les éléments de références sont-ils connus, tenus à jour, et mis à disposition de l'ensemble de l'équipe projet ? - Justification : Le cadrage des opérations de développement nécessite un socle de référentiels qui soient connus, adoptés et validés par l'ensemble des équipes techniques. Ces références doivent évoluer en fonction des avancées de l'état de l'art pour rester à la pointe des pratiques autant techniques que NR. - Tests : Comment est évalué le degré de conformité ? - Cas d’usage : Documentation technique - Niveau : C/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=5-frontend-le-cadrage-des-operations-de-developpement-necessite-02e2d0 #### Recommandation n°33 - Critère : L'état des lieux des données d'entrée est-il mis à disposition afin d'être réutilisé dans d'autres projets ? - Justification : Les principes NR sont stables et les bonnes pratiques déployées sont directement utilisables dans d'autres contextes projet, d'autant plus que les projets au sein d'une organisation ont beaucoup de similarités que ce soit dans les méthodes, les objectifs ou les périmètres fonctionnels. Dans la phase de développement, collecter, préparer et produire ces éléments est un gage d'efficacité et de fiabilité pour augmenter la maturité de l'organisation dans ses pratiques NR. - Tests : Quelles sont les données utilisées en entrée et produite pour les autres projets ? - Cas d’usage : Documentation technique - Niveau : C/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=5-frontend-les-principes-nr-sont-stables-et-les-ee6678 ### Recommandation n°6 — S'assurer que l'utilisation du service permet le contrôle des impacts #### Recommandation n°34 - Critère : Limitez-vous les flux échangés ? - Justification : Dans les usages de services numériques les échanges de données sont à la fois indispensables mais génèrent une consommation importante de ressources. La réduction des besoins d'échanges au strict minimum diminue l'impact de ces échanges. Seule la vue globale des flux avec leurs sources, destinations et objectifs permettent de qualifier la nécessité et d'accepter l'impact de consommation qu'ils génèrent. - Tests : Est-ce qu'il y a une surveillance des flux échangés? Existe-t-il une matrice des flux ? Les flux échangés sont-ils conformes à la matrice des flux ? - Cas d’usage : Les outils de développement et la console des navigateurs permettent de tracer les flux échangés, leurs volumes et fréquences (ex: CHROME : console / network) - Niveau : A/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=6-frontend-dans-les-usages-de-services-numeriques-les-a0b852 #### Conseil n°35 - Critère : Est-ce qu'il y a un suivi du nombre de requêtes ? - Justification : Les opérations réalisées sur le front end génèrent des requêtes vers les services distants. Plus le nombre de requêtes est important plus les mécanismes de traitements et d'échanges vont consommer de ressources. - Tests : Combien de requêtes sont utilisées pour un parcours utilisateur ? - Niveau : A/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-frontend-les-operations-realisees-sur-le-front-end-835a00 #### Conseil n°36 - Critère : Les volumétries d'échanges sont-elles évaluées et réduites avec les traitements techniques les plus pertinents (compression/minification) ? - Justification : Les échanges indispensables doivent permettre de réduire la volumétrie des transferts. La minification des échanges, la compression des données échangées permettent de réduire ces volumes. Toutefois les opérations de compression et décompression nécessitent des exécutions de traitements qui peuvent annuler le bénéfice de la compression des échanges. - Tests : Est-ce que le poids est mesuré ? - Niveau : A/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=6-frontend-les-echanges-indispensables-doivent-permettre-de-reduire-76e6aa #### Recommandation n°37 - Critère : Est-ce qu'il y a des fichiers en double ? - Justification : En plus des besoins de réplication pour gérer la sécurité et la disponibilité des services, certains fichiers sont présents dans plusieurs emplacements sans réelles justifications. La recherche des doublons permet de réduire les volumes de stockage et de sauvegardes sans impact sur le fonctionnement du service. - Tests : A quelle fréquence sont contrôlés les fichiers pour identifier les duplications? - Cas d’usage : File system - Niveau : B/C/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-frontend-en-plus-des-besoins-de-replication-pour-3b7309 #### Recommandation n°38 - Critère : Combien de domaines différents sont utilisés ? - Justification : Les mécanismes de cache et la mise en oeuvre des accès aux ressources externes est facilité lorsque le nombre de sources sont réduites. L'utilisation de nombreux domaines est inefficace à la fois d'un point de vue performance et NR. - Tests : Utilisez-vous plus de 5 domaines différents ? ; Est-ce vraiment justifié ? - Cas d’usage : CHROME : console extension green IT / bonne pratiques - Niveau : B/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=6-frontend-les-mecanismes-de-cache-et-la-mise-2613c3 ### Recommandation n°7 — Limiter les utilisations de composants hardware ou capteurs sur les terminaux utilisateurs #### Recommandation n°39 - Critère : Les capteurs sont-ils sollicités au besoin réel, plutôt qu'en permanence ? - Justification : Les opérations techniques réalisées sur le front end peuvent mettre en oeuvre des capteurs physiques du périphérique utilisateur. La sollicitation de ces capteurs, les processus de contrôle de ces capteurs peut entraîner une usure prématurée et en cas de panne pousser au renouvellement du périphérique. Certaines techniques logicielles permettent de réduire l'utilisation des capteurs physiques, ou de s'assurer qu'ils sont employés avec le minimum de contraintes. - Tests : Est-ce que l'on gère de l'incrément ou de l'absolu en permanence ? - Cas d’usage : L'analyse des codes source couvrent la recherche des modes d'utilisation des capteurs - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=7-frontend-les-operations-techniques-realisees-sur-le-front-6a9fb3 #### Recommandation n°40 - Critère : Les fonctions de mise en pause sont-elles disponibles ? - Justification : L'optimisation des utilisations des composants physiques du périphérique utilisateur permet de préserver la durée de vie de ces composants et conserver plus longtemps l'intégrité du périphérique utilisateur. - Tests : Les mécanismes d'optimisation sont-ils disponibles (Firmware) pour optimiser la durée de vie du matériel (batteries/capteurs...) ? - Cas d’usage : L'analyse des codes source couvrent la recherche des modes d'utilisation des capteurs - Niveau : A/A/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=7-frontend-loptimisation-des-utilisations-des-composants-physiques-du-e35f50 #### Conseil n°41 - Critère : L'inaccessibilité d'un capteur, lié à l'équipement ou au choix de l'utilisateur, est-elle traitée pour permettre au service d'être néanmoins fonctionnel (si possible) ? - Justification : L'inaccessibilité de composants physiques du périphérique utilisateur doit être adressée pour permettre à des matériels anciens, ou partiellement fonctionnels d'exécuter le service. Certains cas d'indisponibilité de capteurs peuvent être simplement traités par des procédures de réinitialisation ou par des approximations logicielles. - Tests : Les procédures de réinitialisation physique des capteurs sont-elles disponibles ? - Niveau : A/B/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=7-frontend-linaccessibilite-de-composants-physiques-du-peripherique-utilisateur-aa442f #### Conseil n°42 - Critère : Des algorithmes prédictifs sont-ils mis en place pour éviter l'utilisation de capteurs physiques ? - Justification : Les capteurs physiques fournissent des données réputées exactes et précises, la majorité des services n'ont que très rarement besoin d'une précision absolue en permanence. Les algorithmes prédictifs peuvent soulager l'utilisation des capteurs et rendre le service néanmoins tout à fait efficace. - Tests : Quelle perte de précision est acceptée par les métiers ? - Niveau : A/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=7-frontend-les-capteurs-physiques-fournissent-des-donnees-reputees-235fca #### Recommandation n°43 - Critère : Informez-vous les utilisateurs des contraintes de volume et format de fichiers acceptés ? - Justification : Les opérations sur le front end peuvent nécessiter des transferts de fichiers entre le poste utilisateur et les serveurs de traitement. Les types et volumes de fichiers acceptés doivent être exposés à l'utilisateur pour éviter des charges de transfert, des stockages et des traitements qui seraient voués à l'échec pour cause de non-respect des formats et volumes attendus. La limitation du volume est indispensable pour réduire l'impact des transferts. - Tests : Les volumes et formats des fichiers sont-ils limités et exposés aux utilisateurs ? ; Quelle est la taille maximum autorisée ? - Cas d’usage : Parcours utilisateurs - Niveau : B/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=7-frontend-les-operations-sur-le-front-end-peuvent-fb5846 #### Conseil n°44 - Critère : La fréquence de l'animation est-elle adaptée à la fonctionnalité ? - Justification : La présentation des opérations sur le front end peut pousser à mettre en place des mécanismes dynamiques. Ces traitements requièrent des ressources de traitements. Il est nécessaire de réduire les impacts de ces éléments dynamiques en les évitant ou lorsqu'ils sont jugés indispensables en réduisant les fréquences des animations. - Tests : Les animations sont-elles par défaut cadencées au plus bas ? - Niveau : A/A/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=7-frontend-la-presentation-des-operations-sur-le-front-a13956 #### Recommandation n°45 - Critère : Est-ce que les uploads permettent uniquement la liste des types de fichiers autorisés ? - Justification : Les fichiers transférés par l'utilisateur génèrent des traitements, des flux d'échange, des espaces de stockage, une redondance pour sécuriser les données, des sauvegardes. Chaque transfert doit donc être utile pour le service. Et supprimés lorsqu'ils n'ont plus d'intérêt. - Tests : Est-ce que les fichiers uploadés sont exploitables ? afin d'éviter le stockage de fichiers inutiles. - Cas d’usage : Parcours utilisateurs - Niveau : B/A/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=7-frontend-les-fichiers-transferes-par-lutilisateur-generent-des-852309 #### Recommandation n°46 - Critère : Les images à uploader sont-elles bien redimensionnées et converties dans un format léger côté client avant transfert ? - Justification : Les transferts d'images introduisent des particularités liées au format des images, certains génèrent des tailles de fichiers très différents. Les tailles et niveaux de qualité des images augmentent très rapidement les volumes nécessaires pour stocker des images. Les transcodages, et redimensionnements peuvent être réalisés avant les transferts mais nécessitent des ressources de traitements, des espaces de stockage intermédiaires et créent de nouveaux fichiers qui, en l'absence de nettoyages automatiques, peuvent augmenter le volume de données. - Tests : Y-a-t-il une fonctionnalité de redimensionnement correspondant à l'usage prévu de l'image à uploader intégrée à la fonctionnalité d'upload ? ; L'usage prévu des images uploadées est-il bien défini ? - Cas d’usage : Les outils de développement et la console des navigateurs permettent de tracer les manipulations d'images et redimensionnements (ex: CHROME : console / network / extension Green IT - Niveau : A/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=7-frontend-les-transferts-dimages-introduisent-des-particularites-liees-04ccb4 #### Recommandation n°47 - Critère : Les fichiers échangés sont-ils compressés ? - Justification : Le volume de données transféré augmente l'empreinte environnementale du service, car les données sont aussi stockées, sécurisées avec de la duplication, sauvegardées. Certains formats de données peuvent être compressés pour réduire leur volume, l'opération de compression nécessitant des ressources de calcul et de stockage intermédiaire il est plus efficace que les données soient disponibles sous forme compressée. - Tests : La compression est-elle efficace ? - Cas d’usage : Les outils de développement et la console des navigateurs permettent de tracer les flux échangés, leurs volumes et fréquences (ex: CHROME : console / network) - Niveau : A/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=7-frontend-le-volume-de-donnees-transfere-augmente-lempreinte-c04347 ### Recommandation n°8 — Faciliter l'utilisation du service dans de bonnes conditions pour tous les utilisateurs #### Recommandation n°48 - Critère : La navigation rapide est-elle possible ? - Justification : La facilité d'utilisation et repérage dans le service rend un meilleur service à l'utilisateur. Il permet aussi à un utilisateur de trouver plus facilement les informations qu'il cherche, ce qui réduit les navigations parasites et diminue la consommation de ressources et d'énergie pour des résultats ne correspondant pas au besoin de l'utilisateur. - Tests : Un fil d'ariane est-il disponible en permanence ? - Cas d’usage : Parcours utilisateurs - Niveau : B/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=8-frontend-la-facilite-dutilisation-et-reperage-dans-le-7e3b3a #### Conseil n°49 - Critère : Est-ce que l'attention utilisateur est capturée avec son consentement et pour les usages qu'il attend ? - Justification : L'attention de l'utilisateur est une ressource qui doit être considérée comme rare et précieuse. Dans cette optique le respect de l'utilisateur passe aussi par sa capacité à concentrer son attention sur les éléments de son choix, plutôt que ceux que le service souhaiterait mettre en avant. - Tests : La matrice de captologie est-elle utilisée ? - Niveau : C/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=8-frontend-lattention-de-lutilisateur-est-une-ressource-qui-0f0d95 #### Conseil n°50 - Critère : Les données réglementées (personnelles, santé, financières) sont-elles exposées aux utilisateurs ? - Justification : Les données que l'utilisateur confie lorsqu'elles entrent dans un cadre réglementaire doivent être exposées aux utilisateurs pour qu'ils puissent les transmettre avec un consentement éclairé. - Tests : Chaque donnée réglementée est-elle identifiée ? - Niveau : C/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=8-frontend-les-donnees-que-lutilisateur-confie-lorsquelles-entrent-599645 ### Recommandation n°9 — Implémenter des solutions techniques dont l'impact est le plus faible #### Recommandation n°51 - Critère : Le service est-il adapté aux différents formats de support d'accessibilité ? - Justification : Certains outils et mécanismes d'accessibilité introduisent des contraintes sur les dispositions des écrans (portrait, paysage, loupe). Le service ne doit pas bloquer les possibilité sous peine d'exclure une parties des utilisateurs. - Tests : Le changement d'orientation d'écran est-il permis et géré dans tout le service ? - Cas d’usage : RGAA - Niveau : C/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-certains-outils-et-mecanismes-daccessibilite-introduisent-des-f77c5e #### Recommandation n°52 - Critère : Les différents formats d'images disponibles ont-ils été évalués pour ne retenir que le plus efficace ? - Justification : Les services numériques utilisent des images à des fins d'illustration ou d'information. Les tailles, degrés de définition, formats d'encodage ont un impact important sur le volume des fichiers de ces images. La réduction des volumes permet de limiter les impacts environnementaux. - Tests : Quel est le volume total des images du service ? - Cas d’usage : Les outils de développement et la console des navigateurs permettent de tracer les flux échangés, leurs volumes et fréquences (ex: CHROME : console / network) - Niveau : A/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-services-numeriques-utilisent-des-images-a-a37a8d #### Recommandation n°53 - Critère : Les redimensionnements d'images sont-ils traités en amont et en statique (côté serveur) ? - Justification : Les services utilisent plusieurs tailles d'une même image pour des besoins différents. Le redimensionnement des images, lorsqu'il est effectué à la demande génère des charges de traitements, des productions de fichiers intermédiaires qui introduisent des déperditions d'énergie à chaque demande. Il est plus efficace que les images soient disponibles dans les différentes tailles utilisées par le service. - Tests : Chaque image est-elle disponible dans son format utile ? - Cas d’usage : Les outils de développement et la console des navigateurs permettent de tracer les manipulations d'images et redimensionnements (ex: CHROME : console / network / extension Green IT - Niveau : A/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-services-utilisent-plusieurs-tailles-dune-meme-d5e548 #### Conseil n°54 - Critère : Est-ce que la définition de l'image est réduite et adaptée à son objectif (illustration, contractuel, ...) ? - Justification : Les images d'illustration et les images qui portent une information plus contractuelle comme l'image d'un produit n'ont pas les mêmes besoins de précisions de qualité. L'adaptation du niveau de qualité à l'importance de l'image permet de réduire l'impact environnemental des besoins les moins critiques pour le service. - Tests : Quel niveau de qualité est attendu pour chaque image ? - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-images-dillustration-et-les-images-qui-a54c72 #### Recommandation n°55 - Critère : Toutes les images ont-elles une alternative texte ? - Justification : Les assistants d'accessibilité doivent pouvoir utiliser une description de l'information portée par l'image afin de permettre une bonne compréhension du service sans la vision de l'image. - Tests : Avez-vous testé le service avec un lecteur d'accessibilité ? - Cas d’usage : Code source / CHROME : Lighthouse / accessibilité - Niveau : B/A/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-assistants-daccessibilite-doivent-pouvoir-utiliser-une-76cde7 #### Conseil n°56 - Critère : Les alternatives de formats d'images sont-elles mises à disposition via srcset ? - Justification : La sélection des différentes tailles d'images disponibles peut être laissée au navigateur avec une encapsulation des images dans srcset. Le browser va sélectionner le format le plus adapté à son utilisation. Cette technique n'est pas toujours la plus efficace du point de vue NR et doit être validée par rapport à des alternatives plus statiques. - Tests : Les gains ont-ils été mesurés avec l'utilisation de srcset ? - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-la-selection-des-differentes-tailles-dimages-disponibles-acd0d6 #### Conseil n°57 - Critère : Les sprites CSS sont-ils mis en place pour limiter les flux de récupération d'images ? - Justification : Les techniques sprite css, permettent de réduire le nombre de fichiers d'images en combinant plusieurs images par fichiers; Cette technique ne réduit pas la volumétrie des échanges, mais réduit le nombre de requêtes de récupération d'images. Cela procure un gain d'efficacité NR si l'ensemble des images du sprite sont réellement utilisées, dans le cas contraire des volumes de données ont été transférées pour rien. - Tests : Les gains ont-ils été mesurés avec l'utilisation de sprite CSS ? - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-techniques-sprite-css-permettent-de-reduire-844ab6 #### Recommandation n°58 - Critère : La mise en forme en css est-elle privilégiée, pour limiter l'usage des images ? - Justification : Parmi les éléments de présentation utilisés dans les services, les images représentent un volume important, ce qui génère un impact environnemental. Dans certains cas des opérations de mise en forme avec du CSS permettent de se dispenser d'une image, cette solution plus légère est à privilégier. - Tests : Quelles images peuvent être remplacées par du CSS ? - Cas d’usage : Navigation / CHROME network - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-parmi-les-elements-de-presentation-utilises-dans-eb6d1e #### Conseil n°59 - Critère : Est-ce que le lazy load apporte un gain (poids de la page, ressource CPU) ? - Justification : Lors du chargement du service sur le périphérique utilisateur, toutes les informations n'ont pas la même importance. Le chargement différé de certains éléments est souvent tout à fait acceptable, sans vraiment réduire le volume de chargement cela sollicite moins de ressources techniques en même temps sur les serveurs ce qui réduit le besoin de dimensionnement de ces serveurs. - Tests : Les gains ont-ils été mesurés avec l'utilisation de lazy load ? - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-lors-du-chargement-du-service-sur-le-29fe88 #### Conseil n°60 - Critère : Est-ce que la définition du son est adaptée ? - Justification : Les sons diffusés par le service, sont caractérisés par leurs durées, le nombre de répétitions, la qualité du son et enfin le type d'encodage (Codec) utilisé. Les actions sur chacun de ces points vont réduire l'impact des fichiers sons autant dans le transfert, que le volume des fichiers. Certains Codec très compressés réduisent de manière significative le volume de données pour une même qualité, mais le codage / décodage de ces formats peut nécessiter beaucoup de ressources de traitements, ce qui atténue fortement le bénéfice global du point de vue NR. - Tests : La qualité de son attendue est-elle spécifiée ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-sons-diffuses-par-le-service-sont-fea704 #### Recommandation n°61 - Critère : Une version épurée est-elle disponible pour les impressions ? - Justification : Les flux de dématérialisation sont parfois rompus, et imposent la production d'écrits sur papiers. L'utilisateur dans certains cas peut aussi être plus confortable à utiliser des documents imprimés plutôt que 100% électroniques. Les impressions ont un impact environnemental important, que ce soit dans la consommation de papier, de consommables tels que les cartouches et encres d'impression. Les besoins de présentation en électronique ou en impression sont différents, d'autre part la limitation de l'empreinte environnementale doit conduire à réduire la densité et le volume d'informations imprimées. - Tests : Le format d'impression est-il spécifié pour réduire l'espace et l'encre utilisé ? - Cas d’usage : Les tests de navigation / parcours utilisateur couvrent les impressions et l'analyse des documents imprimés - Niveau : A/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-flux-de-dematerialisation-sont-parfois-rompus-b03c7b #### Recommandation n°62 - Critère : Est-ce bien une action utilisateur qui déclenche le "play" ? - Justification : Les contenus actifs utilisent des ressources techniques pour fonctionner. L'activité de ces composants doit être lancée à la demande de l'utilisateur pour éviter de consommer de l'énergie inutilement. - Tests : Est-ce que toutes les animations sont en auto start OFF ? ; Evite-t-on de pré-charger les animations / vidéo? - Cas d’usage : Navigation - Niveau : B/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-contenus-actifs-utilisent-des-ressources-techniques-d8311a #### Recommandation n°63 - Critère : Les vidéos ou animations hors de la zone active sont-elles automatiquement mises en pause / stoppées ? - Justification : Les contenus actifs, animations, vidéos, sons lancés par l'utilisateur peuvent au cours de la navigation ne plus être visibles sur la zone écran présentée à l'utilisateur. La poursuite de la diffusion de ces contenus devient inutiles et consomment inutilement des ressources, ils doivent donc être arrêtés. - Tests : Les vidéos et animation en cours sont-elles stoppées lorsqu'elles sortent de l'espace vu par l'utilisateur ? - Cas d’usage : Les tests de navigation / parcours utilisateur couvrent les comportements des objets dynamiques (vidéo, animations, ...) hors de la zone de visualisation - Niveau : A/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-contenus-actifs-animations-videos-sons-lances-a7e693 #### Conseil n°64 - Critère : Une vidéo est-elle la seule solution pour l'illustration attendue ? - Justification : Les flux vidéo sont dans les usages de service numérique l'un des éléments qui consomment le plus de ressources de traitement, de volume d'échange. Les vidéos doivent être limitées aux cas où elles apportent une valeur importante. La vidéo n'est pas accessible pour certains publics et doit donc être limitée. - Tests : Quel est le volume total des vidéos du service ? - Niveau : A/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-flux-video-sont-dans-les-usages-47f131 #### Conseil n°65 - Critère : Réduisez-vous le nombre de picto utilisés dans le service ? - Justification : Tous les éléments de présentation ont un poids supérieur au caractères de l'alphabet. Chaque fois qu'un pictogramme est utilisé alors que l'information qu'il véhicule pourrait être présentée différemment le service augmente son volume. De plus, les assistants d'accessibilité ne permettent pas toujours de restituer ces pictogrammes dans de bonnes conditions. - Tests : Est-ce que les picto attendus sont disponibles dans une font ? - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-tous-les-elements-de-presentation-ont-un-8f8a62 #### Recommandation n°66 - Critère : Limitez-vous le nombre de fonts chargées pour le service ? - Justification : Chaque police est encodée dans un fichier présentant tous les symboles associés ce qui représente un volume de données important échangé et manipulé. Les polices systèmes sont embarquées dans les outils de présentation et ne sont pas véhiculées, les flux sont donc réduits lorsqu'elles sont utilisées. - Tests : Combien de Font sont utilisées ? L'ensemble de ces Font sont-elles nécessaires ? sont-elles web-safe ? - Cas d’usage : Code source / CHROME console - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-chaque-police-est-encodee-dans-un-fichier-3717cf #### Recommandation n°67 - Critère : En cas d'impression, une police permettant l'économie d'encre est-elle mise en place ? - Justification : Les flux de dématérialisation sont parfois rompus, et imposent la production d'écrits sur papier. L'utilisateur dans certains cas peut aussi être plus confortable à utiliser des documents imprimés plutôt que 100% électroniques. Les impressions ont un impact environnemental important, que ce soit dans la consommation de papier, de consommables tels que les cartouches et encres d'impression. Les besoins de présentation en électronique ou en impression sont différents. D'autre part la limitation de l'empreinte environnementale doit conduire à réduire la densité et le volume d'information imprimé. - Tests : Quelle police est prise en charge pour l'impression ? - Cas d’usage : Des tests d'impression sont réalisés pour vérifier les consommations d'encre, papiers et la pertinence des informations imprimées. - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-les-flux-de-dematerialisation-sont-parfois-rompus-4cb4d3 #### Recommandation n°68 - Critère : Est-ce que les polices utilisées ne sont pas chargées uniquement pour un nombre réduit d'objets ? - Justification : Chaque police est encodée dans un fichier présentant tous les symboles associés ce qui représente un volume de données important échangé et manipulé. Lorsque seuls quelques éléments de la police sont utilisés, le rapport entre le volume total et le volume réellement utile devient mauvais et un impact environnemental est généré pour aucun bénéfice. - Tests : Avez-vous créé des fonts personnalisées pour ne charger que les objets utilisés ? - Cas d’usage : Code source / CHROME console - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-chaque-police-est-encodee-dans-un-fichier-13f700 #### Recommandation n°69 - Critère : Le service est-il développé en accord avec les recommandations RGAA ? - Justification : Au-delà des aspects purement réglementaires, l'anticipation de la prise en compte de l'accessibilité est nécessaire pour assurer une couverture de ce sujet durant toute la durée de vie du service. Anticiper les futurs points de règlements et normes permet de pérenniser le service en limitant les besoins de mises à jour dictées par l'environnement légal. - Tests : Quel est le niveau de conformité RGAA ? ; Les valeurs de contraste sont-elles en accord avec les recommandations RGAA ? - Cas d’usage : Déclaration d'accessibilité - Niveau : B/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-au-dela-des-aspects-purement-reglementaires-lanticipation-de-b8128f #### Recommandation n°70 - Critère : Les animations sont-elles nécessaires, souhaitées par l'utilisateur ? - Justification : Le traitement des animations consomme des ressources techniques et détourne l'attention des utilisateurs, de plus les animations sont généralement dépendantes de caractéristiques techniques des terminaux et génèrent des incompatibilités qui poussent artificiellement au renouvellement des équipements. - Tests : Quelles animations pourraient être remplacées par une infographie ? - Cas d’usage : Les parcours utilisateur présentent les objets média et la valeur ajoutée des informations proposées par ces objets - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-le-traitement-des-animations-consomme-des-ressources-a24330 #### Recommandation n°71 - Critère : Une alternative CSS est-elle disponible pour une animation ? - Justification : L'information transmise à l'utilisateur par les animations peut aussi être gérée par des mécanismes CSS qui sont moins lourds donc plus économes de ressources. - Tests : Quelles animations pourraient être remplacées par une alternative CSS ? - Cas d’usage : Code source / CHROME console - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-frontend-linformation-transmise-a-lutilisateur-par-les-animations-ac19ee ### Recommandation n°10 — Rechercher la mise en oeuvre de comportements sobres #### Recommandation n°72 - Critère : Les objets de cartographie, animations, vidéos sont-ils présentés dans un mode statique ? - Justification : Les objets de cartographie n'ont pas toujours une pertinence à être présentés sous forme d'objets dynamiques et interactifs. La version statique sous forme d'image des plans peut apporter à l'utilisateur suffisamment d'information sans qu'il n'ait besoin d'interagir avec l'objet. Les objets de cartographie sont complexes et nécessitent des ressources de traitements et l'utilisation de capteurs, ce que les versions images des plans évite. L'utilisateur conserve la possibilité d'interaction en activant la version dynamique mais uniquement à sa demande. - Tests : Une image statique est-elle affichée plutôt qu'un objet de cartographie, animation, vidéo ? ; Les éléments de cartographie, animation, vidéo sont-ils proposés sous forme d'image et ouverts uniquement sur demande de l'utilisateur ? - Cas d’usage : L'analyse des codes sources et les tests de navigation couvrent la recherche des éléments dynamiques. - Niveau : A/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=10-frontend-les-objets-de-cartographie-nont-pas-toujours-bda7c5 #### Conseil n°73 - Critère : Le suivi de positionnement peut-il se satisfaire d'une fréquence plus réduite ? - Justification : Les opérations techniques réalisées sur le front end peuvent mettre en oeuvre des capteurs physiques du périphérique utilisateur. La sollicitation de ces capteurs, et leurs les processus de contrôle peut entraîner une usure prématurée et en cas de panne pousser au renouvellement du périphérique. Certaines techniques logicielle permettent de réduire l'utilisation des capteurs physiques, ou de s'assurer qu'ils sont employés avec le minimum de contraintes. - Tests : La précision de localisation est-elle spécifiée avec une tolérance d'incertitude ? - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=10-frontend-les-operations-techniques-realisees-sur-le-front-94c2f0 #### Conseil n°74 - Critère : Les recherches inutiles sont-elles limitées par les moteurs de recherche locaux ? - Justification : L'utilisation de moteurs de recherches locaux dans le service permettent aux utilisateurs d'accéder plus rapidement aux informations dont ils ont besoin sans parcourir l'intégralité du service. Ces moteurs de recherche sont donc efficaces d'un point de vue efficacité environnementale et assistance à l'utilisateur. En revanche les moteurs de recherche locaux ne disposent pas de toutes les informations pour proposer des réponses adaptées aux utilisateurs et s'appuient sur des ressources distantes. Il est important de réduire les échanges avec ces ressources distantes afin de ne pas annuler le bénéfice acquis par l'utilisation du moteur de recherche. - Tests : A partir de combien de lettres les données sont-elles transmises aux moteurs de recherche ou d'auto-complétion ? ; Les recherches les plus fréquentes sont-elles mises en cache ? - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=10-frontend-lutilisation-de-moteurs-de-recherches-locaux-dans-9b000a #### Recommandation n°75 - Critère : Le volume des données présentes sur le poste utilisateurs est-il limité ? - Justification : L'ensemble des éléments transférés sur le poste utilisateur ont un impact sur les transferts résaux, sur les traitements nécessaires pour les manipuler sur le terminal utilisateur. La réduction et l'encadrement de cette volumétrie est importante. - Tests : Un volume maximum des composants transférés vers le device utilisateur est-il défini ? - Cas d’usage : Fiche de cadrage projet - Niveau : A/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=10-frontend-lensemble-des-elements-transferes-sur-le-poste-d6474c ## Famille : Hébergement Moyens mis en oeuvre pour permettre l'utilisation d'un service numérique par des utilisateurs distants. ### Recommandation n°1 — Réduire l'impact de l'hébergement #### Conseil n°1 - Critère : Le refroidissement affecte-t-il les nappes phréatiques ? - Justification : L'utilisation de l'eau est associée aux hébergements informatiques. Le plus souvent l'eau circule mais la dégradation peut provenir à la fois de la température et de la pureté. - Tests : Quel delta de température est tolérable pour l'eau entre l'entrée et la sortie ? ; Quel est le volume d'eau traité et le taux d'épuration ? - Niveau : A/C/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-lutilisation-de-leau-est-associee-aux-hebergements-b45f11 #### Conseil n°2 - Critère : L'emplacement du datacenter affecte-t-il l'écosystème à proximité ? - Justification : Les datacenters sont rarement installés au coeur des zones urbaines, ils bénéficient d'environnement naturels plus favorables qu'ils ne doivent pas contribuer à appauvrir. - Tests : Où se trouve le datacenter, peut-il dégrader une zone naturelle, ou affecter des humains ? ; Une étude d'impact a-t-elle été réalisée ? - Niveau : A/C/C - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-les-datacenters-sont-rarement-installes-au-coeur-17886b #### Conseil n°3 - Critère : La qualité de l'eau est-elle dégradée par son utilisation dans le datacenter ? - Justification : Le datacenter doit être en mesure de réutiliser l'eau qu'il rejette. - Tests : L'implémentation des captages et rejets d'eau ont-ils été vérifiés ? ; Le captage d'eau est-il en aval des rejets ? - Niveau : A/C/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-le-datacenter-doit-etre-en-mesure-de-af94bf #### Recommandation n°4 - Critère : L'eau utilisée ne provient-elle pas du réseau d'eau potable ? - Justification : Il n'y a pas de traitement superflu de l'eau nécessaire au refroidissement du datacenter. En conséquence l'utilisation de l'eau potable n'est pas envisageable. - Tests : La source d'approvisionnement d'eau est-elle vérifiée ? - Cas d’usage : Le dossier technique de l'hébergement trace les sources d'approvisionnement en eau - Niveau : A/C/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-il-ny-a-pas-de-traitement-superflu-92d198 #### Recommandation n°5 - Critère : Les déchets issus du datacenter sont-ils valorisés ou recyclés ? - Justification : Le traitement des déchets générés par un datacenter est complexe, il est donc nécessaire de l'adresser et de se préoccuper de sa bonne gestion en termes de recyclage et de respect de l'environnement. - Tests : Avez-vous les moyens de vérifier la filière de traitement des déchets ? - Cas d’usage : Le dossier technique de l'hébergement trace la revalorisation des déchets - Niveau : A/C/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-le-traitement-des-dechets-generes-par-un-f4fc71 #### Conseil n°6 - Critère : Le datacenter produit-il une nuisance sonore ? - Justification : Conformément à l'article L1382 du Code Civil, tout datacenter doit veiller à limiter sa nuisance sonore (= pollution sonore). - Tests : Les mesures en dB sont-elles vérifiées par rapport aux nuisances sur l'environnement ? - Niveau : B/C/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-conformement-a-larticle-l1382-du-code-civil-15fa5a #### Conseil n°7 - Critère : Est-ce que de l'énergie indirecte produite (chaleur) est réutilisée ? - Justification : La transformation d'énergie produit de la chaleur. Afin de ne pas rejeter de source de chaleur dans l'environnement et éviter la consommation d'énergie pour produire de la chaleur dans d'autres activités, la chaleur des datacenters doit être réutilisée (chauffage de locaux, d'eau, de serres, ...) - Tests : Quel est le pourcentage de réutilisation ? - Niveau : A/C/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-la-transformation-denergie-produit-de-la-chaleur.-32aa11 #### Recommandation n°8 - Critère : Est-ce que le bâtiment est certifié LEED / BDM ou équivalent ? - Justification : La structure du bâtiment peut être plus ou moins efficace dans sa conception, les normes environnementales les plus performantes de construction doivent être appliquées. - Tests : Quelle est la certification de la construction ? - Cas d’usage : Le dossier technique de l'hébergement trace la certification de la construction - Niveau : A/C/C - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-la-structure-du-batiment-peut-etre-plus-32e834 #### Recommandation n°9 - Critère : Est-ce que le refroidissement est optimisé en fonction d'une analyse de température précise ? - Justification : Chaque degré supplémentaire de refroidissement consomme de l'énergie, l'adaptation de la production de froid au besoin instantané permet de réduire cette consommation. - Tests : Le refroidissement est-il optimisé en fonction d'une analyse de température en temps réel ? - Cas d’usage : Le dossier technique de l'hébergement trace la stratégie de refroidissement - Niveau : A/C/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-chaque-degre-supplementaire-de-refroidissement-consomme-de-d5fdd5 #### Conseil n°10 - Critère : Comment et sur quels critères est optimisé le refroidissement ? - Justification : Les températures de fonctionnement et le niveau d'hygrométrie des tolérances des serveurs sont étendues, le refroidissement doit être optimisé pour être dans les valeurs hautes de ces plages. - Tests : Le pilotage du refroidissement est-il réalisé automatiquement en fonction de données fiables ? - Niveau : A/C/C - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-les-temperatures-de-fonctionnement-et-le-niveau-92d716 #### Conseil n°11 - Critère : L'infrastructure du datacenter prend-t-elle en compte les contraintes de refroidissement ? - Justification : L'organisation du datacenter peut faciliter la gestion des flux de refroidissements avec des structures permettant de canaliser et réduire le volume d'air traité par le refroidissement. - Tests : Le datacenter est-il conçu en cold corridor ou équivalent ? ; Les tolérances de température et hygrométrie des équipements (Serveurs, routeurs, stockage) sont-elles les plus larges possibles ? - Niveau : B/C/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-lorganisation-du-datacenter-peut-faciliter-la-gestion-a19472 #### Recommandation n°12 - Critère : Les alimentations des serveurs sont-elles efficaces ? - Justification : La consommation énergétique des serveurs est l'un des facteurs permettant de réduire l'empreinte de l'hébergement. Les labels et certifications en constantes évolutions facilitent le choix des gammes et modèles de serveurs. Certains équipements disposent de plusieurs sources d'alimentations. Les gestions d'alimentations redondantes doivent aussi entrer dans les critères de choix - Tests : Les alimentations des serveurs sont-elles certifiées 80 Plus ? - Cas d’usage : Le dossier technique de l'hébergement trace les consommations électriques et la certification des serveurs - Niveau : A/C/C - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-la-consommation-energetique-des-serveurs-est-lun-9cb4ff #### Recommandation n°13 - Critère : Est-ce que le PUE (Power Usage Effectivness) est disponible ? - Justification : La puissance totale consommée par le datacenter en comparaison de la puissance consommée par les serveurs donnent l'efficacité globale de toute l'infrastructure. - Tests : Le PUE est-il inférieur ou égal à 1,2 ? ; Le datacenter suit-il le European code of conduct for data centres ? - Cas d’usage : Le dossier technique de l'hébergement trace l'éfficacité énergétique et les PUE des sites. - Niveau : A/C/C - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-la-puissance-totale-consommee-par-le-datacenter-dc3f58 #### Recommandation n°14 - Critère : Le taux d'occupation des salles du datacenter est-il optimisé pour améliorer le bilan énergétique ? - Justification : La densité d'occupation des racks dans les salles d'hébergement doit permettre de privilégier l'efficacité des équipements mutualisés. - Tests : Un taux d'occupation minimum de 80% est-il pris en compte avant l'ouverture d'une autre salle ? ; Les espaces vides sont-ils comblés pour optimiser la circulation d'air ? - Cas d’usage : Dossier technique - Niveau : B/C/C - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-la-densite-doccupation-des-racks-dans-les-197b7e #### Recommandation n°15 - Critère : Est-ce que le WUE (Water Usage Effectivness) est disponible ? - Justification : La quantité d'eau consommée par le datacenter en comparaison de la puissance consommée par les serveurs donnent l'efficacité globale de toute l'infrastructure. - Tests : Le WUE (Water Usage Effectiveness) inférieur à 1 L/kWh ? - Cas d’usage : Le dossier technique de l'hébergement trace l'éfficacité énergétique et les WUE des sites. - Niveau : A/A/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-la-quantite-deau-consommee-par-le-datacenter-f915ce #### Recommandation n°16 - Critère : L'hébergeur adhère-t-il aux meilleurs prattiques de son secteur d'activité ? - Justification : Le domaine de l'hébergement se struture pour afficher des pratiques métiers vertueuses en développant des codes de conduite. - Tests : Le datacenter suit-il le European code of conduct for data centres ? - Cas d’usage : Le dossier technique de l'hébergement trace les affiliations des sites. - Niveau : A/A/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=1-hebergement-le-domaine-de-lhebergement-se-struture-pour-d84a04 ### Recommandation n°2 — Associer les aspects humains et techniques #### Conseil n°17 - Critère : Est-ce que tous les collaborateurs du prestataire disposent de conditions sociales et salariales équivalentes à celles du client du datacenter ? - Justification : Les besoins de supervision 24/7 des datacenters peuvent pousser les opérateurs à distribuer leurs ressources techniques et humaines de supervision dans un mode "Follow the Sun". Les conditions d'exercice et de travail dans des pays différents peuvent introduire de grandes inégalités de traitement, de couverture sociale. La transparence et la cohérence de traitement de tous les collaborateurs du prestataire permet de garantir la dimension humaine et économique du NR. - Tests : Le prestataire utilise-t-il des sous-traitants hors du territoire ? ; Est-ce que les normes environnementales et sociales du prestataire sont en conformité avec celles du "client" du datacenter ? Le fournisseur externalise-t-il certaines fonctions dans des pays avec un encadrement social différent ? - Niveau : C/A/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=2-hebergement-les-besoins-de-supervision-24%2F7-des-datacenters-8b2464 #### Conseil n°18 - Critère : Le datacenter est-il situé à proximité de l'activité principale ? - Justification : Les déplacements physiques sur les datacenters sont par nature peu fréquents mais des synchronisations avec les équipes techniques sur site est parfois indispensable. La distance doit être minimisée pour réduire les impacts de ces déplacements - Tests : Les besoins, coûts et impacts de déplacements sur le datacenter ont-ils été évalués ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=2-hebergement-les-deplacements-physiques-sur-les-datacenters-sont-d74b7a #### Conseil n°19 - Critère : Les trajets pour interventions au datacenter sont-ils possibles en transport en commun ou mobilité douce ? - Justification : La localisation du datacenter dans un périmètre accessible en mobilité faible émission est plus intéressante pour les quelques déplacements qui seraient nécessaires. - Tests : Les différents moyens de transport pour rejoindre le datacenter sont-ils vérifiés ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=2-hebergement-la-localisation-du-datacenter-dans-un-perimetre-26b592 #### Conseil n°20 - Critère : Le datacenter favorise-t-il l'écosystème économique local ? - Justification : La localisation du datacenter, notamment le pays, peut introduire des conséquences sur la territorialité des données. La région de son implémentation dans des zones favorisées ou défavorisées peut permettre de réduire les impacts des zones où le numérique est peut représenté. - Tests : L'engagement local du fournisseur est-il validé ? - Niveau : C/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=2-hebergement-la-localisation-du-datacenter-notamment-le-pays-5548d5 #### Recommandation n°21 - Critère : Le matériel provient-il d'entreprises réputées comme respectant le code du travail ? - Justification : Les fournisseurs d'approvisionnements matériels du datacenter doivent pouvoir être tracés pour permettre une analyse du cycle de vie. Le strict respect des normes internationales du travail doivent pouvoir être validées. - Tests : La traçabilité d'approvisionnement est-elle garantie ? - Cas d’usage : Procédures d'achats - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=2-hebergement-les-fournisseurs-dapprovisionnements-materiels-du-datacenter-doivent-f5132f #### Recommandation n°22 - Critère : Est-ce que les équipements sont fabriqués par des entreprises respectueuses de l'environnement ? - Justification : Le positionnement NR des fournisseurs de matériels du datacenter doit pouvoir être exposé et validé, pour assurer la continuité de la vision que demande l'analyse du cycle de vie. - Tests : Les indicateurs NR des fournisseurs sont-ils disponibles ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=2-hebergement-le-positionnement-nr-des-fournisseurs-de-materiels-bbfb1e ### Recommandation n°3 — Adapter l'utilisation des équipements techniques aux besoins #### Recommandation n°23 - Critère : Les serveurs /routeurs sont-ils éteints quand ils sont inutilisés ? - Justification : L'infrastructure réseau est au coeur de l'architecture des datacenters, les mécanismes de redondances, de sur-dimensionnement sont largement déployés mais utilisés de manière ponctuelle. En l'absence de besoin et lorsque cela n'impacte pas la sécurité du site, les équipements en sur-nombre devraient être hors tension pour diminuer les consommations d'énergie et les besoins de refroidissement. - Tests : Les procédures d'arrêt des serveurs non-utilisés sont-elles mises en place ? - Cas d’usage : Le dossier technique de l'hébergement trace la stratégie d'activation désactivations des composants en fonction de la charge - Niveau : A/C/C - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-linfrastructure-reseau-est-au-coeur-de-larchitecture-acc578 #### Recommandation n°24 - Critère : La taille du parc physique est-il en adéquation avec le volume de machines virtuelles à exécuter ? - Justification : Les techniques de virtualisation permettent de mutualiser les ressources physiques d'un serveur et d'un espace de stockage. Cette abstraction peut optimiser l'emploi du matériel, mais peut aussi conduire à sous-utiliser les équipements physiques et déployer de nouveaux équipements avant que le besoin ne soit réellement présent. L'impact environnemental total d'un serveur et de son utilisation est important. - Tests : L'allocation des ressources physiques par rapport aux machines virtuelles est-elle suivie ? ; Les ratios vCPU:pCPU sont-ils > 1:1 ? - Cas d’usage : Le dossier technique d'hébergement permet de suivre la gestion de configuration et l'adaptation aux besoins - Niveau : A/C/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-les-techniques-de-virtualisation-permettent-de-mutualiser-e12b2c #### Recommandation n°25 - Critère : La mémoire attribuée est-elle fonction de l'usage réel ? - Justification : L'adaptation et le suivi des consommations de ressources physiques doivent faire intervenir des collectes sur les équipements physiques et sur tous les équipements virtuels qu'ils accueillent. Les techniques de virtualisation récentes autorisent le changement de paramètres sans interruption pour, en fonction du besoin, augmenter ou diminuer les ressources (CPU/RAM) allouées aux machines virtuelles, voire migrer des machines virtuelles sur des serveurs physiques moins chargés. - Tests : Quels mécanismes de supervision sont déployés ? ; Le taux de disponibilité des ressources physiques est-il < 25% avant d'envisager de provisionner de nouveaux équipements ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-ladaptation-et-le-suivi-des-consommations-de-0a97af #### Recommandation n°26 - Critère : Le nombre de coeurs attribués est-il fonction de l'usage réel ? - Justification : Les ressources CPU accessibles par les machines virtuelles sont fonction du nombre de processeurs, du nombre de coeurs de chaque processeur et des capacités d'hyperThreading. Ce nombre de composants CPU constitue la base des ressources virtuelles que les machines virtuelles pourront allouer. - Tests : Le dimensionnement est-il possible à chaud ? ; L'hyperThreading est-il activé pour augmenter le nombre de physical CPU disponibles ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-les-ressources-cpu-accessibles-par-les-machines-ca861b #### Conseil n°27 - Critère : Le choix technique (mutualisé, dédié, collocation) est-il optimisé entre le besoin et l'efficacité énergétique ? - Justification : Les différentes solutions proposées par les hébergeurs génèrent des allocations de matériels physiques très différentes et donc un impact environnemental différent. Le point d'analyse majeur est le nombre de serveurs, les puissances consommées par les serveurs, les volumes de stockage et la puissance consommée par ceux-ci. L'utilisation de serveurs ou de stockages pour un besoin réduit en dessous de sa capacité nominale génère une déperdition environnementale. - Tests : Quel métrique pilote le choix : technique, sécurité , finance, évolutivité, empreinte physique ? - Niveau : B/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-les-differentes-solutions-proposees-par-les-hebergeurs-929c27 #### Recommandation n°28 - Critère : Les coeurs inutilisés sont-ils désactivés ? - Justification : Les services hébergés n'ont pas toujours les mêmes besoins de performance et subissent des variations fortes de charges, au cours de la journée, de la semaine, des mois, de l'année. Les dimensionnements sont calibrés pour accepter les charges maximales qui peuvent être sur des plages de temps restreintes. En dehors de ces périodes, le besoin de puissance est réduit et l'activité des systèmes doit être en mesure de se réduire dans les mêmes proportions pour ne pas monopoliser d'énergie inutilement. - Tests : Les périodes de sous et sur-charge sont-elles anticipées ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-les-services-heberges-nont-pas-toujours-les-a05a7d #### Recommandation n°29 - Critère : Le système de sauvegarde est-il incrémentiel (optimisation disque) ? - Justification : La sécurité est un des points clé des datacenters, les sauvegardes sont l'un des éléments participant à cette sécurisation. La volumétrie des sauvegardes est cumulative. Unitairement le volume de données à sauvegarder tend à croître, les différents jeux de sauvegardes multiplient cet effet. Les données non modifiées n'ont pas de raison d'encombrer inutilement des espaces de sauvegarde. Les sauvegardes incrémentales réduisent l'impact environnemental de ce processus. Certaines solutions sont en mesure de gérer des incréments, d'autres ne savent gérer que des archives totales qui augmentent l'empreinte environnementale. - Tests : Quel est le volume des sauvegardes quotidiennes ? - Cas d’usage : Le dossier technique d'hébergement permet de suivre la volumétrie des sauvegardes et leurs lieux de stockage - Niveau : A/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-la-securite-est-un-des-points-cle-ca3cd7 #### Conseil n°30 - Critère : L'usage de containers par rapport à des machines virtuelles est-il privilégié ? - Justification : Les machines virtuelles et les containers sont 2 techniques de virtualisation. La technologie des machines virtuelles utilise beaucoup de duplications (système d'exploitation par exemple) et créent des composants virtuels associés à des composants physiques. Le mode container repose sur les composants physiques du matériel et les exploite plus nativement en limitant les duplications de composants logiciels. D'un point de vue NR les containers sont souvent plus efficaces mais la technologie est moins largement déployée. - Tests : L'étude comparative pour le service entre VM et container est-elle disponible avec les impacts NR de chaque solution ? - Niveau : B/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-les-machines-virtuelles-et-les-containers-sont-8e55ed #### Conseil n°31 - Critère : Est-ce que les solutions Open Source sont mises en oeuvre lorsqu'elles sont disponibles ? - Justification : Une solution Open Source n'est pas un gage d'efficacité NR et les différentes alternatives doivent être challengées. Mais l'Open Source permet de limiter les ambitions et mainmises de certains acteurs dont les pratiques économiques, sociales sont opaques. - Tests : Les solutions Open Source sont-elles aussi sélectionnées pour leurs performances NR ? - Niveau : C/B/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-une-solution-open-source-nest-pas-un-86b455 #### Recommandation n°32 - Critère : La haute disponibilité est-elle conçue de manière modulaire ? - Justification : Les besoins de sécurisation sont différents en fonction des clients, des services hébergés. La même règle générique d'excellence dans ce domaine n'est pas toujours nécessaire. La conception des mécanismes de haute disponibilité qui met en jeu beaucoup de composants redondants doit pouvoir s'adapter au besoin réel afin de réduire l'impact des services. - Tests : Le besoin de sécurisation est-il défini pour chaque fonction ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-les-besoins-de-securisation-sont-differents-en-dd75bb #### Recommandation n°33 - Critère : Le provisionning / deprovisionning est-il dynamique en fonction de la charge ? - Justification : Lors de l'hébergement d'un service, chaque partie le composant peut être amenée à avoir une durée de vie différente. Il est important que l'ensemble des procédures de fin de vie soient exprimées pour que l'empreinte des composants inutilisés et arrêtés soient nulle. Y compris lorsque l'arrêt est temporaire suite à une baisse d'activité. - Tests : Après combien de temps d'inactivité les services sont-ils dé-provisionnés ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-lors-de-lhebergement-dun-service-chaque-partie-31f40c #### Recommandation n°34 - Critère : Est-ce que les solutions de stockage permettent de réduire le nombre de composants (par exemple: supports SSD haute densité) ? - Justification : La densité des espaces de stockage conditionne la consommation d'énergie que le stockage va demander. Les technologies des disques évoluent rapidement, les parties mobiles tendent à être remplacées par des composants électroniques qui permettent de réduire la consommation électrique globale. - Tests : Quel est le ratio entre l'espace consommé et le volume de données ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=3-hebergement-la-densite-des-espaces-de-stockage-conditionne-a76903 ### Recommandation n°4 — Suivre les impacts de l'hébergeur #### Recommandation n°35 - Critère : L'électricité provient-elle d'énergies renouvelables ? - Justification : L'activité d'un datacenter nécessite de l'énergie. Les sources d'énergies vont déterminer l'empreinte environnementale. Les solutions d'alimentation à partir d'énergie bas carbone et renouvelables vont diminuer cet impact. - Tests : Les sources d'alimentation énergétiques sont-elles connues ? - Cas d’usage : Le dossier technique d'hébergement permet de suivre les sources d'approvisionnement en énergie - Niveau : A/C/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-lactivite-dun-datacenter-necessite-de-lenergie.-les-2a3048 #### Recommandation n°36 - Critère : Les serveurs et les équipements techniques sont-ils certifiés ? - Justification : Les normes, labels et certifications environnementales se généralisent. Les serveurs, les espaces de stockage, les équipements réseaux affichent de plus en plus fréquemment des adhésions à certaines de ces normes de fait ou standardisées. L'émergence de nouveaux marqueurs doit être surveillée pour permettre la meilleure solution. - Tests : Les serveurs ont-ils une certification (ASHRAE, TCO8, ...) ? - Cas d’usage : Le dossier technique de l'hébergement trace l'éfficacité énergétique et les certifications des équipements - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-les-normes-labels-et-certifications-environnementales-se-caff36 #### Recommandation n°37 - Critère : Le datacenter permet-il d'avoir des informations fiables en terme de consommations d'énergie ? - Justification : Le total des consommations d'énergie est utile pour estimer l'empreinte environnementale du datacenter. Cela doit prendre en compte aussi les équipements de secours (générateurs, onduleurs,...), mais la segmentation de ces consommations par usage est beaucoup plus significative, certains indicateurs n'étant calculés qu'avec des données plus précises (par exemple le PUE). L'autre intérêt de cette ventilation est d'identifier les points les plus consommateurs pour mettre en place des actions visant à les réduire. - Tests : Les données sont-elles publiées et vérifiables ? - Cas d’usage : Architecture / Documentation - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-le-total-des-consommations-denergie-est-utile-d3bc38 #### Recommandation n°38 - Critère : L'hébergeur est-il transparent sur l'impact carbone de l'infrastructure et des usages pour ses clients ? - Justification : L'activité d'un datacenter génère un impact carbone qui peut être important. - Tests : L'opérateur du datacenter met-il à disposition de ses clients les informations pour connaître l'impact carbone ? ; Les clients ont-ils accès à des métriques sur l'impact carbone de leurs usages ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-lactivite-dun-datacenter-genere-un-impact-carbone-30aba5 #### Recommandation n°39 - Critère : Est-ce que les fournisseurs sont sélectionnés en fonction de leurs capacités à communiquer les indicateurs différenciants ? - Justification : Dans les règles de sélection des fournisseurs de services d'hébergement, les aspects NR doivent être pris en compte de la même manière que si le service était pris en charge en interne. Le cahier des charges doit exposer en plus des considérations techniques, budgétaires et de respect des normes de sécurité les principes NR que le fournisseur doit remplir. - Tests : Quels seuils sont définis comme limites d'acceptabilité ? - Cas d’usage : Procédure d'achat - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-dans-les-regles-de-selection-des-fournisseurs-7f7f77 #### Conseil n°40 - Critère : La structure juridique, ses filiales et sa filiation sont-elles respectueuses des réglementations et de la déontologie ? - Justification : Les activités d'hébergement prennent deux directions opposées : la concentration avec de gros acteurs et la multiplication d'acteurs de proximité. Les structures juridiques de ces deux types d'entités peuvent être plus ou moins visibles, il est important de pouvoir en appréhender toutes les ramifications pour choisir, en connaissance de cause et dans le respect des principes NR, le fournisseur. - Tests : Toutes les informations légales sont-elles collectées et étudiées ? - Niveau : C/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-les-activites-dhebergement-prennent-deux-directions-opposees-1bf2e7 #### Recommandation n°41 - Critère : Le fournisseur expose-t-il tous ses indicateurs ? - Justification : Le niveau de maturité NR des opérateurs de datacenter est très variable, lorsque les indicateurs de performances NR sont exposés cela démontre une maturité avancée. La communication d'indicateurs ne présume pas de la pertinence et de la fiabilité des indicateurs qui doivent aussi être exposés. - Tests : Quels indicateurs sont basés sur des données externes avec des sources fiables ? - Cas d’usage : Le dossier technique de l'hébergement trace l'ensemble des indicateurs mis à disposition - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-le-niveau-de-maturite-nr-des-operateurs-935f7c #### Conseil n°42 - Critère : Les équipements non-critiques sont-ils issus du reconditionnement ? - Justification : Le prolongement de la durée de vie des équipements permet de réduire les remplacements de matériels, l'utilisation de matériels reconditionnés est une pratique intéressante dans ce sens. Toutefois les avancées technologiques et l'efficacité des composants techniques peut rendre plus utile dans la phase d'usage de disposer de matériels récents qui vont consommer moins d'énergie pour une même utilisation. - Tests : La source d'approvisionnement est-elle exposée ? - Cas d’usage : Architecture / Documentation - Niveau : A/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-le-prolongement-de-la-duree-de-vie-aabe57 #### Recommandation n°43 - Critère : Les équipements sont-ils réparés plutôt que remplacés ? - Justification : La réparabilité des matériels, et le taux effectif de réparation est un critère qui permet d'atténuer l'impact environnemental des matériels sur l'ensemble de leurs durées de vie. - Tests : Le taux de réparation est-il communiqué ? - Cas d’usage : Le dossier technique de l'hébergement trace la filière de réparation / revalorisation - Niveau : A/B/A - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-la-reparabilite-des-materiels-et-le-taux-5bc85c #### Recommandation n°44 - Critère : Les équipements en fin de vie sont-ils revalorisés ( vente / don / recyclage ... ) ? - Justification : Le renouvellement du parc technique est incontournable, les équipements en capacité de servir des usages moins intenses doivent être reconditionnés et ré-injectés dans d'autres secteurs d'activité. Les matériels qui ne peuvent être remis en service doivent entrer dans une filière de recyclage fiable et chaque étape doit être tracée pour garantir sa conformité avec les exigences NR. - Tests : La chaîne est-elle traçable ? - Cas d’usage : Le dossier technique de l'hébergement trace la filière de revalorisation - Niveau : A/B/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-le-renouvellement-du-parc-technique-est-incontournable-f80f16 #### Conseil n°45 - Critère : Est-ce que les serveurs et routeurs sont renouvelés lorsque les technologies permettent une meilleure efficacité énergétique ? - Justification : Les avancées technologiques et l'efficacité des composants techniques peut rendre plus utile dans la phase d'usage de disposer de matériels récents qui vont consommer moins d'énergie pour une même utilisation. - Tests : Est-ce que les certifications des équipements sont disponibles ? - Niveau : B/B/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-les-avancees-technologiques-et-lefficacite-des-composants-a0aa09 #### Recommandation n°46 - Critère : Est-ce que les matériaux de construction / gaine / isolant utilisés permettent une meilleure efficacité énergétique. Le bâtiment répond-t-il aux normes HQE , rt2012 ou équivalentes ? - Justification : En plus de la structure du bâtiment qui peut être plus ou moins efficace dans sa conception, les éléments de construction et liés à l'activité de datacenter peuvent aussi suivre les normes environnementales les plus performantes. - Tests : Quelle norme est utilisée ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-en-plus-de-la-structure-du-batiment-109314 #### Conseil n°47 - Critère : Quel est l'impact du refroidissement du datacenter sur l'environnement ? - Justification : Les techniques de refroidissement font intervenir soit de la production de froid à partir d'une source d'énergie, soit la captation de froid sur une source naturelle. La consommation d'énergie à un impact direct. La captation d'une source naturelle de froid doit aussi être évaluée par rapport à l'impact environnemental de rejet de chaleur. - Tests : Quel est le type de refroidissement utilisé ? - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-hebergement-les-techniques-de-refroidissement-font-intervenir-soit-d148b3 ### Recommandation n°5 — Garder la cohérence de positionnement entre les besoins et les choix d'hébergement #### Recommandation n°48 - Critère : Les mesures carbon / water efficiency sont-elles disponibles ? - Justification : Les standards pour les datacenters mettent en avant les indicateurs d'efficacité qui dépassent la partie énergétique. Les métriques d'efficacité carbone et eau sont de plus en plus employée et permettent une meilleure évaluation des datacenter. - Tests : Les mesures d'efficacité environnementale sont-elles disponibles ? - Cas d’usage : Le dossier technique de l'hébergement trace les indicateurs environnementaux - Niveau : A/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=5-hebergement-les-standards-pour-les-datacenters-mettent-en-bd55ba #### Recommandation n°49 - Critère : L'entreprise (l'hébergeur) applique-t-elle une politique RSE / RGAA ? - Justification : Le respect des considérations des personnes est un critère important pour le NR - Tests : Les équipes de support et d'exploitation sont-elles sous les mêmes législations que le client ? ; Un référent RSE - RGAA est-il disponible ? - Cas d’usage : Procédure d'achat - Niveau : B/A/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=5-hebergement-le-respect-des-considerations-des-personnes-est-19387d #### Recommandation n°50 - Critère : L'entreprise fournit-elle des garanties fiables en terme de RGPD ? - Justification : Le RGPD impose de communiquer les éléments d'hébergement, cet aspect légal doit être vérifié précisément. - Tests : Le respect des réglementations Françaises et Européennes ainsi qu'une indépendance vis-à-vis d'une réglementation d'un pays étranger sont-elles prises en compte ? - Cas d’usage : Dossier technique - Niveau : B/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=5-hebergement-le-rgpd-impose-de-communiquer-les-elements-6f3d67 #### Conseil n°51 - Critère : Les atouts de l'hébergeur sont-ils exposés lorsqu'ils font progresser le NR ? - Justification : Des outils permettent de vérifier les caractéristiques des hébergeurs pour des sites WEB. La promotion des hébergeurs utilisés qui mettent en oeuvre les meilleures solutions NR peuvent être exposés avec des "stickers" sur le site WEB. Certains outils utilisent des règles opaques, dans tous les cas il est indispensable de vérifier la validité des notations données par ces outils. - Tests : Quel partenariat de communication est mis en place ? ; Un référent NR est-il disponible ? - Niveau : B/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=5-hebergement-des-outils-permettent-de-verifier-les-caracteristiques-d0b22d #### Recommandation n°52 - Critère : Toutes les données soumises à une réglementation (santé, bancaire) sont-elles sécurisées sur un hébergeur avec un niveau d'agrément compatible ? - Justification : Les réglementations imposent des agréments spécifiques pour certaines catégories de données (santé, bancaire). Les normes évoluent en fonction des besoins de sécurisation et de l'état de l'art. La validation d'un agrément doit être suivi régulièrement pour garantir que les utilisateurs du services ne sont pas exposés à des risques. - Tests : Quelles sont les certifications de l'hébergeur vis-à-vis des données réglementées ? - Cas d’usage : Analyse de risques - Niveau : C/B/B - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=5-hebergement-les-reglementations-imposent-des-agrements-specifiques-pour-b4585f #### Conseil n°53 - Critère : L'hébergeur est-il agréé ? - Justification : Les réglementations imposent des agréments spécifiques pour certaines catégories de données (santé, bancaire). Les normes évoluent en fonction des besoins de sécurisation et de l'état de l'art. La validation d'un agrément doit être suivie régulièrement pour garantir que les utilisateurs du service ne sont pas exposés à des risques. - Tests : L'hébergeur est-il agréé HDS? ; L'hébergeur est-il agréé PCI-DSS? - Niveau : C/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=5-hebergement-les-reglementations-imposent-des-agrements-specifiques-pour-626d33 #### Conseil n°54 - Critère : Le fournisseur adhère-t-il à un standard / label ? - Justification : L'opérateur de datacenter peut avoir lancé une démarche NR, et être en mesure d'exposer son adhésion et ses actions pour le NR - Tests : Une charte a-t-elle été signée ? Fait-il partie d'un réseau NR ? - Niveau : A/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=5-hebergement-loperateur-de-datacenter-peut-avoir-lance-une-18759a ### Recommandation n°6 — Définir les enjeux et fonctionnalités du projet #### Recommandation n°55 - Critère : Le datacenter est-il à minima Tier 3 ? - Justification : Le niveau de sécurisation du datacenter conditionne les éléments de disponibilité des services numériques. - Tests : Quel est le niveau du datacenter ? - Cas d’usage : Architecture / Documentation - Niveau : B/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=6-hebergement-le-niveau-de-securisation-du-datacenter-conditionne-e3e97e #### Conseil n°56 - Critère : L'opérateur dispose-t-il de plusieurs datacenters interconnectés et distants de + de 100kms ? - Justification : Les impacts des cataclysmes naturels ou industriels peuvent rendre certains sites inopérants. Afin de garantir une continuité de service, les distances entre les différents sites hébergeant les services doivent prendre en compte ces éléments. - Tests : Est-il conforme à une norme ISO ? - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-hebergement-les-impacts-des-cataclysmes-naturels-ou-industriels-c39f4c #### Recommandation n°57 - Critère : La certification du datacenter est-elle adaptée au besoin et à l'emplacement géographique (sismique, innondation) ? - Justification : Les caractéristiques des zones géographiques peuvent nécessiter des dispositions spécifiques que les datacenters doivent prendre en compte. - Tests : Les risques physiques ont-ils été évalués sur toute la vie du projet ? - Cas d’usage : Architecture / Documentation - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=6-hebergement-les-caracteristiques-des-zones-geographiques-peuvent-necessiter-dfb88f #### Conseil n°58 - Critère : Le contrôle d'accès physique au site met-il en oeuvre des données biométriques ? - Justification : La capture d'information biométriques permet de sécuriser des accès, mais transmet des données personnelles importantes qui doivent être protégées. - Tests : Quelles sont les garanties offertes en terme de sécurisation des données d'accès, exploitation, conservation, durée de vie ? - Niveau : B/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-hebergement-la-capture-dinformation-biometriques-permet-de-securiser-043caa #### Conseil n°59 - Critère : Le datacenter fournit-il une solution locale de coffre-fort numérique sécurisé ? - Justification : L'hébergement de données critiques dans un espace hautement sécurisé et crypté est parfois indispensable pour assurer la pérennité de l'organisation - Tests : Quelle technologie, niveau de sécurité, cryptage est utilisée pour le coffre-fort numérique ? - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-hebergement-lhebergement-de-donnees-critiques-dans-un-espace-4a47cc #### Recommandation n°60 - Critère : Les processus mis en place pour la prévention des incidents prennent-ils en compte la non-dégradation des serveurs et équipements ? - Justification : Les procédures de réponses aux incidents doivent en premier lieu protéger les personnes et leurs données, mais la destruction d'équipements physiques génère un besoin de renouvellement avec son impact sur l'environnement. - Tests : A quelle fréquence sont testés les équipements de sécurité ? - Cas d’usage : Le dossier technique de l'hébergement trace les stratégies de traitement des incidents - Niveau : A/B/B - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=6-hebergement-les-procedures-de-reponses-aux-incidents-doivent-3661d8 #### Recommandation n°61 - Critère : L'impact environnemental d'implémentation de chaque fonction est-il en rapport avec son importance ? - Justification : La cohérence NR pousse à s'assurer que les fonctions secondaires n'ont pas un impact environnemental plus important que les fonctions principales. Les spécifications doivent clairement identifier les fonctions principales et secondaires et leur impact du point de vue NR. - Tests : Avez-vous appliqué une démarche 80/20 pour chaque fonction en rapport avec ses impacts environnementaux et son importance ? - Cas d’usage : Analyse d'impact - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-hebergement-la-coherence-nr-pousse-a-sassurer-que-771c4d #### Recommandation n°62 - Critère : Chacune des phases du cycle de vie sont-elles identifiées avec des actions spécifiques ? - Justification : La démarche ACV est une base de la prise en compte du NR dans la conception des services numériques, elle permet d'associer des actions à chaque étape du cycle de vie. - Tests : A quelle fréquence ces actions sont-elles revues ? - Cas d’usage : ACV - Niveau : B/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-hebergement-la-demarche-acv-est-une-base-de-ddcfc4 #### Recommandation n°63 - Critère : Les données des études précédentes sont-elles disponibles et tenues à jour ? - Justification : Les analyses ACV peuvent être réalisées sur des services existants afin de les rendre plus efficaces dans le cas d'une refonte ou adaptation d'un service existant. - Tests : Quelles données ACV sont produites pour permettre leur réutilisation dans d'autres projets ? - Cas d’usage : Documentation technique - Niveau : C/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=6-hebergement-les-analyses-acv-peuvent-etre-realisees-sur-599a24 ## Famille : Spécifications Les spécifications regroupent les éléments de cadrage projet, les moyens mis en oeuvre, les objectifs et contraintes du projet sur toute la durée de vie du produit cible. Indépendamment du type de gestion projet : AGILE ou cycle en V classique. ### Recommandation n°1 — Organiser les ressources humaines projets pour permettre la prise en compte de la démarche NR #### Recommandation n°1 - Critère : Les enjeux NR du projet ont-ils été communiqués à l'équipe dès l'origine ? - Justification : La démarche NR est mieux prise en compte lorsqu'elle s'insère par un processus systémique et qu'elle est exposée comme direction à suivre pour tous les acteurs. - Tests : Combien de personnes sensibilisées / formées au NR dans l'équipe projet ? - Cas d’usage : La fiche projet précise les objectifs et attendus NR - Niveau : A/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=1-specifications-la-demarche-nr-est-mieux-prise-en-8adaec #### Recommandation n°2 - Critère : Les référents NR de l'organisation sont-ils identifiés ? - Justification : Le NR nécessite une forte connaissance qui doit être portée par des personnes qui sont les mieux adaptées. - Tests : Y a-t-il un référent NR permanent ou dédié au projet ? - Cas d’usage : La fiche de cadrage projet désigne le référent NR du projet. - Niveau : A/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=1-specifications-le-nr-necessite-une-forte-connaissance-qui-2ac4c9 #### Conseil n°3 - Critère : Quelle approche éditoriale est prévue pour sensibiliser les clients au NR ? - Justification : La communication vers les utilisateurs et clients est aussi un engagement de l'entreprise pour réduire ses impacts environnementaux et se démarquer de la concurrence en affichant son ambition et ses résultats NR. - Tests : La communication NR vers les clients est-elle définie ? - Niveau : A/B/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-specifications-la-communication-vers-les-utilisateurs-et-clients-61be95 #### Recommandation n°4 - Critère : Chaque entité de l'équipe Projet dispose-t-elle des compétences NR ? - Justification : Chacune des étapes projet requiert des connaissances spécifiques pour les aspects NR, il est important que toutes les étapes soient couvertes afin que les résultats NR soient cohérents tout au long de la vie du service. - Tests : Combien de personnes sont sensibilisées et formées au NR ? - Cas d’usage : Plan de formation adapté à chacun des profils - Niveau : B/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=1-specifications-chacune-des-etapes-projet-requiert-des-connaissances-1ca708 #### Recommandation n°5 - Critère : Les données ACV sont-elles réutilisées dans le cas d'une adaptation d'un service existant ? - Justification : Les analyses ACV peuvent être réalisées sur des services existants afin de les rendre plus efficaces dans le cas d'une refonte ou adaptation d'un service existant. Les spécifications et exigences NR issues des ACV précédentes doivent être reprises et adaptées si besoin. - Tests : Avez-vous mis à disposition des équipes projet les ACV précédentes ? ; L'ACV de ce projet est-elle rendue disponible pour d'autres projets ? ; L'ACV de ce projet sera-t-elle réalisée ? - Cas d’usage : Une ACV minimale ("screening") est disponible pour le service existant - Niveau : A/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=1-specifications-les-analyses-acv-peuvent-etre-realisees-sur-c8b496 #### Conseil n°6 - Critère : Chaque partie-prenante a-t-elle la latitude de prendre des décisions pouvant influer sur l'impact environnemental ? - Justification : Les spécifications et les USER STORY peuvent évoluer au fil du temps, ces évolutions doivent systématiquement prendre en compte les aspects NR. Les adaptations sont le plus souvent le fait des métiers. Les impacts environnementaux doivent pouvoir aussi avoir cette latitude avec des chemins de validation pré-définis. - Tests : Le circuit et l'autonomie de décision ayant un impact NR est-il défini pour chaque acteur ? - Niveau : B/A/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-specifications-les-specifications-et-les-user-story-peuvent-3d43c3 ### Recommandation n°2 — Inclure les utilisateurs dans les ressources projet NR #### Conseil n°7 - Critère : La définition des besoins est-elle réalisée en consultant les utilisateurs finaux ? - Justification : Lorsque les besoins utilisateurs sont extrapolés à partir d'analyses et d'objectifs de l'organisation, cela peut conduire à des expressions de besoin plus larges que celles dont les utilisateurs vont réellement se servir et le service sera plus consommateur que nécessaire. - Tests : La maîtrise d'ouvrage du projet contient-elle un utilisateur témoin ou un représentant maîtrisant le métier ? - Niveau : B/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=2-specifications-lorsque-les-besoins-utilisateurs-sont-extrapoles-a-a9ee6b #### Conseil n°8 - Critère : Transmettez-vous une pédagogie NR aux utilisateurs ? - Justification : Les utilisations des services sont une source de consommation de ressources. Si les utilisateurs sont incités et guidés pour réduire leurs impacts avec des démarches pédagogiques, cela rend l'ensemble du service plus efficace pour réduire son impact. - Tests : Un utilisateur témoin avec une forte coloration NR est-il inclus dans la démarche projet ? ; Un utilisateur témoin dédié au projet est-il formé au NR ? - Niveau : A/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=2-specifications-les-utilisations-des-services-sont-une-source-ef25e1 #### Conseil n°9 - Critère : Les aspects NR sont-ils propagés et entretenus sur l'ensemble des acteurs ? - Justification : Lorsque chacun des acteurs a un accès simple à des marqueurs permettant d'évaluer l'impact environnemental de ses actions et choix, il peut adapter ses pratiques pour rendre le service plus efficace et responsable. - Tests : Quels sont les marqueurs et étapes de suivis définis ? - Niveau : B/A/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-specifications-lorsque-chacun-des-acteurs-a-un-acces-2f833b #### Recommandation n°10 - Critère : Les profils cibles sont-ils définis ? - Justification : Pour exprimer clairement les objectifs NR dans chacune des spécifications il est indispensable de situer les profils cibles et de leur associer des objectifs NR précis. - Tests : Les objectifs NR sont-ils qualifiés pour chaque profil cible? - Cas d’usage : Fiche de cadrage projet - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=2-specifications-pour-exprimer-clairement-les-objectifs-nr-dans-05eda9 #### Recommandation n°11 - Critère : Les aspects numérique responsable sont-ils propagés et entretenus sur l'ensemble des profils utilisateurs ? - Justification : Les phases d'utilisation sont un moyen de communiquer et entretenir le lien sur les aspects NR avec les utilisateurs, c'est aussi une démarche qui offre un canal de communication différent et démarquant vis à vis de la concurrence en impliquant les utilisateurs et les rendant acteurs du service proposé. - Tests : Quelle est votre fréquence de communication NR pour chaque profil utilisateur ? - Cas d’usage : Plan de formation - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=2-specifications-les-phases-dutilisation-sont-un-moyen-de-ec173f ### Recommandation n°3 — Organiser la méthodologie projet pour permettre d'appliquer une démarche NR #### Conseil n°12 - Critère : Les étapes de revue NR sont-elles incluses dans la méthodologie ? - Justification : Les objectifs NR doivent être clairement définis et la gestion projet doit traiter le suivi de ces objectifs avec des revues au même titre que les autres catégories d'exigences, en associant les acteurs aptes à arbitrer, justifier et valider les décisions - Tests : Comment et qui arbitre les conflits ? (par exemple : Budget et NR) - Niveau : B/B/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=3-specifications-les-objectifs-nr-doivent-etre-clairement-definis-619fcc #### Recommandation n°13 - Critère : Des fonctionnalités (User Story) concernent-elles uniquement les aspects NR ? - Justification : Le projet doit définir des exigences NR (Exigences Non Fonctionnelles - NFR) ou des User Stories spécifiques qui vont introduire des orientations NR dans la conception. Ces éléments seront pris en charge au même titre que les autres NFR (sécurité, accessibilité par exemple) et garantiront que les aspects NR seront pris en considération dans toutes les étapes du projet. - Tests : Quel est l'objectif fixé au départ du projet ? - Cas d’usage : Des Tags/Labels NR sont utilisés pour identifier tous les aspects NR pris en compte dans le Backlog - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-specifications-le-projet-doit-definir-des-exigences-nr-786796 #### Recommandation n°14 - Critère : Quelle proportion des fonctionnalités (User Story) ont une composante NR ? - Justification : Certaines fonctionnalités peuvent être conçues avec des impacts NR très différents. En l'absence de clarification, la solution choisie sera le plus souvent pilotée par la facilité ou l'appétence technique, ce qui s'oppose en général à la performance NR. Le seul moyen de guider les décisions est d'introduire des points d'attention sur les aspects NR dans la majorité des User Stories. - Tests : Une exigence NR est-elle justifiée plutôt qu'un aspect NR dans une exigence plus générale ? - Cas d’usage : Le Backlog utilise des Tags/Labels NR pour identifier les user stories avec des éléments NR - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-specifications-certaines-fonctionnalites-peuvent-etre-concues-avec-des-fe6a37 #### Conseil n°15 - Critère : Quelle est la fréquence de revue/validation des éléments NR, sur un mode similaire aux revues et validation "Sécurité" ? - Justification : La prise en compte des aspects NR fait au démarrage de la conception peut être respectée mais dans un mode itératif il est possible de s'en écarter graduellement. Les revues du respect NR sont indispensables pour conserver la cohérence du projet. - Tests : Le processus de revue est-il formalisé ? ; Les référents NR sont-ils inclus dans les revues ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-specifications-la-prise-en-compte-des-aspects-nr-cca6dd #### Recommandation n°16 - Critère : Chaque fonctionnalité est-elle évaluée par rapport aux usages ? - Justification : Les User Story / Use Case doivent être spécifiés par rapport à des usages afin de ne pas aller vers une inflation de fonctionnalités qui seraient superflues par rapport aux besoins réels des utilisateurs. Proposer des fonctionnalités marginales va engendrer une empreinte environnementale, un coût et une incompréhension du service supplémentaire non justifiés. - Tests : Les fonctionnalités attendues par l'utilisateur et leur périmètre d'action sont-ils définis afin de poser un cadre aux interactions et ne pas aller dans le superflu ? - Cas d’usage : Definition of Done - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-specifications-les-user-story-%2F-use-case-doivent-1e29dd #### Conseil n°17 - Critère : L'utilisation d'intégration continue est-elle généralisée ? - Justification : Du point de vue NR, le fait de capitaliser sur les acquis et de fournir un modèle technique qui garanti ces acquis, évite les anomalies et surcoûts de non qualité. - Tests : Est-ce que la compléxité du service est encadrée / suivie dans le processus d'intégration continue ? - Niveau : C/B/C - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-specifications-du-point-de-vue-nr-le-fait-3b7eb8 #### Recommandation n°18 - Critère : Les processus d'intégration continue ne génèrent-ils pas des brèches dans la prise en compte des aspects NR ? - Justification : Les différentes phases de l'intégration continue permettent de piloter les processus avec des attendus définis. L'une de ces étapes d'intégration doit valider le respect des impacts NR. - Tests : Chaque étape du cycle de vie prend-elle en compte les aspects NR? - Cas d’usage : Dossier technique - Niveau : C/B/C - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=3-specifications-les-differentes-phases-de-lintegration-continue-permettent-6e722b #### Conseil n°19 - Critère : Les exigences non fonctionnelles (User Story) sont-elles traitées de la même manière pour les aspects NR, sécurité et accessibilité ? - Justification : Les catégories d'exigences Non Fonctionnelles (NFR) interviennent de manière transverse dans la gestion de projet car les dépendances sont le plus souvent associées à des comportements que l'on ne peut que rarement lier à une seule action. C'est aussi le cas du NR, une décision ponctuelle efficace peut être rendue caduque par des actions en amont ou en aval. - Tests : Les mécanismes de validation sont-ils similaires pour la sécurité et les aspects NR ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=3-specifications-les-categories-dexigences-non-fonctionnelles--interviennent-04d933 #### Recommandation n°20 - Critère : L'état des lieux des données d'entrée est-il mis à disposition afin d'être réutilisé dans d'autres projets ? - Justification : Les principes NR sont stables et les bonnes pratiques déployées sont directement utilisables dans d'autres contextes projet, d'autant plus que les projets au sein d'une organisation ont beaucoup de similarités, que ce soit dans les méthodes, les objectifs ou les périmètres fonctionnels. Dans la phase de spécification, collecter, préparer et produire ces éléments est un gage d'efficacité et de fiabilité pour augmenter la maturité de l'organisation dans ses pratiques NR. - Tests : Quelles sont les données utilisées en entrée et produites pour les autres projets ? ; Existe-t-il une cartographie applicative et une cartographie des processus (et des données) exploitables dans l'entreprise ? Seront-elles bien mises à jour dans le cadre du projet ? ; La cellule d'urbanisation du SI de l'entreprise a-t-elle été sollicitée ? - Cas d’usage : Documentation technique - Niveau : B/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=3-specifications-les-principes-nr-sont-stables-et-les-ee6678 ### Recommandation n°4 — Construire le périmètre du projet et valider la pertinence de chaque fonctionnalité #### Recommandation n°21 - Critère : Les exigences NR sont elles associées à toutes les fonctionnalités produit ? - Justification : Chaque fonctionnalité mise en oeuvre doit disposer d'une prise en compte du NR pour que l'ensemble du service soit conçu avec le respect le plus complet des principes NR, un aspect non couvert pouvant annuler tout ou partie des bénéfices acquis par ailleurs. Il est plus efficace d'avoir un traitement équilibré sur l'ensemble, plutôt que viser l'excellence sur une partie et laisser des trous conséquents sur d'autres. - Tests : Le produit est-il validé comme nécessaire par rapport à son impact environnemental ? - Cas d’usage : Des Tags/Labels NR sont utilisés pour identifier tous les aspects NR pris en compte dans le Backlog - Niveau : A/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-chaque-fonctionnalite-mise-en-oeuvre-doit-disposer-2f9406 #### Recommandation n°22 - Critère : Chaque fonction principale ou secondaire du service est-elle appréhendée en regard de son importance dans le service ? - Justification : La cohérence NR pousse à s'assurer que les fonctions secondaires n'ont pas un impact environnemental plus important que les fonctions principales. Les spécifications doivent clairement identifier les fonctions principales et secondaires et leurs impacts du point de vue NR. - Tests : Les règles de validation des impacts NR des fonctions sont-elles décrites ? - Cas d’usage : Analyse d'impact - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-la-coherence-nr-pousse-a-sassurer-que-a5c08d #### Recommandation n°23 - Critère : Toutes les exigences projet (performance, sécurité, accessibilité, NR) sont-elles associées à chaque fonctionnalité ? - Justification : Le panorama complet des exigences non fonctionnelles (Sécurité, Accessibilité, NR) permet de faciliter les arbitrages et de déterminer l'axe qui sera choisi lorsque des éléments présentent des conflits. Le conflit est difficilement traitable localement, seule la vision globale permettra de garantir que l'équilibre est respecté sur l'ensemble du projet. - Tests : Les règles de priorité sont-elles définies et arbitrées en cas de conflit ? ; La priorité est-elle donnée au NR s'il ne remet pas en cause la sécurité ? - Cas d’usage : Backlog - Tag/Label NR - Niveau : B/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-le-panorama-complet-des-exigences-non-fonctionnelles-123b09 #### Recommandation n°24 - Critère : Les cas d'exclusion de chaque fonctionnalité sont-ils adressés et des alternatives proposées ? - Justification : Certaines fonctionnalités non retenues peuvent néanmoins avoir un intérêt et pousser à trouver des alternatives de remplacement. Ces solutions intermédiaires respectent les mêmes processus projet en terme de NR. - Tests : Les coûts et bénéfices des alternatives sont-ils évalués ? - Cas d’usage : Analyse d'impact - Niveau : B/A/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-certaines-fonctionnalites-non-retenues-peuvent-neanmoins-avoir-3b2c94 #### Conseil n°25 - Critère : La nécessité d'une fonctionnalité est-elle validée en rapport avec son impact NR ? - Justification : La sélection des fonctionnalités spécifiées jugées indispensables peut être remis en cause dans sa forme initiale par rapport aux impacts NR. Dans ce cas les coûts / bénéfices devront prendre en compte ces oppositions et faire l'objet d'une adaptation pour faire converger les 2 approches : nécessité fonctionnelle et impact NR. - Tests : L'arbitrage entre les gains NR et les coûts du projets sont-ils clairement identifiés ? - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-la-selection-des-fonctionnalites-specifiees-jugees-indispensables-42737d #### Recommandation n°26 - Critère : Quelles alternatives sont proposées pour traiter une fonctionnalité non retenue ? - Justification : Des solutions alternatives peuvent être déployées sachant qu'elles ne sont pas les plus efficaces d'un point de vue NR mais apportent une première étape plus efficace par rapport à la solution n'incluant aucune considération NR. Ces pistes alternatives doivent être transitoires et faire l'objet de planification de revue afin d'augmenter graduellement leur conformité NR. - Tests : Chaque fonctionnalité retirée a-t-elle une alternative disponible, si la fonctionnalité est utile ? - Cas d’usage : Analyse d'impact - Niveau : B/A/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-des-solutions-alternatives-peuvent-etre-deployees-sachant-7b2561 #### Conseil n°27 - Critère : Les orientations du service ne sont-elles pas basées sur les effets d'addiction artificiels ? - Justification : La sur-consommation des usages du service implique la création d'une dépendance de l'utilisateur vis à vis du service, et augmente artificiellement les charges d'utilisation du service, donc l'impact environnemental. Ces effets d'addiction sont dommageables pour le respect des principes NR. - Tests : La matrice d'évaluation de captologie est-elle appliquée ? - Niveau : C/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-la-sur-consommation-des-usages-du-service-implique-448826 #### Conseil n°28 - Critère : Les interfaces utilisateurs et techniques sont-elles conçues pour être efficaces du point de vue NR ? - Justification : Le lien entre l'utilisateur et le service peut générer des parcours complexes, longs, avec des volumes de saisie ou d'informations présentées très élevés. Si la gestion des interfaces est efficace pour l'utilisateur, elle sera le plus souvent aussi efficace du point de vue NR - Tests : Le coût NR des interfaces est-il évalué ? - Niveau : B/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-le-lien-entre-lutilisateur-et-le-service-f92306 #### Recommandation n°29 - Critère : Les aspects réglementaires de l'accessibilité sont-ils pris en compte ? - Justification : Le non-respect des réglementations est tout d'abord illégal et peut entraîner des pénalités importantes. Il coupe aussi des utilisateurs, même hors du cadre du handicap, de l'accès au service. - Tests : Est-ce que la conformité au RGAA est garantie ? - Cas d’usage : Analyse de risques - Niveau : C/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-le-non-respect-des-reglementations-est-tout-dabord-0ba282 #### Recommandation n°30 - Critère : Le service est-il conforme au RGPD ? - Justification : Lors des spécifications, si de nouvelles collections de données sont prévues, elles doivent systématiquement faire l'objet d'une évaluation pour les données à caractère personnelle, être associé au registre de traitement et au PIA, en lien avec le DPO. Les aspects de confiance et respect des utilisateurs est l'une des dimensions du NR. - Tests : Les documents RGPD du projet sont-ils réalisés et validés par le DPO ? - Cas d’usage : Documentation : Informations légales - Niveau : C/B/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-lors-des-specifications-si-de-nouvelles-collections-8a525c #### Recommandation n°31 - Critère : La sécurité est-elle adaptée à la valeur de mes données ? - Justification : La sécurisation des données nécessite souvent des éléments redondants, des méthodes de sauvegardes et de duplications qui génèrent une empreinte environnementale supplémentaire. Certaines catégories de données justifient pleinement ces dispositions, mais pour d'autres l'extrême sécurisation n'a pas de sens, si ce n'est la facilité de traiter de la même manière toutes les informations. Le niveau de sécurisation, à partir du moment où il présente un surcoût environnemental, doit être en rapport avec la donnée. - Tests : Les règles de sécurité sont-elles associées à des audits réguliers ? - Cas d’usage : Analyse de risques - Niveau : C/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-la-securisation-des-donnees-necessite-souvent-des-a6070c #### Conseil n°32 - Critère : Les solutions techniques retenues sont-elles pilotées par l'usage plutôt que par l'intérêt technique ? - Justification : Les fonctions techniques ont souvent besoin d'exprimer leurs compétences et leur suivi des avancées technologiques en choisissant les solutions les plus récentes et définies dans leur écosystème comme les plus avancées. Cela pousse à faire des choix d'implémentation guidés par l'attrait technologique plutôt que par l'efficacité notamment NR. Réorienter les pratiques techniques sur les défis NR est une bonne pratique pour conserver l'intérêt technique des professionnels et leur permettre de progresser avec des résultats concrets. - Tests : Toutes les technologies utilisées ont-elles une justification validée et partagée ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-les-fonctions-techniques-ont-souvent-besoin-dexprimer-2e42a3 #### Recommandation n°33 - Critère : L'évaluation de la valeur fonctionnelle de chaque interaction utilisateur est-elle réalisée ? - Justification : Chaque fois que l'utilisateur interagit avec le service, un nombre important de mécanismes "invisibles" se déclenchent. Chacun de ces éléments, en s'exécutant, consomme des ressources. Pour réduire cette consommation, outre les principes d'optimisation des algorithmes, il est plus utile et souvent plus facile de limiter le nombre de ces interactions. - Tests : Est-ce que la fonctionnalité est indispensable ? ; Une analyse MoSCoW a-t-elle été réalisée (Must/Should/Could/Would) ? - Cas d’usage : Definition of Done - Niveau : B/A/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-chaque-fois-que-lutilisateur-interagit-avec-le-21d581 #### Recommandation n°34 - Critère : L'impact de la couverture de la fonctionnalité peut-elle être réduite par la solution technique envisagée ? - Justification : Certaines fonctionnalités sont nativement offertes par des composants techniques, mais ces composants ne se limitent que très rarement au seul périmètre recherché et fournissent beaucoup d'autres fonctionnalités qui peuvent ne pas être utiles. Le fait de pouvoir réduire un composant technique aux seuls apports réellement utiles est un bénéfice NR important. - Tests : Les technologies alternatives ont-elles été testées ? ; Est-ce que la solution technique envisagée pour couvrir la fonctionnalité peut être réduite ? - Cas d’usage : L'analyse d'impact détermne les actions de réduction des impacts avec les acteurs concernés - Niveau : A/A/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-specifications-certaines-fonctionnalites-sont-nativement-offertes-par-des-82d268 ### Recommandation n°5 — Préparer le suivi du cycle de vie du projet et des indicateurs de performance / bénéfice NR #### Recommandation n°35 - Critère : Avez-vous identifié des indicateurs de performance pour le suivi du cycle de vie ? - Justification : Les indicateurs NR universels ne sont pas vraiment disponibles, cela peut pousser à passer énormément d'énergie et de ressources à définir les meilleurs indicateurs. Ce qui représente une surcharge dans le projet qui peut conduire à une remise en cause du traitement des impacts NR dans les projets. Il serait dommage que la crédibilité des bénéfices NR soient dégradés par la recherche de points de mesure. La fiabilité d'un indicateur est dicté par la fiabilité de la donnée qui permet de le calculer, il vaut mieux démarrer avec des indicateurs sans doute moins ambitieux mais justes et peu onéreux en terme de charge projet. - Tests : Quels indicateurs sont mis en place, et comment les données sur lesquels ces indicateurs sont basés sont-elles fiabilisées ? - Cas d’usage : Analyse de bénéfices - Niveau : B/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-les-indicateurs-nr-universels-ne-sont-pas-fd3864 #### Recommandation n°36 - Critère : Dans le processus d'achat (Appel d'offre) des exigences d'engagement NR sont-elles demandées aux prestataires externes ? - Justification : Un projet est rarement réalisé avec un périmètre couvert à 100% au sein de l'organisation, nombre de ressources externes sont mobilisées au cours du projet. Les spécifications permettent d'identifier ces ressources nécessaires et leur associer des exigences NR pour permettre de sélectionner les prestataires en fonctions des contraintes techniques, de solvabilité économique et de NR. - Tests : Les exigences NR des prestataires sont-elles définies ? - Cas d’usage : Les procédures d'achat contiennent des éléments de sélection liées aux enjeux NR - Niveau : B/C/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-un-projet-est-rarement-realise-avec-un-601806 #### Recommandation n°37 - Critère : La gestion des impacts des mises à jour logicielles sur la mise en obsolescence des matériels est-elle évaluée ? - Justification : Dans un développement itératif et tout au long de la vie du service des mises à jour seront appliquées. Chacune de ces adaptations doit permettre de continuer à utiliser les matériels actuels et ne pas ajouter de contraintes artificielles qui amèneraient à saturer les capacités de traitement des terminaux utilisateurs, ni introduire de mise à jour technique qui génèrerait une incompatibilité, nécessiterait / pousserait à un renouvellement des équipements. - Tests : Les impacts sur les composants matériels des mises à jour logicielles sont-ils tracés ? ; Est-ce que la mise à jour du logiciel entraîne une obsolescence de certains matériels pour l'utilisation du logiciel, au regard du cycle de vie du service estimé au lancement du projet ? - Cas d’usage : Analyse d'impact - Niveau : B/B/B - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-dans-un-developpement-iteratif-et-tout-au-60279f #### Recommandation n°38 - Critère : Les équipements actuels des utilisateurs sont-ils évalués ? - Justification : Les spécifications doivent définir les gammes de terminaux que le service doit supporter afin que les utilisateurs avec des périphériques plus anciens puissent accéder au service dans les meilleures conditions. Les incompatibilités matérielles sont une source de souhaits / impératifs de renouvellement de terminaux avant que celui-ci ne soit réellement hors d'usage. Le NR participe à prolonger la durée de vie des équipements. - Tests : La plage des équipements utilisateurs valide est-elle disponible ? ; Les utilisateurs peuvent-ils accéder au produit avec leur équipement actuel ? Des solutions de replis sont-elles décrites ? - Cas d’usage : Fiche de cadrage - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-les-specifications-doivent-definir-les-gammes-de-1808b8 #### Recommandation n°39 - Critère : Les revues de projet prennent-elles en compte les validations des exigences NR ? - Justification : Le cadrage et la phase de spécification prévoient des livraisons intermédiaires, sous forme de POC, de MVP, de BETA. Chacune de ces livraisons intermédiaires est une occasion de revoir et valider la couverture des exigences NR - Tests : Le processus d'arbitrage des conflits est-il partagé par tous les acteurs ? ; Quelle est la fréquence de revue ? - Cas d’usage : Definition of Done - Niveau : B/A/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-le-cadrage-et-la-phase-de-specification-f5e3b8 #### Recommandation n°40 - Critère : Lors de chaque nouvelle mise en production, une revue du respect des enjeux NR est-elle effectuée ? - Justification : La mise en production ne doit pas être considérée comme l'étape ultime de la vie d'un projet dans le respect des principes NR. Cette opération de mise en production permet de statuer sur les engagements NR définis et remplis au cours du projet et de valider que ces éléments seront suivis pendant toute la phase active du service, et pris en compte lors du retrait du service en fin de vie. - Tests : Les anomalies de revues sont-elles consignées et réutilisées ? - Cas d’usage : Definition of Done - Niveau : B/B/B - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-la-mise-en-production-ne-doit-pas-704c0f #### Recommandation n°41 - Critère : Les données et procédures spécifiées ont-elles toutes une information de fin de vie ? - Justification : Les spécifications font apparaître des collections de données des procédures asynchrones ou des tâches périodiques indispensables au bon fonctionnement du service. Ces éléments sont le plus souvent invisibles et en l'absence de spécifications explicites des processus de retrait ils sont rarement pris en compte dans les fins d'exploitation d'un service. Chacun de ces éléments doit porter sa propre information de fin de vie. - Tests : La catalogue des procédures et données est-il à jour ? - Cas d’usage : Chaque élément référencé dans le Dossier Technique porte une information de fin de vie - Niveau : A/B/A - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-les-specifications-font-apparaitre-des-collections-de-4e3c40 #### Recommandation n°42 - Critère : Est-ce que le produit cible à une durée de vie déterminée ? - Justification : Les services répondent à une opportunité et sont créés pour traiter cette demande. Dans un environnement technique et économique très mouvant et imprévisible, ils ont rarement une espérance de vie infinie. Il est utile d'un point de vue NR de décider en préalable du terme de l'exploitation du service pour éviter qu'il ne subsiste ad vitam aeternam alors que l'objet du service n'existe plus. - Tests : Le produit a t'il une "date d'expiration" ? - Cas d’usage : La fiche de cadrage projet fait apparaitre explicitement la durée de vie estimée du service. - Niveau : A/B/A - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-les-services-repondent-a-une-opportunite-et-e5cb28 #### Conseil n°43 - Critère : Les charges, bénéfices, risques sont-ils suivis ? - Justification : La mise en production d'un service respectant les principes NR est un atout important pour une organisation. Pour l'ensemble des parties-prenantes, le bilan de la conduite du projet et du traitement des enjeux NR est un moyen supplémentaire de capitaliser sur les bénéfices de l'opération et d'évaluer sereinement les risques et charges pris en compte dans le projet afin de faciliter les prises en compte NR dans les futurs projets. - Tests : Est-ce qu'une rétrospective est prévue pour évaluer les gains environnementaux ? - Niveau : C/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-la-mise-en-production-dun-service-respectant-245f7b #### Conseil n°44 - Critère : Un plan de suivi des risques est-il déployé ? - Justification : Certains choix techniques sont orientés par l'angle NR, et des adaptations techniques sont réalisées pour plus de conformité NR. Cela peut introduire des risques supplémentaires (délais, difficultés, anomalies). Ces risques doivent être suivis et le plan de traitement des risques doit prendre en considération ces éléments associés aux choix NR. - Tests : Le plan de suivi des risques intègre-t-il le NR ? ; Est-ce que les choix techniques faits pour le NR ont introduit des risques supplémentaires ? - Niveau : B/B/A - Cycle de vie : Déploiement - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-certains-choix-techniques-sont-orientes-par-langle-4542cc #### Conseil n°45 - Critère : Un gain de notoriété et de capitalisation est-il associé aux aspects NR du projet ? - Justification : La conduite d'un projet NR a un retentissement au delà des sphères techniques et métiers du projet, pouvant permettre à l'organisation d'afficher une affinité forte avec les contraintes environnementales qui est valorisable dans les opérations de communications institutionnelles ou informelles. Ces éléments peuvent être chiffrés dans les budgets projet. - Tests : Les bénéfices non financiers sont-ils évalués ? ; Les équipes bénéficient-elles d'une montée en compétence sur les sujets NR ? - Niveau : C/C/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-la-conduite-dun-projet-nr-a-un-913cac #### Recommandation n°46 - Critère : Les fonctions secondaires ont-elles aussi un impact moindre sur l'impact environnemental ? - Justification : 80% des usages sont traités par 20% des fonctionnalités. Sans être une règle immuable, c'est très souvent le cas. Il ne faut pas tomber dans le travers ou les 20% d'usages marginaux consomment 80% des impacts environnementaux du projet. - Tests : Les impacts environnementaux de chaque fonctionnalité sont-ils évalués par rapport à la nature et l'importance de la fonctionnalité ? - Cas d’usage : CHROME : Console dev/Network - Niveau : B/C/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=5-specifications-80%25-des-usages-sont-traites-par-20%25-7ffa3c ### Recommandation n°6 — Déterminer l'environnement de production dans lequel le projet sera construit et déployé en accord avec les principes NR #### Recommandation n°47 - Critère : Les fournisseurs de solutions et prestataires de service sont-ils sélectionnés sur leur capacité à respecter un cahier des charges NR ? - Justification : Les spécifications mettent en évidence des besoins de prestations externalisées ou des relations avec des fournisseurs de services. Dans les règles de sélection des fournisseurs de services ou de produits externes, les aspects NR doivent être pris en compte de la même manière que si le service ou produit était pris en charge en interne. Le cahier des charges doit exposer en plus des considérations techniques, budgétaires et de respect des normes de sécurité les principes NR que le fournisseur doit remplir. - Tests : Les indicateurs NR des fournisseurs sont-ils pris en compte lors de la sélection des prestataires ? - Cas d’usage : Procédures d'achat - Niveau : B/C/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=6-specifications-les-specifications-mettent-en-evidence-des-besoins-2fbb46 #### Conseil n°48 - Critère : Les aspects déplacements physiques sont-ils évalués lors de la sélection de prestataires, des solutions techniques et de l'organisation des acteurs internes intervenant sur le projet ? - Justification : L'impact environnemental des déplacements physiques est très visible et facilement estimable. Lors des interactions avec des partenaires, la distance, le nombre des déplacements doit être évalué et restreint. La définition d'un budget déplacement pour l'ensemble du projet peut apporter plus de contrôle sur cet aspect et promouvoir chaque fois que cela est possible des points distanciels plutôt que présentiels. - Tests : Quel budget de déplacement physique est alloué au projet ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=6-specifications-limpact-environnemental-des-deplacements-physiques-est-tres-934e49 #### Conseil n°49 - Critère : Les intervenants des prestataires disposent-ils tous des mêmes bénéfices sociaux et conditions de travail ? - Justification : Dans les dimensions NR les aspects humains et économiques occupent une place importante. S'assurer que tous les intervenants y compris chez les prestataires (et ses propres sous-traitants et fournisseurs) utilisés pour le projet disposent des mêmes cadres socio-économiques est nécessaire pour que la cohérence des efforts NR ne soit pas anéantie par un choix qui aurait pu être évité. - Tests : Le prestataire utilise-t-il des ressources humaines hors du territoire national ou avec des contrats spécifiques ? - Niveau : C/A/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=6-specifications-dans-les-dimensions-nr-les-aspects-humains-8c1074 #### Recommandation n°50 - Critère : Est-ce que les postes de travail font l'objet d'une gestion de cycle de vie ? - Justification : Chacun des acteurs internes va mobiliser des équipements techniques pour gérer et développer le projet. Les postes de travail de l'ensemble de l'équipe sont un point relativement simple à adresser du point de vue NR. Avec le suivi du cycle de vie des équipements, l'utilisation de matériels avec labels environnementaux, le pilotage des alimentations électriques du poste de travail en fonction de la présence / absence au poste. - Tests : Les postes de travail de développement et d'intégration/tests sont-ils choisis et suivis vis-à-vis de leurs impacts environnementaux ? - Cas d’usage : Une gestion de configuration couvre l'ensemble des équipements des postes de travail avec consolidation des indicateurs de cycle de vie - Niveau : A/C/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-specifications-chacun-des-acteurs-internes-va-mobiliser-des-bd2f5f #### Recommandation n°51 - Critère : Un espace commun a-t-il été mis à disposition du projet pour le partage des ressources ? - Justification : Lors du suivi projet beaucoup de documents sont produits, revues, validés. La duplication de documents, les transferts vers des destinataires multiples est une source de consommation excessive de ressources. Le plus souvent l'utilisation d'un espace partagé avec la mise en place de règles d'accès permet d'éviter ces impacts environnementaux. - Tests : Les documents de travail n'existe-t-il qu'en un seul exemplaire partagé par tous les intéressés ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-specifications-lors-du-suivi-projet-beaucoup-de-documents-7a17c7 #### Recommandation n°52 - Critère : Est-ce que les ressources/composants disponibles pour le projet ont une information concernant la conformité NR ? - Justification : Les développements modulaires sont mis en place dans les projets pour faciliter la réutilisation et permettre d'assembler des composants validés ce qui se traduit par des gains d'efficacité et de fiabilité. Cette pratique est basée sur les descriptions des interfaces (entrées-sorties) de ces composants, de leurs cadres d'utilisation et de leurs dépendances. En plus de ces éléments techniques les aspects et bénéfices NR implémentés dans le composant sont utiles pour capitaliser en plus des aspects techniques sur les aspects NR. - Tests : Chaque composant développé dispose-t-il d'une note d'impact NR ? - Cas d’usage : Dossier technique - Niveau : B/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=6-specifications-les-developpements-modulaires-sont-mis-en-place-98c2da #### Recommandation n°53 - Critère : Dans les ressources techniques du projet est-ce que les gestions de dépendances sont prises en compte, pour limiter l'obésité des solutions techniques employées ? - Justification : La majorité des projets est une suite d'intégration de composants avec des développements d'interfaces spécifiques entre ces composants. Bien souvent les composants issus de bibliothèques publiques (open source ou commerciales) apportent un ensemble de fonctionnalités qui ne sont que rarement toutes utilisées et drainent des dépendances vis-à-vis d'autres composants avec les mêmes caractéristiques. Au final le projet agrège un volume de bibliothèque important alors qu'une petite partie est réellement utilisée. Privilégier les composants dont les dépendances et fonctionnalités sont pilotables par rapport aux besoins est efficace du point de vue NR. - Tests : Un outil de suivi des dépendances de composants est-il employé ? - Cas d’usage : CHROME : Console dev / COVERAGE - Niveau : B/C/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=6-specifications-la-majorite-des-projets-est-une-suite-25a8a5 #### Conseil n°54 - Critère : Dans les choix de conceptions (fonctionnelles et techniques), est-ce que la création, la mise à jour ou la fin de vie d'un domaine du service numérique a un impact réduit sur les autres domaines du service numérique ? - Justification : Les spécifications du projet peuvent s'appuyer sur des éléments déjà employés pour d'autres services. Ces dépendances entre services sont efficaces d'un point de vue gestion du projet mais peuvent être pénalisantes lorsqu'elles imposent le maintien de composants partagés moins efficaces d'un point de vue NR, surtout lorsque les services utilisant ces ressources sont destinés à être arrêtés à des périodes différentes. - Tests : La publication des interfaces entre les composants est-elle systématique ? - Niveau : C/C/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=6-specifications-les-specifications-du-projet-peuvent-sappuyer-sur-670a0f #### Conseil n°55 - Critère : L'implémentation de nouveaux services sous contraintes réglementaires (santé, bancaire, ...) sont-ils nécessaires et le cas échéant s'appuient-ils sur un socle de service disponible ? - Justification : La pratique des professionnels utilisant des données réglementées est guidé par la sécurité des données et par la réduction de l'impact d'utilisation du service pour rester centré sur l'enjeu principal. Les spécifications doivent prendre en compte ces éléments et réutiliser le maximum d'éléments habituels de ces types de services consolidés sous forme d'un socle de service. - Tests : Combien de données réglementées (santé, bancaire, ...) sont nécessaires ? ; Le socle de service est-il évalué par rapport à sa conformité réglementaire (certification) et utilisabilité (accessibilité, sécurité) ? - Niveau : C/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=6-specifications-la-pratique-des-professionnels-utilisant-des-donnees-6d1a2b #### Recommandation n°56 - Critère : Quels sont les KPIs définis ? - Justification : Les métiers et le management ont l'habitude de piloter l'activité avec une gamme d'indicateurs business. Le suivi de la performance NR va aussi nécessiter des indicateurs dédiés pour suivre les impacts. Pour la détermination des indicateurs, des plages de valeurs de performance doivent être définis de manière itérative et suivre l'augmentation de maturité de l'organisation dans l'appréhension de ces données afin que les processus de décisions puissent se mettre en place pour effectuer un pilotage des aspects NR. - Tests : Les plages de valeurs des KPIs sont-elles définies ? - Cas d’usage : Analyse de bénéfices - Niveau : B/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=6-specifications-les-metiers-et-le-management-ont-lhabitude-c6c9b0 ## Famille : Stratégie L'étape de stratégie projet permet de déterminer la pertinence et les enjeux du projet. ### Recommandation n°1 — Définir et valider les besoins et les enjeux du projet afin d'anticiper les impacts #### Recommandation n°1 - Critère : Les réunions sont-elles limitées au strict minimum, en privilégiant le distanciel, lorsque les réunions nécessitent des déplacements physiques ? - Justification : Les trajets sont sources d'émissions de Gaz à Effet de Serre (GES) et ont un impact sur l'organisation personnelle des collaborateurs. - Tests : Les outils existent-ils dans l'entreprise pour permettre les réunions en distanciel dans de bonnes conditions ? ; Toutes les réunions prévues sont-elles utiles ? - Cas d’usage : La fiche de cadrage projet défini les réunions et les distances de déplacements de tous les participants - Niveau : A/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-les-trajets-sont-sources-demissions-de-gaz-14f6be #### Recommandation n°2 - Critère : Le télétravail est-il autorisé, sans limites, aux collaborateurs qui le souhaitent et dont l'activité le permet ? - Justification : Outre la limitation des transports quotidiens et leurs impacts environnementaux, les temps perdus lors des trajets peuvent être considérables. Les outils et l'organisation doivent permettre en revanche de lutter contre la rupture de lien social qui peut s'installer avec le télétravail. - Tests : L'entreprise offre-t-elle un cadre au télétravail ? ; L'organisation du projet permet-elle aux collaborateurs qui le souhaitent et dont le métier le permet de télétravailler, selon un rythme choisi par chaque collaborateur ? - Cas d’usage : La stratégie RH précise les conditions et modalités du télétravail - Niveau : A/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-outre-la-limitation-des-transports-quotidiens-et-185d46 #### Conseil n°3 - Critère : L'entreprise est-elle ouverte à une démarche NR qui pourrait fédérer les énergies autour d'un projet novateur ? - Justification : Pour être efficace, la démarche NR doit être présente dans la stratégie de l'organisation et associer l'ensemble des processus de décision dans l'objectif de réduire les impacts des services numériques. - Tests : Les managers ont-ils les mains libres pour initier la démarche NR dans les projets ? - Niveau : B/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-pour-etre-efficace-la-demarche-nr-doit-235200 #### Conseil n°4 - Critère : Est-ce que les stratégies RSE et NR sont associées et systématiquement mises en oeuvre dans tous les projets ? - Justification : Le traitement NR est une démarche systémique si la stratégie NR est prise en compte dans tous les projets. Comme c'est le plus souvent le cas pour la RSE le gain est beaucoup plus significatif que lorsque les éléments NR sont traités ponctuellement - Tests : Quelle proportion des projets embarquent des exigences NR ? ; Quelle est l'objectif de proportion de projets avec des exigences NR ? A quelle échéance ? - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-le-traitement-nr-est-une-demarche-systemique-baa729 #### Recommandation n°5 - Critère : Comment faire du NR plus qu'un objectif de communication ? - Justification : Les énergies et budgets dépensés pour les aspects purement communication (greenwashing) peuvent être conséquents pour aucun résultat tangible. Avec les mêmes investissements il est tout à fait possible d'obtenir des résultats significatifs sur lesquels la communication sera de plus, plus efficace. - Tests : Les exigences NR sont-elles prises en compte par toutes les équipes projets ? - Cas d’usage : Stratégie RSE / NR - schéma directeur - Niveau : B/A/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-les-energies-et-budgets-depenses-pour-les-3ea9b6 #### Recommandation n°6 - Critère : Le besoin métier est-il exprimé ? - Justification : Les incertitudes poussent à extrapoler les besoins souvent au delà des attentes réelles ce qui est nuisible pour les impacts environnementaux - Tests : Les besoins métiers sont-ils évalués de manière impartiale par rapport à des usages ? - Cas d’usage : La documentation de collecte et expression des besoins est formalisée, validée et partagée - Niveau : B/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-les-incertitudes-poussent-a-extrapoler-les-besoins-fed8e2 #### Recommandation n°7 - Critère : La cible des utilisateurs (principale et secondaire) est-elle définie, pour préciser le besoin métier ? - Justification : Pour répondre justement (ni trop, ni trop peu) aux attentes utilisateurs, il est indispensable de connaître les cibles et leurs comportements., afin de ne pas surcharger les applicatifs, ni les appauvrir au point qu'ils ne répondent plus aux attentes légitimes. Les utilisateurs secondaires ont des besoins souvent plus simples. Sans l'identification de cette catégorie d'utilisateur, il est difficile de dimensionner correctement le service. - Tests : Les profils utilisateurs sont-ils décrits avec les USE CASE correspondant ? - Cas d’usage : Fiche de cadrage projet - Niveau : B/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-pour-repondre-justement--aux-attentes-utilisateurs-c91c9f #### Recommandation n°8 - Critère : Les matériels utilisateurs sont-ils identifiés ? - Justification : Certaines utilisations peuvent être contraintes par les équipements des utilisateurs, pour permettre un choix plus large d'équipements même anciens et limiter les renouvellements de matériels. Il est important de connaître les profils de matériel que les utilisateurs vont pouvoir employer, aujourd'hui et demain. - Tests : Chaque USE CASE est-il associé à la liste des équipements matériels nécessaires à sa mise en oeuvre ? - Cas d’usage : Dossier Technique - Niveau : B/C/C - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-certaines-utilisations-peuvent-etre-contraintes-par-les-9ebfb2 #### Recommandation n°9 - Critère : L’ensemble des produits et services sont-ils indispensables en ligne ? - Justification : Certaines fonctionnalités sont proposées en mode connecté alors qu'aucune donnée distante ou aucun processus de calcul lourd n'est requis, dans ces cas une solution locale (hors ligne) est efficace d'un point de vue environnemental avec moins de circulation d'information et moins d'utilisation des réseaux. En revanche, si le mode hors ligne nécessite des duplications d'informations, il ne se justifie que si les accès réseaux sont intermittents et posent des difficultés d'utilisation du service. - Tests : Le produit/service peut-il être envisagé sans être déployé en ligne, avec un résultat similaire pour l'entreprise ? - Cas d’usage : La fiche de cadrage projet précise les produits et services associés et leurs modes d'opération (en ligne, en personne, ...) - Niveau : A/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-certaines-fonctionnalites-sont-proposees-en-mode-connecte-67a9c3 #### Recommandation n°10 - Critère : Est ce que je peux proposer de couvrir les besoins autrement, en évitant le digital avec un moyen plus respectueux de l’environnement ? - Justification : Certains processus manuels simples peuvent être une alternative au tout numérique, même au sein d'un service numérique. Dans le cadre d'un service numérique la tendance naturelle est d'y intégrer toutes les étapes sans se poser la question de l'efficacité environnementale. - Tests : Le produit/service peut-il être envisagé sans être numérique, avec un résultat similaire pour l'entreprise ? - Cas d’usage : La fiche de cadrage projet précise pour chaque besoin une évaluation d'impact - Niveau : A/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-certains-processus-manuels-simples-peuvent-etre-une-5ccb15 #### Recommandation n°11 - Critère : La solution retenue est-elle la plus respectueuse de l'environnement ? - Justification : Le nouveau service peut apporter une meilleure efficacité environnementale, mais il peut aussi participer à la création de dette environnementale supplémentaire, l'ensemble des 3 dimensions (3P) doivent pouvoir montrer un bénéfice sinon le positionnement du service peut être à revoir. - Tests : Avez-vous exprimé des scénarios alternatifs et évalué l'impact NR de chacun ? ; Le choix final est-il guidé par la performance NR ? - Cas d’usage : Une analyse d'impact est définie pour permettre d'arbitrer les impacts vis à vis de la couverture des besoins - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-le-nouveau-service-peut-apporter-une-meilleure-43029b #### Conseil n°12 - Critère : Le modèle économique de ce service prend-il en compte l'éco-conception ? - Justification : Lorsque le NR est en dehors du modèle économique il est difficile de concilier l'activité économique et les impacts du NR, et cela tourne le plus souvent à des arbitrages où la prosperityabilité immédiate est privilégiée face aux 3P - Tests : Est-ce que l'adaptation du modèle économique est envisagée pour prendre en compte l'éco-conception? - Niveau : A/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-lorsque-le-nr-est-en-dehors-du-d650e9 #### Conseil n°13 - Critère : Les aspects performances, accessibilité, sécurité et sobriété sont-ils pris en compte ensemble ? - Justification : Dans la majorité des cas, une meilleure performance technique est aussi synonyme d'une meilleure efficacité environnementale, la consommation de ressources de calcul est plus faible, les volumes de transferts sont plus restreints, les algorithmes sont plus efficaces. - Tests : Quelles règles de décision sont précisées pour optimiser mon service numérique en mixant sobriété et performance ? - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-dans-la-majorite-des-cas-une-meilleure-e66861 #### Recommandation n°14 - Critère : Les gains NR sont-ils évalués en préalable du projet ? - Justification : Dans le cas de refonte de services, il est plus simple d'estimer les gains attendus par le nouveau service en référence au service actuel. Pour un service nouveau, l'étude préalable déterminera des hypothèses de gains qui devront être affinées au cours du projet. L'affichage des gains attendus est un marqueur important pour convaincre l'ensemble des acteurs du bien fondé de la démarche - Tests : Avez-vous chiffré le bénéfice environnemental du projet en faisant de l’éco-conception ou en décidant d'éviter le numérique ? - Cas d’usage : Analyse d'impact - Niveau : B/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-dans-le-cas-de-refonte-de-services-b2f535 #### Conseil n°15 - Critère : Le NR est-il inscrit dans la stratégie et les objectifs de l'organisation ? - Justification : Afin de pouvoir installer une démarche NR dans les projets, il est indispensable que tous les décideurs adhèrent à cette démarche, c'est nécessairement le cas si le NR est inscrit dans la stratégie de l'organisation. Dans le cas contraire, il sera difficile de mener une démarche NR, car en permanence il faudra trouver des justifications pour convaincre de poursuivre. Le projet en serait impacté donc perçu comme moins efficace "à cause du NR" - Tests : Est-ce que l'ensemble des instances de décision sont partantes pour développer un service numérique éco-conçu dans votre organisation à ce moment-là ? La solidité financière de l'organisation permet-elle d'innover ? - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-afin-de-pouvoir-installer-une-demarche-nr-c29e79 #### Conseil n°16 - Critère : L'attente du marché, clients, fournisseurs, partenaires est-elle en phase avec une démarche NR ? - Justification : Les différents secteurs d'activité présentent des sensibilités variables face au NR, et à périmètre identique certaines organisations ou catégories de parties prenantes ont des aspirations variables. Le fait de s'engager dans une démarche NR et de l'exposer est plus simple si cela correspond à une préoccupation des acteurs concernés. La communication et l'expression de la démarche NR sera quelque peu différente en fonction de la maturité du marché cible. - Tests : Avez-vous réalisé une étude de marché pour valider les attentes des parties prenantes vis à vis du NR ? ; Avez-vous anticipé l'évolution de ces attentes, pour proposer un service NR même si les demandes ne sont pas complètement formalisées au début du projet, mais évoluent au cours de la vie du service ? - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-les-differents-secteurs-dactivite-presentent-des-sensibilites-027ea9 #### Conseil n°17 - Critère : Les enjeux et bénéfices attendus sont-ils bien identifiés ? - Justification : Pour capitaliser sur l'innovation apportée par la prise en compte du NR il est important de déterminer les bénéfices de la démarche, que ce soit d'un point de vue financier, ou d'avantage compétitif ou de notoriété ou de capacité de communication et reconnaissance d'être un acteur engagé pour réduire les impacts du numérique. - Tests : Avez-vous chiffré les gains financiers (réduction des coûts, augmentation CA) et non financiers (communication, environnement, innovation, se différencier de la concurrence) ? - Niveau : B/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-pour-capitaliser-sur-linnovation-apportee-par-la-a7d5e9 #### Conseil n°18 - Critère : L'organisation est-elle en mesure de faire progresser son niveau de maturité vis à vis de l’éco conception et de son périmètre, avec la réalisation de projets NR ? - Justification : La démarche NR doit être présente dans toutes les étapes de réalisation et cela passe nécessairement par une culture NR au sein de l'organisation. La maturité augmentera progressivement avec les pratiques. - Tests : Quelle proportion des acteurs du projet est sensibilisée ou formée au NR ? ; Les processus, outils et méthodes utilisés ont-ils été adaptés pour prendre en compte les enjeux NR ? - Niveau : B/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-la-demarche-nr-doit-etre-presente-dans-c24c86 #### Conseil n°19 - Critère : Un audit de l'existant est-il disponible pour en améliorer les performances NR ? - Justification : Les principaux travers d'un service existant par rapport aux 3P peut utilement servir de socle pour déterminer les axes de performance NR à améliorer avec des quick wins et des adaptations plus profondes. - Tests : Avez-vous besoin de réaliser un audit de l’existant afin d'améliorer le projet ou devez-vous repartir à zéro ? - Niveau : B/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-les-principaux-travers-dun-service-existant-par-e8a4a9 #### Recommandation n°20 - Critère : Les budgets financiers pour les aspects NR du projet sont-ils évalués ? - Justification : Le NR va générer une nouvelle catégorie d'exigences qui devront être prises en compte dans les démarches projet, et demanderont des lignes budgétaires clairement identifiées. Bien que souvent les projets NR soient plus efficaces, moins "boulimiques" de technologies "à la mode" et de fonctionnalités inutiles, les charges projet en final sont diminuées. - Tests : Est ce que j’ai les moyens matériels ? Mes équipements sont-ils à renouveler ou à acheter et quelle sera la manière la plus écologique de le faire ? Les moyens humains sont-ils identifiés pour chaque phase du projet ? Les moyens financiers pour réaliser le projet en éco-conception sont-ils alloués ? - Cas d’usage : Affectation des budgets - Niveau : B/B/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-le-nr-va-generer-une-nouvelle-categorie-f9ade8 #### Recommandation n°21 - Critère : Des équipements matériels sont-ils à renouveler ou à acheter pour le projet, les équipements supplémentaires nécessaires sont-ils mis à disposition en gardant en tête les principes du NR ? - Justification : Le lancement de nouveaux projets est souvent l'occasion de renouveler ou compléter les équipements techniques. Dans le principe de la démarche NR, il serait plutôt l'occasion de challenger une meilleure utilisation des équipements disponibles et mettre en place toutes les solutions possibles pour les préserver. - Tests : La politique d'achat/renouvellement de matériels prend-elle en compte l'efficacité NR ? - Cas d’usage : Gestion de configuration - Niveau : B/C/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-le-lancement-de-nouveaux-projets-est-souvent-edc681 #### Recommandation n°22 - Critère : Mes ressources humaines (Identifiées pour chaque phase) sont-elles disponibles ? - Justification : L'efficacité de la démarche NR ne peut être atteinte sans la connaissance des enjeux NR par les personnes qui prendront part au projet. - Tests : Les sensibilisations/formations NR nécessaires sont-elles budgetées et planifiées ? - Cas d’usage : La fiche de cadrage projet précise les profils de tous les membres de l'équipe. - Niveau : A/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-lefficacite-de-la-demarche-nr-ne-peut-950484 #### Conseil n°23 - Critère : Les sponsors et éventuelles résistances de la démarche NR sont-ils identifiés ? - Justification : Lorsque la démarche NR est peu installée dans le modèle opérationnel de l'organisation, les luttes d'influence vont parfois décider de l'avenir du NR. Pour faciliter l'adoption, les freins doivent être identifiés et les arguments pour vaincre les résistances doivent être préparés en avance de phase et mis à disposition des sponsors de cette démarche. - Tests : Avez-vous anticipé les résistances en exposant les arguments par rapport aux freins à la mise en place de la démarche : obstacles prévisibles, motivation, mauvaise communication interne, management peu impliqué, autres projets lourds et prioritaires, investissements lourds et récents, réglementation,... ? - Niveau : B/B/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-lorsque-la-demarche-nr-est-peu-installee-b493fb #### Recommandation n°24 - Critère : Les objectifs NR sont-ils exposés clairement et partagés par toutes les parties prenantes, internes ou externes à l'organisation ? - Justification : Plusieurs acteurs, y compris externes à l'organisation, peuvent être impliqués dans le projet. La perméabilité de la démarche NR vers toutes les parties prenantes peut permettre d'identifier / activer des leviers que des acteurs n'auraient peut-être pas spontanément exprimés. - Tests : Avez-vous mis en place une communication formelle des objectifs NR, accessible à tous les acteurs ? ; La constitution des objectifs NR est-elle documentée pour permettre son exposition aux acteurs impliqués ? - Cas d’usage : Fiche projet - Niveau : B/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-plusieurs-acteurs-y-compris-externes-a-lorganisation-c385e9 #### Recommandation n°25 - Critère : Les délais de mise en oeuvre sont-ils envisagés ? - Justification : La gestion des délais projet est toujours au centre des préoccupations. Pour que le NR ne soit pas l'élément pointé du doigt il faut que les délais (en plus ou en moins) liés à cette démarche soient exprimés. Le délai projet n'intervient qu'une fois dans la vie du service, le gain ou la dette NR du projet va se multiplier tout au long du cycle de vie du projet. - Tests : Avez-vous chiffré les bénéfices/sur-coûts de la démarche NR sur le planning projet ? - Cas d’usage : Fiche de cadrage projet - Niveau : B/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-la-gestion-des-delais-projet-est-toujours-869732 #### Recommandation n°26 - Critère : Le besoin couvert par le service numérique s'inscrit-il dans l'un des objectifs de développement durable ? - Justification : Le questionnement de l'utilité du service numérique par rapport à l'un ou plusieurs des 17 ODD est capital, afin d'éviter la production de services numériques qui ne soient pas porteurs de valeurs. - Tests : Le service répond-t-il à au moins l'un des Objectifs de Développement Durable (ODD) ? - Cas d’usage : Fiche de cadrage projet - Niveau : A/A/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-strategie-le-questionnement-de-lutilite-du-service-numerique-3e19d8 ### Recommandation n°2 — Prévoir, préparer et valider les disponibilités des ressources humaines du Numérique Responsable #### Recommandation n°27 - Critère : A-t-on les personnes avec les compétences techniques les plus pertinentes pour chaque élément du projet ? - Justification : La démarche NR requiert avant tout une pratique métier affirmée. Il est difficile d'optimiser des éléments techniques lorsque la pratique n'est pas suffisamment ancrée. A l'inverse les optimisations NR sont parfois "contre-intuitives" et une bonne maîtrise du NR et des 3P est indispensable. - Tests : Combien d'acteurs dans chaque étape du projet ont une formation NR ? - Cas d’usage : La fiche de cadrage projet précise pour chaque profil des membres de l'équipe, les compétences nécessaires et les besoins de ressources externes - Niveau : A/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=2-strategie-la-demarche-nr-requiert-avant-tout-une-3980bc #### Recommandation n°28 - Critère : Les référents NR sont-ils listés et la liste communiquée aux acteurs du projet ? - Justification : Le NR adresse un très large périmètre, qu'il est difficile d'appréhender complètement dans chaque phase projet. Il est indispensable que les professionnels intervenant sur le projet puissent s'appuyer à tous moments sur des personnes référence pour les assister dans les meilleures pratiques à déployer. - Tests : Quels sont les référents officiels du projet en terme d'éco-conception ? en interne ou en externe ? - Cas d’usage : La fiche de cadrage projet désigne le référent NR du projet. - Niveau : A/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=2-strategie-le-nr-adresse-un-tres-large-perimetre-e5c0e7 #### Recommandation n°29 - Critère : Une stratégie pour sensibiliser les collègues/partenaires/clients au NR est-elle mise en place avec des étapes permettant de faire progresser les pratiques en continu ? - Justification : L'adoption du NR est une démarche globale, qui ne doit pas être freinée par la capacité de tout faire tout de suite, elle s'inscrit dans une progression qui s'installe au fur et à mesure des pratiques. - Tests : Le plan de formation NR est-il mis en place et suivi ? - Cas d’usage : Le plan de formation intègre les diffusions de sensibilisations et formations aux aspects NR. - Niveau : A/A/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=2-strategie-ladoption-du-nr-est-une-demarche-globale-e2c9de #### Recommandation n°30 - Critère : Les parties prenantes internes et externes sont-elles sensibilisées, voire formées/certifiées au NR ? - Justification : Chaque partie prenante à besoin d'une information efficace sur son domaine d'expertise et d'action, seul un plan de formation adapté peut apporter cette efficacité en amont des projets - Tests : Quel budget formation est alloué par type de profil ? - Cas d’usage : Le plan de formation intègre les diffusions de sensibilisations et formations aux aspects NR. La communication externe propage les enjeux environnementaux du numérique. - Niveau : A/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=2-strategie-chaque-partie-prenante-a-besoin-dune-information-e88dd0 #### Conseil n°31 - Critère : Les équipes ont-elle été questionnées en amont du lancement du projet, l'impact a-t-il été évalué et communiqué ? - Justification : Lorsque le NR est intégré dans la démarche projet, tous les éléments d'optimisation des projets sont mis en oeuvre, notamment les adaptations des processus avec la prise en compte des retours d'expérience sont naturels et totalement adaptés au NR - Tests : Les retours des équipes sont-ils revus et discutés pour améliorer les processus NR , - Niveau : B/A/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=2-strategie-lorsque-le-nr-est-integre-dans-la-e88a9b #### Conseil n°32 - Critère : Chaque partie-prenante interne et externe a-t-elle la latitude de prendre des décisions pouvant influer sur l'impact du Numérique Responsable ? - Justification : Les décisions projets qui peuvent avoir un impact important sur l'environnement doivent pouvoir être prises rapidement. Pour cela il est indispensable de définir l'espace de décision de chaque acteur et les mécanismes de validation. En l'absence de cette clarification, des décisions erratiques, même pour de bonnes raisons, pourraient intervenir et décrédibiliser la démarche NR, ou entraîner une forme d'auto-censure limitant les bénéfices NR - Tests : Le circuit et l'autonomie de décision ayant un impact NR est-il défini pour chaque acteur ? - Niveau : B/A/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=2-strategie-les-decisions-projets-qui-peuvent-avoir-un-20e1ca #### Conseil n°33 - Critère : Mes cibles peuvent-elles adhérer à ma démarche NR et de quelle manière ? - Justification : La démarche NR est mise en place pour le bien de toute la communauté, il serait dommage que cette prise en compte reste confidentielle et ne participe pas à la prise de conscience collective de l'impact des services numériques - Tests : Avez-vous prévu un plan de communication pour évangéliser sur les aspects NR ? - Niveau : A/B/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=2-strategie-la-demarche-nr-est-mise-en-place-b92804 #### Recommandation n°34 - Critère : Le projet avec une démarche NR va t-il réellement répondre aux besoins de mes clients ? - Justification : Une démarche NR appliquée sur un service numérique peut dans certains cas générer un peu d'inconfort / de disruption pour les utilisateurs dans leurs pratiques. Un mécanisme d'accompagnement ou de communication peut aisément lever ces points. Et apporter une valorisation importante. - Tests : Mesurez-vous les satisfactions clients sur les aspects NR ? - Cas d’usage : Fiche de cadrage projet - Niveau : B/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=2-strategie-une-demarche-nr-appliquee-sur-un-service-014739 #### Conseil n°35 - Critère : Les aspects Numérique Responsable sont-ils propagés et entretenus sur l'ensemble des acteurs ? - Justification : Obtenir et maintenir l'engagement des acteurs est un point important pour que le NR devienne la norme de fait. - Tests : Quelle est votre fréquence de communication NR pour chaque profil de partie prenante ? - Niveau : B/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=2-strategie-obtenir-et-maintenir-lengagement-des-acteurs-est-7d2897 ### Recommandation n°3 — Déterminer et planifier la capacité de suivre et capitaliser sur les composantes Numérique Responsable des projets #### Recommandation n°36 - Critère : Chacune des phases du cycle de vie (démarrage, maturité, arrêt) sont-elles identifiées avec des actions spécifiques ? - Justification : La démarche ACV est une base de la prise en compte du NR dans la conception des services numériques. Elle permet d'associer des actions à chaque étape du cycle de vie. - Tests : Avez-vous listé toutes les actions associées au NR pour les différentes étapes projet ? - Cas d’usage : L'analyse d'impact détermne les actions de réduction des impacts avec les acteurs concernés - Niveau : A/C/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-la-demarche-acv-est-une-base-de-d139d2 #### Recommandation n°37 - Critère : Les données ACV sont-elles réutilisées dans le cas d'une adaptation d'un service existant ? - Justification : Les analyses ACV peuvent être réalisées sur des services existants afin de les rendre plus efficaces dans le cas d'une refonte ou adaptation d'un service existant - Tests : Avez-vous mis à disposition des équipes projet les ACV précédentes ? ; L'ACV de ce projet est-elle rendue disponible pour d'autres projets ? - Cas d’usage : Une ACV minimale ("screening") est disponible pour le service existant - Niveau : A/B/B - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-les-analyses-acv-peuvent-etre-realisees-sur-c8b496 #### Recommandation n°38 - Critère : Si je décide de refaire mon service, qu’est-ce que je conserve de l’ancien et comment je le nettoie de la toile ? - Justification : Une bonne optimisation des enjeux NR passe aussi par la réutilisation des éléments qui ont été conçus avec une prise en compte du NR afin d'éviter de dupliquer certains éléments ou d'avoir des composants en double emploi, ou tout simplement inactifs, qui ne seraient maintenus que parce que l'effort de nettoyage n'a pas été pris en compte. - Tests : Les parties réutilisables de l'ancien site sont-elles décrites ? ; Une stratégie globale d'archivage des sites/services numériques existe-t-elle dans l'entreprise ? - Cas d’usage : Analyse d'impact - Niveau : B/B/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-une-bonne-optimisation-des-enjeux-nr-passe-209979 #### Recommandation n°39 - Critère : Est-ce que je peux recycler des briques logicielles ou du contenu existant ? - Justification : La conception modulaire est une pratique métier très largement employée. Le NR peut tirer un bénéfice de ces méthodes lorsque chaque composant modulaire est bien décrit et que ses atouts ou travers sont bien identifiés. - Tests : Existe-t-il un référentiel de briques logicielles partagées (authentification, base de compte utilisateurs, API génériques d'interconnections, etc.) ? ; Une stratégie globale de mutualisation/capitalisation des réalisations inter-projets est-elle en place dans l'entreprise ? - Cas d’usage : Fiche de cadrage projet - Niveau : B/B/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-la-conception-modulaire-est-une-pratique-metier-efbdab #### Conseil n°40 - Critère : Comment sont gérées les phases de fin de vie, dès le début ou à la fin d'un projet ? - Justification : Lors de la conception, chaque partie composant le projet peut être amenée à avoir une durée de vie différente. Il est important que l'ensemble des procédure de fin de vie soient exprimées pour que l'empreinte des composants inutilisés et arrêtés soient nulle. - Tests : Avez-vous listé l'ensemble des procédures de dé-provisionnement ? ; La modularité de la conception permettra-t-elle un déprovisionnement partiel, avec l'abandon de fonctionnalités obsolètes mais conservation de l'implémentation de certains processus métiers toujours utiles ? - Niveau : B/C/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-lors-de-la-conception-chaque-partie-composant-44fafa #### Conseil n°41 - Critère : La prise de conscience des "coûts de non-qualité" est-elle partagée par toutes les parties prenantes internes ? - Justification : La qualité du logiciel produit à un impact direct sur les aspects NR. En effet, les défauts génèrent de multiples livraisons de nouvelles versions successives, les anomalies entraînent des productions de traces d'anomalies importantes, et des fonctionnalités plus consommatrices de ressources techniques, parfois pour un résultat non atteint, donc des ressources ont été gaspillées pour ne produire aucun résultat. - Tests : Les défauts de qualités sont-ils consignés, analysés et traités aussi sur l'axe NR ? - Niveau : C/C/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-la-qualite-du-logiciel-produit-a-un-5fa595 #### Recommandation n°42 - Critère : Lors d'un audit, les éléments suivants sont-ils appréhendés ? - Justification : Lorsque le parcours utilisateur est court, moins de composants sont mis en oeuvre, les flux sont plus réduits, la compréhension du service est plus simple, donc les aspects NR sont mieux pris en compte. - Tests : La consommation d'énergie est-elle mesurée pour chaque parcours-type du site ? - Cas d’usage : L'audit se base sur la cartographie des parcours / branches du service, pour analyser les volumes et charges d'utilisation générées et déterminer les améliorations nécesaires - Niveau : A/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-lorsque-le-parcours-utilisateur-est-court-moins-bd1b0d #### Recommandation n°43 - Critère : Les indicateurs pour mesurer l'efficacité de ma démarche NR sont-ils identifiés et suivis ? - Justification : La mesure de certains éléments est un objectif qui permet de valoriser le résultat d'une démarche NR. La recherche d'indicateurs trop complexes peut s'avérer contre-productive, il vaut mieux s'attacher à des données fiables et marquantes et faire évoluer le nombre et la précision des indicateurs au fur et à mesure des gains de maturité de l'organisation et des acteurs internes - Tests : Quels sont les indicateurs définis pour mesurer l'efficacité de ma démarche NR? - Cas d’usage : Les extensions des navigateurs (ex: CHROME : extension GreenIT) sont utilisés et exposés pour valider l'efficacité. - Niveau : A/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-la-mesure-de-certains-elements-est-un-473793 #### Conseil n°44 - Critère : Les outils pour mesurer l'efficacité de ma démarche NR sont-ils identifiés et communiqués ? - Justification : Permettre aux acteurs de valider les résultats obtenus par la prise en compte du NR est important car il permet à chacun de s'approprier cette démarche et de situer ses actions dans cet objectif avec des outils adaptés à chaque acteur - Tests : Quels sont les outils sélectionnés pour mesurer l'efficacité de ma démarche NR ? - Niveau : B/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-permettre-aux-acteurs-de-valider-les-resultats-6fad05 #### Recommandation n°45 - Critère : La durée de vie du projet est-elle définie ? - Justification : Un service numérique ne peut plus être conçu pour l'éternité, il est étroitement lié aux environnements socio-économiques. A cette fin, il doit pouvoir être remis en cause régulièrement. Ceci présente aussi l'avantage de ne pas cumuler de dettes techniques et de rester au fait des avancées et pratiques les plus efficaces dans les domaines NR qui évoluent très rapidement. - Tests : Avez-vous estimé la période durant laquelle le service sera utile ? - Cas d’usage : Fiche de cadrage projet - Niveau : B/B/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-un-service-numerique-ne-peut-plus-etre-f96c36 #### Conseil n°46 - Critère : Est ce que les expériences des projets passés sont prises en compte ? - Justification : Beaucoup de projets au sein d'une organisation ont des principes communs, il est nécessaire de pouvoir s'appuyer sur d'autres projets pour capitaliser sur les gains et bénéfices des démarches NR du passé, et de les enrichir avec les nouvelles connaissances ou pratiques acquises. - Tests : Combien de post-mortem de projets avez-vous de disponibles pour capitaliser sur les réalisations précédentes ? - Niveau : B/A/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-beaucoup-de-projets-au-sein-dune-organisation-1a3aa3 #### Conseil n°47 - Critère : Est-il prévu de capitaliser l'expérience de ce projet pour le futur ? - Justification : Les méthodologies projet utilisent fréquemment les post-mortem pour apprendre des réalisations passées et progresser. Le NR doit apparaître dans ces thématiques. - Tests : Quelle production documentaire est associée au projet pour les aspects NR ? - Niveau : B/A/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-les-methodologies-projet-utilisent-frequemment-les-post-mortem-e9bfda #### Conseil n°48 - Critère : Les indicateurs couvrent-ils les éléments pour mesurer, évaluer et estimer le niveau de maturité NR, le piloter, l’améliorer et le contrôler ? - Justification : La démarche NR est itérative, elle doit s'insérer dans un processus d'amélioration continue. - Tests : Les sources de données des indicateurs sont-elles fiables ? - Niveau : B/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-la-demarche-nr-est-iterative-elle-doit-d3bea8 #### Recommandation n°49 - Critère : La conformité numérique responsable est-elle exposée ? - Justification : Un service numérique concu en respectant les recommandations du numérique responsable doit exposer les acquis et faiblesses identfiés. Dans une démarche similaire à celle déployée pour l'accessibilité avec la "déclaration d'accessibilité". - Tests : Une déclaration de conception responsable est-elle disponible pour le service numérique ? - Cas d’usage : Document "déclaration de conception responsable" - Niveau : A/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-strategie-un-service-numerique-concu-en-respectant-les-e2ae8a ### Recommandation n°4 — Prévoir, préparer et valider les éléments techniques du projet pour la conformité avec le Numérique Responsable #### Conseil n°50 - Critère : En dehors des éléments constituant le service numérique, quels sont les services annexes nécessaires : technologie tiers / open source, hébergement vert, agence digitale éco-responsable ... ? - Justification : Les phases de design, de développements, de production ont des impacts sur les aspects NR qui doivent être abordés dans toutes les ressources associées au projet. - Tests : L'annexe technique du projet est-elle formalisée ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-strategie-les-phases-de-design-de-developpements-de-865d92 #### Conseil n°51 - Critère : Chaque fonction du service est-elle appréhendée en regard de son importance dans le service ? - Justification : Les fonctionnalités les plus importantes sont parfois moins consommatrices de ressources que des fonctions marginales ce qui n'a pas de sens dans une démarche NR cohérente. - Tests : Avez-vous appliqué une démarche 80/20 pour chaque fonction en rapport avec ses impacts environnementaux et son importance ? - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=4-strategie-les-fonctionnalites-les-plus-importantes-sont-parfois-7343f4 #### Recommandation n°52 - Critère : Est-ce qu'une donnée réglementée (santé, bancaire, ...) est utilisée dans l'ensemble du système ? - Justification : L'exposition de l'utilisateur doit pouvoir être strictement encadrée. Au delà de la réglementation, c'est aussi la dimension humaine du NR qui est en jeu - Tests : Chaque donnée réglementée est-elle justifiée et identifiée ? - Cas d’usage : Analyse de risques - Niveau : C/C/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=4-strategie-lexposition-de-lutilisateur-doit-pouvoir-etre-strictement-1901e5 #### Recommandation n°53 - Critère : Des données personnelles au sens du RGPD sont-elles utilisées ? - Justification : L'utilisateur vous confie des données. Pour prendre en considération l'aspect PEOPLE, et ne pas s'exposer à des sanctions onéreuses, la démarche NR incite à fortement limiter ces données. - Tests : Chaque donnée personnelle est-elle répertoriée et gérée ? - Cas d’usage : Analyse de risques - Niveau : C/C/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=4-strategie-lutilisateur-vous-confie-des-donnees.-pour-prendre-b181e3 #### Conseil n°54 - Critère : Est ce que le choix de solutions Open Source est privilégié ? - Justification : Une solution Open Source n'est pas un gage d'efficacité NR et les différentes alternatives doivent être challengées. Mais l'open source permet de limiter les ambitions et mainmises de certains acteurs dont les pratiques économiques et sociales sont opaques. - Tests : De quelles métriques NR disposez-vous pour les solutions Open Source envisagées ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-strategie-une-solution-open-source-nest-pas-un-c039e6 #### Conseil n°55 - Critère : Les outils intégrés (CMS, frameworks, ...), ou les développements internes, apportent-ils des éléments positifs vis à vis de la démarche NR ? - Justification : Dans les choix BUY/BUILD la dimension NR doit pouvoir être évaluée et projetée dans le temps pour s'assurer que les choix sont suffisamment évolutifs pour permettre de gagner en conformité NR au fil du temps. Et pas uniquement sur la phase de développement / intégration. - Tests : De quelles métriques NR disposez-vous pour les solutions déployées en interne ? ; De quelles métriques NR disposez-vous pour les solutions intégrées ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-strategie-dans-les-choix-buy%2Fbuild-la-dimension-nr-a2d4e4 #### Conseil n°56 - Critère : Quelle est la technologie adhèrant aux principes NR la plus appropriée à mes besoins ? - Justification : Le choix technologique doit être dicté par des critères NR, plutôt que par l'attrait technologique de la nouveauté à la mode. La liste des critères doit être déterminée par un collectif pas exclusivement composé des techniciens qui vont les utiliser afin d'avoir une vision plus large. - Tests : Avez-vous une grille de critères d'évaluation des alternatives technologiques disponibles ? - Niveau : B/B/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-strategie-le-choix-technologique-doit-etre-dicte-par-8f3382 #### Conseil n°57 - Critère : Dans le cas d'un développement interne (CMS, Framework, ...), quelle est la pertinence de le retravailler sous l'angle d'une optimisation NR, si la démarche NR est peu maîtrisée et le projet déjà avancé ? - Justification : Les outils sélectionnés pour les développements doivent permettre d'intégrer les principes NR sans qu'une refonte complexe ne soit nécessaire. La complexité écarte de fait les bonnes volontés et écarte les personnes les moins aguerries, ce qui donne au projet une forme élitiste peu compatible avec les principes NR. - Tests : Le coût de mise à niveau vis-à-vis du NR des solutions déployées en interne est-il chiffré ? - Niveau : B/B/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-strategie-les-outils-selectionnes-pour-les-developpements-doivent-efa460 #### Conseil n°58 - Critère : Comment choisir les solutions techniques les plus propices au NR ? - Justification : Un choix de base technique doit prendre en compte les aspects techniques mais aussi les orientations des fournisseurs et la facilité de déployer la production réalisée à partir de ce socle en limitant les impacts environnementaux. Les critères permettant la sélection de ce type de composants doivent être clairement définis. - Tests : Avez-vous listé les règles qui permettent d'arbitrer les choix techniques, par exemple : la charge de formation par rapport au gain NR, les aspects économiques moyen et long terme par rapport au gain NR, la performance technique et le positionnement NR de la solution et du fournisseur? - Niveau : B/B/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=4-strategie-un-choix-de-base-technique-doit-prendre-88a671 ### Recommandation n°5 — Agir en faveur de la réduction des impacts du SI en construisant des cibles et plans de SI urbanisés (*NEW) #### Recommandation n°59 - Critère : Avez-vous construit une cible du SI en cherchant cohérence et mutualisation ? - Justification : La mesure des impacts du nouveau projet s'inscrit dans une optimisation globale des impacts du SI. - Tests : Une cellule d'Architecture d'Entreprise existe - t elle dans l'entreprise ? ; Mène t elle des activités d'Urbanisation prospectif et de formalisation de Vision du SI ? - Cas d’usage : La vision du SI urbanisée - Niveau : B/B/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=5-strategie-la-mesure-des-impacts-du-nouveau-projet-cdf876 #### Recommandation n°60 - Critère : Avez-vous construit des feuilles de route pilotés et priorisés en tenant compte des gains rapides sur les impacts du SI ? - Justification : L'urbanisation apporte une réponse rapide à des impacts forts du SI - Tests : Le projet a t il été sélectionné parmi ceux qui apportent une réponse rapide à des impacts forts du SI actuels ? ; Le nouveau projet a-t-il été évalué au regard de ses impacts en matière de sobriété numérique ou au regard des gains de réduction des impacts de l'existant ? ; Le nouveau projet a-t-il été choisi parmi le portefeuille des projets avec un critère concernant la réduction rapide des impacts ? - Cas d’usage : La vision du SI urbanisée - Niveau : B/B/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=5-strategie-lurbanisation-apporte-une-reponse-rapide-a-des-3725b3 #### Recommandation n°61 - Critère : Avez-vous conduit des mesures globales des impacts du SI ? - Justification : La mesure globale des impacts du SI permet ainsi de repérer les zones d'optimisations potentielles fortes en matière de sobriété numérique .Elle aide aussi à mesurer les projets techniques ou les projets métiers qui doivent embarquer des mesures de réduction des impacts du SI . - Tests : Quels outils de pilotage sont déployés ? - Cas d’usage : La vision du SI urbanisée - Niveau : A/C/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=5-strategie-la-mesure-globale-des-impacts-du-si-c8b265 #### Conseil n°62 - Critère : Avez-vous un dispositif de diffusion de la connaissance sur le SI (cartographies du SI, Référentiels Fonctionnel, Applicatif, Technique, ...) ? - Justification : La connaissance partagée du patrimoine SI, de la vision SI, des règles d'urbanisation, des politiques et standards, … et des mesures d'impacts, … sont chacun des éléments qui favorisent les bonnes décisions à prendre sur le SI ou dans le cadre d'un projet - Tests : Comment sont partagées les connaissances ? - Niveau : A/A/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=5-strategie-la-connaissance-partagee-du-patrimoine-si-de-6ee502 #### Conseil n°63 - Critère : Avez-vous inscrit des objectifs de sobriété numérique dans la gouvernance SI de l'entreprise ? - Justification : Mettre en place dans la gouvernance du SI des questions clés relatives à la Sobriété Numérique permet d'inscrire dans la durée et dans tous les projets des règles à respecter et donc des réflexes chez les parties prenantes - Tests : La stratégie RSE embarque des objectifs de sobriété du SI ? - Niveau : A/A/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=5-strategie-mettre-en-place-dans-la-gouvernance-du-11f3c9 ### Recommandation n°6 — Agir en faveur de la réduction des impacts du SI en optimisant les assets IT et en mutualisant (*NEW) #### Recommandation n°64 - Critère : Avez-vous défini et mis en place au sein de la DSI un dispositif de gestion de dette du SI et d'obsolescence ? - Justification : Gérer la dette technique et fontionnelle, anticiper les obsolescences, réduire les variétés de composants, de versions de composants, … va dans le sens à la fois d'une sécurisation du SI mais aussi d'une meilleure maîtrise des impacts du SI - Tests : La cellule d'Architecture d'Entreprise a-t-elle mis en place un "Application Portolio Management" ? (APM) ; La cellule d'Architecture avec les INFRASTRUCTURES, les POSTES de TRAVAIL, … a-t-elle mis en place une GESTION de DETTE SI ( ou ASSET IT Mangt ) ? - Niveau : B/C/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=6-strategie-gerer-la-dette-technique-et-fontionnelle-anticiper-289785 #### Conseil n°65 - Critère : Avez-vous impliqué les métiers et la DG dans les Plans de réduction de la dette SI et de l'obsolescence ? - Justification : La gestion de la dette du SI n'est pas que une gestion de dette technique, elle est aussi une gestion de la dette fonctionnelle ( retard des fonctions au regard des besoins, non alignement à la règlementation, architecture inadaptée, ... ) . il convient de choisir des applications à décommissionner , à mutualiser, ... avec les métiers - Tests : L''Application Potfolio Management "implique-t-il les Métiers ? ; La Gestion de dette du SI articule-t-elle les Métiers, les AE, les Projets, les Applications, les DWP, les INFRAS ? - Niveau : B/B/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=6-strategie-la-gestion-de-la-dette-du-si-5973d1 #### Recommandation n°66 - Critère : Avez-vous défini une politique sobre d'usages des environnements ? - Justification : Si disposer de multiples environnements d'accueil lors du développement est un gage de souplesse et d'efficacité pour la délivrance. EN utiliser le bon nombre en développement est une bonne pratique. Mais surtout réduire ce nombre pendant les phases longues de maintenance. Car "plus vous avez d'environnements , plus vous impactez ! " - Tests : De combien d'environnements disposez vous pour le développement de votre application ? ; De combien d'environnements disposez vous pour la maintenance de votre application ? - Niveau : B/B/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=6-strategie-si-disposer-de-multiples-environnements-daccueil-lors-2669dd #### Recommandation n°67 - Critère : Avez-vous étudié des projets de reengineering allant dans le sens de la mutualisation donc de la frugalité ? - Justification : Conduire des actions de reengineering du SI visant à mutualiser des SI tout en répondant aux besoins fonctoinnels des métiers . Mutualiser en général réduit les architectures applicatives et techniques - Tests : Le plan d'action est-il défini ? - Niveau : B/B/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=6-strategie-conduire-des-actions-de-reengineering-du-si-f92129 ### Recommandation n°7 — Agir en faveur de la réduction des impacts du SI en mettent en œuvre des socles applicatifs et data (*NEW) #### Recommandation n°68 - Critère : Avez-vous confirmé et mis sous contrôle des référentiels de données d'entreprise et des gisements de données ? - Justification : Mutualiser certains données clés du SI , qu'il s'agisse de Référentiels de données d'entreprises, Puits de données . Cela permet de réduire le nombre de Bases de données et flux/interfaces d'échanges ; donc de réduire les impacts du Numérique - Tests : Les référentiels sont-ils identifiés et partagés ? - Niveau : B/C/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=7-strategie-mutualiser-certains-donnees-cles-du-si--c6fc81 #### Recommandation n°69 - Critère : Avez-vous sélectionné et déployé des socles applicatifs partagés ? - Justification : Mettre en place des outils d'aide à la gestion des référentiels de données, des moteurs de règles, … apporte des mutualisations des données de référence et de certaines règles de gestion. Cette mutualisation apporte simplification et réduction des impacts. - Tests : Les référentiels sont-ils identifiés et partagés ? - Niveau : B/C/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=7-strategie-mettre-en-place-des-outils-daide-a-1c6519 #### Recommandation n°70 - Critère : Avez-vous sélectionné, déployé de systèmes de gestion de flux mutualisés ( ESB, APIM, ...) ? - Justification : Simplifier la gestion des flux de données grâce à des outils de gestion de flux constitue une mutualisation de nombreuses règles de gestion des flux. Cette mutualisation apporte une simplification et une réduction des impacts . - Tests : Quelles sont les gestions de flux mutualisées en place ? - Niveau : B/C/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=7-strategie-simplifier-la-gestion-des-flux-de-donnees-96d597 #### Conseil n°71 - Critère : Avez-vous promu la mise en place de plateformes de développement permettant l'optimisation et facilitant le green coding ? - Justification : Outiller le développement par des plateformes optimisées apporte potentiellement de la simplification et de la réduction des impacts. Attention, toutefois, certaines plateformes non optimisées ne garantissent pas une réduction des impacts, voire génèrent des applicatifs plus gourmands. - Tests : Comment sont qualifiées les plateformes ? - Niveau : A/B/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=7-strategie-outiller-le-developpement-par-des-plateformes-optimisees-816067 #### Recommandation n°72 - Critère : Avez-vous défini une politique, et des pratiques et dispositifs d'archivage / stockage de données optimisées ? - Justification : Les règles de sauvegarde et archivage des données peuvent être plus ou moins impactantes selon les durées de rétention retenues. Il importe de conduire la définition qui non seulement respectent certaines orientations RGPD mais aussi aillent dans le sens de la réduction des impacts. - Tests : La politique est-elle connue et suivie ? - Niveau : B/C/B - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=7-strategie-les-regles-de-sauvegarde-et-archivage-des-7135b1 ### Recommandation n°8 — Agir en faveur de la réduction des impacts du SI en optimisant la valorisation de la data (*NEW) #### Recommandation n°73 - Critère : Avez-vous favorisé la construction d'architectures de gestion de données permettant de mutualiser du stockage de données ? - Justification : Que ce soit pour le SI opérationnel, mais en particulier, pour les structures de DATA HUB, de stockage BIG DATA, adopter une approche sobre de la collecte des donnéeset une architecture optimisée des stockages de données va avoir un impact non nul sur les impacts. - Tests : Les données mutualisées sont-elles cartographiées ? - Niveau : B/C/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=8-strategie-que-ce-soit-pour-le-si-operationnel-350ff1 #### Recommandation n°74 - Critère : Avez-vous optimisé le cycle de vie de la donnée afin de ne conserver que les données nécessaire d'un point de vue métier et règlementaire. La donnée agrégée peut suffire. ? - Justification : L'analyse du cycle de vie de la données permet de prendre les bonnes décisions quant aux données à conserver aux différentes étapes. Et en particulier ne pas hésiter à stocker de la donnée agrégée pour éviter les stockages aberrants de données inutiles. Ceci s'applique aussi à la gestion documentaire. - Tests : Le cycle de vie est-il décrit ? - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=8-strategie-lanalyse-du-cycle-de-vie-de-la-bbeef4 #### Recommandation n°75 - Critère : Avez-vous mis en place une gouvernance de la donnée ? - Justification : La gouvernance de la donnée permet d'identifier chaque donnée de manière unique , donc d' éviter les redondances de stockage et de traitement ( en effet dans certains cas une même donnée peut être connue sous deux noms différents). En effet, l'identification du système source de la donnée, permet de réduire la complexité d'usages en favorisant la création de services d'usages sur cette seule source ; ceci permet aussi d'éviter les duplications - Tests : La gouvernance est-elle en place ? - Niveau : B/B/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=8-strategie-la-gouvernance-de-la-donnee-permet-didentifier-594140 #### Conseil n°76 - Critère : Avez-vous défini des modalités d'accès centralisé aux données ? - Justification : Mettre en place des dispositifs d'accès centralisés aux données ( API Management surles données, … ) facilite l'urbanisation autour des données et réduit les nombres de services d'accès aux données . Cette mutualisation apporte simplification et réduction des impacts. - Tests : Les modalités d'accès sont-elles décrites et accessibles ? - Niveau : B/C/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=8-strategie-mettre-en-place-des-dispositifs-dacces-centralises-b9264c ## Famille : Ux/ui Les étapes et méthodes de conception des services numériques pour définir les meilleures solutions d'interactions avec l'utilisateur. ### Recommandation n°1 — Intégrer le Numérique Responsable dans les objectifs majeurs du projet #### Recommandation n°1 - Critère : Dans les méthodes d'idéation, l'ensemble des parties prenantes est-il pris en compte dans toute sa dimension (humaine) ? - Justification : Mettre l'Utilisateur au centre de la réflexion est la garantie de couvrir les besoins essentiels de vos cibles et d'avancer dans le bon sens. Par Utilisateurs, nous entendons les usagers finaux du service ou du produit mais également les différentes parties prenantes du projet. Considérer vos utilisateurs avec une dimension humaine et empathique permet d'élargir le prisme de votre réflexion et d'aller au-delà des aspects économiques et technologiques du projet. - Tests : Une cartographie des parties prenantes a-t-elle été réalisée ? Une priorisation des parties prenantes est-elle faite ? ; Les différentes parties prenantes sont-elles intégrées dans les différents outils : expérience et service Map, cartes UX, shadowing, workshops, etc. ) ? Une approche Human-Centered Design est-elle utilisée ? ; L'approche User centric est-elle présente ? - Cas d’usage : Le panel de profils d'utilisateurs couvre l'ensemble des aspects humains que le NR doit adresser pour éviter la fracture numérique - Niveau : B/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-uxui-mettre-lutilisateur-au-centre-de-la-reflexion-f2b9f8 #### Recommandation n°2 - Critère : La planète est-elle prise en compte dans les méthodes d'idéation pour intégrer la dimension écologique (planet centric design) ? - Justification : Chaque décision de conception a un impact. Si les problématiques environnementales et écologiques ne sont pas au coeur de l'analyse, aucun objectif de maîtrise ou de réduction des impacts ne sera pris en compte et donc respecté. - Tests : Le toolkit planet centric est-il connu et utilisé ? - Cas d’usage : Une démarche systémique / Planet Centric est mise en place. - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=1-uxui-chaque-decision-de-conception-a-un-impact.-7a99c6 #### Recommandation n°3 - Critère : Les plus-values extra-financières du numérique responsable sont-elles valorisées dans le business model ? - Justification : Le Numérique Responsable (NR) peut-être considéré comme un réel vecteur de développement économique au sein de votre organisation. Intégrer la dimension NR de façon pérenne à votre business model permettra d'éviter des arbitrages permanents sur sa valorisation et son intégration à vos futurs projets. - Tests : Les valeurs humaines, écologiques et économiques se retrouvent-elles dans le business model canvas et sont-elles validées par toutes les parties prenantes ? ; Un "Evidence planning" est-il utilisé pour mettre en valeur les différents gains et coûts des 3P ? - Cas d’usage : les analyses de bénéfices couvrent les aspects NR avec leurs retombées - Niveau : B/B/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=1-uxui-le-numerique-responsable--peut-etre-considere-comme-db52e4 #### Conseil n°4 - Critère : Un process NR est-il prévu au niveau de la gouvernance projet ? - Justification : Une démarche NR doit être systémique, sur l'ensemble du cycle de vie du projet, et donc portée par tous les acteurs du développement. - Tests : Des revues et un suivi transverse des aspects NR sont-ils mis en place ? A quelle fréquence sont planifiées les revues NR ? ; Un RACI est-il prévu ? - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-uxui-une-demarche-nr-doit-etre-systemique-sur-5e2775 #### Recommandation n°5 - Critère : Les améliorations NR sont-elles identifiées et systématiquement planifiées ? - Justification : Le principe d'amélioration continue permet d'augmenter la performance du projet et donc de limiter son impact. - Tests : La revue projet est-elle réalisée et permet-elle d'améliorer les impacts sur les 3ps ? ; Utiliser un backlog des améliorations identifiées ; Un post mortem est-il systématiquement mis en place ? - Cas d’usage : Backlog - Niveau : C/B/C - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=1-uxui-le-principe-damelioration-continue-permet-daugmenter-la-448d84 #### Recommandation n°6 - Critère : Pour les aspects NR les responsables projet (chef de projet, product owner ....) ont-ils les mêmes prérogatives que les aspects métiers ? - Justification : Pour que le sujet NR soit suivi, il doit être incarné par une personne identifiée, responsable, qui diffuse les enjeux à chaque intervenant métier et prend part aux décisions. Ce rôle peut être défini dans ses objectifs personnels ou fiche de poste. - Tests : Quel est le niveau de décision du responsable projet pour les aspects NR ? ; Le responsable du projet a-t-il présenté le référentiel NR choisi pour le projet ? ; Tous les protagonistes ont-ils bien le même niveau d'information sur les différents rôles quant à la responsabilité NR ? - Cas d’usage : Plan de formation - Niveau : B/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=1-uxui-pour-que-le-sujet-nr-soit-suivi-9f89a6 #### Recommandation n°7 - Critère : La production des livrables (production documentaire comprise) est-elle utilisée en amont du projet et est-elle produite pour permettre d'être réutilisée dans les projets suivants ? - Justification : Une base de connaissances et de compétences NR va émerger au fur et à mesure des projets. Il est important de capitaliser sur l'expérience acquise et de diffuser les bonnes pratiques. Cela permettra à vos équipes de développer des automatismes et de réutiliser des solutions qui ont fait leurs preuves sur de futurs projets. - Tests : La démarche qualité est-elle appliquée à tous les éléments de communication du produit ? ; Un process de low fidelity est-il mis en oeuvre en préalable du high fidelity ? - Cas d’usage : Documentation technique - Niveau : B/B/A - Cycle de vie : Revalorisation - Page : https://gr491.isit-europe.org/crit.php?id=1-uxui-une-base-de-connaissances-et-de-competences-84d5c8 #### Conseil n°8 - Critère : Un budget sur les axes 3Ps est-il associé et suivi lors du projet ? - Justification : Suivant le niveau de maturité de l'organisation, la prise en compte du NR peut engendrer un coût et un temps de réflexion qui doivent être prévus et associés aux bénéfices attendus. Les postes et les temps alloués au NR sur le budget doivent être validés, visibles et communiqués de manière précise à toutes les parties prenantes du projet. - Tests : Les missions UX-UI liées au NR sont-elles clairement détaillées et communiquées dans le budget ? Des indicateurs incluant les 3P sont-ils mis en place pour suivre le budget du projet ? ; Le budget NR est-il validé au niveau projet ? ; Un budget carbone est-il alloué au projet et au service, pour tout le cycle de vie ? - Niveau : B/B/A - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=1-uxui-suivant-le-niveau-de-maturite-de-lorganisation-4b0ecd ### Recommandation n°2 — Sensibiliser les parties prenantes internes et externes au Numérique Responsable #### Recommandation n°9 - Critère : Les parties prenantes sont-elles sensibilisées au NR ? - Justification : Pour adhérer, il faut comprendre. Le NR n'est pas une discipline technique. Les principes du NR doivent être mis en oeuvre dans des pratiques métiers et les comportements de chacun des acteurs. Toutes les parties prenantes du projet doivent être sensibilisées au NR pour agir à leur niveau. - Tests : Un partage de la connaissance et une sensibilisation vers les parties prenantes sont-ils en place ? ; Un support de sensibilisation adaptable aux différents projets et aux différents niveaux de connaissance de l'ensemble des parties prenantes est-il disponible ? - Cas d’usage : Le plan de formation intègre les diffusions de sensibilisations et formations aux aspects NR. - Niveau : B/A/A - Cycle de vie : N/A - Page : https://gr491.isit-europe.org/crit.php?id=2-uxui-pour-adherer-il-faut-comprendre.-le-nr-798b14 #### Recommandation n°10 - Critère : Les différentes étapes du projet sont-elles identifiées avec leur process de validation, afin de faire adhérer les parties prenantes à la démarche itérative ? - Justification : La démarche NR est itérative et parfaitement adaptée aux processus Agiles, ce qui impose aussi des mécanismes de contrôles et de validation performants et formalisés. - Tests : Comment sont validées les étapes projets pour le NR ? ; Disposez-vous de Sustainable Decision Point ? - Cas d’usage : Definition of Done - Niveau : B/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=2-uxui-la-demarche-nr-est-iterative-et-parfaitement-257bc5 #### Conseil n°11 - Critère : Avez-vous mis en place un système de présentation du suivi d'impacts environnementaux, pour l'exploitation du service et pour chaque utilisateur ? - Justification : L'engagement des utilisateurs va susciter l'adhésion à la démarche NR, c'est un aspect important de la propagation des valeurs et résultats de l'organisation. Le fait de communiquer aux utilisateurs des éléments très visuels facilite leur adhésion et la compréhension de vos engagements. - Tests : Un compteur écologique est-il proposé à l'utilisateur de manière didactique ? ; Un compteur de la consommation électrique est-il mis en place pour l'usage du service (par session par ex.) ? ; Un compteur de temps de visionnage est-il mis en place pour l'usage du service (par session par ex.) ? Le poids des fichiers à télécharger est-il systématiquement indiqué afin de sensibiliser à l'impact de la fonctionnalité ? - Niveau : A/A/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=2-uxui-lengagement-des-utilisateurs-va-susciter-ladhesion-a-613160 #### Conseil n°12 - Critère : Quelles données sont disponibles à la communication concernant le respect des normes et préconisations NR sur le service ? - Justification : Un certain nombre de ressources sont disponibles pour afficher le niveau de complétion et adhésion au NR. Cela se traduit par des badges, des labels, des normes... permettant à l'utilisateur d'identifier les organisations qui font les efforts les plus sensibles sur les enjeux sociaux et environnementaux. - Tests : Les labels et badges à atteindre par l'applicatif sont-ils fixés en début de projet et affichés dans le service ? ; Le service est-il certifié et/ou répond-t-il à une normalisation (ISO 14000, 14040...) ? ; Un outil de communication est-il disponible ? - Niveau : B/A/A - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=2-uxui-un-certain-nombre-de-ressources-sont-disponibles-044d9a #### Conseil n°13 - Critère : Pour permettre aux utilisateurs d'être acteurs dans la réduction de leurs impacts, ont-ils accès à des références qui les invitent à des pratiques NR ? - Justification : Le comportement de l'utilisateur reste l'un des points sur lequel l'organisation n'a pas de contrôle. Malgré tous les bénéfices attendus d'une conception responsable de services numériques, la pratique de l'utilisateur peut soit démultiplier les effets positifs, soit les réduire dans des proportions importantes. Communiquer des éléments qui permettent à l'utilisateur de prendre conscience de ces actions pour qu'il réduise son impact est indispensable. - Tests : Des éco-tips et les données d'utilisation sont-ils accessibles par l'utilisateur lors de l'utilisation du service ? ; Les settings à impact NR du service sont-ils clairement identifiables et facilement accessibles par l'utilisateur ? ; Proposez-vous des guidelines orientées NR ? Des solutions alternatives NR permettent-elles de prioriser les choix utilisateurs ? - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=2-uxui-le-comportement-de-lutilisateur-reste-lun-des-8565f8 ### Recommandation n°3 — Rendre disponible et accessible le service numérique au plus grand nombre d'utilisateurs #### Conseil n°14 - Critère : Les freins à l'utilisation du numérique (accessibilité, techniques, territoriaux) sont-ils pris en compte ? - Justification : Afin d’être responsable, le numérique doit en tout premier lieu être disponible et accessible (En France, 14% de la population n'a pas d'accès à internet ou pas de compétences numériques (source : Vie-publique.fr / DILA Source: ICT Surveys - INSEE), car en France plus d'un usager sur 3 manque de compétences numériques de base. C'est l'objet de la dimension humaine du NR, qui couvre les freins à l'utilisation du numérique pour certains publics en fonction de capacités à percevoir les éléments (accessibilité) et les accès et la qualité des réseaux. - Tests : La constitution des personas prend elle en compte l'intégralité des cas d'inclusion numérique ? Les usagers en difficulté sont-ils repérés à l'aide des personnas et accompagnés durant tout le cycle de vie du service via des tests utilisateurs ou onboarding formations ? ; En cas de conflit comment les élements sont-ils arbitrés ? ; L'accès aux technologies et à la qualité du débit d'internet est-il bien pris en compte dès la phase de conception ? Avez-vous défini un objectif au taux d'accessibilité de votre service ? Le service répond-t-il aux recommandations et obligations d'accessibilité et rempli-t-il les critères d'un label d'accessibilité / normes ? - Niveau : C/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-uxui-afin-detre-responsable-le-numerique-doit-en-390b8b #### Recommandation n°15 - Critère : Quelles solutions sont déployées pour lutter contre l'illectronisme et simplifier les usages et services ? - Justification : Réduire les inégalités d’accès au service numérique afin de n’exclure aucun utilisateur, ces cas d'exclusion peuvent être fortement limités en prenant en compte très tôt dans la conception les disparités sociales, générationnelles et territoriales. - Tests : La courbe d'apprentissage de l'utilisation et de la compréhension du service est-elle gérée ? ; L'UX Content de l'applicatif est-il géré, la prise en main du service a-t-elle été facilitée ? ; Quel est le taux de satisfaction/réussite de l'usage du service par tous les usagers séparément ? Les outils d'accessibilité existants et déjà utilisés sont-ils identifiés ? - Cas d’usage : Tests utilisateurs - Niveau : C/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-uxui-reduire-les-inegalites-dacces-au-service-numerique-0e5459 #### Recommandation n°16 - Critère : Les critères technologiques, sociaux, physiques, temporels qui permettent à vos utilisateurs d'atteindre leur but et limiter la fracture numérique, sont-ils pris en compte ? - Justification : Traiter les cas d'exclusion du numérique est la première étape incontournable, mais cela ne garantit pas que l'utilisateur va pouvoir atteindre ses buts aisément par l'utilisation du service. Ces aspects doivent être adressés en facilitant le parcours de l'utilisateur. - Tests : Les usagers en difficultés quant à l'usage du service sont-ils bien pris en compte et représentés, ainsi que leur problématique, via des outils objectifs (personas, filatures, échelles de questions, entretiens, univers narratifs...) ? ; Comment sont collectées les difficultés des utilisateurs ? - Cas d’usage : Analyse d'impact - Niveau : B/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-uxui-traiter-les-cas-dexclusion-du-numerique-est-75270f #### Recommandation n°17 - Critère : Le service fonctionne-t-il avec des connexions faibles ? - Justification : Les environnements de développement et de tests sont souvent performants ce qui masque les impacts de réseaux avec des performances faibles. Afin de ne pas rendre inutilisable le service dans des conditions ou les débits réseaux sont réduits la démarche NR doit prendre en compte une conception adaptée aux territoires ou localisations dont les accès réseaux sont dégradés - Tests : Un mode dit "Low" est-il à envisager ? ; Le service peut-il être testé avec des débits restreints ? ; Une perte de connexion au cours du service est-elle prise en compte avec une segmentation du service évitant à l'utilisateur de refaire un parcours complet? - Cas d’usage : Les outils et consoles de développement des navigateurs sont utilisés pour simuler des réseaux avec des bandes passantes réduites (ex: FIREFOX : Console / Limitation bande passante) - Niveau : A/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=3-uxui-les-environnements-de-developpement-et-de-tests-28b67c #### Recommandation n°18 - Critère : Est-ce que les mécanismes d'accès au service d'assistance sont disponibles et adaptés à tout public ? - Justification : Les capacités d'interactions entre l'utilisateur et le service peut être améliorées avec des mécanismes d'assistance en ligne qui doivent respecter les mêmes exigences NR que l'ensemble du service. L'accessibilité doit être pensée pour le service ainsi que pour les solutions d'aide. - Tests : Les modes d'accès à l'assistance ont-ils été testés avec les publics concernés, des difficultés ont-elles été identifiées ? ; Des formations (Onboardings) sont-elles prévues et accessibles facilement par les utilisateurs en difficulté face à l'usage du service ? Une assistance humaine est-elle prévue en cas de difficultés ? ; Plusieurs modalités d'accès au service sont-elles prévues via des parcours utilisateurs, user journey, experience map différents ? - Cas d’usage : Tests utilisateurs - Niveau : C/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=3-uxui-les-capacites-dinteractions-entre-lutilisateur-et-le-49fbc2 #### Conseil n°19 - Critère : Un fall-back humain a-t-il été mis en place, pour accompagner la prise en main du service ? - Justification : La charge de l'assistance aux utilisateurs est le plus souvent déléguée à un automate, afin de s'affranchir des contraintes de disponibilité et ne pas générer de temps d'attente pour des réponses fréquemment posées. Le contact avec un automate peut être frustrant et doit pouvoir se transformer en contact humain en respectant aussi tous les critères NR. - Tests : Après combien de tentatives infructueuses l'utilisateur est-il mis en relation avec un opérateur humain ? ; Plusieurs formats d'échanges sont-ils envisagés (parlé, écrit, langue des signes, parlé complété, chat, présentiel, braille) ? ; Les différentes typologies de cibles (handicap, illectronisme ...) ont-elles bien été prises en compte ? - Niveau : C/A/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=3-uxui-la-charge-de-lassistance-aux-utilisateurs-est-b12e35 #### Recommandation n°20 - Critère : Une stratégie de compatibilité avec les terminaux et versions logicielles obsolètes est-elle définie ? - Justification : Les avancées technologiques poussent à augmenter en permanence les exigences matérielles, ce qui réduit le parc de périphériques sur lesquels un service peut s'exécuter. Cet aspect écarte certains utilisateurs et pousse au renouvellement d'équipements encore en état de fonctionner avec l'impact environnemental associé. - Tests : La liste des terminaux est-elle élargie aux terminaux cibles secondaires ? Existe-t-il des exigences particulières en terme d'expérience utilisateur (habitudes à une interface existante, à un terminal donné) ? ; Vos personae sont ils qualifiés au niveau des devices et OS associés? ; Est-ce que la démarche responsive et l'application de la démarche mobile first sont mises en oeuvre ? - Cas d’usage : Chaque élément référencé dans le Dossier Technique porte une information de degrés de compatibilité - Niveau : A/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=3-uxui-les-avancees-technologiques-poussent-a-augmenter-en-de5bbb #### Conseil n°21 - Critère : Dans la définition des personae, les versions cibles de devices, OS et browsers ont-ils été pris en compte ? - Justification : Le secteur d'activité, le profil des utilisateurs permet le plus souvent de qualifier le parc matériel qui sera employé pour le service. Les matériels sont déterminés par leurs capacités techniques (puissance de calcul, mémoire, capacité réseau, capteurs, taille et qualité d'écran) mais aussi par les systèmes d'exploitation qu'ils peuvent accueillir. Chaque contrainte que le service impose réduit le nombre de postes qui pourront l'utiliser et donc exclut des publics. - Tests : Quelle date maximale de compatibilité est définie, permettant de déterminer les éléments techniques de vétusté du parc informatique des cibles ? ; Les coûts engendrés par la couverture attendue sont-ils chiffrés et acceptés ? ; Les données analytics des cibles sont-elles intégrées ? - Niveau : B/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=3-uxui-le-secteur-dactivite-le-profil-des-utilisateurs-dc9fd8 ### Recommandation n°4 — Permettre aux personnes en situation de handicap ou porteur de déficiences, d'accéder et d'utiliser efficacement le service numérique #### Recommandation n°22 - Critère : Dès la conception, le service répond-t-il aux normes d'accessibilité en vigueur (au minimum) ? - Justification : Au delà des aspects purement réglementaires, l'anticipation de la prise en compte de l'accessibilité est nécessaire pour assurer une couverture de ce sujet durant toute la durée de vie du service. Anticiper les futurs points de règlements et normes permet de pérenniser le service en limitant les besoins de mises à jour dictées par l'environnement légal. - Tests : Quel est le niveau d'accessibilité visé et mesuré ? ; Des personas représentatifs des différents handicaps et déficiences sont-ils présents ? ; Des tests (contrastes, lisibilité, polices usabilité), effectués avec des outils ou des personnes en situation de handicap, sont-ils prévus ? - Cas d’usage : Les aspects reglementaires et légaux sont exprimés, validés et partagés - Niveau : C/A/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=4-uxui-au-dela-des-aspects-purement-reglementaires-lanticipation-7ec6ce #### Recommandation n°23 - Critère : Tout type d'utilisateur peut-il savoir facilement où il se trouve dans le service, par la mise en place d'un système de navigation inclusif ? - Justification : Plus le service est facile d'utilisation et bien construit, moins l'utilisateur passera de temps à trouver l'information qu'il cherche, ce qui réduira les navigations parasites et diminuera la consommation de ressources et d'énergie - Tests : Un repère de navigation (fil d'ariane ou équivalent) est-il présent ? ; Le plan du site est-il facilement accessible ? Le champ de recherche est-il présent et correctement positionné et indiqué ? Le titre de page est-il explicite ? ; Avez-vous suivi les bonnes pratiques de navigation sur les apps ? Les outils facilitant l'accessibilité relative aux terminaux sont-ils connus et utilisés (voiceover over et talkback) ? - Cas d’usage : Navigateur / Touches Clavier : TAB / SPACE / ENTER - Niveau : C/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=4-uxui-plus-le-service-est-facile-dutilisation-et-f6b950 ### Recommandation n°5 — "Less is More" : Concentrez vous sur les fonctionnalités essentielles et simplifiez votre interface #### Conseil n°24 - Critère : Une sobriété visuelle est-elle mise en place, pour limiter les ressources énergétiques et l'impact sur la dégradation matérielle des composants visuels, sonores et tactiles constitutifs de l'interface ? - Justification : Des éléments/composants visuels, sonores et tactiles peuvent être mis en avant dans une démarche purement esthétique et/ou marketing mais n'ont que très peu d'intérêt pour l'utilisateur. La simplification de ces éléments apportera une meilleure ergonomie et un usage adapté à chacun ainsi qu'une réduction de l'impact énergétique. - Tests : La charte graphique est-elle éco-compatible ? La charte graphique respecte-t-elle les normes d'accessibilité ? ; Une liste d'impacts énergétiques a-t-elle été réalisée ? Des objectifs de réduction d'impact sont-ils mis en place et partagés avec toute l'équipe ? ; Les designers en charge sont-ils formés au design visuel responsable ? - Cas d’usage : Un module dark mode est systématiquement proposé - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=5-uxui-des-elements%2Fcomposants-visuels-sonores-et-tactiles-peuvent-87c5e5 #### Recommandation n°25 - Critère : Est-ce que les fonctionnalités sont utilisées par l'utilisateur ? - Justification : Selon des études (cast software et standish group), 70% des fonctionnalités ne sont jamais ou rarement utilisées. (ref 115 bonnes pratiques) Le nombre de fonctionnalités disponibles dans un service numérique impactent directement la consommation de ressources et l'impact environnemental, en créant des fonctionnalités de peu d'utilité. Ce sont des sources de création de dettes environnementales totalement inutiles. Les fonctionnalités augmentent aussi le volume du service, qui introduisent des délais de chargements, des espaces de stockage supplémentaires. - Tests : Les fonctionnalités proposées sont-elles attendues et utilisées par vos cibles et apportent-elles une réelle valeur à votre produit ? ; Mesurer l'usage de chaque feature et limiter votre produit au juste besoin des utilisateurs ; Dans le respect des recommandations d'utilisation des outils de tracking, avez-vous mis en place des outils de suivi ? - Cas d’usage : Les parcours utilisateurs sont simulés et validés pour identifier les utilisations de fonctionnalités. Des données sont identifiées et collectées (analytics / sondes) en production. - Niveau : A/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=5-uxui-selon-des-etudes--70%25-des-fonctionnalites-9febc7 #### Recommandation n°26 - Critère : Les prises de décision sont-elles justifiées et soutenues par des indicateurs fiables sur les usages des fonctionnalités tout au long du cycle de vie du service ? - Justification : La supervision des usages permet de valider les estimations faites en début de conception et d'identifier les pistes d'amélioration. Mais ce principe se base sur des sources de données fiables. - Tests : Quelles données sont collectées, à quelle fréquence ? ; Des actions sont-elles associées aux données récoltées et analysées ? - Cas d’usage : Analyse d'impact - Niveau : C/B/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=5-uxui-la-supervision-des-usages-permet-de-valider-91d6f8 #### Recommandation n°27 - Critère : Une politique / démarche / une routine de réduction et de priorisation progressive des fonctionnalités, interactions et éléments graphiques, est-elle mise en place ? - Justification : Les suppressions d'éléments sur les interfaces peuvent ne pas perturber les utilisateurs, et donc générer une empreinte réduite avec moins d'éléments et de fonctionnalités sans que cela ne détériore la valeur du service tout en limitant son impact environnemental - Tests : Un outil permettant de prioriser et suivre l'usage des fonctionnalités tout au long du cycle de vie du service est-il utilisé ? ; La suppression des éléments non ou trop peu usités est-elle gérée ? - Cas d’usage : Backlog - Niveau : B/B/B - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=5-uxui-les-suppressions-delements-sur-les-interfaces-peuvent-6f95c5 #### Conseil n°28 - Critère : Les parties prenantes du service SEO sont-elles intégrées, dès la phase de conception ? - Justification : Les algorithmes d'optimisation ont tendance à accumuler des données, dans la majorité des cas les données collectées ne sont pas analysées et ne servent donc pas à rationaliser les usages. Les optimisations doivent s'inscrire dans une démarche itérative et chaque retour doit permettre un gain d'efficacité mesuré avant de passer à l'étape suivante. - Tests : Les retours SEO sont-ils pris en compte dans la phase de conception pour améliorer les impacts NR ? ; Lors d'opérations ciblées, une revue quotidienne de la performance SEO est-elle prévue ? ; L'analyse fine et les critères (ROI) de votre SEO sont-ils mis en place, avec une méthode pour éliminer/prioriser les éléments inefficaces ? - Niveau : C/C/B - Cycle de vie : Administration - Page : https://gr491.isit-europe.org/crit.php?id=5-uxui-les-algorithmes-doptimisation-ont-tendance-a-accumuler-88b831 #### Conseil n°29 - Critère : La pratique de l'e-mailing est-elle réfléchie, justifiée et réduite à son stricte nécessaire ? - Justification : Les diffusions de mails notamment lorsque les mails contiennent des contenus riches génèrent une charge environnementale importante. Dans le cas de diffusion en masse, ces impacts sont démultipliés. Le cas des newsletters est particulièrement sujet à cette explosion de trafic. Les contenus, volumes et cibles de diffusions doivent être réduits pour compenser par l'efficacité et la pertinence ce qui était pris en charge par la diffusion massive. - Tests : L'accès au désabonnement est-il rapide et facile pour l'utilisateur (sans demande de confirmation) ? ; Un suivi des performances de consultation de l'e-mailing est-il en place ? L'information partagée de l'e-mailing, apporte-t-elle une valeur à son lecteur ? L'archivage de l'e-mailing est-il géré ? ; Des campagnes de gestion de la Base de Données sont-elles prévues ? La base de contacts est-elle segmentée pour éviter des envois en masse ? - Niveau : A/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=5-uxui-les-diffusions-de-mails-notamment-lorsque-les-bb507e #### Recommandation n°30 - Critère : Un planning d'archivage et une version allégée des contenus anciens consultables sont-ils mis en oeuvre ? - Justification : Il est souvent produit une quantité non négligeable de fichiers, souvent versionnés, afin de répondre aux exigences client. Instaurer une bonne pratique de gestion des fichiers (livrables client comme internes) est essentiel. Trier et supprimer les versions obsolètes et non utilisables aura un impact positif sur le stockage. En effet, toutes ces données stockées ont un coût environnemental car liées à l'utilisation de serveurs le plus souvent, et représentent donc un coût financier important également. Définir une politique d'archivage des contenus contribuera à une gestion responsable et efficace de la production du service. - Tests : Les critères d'archivage et le planning sont-ils définis ? ; Une automatisation des archives est-elle mise en place ? ; Quel volume est gagné par le transfert en format brut ou allégé des contenus archivés qui restent consultables ? - Cas d’usage : La gestion de configuration prend en compte les contenus avec leurs mécanismes d'optimisations en fonction de l'ancienneté - Niveau : A/C/B - Cycle de vie : Fin de Vie - Page : https://gr491.isit-europe.org/crit.php?id=5-uxui-il-est-souvent-produit-une-quantite-non-e8402d #### Conseil n°31 - Critère : Est-ce que les analytics ont été limités au strict nécessaire pour optimiser le service ? - Justification : Les collectes de données d'analytics sont installées dans les codes sources et doivent être positionnées uniquement aux points de passage où elles apportent une possibilité d'amélioration de performance car leurs actions ne sont pas neutres; elles collectent, transmettent, stockent des données et alourdissent les services en rajoutant des codes exécutables qui demandent des ressources de traitements sur le périphérique utilisateur, sur les réseaux et sur les serveurs distants. De plus, les données collectées peuvent être transmises et utilisées par des tiers pour des usages dont l'utilisateur n'est pas toujours conscient. - Tests : L'utilisation des analytics est-elle optimisée au nécessaire ? ; Les outils mis en place ne présentent-ils pas de redondances ? ; Est-ce que les services analytics n'occupent pas plus de 30% de la performance et de la consommation de ressources ? - Niveau : B/B/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=5-uxui-les-collectes-de-donnees-danalytics-sont-installees-cf9e6c #### Conseil n°32 - Critère : Est-ce que les services tiers (fils réseaux sociaux, social wall, carrousels, google maps etc) ne sont pas utilisés par facilité pour pallier le manque de ressources de production de contenus ? - Justification : Il est courant d'utiliser des services tiers rattachés à l'utilisation des réseaux sociaux, géolocalisation, etc. L'utilisation de ces services tiers doit être au service de l'information et non pas de s'y substituer car leur usage est très gourmand en ressources, bande passante et batterie des terminaux notamment. Il est important de limiter leur usage au strict nécessaire afin de limiter leur impact environnemental. - Tests : Une alternative aux services tiers a-t-elle été envisagée, est-elle possible ? ; Les liens proposés par les services tiers sont-ils éliminés au prosperity de contenus utiles plus légers ? ; L'utilité des services tiers est-elle éprouvée systématiquement ? - Niveau : B/B/C - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=5-uxui-il-est-courant-dutiliser-des-services-tiers-5c8928 ### Recommandation n°6 — Permettre aux utilisateurs de réduire leurs impacts #### Conseil n°33 - Critère : L'utilisation du service permet-elle d'envisager des configurations logicielles ou matérielles moins impactantes pour l'environnement ? - Justification : Les équipements utilisateurs sont de plus en plus performants et les services numériques exploitent ces capacités techniques. Cela a pour effet d'accentuer la fracture numérique en excluant une partie des utilisateurs qui ne peuvent se procurer ces terminaux qui ont un coût financier important. Il est donc important de se questionner sur l'utilité du recours à ces technologies pour arriver à la finalité du service numérique tout en préservant l'accès au plus grand nombre. - Tests : Dans la recherche utilisateurs, des contraintes techniques, matérielles ou humaines qui nécessiteraient une version adaptée du service, ont-elles été identifiées ? ; Dès la première utilisation, un mode d'interface "dégradé", Off line ou moins énergivore du service, est-il poussé à l'utilisateur via une phase d'installation et/ou onboarding ? Les volumes de connexions simultanées ont-ils un impact sur les rendus de l'interface ? ; L'utilisateur a-t-il un accès simple et identifié pour gérer la qualité des médias ? - Niveau : A/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-uxui-les-equipements-utilisateurs-sont-de-plus-en-4faa80 #### Recommandation n°34 - Critère : L'expérience utilisateur prend-elle en compte les évolutions possible du service (ajout/suppression de fonctionnalités) ? - Justification : Un service numérique possède une durée de vie qu'il est important de prolonger au maximum. Il existe souvent une version bêta, puis suivent d'autres fonctionnalités viendront se rajouter au fil de temps. Il est important de soulever ces questions dès la conception du service avec les différents partenaires et clients afin de développer un service modulable et adaptable dans le temps. Cela permettra de limiter les coûts financiers à terme et environnementaux car le service sera évolutif, prolongeant ainsi sa durée de vie. - Tests : Les besoins futurs d'évolution du service ont-il été identifiés et planifiés ? ; Les mises à jour du service sont -elles appropriées et NR Compliant ? ; L'utilisateur peut-il choisir d'activer ou non des fonctionnalités de l'interface en fonction de ses besoins et des éventuelles mises à jour ? - Cas d’usage : Le processus d'amélioration continue se base sur le Backlog, les améliorations avec une orientation NR sont identifés par des Tags / Labels NR - Niveau : A/B/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-uxui-un-service-numerique-possede-une-duree-de-97cd59 #### Conseil n°35 - Critère : Tous les éléments constitutifs de l'interface font-ils l'objet d'une attention particulière en matière d'impact NR, tout en respectant les règles d'accessibilité ? - Justification : Plus le thème visuel est simple, plus il sera économe en ressources consommées pour l'afficher. Plus le service implémente de composants (charge sur les serveurs, les réseaux et les périphériques), plus l'impact du nombre d'utilisateur simultanés est important. La solution technique est souvent de surdimensionner les environnements de production pour assurer une meilleure fluidité sur service. Proposer aux utilisateurs de choisir une présentation du service moins gourmande contribuera à réduire l'impact environnemental (encombrement des réseaux et du surdimensionnement des infrastructures). Avec l'augmentation du nombre d'utilisateurs, le service s'allègera, le périmètre global restera constant et/ou maitrisé avec des moyens techniques justement dimensionnés. De plus, cela aura un rôle pédagogique : l'utilisateur pourra devenir acteur de sa propre consommation et de son impact environnemental. - Tests : Un thème visuel adapté (sombre/clair) est-il proposé à l'utilisateur, de manière simple, rapide et modifiable (automatiquement ou manuellement) , en fonction des différents terminaux ? Un thème "Low", épuré en terme d'éléments d'interface (visuels, animations, vidéos, tactiles, etc.) est-il expliqué et proposé à l'utilisateur dès sa première utilisation et peut-il modifier ce paramètre facilement à tout moment ? ; Tous les éléments constitutifs de l'interface (visuels, sonores, tactiles) font-ils l'objet d'une démarche de réduction d'impact et sont-ils éprouvés dans leur utilité ? ; Le design système est-il optimisé, applicable et appliqué tout au long de la vie du service ? Les paramètres de contraste, couleurs, luminosité sont ils identifiables facilement par l'utilisateur ? - Cas d’usage : CHROME : Extension lighthouse / Accessibilité - Niveau : A/A/B - Cycle de vie : Acquisition - Page : https://gr491.isit-europe.org/crit.php?id=6-uxui-plus-le-theme-visuel-est-simple-plus-bb203e #### Conseil n°36 - Critère : Des solutions sans interface "graphique" sont-elles prévues pour certaines fonctionnalités, afin de proposer des alternatives au design visuel dans l'interface ? - Justification : Une interface ne se résume pas seulement aux éléments visuels qui la constituent, il peut être intéressant de challenger les autres approches de l'expérience utilisateur afin de réduire l'impact du service. - Tests : Une version vocale ou conversationnelle de l'interface est-elle faisable, souhaitable pour l'utilisateur et le NR ? Si oui est-elle proposée à l'utilisateur dès sa première utilisation du service ? ; Une version gestuelle (eye tracking, touch, kinétique) est-elle prévue/envisageable et souhaitable ? - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=6-uxui-une-interface-ne-se-resume-pas-seulement-448af1 #### Conseil n°37 - Critère : Un espace de paramétrage orienté NR est-il à disposition de l'utilisateur, pour limiter au maximum le nombre d'éléments de présentation ? - Justification : Chaque action compte et l'utilisateur a pleinement son rôle à jouer dans la réduction de son incidence environnementale. Sensibiliser l'utilisateur et lui permettre d'en être acteur. Informer de l'impact de ses actions et proposer des alternatives simples et rapides permettront d'avoir un usage plus responsable du service et de développer une conscience collective, à terme, concernant la pollution numérique. - Tests : Existe-il un espace rapidement accessible, où l'utilisateur puisse gérer les paramètres dits “éco” de la UI ? ; Les conseils utilisateurs et/ou des challenges sont-ils proposés pour améliorer l'impact du service ? ; Des alertes sont-elles activables par l'utilisateur pour favoriser les bonnes pratiques (ex: Attention temps d'écran important, faites une pause) ? - Niveau : A/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-uxui-chaque-action-compte-et-lutilisateur-a-pleinement-d3da63 #### Recommandation n°38 - Critère : La dématérialisation du service est-elle complète, et dans le cas où la production de documents papier est indispensable, est-elle conçue pour limiter son impact au minimum ? - Justification : Les flux de dématérialisation sont parfois rompus, et imposent la production d'écrits sur papier. L'utilisateur, dans certains cas, peut aussi être plus confortable à utiliser des documents imprimés plutôt que 100% électroniques. Les impressions ont un impact environnemental important, que ce soit dans la consommation de papier, de consommables tels que les cartouches et encres d'impression. Les besoins de présentation en électronique ou en impression sont différents, d'autre part la limitation de l'empreinte environnementale doit conduire à réduire la densité et le volume d'information imprimé - Tests : Les écrans concernés par l'impression sont-ils identifiés et leur utilité est-elle démontrée ? ; Une feuille de style pour l'impression est-elle réalisée ? ; Est-ce que l'intégralité du contenu doit être imprimée ? Les éléments imprimables sont-ils traités (picto réseaux sociaux , background), les éléments non nécessaires à la lecture / compréhension d'une page sont-ils masqués ? - Cas d’usage : Des tests d'impression sont réalisés pour vérifier les consommations d'encre, papiers et la pertinence des informations imprimées. - Niveau : A/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-uxui-les-flux-de-dematerialisation-sont-parfois-rompus-3fe2d4 #### Recommandation n°39 - Critère : L'utilisateur peut-il controler l'activation de solutions tierces ? - Justification : Les connexions externes au service peuvent apporter de la valeur au service, mais dans certains cas lier l'utilisateur avec des pratiques auxquelles il n'adhère pas. Le choix de l'utilisation des services tiers doit être transparent et dévolu à l'utilisateur. - Tests : Le service numérique permet-il à l'utilisateur de décider de l'activation d'un service tiers ? - Cas d’usage : Cartographie des services périphériques - Niveau : A/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=6-uxui-les-connexions-externes-au-service-peuvent-apporter-cc68d9 ### Recommandation n°7 — "Barebone Iteration": Itérer votre solution jusqu'au minimalisme "acceptable" par vos utilisateurs #### Recommandation n°40 - Critère : Une méthode de démarche systémique est-elle en place, maîtrisée par les acteurs et associée à des outils ? - Justification : Se lancer dans un projet sans prendre en compte l'écosystème du projet/contexte peut avoir un impact conséquent sur le ROI. Mettre en place une démarche systémique et itérative permet d'être plus efficace et responsable pour répondre aux besoins et réduire alors les délais de ROI. - Tests : Les outils du Sytem Design ont-ils été utilisés ? ; Combien de personnes maîtrisent cette méthode ? ; Des outils liés à la méthode sont-ils mis à disposition ? - Cas d’usage : Framework systémique - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=7-uxui-se-lancer-dans-un-projet-sans-prendre-57c075 #### Recommandation n°41 - Critère : Est-ce que la solution a été prototypée en amont, avec le parcours utilisateur et les interactions ? - Justification : Le prototypage interactif permet, à moindre coût, d'avoir une vision graphique, ergonomique et technique de la future solution, de naviguer mais aussi de la tester. Par itération, le prototype sera de meilleure qualité. - Tests : Les prototypes sont-ils validés par toutes les parties prenantes et existe-il un système de suivi de validation de ces derniers ? - Cas d’usage : Tests utilisateurs - Niveau : C/A/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=7-uxui-le-prototypage-interactif-permet-a-moindre-cout-13441b #### Recommandation n°42 - Critère : Le comportement et le feedback utilisateur ont-ils été étudiés pour répondre au mieux à leurs besoins ? - Justification : Le projet est réalisé pour des utilisateurs, ne pas prendre en compte leurs comportements, leurs retours d'utilisation de la solution n'est pas recommandable. Faire tester sa solution auprès d'un panel d'utilisateurs permet d'avoir un réel feedback terrain et d'ajuster le projet pour mieux répondre aux besoins. - Tests : Les prototypes statiques et animés sont-ils testés sur le panel étudié ? ; Les besoins clients sont-ils différenciés des besoins utilisateurs ? ; Des Users stories (couverture de tests) sont-elles rédigées ? - Cas d’usage : Sondage / évaluation user - Niveau : C/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=7-uxui-le-projet-est-realise-pour-des-utilisateurs-a069c4 #### Recommandation n°43 - Critère : La conception est-elle documentée (fonctionnellement et techniquement), les livrables de conception doivent être intelligibles par l'équipe projet et transférables à l'équipe de développement ? - Justification : Trop de documents inadaptés sont produits lors des phases de conception. Une synchronisation entre les différents niveaux d'attentes (tant sur le fond que sur la forme) améliorera la conduite du projet et évitera les frustrations de toutes parts ainsi que l'impact énergétique et humain. - Tests : Les processus et formats d'échanges de spécifications ont-ils été discutés et validés entre les concepteurs, les développeurs et plus largement les parties prenantes ? ; Est-ce qu'une production de spécifications associée aux schémas de conception est prévue ? ; Des outils de conception permettant un export pour développement prenant en compte des recommandations métiers, fonctionnelles et techniques, sont-ils utilisés? - Cas d’usage : Documentation technique - Niveau : B/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=7-uxui-trop-de-documents-inadaptes-sont-produits-lors-2e52c7 #### Recommandation n°44 - Critère : Est-ce que les recherches les plus fréquentes ont été étudiées et adressées pour qu'elles soient ou mises en cache ou affichées à l'utilisateur sans envoi de requête ou clics inutiles. ? - Justification : L'utilisation des moteurs de recherches internes au service permettent aux utilisateurs d'accéder plus rapidement aux informations en limitant la navigation sur le service. Ces moteurs de recherche sont donc un atout d'un point de vue efficacité environnementale et assistance à l'utilisateur. En revanche ils peuvent ne pas disposer de toutes les réponses et s'appuient sur des ressources distantes qu'il est coûteux de consulter. Il est important de réduire les échanges entre votre service et les serveurs distants pour de ne pas annuler le bénéfice acquis par l'utilisation du moteur de recherche. - Tests : Une liste des services les plus demandés et les "fail requests" est-elle constituée ? les "power requests" sont-elles précisées ? ; Une liste des requêtes les plus formulées est-elle constituée ? ; Existe-t-il des solutions d'accomppagnement de l'utilisateur dans la qualification de sa recherche afin de limiter le nombre de requêtes envoyées au serveur ? - Cas d’usage : Dossier technique - Niveau : C/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=7-uxui-lutilisation-des-moteurs-de-recherches-internes-au-cfd836 #### Conseil n°45 - Critère : Le chemin parcouru pour accéder au service est-il le plus rapide et le plus simple possible ? - Justification : Il y a plusieurs scénarios d'accès aux services et/ou information d'un applicatif. Il faut les examiner et les faire coexister afin d'améliorer l'expérience des utilisateurs. - Tests : Le nombre d'étapes et le temps sont-ils inclus dans les users journey/maps ? ; Le nombre d'étapes et le temps sont-ils inclus dans les tests du service par tous les types d'utilisateurs ? - Niveau : B/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=7-uxui-il-y-a-plusieurs-scenarios-dacces-aux-0f9739 #### Recommandation n°46 - Critère : Une démarche d'amélioration continue a-t-elle été mise en place ? - Justification : Au fil du temps, l'organisation va augmenter sa maturité NR. Les services doivent pouvoir bénéficier de ces progrès pour s'enrichir de plus d'intelligence NR embarquée - Tests : La conception est-elle pensée de manière itérative ? ; Toutes les parties prenantes sont-elles identifiées et consultées aux moments clés pour la prise en compte de leurs retours ? - Cas d’usage : Backlog - Niveau : C/B/A - Cycle de vie : Maintenance - Page : https://gr491.isit-europe.org/crit.php?id=7-uxui-au-fil-du-temps-lorganisation-va-augmenter-1f90a2 ### Recommandation n°8 — Ingénierie média : alléger au maximum les médias du service numérique ( images, animations, contenu ... ) #### Recommandation n°47 - Critère : Est ce que la fonctionnalité peut être proposée sans l'appel de scripts ou de bibliothèques externes (JS, AJAX, ...) ? - Justification : Les périphériques utilisateurs disposent de ressources de traitement, la mise en oeuvre de ces ressources consomme de l'énergie et nécessite de transporter vers le périphérique utilisateur les codes exécutables. En réduisant l'utilisation de scripts qui fonctionnent sur le poste utilisateur les 2 aspects sont atténués. De plus, certains utilisateurs peuvent ne pas pouvoir utiliser des scripts. - Tests : Combien de fonctions sont gérées via des bibliothèques externes ? - Cas d’usage : Le code source est analysé pour identifier les appels de bibliothèques externes - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=8-uxui-les-peripheriques-utilisateurs-disposent-de-ressources-de-ec1700 #### Conseil n°48 - Critère : La fonctionnalité cible nécessite -t-elle l'appel d'une iFrame ? - Justification : L'accessibilité d'une iframe étant nulle et l'ergonomie de la page proposant le service étant restreinte, l'iFrame est une solution qui dégradera l'experience utilisateur. - Tests : Une solution API est-elle disponible ? ; Combien d'iFrame sont utilisées dans le service ? Combien sont indispensables pour des raisons de sécurité (Modules de paiements, ....) ? - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=8-uxui-laccessibilite-dune-iframe-etant-nulle-et-lergonomie-cdafe2 #### Recommandation n°49 - Critère : Une politique de gestion/utilisation des médias afin de réduire leurs impacts est-elle en place, avec des critères de compression et de formats des médias ? - Justification : Le volume de données transférées augmente l'empreinte environnementale du service. Il est nécessaire de proposer les médias nécessaires à l'affichage du service dans la compression idoine afin d'améliorer le service et augmenter sa sobriété. - Tests : Une checklist de qualité environnementale des médias utilisés dans le service est-elle utilisée ? ; L'automatisation de compression de tous les médias utilisés est-elle mise en place ? ; Une alternative à chaque média a-t-elle été proposée (remplacement d'une vidéo par une image ou du texte par ex.) ? - Cas d’usage : Les outils/consoles de développement et les extensions des navigateurs permettent de vérifier les bonnes pratiques (ex : CHROME - Extension greenIT / bonnes pratiques) - Niveau : A/B/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=8-uxui-le-volume-de-donnees-transferees-augmente-lempreinte-80697b #### Recommandation n°50 - Critère : Le nombre de polices de caractères (fonts) et les variantes de polices appelées (graisse, caractères utilisés dans le projet) sont-ils limités ? - Justification : Les polices de caractères peuvent être très volumineuses. En réduisant le nombre de polices uniquement à celles utilisées dans le service, la volumétrie échangée diminue. - Tests : Une typo système peut-elle être utilisée ? ; Lorsqu'une typo externe est utilisée, son poids a-t-il été vérifié et existe-t-il une alternative plus légère ? ; Le fichier typographique chargé est-il limité aux stricts caractères, langues et graisses utiles pour le service, la création d'une sub-font est-elle envisagée ? Lors de l'intégration de polices propriétaires, les formats récents optimisés (par ex : WOTF2) sont-ils utilisés ? - Cas d’usage : Les outils/consoles de développement et les extensions des navigateurs permettent de vérifier les bonnes pratiques (ex : FIREFOX - console / alertes) - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=8-uxui-les-polices-de-caracteres-peuvent-etre-tres-7741b4 #### Recommandation n°51 - Critère : Est-ce que les fonctionnalités et composants natifs du système peuvent correspondre au besoin ? - Justification : Certaines fonctionnalités sont disponibles sous plusieurs formes. Lorsqu'elles sont natives, aucun code ou composants supplémentaires ne sont nécessaires pour les utiliser ce qui réduit l'impact du service. - Tests : Le fait que le système ne propose pas nativement le service est-il établi ? ; À fonctionnalités égales, le système natif est-il plus efficace que l'alternative imaginée ? - Cas d’usage : Code source - Niveau : B/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=8-uxui-certaines-fonctionnalites-sont-disponibles-sous-plusieurs-formes.-6d5705 #### Recommandation n°52 - Critère : Les vidéos et animations sont-elles utilisées uniquement lorsqu'elles apportent une valeur pour l'utilisateur ? - Justification : Les flux vidéo et les animations génèrent un volume de données important. La limitation des vidéos réduit la charge environnementale du service. Certains publics ne sont pas en mesure d'utiliser des vidéos, ils seront donc exclus du service si celui-ci s'appuie sur ce type de média. - Tests : Les informations de la vidéo ou de l'animation ne peuvent-elles pas être retranscrites dans un format alternatif ? ; Le poids total, le format et la résolution de chaque vidéo ou animation sont-ils correctement calibrés ? - Cas d’usage : Les parcours utilisateur présentent les objets média et la valeur ajoutée des informations proposées par ces objets - Niveau : A/B/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=8-uxui-les-flux-video-et-les-animations-generent-f5d6cc #### Recommandation n°53 - Critère : Les images sont-elles optimisées par rapport à leurs fonctions ? - Justification : Le volume de données échangées pour la présentation d'une image dépend de sa taille et de la qualité de son format. Certaines images ont des valeurs d'information importantes, d'autres ne sont que de l'illustration. Les consommations de ressources liées doivent donc être en rapport avec l'importance de l'image et permettre à des publics pour lesquels les images ne sont pas accessibles de comprendre leur signification. - Tests : Est-ce que les images utilisées sont adaptées à leurs formats/tailles d'affichage ? ; Les images vectorielles ont-elles un format qui le supporte (SVG) ? ; Est-ce que les pictogrammes et illustrations sont exportés au format SVG ? - Cas d’usage : Les outils/consoles de développement et les extensions des navigateurs permettent de vérifier les bonnes pratiques (ex : CHROME - Extension greenIT / bonnes pratiques) - Niveau : A/B/B - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=8-uxui-le-volume-de-donnees-echangees-pour-la-f5ebc8 ### Recommandation n°9 — Valeur : soyez transparent avec vos utilisateurs #### Conseil n°54 - Critère : Les informations partagées sont-elles utiles à l'utilisateur ? - Justification : L'efficacité d'utilisation d'un service numérique est basée sur la compréhension par l'utilisateur de la manière de satisfaire ses attentes. Les informations que le service numérique communique doivent permettre cette efficacité, en revanche des informations parasites peuvent brouiller sa compréhension et engendrer des comportements qui ne sont pas optimum et qui génèrent donc des actions inutiles pour l'utilisateur et impactantes pour l'environnement. - Tests : Les informations utiles sont-elles accessibles tout au long des parcours utilisateurs ? - Niveau : C/B/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=9-uxui-lefficacite-dutilisation-dun-service-numerique-est-basee-1d2e38 #### Recommandation n°55 - Critère : La notification de toutes les interactions machine / utilisateur ont-elles été prises en compte pour donner systématiquement à l'utilisateur le résultat de ses actions et gérer les erreurs ? - Justification : Les actions déclenchées par l'utilisateur peuvent conduire à des erreurs. Afin d'éviter que l'utilisateur ne répète les mêmes erreurs il doit être informé du fait qu'une erreur est survenue et indiquer la cause ou le mode opératoire pour la corriger. A l'inverse lorsqu'une action se déroule sans anomalie, l'utilisateur doit aussi le savoir pour ne pas réitérer une même action. - Tests : Tous les cas d'erreurs sont-ils testés en interne et par des utilisateurs finaux ? ; Les actions utilisateurs comportent-elles un feedback avec un intitulé clair et une solution ? ; Un fichier répertoriant tous les cas d'erreurs existe-t-il ?sous quel format (backlog, experience map, .. ) ? - Cas d’usage : Navigation / parcours utilisateur - Niveau : B/A/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=9-uxui-les-actions-declenchees-par-lutilisateur-peuvent-conduire-954d0c #### Conseil n°56 - Critère : Les feedbacks utilisateurs d'évaluation du service sont-ils pris en compte ? - Justification : La mesure de la satisfaction ou insatisfaction des utilisateurs est un marqueur important de retour d'expérience qui permet d'améliorer la qualité de service et traiter les cas erronés qui ne seraient pas directement visibles mais introduiraient des conséquences sur la performance globale du service pour remplir les fonctionnalités attendues. - Tests : Un canal de conversation, de remontée sur la qualité des services et contenus proposés est-il disponible et utilisé dans le cadre de l'amélioration des services et contenus ? ; Un planning d'enquête est-il mis en place ? ; Dans le cas d'une App, une récurrence de consultation des notifications disponibles sur le store est-elle en place? - Niveau : C/B/A - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=9-uxui-la-mesure-de-la-satisfaction-ou-insatisfaction-d9e358 #### Conseil n°57 - Critère : L'utilisateur a-t-il les moyens de vérifier simplement les informations exposées dans le service ? - Justification : Lorsque les informations communiquées ne sont pas jugées fiables par les utilisateurs, cela peut engendrer des recherches supplémentaires pour confirmer des assertions et génère une navigation parasite. D'autre part, la crédibilité du service peut être remise en cause et écartée par les utilisateurs. Les utilisateurs ont le droit d'avoir des informations fiables, les éditeurs de service ont le devoir de respecter leurs utilisateurs en transmettant des informations vérifiées. - Tests : Un processus de vérification de la transparence est-il en place ? ; Les sources des informations données sont-elles accessibles par l'utilisateur ? - Niveau : C/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=9-uxui-lorsque-les-informations-communiquees-ne-sont-pas-a44978 #### Recommandation n°58 - Critère : Chacune des actions sont-elles initiées par l'utilisateur ? - Justification : Le mode de fonctionnement du service numérique doit être transparent vis-à-vis de l'utilisateur, les actions proposées doivent être clairement décrites et les conséquences exposées. - Tests : Une carte des interactions du service a-t-elle été réalisée afin de garantir une action utilisateur à chaque action ? ; Est-ce que les confirmations d'actions sont limitées en exprimant les conséquences ? - Cas d’usage : Les validations de parcours utilisateur couvrent la recherche de comportments du service ou l'utilisateur n'a pas l'initiative de l'opération ou n'et pas informé du résultat - Niveau : A/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=9-uxui-le-mode-de-fonctionnement-du-service-numerique-cee095 #### Conseil n°59 - Critère : Les utilisateurs sont-ils informés que des informations confidentielles sont collectées ? - Justification : Les données que les utilisateurs confient sont sous votre responsabilité et les utilisateurs doivent être tenus informés du soin que vous mettez en oeuvre pour assurer la confidentialité de leurs données. Le RGPD impose un cadre pour les données personnelles mais ne couvre pas les autres catégories de données qui mériteraient pourtant les mêmes attentions et précautions. - Tests : Les utilisateurs sont-ils informés de l'utilisation qui sera faite de leurs informations confidentielles ? Les informations de l'utilisation des données collectées sont-elles rendues accessibles et facilement consultables, le DPO a-t-il été consulté ? Les cases à cocher des formulaires ne sont-elles pas préremplies ? ; Le droit à l'oubli des informations confidentielles est-il exposé aux utilisateurs ? ; L'accès aux préférences RGPD est-il en permanence accessible et modifiable par l'utilisateur ? La cinématique de gestion des cookies acceptés / refusés a-t-elle été réfléchie lors de la conception ? - Niveau : C/A/B - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=9-uxui-les-donnees-que-les-utilisateurs-confient-sont-c2ea45 ### Recommandation n°10 — Valeur: concevez un Service Numérique éthique, en ligne avec vos valeurs #### Recommandation n°60 - Critère : Le service évite-t-il les Dark Patterns ? - Justification : Certains services sont pensés pour créer une certaine forme de dépendance à celui-ci. L'utilisateur ne doit pas être soumis et exposé à certaines mécaniques de sur-consommation numérique. - Tests : La Force Continuity (perpétuation d'abonnement) peut-elle être bannie dans les services proposés ? ; Le principe de "Friend spam" est-il exclu ? ; L'autoplay en continu des vidéos est-il désactivé par défaut (Binge watching) ? Aucune contre-partie n'est-elle demandée en feedback d'une action utilisateur ? La "technique Privacy Zuckering" afin de forcer l'utilisateur à partager publiquement des informations personnelles est-elle exclue ? Est-il possible de la supprimer ou à défaut, d'expliquer à l'utilisateur dans quel but elle est en place ? - Cas d’usage : Réalisation d'une étude de captologie - Niveau : A/B/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=10-uxui-certains-services-sont-penses-pour-creer-une-6f419d #### Recommandation n°61 - Critère : Les normes légales d'affichage et de communication sur le RGAA (service publique et Société privée de plus de 250 M d'€ de CA) sont-elles prises en compte ? - Justification : Tous support numérique doit être accessible par tout à chacun. Il est nécessaire de pouvoir tenir informé l'utilisateur du niveau d'accessibilité et des efforts en cours pour améliorer le service. Ces informations doivent être disponibles et explicitement fléchées dans le parcours de l'utilisateur. - Tests : Les évaluations de conformité RGAA sont-elles disponibles ? ; Existe-t-il des "coûts cachés" pour l'utilisateur dans un parcours de paiement qui ne seraient pas bien perçus par certains publics ? ; La démarche NR est-elle exposée aux utilisateurs afin qu'ils puissent adapter leurs usages ? - Cas d’usage : Déclaration d'accessibilité - Niveau : C/A/A - Cycle de vie : Réalisation - Page : https://gr491.isit-europe.org/crit.php?id=10-uxui-tous-support-numerique-doit-etre-accessible-par-8174d4 #### Recommandation n°62 - Critère : Des règles en matière de respect de l'utilisateur sont-elles mises en place ? - Justification : Certains services sont pensés pour créer une certaine forme de dépendance à celui-ci. L'utilisateur doit pouvoir rester objectivement juge de sa consommation numérique - Tests : Une charte éthique numérique est-elle définie ? ; Un diagnostic du design attentionnel a-t-il été réalisé ? L'éthique du projet a-t-elle été testée auprès du référent juridique / éthique ? ; La Misdirection (manipulation, même visuelle, pour orienter les choix utilisateurs) est-elle pratiquée ? L'usage des notifications est-il limité au strict nécessaire ? - Cas d’usage : Réalisation d'une étude de captologie - Niveau : B/A/A - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=10-uxui-certains-services-sont-penses-pour-creer-une-7c7b6b #### Recommandation n°63 - Critère : Est-ce que les publicités sont bien identifiées comme telles et ont-elles une vraie valeur économique dans le service ? - Justification : La publicité ciblée ou non peut être une source de revenus incontournable pour le service numérique, la valeur apportée doit être suffisante pour justifier ces encarts promotionnels, et les utilisateurs ne doivent pas pouvoir confondre ces bannières de publicité et les contenus du service. - Tests : Les publicités sont-elles désactivables ? ; Les publicités sont-elles identifiables visuellement simplement par l'utilisateur ? ; D'un point de vue éthique, les publicités sont-elles liées au contenu du site ou au comportement de l'utilisateur ? Une politique Numérique Responsable ou à minima des KPI sur l'intérêt de la publicité pour l'utilisateur sont-ils en place ? - Cas d’usage : Analyse de bénéfices - Niveau : B/A/B - Cycle de vie : Conception - Page : https://gr491.isit-europe.org/crit.php?id=10-uxui-la-publicite-ciblee-ou-non-peut-etre-558d4f #### Recommandation n°64 - Critère : Dans quelle mesure l'attention de l'utilisateur est-elle contrôlée par le service ? - Justification : L'attention de l'utilisateur est une ressource qui doit être considérée comme rare et précieuse. Dans cette optique le respect de l'utilisateur passe aussi par sa capacité à concentrer son attention sur les éléments de son choix, plutôt que ceux que le service souhaiterait mettre en avant. - Tests : Un diagnostic du design attentionnel a-t-il été réalisé ? ; Lors des séances d'idéation, le pire scénario pour les utilisateurs a-t-il été envisagé ? - Cas d’usage : Etude de captologie - Niveau : B/A/C - Cycle de vie : Utilisation - Page : https://gr491.isit-europe.org/crit.php?id=10-uxui-lattention-de-lutilisateur-est-une-ressource-qui-d8f819