Le code ne coûte plus rien. Tout le reste coûte plus cher

Le code ne coûte plus rien. Tout le reste coûte plus cher.

L'IA a rendu l'écriture du code presque gratuite. Mauvaise nouvelle : ce n'était pas ça, le problème.

---

Pendant cinquante ans, notre industrie a couru après la même chose : écrire du code plus vite. De meilleurs langages, de meilleurs frameworks, de meilleurs IDE, l'autocomplétion, puis les assistants, puis les agents qui ouvrent eux-mêmes leurs pull requests pendant qu'on dort.

On y est arrivé. Produire mille lignes de code fonctionnel prend aujourd'hui le temps de formuler une demande claire.

Et pourtant, les projets ne se livrent pas dix fois plus vite. Les backlogs ne se sont pas vidés. Les équipes ne chôment pas. Il y a une raison à ça, et elle est plus intéressante que « l'IA n'est pas encore assez bonne ».

La loi d'Amdahl s'applique aussi aux humains

Tout le monde en informatique connaît la loi d'Amdahl : le gain obtenu en accélérant une partie d'un système est limité par la portion du temps que cette partie occupe réellement.

Faisons l'exercice avec une équipe de développement. Supposons que l'écriture du code représente 25 % du temps entre une idée et sa mise en production. Le reste : comprendre le besoin, trancher les ambiguïtés, réviser, tester, déployer, corriger, convaincre.

Rendez maintenant l'écriture infiniment rapide. Le gain maximal sur l'ensemble du cycle ?

accélération = 1 / (1 - 0,25) = 1,33x

Un tiers plus vite. Pas dix fois. Pas cent fois. Même avec un outil parfait.

Le code n'a jamais été le goulot d'étranglement. C'était seulement la partie la plus visible du travail, donc celle qu'on a eu envie d'optimiser.

Jevons avait prévu la suite en 1865

L'économiste William Stanley Jevons a observé quelque chose de contre-intuitif à propos du charbon : plus les machines à vapeur devenaient efficaces, plus l'Angleterre en consommait. Rendre une ressource moins chère à utiliser n'en réduit pas l'usage, ça ouvre la porte à tous les usages qui n'étaient pas rentables avant.

Remplacez « charbon » par « code ».

Quand écrire du logiciel coûte cher, on écrit seulement ce qui en vaut la peine. Quand ça ne coûte presque rien, on écrit tout : le script qu'on aurait fait à la main, l'outil interne que personne n'aurait financé, la troisième réécriture d'un module « tant qu'à y être ».

Résultat : il n'y a pas moins de travail. Il y a beaucoup plus de code. Et chaque ligne produite reste une ligne à lire, à comprendre, à sécuriser et à maintenir.

Le code généré est gratuit à l'écriture. Il est facturé plein prix à la lecture.

Les trois nouveaux goulots

Si l'écriture n'est plus la contrainte, où est-elle rendue ?

1. Savoir quoi demander

Un agent exécute fidèlement une demande floue, et livre un résultat flou, mais avec assurance. La compétence rare n'est plus de traduire une intention en syntaxe. C'est d'avoir une intention précise au départ : les cas limites, les contraintes, ce qu'on ne veut surtout pas.

Ironie du sort, la spécification, ce document que les développeurs ont fui pendant vingt ans d'agilité, redevient l'artefact le plus important du projet.

2. Vérifier ce qu'on reçoit

Lire du code a toujours été plus difficile que l'écrire. On vient de multiplier le volume à lire sans multiplier le nombre de lecteurs.

Les équipes qui s'en sortent le mieux ne sont pas celles qui génèrent le plus. Ce sont celles qui ont investi dans la vérification automatique : des tests solides, des types stricts, des environnements où l'agent peut constater lui-même qu'il s'est trompé. Le test n'est plus un filet de sécurité, c'est le contrat.

3. Dire non

Quand tout devient faisable en un après-midi, la question n'est plus « est-ce qu'on peut le bâtir ? » mais « est-ce qu'on devrait ? ». Chaque fonctionnalité ajoutée reste une surface à supporter, à documenter et à expliquer aux utilisateurs.

Le jugement, ou si on préfère le goût, ne se génère pas. Et il devient l'actif qui distingue un bon produit d'un produit simplement rempli.

L'effet secondaire le plus sous-estimé : le logiciel jetable

Voici la partie qui me fascine le plus.

Historiquement, un logiciel devait servir des milliers de personnes pour justifier son coût de développement. Cette équation vient de sauter. On peut maintenant bâtir une application pour un seul utilisateur, pour un seul problème, et la jeter quand le problème disparaît.

Un outil sur mesure pour une PME de douze employés. Une application pour un événement qui dure une fin de semaine. Un tableau de bord qui répond à une seule question, une seule fois.

Ça change la nature même du métier. On passe d'une industrie qui fabrique des produits à une industrie qui fabrique des réponses. Et tout le marché des besoins trop petits pour intéresser un éditeur de logiciels, c'est-à-dire la majorité des besoins réels, vient de s'ouvrir.

Ce que ça veut dire pour nous

Le développeur qui se définissait par sa vitesse de frappe a un problème. Celui qui se définissait par sa compréhension du problème du client vient de recevoir un levier énorme.

En conclusion

L'IA n'a pas remplacé le travail du développeur. Elle a retiré la partie mécanique et laissé tout ce qui était difficile depuis le début : comprendre, décider, vérifier.

On pensait que notre valeur était dans le code. Elle était dans tout ce qui se passe avant et après.

La bonne nouvelle, c'est que cette partie-là ne se génère pas.