L'article critique l'organisation typique des projets informatiques, où les fichiers sont regroupés par type (Commandes, Contrôleurs, Formulaires, Entités, etc.) plutôt que par fonctionnalité. L'auteur illustre comment cette approche, bien que pratique au début, devient problématique à mesure que le projet grandit, entraînant une dispersion des fonctionnalités et un codebase difficile à maintenir. Il suggère une organisation par domaine ou fonctionnalité pour faciliter l'évolution et l'entretien du projet.
L’article décrit une approche simple d’architecture logicielle pour des pipelines ETL en se basant sur une organisation en packages « input », « output » et « use case » pour structurer le code de lecture, d’écriture et de logique métier, adaptée à une mise en œuvre serverless avec AWS Step Functions et Lambda. Il souligne que la complexité vient moins des technologies qu’à bien définir les domaines métier (ex. Observabilité vs Applications) et que pour chaque domaine il vaut mieux créer une fonction dédiée tout en réutilisant du code commun via des couches Lambda (AWS Lambda layers) plutôt qu’imbriquer des traitements sans séparation claire des responsabilités.
Atomic Design est un modèle de composition d'interfaces utilisateur (UI) bien connu, mais souvent mal utilisé comme architecture d'application complète. Cet article explique que Atomic Design excelle dans l'organisation de l'UI, mais ne répond pas aux questions de domaine, d'orchestration des flux applicatifs ou de gestion de l'état métier. Il propose de séparer clairement la composition de l'UI (où Atomic Design a sa place) de l'architecture applicative, avec des règles strictes pour éviter le couplage caché et maintenir la réutilisabilité des composants. Les features deviennent ainsi l'unité architecturale principale, contenant la logique métier et l'orchestration. Cette séparation améliore également la stratégie de test, avec des tests visuels pour l'UI et des tests d'intégration pour les features.
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.