Une API (Application Programming Interface) est le contrat par lequel un logiciel expose des actions et des données à d'autres, sans leur dévoiler sa cuisine interne. Chacun s'appuie sur ce que l'API promet, pas sur la façon dont elle le fait, ce qui permet de faire évoluer un côté sans casser l'autre.

Quand l'application de livraison confirme ton paiement, elle n'a jamais vu le code de la banque : elle a juste appelé son API.


Le contrat par lequel deux logiciels se parlent : l'un expose des actions et des données, l'autre les consomme, sans rien savoir de la cuisine interne de l'autre.

Une assertion, c'est la ligne d'un test qui affirme ce qui doit être vrai : `expect(prix).toBe(80)`. Si la réalité ne colle pas à l'affirmation, le test échoue ; c'est le point précis où le code jure de tenir une promesse.

Le problème du `toBe(80)` tout nu, c'est qu'il dit *quoi* sans jamais dire *pourquoi* 80 : l'assertion grave la valeur, pas la décision qui la justifie.

À lire : [Le singe du pourquoi, édition dev](/blog/le-singe-du-pourquoi).


La ligne d'un test qui affirme ce qui doit être vrai. Si la réalité ne colle pas à l'affirmation, le test échoue.

Assertion

Une boîte noire, c'est un composant dont tu observes les entrées et les sorties sans voir ce qui se passe dedans : tu sais ce qu'il fait, pas comment. Tout l'art de reprendre un système consiste à transformer, une zone à la fois, ses boîtes noires en boîtes dont tu comprends l'intérieur.

Une application dont j'ai hérité était une boîte noire entière : des données entraient, des résultats sortaient, et le milieu restait un mystère.

À lire : [Lire un système qu'on n'a pas écrit](/dossier/lire-un-systeme).


Un composant dont tu observes les entrées et les sorties sans voir ce qui se passe dedans : tu sais ce qu'il fait, pas comment.

Boîte noire

Un bounded context, c'est une frontière à l'intérieur de laquelle un mot a un seul sens : « client » ne désigne pas la même chose au marketing et à la facturation, et prétendre le contraire fabrique des bugs. Repérer ces frontières, c'est découper un gros système en territoires où le vocabulaire reste cohérent.

Le mot qui changeait de sens selon l'endroit du code, c'était la couture entre deux bounded contexts.

À lire : [La carte que le code ne dessine pas](/blog/la-carte-que-le-code-ne-dessine-pas).


Une frontière à l'intérieur de laquelle un mot a un seul sens. « Client » ne veut pas dire la même chose au marketing et à la facturation.

Bounded context

Le bus est le canal de communication qui relie les composants d'un ordinateur (processeur, mémoire, disque) pour qu'ils échangent données et instructions. Tout ce qui circule entre deux pièces de la machine passe par lui, à une vitesse et une largeur données.

Lire un fichier, c'est le processeur qui demande, le disque qui répond, et le bus qui porte la conversation entre les deux.


Le canal de communication qui relie les composants d'un ordinateur, pour qu'ils échangent données et instructions.

`Cache-Control` est l'en-tête par lequel le serveur dit au navigateur combien de temps il peut garder une ressource sans rien revérifier (`max-age`), ou s'il ne doit pas la garder du tout. C'est toi qui règles la durée de fraîcheur, une fois.

Un `Cache-Control` long sur un fichier qui change, et tes utilisateurs gardent l'ancienne version aussi longtemps que tu le leur as dit, correctif déployé ou pas.

À lire : [Le bug que j'avais déjà corrigé](/blog/cache-http).


L'en-tête par lequel tu dis au navigateur combien de temps garder une ressource sans rien revérifier. L'ordre que tu poses une fois et qui te hante ensuite.

Cache-Control

Le cache DNS, c'est la mémoire à chaque étage de la chaîne (navigateur, système d'exploitation, résolveur) qui garde les réponses récentes pour éviter de refaire l'enquête à chaque appel. Il rend le web rapide, au prix d'une vérité parfois périmée : tant que le TTL tient, le cache répond de mémoire.

Toute la scène du fantôme tient dans un cache DNS qui n'avait pas encore expiré.

À lire : [DNS, le premier mensonge du web](/blog/dns-le-premier-mensonge-du-web).


La mémoire à chaque étage de la chaîne (navigateur, système, résolveur) qui garde les réponses récentes pour éviter de refaire l'enquête à chaque fois.

Cache DNS

Le cache HTTP, c'est la copie locale qu'un navigateur garde d'une ressource (un fichier, une image, un script) pour ne pas la redemander à chaque fois. Avant tout appel réseau, il regarde s'il l'a déjà sous une forme qu'il juge encore fraîche, et si oui, il la sert sans contacter personne.

Le bug « déjà corrigé » que voyait l'utilisateur, c'était un cache HTTP servant une version du fichier vieille de plusieurs semaines.

À lire : [Le bug que j'avais déjà corrigé](/blog/cache-http).


La copie locale qu'un navigateur garde d'une ressource pour éviter de la retélécharger. Il rend le web rapide, au prix d'une version parfois périmée que tu as toi-même autorisée.

Cache HTTP

La cartographie fonctionnelle, c'est la carte de ce qu'un système fait (ses capacités), pour qui (ses acteurs) et dans quels mots (le vocabulaire du métier), par opposition à la carte technique de ses services et de ses flux. C'est la carte du sens, pas de la plomberie, et la première dont tu as besoin quand tu découvres un système.

Face à un diagramme d'archi qui ne me disait rien de ce que le système faisait, c'est cette carte-là, tracée en un après-midi, qui m'a rendu la main.

À lire : [La carte que le code ne dessine pas](/blog/la-carte-que-le-code-ne-dessine-pas).


La carte de ce qu'un système fait, pour qui et dans quels mots, par opposition à la carte technique de ses services et de ses flux.

Cartographie fonctionnelle

Un cas limite, c'est l'entrée rare qui tombe pile à la frontière de ce que ton code prévoyait : la valeur zéro, la chaîne vide, le caractère qu'on n'attendait pas. Le programme marche pour tout le monde, sauf pour lui, et c'est précisément là qu'il casse en silence.

Le « + » dans une adresse email est un cas limite d'école : valide pour la norme, refusé par un formulaire qui n'avait testé que des adresses « normales ».

À lire : [Ne mens pas à tes utilisateurs](/blog/ne-pas-mentir).


L'entrée rare qui tombe pile à la frontière de ce que ton code prévoyait, et où il casse en silence.

Cas limite

Un certificat est le document signé par une autorité de confiance qui prouve qu'un serveur est bien celui qu'il prétend être. Le navigateur en vérifie la signature avant d'échanger quoi que ce soit de sensible, et refuse tout net si elle ne tient pas.

Le site tombé à minuit avait un certificat expiré : valide la veille, refusé le lendemain, sans une ligne de code modifiée.

À lire : [Le cadenas a une date de péremption](/blog/tls-le-cadenas).


Le document signé par une autorité de confiance qui prouve qu'un serveur est bien celui qu'il prétend être.

Certificat

Le chaos engineering, c'est provoquer volontairement des pannes (tuer une machine, couper une dépendance, ajouter de la latence) dans un cadre maîtrisé, pour observer comment le système réagit vraiment au lieu de l'espérer. L'écart entre la résilience supposée et la résilience réelle, c'est là que vivent les incidents.

Le serveur que personne n'ose redémarrer marque exactement l'endroit non testé : le chaos engineering va y voir en journée, avant que la panne ne choisisse son moment.

À lire : [Le serveur que tu n'oses pas redémarrer](/blog/chaos-engineering).


Provoquer volontairement des pannes, dans un cadre maîtrisé, pour découvrir comment un système échoue vraiment plutôt que de le supposer.

Chaos engineering

Le chemin de rendu critique, c'est la suite d'étapes que le navigateur doit franchir entre la réception du HTML et le premier pixel : construire le DOM, construire le CSSOM, calculer la mise en page, peindre. Tout ce qui bloque une de ces étapes retarde l'affichage.

Optimiser une page perçue comme lente, c'est raccourcir ce chemin, pas seulement accélérer le serveur qui, lui, avait déjà répondu.

À lire : [Le serveur répondait en 20 ms, l'écran restait blanc](/blog/rendu-ecran-blanc).


La suite d'étapes que le navigateur doit franchir entre la réception du HTML et le premier pixel affiché : DOM, CSSOM, mise en page, peinture.

Chemin de rendu critique

Chiffrer, c'est transformer un message en une bouillie illisible pour quiconque n'a pas la clé. Sur le web, TLS combine deux formes : l'asymétrique pour échanger la clé sans risque, puis la symétrique, plus rapide, pour la conversation elle-même.

Même si quelqu'un intercepte l'intégralité de ton échange HTTPS, sans la clé il ne voit que du bruit.

À lire : [Le cadenas a une date de péremption](/blog/tls-le-cadenas).


Transformer un message en bouillie illisible pour quiconque n'a pas la clé. Sur le web, TLS mêle chiffrement asymétrique (pour échanger la clé) et symétrique (pour la conversation).

Chiffrement

Quand un serveur répond à une requête, il commence toujours par un nombre à trois chiffres qui résume le sort de ta demande : 200 si tout va bien, 404 si la page n'existe pas, 500 s'il s'est cassé. C'est le premier mot du serveur, avant même le contenu, et souvent le plus honnête, parce qu'il range la réponse dans une catégorie précise au lieu de la noyer.

Le dimanche soir où un formulaire a renvoyé un 417 à ma femme sans jamais l'afficher, le code disait déjà tout : demande rejetée, et le serveur savait pourquoi.

À lire : [Ne mens pas à tes utilisateurs](/blog/ne-pas-mentir).


Le nombre à trois chiffres par lequel un serveur résume le sort de ta requête, avant même d'envoyer le contenu.

Code de statut HTTP

La cohésion mesure à quel point un morceau de code fait une seule chose, bien : un module cohésif rassemble ce qui va ensemble, un module peu cohésif est un fourre-tout. Forte cohésion et faible couplage sont les deux faces d'un système qu'on peut comprendre par morceaux, au lieu de devoir tout tenir dans sa tête d'un coup.

Quand un fichier hérité mélange dix responsabilités sans lien, ce n'est pas toi qui es lent : c'est sa cohésion qui est en ruine.

À lire : [Lire un système qu'on n'a pas écrit](/dossier/lire-un-systeme).


À quel point un morceau de code fait une seule chose, bien. Forte cohésion et faible couplage : les deux faces d'un système qu'on peut comprendre par morceaux.

Cohésion

La connaissance tribale, c'est ce que l'équipe sait sans que ce soit écrit nulle part : les pièges, les « touche pas à ça », les raisons oubliées, transmises de bouche à oreille. Elle est précieuse et dangereuse à la fois, parce qu'elle disparaît le jour où la personne qui la détient s'en va.

La seule personne qui savait encore que « les relances, c'est fragile » n'avait rien écrit : c'était de la connaissance tribale, et elle allait partir avec.

À lire : [Faire avouer un système](/blog/faire-avouer-un-systeme).


Ce que l'équipe sait sans que ce soit écrit nulle part : les pièges, les « touche pas à ça », les raisons oubliées, transmises de bouche à oreille.

Connaissance tribale

Un cookie est une petite donnée qu'un serveur dépose dans ton navigateur, et que celui-ci rattache automatiquement à chaque requête vers le même domaine. C'est ainsi qu'un site te reconnaît d'une page à l'autre sans te redemander ton mot de passe : le cookie voyage seul, à ton insu.

Ce voyage automatique est justement ce que CORS existe pour encadrer : sans garde-fou, n'importe quel site profiterait de ton cookie de session.

À lire : [Pourquoi les CORS veulent faire sauter ton navigateur ?](/blog/pourquoi-les-cors-veulent-faire-sauter-votre-navigateur).


Un petit fichier que le serveur dépose dans ton navigateur et que celui-ci renvoie à chaque requête vers ce domaine. C'est ce qui te garde connecté.

Cookie

Le corps de requête, c'est la charge utile transportée : le JSON que tu poses dans un `POST`, le HTML qu'un serveur te renvoie en réponse. C'est le contenu de la lettre, par opposition aux en-têtes qui en sont l'enveloppe.

Une requête peut avoir un corps parfait et échouer quand même, si l'en-tête qui annonce son format le décrit de travers.

À lire : [Le bug était dans l'enveloppe](/blog/requete-http).


La charge utile d'une requête ou d'une réponse : le JSON que tu envoies, le HTML qu'on te renvoie. Le contenu, par opposition à l'enveloppe des en-têtes.

Corps de requête

CORS (Cross-Origin Resource Sharing) est le mécanisme par lequel un serveur déclare quels autres domaines ont le droit d'appeler ses ressources depuis un navigateur. Par défaut, le navigateur bloque ces appels cross-origin ; CORS est la façon d'autoriser des exceptions, proprement.

L'erreur rouge que tu maudis dans la console, c'est souvent CORS qui fait son travail : empêcher un site tiers de se servir de la session ouverte dans ton autre onglet.

À lire : [Pourquoi les CORS veulent faire sauter ton navigateur ?](/blog/pourquoi-les-cors-veulent-faire-sauter-votre-navigateur).


Les entêtes CORS décident quelles pages d'un autre domaine ont le droit d'accéder à une ressource : le videur qui contrôle la frontière entre deux origines.

CORS

Le couplage mesure à quel point deux morceaux de code dépendent l'un de l'autre : fortement couplés, tu ne peux pas toucher l'un sans risquer de casser l'autre. C'est la raison pour laquelle un petit changement, dans un système mal découpé, provoque des dégâts à l'autre bout.

Cartographier un système qu'on n'a pas écrit, c'est d'abord repérer où le couplage est fort, pour savoir où poser les mains fait mal.

À lire : [Lire un système qu'on n'a pas écrit](/dossier/lire-un-systeme).


À quel point deux morceaux de code dépendent l'un de l'autre. Fortement couplés, tu ne peux pas toucher l'un sans risquer de casser l'autre.

Couplage

La couverture de code mesure quelle proportion de tes lignes est exécutée par les tests. C'est un indicateur de quantité, jamais de qualité : 100 % de couverture prouve que le code a été parcouru, pas qu'on a vérifié la bonne chose, ni compris pourquoi.

Une suite générée peut afficher 90 % de couverture et zéro pourquoi : beaucoup d'assertions vertes, aucune raison de vivre.

À lire : [Le singe du pourquoi, édition dev](/blog/le-singe-du-pourquoi).


La proportion de tes lignes exécutée par les tests. Un indicateur de quantité, pas de qualité : couvrir n'est pas comprendre.

Couverture de code

Le CSSOM (CSS Object Model) est l'arbre des styles que le navigateur construit à partir du CSS, en parallèle du DOM. En combinant les deux, il sait enfin quoi afficher (le DOM) et comment (le CSSOM), avant de calculer la mise en page et de peindre.

Tant que le CSSOM n'est pas prêt, le navigateur évite de peindre : il ne veut pas te montrer une page sans style qu'il faudrait redessiner juste après.

À lire : [Le serveur répondait en 20 ms, l'écran restait blanc](/blog/rendu-ecran-blanc).


L'arbre des styles, construit à partir du CSS. Combiné au DOM, il permet au navigateur de calculer où va chaque élément et de quoi il a l'air.

CSSOM

La défense en profondeur, c'est empiler plusieurs protections imparfaites mais indépendantes, de sorte qu'une faille dans l'une soit rattrapée par la suivante. Aucune couche n'est parfaite ; c'est leur indépendance qui empêche les trous de s'aligner en un couloir.

Ce n'est pas le fantasme du mur parfait, c'est s'assurer que le jour où une couche cède, la suivante tient encore.

À lire : [Le modèle du gruyère](/dossier/gruyere).


Empiler plusieurs protections imparfaites mais indépendantes, pour qu'un trou dans l'une soit couvert par la suivante. Le principe du modèle du gruyère.

Défense en profondeur

Une dépendance, c'est le fait qu'une chose ait besoin d'une autre pour fonctionner : un module qui en appelle un autre, une capacité qui en présuppose une autre. Cartographier les dépendances, c'est connaître l'ordre des dominos, savoir ce qui tombe si tu touches à un maillon.

Sur ma carte fonctionnelle, « passer une commande » dépendait de « vérifier le stock » : casse le second, le premier meurt en silence.

À lire : [La carte que le code ne dessine pas](/blog/la-carte-que-le-code-ne-dessine-pas).


Le fait qu'une chose ait besoin d'une autre pour fonctionner. Connaître les dépendances, c'est connaître l'ordre des dominos.

Dépendance

La dette technique, c'est le coût futur des raccourcis pris aujourd'hui : un choix rapide qui dépanne maintenant et qu'il faudra rembourser, avec intérêts, à chaque modification suivante. Comme une dette d'argent, elle est parfois un bon calcul, à condition de savoir qu'on l'a contractée.

Dans un système hérité sans doc, la pire dette est invisible : plus personne ne se souvient du raccourci, donc personne ne sait ce qu'il coûtera.

À lire : [Lire un système qu'on n'a pas écrit](/dossier/lire-un-systeme).


Le coût futur des raccourcis pris aujourd'hui : un choix rapide qui dépanne maintenant et qu'il faudra rembourser, avec intérêts, à chaque modification suivante.

Dette technique

Le DNS (Domain Name System) est l'annuaire du web : il traduit un nom de domaine lisible, comme exemple.com, en l'adresse IP qu'une machine sait réellement joindre. Sans lui il faudrait retenir des suites de chiffres ; avec lui, la traduction se refait à chaque fois que tu tapes une adresse.

Le collègue qui voyait encore l'ancienne version butait sur un détail du DNS : sa réponse n'est presque jamais lue en direct, mais dans un cache.

À lire : [DNS, le premier mensonge du web](/blog/dns-le-premier-mensonge-du-web).


L'annuaire du web : il traduit un nom de domaine lisible (exemple.com) en l'adresse IP qu'une machine sait joindre.

Docker empaquette une application avec tout ce dont elle a besoin (bibliothèques, configuration, dépendances) dans un conteneur isolé. Contrairement à une machine virtuelle, ce conteneur partage le système de l'hôte, ce qui le rend léger et rapide à démarrer.

« Ça marche sur ma machine » cesse d'être une excuse le jour où la machine part, justement, avec l'application dans le conteneur.


Empaqueter une application avec tout ce dont elle a besoin dans un conteneur isolé, pour qu'elle tourne pareil partout, de ta machine au serveur.

Docker

La documentation vivante, c'est une doc qui reste vraie parce qu'elle est branchée sur la réalité du système : générée ou vérifiée depuis le code, les tests, les schémas, plutôt qu'un document figé qui pourrit dès qu'on le referme. Sa promesse : ne pas te mentir, parce qu'elle n'a pas le temps de vieillir.

Face à une doc morte qui décrivait une version disparue, tout ce que je cherchais, c'était une source qui vieillisse moins vite que la mémoire des gens.

À lire : [Faire avouer un système](/blog/faire-avouer-un-systeme).


Une doc qui reste vraie parce qu'elle est branchée sur la réalité du système (générée ou vérifiée depuis le code), au lieu de pourrir dès qu'on la referme.

Documentation vivante

Le DOM (Document Object Model) est l'arbre de tous les éléments d'une page, que le navigateur construit à partir du HTML reçu. C'est à la fois le point de départ de l'affichage et ce que ton JavaScript manipule ensuite pour rendre la page interactive.

Le modifier n'est pas gratuit : touche-le cent fois dans une boucle et tu déclenches cent recalculs, la page saccade.

À lire : [Le serveur répondait en 20 ms, l'écran restait blanc](/blog/rendu-ecran-blanc).


L'arbre de tous les éléments d'une page, construit par le navigateur à partir du HTML. C'est ce que ton JavaScript manipule pour rendre la page vivante.

Le domaine, c'est le champ de réalité que ton logiciel sert : la banque, la réservation, la logistique, avec ses règles et ses mots à lui, qui existent indépendamment du code. Comprendre un système, c'est d'abord comprendre son domaine, parce que le code n'en est qu'une traduction, souvent maladroite.

Le vocabulaire que je récoltais dans les routes et les tables, c'était le domaine qui affleurait sous le code.

À lire : [La carte que le code ne dessine pas](/blog/la-carte-que-le-code-ne-dessine-pas).


Le champ de réalité que ton logiciel sert (la banque, la réservation, la logistique), avec ses règles et ses mots à lui, qui existent indépendamment du code.

Domaine

DRY (Don't Repeat Yourself) tient en une phrase : chaque règle, chaque connaissance d'un système ne doit vivre qu'à un seul endroit. Dupliquer une logique, c'est s'engager à la corriger partout à la fois le jour où elle change, et à en rater fatalement une copie.

Le jour où j'ai corrigé le même bug à trois endroits, et raté le quatrième, j'ai compris ce que coûte vraiment un copier-coller.


Don't Repeat Yourself : chaque connaissance d'un système ne doit exister qu'à un seul endroit. Dupliquer une logique, c'est signer pour la corriger partout, et en oublier la moitié.

Un en-tête HTTP, c'est une métadonnée attachée à une requête ou une réponse : qui tu es (`Authorization`), ce que tu envoies (`Content-Type`), ce que tu sais recevoir (`Accept`), tes cookies. C'est le contrat silencieux qui dit au serveur comment lire tout le reste.

On débogue le corps de la requête pendant des heures, alors que le mensonge est presque toujours dans un en-tête que personne ne relit.

À lire : [Le bug était dans l'enveloppe](/blog/requete-http).


Les métadonnées d'une requête ou d'une réponse : qui tu es, ce que tu envoies, ce que tu acceptes. Le contrat silencieux que le serveur lit avant le contenu.

En-tête HTTP

Un enregistrement A associe directement un nom de domaine à une adresse IP ; un CNAME associe un nom à un autre nom, un alias qu'il faudra résoudre à son tour. L'un pointe vers une machine, l'autre renvoie vers un nom, à charge de recommencer la traduction.

Sur le serveur d'autorité, c'est l'un de ces deux enregistrements que le résolveur récupère, avec son TTL greffé dessus.

À lire : [DNS, le premier mensonge du web](/blog/dns-le-premier-mensonge-du-web).


Un A associe un nom de domaine à une adresse IP ; un CNAME associe un nom à un autre nom, un alias à résoudre à son tour.

Enregistrement A / CNAME

Les codes de statut HTTP se rangent en familles. Les 4xx désignent une erreur du côté de celui qui demande (400 mauvaise requête, 403 interdit, 404 introuvable) : le problème est chez toi, et il est souvent corrigeable. Les 5xx désignent une panne du côté du serveur (500 erreur interne, 503 indisponible) : là, tu ne peux qu'attendre.

Tout le drame du formulaire de ma femme tient dans cette confusion : un 4xx corrigeable en deux secondes, affiché comme s'il n'y avait plus rien à faire.

À lire : [Ne mens pas à tes utilisateurs](/blog/ne-pas-mentir).


Les 4xx disent que le problème est chez celui qui demande (souvent corrigeable) ; les 5xx, qu'il est chez le serveur (tu ne peux qu'attendre).

Erreur 4xx vs 5xx

Un ETag est une étiquette qui identifie une version précise d'une ressource. Quand sa copie a expiré, le navigateur peut demander « j'ai la version portant cet ETag, est-elle toujours d'actualité ? » au lieu de tout retélécharger à l'aveugle.

Le serveur répond alors soit « rien n'a changé, garde la tienne » (une réponse minuscule), soit il renvoie la nouvelle version.

À lire : [Le bug que j'avais déjà corrigé](/blog/cache-http).


L'étiquette qui identifie une version précise d'une ressource. Elle permet au navigateur de demander « c'est toujours la bonne ? » sans tout retélécharger.

ETag

FIFO (First In, First Out) décrit un ordre où le premier entré est le premier sorti, exactement comme une file d'attente à la caisse. C'est le fonctionnement naturel d'une file (queue) : on traite les éléments dans l'ordre où ils sont arrivés.

Une file de messages en FIFO garantit qu'un événement arrivé avant est traité avant, ce qui compte bien plus qu'on ne le croit.


First In, First Out : le premier arrivé est le premier servi, comme une file d'attente à la caisse.

FIFO

FTP (File Transfer Protocol) est l'un des plus vieux protocoles pour transférer des fichiers entre deux machines : on se connecte à un serveur, on navigue dans ses dossiers, on envoie ou récupère des fichiers. Son défaut est aussi vieux que lui : tout circule en clair, mot de passe compris.

C'est pour ça qu'on lui préfère aujourd'hui ses cousins chiffrés comme SFTP : FTP fait le travail, mais sans rideaux aux fenêtres.


File Transfer Protocol : un vieux protocole pour transférer des fichiers entre machines. Simple, mais qui fait tout circuler en clair, mot de passe compris.

Le handshake TCP, ou poignée de main, est l'échange en trois paquets (SYN, SYN-ACK, ACK) par lequel deux machines établissent qu'elles s'entendent avant d'échanger quoi que ce soit. Trois temps, parce que chaque camp doit prouver que sa voix porte dans les deux sens.

Tant que ce handshake n'a pas abouti, aucune requête ne part : « connecté » se décide là, et nulle part ailleurs.

À lire : [Trois paquets avant de se parler](/blog/handshake-tcp).


La poignée de main en trois paquets (SYN, SYN-ACK, ACK) par laquelle deux machines établissent qu'elles s'entendent avant d'échanger la moindre donnée.

Handshake TCP

Le handshake TLS est l'échange, juste après celui de TCP, où le client et le serveur vérifient l'identité (via le certificat) et se mettent d'accord sur des clés de chiffrement. À la fin, la connexion est à la fois privée et authentifiée.

C'est lui qui ferme le cadenas : tant qu'il n'a pas abouti, aucune donnée ne circule, même chiffrée.

À lire : [Le cadenas a une date de péremption](/blog/tls-le-cadenas).


L'échange, juste après celui de TCP, où client et serveur vérifient l'identité et se mettent d'accord sur des clés de chiffrement.

Handshake TLS

KISS (Keep It Simple, Stupid) rappelle qu'entre deux solutions qui marchent, la plus simple gagne presque toujours. La complexité n'est pas une preuve d'intelligence, c'est une dette que quelqu'un, souvent toi plus tard, devra rembourser.

La moitié des systèmes que j'ai galéré à reprendre étaient malins là où ils auraient dû être bêtes.


Keep It Simple, Stupid : entre deux solutions qui marchent, choisis la plus simple. La complexité n'est pas un signe d'intelligence, c'est une dette à rembourser.

KISS

Le langage ubiquitaire, c'est le vocabulaire partagé entre les développeurs et les gens du métier, utilisé à l'identique dans les conversations et dans le code. Quand le code et le métier appellent la même chose du même nom, la traduction disparaît, et avec elle une source d'erreurs sans fin.

Le jour où j'ai vu le « créneau » du client devenir « slot » dans le code, j'ai vu un langage ubiquitaire qui n'avait jamais été tenu.

À lire : [La carte que le code ne dessine pas](/blog/la-carte-que-le-code-ne-dessine-pas).


Le vocabulaire partagé entre développeurs et gens du métier, utilisé à l'identique dans les conversations et dans le code. Quand la traduction disparaît, les bugs de traduction aussi.

Langage ubiquitaire

Le legacy, c'est le code déjà là quand tu arrives : en production, souvent critique, écrit par d'autres, rarement documenté à jour. Ce n'est pas un défaut, c'est l'état normal de presque tout code qui a de la valeur, celui qui a survécu assez longtemps pour qu'on doive encore compter dessus.

L'application dont j'ai hérité un jour était du legacy pur : critique, en production, et ses auteurs partis depuis longtemps.

À lire : [Lire un système qu'on n'a pas écrit](/dossier/lire-un-systeme).


Le code déjà là quand tu arrives : en production, souvent critique, écrit par d'autres, rarement documenté à jour. L'état normal de presque tout code qui a de la valeur.

Legacy

LIFO (Last In, First Out) décrit un ordre où le dernier entré est le premier sorti, comme une pile d'assiettes dont tu prends toujours celle du dessus. C'est le fonctionnement d'une pile (stack) : on retire d'abord le dernier élément posé.

La pile d'appels de ton programme est un LIFO : la dernière fonction appelée est la première à rendre la main.


Last In, First Out : le dernier arrivé est le premier servi, comme une pile d'assiettes où tu prends celle du dessus.

LIFO

Un message d'erreur, c'est ce que le système te dit quand quelque chose échoue. Sa seule mission utile : que la personne en face comprenne ce qui s'est passé et, si elle le peut, comment le réparer.

« Erreur technique, réessayez plus tard » remplit l'écran sans rien dire ; il cache la raison que le serveur connaissait déjà. Un bon message d'erreur ne ment pas par omission.

À lire : [Ne mens pas à tes utilisateurs](/blog/ne-pas-mentir).


Ce que le système dit quand quelque chose échoue. Sa seule mission utile : que la personne en face comprenne, et sache quoi faire.

Message d'erreur

La méthode HTTP est le verbe d'une requête, celui qui dit l'intention : `GET` lit sans rien changer, `POST` crée ou modifie, `PUT`, `DELETE`, et les autres. Toute une machinerie invisible (caches, proxys, nouvelles tentatives) fait confiance à ce verbe.

Utilise un `GET` pour une action qui modifie, et un jour un cache te resservira un vieux résultat, ou le navigateur rejouera l'action seul.

À lire : [Le bug était dans l'enveloppe](/blog/requete-http).


Le verbe d'une requête, qui dit l'intention : GET lit sans rien changer, POST crée ou modifie. Une promesse sur laquelle caches et proxys comptent.

Méthode HTTP

Le moindre privilège, c'est ne donner à chaque partie d'un système (un service, un compte, une clé) que les droits strictement nécessaires à sa tâche, jamais le maximum par confort. Ainsi, un composant compromis ne peut rien faire de plus que son travail.

C'est le réflexe qui limite les dégâts : la question n'est pas « de quoi ça pourrait avoir besoin un jour », mais « qu'est-ce que ça ouvre si on le compromet ».

À lire : [Ce qui tombe ne doit pas tout emporter](/blog/cloisonnement).


Ne donner à chaque partie d'un système que les droits strictement nécessaires à son travail, pas le maximum confortable.

Moindre privilège

Le modèle OSI découpe la communication réseau en sept couches empilées, du câble physique tout en bas jusqu'à l'application tout en haut. Chaque couche ne s'occupe que de son rôle et ne parle qu'à ses voisines, ce qui permet de raisonner sur un étage sans porter tout le reste.

Quand tu débogues un souci réseau, situer le problème sur la bonne couche (le câble ? le routage ? l'appli ?) fait déjà la moitié du diagnostic.


Un découpage de la communication réseau en sept couches, du câble physique jusqu'à l'application, chaque couche ne s'occupant que de son étage.

Modèle OSI

Un paquet est l'unité de base d'un échange réseau : les données sont découpées en petits morceaux, chacun avec une étiquette (d'où il vient, où il va, sa place dans l'ordre). Le réseau ne transporte pas des messages, il transporte des paquets qu'on rassemble à l'arrivée.

Les SYN et ACK d'une poignée de main sont des paquets de contrôle, échangés avant même le premier paquet de données.

À lire : [Trois paquets avant de se parler](/blog/handshake-tcp).


L'unité de base d'un échange réseau : les données sont découpées en petits morceaux étiquetés, que l'on rassemble à l'arrivée.

Paquet

Un port est le numéro qui désigne quelle application, sur une machine, doit recevoir une connexion : l'adresse IP mène à la machine, le port mène au bon programme dessus. Le web écoute en général sur le port 443 (HTTPS) ou 80 (HTTP).

« Connexion refusée » veut souvent dire exactement ceci : la machine est bien là, mais personne n'écoute sur ce port.

À lire : [Trois paquets avant de se parler](/blog/handshake-tcp).


Le numéro qui désigne quelle application, sur une machine, doit recevoir une connexion : l'IP mène à la machine, le port mène au bon programme dessus.

Port

Le rayon d'explosion (blast radius), c'est l'étendue des dégâts qu'une panne, une erreur ou une intrusion peut provoquer avant d'être contenue. Un petit rayon, c'est un incident local ; un grand rayon, c'est tout le système qui tombe pour une seule cause.

On le réduit des deux côtés : en cadrant une expérience de chaos engineering, et en cloisonnant l'architecture pour qu'un problème reste là où il est né.

À lire : [Le serveur que tu n'oses pas redémarrer](/blog/chaos-engineering).


L'étendue des dégâts qu'une panne peut provoquer. Le limiter, c'est s'assurer que ce qui casse d'un côté n'emporte pas tout le reste.

Rayon d'explosion

Une régression, c'est un comportement qui marchait et qui casse à cause d'une modification, souvent ailleurs que là où tu as touché. C'est la panne la plus vicieuse, parce que tu croyais avancer et tu as reculé sans le voir.

Tout le drame du test rouge tient là : est-ce une vraie régression que j'ai introduite, ou une attente devenue périmée ? Sans le pourquoi du test, impossible de trancher.

À lire : [Le singe du pourquoi, édition dev](/blog/le-singe-du-pourquoi).


Un comportement qui marchait et qui casse à cause d'une modification, souvent ailleurs que là où tu as touché.

Régression

Une requête HTTP est la demande qu'un client adresse à un serveur. Elle tient en trois parties : une ligne (le verbe et la cible, comme `GET /utilisateurs`), des en-têtes qui disent au serveur comment lire le reste, et parfois un corps, la charge utile.

Le bug qui « venait du serveur » venait en fait d'un en-tête de la requête : la lettre était bonne, l'enveloppe mentait.

À lire : [Le bug était dans l'enveloppe](/blog/requete-http).


La demande qu'un client envoie à un serveur : un verbe et une cible, des en-têtes qui disent comment la lire, et parfois un corps.

Requête HTTP

La résilience, c'est la capacité d'un système à continuer de rendre son service malgré la défaillance d'un de ses composants : une machine tombe, une autre prend le relais, l'utilisateur ne voit rien. C'est une propriété qui se vérifie en provoquant la panne, pas qui se déduit du code.

Un système qu'on n'a jamais vu tomber n'est pas résilient : c'est un système dont on ignore encore comment il tombe.

À lire : [Le serveur que tu n'oses pas redémarrer](/blog/chaos-engineering).


La capacité d'un système à continuer de fonctionner malgré une panne d'un de ses composants. Une propriété qui se prouve en cassant, pas qui se suppose.

Résilience

Le résolveur, c'est le service qui mène l'enquête DNS à ta place : il reçoit un nom et interroge les serveurs (racine, TLD, autorité) jusqu'à obtenir l'adresse IP. C'est en général celui de ton fournisseur d'accès ou un résolveur public, et il garde en cache ce qu'il a trouvé, pour des milliers d'utilisateurs à la fois.

Quand ton collègue voyait un fantôme, c'est le cache de son résolveur qui tenait encore l'ancienne adresse.

À lire : [DNS, le premier mensonge du web](/blog/dns-le-premier-mensonge-du-web).


Le service qui mène l'enquête DNS à ta place : il reçoit un nom et interroge les serveurs jusqu'à obtenir l'adresse IP, en gardant ses trouvailles en cache.

Résolveur

REST est un style d'API qui s'appuie sur ce qu'HTTP offre déjà : chaque chose est une ressource identifiée par une URL, et les verbes HTTP disent quoi en faire (GET pour lire, POST pour créer, DELETE pour supprimer). Pas de vocabulaire à réinventer, on emprunte celui du web.

Récupérer un utilisateur, c'est un GET sur son URL ; le supprimer, un DELETE sur la même : l'adresse ne change pas, l'intention si.

À lire : [Le bug était dans l'enveloppe](/blog/requete-http).


Un style d'API qui réutilise ce qu'HTTP offre déjà : chaque chose est une ressource adressable par une URL, et les verbes HTTP disent quoi en faire.

REST

La rétro-ingénierie, c'est reconstruire l'intention et le fonctionnement d'un système à partir du résultat, quand les plans ont disparu : lire le code, observer le comportement, et remonter au pourquoi. C'est l'enquête de base face à tout ce que tu n'as pas écrit toi-même.

Comprendre cette application sans ses auteurs, c'était de la rétro-ingénierie : partir de ce qu'elle faisait pour deviner ce qu'elle avait voulu faire.

À lire : [Lire un système qu'on n'a pas écrit](/dossier/lire-un-systeme).


Reconstruire l'intention et le fonctionnement d'un système à partir du résultat, quand les plans ont disparu : lire le code, observer le comportement, remonter au pourquoi.

Rétro-ingénierie

La revalidation, c'est le régime « demander mais pour pas cher » du cache. Quand une copie a expiré, plutôt que de la retélécharger entière, le navigateur vérifie auprès du serveur (souvent via un ETag) si elle est toujours d'actualité, et ne la recharge que si elle a changé.

C'est le compromis entre servir du périmé et tout retélécharger : on paie une petite question au lieu d'un gros transfert.

À lire : [Le bug que j'avais déjà corrigé](/blog/cache-http).


Le régime « demander mais pour pas cher » du cache : plutôt que retélécharger une ressource expirée, le navigateur vérifie juste si sa copie est encore bonne.

Revalidation

RPC (Remote Procedure Call) consiste à appeler une fonction qui tourne sur une autre machine comme si elle était juste là, dans ton code. Pratique, mais l'illusion a un prix : un appel local ne connaît pas le timeout ni la panne réseau, un RPC si.

Traiter un appel distant comme un appel local, c'est oublier que le réseau entre les deux a le droit de te mentir.


Remote Procedure Call : appeler une fonction qui s'exécute sur une autre machine comme si elle était locale, en masquant le réseau derrière un appel ordinaire.

Le sachant, c'est la personne qui détient la connaissance d'un système sans qu'elle soit écrite : celui qu'on finit toujours par aller voir quand ça casse. Il est le dépositaire de la connaissance tribale, et souvent, sans le vouloir, un SPOF humain à lui seul.

Toute la partie utile de mon enquête tenait dans une demi-heure avec le bon sachant, à condition de ne pas lui souffler les réponses.

À lire : [Faire avouer un système](/blog/faire-avouer-un-systeme).


La personne qui détient la connaissance d'un système sans qu'elle soit écrite : celui qu'on finit toujours par aller voir quand ça casse.

Sachant

Un script bloquant est un `<script>` qui fige la construction de la page tant qu'il n'est pas téléchargé et exécuté. Le navigateur l'attend parce qu'un script a le droit de réécrire le document, et il n'ose rien afficher qui pourrait disparaître aussitôt.

Un réseau parfait plus un script bloquant en haut de page, et l'utilisateur fixe du blanc : le remède, c'est `defer` ou une place en bas de page.

À lire : [Le serveur répondait en 20 ms, l'écran restait blanc](/blog/rendu-ecran-blanc).


Un script qui arrête la construction de la page le temps d'être téléchargé et exécuté, parce qu'il pourrait la réécrire. La cause classique de l'écran blanc.

Script bloquant

La segmentation, ou cloisonnement, c'est isoler un système en zones pour qu'un problème reste contenu là où il apparaît : la base n'est pas joignable depuis le web public, un service ne parle qu'à ceux qu'il doit. On bâtit des murs pour raccourcir le rayon d'explosion.

Un système plat où tout se fait confiance, c'est une pile de tranches de gruyère dont les trous sont déjà alignés : une seule brèche ouvre le couloir vers le tout.

À lire : [Ce qui tombe ne doit pas tout emporter](/blog/cloisonnement).


Isoler un système en zones étanches pour qu'un problème (panne ou intrusion) reste là où il est né, au lieu de se propager partout.

Segmentation

SemVer (versionnage sémantique) est une convention de numérotation en trois parties, MAJEUR.MINEUR.CORRECTIF. Le majeur augmente quand quelque chose casse la compatibilité, le mineur quand on ajoute sans rien casser, le correctif pour un simple fix : le numéro raconte donc ce que la mise à jour va te faire.

Passer de 1.4.2 à 2.0.0, c'est prévenir tout le monde noir sur blanc : quelque chose va casser si tu ne fais rien.


Le versionnage sémantique : un numéro en trois parties, MAJEUR.MINEUR.CORRECTIF, où chaque partie a un sens précis et prévient de ce qui change.

SemVer

Un socket est le point de connexion par lequel deux programmes échangent des données, que ce soit sur la même machine ou à travers le réseau. Il combine une adresse et un port pour désigner exactement quel programme, sur quelle machine, doit recevoir la conversation.

Derrière chaque connexion web ouverte, il y a un socket qui tient la ligne entre ton programme et l'autre bout.

À lire : [Trois paquets avant de se parler](/blog/handshake-tcp).


Le point de connexion par lequel deux programmes échangent des données, sur la même machine ou à travers le réseau.

Socket

SOLID est un ensemble de cinq principes de conception orientée objet, dont le plus utile au quotidien : chaque module ne devrait avoir qu'une seule raison de changer. L'idée d'ensemble est d'écrire du code qu'on peut faire évoluer sans que tout se casse à côté.

Un fichier qui change à chaque nouvelle demande, quelle qu'elle soit, viole SOLID avant même qu'on ouvre le débat théorique.


Cinq principes de conception orientée objet. Le plus utile au quotidien : chaque module ne devrait avoir qu'une seule raison de changer.

SOLID

La source de vérité, c'est l'endroit qui fait autorité quand deux informations se contredisent : celui qu'on croit par définition, parce que tous les autres n'en sont que des copies. Un système sain en a une par donnée ; un système malade en a trois qui se disputent.

Quand la doc, le code et le sachant disaient trois choses différentes, ma première question était : lequel des trois fait foi ?

À lire : [Faire avouer un système](/blog/faire-avouer-un-systeme).


L'endroit qui fait autorité quand deux informations se contredisent : celui qu'on croit par définition, parce que les autres n'en sont que des copies.

Source de vérité

Un SPOF (single point of failure), c'est le maillon dont la défaillance suffit, à elle seule, à faire tomber tout le reste : un serveur unique, un service sans réplique, ou une personne qui est la seule à savoir. Le repérer, c'est identifier là où le système n'a aucun filet.

Le pire SPOF que j'aie rencontré n'était pas une machine, c'était un humain : une seule tête tenait la moitié du système.

À lire : [Faire avouer un système](/blog/faire-avouer-un-systeme).


Single point of failure : le maillon dont la défaillance à lui seul fait tomber tout le reste. Parfois une machine, parfois une personne.

SPOF

SSH (Secure Shell) est le protocole qui ouvre une connexion chiffrée vers une machine distante, pour y exécuter des commandes comme si tu étais assis devant. Il reste strictement dans son domaine, établir cette connexion sûre, et le fait bien.

Copier un fichier à travers SSH ? C'est le rôle de `scp`, pas de `ssh` : chacun sa chose, et c'est toute la force de ces outils.

À lire : [Et si je foutais cette feature à la poubelle ?](/blog/et-si-je-foutais-cette-feature-la-poubelle).


Secure Shell : le protocole qui ouvre une connexion chiffrée vers une machine distante, pour y taper des commandes comme si tu étais devant.

TCP (Transmission Control Protocol) est le protocole qui garantit qu'un message arrive complet, dans l'ordre, ou que tu sauras qu'il a échoué. Il établit une connexion fiable entre deux machines, au prix d'un peu de cérémonial avant d'échanger la moindre donnée.

La requête qui pendait trente secondes, c'était TCP qui n'arrivait même pas à ouvrir sa connexion.

À lire : [Trois paquets avant de se parler](/blog/handshake-tcp).


Le protocole qui garantit qu'un message arrive complet et dans l'ordre, ou que tu sauras qu'il a échoué. Une connexion fiable, au prix d'un peu de cérémonial avant de parler.

Un test de non-régression fige un comportement qui marche déjà, pour qu'une modification future ne le casse pas en douce : il monte la garde sur l'acquis. Sa valeur tient entièrement à une chose, savoir *quel* comportement il protège et pourquoi ça compte.

Un test de non-régression sans son pourquoi, c'est le singe qui interdit l'échelle sans savoir pour quelle raison : une garde que plus personne ne sait lever à bon escient.

À lire : [Le singe du pourquoi, édition dev](/blog/le-singe-du-pourquoi).


Un test qui fige un comportement qui marche, pour qu'une modification future ne le casse pas en douce.

L'autodidacte

Toutes les définitions

TCP

Test de non-régression

Test unitaire

TLS

TTL