Déconnectez un utilisateur d’une application basée sur les sessions, et le serveur l’oublie dès la requête suivante. Déconnectez-le d’une application basée sur JWT et, à moins d’avoir mis en place un mécanisme supplémentaire, le token qu’il détient reste valide jusqu’à son expiration. Cette différence est la vraie décision derrière « JWT contre session ». Tout le reste en découle. Ce qu’une session stocke réellement Une session garde l’état de l’utilisateur sur le serveur et ne transmet au navigateur qu’une clé de référence. ...

Cherchez “chiot” dans un système qui ne compare que des mots-clés et un document sur l’éducation des chiens ne ressortira pas, même si n’importe qui lisant les deux les jugerait étroitement liés. La recherche par mots-clés compare des chaînes de caractères. Elle ne sait pas que “chiot” et “chien” veulent dire presque la même chose. Les embeddings règlent exactement ce problème. Ils transforment un texte en une liste de nombres, un vecteur, placé de sorte que des textes de sens proche se retrouvent près d’autres textes de sens proche, quels que soient les mots employés. ...

Enveloppez un appel fetch() dans un try/catch, ciblez un endpoint qui renvoie un 404, et le bloc catch ne s’exécute jamais. La promise se résout. res.json() analyse le corps renvoyé par le serveur, souvent un payload d’erreur du type {"error": "user not found"}, et le reste de la fonction le traite comme l’enregistrement demandé. Aucune exception, aucun avertissement dans la console. La mauvaise donnée continue son chemin jusqu’à ce qu’autre chose se casse à cause d’elle. ...

Une fonction qui s’appelle elle-même a une profondeur maximale, et elle est plus petite que ce que la plupart des gens imaginent : 1 000 appels dans CPython par défaut, à peu près 10 000 à 15 000 dans Node et dans les moteurs des navigateurs, selon ce que chaque frame contient. Dépasser cette limite ne ralentit pas le programme. Il plante. Python lève RecursionError: maximum recursion depth exceeded ; JavaScript lève RangeError: Maximum call stack size exceeded. ...

Vous construisez un dashboard : un header, une sidebar, une zone de contenu principal, un footer. Vous partez sur Flexbox parce que c’est l’outil de mise en page que vous connaissez, et vingt minutes plus tard vous avez trois conteneurs display: flex imbriqués, une sidebar qui ne garde sa largeur qu’avec un nombre magique, et un footer qui flotte à mi-hauteur de la page quand le contenu est court. Rien de tout cela n’est un bug de Flexbox. Vous utilisez un outil à une dimension sur un problème à deux dimensions. ...

Placez go devant un appel de fonction et cette fonction s’exécute en concurrence avec le reste du programme, gérée par le runtime de Go plutôt que par le système d’exploitation. La lancer est la partie facile. La partie difficile, c’est faire passer un résultat entre deux goroutines sans qu’elles se marchent dessus sur un état partagé, et c’est le travail des channels. Qu’est-ce qu’une goroutine ? Une goroutine est une fonction qui s’exécute indépendamment de celle qui l’a lancée, gérée par le runtime de Go et non par le système d’exploitation. Un thread du système d’exploitation réserve un mégaoctet ou plus de stack et coûte au noyau un vrai temps de planification. Une goroutine démarre avec un stack d’environ 2 Ko qui grandit selon les besoins, et le runtime multiplexe de nombreuses goroutines sur une poignée de threads du système d’exploitation. En lancer des milliers à la fois est normal. ...

Une classe qui enregistre un utilisateur en base, lui envoie un email de bienvenue et met en forme un reçu n’est qu’à un changement de casser deux fonctionnalités qui n’ont rien à voir entre elles. Vous touchez le template de l’email et vous risquez l’écriture en base. Vous touchez la mise en page du reçu et vous risquez l’email. SOLID, ce sont cinq règles qui attaquent ce type d’enchevêtrement sous des angles différents, et elles partagent une idée : une classe doit changer pour une seule raison, et le reste du code doit dépendre de ce qu’une chose promet de faire, pas de la façon dont elle le fait. ...

Deux requêtes arrivent sur le même endpoint “retirer 100 €” à un demi-milliseconde d’intervalle. Le compte contient 150 €. Les deux requêtes lisent ce solde, les deux voient des fonds suffisants, les deux approuvent, les deux soustraient 100 €. Le compte termine à -50 €, et aucune branche du code n’aurait dû permettre cela. C’est une race condition : le résultat dépend de l’opération qui termine la première, et “la première” n’a jamais été quelque chose que le code a décidé. ...

Un champ de recherche qui envoie une requête à chaque frappe en envoie cinq pour “redis”, et quatre arrivent périmées avant que la réponse ne revienne. Un handler de scroll qui recalcule le layout s’exécute des centaines de fois par seconde et fait saccader la page. Même problème dans les deux cas : l’événement du DOM se déclenche bien plus souvent que ce dont le handler a besoin. Debounce et throttle règlent ça de deux façons différentes. ...

Ce qu’un décorateur fait vraiment à votre fonction Vous voulez mesurer le temps de chaque fonction qui appelle une API externe lente. Vous pouvez coller des appels à time.perf_counter() dans chacune, ou écrire la mesure une seule fois et l’appliquer partout. Un décorateur est la deuxième option : c’est une fonction qui prend une autre fonction, l’enveloppe dans un comportement supplémentaire et renvoie la version enveloppée sous le même nom. ...