L'article "Microservices Are Killing Your Performance (And Here's the Math)" explique comment les microservices, bien qu'ils promettent une meilleure scalabilité et maintenabilité, peuvent en réalité nuire aux performances. L'auteur compare les appels de fonctions en processus (monolithes) avec les appels HTTP entre microservices, montrant que ces derniers sont 1 000 à 5 000 fois plus lents. Un exemple concret de flux de checkout e-commerce illustre cette différence, avec une architecture microservices 15 % plus lente qu'une architecture monolithique. L'article aborde également le problème N+1 des services, où les dépendances entre services entraînent des temps d'exécution plus longs. Des benchmarks réels montrent que les microservices peuvent être jusqu'à 80 % plus lents dans certaines situations, malgré des conditions réseau parfaites et l'absence de pannes de service.
L’article présente une sélection d’essais influents qui ont marqué la pensée et les pratiques de l’auteur en tant qu’ingénieur logiciel. Parmi les textes cités, on retrouve des classiques comme « Choose Boring Technology » de Dan McKinley, qui prône l’utilisation de technologies éprouvées pour éviter les risques inutiles, « Parse, Don’t Validate » d’Alexis King, qui encourage à transformer les données en types riches pour éliminer les états invalides, ou « Things You Should Never Do, Part I » de Joel Spolsky, mettant en garde contre les réécritures complètes de code. D’autres essais, comme « The Majestic Monolith » de DHH ou « The Rise of ‘Worse is Better’ » de Richard P. Gabriel, remettent en question les tendances architecturales (microservices, perfectionnisme) au profit de solutions pragmatiques et adaptées au contexte. L’auteur souligne aussi l’importance de la qualité (« Software Quality at Top Speed » de Steve McConnell) et de la valeur métier (« Don’t Call Yourself a Programmer » de Patrick McKenzie). Enfin, des conseils plus larges, comme « How To Become a Better Programmer by Not Programming » de Jeff Atwood, rappellent que les compétences techniques ne suffisent pas : comprendre le domaine, communiquer et éviter la complexité inutile sont tout aussi cruciaux. Une lecture inspirante pour repenser sa pratique du développement.
Ce partage Shaarli présente le "DDD Symfony Bundle", un outil pour intégrer le Domain-Driven Design (DDD) dans Symfony. Ce bundle offre un noyau (Kernel) prêt pour le DDD, permettant une importation automatique des configurations des différents contextes délimités (Bounded Contexts), et une intégration avec Symfony Messenger pour gérer les commandes et les requêtes via des bus dédiés. Il facilite ainsi l'autonomie des contextes délimités et maintient une architecture propre et évolutive. Le bundle est disponible sur GitHub et peut être installé via Composer.
L'article de Guillaume REYNAUD explique en détail l'architecture et le déploiement du réseau FTTH (Fibre To The Home) en France. Il détaille les équipements clés comme l'OLT (Nœud de Raccordement Optique), le SRO (Sous-Répartiteur Optique) et le PCO (Point de Connexion Optique), ainsi que leurs rôles respectifs dans la transmission du signal optique. Le réseau FTTH utilise la technologie PON (Passive Optical Network), principalement GPON ou XGS-PON, et repose sur une architecture point-à-multipoint. L'article s'adresse aux professionnels des télécommunications mais aussi aux particuliers, offrant une vue d'ensemble complète du réseau FTTH, des équipements centraux jusqu'au domicile de l'abonné.
Andrew Nesbitt explore le fonctionnement de Dependabot, un outil de mise à jour automatique des dépendances pour GitHub, GitLab et Gitea. Bien que Dependabot soit souvent perçu comme un bot intelligent, il s'agit en réalité d'une bibliothèque Ruby sans état, dont la logique de mise à jour est open source sous licence MIT, mais dont la coordination et le suivi d'état restent propriétaires. L'auteur détaille l'architecture du code, qui supporte plus de 25 écosystèmes de paquets, et explique comment Dependabot utilise des outils natifs pour effectuer les mises à jour. Malgré sa complexité, Dependabot-core est conçu pour être sans état, traitant chaque tâche de manière indépendante.
Lea Verou aborde dans cet article les problèmes de gestion des dépendances sur le web, soulignant que contrairement à d'autres écosystèmes comme NodeJS ou Python, le web a externalisé cette fonctionnalité fondamentale à des outils tiers comme les bundlers (Webpack, rollup, etc.). Elle explique que la gestion des dépendances devrait être une fonctionnalité native de la plateforme, simple et intuitive, plutôt qu'une tâche complexe nécessitant des outils avancés. Verou discute des solutions potentielles, comme les import maps, et plaide pour une amélioration de l'architecture web afin de rendre les dépendances aussi faciles à gérer que dans d'autres environnements de développement.
En 2026, jusqu’à 79 % des tâches traditionnellement confiées aux développeurs juniors pourraient être automatisées par l’IA, remettant en cause les méthodes de formation classiques (syntaxe → implémentation → architecture). Le marché de l’emploi junior se contracte (-40 % à -46 % d’offres selon les pays), mais le vrai défi est pédagogique : former des profils capables de concevoir et d’évaluer des architectures logicielles, plutôt que de simplement produire du code. Les juniors doivent désormais maîtriser l’architecture, les patterns de conception, l’infrastructure et l’audit de code dès le début de leur apprentissage, l’IA prenant en charge la syntaxe. Des expérimentations émergent, comme l’introduction du System Design dès les premières semaines ou l’utilisation de l’IA comme outil d’apprentissage critique. Sans cette inversion, les juniors risquent de devenir des copier-colleurs rapides, générant du code qui "marche" en démo mais accumule dette technique et bugs en production. L’enjeu : éviter une génération de développeurs coincés au niveau débutant, incapables de devenir seniors. Pour les managers, cela implique de repenser le mentorat, de privilégier la qualité à la quantité, et d’encourager l’apprentissage par l’échec et l’analyse. Les écoles et entreprises pionnières (comme Columbia Engineering) testent déjà ces approches, mais la France reste en retard. La question n’est plus de savoir s’il faut changer, mais comment s’y prendre.
L'auteur explique la conception d'une architecture d'audit en deux phases pour Symfony, visant à concilier atomicité et performance. La première phase, transactionnelle (onFlush), capture les changements de données dans la base de données, garantissant ainsi la cohérence. La seconde phase, asynchrone (postFlush), envoie les logs d'audit vers des destinations externes sans impacter les performances de l'application. L'article détaille les avantages de cette approche et les choix architecturaux clés, comme l'utilisation de la méthode onFlush plutôt que des callbacks de cycle de vie.
Cet article explore quatre styles architecturaux d'APIs : REST, webhooks, gRPC et HATEOAS. Il explique l'importance cruciale du choix de l'architecture pour la réussite d'une API, impactant l'intégration, la performance et la scalabilité. REST, le plus populaire, est simple, stateless et cacheable, idéal pour les services web standards. Les webhooks, en deuxième position, permettent une communication asynchrone et sont souvent utilisés pour l'automatisation. L'article fournit des exemples concrets et des raisons de choisir chaque style.
L'article explique le pattern CQRS (Command Query Responsibility Segregation), qui sépare les opérations de lecture et d'écriture vers la base de données. Ce pattern permet d'optimiser les performances et la sécurité en utilisant des modèles de données distincts pour les lectures et les écritures. L'article explore différentes implémentations du CQRS et montre comment Debezium peut simplifier sa mise en œuvre, notamment dans les architectures microservices.
L'article met en garde contre la sur-ingénierie et l'utilisation excessive de motifs de conception complexes dans des projets qui ne le nécessitent pas. L'auteur illustre son propos avec un exemple extrême où une simple concaténation de chaînes de caractères est transformée en une architecture complexe impliquant des interfaces, des usines et des modules. Il identifie plusieurs drapeaux rouges, comme la "future-proofing" fallacieuse, les interfaces avec une seule implémentation, et les abstractions prématurées. L'auteur propose une checklist pour évaluer la nécessité d'une abstraction et encourage à supprimer les mauvaises abstractions. Il conclut en rappelant que le code "scalable" ne doit pas être surestimé et que la simplicité est souvent la clé.
L'article explore l'architecture DCI (Data, Context, Interaction) proposée par Trygve Reenskaug et James O. Coplien en 2009, qui critique l'approche traditionnelle de la programmation orientée objet (POO) pour sa difficulté à capturer les comportements complexes et les collaborations entre objets, essentiels pour aligner le modèle mental de l'utilisateur avec le fonctionnement du logiciel. Les auteurs soulignent que la POO excelle dans la modélisation des structures mais échoue à représenter les interactions complexes, comme un transfert d'argent entre comptes, qui sont pourtant centrales dans la compréhension utilisateur. L'article propose une réflexion sur l'amélioration de l'architecture logicielle pour mieux refléter ces interactions.
Kevin Goldsmith partage ses réflexions sur l'importance d'une stratégie technique claire et documentée pour les organisations technologiques. Il souligne que l'absence de stratégie commune entraîne des décisions divergentes, des choix architecturaux inadaptés et une frustration des partenaires produits. Une bonne stratégie doit être alignée avec les objectifs business, cohérente, compréhensible, et évolutive. Goldsmith recommande de travailler à rebours en imaginant le futur état souhaité pour définir les étapes nécessaires pour y parvenir.
L'article explore quatre modèles avancés pour résoudre des défis architecturaux complexes en utilisant Symfony 7.x et PHP 8.x. Il aborde des problèmes tels que la gestion des API lentes, la communication avec de multiples endpoints, la création de logs d'audit et le téléchargement de fichiers volumineux. L'auteur illustre ces concepts avec des exemples pratiques, notamment l'utilisation de Symfony Messenger pour découpler les tâches non critiques des interactions utilisateur, améliorant ainsi l'expérience utilisateur. L'article est une ressource précieuse pour les développeurs cherchant à optimiser leurs applications avec Symfony.
Ce billet introduit l'architecture RAG (Récupération Augmentée par Génération) comme solution aux hallucinations des LLM (Large Language Models). Les hallucinations, résultant du fonctionnement probabiliste des LLM, sont des réponses inventées par l'IA en l'absence de données suffisantes. L'architecture RAG propose de remédier à ce problème en combinant la capacité des LLM à générer du texte avec une base de données fiable et contrôlée. Ainsi, l'IA peut générer des réponses plus précises et sourcées, évitant ainsi les inventions non fondées.
dependency-cruiser est un outil open source qui permet de valider et visualiser les dépendances dans les projets JavaScript, TypeScript, CoffeeScript ou LiveScript. Il analyse les dépendances selon des règles personnalisables, détecte les violations (comme les dépendances circulaires ou manquantes), et génère des rapports sous forme de texte, graphiques (dot, mermaid, SVG), HTML ou CSV. Idéal pour intégrer dans un pipeline CI/CD, il s’installe via npm/yarn/pnpm et se configure facilement avec npx depcruise --init. Il offre aussi des visualisations claires pour mieux comprendre l’architecture de son code.
Shopify gère 30 To de données par minute pendant des événements comme le Black Friday, tout en maintenant une architecture "monolithique modulaire" et scalable. Leur secret ? Une approche disciplinée basée sur un monolithe modulaire en Ruby on Rails, organisé en "quartiers" logiques (checkout, paiements, commandes, etc.), chacun avec sa propre équipe et ses responsabilités claires. Ils utilisent l’architecture hexagonale (Ports and Adapters) pour isoler la logique métier des dépendances externes, et des Pods (clusters isolés) pour répartir la charge et limiter les pannes. Leur pipeline de données repose sur Debezium + Kafka pour du traitement en temps réel, tandis que MySQL, optimisé avec des centaines de shards et un équilibrage dynamique, supporte 10 millions de requêtes par seconde. Grâce à des outils internes comme Packwerk (pour la modularité) et Sorting Hat (pour le routage intelligent), Shopify prouve qu’un monolithe bien conçu peut rivaliser avec des architectures microservices, même à l’échelle mondiale — tout en restant simple, fiable et "ennuyeusement" efficace. Une leçon de sobriété technique à l’ère de l’hyperscale.
La multi-location (multi-tenancy) en base de données désigne une architecture où une seule instance d’application et d’infrastructure sert plusieurs clients (tenants), tout en garantissant une isolation logique de leurs données. Ce modèle, largement adopté dans le cloud, permet une meilleure scalabilité, une réduction des coûts de maintenance et une optimisation des ressources. L’article détaille quatre approches principales : base unique avec schéma partagé (simple mais risqué en cas d’oubli de filtrage par tenant), base unique avec schémas séparés (meilleure isolation mais complexité accrue), base dédiée par tenant (isolation maximale mais coûteuse en gestion), et plusieurs bases avec tenants partagés (compromis entre coût et performance). Chaque méthode présente des avantages et des inconvénients selon les besoins en sécurité, performance et maintenance
Le Backend For Frontend (BFF) est un pattern architectural qui agit comme une couche intermédiaire entre les applications frontend (web, mobile, etc.) et les API ou microservices. Son objectif est de simplifier la récupération et la transformation des données en centralisant la logique d’agrégation et d’adaptation des données côté serveur, plutôt que de la laisser aux clients. Cela évite de surcharger les applications frontend avec des tâches complexes et permet d’offrir une réponse sur mesure, optimisée pour chaque type de client (mobile, web, etc.). Contrairement à une API Gateway, le BFF est dédié à un type spécifique de client, ce qui permet de mieux répondre à ses besoins en termes de format de données, gestion d’erreurs ou authentification. Ce pattern est particulièrement utile dans un contexte MACH (Micro Services, API-first, Cloud Native, Headless) ou lorsque les besoins des utilisateurs varient selon le type d’application, mais il ajoute une couche supplémentaire à maintenir et nécessite des compétences fullstack. Son adoption se justifie surtout si l’expérience utilisateur doit être différente selon les plateformes.
Alexandre Touret partage son retour d’expérience sur un atelier d’Architecture Kata organisé lors de la Riviera Dev, où plus de soixante participants ont planché sur la conception d’une plateforme numérique dédiée au tourisme solidaire et durable. L’objectif était de proposer une solution intégrant profils utilisateurs éco-responsables, tableau de bord d’empreinte carbone, gamification et gestion d’activités locales, avec des contraintes techniques et métiers variées. L’article présente trois approches distinctes : deux propositions d’équipes (dont une très détaillée avec des diagrammes Structurizr) et la sienne, soulignant l’importance de clarifier les besoins métiers, de prioriser les flux principaux et d’externaliser les fonctions critiques (comme les paiements). L’exercice illustre la diversité des solutions possibles selon l’expérience des participants et rappelle que la pratique régulière des katas permet d’améliorer la prise de décision, la communication et l’adaptabilité en architecture logicielle. Une ressource utile pour quiconque s’intéresse à l’amélioration des compétences en design système.