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.
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 zero-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 tolerance. 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.
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.
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é via un trace ID unique. Chaque service ajoute un span au trace.
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.
Outil pour définir et orchestrer des applications multi-conteneurs via un fichier YAML. Gère réseaux, volumes et dépendances entre services.
Le chef d'orchestre qui dit à chaque musicien (conteneur) quand jouer et comment se synchroniser.
services:
api:
build: .
ports: ["3000:3000"]
depends_on: [db]
db:
image: postgres:16
volumes: ["pgdata:/var/lib/postgresql/data"]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 les instructions pour construire une image Docker couche par couche. Chaque instruction crée un layer cacheable.
Une recette de cuisine étape par étape : chaque ligne ajoute un ingrédient ou une action au plat final.
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
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.
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.
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. Les workflows sont définis en YAML dans .github/workflows et déclenchés par des événements GitHub.
Un assistant personnel intégré à ton bureau (GitHub) qui exécute automatiquement tes instructions.
name: CI
on:
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm testCas d'usage : CI/CD natif pour les projets hébergés sur GitHub, gratuit pour l'open source.
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.
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 gérant l'accès HTTP/HTTPS externe vers les Services internes. Supporte le routage par host et path, le TLS.
Le portier d'un hôtel : il dirige chaque visiteur vers la bonne chambre (service) selon sa réservation (URL).
apiVersion: networking.k8s.io/v1
kind: Ingress
spec:
rules:
- host: api.example.com
http:
paths:
- path: /
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 (git 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
{
"pipeline": {
"build": { "dependsOn": ["^build"] },
"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.
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.
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 écoutent 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 redirige 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.
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) redirige 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).
Outil IaC (Infrastructure as Code) de HashiCorp. Déclare l'infrastructure en HCL, planifie les changements et les applique de manière idempotente.
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.
Autres stacks