Bpifrance présent en tant que sponsor et avec ses speakers !

Cette année, grâce à l’engagement de sa communauté tech, bpifrance.io ; Bpifrance était sponsor de la conférence, ce qui s’inscrit à la fois dans notre volonté de développer notre présence dans l’écosystème tech mais aussi de mettre nos expertises au service de tous.

Willy Malvaut, CyberSecurity Architect a donc eu la chance d'animer un workshop ,“La sécurité en double aveugle : venez relever le défi du kata d’architecture et cybersécurité communautaire” et également de faire un talk “La résilience, c'est l'affaire de tous, donc c'est l'affaire de PersonneS !” en partenariat avec Benjamin Gakic, Security Product Manager chez Bpifrance.

 

 

Retour sur les talks

Keynote Anatomie d’une Backdoor : XZ Utils par Wassim Ahmed-Belkacem et Quentin Dunand

Quentin et Wassem nous ont parlé de la fameuse backdoor détectée fin mars 2024 sur l’outil de compression XZ Utils. Avec un très bon storytelling, une dose d’humour et des slides léchées, les deux speakers nous ont conté cet incident qui a fait trembler le monde de l’open source et où comment un individu (ou un groupe d'individu) ont utilisé des méthodes d’engineering social pour infiltrer et prendre le contrôle d'un projet open source github utilisé par openssh pour y inclure une backdoor d’une grande sophistication.

À l'heure actuelle, nous ne savons pas exactement qui a orchestré cette attaque qui s’est étalée sur plus de 4 ans! Mais de forts soupçons portent sur un groupe étatique et notamment la Russie.

Lien d’une version antérieur enregistrée : https://www.youtube.com/watch?v=Uw5qDg4cS0g

OpenRewrite: Refactoring as code par Jérôme Tama

Vous rêvez d’automatiser vos tâches de refactoring ? Par exemple, réaliser une migration de JUnit 4 vers JUnit 5, une montée de version de votre framework préféré, tel que SpringBoot 2 vers SpringBoot 3, etc…. Et bien ne rêvez plus! OpenRewrite est un outil qui va vous permettre d’appliquer des “recipes”, autrement dit des recettes qui s’occuperont de modifier le code pour vous.

Sans rentrer dans les détails, OpenRewrite vient avec une liste de recettes sur étagère fournies par la communauté que l’on peut utiliser directement. Mais que l’on peut également modifier, composer à partir de recettes existantes ou même créer ses propres recettes! Cherry on the cake, on peut (ou on doit?!) tester unitairement ses recettes!

Petit fun fact, à la fin de son refactoring, OpenRewrite vous indique le temps gagné par rapport à un refactoring manuel!

Pour les plus curieux, les démos réalisées par le speaker sont disponibles sur ce projet Github.

Petite note de Willy : A la suite d’une discussion avec Jérôme et Nicolas Delseaux (CTO Zenika Lille) sur le sujet OpenRewrite pour avoir des retours un peu plus complets, nous sommes arrivés à la conclusion que cet outil est très spécifique au monde Java. Pour le dire autrement : OpenRewrite est très puissant et offre réellement une nouvelle approche pour le refactoring de masse, basée sur la suggestion (i.e. OpenRewrite demande la relecture d’un humain et ne fait pas directement de Pull Request, ce qui est très bien), mais nous ne connaissons pas d’équivalent pour d’autres langages, à l’heure actuelle.

10 fonctionnalités utiles du web que vous ne connaissez pas par Olivier Leplus et Yohan Lasorsa

Une collaboration AWS et Microsoft, on ne voit ça qu’au Snowcamp 🙂

 

Savez-vous que le TC39 est le groupe qui s’occupe de définir le standar EcmaScript avec comme implémentation la plus connue JavaScript ?

Durant cette présentation, les deux speakers nous ont présentés des fonctionnalités du langage en cours ou déjà implémentées par les navigateurs qui méritent tout notre attention. En vrac et sans être exhaustif:

• Temporal API pour faciliter la création et manipulation des dates

• Compression Streams API pour compresser et décompresser directement dans le navigateur
• @property en CSS, qui permet de créer ses propres variables afin de s’assurer du type et d’autres contraintes
• Réaliser un alignement vertical en CSS ? Rien de plus simple avec la propriété align-content!
• Nullish coalescing assignment

• Envie de connaître la root cause de vos erreurs en Javascript ? Utilisez l’attribut cause de la classe Error!

 

Défier l'entropie : refaire ou remettre sous contrôle par Alexandre Jeambrun

Durant cette présentation, Alexandre a commencé par définir ce qu’est l’entropie logiciel. C’est la quantité de désordre dans un système et que, au fil du temps et des transformations que l’on applique à notre système, l’entropie continue d’augmenter. On peut, dans certains cas, faire le parallèle avec la dette technique.

 

Plus exactement, Frederick Brooks définit dans son article No Silver Bullet, 2 formes de complexités:

• la complexité essentielle : c’est celle du métier, des règles métier que l’on implémente. Elle est par nature incompressible.
• la complexité accidentelle : c’est celle que l’on ajoute par choix volontaire ou involontaire et que l’on appelle communément la dette technique.

 

A cela viennent s’ajouter deux autres complexités:

• la complexité technique: cela peut peut prendre la forme de contraintes de sécurité accrues, de difficultés de déploiement, d’outils mal adaptés pour l’expérience développeur.
• la complexité de collaboration : c’est la complexité relative à l’organisation, les échanges en son sein, ou tout simplement l’humain.

 

Une fois que la complexité accidentelle devient trop importante et que l’on n’arrive plus à livrer de valeur, c’est alors que l’on se pose la question : est-ce qu’il ne vaut pas mieux tout reprendre à zéro et réécrire le logiciel from scratch ?

 

Pour le speaker, la réponse est non. Car d’une part, il n’y a pas d’intérêt à vouloir réécrire pour simplement refaire les mêmes erreurs et aboutir au même résultat. Et d’autre part, qu’il est préférable de reprendre le contrôle. Traiter les points qui nous ont conduit à ce résultat.

 

Reprendre le contrôle c’est garder l’application en production pour avoir du feedback, se faire un harnais de tests automatisés solide, respecter les principes Agile avec comme exemple:

 

> Construisez les projets à partir de personnes motivées. Donnez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour mener à bien le travail.

 

C’est aussi appliquer des pratiques craft comme séparer et ne pas coupler son codé métier de son code purement technique, avoir un design évolutif, refactorer régulièrement son code (appliquer la règle du boyscout), etc…

 

Et pour terminer, en réalisant ces changements, il faut bien entendu mesurer l’impact. Et pour cela, le speaker nous suggère de mesurer les DORA Metrics (Accelerate) que sont:

• Deployment frequency (DF)
• Lead time to changes (LT)
• Mean time to recovery (MTTR)
• Change failure rate (CFR)

 

Une très bonne conférence qu’il m’est difficile de résumer ici mais que je recommande.

Tester c’est tricher par Jules Poissonnet et Antoine Caron

Le talk part d'un constat, lorsque l'on parle test dans le monde du développement logiciel, on peut se heurter à des dogmes voire même à du cargo cult.

Notamment, l'une des stratégies les plus connues est la pyramide des tests. Cette dernière, souvent reprise, transformée, adaptée voire dévoyée, date en réalité de 2009. Elle a été créée par Mike Cohn dans son livre “Succeeding with Agile: Software Development Using Scrum”.

La pyramide des tests date d’une époque où effectivement les tests UI, les tests d’IHM étaient coûteux à maintenir et à mettre en place mais est-ce toujours le cas aujourd’hui? Dois-t-on appliquer ses principes by the book ou au contraire se les approprier?

Ils nous suggèrent alors de réfléchir à la question : “Comment tu testes?” (question qu’ils aiment poser en entretien d’embauche). C’est à dire qu’il nous indique qu’il n’existe pas de silver bullet mais plutôt que nous devons réfléchir à notre stratégie de test. Pourquoi il est plus important d’investir du temps dans ces types de tests plutôt qu’un autre, etc….

Il faut donc s’interroger sur sa stratégie de test en gardant à l’esprit 5 piliers :

• Stabilité, les tests nous garantissent de la non régression
• Intégrité, les tests nous donnent l’état de confiance du code
• Documenter, les tests sont la documentation vivante du code
• Conformité, les tests nous garantissent que le code produit est conforme à l’attendu métier (Approche TDD)
• Reproductibilité, les tests nous permettent d’automatiser les choses pénibles

Afin d’expliciter et de faciliter la transmission de ce qu’est notre stratégie de test, les speakers nous conseillent d’ajouter à la racine du projet un fichier TESTING.md au même titre qu’un README.md.

Pour finir, les speakers nous laissent quelques conseils :

• s’orienter vers une stratégie de test en diamant
• Adopter le BDD et l’ATDD
• Préférer Vitest, plus performant, à Jest qui aujourd’hui n’est plus à jour de node
• Adopter Playwright pour les tests UI
• Mocker les API de vos tests UI, car en réalité on ne souhaite que tester l’interface.
• Utiliser le langage Gherkins pour définir les tests, ils pourront alors servir de documentation vivante
• Prendre autant soin de la base de test que de la base de code
• Cibler vos tests, c’est à dire qu’il est possible de n’exécuter des tests qu’en fonction des fichiers modifiés. Ce qui peut faire gagner du temps mais attention à ne pas l’appliquer partout!

 

Le pattern Hive : une stratégie de modularisation pour votre monolithe modulaire ou vos microservices par Thomas PIERRAIN et Julien Topçu

 

 

Lorsque l’architecture microservice s’est répandue dans notre industrie, elle s’est également répandue avec son lot de pièges.

Dans un projet naissant, le contexte métier peut être encore flou et ce même de la part des experts métiers. Alors pourquoi vouloir se lancer dans une architecture microservice qui va figer nos frontières métier ? Le métier évolue, alors l’architecture doit être évolutive!

Retenez que l’architecture microservice est une stratégie de déploiement et non une stratégie de design!

C’est là qu’arrive le Hive Pattern pour nous permettre de créer un monolithe modulaire. On reprend les principes de Ports & Adapters (architecture hexagonale) inventé par Alistair Cockburn pour correctement isoler notre domaine métier au sein même de notre monolithe.

L’intérêt est triple! Dans un premier temps, s’éviter un plat de spaghettis ou “big ball of mud”. Puis dans un second temps, avoir la capacité, au besoin, d’extraire les modules pour en faire des applications indépendantes ou des microservices.

Prenons l’exemple d’un module fortement consommateur en CPU ou en mémoire de part son métier. Avec cette architecture, nous pourrons alors facilement changer notre stratégie de déploiement pour en faire une application à part de notre monolithe afin d’adapter les besoins CPU et ou de mémoire.

Et enfin dans un troisième temps, l’intérêt d’un monolithe est aussi d’avoir tous ces outils de refactoring au même endroit. Lorsqu’une modification impliquant plusieurs modules, on comprend aisément qu’elle est plus simple à faire au sein d’un même projet que sur plusieurs microservices distribués.

Une conférence très bien faite, claire et qui mérite d’être vue. Bravo aux speakers.

Techno-Autoritarisme et design persuasif : quels risques pour nos libertés ? par Marcy Ericka CHAROLLOIS

Impossible pour moi de vous résumer ce talk pour vous en extraire la substantifique moelle mais je ne peux que vous le suggérer! Il s’agit d’un talk qui parle de sujets importants, qui parle du contexte politique dans lequel se trouve les Etats-Unis d’Amérique (sans vouloir citer les principaux protagonistes), de l’influence que peuvent avoir les réseaux sociaux sur nos vies, nos interactions et bien entendu nos idées politiques. Le talk se veut plein d’énergie, interactif, sourcé et le tout dans une présentation soignée.

Malgré cette pluie d’informations déprimantes, nous ressortons à la fin du talk avec l’envie de reprendre le contrôle de nos données face aux géants de la tech, l’envie de ne pas se laisser tromper par des algorithmes toujours plus sophistiqués en gardant en tête que la tech est politique!