Thibault on Simple Enough Blog

Penser top-down dans un monde complexe

Thu, 26 Feb 2026 17:30:00 +0100

I. Deux manières fondamentales de raisonner

Lorsqu’on observe la façon dont on conçoit aujourd’hui des systèmes complexes — infrastructures DevOps, plateformes distribuées, logiciels modernes ou même parcours éducatifs — on retrouve presque toujours la même tension intellectuelle. D’un côté, une approche progressive et incrémentale, qui part des bases pour aller vers quelque chose de plus élaboré. De l’autre, une approche orientée par le résultat attendu, qui commence par définir un objectif, puis remonte ce qui est nécessaire pour l’atteindre.

Test-Driven Infrastructure : appliquer le TDD à l’Infrastructure as Code

Wed, 14 Jan 2026 13:45:30 +0200

Test-Driven Infrastructure

Appliquer le TDD à l’Infrastructure as Code

Le Test-Driven Development (TDD) est aujourd’hui bien installé côté applicatif.
En revanche, lorsqu’il s’agit d’infrastructure, beaucoup considèrent encore que le TDD est inutile, trop complexe ou inadapté.

C’est une erreur.

Le TDD appliqué à l’infrastructure existe déjà, souvent sans être nommé. Lorsqu’il est bien compris, il devient un levier majeur pour sécuriser, structurer et faire évoluer une plateforme cloud.

Utiliser les constantes en TDD avec Go

Tue, 23 Dec 2025 10:08:49 +0200

Bonnes pratiques, pièges et signaux de design

Le Test-Driven Development (TDD) ne sert pas uniquement à écrire des tests.
Il sert avant tout à concevoir du logiciel.

En Go, l’usage des constantes est souvent mal compris en TDD :

faut-il les exposer ?
les tester ?
les injecter ?
les éviter ?

Cet article propose une approche pragmatique et idiomatique Go, issue de l’expérience terrain, pour comprendre quand une constante est un bon design… et quand elle cache un problème.

Interfaces, Fonctions et Modules en Go : Structurer son code pour le TDD sans le complexifier

Mon, 15 Dec 2025 10:08:49 +0200

I. Introduction

Go est un langage minimaliste, mais cette simplicité peut donner l’impression qu’il “manque quelque chose” lorsqu’on aborde des architectures plus poussées, du Test-Driven Development ou la nécessité de mocker certaines dépendances. Très vite, les développeurs venant de Java, C# ou Python se posent les mêmes questions :

Dois-je transformer toutes mes fonctions en structs + interfaces pour tester ?
Comment organiser mes packages pour qu’ils soient modulaires et testables ?
Où placer les interfaces ? Chez le fournisseur ou chez le consommateur ?
Comment isoler un package qui expose uniquement des fonctions ?
Comment détecter automatiquement un changement de signature ?

II. Le modèle Go : simple, modulaire, mais différent

Contrairement à Java ou C#, Go ne repose pas sur l’héritage, les classes ou les gros frameworks d’injection de dépendances.

Consumer-Reported Dependency Health

Mon, 08 Dec 2025 11:18:06 +0200

I. Réinventer la manière d’évaluer la santé des systèmes distribués

Dans les architectures distribuées modernes, la santé d’un système dépend autant — voire davantage — de l’état de ses dépendances que de son état interne. Pourtant, la plupart des stratégies de monitoring reposent encore sur des healthchecks synthétiques ou dédiés : endpoints /health, sondes liveness/readiness, scripts externes, etc.

Comment gérer les paramètres optionnels en Go.

Sat, 15 Nov 2025 10:00:00 +0200

I. Comment gérer les paramètres optionnels en Go

Dans la plupart des langages modernes, il est possible de définir des valeurs par défaut dans les fonctions ou de les surcharger pour couvrir plusieurs cas d’usage.
Go, lui, ne propose ni paramètres optionnels, ni surcharge, ni valeurs par défaut dans les signatures de fonction.
Pourtant, les besoins restent les mêmes : créer des APIs lisibles, stables et capables d’évoluer sans casser les utilisateurs.

Pourquoi et comment utiliser les sous-modules Git

Wed, 02 Jul 2025 18:30:00 +0200

I. Introduction aux sous-modules Git

Les sous-modules Git sont une fonctionnalité native qui permet d’inclure un dépôt Git à l’intérieur d’un autre. Cette approche est utile lorsqu’il faut gérer des dépendances entre différents codebases, tout en conservant leur autonomie.

Les sous-modules pointent vers une révision précise d’un dépôt externe. Cela garantit que chaque version du projet principal utilise exactement la même version de ses sous-modules, assurant ainsi cohérence et reproductibilité.