· 13 min de lecture
La dette opérationnelle est de la connaissance qui n'a jamais été écrite. Les personnes pouvaient toujours demander au collègue qui savait ; les agents IA ne le peuvent pas. Pourquoi l'ère de l'IA fait du contenu ratifié et de la récupération déterministe une discipline d'ingénierie.
· 9 min de lecture
Nous mesurons la dette technique dans notre code. La dette opérationnelle vit entre nos systèmes, là où les processus ne convergent qu'à terme, grâce aux personnes. Ce que l'ingénierie des systèmes distribués nous apprend pour la rembourser.
· 13 min de lecture
Partie 2/2 - Dans les systèmes agentiques, la décision de s'arrêter est aussi importante que la décision d'agir. Le pattern guardian formalise cette décision sous la forme d'un évaluateur typé et indépendant, qui préserve l'autonomie de l'acteur tout en imposant les contraintes de sécurité et les contraintes métier.
· 8 min de lecture
Partie 1/2 - Un agent ne vaut que ce que valent ses conditions de sortie. La plupart des échecs ne sont pas de mauvais premiers pas, mais des boucles qui ne s'arrêtent jamais. Cet article défend une idée simple : les conditions d'arrêt doivent être des evals à part entière, vérifiées à chaque itération. Une nouvelle classe de modèles, que TypeSafe AI appelle les modèles System One, rend cela économiquement réaliste pour la première fois.
· 5 min de lecture
Un modèle de décision classe 10 000 avis d'app mobile pour quelques centimes, un LLM n'écrit que la synthèse, et Laya auto-hébergé garde les données dans l'entreprise.
· 10 min de lecture
Partie 4/4 - Une architecture de référence pour les pistes d'audit, rédigée sous forme d'architecture decision record : outbox transactionnelle, log de Merkle, horodatages qualifiés, crypto-shredding et un plan d'accès masqué.
· 5 min de lecture
Les standards d'architecture proposent généralement deux issues : s'y conformer, ou obtenir une exception. Les systèmes réels ont besoin d'une troisième option : un écart validé et borné qui garde la cible état de l'art (SOTA) à portée.
· 6 min de lecture
Un client qui change de banque, c'est une seule décision vu de l'extérieur, et des jours de travail long, dépendant de tiers, vu de l'intérieur. Comment child workflows, signals, updates, Nexus et Kafka trouvent chacun leur place, et où l'orchestration doit s'arrêter.