Title: Lettre n°14 — 09 mars 2026
Date: 2026-03-09 09:00
Category: Newsletter
JsonLD:  <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°14", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Mar 09 2026 09:00:00 GMT+0200 (Coordinated Universal Time)", "author": { "@type": "Person", "name": "Pascal Le Merrer", "url": "https://www.linkedin.com/in/pascal-le-merrer/" } } </script>
<img class="logo" alt="Logo Craft Letter" src="{static}/images/craftletter.svg">

## Édito

Merci à toutes celles et ceux d’entre vous qui ont répondu au sondage de la lettre n°12. Une large majorité (83%) apprécie les résumés détaillés, c’est pourquoi je vais continuer à en faire. Pas systématiquement, ce sera en fonction de mon envie et de mon temps libre, et aussi parce que plusieurs personnes ont mentionné qu’elles appréciaient le mix des deux formats —et quelques-unes qu’elles préféraient les formats courts. Pour être honnête, je vois aussi mon propre intérêt dans l’écriture de ces résumés&nbsp;: ils me demandent un effort intellectuel plus important, ce qui fait que je retiendrai plus de choses des articles concernés. Comme je le dis souvent, partager est un des meilleurs moyens d’apprendre. Et cette semaine encore, j’ai beaucoup de choses à partager avec vous 😀.

Bonne lecture&nbsp;!


## Pourquoi Gleam est-il un langage enthousiasmant&nbsp;?

Gavin Bannerman explique [pourquoi il est enthousiasmé par Gleam](https://builders.perk.com/gleam-is-boring-so-i-went-to-a-conference-about-it-8f08a52c3de3)🇬🇧.  Cela tourne principalement autour de la simplicité du langage, sa stabilité, et la bienveillance de la communauté. Il est persuadé que le système de types de Gleam améliorerait son expérience sur les gros projets, lui qui utilise TypeScript professionnellement. Par contre, il mentionne le manque de guides dans la documentation comme l’un des points faibles. L’équipe qui développe le langage veut améliorer ce point cette année, car elle cherche à développer l’usage de Gleam en entreprise. Enfin, il suggère de passer 10 minutes sur le [tour du langage](https://tour.gleam.run/)🇬🇧.

Je partage pleinement l’enthousiasme de Gavin. Gleam présente presque toutes les qualités que j’attends d’un langage de programmation, notamment la simplicité et un typage rigoureux —il ne lui manquerait que de meilleures performances pour être parfait. J’attache de l’importance à ce point, car c’est une des clés pour diminuer l’impact environnemental des applications, tout en procurant une bonne expérience utilisateur. La simplicité est une de mes valeurs favorites. Je considère que la complexité, quand elle n’est pas intrinsèque au problème à résoudre, est le résultat d’un manque de maîtrise. Avoir du code simple facilite la maintenance et améliore la productivité. Le fait de n’avoir qu’une seule façon de faire les choses, comme en Gleam, est l’une des clés de cette simplicité.
## Simple made Easy

Dans son article sur Gleam, Gavin Bannerman mentionne [ce talk de Rich Hickey](https://www.youtube.com/watch?v=SxdOUGdseq4)🇬🇧. Rich est le créateur de Clojure, un langage inspiré de Lisp qui produit des exécutables pour la JVM, le CLR (la machine virtuelle .NET), les navigateurs et NodeJS.

Le principal point à retenir de cette présentation, c’est la distinction entre simplicité et facilité dans le cadre du développement logiciel.

Quelque chose est facile parce que c’est proche, physiquement, ou familier —autrement dit, proche de ce que l’on connait. Ou encore proche de nos compétences. La facilité mène souvent à de la complexité cachée.

La simplicité vient d’une absence d’entrelacement avec d’autres choses (concepts, responsabilités, fonctionnalités…). C’est un prérequis pour la fiabilité et la maintenabilité à long terme.

La facilité est une notion relative, tandis que la simplicité est absolue.

Rich ne le mentionne pas, mais la même distinction existe entre [complexe et compliqué](https://vitrinelinguistique.oqlf.gouv.qc.ca/22310/le-vocabulaire/nuances-semantiques/difference-entre-complique-et-complexe).

## Allocateurs de C à Zig

Anton Zhiyanov compare [l’utilisation des allocateurs de mémoire dans différents langages](https://antonz.org/allocators/)🇬🇧&nbsp;: Rust, Zig, Odin, C3 et Hare, avant de montrer comment il est possible de définir un allocateur personnalisé en C.

Un allocateur est un outil qui permet à un langage de programmation de réserver puis libérer une zone mémoire, en général sur le tas, afin qu’un programme y stocke ses structures de données.

La réservation de mémoire à l’aide d’un allocateur requiert en général deux paramètres&nbsp;: la taille de la zone mémoire à réserver, et son alignement. L’alignement contraint l’adresse à laquelle la zone doit débuter, en fonction du type des données à stocker&nbsp;:

* pour des octets, l’alignement vaut 1, il est possible de démarrer à n’importe quelle adresse mémoire&nbsp;;
* pour des valeurs stockées sur 32 bits, l’alignement est de 4, cela veut dire que l’adresse de début doit être un multiple de 4&nbsp;;
* pour des valeurs stockées sur 64 bits, l’alignement est de 8, cela veut dire que l’adresse de début doit être un multiple de 8.
	
Selon les langages, l’allocateur à utiliser peut être défini globalement, ou passé en paramètre lors des appels de fonction&nbsp;; certains autorisent les deux façons de faire, d’autre une seule.
Dans tous, la bibliothèque standard propose un ou plusieurs allocateurs prédéfinis, chacun étant prévu pour un cas d’usage donné. Par exemple, un allocateur de type "arena" sert à allouer plusieurs zones mémoire qui seront libérées simultanément.

Si le sujet de l’allocation de mémoire en C vous intéresse, Geo Carncross détaille des [techniques pour obtenir des gains de performances](https://geocar.sdf1.org/alloc.html)🇬🇧 importants.
## Architecture orientée événements

Dans [Event-Driven Architecture (EDA)&nbsp;: avantages et cas d’usage](https://architecti.blog/articles/2025/013-event-driven-architecture---avantages-et-cas-dusage/)🇫🇷, Lucas Bories explique les 
bases des architectures orientées événements, leurs avantages, et des patterns d’architecture qui peuvent être utilisés. Il décrit aussi les difficultés engendrées par ces architectures.

Dans [Event sourcing par l’exemple](https://www.youtube.com/watch?v=l0c4oR4JPr4)🇫🇷, Loïc Knuchel montre que l’implémentation n’est pas très complexe. J’ai bien aimé la seconde partie, dans laquelle il formule son retour d’expérience, et donne quelques conseils, après avoir expliqué comment ça peut s’implémenter. Par contre, il a peu d’expérience sur ce sujet, et son cas d’usage est simple, comme il le dit lui-même.

Dans [Les bombes à retardement de l’Event Sourcing / CQRS](https://www.youtube.com/watch?v=tj80_nCDr18) 🇫🇷
Thomas Brouillet, qui a plus de recul, explique les problèmes que l’on peut rencontrer avec ce type d’architecture. C’est un bon complément de la présentation précédente.

## Les redirections en Bash

Si, comme moi, vous trouvez que `2>&1` n’est pas très explicite, [les explications de Korben](https://korben.info/redirections-bash-qui-sauvent-ta-vie.html)🇫🇷 vous seront utiles.

## Le nombre de lignes de code est de retour, et c’est pire qu’avant

Allan Macgregor constate que [le nombre de lignes de codes est redevenu une métrique populaire](https://www.thepragmaticcto.com/p/lines-of-code-are-back-and-its-worse)🇬🇧, alors qu’on sait depuis longtemps qu’elle n’est pas pertinente.  Il liste ensuite des métriques qui auraient plus d’intérêt. 

## Une base PostgreSQL qui grossit et ralentit&nbsp;? Ce n’est pas un bug, c’est une fonctionnalité

Votre base PostgreSQL prend de plus en plus d’espace disque, et ralentit, bien que le nombre de lignes reste à peu près constant&nbsp;?  Roger Welin explique [pourquoi c’est normal](https://rogerwelin.github.io/2026/02/11/postgresql-bloat-is-a-feature-not-a-bug/)🇬🇧.

Les données et métadonnées sont stockées sur disque par pages de 8 Ko. Pour retrouver une ligne, PostgreSQL charge l’intégralité de la page qui la contient. 

PostgreSQL fonctionne selon une logique "append only". Quand une requête modifie une ligne, une nouvelle version des données est écrite sur le disque, souvent dans une page différente. L’ancienne version est marquée comme obsolète, mais pas supprimée. De même si une ligne est supprimée par une instruction DELETE, elle n’est pas effacée sur le disque. C’est également vrai pour les index, qui contiennent des pointeurs vers les données "effacées", tant qu’on n’exécute pas un REINDEX.

C’est pourquoi l’espace disque requis va augmenter au fil du temps, même si le nombre de lignes dans la base n’augmente pas. 

VACUUM est le ramasse-miette de PostgreSQL. Il est déclenché par un process nommé autovacuum, et va marquer comme réutilisable l’espace disque correspondant aux lignes obsolètes. Cependant, l’espace occupé ne va pas diminuer. 

Parfois, VACUUM ne libère pas l’espace disque assez rapidement&nbsp;:

* si les mises à jour sont trop fréquentes&nbsp;;
* si des transactions sont trop longues —en particulier s’il manque un COMMIT dans le code.
  
Cela peut se résoudre en faisant des transactions courtes d’une part, et,  d’autre part,  en changeant les valeurs des paramètres `autovacuum_vacuum_cost_delay` et `autovacuum_vacuum_scale_facto` pour les tables mises à jour fréquemment. L’article se conclut sur des recommandations de configuration de ces paramètres.

## PgDog&nbsp;: scaling horizontal de Postgresql

[PgDog](https://github.com/pgdogdev/pgdog)🇬🇧 est un proxy open source qui gère de façon transparente un pool de connexions et la répartition des données entre plusieurs instances de Postgresql.

## Supprimer les branches Git fusionnées

Il existe de nombreuses commandes Git pour faire le ménage dans un dépôt. [Celle-ci](https://spencer.wtf/2026/02/20/cleaning-up-merged-git-branches-a-one-liner-from-the-cias-leaked-dev-docs.html)🇬🇧. a la particularité amusante de provenir d’une fuite d’outils de hacking et de documents internes de la CIA.

Il est utile de compléter cette commande par une seconde qui [supprime les références locales aux branches supprimées sur le dépôt distant](https://dev.to/ruqaiya_beguwala/day-1130-git-fetch-prune-clean-up-stale-remote-tracking-branches-1o8f).

## Hornbeam

Benoit Chesneau, le créateur de [Gunicorn](https://fr.wikipedia.org/wiki/Gunicorn)🇫🇷, a créé [Hornbeam](https://hornbeam.dev/)🇬🇧, qui permet de faire tourner des applications Python sur Beam, la machine virtuelle d’Erlang. Son objectif est de combiner le meilleur des deux mondes.
