Série
Encoder le système
Un arc qui va du manifeste à la conclusion : programmer n'est pas seulement écrire du code, c'est encoder des garanties dans les systèmes.
5 articles sur 8 disponibles
La série
Construire des systèmes, pas de la belle prose
On parle encore trop souvent du code comme d’un style. Pourtant, le code tourne dans notre monde.
Pourquoi l’implicite devient fragile quand humains et agents co-produisent du code.
Faire attribuer les boucles de feedback, pas seulement détecter
Pourquoi les boucles de feedback gagnent en puissance quand le code rend explicites ses concepts système.
Faire respecter l’architecture, ne pas se fier à l’intention
Pourquoi les règles structurantes de l’architecture doivent devenir des vérifications exécutables plutôt que des intentions auxquelles se fier.
Prouver et avouer, ne pas seulement linter
Pourquoi les règles exécutables ne sont que la moitié facile : les vérifications autour du code écrit par des agents doivent exiger la présence, rapporter leurs angles morts, et être écrites comme un standard plutôt que collectées comme des règles.
Construire des garanties, ne pas traquer les bugs
Pourquoi le but n’est pas de corriger les bugs plus vite, mais d’encoder des garanties qui rendent des catégories entières de bugs impossibles, rares ou visibles.
Structurer le domaine, ne pas disperser les règles
Pourquoi les invariants métier appartiennent aux structures du domaine, pas à des règles dispersées dans les chemins du code.
Encoder les garanties, ne pas seulement écrire du code
Programmer est l’art de décider quelles vérités rendre inviolables, où les encoder et à quel coût.
Glossaire de la série
Les concepts employés dans les essais. Chaque définition précise ce que le terme signifie à l’intérieur de cette série.
- Abstraction
Une représentation qui masque certains détails afin de concentrer l’attention sur les concepts importants.
Central dans l’article 2- Adaptateur
Une couche fine qui traduit entre une technologie extérieure et le modèle ou le contrat utilisé par le système.
Central dans les articles 2, 3- Attribution
Le fait d’identifier la règle, l’état, la frontière ou la responsabilité à l’origine du problème.
Central dans l’article 3- Autorité
La partie du système autorisée à décider ou à exécuter une opération.
Central dans l’article 1- Baseline
L'ensemble enregistré des violations existantes qu'une règle accepte quand on l'introduit, pour que seule la dérive nouvelle échoue. Le cliquet qui rend l'application d'une règle supportable dans une base de code réelle.
Central dans l’article 4- Clôture de périmètre
Le moment où un périmètre est déclaré complet, à partir duquel une obligation qui le concerne peut être jugée sans faux rouge. Les prohibitions se vérifient à chaque pas ; les obligations à la clôture. Seul, sur une pull request, tout périmètre est clos ; dans la boucle d'un agent, c'est le harnais qui le dit.
Central dans l’article 5- Colocation
Le fait de placer des éléments de code liés les uns aux autres à proximité, même lorsqu’ils appartiennent à des zones d’exécution ou d’architecture différentes.
Central dans l’article 2- Complément de couverture
Ce qu'un standard rapporte à la place d'un pourcentage de couverture : pour chaque garantie déclarée, à chaque changement, prouvé présent, prouvé absent, ou pas regardé. Le dernier état est là où l'attention du relecteur doit aller.
Central dans l’article 5- Contrat
Une formulation explicite de ce qui peut entrer ou sortir d’une frontière et de ce que chaque côté garantit.
Central dans les articles 1, 3- Dépendance invisible
Une connaissance dont dépend le code sans que cette dépendance soit représentée ou garantie.
Central dans l’article 2- Dérive
L’écart progressif du code ou de son comportement par rapport à la structure que le système devait préserver.
Central dans les articles 2, 3- Détection
Le fait d’établir que quelque chose ne fonctionne pas correctement.
Central dans l’article 3- Échelle des garanties
Les étapes qu'une garantie gravit pour sortir des têtes et entrer dans le système : intention, contrainte déclarée, garantie encodée, garantie vérifiée. L'essentiel de ce qu'une équipe expérimentée sait reste à la première marche ; la correction d'un bug est le moment de gravir les deux dernières.
- Effet de bord
Une interaction avec un élément extérieur au calcul local, comme une base de données, un réseau, un fichier, une horloge ou un appareil.
Central dans les articles 1, 2- État explicite
Une situation nommée dans laquelle le système peut se trouver, représentée directement plutôt que déduite de conditions dispersées.
- Événement métier
Un enregistrement nommé indiquant qu’un événement significatif s’est produit dans le domaine ou dans le modèle du système.
Central dans l’article 3- Exhaustivité
La garantie que tous les cas possibles ont été envisagés et traités.
Central dans les articles 1, 3- Explicite
Un concept représenté sous une forme visible, nommée et inspectable.
Central dans les articles 2, 3- Fait attesté
Un fait du domaine qui enregistre quelque chose qui s'est produit dans le monde (un paiement capturé, un consentement donné, une approbation accordée) et non une valeur calculée par le système. En ajout seul, attribué, corrigé par compensation uniquement ; un fait attesté manquant ne doit jamais être réparé en silence par une automatisation.
- Feedback local
Des vérifications rapides portant sur le code immédiatement modifié, comme les types, la compilation et les tests proches.
Central dans l’article 3- Feedback loop
Un mécanisme qui observe le résultat d’une modification et renvoie une information permettant de guider la correction suivante.
Central dans l’article 3- Feedback proche de la production
Des vérifications des comportements critiques dans des conditions proches de l’exécution réelle.
Central dans l’article 3- Feedback structurel
Des vérifications qui déterminent si les frontières architecturales, les dépendances et les responsabilités continuent d’être respectées.
Central dans l’article 3- Fitness function architecturale
Une vérification automatisée qui évalue régulièrement si le système respecte toujours une propriété architecturale.
Central dans l’article 3- Fonction pure
Une fonction dont le résultat dépend uniquement de ses entrées et qui ne modifie aucun état extérieur.
Central dans les articles 1, 3- Forme et adéquation
Les deux juges d'un système. La forme est la cohérence du modèle en tant que logiciel (frontières tenues, états légaux, contrats respectés) et se vérifie par des outils. L'adéquation est la vérité du modèle par rapport au monde et ne se valide que contre la réalité. Une forme parfaite sur un modèle faux, c'est l'impeccable système faux.
- Frontière
Un point qui sépare des zones ayant des responsabilités, des niveaux de confiance ou des comportements différents.
- Grade
Ce qu'une cellule prouvée de la carte de couverture prouve réellement : une forme (un schéma est là et strict), jamais un sens (le schéma est le bon). Le fond reste au responsable du domaine.
Exemple: Un schéma strict qui accepte un prix négatif passe : la forme est prouvée, le sens ne l'est pas.
Central dans l’article 5- Idempotence
La propriété selon laquelle répéter la même opération ne produit pas d’effets supplémentaires non désirés.
Central dans l’article 1- Identifiant de corrélation
Un identifiant utilisé pour relier les journaux, événements et appels appartenant à une même opération.
Central dans les articles 1, 3- Implicite
Une information nécessaire pour comprendre le système, mais qui n’est pas directement représentée dans le code lu.
Central dans les articles 2, 3- Invariant
Une condition qui doit rester vraie pendant toute la partie pertinente de la vie du système.
Exemple: Une commande payée ne peut pas revenir à l’état « en attente de paiement ».
Central dans les articles 1, 3- Machine à états
Un modèle qui nomme les états possibles, les événements acceptés et les transitions autorisées entre ces états.
- Machine probabiliste
Un système qui produit des sorties probables plutôt que de suivre une unique continuation déterminée.
Central dans l’article 2- Matrice de disposition
Un tableau complet qui classe la signification de chaque événement dans chaque état possible.
Central dans l’article 3- Niveau de garantie
La force avec laquelle une propriété est tenue : impossible (par construction, la violation ne s'écrit pas), rare (vérifiée à une frontière ou en CI), visible (surveillée, vue à la première occurrence), ou espérée (tenue par rien, le défaut). La discipline consiste à placer chaque propriété délibérément et à savoir où elle est.
Exemple: Un total de commande : impossible dans le cœur typé, rare au schéma de l'API, visible dans le job de rapprochement.
- Obligation
Une règle qui exige une présence, dont la violation est donc une absence : chaque port doit avoir son adapter, chaque handler exposé doit valider son entrée. La détecter demande un modèle de la forme attendue, et elle n'est décidable qu'une fois le périmètre qu'elle gouverne complet.
Exemple: Un handler écrit mais jamais enregistré passe ses tests unitaires ; seule une obligation voit le trou.
Central dans les articles 4, 5- Observabilité
La capacité à reconstruire ce qu’un système en fonctionnement a fait, dans quel contexte et pour quelle raison.
Central dans les articles 1, 3- Portabilité cognitive
La capacité à reconnaître une même structure conceptuelle à travers différents langages, frameworks ou implémentations.
Central dans l’article 2- Prohibition
Une règle qui interdit une présence : cette arête ne doit pas exister, cette couche ne doit pas être importée ici. Sa violation est un site concret, fausse dès qu'elle apparaît, donc vérifiable à chaque étape.
Exemple: `domain/**` ne doit pas importer `infrastructure/**`.
Central dans les articles 4, 5- Règle dispersée
Un invariant du domaine qui n'existe que comme l'intersection des disciplines locales de chaque chemin de code susceptible de le violer : écrit N fois, un peu différemment, et le N+1e chemin est à un contrôle oublié de la dérive.
Exemple: Six chemins de code qui vérifient chacun, à leur manière, qu'un solde reste sain.
- Règle-proxy
Une règle qui vérifie un substitut bon marché d'un concept (où vit un fichier) plutôt que le concept lui-même (qui possède une responsabilité). Utile, et contournable : satisfaite à la lettre pendant que le concept reste violé.
Exemple: Déplacer un composant produit dans `ui/` met la règle de dossier au vert alors qu'il importe toujours des hooks produit.
Central dans l’article 4- Responsabilité
La partie du système chargée de garantir qu’une opération est accomplie.
- Robustesse
La capacité d’un système à rester compréhensible, à absorber les écarts et à rendre visible ce qui se produit pendant son exécution.
Central dans l’article 1- Siège
L'endroit unique, localisable statiquement, où une garantie s'attache : le validateur d'entrée d'une server function, les validateurs d'un formulaire, le constructeur d'un type de domaine. Une obligation n'est décidable que là où il y a un siège.
Exemple: `createServerFn().inputValidator(schema)` : un seul endroit où chercher le contrat de cette fonction.
Central dans l’article 5- Snapshot
Une représentation immuable de l’état du système à un instant donné.
Central dans l’article 2- Standard exécutable
La description, par un ingénieur, de ce que « juste » veut dire pour une base de code, écrite une fois, hors de l'application, et rendue exécutable pour juger chaque changement. Ni un framework (on est mesuré contre lui), ni un harnais (il ne pilote pas l'agent), ni un linter (il prouve et avoue au lieu de trouver).
Central dans l’article 5- Structure de domaine
Une forme du modèle de domaine qui porte ses invariants ensemble, comme des conséquences plutôt que des règles : le grand livre pour l'argent, le journal des mouvements pour le stock, le calendrier de réservation pour les réservations. Empruntée quand le monde l'a déjà déboguée, composée sinon.
Exemple: Un solde n'est pas un champ mutable mais un pli sur les écritures d'un grand livre ; aucun chemin de code ne peut oublier l'invariant.
- Surface de vérification
L’ensemble des formes explicites du système que les outils et les personnes peuvent inspecter et vérifier.
Central dans l’article 3- Système de garanties
La composition des mécanismes (vérificateur de types, schémas aux frontières, contrats, tests de propriétés, audits, traces) qui redemande à chaque changement si les garanties du système tiennent encore. Pas une suite de tests : un environnement. Chaque garantie y est exécutable, chaque échec attribué.
- Test basé sur les propriétés
Une approche de test qui vérifie des propriétés générales sur de nombreuses entrées générées automatiquement, plutôt que de dépendre uniquement d’exemples choisis manuellement.
Central dans l’article 3- Test boîte noire
Un test qui vérifie le comportement observable sans dépendre des détails internes de l’implémentation.
Central dans l’article 3- Trace
Un enregistrement relié des différentes étapes suivies par une opération à travers le système.
Central dans les articles 1, 3- Transformation déterministe
Une transformation qui produit toujours le même résultat à partir des mêmes entrées explicites.
Central dans l’article 1- Union discriminée
Un type représentant un ensemble fini d’alternatives, chacune identifiée par un champ distinctif commun.
Central dans les articles 2, 3- ViewModel
Une représentation préparée pour l’interface utilisateur, qui expose l’état et les actions dont la vue a besoin sans intégrer le comportement du domaine dans la vue.
Central dans l’article 2