Devops on Simple Enough Blog

Qu’est-ce qu’un Harness pour agents IA ? Comprendre l’infrastructure derrière Claude Code et Cursor

Wed, 27 May 2026 15:55:01 +0200

I. Qu’est-ce qu’un Harness pour agents IA ?

Lorsque l’on découvre des outils comme Claude Code, Cursor ou OpenAI Codex, il est facile d’avoir l’impression qu’un simple modèle de langage est capable de comprendre un projet complet, corriger du code, exécuter des commandes ou encore lancer des tests de manière autonome.

Pourtant, la réalité technique est bien plus intéressante.

CheckList EC2 : 7 choses à faire après le lancement d'une instance

Wed, 20 May 2026 19:30:00 +0100

CheckList EC2 : 7 choses à faire après le lancement d’une instance

Lancer une instance EC2 est très simple.
Quelques clics dans la console AWS, et la machine démarre.

Mais en pratique, une instance lancée n’est pas une instance prête.

Beaucoup de problèmes en production viennent de détails oubliés juste après le lancement :

mauvais security group
pas de sauvegarde
pas de monitoring
pas de rôle IAM
accès SSH mal configuré
disque trop petit
pas de tag

Voici une checklist simple et pragmatique des 7 choses à vérifier immédiatement après avoir lancé une instance EC2.

Nx n’est pas un outil JavaScript : c’est un orchestrateur de travail

Wed, 13 May 2026 12:00:00 +0100

I. Nx n’est pas un outil JavaScript : c’est un orchestrateur de travail

Nx est souvent présenté — et perçu — comme un outil JavaScript.
Un “truc pour Angular”, ou au mieux “un runner pour monorepos Node”.

Cette perception est compréhensible…
mais fondamentalement incorrecte.

Nx n’est pas un outil JS.
Nx est un orchestrateur de travail.

Et c’est précisément pour cette raison qu’il apparaît presque naturellement dès qu’un dépôt devient polyglotte.

Introduction à AWS Lambda : le guide complet pour débutants et développeurs

Wed, 06 May 2026 10:00:00 +0100

I. C’est quoi AWS Lambda ?

AWS Lambda est un service de calcul serverless lancé par Amazon en 2014. L’idée est simple : on fournit une fonction (un morceau de code), et AWS l’exécute à la demande, sans qu’on aie à gérer le moindre serveur. Vous n’avez pas de serveur à provisionner, pas d’OS à maintenir, pas d’autoscaling à configurer à la main.

Pourquoi le cache Docker est insuffisant pour un monorepo ?

Tue, 28 Apr 2026 10:00:00 +0100

I. Pourquoi le cache Docker est insuffisant pour un monorepo

Docker est partout.
Et avec lui, une idée largement répandue :

« Si on structure bien nos Dockerfiles, le cache Docker va accélérer notre CI. »

C’est vrai… mais seulement jusqu’à un certain point.

Dès qu’on travaille dans un monorepo — avec plusieurs projets, plusieurs langages, plusieurs pipelines logiques — le cache Docker montre rapidement ses limites.

Que faut-il vraiment cacher dans un pipeline CI/CD ?

Tue, 21 Apr 2026 10:00:00 +0100

I. Introduction

Quand on cherche à accélérer un pipeline CI/CD, la première idée qui vient presque toujours est :

« il faut mettre du cache »

Mais très vite, une autre question apparaît :
qu’est-ce qu’on cache exactement ?

Des fichiers ? Des dossiers ? Des images Docker ? Des dépendances ?
Et surtout : quel cache a un vrai impact, et lequel complique juste le système ?

Penser top-down dans un monde complexe

Tue, 07 Apr 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.

Chaos engineering du quotidien : apprendre à aimer la vague

Tue, 24 Mar 2026 10:00:00 +0100

Nous rêvons tous d’un système stable, prévisible, “calme”. Et pourtant, la réalité d’une plateforme moderne, c’est une mer vivante : déploiements, dépendances externes, quotas cloud, réseaux capricieux, pics de charge, erreurs humaines, et parfois… juste “un truc” qui n’aurait pas dû arriver.

Le chaos engineering est souvent présenté comme une discipline spectaculaire — “on coupe une zone AWS”, “on tue un cluster”, “on fait tomber Kafka”. Dans la vraie vie (et surtout en petite équipe), ce n’est ni nécessaire, ni souhaitable au départ.

Cycle du DevOps ou incompréhension du métier ?

Tue, 17 Mar 2026 11:00:00 +0100

Introduction

Le terme DevOps est fréquemment employé pour désigner un ensemble hétérogène de sujets : CI/CD, cloud, Kubernetes, sécurité, observabilité, gestion des incidents, gestion des coûts, etc. Cette polysémie entretient une confusion récurrente : l’organisation exprime un besoin de “DevOps”, mais sans préciser la valeur attendue, les responsabilités associées, ni le modèle opérationnel cible.

Le résultat est bien connu : une succession de périodes d’urgence, suivies d’initiatives d’automatisation, puis d’un retour progressif aux mêmes difficultés. On parle alors de “cycle DevOps”. Dans de nombreux cas, ce cycle n’est pas un phénomène intrinsèque au DevOps, mais l’indicateur d’une incompréhension du métier : le DevOps est utilisé comme une fonction de compensation (support, débrouillage, prise en charge implicite de la production) plutôt que comme une capacité organisationnelle structurante.

Le vrai coût d’un mauvais workflow CI : la charge cognitive

Wed, 25 Feb 2026 10:00:00 +0100

I. Le vrai coût d’un mauvais workflow CI : la charge cognitive

On parle beaucoup de performance des pipelines CI.
On mesure les minutes.
On optimise les caches.
On parallélise.

Mais le vrai coût d’un mauvais workflow CI n’est pas le temps machine.

C’est la charge cognitive.

Et elle est beaucoup plus chère.

II. Le problème invisible

Un pipeline CI inefficace est visible :

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.

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.

Pourquoi les instances AWS Spot deviennent introuvables en décembre

Mon, 01 Dec 2025 17:08:49 +0200

I. Pourquoi les instances AWS Spot deviennent introuvables en décembre

Les instances EC2 Spot sont un excellent moyen d’économiser de 50 à 70 % sur vos coûts AWS.
Elles utilisent la capacité inutilisée des datacenters… mais justement, en décembre, cette capacité disparaît presque totalement.

Résultat :

vos Auto Scaling Groups n’arrivent plus à lancer d’instances
vos déploiements restent bloqués
“insufficient capacity” partout
des interruptions Spot beaucoup plus fréquentes

Si cela vous est déjà arrivé, rassurez-vous : ce n’est pas vous, ni un problème de configuration.
C’est un phénomène saisonnier, et il revient chaque année.

Karpenter : l'autoscaler intelligent pour EKS

Mon, 24 Nov 2025 11:18:06 +0200

I. Karpenter, c’est quoi ?

Karpenter est un autoscaler open-source pour Kubernetes, créé par AWS.
Son rôle : ajuster automatiquement la capacité des nœuds (EC2) d’un cluster EKS en fonction de la charge réelle.

En résumé :

Quand ton cluster manque de ressources, Karpenter ajoute des nœuds.
Quand les nœuds deviennent inutiles, il les supprime.

Mais surtout :

Il le fait plus vite, plus intelligemment et plus efficacement que l’autoscaler classique de Kubernetes (Cluster Autoscaler).

This is who IAM

Tue, 27 May 2025 14:38:31 +0200

I. IAM : Composants et concepts de base

IAM repose sur des entités et des stratégies.

Entités IAM

Utilisateurs : Représentent des personnes ou des applications. Ex : un développeur nommé “alice”.
Groupes : Collections d’utilisateurs partageant les mêmes autorisations.
Rôles : Entités IAM que d’autres entités peuvent assumer temporairement. Idéal pour les cas de fédération ou les services comme EC2 ou Lambda.
Politiques (Policies) : Fichiers JSON qui définissent les autorisations attachées à une entité.

Exemple de politique JSON

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": "s3:ListBucket",
 "Resource": "arn:aws:s3:::example_bucket"
 }
 ]
}

Cette politique IAM permet à une entité AWS (utilisateur, rôle ou groupe) de lister les objets contenus dans un bucket S3 spécifique nommé example_bucket. Elle utilise la version standard du langage de politique (2012-10-17) et applique un effet “Allow” à l’action “s3:ListBucket” sur la ressource identifiée par son ARN (arn:aws:s3:::example_bucket). Cela signifie que l’entité pourra voir la liste des objets dans ce bucket (noms, tailles, métadonnées), mais ne pourra ni lire, ni modifier les fichiers eux-mêmes, sauf si d’autres permissions sont ajoutées. C’est une politique minimale, souvent utilisée dans des scénarios d’inventaire ou de navigation dans un bucket via l’API ou la console AWS.

3 façons simples d'économiser jusqu'à 90 % des coûts de l'EC2: Spot Instances

Fri, 02 May 2025 17:08:49 +0200

I. Introduction aux Spot Instances

Les Amazon EC2 Spot Instances offrent une manière puissante de réduire drastiquement les coûts d’exécution dans le cloud. Conçues pour exploiter la capacité inutilisée d’Amazon EC2, ces instances sont disponibles à un tarif jusqu’à 90 % inférieur à celui des instances à la demande.

Bien que ces économies soient attrayantes, les Spot Instances ne conviennent pas à tous les types de charges de travail. Elles sont idéales pour des workloads flexibles, tolérants à l’interruption ou distribués, comme le traitement de données, l’apprentissage automatique ou les tests de performance.

Un problème. Ne paniquez pas, préparez un ticket d'assistance

Fri, 25 Apr 2025 13:10:00 +0100

I. Identifier et reproduire le problème avec rigueur

Avant de contacter l’ assistance AWS, il est essentiel de documenter précisément le comportement observé. L’ objectif est de permettre à l’ équipe de support d’analyser rapidement le contexte. Cela commence par l’identification du service concerné : EC2, S3, Lambda, ou un autre composant de votre infrastructure cloud. Documenter un incident avec clarté est fondamental pour éviter les allers-retours inutiles.

Introduction aux ELB

Sat, 15 Mar 2025 21:33:57 +0200

I. Introduction aux Load Balancers dans AWS

Un Elastic Load Balancers (ELB) agit comme un répartiteur de charge, distribuant automatiquement le trafic entrant à travers plusieurs ressources cibles, telles que les instances EC2, les containers ou les adresses IP.

Cette fonctionnalité est un pilier de la conception d’applications tolérantes aux pannes et hautement disponibles dans le cloud. AWS propose trois types d’ELB adaptés à différents cas d’usage, chacun avec ses spécificités.

Qu’ est-ce qu’ un Bundle ? Décryptage du concept

Mon, 03 Feb 2025 10:00:00 +0100

Le terme “bundle” est omniprésent dans le développement web et DevOps. Il peut désigner un regroupement de fichiers, de ressources ou d’éléments pour simplifier leur gestion et améliorer les performances.

Mais un bundle n’a pas la même signification partout. Dans cet article, nous allons explorer ses différents usages dans trois domaines clés :

Hugo (générateur de site statique)
CSS & JavaScript (développement front-end)
DevOps (Docker, Kubernetes, Helm, etc.)

I. Bundle dans Hugo : Organiser ses fichiers intelligemment

Dans Hugo, un bundle est un dossier contenant une page et ses ressources associées (images, fichiers JSON, etc.). Il existe deux types de Page Bundles :