🚀 Full room and a fantastic group of Java developers for the 2h Microcks workshop at DevLille 2026!

A great session led by Sébastien Degodez (AXA) and Laurent Broudoux, exploring how to leverage Microcks and Testcontainers to confidently validate APIs and microservices.

Thanks to everyone who joined, asked questions, and shared their experiences 🙌

#DevLille #Microcks #Java #APITesting #Testcontainers #OpenSource

[DevLille] 3 ans de DevEx pour 3000 ingénieurs : de la stratégie à l’impact !

Pour une bonne expérience de développeur, il faut trois choses

Adeo en quelques chiffres : 15 marques, 1300 magasins, 3ème groupe mondial de vente de bricolage.

Chez Adeo, il y a entre 1000 et 5000 développeurs, avec énormément d’outils, et des équipes de plateforme qui ne prennent pas les retours des utilisateurs.

Thomas et Julien ont tenté de corriger ça avec le DevHub, résultat d’un plan de plusieurs années.

Les fondations

Qui sont les développeurs, où ils travaillent, et avec quels outils. Quelle source de vérité identifie les développeurs ? GitHub, bien sûr ! En cherchant les commits et en liant les types de fichiers aux développeurs, ils ont pu compter les développeurs. Ensuite, pour voir sur quoi travaillent les développeurs, ils ont créé un tech radar. Ce tech radar est automatisé, en lisant les données FinOps, les repositories GitHub, et les fichiers SBOM. Grâce à ça, l’équipe a fourni aux développeurs un tableau de bord éditable (pour éviter les faux positifs). Enfin, ils sont allé voir les développeurs pour savoir quels outils étaient utilisés par les développeurs (CI, observabilité, outils de collaboration).

Et le DevHub a été créé pour fournir un point d’entrée unique pour comprendre cet écosystème

Outils de communication

Il a fallu ensuite créer des outils de partage qui marchent à l’échelle, et donc des canaux de communication dédiés. Julien en présente deux : la newsletter hebdomadaire, et les tech bubbles (des événements de partage présentant de l’expertise). Il a fallu aussi des canaux de communciation spécialisés. Donc des canaux Slack ont été créés où les gens sont ajoutés automatiquement selon leurs commits. Enfin, l’innersource, déja important chez Adeo est augmenté par un portail présentant des starters kits pour les différentes plateformes.

L’onboarding est un sujet important, puisqu’Adeo compte aujourd’hui environ 2300 développeurs, avec un turn-over significatif (en particulier chez les prestataires). L’équipe a donc défini un trajet d’onboarding dans lequel ils vont, selon le type de profil, proposer des formations spécifiques. DevHub intègre des sensibilisations pour plus de 100 outils, et 10 nouveaux arrivants sont embarqués chaque semaine.

Et c’est le moment de la démo.

Thomas nous montre la carte des outils disponibles, mais aussi les vidéos en l’illustrant avec le framework de micro-frontend local, Kobi. Et il enchaîne avec un exemple de parcours d’onboarding.

Comme DevHub facilite l’onboarding, l’équipe a voulu également mettre en place du training.

Obtenir du feedback

Deux fois par an, l’équipe demande à tous les développeurs du groupe leur avis sur les outils qui sont utilisés. DevHub va permettre d’analyser le feedback, de prioriser les évolutions et de piloter ces évolutions. Lors de la dernière campagne, l’équipe a récolté ~10.000 feedbacks. Et ils essayent aussi de capturer des user journeys de développeurs. Le but est de voir au-delà des outils afin de savoir si l’expérience des développeurs est bonne. Avec ça, ils mesurent le pourcentage de satisfaction (objectif au-dessus de 70%) et d’irrtation (objectif en-dessous de 10%).

Mais comment identifier les nouveaux besoins ? En allant faire de l’ethnologie dans les équipes. Par exemple, Adeo est récement passé de Vault à OpenBao. Dans ce cas, Thomas est allé vérifier que la migration se faisait sans douleur dans les équipes. Et pour garantir que ces projets sont des succès, il y a aussi de l’accompagnement aux nouveaux outils.

Sur les environnements locaux, Thomas en a parlé ce matin et à DevoxxFr.

Aller plus loin

Qu’est-ce qu’on peut encore ajouter à tout ça ? Pour Julien, on pense évidement à ajouter de l’IA en déclinant tous les outils : channel Slack, AI Engineering Champions, AI Hub (qui arrive bientôt), Summer of LLM. Mais l’expérience développeur, ça n’est pas que de l’outillage. Il y d’autres indicateurs (flow state, documentation, collaboration entre équipes, focus client, organisation du travail, …). Tout ça va rentrer dans un Developer Experience Index.

Et en fait, tous ces outils sont utilisables également sur d’autres profils, en remplaçant la developer experience par l’engineering experience.

[DevLille] Métier vs Technique : réconcilier deux mondes grâce au domain driven design

Mathilde a découvert dans sa mission actuelle le rôle de product manager dans une équipe qui ne travaille que sur du middleware. Et elle a découvert l’event storming, qui l’a aidé à comprendre son domaine.

L’event storming vient du monde du DDD, basé sur deux principes

Il y a également deux perspectives : la stratégie s’intéresse au système global, et la tactique, qui s’intéresse à une partie identifiée du système. On va découper notre domaine en sous-domaines (par exemple dans le e-commerce le catalogue produit, le panier, la commande, le paiement, la livraison, …) et pour chacun d’entre eux on va lier les experts métiers et techniques. Pour ce sous-domaine, on va construire pour chaque problématique un contexte borné. Et on définit dans ce sous-domaine un langage ubiquitaire.

Muni de toutes ces notions, l’event storming est un atelier de réflexion collective qui permet d’aligner la compréhension en modélisant un métier, un processus afin de cartographier la connaissance (pour voir en particulier les zones d’ombre). IL y en a environ 3 types : la big picture offre en amont une compréhension globale, le process modeling permet de zoomer sur une partie identifiée dans la big picture et permet d’identifier les personas, policies et objectifs, et enfin le software design permet de descendre dans les détails de l’implémentation technique.

La vision métier et DDD utilisent des termes un peu différents qui se mappent néanmoins très bien.

La big picture et le story mapping ne sont pas exactement identiques. La big picture modélise des processus complexes, aligne les acteurs et visualise les obstacles et zones d’ombre. En revanche le story mapping découpe et priorise un besoin clair, facilite les échanges dans l’équipe et permet de séquencer les développements.

Si vous voulez animer un atelier big picture, il vaut mieux

• Le faire en présentiel
• En 2 heures maximum
• Avec le matériel classique d’animation (salle, tableau blanc, post-its, stylos, …)
• Et surtout avoir tous les interlocuteurs sachants sur le process

Il faut être clair sur l’objectif : on s’aligne sur le comportement attendu, et on cherche à identifier les problèmes, les zones d’ombre, les conflits, sans chercher à les résoudre.

On commence par identifier les événements, puis on les organise sur une timeline (en alignant le langage utilisé). On y ajoute les systèmes, les personnas, et les hotspots (conflits, zones d’ombre). On identifie ensuite les événements pivots (qui permettent de trouver les bounded contexts).

Pour aller plus loin, on peut évidement lire le livre Domain Driven Design.

[DevLille] J’ai ton numéro de CB dans ma BDD

Purse a conçu un coffre-fort numérique pour stocker des numéros de carte bancaire.
Sur une carte bancaire, on trouve

• Un personal access number (PAN)
• Une date d’expiration
• Un nom de porteur
• Un réseau de paiement (et CB ne veut pas dire carte bleue, mais carte bancaire)
• Un cryptogramme (ou CVV)

Purse est un orchestrateur de paiement. Parce que le monde du paiement a un vocabulaire complet.
Quand un acheteur effectue une transaction, il passe par un PSP (un partenaire technique) qui va adresser la demande à la banque acquéreuse, qui va passer par le réseau de paiement pour demander la transaction à la banque de l’acheteur. Purse se place avant les PSP. Purse manipule pour ça des informations sensibles (le PAN et le CVV). L’industrie bancaire a définit le standard PCI-DSS pour valider la sécurité de stockage. Ce standard implique plus de 300 exigences à prouver. Comme c’est très impactant, les acteurs essayent d’isoler dans le système d’information la zone stockant ces données (que Thomas appelle un vault), pour ne pas avoir à valider tout le SI. Pour identifier une carte bancaire, on lui associe un token qui garantit que le PAN ne sort pas de ce vault.

A l’origine, Purse utilisait un vault fourni par une entreprise externe. Mais en 2025, ils ont décidé de le réécrire.

Alors comment on construit un vault validé PCI-DSS ?

D’abord en prenant des fournisseurs conforme à PCI-DSS : GCP, MongoDB Atlas, Okta et Cloudflare.

Au coeur de ce système, il y a du chiffrement, et en particulier un tokenizer qui génère un token pour chaque carte bleue, puis chiffre le PAN et CVV avant de les sauvegarder en base. Concernant le chiffrement, il doit être réversible, donc c’est de l’AES-256- CGM. Les clés de chiffrement tournent tous els mois, personne ne les connaît, et elles sont stockées dans un hardware security module. Purse a aussi réfléchi à une solution sans vendor lock-in.
Tout ça est implémenté par un key management system (KMS) fourni pour l’instant par GCP.
Comment ça marche ? Purse génère à partir d’une key encryption key (que Purse connaît) une data encryption key utilisée pour chiffrer les données avant de les stocker dans MongoDB. Purse dispose d’un data encryption key par partenaire technique. L’avantage de séparer les choses, c’est que les rotations de key encryption key n’impliquent pas le rechiffrement de toutes les données, mais juste de la data encryption key.
Le chiffrement est en fait exécuté par le driver MongoDB CSFLE. Pour ça, on récupère la data encryption key (chiffrée dans MongoDB), on la déchiffre dans le client, et de cette manière la donnée non chiffrée n’est jamais visible en dehors du client.

Un intérêt de MongoDB est la capacité de faire des index avec time to live intégré. Du fait de PCI-DSS, le CVV doit être stocké dans un serveur Valkey uniquement en mémoire. Enfin, dans les serveurs Valkey, que le client gère comme un cluster, mais sans communication entre les différents serveurs (pour respecter PCI-DSS).

En 2026, on essaye de faire le tunnel de paiement dans la page du client, plutôt qu’à travers des redirections. La technologie standard pour ça … c’est l’iframe ! Et pour synchroniser les deux fenêtres, un client JS est fourni au client qui communique avec l’iframe à travers postMessage.

En terme d’infrastructure, le vault est exécuté par Google Cloud Run, parce que ça simplifie la gestion du service tout en diminuant la surface d’attaque. Ca apporte aussi une segmentation réseau qui isole le vault du reste de l’infrastructure de Purse. Grâce au secure web proxy fourni par Google garantit la validité du traffic. Enfin, le service est identifié en passwordless grâce à la workload identity federation.

Pour éviter les attaques de chaîne d’approvisionnement, Purse écrit les signatures des dépendances de son projet pour garantir que ce sont les bonnes dépendances qui sont utilisées.

Au vu de la complexité du système, il faut automatiser les choses autant que possible. Ca permet de simplifier la conformité, mais aussi de faire en sorte qu’aucun humain n’accède à la production.

Purse a commencé le développement de ce vault en mai 2025, a atteint la certification PCI-DSS en décembre 2025. Aujourd’hui, 95% des flux passent par le vault interne.

Aujourd’hui, Purse se demande si il ne faudrait pas appliquer aux données personnelles les mêmes idées que pour les numéros de carte bleue.

[DevLille] Le jour où nous avons arrêté de publier des messages Kafka depuis notre API… et pourquoi cela a renforcé notre architecture orientée événements

En fait, la présentation va nous parler de ce qu’est le dual write, et comment le résoudre avec l’outbox pattern.
Chez Decathlon, pour gérer les cartes cadeaux, ils ont une application qui gère la commande des cartes, active les cartes cadeau et met à jour le compte client.
Et bien sûr, tout est asynchrone.
L’architecture semble parfaite … mais c’est là que s’invite le dual write. Imaginons par exemple que dans la même transaction, on envoie le message Kafka, et on écrit dans la base de données.
Kafka n’étant pas transactionnel, même si la transaction est annulée, le message part quand même.
Et si le timing est incorrect, on peut aussi avoir des données incohérentes dans le consommateur Kafka.
L’équipe de Virginie a donc réfléchi.
Ils ont d’abord tenté d’envoyer un message d’undo … ça ne marche très bien quand on envoie des mails, par exemple.
Ils ont aussi tenté de faire du rety, mais ça a tendance à partir en boucle infinie.
Ils ont également essayé de modifier l’ordre des opérations, mais ça ne change rien.

Et finalement, ils ont mis en place l’outbox pattern : on écrit les messages Kafka dans une table de la base de données, qu’on envoie ensuite grâce à Debezium déployé dans un cluster Kafka.
C’est compliqué, mais ça apparaît comme le standard.
IL y a quelques variantes, comme par exemple envoyer le message Kafka, et de là l’écrire dans la base de données. On peut aussi écrire dans les logs de Postgres et de connecter Debezium dessus.
On peut aussi ne pas stocker les messages Kafka dans la base de données, mais les générer dans Debezium à partir de la table utilisée par l’application.

L’équipe a choisi la dernière variante, même si elle implique un couplage entre l’émetteur et les consommateurs, et complique l’idempotence.

Tout ça implique évidement Debezium. Et Virginie a quelqeus conseils sur ce sujet.

Debezium est configuré pour le lire le write ahead log de PostgreSQL.
A chaque log (donc à chaque transaction), Debezium va mettre à jour son replication slot.
Et PostgreSQL supprime les logs du WAL après lecture.
Si le connecteur s’arrête de lire les lohs, ça peut faire tomber PostgreSQL parce que ce replication slot prendra de plus en plus de place.
Ca arrive dans deux cas

Pour éviter ça, il faut configurer un heartbeat (stocké dans la base de données) et du monitoring.
Virginie conseille de mesurer l’espace disqeu restant, et le taux d’écriture du heartbeat connecté aux messages émis dans Kafka.

[DevLille] Et si on ouvrait le capot de PostgreSQL

Oh mais dites donc, c’est le DevLille !
Et pour commencer simplement, l’excellent Benjamin Coenen soulève le capot de PostgreSQL.
Il travaille chez Supabase, qui fournit du backend web as a service basé sur … PostgreSQL.

La présentation sera évidement très simplifiée.

Parlons des termes …
Un serveur pg peu héberger plusieurs bases.
Dans chaque base, il y a des objets (tables, indexes, séquences, vues, fonctions) qui sont référencés par des OIds (des entiers de 4 octets).
Ces OIDs sont référencés dans des catalogues système (pg_database, pg_class, pg_namespace, …).
D’un point de vue fichier, on a pour chaque base tout un tas de fichiers.
Le plus intéressant est le dossier base qui contient les données, dans un sous-dossier portant comme nom l’OID.
On y trouve les données, un fichier *_fsm contenant l’espace vide, et un fichier *_vm donnant l’information de visibilité.
Le fichier de données est découpé en pages de 8 Kb.
Chaque page a la même organisation: une entête contenant les pointeurs vers les lignes, et des tuples contenant les données des lignes. L’intérêt de l’indirection, c’est de limiter les manipulations sur les tuples quand on modifie leur indexation (on ajoute un index ou on le supprime, voire on supprime les lignes).

Parlons des processes …
Postgres est multiprocess.
Quand un client se connecte à postgres, il crée un process qui discute avec une mémoire partagée qui va discuter avec les process internes de pg. Par défaut, pg limite le nombre de clients à 100 (d’où les pg-pool et autees proxies).
Les processes internes n’écrivent pas directement les données sur le disque, mais écrivent dans ces zones de mémoire partagée.
C’est un process particulier, le background_writer, qui va écrire les données sur disque toutes les 200 ms.
Le checkpointer fait à peu près la même chose (on y reviendra plus en détail).
L’autovacuum va nettoyer la base de données toutes les minutes.
Le WAL writer synchronise le write ahead log avec le disque.
IL y en a d’autres … Mais globalement, les processes internes sont tous là pour écrire des données particulières sur le disque.

Parlons des requêtes …
Une requête SQL est parsée, analysée, réécrite, planifiée et finalement exécutée.

Pour Benjamin, la partie marrante est la gestion de concurrence, le MVCC (multiversion concurrency control).
Chaque opération est effectuée au sein d’une transaction, explicite ou implicite.
Revenons à nos fichiers de données. Chaque tuple a un HeapTupleHeaderData qui contient quatre valeurs intéressantes

Par quelques exemples que je ne reproduira ici, Benjamin nous introduit le concept de commit log (plus souvent appelé clog) qui contient le journal d’exécution de ces différentes transactions.
Celui-ci permet notament de voir quelles données ne sont plus visibles, et peuvent donc être supprimées sans problème (grâce au VACUUM).
Les transactions ont différents niveaux de visibilité qui permettent de savoir quand elles sont accessibles.

Pour revenir au VACUUM, il fonctionne un peu comme un garbage collector en 3 phases

Postgres est résilient parce que le write ahead log est persisté sur disque (d’une manière très semblable à des systèmes de persistance Java comme space4j ou prevayler).

💜 Les coachs du Tremplin (2/2)

👤 Alice PELTIER
👤 Audrey Wech
👤 Élisa Degobert

🙏 Merci pour leur engagement auprès des futurs speakers.

#DevLille #communautetech

💜 Les coachs du Tremplin DevLille × Cloud Nord × Agi'Lille

Le Tremplin, c’est de l’accompagnement et du partage.
6 candidats seront coachés par des bénévoles de la communauté tech.

🎯 Structurer un talk.
🎯 Gagner en confiance.
🎯 Monter sur scène.

👤 Ludovic CHOMBEAU
👤 Nabil Boulehrouz
👤 Johan Dufour

👇 Suite dans le post suivant

#DevLille #TremplinTech

💬 Retour d’XP — Tremplin 2025

« Coaching de qualité, avec des conseils concrets qui m’ont aidé à progresser dans mes présentations. » — Hakim Lakrout

Des conseils pratiques et un vrai accompagnement pour améliorer sa prise de parole. 🎤💡

#DevLille #CloudNord #AgiLille #TremplinTech