Meta Lambda

Intégrer l'IA sans jeter l'argent par la fenêtre de contexte

2026-10-12T00:00:00+00:00

Dans un pipeline qui enchaîne des appels à un LLM, l'étape qui fait le plus d'appels n'est pas forcément celle qui coûte le plus cher. Et chaque jeton envoyé dans la fenêtre de contexte a un coût : en argent chez un fournisseur d'API, en latence, et en calcul, donc indirectement en énergie. Ce coût grimpe vite avec la taille des données.

Or une partie de cette dépense peut être évitée : des contenus renvoyés à l'identique, des étapes rejouées, des questions que du code aurait réglées seul.

Repérer et supprimer ce gaspillage n'est pas une affaire de bonnes intentions : la frugalité est de l'ingénierie de performance, avec les mêmes réflexes que d'habitude. Voici ceux que j'ai retenus en développant RetroDoc</a>, un outil qui reconstruit la documentation d'un dépôt Git à partir de son code (j'en parlais dans La dette de documentation</a>). Les principes valent pour d'autres projets de ce genre, mais les gains que je cite dépendent de mon projet, de mon modèle et de mes données : RetroDoc ne sert qu'à les illustrer.

Avant d'optimiser, trouvez ce qui pèse vraiment</h2>
Ne vous fiez pas à l'intuition. Appels, jetons et temps ne se répartissent pas de la même façon entre les étapes d'un pipeline, et on est toujours tenté de s'attaquer à celle qui fait le plus d'appels.
Chez moi, une étape de résumé fait 45 à 55 % des appels sur une application d'environ 180 fichiers. La cible idéale ! Sauf que ses prompts sont petits : elle ne pèse que 9 à 17 % du temps. L'essentiel se passe dans une autre étape : 61 % du temps en local (72,6 minutes sur 118,4), 72 % avec DeepSeek. La supprimer aurait économisé des appels, pas des heures.

Le nombre d'appels ne dit pas où passe le temps.</figcaption> </figure>
Knuth le disait déjà en 1974, bien avant les LLM :

It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. — Donald Knuth, Structured Programming with go to Statements </blockquote>
Pour ne pas avoir à deviner, faites afficher cette répartition à chaque exécution : un récapitulatif des appels, des jetons et du temps, étape par étape et modèle par modèle. Si votre fournisseur les expose, séparez les jetons d'entrée des jetons de sortie (ils ne pèsent pas pareil), repérez ceux qu'un cache de prompt a déjà traités, et comptez à part les appels échoués ou rejoués. Une étape peut en effet consommer beaucoup de jetons sans être lente, ou l'inverse.
Deux précautions rendent ce récapitulatif fiable. Ne comptez que les jetons que le serveur rapporte, sans les estimer à partir du nombre de caractères, quitte à signaler que le total est sous-estimé. Et si vous affichez un prix, datez-le : les tarifs changent plus vite que votre code, et une seule grille ne vaut pas pour plusieurs modèles. À défaut, donnez au moins les volumes de jetons, qui permettent de le calculer.
Réutilisez ce qui est déjà fait</h2>
Si les données qu'un traitement reçoit n'ont pas changé depuis la dernière exécution, inutile de rappeler le modèle : on réutilise le résultat déjà obtenu. Associez à chaque résultat une clé calculée sur ce dont il dépend (le contenu des documents lus, le modèle utilisé, la version du prompt) et sautez ce qui est à jour. La clé doit couvrir tout ce qui peut changer le résultat : selon votre système, cela peut inclure aussi les paramètres de génération ou le format de sortie attendu.
Enregistrez après chaque appel, pas à la fin : une exécution interrompue reprend alors où elle s'était arrêtée, au lieu de jeter le travail déjà fait.
Un cache n'est utile que si ses clés sont stables. Dans mon cas, une étape intermédiaire n'était pas déterministe : ses identifiants changeaient à chaque exécution, toutes les clés en aval aussi, et une relance « sans changement » refaisait tout. Le tonneau des Danaïdes ! Cherchez ce qui, dans votre pipeline, rend vos clés instables, et décidez à l'avance ce qui invalide le cache : si changer un prompt ne le vide pas, vous servirez de vieux résultats sans le savoir. Et gardez en tête qu'avec un modèle non déterministe, réutiliser le cache, c'est accepter la réponse de la première génération : une mauvaise réponse reste figée tant que l'entrée ne change pas, ou que vous ne videz pas le cache.

Un cache n'économise que si sa clé est stable.</figcaption> </figure>
Lisez chaque document une seule fois</h2>
Dans un pipeline à plusieurs étapes (extraction, classification, résumé, vérification), le même document finit souvent dans plusieurs prompts, un par question. Le modèle relit donc plusieurs fois le même texte.
Deux remèdes. Poser les questions ensemble dans un seul appel, avec une réponse structurée qui les couvre toutes. Ou garder le contenu commun en tête de prompt et profiter du cache de prompt si votre fournisseur en propose (il évite de retraiter un début de prompt déjà envoyé). Ils n'ont pas les mêmes gains : le premier change la façon d'interroger le modèle, le second dépend de ce que votre fournisseur propose et facture.
Pour savoir si le jeu en vaut la chandelle, mesurez d'abord le recouvrement : un petit script qui compte, pour chaque étape, les documents qu'elle lit, et ce que les étapes ont en commun. Chez moi, deux étapes de RetroDoc lisaient les mêmes fichiers : 36 % des caractères qu'elles lisaient portaient sur des fichiers lus deux fois. En les fusionnant, j'ai supprimé un tiers des appels et des jetons sur une application réelle.
Mais fusionner n'est pas gratuit pour la qualité. L'ordre des questions compte : en plaçant la question sur les entités en premier, le modèle ne retrouvait plus qu'un seul point d'entrée de l'application (route, commande…) sur une quinzaine. Et sur une petite bibliothèque de neuf fichiers, la lecture fusionnée retrouvait moins de points d'entrée que les deux lectures séparées. Gardez donc l'ancien chemin disponible, et comparez.
Réservez le modèle à ce qui est ambigu</h2>
Si du code peut répondre avec certitude, qu'il réponde. Beaucoup de contrôles qu'on délègue à un LLM relèvent de la vérification mécanique : la source citée existe-t-elle, la valeur annoncée apparaît-elle dans le texte, le JSON respecte-t-il son schéma, le chemin existe-t-il ? Passez chaque réponse du modèle par ces contrôles, et ne le rappelez que pour les cas douteux. Un tel contrôle ne doit valider que ce qu'il peut établir mécaniquement : il conclut « valide », « invalide » ou « indéterminé », et ce dernier cas part au modèle.
Chez moi, chaque étape d'un use case (un scénario fonctionnel décrit pas à pas) cite les lignes de code qui la justifient, et les faire vérifier par un LLM représentait un appel sur cinq. Une simple recherche de texte règle une bonne part des cas : le contrôle vérifie que les lignes citées existent et que les noms mentionnés par l'étape s'y trouvent, et n'envoie au modèle que le reste.
Sur une petite bibliothèque, 80 % des étapes passent seules. Mais un use case n'est réglé que si toutes ses étapes passent : 6 sur 13, ce qui ramène cette vérification de 8 à 4 appels. Sur une application plus grande et plus dynamique, seule la moitié des étapes passent seules, et le reste part encore au modèle. Le gain dépend donc de votre code : annoncez le résultat moyen, pas celui de votre meilleur cas.
Ce contrôle a aussi sa limite : trouver un nom dans le code ne prouve pas que la fonction fait ce que la documentation lui attribue. Ses scores sont donc un peu optimistes (quand on demande aussi son avis au modèle, il est plus sévère), et on fait relire un échantillon par le modèle pour garder la mesure honnête.

Part des étapes réglées sans appel au modèle.</figcaption> </figure>
Le cas « indéterminé » est le plus facile à oublier. Mon contrôle comptait d'abord comme valide une affirmation qui ne nommait rien de vérifiable, puisque rien ne la contredisait : 93 % de réussite, ramenés à 80 % après correction. Un thermomètre qui affiche toujours 37 °C ne signale jamais de fièvre.
Produisez une fois, consultez autant que vous voulez</h2>
Séparez la production de la consommation. Si le résultat d'un traitement lourd sert à de nombreuses questions, exposez-le par un chemin de lecture léger (fichiers statiques, index, API en lecture seule) plutôt que de reposer la question au modèle à chaque fois. Le travail se fait une fois, à la génération.
Dans mon cas, les documents générés sont servis aux agents de code par un serveur en lecture seule, sans clé d'API ni modèle : une recherche lexicale écrite à la main suffit, sans embeddings tant qu'on n'a pas montré qu'elle échoue sur le vocabulaire du domaine. Pour le montrer, testez-la sur quelques questions représentatives, avec les synonymes et les formulations indirectes que vos utilisateurs emploieront vraiment, et n'ajoutez des embeddings que si elle échoue de façon durable. Les réponses sont déterministes. Elles préviennent aussi quand un fichier cité a été modifié depuis la génération : un résultat produit une fois peut devenir faux, et le lecteur doit le savoir.
Laissez l'utilisateur plafonner, et dites ce qui reste dehors</h2>
Un pipeline LLM doit pouvoir être borné : un plafond sur le nombre de documents, un échantillon pour les vérifications lourdes, une estimation affichée avant de lancer. Savoir « ça va faire 300 appels » avant de commencer change la décision de lancer ou non.
Mais la limite doit rester un choix visible. Chez moi, l'utilisateur peut limiter l'analyse aux N fichiers les mieux classés, et le rapport liste tout ce qui n'a pas été analysé. Attention : plafonner le périmètre ne plafonne pas le travail demandé au modèle, car un fichier long demande plus d'appels qu'un fichier court. Je n'ai que le plafond de périmètre et l'estimation avant lancement ; si votre budget est une contrainte ferme, plafonnez aussi les appels ou les jetons.
J'ai refusé un plafond automatique : abandonner des entrées sans le dire fausse le résultat, et masquerait ici de la dette de documentation, exactement ce que l'outil doit révéler. Une borne silencieuse est une dégradation, pas une optimisation.
Mesurez avant d'activer une optimisation</h2>
C'est le conseil qui m'a le plus servi. Une optimisation dont on ne connaît pas l'effet sur le résultat n'en est pas encore une : un prompt plus court ou un appel en moins qui dégrade silencieusement le résultat déplace le problème, il ne le supprime pas. Mesurez donc la qualité en même temps que le gain, avec une référence si vous en avez une, et sur plusieurs exécutions, car la variance d'un LLM peut être aussi grande que l'effet que vous cherchez.
Un exemple. Pour alléger les prompts, j'ai essayé de ne montrer au modèle que la signature et les premières lignes de chaque méthode, au lieu du code complet. Résultat : des prompts 42 % plus petits. Sur le papier, c'est un gain net.
Mais en regardant aussi le résultat, le tableau change : le modèle retrouve moins d'entités (les objets métier du code, comme un utilisateur ou une commande), 77 à 94 par exécution contre 103 à 132 avec le code complet, dans les trois exécutions. Sans cette seconde mesure, j'aurais activé l'optimisation par défaut et perdu de l'information sans m'en apercevoir. Elle reste donc une option, et c'est un avantage : chaque projet règle le curseur selon ses moyens, la qualité de ses données, la puissance de son modèle, le temps dont il dispose. Un projet aux données propres et au modèle puissant n'a pas les mêmes besoins qu'un projet qui tourne sur un petit modèle local.
La suite logique est de mesurer ce qu'on perd exactement : compter des entités donne une quantité, pas une qualité. Avec une liste annotée à la main, on peut calculer la précision (ce que le modèle a trouvé est-il juste ?) et le rappel (a-t-il trouvé tout ce qu'on attendait ?).
J'ai appliqué la même démarche à une autre approche, qui réduit de 55 % le nombre d'appels sur une grosse application mais donne de moins bons résultats sur une petite. Là aussi, c'est un réglage plutôt qu'un choix imposé : à chacun de l'adapter à la taille de son projet.

Un gain de 42 % sur les prompts, et une perte dans le résultat.</figcaption> </figure>
Ces chiffres viennent d'un modèle local, de peu de dépôts et de trois exécutions par réglage : ils valent pour mon projet, pas forcément pour le vôtre. C'est précisément pourquoi il faut les mesurer chez soi.
Concevoir juste ce qu'il faut</h2>
Rien de spectaculaire là-dedans : des compteurs, des clés de cache stables, des contrôles qui évitent un appel, des limites choisies par l'utilisateur, et l'habitude de noter ce qu'on a mesuré avec ce qu'on n'a pas pu mesurer. Chaque appel évité est un choix qu'on peut justifier, et chaque appel gardé aussi.

Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher. — Antoine de Saint-Exupéry, Terre des hommes </blockquote>
À condition de savoir ce qu'on retranche. Sans mesure, on coupe à l'aveugle.

L'agentic coding ne réinvente pas l'ingénierie logicielle, il la rend obligatoire

2026-10-05T00:00:00+00:00

Des tests fiables, une architecture explicite, des builds reproductibles, des changements petits et réversibles, une documentation qui sert vraiment. Je défends ces idées depuis des années, et elles passaient parfois pour du perfectionnisme. (Quand on est poli.)
Avec les agents de code, la discussion est close : ce ne sont plus des préférences d'équipe, c'est la condition pour que l'outil fonctionne.
C'est ce que je constate sur le terrain, et c'est ce que raconte aussi la communauté qui utilise ces outils intensivement. Voici ce qui en ressort, avec les désaccords qui restent ouverts.
Un agent, c'est d'abord une boucle</h2>
Un assistant classique propose du code, on le relit, on le corrige. Un agent agit : il lit le dépôt, lance des commandes, exécute les tests, observe le résultat et corrige. Un modèle qui n'exécute jamais son code reste dans le plausible. Un agent qui peut vérifier ce qu'il produit entre dans un cycle d'hypothèse, d'action, d'observation et de correction.
C'est un peu le rémoulage d'une lame : on dégrossit, on contrôle le fil, on corrige, et on recommence. Sans contrôle du fil, on affûte à l'aveugle.
Simon Willison, qui documente ces pratiques sous le nom d'agentic engineering</a>, en fait le critère qui distingue l'agent : il exécute le code qu'il écrit. Le prompt compte toujours, mais la qualité du résultat dépend surtout de ce que l'agent peut observer.

Hypothèse, action, observation, correction : la boucle ne vaut que par ce qu'elle observe.</figcaption> </figure>
Donner à l'agent quelque chose à observer</h2>
La question à se poser est simple : si l'agent modifie quelque chose, comment sait-il que ça marche ? Compilateur, tests, logs, navigateur, métriques : plus ces signaux sont fiables et rapides, plus la boucle est efficace.
Un compilateur strict et un linter intransigeant, c'est du feedback gratuit. Et ils ne se lassent jamais de répéter la même remarque. Sur un projet Rust, trois commandes suffisent à cadrer un agent :
cargo fmt --check cargo clippy -- -D warnings cargo test </code></pre> Un développeur humain en tire le même bénéfice. Ce qui change, c'est qu'un projet sans ce filet ne fait plus seulement perdre du temps à l'équipe : il rend l'agent dangereux.
Le dépôt est une interface, et la documentation aussi</h2>
Un dépôt a toujours été une interface pour les humains qui arrivent dans l'équipe. C'est maintenant aussi une interface pour les agents : comment démarrer, comment lancer les tests, où est la logique métier, quelles conventions comptent vraiment. Un humain compense une documentation médiocre avec son expérience et ses collègues. Un agent, lui, compense avec des suppositions, et avec beaucoup d'aplomb. (J'en parlais déjà dans La dette de documentation</a>.)
Le fichier d'instructions (AGENTS.md</code>, CLAUDE.md</code>) illustre bien cette convergence. Une étude qualitative de Google</a> auprès de 12 développeurs montre qu'il joue un double rôle : instructions pour l'IA et documentation d'onboarding pour les humains. Elle montre aussi que les 12 valident leurs règles « au feeling », sans évaluation formelle. L'échantillon est petit, mais cela rejoint la mise en garde de Birgitta Böckeler (Thoughtworks) : le context engineering</a> n'a pas de tests unitaires et reste probabiliste. Son conseil : construire ces règles progressivement plutôt que de tout déverser d'un coup, et ne jamais parler de « garantie » quand on écrit une instruction.
Autrement dit, on retrouve ce qu'on disait de la documentation humaine : courte, vivante, maintenue.
Ce qui compte doit être vérifiable par une machine</h2> Une règle qui doit toujours être respectée ne devrait pas vivre uniquement dans un fichier Markdown. « Le module billing</code> ne dépend jamais de web</code> » peut s'écrire dans les instructions, ou faire échouer la CI. Seule la deuxième solution est fiable, pour les agents comme pour les humains pressés un vendredi soir. L'idée est ancienne en clean architecture : les règles d'architecture s'automatisent. Les agents nous obligent simplement à le faire. Les tests d'abord, mais sans cérémonie</h2> Le TDD/BDD fait partie de mon hygiène de développement depuis longtemps. Avec un agent, je n'y ai pas renoncé, mais j'ai changé le rythme : beaucoup moins de petits cycles RED/GREEN/REFACTOR, des cycles plus larges et plus directs. Je continue pourtant à faire écrire les tests en premier, pour trois raisons : c'est une reformulation du problème : le test dit autrement ce que le prompt demandait, et les écarts de compréhension apparaissent tôt ;</li> cela évite les trous de couverture : on n'écrit pas les tests après coup en fonction de ce que le code fait déjà ;</li> cela donne à l'agent un moyen de vérifier lui-même son code.</li> </ul> Les avis divergent. Willison recommande le red/green TDD</a> : écrire le test, le voir échouer, puis implémenter. Böckeler, à l'inverse, a mesuré l'effet</a> sur des tâches simples : pas de différence nette avec ou sans TDD, des solutions sans TDD plutôt mieux classées, et au moins trois fois plus de tokens. Elle a arrêté de demander le test-first à ses agents. Son raisonnement se tient : le red/green ne prouve rien quand c'est l'agent qui écrit le test et constate l'échec, puisque personne ne vérifie que l'échec a lieu pour la bonne raison. Et une bonne partie des bénéfices du TDD (gérer la peur, avancer à petits pas, subir la friction de la conception) est propre à l'humain. Son expérience reste réduite (des tâches Python greenfield, une qualité jugée par un modèle), et elle n'a pas testé le cas où l'humain écrit lui-même les scénarios. Je n'y vois donc pas la preuve que j'ai tort, mais de quoi préciser ce que je garde : pas la cérémonie, ses fonctions. Sa conclusion rejoint d'ailleurs mon expérience : mieux vaut surveiller les résultats que dicter la méthode. Elle propose les tests de mutation, qui montrent si un test détecterait réellement une régression, plutôt que d'imposer un rituel en espérant. C'est aussi pourquoi je relis les tests avant le code. Ils sont la partie du diff qui dit ce que le système est censé faire. Le vrai sujet : la dette cognitive</h2> C'est la partie la plus discutée par les praticiens, et la moins visible dans les guides. Willison le résume ainsi : écrire du code ne coûte presque plus rien</a>, ce qui bouleverse nos intuitions. Mais la compréhension, elle, n'est pas devenue gratuite. Un fil Hacker News</a> décrit des équipes qui reçoivent chaque semaine des quantités de code qui marche à peu près, sans pouvoir le relire sérieusement. Une étude qualitative récente</a> parle de « dette de compréhension » : les agents produisent des changements plus vite et en lots plus gros que les relecteurs ne peuvent les inspecter. Tout le monde n'est pas d'accord. Pour certains, « dette cognitive » est un mot-valise qui désigne un workflow mal construit (documentation absente, tests manquants, onboarding raté). Pour d'autres, le vrai problème est la qualité du code généré, donc la dette technique classique. Mon avis : les deux ont raison, et c'est la discussion que j'ai avec mes clients depuis des années. Une dette cognitive est une dette technique que personne n'a encore identifiée. Les agents ne changent pas sa nature, seulement la vitesse à laquelle elle s'accumule. Addy Osmani (qui travaille sur Claude Code chez Anthropic) donne une image qui fait mouche : avec un agent, le relecteur est souvent « le premier humain à voir ce code », car le raisonnement de l'agent est jeté une fois le diff produit. Sa piste : capturer l'intention et les alternatives écartées dans un journal de décisions attaché à la PR. Steve Yegge va dans le même sens avec Beads</a>, un journal versionné dans Git qui garde le « pourquoi » des changements (un projet qu'il promeut lui-même, donc à prendre comme une illustration). Les ADR font la même chose depuis longtemps. Les remèdes restent donc classiques : des changements petits et liés à une intention claire, des décisions écrites, une revue centrée sur l'architecture et le comportement, et une règle simple, ne pas fusionner ce qu'on ne sait pas expliquer. La revue devient le goulot</h2> Avant, écrire coûtait plus cher que lire. Ce rapport s'inverse. Osmani rassemble des mesures récentes, avec une réserve qu'il signale lui-même : elles viennent surtout d'éditeurs d'outils. GitClear observe environ quatre fois plus de code produit par les utilisateurs quotidiens d'IA, pour un gain réel d'environ 12 %. Faros, sur 22 000 développeurs, relève 31 % de PR fusionnées sans aucune revue en plus. Personne n'a décidé d'arrêter de relire : le volume a décidé à notre place. Le volume a changé de côté, la capacité de relecture pas.</figcaption> </figure> Ses recommandations ressemblent à du bon sens d'ingénieur : Trier par risque : un changement de configuration mérite un linter, un chemin de paiement mérite le grand jeu.</li> Garder les PR petites, car un diff énorme est refusé ou approuvé sans lecture.</li> Lire les tests modifiés d'abord : un agent peut « réparer » un test en réécrivant l'assertion pour coller au comportement cassé.</li> Mettre l'humain « sur la boucle » plutôt que « dans la boucle » : échantillonner et auditer, pas lire chaque ligne.</li> </ul> La revue par IA est utile pour dégrossir, mais elle ne remplace pas la compréhension. Quand un modèle relit le code d'un autre modèle, ils ont tendance à se tromper de la même façon : ce que l'un ne voit pas, l'autre ne le voit pas non plus. Son « looks good » est sans doute sincère, il ne vaut pas celui d'un humain qui a compris. Tout doit pouvoir se défaire</h2> Pour savoir quelle autonomie laisser à un agent, je me pose une seule question : que se passe-t-il si c'est faux ? Si la réponse est « je jette la branche », il peut travailler sans surveillance. Si c'est « une migration est partie en production », certainement pas. La branche dédiée est le minimum, et git worktree</code> va plus loin : chaque agent reçoit son propre répertoire de travail, une paillasse jetable sans risque pour le reste. Plus c'est difficile à défaire, moins on laisse d'autonomie.</figcaption> </figure> C'est ce qui rend le parallélisme possible, mais il a sa limite. Un praticien qui fait tourner trois à cinq agents depuis des mois conclut que la décomposition des tâches compte plus que leur nombre. Des consignes vagues donnent autant d'interprétations que d'agents, et deux agents dans le même répertoire finissent par s'écraser. Le multi-agent sert à paralléliser des problèmes indépendants, pas à remplacer une conception qu'on n'a pas faite. Sécurité : des tests verts ne suffisent pas</h2> Des chercheurs ont montré que des agents peuvent produire des patchs qui passent tous les tests tout en contenant une faille</a>, que la faille ait été glissée volontairement par un attaquant ou introduite sans le vouloir. L'étude porte sur des scénarios précis, mais le principe est général : les tests ne prouvent que ce qu'ils couvrent. Willison propose un cadre utile, la lethal trifecta. Un agent qui a accès à des données privées, qui lit du contenu non fiable et qui peut communiquer vers l'extérieur peut être manipulé par injection de prompt pour exfiltrer ces données. Dès que les trois sont réunis, le risque est structurel. La réponse est celle de tout système sensible : sandbox, permissions minimales, secrets isolés, réseau restreint, journalisation. Et l'autonomie reste proportionnelle au risque : refactorer une fonction pure ne demande pas les mêmes garde-fous que toucher à l'authentification. La lethal trifecta : le risque apparaît quand les trois se rejoignent.</figcaption> </figure> Ce que ça dit de notre métier</h2> Avec les agents, les bonnes pratiques sont restées les mêmes. Ce qui a disparu, c'est la possibilité de s'en passer. Une équipe sans tests fiables, sans architecture explicite et sans discipline de revue pouvait survivre avec des humains qui compensent avec leurs petites mains. Avec des agents capables de produire dix fois plus de code, elle accumule dix fois plus vite sa dette. La bonne question n'est plus « quel est mon meilleur prompt ? » mais « quel environnement ai-je construit pour que mon agent, et mes collègues, puissent réussir ? ». Ça ressemble beaucoup plus à de l'ingénierie qu'à de la magie. Boileau le disait déjà, et j'en parlais dans J'ai une dette technique et c'est mon choix</a> : Hâtez-vous lentement, et sans perdre courage, Vingt fois sur le métier remettez votre ouvrage — Boileau, L'Art poétique </blockquote> Avec des agents qui vont dix fois plus vite, c'est devenu un conseil d'ingénieur. Sources : Simon Willison, Agentic Engineering Patterns</a> · Birgitta Böckeler, TDD inside the agent loop</a> et Context Engineering for Coding Agents</a> · Addy Osmani, Agentic Code Review</a> · Google Research, règles d'agents</a> et patchs corrects mais vulnérables</a>
La dette de documentation : le passif caché qui plombe vos projets 2026-09-28T00:00:00+00:00 Il y a une dette dont on parle beaucoup en 2026 : la dette technique. Refactoring repoussé, tests manquants, architecture qui grince. Mais il existe une dette cousine, tout aussi coûteuse et bien moins visible sur un dashboard de qualité de code : la dette de documentation, fonctionnelle autant que technique. J'ai vu ce cas de figure se répéter, sous des formes différentes mais avec la même mécanique de fond. Comment on en arrive là</h2> « Shipping first time code is like going into debt » — Ward Cunningham, qui a inventé le terme « dette technique » en 1992, posait déjà le problème : livrer du code non mûri, c'est emprunter. Reste à savoir qui paiera les intérêts, et avec quoi. </blockquote> La solution grandit sans cadrage produit formel. Une PME lance un MVP, une fonctionnalité en entraîne une autre, un client important demande une exception, puis une autre. Le produit avance à la vitesse du besoin, pas à celle de la documentation. Personne n'a jamais écrit noir sur blanc pourquoi telle règle métier existe — elle vit uniquement dans la mémoire de ceux qui l'ont codée, ou pire, uniquement dans le code lui-même, sous forme de if</code> imbriqués sans commentaire. Les sachants quittent l'entreprise. Et avec eux part la doc fonctionnelle et technique qui n'a jamais existé ailleurs que dans leur tête. Ce n'est pas une négligence isolée : c'est souvent la conséquence directe du premier point. Quand il n'y a jamais eu de cadrage formel, il n'y a rien à transmettre au départ d'un sachant — sinon un debrief de dernière minute, forcément incomplet. Ce phénomène n'a rien d'anecdotique. Selon l'enquête 2022 de Stack Overflow menée auprès de plus de 70 000 développeurs, 68 % des développeurs tombent au moins une fois par semaine sur une information dont ils ont besoin... mais qui n'existe nulle part, sauf dans la tête de quelqu'un d'autre. Un chiffre qui grimpe à 73 % chez les managers techniques — souvent les plus expérimentés, donc les plus proches du départ. Une information indispensable, absente de partout sauf d'une tête.</figcaption> </figure> Les impacts, au-delà de l'inconfort</h2> Le manque de documentation n'est pas qu'une gêne pour les nouveaux arrivants. Il a des conséquences concrètes et mesurables : Onboarding qui s'éternise : un nouveau développeur met des semaines à devenir autonome, en reconstituant par archéologie ce qu'une doc aurait transmis en heures.</li> Régressions fonctionnelles : sans trace des règles métier, on réintroduit des bugs déjà corrigés, ou on casse un comportement qui avait une raison d'être oubliée depuis longtemps.</li> Décisions produit à l'aveugle : impossible de savoir si une fonctionnalité existe déjà, sous quelle forme, ni pourquoi elle a été conçue ainsi.</li> Dépendance critique à quelques individus : le bus factor devient un risque business réel, pas juste une private joke d'ingénieur.</li> Un coût qui s'accumule avec le temps : chaque fonctionnalité ajoutée sans être documentée alourdit un peu plus la dette suivante — comme des intérêts qui s'empilent sur un capital jamais remboursé.</li> </ul> Le temps perdu se chiffre facilement. Toujours selon la même enquête, 62 % des développeurs passent plus de 30 minutes par jour à chercher des réponses ou des solutions, et 25 % y consacrent plus d'une heure — ce qui représente, pour une équipe de 50 développeurs, entre 333 et 651 heures perdues chaque semaine. À l'échelle macro, le Consortium for Information & Software Quality (CISQ) a estimé, dans son rapport 2022 sur la qualité logicielle aux États-Unis, que la mauvaise qualité logicielle coûtait 2 410 milliards de dollars, dont 1 520 milliards imputables à la seule dette technique. La documentation manquante n'est évidemment pas l'unique cause de ce chiffre, mais elle en est un contributeur direct et documenté. Le manque de documentation se chiffre, en heures perdues comme en dollars.</figcaption> </figure> Comme le résume Damian Conway, auteur de Perl Best Practices : « Documentation is a love letter that you write to your future self » — une documentation, c'est une lettre d'amour qu'on s'écrit à soi-même dans le futur. Faute de l'avoir écrite, c'est toute l'équipe suivante qui en paie l'absence. </blockquote> Même à l'heure de l'IA, la doc reste indispensable</h2> On pourrait penser que l'essor des agents de code change la donne, ou même rend la doc obsolète puisque l'IA « comprend » le code. C'est l'inverse qui se produit. Un agent de code ou de QA n'a pas d'intuition métier. Il ne sait pas pourquoi une règle existe, seulement ce que le code fait littéralement. Une documentation fonctionnelle et technique de qualité, passée en contexte ou indexée en RAG, améliore considérablement l'efficacité de ces agents : moins d'hallucinations sur l'intention métier, des suggestions de code plus pertinentes, une revue de QA capable de distinguer un vrai bug d'un comportement voulu. La doc n'a pas perdu de valeur avec l'IA — elle en a gagné, parce qu'elle devient la mémoire structurée que l'agent consulte à chaque tâche. RetroDoc : reconstruire la doc manquante</h2> J'interviens régulièrement chez mes clients pour résoudre leurs problèmes de dette technique, mais aussi pour les accompagner dans l'intégration efficace de l'IA à leur métier. Et sur le terrain, le constat est sans appel : le manque de documentation ne freine pas seulement leurs équipes, il a un impact direct sur mes propres missions. Chaque heure passée à reconstituer manuellement le contexte fonctionnel d'une application est une heure en moins pour résoudre le vrai problème. C'est ce constat qui m'a poussé à créer RetroDoc, et plus largement une panoplie d'outils pensés pour ça, en m'appuyant sur ma longue expérience du développement logiciel et de la dette technique, combinée à mon savoir-faire en intégration d'IA agentique. RetroDoc s'appuie sur le code source, l'historique des tickets et les quelques documents épars encore disponibles pour reconstruire a posteriori la documentation fonctionnelle et technique qui n'a jamais été écrite — ou qui s'est perdue avec le départ des sachants. L'idée n'est pas de remplacer la discipline de documenter au fil de l'eau, mais de traiter le passif existant : redonner à une équipe une base de connaissance exploitable, à la fois pour les humains qui rejoignent le projet et pour les agents IA qui vont désormais y travailler à leurs côtés. RetroDoc reconstruit a posteriori ce qui n'a jamais été écrit.</figcaption> </figure> Je partagerai l'avancement de RetroDoc dans un prochain article. Sources : Stack Overflow Developer Survey 2022</a> · CISQ, Cost of Poor Software Quality in the US: A 2022 Report</a> Gloire aux Soft Skills !!! 2026-09-24T00:00:00+00:00 On l'entend partout en ce moment : le métier de codeur serait en train de mourir. Pour les juniors, c'est encore plus rude. À quoi bon apprendre à coder quand une IA générative le fait à leur place, souvent mieux, et surtout beaucoup plus vite ? Résultat, les soft skills ont le vent en poupe. Communication, collaboration, empathie… On les retrouve martelées dans chaque offre d'emploi et chaque conférence. On pourrait croire qu'elles ont soudainement pris de la valeur. En réalité, c'est surtout le code qui en a perdu, et on se raccroche à ce qui reste. Gloire aux soft skills, donc ! Ou presque. Le code devient jetable</h2> L'IA générative a changé la donne assez brutalement : écrire du code n'est plus un acte rare, ni particulièrement précieux. Une IA en recrache à la chaîne, avec un niveau tout à fait honorable, sur des tâches qui exigeaient un vrai savoir-faire il y a encore deux ou trois ans. Ajoutez à ça un marché du travail qui se tend (les développeurs le sentent bien sur le terrain), et les candidats cherchent logiquement à se différencier ailleurs. Puisque le code ne suffit plus à faire la différence, on se rabat sur ce que l'IA ne sait pas encore bien faire : les soft skills. Plus qu'une montée en puissance des soft skills, c'est un repli stratégique face à la dévaluation du code brut. Les soft skills n'ont pas pris de valeur : c'est le code qui en a perdu.</figcaption> </figure> Ce que ce glissement libère</h2> Vu comme ça, l'histoire est un peu triste : celle d'un métier qui perd son cœur technique. Je crois au contraire que c'est une bonne nouvelle ! Réduire un développeur à la production de code a toujours été une vision étriquée du métier. L'IA générative nous donne l'occasion de sortir de ce rôle d'exécutant pour devenir un vrai contributeur à l'avancée du produit. Un meilleur architecte, un meilleur communicant, quelqu'un qui pense système plutôt que syntaxe. Rien de bien neuf d'ailleurs, le MIT l'enseignait déjà en 1985 : We believe that the essential material to be addressed by a subject at this level is not the syntax of particular programming-language constructs, nor clever algorithms for computing particular functions efficiently, nor even the mathematical analysis of algorithms and the foundations of computing, but rather the techniques used to control the intellectual complexity of large software systems. — H. Abelson & G. J. Sussman, préface de Structure and Interpretation of Computer Programs</a> </blockquote> Il y a même une dimension managériale qui émerge, et qui me semble sous-estimée. Orchestrer plusieurs agents IA pour atteindre un résultat, identifier les points forts de chacun, cadrer leur travail, vérifier le rendu… Ça ressemble à s'y méprendre au quotidien d'un manager d'équipe. (La machine à café et les entretiens annuels en moins.) On ne code plus seul dans son coin : on délègue, on arbitre, on supervise. Orchestrer des agents, c'est déjà un peu manager une équipe.</figcaption> </figure> La fin d'une aberration du recrutement</h2> Autre effet de bord, plus concret celui-ci : on pourrait enfin en finir avec une absurdité qui traîne dans notre métier depuis toujours. Les intitulés de poste hyper-spécifiques ! « Développeur langage X, framework Y, version Z », qui enferment les profils dans une case technique précise… et périssable. Si la valeur d'un développeur se déplace vers l'architecture, la communication et l'orchestration, ces intitulés n'ont plus grand sens. On devrait voir émerger des profils bien plus transverses, capables de passer d'une stack à l'autre sans en faire un drame. Parce que ce qui compte, ce n'est plus la maîtrise pointue d'une syntaxe, mais un savoir-faire de fond, transposable. De la case technique au profil transverse.</figcaption> </figure> Et la relève, dans tout ça ?</h2> Reste une question qui me tient particulièrement à cœur : qu'est-ce que tout ça signifie pour la formation des jeunes développeurs ? Si le code perd sa place centrale, former quelqu'un uniquement à coder devient une impasse. Montaigne, lui, avait déjà tranché : Je voudrois aussi qu'on fut soigneux de luy choisir un conducteur qui eust plustost la teste bien faicte que bien pleine, et qu'on y requit tous les deux, mais plus les meurs et l'entendement que la science. — Montaigne, Essais, I, 26</a> </blockquote> Une tête bien pleine… ou bien faite.</figcaption> </figure> Il faudra sans doute repenser en profondeur ce qu'on transmet, et dans quel ordre. Des têtes bien faites, plutôt que bien pleines de syntaxe ! La dette technique n'est que la partie émergée 2026-09-21T00:00:00+00:00 Quand on me mandate en tant que freelance, la demande initiale ressemble presque toujours à la même chose : « l'équipe n'arrive pas à produire assez vite, il faut accélérer ». C'est un cadrage confortable : il pointe vers un problème technique, donc vers une solution technique. Sauf que dans la plupart des missions, ce que je découvre en creusant n'a que partiellement à voir avec le code. La dette technique existe, bien sûr. Mais elle n'est souvent que la partie visible d'un ensemble plus large : dette organisationnelle, dette de documentation, dette de compétences. Et tant qu'on ne traite que la première, on ne fait parfois que déplacer le problème, ou pire, l'aggraver. La dette technique n'est que la partie visible du problème.</figcaption> </figure> Je voudrais raconter ici une mission qui illustre bien ce mécanisme, parce qu'elle m'a appris quelque chose que je n'avais pas anticipé : améliorer le code peut, dans certaines conditions, empirer la situation globale d'une équipe. Un goulot d'étranglement humain</h2> Dès mes premiers entretiens avec les développeurs, quelques heures après mon arrivée, un pattern est apparu clairement : une seule personne assurait toute la QA de l'application. Toute. Chaque fonctionnalité, chaque correctif, chaque évolution passait par elle avant de pouvoir être livré. Ce n'était pas qu'un problème de capacité. En discutant avec elle, j'ai perçu une vraie fatigue, un débit de parole élevé, des hésitations, une personne qui se perdait dans ses explications. Je lui ai dit, assez directement, qu'elle devait se ménager, parce qu'à ce rythme elle n'allait pas tenir. C'est exactement ce qui s'est passé peu de temps après. Au-delà de l'aspect humain, c'était aussi un risque business direct : cette personne était la seule à connaître l'application dans son ensemble. Un classique bus factor de un. Si elle s'arrêtait, ce n'était pas juste la QA qui s'arrêtait, c'était potentiellement l'activité de l'entreprise qui se retrouvait menacée. J'ai identifié deux priorités immédiates : mettre en place des suites de tests end-to-end pour sécuriser les workflows complexes de l'application, et lui trouver un binôme pour répartir la connaissance métier. La première action a bien avancé pendant ma mission, même si le périmètre de l'application était large et que le travail se poursuit encore aujourd'hui par l'équipe. La seconde s'est heurtée à un mur : l'absence totale de documentation du comportement attendu de l'application. Sans elle, impossible de former qui que ce soit, développeur comme QA. Et malgré mon insistance, le binômage n'a jamais eu lieu pendant ma mission. Je pense que l'impact réel de cette situation n'a pas été pleinement mesuré côté client. Les effets en cascade</h2> Ce goulot d'étranglement ne se contentait pas de ralentir les livraisons, il générait des effets secondaires qui, eux, ressemblaient à s'y méprendre à de la dette technique classique. Une fonctionnalité prête attendait parfois longtemps avant d'être prise en charge par la QA. Pendant ce temps, sa branche vieillissait, et chaque développeur devait la rebaser régulièrement sur master</code> pour ne pas perdre le fil. C'est un travail invisible, répétitif, qui ne produit aucune valeur, mais qui devient nécessaire uniquement parce que la file d'attente en aval n'avance pas. Une dette organisationnelle qui se transforme en charge technique. Un goulot d'étranglement unique, et ses effets en chaîne.</figcaption> </figure> Les allers-retours entre développement et QA prenaient eux aussi énormément de temps, ce qui faisait mécaniquement déraper les deadlines. Et en bout de chaîne, la pression du calendrier poussait parfois à livrer des choses qui n'étaient pas techniquement abouties. Un comble, pour un process censé garantir la qualité. Cette pression ne restait pas cantonnée à la QA. Elle se diffusait à toute l'équipe de développement, qui sentait bien que le rythme des livraisons ne suivait pas, sans toujours pouvoir agir dessus. Ce genre de tension continue, même quand elle reste discrète au quotidien, finit par peser sur le moral collectif : le sentiment de courir après un retard qu'on ne rattrape jamais est usant, bien au-delà de la seule personne en première ligne. Le paradoxe de l'optimisation locale</h2> Comment un chantier technique qui a parfaitement fonctionné a-t-il pu, au final, aggraver la situation ? C'est le point que je trouve le plus intéressant, et le plus contre-intuitif, de cette mission. J'ai mis en place de la CI/CD et des suites de tests automatisés, avec un objectif précis : détecter les défauts en amont, avant qu'ils n'atteignent la QA, pour la décharger des livraisons de mauvaise qualité. Sur ce plan-là, ça a très bien fonctionné. Ce n'est pas la partie technique qui a échoué. Le problème est venu d'ailleurs. En fluidifiant le pipeline de développement, ces améliorations ont aussi accéléré le rythme de production. Nous avons ensuite accompagné les développeurs sur l'usage de l'IA pour les aider dans leurs tâches. Mais l'effet net n'a pas été du meilleur code, il a été plus de code. Plus de fonctionnalités livrées, plus vite, avec une qualité de base qui ne s'améliorait pas vraiment. Résultat : encore plus de volume à faire passer par le même goulot d'étranglement humain, désormais sous une pression accrue. Chaque optimisation locale que j'apportais au système ne faisait que déplacer la contrainte, et parfois l'intensifier, plutôt que de résoudre le vrai problème. Accélérer en amont du goulot ne fait qu'allonger la file d'attente.</figcaption> </figure> Bref, c'est une illustration assez nette d'un principe qu'on retrouve dans la théorie des contraintes : optimiser une étape qui n'est pas le goulot d'étranglement du système n'améliore pas le débit global, ça déplace simplement la pression vers le vrai point de blocage. Ce qu'un freelance peut, et ne peut pas, résoudre seul</h2> Cette mission m'a laissé une conviction assez claire. La dette technique, un freelance peut la traiter directement : refactoring, tests, CI/CD, ce sont des leviers qui dépendent largement de sa propre action. La dette organisationnelle, en revanche, demande une reconnaissance et une volonté qui appartiennent au client. On peut alerter, documenter le risque, proposer des solutions concrètes, mais on ne peut pas décider à la place de l'entreprise de réorganiser une équipe ou de recruter un binôme. Ce n'est pas un constat pessimiste. C'est plutôt une invitation à élargir le diagnostic dès le départ d'une mission. Quand on me parle de vitesse de production, je sais d'expérience qu'il faut regarder au-delà du code : où est le vrai goulot d'étranglement, qui porte seul une connaissance critique, quelle documentation manque pour que cette connaissance puisse être transmise. La dette technique se corrige avec du temps et de la rigueur. La dette organisationnelle, elle, ne se corrige qu'avec une décision. Et celle-ci n'appartient jamais au freelance. Ports and Adapters at compile-time for Rust 2023-08-28T15:00:00+00:00 Dans ce dépôt</a>, je propose une façon simple et efficace de mettre en œuvre une inversion de dépendances avec Rust. Plus particulièrement lorsque le besoin est de substituer les dépendances lors de la compilation et d'éviter le Dynamic Dispatch</a>. Très utile pour les tests unitaires et le TDD, mais aussi pour proposer des binaires avec des variantes d'implémentation. Par exemple pour livrer un webservice dans 2 versions , une pour Postgres et l'autre pour SqlLite. Le code fait appel à la compilation conditionnelle</a>, il est simple et lisible, mais destiné à des développeurs avancés qui ont déjà quelque notions de ces concepts. J'insiste cependant sur le fait qu'il vaut mieux ne pas introduire d'abstraction tant qu'elle n'est pas indispensable, ce serait contre-productif. Cadeau !!! Elixir amqp 1.2 et confirm handler 2019-05-15T13:25:00+00:00 RabbitMq permet de recevoir des confirmations de ventilation des messages par l'exchange. Le client Elixir, amqp (> 1.2)</code> permet d'attendre de manière bloquante ces confirmations, mais ne propose pas d'API pour enregistrer un handler. Ce qui m'a donné l'opportunité de faire cette contribution, qui fait maintenant partie de la version 1.2. Cet article résume l'histoire de cette contribution à des fins didactiques. Le contexte</h2> La fonctionnalité de publisher confirm</a> proposée par RabbitMq, permet en sacrifiant un peu de performances, d'obtenir une confirmation que le message publié à bien été accepté par les queues destinataires. Imagine que tu publie un message dans le bus AMQP, ce que tu obtiens de manière synchrone lors d'un publish, c'est une confirmation que l'exchange à bien reçu le message. Cela ne garanti pas que le message est bien ventilé vers les queues enregistrées comme destinataires. Une option serait d'utiliser les transactions du protocol AMQP 0-9-1</code>, mais elle ont un énorme impacte sur le débit de messages. L'autre option est d'utiliser une extension du protocole proposée par RabbitMq: publisher confirm. Cette extension te permet de d'activer le mode confirmation pour un channel. Ce qui a pour effet de reproduire le sémantique de l'acquittement de message, au niveau de l'exchange. Quand celui-ci parvient a router un message, il retourne un message d'acquittement. Le paquet Hex amqp < 1.2</code> expose une fonction AMQP.Confirm.select/1</code> qui permet de d'activer les confirmations sur le channel. Et une suite de fonctions wait_for_confirms*(/1|/2)</code></a> qui permettent d'attendre de manière synchrone la confirmation des derniers messages envoyés. Dans mon système je conserve un état des messages à envoyer, et des messages envoyés avec succès. Mais je ne souhaite pas bloquer l'acteur en charge de publier les messages pour valider la confirmation de l'envoi de ceux-ci. J'aimerais plutôt exploiter au mieux l'outillage en déléguant la confirmation de l'envoi à un autre acteur. En me documentant sur le fonctionnement du publisher confirm et des recommandations pour RabbitMq, et en lisant le code source d'autres clients, je me suis rendu compte que plusieurs clients implémentaient un fonction register_confirm_handler</code> et next_publish_seqno</code>. Ces fonctions permettent respectivement de déclarer un handler pour traiter les confirmations et d'obtenir l'identifiant du message publié pour un channel. C'est justement ce dont j'avais besoin. Le client Elixir s'appuyant sur le client Erlang, qui lui implémement ces fonctions, il n'y avait plus qu'à se pencher pour récolter, permettant de fermer quelque issues au passage. Le développement</h2> Je vais ré-exposer les fonctions proposée par Erlang, dans la continuité de la codebase actuelle. Habituellement je consulte donc avec la plus grande précaution les consignes de contribution. Mais dans le cas présent elles brillaient par leur absence. Dans ce cas, je m'imprègne des pratiques des mainteneurs précédents en explorant le code source. Je trouve que c'est une étape indispensable, open source, ou pas. Cela contribue à rendre le code homogène et compréhensible. Ensuite j'écris un test simple. Je n'argumente plus sur la nécéssité d'écrire les tests en premier. Dans un premier temps le setup. Il me faut : une connection pour obtenir un channel</li> un channel pour selectionner le mode confirmation.</li> un callback pour fermer la connection proprement à la fin du test</li> </ul> Puisque toute les opérations se font au niveau du channel, je l'ajoute au contexte qui sera passé en argument du test. // test/confirm.exs defmodule ConfirmTest do use ExUnit.Case alias AMQP.Connection alias AMQP.Channel alias AMQP.Confirm setup do {:ok, conn} = Connection.open {:ok, chan} = Channel.open(conn) :ok = Confirm.select(chan) on_exit fn -> :ok = Connection.close(conn) end {:ok, chan: chan} end // ... </code></pre> Ensuite le premier test, simple, récupérer le numéro de séquence du message. En consultant la documentation de RabbitMq et du client Erlang, je comprend que le premier numéro de séquence d'un channel vide est 1 et que la fonction Erlang</a> attend l'identifiant du process channel en argument. Ensuite je décide du nom et module de la fonction, en m'inspirant des pratiques du code source actuel, qui est de reprendre celui de la fonction Erlang. Voci le test: describe "next_publish_seqno" do test "returns 1 whe no messages where sent", ctx do assert 1 == Confirm.next_publish_seqno(ctx[:chan]) end end </code></pre> Il ne reste plus qu'a le lancer pour le regarder échouer, puis écrire le code pour le faire passer. Dans le module AMQP.Confirm</code>, j'ajoute une fonction qui: Prend une structure Channel</code> en argument</li> Appelle la fonction Erlang</li> Retourne le résultat sous forme d'entier positif</li> </ul> # lib/amqp/confirm.ex @doc """ On channel with confirm activated, return the next message sequence number. To use in combination with `register_handler/2` """ @spec next_publish_seqno(Channel.t) :: non_neg_integer def next_publish_seqno(%Channel{pid: pid}) do :amqp_channel.next_publish_seqno(pid** end </code></pre> Ensuite je regarde le test passer, easy :) Deux points très importants ici: puisqu'il s'agit d'ajouter cette fonction a l'API publique de la bibliothèque, j'écris une spécification de sa signature en bonne et due forme.</li> Pour les mêmes raisons, je me fends d'une documentation d'utilisation.</li> </ul> L'étape suivante c'est d'ajouter la fonction qui permet d'enregistrer un handler. Tous ce que qui a été dit avant reste vrai (tests, documentation, conventions ...). La fonction Erlang register_confirm_handler</code></a> attend en argument les identifiants du channel et du handler et retourne un ok</code>. La documentation précise également que le handler recevra une structure en guise de message #basic.ack{}</code> ou #basic.nack{}</code>. Ce ne sont pas des structures valides pour Elixir, ce sont des Erlang Records. Comme la sémantique de confirmation est la même que celle de l'acquittement de messages par le consommateur, la transposition des Records Erlang vers Elixir existe déjà. En explorant le fichier core.ex</code></a> de la bibliothèque j'apprends que le process recevra un message :basic_ack</code> ou :basic_nack</code>. Il sera accompagné d'un ou plusieurs numéros de séquence. Si il y en a plusieurs, le troisième argument du message vaudra true</code>. Cette fois-ci le test consiste à: obtenir le prochain numéro de séquence</li> envoyer un message</li> déclarer le module test comme handler de confirmation</li> s'assurer que je reçoive bien la confirmation</li> s'assurer que la confirmation porte bien numéro de séquence attendu</li> </ul> describe "register_handler" do test "handler receive confirm with message seqno", ctx do seq_no = Confirm.next_publish_seqno(ctx[:chan]) :ok = AMQP.Basic.publish(ctx[:chan], "", "", "foo") :ok = Confirm.register_handler(ctx[:chan], self()) assert_receive {:basic_ack, seq_no, false} :ok = Confirm.unregister_handler(ctx[:chan]) end end </code></pre> Faire échouer les tests et passer à l'implémentation. La fonction register_handler</code> prend en argument le channel et l'identifiant du handler. Elle spawn un process qui va servir d'adapter entre les messages de Erlang vers Elixir. Ce process est supervisé ainsi que celui du handler pour réagir à la mort des process enfants</a> avec un message {:DOWN}</code>. Puis appelle la fonction privée handle_confirm</code> qui attend la réception d'un message Erlang et se charge de le transposer et de l'envoyer au handler. Pour finir elle utilise la récursion pour rester à l'écoute. @doc """ Register a handler for confirms on channel. The handler will receive either: * `{:basic_ack, seqno, multiple}` * `{:basic_nack, seqno, multiple}` The `seqno` (delivery_tag) is an integer, the sequence number of the message. `multiple` is a boolean, when `true` means multiple messages confirm, upto `seqno`. see https://www.rabbitmq.com/confirms.html """ @spec register_handler(Channel.t, pid) :: :ok def register_handler(%Channel{pid: pid}, handler_pid) do adapter_pid = spawn fn -> Process.flag(:trap_exit, true) Process.monitor(handler_pid) Process.monitor(pid) handle_confirm(handler_pid) end :amqp_channel.register_confirm_handler(pid, adapter_pid) end defp handle_confirm(handler_pid) do receive do basic_ack(delivery_tag: delivery_tag, multiple: multiple) -> send(handler_pid, {:basic_ack, delivery_tag, multiple}) handle_confirm(handler_pid) basic_nack(delivery_tag: delivery_tag, multiple: multiple) -> send(handler_pid, {:basic_nack, delivery_tag, multiple}) handle_confirm(handler_pid) {:DOWN, _ref, :process, _pid, reason} -> exit(reason) end end </code></pre> Les tests passent, il ne reste qu'à ajouter la fonction unregister_hander/1</code>. Je ne la commenterais pas, car tu n'y apprendra rien de plus ce qui a été dit plus haut. Tu trouvera la commit dans son intégralité sur github</a>. Pour finir</h2> La PR a été intégrée et fait partie des features de la version 1.2. Le fait d'avoir adopté les conventions des mainteneurs du projet leur ont permis d'enchaîner un refactoring sans en souffrir. Et finalement je peux traiter les confirmations de manière asynchrone sans avoir à utiliser l'API du client Erlang dans mon application. Du dosage de la rouille 2019-04-17T13:25:00+00:00 Parlons de la rouille, cette délicieuse sauce qui accompagne nos soupes de poisson. Le bon dosage des ingrédients ravira le palais vos convives ! Pour faire une portion de rouille les ingrédients sont : 1/2 gousse d'ail dégermée 1/8 petit piment rouge 1/8 jaune d'oeuf 1/8 tranche de pain 1/32 L d'huile d'olive </code></pre> Plus on est nombreux autour de la table et plus on rit. Il va donc falloir multiplier la proportion des ingrédients pour atteindre un dosage équilibré. Miam ! Je profite de cet article dédié à la recette de la rouille pour évoquer Rust au passage. Non, pas le jeu vidéo pour survivaliste virtuel frustré (je plaisante, bisous !). Rust(2018)</a>: Le langage de programmation qui fait peur. {:style="float: left"} Je ne sais plus par quelle association d'idée j'en suis arrivé là. Mais je vais vous expliquer comment je calcule le dosage des ingrédients de ma rouille avec Rust. En espérant qu'a l'issu de cet article Rust ne vous intimidera plus et titillera votre palais. Pourquoi autant d'intérêt pour la rouille ?</h2> Le premier aspect séduisant de Rust est l'absence de garbage collector, évitant beaucoup de problèmes de latence. Son système de gestion de mémoire, qui martyrise les nouveaux venus, apporte un gros avantage en termes de sécurité. (Mais ce n'est pas le pays des Bisounours</a> non plus) Rust est idéal pour l'embarqué, les outils système, mais pas que. WebAssembly, protocoles réseau, concurrence, portabilité ... C'est à chacun de choisir ses arguments. La recette</h2> Pour générer un nouveau crate</code> (un package Rust</a>), il est possible d'utiliser cargo</code> (l'outil de build). cargo new doser --bin </code></pre> L'option --bin</code> précise qu'il s'agit d'un exécutable et non d'une bibliothèque. Le point d'entrée d'un crate</code>, sans surprise, est le fichier main.rs</code>. Le doseur de rouille a besoin de la recette unitaire. Profitons-en pour introduire quelques notions. // main.rs const RECIPE: &str = " 1/2 gousse d'ail dégermée 1/8 piment rouge 1/8 jaune d'œuf 1/8 tranche de pain 1/32 L d'huile d'olive "; </code></pre> C'est une constante const</code>, nommée RECIPE</code> dont on définit le type &str</code></a>. &str</code> est une référence vers une chaîne de caractères UTF-8 immuable</a>. La ligne se terminant par un ;</code> il s'agit d'une déclaration</a>. Les Ingrédients</h2> Pour modéliser les ingrédients de la recette et leurs proportions utilisons une structure dans son propre module. Un module Rust</a> peut être déclaré grâce à mod</code> suivi d'accolades {}</code>, le contenu des accolades sera alors la définition du module. Le contenu du module peut aussi être déporté dans un autre fichier qui porte le nom du module en question. Dans ce cas on omet les parenthèses. // main.rs use ingredient </code></pre> // ingredient.rs use num_rational::Ratio; pub struct Ingredient { pub label: String, pub quantity: Ratio<u32> } </code></pre> Dans notre fichier ingredient.rs</code> est défini une structure (struct</code>) que le module expose publiquement. Par défaut la visibilité est privée le mot clé pub</code> rend publique la structure et ses champs. Nos ingrédients sont composés: d'un label</code> qui contient la désignation, qui est une donnée de type String</code>.</li> d'une quantity</code> qui contient une fraction Ratio</code>.</li> </ul> use num_rational::Ratio</code> est la syntaxe d'import de Rust. Par ce biais nous indiquons que nous utilisons la structure Ratio</code> de la bibliothèque num_rational</code>. La philosophie de Rust est d'embarquer le strict minimum dans le noyau du langage et d'utiliser des crates</code> pour ajouter des fonctions ou structures. num_rational</code> ne fait pas partie du langage, c'est une dépendance externe. Pour gérer les dépendances il faut utiliser le fichier Cargo.toml</code> qui est crée à la racine du projet. [package] name = "doser" version = "0.1.0" authors = ["Cedric <cedric.brancourt@gmail.com>"] edition = "2018" [dependencies] num-rational = "0.2" </code></pre> La section dependencies</code> permet de référencer les dépendances à récupérer lors du cargo build</code> ou cargo run</code>. Le type Ratio</code> prend un paramètre si l'on regarde la définition de ce type</a>. La définition du constructeur est pub fn new(numer: T, denom: T) -> Ratio<T></code>. Puisqu'il existe plusieurs types de numériques suivant leur taille, signés ou pas, la bibliothèque utilise un type générique</a> T</code>. Qui donnera un Ratio</code> dérivé de ce type. Dans le cadre de notre recette, les quantités négatives n'étant pas possible, il ne s'agira que d'entiers non signés de 32 bits: u32</code>. À présent définissons une méthode scale</code> qui sera en charge de retourner un nouvel ingrédient multiplié par la quantité. Un nouvel ingrédient, car il n'est pas question ici de changer la valeur de l'ingrédient d'origine, mais d'en obtenir un nouveau à l'échelle de la recette. // ingredient.rs // ... impl Ingredient { pub fn scale(&self, mult: u32) -> Self { Self { label: self.label.clone(), quantity: self.quantity * mult, } } } </code></pre> impl</code> nous permet de définir des méthodes pour la structure Ingredient</code>. Nous définissons une méthode publique (pub</code>) nommée scale</code>. Elle prend en argument : &self</code> qui est une référence</a> à l'objet courant.</li> mult: u32</code> qui est notre multiplicateur de type u32</code></li> </ul> Elle retourne Self</code> qui est un alias vers le type courant, donc vers Ingredient</code> Le corps de la fonction se contente de retourner une nouvelle instance d'ingrédient dont : la quantity</code> est multipliée par mult</code>. Ce qui retourne un nouveau Ratio</code></li> le label est lui explicitement cloné. Sinon nous aurions transféré la propriété du label au nouvel ingrédient. Ce qui produirait une erreur de compilation car leur cycle de vie est différent.</li> </ul> Tests unitaires</h3> Rust permet d'écrire des tests unitaires à proximité du code source sans les embarquer dans le build de production. Beaucoup de tests qui auraient été écrits dans un langage interprété et non typé sont évités car le compilateur sert de garde-fou. L'unique test à écrire dans notre cas est de vérifier que la logique implémentée est la bonne. // ingredient.rs // ... #[cfg(test)] mod tests { use crate::Ingredient; use num_rational::Ratio; #[test] fn it_scale_quantity() { let quantity = Ratio::new(1, 2); let ingredient = Ingredient { label: "".to_string(), quantity, }; assert_eq!(ingredient.scale(2).quantity, Ratio::from_integer(1)) } } </code></pre> #[cfg(test)]</code> est une annotation destinée au compilateur. Elle indique que la section qui suit est destinée à l'environnement de test et donc ne sera pas embarquée dans le binaire de production. Ensuite est défini un module de tests avec mod tests {}</code>. Ce module importe ses dépendances à Ratio</code> et Ingredient</code> avec use</code>. Viens ensuite notre test qui n'est autre qu'une fonction précédée de l'annotation #[test]</code>. Dans ce test on crée un ingrédient avec une quantity</code> de 1/2. Puis on vérifie que la quantity</code> du résultat d'une multiplication par 2 nous donne un Ratio</code> équivalent à 1. À ce stade vous pouvez jouer avec le fichier ingredient.rs dans le Playground</a> Le parser</h2> Notre recette est une chaîne de caractères multi-lignes. Nous allons l'analyser pour retourner une collection d'ingrédients. Notre analyseur est lui aussi un module nommé parser</code>. Il expose une fonction publique: pub fn parse(input: &str) -> Vec<Ingredient> { input.lines().filter_map(&parse_line).collect() } </code></pre> Cette fonction prend en paramètre un &str</code> que nous avons déjà rencontré plus haut. Elle renvoi une collection de type vecteur</a> Vec</code>. Le type Vec</code> attend lui aussi un paramètre, qui est le type de ses éléments (Ingredient</code>). lines()</code> appelé sur input</code> renvoi un itérateur</a> sur les lignes du &str</code>. Ensuite est appelé filter_map</code></a> qui fonctionne comme un map</code> classique à quelque détails près, nous y reviendrons plus loin. L'argument &parse_line</code> est une référence à la fonction parse_line</code> qui sera appliquée sur chaque ligne. Le tout renvoi un iterator</code> de nouveau. Pour terminer nous appelons collect</code></a> qui s'applique aux itérateurs pour renvoyer une collection (Vec</code>). Revenons à notre fonction parse_line</code>. // parser.rs // ... fn parse_line(line: &str) -> Option<Ingredient> { let splits: Vec<&str> = line.splitn(2, ' ').collect(); match splits[..] { [quantity, label] => Some(Ingredient { quantity: str_to_ratio(quantity), label: label.to_string(), }), _ => None, } } </code></pre> Cette fonction prend en argument un &str</code> qui représente une ligne de texte et l'analyse pour en ressortir un Ingredient</code>. Cependant il est possible que la ligne ne soit pas formatée correctement. Dans ce cas quel est le retour de la fonction ? Rust n'a pas de nil</code> ou null</code>, comme d'autres langages il dispose de valeurs mises en boites, ici Option</code></a> qui dénote l'éventualité qu'il y ait une valeur. Option</code> est une énumération de valeurs possibles: Some(Ingredient)</code></li> None</code></li> </ul> line.splitn(2, ' ').collect()</code> divise la ligne en 2 parties à partir du premier espace, et retourne une collection. let splits: Vec<&str></code> permet de préciser le type de la collection attendue qui ne peut pas être toujours déduit par le compilateur. splits</code> est ensuite destructuré avec match</code> qui permet de faire des branches en fonction des motifs (pattern matching). Soit nous obtenons 2 éléments pour construire Some(Ingredient)</code> soit la ligne est mal formatée et donc None</code>. Lors de la construction de Ingredient</code>, to_string</code> est appelé sur label</code>. label</code> localement est de type &str</code>(référence empruntée) alors que la structure Ingredient</code> attend un String</code> (valeur possédée), to_string</code> opère la copie comme vu précédemment avec clone</code>. Puisque nous obtenons un résultat de type Option</code> , dans la fonction parse</code> nous obtenons un Iterator<Option></code>. Pour obtenir un Iterator<Ingredient></code> il suffit d'utiliser filter_map</code></a> qui va ignorer les résultats de type None</code> et déballer l'ingrédient du Some(Ingredient)</code>. Pour convertir quantity</code> qui est aussi de type &str</code> en Ratio</code>, nous utilisons la fonction str_to_ratio</code> // parser.rs //... fn str_to_ratio(s: &str) -> Ratio<u32> { let numerics: Vec<u32> = s .splitn(2, '/') .map(str::parse::<u32>) .filter_map(Result::ok) .collect(); match numerics[..] { [numer] => Ratio::from_integer(numer), [numer, denom] => Ratio::new(numer, denom), _ => panic!("Malformed recipe quantity: {:?}", numerics), } } </code></pre> Cette fonction sépare le &str</code> en 2 parties à partir du /</code> puis transforme les résultats en u32</code>. filter_map</code> est de nouveau utilisé, cette fois pour n'obtenir que le contenu des boites Result::ok</code></a>. Ensuite le résultat est décomposé avec match</code>: une seule valeur c'est un Ratio</code> depuis un entier.</li> deux valeurs c'est un Ratio</code> à partir d'un numérateur et d'un dénominateur.</li> aucun des deux c'est une erreur.</li> </ul> panic!</code></a> est une macro comme tout ce qui se termine par un !</code>. Elle termine le programme comme une exception non interceptée. En lecteur attentif, vous noterez qu'il aurait été préférable de renvoyer un Option<Ratio></code> pour sécuriser les erreurs d'analyse de la chaîne de caractères. Ce qui n'est pas fait par besoin de démontrer panic!</code> dans l'article. La chanson de la main</h2> Elle vient de loin ...</a> De retour dans notre fichier main.rs</code> voyons comment combiner tout ça. // main.rs mod ingredient; mod parser; </code></pre> Cette forme de déclaration de module précise que les modules ingredient</code> et parser</code> se trouvent dans les fichiers du même nom. La fonction main</code> du fichier main.rs</code> est, sans surprise, celle qui est exécutée lors du lancement du programme. // main.rs fn scale_ingredients(ins: Vec<Ingredient>, mult: u32) -> Vec<Ingredient> { ins.iter().map(|e| e.scale(mult)).collect() } fn main() { let scale: u32 = 2; let base_ingredients = parser::parse(RECIPE); for i in base_ingredients.iter() { println!("{}", i.scale(scale)) } } </code></pre> Cette fonction déclare une variable locale scale</code> qui est le multiplicateur de la recette. Puis utilise la fonction parse</code> du module parser</code> pour obtenir les ingrédients depuis RECIPE</code>. Ensuite nous itérons sur les ingrédients pour afficher l'ingrédient multiplié par l'échelle. iter()</code></a> Nous permet d'obtenir un Iterator</code> depuis un Vec</code>. println!</code></a> est la macro qui permet d'afficher sur la sortie standard. Pour qu'une valeur puisse être formatée pour la sortie texte, elle doit implémenter le Trait</code> Display</code></a>. Un Trait</code></a> s'apparente à une interface pour un comportement implémenté sur plusieurs types. L'implémentation de Display</code> pour notre ingrédient se déclare ainsi: // ingredient.rs impl std::fmt::Display for Ingredient { fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result { write!(f, "{} {}", self.quantity, self.label) } } </code></pre> Elle prend en argument la structure courante et une fonction de formatage</a> La macro write!</code> pousse les données formatées dans un tampon. Le format choisi est tout simplement d'afficher la quantité suivie du libellé. Pour aller plus loin</h2> L'ensemble du programme est disponible est disponible dans le Playground Rust</a>, qui permet de jouer avec le code sans avoir à installer Rust. Le code est également disponible sur github</a>. cargo test</code> permettra de lancer les tests. cargo run</code> lancera l'application (en environnement de développement). Pour continuer d'expérimenter avec Rust je recommande de tenter ces exercices : sécuriser la fonction parser::str_to_ratio</code> pour supprimer le panic!</code></li> faire en sorte de pouvoir passer le multiplicateur</a> à l'invocation du programme</li> paralléliser l'exécution des parse_line</code> avec l'outillage du langage</a></li> </ul> Un dernier conseil pour la faim et le dosage de la rouille : Rust permet beaucoup d'optimisations de gestion de la mémoire. Cependant, la maîtrise de la recette est dans le dosage ! Utiliser des références à tout bout de chandelles vous obligera à affronter le bourreau shaker</a>. Dans un premier temps abusez de clone</code>, puis optimisez progressivement. Toutes bonnes choses ayant une fin, il est temps de nous quitter. Au revoir lecteur, je pars</a>... Droits et rôles dans une architecture orientée domaine 2018-11-08T13:25:00+00:00 Le chemin à emprunter en suivant la direction Domain Driven Design (DDD) n’est pas si complexe qu’il n’y paraît. Il requiert, entre autres, de se débarrasser de certains réflexes et idées préconçues. Surtout de la fâcheuse tendance qu’on a de se projeter dans l’implémentation et la technique en zappant l’analyse du domaine. (Si vous n’êtes pas familier avec le DDD, je vous recommande de vous familiariser avec le sujet avant la lecture de cet article.) C’est vrai aussi pour la question des permissions dans le système. Cette question revient très régulièrement. Comme toujours il n’y a pas de réponse universelle, mais il y a des orientations qu’il est bon de connaître l’heure du choix venue. Comment faire cohabiter la notion de permission avec la modélisation du domaine</a> ? C’est la question à laquelle je me propose de répondre dans cet article. Questions / réponses</h2> Pour introduire la question et la réponse, je vous rapporte une conversation que j'ai eue avec un architecte logiciel externe à l'œil perçant (monsieur X). Je venais de présenter un diagramme qui détaille le flux de contrôle d'une commande (ci-dessous). (Image manquante : base_service_arch.png — perdue avec la fermeture du blog Synbioz) Voici les questions et réponses qui suivirent cette présentation. x: Dans ton modèle de flux pour l'exécution des commandes, tu places où le contrôle d'autorisation ? cb: Bonne question :) Je distingue 2 choses : le rôle et la propriété. Je suppose que tu parles du rôle. Pour moi les rôles d'un utilisateur sont liés à son identité. x: Typiquement un utilisateur doit avoir le rôle X, Y ou Z pour effectuer une action donnée. cb: En règle générale je le mettrais dans les interactors/handlers. x: Du point de vue métier, c'est généralement exprimé comme précondition à un use case. cb: Oui, en effet c'est une précondition ou un argument requis. Parfois même une règle du domaine. x: Il y a quelque chose qui me chiffonne à l'idée de passer un objet "current user" à toutes mes commandes cb: Oui, tu remarqueras que je ne parle pas de current user. C'est plus qualifié que ça. Le rôle fait partie du jargon du domaine. Dans le cadre de la revue de document par exemple : Dans mon review handler je transforme mon user en reviewer_uid</code> et je le passe a mon business tout simplement. Donc si je peux pas transformer mon user en reviewer_uid</code>, c'est qu'une condition de permission n'est pas satisfaite. La réponse sera un échec pour cause de permission. x: Et ton business va chercher les rôles ? cb: Non, si j'avais besoin de plus d'informations sur le reviewer dans mon domaine j'aurai un modèle reviewer en relation avec l'UID de l'utilisateur. x: Oui, d'office je ne comptais pas passer un objet avec des token oauth etc … :) cb: Si le rôle doit interagir avec le domaine au-delà d'une simple référence (UID), c'est le rôle que je passe (entité). Je trouve ça élégant car ça concilie la gestion du rôle et le domain model. La transformation du user en reviewer se fait dans la couche appli. Tandis que l'exploitation du reviewer se fait dans la couche domaine. x: Mais donc la responsabilité de vérifier l'autorisation revient au use case… ce qui peut élargir significativement le nombre de cas à tester :-\ cb: Non, je dirais plutôt dans la boundary. Son rôle est de transformer les objets du dehors vers ceux du domaine, ça te permet de "fail early" en validant les entrées. x: Oui ça fonctionne tant que la décision ne dépend pas des données qui vont être chargées dans le use case (typiquement une vérification de propriété) cb: Il n'y pas de "silver bullet" désolé :) La propriété c'est radicalement différent. En tout cas selon moi. Elle serait plutôt un scope d'accès aux ressources. x: Oui t'as raison je pense que ce problème-là doit être réglé via le scoping, ça devrait plus souvent se terminer en "record not found" que "unauthorized" voilà :) cb: J'ai fait un article</a> là-dessus y a longtemps. Où j'oriente vers des Activity Access control x: Ok je regarderai ça cb: Si tu le permets, je vais garder notre conversation pour que je puisse éclaircir le sujet plus tard dans le document. </blockquote> Ce monsieur X a le don de poser les bonnes questions. Ce qui en fait un collaborateur à forte valeur ajoutée. Il paraît que j'ai un don aussi : Quand quelqu'un me demande quelque chose, je lui explique comment s'en passer. C'est moisi comme super pouvoir. Exemple concret</h2> Par expérience nous utilisons des abstractions pour qualifier les composants logiciels lors de nos échanges. Mais cette pratique a la contrainte de n'être accessible qu'à ceux qui ont déjà l'expérience de l'abstraction en question. Il faut donc du concret, de l'exemple. J'aime beaucoup les exemples, mais je redoute leur principal effet pervers : ils sont souvent pris au pied de la lettre. N'oublions pas de nous inspirer des exemples, mais gardons-nous de les reproduire. Posons le contexte de l'exemple : Il s'agit d'un service qui permet de rédiger et publier des GTC</abbr>. Plusieurs processus sont inclus : rédiger un brouillon, publier un nouveau document à partir d'un brouillon, définir la version courante… Nous allons nous intéresser seulement au cas de l'ajout d'un nouveau brouillon. Puisque tout doit commencer par une analyse du domaine, parlons-en brièvement pour faire apparaître la notion de rôle dans le domaine. Notre jargon du domaine pour l'instant se résume à "ajouter" et "brouillon". Mais qui ? Dans notre contexte métier le brouillon est ajouté par son auteur. Nous avons maintenant un use case complet. Un auteur ajoute un brouillon. Le contexte technique dans notre exemple est déjà en place, car l'intégration se fait dans un système existant. Bien qu'il ne soit pas essentiel au principe de base, le contexte du système l'est pour l'exemple. Je vais donc planter le décor. Les services sont exposés au travers d'une API gateway. Elle est en charge de vérifier l'identité de l'utilisateur et d'enrichir la requête HTTP avec les propriétés liées. Les requêtes qui parviennent aux services contiennent déjà l'UID de l'utilisateur, ainsi que ses rôles dans l'ensemble du système d'information. Ces derniers viennent d'une brique d'authentification historique et n'ont pas de portée dans le domaine actuel. Par exemple, le rôle "admin" n'a aucun sens dans le contexte du domaine de la publication de conditions contractuelles. Un module rack (nommé MountApi) est en charge de filtrer et valider les paramètres reçus via HTTP. Ce qui nous affranchit de beaucoup de programmation défensive. Voilà pour le background, revenons à nos moutons. Nous avons une source d'authentification dont le rôle "admin" peut être un auteur de GTC. Faisons en sorte que notre code exprime le domaine. Notre aggregate Draft</code> (ligne 10 ci-dessous) ne pourra pas s'initialiser sans author_uid</code>. Ce qui évite de transiger avec les règles du domaine. Surtout dans le cadre d'un aggregate. Il en va de même pour toutes les méthodes du genre change_content(author_uid:, content:)</code>. De ce fait notre couche domaine dispose de la notion d'auteur, ce dernier est indispensable à l'écriture d'un brouillon. (Image manquante : domain_draft.png — perdue avec la fermeture du blog Synbioz) Si nous remontons dans la couche applicative (ligne 9 ci-dessous), notre service (command, interactor, use case) aura lui aussi besoin de ce paramètre qui doit lui être fourni, puisqu'il est une précondition au use case : (Image manquante : app_service.png — perdue avec la fermeture du blog Synbioz) Pour finir c'est dans notre couche infrastructure que nous transformons les données externes en données internes. Puisque par le canal HTTP nous obtenons des rôles avec la requête, notre handler est en charge de vérifier ceux-ci. Il agit comme une couche d'anti-corruption pour préserver les autres couches (App</code> et Domain</code>) et les garde centrées sur le domaine et isolées du reste du système. C'est une fonctionnalité partagée à travers un mixin (BaseHandler</code> ci-dessous). La stratégie est simple : Avec l'outil de gestion de permissions (ici activity_permission_engine</a>), on enregistre le handler comme une activité (ligne 15). Puis on autorise le rôle admin</code> à effectuer cette activité (ligne 17). Ensuite nous vérifions que l'utilisateur courant correspond bien à un des rôles pour lesquels l'activité est autorisée (lignes 11, et 22 à 27). S'il ne l'est pas une réponse appropriée est retournée sans aller plus loin. (Image manquante : infra_base_handler.png — perdue avec la fermeture du blog Synbioz) À présent notre handler qui utilise le mixin BaseHandler</code> peut se contenter de passer l'UID de l'utilisateur courant comme celui de l'auteur. (Image manquante : handler.png — perdue avec la fermeture du blog Synbioz) Dans notre exemple le contrôle de droits d'accès se fait au niveau de la couche infrastructure car les rôles n'ont rien de local à l'application puisqu'un contexte borné (bounded context</a>) lui est dédié. Cependant dans le contexte borné du domaine de l'authentification ils seront partie prenante de l'application, voire du domaine. Ces rôles externes ne franchissent jamais la frontière de la couche applicative. Et cette dernière n'utilise que des concepts qui font partie de son domaine d'application (auteur). This is the end, my only friend…</h2> Au-delà de l'exemple fourni il y a beaucoup de manières d'arriver au même résultat. L'important c'est de bien identifier les zones de responsabilité de chaque couche (infrastructure, domaine, application). Éviter que l'implémentation des sessions (dans le giron de l'infrastructure) ne se répande partout dans les autres couches créant du couplage et brouillant la lisibilité (comme un current_user</code> qui se balade dans les modèles). Et rendre visible, les rôles dans la couche domaine. Il ne faudra surtout pas hésiter à implémenter le rôle comme un modèle local du domaine si les règles du métier rendent nécessaire l'interaction avec le domaine. Tous ces principes peuvent être transposés, quel que soit le langage ou le framework. Ils peuvent nécessiter quelques ajustements mineurs en fonction de la nature du domaine (pour la brique d'authentification par exemple). Ils sont la pierre de Rosette de l'architecture du système. La métaphysique des systèmes proudhoniens 2018-05-17T13:25:00+00:00 Libertaire, Anarchiste, Utopiste, ZADiste, Étudiant (68) … C’est la saison ! Quelle étiquette coller à un système dessiné pour privilégier l’autonomie et l’indépendance de ses composants ? C’est une promenade philosophique, sans conclusion, qui fait le parallèle entre une « Utopie » sociale et le design d’un système. Proudhonien ?</h2> Ces deux dernières années mes recherches documentaires professionnelles ont porté principalement sur la composition de systèmes distribués, plus particulièrement sur la capacité à diviser ces systèmes en sous-systèmes découplés. L'objectif est de devenir plus efficace sur des systèmes dont l'éventail fonctionnel est large, et donc d'éviter le couplage entre les différentes fonctionnalités offertes par le système. (voir Pérégrinations vers une architecture découplée</a>) Ces recherches ont fait écho à certaines de mes lectures sur les possibles alternatives de société et plus particulièrement la pensée de Pierre Joseph Proudhon</a>. (Image manquante : Pierre-Joseph_Proudhon_thumb_650.png — perdue avec la fermeture du blog Synbioz) Aujourd'hui quand je regarde ces systèmes avec une interprétation personnelle, ils présentent en effet des qualités et similitudes avec les aspirations de P.J. Proudhon. De l'Utopie idéaliste ?</h2> On peut se laisser porter par le courant, nager à contre courant, mais aussi rejoindre la berge et continuer à pied ! Cette dernière option n'est pas envisagée quand on idéalise, mais s'avère bien plus pratique. Dans son genre, Proudhon n'était pas un idéaliste mais un pragmatique. Il donnait dans la proposition concrète. Une proposition qui tendait vers un idéal mais qui était faite aussi de compromis afin de la rendre pratique. Quitte à se contredire ! Ce qui lui a été reproché parfois. Parmi l'énumération nombreuse des droits de l'homme que la sagesse du XIXe siècle recommence si souvent et si complaisamment, deux assez importants ont été oubliés, qui sont le droit de se contredire et le droit de s'en aller. — Charles Baudelaire </blockquote> Dans la conception du système découplé il n'est point nécessaire de dogmatiser ni de réaliser l'idéal dans son intégralité. C'est une direction à suivre plus qu'un objectif à atteindre. Une force qui s'opère comme un contre-pouvoir aux processus qui sont employés par réflexe pavlovien. L'ordre sans le pouvoir</h2> Le pouvoir s'exerce sur des sujets, d'autres personnes ou entités. Quand il s'exerce sur soi, j'imagine qu'il doit s'appeler l'indépendance. Dans notre système découplé l'abolition du pouvoir autoritaire peut se traduire par un passage du mode de coopération de l'orchestration à la chorégraphie</a>. (Image manquante : orchestration_vs_choregraphy.png — perdue avec la fermeture du blog Synbioz — Building Microservices by Sam Newman, O'Reilly) Il n'y a plus de relation impérative entre les composants du système, mais une relation réactive, comme le montrent les études plus formelles</a>. La notion de contrôle de flux assurée par une cascade d'orchestrateurs disparaît au profit de l'apparition de plusieurs acteurs qui agissent de concert quand on leur donne la réplique. Si le résultat de loin ressemble à un brouhaha, localement il est loin de brouiller l'écoute. La décentralisation</h2> En passant du mode orchestration au mode chorégraphie, en plus de nous affranchir de la notion de contrôle nous décentralisons la décision pour la rendre locale. Chaque service est en charge d'opérer sur son strict périmètre de responsabilité, ses propres données. Aucun autre service ne peut faire d'ingérence dans ces dernières, ni produire d'effet de bord non maîtrisé. Il ne peut y avoir d'effets de bords sur d'autres services. Autrement dit les décisions sont prises localement et ont un impact direct local uniquement. La commune est par son essence… un être souverain. En cette qualité, la commune a le droit de se gouverner elle-même, de s'administrer, de s'imposer des taxes, de disposer de ses propriétés et de ses revenus, de créer pour sa jeunesse des écoles, d'y nommer des professeurs, de faire sa police, d'avoir sa gendarmerie, et sa garde civique ; de nommer ses juges ; d'avoir ses journaux, ses réunions, ses sociétés particulières, ses entrepôts, sa mercuriale, sa banque, etc. La commune prend des arrêtés, rend des ordonnances : qui empêche qu'elle n'aille jusqu'à se donner des lois ? Elle a son Église, son culte, son clergé, librement élus ; elle discute publiquement, en conseil municipal, dans ses journaux ou ses cercles, tout ce qui touche à ses intérêts ou excite son opinion… Il n'y a point de milieu : la commune sera souveraine ou succursale, tout ou rien — P.J. Proudhon </blockquote> Le fédéralisme</h2> Toutes mes idées économiques… peuvent se résumer en ces trois mots : Fédération agricole industrielle ; toutes mes vues politiques se réduisent à une formule semblable : Fédération politique ou décentralisation… Toutes mes espérances actuelles et futures sont exprimées par ce troisième terme, corollaire des deux autres : Fédération progressive — P.J. Proudhon </blockquote> Pour que les systèmes puissent coopérer, ils doivent adhérer à des principes communs. L'adhésion d'un service à un système est une initiative qui est gérée dans son périmètre de décision. En souscrivant à un bus d'événements commun, les services forment une fédération. (Image manquante : La_Bretagne_Fédérale - novembre 1931.jpg — perdue avec la fermeture du blog Synbioz) Le contrat de fédération, dont l'essence est de réserver toujours plus aux citoyens qu'à l'État, aux autorités municipales et provinciales plus qu'à l'autorité centrale, pouvait seul nous mettre sur le chemin de la vérité. — P.J. Proudhon </blockquote> Les échanges au sein de cette fédération sont régulés par un contrat. C'est la clé de voûte du système et de la fédération. La définition des APIs et des formats de messages échangés de manière formelle et concrète permet aux composants du système de s'intégrer sans heurts. Empaqueté et distribué, notre contrat peut être utilisé par les tests d'intégration des services qui y souscrivent pour assurer la cohésion de l'ensemble. Voila l'aspect fédéraliste du système. Son rôle est d'assurer la composition d'entités autonomes afin de pouvoir achever collectivement des projets plus grands. La propriété</h2> (Image manquante : data-ownership_thumb_650.png — perdue avec la fermeture du blog Synbioz) Chaque service est seul propriétaire et exploitant de ses données internes. Il peut ainsi garantir sa cohérence interne et son autonomie. Dans un système composé de Self-Contained Systems</a>, dont l'intégration repose sur un flux d'événements chaque système maintient sa propre version d'une donnée plus globale. Le flux d'événements est partagé entre les différents services, chacun constitue son jeu de données local à partir de ce flux. La propriété dans ce cas est non privative. Le fruit du travail d'un service, ce sont quelques effets de bords sur la donnée locale, mais surtout un nouvel événement. Événement qui sera exploité par quantité d'autres services pour en produire de nouveaux. Échanger le fruit du travail tout en mutualisant les ressources, ça laisserait rêveur plus d'un communard ! Une majorité de minorités</h2> Un État de 26 millions d'âmes, comme serait l'Italie, est un État dans lequel toutes les fiertés provinciales et municipales sont confisquées au profit d'une puissance supérieure, qui les gouvernent. Là, toute localité doit se taire, l'esprit de clocher, faire silence : hors le jour des élections, dans lequel le citoyen manifeste sa souveraineté par un nom propre écrit sur un bulletin, la collectivité est absorbée dans le pouvoir central… La fusion, en un mot, c'est-à-dire l'anéantissement des nationalités particulières, où vivent et se distinguent les citoyens, en une nationalité abstraite où l'on ne respire ni ne se connaît plus : voilà l'unité… Et qui profite de ce régime d'unité ? Le peuple ? Non, les classes supérieures. — P.J. Proudhon </blockquote> Puisque notre système est composé d'unités indépendantes dont les choix d'implémentation se font localement. Il est possible de faire cohabiter un grand nombre de services faisant tous appel à des technologies différentes. Permettant à chaque service d'exploiter les technologies qui répondent le mieux à son périmètre de responsabilités. La seule contrainte étant de respecter le contrat. Un système qui valorise la diversité plutôt que de cacher les différences derrière un ordre dicté à un niveau supérieur. Liberté, Égalité, Fraternité ou choucroute ?</h2> Au témoignage de l'histoire, la fraternité, but suprême des révolutions, ne s'impose pas : elle a pour condition la liberté d'abord, l'égalité après. Comme si la justice nous disait à tous : Hommes, soyez libres ; citoyens, devenez égaux, et puis, frères, embrassez-vous. — P.J. Proudhon </blockquote> Ce qui est vrai pour le système est vrai pour l'équipe qui le développe. Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations. — M. Conway </blockquote> Le système fonctionne plutôt bien dans des équipes autogérées. Puisque chaque membre est autonome dans son domaine, Il est indispensable que chacun ait une bonne connaissance de l'objectif global et final. Pour que chacun ait cette maitrise et cette envie positive, ils doivent être impliqués dès le début du projet. (Image manquante : liberte-egalite-solidarite-20693_thumb_650.png — perdue avec la fermeture du blog Synbioz) L'attachement au respect du contrat (API, conventions, guidelines…), est un autre pilier qui doit faire l'objet d'une grande attention. C'est ce qui garantit que le travail fourni par chacun peut s'intégrer correctement avec celui du voisin. Finalement le ciment du tout doit être la fraternité bienveillante. Se serrer les coudes, assister, écouter, concéder, concilier et réconcilier. Le système de l'humanité ne sera connu qu'à la fin de l'humanité. — P.J. Proudhon </blockquote>

Meta Lambda

Intégrer l'IA sans jeter l'argent par la fenêtre de contexte

L'agentic coding ne réinvente pas l'ingénierie logicielle, il la rend obligatoire

La dette de documentation : le passif caché qui plombe vos projets

Les impacts, au-delà de l'inconfort</h2> Le manque de documentation n'est pas qu'une gêne pour les nouveaux arrivants. Il a des conséquences concrètes et mesurables :</p>

Gloire aux Soft Skills !!!

La dette technique n'est que la partie émergée

Ports and Adapters at compile-time for Rust

Elixir amqp 1.2 et confirm handler

Du dosage de la rouille

Droits et rôles dans une architecture orientée domaine

La métaphysique des systèmes proudhoniens

Proudhonien ?</h2> Ces deux dernières années mes recherches documentaires professionnelles ont porté principalement sur la composition de systèmes distribués, plus particulièrement sur la capacité à diviser ces systèmes en sous-systèmes découplés.</p>

L'ordre sans le pouvoir</h2> Le pouvoir s'exerce sur des sujets, d'autres personnes ou entités. Quand il s'exerce sur soi, j'imagine qu'il doit s'appeler l'indépendance.</p>

La propriété</h2> (Image manquante : data-ownership_thumb_650.png — perdue avec la fermeture du blog Synbioz)</em></p> Chaque service est seul propriétaire et exploitant de ses données internes. Il peut ainsi garantir sa cohérence interne et son autonomie.</p>