L’article explique que la lenteur des équipes techniques est souvent attribuée à tort aux compétences des développeurs, alors qu’elle provient principalement de la complexité du codebase. L’auteur, Ally Piechowski, introduit le concept de codebase drag (frottement du codebase), où la dette technique et les choix d’architecture alourdissent les tâches quotidiennes, comme illustré par l’exemple d’une équipe ayant passé une semaine sur une fonctionnalité simple à cause d’un code mal structuré.

L’auteur identifie cinq signaux révélateurs d’un codebase problématique, dont les estimations gonflées et la peur des déploiements. Par exemple, des équipes reportent systématiquement les déploiements par crainte de générer des incidents, ce qui reflète un manque de fiabilité du code et des processus. Ces problèmes ne sont pas résolus par des réorganisations ou des embauches, mais nécessitent un investissement direct dans la refonte du code.

L’article propose un audit interactif pour évaluer l’impact du codebase sur la productivité, soulignant que les équipes sous-estiment souvent l’ampleur des coûts cachés liés à un code mal conçu. La solution passe par une prise de conscience de ces dysfonctionnements et une priorisation de la maintenance technique pour réduire le codebase drag.

Le RGAA version 5, prévue pour fin 2026, marque un tournant dans l’accessibilité numérique en France en s’alignant sur les standards internationaux WCAG 2.2. Cette mise à jour impose une approche globale, intégrant les quatre piliers du WCAA (Perceptible, Utilisable, Compréhensible, Robuste) comme socle obligatoire, avec une priorité sur les niveaux A et AA. L’objectif n’est plus seulement technique, mais vise une conception native de produits inclusifs, impliquant tous les métiers du produit.

Les entreprises, notamment celles dépassant 10 salariés et 2 millions d’euros de chiffre d’affaires, s’exposent désormais à des sanctions pouvant aller jusqu’à 25 000 € par manquement, renouvelables chaque année. Au-delà des obligations légales, l’accessibilité devient un levier stratégique, améliorant l’expérience utilisateur, élargissant l’audience et renforçant l’image de marque.

Cette version ne remet pas en cause les audits en cours, mais rationalise les critères existants pour une meilleure harmonisation avec les normes mondiales. L’accent reste mis sur la conformité légale actuelle, tout en préparant les acteurs à ces nouvelles exigences.

L’article explore la vertu de la paresse en programmation, popularisée par Larry Wall dans Programming Perl, qui encourage la création d’abstractions pour simplifier le travail futur. L’auteur souligne que cette paresse intelligente, bien que semblant contre-intuitive, nécessite un effort intellectuel important pour concevoir des solutions élégantes et réutilisables. Cependant, il critique l’évolution récente où cette notion a été détournée par une culture de productivité superficielle, incarnée par des figures comme Garry Tan, qui glorifient une écriture de code frénétique et désordonnée, notamment avec l’aide des IA génératives.

L’auteur dénonce l’absurdité d’une approche où la qualité du code est mesurée en lignes produites par jour, comparant ironiquement les 37 000 lignes quotidiennes de Tan à la taille totale de DTrace (60 000 lignes). Il illustre cette dérive avec l’exemple d’un projet de Tan, un "blog-newsletter-thingy", truffé de composants inutiles comme des tests redondants, une application Rails basique et plusieurs variantes de logo, dont une vide.

Enfin, l’article met en garde contre la perte de sens de la paresse comme vertu, notamment avec l’essor des outils automatisés qui amplifient une productivité illusoire. L’auteur plaide pour un retour à une paresse réfléchie, où l’abstraction sert non seulement le développeur actuel, mais aussi la communauté, en évitant les pièges d’une industrie obsédée par la quantité plutôt que par la qualité et la durabilité du code.