L’article aborde la notion de « bon code » dans un contexte où l’IA facilite la génération de code, tout en soulignant que sa qualité reste un enjeu majeur. L’auteur s’appuie sur les travaux de Simon Willison pour définir un code efficace : il doit fonctionner correctement, être validé par des tests et des vérifications, et résoudre un problème réel plutôt qu’un besoin technique mal ciblé. La robustesse face aux erreurs, la simplicité, la documentation à jour et l’évolutivité sont également mises en avant.

L’auteur insiste sur l’importance de gérer les cas d’échec avec des messages exploitables et d’éviter la complexité inutile, tout en respectant des critères non fonctionnels comme la sécurité ou la maintenabilité. Ces principes, valables avant l’ère de l’IA, deviennent encore plus cruciaux avec l’automatisation, car ils garantissent la fiabilité et la pérennité des solutions produites.

Ce dépôt GitHub, soutenu par les équipes de Google Chrome et Microsoft Edge, propose un guide moderne pour le développement web destiné aux agents d'IA. Il vise à les orienter vers des API modernes, performantes et sécurisées plutôt que des solutions obsolètes, en comblant le fossé entre les connaissances des modèles et les bonnes pratiques actuelles.

L'outil, disponible via une commande CLI (npx modern-web-guidance@latest install), fournit des recommandations ciblées et optimisées pour le contexte des agents, couvrant des disciplines comme l'UX, le CSS, les performances ou l'accessibilité. Il inclut 102 fonctionnalités web modernes et 128 cas d'usage concrets, avec des évaluations pour éviter les contenus redondants.

Le projet, encore en version préliminaire, encourage les contributions et retours via GitHub pour enrichir ses guides, notamment sur l'adoption progressive des fonctionnalités et les stratégies de fallback.

L’article The Intent Debt d’Addy Osmani explore trois types de dettes techniques dans le développement logiciel : technique, cognitive et intentionnelle. La dette intentionnelle, distincte des deux autres, désigne l’absence de documentation claire des objectifs, contraintes et justifications derrière un système, ce qui rend son évolution difficile à comprendre pour les nouveaux membres ou les outils automatisés. Contrairement à la dette technique (liée au code) ou cognitive (liée à la compréhension humaine), la dette intentionnelle ne peut être résolue par des agents IA, car elle repose sur des décisions humaines non formalisées.

L’auteur souligne que ces dettes sont indépendantes : un code propre peut cacher une dette intentionnelle élevée si son contexte n’est pas documenté. Les agents IA peuvent aider à réduire la dette technique ou cognitive (en expliquant du code), mais ils ne peuvent pas restituer une intention non écrite, risquant même d’inventer des justifications plausibles mais erronées. Cette limite devient critique avec l’automatisation croissante, car les équipes ne peuvent plus compter sur la transmission orale des connaissances pour combler ce vide.

Enfin, Osmani met en garde contre l’aggravation de la dette intentionnelle avec l’essor des outils automatisés. Historiquement, les équipes compensaient ce manque par des échanges informels, mais cette approche devient insoutenable à l’ère de l’IA, où la documentation explicite des intentions devient indispensable pour éviter des dérives coûteuses et difficiles à corriger.

Le billet du Google Testing Blog explique comment choisir des valeurs de test robustes pour éviter les faux positifs. L’idée principale est que des valeurs par défaut ou trop simples peuvent masquer des bugs, comme illustré par un exemple où une méthode de map ne stocke jamais la valeur fournie, mais où le test passe grâce à la valeur par défaut (0). Pour des tests fiables, il est conseillé d’utiliser des valeurs non triviales, couvrant différents scénarios (bornes numériques, cas vides, etc.), et de varier les entrées pour éviter les dépendances accidentelles. L’article recommande aussi des techniques comme le fuzzing ou les tests paramétrés pour une couverture plus exhaustive.

Ce dépôt GitHub propose une collection de bonnes pratiques TypeScript pour améliorer la sécurité, la lisibilité et la maintenabilité du code. Il met en avant des patterns concrets comme l'utilisation de unknown plutôt que any pour renforcer la validation des types, ou l'inférence automatique des types pour éviter les annotations superflues. L'idée centrale est d'exploiter les fonctionnalités modernes de TypeScript pour écrire un code plus robuste et évolutif.

Parmi les conseils clés, on retrouve l'emploi de satisfies pour valider des structures sans perdre l'inférence, ou encore la dérivation de types à partir de valeurs immuables avec as const. Le dépôt aborde aussi des concepts avancés comme les unions discriminées pour modéliser des états impossibles, ou les vérifications exhaustives avec never pour détecter des erreurs dès la compilation.

Enfin, il souligne l'importance de connecter les vérifications d'exécution aux types via des prédicats, et de construire des types à partir d'autres existants. Ces pratiques visent à réduire les erreurs tout en simplifiant la maintenance du code.

Ce site propose un guide structuré pour maîtriser JavaScript à travers 33 concepts fondamentaux, allant des bases (types primitifs, portée, fermetures) aux sujets avancés (moteurs JS, expressions régulières, algorithmes). Chaque notion est expliquée de manière claire avec des exemples pratiques, des schémas et des ressources complémentaires, adaptées aussi bien aux débutants qu’aux développeurs expérimentés.

L’approche met l’accent sur la compréhension profonde plutôt que sur le copier-coller, en couvrant des mécanismes clés comme l’asynchrone (boucle d’événements, Promesses), la programmation orientée objet (prototypes, classes) et les bonnes pratiques (code propre, motifs de conception). Les sections dédiées à l’entretien technique et à l’optimisation des performances en font aussi un outil utile pour les candidats.

Le contenu est organisé en parcours progressifs, avec une recherche intégrée et un index complet pour naviguer facilement. Le projet s’appuie sur des ressources externes vérifiées et propose des quiz pour valider les acquis, tout en restant accessible aux autodidactes ou aux développeurs souhaitant combler des lacunes.

L’auteur, développeur depuis 1983, partage son expérience de l’intégration de l’IA dans son workflow, notamment via le Markdown pour rédiger spécifications et architectures. Il critique à la fois le vibe coding (délégation aveugle à l’IA) et le rejet puriste de cette technologie, soulignant que la valeur réside désormais dans la conception et la supervision, pas dans la production de code brute.

Il utilise l’IA comme un outil collaboratif : pour des tâches simples, elle agit comme une exécutante rapide, tandis que pour les parties complexes, il supervise et valide, voire code lui-même. L’objectif est de maintenir une architecture compréhensible et maîtrisée, évitant ainsi les risques liés à des systèmes opaques ou dépendants de tarifs ou de disponibilités externes.

Enfin, il compare l’IA à un retour partiel du cycle en V, où la spécification redevient centrale. La confiance dans le code généré doit être proportionnelle à la capacité de le critiquer, et les rôles (spécification, validation, expertise) doivent rester clairs pour préserver la robustesse du système.

L’auteur explique comment Domain-Driven Design (DDD) a révolutionné sa vision de l’architecture logicielle, notamment pour les agents IA. Après des années de routine en développement, il découvre ce concept en lisant Domain-Driven Design d’Eric Evans, ce qui transforme sa manière d’aborder la complexité des systèmes. Son expérience précédente avec des microservices mal conçus, où les services manquaient de sens métier, l’a poussé à chercher une approche plus structurée.

Le livre l’a confronté à une réflexion approfondie sur la modélisation du domaine, où chaque détail (noms de classes, relations, effets de bord) devient crucial. Cette approche l’a ramené aux fondamentaux de la programmation orientée objet, avec une attention accrue à la clarté et à la cohérence du code. Il souligne que DDD a comblé un vide entre le développement et la compréhension du métier, contrairement à sa vision initiale où ces deux aspects étaient dissociés.

L’AFUP Day 2026 à Paris a réuni des professionnels de l’écosystème PHP autour de conférences axées sur l’intelligence artificielle, l’architecture et la productivité. L’événement a mis en lumière l’intégration croissante de l’IA dans les outils comme Symfony, avec des présentations sur les embeddings pour des recherches sémantiques et l’utilisation de LLM comme GitHub Copilot pour optimiser les workflows de développement.

Loïck Piera a présenté Castor, un task runner open source développé par JoliCode, tandis que Nicolas Grekas a exploré les avantages de Caddy et FrankenPHP pour moderniser la gestion des applications PHP, proposant une alternative au traditionnel PHP-FPM. Ces outils visent à améliorer la productivité et la durabilité des projets.

Enfin, des discussions ont porté sur les bonnes pratiques en matière de qualité de code, notamment avec PHPStan, et sur la nécessité de concilier fonctionnalité, pérennité et collaboration humaine pour garantir des logiciels robustes et évolutifs.

L’article explique comment gérer les options et arguments dans des scripts Bash afin de rendre les scripts plus flexibles et robustes, notamment via les commandes getopts, shift et les variables spéciales comme $1 ou $@. Il détaille la différence entre options courtes et longues, montre comment vérifier la présence d’arguments obligatoires et recommande des pratiques de développement plus sûres comme set -euo pipefail pour détecter rapidement les erreurs et éviter les comportements inattendus dans les scripts shell.

L’article explore les défis liés à la mise à l’échelle des View Transitions entre documents, notamment pour des pages affichant des centaines d’éléments comme une grille de produits. Après avoir résolu les problèmes initiaux (métadonnées obsolètes, délais de timeout, etc.), l’auteur souligne que les tutoriels classiques, conçus pour des transitions simples, échouent face à des cas complexes. La solution idéale, purement CSS, reposerait sur des fonctions comme ident() et sibling-index() pour générer automatiquement des noms uniques, mais cette approche n’est pas encore implémentée dans les navigateurs.

En attendant, les développeurs doivent recourir à des méthodes manuelles fastidieuses, comme des règles CSS répétitives pour chaque élément, ce qui devient ingérable avec un grand nombre d’items. L’article met en lumière l’écart entre les promesses futures des standards CSS et les contraintes actuelles, tout en soulignant l’importance de solutions évolutives pour des interfaces dynamiques.

L’article aborde les difficultés rencontrées avec les Cross-Document View Transitions, une fonctionnalité permettant d’animer les transitions entre pages HTML classiques sans framework. L’auteur explique que les tutoriels obsolètes, utilisant une balise <meta> désormais dépréciée, induisent en erreur, tandis que les solutions pour Single-Page Applications (SPA) ne s’appliquent pas aux sites multi-pages. Les problèmes courants incluent des transitions silencieusement bloquées par un délai de 4 secondes, des distorsions d’images ou des styles CSS complexes pour gérer les noms de transitions.

L’auteur souligne l’absence de documentation claire et actualisée, rendant l’implémentation ardue malgré des démos prometteuses. Il annonce une série en deux parties pour clarifier les bonnes pratiques, comme l’utilisation de l’API @view-transition en CSS, la gestion des événements pagereveal et pageswap, ou encore l’optimisation des noms de transitions pour éviter des fichiers CSS surchargés. La seconde partie promet des solutions pour les projets à grande échelle, notamment la gestion des animations avec prefers-reduced-motion.

L’article explique comment résoudre le problème des requêtes N+1 dans Symfony 8.1 avec Doctrine ORM, un fléau pour les performances des applications. Il détaille d’abord le mécanisme du N+1, où une requête initiale récupère N entités, puis N requêtes supplémentaires chargent leurs relations, dégradant fortement les performances en production.

L’auteur propose des stratégies avancées pour l’éviter, comme l’utilisation de DQL avec JOIN FETCH pour charger les entités et leurs relations en une seule requête, ou encore des modes de récupération précis et l’hydratation via des DTO. Ces méthodes, combinées à des outils comme le Symfony Web Profiler, permettent d’optimiser significativement les endpoints.

L’article d’Alex Bespoyasov explore l’application de l’architecture propre (Clean Architecture) au développement frontend, en s’appuyant sur une présentation et des exemples concrets. L’idée centrale est de structurer le code en couches distinctes (domaine, application et adaptateurs) pour améliorer la maintenabilité et l’extensibilité des applications, même face à des changements fréquents. L’auteur illustre cette approche en concevant une boutique de cookies avec React et TypeScript, tout en soulignant que la méthode reste compatible avec d’autres frameworks ou bibliothèques.

L’architecture propre vise à séparer les responsabilités selon leur proximité avec le domaine métier, centralisant ainsi les règles métier et réduisant les dépendances externes. Bespoyasov insiste sur la composition des composants pour faciliter les modifications futures, en citant Rich Hickey pour appuyer cette philosophie. Bien que l’exemple utilise React et TypeScript, l’auteur précise que ces outils ne sont pas obligatoires, et que l’accent est mis sur les principes plutôt que sur une implémentation rigide.

Enfin, l’article propose des pistes pour approfondir, comme des méthodologies complémentaires adaptées à différents types de projets. Bespoyasov rappelle que l’objectif est de comprendre l’idée plutôt que de reproduire servilement les exemples, encourageant les développeurs à adapter ces principes à leurs besoins spécifiques.

L’article explique comment sortir les outils de qualité de code PHP du vendor/ d’un projet Symfony en utilisant l’image Docker jakzal/phpqa, afin d’éviter les conflits de dépendances, les composer update plus lents et les divergences entre environnement local et CI. L’auteur remplace les dépendances require-dev classiques (PHPStan, Rector, PHP-CS-Fixer, Deptrac, etc.) par des exécutions one-shot dans un conteneur Docker contenant les binaires .phar, avec un tag d’image figé pour garantir la reproductibilité et un cache partagé /tmp pour accélérer fortement les analyses. Le workflow repose sur un Makefile séparant des contrôles rapides avant commit et des vérifications plus lourdes avant release, avec des cibles atomiques réutilisables individuellement. Certains cas restent toutefois hors du périmètre de jakzal/phpqa, notamment lint:container de Symfony, composer audit et Biome pour JS/TS. L’article souligne aussi les limites des outils non maintenus embarquant une ancienne version de nikic/php-parser, comme PHPMetrics ou PDepend, devenus incompatibles avec certaines nouveautés de PHP 8.4/8.5.

Sean Goedecke explique qu’en 2026 il utilise désormais les LLMs comme de véritables agents capables de produire des pull requests complètes, y compris dans des zones de code qu’il maîtrise bien, avec une simple passe de revue finale avant validation. Il décrit un changement majeur par rapport à 2025 : les agents récupèrent beaucoup mieux de leurs erreurs, vont plus vite et nécessitent moins de supervision en temps réel, ce qui l’a amené à passer d’un workflow centré sur VSCode à des outils orientés terminal et agents comme GitHub Copilot App. Il insiste cependant sur le fait que son travail s’est déplacé vers l’évaluation rapide des propositions générées, le tri des mauvaises approches et la revue approfondie des changements acceptés, notamment pour supprimer les “LLM-isms” comme le sur-commentaire ou certaines décisions de conception discutables. L’auteur continue aussi d’utiliser les LLMs pour apprendre de nouveaux domaines, produire du code jetable de recherche ou explorer des bases de code inconnues, mais souligne qu’ils restent moins fiables pour le jugement architectural, les ADRs ou les décisions techniques engageantes à long terme.

L’auteur partage sa méthode pour développer des produits avec l’IA tout en maîtrisant les coûts, en limitant la consommation de tokens à environ 20 € par mois. Il utilise principalement Claude pour coder, notamment pour ses projets Writizzy (une plateforme de newsletters) et Hakanai (blogs statiques), en appliquant une approche de context engineering pour guider l’IA et éviter les erreurs.

Pour structurer son travail, il s’appuie sur des fichiers Claude.md définissant les spécifications du projet et des règles conditionnelles (.claude/rules) qui imposent des bonnes pratiques (comme l’utilisation de Nuxt UI ou des vérifications de typage). Ces règles, affinées empiriquement, réduisent les explorations inutiles de l’IA et optimisent l’efficacité.

Enfin, l’auteur souligne que ces mesures ne sont pas infaillibles : il complète avec des contrôles automatisés (tests, linters, CI) pour limiter les risques d’erreurs. Il évoque aussi une possible transition vers un autre modèle, plus performant pour le code, tout en maintenant une approche budgétaire stricte.

L’article de Teddy Ferdinand souligne que l’intégration tardive de la cybersécurité dans un projet limite ses options à des mesures radicales, comme bloquer la mise en production ou imposer des corrections coûteuses, faute de pouvoir ajuster l’architecture ou les choix techniques en amont. L’auteur explique que cette approche brutale résulte souvent d’un manque de collaboration précoce, où les critères de sécurité ne sont pas définis dès le début, transformant une revue finale en révélateur de problèmes évitables.

Ferdinand illustre que les blocages en fin de projet sont rarement perçus comme des solutions, mais plutôt comme des échecs, car ils surviennent après que les engagements métiers, les budgets et les délais aient été figés. Il insiste sur l’importance d’intégrer la sécurité dès les phases clés, en amont, pour éviter des arbitrages douloureux et des tensions entre équipes projet, métier et management.

Enfin, l’auteur rappelle que la sécurité ne vise pas à freiner les projets, mais à les sécuriser de manière proactive, en clarifiant les règles, les responsabilités et les critères de validation avant que les choix ne deviennent irréversibles.

Ce billet du Google Testing Blog souligne l'importance d'ajouter du contexte dans les réponses aux commentaires de revue de code. Plutôt que des réponses minimalistes comme "Fait" ou "Corrigé", il recommande d'expliquer brièvement le pourquoi ou le comment derrière les modifications, surtout lorsque les changements ne sont pas immédiatement évidents.

L'article illustre cette pratique avec des exemples concrets, comme l'ajout de tests pour des cas limites ou l'explication d'un choix de bibliothèque en fonction des contraintes du projet. Ces précisions facilitent la compréhension des reviewers et laissent une trace claire pour les futurs lecteurs du code.

Enfin, il encourage à documenter les décisions prises lors de discussions hors ligne ou les compromis techniques, afin que tous les contributeurs puissent suivre la logique derrière les modifications. Un lien vers le guide de revue de code de Google est proposé pour approfondir ces bonnes pratiques.

L’édition 2026 du Devoxx a mis en lumière l’impact croissant de l’IA sur l’ingénierie logicielle, notamment à travers des architectures multi-agents et des outils émergents comme l’informatique quantique. Les conférences ont souligné des avancées majeures, comme les design patterns agentiques, qui redéfinissent l’interaction avec les grands modèles de langage (LLM) en structurant des écosystèmes autour d’objectifs, de mémoire, d’outils et de planification.

Parmi les concepts clés, le Retrieval Augmented Generation (RAG) a été présenté comme une solution efficace pour connecter les IA à des données actualisées ou privées, en optimisant l’extraction ciblée d’informations plutôt que leur intégration massive. Une autre approche, le planning programmatique, a été évoquée pour les processus métiers nécessitant un contrôle précis, où le développeur code une séquence fixe d’appels aux LLM, limitant ainsi les risques d’hallucinations.

Enfin, l’événement a abordé des enjeux futurs comme la résilience de l’expertise technique au-delà de 2030 et les défis posés par la complexité croissante des outils, tout en explorant des solutions pour maintenir la qualité logicielle à l’ère de l’IA.