Le Spec-Driven Development (SDD) est une approche où la spécification formalisée devient l'artefact central du projet, guidant l'architecture, l'implémentation et les tests. Cette méthode vise à éviter les incompréhensions et la dette technique en clarifiant les comportements attendus avant l'implémentation. La spécification est versionnée avec le code et doit être maintenue à jour, agissant comme un contrat que l'implémentation doit respecter. Le cycle SDD comprend plusieurs phases itératives, dont la rédaction des exigences et des critères d'acceptation, avant de passer à l'implémentation et aux tests. #SpecDrivenDevelopment #DéveloppementLogiciel #GestionDeProjet
Récap du jour 2 de Touraine Tech 2026 : Une journée riche en retours d’expérience techniques et humains. Florian Forestier a partagé une aventure de debugging bas niveau sur du matériel réseau obsolète, révélant comment une vieille version d’Ubuntu a permis de résoudre un bug kernel lié aux pilotes QLogic. Paul Pinault a exploré les failles de sécurité des ampoules connectées, soulignant les défis réglementaires (RED, Cyber Resilience Act) et les vulnérabilités matérielles. Antoine Caron et Mathieu Mure ont rappelé l’impact des images sur les performances web, avec des conseils pratiques pour optimiser leur chargement (AVIF, srcset, Git LFS). Matthias et Sylvain Gougouzian ont présenté un projet maker familial inspirant, mêlant apprentissage technique et communication intergénérationnelle. Enfin, Olivier Poncet a disséqué l’architecture ingénieuse d’Another World (1991), un jeu vidéo révolutionnaire conçu par une seule personne, mettant en lumière des optimisations matérielles et logicielles audacieuses. Une édition marquée par des échanges humains et techniques de qualité, avec une mention spéciale pour l’organisation et l’ambiance conviviale.
La Feature-Driven Architecture consiste à organiser une application autour de fonctionnalités complètes, chacune regroupant tout ce qui est nécessaire à son fonctionnement (logique, état, vues, tests), afin d’améliorer la scalabilité du code, la clarté des responsabilités et l’autonomie des équipes plutôt que de structurer le projet par couches techniques. Cette approche réduit les dépendances implicites, facilite le développement parallèle et permet de faire évoluer une fonctionnalité sans impacter les autres, tout en restant compatible avec des méthodes comme l’Atomic Design pour mutualiser des composants UI réellement génériques. Elle est particulièrement pertinente pour les applications complexes, en croissance ou développées par plusieurs personnes, où l’enjeu principal de la scalabilité concerne autant l’organisation du code et du travail que les performances techniques.
Le Context Driven Engineering émerge comme un nouveau paradigme de développement logiciel à l’ère de l’IA : au lieu de simplement générer du code à partir de prompts, les équipes doivent fournir un contexte structuré (spécifications, contraintes, règles et documentation) et suivre un workflow type spec-plan-act afin de fiabiliser la production et d’industrialiser l’usage des assistants. L’article montre que cette évolution entraîne la mise en place de règles pour les agents, d’outils de gouvernance, d’intégrations CI/CD et de nouvelles pratiques de documentation, tout en soulevant des enjeux humains et organisationnels tels que la formation des juniors, la mutation du rôle des développeurs et la nécessité de conserver les fondamentaux de l’ingénierie — architecture, tests, sécurité et documentation — qui deviennent encore plus critiques dans un contexte où le code peut être produit massivement par des IA.
L’article passe en revue plusieurs patterns d’architecture particulièrement pertinents en 2026 et les replace dans des contextes concrets, loin de l’effet de mode, en détaillant leurs bénéfices réels, leurs pièges fréquents et les stacks technologiques qui les accompagnent. Sont étudiés dans cette partie le Strangler Fig Pattern, utilisé pour moderniser progressivement un système legacy par extraction incrémentale derrière une façade/API claire ; l’Anti-Corruption Layer (ACL), essentiel pour protéger un nouveau domaine métier des incohérences d’un ancien système ; l’architecture hexagonale (Ports & Adapters), qui isole le cœur métier des contraintes techniques pour faciliter les tests, les migrations et l’évolution technologique ; ainsi que le Service Mesh, présenté comme une réponse aux problématiques de communication, d’observabilité et de sécurité dans des architectures microservices, mais avec une complexité opérationnelle non négligeable.
Ces patterns sont replacés dans une vision d’ensemble avec ceux abordés dans la première partie — Event-Driven Architecture, API-First avec API Gateway et BFF, CQRS avec Event Sourcing, et le Saga Pattern — afin de proposer un panorama cohérent des choix architecturaux actuels. L’article insiste sur le fait que ces patterns ne sont pas des recettes universelles mais des outils à utiliser selon le contexte, la maturité de l’organisation et la nature du système existant, en montrant clairement quand ils apportent de la valeur… et quand ils compliquent inutilement l’architecture.
L’article décrit plusieurs patterns d’architecture logicielle identifiés comme pertinents pour 2026, en les replaçant dans la réalité des chantiers IT plutôt que dans la simple mode. Il explique notamment l’Event-Driven Architecture (EDA) comme une approche asynchrone permettant de découpler les systèmes pour améliorer la scalabilité et la résilience, illustrée par un cas e-commerce concret avec gains de performance et disponibilité, et détaille le pattern API-First et API Gateway, qui structure un système d’information moderne en concevant d’abord l’API et en centralisant son exposition, sa sécurité et son monitoring. L’article aborde aussi brièvement CQRS avec Event Sourcing et Saga Pattern pour gérer des logiques complexes de séparation lecture/écriture et de transactions distribuées, en donnant leurs principes, bénéfices, pièges à éviter et cas d’usage terrain.
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é.