DevLille 2026 : retour des conférences

french— personal blog

Premier jour (11 juin 2026)

Une première chose à mentionner : les salles sont immenses, et l'équipement est de loin le meilleur que j'ai vu depuis que je participe à des conférences. Certaines salles, notamment Grand Théâtre sont clairement intimidantes même en tant que participant.

Et si on ouvrait le capot de PostgreSQL ?

J'aurais bien aimé participer à cette conférence ; il faut avouer que l'entrée est vraiment mal indiquée, pour ne pas dire pas du tout. Je ne pourrais donc pas dire grand chose sur cette dernière, n'ayant vu aucun siège disponible dans la salle, et quelques secondes seulement de bruit au micro du speaker.

Noms de domaines : la grande histoire des petites extensions

J'ai beaucoup aimé la structure de la présentation (comme souvent avec OVH) qui revient sur le fonctionnement historique des DNS, mais aussi des noms de domaines.

La première découverte, c'est l'existence de domaines de second niveau pour le Japon ou l'Italie (je ne connaissais que l'existence du .co.uk). La gestion de ces domaines appartient toujours à l'organisme national, en France par exemple avec le .gouv.fr.

Justement, faisons un petit test, en résolvant wikipedia.fr avec dig +trace (j'ai enlevé certaines parties pour plus de lisibilité) :

.			36323	IN	NS	h.root-servers.net.
;; Received 1097 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

fr.			172800	IN	NS	d.nic.fr.
;; Received 564 bytes from 198.97.190.53#53(h.root-servers.net) in 369 ms

wikipedia.fr.		3600	IN	NS	ns-62-c.gandi.net.
;; Received 499 bytes from 194.0.9.1#53(d.nic.fr) in 117 ms

wikipedia.fr.		10800	IN	SOA	ns1.gandi.net. hostmaster.gandi.net.
;; Received 101 bytes from 217.70.187.63#53(ns-62-c.gandi.net) in 56 ms

On voit ici un cheminement classique d'une requête DNS intégrale :

  1. Résolution des serveurs de noms de la racine ., en désignant ici le serveur h(.root-servers.net.) (Laboratoire de recherche de l'armée américaine), reçu par 127.0.0.53 (systemd-resolved).
  2. Résolution des serveurs de noms du premier niveau fr., en désignant ici d.nic.fr (AFNIC), reçu par h(.root-servers.net.) (Laboratoire de recherche de l'armée américaine).
  3. Résolution des serveurs de noms du second niveau wikipedia.fr., en désignant ici ns-62-c.gandi.net., reçu par d.nic.fr (AFNIC).
  4. Résolution de l'enregistrement SOA du domaine wikipedia.fr., en désignant ici ns1.gandi.net. et hostmaster.gandi.net. (Gandi).

Regardons maintenant la même approche pour impots.gouv.fr :

.			35704	IN	NS	a.root-servers.net.
;; Received 1097 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

fr.			172800	IN	NS	g.ext.nic.fr.
;; Received 559 bytes from 198.41.0.4#53(a.root-servers.net) in 278 ms

fr.			600	IN	SOA	a.nic.fr. dnsmaster.afnic.fr.
;; Received 401 bytes from 194.0.36.1#53(g.ext.nic.fr) in 127 ms

impots.gouv.fr.		3600	IN	NS	dns2.impots.gouv.fr.
;; Received 495 bytes from 194.0.9.1#53(d.nic.fr) in 45 ms

Même exercice :

  1. Résolution des serveurs de noms de la racine ., en désignant ici le serveur a.root-servers.net., reçu par 127.0.0.53 (systemd-resolved).
  2. Résolution des serveurs de noms du premier niveau fr., en désignant ici g.ext.nic.fr, reçu par a.root-servers.net..
  3. Contrairement au cas de wikipedia.fr, la résolution ne fait pas apparaître de délégation publique de gouv.fr. : le serveur autoritaire de fr. répond encore pour la zone fr. elle-même, avec le SOA a.nic.fr. dnsmaster.afnic.fr..
  4. La délégation visible concerne directement impots.gouv.fr., avec ici un serveur de noms dns2.impots.gouv.fr., réponse fournie par un serveur autoritaire de la zone fr..

On n’observe donc pas un enchaînement . → fr. → gouv.fr. → impots.gouv.fr., mais plutôt . → fr. → impots.gouv.fr.. Cela indique que, du point de vue DNS public, gouv.fr n’est pas exposé ici comme une zone intermédiaire autonome, même si des sous-domaines en *.gouv.fr sont bien utilisés par l’administration.

Bref, sacrément curieux de voir que l'AFNIC gère également certains SLD, notamment gouv.fr..

Autre ressources importantes mentionnées : la liste maintenue par mozilla à l'adresse publicsuffix.org/list. On y retrouve par exemple les fameux domaines de second niveau abordés précédemment :

// fr : https://www.afnic.fr/ https://www.afnic.fr/wp-media/uploads/2022/12/afnic-naming-policy-2023-01-01.pdf
fr
asso.fr
com.fr
gouv.fr
nom.fr
prd.fr
tm.fr
// Other SLDs now selfmanaged out of AFNIC range. Former "domaines sectoriels", still registration suffixes
avoues.fr
cci.fr
greta.fr
huissier-justice.fr

Mais aussi des domaines 3LD (troisième niveau), avec le Japon en tête de liste en quelques exemples :

masaki.ehime.jp
matsuno.ehime.jp
matsuyama.ehime.jp
namikata.ehime.jp
niihama.ehime.jp
ozu.ehime.jp
saijo.ehime.jp
seiyo.ehime.jp
shikokuchuo.ehime.jp
tobe.ehime.jp
toon.ehime.jp
uchiko.ehime.jp
uwajima.ehime.jp
yawatahama.ehime.jp
echizen.fukui.jp
eiheiji.fukui.jp
fukui.fukui.jp
ikeda.fukui.jp
katsuyama.fukui.jp
mihama.fukui.jp
minamiechizen.fukui.jp

Autre référence intéressante, le domaine .eu existe en cyrillic .ею tout comme en Grec .ευ, bien géré par EURid.

Également une mention intéressante au RDAP (Registration Data Access Protocol) qui représente les différentes informations (anciennement WHOIS) de façon beaucoup plus structurée et normalisée en JSON, ce qui en gros aide surtout au parsing d'informations. Contrairement au WHOIS qui utilisait le port TCP/43, RDAP utilise directement HTTPS avec une API REST. Voici un exemple avec curl https://rdap.apnic.net/ip/1.1.1.1 :

{
  "rdapConformance": [
    "history_version_0",
    "nro_rdap_profile_0",
    "cidr0",
    "rdap_level_0"
  ],
  "notices": [
    {
      "title": "Source",
      "description": [
        "Objects returned came from source",
        "APNIC"
      ]
    },
    {
      "title": "Terms and Conditions",
      "description": [
        "This is the APNIC WHOIS Database query service. The objects are in RDAP format."
      ],
..
  "remarks": [
    {
      "description": [
        "APNIC and Cloudflare DNS Resolver project",
        "Routed globally by AS13335/Cloudflare",
        "Research prefix for APNIC Labs"
      ],
      "title": "description"
    },
    {
      "description": [
        "---------------",
        "All Cloudflare abuse reporting can be done via",
        "resolver-abuse@cloudflare.com",
        "---------------"
      ],
      "title": "remarks"
    }
  ],
..
  "handle": "1.1.1.0 - 1.1.1.255",
  "type": "ASSIGNED PORTABLE",
  "startAddress": "1.1.1.0",
  "endAddress": "1.1.1.255",
  "objectClassName": "ip network",
  "ipVersion": "v4",
  "cidr0_cidrs": [
    {
      "v4prefix": "1.1.1.0",
      "length": 24
    }
  ],
  "port43": "whois.apnic.net"
}

Deux éléments drôles et intéressants :

  • 6% du PIB de Tuvalu vient de son ccTLD .tv (certaines sources citent plutôt 10%).
  • 30% du PIB d'Anguilla vient de son ccTLD .ai, très largement utilisé actuellement.

Il a également été mentionné l'importance et la criticité de son choix de TLD, notamment les ccTLD, car ils appartiennent directement aux pays en question qui peuvent décider de suspendre le réseau Internet (cas de bit.ly avec la Libye) ou encore certaines restrictions qui peuvent s'appliquer au niveau géopolitique (impossible pour une société américaine d'envoyer de l'argent en Afghanistan par exemple pour obtenir un domaine .af).

Certains TLDs ont notamment disparu, comme celui de la yougoslavie (la Serbie ayant récupéré le .rs, prisé pour les développeurs Rust), ou encore le .su que la Russie a refuser de supprimer. Encore aujourd'hui, de nombreux sites utilisent encore ce TLD faisant pourtant directement référence à l'URSS.

Enfin, les gTLD initiés en 2012 ont permis à des organisations tierces autre que des pays d'obtenir leur propre domaine de second niveau, par exemple .sncf (plus utilisé, sauf dans l'authentification et le Wi-FI à bord des TGV suite à l'émergence de SNCF Connect) ou encore le .ovh, dont on apprend qu'il sera bientôt utilisé dans un autre cadre (plus disponible à la vente).

Une dernière découverte intéressante concerne les enchères en cas de contentieux si plusieurs acteurs veulent obtenir le même nom. C'est le cas du gTLD .web, obtenu plutôt frauduleusement et malhonnêtement par Verisign, et qui n'est toujours pas disponible à la vente.

À noter pour terminer que l'ICANN perçoit des frais sur l'ensemble des domaines enregistrés, ccTLD comme gTLD.

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

Présentation cette fois dans le périmètre technique de Décathlon visiblement à fond Kafka.

Le sujet portait principalement sur la gestion du dualwrite, avec comme solution l'outbox pattern. C'est quelque chose que je ne connaissais pas particulièrement et qui est très intéressant en tant qu'Ops. Voici une explication de la conférence :

Tout d'abord sur le contexte, l'équipe concernée chez Décathlon gère une API permettant de commander des cartes cadeaux. Lorsqu'une commande est passée, un certain nombre d'actions doivent être exécutées : réserver les cartes disponibles, enregistrer la commande, générer une facture, envoyer des mails.

Une réponse rapide et bête pour éviter tout problème pourrait être de laisser l'API exécuter toutes les actions de façon synchrone elle même :

  • Ça ralentit directement le processus, chaque service bloque l'avancement.
  • C'est fragile, si un service n'est pas disponible, le processus est bloqué.
  • C'est pas facile à faire évoluer dans le temps sans retoucher à l'API à chaque fois qu'on veut modifier un service.

Ce sont ces trois problématiques principales qu'on doit résoudre. Pour cela, ils utilisent Kafka. Pour rappel si vous ne connaissez pas Kafka, il s'agit d'un message broker composé de plusieurs éléments :

  1. Un producer écrit un message
  2. Un consumer lit un message
  3. Un topic représente un canal dédié. Les producers écrivent dans le topic, les consumers s'abonnent.
  4. Un modèle publish/suscribe : les producers ne connaissent pas les consumers, et plusieurs consumers peuvent lire le même message de leur côté.

Kafka permet donc de faire de l'asynchrone en déclouplant les programmes. Chaque service lit les messages envoyés dans le topic et pourront exécuter indépendamment et de leur côté les différentes actions requises.

Vient maintenant le problème du dual write. Quand l'API traite une commande, deux écritures dans deux systèmes différents sont requis :

  1. Inscrire la commande dans la base de données (PostgreSQL utilisé chez Décathlon)
  2. Envoyer un message dans Kafka pour prévenir les autres services.

Les deux systèmes étant séparés, cela peut poser un problème de cohérence des données, en deux exemples :

  • Écriture en base réussie, mais plante avant de publier dans Kafka. La commande existe mais toutes les autres actions ne sont pas exécutées.
  • Publication dans Kafka réussie, mais plante avant d'écrire dans la base. La commande n'existe pas mais tous les autres actions sont exécutées.

La solution à ce problème, c'est l'outbox pattern. L'objectif est de créer une table outbox pour exécuter une seule et même transaction dans la base de données : la transaction est réussie uniquement si la commande est inscrite dans la table commandes et si un message à envoyer est également écrit dans la fameuse table outbox.

Ensuite, un relais lit régulièrement le contenu de la table pour publier le contenu dans Kafka.

Le problème c'est que si on fait ça, cela ralentit la base car il faut exécuter une requête régulièrement. Une technique plus propre consiste à lire directement le journal de la base de données, le WAL dans le cas de PostgreSQL. Le CDC va lire ce journal et peut donc, sans interroger la base de donnée, et en temps réel, observer qu'un message doit être publié dans Kafka.

Kafka Connect permet de brancher Kafka à d'autres systèmes à l'aide de connecteurs. C'est le connecteur Debezium qui va directement lire le journal de la base pour publier directement un message dans Kafka.

Voici les 4 approches envisagées pour résoudre le problème de cohérence des données :

  1. Utiliser une table dédiée outbox.
  2. Inverser l'ordre en inscrivant la commande en base après le message Kafka pour réagir à son propre évènement.
  3. Écrire directement dans le journal (quelque chose comme pg_logical_emit_message()) ne nécessitant donc pas de table dédiée.
  4. Utiliser une table existante.

C'est la quatrième solution qui a été retenue : pourquoi utiliser une table outbox quand Debezium voit qu'une table change dans le journal, il publie un message dans Kafka. Voici l'ordre de fonctionnement final :

  1. L'API client appelle l'API Stock' pour réserver une carte.
  2. L'API Stock enregistre la commande dans la base.
  3. Debezium lit le journal et détecte les changements.
  4. Debezium publie dans les différents topics Order change, Order Line change et Giftcard change.
  5. Tous les services (consumers dans Kafka) s'abonnent à ses topics et réalisent chacuns leurs actions Invoicing consumer, Order Mail consumer, Activation consumer, Giftcard Mail consumer, Wallet consumer.

Il y a néanmoins deux petites problématiques liées à ce fonctionnement sans de table outbox = dédiée :

  1. Les doublons : chaque évènement de modification de la base n'étant pas identifié clairement par un identifiant d'évènement unique, les consumers doivent pouvoir traiter les doublons. Ils doivent être idempotent pour assurer, même avec plusieurs exécutions, d'obtenir le même résultat qu'une seule exécution (par exemple, envoyer qu'un seul mail).
  2. La stabilité du schéma : vu que les message utilisent la structure des tables métiers et que le JSON n'impose pas de contrôle (le format binaire Avro n'est pas utilisé par Décathlon), tout changement de structure dans des tables Order ou Giftcard modifie la forme des messages et peut casser les consumers.

Pour résumer, la problématique était la cohérence des données, résolue avec l'outbox pattern en utilisant Debezium pour lire dans le journal postgreSQL et publier dans Kafka. Il faut néanmoins gérer les doublons et faire attention à la stabilité du schéma.

J'ai été plutôt surpris de leur choix, car pg_logical_emit_message() est techniquement ce qui pourrait se faire de plus propre. Mais comme il a été abordé dans les questions, cela demande un peu plus de tooling et présente également ses propres désavantages.

Pourquoi personne n’aime relire ta Pull Request

Cette fois, c'est de l'expérience qui vient de chez Docker. Avant de parler de la conférence directement, il a été bon d'entendre la notion de documentation implicite grâce à l'environnement de git. Toutes les discussions associées à des commits permettent de clairement comprendre comment fonctionne le code, bien souvent davantage que dans la documentation officielle. C'est le cheminement de pensée de développeurs qui amène à produire ce code, qui est donc justifié par une analyse commune de développeurs.

La conférence débute sur la critique du diff : pas de contexte. Cela ne permet pas, à lui seul, de comprendre la modification apportée.

3 critères sont recommandés pour une Pull Request idéale : limpide (atomique), ennuyeuse/linéaire (pas de complexité/pas de plot twist) et courte.

Pour limpide et linéaire, le squash et le rebase sont de bonnes pratiques à adoper pour avoir un chemin clair et lisible. Un merge commit n'est pas lisible pour le reviewer : il faut systématiquement rebase au lieu d'ajouter un commit supplémentaire.

Pour courte, on peut se baser sur les travaux des psychologues Cowan et Miller pour envisager une limite de 5 commits changes/files. C'est le nombre idéal permettant au reviewer de comprendre la Pull Request de façon limpide, linéaire et courte.

Attention, un commit peut bien entendu intégrer plusieurs éléments. Il doit être atomique dans sa forme, effectuer des modifications clairement explicitées dans son nom, mais peut bien sûr modifier un grand volume de fichiers si tel est son objectif.

En bref : les demandes de modifications doivent raconter une histoire à travers plusieurs commits. Pour créer cette histoire, une démonstration a été apportée avec sbx (outil développé par Docker) permettant d'utiliser l'IA pour automatiquement créer une histoire (dans le sens rassembler une suite de commits limpides, linéaire et courts). L'histoire racontée par l'IA peut parfaitement raconter une autre histoire que celle vécue par le développeur au moment d'écriture de son code : l'objectif est juste de faciliter la compréhension et favoriser l'acceptation par le reviewer.

Si vous voulez essayer par vous même, le code est disponible dans le dépôt maxcleme/commit_organizer_agent.

Les slides sont également disponibles ici.

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

Retour d'expérience qui nous vient droit de chez Purse. Ils ont décidé de développer eux-même ce qu'ils appellent un Vault, c'est à dire le composant qui traite les différentes données bancaires (PAN, CVV, date d'expiration).

Petit rappel intéressant comme quoi le signe CB signifie carte bancaire, et non pas carte bleue. Le petit logo qui s'affiche à côté du PAN correspond bien souvent au réseau de carte utilisé : CB est expliqué comme souvent moins chargé de frais, à l'inverse des fournisseurs américains (VISA).

Pour créer ce coffre, il est nécessaire d'être certifié PCI-DSS, présenté comme très, très contraignant même jusqu'au équipes RH.

Concernant le design technique, ils ont souhaité se baser sur l'offre de Cloud GCP, mais souhaitant éviter à minima le vendor lock-in. Comme mentionné dans le premier commentaire après la conférence, l'architecture n'est pas vraiment indifférente au fournisseur Cloud sous-jacent et dépend fortement des services Google, bien que pouvant être modifiés.

L'utilisation de la plateforme Cloud n'est pas annodin : cela permet de décharger une grande partie de la responsabilité et limiter la surface d'autorisations, ce qui facilite grandement la certification. Honnêtement, la plateforme présentée est certe conforme sur le plan réglementaire, mais il ne s'agit en aucun cas d'une solution souveraine (compatible SecNumCloud par exemple) et vraiment cloud agnostic.

Le service KMS est utilisé pour la gestion des clés. Les données bancaires sont ensuites chiffrées puis tokenisées pour permettre leur manipulation dans le reste du processus de paiement. Ils utilisent notamment MongoDB CSFLE pour gérer le chiffrement KEK.

La version 4.0 du PCI DSS intègre des règles spécifiques concernant le stockage du CVV, pouvant être conservé mais uniquement pour le traitement de l'opération. C'est pour cela qu'il est nécessaire d'indiquer le CVV systématiquement même lorsqu'on enregistre la carte sur un site.

L'intégration dans les pages s'effectue avec l'iframe et les CSP, l'approche standard et utilisée dans le domaine.

Utilisation de Cloud Run à la place de Kubernetes, fortement dépendant à Google mais facilite l'audit et la rapidité de déploiement. Comme indiqué en réponses à la fin de la conférence, la phase de conception n'a duré que quelques semaines, pour une mise en production progressive sous 6 mois / 1 an. L'auditeur a été présent lors de la validation de l'architecture, ce qui a confirmé le stockage des CVV temporairement en mémoire avec Valkey (fork de Redis).

Une mention intéressante : il pourrait être pratique de stocker toutes les données personnelles, même moins critiques comme le nom prénom, sous forme systématiquement tokenisées par KMS. Cela permettrait qu'en cas de fuite de la base de données, les différentes données personnelles ne se retrouvent pas massivement dans la nature.

Renovate à la rescousse : Automatisez la dette technique de votre infra Kubernetes

Présentation de la solution Renovate qui permet d'obtenir les dernières versions de notre IaC.

Possibiité de faire du regex pour chercher les versions dans les fichiers IaC, tout comme dans les versions disponibles auprès d'API.

Déployer souvent, stresser moins : feature flags en prod critique

Super présentation concernant la gestion des nouvelles fonctionnalités par Takima.

Beaucoup basé sur de l'agile et du Java et le trunk based development.

Utilisation du RefreshScope dans le framework Java Spring dans le package common. Notion de bit de proxy.

Pour activer une feature, possibilité de faire un actuator/refresh pour avoir un hot reload notamment sous Kubernetes.

Applicable dans les Experimental/Ops/Feature flags (notion if/else).

Possibilité d'utiliser le GitOps avec plusieurs arbres de décision ou faire une page admin permettant d'activer ces éléments.

Deuxième jour (12 juin 2026)

Garder les clés de ses données : Le chiffrement au service de la souveraineté

Présentation de la part d'OVH sur trois produits autour du KMS :

  • Dedicated HSM : le contrôle est total et l'isolation s'effectue au niveau du hardware (pas de mutualisation entre les clients). Le problème dans cette approche, c'est la complexité de gestion, notamment avec des standards qui n'existent pas.
  • Shared HSM : créé pour faciliter l'accès et transparent pour l'utilisateur (il exploite directement l'IAM qui fait le relais vers le HSM). Dans ce modèle, toute la gestion est accessible au "clic" (en gros, dans l'interface graphique, mais aussi indirectement dans l'API) et pas de vendor-locking (protocole KMIP). Les performances sont néanmoins limitées (notamment le nombre d'appels à l'API) et isolé par le software du HSM.
  • Managed HSM : permet de partionner le HSM pour garantir plus de performances. Fonctionne à l'aide d'un driver pkesii, une HSM Gateway et une base de données.

OVH indique que des certifications ISO 27001, PCI-DSS et FIPS 140-3 sont en cours ou déjà disponibles pour ces produits. Pour plus de transparence, il a été confirmé la volonté de mettre en Open Source la plateforme technique du KMS pour permettre plus de transparence. Et plutôt drôle ; une question portait classiquement sur le risque que cela induirait d'exposer son architecture de cette façon. Sur ce plan, je suis parfaitement d'accord avec la réponse apportée par OVH ; la sécurité par la transparence est bien meilleure que la sécurité par l'obscurité.

Concernant le hardware, OVH utilise des HSM ProvenRun (appelés par conséquence et quelle surprise, ProvenHSM). Ces derniers viennent compléter les équipements HSM Thalès également présents chez OVH, mais sont indiqués comme beaucoup plus flexibles et facile à administrer dans l'utilisation d'une plateforme Cloud.

À noter qu'une question a été posée concernant la possibilité pour OVH de construire ses propres HSM ; on nous indique un nombre de 4 à 5 équipements par datacenter, pour une cinquentaine d'équipements au total chez OVH, ce qui ne justifie donc pas de construire ses propres équipements pour des raisons de coût évidents.

J'ai déjà utilisé le service KMS d'OVH compatible KMIP avec Openbao, cela fonctionnait très bien. Je ne peux que conseiller d'utiliser leur outil okms-cli juste idéal pour communiquer avec le protocole KMIP.

Et si votre database était la queue qu'il vous fallait ?

Présentation également très intéressante mentionnant les trois brokers actuellement utilisés dans les architectures API : Kafka, Pub/Sub et RabbitMQ.

Plusieurs éléments clés :

  • Dédupliquer possède un coût
  • Exponentiel backup
  • Wired Tiger
  • Courbe de contention
  • Dépasser le knee consiste à prendre plusieurs jobs d'un coup (batching) ou partitionner la contention (bucketing). Le bucketing est considéré comme plus simple.
  • S'il n'y a rien dans les casiers, on va faire des appels pour rien
  • Ordering strict dans le broker

J'ai beaucoup aimé l'approche de trouver la meilleure solution qui n'est pas la plus performante, mais la plus adaptée, c'est juste une question d'arbitrage. La présentation insistait régulièrement sur une lisibilité qui se perd avec une montée en performances.

EcoScore A ou E : où se situe vraiment votre API ?

Quelques rappels plutôt discutables concernant les émissions de GES du numérique sur la base des rapports effectués par l'ARCEP. La moitié de la consommation provient des terminaux, ce qui encourage à baisser la consommation de ces derniers en priorité.

Je ne connaissais pas la loi de Wirth ; les programmes ralentissent plus vite que le matériel accélère.

Pour la conformité API, j'apprends l'existence de l'API GreenScore, utilisé par Décathlon dans une conférence à laquelle j'ai pu participer par la suite. Les référentiels connus sont EROOM/EOF v1.1.

Au sens de l'état, la DINUM publie le RGESN, mais il existe aussi GR491, RVWEB v5 (publié par le collectif Green IT).

Connaissez vous le standard ISO/IEC 21031:2024 ? Il s'agit de la spécification SCI (Software Carbon Intensity).

Des ressources intéressantes : Cloud carbon footprint, e-footprint ou encore Boavizta API.

Un petit fork de la CNCF landscape pour créer la Sustainability Landscape à l'adresse suivante.

Pour calculer le Greenscore et éviter de devoir travailler sur des documents feuille de calcul, zats-greenscore est un projet qui permet de graphiquement auditer une application pour calculer le Greenscore.

Concernant Tauri je ne connaissais pas également, qui implémente en Rust un Electron plus souple, environ 10x plus léger.

DevGreenOps : Passer du sprint à l'endurance énergétique avec Decathlon x Greenspector

Application concrète de la conférence précédente, avec un focus sur le front-end dans un premier temps (comme cela a été abordé dans les questions, Décathlon l'ignore par le backend mais préfère le traiter séparémment).

Sans trop de surprise, l'économie d'énergie passe par une diminution du temps d'écran et éviter l'obsolescence programmée.

L'exercice concerne l'application d'achat de Décathlon, déployée dans une quarantaine de pays.

Historiquement, il est indiqué que des KPIs existaient mais pour un usage commercial ou technique. L'optimisation logicielle (dans le sens de l'EcoScore) peut également être utile pour augmenter les bénéfices indirectement, en permettant par exemple à une application de s'exécuter plus rapidement dans des environnements avec une flotte de terminaux moins performants, favorisant l'utilisation de l'application et donc les achats in-fine.

Pour tester le frontend, il faut tester les différentes pages, mais aussi dans le cas d'intégration du navigateur (par exemple le WebView).

Le DSL Greenspector permet l'exploitation d'un script simulant l'utilisation de l'application. Ces tests peuvent être effectués dans le Cloud de Greenspector. La diversité des équipements mobiles proposés par le Cloud Greenspector a même permit de résoudre des problèmes non identifés dans les différents tests exécutés en amont par l'équipe de développement.

Tout l'intérêt de ceci est de pouvoir intégrer cet audit EcoScore dans une CI, lors de la publication d'une RC par exemple.

Petite mention à la difficulté de réalisation des tests ; le catalogue peut changer, et si une doudoune violette est utilisée pour le test mais n'existe plus sur le catalogue, le test ne sera plus disponible. Il n'est pas possible d'éviter autrement le problème qu'avec une vigilence particulière car ces relevés s'exécutent directement sur l'environnement de production pour une fiabilité maximale et une reproduction de conditions réelles.

Notion de CALMS.

Qu'est-ce que OID4VP : le protocole derrière les portefeuilles numériques européens

Explication technique du OID4VP. Je trouve certains problèmes, que le listerais ici.

Notions autour de eIDAS2, Clientid, Jar jwt, VP Token, SD-JWT VC.

Aborde le Decoy crypto avec l'utilisation de faux champs, à voir comparaison avec sel/poivre (référence OWASP).

Créer son premier provider Terraform avec le plugin-framework

Conférence également très intéressante sur la création d'un provider Terraform à l'aide du Terraform Plugin Framework.

Exploite le repo scaffholding.

Notion de "./...", avec par exemple go generate.

Hashicorp indique que Terraform ne supporte pas OpenAPI provider spec generator, peut être à l'avenir.

Testez vos tests avant qu’ils ne vous trahissent : le mutation testing !

Le point de départ de cette conférence, c'est le test coverage, l'indicateur historique des tests qui repose sur la proportion du code exécuté lors des tests. C'est donc purement un indicateur de quantité et non pas de qualité.

Il existe deux granularités qui sont présentées lors de cette conférence (plutôt classiques) :

  1. Le line coverage correspond au pourcentage de lignes de code qui a été exécuté lors des tests.
  2. Le branch coverage correspond au pourcentage de chemins de décision empruntés.

Par exemple dans une condition, un test qui n'exécute qu'un if affichera 100% de line coverage mais 50% de branch coverage.

Le problème dans cette approche c'est clairement qu'on part d'une mauvaise base initiale ; une ligne exécutée n'est pas forcément bien testée.

C'est là que vient le mutation testing ; faire en sorte que les tests soient plus qualitatifs, en injectant volontairement des petits bugs. On veut vérifier que les tests échouent même quand le code devient faux. Cela peut aider à identifier les tests qui ne sont pas de bonne qualité.

Pour le vocabulaire, une version infectée par un bug est appelée un mutant. Pour chaque mutant généré, on effectue la suite de tests :

  • Si un test passe au rouge, le mutant est tué. Les tests ont détectés le bug.
  • Si aucun test ne passe au rouge, le mutant survit. Les tests n'ont pas détectés le bug et doivent donc être réajustés.

Les erreurs de code injectées ne sont pas aléatoires, on suit des règles qu'on appelle mutateurs. Quelques exemples :

  • Opérateurs arithmétiques : + devient /.
  • Opérateurs conditionnels : > devient < (off-by-one).
  • Négations conditionnels : == devient !=.
  • Opérateurs logiques : && devient ||.
  • Littéreaux : true devient false.
  • Et même des suppressions d'instructions en retirant une ligne.

Pour mesurer les résultats, on utilise deux scores distincts :

  1. Le Mutation Score qui prend tous les mutants : MS = mutants tués / tous les mutants. Il mesure en gros le problème de ne pas tester le code et en plus, de mal le tester.
  2. Le Test Strength qui prend les mutants situé dans du code couvert par au moins un test : TS = mutants tués / (mutants couverts par les tests). Celui-ci isole la qualité de tests sur ceux existants.

Quelques exemples de nouveau pour illustrer ces deux scores :

  • MS 40% & TS 80% (4 mutants tués, 1 survivant et 5 non couverts) : les tests exécutés sont solides, mais il faut ajouter davantage de tests (problème de couverture).
  • MS 30% & TS 33% : la couverture du code est correcte (MS ≈ TS) mais ne vérifient pas suffisament (problème d'assertions).
  • MS 80 %, TS 89 % : c'est parfait ! la couverture de code est très bonne dans les deux scores, ce qui se traduit en bonne couverture et bonnes assertions.

Le problème dans tout ça, c'est l'adoption : pas grand monde l'utilise aujourd'hui. La raison ? les faux positifs ! On part d'une mauvais postulat : un mutant survivant ne provient pas forcément d'une suite de tests mauvais, mais parce qu'il est impossible à tuer.

Dans ce cas, on parle de mutants équivalents qui ne peuvent pas être couverts par un test. Il s'agit donc d'un faux positif. Le problème, c'est qu'il est nécessaire d'analyser tous les mutants pour identifier ceux qui sont réels ou ceux qui sont équivalents. C'est un travail répétitif qui explique pourquoi ce dernier n'est pas adopté de façon massive.

La conférence mentionne également la possibilité d'industrialiser le mutation testing en intégrant directement dans une CI/CD. On peut ainsi définir des seuils de score pour définir un objectif à atteindre aux équipes, par exemple.

Et dans tout ça, pourquoi ne pas utiliser l'IA pour traiter les faux positifs (mutants équivalents) ? Voir même de proposer automatiquement des PR pour résoudre ces problèmes ? La conférence insiste sur la capacité à utiliser ce genre d'outils pour rendre le mutation testing vraiment intéressant pour améliorer les tests unitaires sans impacter fortement les équipes de travail.