Présentez une idée à une IA, et vous la trouverez rarement à court de solutions. Une architecture apparaît. Une interface se dessine. Un schéma de données s’organise, un planning se pose, un début de code s’écrit. La capacité est impressionnante — et c’est précisément là que le piège se referme. Parce que la fonctionnalité semble facile à produire, elle paraît soudain justifiée.
Or la facilité technique ne crée pas un besoin.
Une idée réalisable n’est pas nécessairement une bonne idée.
C’est une phrase que je me répète souvent depuis un an. Avant l’IA, un filtre naturel écartait beaucoup de fausses bonnes idées : elles coûtaient trop cher à développer. On y renonçait sans même en débattre, parce que le budget tranchait à notre place. Ce filtre fonctionne beaucoup moins bien aujourd’hui. Quand fabriquer devient presque gratuit, la discipline budgétaire ne protège plus. Le risque n’est plus de manquer de moyens, c’est d’accumuler des fonctionnalités simplement parce qu’on pouvait les produire.
Ce qui est gratuit à développer n’est jamais gratuit à conserver
Une fonctionnalité n’ajoute jamais seulement une fonctionnalité. Elle ajoute un choix de plus dans une interface déjà chargée. Du code à maintenir. Des cas à tester. Des données à stocker et à protéger. Des questions au support. Une promesse commerciale implicite. Une responsabilité future dont personne ne se souvient au moment de la livraison.
Même quand l’IA la produit en une heure, cette fonctionnalité continue de coûter chaque mois qui suit. Le coût de développement s’est effondré ; le coût de possession, lui, n’a pas bougé. C’est un déséquilibre nouveau, et il est traître : il déplace la dépense là où on ne la regarde plus.
C’est pour cette raison que, chez nous, la question n’est plus seulement comment développer ça ? mais devrions-nous seulement le faire ? Et pour y répondre honnêtement, j’ai pris une habitude qui surprend souvent quand je la décris.
Demander un réquisitoire avant un plan de développement
Avant de demander à un agent comment construire une fonctionnalité, je lui demande de plaider contre elle.
Le réquisitoire, littéralement : pourquoi ne faudrait-il pas la développer ? Quel problème réel prétend-elle résoudre, et pour combien d’utilisateurs concrets ? Une réponse existe-t-elle déjà, ailleurs dans le produit ? Peut-on satisfaire le besoin sans écrire une ligne de code ? Quel comportement cherche-t-on vraiment à changer ? Quelle charge de maintenance cela représente-t-il dans un an ? Comment saurons-nous, dans trois mois, si c’était utile — et à quelles conditions faudra-t-il la retirer ?
Ces questions n’ont rien d’anti-innovation. Elles évitent seulement de confondre enthousiasme et priorité. Un agent est particulièrement bon à cet exercice, à condition qu’on le lui demande explicitement : livré à lui-même, il propose un plan de développement, parce que c’est ce qu’on attend d’un assistant serviable. Contraint de contester, il fait remonter des angles morts que l’enthousiasme du moment nous cache. La meilleure réponse d’un agent n’est pas toujours un plan de dev. Parfois, c’est : « ce besoin est réel, mais cette fonctionnalité n’est pas la meilleure manière d’y répondre. »
Prototyper pour décider, pas pour s’engager
L’IA fabrique un prototype à une vitesse déconcertante. C’est, à mon sens, l’un de ses meilleurs usages — à condition de ne pas se tromper sur sa nature.
Un prototype est un outil de décision. Il sert à tester un parcours, à montrer quelque chose à un client, à confronter une hypothèse au réel, à estimer les difficultés cachées. Il n’a pas vocation à devenir une fonctionnalité de production simplement parce qu’il existe déjà et qu’il marche à peu près. La bascule silencieuse du prototype vers la production, sous prétexte que « le plus dur est fait », est l’une des erreurs les plus coûteuses que j’observe autour de l’IA.
Le coût irrécupérable d’un prototype est désormais très faible. C’est une bonne nouvelle, à une condition : que ce faible coût nous serve à l’abandonner plus facilement, pas à le sanctifier. On a moins investi ; on devrait donc renoncer plus vite. Dans les faits, c’est souvent l’inverse qui se produit, et le prototype devient une dette qu’on n’a jamais vraiment choisie.
La suppression est aussi une décision produit
Une organisation valorise spontanément ce qu’elle livre. On parle des lancements, des fonctionnalités ajoutées, des chantiers ouverts. On parle beaucoup moins des projets arrêtés à temps, des fonctionnalités volontairement redimensionnées, des développements remplacés par quelque chose de plus simple.
Pourtant, ces décisions-là créent parfois plus de valeur qu’une livraison de plus. Elles préservent la lisibilité du produit. Elles concentrent les ressources là où elles comptent. Elles réduisent les coûts futurs que personne n’avait anticipés.
Nous en avons fait l’expérience très concrètement. Notre site vitrine hébergeait un mini-site événementiel dédié à la Coupe du Monde 2026, développé et maintenu à la main. À un moment, la vraie question n’était plus comment l’améliorer mais pourquoi le porter là. Car nous avions déjà, dans notre propre suite, de quoi le faire vivre sans une ligne de code dédiée : notre brique CMS, alimentée par notre moteur de scores LiveSports. Nous avons donc retiré la fonctionnalité du site vitrine et laissé cette plateforme la porter. Ce n’était pas un échec technique — le code fonctionnait. C’était une décision produit assumée : ne pas redévelopper dans un coin ce qu’un autre de nos produits fait déjà, mieux, et sans double maintenance.
Cette décision n’a pas de trace glorieuse. Elle a une trace tracée, c’est différent. Chez nous, renoncer n’est pas une absence de décision : c’est une décision qui laisse une marque. Nos outils de suivi ont d’ailleurs des étiquettes faites exactement pour ça — un travail qu’on décide de ne pas faire est marqué comme tel, Won’t Do, aux côtés de « doublon » ou « ne se reproduit pas ». La décision de ne pas faire est écrite, datée, motivée. Elle n’est pas subie, elle est prise.
Définir les conditions d’arrêt dès le départ
La meilleure manière de savoir renoncer plus tard, c’est de décider au démarrage dans quelles conditions on renoncera.
Avant de lancer un développement incertain, nous essayons de poser noir sur blanc : quelle hypothèse teste-t-on ? Quel public est concerné ? Quel résultat attend-on, mesuré par quelle métrique ? À quelle date réévalue-t-on ? Et surtout — dans quelles conditions décidera-t-on d’arrêter ? Écrire la condition d’abandon avant d’être émotionnellement investi change tout. Une fois le travail commencé, on trouve toujours de bonnes raisons de continuer.
L’IA est précieuse à cette étape aussi. Elle aide à formaliser ces critères, puis à analyser froidement les résultats au moment de la réévaluation. Elle n’accélère pas seulement la décision de faire : elle accélère aussi, quand on le lui demande, la décision de ne pas poursuivre. C’est d’ailleurs à cela que sert, chez nous, un audit périodique des fonctionnalités : passer chacune au crible pour décider si elle mérite d’exister, d’être réduite, ou d’être supprimée.
Le courage de ne pas produire
Quand fabriquer devient facile, la rareté se déplace. Ce qui manque n’est plus la capacité technique — l’IA la fournit en abondance. Ce qui manque, c’est la capacité à choisir : à distinguer une idée réalisable d’une idée souhaitable, à préférer un produit lisible à un produit exhaustif, à assumer un renoncement quand tout, autour de nous, célèbre l’ajout.
C’est un renversement inconfortable pour un dirigeant. Pendant des années, produire vite était un avantage compétitif. Il l’est encore, mais il ne suffit plus. La prochaine discipline à installer, celle qui séparera les équipes qui subissent l’IA de celles qui la maîtrisent, tient dans une phrase que je voudrais entendre plus souvent de la part de nos agents comme de nos équipes : ce besoin est réel, mais ne développons pas cette fonctionnalité — voici pourquoi.
Et vous — quand avez-vous, pour la dernière fois, félicité quelqu’un d’avoir décidé de ne pas construire quelque chose ?