Qualité logicielle à l’ère de l’IA : les fondamentaux restent utiles

J’ai rouvert un livre d’ingénierie logicielle qui m’a accompagné. En parcourant sa table des matières, je me suis posé une question très actuelle : ces livres deviennent-ils obsolètes quand une IA peut écrire du code ?

Je ne le pense pas. La fabrication change vite. Les questions fondamentales restent reconnaissables : comprendre un problème, maîtriser sa complexité, rendre une modification vérifiable et permettre à quelqu’un de reprendre le travail. Se mettre sur les épaules des géants, ce n’est pas refuser les nouveaux outils. C’est éviter de repartir de zéro à chaque changement d’interface.

Le logiciel ne se résume pas aux fonctionnalités

Une partie importante du développement est invisible. Mettre à jour les dépendances, clarifier des noms, simplifier une condition ou sécuriser un accès ne donne pas forcément une nouvelle capture d’écran à montrer. Pourtant, c’est ce travail qui permet au produit de continuer à fonctionner.

Quand la production de code accélère, cette partie ne disparaît pas. Elle peut même devenir plus importante : davantage de changements signifie davantage d’occasions d’introduire une incohérence. Le bon indicateur n’est donc pas seulement ce que l’équipe a ajouté. Il faut aussi regarder ce qu’elle a rendu plus fiable, plus simple ou moins coûteux à maintenir.

La complexité algorithmique n’est pas un détail académique

J’aime les exemples où une meilleure idée réduit le nombre de calculs nécessaires. La complexité algorithmique décrit la manière dont le travail à effectuer évolue avec la taille des données. Elle oblige à regarder au-delà du fonctionnement sur un petit exemple.

Dans un modèle simplifié, un traitement cubique multiplie son volume de calcul par huit quand on double la taille de l’entrée ; un traitement quadratique le multiplie par quatre. Cela ne suffit pas à prédire un temps réel, qui dépend aussi de l’implémentation et de la machine. Mais cela montre pourquoi une simplification peut avoir plus d’effet qu’un serveur plus puissant.

Lire le code reste une compétence

Je me suis demandé s’il serait encore nécessaire, pour un ingénieur logiciel, de savoir lire le code. Un opérateur PHP que je ne connaissais pas m’a placé devant ce choix très concret : ignorer le détail parce que l’IA peut l’expliquer, ou faire l’effort de comprendre.

Je préfère garder cette capacité. Pas pour réciter toutes les syntaxes. Pour poser les bonnes questions et détecter quand une explication ne tient pas. Un outil peut m’aider à apprendre un mécanisme inconnu. Il devient beaucoup moins utile si je m’en sers pour ne jamais rencontrer ce mécanisme.

L’open source remet la qualité face au réel

J’ai partagé une correction dans xdg-desktop-portal-hyprland : des objets Wayland étaient détruits après la déconnexion qui avait déjà libéré leur infrastructure. La correction consistait à revoir cet ordre de destruction. Un petit changement, mais un vrai problème de durée de vie des objets.

Ce genre de contribution rappelle ce qu’est un logiciel : un ensemble de contraintes qui existent même quand le code paraît plausible. L’IA peut aider à explorer la cause et préparer une correction. Le résultat doit néanmoins respecter le fonctionnement du projet et être compréhensible par les personnes qui le maintiennent.

L’artisanat n’est pas une nostalgie

Je ne défends pas une manière lente de travailler par principe. Je défends le soin apporté au résultat. Automatiser une tâche répétitive, améliorer son environnement ou utiliser un agent pour explorer une base de code peut faire partie de ce soin.

La question devient simple : est-ce que cet outil me permet de livrer un logiciel plus solide et plus facile à faire évoluer ? Si oui, utilisons-le. Les fondamentaux ne sont pas là pour préserver une identité professionnelle. Ils servent à construire quelque chose qui tient, même après la démonstration, même après le départ de la personne qui l’a écrit.

Une bonne revue de code devrait refléter cette exigence : pas seulement vérifier que le programme tourne, mais demander si le prochain changement sera compréhensible. C’est une manière très concrète de prendre soin du travail des autres.