Cet article de Sebastian Bergmann explique les différences entre les Data Transfer Objects (DTOs) et les Value Objects, et pourquoi l'immutabilité facilite les tests. Les DTOs, motivés techniquement, servent à transférer des données entre couches ou systèmes, tandis que les Value Objects, motivés par le domaine, représentent des concepts stables du domaine. L'immutabilité réduit la charge cognitive en test, car elle garantit que l'état des objets ne change pas. Les Value Objects, étant immuables, n'ont pas besoin de test doubles, contrairement aux DTOs qui peuvent en nécessiter si ils contiennent de la logique. L'utilisation d'objets immuables simplifie les tests en évitant les effets de bord indirects.
L'article explore l'importance souvent sous-estimée du titre de page (
Steve Yegge partage six nouvelles astuces pour mieux coder avec des agents, basées sur ses expériences récentes. Parmi celles-ci, il souligne que le logiciel est désormais jetable, avec une durée de vie inférieure à un an, rendant les réécritures plus faciles et intelligentes que les corrections. Cette approche remet en question les conseils traditionnels, comme ceux de Joel Spolsky, et ouvre la voie à des architectures modernes et maintenables, posant un défi aux fournisseurs de SaaS tiers.
Cet article partage l'expérience de SNCF Connect dans la mise en place d'une stratégie de service numérique responsable. Il définit un service numérique responsable comme une solution utile, sobre, accessible et respectueuse, reposant sur quatre piliers : accessibilité, sobriété, confidentialité et respect des libertés. L'article souligne l'importance de ces principes, soutenus par des référentiels concrets comme le RGAA, le RGPD et le RGESN, et illustre comment SNCF Connect aligne ses actions sur ces enjeux pour promouvoir des mobilités durables et accessibles. Il présente également des bonnes pratiques pour déployer une telle stratégie, comme la labellisation numérique responsable.
L'article revient sur l'utilisation souvent abusive de l'attribut HTML title, qui sert à afficher des infobulles ou à fournir un nom accessible aux éléments interactifs. Malgré les mises en garde depuis 2013, cet attribut est encore mal employé, posant des problèmes d'accessibilité. Les infobulles sont cachées et nécessitent une interaction précise, ce qui les rend peu intuitives et frustrantes pour les utilisateurs. L'article souligne l'importance de répéter les bonnes pratiques pour ancrer une utilisation correcte de l'attribut title.
Cet article de Guillaume Barbier explore les défis liés à la création de tableaux de données accessibles sur le web en 2025. Il identifie deux principales raisons pour lesquelles les tableaux restent inaccessibles : un manque de culture numérique et des limitations techniques. L'auteur souligne la confusion entre la structuration de l'information et la présentation visuelle, ainsi que les difficultés techniques rencontrées avec certaines combinaisons de navigateurs et lecteurs d'écran. Il propose une synthèse des connaissances pour aider à créer des tableaux accessibles et évoque quelques motifs à éviter. L'article aborde également d'autres critères d'accessibilité comme la redistribution et les mouvements de glissement, avec des techniques pour éviter les déformations sur les écrans étroits.
Cet article explique comment utiliser les titres pour structurer clairement une page web, améliorant ainsi la compréhension pour tous les utilisateurs, y compris ceux utilisant des technologies d'assistance. L'article aborde trois problèmes courants : utiliser des titres pour du texte non structurel, ne pas utiliser de titres pour du texte structurel, et un ordre de titres incohérent. Les solutions proposées incluent l'utilisation appropriée de HTML et CSS pour garantir une sémantique et une hiérarchie correctes des titres.
Cet article explore comment conduire le changement vers une Clean Architecture au sein d'une équipe de développement. Il aborde les aspects humains et organisationnels, complémentaires aux aspects techniques traités dans un précédent article. L'auteur partage son expérience en tant que lead développeur, soulignant l'importance de l'adhésion de l'équipe, de la pédagogie, et de la création d'un environnement de confiance pour réussir une telle refonte. Il insiste sur l'importance de lever les incompréhensions et d'encourager l'expérimentation pour ancrer progressivement les concepts. Un article précieux pour ceux qui souhaitent transformer une base de code existante en un terrain d'apprentissage collectif autour de la Clean Architecture.
L'article explore une approche proactive pour intégrer la performance web dès le début du développement, évitant ainsi le cycle de dégradation des performances. Odell, ingénieur chez Canva, propose d'impliquer toute l'équipe et de rendre la performance visible tôt, plutôt que de la traiter comme un problème à résoudre a posteriori. Il explique comment les problèmes de performance s'accumulent silencieusement et pourquoi les corrections tardives sont souvent inefficaces. La solution proposée est de créer des systèmes et des processus qui favorisent naturellement les décisions rapides et performantes.
L'article souligne l'importance cruciale de l'attribut lang dans la balise <html> pour l'accessibilité web. Cet attribut indique la langue du contenu aux navigateurs et lecteurs d'écran, évitant ainsi des erreurs de prononciation et améliorant l'expérience utilisateur pour les personnes malvoyantes ou dyslexiques. Malgré son importance, l'omission de cet attribut reste un problème récurrent, comme le montre le rapport WebAIM Million. L'auteur insiste sur la nécessité d'une meilleure éducation en accessibilité pour les développeurs.
L'article explique comment associer explicitement des éléments HTML, comme les labels et les champs de formulaire, en utilisant des IDREFs. Il souligne l'importance de cette pratique pour améliorer l'accessibilité, notamment pour les technologies d'assistance. L'auteur détaille les bonnes pratiques, telles que l'unicité et l'existence des IDs, et propose des outils pour détecter les références brisées. Un exemple concret illustre l'utilisation de l'attribut for dans une balise <label> pour référencer l'ID d'un champ <input>.
Cet article explique comment rédiger un bon fichier CLAUDE.md pour optimiser l'utilisation de l'IA Claude dans un projet de code. Il souligne que les modèles de langage (LLMs) sont sans état et ne connaissent rien du codebase au début de chaque session, d'où l'importance de CLAUDE.md pour les informer. Le fichier doit couvrir le "quoi", le "pourquoi" et le "comment" du projet, mais sans surcharger d'informations non pertinentes, car Claude pourrait les ignorer. Des conseils pratiques sont donnés pour créer un fichier efficace, en suivant les bonnes pratiques d'ingénierie de contexte.
Ce guide pratique de l'OWASP Top 10, destiné aux développeurs web, détaille dix erreurs courantes et comment les éviter. Il aborde des sujets comme le contrôle d'accès brisé (A01), les échecs cryptographiques (A02), et les injections (A03), avec des exemples concrets et des solutions pour les prévenir dès l'écriture du code. Un outil précieux pour améliorer la sécurité des applications web.
Dans ce 3ᵉ et dernier volet de sa série, l’auteur raconte comment il a concrètement « vibe codé » une CLI — une petite application génératrice de Cilium Network Policies — en utilisant Claude Code et Speckit. Au-delà de la phase initiale d’idéation et de conception (décrite dans les épisodes précédents), ce billet détaille comment, à travers un workflow rigoureux (spécification, clarification, planification, découpage en tâches, validation, générations de code et tests), l’auteur a transformé un besoin métier complexe en un MVP fonctionnel — livré en un seul sprint et déjà en production. Il en tire des leçons fortes : l’IA ne remplace pas le développeur, elle l’augmente, mais uniquement si on encadre l’exercice avec une méthode claire, des specs précises et une boucle de validation humaine. Pour finir, il plaide pour une évolution du rôle du développeur vers celui d’architecte / Product Owner — capable de piloter l’IA tout en garantissant la qualité, la cohérence et la maintenabilité du code.
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é.
Nicolas Jourdan explique comment créer des commandes personnalisées pour Symfony Console de manière professionnelle avec Symfony 7.4. L'article montre l'évolution des bonnes pratiques en partant d'une approche classique, puis en introduisant les commandes invocables et les attributs d'entrée pour un code plus propre et plus lisible. L'exemple concret d'une commande pour importer des avis clients depuis un fournisseur externe illustre ces améliorations.
L’auteur montre comment un service « simple » qui orchestre plusieurs effets secondaires (sauvegarde, envoi d’e-mail, tracking analytics…) peut sembler propre et fonctionner en développement — mais devient une « bombe à retardement » en production : latence, états partiels incohérents, logique métier mélangée à l’orchestration. Comme solution, il recommande d’introduire d’abord des Domain Events pour découpler la logique métier des effets secondaires, puis d’utiliser le pattern Outbox pour garantir l’atomicité entre la persistance des entités et des événements, et enfin — lorsque les étapes sont critiques (paiement, création de wallet, etc.) — d’opter pour un pattern Saga pour assurer soit la réussite de l’ensemble, soit la compensation en cas d’échec.
Ce guide explique comment implémenter la validation dans une architecture Domain-Driven Design (DDD) en suivant une approche par couches. Il souligne l'importance de maintenir l'intégrité des objets de domaine, de valider uniquement ce pour quoi chaque couche est responsable, et d'éviter la duplication de la logique de validation. L'article détaille les meilleures pratiques pour la validation dans la couche de domaine (objets de valeur, entités et services de domaine) et la couche d'application (validation des commandes et orchestration des cas d'utilisation). Il met en avant l'importance de fournir des messages d'erreur clairs et de valider rapidement.
Ahmad Bilal partage 50 erreurs courantes en TypeScript pour éviter les pièges et améliorer la qualité du code. L'article explique comment TypeScript, bien que prometteur, peut donner une fausse impression de sécurité si mal utilisé. Il couvre des erreurs basiques (comme l'utilisation abusive de any ou l'ignorance des avertissements du compilateur) et des pièges plus avancés (comme la confusion entre null et undefined ou l'oubli du type never). Un guide pratique pour mieux maîtriser TypeScript.
L'article explore la problématique des animations CSS redondantes dans les projets web. L'auteur souligne que les animations de base comme les fade-in, slide ou zoom sont souvent recréées de manière indépendante, entraînant une duplication inutile de code et une maintenance complexe. Il propose une solution pour standardiser ces animations en consolidant les @keyframes, transformant ainsi un système chaotique en un système clair et prévisible. Une lecture utile pour les développeurs front-end cherchant à optimiser leur code et leur flux de travail.