Title: Lettre n°1 - 8 Décembre 2025
Date: 2025-12-08 10:20
Category: Newsletter
JsonLD:  { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°1", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Dec 08 2025 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">


## Édito

J'ai découvert le développement logiciel alors que je n'étais qu'un adolescent. Cela m'a passionné, au point que j'en ai fait mon métier, et après plusieurs décennies, je le pratique avec un plaisir toujours renouvelé. Si mon intérêt pour le développement logiciel ne s'est pas émoussé au fil du temps, c'est grâce à la combinaison de plusieurs facteurs.

Tout d'abord, j'apprends en permanence ; être toujours à jour en termes de technologies, d'outils et de pratiques me permet non seulement de rester pertinent, mais aussi de ne pas sombrer dans une routine dont je me lasserais inévitablement. Cela implique de pratiquer une veille technologique constante, sous de multiples formes : lecture d'articles de blogs, de livres, conférences, ateliers, projets personnels... Par chance, tout cela aussi est un plaisir pour moi.


Ensuite, j'essaie de créer des logiciels dont je suis fier : je mets en pratique certaines bonnes idées que je découvre au fil de ma veille, qu'elles soient techniques ou méthodologiques. Et je fais en sorte que les clients et utilisateurs de ces logiciels soient satisfaits.

Enfin, je partage ce que j'apprends : j'ai donné plus d'une centaine de conférences, des dizaines de formations, écrit un livre, et je contribue à l'organisation d'événements : Meetup Software Craft Rennes, SoCraTes Rennes, Breizhcamp... J'apprécie particulièrement l'aspect social du développement, aussi bien le travail en équipe que les échanges au sein de communautés de professionnels.

﻿
Améliorer constamment ses compétences et connaissances, se montrer professionnel, et partager : c'est l'essence de l'artisanat logiciel —le _software craft_. Je suis un _crafter_, pour employer un de ces anglicismes dont nous sommes si friands dans ce milieu.

Depuis plus de 15 ans, je partage une partie de mes trouvailles avec les gens qui m'entourent, que ce soient des collègues, ou les gens qui viennent voir mes conférences. La publication d'une newsletter participe de la même envie de diffuser ce qui a retenu mon attention récemment. Mes centres d'intérêt sont assez variés, cela devrait se refléter dans le contenu de la lettre au fil des semaines. Vous y trouverez des articles relatifs au développement logiciel d'une façon générale, qu'il soit front-end, back-end ou autre. Mais aussi des articles consacrés à l'architecture logicielle, la méthodologie, les outils, des projets open source, des conférences... Bref, tout ce qui fait le quotidien d'une développeuse ou d'un développeur.

Bonne lecture ! 

Pascal 

## Quitter Github pour Codeberg

[Ce retour d'expérience](https://eldred.fr/blog/forge-migration/) consacré à la migration de dépôts Git de Github vers Codeberg m'a interpelé, car j'ai migré récemment mes projets de Github vers une instance de Gitea (hébergée par Zaclys). Toutefois l'auteur de l'article est allé plus loin que le simple transfert de dépôts Git, car il a aussi migré des pipelines de CI, et les pages hébergées avec Github Pages. Il existe de nombreux scripts pour migrer tous vos dépôts d'un coup, de Github [vers ForgeJo](https://github.com/PatNei/GITHUB2FORGEJO) ou [vers Gitea](https://github.com/situ2001/gitea-bulk-migration). Je suis parti de celui-là, mais il en existe une version améliorée.

Eldred Habert n'est le seul a avoir quitté Github : [les développeurs du langage Zig ont fait de même](https://ziglang.org/news/migrating-from-github-to-codeberg/), mettant en avant la dégradation du service qu'ils ont constaté ces dernières années. Mais cela engendre un risque sur le financement du projet, qui reposait en grande partie sur Github sponsors.

## Gérer les effets de bord en 30 ligne de JavaScript

Comment tester simplement un code qui fait des appels à des services externes, comme une base de données, ou une API ? La mise en oeuvre d'une [architecture functional core - imperative shell, en seulement 30 lignes de Javascript](https://lackofimagination.org/2025/11/managing-side-effects-a-javascript-effect-system-in-30-lines-or-less/), permet de tester la logique métier, sans base de données de test ni mocks.

## L'opérateur pipe se répand

A propos d'emprunts à la programmation fonctionnelle, l'opérateur pipe |> fait partie des [nouveautés de PHP 8.5](https://les-tilleuls.coop/blog/sortie-de-php-8-5-ce-quil-faut-retenir), et il est déjà [disponible en JavaScript](https://blog.openreplay.com/fr/javascript-pipeline-operateur-signifie/) (via Babel). C'est une des choses qui me manque le plus quand je code en Python ou d'autres langages non fonctionnels (le jeu de mot est volontaire). Il change totalement la façon de penser les fonctions, et les rend bien plus simples à lire une fois qu'on a assimilé la syntaxe.

## Pourquoi GCC utilise-t-il des ou exclusifs pour mettre à 0 des registres ? 

Dans un [article court et abordable](https://xania.org/202512/01-xor-eax-eax) même quand on y connait pas grand chose en assembleur, Matt Godbolt explique avec beaucoup de pédagogie une optimisation effectuée par GCC. Et si vous vous piquez d'intérêt pour le sujet, il a lancé un calendrier de l'avent dédié à l'[optimisation lors de la compilation de code C ou C++](https://www.youtube.com/playlist?list=PL2HVqYf7If8cY4wLk7JUQ2f0JXY_xMQm2).

## Le calendrier de l'avent HTMHell est de retour

[Ce site](https://htmhell.dev/adventcalendar/?s=hell) initié par [Manuel Matuzović](https://mastodon.social/@matuzo@front-end.social) propose chaque jour jusqu'à Noël un article sur la sécurité, l'accessibilité, l'expérience utilisateur, ou les performances des pages Web.

## Se protéger des attaques supply-chain en Javascript et en Python

[Aikido Safe Chain](https://www.npmjs.com/package/@aikidosec/safe-chain) est un outil qui filtre les demandes de téléchargement de paquets JS et Python, et vérifie si le paquet demandé ne contient pas de code malveillant. A son lancement, en Juillet dernier, il était compatible avec npm, npx, et yarn ; aujourd'hui il fonctionne avec pnpm, pnpx, bun, bunx, mais aussi des outils du monde Python comme uv, pip , ou pip3. Et d'autres gestionnaires de paquets sont prévus.

## Meilleur que JSON

Dans [Meilleur que JSON](https://aloisdeniel.com/blog/better-than-json), Aloïs Deniel explique pourquoi il préfère Protobuf à l'omniprésent JSON : les données sont typées, leur format est vérifié et décrit par un schéma ; la compacité du format binaire améliore les performances. Et l'expérience développeur est améliorée par les générateurs de code. Ce qu'il ne mentionne pas, c'est qu'il existe d'autres formats du même type, comme [Apache Avro](https://avro.apache.org/). JsonToTable fournit une [comparaison détaillée des deux formats](https://jsontotable.org/blog/protobuf/protobuf-vs-avro), et indique dans quels cas d'usage chacun est plus pertinent. Spoiler : aucun des deux n'est meilleur dans tous les cas, mais les deux surpassent JSON.


Et voilà, c'est tout pour cette première lettre !
