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

# Craft Letter n°5

## Édito

Lorsque j'ai décidé de lancer cette newsletter, je l'imaginais comme une sélection d'articles issus de ma veille, parfois agrémentée de mes commentaires. C'est bien ce qu'elle contient en général. Mais cette semaine, un intrus s'est glissé dans la lettre. Vous y trouverez en effet un sujet que je n'ai pas découvert lors de mes pérégrinations sur le Web, puisque je l'ai rédigé. Il décrit la mise en oeuvre d'un des outils dont je vous ai parlé dans un numéro précédent, Aerospace.  Elle n'a pas été triviale, aussi je me suis dit que mon expérience pourrait peut-être être utile à certain·e·s d'entre vous.

Je vous souhaite une bonne lecture,  et, surtout, une très bonne année 2026 !

Pascal




## Taiko et Gauge

[Taiko](https://yrkan.com/blog/taiko-browser-automation/) est un framework de test automatisés pour les navigateurs Web. Moins connu que le très populaire Playwright (porté par Microsoft, ce qui explique sa visibilité), il s'en distingue par sa simplicité.
Par exemple, le requêtage des éléments des pages HTML se base essentiellement sur les textes affichés, pas sur des expressions xpaths complexes.

[Gauge](https://gauge.org/) est un framework de test dans lequel des spécifications écrites en Markdown déclenchent l'exécution de tests écrits en Javascript ou Python. Il peut être utilisé en combinaison avec Taiko.

## Bonnes et mauvaises pratiques d'UX

[The Good, The Bad and The UX](https://ux-good-patterns.netlify.app) 🇬🇧 est une collection d'exemples de mauvaises pratiques d'UX, en vis-à vis de versions corrigées. Très parlant.

## Podcast Code Garage

Le [podcast Code Garage](https://code-garage.com/podcast?tab=classic) 🇫🇷 est celui du site du même nom, qui propose des cours en ligne. 
Dans des épisodes dont la plupart sont courts (moins de quinze minutes en général), Nicolas Brondin-Bernard explique les bases d'une techno, ou son historique.

Quelques épisodes plus longs sont consacrés à des interviews. 

Plus de 150 épisodes sont disponibles à ce jour.

## Déni d'inventaire

 [Les attaques par déni d'inventaire](https://www.numerama.com/cyberguerre/2148387-ils-creent-de-fausses-ruptures-de-stock-quest-ce-quune-attaque-par-deni-dinventaire.html) 🇫🇷  ciblent les sites de e-commerce. Elles visent à faire croire que certains articles ne sont plus en stock, ce qui empêche leur vente.

## Le coût caché des buzzwords dans la tech

Jernej Klancic raconte quelques anecdotes dans lesquelles [l'adoption irréfléchie d'une techno ou d'un principe qui faisait le buzz](https://engineering.leanix.net/blog/trade-offs/) 🇬🇧 lui a jouée de mauvais tours. Il a établi une liste de questions à se poser avant de prendre une décision de ce type.

J'ajoute ma propre recommandation : quand ces décisions impactent l'architecture du logiciel que vous développez, je vous invite à les tracer dans un [Architecture Decision Record](https://github.com/joelparkerhenderson/architecture-decision-record?tab=readme-ov-file#what-is-an-architecture-decision-record) (ADR) 🇬🇧, en explicitant les avantages et inconvénients de la techno choisie. C'est un document simple, idéalement au format markdown, qui est suivi sous Git, à côté du code. Dans ce document vous décrivez un problème à résoudre, les solutions que vous avez envisagées, celle que vous avez retenue et pourquoi. Vous notez aussi les conséquences de ce choix, qu'elles soient positives ou négatives. Pourquoi  faire ça ? D'une part cela oblige à se poser un minimum de questions lors d'un choix d'architecture, et cela permet de partager ses réflexions avec le reste de l'équipe. D'autre part, cela permet de garder une trace, qui pourra s'avérer utile à l'avenir : quand dans quelques années, quelqu'un se demandera pourquoi telle techno a été choisie, il en trouvera les raisons dans un ADR ; et pourra ainsi juger s'il est pertinent ou pas de remettre en cause ce choix.

## Rust in Paris

La conférence [Rust in Paris](https://www.rustinparis.com/) 🇬🇧 aura lieu vendredi 27 mars. Elle se passera en présentiel (119€, tarif étudiant 69€) mais aussi en ligne (39€). Le CFP est ouvert. Toutes les interventions seront en Anglais.

## Touraine Tech

La 8ème édition de [Touraine Tech](https://touraine.tech/) 🇫🇷 aura lieu à Tours, les 12 et 13 février 2026. Le programme est disponible, et il est encore possible de s'inscrire (70€).


## 7 choses qu'un développeur doit connaître sur les bases de données

Pierre Top donne [des recommandations](https://blog.octo.com/7-choses-qu'un-developpeur-doit-connaitre-sur-les-bases-de-donnees) 🇫🇷 sur des points auxquels nous devrions faire attention lorsqu'on met Postgresql en production. L'auteur est manifestement expérimenté sur le sujet, on devine le vécu derrière certaines recommandations. Le revers de la médaille, c'est que ce n'est pas du clé en main : parfois, il vous faudra faire quelques recherches complémentaires si vous n'êtes pas déjà familier avec les notions qu'il évoque.

## Le compilateur est votre meilleur ami

Dans un article assez long, intitulé [le compilateur est votre meilleur ami, arrêtez de lui mentir](https://blog.daniel-beskin.com/2025-12-22-the-compiler-is-your-best-friend-stop-lying-to-it) 🇬🇧 , Daniel Beskin rappelle succinctement comment fonctionne un compilateur et comment écrire le compilateur d'un langage dans ce même langage. Il explique les différences entre les compilateurs de Rust, Java et Typescript, et pourquoi un compilateur est utile, quelle que soit la taille du projet. Selon lui la présence d'une conversion de type (*cast*) dans le code est un symptôme d'un problème, typique d'un langage avec un système de type imparfait. Il décrit les solutions apportées par des langages avec des systèmes de type avancés, comme Haskell, à la gestion des valeurs nulles ou des exceptions. Il rappelle les avantages apportés par l'encapsulation des types primitifs. Puis comment les types union permettent au compilateur d'offrir des garanties comme le respect d'invariants, et donc d'éviter des bugs.  Il finit par une illustration des garanties que peuvent offrir les compilateurs de certains langages fonctionnels, qui permettent la création de types comme "Liste non vide", "Trié par priorité" ou "Âgé de 18 ans ou plus". Plus besoin de vérifier partout dans le code si ces conditions sont respectées, c'est le compilateur qui le fait pour nous. Ce qui fait dire aux développeurs de ces langages : "si ça compile, ça marche !".

## Configuration d'Aerospace

Dans [la lettre n°2](https://www.craftletter.fr/lettre-ndeg2-15-decembre-2025.html), je vous ai parlé d'Aerospace, un gestionnaire de fenêtres pour MacOS. Depuis, je l'ai adopté, et j'adore son comportement par rapport à celui du gestionnaire de fenêtre de MacOS. En une combinaison de touches (ctrl+1, 2, 3...) j'accède à l'espace de travail de mon choix, c'est tellement plus efficace que le mécanisme par défaut de l'OS.

Par contre, les seules dispositions de clavier officiellement supportées sot QWERTY, DVORAK et COLEMAK. Le support d'autres dispositions, bien que réclamé par de nombreux utilisateurs, n'est pas prévu par le mainteneur du projet. C'est le revers de la médaille de l'open source.

Cela a un impact, c'est que la configuration d'Aerospace entre en conflit avec les raccourcis clavier par défaut de MacOS, pour taper des caractères comme `~`, `{`, `[`,  ou `|` .

Il existe des solutions qui requièrent l'installation d'un logiciel tiers comme Karabiner ou BetterTouchTool. Pour ma part, j'ai préféré créer une configuration personnalisée, décrite dans `~/.aerospace.toml`. 

J'ai remplacé `alt` par `ctrl` dans les raccourcis permettant d'accéder à un espace de travail ou de déplacer une fenêtre.

Dans ce même fichier, j'ai ajouté plusieurs entrées pour affecter automatiquement certaines applications à un espace de travail.
  
Par exemple, pour que chaque nouvelle fenêtre du finder se place automatiquement dans le premier espace de travail : 

```
[[on-window-detected]]
if.app-id = 'com.apple.finder'
run = 'move-node-to-workspace 1'
```


Pour trouver rapidement l'identifiant de n'importe quelle application, et remplir la propriété `if.app-id`, il suffit de taper la commande suivante dans un terminal :

`osascript -e 'id of app "Nom de l'application"'`

par exemple : 

`osascript -e 'id of app "Firefox"'`

`osascript`est une commande qui exécute un script AppleScript.

J'ai mis en ligne ma [configuration d'Aerospace](https://gitea.zaclys.com/PascalLeMerrer/aerospace-configuration/src/branch/main/.aerospace.toml).

---

Voilà, c'est tout pour aujourd'hui !

_Cette newsletter n'est pas sponsorisée par qui que ce soit. Les liens que je mentionne ne donnent lieu à aucune contrepartie._

