Sommaire

1. Les femmes dans vos équipes tech
2. Rendez les états impossibles inatteignables dans vos frontends
3. Sustainable by design
4. Alice au pays d’Opentelemetry
5. Débuter dans l'accessibilité numérique

Les femmes dans vos équipes tech

Par Gaëtan Bremond

Pourquoi vous ne les attirerez pas et ne les retiendrez pas !

Cette édition de BDX.io avec pour thème “Les femmes dans l’IT” s’ouvre naturellement par une conférence de Marcy Ericka Charollois au titre accrocheur et volontairement provocateur.

En effet, nul besoin d’avoir fait une thèse en sociologie pour comprendre que notre industrie est une industrie d’hommes avec un groupe majoritaire assez  homogène de personnes ayant entre 25 et 35 ans ayant fait une école d’ingénieur. Les statistiques ne manquent pas avec seulement 30% de femmes dans l’IT tout poste confondu, 52% des femmes qui pensent que leur genre est/sera un problème dans leur carrière, le manque de légitimité ressenti par les femmes pour postuler  , etc.. Mais alors pourquoi ? Et quelles solutions existent pour permettre une meilleure diversité ?

La notion principale présentée par lors de cette keynote est l’habitus théorisé par Pierre Bourdieu.

L’habitus désigne un système de préférences, un style de vie particulier à chacun qui influence les pratiques des individus au quotidien. Ces prédispositions sont intériorisées inconsciemment car l'individu s’adapte et s’intègre à un environnement social.

De manière plus pragmatique, l’habitus se construit dès le plus jeune âge aux travers des valeurs que vous transmettent vos familles, l’école (primaire, supérieure, etc.), mais aussi votre corps (prendre de l’espace, explorer, etc.) voir même votre langage (couper la parole, lexique, etc.). Cela a pour effet de créer des regroupements  homogènes autour de codes (vestimentaires, valeurs, etc.) qui se retrouvent en tant que groupe majoritaire décisionnaire (pour le recrutement par exemple). Ce groupe devient par la même occasion biaisé :

• biais de confirmation : chercher des indices confirmant l’idée qu’on se fait d’une personne;
• effet de halo : réassurance de votre première impression;
• biais de sympathie/antipathie : confirmer son avis au sein du groupe
• etc.

Tous ces biais amènent à l’apparition d’un statu quo représentant l’état actuel de la structure sociale et de ses valeurs. C’est ce statu quo qui entraîne des réflexions comme :

• Je n’ai rien contre le féminisme mais …
• J’ai du mal avec les femmes qui ne sont pas douces, gentilles, polies, etc.
• Mais pourquoi X est moins performante que Y ? (comparaison de femmes à femmes)

Une fois ce constat effectué, on fait face à une résistance au changement tout à fait naturelle qui a été étudiée. La majorité des personnes (70%) est neutre,  encore en réflexion sur la conduite à adopter et se retrouve face à deux groupes diamétralement opposés avec 15% de réfractaires quasi-impossibles à convaincre et 15% de personnes partantes/motrices du changement.

Même au sein du groupe de personnes partantes on peut se retrouver face à des problématiques :

• Je veux aider mais je ne sais pas par où commencer.
• On veut mettre en place des actions mais sont-elles bonnes ?
• On a besoin de rôles modèles.

Pour répondre à ça Marcy, propose un ensemble de solutions (résumé non exhaustif) :

Soyez proactifs

• Intervenir auprès des femmes directement au sein des formations.
• Ne pas juger les profils reconvertis (problématiques d’orientation genrées).

Attirez les femmes

• Féminisez votre titre de poste.
• Attention aux recherches (recherche Linkedin "Développeur" VS "Développeuse").

Mettez en avant

• Vos actions.
• Des témoignages de femmes talentueuses.

Evitez

• De comparer les femmes entre elles.
• De vous autoproclamé bienveillants/alliés.

Retenez

• Avec une culture safe (comprendre les privilèges).
• Avoir une parole libérée sans interruptions.
• Être à l’écoute et faire preuve d’empathie.
• Poser des questions pour éviter la posture sachant.e/ignorant.e.

Offrez des ressources

• Autour de la parentalité, menstruation (congés menstruel).
• Assistance psychologique, mutuelle, etc.
• Souplesse de l’emploi du temps.
• Mentorat interne.

Encouragez

• A prendre la parole.
• En investissant dans leurs actions d’empowerment (conférences, formations sociales, etc.).
• A devenir un rôle modèle parce qu’elle est compétente.

Il est impossible de détailler un sujet aussi complexe en si peu de lignes et les solutions proposées par Marcy vont plus loin que ces simples mots, donc je vous invite à aller voir le replay de cette Keynote d’ouverture.

Maintenant pensez au statu quo : vous le maintenez ? vous le brisez ?

Rendez les états impossibles inatteignables dans vos frontends

Par Sébastien Oddo

Présentation d’une machine à états avec XState

Un quickie après la pause déjeuner, quoi de mieux pour se remettre en forme en vue de l’après-midi ?

Il existe différentes façons de gérer des états sur une application front-end. Quand l’application grossit, l’état applicatif global se mêle aux états locaux des différents composants.

• Etat représenté par un objet simple modifié de manière synchrone (“useState” de React)
• État plus complexe, modifié  de façon asynchrone par un système d’évènements (Redux avec React)
• Système d’état et de transition que nous allons voir avec la librairie XState

Il est dans ce genre de cas de plus en plus complexe de s'assurer que tous ces états fonctionnent bien ensemble et que l'on ne tombe pas dans un "état impossible" par accident.

Une machine à états va permettre de forcer la définition de tous les états possibles ainsi que les transitions entre eux. C’est ce que propose la librairie XState, qui décrit les états et les transitions via un objet JSON. Elle permet même de gérer plusieurs états en parallèle.

La conférence s’est terminée par une démonstration de code autour de cette librairie, en prenant l’exemple d’un formulaire simple à soumettre pour savoir si on préfère le beurre doux ou le beurre salé en fonction de son département en France (true story).

Une extension XState pour Visual Studio Code permet de faciliter la conception et la visualisation de tous les états de sa machine.

Si vous voulez mon avis hautement objectif de cet outil : étant très rigoureux, il me plaît bien car agréable à utiliser avec l’extension VS Code et très formel. En revanche, j’ai l’impression qu’il se limite à des machines d’état de petite taille pour éviter d’avoir un descripteur JSON illisible par son volume et sa complexité.

N’hésitez pas à vous rendre sur le replay de cette conférence pour avoir des exemples concrets et brefs de code sur cet amusant formulaire de sondage culinaire !

Sustainable by design

Par Thibault Morassin

Introduction

Le réchauffement climatique est un fait.

La pollution produite par le numérique est un fait, les entreprises doivent réduire leur empreinte environnementale sur le digital.

Mais par où commencer ? On ne peut pas nier le business, ni dégrader l’expérience des clients/utilisateurs. Un des plus gros freins est la résistance au changement, qu’il ne faut jamais sous-estimer, même chez les plus motivés qui peuvent de fait s’avérer réfractaires aux contraintes emmenées par le changement.

Les initiatives de conception durable ne se concrétiseront que si les bénéfices business sont probants. Il est ainsi très important d’avoir du soutien hiérarchique au sein de l’entreprise se voulant être durable (soutien par le comex/codir etc.).

L’impact du numérique

Selon le 6ᵉ rapport du GIEC, une augmentation de +1,5° à +2°C est prévue avant 2040. Mais quel est l’impact du digital dans tout ça ?

Le digital (au sens large) correspond à 10% de la consommation électrique mondiale, et à 3% des émissions de gaz à effet de serre à l’heure actuelle, contre 6,7% d'ici à 2040.

Penchons-nous sur l’analyse du cycle de vie d’un objet digital. Selon les normes ISO 14040:2006 et ISO14044:2006, on considère 4 phases dans la vie d’un objet digital :

1. 🛠️  Fabrication : de l’extraction des matières premières à la dernière porte de l’usine,
2. 🚚  Distribution : dernière porte de l’usine à l’utilisateur,
3. 🧑‍💻  Usage : impacts liés à l’utilisation, l’administration; l’exploitation, principalement la consommation d’électricité,
4. 🚮  Fin de vie : traitement, recyclage et/ou mise en décharge des déchets liés au recyclage.

L’optimisation de la phase 3 usage a un impact positif sur l’empreinte de toutes les autres phases, dans la mesure où elle conduit à l’amélioration de la durée de vie des équipements. Un usage plus efficient diminue le besoin de produire, donc de distribuer, donc de recycler.

Et pour optimiser cette phase d’usage, il est nécessaire d’être performant sur tous les tiers :

• 💻  Sur les terminaux : côté utilisateur, à savoir les écrans, disques durs, CPU, GPU…
• 🌐  Sur le réseaux (internet),
• 💾  Sur les centres de données : datacenters, disques durs, serveurs…

Chacun a un vrai rôle pour réduire l’impact environnemental du numérique.

Une étude de cas : Dalkia

Dalkia est une filiale d’EDF, spécialisée dans la climatologie, à savoir les réseaux de chauffage et/ou de refroidissement.

Leurs principaux clients sont les communes : lorsque l’on se baigne en hiver dans une piscine municipale, il y a fort à parier que c’est Dalkia qui l’a chauffée.L’étude de cas est basée sur le site https://www.dalkia.com/.

L'éco-conception en application

Les projets sont généralement d’une durée très longue, principalement à cause de la résistance en changement expliquée en première partie. Pour Dalkia, le projet a duré 16 mois.

Une idée reçue veut que l’éco-conception soit un ajustement du produit, une redirection. Or l’écoconception, ce n’est pas de la refonte, mais c’est repartir à zéro pour ensuite tout reconstruire à nouveau, différemment.

Genèse du projet

Tout part d’une initiative de Niji qui a contacté Dalkia qui eux avaient déjà amorcé une prise de conscience écologique, déjà calculé leur impact environnemental, une politique RSE puissante et une stratégie de développement durable.

Tous les feux étaient ainsi au vert pour mener à bien un tel projet.

Projection des bénéfices du projet

💡 Aspect branding :

• Une promesse écologique respectée : un leader de l’énergie durable qui s’engage à être durable,
• Des retombées média internationales : Dalkia serait alors un pionnier du digital durable,
• Une démarcation de ses concurrents : casser une uniformisation des acteurs de ce domaine, où tous les sites sont sensiblement les mêmes (avec du bleu partout).

🧑‍💼 Aspect ressources humaines : Dalkia aurait ainsi une image traduisant son métier, un bénéfice pouvant ainsi attirer plus d’individus, plus engagés dans l’écologie.

🪙 Aspect Business : ceci permettrait de montrer à ses clients que Dalkia applique ce qu’elle leur propose.

Les résultats

Pour ce qui est relatif à l’hébergement :

• Un nombre de serveurs divisés par 3.5 (passant de 7 à 2),
• Un site statique mis à jour 1 fois par jour, avec les environnements de développement éteints le soir et le week-end (puisque personne ne travaille sur ce projet-là, à ces horaires-là)
• 50% d’hébergement vert : 50% de l’hébergement alimenté avec des énergies vertes

Concernant les pages web :

• EcoIndex : majorité des pages notées A (E ou G auparavant)
• Des pages web plus légères, avec une compression de médias, pas de lecture automatique des vidéos, un site avec seulement 2 nuances de couleur…
• Temps moyen de chargement d’une page de 1.3 s, contre jusqu’à 9s pour l’ancien site
• Le nombre de pages total sur le site divisé par 4,
• Un site plus accessible, respectant 94% des critères RGAA (pas directement lié à l’éco-conception, mais lié au durable)
• Un aspect pédagogique sur le site, qui explique la démarche. De ce fait, Dalkia est maintenant consultée par communes, mairies etc. pour expliquer leur projet et leur démarche.

Enfin, le nouveau site de Dalkia émet 64% d’émissions de CO2 de moins que l’ancien site.

Quelques enseignements clés

Pilotage

1. Accompagnement au changement : phase de cadrage importante, pour donner tous les éléments pour un Go/NoGo,
2. Gouvernance renforcée : rejoint l’importance du soutien hiérarchique côté client,
3. Scope : accepter de revoir ses services, quitte à les rogner (a-t-on vraiment besoin d’un blog sur son site, quand on a ses réseaux sociaux qui divulguent les articles ?)

Contenu

1. Frugalité/concision : accepter d’être plus direct, plus efficace,
2. Adaptation de la stratégie du contenu : le SEO reste important, il ne faut pas supprimer tout le contenu déjà créé et négliger le bon équilibre entre le fond et la forme.

Méthodologie & organisation

1. Collaboration entre le design et la technique, pour s’assurer que toute la chaîne entre design et prod soit sustainable,
2. Tests de durabilité systématiques et récurrents de chacune des fonctionnalités, chacun des éléments (https://www.ecoindex.fr/, https://greenframe.io/ …).

Ceci étant dit, il ne semble pas possible d’identifier de manière claire et précise de quelles décisions proviennent les améliorations mesurées en termes d’émissions de CO2 : si c’est le fait d’éteindre les environnements la nuit, de réduire le nombre de pages, d’assumer avoir moins de contenu, etc.

Alice au pays d’Opentelemetry

Par Gaëtan Bremond

Avec cette conférence préparez vous à suivre Jérôme Tama dans son voyage vers les affres et les subtilités de la mise en place d’Opentelemetry.

Tout d’abord qu’est ce que c’est Opentelemetry alias Otel ?

C’est en premier lieu 3 standards de données autour des signaux de vos applications : les logs, les traces et les métriques. Chacun de ces standards à des niveaux de maturité différents car on est encore sur un projet plutôt jeune, les traces et les métriques étant les plus rodées mais les logs sont encore à l’état de brouillon.

C’est aussi une convention autour de la désignation des ressources produisant ces signaux (nom, version, mode de déploiement, etc.) et des implémentations pour instrumenter votre code dans vos langages préférés et vous aider à produire les signaux ci-dessus. Et enfin, un collecteur “magique” qui va vous permettre de réaliser la promesse d’Otel : unifier et corréler les métriques, les traces et les logs.

Toutes ces promesses sont bien belles mais maintenant place à la mise en application !

Jérôme se retrouve face à un système utilisant des microservices écrits en Java hébergés sur Kube. Ce système a une problématique d’observabilité notamment pour identifier les lenteurs, les bugs, etc. notre aventurier choisit donc d’utiliser l’outil magique dont il a entendu parler lors de plusieurs talks : Opentelemetry.

Suivons étape par étape ses péripéties :

1. Installation du collecteur “magique” : jusqu’ici tout se passe bien, il suffit de créer un collecteur magique dans le cluster Kube du projet.
2. Collecter les métriques : tout semble facile, les conteneurs de l’application écrit avec le framework Quarkus savent déjà exposer des métriques au format Prometheus en changeant simplement la configuration. Puis, on demande au collecteur Otel d’aller récolter les métriques sur les applications toutes les X secondes avec un receiver Prometheus.

🚨 Tout n’est pas si simple…

Opentelemetry se chargeant simplement de récolter les données il ne les stocke pas donc il faut lui adjoindre un système de persistance comme Prometheus et aussi un outil pour permettre la visualisation comme Grafana.

1. Ajout d’une nouvelle ressource : ce premier test concluant Jérôme se décide à collecter les métriques d’une deuxième application Quarkus.

🚨 Et là c’est le drame…

Impossible de savoir de quelle application proviennent quelles données il faut donc nommer ces ressources selon la convention Otel. Pour cela on utilise l’opérateur Opentelemetry pour déployer un sidecar avec chaque conteneur d’application qui se chargeront de transmettre les données vers le collecteur principal en y ajoutant des attributs (avec le processor resourcedetection).

1. Collecter les traces : maintenant on a envie de visualiser le chemin d’une requête dans un de nos systèmes. Quarkus sait, encore une fois, générer des traces et les envoyer au format Opentelemetry donc il suffit simplement d’ajouter au sidecar un receiver acceptant ce format. Ensuite, il faut persister ces données et Jérôme choisit Tempo pour rester dans l’univers Grafana Lab.

❤️ Miracle tout fonctionne !

Une fois la configuration mise en place pour les métriques, les traces fonctionnent quasiment toutes seules.

1. Collecter les logs : il ne nous reste plus qu’à récupérer les logs pour compléter la trinité des signaux.

🚨 Malheureusement rien n’y fait…

Notre aventurier des temps modernes n’arrive pas à faire fonctionner son sidecar pour collecter les logs. Il se résout à lire et parser directement les logs sur le filesystem des conteneurs avec un collecteur dans un Daemonset (concept de Kube permettant de déployer une instance sur chaque nœud) qui envoie les logs directement à Loki. Les logs ne passent pas par les collecteurs car pour enregistrer dans Loki il ne faut pas avoir des logs trop riches en attributs donc on reste avec le strict minimum.

🚨 Il reste un défi de taille : parser les logs.

Il existe des tas de formats de logs (JSON, txt, etc.) avec chacun leurs spécificités. Jérôme se retrouve donc à analyser les logs avec une suite séquentielle d’opérateurs pour extraire les différents attributs (code, verbe HTTP, logs de démarrage, stacktrace, etc.). C’est un travail difficile et qui peut être amené à être refait avec les changements de format de logs de vos applications…

🚨 Et la corrélation dans tout ça ?

Cette grande unification des signaux ne se fait pas toute seule, Otel n’est pas capable de faire le lien entre les différents signaux de lui-même. C’est à vous de rajouter les attributs pour faire le lien en ajoutant par exemple le traceId dans les logs et vice-versa. Grafana vous permettra ensuite de faire le lien entre les différentes données en se basant sur ces identifiants. Le lien entre les métriques et les autres signaux est plus complexe à avoir car le standard n’est pas encore au point donc Jérôme décide de le laisser de côté.

Leçons (durement) apprises :

• Otel n’est pas un backend de persistance;
• Les ressources c’est la vie, il faut savoir qui produit quelle ressource avec des tags;
• Otel ne gère pas tout seul la corrélation;
• Otel est encore en construction;
• Ce n’est pas une solution rapide et sans effort.

Conclusion

C’est la fin de ce voyage en terre inconnue qui je l’espère vous a un peu éclairer sur le chemin tortueux de l’observabilité. Opentelemetry a tenu ses promesses  en évitant notamment le vendor locking et il ne faut pas hésiter à contribuer pour compléter le projet (aussi bien en termes de doc que de features).

Merci encore à Jérôme pour cette superbe conférence pleine de rebondissements et d’humour !

PS : Pour plus de détails sur le fonctionnement des pipelines de traitement Opentelemetry je vous invite à voir la conférence.

Débuter dans l’accessibilité numérique

Par Thibault Morassin

L’accessibilité numérique n’est pas simplement une question de taille de police, de couleur, ou de contraste.

Pour être véritablement accessible, une interface web doit pouvoir être utilisable et navigable sans souris, que ce soit uniquement au clavier ou bien avec un lecteur d’écran.

En tant que développeur notamment, il est important de garder à l’esprit que chaque élément interactif doit être accessible. Parmi ceux-ci, on retrouve certes les inputs, les boutons ou les ancres, mais il faut également penser aux boutons “secondaires”, comme l'icône loupe de notre barre de recherche ou encore le bouton permettant d’afficher un mot de passe.

Je ne peux que vous conseiller de vous essayer à la navigation exclusivement au clavier sur un site web dans un premier temps, puis d’essayer avec un lecteur d’écran (vous allez voir, ce n'est pas super fun) : l’expérience personnelle reste le meilleur moyen d'être sensibilisé.Vous pouvez trouver une liste des différents lecteurs sur Wikipédia.

Quelques guidelines

Voici une liste non exhaustive des quelques-unes des bonnes pratiques présentées lors de la conférence. Celles-ci peuvent paraître triviales, mais une piqûre de rappel ne fait jamais de mal. 😉

Le document et son contenu

• Il faut respecter les éléments HTML et leur significations : un bouton <button> pour une déclencher action, une ancre <a href="..."> pour une navigation. Des balises <main>, <header> et <footer> uniques au sein du document, les ensemble d’éléments de navigation sont inclus dans une <nav>, les éléments des listes doivent être des <li> compris au sein de listes ordonnées <ol> ou non ordonnées <ul>.
• Respecter la hiérarchie des titres. Il faut voir les titres sont comme une table des matières dont on doit respecter la hiérarchie. Et si jamais l’interface n’est pas cohérente, il faut utiliser la balise correcte puis la styliser.
• Correctement définir la langue du site <html lang="fr"></html>, car l’attribut lang permet au lecteur de vocaliser la langue. Mal configuré, le lecteur lirait du français avec l’accent anglais. A noter qu’il est possible d’ajouter l’attribut sur n’importe quel élément (paragraph, span, ancre…).
• Penser au zoom du texte, redéfini sur de très nombreuses interfaces. Il est important que la taille du texte soit en valeur css relative : pas en pixel mais en rem, pour que le texte reste proportionnel au zoom.
• Pour les couleurs, toujours avoir un ratio de contraste de 4.5 minimum. On peut tolérer un ratio plus faible de 3.1 lorsque le texte est agrandi de 120% ou 150%. L’inspecteur d’éléments de la console permet d’afficher le ratio de contraste, et de proposer de nouvelles valeurs si celui-ci est insuffisant.Généralement, les boutons et ancres ont des intitulés très courts, et dans certains cas le contexte est nécessaire pour comprendre le sens de l’action qui découle.

Dans l’exemple d’un blog affichant une liste de 10 d’articles dont on ne verrait que l’abstract avec un lien “Lire la suite”, le lecteur d’écran répèterait 10 fois “Lire la suite - lien” sans donner plus d’information à l’utilisateur. Pour pallier cela sans pour autant donner plus de détail dans l’intitulé de l’ancre, l’attribut title (des boutons et des ancres) permet de donner plus d’information au lecteur d’écran uniquement : <a href="/articles/..." title=”Lire la suite de l'article Débuter dans l’accessibilité numérique”>

• Similairement, dans le cas de boutons composés uniquement d’une icône et donc n’ayant pas d’intitulé, il est nécessaire de rajouter l’attribut title pour décrire l’action.

Pour les inputs

• Toujours lier un <label> avec son <input> grâce à l’attribut for, sans quoi le lecteur d’écran ne peut faire le lien et va juste lire “champs à remplir”, sans donner le contexte (“Votre adresse mail - champs à remplir”)
• Si le champ est obligatoire, il est nécessaire de renseigner l’attribut required, il ne faut pas se contenter de déclencher une erreur sur l’interface avec une vérification JavaScript.

Les images

• L’attribut alt doit permettre de décrire le contenu de l’image, avec de véritables phrases correctement structurées de manière à ce que la description se suffise à elle-même.

L’affichage des différents états

• Toujours rendre les états :hover :focus et :focus-visible esthétiquement visibles et différenciables des autres éléments et de l’état de base,
• Attention au tabindex. Le tabindex permet de rendre focusable un élément et/ou de changer l'ordre de focus lors de la navigation au clavier. tabindex="1" enlève le focus, tabindex="0" donne le focus à l’élément. A l’usage, si on change l’ordre à un endroit de la page, il faut se rappeler du nouvel ordre et le prendre en compte pour ne pas gêner la navigation de l’utilisateur.

Formations d’accessibilité

Pour les curieux souhaitant aller plus loin, voici quelques formations partagées par l’orateur :

• Access42 : https://access42.net/
• Atalan : https://www.atalan.fr/
• Ideance : https://ideance.net/fr/
• Koena : https://koena.net/
• Tanaguru : https://www.tanaguru.com/

Et ne pas oublier le Référentiel général d’amélioration de l’accessibilité (RGAA), la check-list d’accessibilité du gouvernement concernant l’accessibilité numérique : https://accessibilite.numerique.gouv.fr/

Rendez-vous vendredi pour la seconde partie de ce Retour sur la BDX I/O 2022 !