Add newsletter #10

content/newsletter/craft-letter-10.md

@@ -0,0 +1,66 @@
+Title: Lettre n°10 — 09 février 2026
+Date: 2026-02-09 09:00
+Category: Newsletter
+JsonLD:  <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°10", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Feb 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">
+
+
+## Swift n’est pas le langage que vous croyez
+
+Dans un article qui date de 2023, Naman Goel compare [Swift et Rust](https://nmn.sh/blog/2023-10-02-swift-is-the-more-convenient-rust) 🇬🇧. Selon lui on retrouve des concepts de Rust dans Swift, comme le pattern matching ou la gestion des valeurs nulles, avec une syntaxe plus familière. Les [énumérations en Swift ](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/enumerations)🇬🇧 sont des [types algébriques](https://fr-academic.com/dic.nsf/frwiki/1669687) 🇫🇷, c’est-à-dire qu’ils combinent plusieurs autres types, pas seulement des constantes. C’est un autre concept issu de la programmation fonctionnelle.
+
+Swift est un langage multi paradigme : impératif, orienté objet et fonctionnel. La gestion de la mémoire est basée sur le [comptage de références](https://fr.wikipedia.org/wiki/Comptage_de_r%C3%A9f%C3%A9rences)🇫🇷. Il n’utilise pas de ramasse-miettes (*garbage collector*) pour libérer la mémoire, ce qui évite les pauses dans l’exécution du code. Il est compilé en code machine à l’aide de LLVM, ce qui lui permet de générer des applications pour toutes les plateformes supportées par ce dernier. 
+
+L’affirmation selon laquelle Swift serait un Rust plus simple ne me convainc pas —il y a bien des points communs entre ces langages, mais aussi pas mal de différences. Ce qui m’a plus intéressé, et que j’ai découvert grâce à cet article, c’est que Swift n’est plus limité à l’écosystème Apple. En effet, depuis 2020. Il peut générer des programmes pour Windows ou Linux, et la génération d’application d’Android est sur le point d’arriver.
+
+D’ailleurs, [Apple veut étendre son utilisation au cloud](https://www.infoq.com/presentations/swift-apps-services/) 🇬🇧. 
+
+## JQ Quest
+
+Jq est un outil bien connu pour manipuler du JSON en ligne de commande. Il peut vous éviter d’écrire un script qui doit transformer ou filtrer des données. [JQ Quest](https://codeberg.org/gturri/jq-quest) 🇬🇧 est une série d’exercice pour apprendre à vous servir de JQ.
+
+## State Of Js 2025
+
+Si vous vous êtes curieux·se de connaître les outils à la mode dans l’écosystème JavaScript, 
+vous pouvez consulter les résultats du sondage [State of JS 2025](https://2025.stateofjs.com/en-US) 🇬🇧. Ils sont en ligne —même si la page d’accueil ne l’indique pas encore à l’heure où je rédige cette neswletter... Oups.  
+
+Quelques points qui m’ont interpelés :
+
+* Angular est toujours aussi peu apprécié : plus d’une personne sur deux qui l’a essayé n’a pas aimé l’expérience.
+* Le taux de satisfaction des utilisateurs de HTMX est en baisse (de 84% en 2016 à 69% en 2025) ; je soupçonne que cela correspond à la découverte des limitations de ce framework quand les applications deviennent plus complexes. Datastar, dont je vous parlais dans [la lettre n°7](http://127.0.0.1:8000/lettre-ndeg7-19-janvier-2026.html), n’apparait pas dans ce sondage, c’est dommage, car j’aurais bien aimé découvrir les retours d’expérience à son sujet.
+* La satisfaction des utilisateurs de React est également en baisse régulière (de 92% en 2016 à 72% en 2025).
+* Cypress (Tests End-to-end), autrefois très populaire, a perdu de sa superbe, puisque à peine plus de la moitié des utilisateurs ont envie de le réutiliser.
+* À l’inverse, Playwright (tests End-to-end), Vitest (tests unitaires), Vite (build), Astro (framework pour créer des sites de contenu), Bun  (alternative à NodeJs), Hono et Fastify (frameworks Web) sont appréciés par une large majorité de ceux qui les ont utilisés.
+* Solid (Framework Front-end) maintient depuis 2021 un taux de satisfaction autour de 90% ; il mériterait sans doute plus d’attention.
+
+## ReliCSS : un outil pour faire de l’archéologie dans le Front-End
+
+[ReliCSS](https://www.alwaystwisted.com/articles/introducing-relicss-a-tool-for-front-end-archaeology)🇬🇧 est un nouvel outil qui identifie les directives obsolètes dans les feuilles de style CSS ❤️. Il n’est disponible que sous la forme d’une application Web pour l’instant, mais une version en ligne de commande est prévue.
+
+## Réviser les concepts des API REST
+
+Datacamp a publié une [synthèse sur les API REST](https://www.datacamp.com/blog/rest-api-interview-questions) 🇬🇧. Simple et efficace, j’aime beaucoup la forme !
+## Turso : une réécriture de SQLite en Rust
+
+[Turso](https://kerkour.com/turso-sqlite)🇬🇧 est une réécriture de SqLite en Rust, mais pas seulement.
+En plus des spécificités de Rust, qui devraient permettre d’éviter les bugs liés à la gestion de la mémoire qui affectent certaines versions de SqlLite, Turso apporte de nouvelles fonctionnalités : le support des connexions via le réseau et les accès concurrents, comme Postgresql.  
+## Performances de NodeJS
+
+Les [performances de NodeJs](https://www.repoflow.io/blog/node-js-16-to-25-benchmarks-how-performance-evolved-over-time)🇬🇧 ont été améliorées régulièrement de la version 16 à la version 25. Si vous n’utilisez pas encore la dernière version, la mettre à jour serait un moyen pas trop coûteux de faire un peu d’écoconception.
+## Oubliez la dette technique
+
+Derrière un titre un brin provocateur, Uwe Friedrichsen déroule [une réflexion intéressante sur la dette technique](https://www.ufried.com/blog/forget_technical_debt/)🇬🇧. Il en donne sa propre définition, qui n’est pas celle de Ward Cunningham (l’inventeur du concept) : pour lui c’est tout ce qui augmente la charge cognitive des développeurs. Il essaie d’identifier les causes de cette dette, qui sont d’après lui plus souvent organisationnelles que techniques. Il en mentionne aussi ses conséquences : le développement des fonctionnalités est ralenti, et les problèmes en production sont plus nombreux.
+Selon lui, réduire la dette sans s’attaquer à ses causes racines serait insuffisant, car elle s’accumule plus vite qu’on ne peut la réduire.
+
+À propos de dette technique, je vous suggère de (ré)écouter la conférence d’Arnaud Lemaire "[Dette technique et entropie du logiciel](https://www.youtube.com/watch?v=VKe9EE4MUxk)"🇫🇷. Il commence par expliquer la notion de dette technique telle que Ward Cunningham l’a définie, avant d’en venir à ce que désigne plus communément par ce terme, et qu’il appelle "pourriture logicielle". Ce talk, qui ensuite aborde bien d’autres sujets, reste toujours pertinent et intéressant, malgré son ton provocateur.
+
+## Images docker durcies (bis)
+
+Docker n’est pas le seul à proposer des images durcies : le [projet minimal](https://github.com/rtvkiz/minimal) le fait aussi (à une moins grande échelle). Une image durcie est une image Docker dans laquelle tout ce qui n’est pas indispensable a été supprimé, dans le but de réduire la surface d’attaque (autrement dit les failles de sécurité potentielles).
+## Devoxx France 2026
+
+La plus grosse conférence Française consacrée au développement logiciel sera de retour du 22 au 24 Avril. [La billetterie est ouverte](https://reg.devoxx.fr/#w). Conseil d’ami : n’y allez pas pour la nourriture, vous seriez déçu·e 😉.
+
+--------
+
+Voilà, c’est toute pour cette semaine !

content/pages/index.md

@@ -1,9 +1,9 @@
 Title: Accueil
-Date: 2026-02-02 09:00
+Date: 2026-02-09 09:00
 URL:
 save_as: index.html
 Category: Home
-JsonLD: { "@context": "https://schema.org", "@type": "WebPage", "name": "Accueil", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Feb 02 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/" } }
+JsonLD: { "@context": "https://schema.org", "@type": "WebPage", "name": "Accueil", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Feb 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/" } }
 
 <img class="logo" alt="Logo Craft Letter" src="{static}/images/craftletter.svg">
 
@@ -34,6 +34,7 @@ Pour savoir qui je suis, ou pourquoi j'écris cette lettre, je vous invite à vo
 
 # Archives
 
+* [Lettre n°10]({filename}/newsletter/craft-letter-10.md)
 * [Lettre n°9]({filename}/newsletter/craft-letter-9.md)
 * [Lettre n°8]({filename}/newsletter/craft-letter-8.md)
 * [Lettre n°7]({filename}/newsletter/craft-letter-7.md)