Vingt-huit systèmes, décrits honnêtement.

Django 5.2, PostgreSQL et MariaDB, rendu côté serveur, sans SPA. Environ 120 modèles répartis sur quatorze applications et 170 templates. Déployé sur un hébergement mutualisé sous Passenger, avec cron plutôt que Celery parce qu'aucun processus d'arrière-plan n'y survit.

Conversions API côté serveur avec déduplication du Pixel navigateur sur un event id partagé, données personnelles hachées, déclenchée sur un thread d'arrière-plan et conçue pour échouer sans rien bloquer. Pilotes d'imprimante fiscale avec un mode dégradé à pilote nul : un appareil injoignable marque le ticket en attente au lieu de bloquer la vente. Une API à bearer token pour un client Windows de pointage, hors dépôt, qui envoie des instantanés d'activité à la minute. Un système de rôles résolu par priorité - superuser, puis groupe, puis fiche de personnel de clinique - qui alimente dix tableaux de bord différents depuis une seule base de code.

Django 5.2, PostgreSQL, Stripe, constructeur de pages GrapesJS dans l'administration. Vingt-cinq modèles répartis sur quatre applications porteuses de modèles.

Le backend d'IA est masqué derrière un type de résultat unique et normalisé, avec trois implémentations interchangeables - mock, API hébergée et auto-hébergée - choisies par une seule variable d'environnement : le produit tourne donc de bout en bout sans aucun fournisseur d'IA branché et sans changer une ligne de code. Une chaîne de traitement clinique téléversement → analyse → observations → plan de traitement → lignes de devis, chaque observation portant sa propre plage de confiance. Un middleware d'attribution first-touch qui capte quatre click ids de régies publicitaires dans un rapport d'entonnoir du lead au client payant.

Django 5.2, MySQL, modeltranslation sur trois applications, CKEditor 5, constructeur de landing pages GrapesJS.

Une machine à états de la demande de rendez-vous à sa validation : la demande d'un visiteur reste en attente jusqu'à ce que le personnel l'approuve, et c'est alors qu'une fiche patient est créée ou rapprochée et qu'un vrai rendez-vous se matérialise. Chaque lead enregistre ses réponses deux fois - en JSON et en lignes distinctes - avec l'IP, le user agent, le referrer, la géographie et l'ensemble complet des UTM et des click ids Meta. Les landing pages de campagne sont montées en dehors du routage à préfixe de langue : le trafic payant ne tombe donc jamais sur une redirection de locale.

Django 5.2 avec DRF et JWT, PostgreSQL, Celery et Redis, hachage Argon2, quarante-neuf applications locales. React avec Vite et Tailwind côté front, Flutter pour le mobile. Sentry, gunicorn avec gevent.

Un moteur de recommandation qui classe sept états du système nerveux à partir d'un check-in, applique des filtres d'éligibilité stricts, comprime la priorité dans une échelle à six points pour que le contexte l'emporte sur la popularité, puis échantillonne par softmax au lieu de prendre l'argmax - tout le catalogue reste ainsi atteignable au lieu de se réduire aux vingt mêmes contenus. Un quatrième emplacement est réservé à la découverte et échantillonné par fraîcheur. Il tourne sur des requêtes brutes du driver plutôt que sur l'ORM, parce qu'il s'exécute sur chaque écran. La recherche s'appuie sur environ trente mille solutions structurées extraites d'à peu près quatre-vingt-quinze livres, avec un prompt qui interdit au modèle de répondre depuis ses connaissances générales et une branche explicite pour les situations de crise. Un harnais Monte Carlo fait tourner le vrai moteur sur des sessions synthétiques - cinquante mille check-ins dans une exécution, soixante-dix mille sessions équilibrées dans une autre - en vérifiant qu'aucun état de crise ne reçoit une carte inadaptée et qu'aucune carte n'est inatteignable. Il a aussi révélé une vraie lacune de détection, ce qui est précisément l'intérêt d'un harnais. Le choix du fournisseur et chaque clé d'API se résolvent depuis une table éditable dans l'administration avant de retomber sur l'environnement : les fournisseurs et les clés changent donc sans déploiement.

Django 5.1, MySQL en production avec PostgreSQL et SQLite en repli pour le développement, Celery et Redis avec un repli en mode eager, verrouillage django-axes, profilage Silk, constructeur GrapesJS. Quarante modèles répartis sur six applications.

La finalisation du paiement est volontairement doublée et idempotente - la même routine s'exécute depuis le webhook Stripe et depuis la page de retour, et sort immédiatement si la réservation est déjà payée : un webhook manqué ne peut donc pas faire perdre une réservation payée. Le channel manager ne propose aucun schéma de signature de webhook, l'endpoint est donc authentifié par un secret placé dans le chemin de l'URL, avec un test qui le vide pour prouver qu'il passe en fail closed. Une machine à états de réservation dirige les séjours confirmés vers le canal direct et les blocages vers un canal séparé ; la propriété qui n'a pas d'identifiant de canal est rapprochée localement par son slug. Chaque e-mail sortant est enregistré avant envoi par un backend de messagerie sur mesure.

Django 5.1, MySQL, Celery avec un repli en mode eager quand Redis est absent, administration Unfold avec un studio embarqué, HTMX et Alpine par-dessus Tailwind. Environ quarante modèles répartis sur dix applications. Flutter pour les deux clients mobiles, JWT en stockage sécurisé.

Un paiement en cours est conservé comme réservation temporaire et n'est promu en réservation réelle que lorsque Stripe confirme la session : les paniers abandonnés n'immobilisent donc jamais de stock. Six types de documents fiscaux distincts partagent des mixins communs de parties et de lignes, au lieu d'être un seul modèle de facture doté d'un indicateur de type. Les fiches clients se rapprochent entre canaux via une couche de client canonique, avec des registres séparés pour les particuliers et les sociétés : la même personne arrivée par une OTA et par une réservation directe forme une seule fiche. Chaque secret d'intégration se résout d'abord depuis la base de données, avec un cache de soixante secondes, ce qui permet de faire tourner les clés à chaud.

Django 5.0, MySQL, modeltranslation sur huit langues, Tailwind et Alpine servis depuis un CDN, sans étape de build. Trente-huit modèles.

Confirmation de réservation par code e-mail à six chiffres, limité en fréquence par IP avec un plafond de cinq tentatives, une expiration à quinze minutes et un délai d'attente avant renvoi. Des tokens signés à durée limitée donnent à un visiteur anonyme l'accès à sa propre page de réservation pendant vingt-quatre heures, sans compte. Le prix est recalculé côté serveur à chaque enregistrement, à partir d'une table de paliers de durée à cinq tranches croisée avec le niveau d'assurance, la remise s'appliquant uniquement au sous-total de la location - jamais repris tel quel depuis le client.

Django 5.1, MySQL, Redis et Celery, DRF avec JWT et OpenAPI, administration Unfold, modeltranslation et parler. Une application React 19 construite avec Vite et livrée déjà compilée. Quatorze applications, sept langues avec des catalogues de traduction complets.

Scoring des leads par modèle de langage avec recherche web : les réponses au formulaire, les UTM, les click ids, le résultat de l'authentification et le statut do-not-call sont assemblés en un dossier, puis notés dans une tranche avec une justification et une action recommandée, en utilisant une clé propre à chaque client. Une pile de conformité en trois parties - scrub complet avec détection du type de ligne et des numéros mobiles, contrôle des plaideurs professionnels, et recherche de numéro réattribué par rapport à une date de consentement. Le tenant est résolu depuis l'en-tête Host avec un cache de cinq minutes, et chaque soumission de formulaire est revérifiée par rapport au client de cet hôte, si bien qu'un lead qui traverse deux tenants est structurellement impossible. Le constructeur de formulaires stocke un HMAC de chaque code de vérification plutôt que le code lui-même, et chaque case de consentement écrit un enregistrement immuable de la formulation exacte, de l'IP et de l'URL.

Django 5.2 avec Wagtail, deux entrepôts de données - PostgreSQL pour l'état opérationnel et ClickHouse comme collecteur de tracking à haut débit - Redis, Celery avec beat et Flower, DRF plus une couche JWT écrite à la main pour le mobile. Quarante-six modèles dans la seule application centrale.

Chaque fournisseur est rattaché à l'un des trois sous-scores - joignabilité, authenticité, intention - exécutés en parallèle dans un pool de threads et moyennés en une note composite avec des poids réglables dans l'administration. Les adaptateurs qui échouent ou qui passent leur tour sortent du dénominateur au lieu de compter zéro, et n'importe quel adaptateur bloquant impose d'office la note la plus basse. Le jeu de signaux comprend la biométrie comportementale, l'empreinte TLS, la profondeur de scroll et la cadence de saisie du formulaire, à côté de trois sous-signaux issus de modèles de langage. Le routage vers l'acheteur filtre sur le crédit, les horaires d'ouverture, la capacité journalière et hebdomadaire, la verticale et la géographie, puis départage sur la charge des vingt-quatre dernières heures avant la priorité. Chaque appel sortant vers un fournisseur écrit une ligne de log avec l'endpoint, le statut et un résumé de la réponse, précisément pour pouvoir rapprocher le coût fournisseur par lead.

Flutter avec Riverpod, Dio et go-router, stockage sécurisé pour les tokens. Une application Django compagnon qui expose le registre d'administration en REST.

Les permissions ne sont pas réimplémentées : l'API fait correspondre les verbes HTTP aux permissions view, add, change et delete de Django, et la recherche, la pagination et le tri des listes proviennent directement de la configuration de chaque classe d'administration. Ajouter un modèle à l'administration Django l'ajoute à l'application mobile. Une application sœur destinée aux acheteurs reprend les quatorze jeux de thèmes par client de l'application web, lit le thème actif à la connexion et le met en cache, pour éviter, au démarrage à froid, un flash avec la mauvaise identité visuelle.

Django 5.2 avec Wagtail, MySQL, Redis, Celery avec beat, Channels et Daphne pour les WebSockets, DRF avec JWT, pandas et numpy, web3 pour le rail crypto. Flutter et Dart pour les clients mobiles et de bureau, un seul lib/ partagé entre les trois. Dix-sept langues configurées.

Sept lectures d'indicateurs indépendantes par unité de temps, et une unité de temps n'est en accord que lorsque au moins cinq des sept concordent - puis une confirmation sur plusieurs unités de temps par-dessus, avec des filtres optionnels sur les chandeliers et l'actualité, et des stops et objectifs dérivés de l'ATR. Chaque passage écrit une ligne d'audit, qu'il ait produit un signal ou non, et le dry-run est le comportement par défaut. Le rail de paiement crypto ne détient aucune clé privée sur le serveur : une tâche planifiée surveille la chaîne pour repérer les transferts vers une adresse de réception, rapproche les dépôts en attente par montant et confirme après douze confirmations. Deux middlewares empilés rendent le produit inaccessible tant que l'onboarding n'est pas réellement terminé.

Django 4.2, MySQL, administration Unfold avec un tableau de bord Chart.js, modeltranslation sur huit langues, Tailwind et Alpine depuis un CDN. Soixante-deux modèles répartis sur neuf applications, soixante-trois tables.

La chaîne de préparation est réelle plutôt que déclarative : la génération du bon de transport journalise la requête complète, la réponse et l'erreur au regard de la commande, et la facturation émet documents et avoirs sur cette même commande. La tarification en deux devises stocke un montant natif et un montant d'affichage sous forme de paire, plutôt qu'un montant et un taux, pour qu'une commande passée ne se revalorise pas silencieusement quand le taux de change bouge.

Django 4.2, MySQL, administration Unfold, ReportLab avec une police enregistrée sur mesure pour la composition des PDF. Cinquante-cinq modèles.

Le corps du contrat est un modèle juridique structuré qui se numérote automatiquement, fige les coordonnées du bénéficiaire au moment de la signature, et vérifie qu'un contrat est rattaché soit à une personne physique soit à une société, jamais aux deux. Les PDF de devis sont composés pièce par pièce - huit types de pièces, chacun avec sa description, son prix et ses photographies - comme un document mis en page, et non comme un remplissage de gabarit. Chaque montant est stocké dans les deux devises, en colonnes parallèles.

Django 5.2, MySQL, administration Unfold avec des templates de calendrier et de feuille de temps sur mesure. Le client de bureau est en Tkinter - environ 1 600 lignes - empaqueté avec PyInstaller en un seul exécutable et distribué via un installeur.

La logique de pointage de sortie automatique est la partie intéressante : une session se ferme à son dernier heartbeat uniquement lorsque la fin de journée prévue est passée et qu'aucun heartbeat n'est arrivé depuis dix minutes - et un heartbeat ultérieur portant un horodatage qui atteste que l'application est vivante peut réanimer une session qu'une véritable coupure avait fermée. C'est un problème d'état distribué traité correctement, plutôt qu'un cron nocturne qui devine.

Laravel 11 avec Breeze, MySQL, Blade avec Vite, Tailwind et Alpine, DomPDF. Onze modèles, dix-huit migrations.

Rien d'architecturalement inhabituel, et il ne faut pas prétendre le contraire : c'est un petit outil interne, correct. La partie qui a du fond, c'est le tableau de bord du pipeline, qui agrège les décomptes par type d'espace et par usage, la distribution par tranche de surface et le budget moyen face à la valeur totale et payée des proformas.

Django 4.2, MySQL, administration Unfold, modeltranslation sur dix langues, Tailwind et Alpine. Environ trente modèles. Un plugin compagnon pour l'outil de design, en dehors du runtime Django.

La chaîne prend du code source collé, en génère des diagrammes d'architecture et de flux, puis construit une spécification d'écrans et de palette qu'un plugin d'outil de design récupère et dessine sous forme de vraies frames éditables. C'est un petit outil, mais il supprime l'heure la moins agréable du démarrage d'un projet.

Bibliothèque standard de Python uniquement. Pas de framework, pas de dépendances, pas d'étape de build, environ 920 lignes. Le serveur est le serveur HTTP de la bibliothèque standard, avec une file de tâches en threads.

Il gère correctement l'authentification à deux niveaux du fournisseur - des identifiants de service pour émettre des identifiants client, puis des identifiants client pour la génération, mis en cache et réutilisés - et traite la génération comme réellement asynchrone, en interrogeant chaque tâche sur son propre thread avec un timeout. Sans identifiants configurés, l'UI désactive la génération et le dit, plutôt que d'échouer au moment de l'usage.

PHP et Laravel 8 avec Jetstream et Livewire, MySQL, templates Blade, Laravel Mix qui compile Tailwind, Bootstrap, jQuery, Alpine et Sass. Treize modèles, vingt-neuf migrations, trente-deux contrôleurs, Apache sur cPanel.

La traduction vit dans le schéma plutôt que dans un paquet : les modèles d'articles, de boutique, de galerie et de menu portent chacun quatre jeux de colonnes parallèles, un par langue, et le roumain est arrivé cinq ans après le lancement, par des migrations qui élargissent chacun d'eux. C'est une conception plus fruste qu'une table de traductions, et il a une vraie vertu : lire une ligne traduite, c'est la même requête que lire une ligne non traduite, sans jointure ni logique de repli à rater. Il faut le dire clairement : c'est un monolithe CRUD conventionnel, sur une stack qui a vieilli. Ce qu'il démontre n'est pas de l'ingéniosité, mais le fait qu'il a été maintenu discrètement pendant des années après la passation.

Django 4.2, MariaDB, administration Jazzmin avec des inlines imbriqués, modeltranslation et Rosetta pour éditer les traductions dans le navigateur, Bootstrap et AOS. Trente modèles. Quatre conteneurs : nginx, web, base de données et un ordonnanceur.

L'expéditeur de campagnes calcule combien d'intervalles se sont écoulés depuis l'heure de départ et envoie le lot suivant de dix destinataires, en suivant l'avancement et en écrivant un journal de livraison avec un message id généré par destinataire - un étalement conçu pour survivre à un hébergement mail mutualisé plutôt que de supposer un prestataire d'envoi. Une tâche horaire interroge ensuite l'IMAP, analyse les notifications de bounce et les rapproche de ces journaux de livraison par message id. Sous cette couche, une protection anti-abus en plusieurs niveaux : des URL pièges qui bannissent l'IP source pendant trente jours, une liste de bots interdits et des limites de fréquence par vue.

HTML statique avec Tailwind compilé en une seule feuille de style, des modules JavaScript natifs, un unique endpoint PHP pour le formulaire de contact. Apache sur hébergement mutualisé.

L'endpoint de messagerie parle SMTP directement - il ouvre lui-même une socket TLS et effectue la poignée de main d'authentification, sans bibliothèque mail - parce que l'hébergeur n'offrait aucune solution utilisable. L'analytique est réellement conditionnée au consentement : le tag n'est pas chargé du tout tant que le consentement n'est pas enregistré, et il respecte en plus Do-Not-Track et refuse de s'exécuter en dehors du nom d'hôte de production. Le sens droite à gauche est traité dans les sources Tailwind plutôt que rajouté sous forme de deuxième feuille de style, et chaque URL déclare ses alternatives de langue.

Django 4.2, MySQL, administration Unfold, modeltranslation. PayPal appelé directement en REST plutôt que via un SDK.

Un CMS à modèles singleton où chacune des quelque vingt sections de page crée automatiquement sa ligne à la migration : un rédacteur n'ouvre jamais l'administration sur un écran vide et n'a jamais à savoir ce qu'est une fixture. Toutes les clés tierces vivent dans un coffre stocké en base de données plutôt que dans des fichiers d'environnement, ce qui est le bon compromis pour un client qui change de prestataire plus souvent qu'il ne déploie.

HTML statique. Pas de framework, pas de base de données, pas d'étape de build - la bonne réponse pour un catalogue qui change deux fois par an et doit survivre à la fenêtre de support de n'importe quel framework.

Rien, et c'est justement le propos. Toutes les demandes ne sont pas des systèmes, et un site statique que le client peut héberger n'importe où pendant dix ans est ici un meilleur résultat qu'un CMS dans lequel personne ne se connectera.

Django 4.2 avec django-unfold, MySQL via PyMySQL, modeltranslation sur huit langues, CKEditor pour les champs longs, Tailwind et Alpine chargés depuis un CDN sans étape de build, Whitenoise, Passenger sur cPanel. Trente-deux modèles répartis sur trois applications.

Rien ici n'est difficile, et l'entrée mérite sa place en démontrant la compétence inverse : un site dont le propriétaire n'a jamais besoin d'un développeur pour en changer un mot. Le défaut, et je l'assume, se voit dans le schéma - le modèle de portfolio porte encore un champ de surface et un champ de localisation hérités du template immobilier dont il a été forké, et environ un tiers de la liste de dépendances est repris sans jamais être importé. C'est ce que coûte réellement le fait de forker un projet qui marche pour gagner une semaine, et je préfère le montrer plutôt que l'effacer de l'histoire.

Vue 3 avec la Composition API, Vue Router, Vite avec un découpage manuel des vendors, Tailwind, GSAP, icônes Lucide. Environ six mille trois cents lignes réparties sur huit routes, dont une page de design system. Apache qui sert le résultat du build.

Douze composants d'animation, un par service, écrits plutôt que tirés d'une bibliothèque, avec des composables d'intersection observer et de compteur en dessous. C'est un travail d'artisanat et c'est toute son ambition. Il porte aussi l'exemple le plus net que j'aie d'une dépendance qui survit à sa raison d'être : reCAPTCHA v3 se charge sur chaque page et ne protège rien, parce qu'il n'y a aucun formulaire sur le site - la route contact est un lien mailto, et la bibliothèque de validation installée pour le formulaire jamais construit est encore dans le manifeste. Un script tiers qui s'exécute à chaque chargement de page sans rien faire est un risque en matière de consentement, pas un reliquat inoffensif, et il est sur la liste des choses à retirer.

Solidity 0.8.24 avec OpenZeppelin 5.1 figé à la version exacte, Hardhat et ethers v6, Node 20 pour le relayer et le faucet, Terraform et Docker Compose pour la flotte de validateurs, une pile Blockscout embarquée derrière nginx pour l'explorateur, du JavaScript natif pour les dApps et le wallet, Rust et Anchor pour la branche Solana. 3 500 lignes de Solidity original, 12 000 de JavaScript, 142 tests de contrats répartis sur quatre suites.

Un seul fichier d'allocation fait autorité sur l'offre de cent millions, et le build en génère le genesis, les répertoires compose par rôle et les scripts de déploiement, pour le devnet, le testnet et le mainnet indifféremment - les trois réseaux ne peuvent donc pas diverger. Une étape de préflight refuse de construire un genesis de mainnet tant qu'il reste une adresse de remplacement. Le faucet réimplémente le protocole WebSocket du client de nœud pour que la page n'ait aucun cas particulier à gérer sur les réseaux locaux. Le relayer n'avance son curseur de blocs qu'une fois chaque message d'une plage persisté, parce qu'avancer d'abord perd des transferts définitivement et que rien ne rescanne. La conservation de l'offre est un invariant de conception plutôt qu'un contrôle : exactement une chaîne met en séquestre et toutes les autres émettent, le plafond du token est égal à l'offre du genesis, et les scripts de déploiement n'émettent rien. La version d'OpenZeppelin est figée parce que la 5.2 émet un opcode plus récent que l'EVM du nœud - une bibliothèque plus récente produirait du bytecode que ses propres validateurs ne pourraient pas exécuter. Le bridge est un bridge à quorum de confiance, et il est décrit comme tel à trois endroits distincts plutôt qu'appelé trustless.

Python 3.11 avec pandas et numpy, volontairement bornés en version pour que les wheels précompilées s'installent sur un hébergement mutualisé sans compilateur. SQLite pour le journal de trades, MySQL pour l'export, le serveur HTTP de la bibliothèque standard pour le tableau de bord. 18 000 lignes réparties sur 94 modules et 541 tests.

Le modèle de langage tourne sur sa propre horloge en arrière-plan et écrit un cache que la boucle de trading lit instantanément, parce qu'un aller-retour d'une à trois secondes sur des bougies de cinq secondes revient à agir sur un prix qui n'existe plus - et cette défaillance est silencieuse, puisque la réponse a toujours l'air sensée. Il peut émettre un biais et deux multiplicateurs ; il ne peut pas inventer un trade, choisir une direction, dimensionner une position ni déplacer un stop, et il retombe sur neutre en cas d'échec. La couche d'apprentissage est une régression logistique écrite à la main, précisément pour qu'elle ne puisse pas dissimuler du surapprentissage : in-sample et out-of-sample toujours rapportés ensemble, découpages respectant l'ordre chronologique, et une référence naïve « prendre tous les trades » imprimée à côté. Les sorties se déclenchent sur le prix du sous-jacent plutôt que sur la prime de l'option, parce que la prime bouge avec la volatilité et l'érosion de la valeur temps. Le superviseur utilise un verrou fichier depuis que deux lancements espacés de quelques secondes sont passés au travers d'un contrôle par pidfile et ont laissé deux bots trader sur un même compte.

Django 4.2, django-unfold, MySQL, modeltranslation sur dix langues, CKEditor, Tailwind et Alpine depuis un CDN, Passenger sur cPanel. Trente modèles répartis sur trois applications, plus un plugin Figma compagnon.

Le générateur Figma construit son arborescence de nœuds de façon déterministe - frames, rectangles et textes disposés par le code - et n'offre qu'ensuite une passe optionnelle par modèle pour l'embellir. Cet ordre est toute la conception : le même projet produit toujours la même mise en page, et le modèle peut améliorer le résultat mais n'est jamais la raison de son existence. Le plugin récupère sa spécification via une URL d'administration signée, ce qui permet à l'application Figma de bureau de tirer une maquette sans détenir de session. Deux manques que je ne prétendrai pas terminés : le côté push de l'intégration Figma est encore un stub, et le client OpenAI est importé sans être figé, si bien qu'une installation propre de ce panneau échoue tant qu'il n'est pas ajouté.

Python 3.11 et Django 5.2 LTS, django-unfold, MySQL via PyMySQL, Redis, Celery avec beat, results et Flower, Strawberry GraphQL avec l'extension d'optimisation Django, modeltranslation, Silk en développement uniquement, React 18 et Vite pour l'îlot front-end. Dix applications, trente-trois modèles, environ huit mille deux cents lignes de Python.

Le suivi des conversions se déclenche deux fois volontairement : le pixel navigateur et l'API côté serveur envoient le même événement sous le même event id, la plateforme les dédoublonne, et les événements que les bloqueurs supprimeraient autrement - couramment d'un cinquième à deux cinquièmes d'entre eux - survivent. Les champs personnels sont hachés avant de sortir, et un échec de tracking est avalé plutôt que levé, parce qu'un lead vaut plus qu'un lead parfaitement rapporté. Le moteur de formulaires, c'est neuf modèles et douze types de questions sur un entonnoir à cinq états avec une piste d'audit des événements ; ses endpoints publics sont délibérément exemptés de CSRF, parce que le balisage est rédigé dans l'administration et servi tel quel, et qu'un identifiant de session impossible à deviner, émis par le serveur, fait le travail qu'aurait fait le token. Chaque contrainte de version dans le fichier de dépendances porte la raison de son existence, y compris celles dont je préférerais ne pas avoir besoin. Le point faible, c'est la couverture : vingt-trois tests de fumée pour huit mille lignes, ce qui n'est pas assez, et je le sais.