DEV Community: Arthur Rousseau

Devfest Nantes 2024, la frayeur s'invite à la cité des congrès 👻

Arthur Rousseau — Tue, 19 Nov 2024 07:55:23 +0000

Il y a tout juste un mois se tenait le Devfest Nantes 2024. Réunissant chaque année plus de 3 500 passionnés, cet événement s'impose comme le rendez-vous incontournable des communautés tech de la région.

Onepoint était présent à cet événement. Découvrez au travers de ces dark chapters notre rétrospective de cette édition effrayante !

L'événement tech le plus effrayant de la région

Pour cette douzième édition, ce ne sont pas moins de 40 conférences qui attendaient les nombreux participants. A celles-ci s'ajoutent 16 quickies et 15 codelabs répartis sur 4 tracks plongés dans l'ambiance terrifiante de ce "Dark Chapter of the Devfest".

Le thème de cette année nous laissait envisager le pire dès le matin du premier jour. Heureusement pour nous, aucun bug ne s'est immiscé dans l'application de contrôle des billets et aucun fantôme malicieux n'a eu pour idée de créer une pénurie de café ! Nos peurs se sont assez vite évaporées, preuve que le Devfest Nantes est une machine bien rodée.

Avant même d'accueillir les premières conférences de la journée, c'est dans le grand auditorium que Mehdi Moussaïd —aussi connu sur YouTube sous le pseudo de Fouloscopie—, a présenté la keynote d'ouverture de ce Devfest. Chercheur spécialisé dans le comportement des foules, il nous fait découvrir son métier et nous donne les clés pour comprendre et ne plus avoir peur de la foule. Une keynote inattendue, passionnante qui nous dévoile les aspects scientifiques qui se cachent derrière ces situations que l'on peut vivre au quotidien.

Deux animations spéciales étaient au programme cette année, mais ni moi ni les co-auteurs de cet article n'avons eu l'occasion d'y participer :

Trois sessions de "Code In The Dark", un challenge pendant lequel les participants ont vingt minutes pour reproduire, à l'aveugle, une page web. À la fin du temps imparti, les participants présentent leurs réalisations et le résultat le plus proche de la maquette l'emporte !
Deux sessions d'expérimentations sociales avec Mehdi Moussaïd.

Onepoint et le Devfest

Impossible pour nous d'évoquer cette édition du Devfest Nantes sans vous parler de notre présence à cet événement.

Pour cette huitième édition consécutive, vous êtes nombreux à avoir bravé vos peurs pour nous rejoindre sur le stand Onepoint. Au programme, ce ne sont pas moins de quatre animations effrayantes qui vous attendaient :

"Beyond The Phobia", un jeu mobile multijoueur similaire à "Blanc-Manger Coco" dans lequel vous affrontez vos adversaires pour créer la phrase la plus drôle —ou effrayante— de la tech. La variante "Peur du noir", jouable en exclusivité sur notre stand, vous plonge dans le noir pour vous faire découvrir les enjeux qui se cachent derrière une application accessible.
"Epouvant'AI", un projet autour de l'IA qui vous aide à lutter contre vos plus grandes peurs en générant une image de celle-ci tournée en ridicule,
"Ouij-IOT", une table de ouija connectée aux esprits du code qui rôdent sur le Gitlab de nos projets,
"OUIA", qui utilise cette même table de ouija et la puissance de l'IA générative pour générer le portrait horrifique de personnages historiques disparus.

Vous avez également retrouvé sur scène trois de nos experts, présents pour animer des conférences ou des ateliers en ce premier jour de Devfest :

Cécile Hannotte nous présentait comment des algorithmes peuvent être utilisés pour expliquer les prédictions de nos IA dans son talk "IA-404 : Explication not found"
Gaël Poupard nous proposait d'observer toutes les mutations qui se passent dans votre HTML au travers de son codelab "L'invasion du HTML mutant"
Benjamin Legrand était présent pour nous parler d'AnalogJS lors de sa conférence "AnalogJS, le meta-framework pour Angular que l'on attendait (ou pas)"

Un énorme merci à eux, ainsi qu'aux personnes qui ont contribué à la réalisation et la mise en place du stand et de ces beaux projets que vous avez pu découvrir lors de ces deux jours.

L’organisation d’un tel événement ne s’improvise pas. En interne, c’est le fruit d’un travail acharné. Chaque conférence, chaque projet, mais aussi chaque détail de la scénographie a été discuté en interne, validé, répété et peaufiné jusqu'au dernier jour. Chaque élément a été soigneusement pensé, des contenus présentés sur le stand en passant par les animations ou les supports visuels utilisés.

Cette organisation pourrait certainement faire l’objet d’un article à part entière, tant elle reflète l’investissement de nos équipes. Alors, restez connectés, les secrets de l'organisation de ce Devfest seront peut-être bientôt dévoilés !

Et les conférences dans tout ça ?

Si certains garderont comme plus beau souvenir de ce Devfest leur passage sur scène, d’autres auront surtout en tête les conférences qu’ils ont pu suivre depuis le public. Nous étions nombreux à avoir assisté à cet événement et certains d'entre nous ont souhaité revenir sur les conférences qui les ont le plus marquées. Un grand merci à Benoit Reynaert, Anthony Baticle et Hervé Martin pour vous être prêtés à l'exercice !

Multi Kubernetes, Multi Régions, Au-secours !

Jeudi 11h10 - Jules Verne - Aurélien Moreau, Nicolas Lavacry - Casden

Aurelien Moreau, architecte Takima et Nicolas Lavacry de la Casden-Banque-Populaire ont eu à déployer des applications containerisées sur plusieurs clusters Kubernetes, multi région et multi providers. Cette conférence se base sur un projet imaginaire ayant les mêmes exigences que la Casden et explore les solutions possibles.

Les premières difficultés exposées sont liées à l'incompatibilité de Kubernetes avec la latence entre nœuds du cluster, nécessitant de créer des clusters distincts. Sont ensuite explorés les problèmes d'optimisation des accès verticaux (routage et loadbalancing des clients extérieurs faisant appel aux services en fonction de leur géolocalisation) et horizontaux (routage des flux inter-cluster internes).

L'intervention se clôt avec une démo du load balancing multi-région (via VPN) puis par la présentation des solutions possibles pour la création d'un service et d'une BDD répliquée inter-cluster.

La conférence a été un succès tant sur le fond que sur la forme. Les speakers se donnent la parole de manière fluide et dynamique, la démo est simple et efficace, le sujet bien que complexe est abordé de manière accessible pour tous. Merci à eux !

Retour de Benoit Reynaert - Abstract, feedbacks et replay à retrouver ici.

Our future without passwords

Jeudi 14h00 - Titan - Milica Mihajlija - Google

Milica Mihajlija, Technical Writer chez Google, a présenté une alternative innovante qui permet de se passer de mots de passe : les passkeys. Cette fonctionnalité encore méconnue aujourd'hui est présente sur de rares sites.

Les passkeys sont des clés de sécurité qui permettent de s'authentifier sur des sites web sans avoir à saisir de mot de passe.
Elles reposent sur le combo clé publique / clé privée et sont compatibles sur la plupart des plateformes et navigateurs.
Cette approche se veut plus sécurisée car les passkeys ne peuvent être réutilisées entre plusieurs sites, ni être compromises en cas d'intrusion serveur, et permettent de se prémunir des attaques de type phishing.

Ces clés sont générées par un appareil physique (comme une clé USB) ou un appareil mobile (comme un smartphone), elles sont prévues uniques pour chaque site web.
La clé publique est stockée sur le serveur distant tandis que l'utilisateur conserve précieusement sa clé privée.

Dans sa présentation, Milica explique les passkeys et montre un exemple de code exécuté dans le navigateur pour les générer.
Elle aborde les configurations permettant d'utiliser une même passkey sur plusieurs sous-domaines d'un même site. Par exemple, il est possible de rendre valable une clé générée pour le domaine domain.tld sur le sous-domaine rewards.domain.tld. Durant son talk, Milica a également évoqué la possibilité de synchroniser ses passkeys entre différents appareils utilisateurs (PC, tablette, smartphone, etc.) via des solutions similaires aux gestionnaires de mots de passe.

La présentation se termine par une proposition de démarche qui vise à introduire ce nouveau système de sécurité sur les sites web, de comment il est possible de sensibiliser les utilisateurs à la sécurité et les accompagner à ce changement.

La conférence a été très intéressante, bien que légèrement commerciale avec un focus sur les solutions Google. Milica a su captiver son audience en expliquant de manière claire et concise un sujet complexe. Les exemples concrets et les démonstrations ont permis de bien comprendre le fonctionnement et la mise en place de ces passkeys.

Retour d'Anthony Baticle - Abstract, feedbacks et replay à retrouver ici.

Introduction pratique à OpenTelemetry pour les développeurs

Jeudi 15h10 - Jules Verne - Nicolas Frankël - Apache APISIX

Fort de 15 années d'expérience dans le domaine du développement, Nicolas Frankël, developer advocate pour APISIX, a été le témoin du déclin du monitoring. Il nous présente, dans la plus grande des salles de ce Devfest, son talk intitulé "Introduction pratique à OpenTelemetry pour les développeurs".

Un frisson s'est emparé de moi lorsqu'il a évoqué cette époque où des équipes entières passaient leurs journées à scruter des dashboards sur d'énormes murs d'écrans. Si comprendre le fonctionnement de nos applications a toujours été important, aujourd'hui la complexité de nos architectures et leur distribution est devenue telle qu'une approche archaïque n'est plus possible. C'est de ce constat qu'a émergé l'idée d'observabilité.

Après avoir détaillé les trois piliers sur lesquels reposent l'observabilité —les métriques, les logs et le tracing— Nicolas nous partage sa propre définition de ce dernier. Selon lui, le tracing est "un ensemble de techniques et d'outils qui permettent de suivre une requête métier à travers de multiples composants et au travers du réseau".

Ca tombe bien, c'est justement ce que font déjà les pionniers du tracing tels que Zipkin, Jaeger ou OpenTracing ! Malheureusement, chaque solution parle sa propre langue et ne peut propager ses traces qu'au travers de composants qui la comprennent. C'est là qu'intervient le W3C, qui s'est emparé de ce sujet pour proposer un standard de propagation de traces, trace-context.

Après avoir brièvement présenté ce qu'est OpenTelemetry —une implémentation du standard trace-context, et plus encore—, place à la démonstration ! Ici en représentant le SI d'un site de e-commerce fictif utilisant de nombreux composants différents (Java, Rust, Python, Go, etc.).

En une vingtaine de minutes, nous découvrons la simplicité avec laquelle il est possible d'intégrer OpenTelemetry au sein de nos projets. A l'issue de cette démonstration, nous étions capables de retracer le cheminement des requêtes qui atteignaient notre SI.

Un énorme merci à Nicolas Frankël qui, à travers sa conférence, a su souligner l'importance du tracing au sein de nos architectures distribuées. Je ressors de cette salle avec l'espoir que demain, plus aucun développeur ne devrait avoir à ~~subir~~ fouiller désespérément dans des logs pour essayer de retracer le chemin d'une requête !

Retour d'Arthur Rousseau - Abstract, feedbacks et replay à retrouver ici.

Atelier - Fresque de la Data

Vendredi 09h00 - Hangar - Laurène Thenoz, Sandra Pietrowska - Hymaïa

Animée par Laurène Thenoz, Product Manager, et Sandra Pietrowska, Data Scientist chez Hymaïa.

Cet atelier, habituellement prévu pour durer 4 heures, a été adapté, pour l’occasion, à un format de 2 heures. Trente participants étaient répartis en quatre groupes, selon un niveau équitable de connaissances en Data.

L’exercice débutait par un cas d’usage destiné à produire un dashboard pour la gestion de la vente d’organes (thème du Devfest oblige !). Chaque équipe devait ordonner une première série d’une dizaine de cartes correspondant aux différentes étapes du processus : réception de données via divers canaux et formats (structurés, non structurés, fichiers Excel, données sensibles), ingestion, stockage, transformation, déploiement et utilisation finale du dashboard. Cette mise en situation reflétait notamment mon quotidien, à l’exception, bien sûr, des organes !

Quelques minutes après avoir posé les premières cartes, les organisatrices nous ont annoncé que l’atelier serait en fait un concours, avec des livres à gagner, ce qui a ajouté une dimension compétitive et stimulé la créativité collective sur les grandes tables blanches mises à disposition.

Pour corser l’exercice, une équipe rivale nous imposait trois obstacles (par exemple, un dashboard buggé, des tests non réalisés ou un manque de confiance dans les chiffres affichés). Chaque problème pouvait être résolu en utilisant une carte solution appropriée.

Au fil de l’atelier, les présentatrices ont introduit de nouvelles étapes pour enrichir le scénario et approfondir la compréhension des rôles comme Data Engineer, Data Scientist, ou Data Analyst, ainsi que des concepts tels que la Data Lineage, le RGPD, Data Quality, etc.

Entre chaque étape, Laurène et Sandra prenaient la parole pour présenter des informations complémentaires, comme le Data Business Canvas Model (issu du Lean Canvas) pour définir un modèle économique axé sur la data, ou une matrice d’aide à la priorisation orientée création de valeur.

Peu après, avec un nouveau jeu de cartes, nous avons abordé les aspects prédictifs et prescriptifs de l’intelligence artificielle, en discutant de concepts tels que le machine learning, le deep learning, le feature engineering, la model baseline, etc., tout en étant confrontés à de nouvelles problématiques à résoudre.

Laurène s'est arrêtée à notre table pour nous sensibiliser aux enjeux des modèles qui fonctionnent "trop bien" et se poser la question de savoir si notre modèle reste en adéquation avec la réalité.

Pour conclure la session, quelques rappels importants :

Les meilleures pratiques de développement s’appliquent à la Data, inutile de réinventer la roue.
La performance des algorithmes de machine learning peut diminuer avec le temps, d'où la nécessité de les remettre en question régulièrement.
Il est indispensable de passer d’une mentalité de PROJET à une mentalité de PRODUIT. Le PRODUIT doit être aligné sur la stratégie d’entreprise et la stratégie Data.

Avant de partir, un dernier message de sensibilisation sur l’impact environnemental de l’intelligence artificielle générative, comparant cela à un aller-retour Paris - New York (s’appuyant, entre autres, sur dataforgood.fr) :

Le cycle de vie (ACV) d’un serveur pour 6 ans de durée de vie : équivalent à 3 allers-retours Paris - New York.
L'entraînement de ChatGPT 3 : équivalent à 200 allers-retours Paris - New York.
Poser 16 questions à ChatGPT : équivaut à faire bouillir une bouilloire (heureusement, pas besoin d’aller jusqu’à New York !).

Cerise sur le gâteau, notre équipe a remporté la victoire ainsi qu’un livre sur le product management : Le kit de survie du product manager ambitieux. La journée commençait très bien !

Retour d'Hervé Martin - Abstract et feedbacks à retrouver ici.

J'ai une idée pour réduire l'empreinte environnementale du numérique par 4

Vendredi 10h10 - Jules Verne - Tristan Nitot - OCTO Technology

Tristan Nitot est très impliqué depuis plusieurs années dans des projets importants du numérique, il a co-fondé Mozilla Europe, est passé par Qwant, Scaleway et Cozy Cloud. Aujourd'hui âgé de 57 ans, il est directeur associé chez OCTO Technology et est le présentateur du podcast « L'octet vert »

Lors de sa conférence il propose son alternative à la loi de Moore : le principe d'erooM.

Il part du constat que l'impact environnemental du numérique est principalement lié aux ressources extraites et utilisées pour la fabrication de nos appareils, serveurs, smartphones, etc. Cet impact est fortement lié a La loi de Moore. Ce principe a fait que pendant des décennies, acheter un nouvel appareil pour le même prix que l'ancien offrait des performances grandement supérieures (X2 tous les 2 ans). La conséquence a été la mise en place d'une obsolescence programmée, les applications fournies étant, selon la loi de Wirth proportionnellement plus lentes et consommatrices en ressources CPU et RAM.

Cette loi de Moore arrive aujourd'hui à essoufflement. La proposition de Tristan est de passer a une loi d'optimisation, nos application devraient consommer 2X moins de ressources tous les 2 ans. La conséquence en serait une croissance maintenue mais une consommation en ressources grandement limitée. L'utopie étant qu'à un jeune adulte, on offre un bon ordinateur et que celui-ci lui serve toute sa vie.

La conférence a beaucoup plu, tant sur la qualité du speaker, la forme et le fond. Dans les jours qui ont suivi, elle a entrainé plusieurs discussions notamment sur le sujet du profilling d'application et comment améliorer les performances de nos applis. Spoiler : il y a un profiler intégré dans les IDE Jetbrains pour la partie backend et pour le frontend, allez dans la console de dev de votre navigateur. Il y également eu une conférence d'introduction à l'OpenTelemetry lors de ce DevFest.

En conclusion, le noeud du problème est aussi la motivation du client, comment l'inclure dans cette démarche d'optimisation quand "ça marche" et qu'il y a d'autres priorités ? A ce sujet, la mesure et l'amélioration de l'impact environnemental des entreprises va être de plus en plus important via des contraintes venant du RSE et du green deal de l'Europe. Prenons de l'avance !

Retour de Benoit Reynaert - Abstract, feedbacks et replay à retrouver ici.

Les aventuriers de la motivation perdue

Vendredi 14h00 - Belem - Noémie Delrue - CGI

Noémie Delrue est consultante SharePoint et Microsoft 365 chez CGI.
Et si on se déconnectait de la tech' pour prendre du temps à réfléchir sur soi, se recentrer sur l'humain, se questionner sur ses aspirations, résonner sur ce qui nous anime et nous motive au quotidien ?

Dans sa présentation, Noémie a présenté avec humour, bienveillance, et pragmatisme une conférence sur la motivation et l'engagement des collaborateurs en entreprise.
Elle nous conte des anecdotes, nous fait rire et réfléchir, les analogies nous parlent.
Noémie offre un moment inspiré de la relaxation pour lâcher prise, nous recentrer sur nous-même, nous aider à trouver un sens à ce que l'on fait au quotidien, et surtout dire MERCI.

Cette conférence nous invite à un retour à l'essentiel, avec douceur, humour et empathie. Un moment inspirant et émouvant qui nous rappelle l'importance de prendre soin de soi et des autres.
Et si vous aussi vous teniez votre Brag Doc pour célébrer vos réussites ? Si ce mot ne vous dit rien, je vous invite à voir le replay de la conférence.

Retour d'Anthony Baticle - Abstract, feedbacks et replay à retrouver ici.

Anatomie d'une faille

Vendredi 15h10 - Jules Verne - Olivier Poncet - Arneo

Olivier Poncet, CTO de Arneo et habitué du Devfest était présent pour nous raconter une histoire.
Cette histoire est celle de la faille de XZ Utils qui, sans un coup de chance exceptionnel et la curiosité du développeur l'ayant découverte, aurait pu passer inaperçue et entraîner des conséquences dramatiques.

La conférence débute par un retour à la date du 29 mars 2024. Ce jour-là, Red Hat rapporte que du code malicieux a été identifié au sein des livrables de XZ Utils. Les risques liés à cette faille sont tels que le score de la CVE (Common Vulnerabilities and Exposures) dans laquelle elle a été reportée est évalué à 10/10. Il s'agit là d'une faille dont la criticité est maximale et pour laquelle des actions de remédiation doivent être prises immédiatement.

XZ Utils est un outil embarqué dans une grande partie des distributions Linux permettant de compresser / décompresser des données via l'algorithme LZMA.

Mais... comment en sommes-nous arrivés là ? Quels étaient les objectifs de cette attaque et surtout, comment a-t-elle été déjouée ?

Pendant 40 minutes, Nicolas nous retrace l'histoire de cette attaque menée sur le long terme. La présentation retrace les quatre phases de cette celle-ci. A l'image d'un épisode de Columbo, on nous présente directement l'auteur des faits, un certain Jia Tan. L'objectif de cette attaque ? Corrompre la supply-chain de certaines distributions Linux et y intégrer une porte dérobée via les outils de compression proposés par XZ Utils.

Nous découvrons alors l'histoire de Collin Lasse, seul mainteneur du projet XZ Utils depuis 2009, et sa rencontre avec Jia Tan. En 2022, Collin Lasse est submergé de demandes liées à XZ Utils et la pression est telle qu'il est contraint de nommer un second mainteneur. Après avoir fait ses preuves en contribuant régulièrement au projet, Jia Tan est nommé co-mainteneur de XZ Utils au début de l'année 2023.

Bien que les conséquences de cette décision ne soient pas visibles immédiatement, le mal est fait. Petit à petit, nous découvrons comment Jia Tan a pris le contrôle et ajouté du code malicieux au sein de XZ Utils. Au fur et à mesure du talk, l'énigme s'éclaircit. On prend alors la mesure de toute l'ingéniosité qu'a nécessité cette attaque.

La compromission de XZ Utils est découverte par Andres Freud, membre de la core team de PostgreSQL et ingénieur chez Microsoft, le 29 mars 2024. Après avoir constaté une charge CPU anormale liée à openssh, il a enquêté et identifié la source du problème : liblzma, l'un des paquets de XZ Utils.

Pour être honnête, je n'avais pas entendu parler de cette attaque avant d'assister à cette conférence, mais j'en ressors avec deux leçons :

En tant que mainteneur de projet open source, on peut être amené à se retrouver en amont de la supply chain d'autres projets. Si votre projet est utilisé par d'autres projets, vous devenez potentiellement un vecteur d'attaque.
En tant que consommateur de projets open source, il est nécessaire de rester attentif à ce qu'on utilise. On peut sans doute limiter les librairies qu'on utilise dans nos projets (a-t-on vraiment besoin de is-odd dans nos projets ?). Au-delà de ça, il convient d'être attentif aux versions de ce qu'on utilise, en faisant parfois des compromis (est-ce que j'utilise la dernière version en date, est-ce que j'utilise une version moins récente, mais éprouvée ?).

Cette conférence est probablement celle qui m'a le plus intéressé de tout ce Devfest ! Si vous n'avez pas eu la chance d'assister à cette conférence en direct, je vous recommande vivement d'aller voir son replay !

Retour d'Arthur Rousseau - Abstract, feedbacks et replay à retrouver ici.

Le monstre invisible : l'empreinte carbone de l'IA

Vendredi 16h20 - Titan - Olivier Bierlaire - Carbonifer

À l’Auditorium 800 de la Cité des Congrès, la conférence est présentée par Olivier Bierlaire, ancien pensionnaire de la maison Elastic et fondateur de Carbonifer aidant les sociétés à rendre leurs infrastructures cloud plus écologiques.

Dès le début, Olivier nous plonge directement dans l'urgence climatique avec des chiffres révélateurs, montrant que l’empreinte carbone de l’IT dépasse aujourd’hui celle de l’aviation civile ou du transport maritime. Et cet impact ne se limite pas à la seule émission de CO₂ : il englobe également la consommation d'eau, l'exploitation des sols, le recyclage des composants, sans oublier les nuisances sonores.

Et l'IA générative dans tout ça ?

Ces quatre dernières années, les besoins en puissance de calcul pour l'IA ont connu une croissance exponentielle. Certaines grandes entreprises technologiques (GAFAM) ont même installé des data centers à proximité de centrales nucléaires américaines, anticipant une demande croissante en électricité au cours des deux prochaines années.

Quelques repères :

Une tonne de CO₂ correspond, par exemple, “grosse maille” à un aller-retour entre Paris et New York.
L’empreinte carbone par habitant : États-Unis (14 tonnes), Europe (7 tonnes), France (4 tonnes).
Pour suivre les accords de Paris, nous devrions être à 2 tonnes…

Olivier nous invite à considérer l’empreinte carbone de ChatGPT-3 (très difficile à calculer, la transparence des chiffres d’émissions de CO₂ reste encore perfectible, voire même opaque) :

L’entraînement : environ 500 tonnes de CO₂. Plus un modèle est petit, moins la consommation est importante.
L’utilisation annuelle (inférence) : entre 40 000 et 120 000 tonnes de CO₂.

Il présente plusieurs tableaux montrant que le fine-tuning ne représente qu'une petite partie de l’entraînement, que ce soit en termes de matériel ou pour les modèles de langage de grande taille (LLM). Il souligne notamment que "CodeParrot" – un modèle basé sur GPT-2 – est l’un des plus efficaces en termes d’émissions de CO₂, avec seulement 2 à 3 tonnes métriques générées pour l'entraînement, grâce à sa taille réduite et à l’utilisation de datasets plus petits.

Mesurer pour mieux réduire

En s’appuyant sur une citation de Peter Drucker, “Si vous pouvez le mesurer, vous pouvez l’améliorer”, Olivier introduit ensuite des outils de mesure des émissions de CO₂ et met l’accent sur l’importance du choix des lieux de requêtage :

Carbon Tracker
Code Carbon
GenAI Impact
Outils de suivi carbone des grands clouds : AWS, Google Cloud

Solutions pratiques pour réduire les émissions de CO₂

On pourrait intuitivement penser que moins on dépense, moins on émet de CO₂. Ainsi, lors des phases d’entraînement, plus le modèle est petit, moins la consommation sera élevée, en tenant compte également du matériel utilisé et du pays où l’on souhaite effectuer cet entraînement.

Côté inférence, même constat : plus le modèle est petit, moins la consommation sera élevée. Par ailleurs, générer du texte est moins gourmand en ressources que générer une image, sans oublier le matériel et la localisation de l’exécution de la requête.

Olivier présente diverses initiatives, notamment AI for Green, et mentionne des usages controversés de l'IA (comme la détection de nouveaux gisements pétroliers au Texas) ainsi que des applications plus positives, telles que le projet Global Fishing Watch pour détecter la pêche illégale.

Il mentionne également une étude aux résultats intrigants, selon laquelle la rédaction d'une page avec ChatGPT génèrerait environ 130 à 1 500 fois moins de CO₂ qu'un texte rédigé par un humain.

J’ai assisté à une conférence percutante sur l'impact écologique de l’IA dans notre quotidien et les points essentiels que j’en retiens sont les suivants :

La consommation de l’IA dépend étroitement de l’infrastructure et du lieu d’utilisation (en France, par exemple, on est plus chanceux qu’en Allemagne !),
Réduire la taille des modèles permet de diminuer leur impact écologique,
Réutiliser les modèles existants plutôt que de les réentraîner à chaque fois,
Mesurer, estimer et calculer les émissions pour adopter un retour sur investissement carbone,
Remettre en question le recours systématique à l'IA, qui n’est pas toujours la meilleure solution.

Retour d'Hervé Martin - Abstract, feedbacks et replay à retrouver ici. Le support de la conférence est disponible à cette adresse.

Data et sport : la révolution

Vendredi 16h50 - Jules Verne - Eric Alard - ENI Ecole Informatique

En tant que passionné de sport, il m'était impossible de rater cette conférence. Eric Alard, ancien bobeur ayant participé à cinq Jeux olympiques d’hiver, est désormais Responsable des relations École-Entreprises à l’ENI, coach, conférencier et auteur du livre *Devenez votre propre champion*.

Le sport génère d’immenses émotions et souvenirs ; le présentateur s’appuie d’ailleurs sur des moments emblématiques du sport français pour raviver ces souvenirs. Aujourd'hui, nous nous trouvons à un carrefour où la data pourrait transformer nos prochains souvenirs.

La data au service de la performance

Très populaire outre-Atlantique dans le baseball, le football américain ou le basketball, l’utilisation des données me rappelle le film Le Stratège. Ce film raconte l’histoire, vieille de plus de 20 ans, d’un entraîneur de baseball qui parvient à hisser son équipe au sommet de la Major League Baseball (MLB). Son succès repose sur une collaboration visionnaire avec un “data scientist” avant l’heure, qui a permis de constituer une équipe de joueurs complémentaires sur la base de statistiques.

Mais revenons à notre présentation. En tant qu'ancien bobeur, le présentateur a lui-même constaté l’évolution technologique de son sport : l’apparition de capteurs, d'accéléromètres, et de données sur la vitesse. Ces informations sont devenues précieuses tant pour les athlètes que pour les entraîneurs, les aidant à optimiser les performances. La data transforme la préparation des sportifs et redéfinit le sport lui-même.

Aujourd’hui, l’utilisation massive de données et leur précision touchent un éventail encore plus large de sports. Au rugby, par exemple, les joueurs utilisent des protège-dents équipés d’accéléromètres, ou des maillots dotés de poches intégrant un capteur GPS, permettant d’obtenir des données en temps réel et d’être plus prédictifs dans l’optique de remporter la victoire. En football, on admet souvent que l’équipe victorieuse est celle qui a parcouru le plus de kilomètres sur le terrain. Quant au cyclisme, l’une des équipes les plus performantes a développé des applications internes axées sur la diététique, ce qui a permis à trois de ses coureurs de remporter les trois principaux tours.

Pour que la data représente un réel avantage, trois conditions sont nécessaires :

L’accès à la technologie
Le traitement des données recueillies
Des moyens financiers pour l'exploiter

La data pour enrichir l’expérience

L’utilisation de la data ne se limite pas à la performance ; elle enrichit aussi l’expérience du sport. Le spectacle dépasse désormais l’événement lui-même et se prolonge bien au-delà, renforçant l'“expérience fan” et l’hyperconnexion. Le présentateur évoque le succès des derniers Jeux olympiques, notamment un moment dans la salle de basket de Lille : lors d’un temps-mort, la foule en délire ne soutenait pas les basketteurs mais Léon Marchand, en pleine finale à plusieurs centaines de kilomètres de là.

Le sport est un miroir de notre société. Et quelle que soit l’avancée technologique, la machine la plus performante restera l’être humain, avec son libre arbitre, son génie et sa créativité. Ce sont ces éléments imprévisibles, ces exploits sportifs que même l’intelligence artificielle ne pourra prédire, qui continueront de nous faire vibrer et de créer nos souvenirs.

Cette dernière conférence s'apparente à un TEDx avec un storytelling émotionnel travaillé. Certes moins technique, elle est plus accessible à tous, touchant un public plus large.

Retour d'Hervé Martin - Abstract, feedbacks et replay à retrouver ici. Replay TEDx Orléans disponible sur YouTube.

Alors, pas trop peur ?

Même placé sous le signe de la frayeur, cette édition du Devfest Nantes nous semble avoir été une véritable réussite. C'est toujours un plaisir de voir autant de passionnés réunis et nous sommes fiers d'avoir pu représenter l'équipe Onepoint au cours de ces deux journées.

Un grand bravo à l’équipe organisatrice du Devfest, mais aussi et surtout à toutes les personnes de Onepoint qui ont rendu cet événement possible. Que ce soit à travers nos animations, nos conférences, ou votre visite sur le stand, ce que vous avez vécu avec nous est le résultat de plusieurs mois de travail acharné. Un immense merci à eux pour leur investissement !

Merci également à Onepoint et tout particulièrement à Julien Guimier et Stéphane Théou pour nous avoir permis, une fois de plus, d'assister et participer à un tel événement !

Riche en rencontres et en découvertes, ce Devfest Nantes 2024 restera gravé dans nos mémoires ! Merci à toutes celles et ceux qui ont pris le temps de venir discuter avec nous et découvrir nos animations pendant ces deux journées. On se donne rendez-vous l’année prochaine pour de nouvelles aventures toujours plus innovantes et surprenantes ! D’ici là, prenez le temps de revivre cette édition à travers les rediffusions des conférences, les photos de l'événement et notre aftermovie. À très bientôt !

ArchUnit : comment l'utiliser pour contrôler l'architecture de vos projets Java

Arthur Rousseau — Tue, 25 Jun 2024 07:11:00 +0000

Vous êtes développeur et vous vous lancez dans la conception d'un nouveau projet ? L'une des premières étapes cruciales consiste à déterminer l'architecture logicielle qui sera utilisée. "Les classes seront-elles regroupées par couche ou par fonctionnalité ?". "Est-il préférable d'avoir une architecture MVC, MVP, hexagonale, etc... ?". "Devons-nous envisager un découpage par module ?". Ce sont autant de questions auxquelles il vous faudra répondre avant même d'écrire votre première ligne de code.

Cependant, la vraie difficulté commence une fois l'architecture définie. Le plus dur reste désormais de s'assurer que l'ensemble des développements respecte les règles que vous vous êtes fixées. Je ne compte plus le nombre de fois où j'ai pu déceler des soucis architecturaux lors de merge requests. "Cette classe devrait plutôt être dans tel package", "cette classe ne devrait pas utiliser ces modèles".

Cette situation vous semble familière ? Et si je vous disais qu'il existe un outil qui peut faire ces contrôles à votre place ? ArchUnit est une librairie Java qui va vous permettre de vérifier automatiquement que votre code respecte vos règles d'architecture. Nul besoin d'outil externe, le tout est validé au travers de vos tests unitaires ! Dites au revoir aux contrôles manuels, faillibles et chronophages. Dans cet article, je vais vous présenter comment utiliser ArchUnit au travers de cas d'usage concrets, sélectionnés à partir de ce que j'ai pu mettre en place sur mes précédents projets.

Bien qu'il soit préférable d'utiliser ArchUnit aux prémices de votre projet, vous constaterez qu'il est tout à fait possible de l'intégrer à un projet déjà bien avancé. Afin que vous puissiez avoir des exemples concrets auxquels vous référer, cet article contient de nombreux extraits de code. Pour simplifier leur lecture, certains d'entre eux ont été abrégés, mais l'exhaustivité des sources présentées est disponible dans le dépôt GitHub archunit-sample.

ArchUnit, qu'est-ce que c'est ?

ArchUnit est une librairie conçue pour vérifier automatiquement l'architecture logicielle de votre application au travers de n'importe quel framework de test Java (typiquement, JUnit).

Grâce à ArchUnit, vous pouvez définir des règles architecturales qui seront alors contrôlées au travers de tests unitaires. En cas d'échec, ces tests unitaires vous indiquent clairement les violations constatées et comment y remédier.

Techniquement, ArchUnit repose sur l'analyse du bytecode Java, et sa matérialisation sous forme de classes spécifiques à ArchUnit. Par exemple, les classes JavaClass et JavaMethod représentent respectivement les classes et les méthodes de votre projet.

Son intégration simple et ses capacités d'extension font d'ArchUnit un outil de choix pour détecter automatiquement les écarts architecturaux, et ce dès les premières étapes de développement.

Intégration d'ArchUnit et création de votre première règle

Au sein d'un projet qui utilise déjà JUnit, l'intégration d'ArchUnit ne nécessite que l'ajout de la librairie archunit-junit5 (ou archunit-junit4, si vous utilisez toujours JUnit 4).
Exemple d'intégration via Gradle :

testImplementation 'com.tngtech.archunit:archunit-junit5:1.3.0'

Maintenant qu'ArchUnit est intégré à votre projet, il est temps de créer votre premier test d'architecture.

[...]

// Si vous utilisez JUnit 4, pensez à utiliser le runner ArchUnitRunner via l'annotation @RunWith(ArchUnitRunner.class)
@AnalyzeClasses(packages = "fr.arthurrousseau.archunit") // #1
class ArchitectureTest {

    @ArchTest // # 2
    public static final ArchRule SERVICES_MUST_BE_ANNOTATED = classes() // #3
        .that().resideInAPackage("..service.impl") // #4
        .should().beAnnotatedWith(Service.class); // # 5

    // Les règles peuvent être déclarées sous forme de méthodes ou de variables statiques
    @ArchTest // #2
    void testThatClassesInDomainImplPackageMustBeAnnotated(JavaClasses classes) {
        ArchRule rule = classes() // #3
            .that().resideInAPackage("..service.impl") // #4
            .should().beAnnotatedWith(Service.class); // #5
        rule.check(classes);
    }
}

ArchitectureTest.java - Github.com

Décortiquons ensemble les informations présentes dans l'extrait de code ci-dessus.

#1 - L'annotation @AnalyzeClasses permet d'indiquer les classes qui seront testées par ArchUnit.
#2 - L'annotation @ArchTest (en remplacement de l'annotation @Test) rend possible l'injection des JavaClass au sein de vos méthodes de test.
#3 - La méthode .that() permet de ne conserver que les classes qui correspondent aux conditions qui suivent.
#4 - La méthode .should() applique les règles qui suivent aux classes qui ont été conservées.

Le test ci-dessus permet donc de :

#1 - Charger l'ensemble des classes présentes dans le package fr.arthurrousseau.archunit
#3 - Filtrer et ne conserver que les classes qui sont présentes dans le package *.service.impl
#4 - Vérifier que l'ensemble des classes qui correspondent à ces filtres sont annotées avec l'annotation @Service.

Pour tester cette règle, admettons qu'au sein de votre projet vous disposez d'une classe ProductServiceImpl n'étant pas annotée @Service :

package fr.arthurrousseau.archunit.products.service.impl;

// [...]

@RequiredArgsConstructor
public class ProductServiceImpl implements ProductService {
    [...]
}

Voici le résultat que retournerait l'exécution des tests d'architecture :

java.lang.AssertionError: Architecture Violation [Priority: MEDIUM] - Rule 'classes that reside in a package '..service.impl' should be annotated with @Service' was violated (1 times):
Class <fr.arthurrousseau.archunit.products.service.impl.ProductServiceImpl> is not annotated with @Service in (ProductServiceImpl.java:0)

La classe ProductServiceImpl ne respectant pas la règle décrite, le test échoue. Les informations tracées lors de l'exécution des tests ArchUnit permettent de cibler l'origine du problème.

Aussi simple soit-elle, cette première règle vous rapproche un peu plus de l'automatisation du contrôle de l'architecture de votre projet !

Mise en place de règles unitaires et composites

Maintenant que vous avez écrit votre première règle ArchUnit, passons à son intégration dans un projet plus complet. A partir de maintenant, les extraits de code qui suivent sont issus du projet archunit-sample.

Le package controller contient les classes qui exposent les points d'entrée permettant d'effectuer des opérations sur les produits que gère le projet.
Afin de s'assurer de la cohérence de nos points d'entrée, il a été décidé que l'ensemble des controllers soient annotés avec l'annotation @Controller, possèdent le suffixe Controller et soient positionnés à la racine du package ..controller.

Cette cohérence peut être assurée à l'aide des trois règles unitaires suivantes :

@ArchTest
public static final ArchRule CONTROLLER_NAMING_RULE = classes()
    .that().areAnnotatedWith(Controller.class)
    .should().haveSimpleNameEndingWith("Controller");

@ArchTest
public static final ArchRule CONTROLLER_ANNOTATION_RULE = classes()
    .that().haveSimpleNameEndingWith("Controller")
    .should().beAnnotatedWith(Controller.class);

@ArchTest
public static final ArchRule CONTROLLER_LOCATION_RULE = classes()
    .that().areAnnotatedWith(Controller.class)
    .should().resideInAPackage("..controller");

Mais elles peuvent également être regroupées au sein d'une seule et même règle composite :

@ArchTest
public static final ArchRule CONTROLLER_RULE = classes()
        .that().areAnnotatedWith(Controller.class)
        .or()
        .haveSimpleNameEndingWith("Controller")
        .should().resideInAPackage("..controller")
        .andShould().beAnnotatedWith(Controller.class)
        .andShould().haveSimpleNameEndingWith("Controller");

ControllerTest.java - Github.com

En regroupant ces vérifications au sein d'une seule et même règle, vous centralisez vos contrôles, vous rendez plus naturelle la compréhension de vos règles et vous simplifiez leur maintenance (si demain vous décidiez de modifier votre règle pour utiliser des @RestController plutôt que des @Controller, vous n'auriez qu'une seule règle à modifier).

Aller plus loin à l'aide des conditions personnalisées

Toujours pour assurer la cohérence des points d'entrée, voyons comment faire pour s'assurer que ceux-ci ne manipulent que des objets qui leur sont dédiés. Interdiction donc de recevoir ou de renvoyer des objets du package domain : les objets utilisés devront provenir du package controller.model

Bien qu'ArchUnit mette à disposition un grand nombre de méthodes (163 à date) permettant de vérifier que vos classes respectent les règles que vous avez fixées (comme par exemple, les méthodes beAnnotatedWith et haveSimpleNameEndingWith que vous avez utilisées jusqu'à présent), vous aurez parfois besoin d'aller plus loin.

Pour mettre en place cette nouvelle règle vous allez devoir utiliser une condition personnalisée. Ce type de condition va vous permettre de mettre en place des règles plus poussées avec une extrême simplicité. En effet, il vous suffit d'étendre la classe ArchCondition et implémenter la méthode check pour lui faire faire ce que vous souhaitez !

Voici la signature de la méthode que vous devrez implémenter :

void check(JavaClass clazz, ConditionEvents events)

Le premier paramètre, clazz, correspond à la classe qui est en train d'être contrôlée. Le second paramètre, events, fait office de registre de violations de règles. A chaque fois qu'une violation sera constatée sur la classe en cours de test, c'est au travers de cet objet qu'elle devra être tracée.

static class UseDtoObjectsOnly extends ArchCondition<JavaClass> {
    public UseDtoObjectsOnly(Object... args) {
        super("use DTO objects only", args); // #1
    }

    @Override
    public void check(JavaClass controllerClass, ConditionEvents events) {
        for (JavaMethod method : controllerClass.getMethods()) {
            JavaClass returnClass = method.getReturnType().toErasure();
            var packageName = returnClass.getPackageName();

            if (!packageName.contains("controller.model") || !returnClass.getSimpleName().endsWith("Dto")) { // #2
                events.add(SimpleConditionEvent.violated(method, "Violation détectée")); // #3
            }
        }
    }
}

ControllerTest.java - Github.com

L'exemple ci-dessus présente une façon d'atteindre nos objectifs. Les éléments les plus importants de cette implémentation sont les suivants :

#1 - Message associé à la condition, utilisé lorsque pour créer les traces d'erreur en cas de violation,
#2 - On vérifie, au travers des objets fournis par ArchUnit, que l'objet retourné se trouve bien dans le package controller.model et possède un nom qui termine par Dto,
#3 - events.add(SimpleConditionEvent.**violated**(method, message)); méthode permettant de tracer le fait que la méthode testée n'a pas respecté la condition personnalisée.

Pour utiliser cette condition, il suffit de l'associer à une nouvelle règle :

@ArchTest
public static final ArchRule CONTROLLER_RULE = classes()
    .that().areAnnotatedWith(Controller.class)
    .or().haveSimpleNameEndingWith("Controller")
    .should(new UseDtoObjectsOnly());

Le controller ProductsController possède une méthode add() qui prend en entrée un objet de type Product qui réside dans le package domain.model.

@Controller
public class ProductControler {

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public ProductDto add(@RequestBody Product product) {
        return productService.saveProduct(product);
    }
}

La règle que vous venez de mettre en place lève une erreur et indique, comme vous pouviez vous y attendre, que ce controller manipule des données qui ne sont pas propres au package controller.model :

java.lang.AssertionError: Architecture Violation [Priority: MEDIUM] - Rule 'classes that are annotated with @Controller or have simple name ending with 'Controller' should use DTO objects only was violated (1 time):
Method fr.arthurrousseau.archunit.products.ProductControler.add() has a parameter fr.arthurrousseau.archunit.products.service.model.Product which is not in the controller.model package and / or does not end with Dto

ArchUnit et le concept de règles gelées

Lors de l'ajout de nouvelles règles au sein de projets existants, il est possible qu'un certain nombre de violations existantes soient détectées.
Parfois, leur nombre est tel qu'il n'est pas possible d'y remédier immédiatement. La meilleure façon de traiter ces violations consiste à les traiter petit à petit, de façon itérative.

Les règles d'architecture peuvent être gelées à l'aide de la classe FreezingArchRule. Le fait de geler une règle enregistre l'ensemble des violations actuelles dans un ViolationStore. De cette façon, lors des prochaines exécutions, seules les nouvelles violations lèveront une erreur. Les violations listées lors du gel de la règle seront supprimées du ViolationStore dès leur correction.

Pour geler une règle, il suffit de l'encapsuler dans la méthode FreezingArchRule.freeze(rule)) :

@ArchTest
public static final ArchRule SERVICES_SHOULD_CALL_LOGGER_RULE = FreezingArchRule.freeze(methods().that()./* Suite de la règle */));

ControllerTest.java - Github.com

En plus de cela, il vous sera nécessaire d'autoriser la création d'un nouveau store en créant un fichier archunit.properties au sein des ressources de votre projet :

# Permet la création du ViolationStore
freeze.store.default.allowStoreCreation=true

archunit.properties - Github.com

Suite à la première exécution de cette règle gelée, vous constaterez qu'ArchUnit a créé deux nouveaux fichiers dans le dossier archunit_store :

#Tue Jun 04 23:48:33 CEST 2024
[NOM_DE_LA_REGLE]=2a2375fa-54ec-4fa7-b979-17478323ac4c

stored.rules - Github.com

Method fr.arthurrousseau.archunit.products.service.impl.Products.deleteProduct() doesn't log anything
Method fr.arthurrousseau.archunit.products.service.impl.Products.getAllProducts() doesn't log anything
Method fr.arthurrousseau.archunit.products.service.impl.Products.getProductById() doesn't log anything

2a2375fa-54ec-4fa7-b979-17478323ac4c - Github.com

Le premier fichier contient la liste des règles gelées et leurs identifiants. Le second fichier contient quant à lui l'ensemble des violations existantes au moment du gel de la règle. Chaque règle gelée possède son propre fichier, nommé en fonction d'un identifiant unique généré par ArchUnit.

Contrôler l'architecture globale de votre application

Si vous souhaitez vous assurer que l'architecture globale de votre projet est respectée, alors vous aurez besoin d'utiliser des fonctions du package com.tngtech.archunit.library.

Ce package comporte une large collection de règles prédéfinies qui seraient complexes à mettre en place au travers de simples règles.

Dans le cadre du projet archunit-sample, voici les règles qui composent l'architecture globale du projet :

Le package controller n'est accédé par aucun autre package. Ce package a accès au package service.
Le package service est indépendant, il ne dépend ni du package controller, ni du package repository*.
Le package repository n'est accédé par aucun autre package*. Ce package a accès au package service.

(*) Techniquement, le package service est indépendant des autres puisqu'il expose une interface ProductRepository qui est implémentée par le package repository.

Cette architecture peut être vérifiée à l'aide de la règle ci-dessous :

@ArchTest
    public static final ArchRule LAYERED_ARCHITECTURE_TEST = layeredArchitecture()
            .consideringOnlyDependenciesInLayers()
            .layer("Controller").definedBy("..controller..")
            .layer("Service").definedBy("..service..")
            .layer("Data").definedBy("..data..")
            .whereLayer("Controller").mayNotBeAccessedByAnyLayer()
            .whereLayer("Controller").mayOnlyAccessLayers("Service")
            .whereLayer("Service").mayNotAccessAnyLayer()
            .whereLayer("Data").mayOnlyBeAccessedByLayers("Service");

ControllerTest.java - Github.com

Au travers d'une syntaxe simple, chacun des packages du projet est associé à une couche de l'architecture de l'application. Chacune des couches déclarées peut alors spécifier à quelle autre couche elle a accès, mais aussi quelle autre couche a droit d'y accéder.

Que retenir de l'utilisation d'ArchUnit ?

Mettre en place l'architecture logicielle d'un projet est une chose, s'assurer qu'elle soit respectée et maintenue en est une autre.

ArchUnit permet de définir et de vérifier automatiquement que votre projet respecte les règles architecturales que vous vous êtes fixées. En vous affranchissant de ces vérifications manuelles, vous aurez plus de temps pour vous concentrer sur ce qui compte vraiment pour vous : produire du code de qualité et développer de nouvelles fonctionnalités innovantes pour vos clients.

L'intégration d'ArchUnit dans vos projets Java est simple et rapide : il vous suffit d'ajouter la librairie qui correspond à votre version de JUnit et le tour est joué ! Sa flexibilité et son extensibilité en font un outil puissant capable de s'adapter aux besoins spécifiques de chaque projet. De plus, la possibilité de geler des règles vous permet de remédier progressivement aux violations existantes, sans impact immédiat sur vos développements.

Vous êtes en quête d'idées de règles à appliquer à vos projets ? N'hésitez pas à consulter la documentation officielle d'ArchUnit. Vous y trouverez de nombreux cas d'usage qui pourront vous aider à trouver l'inspiration.

Pour les utilisateurs avancés, voici quelques pistes que vous pourriez explorer pour aller plus loin.

Mettre en place une règle pour vérifier que vous n'avez pas d'annotations @Autowired sur vos attributs (préférez les injections par constructeur),
Exporter vos règles dans une librairie dédiée (idéal si vous avez de nombreux projets qui doivent respecter les mêmes règles),
Générer vos règles ArchUnit à partir de diagrammes de classe PlantUML (exemple à cette adresse)

Si à la suite de cet article vous avez sauté le pas, n'hésitez pas à partager vos retours d'expérience. Je suis curieux de savoir comment vous avez adopté ArchUnit au sein de vos applications !