Dans un monde où l’intelligence artificielle peut générer du code plus rapidement que jamais, la valeur réelle d’un ingénieur logiciel ne réside plus dans sa capacité à produire des lignes de code, mais dans sa capacité à réfléchir, analyser et résoudre des problèmes. L’article de Milan Cvitkovic, "You're Not Paid to Write Code", remet en question la culture du "code d’abord" et souligne l’importance de la réflexion stratégique avant toute implémentation technique.
Le piège de l’identité et la dette technique
L’auteur commence par dénoncer un mythe persistant : l’ingénieur logiciel n’est pas payé pour écrire du code, mais pour résoudre des problèmes. Pourtant, beaucoup d’équipes mesurent encore la performance à l’aune du nombre de lignes de code produites ou de fonctionnalités livrées. Cette approche est non seulement obsolète, mais aussi risquée.
- Le code est un passif, pas un actif : Chaque ligne de code écrite doit être maintenue, documentée et adaptée aux évolutions futures. Comme le souligne Jeff Atwood, "le meilleur code est celui qu’on n’écrit pas". L’objectif devrait être de résoudre un problème avec le moins de code possible, en privilégiant des solutions existantes ou des simplifications architecturales.
- L’exemple du panier d’achat : Un ingénieur qui optimise une requête SQL pour accélérer un processus de paiement sans analyser les données utilisateurs risque de résoudre le mauvais problème. Dans ce cas, le vrai frein était un formulaire de paiement trop long, et non la performance technique.
L’impact de l’IA et la nécessité de repenser les priorités
Avec l’avènement des outils d’IA générative, la tentation de coder rapidement est encore plus forte. Pourtant, une étude de 2025 (METR) révèle que les développeurs utilisant ces outils étaient 19 % plus lents en réalité, en raison d’une surconfiance et d’une baisse de la qualité du code. L’IA amplifie les erreurs de cadrage et de jugement si la réflexion préalable fait défaut.
- L’IA ne remplace pas la pensée critique : Elle accélère l’exécution, mais ne peut pas définir ce qui doit être exécuté. Les ingénieurs doivent donc valider les sorties de l’IA comme ils le feraient pour un junior, en évaluant la pertinence business et technique des solutions proposées.
- La méthode "thinking-first" : Avant de coder, l’auteur recommande de rédiger un paragraphe clarifiant :
- Quel est le vrai problème ?
- Qui est affecté ?
- Comment saurons-nous qu’il est résolu ?
Pour les projets plus complexes, un document léger suffira pour aligner les parties prenantes et tester les hypothèses via des prototypes.
Le rôle réel de l’ingénieur logiciel en 2026
L’ingénieur moderne doit :
- Comprendre le problème avant de chercher une solution technique.
- Évaluer les compromis : coûts de maintenance, risques, et valeur business.
- Architecturer avec discernement : une mauvaise décision technique coûte cher à long terme.
- Valider le code généré par l’IA comme on le ferait pour un collègue junior.
Moins de code, plus de valeur
L’article rappelle que les erreurs coûteuses en développement logiciel ne viennent pas des bugs, mais d’une mauvaise compréhension du problème. En 2026, la vraie compétence d’un ingénieur réside dans sa capacité à poser les bonnes questions, challenger les exigences et éviter le code inutile. Comme le résume l’auteur : "Le meilleur code est celui qu’on n’écrit pas. Et si vous devez en écrire, rappelez-vous : chaque ligne est une promesse faite au futur."