Paradoxe de Jevons : l’IA rend le code gratuit, et l’effet rebond transforme votre équipe en usine à features

Le 8 novembre 2026, Stefan Wolpers (Professional Scrum Trainer, auteur du Scrum Anti-Patterns Guide) a publié sur Age of Product un texte au titre provocateur : We’re Not Paid to Practice Scrum, but Answer 5 Product Questions. Son point de départ tient en une idée que tout dirigeant devrait méditer : pendant des décennies, le coût élevé du développement logiciel jouait un rôle de rationnement. Personne ne pouvait tout construire, donc quelqu’un devait choisir. L’IA a fait sauter ce garde-fou. Et ce qui se passe ensuite porte un nom bien connu des économistes : le paradoxe de Jevons.

Quand une ressource devient moins chère à utiliser, on ne l’économise pas : on en consomme davantage. Le code ne fait pas exception. Les agents IA ont fait chuter le coût d’une fonctionnalité, donc les organisations en lancent plus, en livrent plus, en maintiennent plus. Mais personne n’a vérifié si ces fonctionnalités résolvaient un vrai problème client.

Cet article vous explique d’où vient ce paradoxe, ce qu’est l’effet rebond, pourquoi il frappe aujourd’hui vos équipes produit, et comment reprendre la main avec cinq questions simples que l’IA ne posera jamais à votre place.

Qu’est-ce que le paradoxe de Jevons ?

En 1865, l’économiste britannique William Stanley Jevons publie The Coal Question. À l’époque, la Grande-Bretagne tire sa puissance industrielle du charbon, et une inquiétude monte : les réserves vont-elles s’épuiser ? Beaucoup pensent que le progrès technique va régler le problème. La machine à vapeur, perfectionnée depuis James Watt, consomme de moins en moins de charbon pour le même travail. Une meilleure efficacité devrait donc faire baisser la consommation de charbon.

Jevons démontre l’inverse. Chaque amélioration de l’efficacité rend la vapeur plus rentable, donc utilisable dans de nouveaux secteurs, de nouvelles usines, de nouveaux usages. La consommation totale de charbon ne baisse pas : elle explose. Comme le résume le projet Energy History de l’université Yale, pour Jevons, une efficacité accrue de la consommation ne réduit pas la demande d’énergie.

Voilà le paradoxe de Jevons en une phrase : un gain d’efficacité sur une ressource peut provoquer une augmentation de la consommation de cette ressource, au lieu de la réduction attendue. Ce n’est pas une loi physique, c’est un mécanisme économique, qui dépend du marché et de la demande. Mais quand la demande est élastique, il frappe fort.

Effet rebond direct, rebond indirect, effet Jevons : les nuances à connaître

Les économistes de l’énergie parlent aujourd’hui d’effet rebond pour décrire ce phénomène, et distinguent plusieurs niveaux :

• L’effet rebond direct : le bien devenu plus efficace est utilisé davantage. Une voiture plus sobre coûte moins cher au kilomètre, donc on roule plus. Une partie des économies d’énergie promises s’évapore.
• Le rebond indirect : l’argent économisé est dépensé ailleurs, dans d’autres biens et services qui consomment eux aussi des ressources.
• L’effet Jevons (ou « backfire ») : le cas extrême où le rebond dépasse 100 %. La consommation totale finit plus haute qu’avant l’amélioration. C’est ce que Jevons observait avec le charbon.

C’est pour cela que l’efficacité énergétique, seule, ne suffit pas toujours à faire baisser la demande énergétique ou les émissions de CO2 : sans changement des comportements, une partie des gains d’efficacité est mangée par la hausse des usages. Retenez cette mécanique. Elle va nous servir pour parler de votre backlog.

Le paradoxe de Jevons appliqué à l’IA : ce qui ne grossit pas avec vos agents

Soyons honnêtes : la baisse du coût de construction est une excellente nouvelle. Des problèmes clients qui n’étaient pas rentables à résoudre le deviennent. Un prototype monté en un après-midi est une manière légitime de tester si un client s’intéresse vraiment à une idée. Le problème n’est pas l’efficacité. Le problème, c’est ce qui ne suit pas.

Car plusieurs ressources ne se multiplient pas avec le nombre d’agents :

• L’attention de vos clients. Ils ne lisent pas plus de release notes parce que vous en écrivez plus.
• Leur capacité à absorber le changement. Dix nouvelles fonctionnalités par mois, c’est dix choses à apprendre, ou à ignorer.
• Votre capacité de revue. Le rapport DORA 2025 sur le développement assisté par IA décrit l’IA comme un amplificateur des forces et des faiblesses existantes d’une organisation, et constate que l’instabilité des livraisons continue d’augmenter. DORA ajoute un mécanisme que tout relecteur connaît : le gain de vitesse de l’auteur se transforme souvent en charge cognitive accrue pour celui qui relit.
• Votre capacité à maintenir, sécuriser et supporter tout ce qui a été livré. Le code généré en deux heures coûte toujours des années de maintenance.

Quand la décision de lancer un chantier repose sur le coût de la première version, les économies visibles captent toute l’attention et les coûts de cycle de vie disparaissent du radar. Nous avions déjà décrit ce mirage dans notre article sur le vibe coding en entreprise : tout le monde code avec l’IA, plus personne ne trie.

Les 5 questions produit que l’effet rebond rend impossibles à esquiver

Wolpers résume depuis des années son métier par une phrase que nous adorons chez Corporate Mavericks : nous ne sommes pas payés pour pratiquer Scrum, mais pour résoudre les problèmes de nos clients dans les contraintes données, tout en contribuant à la pérennité de l’organisation. Quand construire ne coûte presque plus rien, cinq questions deviennent beaucoup plus chères à sauter :

1. Quel problème client mérite d’être résolu ?

La réponse a deux faces : pourquoi le client s’en soucie, et pourquoi le résoudre vaut le coup pour l’organisation. Uri Levine, cofondateur de Waze, en a fait le titre de son livre de 2023 : Fall in Love with the Problem, Not the Solution. Quand le code est gratuit, tomber amoureux de sa propre solution redevient abordable. Méfiance aussi avec l’IA qui « résume » trois cents tickets support en trois problèmes : elle a déjà décidé ce qu’elle gardait et ce qu’elle jetait.

2. Est-ce la meilleure utilisation de notre temps, maintenant ?

Les nouvelles fonctionnalités sont en concurrence avec la maintenance, la fiabilité, la dette technique et le support. Et dans un comité, la maintenance perd toujours face à une fonctionnalité brillante. Le bon affinage d’un backlog ne produit pas des tickets jolis (c’est justement ce qu’un agent produit le plus vite), il produit une compréhension partagée suffisante pour décider, y compris de ne pas construire.

3. Est-ce assez bon pour les gens qui vont le voir ?

« Assez bon » dépend de l’objectif. Un prototype pour apprendre et du code destiné à la production n’ont pas le même standard, mais chacun doit en avoir un. Le vrai danger : ne plus savoir distinguer la sonde jetable du produit, et voir le prototype de deux heures partir en production « parce qu’il marche déjà ». Après la vingtième sortie d’agent de la journée, « ça a l’air bien » devient le seul critère de qualité. Ce n’est pas un critère.

4. Est-ce que ça a résolu le problème ?

L’output se compte facilement : tickets fermés, fonctionnalités livrées, story points brûlés. Aucun de ces chiffres ne dit si le problème du client a diminué. Wolpers propose un exemple simple : une équipe veut réduire le nombre de nouveaux clients qui décrochent pendant l’onboarding, et un agent construit une visite guidée en deux jours. Avant de livrer, l’équipe écrit quatre choses : la situation de départ (la part actuelle de clients qui abandonnent avant leur premier résultat utile), le changement qui justifierait de garder la fonctionnalité, la période d’observation (plusieurs semaines) et les règles de décision (garder, modifier ou supprimer). Ce dernier point est celui que tout le monde saute, parce que supprimer quelque chose qui « marche » ressemble à du gaspillage.

5. Notre façon de travailler est-elle toujours la bonne ?

C’est la question que l’IA bouleverse le plus, parce que la façon de travailler change à chaque nouveau modèle et à chaque nouvel agent. La rétrospective existe pour ça. Wolpers recommande d’y ajouter un audit régulier des tâches déléguées à l’IA, avec un signal d’alerte précis : quand le temps de revue par livrable tend vers zéro, l’assistance est silencieusement devenue de l’automatisation non relue.

Où les équipes se plantent (et pourquoi l’IA aggrave chaque erreur)

Chacune des cinq questions a son échec classique, et l’IA les rend tous moins chers à commettre :

• Quel problème ? La demande du directeur saute l’entonnoir et arrive dans le backlog avec une deadline, parce que la hiérarchie pèse plus lourd que les preuves.
• Meilleur usage du temps ? Un backlog bien rangé passe pour un bon affinage, et la maintenance perd tous ses arbitrages.
• Assez bon ? La fatigue de revue s’installe, et on valide à l’œil.
• Ça a marché ? La Sprint Review devient une démo, les parties prenantes applaudissent l’incrément au lieu de demander ce qui a changé pour le client.
• Comment on travaille ? Personne n’a le temps d’inspecter sa façon de travailler, tout le monde est occupé à livrer ce que les agents ont produit.

L’usine à features commence précisément là : quand une équipe considère qu’une livraison réussie prouve que le choix était bon. C’est la même illusion que nous dénoncions à propos du ROI de l’IA : la courbe de vélocité monte, et personne ne sait si la valeur suit.

Comment éviter l’effet rebond dans votre organisation : 6 leviers concrets

Vous ne stopperez pas la baisse du coût du code, et ce n’est pas souhaitable. En revanche, vous pouvez éviter que ce gain d’efficacité se transforme en augmentation de la consommation de l’attention de vos équipes et de vos clients.

1. Posez une limite de travail en cours sur la revue, pas sur la production. Le vrai goulot n’est plus le développement, c’est ce que l’équipe peut relire et mesurer correctement par cycle. Une limite explicite rend ce plafond visible, quel que soit le nombre de pull requests ouvertes par les agents.
2. Étiquetez chaque élément : sonde ou produit. Un prototype sert à apprendre, il a son propre standard et une date de péremption. Il ne part jamais en production sans repasser par la Definition of Done.
3. Écrivez les règles de décision avant de livrer. Situation de départ, seuil de succès, durée d’observation, conséquence (garder, modifier, supprimer). Sans ça, tout résultat sera interprété comme un succès.
4. Donnez un standard aux livrables IA. Une analyse, un rapport ou des tickets rédigés par un agent méritent un critère d’acceptation écrit par ceux qui en sont responsables, avant de sortir de l’équipe.
5. Protégez le temps d’apprentissage. Erik Brynjolfsson, Daniel Rock et Chad Syverson ont décrit la « courbe en J » de la productivité des technologies généralistes comme l’IA : elles exigent des investissements immatériels (nouveaux processus, nouvelles compétences) qui font paraître la productivité plus faible au début. Juger trop vite, c’est condamner l’apprentissage comme une perte.
6. Donnez à quelqu’un le pouvoir de dire stop. C’est le levier le plus inconfortable, et le seul qui change vraiment le modèle opérationnel.

Ce dernier point rejoint le débat sur l’avenir du rôle de Product Owner face à l’IA : si personne n’a l’autorité de renoncer à construire, le rôle se réduit à alimenter des agents.

Ce qu’il faut retenir

Le paradoxe de Jevons n’est pas une curiosité d’historien de la machine à vapeur. C’est le mécanisme qui transforme aujourd’hui la baisse spectaculaire du coût du code en avalanche de fonctionnalités non triées. L’effet rebond n’est ni bon ni mauvais en soi : il devient toxique quand plus personne ne filtre ce qui mérite d’être construit.

Le coût élevé du développement faisait un tri grossier à votre place (souvent mal, d’ailleurs, car l’idée portée par le sponsor le plus haut placé survivait toujours). Ce tri a disparu. À vous de le remplacer par quelque chose de mieux : des questions explicites, des preuves, et le droit de dire non.

FAQ : paradoxe de Jevons, effet rebond et IA

Source principale : Stefan Wolpers, We’re Not Paid to Practice Scrum, but Answer 5 Product Questions, Age of Product, 8 novembre 2026. Les chiffres Epoch AI, Anthropic S-1, DORA 2025 et l’enquête sur le product operating model sont cités d’après cet article.