Aller au contenu

Toutes les fiches — Page 17

Qualité & Sécurité

TDD is dead. Long live testing. (Une contre-argumentation point à point à l'article phare de David Heinemeier Hansson, détracteur du Test-driven development)

**Mathieu Eveillard** publie sur son blog personnel le **7 décembre 2022** (dernière mise à jour 17 mars 2025) une **contre-argumentation point à point** au célèbre essai de **David Heinemeier Hansson (DHH)** *"TDD is dead. Long live testing."* (RailsConf 2014). Article catégorisé **craft / best-of**, position d'**artisan logiciel** qui défend le **Test-Driven Development** sans dogmatisme. **Distinction-pivot** que DHH manque selon Eveillard : ***"Test-first"*** (écrire tous les tests avant le moindre code) vs ***"Test-Driven Development"*** (les tests me **guident** dans l'écriture du code, donc j'écris à chaque fois un peu de code *"en réaction"* à un nouveau test). DHH critique le *Test-first* en l'appelant TDD — confusion qui **cache une tout autre façon de programmer**. **Réponses point à point** : (1) *"TDD as hammer to beat down the nonbelievers"* — Eveillard concède le point déontologique mais redéfinit *"bon code"* : pas seulement absence de bugs mais **tests unitaires fins** documentant le comportement au plus bas niveau, co-localisés avec le code, **filet de sécurité** ; (2) *"Rebalance from unit to system"* — TDD **ne dit rien** des tests système et **ne dit pas** qu'il n'y a rien en dehors du TDD ; tests système ne **remplacent pas** unitaires (impôt sur le revenu en e2e n'a aucun sens) ; **pyramide de tests** — chaque type apporte sa pierre, unitaires pour feedback **millisecondes** + détection bug précoce ; (3) *"Horrendous monstrosities of architecture (service objects, command patterns)"* — Eveillard répond qu'il **ne connaît pas ces effets en programmation fonctionnelle**, donc l'effet est probablement dû à la **POO**, pas au TDD ; mais concède que trop d'injection de dépendances peut coupler test et implémentation. **Conclusion équilibrée** : *"Le TDD n'est pas une religion, c'est un outil"*. Le TDD se prête particulièrement bien au **code du domaine** (noyau fonctionnel d'un *bounded context*, *cœur de l'hexagone*) — moteur de calcul, règles de gestion fines, cas limites — ***"30% au plus de la codebase"***. Mention de la **Loi de l'Instrument** (si l'outil n'aide pas, c'est qu'on tombe dedans). **Pertinence dossier** : article **craft hors-corpus IA** mais à archiver pour positionner les débats actuels sur les coding agents (Beck *Augmented Coding Beyond Vibes* 2025-06-25, Vibe Coding vs TDD, Frizzo *writing muscle atrophy*) dans la lignée historique des débats craft autour du TDD. À mobiliser comme **fond de bibliothèque** pour formations.

#Mathieu Eveillard#TDD#Test-driven development

**Mathieu Eveillard** — développeur / coach craft / formateur (blog personnel mathieueveillard.com, services *Accompagnement* et *Office hours*). Identité publique : *artisan logiciel* avec une pratique pédagogique autour du TDD · du DDD et du craft. Newsletter hebdomadaire (*"Chaque mercredi, une idée pour démarrer la journée"*).

Architecture & Construction

The Magic of Platforms

Keynote **Gregor Hohpe** (Enterprise Strategist AWS, auteur *The Software Architect Elevator* et du livre en cours *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse*) à **PlatformCon 2022** sur **la magie des plateformes** — pourquoi les plateformes réussissent, ce qui les distingue d'une simple *IT Service Management*, et **les décisions d'architecture non-triviales** à prendre quand on en construit une. **Thèse-pivot** : *« les standards ne réduisent pas la créativité, ils peuvent la décupler »* — analogue Baltimore 1904 (incendie, pompes incompatibles), vis métrique ISO, HTTP, papier A4. **Citation canonique reprise de Peter / Thoughtworks** : ***« platforms centralize expertise but not innovation »*** — on ne réinvente pas la roue, mais on laisse l'innovation aux équipes proches du client. **Analogie pivot** : industrie automobile (Volkswagen Group construit Audi A4 et Bentley Bentayga sur la même plateforme), *« undifferentiated heavy lifting »* (vocabulaire AWS) sous le capot, différenciation visible côté client. **Trois propriétés d'une vraie plateforme** : (1) **low friction** — on ne peut pas forcer l'adoption, les équipes contourneront ; (2) **transparence** (pas une *black box*) — les utilisateurs doivent pouvoir diagnostiquer s'ils sont en cause ou si c'est la plateforme ; (3) **shared responsibility** (référence directe au *AWS Shared Responsibility Model*) — la plateforme ne corrige pas une appli mal conçue. **Anti-pattern explicite** : *« a common layer can be many things — it is not necessarily a platform »* ; l'IT Service Management traditionnelle a la même image (couche commune sous tout le monde) mais l'**interface est l'opposée** (high-friction, formulaires, bottleneck). **Deux voies de construction** : (a) anticiper tous les besoins (Hohpe : *« I don't feel I'm smart enough »*) ; (b) **évolution** à partir de pièces utiles, en observant l'usage. **Décisions à expliciter** : objectifs (cognitive load ↓, safer / fewer mistakes, faster via samples/blueprints/self-service, compliance), forme de la courbe d'apprentissage (cliff, hockey stick, gear shift). **Concept canonique #1 — Floating platforms vs Sinking platforms** : quand la *base platform* (typiquement le cloud) gagne de nouvelles capacités, **deux stratégies opposées** : **sinking platform** (statique, dupliquant ce que la base offre maintenant, coulant à mesure que le niveau monte) vs ***floating platform*** (jette les morceaux devenus redondants, **re-monte au-dessus du nouveau niveau**, innove plus haut). Métaphore *« submarine and a boat »*. Implication contractuelle forte : **prévenir explicitement les stakeholders** que des composants seront supprimés quand la base les absorbe. **Concept canonique #2 — Fruit salad vs Fruit basket** : une plateforme n'est pas une collection de capacités juxtaposées (panier) mais un assemblage **proportionné et bite-sized** où les pièces interagissent — *« the per-kilo price for fruit salad is higher than for a fruit basket »*. Le titre dérive de l'expression *the magic of platforms* — l'effet contre-intuitif où **standardiser libère l'innovation au lieu de l'étouffer**, à condition de soigner l'interface, l'évolution et l'intégration entre les composants. À mobiliser pour : architectes plateforme, **Platform Engineering / IDP teams 2026** (référence fondatrice, prédate l'explosion *Internal Developer Platforms* mais structure le vocabulaire), DSI évaluant build-vs-stagnate face aux capacités natives cloud, COMEX produit. Convergence avec **AI/works™ Thoughtworks** (2026-05-12), **L'Usine Logicielle Augmentée Wescale** (2026-05-03), **PROJ-AI Habert/WEnvision** (2026-05-05), **DORA AI ROI** (2026-04-21 — Platform comme pilier systémique).

#Plateformes logicielles#platform engineering#Internal Developer Platforms IDP

**Gregor Hohpe** — Enterprise Strategist chez Amazon Web Services · architecte logiciel · auteur prolifique (*Enterprise Integration Patterns* — référence depuis ~2003 — et *The Software Architect Elevator*, O'Reilly 2020). Au moment du talk · écrit *Platform Strategy: Accelerating Innovation Through Harmonization and Reuse* (publié sur Leanpub, accessible via *leanpub.com/platformstrategy*). Profil : architecte *bridging the gap between business and tech* · expérience CTO Allianz · conseil C-suite · conférencier régulier (QCon, GOTO, PlatformCon). Référence majeure dans l'architecture d'entreprise et l'intégration. Talk donné en **keynote PlatformCon 2022** (juin 2022, conférence en ligne organisée par platformengineering.org).

Philosophie & Société

How To Speak

Techniques de communication orale, présentation académique, heuristiques de parole efficace

#communication orale#art oratoire#présentation

Patrick Winston

Philosophie & Société

Goodhart's law

Article encyclopédique (Wikipedia, anglais) sur la **loi de Goodhart** : énoncée par l'économiste britannique Charles Goodhart en 1975 à propos de la politique monétaire — « toute régularité statistique observée tend à s'effondrer dès qu'on exerce une pression sur elle à des fins de contrôle » — puis généralisée par l'anthropologue Marilyn Strathern (1997) en l'aphorisme canonique « quand une mesure devient une cible, elle cesse d'être une bonne mesure ». Le sujet relie économie, théorie des incitations, évaluation des politiques publiques et, par extension, l'optimisation des métriques dans les systèmes d'IA.

#loi de Goodhart#mesure devenue cible#régularité statistique

Wikipedia contributors (concept : Charles Goodhart ; généralisation : Marilyn Strathern)