Retour sur le challenge Design4Green 2020
Du 4 au 6 novembre, l’équipe Spécinov a participé pour la troisième fois au challenge Design4Green : une compétition internationale de 48h d’écoconception numérique ouvertes aux étudiants comme aux professionnels.
À lire : Qu’est-ce que l’écoconception ?
Quel était le sujet du Design4Green 2020 ?
Élaboré par l’Institut du Numérique Responsable (INR), le sujet de cette année consistait en la refonte d’un outil cartographique permettant la visualisation d’indices de fragilité numérique par territoire.
En respectant les règles d’écoconception, les équipes avaient 48h pour développer un outil de recherche fonctionnel affichant l’indice de fragilité d’une commune par rapport à son département et à sa région.
Le projet développé par l’équipe Spécinov
Cette année, nous sommes fiers de conserver notre place sur le podium du Design4Green en étant second au classement entreprises !
Conception générale
Une application écoconçueNous avons intégré dans l’application toutes nos bonnes pratiques d’écoconception logicielles que nous avons l’habitude de mettre en œuvre sur les projets clients. Voici quelques bonnes pratiques mises en place :
- Compression des réponses : Toutes les réponses envoyées par le serveur sont compressées avec gzip pour limiter le volume de données transitant sur le réseau.
- Minification des ressources : La compilation Webpack Angular intègre la minification de toutes les ressources (javascript, CSS, …) pour réduire le volume de données envoyées sur le poste client.
- Mise en cache : Les réponses envoyées au client contiennent l’attribut Cache-Control dans le header pour que le client utilise les éléments mis en cache sans réinterroger le serveur.
- Limitation du nombre de requêtes : Le nombre de requêtes est limité, on veille à ne pas multiplier les appels API.
- Limitation du volume de données transférées : Le volume de données envoyé sur le réseau est limité pour réduire la charge réseau et l’impact environnemental de l’utilisation de l’application. Le volume de données total qui transite sur le réseau pour l’accès à la page de connexion est de 295Ko environ ce qui est faible au regard des fonctionnalités offertes.
- Limitation de la taille du DOM : L’application a été conçue pour que la taille de son DOM reste limitée pour réduire les temps de traitement JavaScript sur le client.
- Gestion des images : La gestion de la taille et de la compression des images a été optimisée. Le format vectoriel SVG est utilisé pour la mise en place des icônes, il permet d’avoir un poids très réduit pour les images « simples » tout en ayant une qualité d’affichage optimale.
- Framework CSS : Le CSS de l’application se base sur le framework Pure CSS qui est un framework light pesant seulement 0.9 ko.
- Gestion de la carte : Par défaut la représentation graphique des données sur la carte est désactivée pour que seuls les utilisateurs réalisant une recherche chargent les données liées à ce composant.
- Génération PDF : La génération du document PDF exporté est réalisée par le backend pour ne pas charger un composant côté front qui n’est pas forcément nécessaire pour tous les utilisateurs.
Sécurisation et RGPD
Les directives du RGPD sont également respectées. Les informations relatives au stockage des données personnelles sont consultables par l’utilisateur de l’application grâce à un bouton RGPD dédié.
Conception technique
Langage choisiPour réaliser cette application nous avons choisi l’architecture technique suivante :
Le serveur Debian expose via Nginx un front end Angular et un back end .NET Core 3.1. Le front end Angular 10 s’exécute sur le poste du client et appelle les API .NET Core du back end.
La technologie Angular a été sélectionnée car elle permet, via la compilation JavaScript Webpack, de réduire sensiblement la taille du package envoyé sur le navigateur client. L’application complète chargée sur le navigateur client pèse 295 ko.
De plus, dans cette architecture tous les appels API sont maitrisés ce qui permet de réduire le nombre de requêtes HTTP et le poids des données ramenées par chaque appel.
Enfin, cette stack technologique est mature et robuste et nous avons pu l’éprouver dans des contextes clients contraints.
Optimisation des requêtesLes requêtes entre le client et le serveur ont été fortement optimisées en suivant 2 axes de travail : la limitation du nombre de requêtes et la limitation du volume de chaque requête.
Ce travail d’analyse a notamment été poussé sur les 4 listes de filtrage et de sélection : Région, Département, Intercommunalité, Commune.
En effet, les deux premières listes ayant un nombre d’éléments restreint on récupère auprès de l’API le contenu des listes à l’ouverture de l’application. On limite ainsi le nombre de requêtes.
Pour les deux autres le nombre d’éléments étant important, il n’est pas pertinent de tout récupérer à l’ouverture de l’application. La recherche est donc réalisée à la saisie clavier de l’utilisateur, on limite ainsi le volume de données remontées. Pour ne pas avoir un trop grand nombre de requêtes, la recherche est réalisée après la saisie de 3 caractères et après un timeout.
Enfin, la dernière recherche réalisée par l’utilisateur est stockée dans le LocalStorage du navigateur. Ainsi, à sa reconnexion on recharge les données à partir du LocalStorage sans refaire d’appel API.
Conception fonctionnelle
Nous avons fait le choix d’intégrer un outil de représentation graphique qui présente un intérêt fort pour visualiser le niveau de fragilité numérique d’une commune vis-à-vis des communes qui l’entoure.
La frugalité des fonctionnalités étant un axe fort de l’écoconception, nous avons fait le choix de conserver la cartographie. Elle présente un intérêt fort pour l’application dont le but premier est de comparer la fragilité numérique d’un territoire vis-à-vis des territoires qui l’entoure.
Découvrir nos services d'écoconception numérique
Design et accessibilité
Aux couleurs du nouveau logo de l’INR, le design du site se veut simple et moderne.
En tant qu’outil numérique détectant les situations d’exclusions numériques sur le territoire, il était primordial de développer un design garantissant la facilité d’utilisation et l’accessibilité.
Garantir la facilité d’utilisation- En conservant uniquement les quatre champs de filtrage utiles pour comparer l’indice de fragilité d’une commune par rapport au département et à la région auxquels elle appartient.
- En donnant la possibilité de choisir une commune par deux moyens : filtrage grâce aux listes déroulantes ou navigation sur la carte.
- En interprétant les indices de fragilité par une donnée chiffrée et un code couleur gradient.
Garantir l’accessibilitéL’interface a été conçue de façon ergonomique avec un chemin de navigation simple pour rester accessible.
Les éléments textuels et graphiques ont une taille et un contraste suffisant dans le respect des directives WCAG 2.0.
Tous les contenus qui ne sont pas de type texte contiennent les balises nécessaires pour la lecture du contenu alternatif de description.
Découvrir l'audit d'accessibilité
Encore bravo aux 5 membres de l’équipe Spécinov pour le travail fourni et aux 278 autres participants de cette édition 2020 du Design4Green.
Rendez-vous l’année prochaine pour obtenir la première place !
