Add newsletter #11

content/newsletter/craft-letter-11.md

@@ -0,0 +1,101 @@
+Title: Lettre n°11 — 16 février 2026
+Date: 2026-02-16 09:00
+Category: Newsletter
+JsonLD:  <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "name": "Lettre n°11", "description": "Lettre de veille technologique en développement logiciel", "image": [ "https://www.craftletter.fr/images/craftletter.svg" ], "datePublished": "Mon Feb 16 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
+
+De temps en temps, une rencontre, une conférence, une méthode ou un article me marque particulièrement, et de façon durable. Parce qu’il est aligné avec mes valeurs, et qu’il m’apporte un éclairage nouveau. Je m’appuie dessus, le cite fréquemment et mets en œuvre tout ou partie de ce qu’il raconte pendant quelques années, jusqu’à ce que ce soit tellement intégré que je n’y pense même plus, et que cela devienne une évidence  —ce qui est un problème, car ce qui est acquis pour moi ne l’est pas nécessairement pour les autres. Cela a été le cas, par exemple,  il y a 25 ans lors de ma découverte de l’eXtreme Programming et de l’Agilité —l’état d’esprit original, pas la caricature qui s’est répandue depuis.
+
+Le premier article mentionné dans cette newsletter fera probablement partie de ces rares élus. Les chiffres qu’il donne méritent d’être retenus, et ses conseils devraient être suivis, selon moi.
+
+## La crise de qualité logicielle et de productivité que les exécutifs ne traiteront pas
+
+Si vous ne deviez lire qu’un seul article cette semaine, c’est [celui-là](https://flowchainsensei.wordpress.com/2026/02/04/the-software-quality-and-productivity-crisis-executives-wont-address/) 🇬🇧.
+
+Bob Marshall fait un constat assez accablant, en partant de plusieurs études : la qualité des logiciels s’est considérablement dégradée ces dernières années, et les trois quarts des projets de développement logiciel sont des échecs. Ces chiffres n’ont jamais été aussi hauts. La dette technique est la principale préoccupation de 9 CTO sur 10, et la solution pour la résorber est connue. Malgré ça, la direction des entreprises n’y accorde aucun intérêt, tant qu’une crise n’éclate pas. Pourquoi ? Parce que la majorité des dirigeants se focalisent sur leurs revenus personnels, et sur le court terme. De même, ils ne s’intéressent pas au bien être des développeurs, alors que 83% d’entre eux ont fait, ou feront, un burn-out.
+
+Pourtant, l’histoire récente nous montre qu’un autre monde est possible. Un monde où la qualité est une préoccupation, et où la majorité des projets atteignent leurs objectifs —l’un découlant de l’autre. Un monde où les développeurs sont heureux de faire leur travail, et ne mettent pas en péril leur santé mentale. Pour revenir à ça, ce que préconise Bob Marshall, c’est de prendre en main vous-même la gestion de la dette technique, sans en attendre l’autorisation —qui ne viendra pas, ou trop tard. Et de rendre ce travail visible en définissant vos propres indicateurs, qui auront plus de valeur que ceux qu’on vous impose.
+
+Bob Marshall évoque les risques de cette démarche, mais j’ajouterais qu’il ne faut pas en négliger les avantages :  se montrer courageux et transparent est un moyen de gagner le respect de vos collègues. Et si vous êtes dans une entreprise qui punit ces qualités au lieu de les récompenser, il est temps d’en changer.
+
+À lire d’urgence.
+
+## Laravel vs Symfony
+RadWebHosting a établi [une comparaison détaillée des deux frameworks PHP les plus populaires](https://blog.radwebhosting.com/laravel-vs-symfony-a-comprehensive-comparison-of-php-frameworks/) 🇬🇧, Laravel et Symfony, avec des recommandations pour vous guider dans un choix entre les deux.
+## Event Storming
+
+L'Event Storming est un type d'atelier inventé par Alberto Brandolini —oui, celui qui a énoncé la [loi de Brandolini](https://fr.wikipedia.org/wiki/Loi_de_Brandolini)🇫🇷, mais ça n'a aucun rapport.
+
+L'Event Storming se décline en différentes variantes, selon l'objectif. Les plus courantes sont :
+
+* **Big Picture Event Storming** : pour explorer collaborativement un domaine métier complexe ;
+* **Process Modeling Event Storming** : pour détailler un process métier, du début à la fin (par exemple : de la commande à la livraison d'un produit) ;
+* **Software Design Event Storming** : pour enrichir un Process Modeling Event Storming, en y ajoutant des éléments d'architecture logicielle (contextes bornés, agrégats, commandes...).
+
+J'ai animé à plusieurs reprises des ateliers **Process Modeling Event Storming**, avec un public mixte, technique et métier. Mon retour d'expérience, c'est que, s'il est bien préparé, c'est un atelier qui apporte énormément de valeur par rapport au temps consacré —je vous recommande de prévoir deux heures, pas plus. Les participants, même s'ils travaillent sur le logiciel depuis plusieurs années, en apprendront des subtilités qu'ils ignoraient. C'est un outil idéal pour faire découvrir un logiciel existant à de nouveaux venus.
+
+Staffan Palopää explique [comment animer ces ateliers](https://www.qlerify.com/post/event-storming-the-complete-guide) 🇬🇧.
+
+## Moderniser un legacy conséquent sans y perdre ses plumes
+
+Dans cette [première partie](https://blog.octo.com/apprivoiser-un-legacy-consequent-sans-y-perdre-les-plumes) 🇫🇷, Bruno Boucart décrit comment le code legacy s’installe inexorablement au fil des années, et devient un obstacle pour les développeurs, qui subissent les conséquences de choix organisationnels. La modernisation d’un code legacy est souvent perçue comme impossible. Mais la réécriture totale d’un logiciel, sans changement des pratiques et de l’organisation, produira une application avec les mêmes défauts que la précédente. En particulier, le management doit adopter la posture du *servant leadership*, c’est-à-dire créer les conditions qui permettront aux équipes de réussir, plutôt que de chercher à les contrôler. 
+
+L’organisation d’ateliers d’Event Storming Big Picture est un moyen d’assurer que le nouveau code correspondra aux besoins du métier. Mais cela implique de réorganiser les équipes en fonction des sous-domaines identifiés lors de ces ateliers. Après avoir identifié les sous-domaines, qui sont un découpage du problème, il devient possible de découper la solution technique en contextes bornés (*bounded contexts*). Cet alignement entre l’organisation du code, les responsabilités des équipes, et le métier, est une condition indispensable au succès de la refonte.
+
+Une autre condition réside dans la compréhension du métier par les développeurs. Ce point peut être résolu par l’organisation d’ateliers. Tout d’abord, des ateliers de User Story Mapping, qui permettent d’identifier les parcours utilisateurs et prioriser les User Stories. Ensuite, des ateliers d’Example Mapping, pour préciser le contenu des User Stories.
+
+La dernière partie de l’article évoque trop rapidement l’approche Team Topologies pour être utile.
+
+Si la différence entre sous-domaines et contextes bornés n’est pas claire pour vous, je vous invite à lire [cette explication](https://blog.ancyracademy.fr/posts/bounded-contexts-vs-subdomains/) 🇫🇷.
+
+Si vous souhaitez vous familiariser avec le Domain Driven Design, je vous recommande la lecture de [Learning Domain Driven Design](https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/) 🇬🇧 de Vlad Khononov.
+
+J’évoquerai dans la prochaine lettre la suite de l’article de Bruno.
+
+## Découvrir ou approfondir JavaScript et/ou TypeScript
+
+Axel Rauschmayer propose [une série de livres](https://exploringjs.com/)  🇬🇧, à propos de JavaScript et Typescript, dont la version en ligne est gratuite.
+
+## Le but de l’intégration continue est d’échouer
+
+Je ne suis pas du tout d’accord avec le point de vue défendu par l’auteur de ce billet de blog, selon lequel [le but de la CI serait d’échouer](https://blog.nix-ci.com/post/2026-02-05_the-purpose-of-ci-is-to-fail) 🇬🇧. Selon lui, la valeur ne serait produite que par les erreurs détectées, comme il l’explique après un rappel de ce qu’il entend par CI (*Continuous Integration*).
+
+Sans surprise, mon point de vue est celui qui est plus communément admis : l’objectif de la CI  est de nous assurer que le code que l’on s’apprête à déployer ne comporte pas de problème évident, et a de bonnes chances de fonctionner en production.
+
+Au passage, j’ajouterai que si l’auteur décrit ce qui est appelé de façon un peu abusive "intégration continue" aujourd’hui (par moi aussi), ce n’est pas ce que désigne initialement cette expression. Le concept d’intégration continue consiste à fusionner tous les jours votre code avec celui de vos collègues, comme son nom l’indique. Pour cela, un système de gestion de version tel que Git suffit.  Github Actions, Gitlab CI ou un équivalent ne sont pas nécessaires. Le build et les vérifications automatisés exécutés par ces derniers sont un complément très utile de l’intégration continue au sens premier. Faire une "vraie" intégration continue élimine la plupart des conflits, ce qui gagne du temps et évite des bugs. Cela nécessite de réaliser en plusieurs fois les changements, plutôt qu’attendre qu’une fonctionnalité soit complète avant de fusionner des centaines, voire des milliers de lignes de code. Ce qui peut amener à faire du Trunk Based Development, et améliorer nettement la productivité.  Mais c’est une autre histoire, dont j’aurais certainement l’occasion de vous parler plus tard.
+
+## Une conférence au soleil 
+
+[Sunnytech](https://sunny-tech.io/) 🇫🇷, la conférence Tech organisée à Montpellier, aura lieu les 2 et 3 juillet 2026. Le CFP est ouvert. La première vague de billets est déjà vendue, mais une nouvelle vague sera mise en vente mi-avril, avant une troisième et dernière vague fin avril.
+
+## Une conférence peut-être un peu moins ensoleillée...
+... et encore, ça reste à démontrer ! 😉
+
+Le 9 Juin aura lieu [C:\aen\Tech](https://caen.tech/) 🇫🇷, une conférence Normande qui privilégie les retours d’expérience locaux. Le CFP est ouvert.
+## Granian, un serveur HTTP performant pour Python
+
+C’est un euphémisme de dire que les performances ne sont pas le point fort de Python. 
+
+[Granian](https://github.com/emmett-framework/granian) est un serveur HTTP écrit en Rust, qui vise à améliorer cet état de fait. Remplacer Guvicorn ou Uvicorn par Granian ne transformera pas votre application en bête de course, car de multiples autres facteurs entrent en jeu : le framework, les algorithmes implémentés, les accès disque et réseau, les requêtes à la base de données... Mais c’est une étape, qui peut apporter des changements significatifs par rapport à la simplicité de l’effort demandé. Il faudra bien entendu faire des benchmarks pour mesurer l’impact réel de ce changement dans votre cas de figure. En effet, dans le pire des cas, il peut s’avérer négatif. Cela peut arriver si votre code n’est pas asynchrone. 
+
+Merci à Mikaël qui m’a fait découvrir Granian et partagé son retour d’expérience !
+
+## Crystal, un langage pour les humains et les ordinateurs
+
+Lors du Fosdem, cette énorme conférence dédiée à l’open-source, [Johannes Müller a présenté Crystal](https://crystal-lang.org/2026/01/23/crystal-talk-fosdem/) 🇬🇧. Crystal est un langage généraliste, Orienté Objet, inspiré de Ruby. Il en corrige ce que je considère comme des points faibles. Il apporte un typage statique, de l’inférence de type, de meilleures performances, un déploiement plus facile et une meilleure gestion de la concurrence, tout en conservant la lisibilité et la facilité d’utilisation de Ruby. Ce langage sympathique est utilisé en production, comme le montre [cette liste](https://crystal-lang.org/used_in_prod/) qui est probablement incomplète.
+
+Crystal, qui date de 2013, a eu pour slogan jusqu’à fin 2019 "Fast as C, slick as Ruby" ("*Rapide comme C, Ingénieux comme Ruby*"). L’affirmation selon laquelle Crystal aurait la rapidité du C était exagérée, et c’est probablement pourquoi ce slogan a été abandonné.
+
+## Bienfaits du TDD et tests en production 
+
+Ola Hast et Asgaut Mjølne Söderbom [expliquent comment leurs équipes obtiennent d’excellents résultats](https://www.infoq.com/news/2026/02/feedback-TDD-production/) 🇬🇧  avec des tests unitaires et des tests d’intégration, sans tests end-to-end. 
+
+Le TDD et le Pair programming leur permettent d’écrire un code de qualité. Le Pair et le Mob Programming éliminent le besoin de faire des revues de code, diffusent la connaissance, et augmentent la résilience des équipes.
+
+Puisque les environnements de test ne sont qu’une approximation de la production, ils les ont quasiment abandonnés au profit du test en production, et déploient de petits incréments, désactivables par des *feature flags* pour réduire les risques.
+
+-----
+
+Voilà, c’est tout pour cette semaine.

content/pages/index.md

@@ -1,9 +1,9 @@
 Title: Accueil
-Date: 2026-02-09 09:00
+Date: 2026-02-16 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 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/" } }
+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 16 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°11]({filename}/newsletter/craft-letter-11.md)
 * [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)