Mis à jour ces 90 derniers jours 16 nouvelles · 27 révisées
Fichier listant les patterns à exclure du contexte de build Docker. Réduit la taille du contexte envoyé au daemon.
La liste des choses à NE PAS mettre dans la valise avant un voyage.
node_modules
.git
.env
dist
*.md
.DS_StoreCas d'usage : Accélérer le build et éviter de copier des fichiers sensibles ou inutiles dans l'image.
Méthodologie en 12 principes pour construire des applications cloud-native. Inclut config via env vars, stateless processes, port binding, logs as streams.
Les 12 commandements du développeur cloud : suis-les et ton app tournera partout sans problème.
// Factor 3 : Config via env vars
const dbUrl = process.env.DATABASE_URL;
// Factor 6 : Stateless processes
// Pas de state en mémoire locale
// Factor 11 : Logs as event streams
process.stdout.write(JSON.stringify(logEvent));Cas d'usage : Concevoir des applications facilement déployables sur n'importe quel cloud ou PaaS.
Propriétés des transactions relationnelles. Atomicité (tout ou rien), Cohérence, Isolation (pas d'interférence), Durabilité (persisté après commit).
Un virement bancaire : soit les deux comptes sont mis à jour, soit aucun. Pas de demi-transfert.
const trx = await db.transaction();
try {
await trx('accounts').where({ id: from }).decrement('balance', amount);
await trx('accounts').where({ id: to }).increment('balance', amount);
await trx.commit();
} catch (e) {
await trx.rollback();
}Cas d'usage : Garantir l'intégrité des données financières, commandes, stocks.
Outil de configuration management et d'automatisation agentless (via SSH). Utilise des playbooks YAML déclaratifs pour configurer des serveurs.
Un chef d'équipe qui donne des instructions par téléphone (SSH) sans avoir besoin d'installer un logiciel sur place.
# playbook.yml
- hosts: webservers
tasks:
- name: Install nginx
apt: name=nginx state=present
- name: Start nginx
service: name=nginx state=startedCas d'usage : Configurer des serveurs, déployer des applications, orchestrer des tâches multi-machines.
Plateforme de streaming distribué à haute performance. Les messages sont persistés dans des topics partitionnés, consommés par des consumer groups.
Un journal officiel : les articles (messages) sont publiés, archivés, et chaque lecteur (consumer) peut relire depuis n'importe quelle date.
// Producer
await producer.send({
topic: 'user-events',
messages: [{ key: userId, value: JSON.stringify(event) }]
});
// Consumer
await consumer.subscribe({ topic: 'user-events' });
await consumer.run({ eachMessage: async ({ message }) => {
processEvent(JSON.parse(message.value));
}});Cas d'usage : Event sourcing, streaming de données temps réel, communication inter-services à grande échelle.
Outil de déploiement continu GitOps pour Kubernetes, projet diplômé de la CNCF. Il surveille un dépôt Git (manifests, Helm, Kustomize), compare avec l'état du cluster, affiche la dérive et synchronise automatiquement ou à la demande. Argo CD 3.0, publié le 6 mai 2025, durcit les défauts (RBAC des logs appliqué, journaux JSON) et améliore les performances.
Un contremaître qui relit le plan d'architecte toutes les trois minutes et corrige le chantier dès qu'un mur n'est pas au bon endroit.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata: { name: api-prod, namespace: argocd }
spec:
project: default
source:
repoURL: https://github.com/acme/infra
path: apps/prod/api
targetRevision: main
destination:
server: https://kubernetes.default.svc
namespace: api
syncPolicy:
automated: { prune: true, selfHeal: true } # corrige la dériveCas d'usage : Déployer des dizaines d'applications sur plusieurs clusters avec un historique auditable et une interface qui montre l'écart Git ↔ cluster.
Fichier ou ensemble de fichiers produits par un job CI/CD (binaire, image Docker, rapport de tests). Passé entre stages ou archivé.
Le produit fini sortant d'un atelier, prêt à être livré ou inspecté au poste suivant.
- uses: actions/upload-artifact@v4
with:
name: build-output
path: dist/Cas d'usage : Partager le résultat du build entre le job de build et le job de deploy.
Modèle de cohérence des systèmes distribués NoSQL. Basically Available, Soft state, Eventually consistent. Opposé à ACID, favorise la disponibilité.
Un réseau social : ton post apparaît chez toi immédiatement mais chez tes amis quelques secondes plus tard.
// Écriture sur le noeud primaire
await primary.set('user:123', userData);
// La replica peut avoir un léger retard
const cached = await replica.get('user:123');
// Peut retourner l'ancienne valeur pendant quelques msCas d'usage : Systèmes à très haute disponibilité où un léger délai de cohérence est acceptable.
Stratégie de déploiement maintenant deux environnements identiques (blue=actif, green=nouvelle version). Le switch est instantané via le load balancer.
Préparer un deuxième plateau repas en cuisine puis échanger les plateaux sur la table d'un coup.
# 1. Déployer la nouvelle version sur green
# 2. Tester green
# 3. Basculer le trafic
aws elbv2 modify-listener \
--listener-arn $ARN \
--default-actions TargetGroupArn=$GREEN_TG
# 4. L'ancien blue devient le prochain greenCas d'usage : Déploiement zéro-downtime avec rollback instantané en cas de problème.
Pattern d'isolation des ressources en compartiments séparés. Si un compartiment sature, les autres continuent de fonctionner normalement.
Les compartiments étanches d'un navire : si un se remplit d'eau, les autres restent secs et le bateau ne coule pas.
// Pools de connexions séparés par service
const paymentPool = new Pool({ max: 10 });
const analyticsPool = new Pool({ max: 5 });
// Si analytics sature son pool,
// le pool de payment reste disponibleCas d'usage : Empêcher qu'un service lent consomme toutes les connexions et bloque les autres.
Librairie Node.js de gestion de queues basée sur Redis. Supporte les jobs delayed, repeatable, la priorisation et les workers concurrents.
Une file d'attente intelligente avec des tickets numérotés, des VIP, et des tâches programmées.
const queue = new Queue('emails');
await queue.add('welcome', { userId: '123' });
const worker = new Worker('emails', async (job) => {
await sendEmail(job.data.userId);
});Cas d'usage : Traitement asynchrone : envoi d'emails, génération de PDF, processing d'images.
Processus de suppression ou mise à jour des données en cache devenues obsolètes. L'un des deux problèmes les plus durs en informatique.
Retirer les produits périmés des rayons du supermarché : oublier et le client mange un yaourt périmé.
// TTL-based
await cache.set('user:123', data, 'EX', 300);
// Event-based
userEvents.on('updated', async (userId) => {
await cache.del(`user:${userId}`);
});Cas d'usage : Maintenir la fraîcheur des données cachées sans sacrifier les performances.
Stratégie où l'application vérifie le cache d'abord, puis lit la DB en cas de miss et remplit le cache. Le cache ne se remplit qu'à la demande.
Tu cherches dans ton tiroir (cache), si ce n'est pas là tu vas au grenier (DB) et tu ranges une copie dans le tiroir.
async function getUser(id) {
let user = await cache.get(`user:${id}`);
if (!user) {
user = await db.findUser(id);
await cache.set(`user:${id}`, user, 'EX', 300);
}
return user;
}Cas d'usage : Pattern le plus courant pour accélérer les lectures fréquentes sans charger la DB.
Déploiement progressif envoyant d'abord un petit pourcentage du trafic vers la nouvelle version. Si les métriques sont bonnes, on augmente progressivement.
Le canari dans la mine : on envoie un éclaireur (1% du trafic) pour vérifier que l'air est bon avant d'envoyer tout le monde.
# Istio canary routing
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
spec:
http:
- route:
- destination: { host: api, subset: stable }
weight: 90
- destination: { host: api, subset: canary }
weight: 10Cas d'usage : Déploiements à haut risque sur des systèmes critiques avec observation progressive.
Un système distribué ne peut garantir simultanément que 2 des 3 propriétés : Consistency, Availability, Partition tolérance. En pratique on choisit CP ou AP.
Tu peux avoir un resto rapide, bon marché, ou de qualité : choisis-en deux, pas trois.
// CP (Consistency + Partition tolerance)
// -> MongoDB avec write concern majority
// AP (Availability + Partition tolerance)
// -> Cassandra, DynamoDB
// CA n'existe pas en distribué (partition inévitable)Cas d'usage : Choisir la bonne base de données selon les besoins de cohérence vs disponibilité.
Réseau de serveurs distribués géographiquement pour servir le contenu statique au plus proche de l'utilisateur. Réduit la latence et la charge serveur.
Des distributeurs automatiques dans chaque quartier au lieu d'un seul magasin central.
// Cloudflare, CloudFront, Vercel Edge
// Headers de cache
Cache-Control: public, max-age=31536000, immutable
// Invalidation
aws cloudfront create-invalidation \
--distribution-id ABC --paths "/*"Cas d'usage : Servir images, JS, CSS avec des temps de réponse <50ms partout dans le monde.
Commande Git pour appliquer un commit spécifique d'une branche sur une autre sans fusionner toute la branche.
Cueillir une cerise sur un arbre sans prendre tout l'arbre : on prend juste le commit voulu.
# Appliquer un commit spécifique sur main
git checkout main
git cherry-pick abc1234
# Cherry-pick sans commit
git cherry-pick --no-commit abc1234Cas d'usage : Appliquer un hotfix de prod sur main sans merger toute la branche de release.
Pattern de résilience qui coupe les appels vers un service défaillant après N échecs. Évite la cascade de pannes. États : closed, open, half-open.
Un disjoncteur électrique : il coupe le courant automatiquement quand il détecte une surcharge pour protéger le reste.
const breaker = new CircuitBreaker(callExternalAPI, {
timeout: 3000,
errorThresholdPercentage: 50,
resetTimeout: 30000
});
breaker.fallback(() => cachedResponse);
const result = await breaker.fire(params);Cas d'usage : Protéger un service des cascades de pannes quand un service downstream est instable.
Plateforme serverless exécutant du JavaScript, TypeScript, Python ou WebAssembly sur le réseau mondial de Cloudflare. Chaque Worker tourne dans un isolat V8 (pas dans un conteneur ni une VM) : le runtime, open source sous le nom workerd, en exécute des centaines par processus, d'où des démarrages à froid de quelques millisecondes et une exécution au plus près de l'utilisateur.
Des employés déjà en poste dans chaque agence de quartier, plutôt qu'un intérimaire qu'on doit recruter et former (démarrer une VM) à chaque client.
// src/index.js – un Worker = un handler fetch
export default {
async fetch(request, env, ctx) {
const url = new URL(request.url);
if (url.pathname === '/api/geo') {
// request.cf : métadonnées du point de présence
return Response.json({ country: request.cf?.country });
}
const cached = await caches.default.match(request);
if (cached) return cached;
const res = await fetch(request); // origine
ctx.waitUntil(caches.default.put(request, res.clone()));
return res;
},
};Cas d'usage : Réécriture d'URL, authentification en bordure, tests A/B, cache d'API ou petit backend à latence minimale pour un public mondial.
Mode de développement de Docker Compose (section « develop.watch », disponible depuis Compose 2.22.0) qui surveille les fichiers locaux et, selon la règle, synchronise les fichiers dans le conteneur (action sync), redémarre le service (sync+restart) ou reconstruit l'image (rebuild). Il remplace les montages de volumes bricolés pour le rechargement à chaud.
Un assistant qui remet la bonne feuille dans le classeur dès que vous la modifiez, et qui ne réimprime tout le classeur que si la couverture change.
services:
api:
build: .
develop:
watch:
- action: sync # copie à chaud dans le conteneur
path: ./src
target: /app/src
- action: rebuild # nouvelle image si les deps changent
path: package.json
# docker compose up --watch (ou : docker compose watch)Cas d'usage : Boucle de développement rapide sur une API Node ou Python conteneurisée sans perdre la parité avec la production.
Objet Kubernetes stockant des données de configuration non sensibles sous forme clé-valeur. Injecté comme variable d'env ou fichier monté.
Un tableau d'affichage public dans un bureau : tout le monde peut lire les infos affichées.
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
NODE_ENV: production
LOG_LEVEL: infoCas d'usage : Externaliser la configuration pour pouvoir la changer sans reconstruire l'image.
Réutilisation d'un pool de connexions persistantes à la base de données au lieu d'en créer une nouvelle par requête. Réduit la latence et la charge.
Un parking de vélos partagés : tu prends un vélo disponible et tu le rends après, pas besoin d'en acheter un à chaque trajet.
const pool = new Pool({
host: 'db.example.com',
max: 20, // max connexions
idleTimeoutMillis: 30000
});
const result = await pool.query('SELECT ...');Cas d'usage : Éviter d'ouvrir/fermer des milliers de connexions par seconde, source de latence et crash.
Convention de messages de commit structurés (type(scope): description). Permet la génération automatique de changelogs et le versionnement sémantique.
Un formulaire standardisé : tout le monde remplit les mêmes champs, rendant le tri automatique possible.
feat(auth): add OAuth2 login
fix(api): handle null response body
chore(deps): update express to v5
BREAKING CHANGE: remove v1 endpointsCas d'usage : Automatiser le versionnement et le changelog dans le pipeline CI/CD.
Contrôleur garantissant qu'un Pod tourne sur chaque noeud du cluster (ou un sous-ensemble). Utilisé pour les agents système.
Un concierge par immeuble : chaque bâtiment (noeud) a exactement un concierge attitré.
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: log-agent
spec:
selector:
matchLabels: { app: log-agent }
template:
spec:
containers:
- name: agent
image: datadog/agent:latestCas d'usage : Déployer des agents de monitoring, collecte de logs ou réseau sur chaque noeud.
Moteur de CI/CD créé par Solomon Hykes (fondateur de Docker) : les pipelines s'écrivent comme des fonctions en Go, Python, TypeScript, Java, PHP ou Rust, s'exécutent dans des conteneurs avec cache de chaque opération, et tournent à l'identique en local et sur n'importe quelle CI. Lancé en version 0.2 le 30 mars 2022, le projet a annoncé en septembre 2026 une version 1.0 imminente et propose des moteurs managés (Cloud Engines).
Au lieu d'écrire la recette en pictogrammes propres à chaque cuisine (YAML GitHub, YAML GitLab…), vous l'écrivez une fois dans votre langue et un robot la cuisine partout.
// dagger/src/index.ts
import { dag, Container, Directory, object, func } from "@dagger.io/dagger";
@object()
class Ci {
@func()
test(source: Directory): Container {
return dag.container()
.from("node:24-alpine")
.withDirectory("/app", source)
.withWorkdir("/app")
.withExec(["npm", "ci"]) // chaque étape est cachée
.withExec(["npm", "test"]);
}
}
// dagger call test --source=. (même résultat en local et en CI)Cas d'usage : Pipelines complexes à tester en local avant de pousser, ou équipes qui veulent sortir du YAML spécifique à une plateforme CI.
Scripts versionnés et ordonnés pour modifier le schéma de base de données de manière incrémentale, reproductible et réversible.
Un journal des travaux dans un immeuble : chaque rénovation est documentée et peut être annulée.
// 001_create_users.sql
CREATE TABLE users (
id UUID PRIMARY KEY,
email VARCHAR(255) UNIQUE NOT NULL
);
-- npx prisma migrate dev
-- npx knex migrate:latestCas d'usage : Synchroniser le schéma de base entre tous les environnements de manière automatisée.
Queue spéciale recevant les messages qui ont échoué après plusieurs tentatives de traitement. Permet l'analyse post-mortem et le reprocessing.
Le bureau des objets trouvés de la poste : les lettres non distribuables y sont stockées pour investigation.
const queue = new Queue('payments', {
defaultJobOptions: {
attempts: 3,
backoff: { type: 'exponential', delay: 1000 },
removeOnFail: false
}
});
// Les jobs échoués vont dans la DLQCas d'usage : Ne pas perdre les messages critiques (paiements, commandes) malgré les erreurs.
Ressource Kubernetes déclarant l'état désiré des Pods (image, replicas, stratégie de mise à jour). Gère le rollout et le rollback.
Un contrat de maintenance : tu déclares combien d'employés tu veux et K8s s'assure que ce nombre est toujours respecté.
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
selector:
matchLabels: { app: api }
template:
spec:
containers:
- name: api
image: mon-app:1.0Cas d'usage : Déployer des applications stateless avec rolling updates et rollback automatique.
Suivi d'une requête à travers tous les services d'un système distribué grâce à un identifiant de trace unique ; chaque service ajoute un « span ». Le standard de fait est OpenTelemetry (projet CNCF) : sa spécification de traçâge est stable et couverte par un support long terme, et le protocole OTLP transporte traces, métriques et journaux.
Le suivi d'un colis : chaque entrepôt (service) scanne le code-barres (trace ID) et ajoute une étape.
// OpenTelemetry
const tracer = trace.getTracer('api');
app.use((req, res, next) => {
const span = tracer.startSpan('http.request');
span.setAttribute('http.method', req.method);
res.on('finish', () => span.end());
next();
});Cas d'usage : Identifier quel service cause la latence dans une chaîne de 10 microservices.
Images Docker minimalistes de Google ne contenant que l'application et ses dépendances runtime, sans shell ni gestionnaire de paquets.
Un coffre-fort scellé : impossible d'y entrer même si on essaie, ce qui le rend plus sûr.
FROM node:20 AS build
COPY . .
RUN npm ci && npm run build
FROM gcr.io/distroless/nodejs20
COPY --from=build /app/dist /app
CMD ["/app/server.js"]Cas d'usage : Réduire la surface d'attaque en production en éliminant tout outil exploitable.
Orchestrateur de builds d'images Docker, déclaré généralement disponible par Docker en février 2025 (Docker Desktop 4.38, plugin Buildx). Un fichier docker-bake.hcl (ou JSON/YAML) décrit des « targets » avec Dockerfile, arguments, plateformes, tags et attestations (SBOM, provenance) ; « docker buildx bake » construit plusieurs images, multi-plateformes, en parallèle, sans longues lignes de commande.
Ce que Compose fait pour l'exécution des conteneurs, Bake le fait pour leur fabrication : une seule fiche de production au lieu de dix commandes à retenir.
# docker-bake.hcl
group "default" { targets = ["api", "worker"] }
target "api" {
context = "."
dockerfile = "Dockerfile"
platforms = ["linux/amd64", "linux/arm64"]
tags = ["ghcr.io/acme/api:1.4.0"]
attest = ["type=sbom", "type=provenance,mode=max"]
}
target "worker" { inherits = ["api"], target = "worker" }
# docker buildx bake # construit tout le groupe
# docker buildx bake api --push # une cible, puis pushCas d'usage : Monorepo qui produit plusieurs images (API, worker, migrations) multi-architectures avec SBOM et provenance en CI.
Outil pour définir et orchestrer une application multi-conteneurs dans un fichier YAML (réseaux, volumes, dépendances). Depuis Compose V2, c'est un plugin du CLI Docker : on écrit « docker compose » (avec un espace) et non plus « docker-compose ». Docker a cessé de supporter Compose V1 après juin 2023 ; le champ « version: » en tête de fichier est obsolète et déclenche un avertissement.
Le chef d'orchestre qui dit à chaque musicien (conteneur) quand jouer et comment se synchroniser.
# compose.yaml (plus de champ version:)
services:
api:
build: .
ports: ["3000:3000"]
depends_on: [db]
db:
image: postgres:16
volumes: ["pgdata:/var/lib/postgresql/data"]
volumes:
pgdata: {}
# docker compose up -d (V2 = plugin du CLI docker)Cas d'usage : Environnement de développement local reproduisant la stack complète en une commande.
Instance exécutable d'une image Docker, isolée du système hôte grâce aux namespaces et cgroups Linux. Léger, démarrage en secondes.
Un appartement meublé dans un immeuble : chaque locataire (conteneur) a son espace privé mais partage les fondations (le kernel).
docker run -d --name api -p 3000:3000 mon-app:1.0
docker ps
docker logs api
docker exec -it api sh
docker stop api && docker rm apiCas d'usage : Exécuter des applications isolées avec des dépendances propres sans conflits système.
Template immuable contenant le code, les dépendances et la config nécessaires pour créer un conteneur. Construite couche par couche via un Dockerfile.
Un moule à gâteau : le moule (image) est toujours le même, mais chaque gâteau produit (conteneur) vit sa propre vie.
# Lister les images locales
docker images
# Télécharger une image
docker pull node:20-alpine
# Construire une image
docker build -t mon-app:1.0 .Cas d'usage : Base de tout déploiement conteneurisé, garantit la reproductibilité entre dev et prod.
Réseau virtuel isolé permettant la communication entre conteneurs. Bridge par défaut, overlay pour le multi-host.
Un réseau WiFi privé : seuls les appareils connectés au même réseau peuvent se parler.
docker network create mon-reseau
docker run --network mon-reseau --name api app
docker run --network mon-reseau --name db postgres
# api peut joindre db par son nomCas d'usage : Isoler les communications entre services tout en permettant la découverte par nom DNS.
Service de stockage et distribution d'images Docker. Docker Hub est le registry public par défaut, mais on peut héberger le sien.
Une bibliothèque de livres (images) où chacun peut emprunter (pull) ou déposer (push) des ouvrages.
docker tag mon-app:1.0 registry.io/mon-app:1.0
docker push registry.io/mon-app:1.0
docker pull registry.io/mon-app:1.0Cas d'usage : Stocker les images de manière centralisée pour que le CI/CD et tous les environnements y accèdent.
Outil d'analyse de sécurité intégré à Docker qui scanne les images pour détecter les vulnérabilités CVE dans les dépendances.
Un détecteur de métaux à l'entrée d'un aéroport : il scanne tout ce qui passe pour trouver les menaces.
docker scout cves mon-app:1.0
docker scout recommendations mon-app:1.0Cas d'usage : Intégrer le scan de vulnérabilités dans le pipeline CI pour bloquer les images dangereuses.
Mécanisme de persistance des données indépendant du cycle de vie du conteneur. Géré par Docker et monté dans le filesystem du conteneur.
Un disque dur externe : on le branche sur n'importe quel PC (conteneur) et les données restent.
docker volume create mydata
docker run -v mydata:/app/data mon-app
# Bind mount pour le dev
docker run -v $(pwd):/app mon-appCas d'usage : Persister les données de bases de données entre les redémarrages de conteneurs.
Fichier texte décrivant, instruction par instruction, la construction d'une image Docker ; chaque instruction crée une couche mise en cache. On part d'une image de base à jour : Node.js 24 est la ligne LTS active (support actif jusqu'au 20 octobre 2026), Node.js 26 sortie le 5 mai 2026 devient LTS le 28 octobre 2026, et Node.js 20 est en fin de vie le 30 avril 2026.
Une recette de cuisine étape par étape : chaque ligne ajoute un ingrédient ou une action au plat final.
# Node 24 = LTS active (endoflife.date)
FROM node:24-alpine
WORKDIR /app
# d'abord les manifestes : couche cachée tant que le lock ne change pas
COPY package*.json ./
RUN npm ci --omit=dev
# ensuite le code
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]Cas d'usage : Automatiser la construction d'images reproductibles pour le CI/CD.
Suite Elasticsearch + Logstash + Kibana pour la collecte, l'indexation et la visualisation des logs. Souvent remplacé par EFK (Fluentd) ou Loki.
Un système de classement automatique : Logstash trie le courrier, Elasticsearch le range, Kibana permet de chercher.
// Filebeat -> Logstash -> Elasticsearch
// Recherche dans Kibana :
// level:error AND service:api AND @timestamp > now-1hCas d'usage : Centraliser les logs de tous les services pour le debugging et l'audit.
Marge d'indisponibilité tolérée sur une période, déduite du SLO : avec un SLO de 99,9 % sur 30 jours, le budget d'erreur est d'environ 43 minutes. Formalisé par Google dans le livre « Site Reliability Engineering » (chapitre Embracing Risk), il arbitre objectivement entre vitesse et fiabilité : tant qu'il reste du budget, on déploie ; s'il est consommé, on gèle les fonctionnalités et on investit dans la stabilité.
L'argent de poche de la fiabilité : on peut le dépenser en déploiements risqués, mais quand le porte-monnaie est vide, plus de sorties jusqu'au mois prochain.
// Budget d'erreur mensuel à partir du SLO
const slo = 0.999; // 99,9 % de requêtes réussies
const totalRequests = 12_000_000; // sur 30 jours
const budget = totalRequests * (1 - slo); // 12 000 erreurs autorisées
const errorsSoFar = 9_800;
const remaining = budget - errorsSoFar; // 2 200
const burnRate = errorsSoFar / (budget * (daysElapsed / 30));
// burnRate > 1 : on consomme plus vite que prévu → alerte,
// on gèle les mises en production non critiques.Cas d'usage : Décider, avec des chiffres partagés entre développeurs et SRE, si l'on peut sortir une fonctionnalité risquée cette semaine.
Modèle de cohérence où les répliques convergent vers le même état après un délai, sans garantie de lecture immédiate de la dernière écriture.
Mettre à jour son adresse à la poste : tous les facteurs finiront par avoir la nouvelle adresse, mais pas tous en même temps.
// Écriture confirmée sur le primaire
await dynamo.put({ TableName: 'users', Item: user });
// Lecture éventuellement consistante (plus rapide)
await dynamo.get({ ConsistentRead: false, ... });
// Lecture fortement consistante (plus lente)
await dynamo.get({ ConsistentRead: true, ... });Cas d'usage : Systèmes distribués géographiquement où la latence réseau empêche la cohérence forte.
Toggle permettant d'activer/désactiver une fonctionnalité sans redéployer. Permet le trunk-based development et le progressive rollout.
Un interrupteur sur ton tableau électrique : tu allumes ou éteins une pièce (feature) sans toucher à la maison.
if (featureFlags.isEnabled('new-checkout', { userId })) {
return <NewCheckout />;
}
return <OldCheckout />;Cas d'usage : Déployer du code inactif en prod et l'activer progressivement par audience.
Pratique qui rend les équipes techniques responsables du coût cloud : mesurer, attribuer (tags, centres de coût), optimiser (dimensionnement, instances réservées ou spot, arrêt des environnements inutilisés) et arbitrer coût contre vitesse. La FinOps Foundation (Linux Foundation) publie la spécification FOCUS qui normalise les fichiers de facturation des fournisseurs ; la version 1.2, ratifiée le 29 mai 2025, couvre aussi le SaaS et les monnaies multiples.
Le compteur électrique par pièce : quand chaque colocataire voit ce qu'il consomme, la lumière du couloir ne reste plus allumée toute la nuit.
-- Facture normalisée FOCUS : mêmes colonnes quel que soit le cloud
SELECT
ServiceName,
Tags['team'] AS team,
SUM(EffectiveCost) AS cout_effectif -- remises incluses
FROM billing_focus
WHERE ChargePeriodStart >= DATE '2026-09-01'
AND ChargePeriodStart < DATE '2026-10-01'
GROUP BY ServiceName, team
ORDER BY cout_effectif DESC
LIMIT 20; -- les 20 postes à optimiser en premierCas d'usage : Facture cloud qui grimpe sans que personne ne sache quelle équipe ou quel service la génère.
Successeur officiel de la ressource Ingress pour le trafic entrant dans Kubernetes, porté par SIG Network. Il sépare les rôles : GatewayClass (l'implémentation, gérée par l'infra), Gateway (le point d'entrée, géré par la plateforme) et HTTPRoute/TLSRoute/GRPCRoute (les règles, gérées par les équipes applicatives). GA depuis la v1.0 du 31 octobre 2023 ; la v1.5 du 27 février 2026 stabilise notamment TLSRoute et le mTLS côté client. Le retrait d'Ingress NGINX en mars 2026 en fait la cible de migration recommandée.
Ingress, c'était un portier unique qui gérait tout avec des post-it (annotations). Gateway API, c'est un hall d'accueil avec un plan officiel : le propriétaire installe la porte, chaque équipe affiche ses propres panneaux.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: api
spec:
parentRefs:
- name: public-gw # Gateway gérée par la plateforme
hostnames: ["api.example.com"]
rules:
- matches:
- path: { type: PathPrefix, value: /v2 }
backendRefs:
- { name: api-v2, port: 80, weight: 90 } # canary 90 % / 10 %
- { name: api-v3, port: 80, weight: 10 }Cas d'usage : Remplacer un Ingress NGINX retiré, faire du canary par poids, du routage par en-tête, ou exposer du gRPC/TLS sans annotations spécifiques au contrôleur.
Outil de recherche dichotomique dans l'historique Git pour identifier le commit ayant introduit un bug. Logarithmique en complexité.
Chercher une page dans un dictionnaire en ouvrant au milieu et en éliminant une moitié à chaque fois.
git bisect start
git bisect bad # commit actuel est bugué
git bisect good v1.0.0 # cette version marchait
# Git checkout un commit, tu testes, puis :
git bisect good # ou bad
git bisect resetCas d'usage : Trouver en quelques minutes parmi 1000 commits lequel a introduit une régression.
Scripts exécutés automatiquement lors d'événements Git (pre-commit, pre-push, commit-msg). Permettent d'automatiser les vérifications.
Un videur à l'entrée d'un club : il vérifie que tu respectes le dress code avant de te laisser entrer.
#!/bin/sh
# .git/hooks/pre-commit
npm run lint
npm run test:unitCas d'usage : Bloquer les commits qui ne passent pas le lint ou les tests unitaires.
Extension Git pour gérer les fichiers volumineux (images, vidéos, modèles ML). Stocke des pointeurs dans Git et les fichiers sur un serveur dédié.
Au lieu de stocker les meubles chez toi, tu gardes un ticket de consigne et les meubles sont dans un garde-meuble.
git lfs install
git lfs track "*.psd"
git add .gitattributes
git add design.psd
git commit -m "add design file"Cas d'usage : Versionner des assets binaires volumineux sans exploser la taille du dépôt Git.
Journal local de tous les déplacements de HEAD et des refs. Permet de retrouver des commits perdus après un reset, rebase ou drop.
L'historique de navigation de ton navigateur : même si tu fermes un onglet, tu peux retrouver la page.
git reflog
# abc1234 HEAD@{0}: reset: moving to HEAD~3
# def5678 HEAD@{1}: commit: feat: add auth
git checkout def5678 # récupérer le commit perduCas d'usage : Récupérer un commit perdu après un rebase raté ou un reset --hard accidentel.
Met de côté temporairement les modifications en cours sans les commiter. Permet de changer de branche proprement.
Mettre son travail dans un tiroir pour libérer son bureau, puis le ressortir plus tard.
git stash
git checkout hotfix-branch
# ... travail sur le hotfix
git checkout feature-branch
git stash popCas d'usage : Sauvegarder rapidement du travail en cours pour traiter une urgence sur une autre branche.
Plateforme CI/CD intégrée à GitHub : des workflows YAML dans .github/workflows, déclenchés par des événements du dépôt. Le runtime des actions JavaScript bascule sur Node.js 24 : Node 24 est le défaut depuis le 16 juin 2026 et Node 20 est retiré des runners le 23 septembre 2026, d'où la nécessité de mettre à jour les actions (actions/checkout@v5, etc.).
Un assistant personnel intégré à ton bureau (GitHub) qui exécute automatiquement tes instructions.
name: CI
on:
pull_request:
branches: [main]
permissions:
contents: read
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5 # version Node 24
- uses: actions/setup-node@v5
with: { node-version: 24, cache: npm }
- run: npm ci && npm testCas d'usage : CI/CD natif pour les projets hébergés sur GitHub, gratuit pour l'open source.
Mécanisme par lequel un job GitHub Actions obtient un jeton OpenID Connect éphémère signé par GitHub, échangé ensuite contre des identifiants temporaires chez AWS, GCP, Azuré ou Vault. Il faut la permission « id-token: write » (qui ne donne aucun droit d'écriture sur le dépôt, uniquement le droit de demander le jeton) et une relation de confiance côté cloud qui filtre sur le dépôt, la branche ou l'environnement.
Un badge visiteur imprimé à l'accueil pour la journée, avec votre nom et le service visité, plutôt qu'un passe permanent qui traîne dans un tiroir.
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write # autorise la demande du jeton OIDC
contents: read
steps:
- uses: actions/checkout@v5
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
aws-region: eu-west-3
# plus aucun AWS_SECRET_ACCESS_KEY stocké dans les secrets
- run: aws s3 sync ./dist s3://mon-site-prodCas d'usage : Déployer depuis GitHub Actions vers un cloud sans stocker de clés d'accès longue durée dans les secrets du dépôt.
Système CI/CD intégré à GitLab, configuré via .gitlab-ci.yml. Supporte les pipelines multi-stages, les environnements et le Auto DevOps.
Une usine intégrée à l'entrepôt (GitLab) : tout se fait sous le même toit.
stages: [build, test, deploy]
build:
stage: build
script: npm run build
artifacts:
paths: [dist/]Cas d'usage : Pipeline CI/CD tout-en-un pour les organisations utilisant GitLab comme forge.
Méthode d'exploitation où l'état désiré de l'infrastructure et des déploiements est décrit de façon déclarative dans Git, seule source de vérité ; un agent (Argo CD, Flux) réconcilie en continu l'état réel du cluster avec le dépôt. Un déploiement devient une pull request, un retour arrière un « gît revert », et toute dérive manuelle est détectée et corrigée.
Le thermostat de la maison : vous écrivez la température voulue, l'appareil compare en boucle avec la réalité et corrige, sans que personne n'aille toucher la chaudière à la main.
# Le dépôt décrit l'état désiré ; l'agent (ex. Argo CD) l'applique.
# apps/prod/api/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base/api
images:
- name: ghcr.io/acme/api
newTag: "1.4.0" # déployer = changer ce tag via une PR
# Retour arrière : git revert <sha> ; l'agent resynchronise.Cas d'usage : Plusieurs clusters ou environnements à garder cohérents, audit des changements exigé, et fin des « kubectl apply » lancés depuis un poste.
Capacité d'un système à continuer de fonctionner avec des fonctionnalités réduites quand un composant est en panne, plutôt que de tomber entièrement.
Un restaurant dont le four tombe en panne : il sert des plats froids plutôt que de fermer complètement.
async function getRecommendations(userId) {
try {
return await recommendationService.get(userId);
} catch (e) {
logger.warn('Reco service down, fallback');
return getPopularItems(); // fallback
}
}Cas d'usage : Maintenir le service principal même quand des services secondaires (recommandations, analytics) sont en panne.
Endpoint HTTP renvoyant l'état de santé d'un service et ses dépendances (DB, cache, APIs). Utilisé par les load balancers et orchestrateurs.
Le check-up médical annuel : vérifier que le coeur (DB), les poumons (cache) et le cerveau (API) fonctionnent.
app.get('/health', async (req, res) => {
const dbOk = await db.ping().catch(() => false);
const redisOk = await redis.ping().catch(() => false);
const status = dbOk && redisOk ? 200 : 503;
res.status(status).json({ db: dbOk, redis: redisOk });
});Cas d'usage : Permettre au load balancer de retirer automatiquement les instances défaillantes.
Gestionnaire de packages Kubernetes. Un Chart est un bundle de templates YAML paramétrables pour déployer une application complète.
Un kit IKEA avec notice : tout est emballé ensemble avec des instructions configurables.
helm repo add bitnami https://charts.bitnami.com
helm install my-db bitnami/postgresql \
--set auth.postgresPassword=secret \
--namespace stagingCas d'usage : Standardiser et versionner les déploiements Kubernetes avec des valeurs par environnement.
Vertical = plus de CPU/RAM sur une machine. Horizontal = plus de machines. Le horizontal est quasi illimité mais nécessite des apps stateless.
Vertical = acheter un plus gros camion. Horizontal = acheter plus de camions.
# Vertical : upgrader l'instance
aws ec2 modify-instance --type m5.2xlarge
# Horizontal : ajouter des instances
kubectl scale deployment api --replicas=10Cas d'usage : Horizontal scaling pour les apps stateless derrière un load balancer.
Ressource qui ajuste automatiquement le nombre de réplicas d'un Deployment selon des métriques (CPU, mémoire, custom metrics).
Un manager qui embauche des intérimaires quand l'affluence augmente et les libère quand ça se calme.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
scaleTargetRef:
kind: Deployment
name: api
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource: { name: cpu, target: { averageUtilization: 70 } }Cas d'usage : Adapter automatiquement la capacité aux pics de trafic sans surprovisionnement permanent.
Outil npm pour gérer facilement les Git hooks dans un projet. Configure les hooks via le package.json ou des fichiers dédiés.
Un système de sécurité automatique : une fois installé, il se déclenche tout seul à chaque commit.
npx husky init
# .husky/pre-commit
npx lint-stagedCas d'usage : Garantir que tous les membres de l'équipe exécutent les mêmes vérifications avant chaque commit.
Service de gestion des identités et des permissions cloud. Définit qui peut faire quoi sur quelles ressources via des policies JSON.
Le système de badges d'une entreprise : chaque badge (role) ouvre certaines portes (permissions) et pas d'autres.
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::my-bucket/*"
}Cas d'usage : Appliquer le principe du moindre privilège pour chaque service et utilisateur.
Pattern garantissant qu'un message traité plusieurs fois produit le même résultat. Essentiel avec les systèmes at-least-once delivery.
Appuyer 10 fois sur le bouton d'un ascenseur ne l'appelle pas 10 fois.
async function processPayment(msg) {
const exists = await db.findOne({ idempotencyKey: msg.id });
if (exists) return; // déjà traité
await db.insert({ idempotencyKey: msg.id });
await chargeCustomer(msg.data);
}Cas d'usage : Éviter les doubles paiements ou doubles envois dans un système distribué.
Structures de données accélérant les recherches en base. B-tree pour les ranges, Hash pour l'égalité, Composite pour les requêtes multi-colonnes.
L'index d'un livre : au lieu de lire toutes les pages, tu vas directement au bon chapitre.
-- B-tree (par défaut, ranges)
CREATE INDEX idx_users_email ON users(email);
-- Composite
CREATE INDEX idx_orders_user_date
ON orders(user_id, created_at);
-- Covering
CREATE INDEX idx_cover ON orders(user_id)
INCLUDE (total, status);Cas d'usage : Passer une requête de 2 secondes à 2 millisecondes sur une table de millions de lignes.
Ressource Kubernetes historique pour exposer des Services en HTTP/HTTPS (routage par hôte et chemin, TLS). Le contrôleur le plus répandu, Ingress NGINX, a été retiré par le projet Kubernetes en mars 2026 : plus de versions, plus de correctifs de sécurité. La voie recommandée est la Gateway API (GatewayClass, Gateway, HTTPRoute), l'outil ingress2gateway aidant la migration.
Le portier d'un hôtel : il dirige chaque visiteur vers la bonne chambre (service) selon sa réservation (URL).
# Ingress classique (toujours valide, mais Ingress NGINX est retiré)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api
spec:
ingressClassName: traefik # choisir un contrôleur maintenu
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service: { name: api-svc, port: { number: 80 } }Cas d'usage : Point d'entrée unique HTTPS pour router le trafic vers plusieurs services backend.
Mode rebase permettant de réorganiser, squasher, modifier ou supprimer des commits avant de les publier. Nettoie l'historique.
Réécrire un brouillon : tu réorganises les paragraphes et corriges les fautes avant de publier.
git rebase -i HEAD~3
# pick abc1234 feat: add login
# squash def5678 fix: typo
# reword ghi9012 feat: add logoutCas d'usage : Nettoyer une série de commits WIP en un historique cohérent avant la code review.
Unité de travail dans un pipeline CI/CD, exécutée dans un runner/agent isolé. Plusieurs jobs peuvent tourner en parallèle dans un même stage.
Un employé qui fait une tâche précise sur la chaîne de montage.
jobs:
lint:
runs-on: ubuntu-latest
steps: [{ run: 'npm run lint' }]
test:
runs-on: ubuntu-latest
steps: [{ run: 'npm test' }]Cas d'usage : Paralléliser lint, tests unitaires et tests e2e pour accélérer le feedback.
Job exécute un Pod jusqu'à complétion. CronJob planifie des Jobs selon une expression cron. Pour les tâches batch et récurrentes.
Job = un plombier appelé pour une réparation unique. CronJob = le passage hebdomadaire du jardinier.
apiVersion: batch/v1
kind: CronJob
metadata:
name: daily-backup
spec:
schedule: "0 2 * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: backup
image: backup-tool:1.0Cas d'usage : Backups planifiés, nettoyage de données, envoi de rapports périodiques.
Mécanisme de cache Docker où chaque instruction Dockerfile crée un layer réutilisable. Si un layer change, tous les suivants sont reconstruits.
Un château de cartes : si tu modifies une carte en bas, tout ce qui est au-dessus tombe et doit être reconstruit.
# Bon ordre pour le cache
COPY package*.json ./
RUN npm ci
# Code copié APRÈS les dépendances
COPY . .Cas d'usage : Réduire le temps de build CI de minutes à secondes en exploitant le cache des dépendances.
Outil qui exécute des linters uniquement sur les fichiers staged (gît add). Évite de linter tout le projet à chaque commit.
Un contrôle qualité qui ne vérifie que les nouveaux produits, pas tout l'entrepôt.
// package.json
"lint-staged": {
"*.{ts,tsx}": ["eslint --fix", "prettier --write"],
"*.css": ["stylelint --fix"]
}Cas d'usage : Accélérer les pre-commit hooks en ne traitant que les fichiers modifiés.
Composant réseau distribuant le trafic entrant entre plusieurs instances d'un service. Algorithmes : round-robin, least connections, IP hash.
L'hôtesse d'accueil d'un restaurant qui répartit les clients entre les tables disponibles.
# Nginx load balancer
upstream api {
least_conn;
server api1:3000;
server api2:3000;
server api3:3000;
}
server {
location / { proxy_pass http://api; }
}Cas d'usage : Distribuer le trafic uniformément et assurer la haute disponibilité.
Logs au format JSON structuré avec des champs standardisés (timestamp, level, message, context). Facilite le parsing et la recherche.
Un rapport de police avec des champs standardisés vs un texte libre : le premier est triable et cherchable.
import pino from 'pino';
const logger = pino({ level: 'info' });
logger.info({ userId: '123', action: 'login', duration: 42 },
'User logged in successfully'
);Cas d'usage : Débugger en production en cherchant par userId, requestId ou level dans un outil comme ELK.
Message broker (RabbitMQ) : routage push vers des consommateurs, message supprimé après consommation. Event broker (Kafka) : log append-only, multiple consumers, replay possible.
Message broker = courrier postal (une lettre, un destinataire). Event broker = journal télévisé (tout le monde peut regarder et revoir).
// Message broker : un consumer traite le message
// -> RabbitMQ, BullMQ
// Event broker : N consumers lisent le même event
// -> Kafka, Redis StreamsCas d'usage : Message broker pour les tâches (1 worker). Event broker pour les événements (N consumers).
Données numériques agrégées mesurant la performance d'un système (latence, throughput, error rate, saturation). Les 4 golden signals de Google.
Le tableau de bord d'une voiture : vitesse, température, niveau d'essence en un coup d'oeil.
// Prometheus client
const httpDuration = new Histogram({
name: 'http_request_duration_seconds',
help: 'Duration of HTTP requests',
labelNames: ['method', 'route', 'status']
});
app.use((req, res, next) => {
const end = httpDuration.startTimer();
res.on('finish', () => end({ method: req.method }));
});Cas d'usage : Alerter quand la latence p99 dépasse le SLO ou quand le taux d'erreur augmente.
Stratégie de dépôt unique contenant plusieurs projets/packages. Outils comme Nx, Turborepo ou Lerna gèrent les dépendances et les builds.
Un centre commercial : tous les magasins (projets) sous le même toit avec des infrastructures partagées.
// turbo.json (Turborepo 2 : la clé "pipeline" est devenue "tasks")
{
"$schema": "https://turborepo.dev/schema.json",
"tasks": {
"build": { "dependsOn": ["^build"], "outputs": ["dist/**"] },
"test": { "dependsOn": ["build"] }
}
}Cas d'usage : Partager du code entre frontend, backend et libs avec des dépendances atomiques.
Technique Dockerfile utilisant plusieurs FROM pour séparer build et runtime. L'image finale ne contient que les artefacts nécessaires.
Construire un meuble en atelier puis ne livrer que le meuble fini, pas les outils ni les copeaux.
FROM node:20 AS build
WORKDIR /app
COPY . .
RUN npm ci && npm run build
FROM node:20-alpine
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]Cas d'usage : Réduire la taille des images de production de 1 Go à moins de 100 Mo.
Partition logique d'un cluster Kubernetes pour isoler les ressources entre équipes ou environnements. Permet des quotas et des RBAC distincts.
Les étages d'un immeuble de bureaux : chaque équipe a son étage avec ses propres règles d'accès.
kubectl create namespace staging
kubectl get pods -n staging
kubectl apply -f deploy.yaml -n stagingCas d'usage : Séparer dev, staging et prod sur le même cluster avec des quotas de ressources.
Standard ouvert de la CNCF pour l'observabilité : API, SDK, protocole OTLP et Collector pour produire et acheminer traces, métriques et journaux vers n'importe quel backend (Grafana, Datadog, Jaeger…). Le statut officiel de la spécification indique que le traçâge est stable avec support long terme, que les journaux sont stables et que le modèle de données des métriques est stable dans OTLP.
La prise électrique normalisée : quel que soit l'appareil (service) et quel que soit le fournisseur d'énergie (backend), tout se branche sans adaptateur.
// instrumentation.js – chargé avant l'app (node --import ./instrumentation.js)
import { NodeSDK } from '@opentelemetry/sdk-node';
import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
const sdk = new NodeSDK({
serviceName: 'api',
traceExporter: new OTLPTraceExporter({ url: 'http://otel-collector:4318/v1/traces' }),
instrumentations: [getNodeAutoInstrumentations()], // http, pg, redis... auto-tracés
});
sdk.start();Cas d'usage : Instrumenter une fois ses services et rester libre de changer d'outil d'observabilité sans retoucher le code.
Fork communautaire de Terraform sous licence MPL 2.0, créé après le passage de Terraform à la licence BSL en août 2023 et accueilli par la Linux Foundation le 20 septembre 2023, puis accepté en sandbox CNCF le 23 avril 2025. Compatible avec le langage HCL et les providers, il ajoute ses propres fonctionnalités : chiffrement de l'état, valeurs éphémères et méta-argument « enabled » dans la version 1.11.0 du 9 décembre 2025.
Une recette de cuisine libre de droits recopiée le jour où l'auteur original a mis un cadenas sur son livre : mêmes ingrédients, mais on peut continuer à l'améliorer ensemble.
# Même syntaxe HCL, binaire « tofu »
resource "aws_s3_bucket" "logs" {
bucket = "mon-app-logs"
enabled = var.env == "prod" # méta-argument enabled (OpenTofu 1.11)
}
# Cycle identique à Terraform
# tofu init
# tofu plan
# tofu applyCas d'usage : Équipes qui veulent un outil IaC réellement open source ou qui craignent la clause d'usage de la BSL (produits concurrents d'HCP).
Panneaux open source qui donnent une expérience « à la Heroku » sur son propre VPS : connexion Git, build (Dockerfile, Nixpacks, Compose), HTTPS automatique, bases de données, sauvegardes. Coolify (PHP/Laravel, licence Apache 2.0) est le plus mature et riche en applications prêtes à l'emploi ; Dokploy (TypeScript, Docker Swarm natif, cœur Apache 2.0 avec un dossier sous licence source-available) est plus léger et orienté Docker.
Acheter la machine à café professionnelle pour le bureau au lieu de payer chaque capsule au prix fort : un peu d'installation, puis une fraction du coût.
# Installer Coolify sur un VPS Debian/Ubuntu neuf (root)
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash
# → interface web sur http://<ip>:8000, puis :
# 1. connecter le dépôt Git (GitHub App / clé de déploiement)
# 2. choisir le build : Dockerfile, Nixpacks ou docker-compose
# 3. domaine + HTTPS Let's Encrypt automatiques
# 4. variables d'environnement, base Postgres managée, backups S3
# Alternative Docker Swarm / TypeScript :
curl -sSL https://dokploy.com/install.sh | shCas d'usage : Indépendant ou petite équipe qui veut héberger dix projets (Next, Nest, WordPress, n8n) sur un VPS à 20 € sans devenir administrateur Kubernetes.
Suite automatisée d'étapes (build, test, deploy) déclenchée par un événement (push, PR). CI = intégration continue, CD = déploiement/livraison continue.
Une chaîne de montage automobile : chaque poste vérifie et ajoute quelque chose avant le contrôle final.
# GitHub Actions
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
- run: npm run buildCas d'usage : Automatiser les tests et le déploiement à chaque commit pour livrer plus vite et plus sûrement.
Discipline qui construit et exploite une plateforme interne (Internal Developer Platform) offrant en libre-service aux équipes produit ce dont elles ont besoin : environnements, pipelines, observabilité, bases de données. L'équipe plateforme agit comme un fournisseur interne qui réduit la charge cognitive des développeurs (modèle Team Topologies). Gartner prévoyait que 80 % des grandes organisations auraient une équipe plateforme d'ici 2026 ; Backstage (Spotify, CNCF) est le portail développeur le plus répandu.
Plutôt que chaque restaurant construise sa propre centrale électrique, une régie fournit l'électricité, l'eau et le gaz : les cuisiniers cuisinent.
# Backstage : catalog-info.yaml déclaré à côté du code
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: api-commandes
annotations:
github.com/project-slug: acme/api-commandes
backstage.io/techdocs-ref: dir:.
spec:
type: service
lifecycle: production
owner: team-paiement
dependsOn: [resource:postgres-commandes]
# Le portail agrège doc, pipelines, alertes, SLO, propriétaires…Cas d'usage : Organisation de plusieurs dizaines d'équipes où chacune réinvente son CI, son Terraform et son monitoring.
Plus petite unité déployable dans Kubernetes, regroupant un ou plusieurs conteneurs partageant réseau et stockage. Éphémère par nature.
Une cabine de bateau partagée : les occupants (conteneurs) partagent la même adresse (IP) et le même espace de rangement.
apiVersion: v1
kind: Pod
metadata:
name: mon-api
spec:
containers:
- name: api
image: mon-app:1.0
ports:
- containerPort: 3000Cas d'usage : Unité de base gérée par les Deployments, jamais créée directement en prod.
Vérifications de santé Kubernetes. Liveness redémarre les Pods bloqués, Readiness retire du trafic les Pods non prêts, Startup gère les démarrages lents.
Liveness = vérifier que quelqu'un respire. Readiness = vérifier qu'il est habillé et prêt à travailler.
livenessProbe:
httpGet: { path: /health, port: 3000 }
periodSeconds: 10
readinessProbe:
httpGet: { path: /ready, port: 3000 }
initialDelaySeconds: 5Cas d'usage : Éviter d'envoyer du trafic à des Pods en cours de démarrage ou bloqués.
Outil IaC utilisant des langages de programmation réels (TypeScript, Python, Go) au lieu d'un DSL. Même concept que Terraform mais avec du vrai code.
Terraform te donne un formulaire à remplir, Pulumi te laisse écrire une lettre dans ta propre langue.
import * as aws from '@pulumi/aws';
const bucket = new aws.s3.Bucket('my-bucket', {
website: { indexDocument: 'index.html' }
});
export const url = bucket.websiteEndpoint;Cas d'usage : Équipes de devs préférant TypeScript/Python au HCL pour gérer l'infrastructure.
PersistentVolume (PV) est un stockage provisionné dans le cluster. PersistentVolumeClaim (PVC) est une demande de stockage par un Pod.
PV = un entrepôt disponible. PVC = le bon de commande pour réserver de l'espace dans cet entrepôt.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: db-storage
spec:
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 20GiCas d'usage : Fournir du stockage persistant aux bases de données dans Kubernetes.
Message broker AMQP pour la communication asynchrone entre services. Supporte les queues, exchanges, routing et dead letter queues.
Un bureau de poste : il reçoit les lettres (messages), les trie et les distribue dans les bonnes boîtes aux lettres (queues).
// Publisher
channel.publish('orders', 'order.created',
Buffer.from(JSON.stringify(order)));
// Consumer
channel.consume('order-processing', (msg) => {
const order = JSON.parse(msg.content);
processOrder(order);
channel.ack(msg);
});Cas d'usage : Découpler les services pour absorber les pics de charge sans perdre de messages.
Mécanisme limitant le nombre de requêtes par client/IP sur une période donnée. Protège contre les abus, DDoS et la surcharge.
Le nombre maximum de cafés qu'une machine peut servir par minute : au-delà, il faut attendre.
// express-rate-limit
const limiter = rateLimit({
windowMs: 15 * 60 * 1000,
max: 100,
message: 'Too many requests'
});
app.use('/api', limiter);Cas d'usage : Protéger les APIs publiques contre les abus et garantir un service équitable.
Copie en lecture seule d'une base de données primaire, répliquée de manière asynchrone. Distribue la charge des requêtes SELECT.
Des copies d'un même livre dans une bibliothèque : plusieurs lecteurs peuvent lire simultanément.
// Routing des requêtes
const db = query.isRead
? replicaPool.connect()
: primaryPool.connect();
await db.query(query.sql);Cas d'usage : Absorber le trafic de lecture (rapports, dashboards) sans surcharger la base primaire.
Merge crée un commit de fusion préservant l'historique. Rebase rejoue les commits sur la branche cible pour un historique linéaire.
Merge = coller deux routes avec un carrefour. Rebase = redessiner une route pour qu'elle continue tout droit.
# Merge : préserve l'historique
git merge feature/login
# Rebase : historique linéaire
git checkout feature/login
git rebase main
git checkout main && git merge feature/loginCas d'usage : Rebase pour un historique propre sur les feature branches, merge pour les branches partagées.
Base de données clé-valeur en mémoire, ultra-rapide. Supporte strings, hashes, lists, sets, streams. Utilisé comme cache, broker, et store de sessions.
Un post-it géant ultra-rapide : tu écris, tu lis, c'est instantané, mais ça tient en mémoire.
await redis.set('session:abc', JSON.stringify(user), 'EX', 3600);
const session = await redis.get('session:abc');
await redis.del('session:abc');Cas d'usage : Cache applicatif, sessions, rate limiting, queues (BullMQ), leaderboards.
Système de messagerie fire-and-forget de Redis. Les publishers envoient sur des channels, les subscribers écoûtent en temps réel. Pas de persistance.
Une radio en direct : si tu n'es pas branché au moment de la diffusion, tu rates le message.
// Publisher
await redis.publish('notifications', JSON.stringify(notif));
// Subscriber
const sub = redis.duplicate();
await sub.subscribe('notifications', (msg) => {
console.log(JSON.parse(msg));
});Cas d'usage : Notifications temps réel, invalidation de cache distribuée entre instances.
Contrôleur Kubernetes garantissant qu'un nombre spécifié de réplicas de Pods sont en cours d'exécution. Géré automatiquement par un Deployment.
Un thermostat : il maintient toujours la température (nombre de Pods) au niveau configuré.
# Géré via Deployment, rarement créé directement
kubectl get replicasets
kubectl scale deployment api --replicas=5Cas d'usage : Assurer la haute disponibilité en maintenant le nombre de Pods désiré.
Stratégie de retry augmentant le délai exponentiellement entre chaque tentative (1s, 2s, 4s, 8s...) avec jitter aléatoire pour éviter le thundering herd.
Rappeler quelqu'un qui ne répond pas : attendre 1 min, puis 5 min, puis 15 min au lieu de spammer.
async function retryWithBackoff(fn, maxRetries = 3) {
for (let i = 0; i < maxRetries; i++) {
try { return await fn(); }
catch (e) {
const delay = Math.pow(2, i) * 1000 + Math.random() * 1000;
await sleep(delay);
}
}
throw new Error('Max retries exceeded');
}Cas d'usage : Appels réseau vers des services externes pouvant avoir des indisponibilités temporaires.
Serveur intermédiaire recevant les requêtes client et les transférant aux serveurs backend. Gère TLS, caching, compression, et sécurité.
Un secrétaire qui filtre les appels, prend les messages et redirigé vers le bon interlocuteur.
# Nginx reverse proxy
server {
listen 443 ssl;
location /api { proxy_pass http://backend:3000; }
location / { root /var/www/html; }
}Cas d'usage : Point d'entrée unique HTTPS devant les services backend, avec caching et rate limiting.
Stratégie de mise à jour remplaçant les instances une par une. À tout moment, un mix de l'ancienne et nouvelle version tourne. Stratégie par défaut de Kubernetes.
Changer les pneus d'un camion un par un pendant qu'il roule, au lieu de tout changer d'un coup à l'arrêt.
# Kubernetes rolling update (défaut)
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0Cas d'usage : Mise à jour standard des Deployments Kubernetes sans interruption de service.
Service de stockage objet cloud d'AWS. Stockage illimité, hautement durable (99.999999999%), accessible par API HTTP. Standard de facto du stockage cloud.
Un entrepôt infini avec une adresse URL pour chaque objet stocké.
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
const s3 = new S3Client({ region: 'eu-west-1' });
await s3.send(new PutObjectCommand({
Bucket: 'my-bucket',
Key: 'uploads/photo.jpg',
Body: fileBuffer
}));Cas d'usage : Stocker fichiers uploadés, backups, assets statiques, data lake.
Inventaire formel de tous les composants d'un logiciel (paquets, versions, licences, empreintes), au format machine. Deux standards dominent : CycloneDX, de l'OWASP, normalisé ECMA-424 (1.6 en juin 2024, 1.7 en décembre 2025), et SPDX, de la Linux Foundation, normalisé ISO/IEC 5962:2021. Il permet de savoir en minutes si l'on est touché par une vulnérabilité de dépendance, et répond à la catégorie A03:2025 « Software Supply Chain Failures » de l'OWASP.
La liste des ingrédients sur un emballage : en cas de rappel d'un lot de farine, on sait immédiatement quels gâteaux retirer des rayons.
# Générer un SBOM CycloneDX à partir du lockfile npm
npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json
# Ou depuis une image Docker (Syft), au format SPDX
syft ghcr.io/acme/api:1.4.0 -o spdx-json > sbom.spdx.json
# Docker Buildx peut attacher le SBOM à l'image
docker buildx build --sbom=true -t ghcr.io/acme/api:1.4.0 --push .
# Scanner le SBOM contre les CVE connues (Grype)
grype sbom:sbom.cdx.json --fail-on highCas d'usage : Réagir vite à une CVE type Log4Shell, répondre aux exigences clients ou réglementaires, alimenter le scan de vulnérabilités en CI.
Objet Kubernetes pour stocker des données sensibles (mots de passe, tokens, clés). Encodé en base64, pas chiffré par défaut.
Un coffre-fort au bureau : accès restreint, mais si la porte est ouverte tout le monde peut lire.
apiVersion: v1
kind: Secret
metadata:
name: db-creds
type: Opaque
data:
password: cGFzc3dvcmQxMjM=Cas d'usage : Injecter des credentials de base de données ou des clés API dans les Pods.
Firewall virtuel au niveau instance contrôlant le trafic entrant (inbound) et sortant (outbound) par port, protocole et source/destination.
Le vigile d'un immeuble avec une liste d'invités : seuls ceux sur la liste (règles) peuvent entrer par la bonne porte (port).
resource "aws_security_group" "api" {
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}Cas d'usage : Restreindre l'accès aux bases de données uniquement depuis les serveurs applicatifs.
Convention de versionnement MAJOR.MINOR.PATCH. Major = breaking change, Minor = nouvelle feature rétrocompatible, Patch = correction de bug.
L'adresse d'un immeuble : numéro de rue (major), étage (minor), numéro d'appartement (patch).
// 1.0.0 -> 1.0.1 (bugfix)
// 1.0.1 -> 1.1.0 (new feature)
// 1.1.0 -> 2.0.0 (breaking change)
npm version patch // 1.0.0 -> 1.0.1
npm version minor // 1.0.1 -> 1.1.0
npm version major // 1.1.0 -> 2.0.0Cas d'usage : Communiquer clairement l'impact d'une mise à jour aux consommateurs d'une lib/API.
Modèle d'exécution où le cloud provider gère l'infrastructure. Le code s'exécute en fonctions éphémères, facturées à l'exécution. Ex : AWS Lambda, Vercel Functions.
Un taxi : tu paies la course (exécution) sans acheter ni entretenir de voiture (serveur).
// AWS Lambda handler
export const handler = async (event) => {
const body = JSON.parse(event.body);
const result = await processOrder(body);
return { statusCode: 200, body: JSON.stringify(result) };
};Cas d'usage : APIs à trafic variable, traitement d'événements, webhooks, cron jobs.
Abstraction réseau stable exposant un ensemble de Pods via une IP fixe et un DNS interne. Types : ClusterIP, NodePort, LoadBalancer.
Un standard téléphonique : un seul numéro (Service) redirigé vers le bon employé disponible (Pod).
apiVersion: v1
kind: Service
metadata:
name: api-svc
spec:
selector: { app: api }
ports:
- port: 80
targetPort: 3000
type: ClusterIPCas d'usage : Permettre la communication inter-services sans connaître les IPs éphémères des Pods.
Partitionnement horizontal des données sur plusieurs instances de base de données. Chaque shard contient un sous-ensemble des données.
Diviser un annuaire téléphonique en volumes A-M et N-Z pour que deux personnes cherchent en parallèle.
// Shard key basée sur userId
const shardId = hash(userId) % NUM_SHARDS;
const db = shardConnections[shardId];
await db.query('INSERT INTO orders ...', [order]);Cas d'usage : Dépasser les limites d'une seule machine quand la base atteint des téraoctets.
Commits signés cryptographiquement avec GPG ou SSH pour prouver l'identité de l'auteur. Badge Verified sur GitHub.
Un courrier recommandé avec signature : tu prouves que c'est bien toi qui l'as envoyé.
git config --global commit.gpgsign true
git config --global user.signingkey ABC123
git commit -S -m "feat: signed commit"
git log --show-signatureCas d'usage : Prouver l'authenticité des commits dans les projets critiques et open source.
SLI = métrique mesurée (latence p99). SLO = objectif interne (p99 < 200ms). SLA = engagement contractuel client avec pénalités (99.9% uptime).
SLI = le thermomètre. SLO = la température souhaitée. SLA = la garantie du chauffagiste avec remboursement si pas atteint.
// SLI : latence p99 mesurée
// SLO : p99 < 200ms, disponibilité > 99.95%
// SLA : 99.9% uptime, sinon crédit client
// Error budget = 100% - SLO = 0.05% de marge d'erreurCas d'usage : Définir des objectifs de fiabilité et savoir quand investir en stabilité vs features.
Groupe logique d'étapes dans un pipeline (build, test, deploy). Les stages s'exécutent séquentiellement, les jobs dans un stage en parallèle.
Les étapes d'un examen : écrit d'abord, puis oral. Tu passes à l'oral seulement si l'écrit est réussi.
stages:
- build
- test
- deploy
build-job:
stage: build
script: npm run buildCas d'usage : Organiser le pipeline pour fail fast : pas de deploy si les tests échouent.
Contrôleur pour applications stateful nécessitant une identité réseau stable et un stockage persistant. Les Pods ont des noms ordonnés (app-0, app-1).
Des places de parking numérotées : chaque voiture (Pod) a toujours la même place et le même numéro.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mongo
spec:
serviceName: mongo
replicas: 3
volumeClaimTemplates:
- metadata: { name: data }
spec: { resources: { requests: { storage: 10Gi } } }Cas d'usage : Déployer des bases de données (MongoDB, PostgreSQL) ou des systèmes distribués (Kafka).
Deux briques de sécurité de la chaîne d'approvisionnement logicielle. SLSA (« salsa », spécification v1.1 approuvée en avril 2025) définit des niveaux Build L1 à L3 : L1 une provenance existe, L2 le build tourne sur une plateforme hébergée qui signe la provenance, L3 la plateforme est isolée et durcie. Sigstore fournit l'outillage : Cosign signe images et artefacts, Fulcio délivre des certificats éphémères liés à une identité OIDC (signature « sans clé »), Rekor journalise chaque signature dans un registre public infalsifiable.
SLSA est la norme qui dit ce qu'un bon tampon de traçabilité doit prouver ; Sigstore est le tampon lui-même, avec le registre public où chaque coup de tampon est consigné.
# GitHub Actions : signer l'image sans clé (identité OIDC du workflow)
permissions:
id-token: write # jeton OIDC → certificat Fulcio
packages: write
steps:
- uses: sigstore/cosign-installer@v3
- run: docker build -t ghcr.io/acme/api@${DIGEST} . && docker push ...
- run: cosign sign --yes ghcr.io/acme/api@${DIGEST}
# Vérification côté déploiement :
# cosign verify ghcr.io/acme/api@${DIGEST} \
# --certificate-identity-regexp 'github.com/acme/.*' \
# --certificate-oidc-issuer https://token.actions.githubusercontent.comCas d'usage : Prouver qu'une image déployée en production a bien été construite par votre CI depuis votre dépôt, et bloquer tout artefact non signé à l'admission.
Outil d'infrastructure as code créé par HashiCorp : on déclare l'infrastructure en HCL, on planifie puis on applique les changements de façon idempotente. En août 2023, HashiCorp a fait passer Terraform de la licence MPL 2.0 à la BSL 1.1 (source disponible, non open source), ce qui a donné naissance au fork OpenTofu sous la Linux Foundation. IBM a finalisé le rachat de HashiCorp le 27 février 2025 sans changer la licence.
Un architecte avec un plan : tu dessines l'infrastructure souhaitée et Terraform construit ou modifie pour correspondre.
resource "aws_instance" "api" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t3.micro"
tags = { Name = "api-server" }
}
# terraform plan -> terraform applyCas d'usage : Gérer toute l'infrastructure cloud de manière versionnée, reproductible et auditable.
Stratégie de branchement où tous les devs commitent sur main (trunk) via des branches courtes (<1 jour). Favorise l'intégration continue.
Un seul cahier partagé où chacun écrit sa partie rapidement plutôt que chacun son cahier fusionné une fois par mois.
git checkout -b feat/login
# ... code pendant quelques heures
git push origin feat/login
# PR review rapide puis merge dans mainCas d'usage : Équipes pratiquant le CI/CD avec des déploiements fréquents (plusieurs fois par jour).
Réseau virtuel isolé dans le cloud, avec des sous-réseaux publics/privés, des tables de routage et des passerelles Internet. Fondation de toute architecture cloud.
Un terrain clôturé avec des bâtiments (sous-réseaux), un portail (Internet Gateway) et un gardien (Security Group).
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
}
resource "aws_subnet" "private" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
}Cas d'usage : Isoler les ressources cloud et contrôler finement le trafic réseau entrant/sortant.
Stratégie où les écritures vont d'abord dans le cache, puis sont flush vers la DB de manière asynchrone/batchée. Très performant mais risque de perte.
Prendre des notes sur un brouillon puis recopier au propre plus tard : rapide mais risque de perdre le brouillon.
async function updateUser(id, data) {
await cache.set(`user:${id}`, data);
await cache.sadd('dirty-keys', `user:${id}`);
// Un worker flush les dirty keys vers la DB
}Cas d'usage : Compteurs temps réel, analytics haute fréquence où la perte ponctuelle est acceptable.
Stratégie où chaque écriture met à jour simultanément le cache et la base de données. Garantit la cohérence cache/DB au prix d'écritures plus lentes.
Écrire dans ton agenda ET dans le calendrier mural en même temps : toujours synchronisés.
async function updateUser(id, data) {
await db.updateUser(id, data);
await cache.set(`user:${id}`, data, 'EX', 300);
return data;
}Cas d'usage : Données critiques nécessitant une cohérence forte entre cache et DB.