Écoconception logicielle : et si le meilleur code était celui qu'on supprime ?

Le réflexe de l'accumulation

Dans le développement logiciel, on a longtemps associé le progrès à l'ajout. Une nouvelle fonctionnalité, c'est du code en plus. Une amélioration, c'est une couche supplémentaire. Un correctif, c'est encore quelques lignes greffées sur l'existant.

Au fil des années, ce réflexe produit un système qui grossit sans cesse. Plus de lignes, plus de dépendances, plus de chemins d'exécution. Et plus un système grossit, plus il consomme : du temps de calcul, de la mémoire, de l'énergie — et de l'attention humaine pour le maintenir.

C'est le paradoxe que nous voyons sur le terrain : un logiciel n'est pas meilleur parce qu'il contient plus de code. Il est meilleur quand il fait ce qu'on attend de lui avec le moins de complexité possible.

L'écoconception, ce n'est pas un label

L'écoconception logicielle est souvent réduite à une affaire d'image — un argument marketing posé sur un produit qui n'a rien changé en profondeur. Pour nous, c'est l'inverse : c'est une discipline d'ingénierie qui commence dans le code lui-même.

Concrètement, un logiciel sobre repose sur quelques principes simples :

• Moins de code à exécuter signifie moins de cycles processeur, donc moins d'énergie consommée à chaque requête.
• Moins de dépendances réduit la surface à charger, à mettre à jour, à sécuriser.
• Une architecture claire évite les traitements redondants, les requêtes inutiles, les boucles qui tournent pour rien.

L'écoconception n'est donc pas une contrainte qu'on ajoute par-dessus le travail. C'est une conséquence directe d'un code bien pensé. Un système sobre est presque toujours un système mieux conçu.

Ce que l'IA agentique a débloqué

Le refactoring — l'art de réécrire du code existant pour l'améliorer sans changer son comportement — a toujours été le chantier qu'on repousse. Risqué, long, difficile à justifier auprès d'un client qui ne voit pas le bénéfice immédiat.

La difficulté n'a jamais été d'écrire le nouveau code. Elle a toujours été de tenir le système entier dans sa tête pour savoir où intervenir sans tout casser. Sur une base ancienne que plus personne ne maîtrise entièrement, cette vision d'ensemble est précisément ce qui manque.

C'est ce que l'IA agentique change. Elle explore le système, en révèle la structure implicite, et nous redonne la vision macro qu'on avait perdue. Elle ne se contente pas de produire du code plus vite : elle nous aide à identifier ce qui est devenu inutile, redondant, mort.

Sur l'une des bases que nous faisons évoluer, ce travail nous a permis de retirer plusieurs centaines de milliers de lignes de code devenues superflues. Le progrès ne s'est pas mesuré en code ajouté, mais en code supprimé. Un système allégé, plus rapide, moins gourmand, et surtout plus simple à maintenir pour les années à venir.

« Moins de code » : un triple gain

Réduire un système n'est pas qu'un geste écologique. C'est un choix qui se justifie sur trois plans à la fois.

Écologique

Chaque ligne de code qui s'exécute consomme de l'énergie. À l'échelle d'une application utilisée quotidiennement par des milliers d'utilisateurs, la sobriété du code a un impact réel sur l'empreinte du logiciel. Supprimer le superflu, c'est réduire cette empreinte à chaque requête, sans rien sacrifier au service rendu.

Économique

Un système plus simple coûte moins cher à maintenir. Moins de code, c'est moins de bugs potentiels, moins de temps passé à comprendre l'existant, moins de dette technique à porter. La sobriété technique est aussi une sobriété budgétaire : un legacy redevient évolutif au lieu d'être une dette qu'on subit.

Durable

Un code épuré est un code qui se transmet. Quand un système reste lisible et bien structuré, n'importe quel membre de l'équipe peut y intervenir sans semaine d'archéologie préalable. La maintenabilité n'est pas un luxe : c'est ce qui garantit qu'un logiciel reste vivant au-delà de ses créateurs initiaux.

La frontière reste un choix humain

Il serait tentant de conclure que l'IA fait désormais le travail à notre place. C'est faux. L'IA propose, explore, cartographie. Mais elle ne décide pas où doivent passer les frontières d'un système : entre le domaine métier et l'infrastructure technique, entre les différents contextes fonctionnels, autour des points d'entrée et de sortie.

Ces décisions relèvent de l'architecture — un acte humain, fondé sur l'expérience et la compréhension du métier du client. C'est en dessinant ces frontières avec rigueur, en s'appuyant sur des principes éprouvés comme la Clean Architecture, l'approche hexagonale et le Domain-Driven Design, que le gain obtenu tient dans la durée. Pas le temps d'un sprint, mais pour des années.

L'écoconception logicielle n'est donc pas une affaire d'outil. C'est une affaire de méthode et de décision. L'IA nous donne une carte plus claire. À nous de choisir où tracer les routes.