Title: Lettre n°6 - 12 janvier 2026
Date: 2026-01-12 09:00
Category: Newsletter
JsonLD: { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°6 - 12 Janvier 2026", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Jan 12 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/" } }

<img class="logo" alt="Logo Craft Letter" src="{static}/images/craftletter.svg">


## Utiliser des graphiques pour tirer un meilleur parti des métriques DORA

Egor Savochkin explique comment identifier, à l'aide de graphiques, [l'impact des changements de pratiques et d'organisation](https://www.infoq.com/articles/DORA-metrics-PBCs/) 🇬🇧 sur la performance d'une équipe de développement.

La performance est mesurée par [les métriques DORA](https://blog.stephane-robert.info/docs/devops/dora/) 🇫🇷, telles que décrites dans [Accelerate](https://en.wikipedia.org/wiki/DevOps_Research_and_Assessment) 🇬🇧 :

* la durée entre la création d'un _commit_ et sa mise en production
* la fréquence de mise en production ;
* le pourcentage des déploiements qui causent un incident en production ;
* le temps requis pour restaurer le service après un incident.

Suivre l'évolution de ces métriques sur des graphiques "process comportement" (PBC) permet de distinguer les évènements exceptionnels des changements qui ont un impact durable. Cela confirme —ou infirme— l'efficacité des expérimentations menées par les équipes, au lieu de se baser sur des ressentis.

Il rappelle que les métriques sont un instrument de mesure, pas un objectif. L'absence de récompense liées aux métriques assure qu'il n'y aura pas de tricherie.

## Langage C3

Le [langage C3](https://c3-lang.org/) se base sur le C, et peut être mêlé avec du C, comme le Typescript avec du JavaScript. Il apporte de nombreuses fonctionnalités par rapport à son aîné : génériques, programmation par contrats, type Option pour la gestion de valeurs nulles, etc.

## Des livres d'intro à Git, Bash, SQL, Docker, Laravel...


Bobby Iliev a écrit [une série de livres](https://github.com/bobbyiliev) 🇬🇧, dont certains sont disponibles en open source, au format électronique : 

- 📖   Introduction to Bash Scripting 
- 📗   Introduction to Git and GitHub
- 📕   Introduction to SQL
- 🐳   Introduction to Docker
- 💡   Laravel tips and tricks 

Pour les deux premiers, une partie des chapitres est aussi disponible sous forme de vidéo.

Il a aussi publié des livres qui ne sont pas disponibles gratuitement : 

- 🌍   Introduction to Terraform
- 🐧   Introduction to Linux 


## Les problèmes posés par la relecture de code

L'usage des Pull Requests (PR) de Github ou leur équivalent Gitlab, les Merge Requests, est la norme pour la plupart des équipes de développement. Ces pratiques visent à détecter des bugs et à ce que les standards de l'équipe soient respectés. Elles ont pour conséquence une diffusion de la connaissance du code.

Toutefois elles ne sont pas sans défaut. Un problème fréquent, posé par la dépendance envers les collègues sollicités pour la relecture, est qu'ils/elles mettent parfois plusieurs jours à faire leurs retours. Un autre problème, qui peut être la cause du précédent, c'est la taille trop importante de certaines PR —symptôme révélateur d'une durée de vie trop longue de la branche. Personne n'a envie de relire des PR de plusieurs milliers de lignes.  A l'inverse, une PR au contenu trivial ne justifie pas que l'on sollicite des collègues pour une relecture —qui, si elle est rendue obligatoire, n'a pas vraiment de sens dans ce cas. Tous ces problèmes nuisent à la productivité des équipes. 

Une première solution est décrite par MartinFowler dans [Ship / Show / Ask](https://martinfowler.com/articles/ship-show-ask.html) 🇬🇧. Il propose d'adopter des processus différents en fonction de la nature de la PR.

Une solution plus radicale consiste à passer au [Trunk Based Development](https://thinkinglabs.io/articles/2025/07/21/on-the-benefits-of-trunk-based-development.html) 🇬🇧, dans lequel les branches ont une durée de vie maximale d'une journée, et sont relues, si besoin, après leur fusion dans la branche principale. C'est une des pratiques employées par les équipes les plus performantes, d'après Accelerate.


## Les chiffres que devraient connaître les développeurs Python

Michael Kennedy a effectué une série de benchmarks, dont il livre [les résultats](https://mkennedy.codes/posts/python-numbers-every-programmer-should-know/) 🇬🇧 de façon synthétique. On y découvre que la consommation mémoire d'un processus Python vide est de 16 Mo, tandis qu'importer FastAPI est 500 fois plus long qu'écrire sur disque un fichier d'un Mo. 

## JuJutsu pour les utilisateurs de Git

JJ, dont je vous ai parlé dans [la lettre n° 4](https://www.craftletter.fr/lettre-ndeg4-29-decembre-2025.html), est une alternative à Git, avec qui il est compatible.
[jj cheatsheet for Git users](https://gist.github.com/elithrar/4a09ef750af5624b729a6f1d87a0431c) 🇬🇧 est un aide mémoire qui m'a été utile ces derniers jours.

## JuJutsu, pre-commit et Prek

[pre-commit](https://pre-commit.com/) est un outil qui permet d'exécuter une série de vérifications sur le code avant de le commiter. Les contrôles de base, que vous pouvez choisir d'activer ou pas, sont extensibles au moyen de plugins. Certains peuvent corriger automatiquement les problèmes qu'ils détectent. Il va par exemple vérifier le formatage du code, l'absence d'instructions de debug, le respect de bonnes pratiques du langage, etc. Plus d'une douzaine de langages de programmation sont supportés, ainsi que les Dockerfile.

Il s'enregistre comme un hook Git, ce qui fait qu'il se déclenche automatiquement quand vous tentez de commiter du code. Si certaines de vérifications ne sont pas satisfaites, le commit échoue. 

JJ n'est pas compatible, pour l'instant, avec pre-commit. Mais il existe une solution : [jj-pre-push](https://pypi.org/project/jj-pre-push/).
pre-commit est écrit en Python. Malgré cela, son exécution est plutôt rapide, car il ne traite, par défaut, que les fichiers que vous avez modifiés. C'est toutefois une bonne idée de l'exécuter dans les pipelines de CI avec pre-commit run --all, de façon à vérifier l'intégralité du code. Non seulement cela garantit que tout votre code respecte les standards que vous avez définis, mais aussi cela permet de pallier au fait que certains développeurs peuvent ne pas l'exécuter sur leur poste.

Si pre-commit n'est pas assez rapide pour vous, il existe une réécriture en Rust, nommée [Prek](https://prek.j178.dev/).

##  L'open source en danger ?

Tailwind Labs, malgré le succès croissant de son framework CSS, a vu ses revenus s'effondrer depuis 2 ans. [Les trois quarts des membres de l'équipe technique viennent d'être été licenciés](https://loud-technology.com/blog/tailwind-labs-ia-menace-modele-economique-open-source/) 🇫🇷. En cause : les LLM, qui ont détruit le modèle économique de l'entreprise. Leur usage massif remet en cause la pérennité de nombreux projets open source.

## Les bases de données en 2025

Andy Pavlo publie sa [rétrospective annuelle sur les bases de données](https://www.cs.cmu.edu/~pavlo/blog/2026/01/2025-databases-retrospective.html) 🇬🇧. Il évoque la domination de Postgresql, le procès intenté par MongoDB .inc à l'encontre de Ferret .inc, les formats des fichiers de données...

## Rétro-ingénierie de jeux vidéo

Fabien Sanglard a écrit plusieurs livres qui sont devenus des références en matière de rétro-ingénierie de jeux vidéo. [Le premier est consacré à Wolfenstein 3D](https://fabiensanglard.net/gebbwolf3d/) 🇬🇧, l'ancêtre de DOOM. [Le second](https://fabiensanglard.net/gebbdoom/) 🇬🇧 décortique le code et les algorithmes de DOOM, qui était une révolution technique en son temps, ainsi que le matériel sur lequel il tournait dans les années 90 (ordinateurs et consoles). [Le dernier](https://fabiensanglard.net/cpsb/) 🇬🇧 couvre le matériel et le logiciel utilisés par CAPCOM pour faire tourner sur des bornes d'arcade des jeux comme Street Fighter II, Ghouls’n Ghosts, ou Final Fight.
