Rendre la technologie complexe sereine.
Nous partageons ici ce que nous apprenons en chemin.
· 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.
· 14 min de lecture
Partie 3/4 - La séparation des tâches appliquée à la preuve : pourquoi les équipes produit ne doivent jamais être les seules autrices de leurs propres enregistrements d'audit, et comment un proxy Kafka, le CDC et la réconciliation y remédient.
· 12 min de lecture
Partie 2/4 - Construite naïvement, une piste d'audit devient le plus gros et le moins effaçable des stocks de données personnelles que vous possédez. Comment les principes de protection des données et la divulgation minimale façonnent une piste qui prouve sans exposer.
· 8 min de lecture
Partie 1/4 - Écrire « la Terre est plate » dans un log serveur ne prouve rien. Ce qu'il faut pour transformer des enregistrements en preuves : l'inviolabilité détectable, les horodatages qualifiés eIDAS 2 et des accès d'urgence tracés.
· 11 min de lecture
AES-GCM empêche quiconque de forger ou d'altérer vos données chiffrées. Il n'empêche pas de déplacer une donnée chiffrée ailleurs, ou elle sera naturellement déchiffrée. Une attaque concrète, le paramètre qui la corrige, un test qui la garde corrigée, et ce qu'il reste à protéger ensuite.
· 11 min de lecture
Partie 2/2 - Le développement piloté par l'IA a changé notre façon de livrer du code. Pour garder une revue rapide et une qualité élevée, proportionnez l'examen au risque, préférez les preuves aux affirmations, et concevez des déploiements qui rendent les erreurs peu coûteuses.
· 9 min de lecture
Partie 1/2 - Le développement piloté par l'IA a changé notre façon de livrer du code. Pour garder une revue rapide et une qualité élevée, proportionnez l'examen au risque, préférez les preuves aux affirmations, et concevez des déploiements qui rendent les erreurs peu coûteuses.
· 11 min de lecture
Quatre ères de l'ingénierie avec l'IA, et comment construire un bon harnais.
· 13 min de lecture
Quand un achat délégué tourne mal, les deux parties ont des logs, et ces logs se contredisent. Pourquoi TLS ne peut pas trancher, et ce que les signatures de messages RFC 9421 peuvent (et ne peuvent pas) y faire.
· 8 min de lecture
La sécurité ne se termine jamais sur une racine de confiance inconditionnelle ; elle s'arrête là où la couche suivante cesse d'être rentable. Pour les clés SSH sur un Mac, trois couches suffisent, et l'une d'elles est déjà dans votre portable.
· 13 min de lecture
De Scala à Kotlin puis à Go : douze ans de choix de langages back-end, les leçons derrière chaque changement, et pourquoi l'IA pourrait décider du prochain.
· 13 min de lecture
Dans la partie 1, j'ai expliqué pourquoi des scénarios de test écrits à la main gardaient nos tests au vert pendant que les dates de livraison glissaient, et pourquoi la réponse réside dans des données qui portent la forme de la production par construction. Cet article décrit la méthode en trois étapes : profiler, générer, prouver.
· 6 min de lecture
Nous avions tout bien fait : des scénarios clairs, des jeux de données réalistes, le tout sous gestion de versions. Pourtant, chaque fois que nous rencontrions des données proches de la production, de nouveaux bugs apparaissaient. Nous ne pouvions plus dire quand nous aurions terminé. La leçon : des données synthétiques à grande échelle, construites à partir de profils réels, corrigent la forme d'imprévisibilité la plus coûteuse.
3 min de lecture
J'ai passé les 25 dernières années dans la tech. En chemin, j'ai vu beaucoup de programmes échouer. Quelques-uns ont échoué bruyamment, avec des contrats résiliés et des conseils d'administration difficiles. La plupart ont échoué en silence. Les échéances ont glissé un sprint après l'autre. Les budgets se sont étirés. Le périmètre a été rogné jusqu'à ce que ce qui a fini par être livré ne soit plus que l'ombre de ce qui avait été promis.
10 min de lecture
Les requins ont les films. Les moustiques ont les victimes. Les programmes meurent rarement d'un échec spectaculaire, mais de mille oui raisonnables. Les dix visages du piège de la vitesse, et comment tenir un cap.
11 min de lecture
Les programmes coulent rarement à cause d'une mauvaise idée. Ils coulent parce qu'ils embarquent toutes les bonnes.
14 min de lecture
Un plan est une hypothèse, pas une promesse. La plupart des programmes le traitent comme une promesse. La pensée agile aide au niveau des équipes, mais la plupart des organisations peinent encore à planifier au niveau du programme.
17 min de lecture
La plupart des programmes sont planifiés comme si les personnes étaient interchangeables, et tombent dans le piège humain. Les dix visages du piège, et comment construire des équipes qui livrent.
9 min de lecture
Les programmes meurent rarement de mauvaises décisions. Ils meurent de décisions qui ne sont jamais tout à fait prises.
9 min de lectureRédigé en anglais
Engineers want to build great programs, but ego disguised as ambition sinks them. Ten faces of the perfection trap, and how to stay ambitious without gambling.
10 min de lecture
Les programmes sont rarement lents parce que les gens travaillent lentement. Ils sont lents parce que le travail passe l'essentiel de sa vie à attendre.
11 min de lecture
Vert dehors, rouge dedans. Pourquoi des gens bien rapportent du vert sur des programmes en difficulté : dix habitudes qui font pousser une pastèque, et comment rendre la vérité facile à dire.
11 min de lecture
Le travail est réparti entre équipes, fournisseurs et systèmes, chacun avec son propre plan, son propre backlog et sa propre définition de « terminé ». Chaque équipe construit soigneusement sa partie, mais l'intégration n'a pas de propriétaire avant qu'il ne soit trop tard.
12 min de lecture
Le mariage dure une journée, mais la vie à deux, c'est tout ce qui vient après. Pourquoi des programmes livrés à temps échouent quand même, les dix visages du piège de la mise en production, et comment préparer la vie à deux, pas seulement le mariage.