Retour sur le BreizhCamp 2024 : Édition Star Wars

21 janvier 2025 Damien Le Dantec

Le BreizhCamp était de retour cette année pour sa douzième édition du 26 au 28 Juin 2024 sur le thème Star Wars !

Zenika est toujours au rendez-vous après 12 ans en étant sponsor Platinum de cet évènement qui rassemble maintenant plus de 1000 passionnés autour de près de 100 thèmes présentés. Le premier jour permet principalement d’assister à des ateliers tandis que les 2 jours suivants sont dédiés à des conférences plus classiques allant de quickies de 15 minutes le midi à des sujets de 55 minutes.

Le BreizhCamp est toujours très attendu par les participants. Depuis 2022, un tirage au sort est effectué pour distribuer les billets. Toujours dans l’optique de rester accessibles, les tarifs restent raisonnables pour ce type d’événement (75€ pour 2 jours, 90€ pour 3).

Zenika présent avec notre stand et nos speakers

Nos speakers étaient particulièrement présents cette année avec de nombreux talks, plus exactement 12 speakers pour 4 universités, 6 conférences et 1 quickie sur les 98 sessions de cette édition. Voici les liens des sessions de nos speakers :

“Voyage au coeur d’Appwrite : le backend open-source qui challenge Firebase” : Lucas Audart & Mickael Alves
« Parcours initiatique sur l’authentification avec Keycloak » : Jérôme Marchand
“Migration de projets Terraform vers Terragrunt » : Jérôme Marchand
« La Diva, la Rockstar et le consultant » : Antoine Cailly
« Redis, le plus sous-estimé des plus utilisés ! » : Adrien Wattez
« La bienveillance, (je trouve que) c’est de la 💩 » : Malo Toanen & Luc Sorel-Giffo
« Stockage web : le guide galactique » : Anthony Le Goas
« Et si vous mettiez à disposition vos jobs de CI/CD sur une étagère ? » : Jules AGOSTINI & Jean-Philippe Baconnais
« Ce que j’aurais aimé savoir avant que ma JVM n’explose en prod » : Hugo Metivier
« APIs ♥️ HTML » : Benoit AVERTY
“Comment j’ai trouvé le sens de la vie grâce à WebAssembly” : Théo Gianella

En plus des speakers, nous étions plus d’une vingtaine à venir profiter de l’événement.

Cette année sur le stand Zenika, nous pouvions retrouver plusieurs activités : une machine à granité (glace pilée aromatisée) pour rafraîchir les participants et plusieurs cadeaux étaient à gagner grâce à un quizz sur le thème de Star Wars.

Cependant, l’activité principale était la réalisation par les visiteurs d’un Légo représentant le croiseur d’assaut de la classe Venator !

Sélection des talks qui nous ont plus

Keynote du jeudi matin (Lionel Dricot)

La journée du jeudi a été lancée par la keynote de Ploum (Lionel Dricot). Son talk permet de prendre de la hauteur sur le monde de l’informatique et de relativiser sur les “bulles” technologiques telles que l’IA ou encore la blockchain. Selon Ploum, il est important de savoir être pragmatique sur les solutions à apporter dans nos métiers et de se concentrer sur la résolution de problèmes plutôt que la mise en place de solutions “hypes” qui pourraient ne pas être pertinentes en fonction du contexte. La hype ou bulle technologique peut être défini selon Ploum par :

Mon truc qui fait “pouet pouet” est mieux que ton truc qui fait “coin coin”.
Enthousiasme irraisonné
Warren Buffet disait “si ma femme de ménage me demande quelles actions acheter en bourse, c’est le moment où je dois tout vendre”.
Si on se met à en parler sur LinkedIn, c’est qu’il est urgent de passer à autre chose.

Pourquoi participer à une course marketing pour vendre de la nouveauté et produire des profits sans se soucier de l’utilité finale, des besoins réels et des impacts (sociétaux, écologiques, etc.) ?

Ploum nous pousse à nous rappeler le sens de nos métiers technologiques, l’utilité de ce que l’on produit, la finalité de nos missions, les besoins auxquels on répond.

Toujours dans un souci de durabilité, Ploum préconise pour progresser de se concentrer sur les connaissances durables telles que la dactylographie ou Git plutôt que sur des outils technologiques fortement soumis à un effet de mode.

Notre responsabilité en tant que développeur n’est pas de mettre en place la dernière solution technique la plus en vogue, mais de répondre au besoin de nos utilisateurs en mettant en place une solution durable.

Notre responsabilité de dire non ou au moins de demander pourquoi. Questionner à nouveau le but pratique pour penser des solutions plus durables (et souvent plus simples).

Model Mitosis : ne plus se tromper entre les microservices et le monolithe (Julien Topçu et Josian Chevalier)

Julien Topçu et Josian Chevalier nous on offert un talk sur l’utilisation du Model Mitosis pour concevoir une architecture. Illustré par une discussion d’architectes qui expliquent leur point de vue à un (long) daily, nous voyons de manière itérative la démarche du Model Mitosis.

La problématique est montrée sous la forme d’une confrontation entre une architecture monolithe et une architecture micro-services. Le but étant de voir les limites des 2 modèles sur un cas d’usage précis et d’utiliser le Model Mitosis pour avoir une approche dynamique sur la conception.

D’un côté, si nous partons tête baissée sur un monolithe, nous pouvons rapidement arriver à un logiciel “spaghetti” qui devient difficilement maintenable.

De l’autre, en cas de mauvaise conception d’une architecture microservices, nous pouvons tomber dans le cas d’un “monolithe distribué” où le couplage fort entre les services nous fait perdre tout l’intérêt de ce type d’architecture.

La démarche du Model Mitosis permet de partir d’un monolithe et de faire un découpage itératif en se basant sur les comportements de l’application plutôt que sur les concepts. L’idée est de retarder la séparation des domaines tant qu’ils ne sont pas correctement découplés. Par cette approche nous avons dans notre application un dossier “Shared Kernel” qui contient tous les concepts partagés par plusieurs domaines métier que nous cherchons à réduire peu à peu jusqu’à idéalement le voir disparaître. Le “Shared Kernel” peut aussi devenir à terme un “Generic Subdomain” qui pourrait potentiellement prendre la forme d’une librairie externe.

Au bout de la démarche, nous arrivons à un “monolithe modulaire” ou une architecture microservices si nous en avons le besoin.

Il est important de garder en tête que le passage en architecture microservices doit être guidé par des métriques métiers comme par exemple un besoin de scaling sur une brique spécifique.

Tests JavaScript : reconstituer le puzzle (Jean-François Greffier)

L’écosystème JavaScript est particulièrement riche en termes d’outils et le domaine des tests ne déroge pas à la règle. Jean-François Greffier nous apporte à travers ce talk un état des lieux de l’existant et tout un ensemble de recommandations en fonction de nos besoins.

Il initie ce talk en décrivant l’anatomie d’un framework de test. Il est important de connaître les différentes parties afin de comprendre sur quoi s’applique les différents outils de tests que nous connaissons.

Nous y retrouvons :

Les assertions
Le “test runner”
Le transformer (Quand on utilise TypeScript par exemple)
L’environnement (Quand on souhaite utiliser le DOM par exemple)
Les mocks

À ça nous pouvons ajouter dans une moindre mesure les outils de coverage, de reporting et de snapshot.

Pour illustrer ses propos, Jean-François Greffier s’est basé sur les sources de Vitest pour nous montrer chaque partie.

La cartographie des outils nous a permis d’identifier les principales librairies et de comprendre sur quelle(s) partie(s) d’un framework de test elles se concentrent.

Pour finir, Jean-François Greffier nous a donné ses recommandations en prenant comme critères la fiabilité et la vitesse d’exécution d’une solution. Ça nous donne Vitest pour les tests unitaires, l’utilisation de testing library avec Happydom pour les tests d’intégration et Playwright pour les tests E2E, sans oublier les tests statiques avec Eslint ou Stylelint.

La clean archi ça marche aussi pour le front (Dorian Lamandé)

Quand on parle d’architecture logicielle, on parle rarement d’architecture d’application frontend. Dorian Lamandé nous montre comment la clean architecture peut s’y appliquer.

De manière générale, pour toute application, sa devise est “Isoler c’est gagner”.

La valeur de la partie frontend réside dans les règles fonctionnelles, l’UX ou encore la représentation graphique du métier et en aucun cas les différentes technologies mises en place. C’est pourquoi isoler ces règles métier côté front nous permet d’isoler ce qui a de la valeur pour nos utilisateurs.

Tout au long de ce talk, c’est l’architecture “clean archigonale”, un mélange entre architecture hexagonale et clean architecture qui est exposée.

*Schéma issu du code source d’exemple, partagé lors du talk :* *https://github.com/betagouv/agir-front*

L’idée est que le composant front ne se charge uniquement de l’affichage et que le découpage se fasse par “use-case”. Chaque use-case a pour but d’ordonnancer les différentes actions telles que la récupération des données par exemple.

Différents “ports” et “adapters”, concepts empruntés de l’architecture hexagonale seront créés pour isoler la logique métier de la couche technique.

Ensuite nous avons le “Presenter” qui se charge d’implémenter les différentes logiques d’affichage et qui met en forme les données pour le composant.

Grâce à ce découpage, le développement est simplifié et notamment la partie tests. En effet, on peut facilement faire des tests unitaires pour les “use-cases” et “Presenter” et même avoir une démarche TDD. Un autre apport consiste à facilement mocker les appels réseaux et donc s’abstraire de l’implémentation back si cette dernière n’est pas encore prête.

Pour finir, Dorian rappelle bien que ce type d’architecture n’est pas la silver bullet du développement front. Il est important d’adapter l’architecture de son application en fonction de son besoin.

Alerte, tout brûle ! Comment gérer des incidents techniques (Alexis “Horgix” Chotard)

La gestion des incidents de production est un sujet particulièrement dense. En arrivant chez PayFit, logiciel de gestion de paie, Alexis Chotard (“Horgix”) a dû tout mettre en place, que ce soit d’un point de vue technique ou organisationnel.

Le première chose est d’expliquer ce qu’est un incident. On peut facilement le décrire par quelque chose qui nous éloigne de notre travail planifié avec un certain degré d’urgence. Un bug en production n’est pas forcément un incident mais on peut aussi avoir des incidents sans avoir de bug en production comme par exemple un dysfonctionnement chez notre Cloud Provider.

Une des premières choses à mettre en place pour une gestion d’incidents efficace est la clarification de la sévérité de ces derniers. Pour ça, pas besoin d’un arbre de décision complexe, 3 ou 4 niveaux avec du bon sens suffisent généralement.

D’un point de vue organisationnel, la définition d’un “Incident Commander” par incident est un bon point de départ. Cela peut être une personne technique ou non, qui se charge de coordonner, prendre du recul et communiquer sur l’évolution de l’incident.

Un indispensable est d’avoir la notion d’astreinte en fonction du niveau de service souhaité. Ce sujet mériterait tout un talk mais il est important d’avoir une équipe suffisamment nombreuse pour tourner régulièrement mais pas trop nombreuse pour ne pas perdre la main.

En termes d’outillage, plusieurs types sont importants. De l’alerting, un outil de gestion des astreintes ou encore une status page pour informer les utilisateurs.

Pour améliorer notre fonctionnement face aux incidents, il est important de mesurer leurs impacts et de qualifier leurs résolutions. Faire des post mortems est aussi très important.

Mais bien-sûr, le meilleur incident est celui qui n’existe pas. Pour ça nous pouvons nous appuyer sur des tests de charge, du chaos engineering ou encore l’utilisation de canary release.
Alexis a clôturé le talk sur la présentation de incident.io, un outil récemment mis en place dans son équipe afin de centraliser les différents outils pour les différentes phases de gestion des incidents.

Défier l’entropie : réécrire ses applications ou reprendre le contrôle ? (Alexandre Jeambrun)

Il arrive régulièrement que dans la vie d’un produit logiciel, la question de réécrire l’application sur une technologie plus récente se présente. C’est le cas où l’application devient de plus en plus complexe ou que la technologie utilisée devient dépréciée.

Alexandre Jeambrun nous fait part de son retour d’expérience sur ce sujet et met en lumière que décider de réécrire l’application est rarement (voir jamais) une bonne idée.

En effet, en cas de réécriture, plusieurs problèmes peuvent survenir. C’est d’autant plus le cas si nous profitons d’une refonte technique pour ajouter ou modifier des fonctionnalités. Si nous n’analysons pas les causes qui nous ont conduit à cette refonte, nous pouvons reproduire les mêmes erreurs et retomber dans ce même besoin de refonte très rapidement.

Avant de nous donner des outils afin de reprendre le contrôle de nos applications, Alexandre nous expose les sources de désordre d’une application.

On pense rapidement à la technologie dépréciée ou de mauvaise architecture qui conduit à une complexité mais nous avons aussi un facteur humain. Avec les compétences de l’équipe ou encore le turn-over qui peut désordonner notre application. Nous avons aussi l’environnement de travail, le marché qui évolue ou encore le changement de budget attribué à l’équipe qui peut avoir pour conséquence une réécriture.

Les différentes solutions apportées par Alexandre ont été classées par source de désordre.

Pour le côté humain, on peut citer le fait que l’équipe ait son mot à dire sur le recrutement, travailler sur l’onboarding mais aussi sur l’outboarding.

Côté technologie, séparer la logique métier de la technologie sous-jacente est un indispensable mais il faut aussi penser “modularité” et refactorer régulièrement pour ne pas laisser une complexité inutile s’installer.

Pour reprendre le contrôle d’une application qui est “en désordre”, il est nécessaire de refactorer et livrer de manière fréquente et itérative. On peut s’aider de tests et d’outils comme Sonar.

S’il y avait qu’une chose à retenir, c’est que réécrire une application n’est jamais une bonne idée.

La quête de la réactivité : L’odyssée des Signals (Stéphane Spassevitch)

Ces dernières années, nous avons vu une évolution du principe de réactivité dans les frameworks front-end avec l’arrivée (ou la remise en avant) des Signals.

Stéphane Spassevitch nous a retracé le fonctionnement de ce principe en partant des prémisses avec AngularJS jusqu’à aujourd’hui avec SolidJS qui a remis les Signals sur le devant de la scène.

Bien sûr, les principaux frameworks actuels (ReactJS, VueJS et Angular) ne sont pas oubliés et leurs principes de réactivité expliqués.

Issu d’une reconversion professionnelle et comptant maintenant 3 années d’expérience, Stéphane nous a apporté son analyse sur le sujet. C’est avec ce type de talk de qualité que nous voyons qu’il n’est pas nécessaire de faire un cursus “classique” pour avoir une bonne connaissance et une analyse pertinente sur des sujets complexes tels que la réactivité côté frontend.

Notre retour

Comme chaque année, le BreizhCamp a donné lieu à beaucoup de découvertes, d’échanges et d’apprentissage. Avec encore plus de choix cette année par rapport aux précédentes puisque le nombre de tracks a été augmenté (5 au lieu de 4). Une nouvelle édition avec comme à son habitude des intervenants de qualité sur des sujets d’actualité, tout en visant à réduire son impact écologique.