Sujet : design
-
Pipeline, répartition parallèle, orchestrateur et comité de relecture : quel patron multi-agent pour quelle tâche
Un pipeline convient aux tâches formées d'une séquence fixe de transformations ; la répartition parallèle (fan-out), aux sous-questions indépendantes ou aux tentatives répétées dont les résultats sont soumis au vote ; un orchestrateur avec des agents exécutants, aux tâches dont la décomposition n'est connue qu'à l'exécution ; un comité de relecture, aux résultats à évaluer selon plusieurs critères. Chaque patron multiplie le coût en tokens et ajoute une couche de coordination susceptible de connaître ses propres défaillances.
-
Event sourcing et CQRS : leurs avantages et leurs coûts
L’event sourcing enregistre chaque changement d’état sous forme d’événement immuable et reconstitue l’état courant par rejeu ; CQRS sépare le modèle d’écriture des modèles de lecture. Tous deux apportent de l’auditabilité et de la souplesse au prix d’une complexité accrue et d’une cohérence à terme.
-
La dette technique : métaphore et décision
La dette technique décrit le coût futur d'un raccourci ; la métaphore est utile lorsque la dette est délibérée et suivie, et trompeuse lorsqu'elle sert à excuser un travail négligé ou à désigner la moindre imperfection.
-
Conception de la mémoire d'un agent : ce qu'il faut conserver, résumer et oublier
La mémoire d'un agent comporte trois niveaux : la fenêtre de contexte, un bloc-notes de tâche et un stockage durable entre sessions ; décider pour chaque élément à quel niveau il appartient, garder la mémoire durable petite et révisable, et supprimer ce qui n'est plus vrai.
-
Liste de contrôle de revue de confidentialité pour une fonctionnalité
Dix questions auxquelles une personne chargée de la revue répond avant la mise en production d'une fonctionnalité : inventaire des nouvelles données personnelles, décisions de minimisation, tâche de rétention, accès et journalisation des accès, couverture de l'export et de la suppression, finalités de préférence, flux vers des tiers, une brève passe LINDDUN, données de test, et un résultat consigné ; uniquement des propriétés d'ingénierie, sans évaluation juridique.
-
Le mode sombre avec prefers-color-scheme, color-scheme et light-dark()
Le mode sombre comporte trois volets : la media query prefers-color-scheme pour détecter le choix de l'utilisateur, la propriété color-scheme (et la balise meta correspondante) pour indiquer au navigateur quels schémas la page prend en charge afin que les contrôles de formulaire, les barres de défilement et le canevas suivent, et light-dark() ou des propriétés personnalisées pour permuter les valeurs de palette sans dupliquer les règles.
-
La boucle du développement piloté par les tests
Écrire un test qui échoue, le faire passer avec la modification la plus simple possible, puis refactoriser une fois les tests au vert ; la boucle maintient les décisions de conception petites et donne à chaque ligne une raison d'exister.
-
Les dataclasses pour les enregistrements simples
Les dataclasses génèrent __init__, __repr__ et l'égalité à partir des champs annotés ; les dataclasses frozen donnent des objets-valeur immuables, slots réduit la mémoire, et field(default_factory=...) évite le partage de valeurs par défaut mutables.
-
Reconnaître les code smells avant de refactoriser
Les code smells sont des symptômes de surface (méthodes longues, grandes classes, feature envy, shotgun surgery, primitive obsession) qui suggèrent un problème de conception plus profond ; les nommer donne un vocabulaire pour la revue et un déclencheur pour le refactoring.
-
Concevoir les exceptions d'une bibliothèque Python
Définir une exception de base par bibliothèque, en dériver des erreurs spécifiques, lever ces erreurs avec du contexte, chaîner les causes avec « raise ... from », et ne capturer étroitement qu'à la frontière où l'échec peut être traité.
-
Modéliser des états avec Literal, Enum et TypedDict
Remplacer les chaînes libres et les dictionnaires non typés par des unions Literal, des énumérations et des TypedDict, afin que les états impossibles soient rejetés par le vérificateur de types et documentés en un seul endroit.
-
Quand une équipe doit-elle découper un monolithe en services ?
Question ouverte : quels signaux observables (couplage de déploiement, frontières d'équipe, besoins de mise à l'échelle, schémas d'incidents) ont précédé des extractions réussies de services à partir d'un monolithe, et quelles extractions ont ensuite été annulées ?
-
Les points d'approbation humaine dans les flux de travail d'agents : quelles actions en ont besoin
Un point d'approbation met un agent en pause avant une action et laisse une personne l'autoriser ou la refuser ; soumettre à approbation les actions irréversibles, visibles de l'extérieur, coûteuses ou modifiant des privilèges, laisser le reste automatique, et montrer à la personne exactement ce qui serait exécuté.
-
Commencer par un monolithe l'emporte sur commencer par des microservices
Hypothèse : les nouveaux produits qui débutent sous la forme d'un monolithe bien structuré atteignent un modèle de domaine stable plus rapidement et avec moins d'incidents opérationnels que ceux qui débutent en microservices ; les découper plus tard, le long de frontières éprouvées, coûte moins cher.
-
Modélisation des menaces sur la vie privée avec LINDDUN, en résumé
Parcourir un diagramme de flux de données élément par élément au regard des sept types de menaces LINDDUN (corrélation, identification, non-répudiation, détection, divulgation de données, méconnaissance et non-intervenabilité, non-conformité), consigner des scénarios par élément et choisir des mesures d'atténuation dans une liste courte ; un format en une seule séance, calqué sur une séance STRIDE.
Lisible par machine : JSON