Entraînement Practice

Le monitoring vérifie des conditions connues d'avance (seuils, dashboards prédéfinis) et dit QUE ça casse. L'observabilité est la capacité à répondre à des questions non anticipées à partir des données émises par le système (logs, metrics, traces) : elle permet de comprendre POURQUOI. Monitoring checks conditions known in advance (thresholds, predefined dashboards) and tells you THAT something broke. Observability is the ability to answer unanticipated questions from the data the system emits (logs, metrics, traces): it lets you understand WHY.

Logs : événements discrets riches en contexte, chers en volume. Metrics : agrégats numériques pas chers, parfaits pour alerter, pauvres en contexte. Traces : parcours d'une requête à travers les services en spans. Leur vraie force : la corrélation par trace ID. Logs: discrete events rich in context, expensive in volume. Metrics: cheap numeric aggregates, perfect for alerting, poor in context. Traces: a request's journey across services in spans. Their real power: correlation via trace ID.

On peut filtrer, agréger et chercher par champ (level, route, user_id, duration_ms) au lieu de grepper du texte. Avec un identifiant de corrélation (request/trace ID) propagé entre services, on reconstitue le parcours complet d'une requête dans toute la stack. You can filter, aggregate and search by field (level, route, user_id, duration_ms) instead of grepping text. With a correlation identifier (request/trace ID) propagated between services, you can reconstruct a request's full journey through the stack.

RED, pour les services : Rate (requêtes/s), Errors (taux d'erreur), Duration (latence en percentiles p50/p95/p99). USE, pour les ressources : Utilization, Saturation, Errors. Deux grilles standard pour construire dashboards et alertes. RED, for services: Rate (requests/s), Errors (error rate), Duration (latency in p50/p95/p99 percentiles). USE, for resources: Utilization, Saturation, Errors. Two standard grids for building dashboards and alerts.

Une trace est un arbre de spans, chacun représentant une opération (appel HTTP, requête SQL) avec durée, attributs et parent. La context propagation transporte le trace ID et le span ID parent dans les headers HTTP (W3C traceparent) de service en service, permettant de reconstituer l'arbre complet. A trace is a tree of spans, each representing an operation (HTTP call, SQL query) with duration, attributes and a parent. Context propagation carries the trace ID and parent span ID in HTTP headers (W3C traceparent) from service to service, allowing the full tree to be reconstructed.

Le standard CNCF vendor-neutral pour générer et exporter logs, metrics et traces : SDK par langage, auto-instrumentation, et un Collector qui reçoit, transforme et exporte. On instrumente une fois et on change de backend (Jaeger, Prometheus, Datadog…) sans toucher au code : pas de lock-in. The vendor-neutral CNCF standard for generating and exporting logs, metrics and traces: per-language SDKs, auto-instrumentation, and a Collector that receives, transforms and exports. Instrument once and switch backends (Jaeger, Prometheus, Datadog…) without touching the code: no lock-in.

Un SLI est une mesure de ce que vivent les utilisateurs (ex. proportion de requêtes servies en moins de 300 ms). Un SLO est l'objectif qu'on s'engage à tenir sur ce SLI (ex. 99,9 % sur 30 jours) — le budget d'erreur qui en découle arbitre entre fiabilité et vitesse de déploiement. An SLI is a measurement of what users experience (e.g. proportion of requests served under 300 ms). An SLO is the target you commit to on that SLI (e.g. 99.9% over 30 days) — the resulting error budget arbitrates between reliability and deployment speed.

Les utilisateurs subissent les symptômes (erreurs, latence), pas les causes (CPU haut). Un CPU à 95 % avec des utilisateurs heureux ne justifie pas de réveiller quelqu'un ; un taux d'erreur à 5 % si. Alerter sur les causes génère de l'alert fatigue ; les causes se consultent dans les dashboards après l'alerte. Users suffer symptoms (errors, latency), not causes (high CPU). A CPU at 95% with happy users doesn't justify waking someone up; a 5% error rate does. Alerting on causes generates alert fatigue; causes get consulted in dashboards after the alert.

L'intégration N×M : chaque application LLM devait écrire un connecteur custom pour chaque service. MCP standardise le protocole entre les deux : un serveur écrit une fois fonctionne avec tous les hosts compatibles — on passe de N×M à N+M connecteurs. N×M integration: every LLM application had to write a custom connector for every service. MCP standardizes the protocol between the two: a server written once works with every compatible host — going from N×M to N+M connectors.

Le host (l'application LLM : Claude Desktop, un IDE), qui orchestre ; le client (la connexion 1-à-1 vers un serveur, à l'intérieur du host) ; le serveur (le programme qui expose tools, resources et prompts). Un host connecté à trois serveurs maintient trois clients. The host (the LLM application: Claude Desktop, an IDE), which orchestrates; the client (the 1-to-1 connection to a server, inside the host); the server (the program exposing tools, resources and prompts). A host connected to three servers maintains three clients.

Tools : le modèle décide de les appeler (avec approbation utilisateur) — ex. create_issue. Resources : l'application choisit les données à attacher au contexte — ex. contenu de fichier. Prompts : templates déclenchés explicitement par l'utilisateur — ex. slash commands. Tools: the model decides to call them (with user approval) — e.g. create_issue. Resources: the application chooses the data to attach to the context — e.g. file contents. Prompts: templates explicitly triggered by the user — e.g. slash commands.

Sur JSON-RPC 2.0, avec une poignée de main initialize qui négocie version et capacités. Transports : stdio (le host lance le serveur en sous-processus, communication stdin/stdout, idéal en local) et HTTP streamable (endpoint distant avec streaming, qui remplace l'ancien HTTP+SSE). On JSON-RPC 2.0, with an initialize handshake negotiating version and capabilities. Transports: stdio (the host launches the server as a subprocess, stdin/stdout communication, ideal locally) and streamable HTTP (a remote endpoint with streaming, replacing the older HTTP+SSE).

Le function calling est le mécanisme par lequel le modèle génère des appels de fonctions, mais chaque intégration reste du code custom dans une seule app. MCP standardise la couche au-dessus : découverte dynamique (tools/list), transport, cycle de vie — un serveur MCP est réutilisable par n'importe quel host. Function calling is the mechanism by which the model generates function calls, but each integration remains custom code inside a single app. MCP standardizes the layer above: dynamic discovery (tools/list), transport, lifecycle — an MCP server is reusable by any host.

Du contenu externe rapporté par un outil (page web, issue GitHub, email) contient des instructions malveillantes que le modèle risque de suivre — ex. exfiltrer des secrets via un autre outil. Le trio dangereux : données privées + contenu non fiable + canal de sortie externe. External content brought back by a tool (web page, GitHub issue, email) contains malicious instructions the model may follow — e.g. exfiltrating secrets through another tool. The dangerous trio: private data + untrusted content + an external output channel.

Principe du moindre privilège (tokens à permissions minimales, serveurs read-only si possible), human-in-the-loop pour les actions sensibles, audit des serveurs tiers avant installation (ils exécutent du code localement), et isolation des serveurs à risque. Principle of least privilege (minimally-scoped tokens, read-only servers when possible), human-in-the-loop for sensitive actions, auditing third-party servers before installing them (they run code locally), and isolating risky servers.

Adopté au-delà d'Anthropic (OpenAI, Google DeepMind, Microsoft, les IDE), c'est le standard de facto des agents. Un stagiaire marque des points en citant un usage concret (serveur GitHub/Postgres dans un IDE) ou un mini-serveur écrit avec le SDK, plus les limites : coût en tokens, risques d'injection. Adopted beyond Anthropic (OpenAI, Google DeepMind, Microsoft, IDEs), it's the de facto agent standard. An intern scores points by citing concrete usage (a GitHub/Postgres server in an IDE) or a mini-server written with the SDK, plus the limits: token cost, injection risks.

Compose démarre une stack sur une seule machine. K8s ajoute le multi-machines, la boucle de réconciliation (self-healing automatique), le scaling déclaratif, les rolling updates avec rollback, et le service discovery/load balancing intégrés — au prix d'une complexité opérationnelle bien supérieure. Compose starts a stack on a single machine. K8s adds multi-machine support, the reconciliation loop (automatic self-healing), declarative scaling, rolling updates with rollback, and built-in service discovery/load balancing — at the cost of far greater operational complexity.

kube-apiserver (point d'entrée unique, valide et persiste les objets), etcd (base clé-valeur stockant tout l'état du cluster), kube-scheduler (choisit le node de chaque nouveau Pod), controller manager (fait tourner les boucles de réconciliation). kube-apiserver (single entry point, validates and persists objects), etcd (key-value store holding the entire cluster state), kube-scheduler (picks the node for each new Pod), controller manager (runs the reconciliation loops).

kubelet surveille l'API server, lance les conteneurs des Pods assignés au node via le container runtime (containerd) et remonte leur état. kube-proxy programme les règles réseau (iptables/IPVS) pour que les Services routent vers les bons Pods. kubelet watches the API server, starts the containers of Pods assigned to the node through the container runtime (containerd) and reports their status. kube-proxy programs the network rules (iptables/IPVS) so Services route to the right Pods.

Le Deployment gère les versions et les rolling updates (nouveau ReplicaSet monté progressivement, ancien descendu, rollback possible). Le ReplicaSet maintient le nombre de réplicas demandé. Le Pod est la plus petite unité : un ou plusieurs conteneurs partageant IP et volumes, éphémère par conception. The Deployment manages versions and rolling updates (new ReplicaSet scaled up progressively, old one scaled down, rollback possible). The ReplicaSet maintains the requested replica count. The Pod is the smallest unit: one or more containers sharing IP and volumes, ephemeral by design.

ClusterIP : IP virtuelle interne au cluster (le défaut, pour le trafic entre services). NodePort : ouvre un port sur chaque node (tests, on-prem sans LB). LoadBalancer : provisionne un load balancer cloud avec IP publique — en pratique un seul, devant un Ingress qui route vers N services ClusterIP. ClusterIP: cluster-internal virtual IP (the default, for service-to-service traffic). NodePort: opens a port on every node (testing, on-prem without a LB). LoadBalancer: provisions a cloud load balancer with a public IP — in practice just one, in front of an Ingress routing to N ClusterIP services.

Liveness : le process est-il vivant ? Échec → restart du conteneur. Readiness : peut-il recevoir du trafic ? Échec → retiré des endpoints du Service, sans restart. Piège : tester une dépendance externe (DB) dans la liveness → restarts en boucle quand la dépendance a un souci. Liveness: is the process alive? Failure → container restart. Readiness: can it receive traffic? Failure → removed from the Service's endpoints, no restart. Trap: testing an external dependency (DB) in the liveness probe → restart loops whenever the dependency has an issue.

requests = ressources garanties, utilisées par le scheduler pour placer le Pod. limits = plafond : CPU throttlé au-delà, dépassement mémoire → OOMKilled. Sans requests le scheduling est aveugle ; sans limits un Pod peut affamer le node. requests = guaranteed resources, used by the scheduler to place the Pod. limits = ceiling: CPU is throttled beyond it, exceeding memory → OOMKilled. Without requests scheduling is blind; without limits one Pod can starve the node.

Pour un projet à un ou deux services sur un seul serveur : un VPS avec Docker Compose ou un PaaS suffit, avec une fraction de la complexité. K8s se justifie avec plusieurs machines, des besoins réels de scaling/haute dispo, et une équipe capable de l'opérer. For a project with one or two services on a single server: a VPS with Docker Compose or a PaaS is enough, at a fraction of the complexity. K8s is justified with multiple machines, real scaling/high-availability needs, and a team able to operate it.

Il disparaît entièrement : `tsc` efface les annotations et émet du JavaScript pur. La vérification est uniquement statique — aucune donnée n'est validée au runtime, d'où le besoin de validation aux frontières (zod) pour les entrées externes. It disappears entirely: `tsc` erases the annotations and emits plain JavaScript. Checking is static only — no data is validated at runtime, hence the need for boundary validation (zod) on external input.

Deux types sont compatibles si leurs structures le sont, peu importe leur nom (duck typing vérifié statiquement). Un objet avec les bonnes propriétés est assignable à une interface même s'il n'a jamais été déclaré comme telle — contrairement au typage nominal de Java/C#. Two types are compatible if their structures are, regardless of their names (statically checked duck typing). An object with the right properties is assignable to an interface even if it was never declared as one — unlike Java/C#'s nominal typing.

`any` désactive toute vérification et se propage à tout ce qu'il touche. `unknown` accepte n'importe quelle valeur mais interdit tout usage tant qu'on n'a pas rétréci le type (typeof, type guard, validation). Aux frontières : `unknown`, jamais `any`. `any` disables all checking and spreads to everything it touches. `unknown` accepts any value but forbids any use until the type has been narrowed (typeof, type guard, validation). At the boundaries: `unknown`, never `any`.

Le rétrécissement d'un type union au fil du contrôle de flot : après `if (typeof x === "string")`, `x` est un `string` dans la branche. Outils : `typeof`, `instanceof`, `in`, champ discriminant d'une discriminated union, type guards personnalisés (`x is User`). Shrinking a union type through control flow: after `if (typeof x === "string")`, `x` is a `string` inside the branch. Tools: `typeof`, `instanceof`, `in`, the discriminant field of a discriminated union, custom type guards (`x is User`).

Quasi interchangeables pour un objet. `interface` : declaration merging et `extends`, bien pour les formes d'objets publiques. `type` : unions, intersections, tuples, mapped types. Le choix relève surtout de la convention d'équipe. Nearly interchangeable for an object. `interface`: declaration merging and `extends`, good for public object shapes. `type`: unions, intersections, tuples, mapped types. The choice is mostly team convention.

`function getProp<T, K extends keyof T>(obj: T, key: K): T[K]` : `K` doit être une clé existante de `T`, donc demander une propriété inexistante est une erreur de compilation, et le type de retour est exactement celui de la propriété demandée. `function getProp<T, K extends keyof T>(obj: T, key: K): T[K]`: `K` must be an existing key of `T`, so asking for a nonexistent property is a compile error, and the return type is exactly that of the requested property.

`Partial<T>` : tout optionnel (payload PATCH). `Pick<T, K>` : ne garder que certaines clés. `Omit<T, K>` : tout sauf certaines clés (DTO sans `password`). `Record<K, V>` : dictionnaire typé (`Record<string, number>`). `Partial<T>`: everything optional (PATCH payload). `Pick<T, K>`: keep only certain keys. `Omit<T, K>`: everything except certain keys (DTO without `password`). `Record<K, V>`: typed dictionary (`Record<string, number>`).

Parce que le type est une annotation de compilation, pas une garantie : le serveur peut renvoyer n'importe quoi. `schema.parse(data)` valide réellement au runtime, et `z.infer<typeof schema>` dérive le type statique du schéma — une seule source de vérité pour les deux niveaux. Because the type is a compile-time annotation, not a guarantee: the server can return anything. `schema.parse(data)` actually validates at runtime, and `z.infer<typeof schema>` derives the static type from the schema — one source of truth for both levels.

Un appel de fonction est infiniment plus simple qu'un appel réseau : pas de latence ni de panne partielle, une transaction ACID couvre tout, un seul déploiement, une stack trace pour debugger. En début de projet, la vitesse d'itération prime et les frontières de domaines sont encore inconnues — les microservices les figeraient trop tôt. A function call is infinitely simpler than a network call: no latency or partial failure, one ACID transaction covers everything, one deployment, one stack trace for debugging. Early on, iteration speed rules and domain boundaries are still unknown — microservices would freeze them too early.

Un seul déployable, mais des modules internes aux frontières nettes : chaque module n'est accessible que par son interface publique (billing ne touche pas aux tables de users). On garde la simplicité opérationnelle du monolithe tout en préparant une éventuelle extraction future — un déménagement plutôt qu'une réécriture. A single deployable, but internal modules with clean boundaries: each module is only reachable through its public interface (billing never touches users' tables). You keep the monolith's operational simplicity while preparing a possible future extraction — a move rather than a rewrite.

1) Déploiement indépendant : chaque équipe déploie sans attendre les autres — la promesse centrale. 2) Scaling ciblé : répliquer un seul service sous charge (surtout utile pour des besoins asymétriques : GPU, mémoire, langage). 3) Ownership d'équipe : chaque équipe possède ses services de bout en bout — la loi de Conway appliquée volontairement. 1) Independent deployment: each team deploys without waiting for the others — the central promise. 2) Targeted scaling: replicating one service under load (mostly useful for asymmetric needs: GPU, memory, language). 3) Team ownership: each team owns its services end to end — Conway's law applied deliberately.

L'anti-pattern n°1 : des services séparés par le réseau mais couplés au point de devoir se déployer ensemble (base partagée, API fragiles, chaînes d'appels synchrones). On paie tous les coûts du distribué — latence, pannes partielles, complexité ops — sans le bénéfice central du déploiement indépendant. The number one anti-pattern: services separated by the network but so coupled they must deploy together (shared database, fragile APIs, chains of synchronous calls). You pay every cost of distribution — latency, partial failures, ops complexity — without the central benefit of independent deployment.

Deux services qui partagent une base sont couplés par le schéma : un ALTER TABLE de l'un casse l'autre, et les déploiements redeviennent coordonnés. Chaque service possède sa base ; les autres n'y accèdent que via son API. Le prix : plus de JOIN cross-services ni de transaction ACID globale. Two services sharing a database are coupled through the schema: one's ALTER TABLE breaks the other, and deployments become coordinated again. Each service owns its database; others only access it through its API. The price: no more cross-service JOINs or global ACID transactions.

Une saga remplace la transaction distribuée impossible par une séquence de transactions locales, une par service. Si une étape échoue, des transactions de compensation défont les étapes précédentes (annuler la réservation, rembourser le paiement) — orchestrées par un coordinateur ou chorégraphiées par une chaîne d'événements. A saga replaces the impossible distributed transaction with a sequence of local transactions, one per service. If a step fails, compensating transactions undo the previous steps (cancel the reservation, refund the payment) — orchestrated by a coordinator or choreographed through a chain of events.

Synchrone (REST, gRPC) : simple à raisonner, réponse immédiate, mais couplage temporel — les latences s'additionnent et les pannes se propagent en cascade. Asynchrone (événements via Kafka/RabbitMQ) : découplage, absorption des pics, mais cohérence à terme et debugging plus difficile. Règle pratique : synchrone pour les queries client, asynchrone entre services quand c'est possible. Synchronous (REST, gRPC): easy to reason about, immediate answer, but temporal coupling — latencies add up and failures cascade. Asynchronous (events via Kafka/RabbitMQ): decoupling, burst absorption, but eventual consistency and harder debugging. Practical rule: synchronous for client-facing queries, asynchronous between services whenever possible.

La migration progressive d'un monolithe : on extrait une capacité à la fois, un proxy ou une gateway route progressivement le trafic vers le nouveau service, et le monolithe rétrécit petit à petit. À l'opposé du big bang rewrite. Chaque extraction doit se justifier seule — commencer par le meilleur ratio douleur/risque. Progressive migration of a monolith: extract one capability at a time, a proxy or gateway gradually routes traffic to the new service, and the monolith shrinks bit by bit. The opposite of a big-bang rewrite. Each extraction must justify itself — start with the best pain-to-risk ratio.

Beaucoup de tests unitaires (rapides, isolés, précis dans leur diagnostic), moins de tests d'intégration (plusieurs composants avec de vraies dépendances), très peu de E2E (l'application pilotée comme un utilisateur). Plus on monte, plus le test est réaliste mais lent, cher à maintenir et vague quand il échoue. Many unit tests (fast, isolated, precise in their diagnosis), fewer integration tests (several components with real dependencies), very few E2E tests (the app driven like a user). The higher you climb, the more realistic the test but the slower, more expensive to maintain and vaguer when it fails.

Arrange : préparer les données et l'objet testé. Act : appeler la fonction testée. Assert : vérifier le résultat observable. Cette structure en trois blocs rend le test lisible et garantit qu'il vérifie un comportement précis, avec idéalement une seule raison d'échouer. Arrange: prepare the data and the object under test. Act: call the function being tested. Assert: verify the observable result. This three-block structure keeps the test readable and ensures it verifies one precise behavior, ideally with a single reason to fail.

Stub : renvoie des réponses préprogrammées (fournit un état au test). Mock : porte des attentes sur les interactions, le test échoue si l'appel attendu ne se produit pas (vérifie un comportement). Spy : enregistre les appels reçus sans changer le comportement. Fake : implémentation réelle mais simplifiée, comme un repository en mémoire. Stub: returns pre-programmed answers (provides state to the test). Mock: carries expectations about interactions, the test fails if the expected call doesn't happen (verifies behavior). Spy: records received calls without changing behavior. Fake: a real but simplified implementation, like an in-memory repository.

Red : écrire un test qui échoue. Green : écrire le code minimal qui le fait passer. Refactor : nettoyer avec les tests au vert. Apports : l'API se conçoit du point de vue de l'appelant, le code est testable par construction, et chaque refactoring est protégé par le filet de tests existant. Red: write a failing test. Green: write the minimal code that makes it pass. Refactor: clean up with tests green. Benefits: the API is designed from the caller's point of view, the code is testable by construction, and every refactoring is protected by the existing safety net.

Un test non déterministe (flaky) détruit la confiance dans la suite : on relance sans lire, un vrai bug finit par passer. Ennemis classiques : Date.now() et l'horloge, Math.random(), les timeouts et sleeps, l'ordre d'itération non garanti, les dépendances entre tests. Solution : injecter le temps et l'aléa comme des dépendances. A non-deterministic (flaky) test destroys trust in the suite: people re-run without reading, and a real bug eventually slips through. Classic enemies: Date.now() and the clock, Math.random(), timeouts and sleeps, unspecified iteration order, inter-test dependencies. Solution: inject time and randomness as dependencies.

À lancer de vraies dépendances (Postgres, Redis, Kafka…) dans des conteneurs Docker jetables le temps d'une suite de tests d'intégration. On teste les vraies requêtes SQL, contraintes et transactions au lieu de mocker le driver — quelques secondes de démarrage contre un réalisme incomparable. Starting real dependencies (Postgres, Redis, Kafka…) in throwaway Docker containers for the duration of an integration test suite. You test real SQL queries, constraints and transactions instead of mocking the driver — a few seconds of startup for incomparable realism.

Elle mesure les lignes exécutées, pas les comportements vérifiés : un test sans assertion donne 100 % de couverture et 0 % de valeur. Loi de Goodhart : en cible, elle pousse à écrire des tests pour couvrir plutôt que pour vérifier. Utile en tendance et pour repérer les zones mortes ; le mutation testing mesure mieux la qualité des assertions. It measures executed lines, not verified behaviors: an assertion-free test yields 100% coverage and 0% value. Goodhart's law: as a target, it pushes people to write tests to cover rather than to verify. Useful as a trend and to spot dead zones; mutation testing measures assertion quality better.

Attendre des conditions, jamais des durées (auto-waiting de Playwright, attentes explicites sur l'état) ; isoler les données de chaque test ; utiliser des sélecteurs stables (data-testid plutôt que des classes CSS) ; limiter le E2E aux parcours critiques. Un sleep(2000) est presque toujours un futur test flaky. Wait for conditions, never durations (Playwright's auto-waiting, explicit waits on state); isolate each test's data; use stable selectors (data-testid rather than CSS classes); limit E2E to critical journeys. A sleep(2000) is almost always a future flaky test.

HTTP est requête/réponse : le serveur ne peut pas envoyer de données de sa propre initiative. Le WebSocket établit une connexion TCP persistante et full-duplex : les deux côtés émettent quand ils veulent, avec quelques octets d'overhead par message. HTTP is request/response: the server cannot send data on its own initiative. WebSocket establishes a persistent, full-duplex TCP connection: both sides send whenever they want, with a few bytes of overhead per message.

Le client envoie un GET HTTP avec `Upgrade: websocket`, `Connection: Upgrade` et un nonce `Sec-WebSocket-Key`. Le serveur répond `101 Switching Protocols` avec `Sec-WebSocket-Accept` (SHA-1 du nonce + GUID fixe). La connexion TCP est ensuite réutilisée pour des frames full-duplex. Démarrer en HTTP permet de traverser les proxies et de partager le port 443. The client sends an HTTP GET with `Upgrade: websocket`, `Connection: Upgrade` and a `Sec-WebSocket-Key` nonce. The server answers `101 Switching Protocols` with `Sec-WebSocket-Accept` (SHA-1 of the nonce + a fixed GUID). The TCP connection is then reused for full-duplex frames. Starting as HTTP gets through proxies and shares port 443.

Short polling : requête toutes les X secondes, simple mais latence moyenne X/2 et requêtes vides. Long polling : le serveur garde la requête ouverte jusqu'à avoir une donnée, latence quasi nulle mais une reconnexion par message. SSE : flux HTTP `text/event-stream` unidirectionnel serveur → client, avec reconnexion automatique native via EventSource — souvent suffisant pour notifications et dashboards. Short polling: a request every X seconds, simple but average latency of X/2 and empty requests. Long polling: the server holds the request open until it has data, near-zero latency but one reconnection per message. SSE: a unidirectional server → client `text/event-stream` HTTP flow, with native automatic reconnection via EventSource — often enough for notifications and dashboards.

De heartbeat : proxies, NAT et firewalls coupent silencieusement les connexions TCP inactives (souvent après 30-60 s). Le serveur envoie un ping périodique ; sans pong en retour, la connexion est considérée morte et nettoyée. Sans heartbeat, on accumule des connexions zombies et le client croit être connecté à tort. Heartbeat: proxies, NAT and firewalls silently drop idle TCP connections (often after 30-60 s). The server sends a periodic ping; without a pong back, the connection is considered dead and cleaned up. Without a heartbeat you accumulate zombie connections and the client wrongly believes it's connected.

Deux briques : des sticky sessions au load balancer (la connexion, stateful, doit vivre sur une instance stable) et un pub/sub type Redis entre les instances — celle qui reçoit un message le publie sur un channel, toutes les instances abonnées le relaient à leurs propres clients connectés. C'est ce qu'implémente l'adapter Redis de socket.io. Two building blocks: sticky sessions at the load balancer (the connection is stateful and must live on a stable instance) and a Redis-style pub/sub between instances — the one receiving a message publishes it on a channel, and every subscribed instance relays it to its own connected clients. That's what socket.io's Redis adapter implements.

Apports : reconnexion automatique, rooms, namespaces, acknowledgements, fallback en long polling et adapter Redis pour le multi-instance. Prix : un protocole propriétaire (incompatible avec un client ou serveur WebSocket brut) et une dépendance des deux côtés. Aujourd'hui, ce sont surtout les rooms et l'adapter qui le justifient, plus le fallback. Additions: automatic reconnection, rooms, namespaces, acknowledgements, long-polling fallback and a Redis adapter for multi-instance. Cost: a proprietary protocol (incompatible with a raw WebSocket client or server) and a dependency on both sides. Today, rooms and the adapter justify it more than the fallback does.

L'API WebSocket du navigateur n'autorise pas de headers custom. Options : cookie de session envoyé au handshake (en vérifiant impérativement le header Origin), token court-vécu en query string (attention aux logs serveur) ou message d'authentification juste après l'ouverture. L'identité est ensuite attachée à la connexion. The browser's WebSocket API doesn't allow custom headers. Options: session cookie sent at the handshake (imperatively checking the Origin header), a short-lived token in the query string (beware server logs) or an authentication message right after opening. Identity is then attached to the connection.

Les WebSockets ne sont pas soumis au CORS : un site malveillant peut ouvrir une connexion vers votre serveur, et le navigateur y joint les cookies de session. Si le serveur ne vérifie pas le header Origin contre une allowlist, l'attaquant obtient une connexion authentifiée au nom de la victime. Protection : valider Origin au handshake (et/ou utiliser des tokens plutôt que le cookie seul). WebSockets are not subject to CORS: a malicious site can open a connection to your server, and the browser attaches the session cookies. If the server doesn't check the Origin header against an allowlist, the attacker gets an authenticated connection on the victim's behalf. Defense: validate Origin at the handshake (and/or use tokens rather than the cookie alone).

Delivery : chaque commit vert produit un artefact déployable, mais un humain décide quand déployer en prod. Deployment : tout commit vert sur la branche principale part en prod automatiquement, sans intervention. La différence tient en une phrase : qui appuie sur le bouton. Delivery: every green commit produces a deployable artifact, but a human decides when to ship to production. Deployment: every green commit on the main branch ships to production automatically, no intervention. The difference fits in one sentence: who presses the button.

Principe du fail-fast : ce sont les vérifications les moins chères (quelques secondes). Autant échouer en 30 secondes sur un problème de formatage ou de typage qu'attendre 10 minutes de tests pour le découvrir. On ordonne le pipeline du moins cher au plus cher. Fail-fast principle: they are the cheapest checks (a few seconds). Better to fail in 30 seconds on a formatting or typing issue than to wait through 10 minutes of tests to find out. You order the pipeline from cheapest to most expensive.

La machine qui exécute les jobs : hébergée par la plateforme (VM éphémère et vierge à chaque job) ou auto-hébergée (self-hosted) quand on a besoin de GPU, d'un réseau privé ou de matériel spécifique. Comme l'environnement repart de zéro, le cache est essentiel pour la vitesse. The machine that executes jobs: hosted by the platform (ephemeral, clean VM per job) or self-hosted when you need GPUs, a private network or specific hardware. Since the environment starts from scratch, caching is essential for speed.

Deux builds ne sont jamais garantis identiques : une dépendance peut avoir été mise à jour entre-temps, ce qui invalide tout ce qui a été testé en staging. On construit une seule fois (image taguée par SHA de commit) et on promeut ce même artefact immuable d'un environnement à l'autre. Two builds are never guaranteed identical: a dependency may have been updated in between, invalidating everything tested in staging. You build once (image tagged with the commit SHA) and promote that same immutable artifact from one environment to the next.

Rolling : on remplace les instances une par une, zéro interruption mais deux versions coexistent (rétro-compatibilité obligatoire). Blue-green : deux environnements complets, bascule totale du trafic, rollback instantané mais infra doublée. Canary : la nouvelle version reçoit 1-5 % du trafic, on surveille les métriques avant d'élargir — le meilleur contrôle du rayon d'impact. Rolling: replace instances one by one, zero downtime but two versions coexist (backward compatibility required). Blue-green: two full environments, full traffic switch, instant rollback but doubled infrastructure. Canary: the new version gets 1-5% of traffic, you watch metrics before widening — the best blast-radius control.

Tout le monde merge fréquemment sur main via des branches très courtes (moins de 1-2 jours). Le code inachevé part en prod désactivé derrière un feature flag, ce qui sépare le déploiement (le code est sur les serveurs) de la release (il est activé pour les utilisateurs). Couper un flag prend des secondes. Everyone merges to main frequently through very short-lived branches (under 1-2 days). Unfinished code ships to production disabled behind a feature flag, separating deployment (code is on the servers) from release (it's enabled for users). Killing a flag takes seconds.

Redéployer l'artefact précédent est trivial, mais une migration qui a supprimé ou transformé des données ne se rejoue pas à l'envers. D'où le pattern expand/contract : ajouter la nouvelle colonne, faire cohabiter les deux versions, puis supprimer l'ancienne colonne dans un déploiement ultérieur — chaque version du code fonctionne avec le schéma d'avant et d'après. Redeploying the previous artifact is trivial, but a migration that dropped or transformed data cannot be replayed backwards. Hence the expand/contract pattern: add the new column, let both versions coexist, then drop the old column in a later deployment — each code version works with the schema before and after.

Secrets stockés chiffrés, scopés par environnement, injectés en variables à l'exécution et masqués dans les logs. Limite : le masquage ne reconnaît pas un secret transformé (base64, URL-encodé, concaténé) — un echo de debug peut le faire fuiter. Un secret leaké se révoque, il ne se supprime pas des logs archivés. Secrets stored encrypted, scoped per environment, injected as variables at runtime and masked in logs. Limit: masking doesn't recognize a transformed secret (base64, URL-encoded, concatenated) — a debugging echo can leak it. A leaked secret gets revoked, not deleted from archived logs.

Quatre raisons : données servies depuis la RAM (aucune I/O disque sur le chemin des requêtes), event loop mono-thread (zéro lock, zéro context switch), structures de données optimisées en C, protocole minimal (RESP). Dire seulement « parce que c'est de la RAM » est insuffisant. Four reasons: data served from RAM (no disk I/O on the request path), single-threaded event loop (zero locks, zero context switches), data structures optimized in C, minimal protocol (RESP). Saying only 'because it's RAM' is not enough.

Le sorted set : chaque membre a un score, maintenu trié en permanence. ZADD pour insérer/mettre à jour un score, ZINCRBY pour l'incrémenter, ZRANGE (ou ZREVRANGE) pour le top N, ZRANK pour la position d'un joueur. Tout est en O(log n). The sorted set: each member has a score, kept permanently ordered. ZADD to insert/update a score, ZINCRBY to increment it, ZRANGE (or ZREVRANGE) for the top N, ZRANK for a player's position. Everything is O(log n).

Lecture : l'app interroge le cache ; sur un miss, elle lit la DB puis peuple le cache avec un TTL. Écriture : DB puis invalidation de la clé. Défauts : premier accès lent (cache froid) et fenêtre d'incohérence — entre l'écriture DB et l'invalidation, ou pendant le TTL, on sert l'ancienne valeur. Read: the app queries the cache; on a miss, it reads the DB then populates the cache with a TTL. Write: DB then key invalidation. Flaws: slow first access (cold cache) and an inconsistency window — between the DB write and the invalidation, or during the TTL, the old value is served.

Write-through : chaque écriture passe par le cache qui écrit dans la DB de façon synchrone — cache toujours frais mais écritures plus lentes. Write-behind : on écrit dans le cache, flush asynchrone vers la DB — écritures ultra-rapides mais perte possible de données si crash avant le flush. Write-through: every write goes through the cache, which writes to the DB synchronously — cache always fresh but slower writes. Write-behind: you write to the cache, with an asynchronous flush to the DB — ultra-fast writes but possible data loss if a crash occurs before the flush.

Une clé chaude expire et des centaines de requêtes font miss simultanément : toutes frappent la DB, qui s'écroule (dogpile). Parades : lock distribué (SET NX EX — un seul client recalcule, les autres attendent ou servent le stale), TTL jitter (TTL ± aléa pour désynchroniser les expirations), recalcul anticipé avant expiration. A hot key expires and hundreds of requests miss simultaneously: they all hit the DB, which collapses (dogpile). Countermeasures: a distributed lock (SET NX EX — a single client recomputes, the others wait or serve stale), TTL jitter (TTL ± random to desynchronize expirations), early recomputation before expiry.

RDB : snapshots binaires périodiques (fork + copy-on-write), compacts, restart rapide, mais perte de tout ce qui suit le dernier snapshot. AOF : journal de chaque écriture avec fsync configurable (everysec ≈ 1 s de perte max), fichier plus gros, restart plus lent. On les combine souvent ; un pur cache peut désactiver les deux. RDB: periodic binary snapshots (fork + copy-on-write), compact, fast restart, but everything after the last snapshot is lost. AOF: a journal of every write with configurable fsync (everysec ≈ at most 1 s of loss), bigger file, slower restart. They're often combined; a pure cache can disable both.

noeviction (le défaut) : les écritures échouent avec une erreur. allkeys-lru : éviction des clés les moins récemment utilisées, TTL ou pas. volatile-lru : éviction uniquement parmi les clés à TTL. allkeys-lfu : par fréquence d'accès, souvent le meilleur choix pour un vrai cache. noeviction (the default): writes fail with an error. allkeys-lru: evicts the least recently used keys, TTL or not. volatile-lru: evicts only among keys with a TTL. allkeys-lfu: by access frequency, often the best choice for a real cache.

C'est du fire-and-forget : aucune persistance, un abonné déconnecté perd définitivement les messages émis pendant son absence, pas d'acquittement ni de redélivrance. Les streams comblent une partie du manque (consumer groups, acks, relecture) ; pour du routage riche, des DLQ et des garanties fortes, il faut une vraie MQ (RabbitMQ, Kafka). It's fire-and-forget: no persistence, a disconnected subscriber permanently loses messages published while away, no acknowledgment or redelivery. Streams fill part of the gap (consumer groups, acks, replay); for rich routing, DLQs and strong guarantees, you need a real MQ (RabbitMQ, Kafka).

Atomicity : débit et crédit passent ensemble ou pas du tout. Consistency : les contraintes (solde, clés étrangères) restent vraies. Isolation : deux virements concurrents ne se voient pas à moitié faits. Durability : après commit, un crash ne perd rien (write-ahead log). Atomicity: debit and credit happen together or not at all. Consistency: constraints (balance, foreign keys) remain true. Isolation: two concurrent transfers don't see each other half-done. Durability: after commit, a crash loses nothing (write-ahead log).

Document (MongoDB) : JSON imbriqués, agrégats dénormalisés. Clé-valeur (Redis, DynamoDB) : GET/PUT par clé, latence minimale. Colonnes larges (Cassandra) : écritures massives distribuées, modélisation par requête. Graphe (Neo4j) : nœuds et relations de première classe, traversées efficaces. Document (MongoDB): nested JSON, denormalized aggregates. Key-value (Redis, DynamoDB): GET/PUT by key, minimal latency. Wide-column (Cassandra): massive distributed writes, query-driven modeling. Graph (Neo4j): first-class nodes and relationships, efficient traversals.

Dans un système distribué, PENDANT une partition réseau (P, subie, pas choisie), il faut trancher entre cohérence (refuser de répondre plutôt que répondre faux) et disponibilité (répondre au risque de diverger). Hors partition, le vrai trade-off est latence vs cohérence (PACELC). CAP ne s'applique pas à une base mono-nœud. In a distributed system, DURING a network partition (P, endured, not chosen), you must choose between consistency (refusing to answer rather than answering wrong) and availability (answering at the risk of diverging). Outside a partition, the real trade-off is latency vs consistency (PACELC). CAP doesn't apply to a single-node database.

Les répliques convergent vers la même valeur « à terme » : entre-temps, une lecture peut renvoyer une donnée périmée. Des garanties intermédiaires existent (read-your-writes, cohérence de session), et certains systèmes règlent la cohérence par requête (Cassandra : ONE vs QUORUM). Replicas converge to the same value 'eventually': in the meantime, a read can return stale data. Intermediate guarantees exist (read-your-writes, session consistency), and some systems tune consistency per request (Cassandra: ONE vs QUORUM).

Réplication : copier les mêmes données sur plusieurs nœuds (leader-follower) → scale les lectures, tolère les pannes ; attention au replica lag. Sharding : partitionner des données différentes sur plusieurs nœuds selon une shard key → scale aussi les écritures ; mauvaise clé = hot shard, et les requêtes cross-shard coûtent cher. Replication: copying the same data to several nodes (leader-follower) → scales reads, tolerates failures; beware of replica lag. Sharding: partitioning different data across nodes according to a shard key → also scales writes; a bad key = hot shard, and cross-shard queries are expensive.

Colonne à faible sélectivité (booléen : le planner préfère un scan complet), fonction appliquée à la colonne (lower(email) sans index d'expression), LIKE avec wildcard en tête ('%foo'), colonnes hors du préfixe d'un index composite, table minuscule. Vérifier avec EXPLAIN ANALYZE. Low-selectivity column (a boolean: the planner prefers a full scan), a function applied to the column (lower(email) without an expression index), LIKE with a leading wildcard ('%foo'), columns outside a composite index's prefix, a tiny table. Check with EXPLAIN ANALYZE.

L'ORM charge une liste (1 requête) puis, en lazy loading, exécute 1 requête par élément pour la relation accédée dans une boucle : 1+N requêtes, page lente, log rempli de requêtes identiques. Correction : eager loading (JOIN FETCH, include, select_related/prefetch_related). The ORM loads a list (1 query) then, via lazy loading, runs 1 query per item for the relation accessed in a loop: 1+N queries, slow page, log full of identical queries. Fix: eager loading (JOIN FETCH, include, select_related/prefetch_related).

JSONB stocke du JSON binaire indexable (GIN) et requêtable dans un moteur ACID : on garde les colonnes relationnelles et les contraintes pour le structuré, et la flexibilité documentaire pour la partie variable — sans ajouter une deuxième base à opérer. JSONB stores binary JSON that is indexable (GIN) and queryable inside an ACID engine: you keep relational columns and constraints for the structured part, and document-style flexibility for the variable part — without adding a second database to operate.

L'authentification prouve l'identité (login, MFA) ; l'autorisation détermine les droits. OAuth 2.0 est un framework d'autorisation déléguée : il ne dit pas qui est l'utilisateur. C'est OIDC qui ajoute la couche d'identité (id_token, endpoint /userinfo) au-dessus d'OAuth. Authentication proves identity (login, MFA); authorization determines rights. OAuth 2.0 is a delegated authorization framework: it doesn't say who the user is. OIDC is what adds the identity layer (id_token, /userinfo endpoint) on top of OAuth.

Trois parties encodées en base64url, séparées par des points : header (algorithme de signature), payload (claims : sub, iss, aud, exp, iat + claims métier), signature calculée sur les deux premières. Le token est signé mais PAS chiffré : lisible par tous, infalsifiable sans la clé. Three base64url-encoded parts separated by dots: header (signing algorithm), payload (claims: sub, iss, aud, exp, iat + business claims), and a signature computed over the first two. The token is signed but NOT encrypted: anyone can read it, nobody can forge it without the key.

HS256 = HMAC symétrique : le même secret signe et vérifie, donc tout service qui vérifie peut aussi forger. RS256 = RSA asymétrique : la clé privée signe, la clé publique (publiée via JWKS) vérifie. En microservices, RS256 : les services valident les tokens sans jamais détenir la clé de signature. HS256 = symmetric HMAC: the same secret signs and verifies, so any verifying service can also forge. RS256 = asymmetric RSA: the private key signs, the public key (published via JWKS) verifies. In microservices, RS256: services validate tokens without ever holding the signing key.

Il est auto-porteur : valide jusqu'à son exp, sans consultation du serveur — un logout ne l'invalide pas. Parade : access token court (5-15 min) + refresh token long stocké côté serveur, donc révocable, avec rotation (chaque usage émet un nouveau refresh token, la réutilisation d'un ancien signale un vol). It's self-contained: valid until its exp without asking the server — a logout doesn't invalidate it. Countermeasure: short-lived access token (5-15 min) + long-lived refresh token stored server-side, hence revocable, with rotation (each use issues a new refresh token; reusing an old one signals theft).

Une extension du flow authorization code : le client génère un code_verifier aléatoire, envoie son hash SHA-256 (code_challenge) au début, et présente le verifier à l'échange du code. Un code intercepté est donc inexploitable. Conçu pour les clients publics (mobile, SPA) sans client_secret ; recommandé partout, obligatoire en OAuth 2.1. An extension of the authorization code flow: the client generates a random code_verifier, sends its SHA-256 hash (code_challenge) upfront, and presents the verifier when exchanging the code. An intercepted code is therefore unusable. Designed for public clients (mobile, SPA) without a client_secret; recommended everywhere, mandatory in OAuth 2.1.

L'access token sert à appeler l'API (resource server) : c'est de l'autorisation, son contenu est destiné à l'API. L'id_token est un JWT destiné au client, qui décrit QUI est connecté (claims sub, email, name…) : c'est de l'authentification. Ne jamais utiliser l'un à la place de l'autre. The access token is for calling the API (resource server): it's authorization, and its content is meant for the API. The id_token is a JWT meant for the client, describing WHO is logged in (sub, email, name claims…): that's authentication. Never use one in place of the other.

localStorage est lisible par tout JS de la page : une XSS exfiltre le token. Un cookie httpOnly + Secure + SameSite est invisible pour JS (protégé XSS) mais envoyé automatiquement : surface CSRF, atténuée par SameSite=Lax/Strict et un token anti-CSRF. Pattern robuste : access token en mémoire + refresh token en cookie httpOnly. localStorage is readable by any JS on the page: an XSS exfiltrates the token. An httpOnly + Secure + SameSite cookie is invisible to JS (XSS-safe) but sent automatically: CSRF surface, mitigated by SameSite=Lax/Strict and an anti-CSRF token. Robust pattern: access token in memory + refresh token in an httpOnly cookie.

La signature avec l'algorithme ATTENDU (configuré côté serveur, jamais lu aveuglément dans le header), puis les claims : exp (avec une tolérance de clock skew), iss (bon émetteur), aud (token bien destiné à ce service), et les scopes/rôles pour l'autorisation. Le tout via une lib éprouvée, pas de crypto maison. The signature with the EXPECTED algorithm (configured server-side, never blindly read from the header), then the claims: exp (with clock-skew tolerance), iss (right issuer), aud (token really meant for this service), and scopes/roles for authorization. All through a battle-tested library, no home-made crypto.

Découplage (le producteur ignore qui consomme, le consommateur peut être down sans casser le producteur), lissage de charge (un pic s'empile dans la queue au lieu d'écrouler le consommateur), résilience (le message persiste jusqu'à son traitement, avec retry natif via la redélivrance). Decoupling (the producer doesn't know who consumes, the consumer can be down without breaking the producer), load smoothing (a spike piles up in the queue instead of crushing the consumer), resilience (the message persists until processed, with native retry through redelivery).

Jamais directement dans une queue : dans un exchange, avec une routing key. L'exchange route ensuite le message vers zéro, une ou plusieurs queues selon ses bindings (les règles de liaison exchange → queue). Never directly to a queue: to an exchange, with a routing key. The exchange then routes the message to zero, one or several queues according to its bindings (the exchange → queue link rules).

Direct : correspondance exacte entre routing key et binding. Fanout : diffusion à toutes les queues liées, routing key ignorée (pub/sub pur). Topic : pattern matching sur la clé segmentée par des points, avec `*` = exactement un mot et `#` = zéro ou plusieurs mots. Direct: exact match between routing key and binding. Fanout: broadcast to all bound queues, routing key ignored (pure pub/sub). Topic: pattern matching on the dot-separated key, with `*` = exactly one word and `#` = zero or more words.

Le broker détecte la fermeture du canal et remet le message en queue avec le flag redelivered ; un autre consumer le reprend. Rien n'est perdu (at-least-once), mais le traitement a pu être partiellement appliqué — d'où l'exigence d'idempotence côté consumer. The broker detects the channel closing and requeues the message with the redelivered flag; another consumer picks it up. Nothing is lost (at-least-once), but processing may have been partially applied — hence the idempotence requirement on the consumer side.

Auto-ack = at-most-once : le message est considéré livré dès l'envoi, un crash du consumer le perd. Ack manuel après traitement = at-least-once : rien n'est perdu, mais un crash entre traitement et ack produit un doublon. L'exactly-once de bout en bout n'existe pas sans coopération applicative. Auto-ack = at-most-once: the message is considered delivered as soon as it's sent, a consumer crash loses it. Manual ack after processing = at-least-once: nothing is lost, but a crash between processing and ack produces a duplicate. End-to-end exactly-once doesn't exist without application-level cooperation.

Parce que le at-least-once produit des doublons lors des redélivrances. Techniques : déduplication par message id (stocké en base avec contrainte unique, le doublon échoue proprement) ou opérations naturellement idempotentes (upsert, `SET status = 'paid'` plutôt que `balance += x`). Because at-least-once produces duplicates on redeliveries. Techniques: deduplication by message id (stored in the database with a unique constraint, the duplicate fails cleanly) or naturally idempotent operations (upsert, `SET status = 'paid'` rather than `balance += x`).

Une queue vers laquelle un dead-letter exchange (DLX) route les messages rejetés sans requeue, expirés (TTL) ou en dépassement de longueur max. Sans elle, un message empoisonné qui fait crasher le consumer revient en boucle et bloque la queue ; avec elle, on l'isole, on l'inspecte et on le rejoue. A queue to which a dead-letter exchange (DLX) routes messages rejected without requeue, expired (TTL) or overflowing the max length. Without it, a poison message that crashes the consumer loops forever and blocks the queue; with it, you isolate, inspect and replay it.

Rabbit est une queue : broker intelligent qui route finement, message supprimé après ack — idéal pour la distribution de tâches, le routage riche, la latence faible. Kafka est un log append-only : les messages restent, chaque consumer avance son offset — replay possible, lectures indépendantes du même flux, très haut débit via les partitions. Event streaming → Kafka ; task queues → Rabbit. Rabbit is a queue: a smart broker with fine-grained routing, messages deleted after ack — ideal for task distribution, rich routing, low latency. Kafka is an append-only log: messages stay, each consumer advances its offset — replay possible, independent reads of the same stream, very high throughput via partitions. Event streaming → Kafka; task queues → Rabbit.

Ressources identifiées par des URLs, interface uniforme HTTP (verbes GET/POST/PUT/PATCH/DELETE + codes de statut), statelessness (chaque requête porte tout son contexte), réponses cacheables. HATEOAS (liens vers les actions possibles dans les réponses) complète le modèle « pur », rarement implémenté. Resources identified by URLs, the uniform HTTP interface (GET/POST/PUT/PATCH/DELETE verbs + status codes), statelessness (each request carries its full context), cacheable responses. HATEOAS (links to possible actions inside responses) completes the "pure" model, rarely implemented.

401 Unauthorized = non authentifié : le serveur ne sait pas qui vous êtes (token absent, invalide ou expiré). 403 Forbidden = authentifié mais non autorisé : identité connue, droits insuffisants. Réessayer avec les mêmes credentials ne changera rien à un 403. 401 Unauthorized = not authenticated: the server doesn't know who you are (missing, invalid or expired token). 403 Forbidden = authenticated but not authorized: known identity, insufficient rights. Retrying with the same credentials won't change a 403.

Over-fetching : l'API renvoie plus de champs que nécessaire (40 champs pour en afficher 3). Under-fetching : un écran nécessite plusieurs appels enchaînés. GraphQL laisse le client décrire exactement les champs voulus, relations comprises, en un seul aller-retour sur un endpoint unique. Over-fetching: the API returns more fields than needed (40 fields to display 3). Under-fetching: one screen requires several chained calls. GraphQL lets the client describe exactly the fields it wants, relations included, in a single round trip on a single endpoint.

Avec des resolvers naïfs, une liste de N éléments dont chacun résout une relation (ex. l'auteur d'un post) déclenche 1 requête pour la liste + N requêtes pour les relations. Solution : le batching avec le pattern DataLoader, qui regroupe les chargements d'un même tick en une seule requête (WHERE id IN (...)) et déduplique. With naive resolvers, a list of N items each resolving a relation (e.g. a post's author) triggers 1 query for the list + N queries for the relations. Solution: batching with the DataLoader pattern, which groups same-tick loads into a single query (WHERE id IN (...)) and deduplicates.

Sérialisation protobuf binaire (champs numérotés, payloads compacts, parsing rapide), transport HTTP/2 (multiplexage sur une connexion persistante, compression d'en-têtes), code client/serveur généré depuis le contrat .proto, et streaming natif (server, client, bidirectionnel). Binary protobuf serialization (numbered fields, compact payloads, fast parsing), HTTP/2 transport (multiplexing over a persistent connection, header compression), client/server code generated from the .proto contract, and native streaming (server, client, bidirectional).

Une opération est idempotente si la rejouer produit le même état final qu'une seule exécution. GET, PUT et DELETE sont idempotents ; POST ne l'est pas. C'est crucial pour les retries : rejouer un POST de paiement sans idempotency key peut débiter deux fois. An operation is idempotent if replaying it produces the same final state as a single execution. GET, PUT and DELETE are idempotent; POST is not. This is crucial for retries: replaying a payment POST without an idempotency key can charge twice.

Offset (`?page=3&limit=20`) : simple, mais les éléments se décalent si la liste change entre deux pages, et OFFSET profond force la base à parcourir puis jeter des milliers de lignes. Cursor : un pointeur opaque après le dernier élément vu — stable et performant. À préférer par défaut pour les listes qui bougent. Offset (`?page=3&limit=20`): simple, but items shift if the list changes between pages, and a deep OFFSET forces the database to scan then discard thousands of rows. Cursor: an opaque pointer after the last seen item — stable and fast. Prefer it by default for lists that change.

API publique → REST (universel, cacheable, testable au curl). BFF ou client mobile agrégeant plusieurs sources → GraphQL (composition des données en un aller-retour). Microservices internes à fort trafic → gRPC (contrats stricts, perfs, streaming ; mais navigateur seulement via grpc-web + proxy). Public API → REST (universal, cacheable, curl-testable). BFF or mobile client aggregating several sources → GraphQL (data composition in one round trip). High-traffic internal microservices → gRPC (strict contracts, performance, streaming; but browsers only via grpc-web + proxy).

Un simple pointeur mutable vers un commit : un fichier de 41 octets dans `.git/refs/heads/` contenant un hash. L'historique est le graphe (DAG) des commits ; la branche n'est qu'une étiquette qui avance à chaque commit. D'où des branches instantanées et gratuites. Just a mutable pointer to a commit: a 41-byte file in `.git/refs/heads/` containing a hash. History is the graph (DAG) of commits; the branch is only a label that advances with each commit. Hence instant, free branching.

Merge crée un commit de fusion à deux parents et préserve l'historique tel qu'il s'est passé. Rebase rejoue chaque commit de la branche par-dessus la cible : nouveaux commits, nouveaux hashes, historique linéaire mais réécrit. Le résultat du code est le même, l'historique non. Merge creates a two-parent merge commit and preserves history as it happened. Rebase replays each commit of the branch on top of the target: new commits, new hashes, a linear but rewritten history. The resulting code is the same, the history is not.

Réécrire une série de commits avant de la partager : réordonner, fusionner (`squash`/`fixup`), reformuler (`reword`), modifier (`edit`) ou supprimer (`drop`) des commits. C'est l'outil standard pour nettoyer une branche avant d'ouvrir la PR. Rewrite a series of commits before sharing it: reorder, combine (`squash`/`fixup`), reword (`reword`), amend (`edit`) or delete (`drop`) commits. It's the standard tool for cleaning up a branch before opening the PR.

Il rejoue un commit précis sur la branche courante, en créant un nouveau commit (nouveau hash). Cas typique : reporter un hotfix de `main` vers une branche de release. Attention : le même changement existe alors deux fois dans l'historique si les branches sont mergées ensuite. It replays one specific commit onto the current branch, creating a new commit (new hash). Typical case: backporting a hotfix from `main` to a release branch. Beware: the same change then exists twice in history if the branches are later merged.

Recherche dichotomique du commit fautif : on marque un commit `bad` et un commit `good`, Git checkout le commit du milieu, on teste et on répond good/bad, jusqu'à isoler le coupable en log₂(n) étapes (1000 commits ≈ 10 tests). `git bisect run ./script.sh` automatise tout. Binary search for the offending commit: you mark one `bad` and one `good` commit, Git checks out the middle commit, you test and answer good/bad, until the culprit is isolated in log₂(n) steps (1000 commits ≈ 10 tests). `git bisect run ./script.sh` automates the whole thing.

`git reflog` journalise localement tous les déplacements de HEAD et des branches (~90 jours). Après un rebase raté ou un `reset --hard` malheureux, on retrouve le hash d'avant l'erreur et on restaure avec `git reset --hard HEAD@{n}`. Un commit non référencé n'est perdu qu'après passage du garbage collector. `git reflog` locally journals every move of HEAD and branches (~90 days). After a botched rebase or an unfortunate `reset --hard`, you find the hash from before the mistake and restore with `git reset --hard HEAD@{n}`. An unreferenced commit is only lost once the garbage collector runs.

Ne jamais rebaser des commits déjà poussés et partagés. Le rebase crée de nouveaux hashes : les collègues qui ont basé leur travail sur les anciens commits se retrouvent avec des historiques divergents pénibles à réconcilier. Rebase = uniquement sur ses commits locaux. Never rebase commits that have already been pushed and shared. Rebase creates new hashes: colleagues who based their work on the old commits end up with painfully diverged histories. Rebase = only on your local commits.

`--force` écrase la branche distante aveuglément, même si un collègue a poussé entre-temps (travail perdu). `--force-with-lease` échoue si la branche distante a bougé depuis le dernier fetch : même usage (pousser après un rebase), sans le risque. C'est le seul force push acceptable en équipe. `--force` blindly overwrites the remote branch, even if a colleague pushed in the meantime (lost work). `--force-with-lease` fails if the remote branch moved since your last fetch: same use (pushing after a rebase), without the risk. It's the only acceptable force push on a team.

La VM virtualise du matériel et embarque un OS complet avec son propre noyau via un hyperviseur. Le conteneur est un simple processus isolé (namespaces + cgroups) qui partage le noyau de l'hôte : démarrage en millisecondes et overhead de quelques Mo, contre minutes et Go pour la VM. A VM virtualizes hardware and ships a full OS with its own kernel via a hypervisor. A container is just an isolated process (namespaces + cgroups) sharing the host kernel: millisecond startup and a few MB of overhead, versus minutes and GBs for a VM.

Les namespaces (isolent ce que le processus voit : PID, réseau, montages, hostname…), les cgroups (limitent CPU/RAM/I/O) et un union filesystem comme OverlayFS (couches d'image en lecture seule + couche d'écriture éphémère). Namespaces (isolate what the process sees: PID, network, mounts, hostname…), cgroups (limit CPU/RAM/I/O) and a union filesystem like OverlayFS (read-only image layers + an ephemeral writable layer).

L'image est le modèle immuable construit depuis un Dockerfile (comme une classe) ; le conteneur est une instance en cours d'exécution de cette image (comme un objet), avec sa couche d'écriture propre et éphémère. The image is the immutable template built from a Dockerfile (like a class); the container is a running instance of that image (like an object), with its own ephemeral writable layer.

La couche d'écriture du conteneur disparaît avec lui. On monte donc un volume nommé (ou un bind mount) sur le répertoire de données, ex. `-v pgdata:/var/lib/postgresql/data` : le volume survit aux recréations du conteneur et se sauvegarde indépendamment. The container's writable layer disappears with it. You mount a named volume (or bind mount) on the data directory, e.g. `-v pgdata:/var/lib/postgresql/data`: the volume outlives container recreations and can be backed up independently.

Un Dockerfile avec plusieurs `FROM` : on compile dans une image lourde (SDK, outils de build) puis on copie uniquement l'artefact final dans une image runtime minimale. Résultat : image plus petite, plus rapide à distribuer, sans outils de build donc surface d'attaque réduite. A Dockerfile with several `FROM` stages: you compile in a heavy image (SDK, build tools) then copy only the final artifact into a minimal runtime image. Result: smaller image, faster to ship, no build tools inside so a reduced attack surface.

`ENTRYPOINT` définit l'exécutable fixe du conteneur ; `CMD` fournit ses arguments par défaut, remplaçables à l'exécution (`docker run image autre-arg`). Combinés : `ENTRYPOINT ["node"]` + `CMD ["server.js"]` lance `node server.js` par défaut. `ENTRYPOINT` sets the container's fixed executable; `CMD` provides its default arguments, overridable at run time (`docker run image other-arg`). Combined: `ENTRYPOINT ["node"]` + `CMD ["server.js"]` runs `node server.js` by default.

Ils sont placés sur un même réseau bridge dédié et se joignent par leur nom de service via le DNS interne de Docker (ex. `postgres:5432` depuis le conteneur applicatif). Pas besoin de publier les ports sur l'hôte pour la communication interne. They're placed on a dedicated bridge network and reach each other by service name through Docker's internal DNS (e.g. `postgres:5432` from the app container). No need to publish ports on the host for internal communication.

Chaque instruction crée une couche mise en cache ; modifier une instruction invalide toutes les couches suivantes. On place donc les étapes stables en premier (installation des dépendances) et le code source en dernier, pour que `docker build` ne réinstalle pas tout à chaque changement de code. Each instruction creates a cached layer; changing one invalidates all subsequent layers. Put stable steps first (dependency installation) and source code last, so `docker build` doesn't reinstall everything on every code change.