Ce billet de Pascal Martin aborde la réalité du développement logiciel, où les développeurs passent souvent plus de temps à maintenir ou modifier du code existant qu’à en écrire de nouveau. L’auteur souligne que, même au sein d’une équipe, la connaissance approfondie d’un projet est rarement partagée par tous ses membres, chacun intervenant principalement sur des parties spécifiques. Il évoque aussi l’absence historique de pratiques comme les revues de code ou les tests automatisés, qui auraient pu faciliter cette maîtrise collective.
Martin illustre son propos par son expérience personnelle, où il a souvent dû intervenir sur des bases de code inconnues, que ce soit en SSII ou en tant qu’éditeur de logiciels. Il note que même les projets développés from scratch reposent souvent sur des composants partagés, et que l’ajout de nouveaux développeurs ne garantit pas une connaissance exhaustive du code.
Enfin, il remet en question l’idée reçue selon laquelle une équipe connaît parfaitement son propre projet, rappelant que les absences, les départs ou le simple passage du temps rendent cette maîtrise illusoire. Il interroge ainsi les pratiques de passation de connaissances et de documentation au sein des équipes.
L’auteur explique avoir migré son blog de WordPress vers EmDash après 12 ans d’utilisation, citant des raisons de maintenance et de sécurité. EmDash, un CMS inspiré de WordPress mais plus léger, permet d’importer facilement le contenu existant, y compris les images, tout en offrant une interface d’administration similaire.
Le nouveau système repose sur Cloudflare Workers, une plateforme serverless qui limite les risques de sécurité grâce à un runtime restreint. L’auteur souligne les avantages de cette solution, comme l’utilisation de services intégrés (D1, R2, KV) et une consommation de ressources optimisée, idéale pour un site à faible trafic.
EmDash adopte une approche plus sécurisée que WordPress en limitant les capacités des plugins, qui s’exécutent dans des environnements isolés. L’auteur souligne que la plupart des fonctionnalités nécessaires sont déjà intégrées ou facilement développables, réduisant ainsi le besoin de dépendre de modules externes.
L’auteur, Derek Mwale, explique qu’il conçoit désormais des logiciels en anticipant leur maintenance sur dix ans, ce qui influence ses choix techniques : structure des dossiers, nommage des variables, documentation ou encore conception des API. Cette approche vise à faciliter la compréhension du code par son "moi futur", souvent moins familier avec le contexte initial, et à éviter les solutions trop complexes ou abstraites qui deviennent rapidement incompréhensibles.
Il compare le logiciel à un jardin plutôt qu’à un bâtiment, soulignant que sans entretien, il se dégrade avec le temps (dépendances obsolètes, changements de frameworks, etc.). Pour lui, la lisibilité n’est pas un simple bonus mais une fonctionnalité essentielle, car un code trop astucieux ou obscur devient un fardeau pour les développeurs futurs, voire pour lui-même quelques mois plus tard.
Enfin, il met en garde contre le "code trop malin", qui peut sembler élégant à court terme mais se transforme en dette technique. Il privilégie des solutions simples et claires, car elles résistent mieux à l’épreuve du temps, contrairement aux abstractions génériques ou aux fonctionnalités superflues.
Le billet du Google Testing Blog présente le concept de prefactoring, une méthode de refactoring préparatoire visant à simplifier l’intégration de nouvelles fonctionnalités dans un code existant. L’idée centrale, inspirée de Kent Beck, consiste à restructurer le codebase avant d’ajouter une fonctionnalité, plutôt que de le faire en aval ou de forcer l’intégration directement. Cette approche permet d’éviter les complications en cascade et de rendre le code plus adaptable.
Le prefactoring offre plusieurs avantages : il facilite l’implémentation des nouvelles fonctionnalités en les intégrant naturellement, accélère les revues de code en séparant les modifications structurelles des changements fonctionnels, et réduit les risques de bugs en isolant les nettoyages des logiques métiers. De plus, il permet des retours arrière plus sûrs grâce à des changements plus petits et ciblés.
L’article illustre cette pratique avec un exemple concret : l’extraction d’une fonction d’affichage de nom pour éliminer une duplication, avant d’ajouter le support d’un prénom intermédiaire. Cette méthode peut aussi s’appliquer en cours de revue si un nettoyage est suggéré, à condition qu’il ne bloque pas la fonctionnalité principale.
L’article explique comment améliorer la maintenance et la sécurité des workflows GitHub, un enjeu crucial pour les projets open source comme Castor. Il présente zizmor, un outil d’analyse statique qui détecte les vulnérabilités dans les fichiers de configuration CI, similaire à PHPStan pour le code. L’outil identifie des erreurs courantes comme des références non verrouillées à des actions ou des risques de fuite de credentials, et propose des correctifs automatiques.
Les exemples de rapports générés par zizmor illustrent des problèmes spécifiques, comme l’absence de hachage pour une action ou l’utilisation dangereuse de GITHUB_ENV. La commande zizmor . --fix=all permet de corriger automatiquement certaines erreurs, mais nécessite un token GitHub pour accéder aux hashes des commits associés aux tags.
Enfin, l’article mentionne que zizmor ne gère pas les mises à jour majeures des actions, nécessitant d’autres méthodes pour ces cas. L’outil s’intègre ainsi dans une démarche globale de sécurisation et de maintenance des pipelines CI/CD.
L’article souligne les risques de l’anticipation excessive dans le développement logiciel, où la complexité naît souvent de besoins hypothétiques plutôt que réels. L’auteur illustre ce propos avec un exemple concret : une fonctionnalité rendue paramétrable par prudence, mais jamais utilisée, entraînant deux ans de maintenance inutile. Cette approche, bien que courante, alourdit inutilement les systèmes en augmentant le temps de développement, les risques de bugs et la difficulté de maintenance.
L’auteur explique que les abstractions prématurées, comme des interfaces génériques ou des systèmes de configuration superflus, compliquent le code sans apporter de valeur réelle. Ces choix, motivés par une anticipation incertaine, rendent souvent le logiciel plus difficile à comprendre et à faire évoluer. De plus, la solution imaginée pour un besoin hypothétique peut s’avérer inadaptée, forçant des adaptations coûteuses plutôt qu’une refonte optimale.
Pour éviter ces écueils, l’auteur prône un principe simple : construire uniquement ce qui est nécessaire aujourd’hui, en se basant sur des besoins avérés plutôt que sur des scénarios futurs incertains. Cette approche réduit la complexité, facilite la maintenance et permet d’adapter le code plus efficacement lorsque les besoins réels se présentent.
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.
Améliorer l'expérience utilisateur (UX) dans les vieux systèmes (legacy), souvent lents et obsolètes, représente un défi majeur pour les organisations. Ces systèmes, bien que critiques pour les opérations quotidiennes, sont coûteux à maintenir et peu documentés, avec des processus fragmentés et des choix de design incohérents. Leur coexistence avec des produits modernes crée des interfaces hybrides, où des éléments performants côtoient des fonctionnalités lentes et peu intuitives, impactant globalement l'UX.
L'article souligne que même une petite faille dans un flux utilisateur complexe peut discréditer l'ensemble d'une application, malgré les efforts déployés ailleurs. Les systèmes hérités, souvent personnalisés et sans tests d'utilisabilité rigoureux, absorbent une part importante des ressources (40 à 60 % du temps en maintenance). Leur modernisation nécessite une approche progressive, en s'appuyant sur les connaissances existantes pour éviter de reproduire les erreurs du passé.
L’article de Bearstech alerte sur les risques liés à l’intégration massive des grands modèles de langage (LLMs) dans les processus de développement logiciel, soulignant un paradoxe entre gain de productivité et explosion de la dette technique. L’adoption généralisée de l’IA générative, motivée par des impératifs de rapidité, entraîne une production de code souvent mal maîtrisé, augmentant la complexité des systèmes et rendant leur maintenance et leur sécurisation plus difficiles.
Les conséquences incluent des difficultés accrues pour appliquer des correctifs de sécurité, un coût élevé pour le débogage et l’audit, ainsi qu’une baisse de productivité pour les développeurs expérimentés. Les LLMs, en validant les biais initiaux des utilisateurs, peuvent aussi fausser la qualité des solutions proposées, aggravant les vulnérabilités des systèmes.
Enfin, l’article met en garde contre l’illusion d’une productivité durable, rappelant que le "vibe coding" – dépendre entièrement de l’IA pour coder – fragilise la sûreté des infrastructures IT, notamment dans les entreprises françaises.
L’auteur partage son expérience de refonte de son homelab après une panne matérielle et une organisation chaotique des conteneurs LXC. Son infrastructure, basée sur un NUC Minisforum MS-01 sous Proxmox et un NAS Synology, hébergeait un LXC monolithique regroupant une trentaine de services Docker (dont des doublons comme SearXNG ou BentoPDF), rendant la maintenance complexe. Après une panne nocturne et une carte mère défectueuse, il a profité de la situation pour réorganiser ses conteneurs en appliquant le principe "un LXC, une responsabilité fonctionnelle", améliorant isolation, lisibilité et maintenabilité. Un retour d’expérience concret pour éviter la dérive des infrastructures.
Cet article de Towards Data Science explore le problème de la "boîte noire" dans le code généré par l'IA. Bien que l'IA améliore initialement la productivité des équipes de développement, le code généré devient rapidement difficile à maintenir en raison de son manque de structure. Les principaux problèmes incluent la tendance à tout regrouper dans un seul module, les dépendances circulaires et implicites, l'absence de contrats explicites et une documentation qui explique l'implémentation plutôt que l'utilisation. Un exemple concret illustre comment une génération non structurée peut créer un système de notifications monolithique difficile à modifier, contrairement à une approche structurée qui décompose le système en composants indépendants. L'article souligne que le problème n'est pas l'IA en soi, mais plutôt l'architecture résultante.
Florent Destremau discute de l'utilisation des DTO (Data Transfer Objects) dans les formulaires, soulignant que leur utilisation est souvent présentée comme une évidence sans considérer le contexte et le coût de maintenance. Il illustre cela avec un exemple simple où l'ajout d'un DTO et d'un service de mapping pour une entité basique crée une sur-complexité et une duplication de code. Il argue que pour des opérations CRUD simples, les DTO n'apportent que peu de valeur et recommande plutôt d'écrire des tests pour protéger le code. Il montre comment déplacer les contraintes de validation sur l'entité et utiliser du typage strict peut simplifier le code tout en maintenant une bonne robustesse. Il conclut que cette approche résulte en un couplage plus souple et une couverture de test accrue, malgré une perception initiale de moins de rigueur.
Stan partage son expérience en tant que mainteneur de projets open source (openvpn-install et wireguard-install) et explique comment Claude Code l'a aidé à gérer son backlog important. Grâce à l'IA, il a pu mettre en place des tests automatisés dans Docker, ce qui lui a permis de traiter plus efficacement les bugs et les demandes de fonctionnalités. Il décrit son workflow, les défis rencontrés et les améliorations apportées, comme la gestion des logs et l'ajout de fonctionnalités demandées depuis longtemps. Un témoignage intéressant sur l'impact des outils d'IA sur la maintenance de projets open source.
Chez Les-Tilleuls.coop, on réhabilite la maintenance logicielle, souvent perçue comme une corvée, mais qui est en réalité une discipline exigeante et formatrice. Contrairement à la création ex nihilo, la maintenance confronte au réel, aux imprévus et à la complexité, tout en étant un travail invisible et préventif. Elle enseigne la résilience, l'empathie et l'importance de concevoir des systèmes durables. Dans un monde obsédé par l'innovation, la maintenance est un acte écologique et économique, permettant de faire durer les projets au-delà de leur phase initiale.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre