La qualité du code compte-t-elle encore à l’ère de l’IA ? Cela dépend d’une chose
Posez une question à n’importe quel ingénieur logiciel senior, et vous êtes presque certain d’obtenir sa réponse préférée en deux mots : « Ça dépend. »
À l’ère des outils de codage IA et du « vibe coding », le débat sur la question de savoir si la qualité du code compte encore a atteint un paroxysme sur les réseaux sociaux. Dans une présentation pour la chaîne AI Engineer, Max Kanat-Alexander (Capital One) dépasse les arguments binaires « oui ou non » pour offrir un cadre concret permettant de savoir quand la rigueur d’ingénierie est critique — et quand on peut la jeter par la fenêtre.
Le fondement : Pourquoi le code existe tout court
Avant de décider si la qualité du code compte, il faut établir ce que les pratiques d’ingénierie logicielle cherchent réellement à accomplir. Selon Kanat-Alexander, tout ce que vous voulez accomplir avec un morceau de logiciel — qu’il s’agisse d’aligner un modèle, de faire scaler un système ou de stimuler l’adoption — se résume à deux facteurs :
- Comprendre le système.
- Exécuter sur la base de cette compréhension.
Les debuggers, les outils d’observabilité, les evals et les tests n’existent pas dans le vide ; ils existent exclusivement pour améliorer notre compréhension d’un système et notre capacité à agir dessus. Pour un ingénieur logiciel, cela se résume à deux questions critiques :
- Quel est le comportement réel et concret du système ? (Pas seulement ce que la documentation prétend qu’il fait.)
- Comment modifier correctement et en toute sécurité ce comportement ?
Alors qu’un simple programme « Hello World » est facile à saisir dans son intégralité, les systèmes du monde réel — comme le massive codebase open-source Chromium — ont essentiellement des interactions possibles infinies. Aucun humain ne peut tenir le comportement entier de Chromium dans sa tête. Au lieu de cela, nous nous appuyons sur la compréhension de composants spécifiques, comme un parseur d’URL.
C’est pourquoi le code existe : pour la structure. Dans le passé, les ingénieurs parlaient de concepts comme la « lisibilité » et la « testabilité », qui sonnent comme des préoccupations purement humaines. Ce qui a toujours compté le plus en dessous, c’était une structure reconnaissable et compréhensible.
Le cercle vicieux du risque de modification
La structure compte le plus quand vous devez modifier un système. Chaque modification comporte deux risques :
- Introduire un problème immédiat : Ce n’est pas seulement un bug — cela pourrait être une deadline manquée, un dépassement de budget, ou un comportement utilisateur mal aligné causé par la difficulté de comprendre le système.
- Rendre les changements futurs plus durs : En dégradant la structure, vous rendez le système plus dur à comprendre la prochaine fois.
Le risque #2 alimente directement le risque #1 dans un cycle composé et non linéaire. Au fil du temps, les codebases géantes peuvent atteindre un état où chaque seul changement déclenche des frictions organisationnelles, des retards de timeline ou des incidents de production.
La grande division : Logiciel durable vs jetable
Alors que les gens débattent de savoir si les futurs modèles d’IA auront un jour une capacité infinie à démêler une complexité massive, l’IA fait déjà autre chose en ce moment : elle rend le logiciel jetable 100 000 fois plus courant.
Historiquement, les ingénieurs ont passé la plupart de leur temps à construire et maintenir du logiciel durable — des systèmes qui vivent pendant des années, servent des milliers ou des millions d’utilisateurs, et portent des conséquences business catastrophiques s’ils échouent. Le logiciel durable ne disparaît pas ; en fait, les outils d’IA conduiront probablement à plus de logiciel durable construit.
Cependant, les agents IA nous permettent aussi de faire tourner du logiciel où :
- Les conséquences de l’échec sont minimales ou inexistantes.
- Peu de personnes (et aucun autre système de production) en dépendent.
- Le coût de remplacement est quasi nul (il peut être reconstruit en heures).
- Le coût de maintenance est essentiellement rien.
Vous n’aimez pas votre calculatrice OS ? Demandez à un agent d’en construire une personnalisée. Vous planifiez une fête d’anniversaire d’enfant ? Faites tourner une app de planification de fête one-off et jetez-la lundi. Dans le monde du logiciel jetable, la qualité du code ne compte pas du tout parce que les risques composés des modifications futures n’existent simplement pas.
| Facteur d’évaluation | Logiciel jetable | Logiciel durable |
|---|---|---|
| Conséquences de l’échec | Minimales à nulles | Élevées / Critiques pour le business |
| Dépendances | Isolé ; utilisé par une ou quelques personnes | Dépendu par des milliers/millions ou d’autres systèmes |
| Coût de remplacement | Quasi nul (remplaçable en heures/jours) | Extrêmement élevé |
| Coût de maintenance | Sans importance ou quasi gratuit | Investissement continu énorme |
| Rigueur d’ingénierie nécessaire | Aucune | Maximum |
Deux nouvelles disciplines pour l’ingénierie moderne
Parce que la jetabilité et la durabilité existent sur un spectre, les équipes logicielles modernes ont deux leviers stratégiques qu’elles peuvent actionner.
1. Ingenier pour la jetabilité
Au lieu d’appliquer des processus lourds à tout, les organisations peuvent architecturer des environnements qui rendent intentionnellement le logiciel sûr à jeter :
- Environnements isolés : Créez des sandboxes qui n’accèdent qu’aux données d’un utilisateur individuel, avec zéro accès aux données clients ou PII.
- Indépendance forcée : Bloquez les appels API entrants d’autres systèmes de production pour que rien ne puisse accidentellement dépendre d’un outil jetable.
- Redondance durable : Gardez un système legacy fiable et « clunky » comme backup, tout en laissant les employés « vibe coder » des front-ends personnalisés rapides pour leurs propres workflows. Si leur front-end personnalisé casse, ils retombent simplement sur le système durable.
- Limites de scope strictes : Gardez les outils hyper-focalisés sur un seul utilisateur ou un seul événement.
2. Faire baisser le coût de la rigueur
Les ingénieurs expérimentés savent que les prototypes « temporaires » ont l’habitude de devenir des systèmes de production permanents. Si vous jugez mal où un projet se situe sur le spectre — ou changez d’avis plus tard — vous voulez que la transition du jetable au durable soit aussi indolore que possible. Vous y arrivez en rendant la rigueur d’ingénierie bon marché et sans effort :
- Standardisation impitoyable : Standardiser les langages, frameworks et protocoles RPC n’est pas de la bureaucratie ; c’est éliminer des possibilités. Moins de frameworks signifie moins de linters, de patches de sécurité et d’outils d’agents sur mesure à maintenir.
- Outils in-workflow : Construisez des checks de qualité qui tournent automatiquement en arrière-plan. Quand les outils sont rapides, fiables, faibles en faux positifs et nécessitent zéro effort conscient du développeur, ça se sent gratuit — ce qui signifie que vous pouvez l’appliquer même aux projets jetables.
- Infrastructure de test sans friction : N’exigez pas que chaque développeur soit un expert en tests. Investissez dans une infrastructure qui rend les tests rapides et déterministes dès le départ — par exemple, en utilisant des agents de codage pour générer et maintenir automatiquement des versions fake in-memory de services.
- Strictness maximale dès le départ : Activez toutes les règles de lint et les réglages de strictness au maximum dès le jour un. Ça élimine les débats d’équipe sans fin et prévient le cauchemar d’essayer d’activer rétroactivement un linter sur un codebase d’un million de lignes.
Le verdict
Alors, la qualité du code compte-t-elle encore ? Kanat-Alexander nous laisse avec trois réponses claires :
- Pour le logiciel jetable ? Non.
- Pour le logiciel durable ? Oui.
- La rigueur doit-elle être chère ? Non.