Architecture on Simple Enough Blog

Comment créer un groupe de sécurité autorisant uniquement le trafic provenant de CloudFront ?

Thu, 05 Mar 2026 17:52:00 +0100

Comment créer un groupe de sécurité autorisant uniquement le trafic provenant de CloudFront ?

Pourquoi cette question revient toujours

Dans l’univers AWS, certaines questions reviennent avec une régularité frappante.
Non pas parce qu’elles sont mal formulées, mais parce qu’elles mettent le doigt sur une tension réelle entre sécurité, réseau et architecture applicative.

ADR (Architecture Decision Record) : documenter des décisions utiles

Mon, 23 Feb 2026 11:00:00 +0100

Les équipes techniques passent beaucoup de temps à discuter, arbitrer, choisir… puis à oublier pourquoi elles ont choisi certaines décisions.
Le résultat est connu :

les mêmes débats reviennent tous les 3 mois,
on re-questionne des décisions sans le contexte de l’époque,
l’onboarding dépend de “ceux qui savent”,
et des migrations inutiles naissent d’une simple perte de mémoire.

Un ADR (Architecture Decision Record) sert à éviter cela. Ce n’est pas une “grosse doc d’architecture”, ni un cahier des charges : c’est une note courte qui capture une décision importante, avec le minimum de contexte pour qu’elle reste compréhensible et réutilisable.

AWS multi-accounts : solution d’architecture ou dette organisationnelle déguisée ?

Wed, 18 Feb 2026 17:30:00 +0100

I. Introduction

La création de multiples comptes AWS est aujourd’hui présentée comme une bonne pratique quasi universelle.
Elle est souvent introduite par des tutoriels simples, orientés console, qui donnent l’impression que le problème se résume à une série de clics.

Cette vision est trompeuse.

Le multi-account n’est pas un détail d’implémentation, mais un choix architectural fondamental.
Il influence directement :

Entrer dans le cloud : les portes de l’enfer

Wed, 04 Feb 2026 09:10:00 +0100

Entrer dans le cloud est rarement vécu comme un simple changement d’infrastructure.
Pour beaucoup d’organisations, c’est une rupture brutale, presque violente, avec leurs habitudes, leurs outils et leurs modèles mentaux.

Ce qui devait apporter de la simplicité révèle au contraire une complexité jusqu’alors masquée.
Et cette complexité n’est pas seulement technique.

I. L’appel du cloud

Le cloud commence toujours par une promesse séduisante.

La latence : comprendre, percevoir et maîtriser un délai invisible

Wed, 28 Jan 2026 09:00:00 +0100

La latence est l’un de ces termes omniprésents en informatique, souvent invoqué pour expliquer un ressenti négatif — « ça lag », « c’est lent » — sans que sa signification réelle soit clairement comprise.
Pourtant, la latence n’est ni un bug, ni un simple problème de performance : c’est une contrainte structurelle des systèmes informatiques modernes.

Cet article propose une vision complète de la latence :

ce qu’elle est d’un point de vue général,
sa définition technique,
la manière dont elle est perçue par les utilisateurs,
les compromis qu’elle impose,
et surtout, comment la maîtriser architecturalement.

I. Qu’est-ce que la latence ?

1. Définition générale

Dans son sens le plus simple, la latence désigne le temps d’attente entre une action et la première réaction du système.

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.

« Ça rame », « ça lag », « ça bug » : mais au final qu'est ce que ça veut vraiement dire ?

Tue, 30 Dec 2025 10:00:00 +0100

Introduction

Dans une famille, au travail ou dans une équipe technique, il arrive souvent d’entendre : « ça rame », « ça lag » ou « ça bug ». Ces expressions sont utilisées de manière interchangeable… à tort. Elles mélangent des problèmes qui n’ont en réalité rien à voir les uns avec les autres.

Comprendre la différence entre ces trois situations permet de mieux expliquer ce qui se passe, de réagir plus vite et surtout d’éviter de mauvaises solutions. Un problème de lenteur ne se règle pas comme un bug, et un bug ne disparaît jamais simplement parce qu’on a rendu la machine plus puissante.

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.