La retenue est la compétence de développeur la plus importante en 2026

Le mois dernier, un ami m'a montré son produit de portail client. Interface propre. Les clients l'adoraient. Partage simple de livrables, workflows d'approbation, un outil focalisé qui faisait une chose extrêmement bien. Il en était fier. À juste titre.

Puis il a ouvert son backlog et m'a montré les demandes de fonctionnalités qui étaient arrivées au cours du dernier trimestre. Facturation. Suivi du temps. Gestion de projet avec diagrammes de Gantt. Un système de chat intégré. Un tableau de bord de reporting. Il pouvait construire chacune d'entre elles — la plupart en un week-end, avec Claude Code et un prompt bien structuré. L'IA n'avait pas seulement rendu ces fonctionnalités possibles. Elle les avait rendues trivialement faciles.

Il a d'abord construit le module de facturation. Puis le suivi du temps. En six semaines, son portail client propre était devenu une suite de gestion de projet boursouflée qui concurrençait mal Asana, mal FreshBooks et mal Slack — le tout simultanément. Le temps d'onboarding avait triplé. Les tickets de support étaient passés de "comment partager un livrable ?" à "où est passé le bouton d'approbation ?" Ses clients d'origine — ceux qui avaient choisi son produit spécifiquement parce qu'il était focalisé — commençaient à partir.

L'outil qui lui avait permis de construire plus vite que jamais était le même outil qui lui avait permis de détruire son produit plus vite que jamais. Et la compétence qui lui manquait n'avait rien à voir avec le code.

Le goulot d'étranglement dont plus personne ne parle

Pendant des années, la contrainte des équipes logicielles était la vitesse d'exécution. On avait plus d'idées que de capacité. Le backlog était un cimetière de fonctionnalités qui ne seraient jamais construites parce qu'il n'y avait tout simplement pas assez de temps d'ingénierie. La planification prenait peut-être 20% du cycle — le reste était de l'implémentation concentrée, lutter avec les dépendances, déboguer les cas limites, livrer.

Cette contrainte a disparu.

Les outils de codage IA en 2026 ont éliminé le goulot d'exécution si complètement que l'ancien ratio planification-construction s'est inversé. Là où les équipes passaient autrefois 80% de leur temps à construire et 20% à planifier, les équipes avec lesquelles je travaille passent maintenant la majorité de leur temps sur une question qui existait à peine il y a trois ans : devrait-on construire ça ?

Ce n'est pas un changement subtil. C'est un changement fondamental dans ce qui rend un développeur logiciel précieux. Le Chaos Report du Standish Group a trouvé que 50% des fonctionnalités dans les logiciels sur mesure sont rarement ou jamais utilisées. Cette statistique date d'une ère où construire des fonctionnalités était coûteux et lent. Quand construire est bon marché et rapide, le pourcentage de fonctionnalités inutilisées ne baisse pas — il augmente, parce qu'il n'y a pas de friction naturelle pour empêcher la surconstruction.

Le Project Management Institute rapporte qu'environ la moitié de tous les projets souffrent de scope creep. Encore une fois — ça vient d'une ère de contraintes. Supprimez les contraintes, et le scope creep ne disparaît pas. Il s'accélère.

Voici ce que j'ai réalisé après avoir vu cela se produire dans mes propres projets et les équipes que je conseille : la compétence la plus précieuse en développement logiciel n'est plus la capacité de construire. C'est la discipline de décider quoi ne pas construire. Et cette discipline a un nom.

La retenue.

Pourquoi l'IA ne peut pas remplacer cette compétence

Je passe la majorité de mes heures de travail dans Claude Code. J'ai écrit sur comment il a changé tout mon workflow de développement, comment les équipes d'agents peuvent traiter des projets complexes en parallèle, comment la gestion des tâches entre sessions a transformé les refactors multi-fichiers. Je ne suis pas un sceptique de l'IA. Je suis profondément ancré dans cet écosystème.

Mais voici ce que j'ai remarqué après des mois de livraison avec ces outils : l'IA est extraordinairement bonne pour le comment et véritablement terrible pour le si on devrait.

Demandez à Claude Code de construire un module de facturation pour un portail client. Il générera des modèles de données propres, une UI solide, une validation correcte, la gestion des cas limites — le package complet. Ce qu'il ne fera pas — ce qu'il ne peut pas faire — c'est vous dire qu'ajouter la facturation va confondre vos utilisateurs principaux, cannibaliser l'identité de votre produit et vous mettre en concurrence directe avec FreshBooks, une entreprise avec une décennie d'expertise dans le domaine et 100M$ de chiffre d'affaires annuel.

Ce n'est pas une décision technique. C'est une décision produit. Et elle nécessite quelque chose qui manque fondamentalement à l'IA : une compréhension du contexte de votre client, de votre position concurrentielle et des conséquences de second ordre de l'ajout de surface à votre produit.

J'ai commencé à voir cela comme la différence entre la capacité et le jugement. L'IA vous donne une capacité quasi infinie. Le jugement est ce qui vous dit quelles capacités déployer réellement. Et le jugement ne vient que de la compréhension des personnes qui utilisent votre logiciel — leurs frustrations, leurs workflows, la raison pour laquelle ils ont choisi votre outil plutôt que les douze alternatives.

Aucun modèle, quelle que soit la taille de la fenêtre de contexte, ne peut reproduire cette compréhension. Pas encore. Peut-être jamais.

Le problème du portail client — un pattern que je vois sans cesse

L'histoire du portail client avec laquelle j'ai ouvert n'est pas un cas isolé. J'ai vu ce pattern se répéter dans une demi-douzaine de produits l'année dernière, et il suit toujours le même arc.

Phase 1 : Focus. Le produit démarre propre. Il résout bien un problème. Les clients l'adorent parce qu'il est simple, opinioné et rapide. L'équipe reçoit des avis positifs spécifiquement parce que le produit n'essaie pas de tout faire.

Phase 2 : Pression de fonctionnalités. Les clients commencent à demander des fonctionnalités adjacentes. "Pouvez-vous ajouter la facturation ?" "Et le suivi du temps ?" "Ce serait super si on pouvait aussi gérer des projets ici." Chaque demande est raisonnable isolément. Chaque fonctionnalité est constructible en jours, voire en heures, avec l'assistance IA.

Phase 3 : Le piège de la construction. L'équipe dit oui à tout parce que dire oui est facile quand construire est bon marché. Ils livrent fonctionnalité après fonctionnalité, chacune ajoutant de la complexité à l'UI, au modèle de données, au flux d'onboarding et à la charge de support.

Phase 4 : Crise d'identité. Le produit qui était "le meilleur outil pour partager des livrables" est maintenant "un outil médiocre qui fait aussi six autres choses." Les nouveaux utilisateurs l'ouvrent et se sentent submergés. Les utilisateurs d'origine ne trouvent plus les fonctionnalités pour lesquelles ils sont venus. Le produit a perdu sa raison d'être.

Phase 5 : Déclin. Le churn augmente. L'équipe réagit en construisant plus de fonctionnalités pour retenir les utilisateurs, ce qui aggrave le problème. C'est une spirale descendante alimentée par la vitesse même que l'IA fournit.

La solution n'est pas de construire plus lentement. La solution est de mieux décider.

À quoi ressemble la retenue en pratique

La retenue ne consiste pas à dire non à tout. C'est de la paralysie, pas de la stratégie. La retenue, c'est avoir un framework pour décider quelles choses construire et — de façon cruciale — avoir un processus qui vous force à prendre cette décision avant de toucher du code.

Voici le framework que j'ai adopté, et il a transformé ma façon d'aborder chaque projet.

Étape 1 : La conversation de pré-planification

Avant d'ouvrir Claude Code, avant d'écrire une seule ligne d'une spec, j'ai ce que j'appelle une conversation de cadrage. Parfois c'est avec un cofondateur ou un responsable produit. Parfois c'est juste moi et Claude dans une fenêtre de conversation séparée — pas en mode code, mais en mode réflexion.

L'objectif de cette conversation n'est pas "comment construisons-nous ça." L'objectif est "devrait-on construire ça, et si oui, qu'est-ce qu'on construit exactement ?"

J'utilise Claude comme partenaire de réflexion stratégique ici. Pas en lui donnant une liste rigide de questions — ça produit des réponses formulaïques. À la place, je décris l'idée de fonctionnalité et je demande à Claude de la mettre à l'épreuve. Remettre en question mes hypothèses. Faire émerger des compromis que je n'ai pas considérés. Me poser des questions auxquelles je n'ai pas encore de bonnes réponses.

Un prompt typique ressemble à quelque chose comme ça :

J'envisage d'ajouter [fonctionnalité] à [produit]. Le produit fait actuellement [fonction principale]
pour [client cible]. Avant de construire quoi que ce soit, je veux que tu agisses comme un stratège
produit critique. Pose-moi des questions de clarification sur :

- Le problème central que cette fonctionnalité résout
- Qui la demande spécifiquement et pourquoi
- Ce qu'ils font actuellement à la place
- Si cela renforce ou dilue l'identité du produit
- À quoi nous devrions renoncer pour bien faire ça

Ne me donne pas un questionnaire rigide. Aie une vraie conversation. Pousse quand mon
raisonnement est faible.

Ce qui ressort de cette conversation, c'est de la clarté. Parfois la fonctionnalité s'en sort intacte. Parfois sa portée est drastiquement réduite. Parfois je réalise qu'elle ne devrait pas être construite du tout — au moins pas comme fonctionnalité native.

Étape 2 : L'alternative intégration d'abord

L'une des formes les plus puissantes de retenue est de choisir l'intégration plutôt que l'implémentation. Au lieu de construire la facturation dans le portail client, proposez une intégration Stripe ou FreshBooks. Au lieu de construire la gestion de projet, connectez-vous à Linear ou Asana via API.

Cette approche a un avantage réel au-delà du focus produit : vos utilisateurs obtiennent des outils best-in-class pour chaque fonction au lieu d'une version intégrée médiocre. Et votre équipe d'ingénierie maintient une codebase plus petite et plus focalisée.

Dans l'architecture agent skills qui émerge dans les outils de codage IA, cela s'intègre parfaitement. Au lieu de construire des fonctionnalités monolithiques, vous construisez des agent skills focalisés qui peuvent interagir avec des services externes. Chaque skill fait une chose. Chaque skill est testable, maintenable et remplaçable indépendamment.

Je construis avec ce pattern dans Claude Code, et l'approche agent skills rend cela particulièrement naturel. Un skill qui se connecte à l'API de Stripe est plus propre, plus maintenable et plus puissant qu'un module de facturation bâclé que vous avez construit vous-même.

Étape 3 : Le document de limites de portée

Avant qu'une fonctionnalité reçoive une spec, elle reçoit des limites de portée. C'est un document court — généralement moins d'une page — qui déclare explicitement ce qui est dans la portée et ce qui est hors portée. Pas comme une formalité, mais comme un engagement.

Voici à quoi ressemblent les miens :

La colonne "Pourquoi hors portée" est la plus importante. Elle vous force à articuler la raison pour laquelle quelque chose ne devrait pas être construit, ce qui rend beaucoup plus difficile de l'ajouter silencieusement plus tard quand quelqu'un le demande gentiment.

Le Plan Mode est maintenant un standard de l'industrie — mais ce n'est pas suffisant

Quelque chose d'intéressant s'est produit dans les outils de codage IA début 2026. Claude Code, Cursor et Codex ont tous convergé vers le même pattern architectural : un mode planification dédié qui sépare la réflexion de la construction.

Dans Claude Code, vous entrez en mode planification en appuyant sur Shift+Tab ou en tapant /plan. Le modèle passe en lecture seule — il explore votre codebase, pose des questions de clarification et génère un plan d'implémentation sans écrire un seul fichier. Cursor a un mécanisme similaire. De même que Codex, avec sa propre variation du pattern.

Cette convergence n'est pas une coïncidence. Les créateurs d'outils sont tous arrivés à la même conclusion : les développeurs qui planifient avant de construire produisent de meilleurs résultats. Le développement piloté par les spécifications — où la spécification est la source de vérité, pas le code — est devenu le workflow standard de l'industrie pour le développement sérieux assisté par IA.

Mais voici ce que la plupart des gens manquent à propos du mode planification : il résout le problème du comment construire. Il ne résout pas le problème du quoi construire.

Le mode planification intervient après que vous avez déjà décidé de construire quelque chose. Il vous aide à bien le construire. Il vous aide à réfléchir à l'architecture, aux flux de données, aux dépendances, aux cas limites. C'est véritablement précieux — je l'utilise pour chaque fonctionnalité significative.

Ce que le mode planification ne fait pas, c'est remettre en question si la fonctionnalité devrait exister en premier lieu. Il prend votre décision de construire comme acquise et optimise l'exécution. C'est comme avoir un navigateur brillant qui peut trouver l'itinéraire le plus rapide vers n'importe quelle destination mais ne demande jamais si vous allez dans la bonne ville.

La conversation de pré-planification que j'ai décrite plus tôt est la couche manquante. Elle se situe au-dessus du mode planification dans la hiérarchie du workflow. D'abord vous décidez quoi construire (pré-planification). Ensuite vous décidez comment le construire (mode planification). Ensuite vous le construisez (implémentation).

Sautez la première étape, et le mode planification vous aide juste à construire la mauvaise chose plus vite.

Le workflow de développement piloté par les spécifications qui fonctionne vraiment

Voici le workflow complet auquel je suis arrivé après des mois d'itération. Il combine la conversation de retenue stratégique avec la planification tactique que fournissent des outils comme Claude Code.

Phase 1 : Cadrer (Humain + IA comme partenaire de réflexion)

C'est la conversation de pré-planification. Vous n'écrivez pas de code. Vous n'écrivez pas de specs. Vous réfléchissez — à voix haute, avec l'IA comme caisse de résonance.

Entrées : Une idée brute de fonctionnalité, du feedback client, un signal de marché ou une pression concurrentielle.

Processus :

1. Décrivez l'idée à Claude dans un contexte non codant
2. Laissez Claude poser des questions de clarification (ne lui donnez pas un template rigide)
3. Définissez le "job to be done" central — quel problème cela résout-il ?
4. Identifiez le client cible et sa solution de contournement actuelle
5. Testez la portée sous pression — qu'est-ce qui est dedans, dehors, et pourquoi
6. Cartographiez le parcours utilisateur avant de toucher aux détails techniques

Sortie : Un Product Requirements Document (PRD) léger avec l'énoncé du problème, les limites de portée, les parcours utilisateurs et les décisions explicites sur ce que vous ne construisez pas.

Le mouvement clé ici : le PRD devrait contenir au moins autant sur ce que vous avez décidé de ne pas faire que sur ce que vous avez décidé de faire. Cette documentation de retenue est ce qui empêche le scope creep plus tard.

Phase 2 : Planifier (Outil de codage IA en mode planification)

Maintenant vous amenez le PRD dans Claude Code, Cursor ou votre outil de choix et entrez en mode planification.

Entrées : Le PRD de la Phase 1.

Processus :

1. Alimentez le PRD dans Claude Code en mode planification (/plan ou Shift+Tab)
2. Laissez le modèle analyser votre codebase existante par rapport aux exigences
3. Générez un plan architectural : modèles de données, endpoints API, structure des composants
4. Vérifiez le plan pour le scope creep — introduit-il quelque chose qui n'est pas dans le PRD ?
5. Itérez jusqu'à ce que le plan corresponde exactement aux limites de portée

Sortie : Un plan d'implémentation détaillé avec les changements fichier par fichier, l'ordre des dépendances et la complexité estimée.

Phase 3 : Construire (Outil de codage IA en mode implémentation)

Ce n'est que maintenant que vous écrivez du code. Et parce que vous avez fait le travail stratégique en amont, l'implémentation est focalisée, rapide et disciplinée.

Entrées : Le plan approuvé de la Phase 2.

Processus :

1. Exécutez le plan étape par étape
2. Utilisez l'exécution parallèle de tâches pour les flux de travail indépendants
3. Vérifiez chaque composant terminé par rapport au document de limites de portée
4. Arrêtez-vous quand le plan est terminé — résistez à la tentation d'ajouter "juste une chose de plus"

Sortie : Du code fonctionnel qui correspond exactement à la spec. Rien de plus, rien de moins.

Phase 4 : Valider (Jugement humain)

Après la construction, revenez à la couche stratégique.

Cette fonctionnalité renforce-t-elle ou dilue-t-elle l'identité du produit ? Le parcours utilisateur semble-t-il correct ? Y a-t-il quelque chose que vous avez construit qui, avec le recul, aurait dû être une intégration plutôt qu'une fonctionnalité native ?

C'est là que vous attrapez le scope creep qui s'est glissé pendant l'implémentation. Ça arrive même avec une bonne planification. La discipline consiste à l'attraper avant le déploiement.

Si vous préférez que quelqu'un construise ce pipeline de planification à implémentation de zéro, j'accepte des missions de consulting en architecture et workflow. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

La frontière floue entre builder et product manager

Voici quelque chose que je ne m'attendais pas à écrire il y a un an : le rôle de "développeur" et le rôle de "product manager" fusionnent.

Quand construire était le goulot d'étranglement, on avait besoin de personnes dédiées pour prendre les décisions produit (PMs) et de personnes dédiées pour exécuter ces décisions (ingénieurs). La division avait du sens parce que l'exécution était si chronophage que mélanger la réflexion produit aurait tout ralenti.

Maintenant que l'IA gère le gros de l'exécution, le builder qui ne peut pas prendre de décisions produit est... limité. Vous êtes rapide pour construire, certes. Mais rapide pour construire quoi ? Si vous avez besoin de quelqu'un d'autre pour vous dire ce qui vaut la peine d'être construit, vous fonctionnez à demi-capacité.

Les développeurs solo et les petites équipes les plus efficaces que je connais en 2026 ont internalisé les compétences de gestion de produit. Ils réfléchissent aux segments de clients, au positionnement concurrentiel, aux compromis de fonctionnalités et au timing du marché — non pas parce qu'ils ont lu un livre à ce sujet, mais parce que l'IA a supprimé l'excuse de ne pas y réfléchir. Quand on peut tout construire en un week-end, la défense "je suis trop occupé à coder pour penser à la stratégie produit" s'évapore.

C'est un avantage déloyal pour les builders qui développent cette discipline. Pendant que votre concurrent utilise l'IA pour livrer douze fonctionnalités par mois, vous utilisez l'IA pour en livrer trois — mais les trois que vous livrez sont celles qui comptent vraiment. Votre produit reste focalisé. Vos utilisateurs restent satisfaits. Votre codebase reste maintenable.

C'est ça la retenue. Et c'est ce qui sépare les produits que les gens aiment des produits que les gens tolèrent.

Ce que j'avais tort sur la vélocité

Je dois être honnête sur quelque chose. Les premiers mois après que Claude Code est devenu mon outil de développement principal, je suis tombé exactement dans le piège contre lequel je mets en garde.

La vitesse était enivrante. Je pensais à une fonctionnalité à 9h du matin et l'avais déployée avant le déjeuner. Ma production hebdomadaire avait triplé. Je mesurais ma productivité en fonctionnalités livrées, et ce nombre augmentait chaque semaine. Je me sentais incroyablement productif.

Puis j'ai regardé mes analytics. Le temps passé sur page de ma documentation avait baissé. Les taux d'activation des utilisateurs ne s'étaient pas améliorés malgré toutes les nouvelles fonctionnalités. Les tickets de support avaient augmenté — non pas parce que les choses étaient cassées, mais parce que les utilisateurs ne trouvaient pas ce dont ils avaient besoin dans une interface de plus en plus encombrée.

Je livrais plus et accomplissais moins. L'IA amplifiait ma production, mais ma production était non focalisée. La vitesse sans direction n'est que de la vibration.

La correction fut douloureuse. J'ai passé une semaine entière à ne rien faire d'autre que supprimer des fonctionnalités. Effacer du code qui marchait parfaitement. Simplifier des flux qui avaient trop d'étapes. Revenir à la version focalisée pour laquelle les utilisateurs s'étaient inscrits à l'origine.

Cette semaine de soustraction a produit de meilleures métriques d'engagement que le mois précédent d'addition. Et elle m'a appris quelque chose que j'aurais dû savoir depuis le début : la valeur d'un produit ne se mesure pas à ce qu'il peut faire. Elle se mesure à la qualité avec laquelle il fait la chose pour laquelle l'utilisateur est venu.

Un modèle pratique pour la conversation de pré-planification

J'ai promis un framework, donc voici le modèle réel que j'utilise pour la conversation de cadrage avant tout travail sur une fonctionnalité. Ce n'est pas un questionnaire rigide — c'est une structure de départ à partir de laquelle la conversation évolue.

Prompt d'ouverture à Claude (ou votre équipe) :

J'envisage d'ajouter [fonctionnalité] à [produit]. Avant de planifier ou construire quoi que ce soit,
je veux mettre cette décision à l'épreuve. Voici le contexte brut :

- Produit : [ce qu'il fait aujourd'hui]
- Client cible : [qui l'utilise]
- Idée de fonctionnalité : [ce qui est envisagé]
- Source de la demande : [feedback client / pression concurrentielle / idée interne]

Agis comme un stratège produit critique. Ton job est de m'aider à décider SI cela
devrait être construit, pas COMMENT. Pose-moi des questions dans ces domaines :

1. Problème central : Quel job cette fonctionnalité fait-elle pour l'utilisateur ?
2. Contexte client : Qui veut ça spécifiquement ? Sont-ils notre client cible ?
3. Solutions actuelles : Que font les utilisateurs aujourd'hui ? L'écart est-il assez douloureux ?
4. Réalité concurrentielle : Qui fait déjà ça bien ? Peut-on faire mieux ?
5. Risque de portée : Est-ce que ça étend la surface du produit d'une manière qui dilue l'identité ?
6. Alternative d'intégration : Pourrait-on résoudre ça par une intégration ?

Aie une vraie conversation. Pousse quand mon raisonnement est faible.

Ce que la sortie devrait contenir :

La colonne de décision est ce qui rend ceci différent d'un PRD traditionnel. La plupart des PRDs supposent que la fonctionnalité sera construite — le document existe pour décrire comment. Ce document part de l'hypothèse que la fonctionnalité pourrait ne pas être construite, et exige un argumentaire positif avant d'aller plus loin.

Où ça ne marche pas (et où ça marche)

Je serais malhonnête si je présentais ceci comme un framework sans faille. La retenue a aussi ses modes de défaillance.

Quand la retenue devient paralysie. Il existe une version de ceci où vous analysez chaque demande de fonctionnalité si minutieusement que rien n'est construit. La paralysie par analyse est réelle, et la conversation de cadrage peut l'alimenter si vous n'y faites pas attention. Le remède est le time-boxing : donnez à la conversation de pré-planification un maximum de 2-3 heures par fonctionnalité. Si vous ne pouvez pas prendre de décision dans cette fenêtre, le problème n'est pas la fonctionnalité — c'est une compréhension insuffisante du client. Allez parler aux utilisateurs à la place.

Quand vous devez explorer. Certaines fonctionnalités doivent être construites avant de savoir si elles sont bonnes. Le prototypage a de la valeur. Le framework que j'ai décrit fonctionne mieux pour les fonctionnalités de production qui seront déployées à de vrais utilisateurs. Pour les expériences internes et les prototypes, un processus plus léger est approprié. Construisez, testez avec un petit groupe, et prenez la décision de retenue en vous basant sur des données d'usage réelles plutôt que sur la seule pré-planification.

Quand le marché bouge vite. Dans des marchés véritablement compétitifs où la vitesse vers la parité de fonctionnalités détermine la survie, une retenue excessive peut vous coûter la partie. Le framework s'applique toujours, mais la conversation de cadrage devrait être plus courte et plus focalisée sur la nécessité concurrentielle que sur la vision produit idéale.

Où ça fonctionne de manière consistante : les produits avec un public défini, les produits qui ont passé la phase initiale de product-market fit, et les produits où la satisfaction utilisateur compte plus que les cases de fonctionnalités cochées. Cela décrit la majorité du SaaS B2B, la majorité des outils pour développeurs, et la majorité des produits grand public avec des modèles économiques basés sur la rétention.

Le mode de défaillance dont je me soucie le moins est que quelqu'un adopte trop de retenue. D'après mon expérience, l'attraction gravitationnelle vers la construction est si forte que tout framework qui impose une pause — même brève — produit de meilleurs résultats que le comportement par défaut.

L'avantage déloyal que personne ne vend

Il y a une raison pour laquelle personne ne parle de retenue sur tech Twitter. Ça ne se démo pas bien. "J'ai décidé de ne pas construire cette fonctionnalité" n'est pas un tweet qui génère de l'engagement. "J'ai livré un SaaS complet en 6 minutes" oui. La structure d'incitations de la conversation publique de notre industrie est biaisée vers la vitesse, la production et la capacité — pas le jugement, le focus ou la discipline.

Mais parlez aux fondateurs qui livrent depuis cinq ou dix ans. Ceux dont les produits ont encore des bases d'utilisateurs passionnés. Demandez-leur quelle a été leur décision produit la plus importante, et presque aucun ne pointera vers une fonctionnalité qu'ils ont construite. Ils pointeront vers une fonctionnalité qu'ils n'ont pas construite. Une direction qu'ils n'ont pas prise. Un moment où ils ont regardé ce qui était possible et ont choisi le focus plutôt que la capacité.

L'IA rend ce choix plus difficile que jamais. Quand on peut tout construire en un week-end, dire "non" ressemble à du gaspillage. On a l'impression de laisser de la valeur sur la table. Chaque fibre de votre instinct de builder crie de le livrer.

Les builders qui résistent à cet instinct — qui traitent la retenue comme une compétence à développer, pas un obstacle à surmonter — sont ceux qui construisent des produits qui durent.

Vos outils IA continueront d'aller plus vite. Les modèles continueront de devenir plus intelligents. Le coût d'exécution de n'importe quelle fonctionnalité continuera de tendre vers zéro. La seule chose qui ne changera pas est le coût de construire la mauvaise chose : des utilisateurs confus, des produits boursouflés, une charge de maintenance croissante, et une érosion lente du focus qui rendait votre produit digne d'être utilisé.

La prochaine fois que vous ouvrez Claude Code ou Cursor ou Codex avec une nouvelle idée de fonctionnalité, essayez quelque chose avant de taper le premier prompt. Fermez l'outil de codage. Ouvrez une conversation vierge. Et posez-vous la question à laquelle l'IA ne peut pas répondre pour vous :

Est-ce que ça devrait exister ?

Questions fréquemment posées

Qu'est-ce que la retenue en développement logiciel ?

La retenue est la discipline de décider quoi ne pas construire, même quand on a la capacité de le construire. En 2026, avec les outils IA qui rendent l'exécution quasi instantanée, la retenue signifie évaluer si une fonctionnalité renforce l'identité de votre produit et sert vos utilisateurs principaux avant de s'engager dans l'implémentation.

Comment fonctionne le mode planification dans Claude Code ?

Le mode planification de Claude Code s'active via Shift+Tab ou la commande /plan. Il passe l'IA en mode lecture seule où elle explore votre codebase, pose des questions de clarification et génère un plan d'implémentation sans écrire de fichiers. Pour un aperçu plus approfondi des workflows Claude Code, consultez mon guide crash course.

Qu'est-ce que le développement piloté par les spécifications ?

Le développement piloté par les spécifications traite la spécification — pas le code — comme la source de vérité. Vous écrivez d'abord une spec détaillée, et les outils IA génèrent, testent et valident le code par rapport à celle-ci. GitHub a publié un spec-kit open source pour soutenir ce workflow, et les outils majeurs comme Claude Code, Cursor et Codex ont tous adopté des patterns planification d'abord.

Comment empêcher le feature bloat quand l'IA rend la construction rapide ?

Utilisez une conversation de pré-planification avant tout travail de spec. Définissez les limites de portée explicitement — ce qui est dedans, ce qui est dehors, et pourquoi. Choisissez l'intégration plutôt que l'implémentation pour les fonctionnalités non essentielles. Et mesurez le succès du produit par les résultats utilisateurs, pas par le nombre de fonctionnalités.

Pourquoi l'IA ne peut-elle pas remplacer les décisions de stratégie produit ?

L'IA excelle dans l'exécution — générer du code, optimiser l'architecture, gérer les détails d'implémentation. Mais les décisions stratégiques produit nécessitent une compréhension du contexte client, du positionnement concurrentiel et des conséquences de second ordre que les modèles actuels ne peuvent pas évaluer de manière fiable. La question du si on devrait construire reste une responsabilité humaine.

Travaillons ensemble

Vous cherchez à construire des systèmes IA, automatiser des workflows ou faire évoluer votre infrastructure tech ? Je serais ravi de vous aider.

• Fiverr (builds personnalisés et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io