Le développement logiciel n’a jamais été aussi rapide qu’aujourd’hui. Nous pouvons livrer en un après-midi une fonctionnalité qui nécessitait auparavant un sprint entier.
Mais cette rapidité engendre un nouveau problème : elle tue les produits. L’ancien goulot d’étranglement était l’exécution. Nous ne pouvions pas développer assez vite, et cette pénurie nous obligeait à établir des priorités. Cette contrainte a désormais disparu.
Sans elle, les développeurs livrent tout ce qu’ils peuvent au lieu de tout ce qu’ils devraient. Il existe une compétence qui distingue les développeurs et les équipes qui livrent d’excellents produits de ceux qui se noient sous les fonctionnalités. Ce n’est pas une compétence technique. L’IA ne peut pas le faire à votre place. La plupart des développeurs ne la mettent pas en pratique.
La compétence de la retenue
Même si le développement basé sur les spécifications est devenu une norme industrielle en 2026, cette compétence reste cruciale. Aujourd’hui, réfléchissons en quoi consiste cette compétence et pourquoi elle est plus importante que jamais. Je vais vous donner un cadre concret, comprenant à la fois la réflexion stratégique et les outils tactiques pour commencer à la mettre en pratique immédiatement.
Avant l’ia, notre flux de travail consistait à consacrer environ 20 % de notre temps à la planification et 80 % à la construction. Aujourd’hui, c’est l’inverse. La véritable évolution ne réside pas seulement dans le fait que la planification prend plus de temps, mais aussi dans le fait que l’objectif de notre planification a changé.
Il ne s’agit plus de savoir comment nous construisons cela. Ce qui importe, c’est de savoir si nous devons vraiment le développer.
C’est une question à laquelle l’IA ne peut pas répondre à notre place. La compétence qui se cache derrière cela a un nom : la retenue. La retenue consiste à privilégier la concentration plutôt que la capacité. C’est la discipline qui nous permet de dire : « Nous pourrions développer cela, mais cela n’a pas sa place ici. »
Le piège de la capacité
L’IA rend la construction si facile que nous cessons de nous demander si nous devrions le faire. Laissez-moi vous montrer à quoi cela ressemble dans la pratique. Imaginons que vous développiez un outil de portail client. Il est épuré, ciblé, et vos clients l’adorent. Les agences l’utilisent pour partager des livrables et obtenir des validations.
Puis, des entreprises potentielles viennent frapper à votre porte. Elles veulent des fonctionnalités de facturation, de suivi du temps et de gestion de projet. Chacune de ces fonctionnalités peut être développée en un week-end grâce à l’IA. Vous développez donc la fonctionnalité de facturation pour conclure ces contrats.
Mais l’intégration devient alors plus lourde. Les tickets d’assistance commencent à passer de « comment partager un fichier » à « pourquoi ma facture ne se synchronise pas avec QuickBooks ». Vous commencez à attirer des clients qui vous ont choisi pour la facturation et non pour le portail.
Un chef de produit avisé ferait preuve de retenue à ce stade. Cela signifie refuser d’intégrer la facturation en tant que fonctionnalité. Proposez plutôt une intégration épurée ou une compétence d’agent préconfigurée. Vous répondez au besoin sans l’absorber, et l’identité de votre produit reste intacte.
Outils spécialisés plutôt que monolithes
La retenue est tout aussi importante lorsque vous développez vos propres outils pour votre propre activité. Peut-être même davantage, car rien ne vous empêche de surdévelopper. Mon entreprise repose sur la production de contenu, qui comporte de nombreux éléments mobiles.
Je pourrais créer une application monstrueuse capable de couvrir tous ces besoins. Cela peut sembler efficace, mais en réalité, c’est un cauchemar à maintenir. C’est fragile. Chaque fois qu’un changement survient dans mon entreprise, l’application tombe en panne.
Ce qui est bien plus efficace, c’est de décomposer chaque sous-processus en un outil dédié. Chacun a une fonction, et certains ne sont même pas des applications. Il peut s’agir de compétences que les agents utilisent pour relier les éléments entre eux.
Considérez cela comme des outils spécialisés reliés par les compétences des agents, plutôt que comme un seul gros monolithe. Les agents travaillent bien mieux avec des systèmes ciblés.
- Vos outils sont plus faciles à créer
- plus faciles à maintenir
- et plus faciles à faire évoluer et à itérer.
La convergence des outils vers le mode Plan
En 2026, tous les principaux outils ont abouti à la même idée : planifier d’abord, puis construire. Claude Code, Cursor, et Codex ont tous intégré le mode Plan comme fonctionnalité centrale. Les interfaces diffèrent légèrement, mais le principe reste identique.
Cette convergence est le signe le plus clair que le développement piloté par les spécifications est devenu la norme dans le secteur. Selon la documentation officielle d’Anthropic, le mode Plan de Claude Code est un mode en lecture seule où l’IA analyse la base de code, pose des questions de clarification et génère un plan d’implémentation détaillé, sans pouvoir modifier de fichiers ni exécuter de commandes.
Comment activer le mode Plan
L’activation se fait par un raccourci clavier simple : appuyer deux fois sur Shift+Tab pour basculer en mode Plan. Cette même combinaison permet de revenir au mode standard. Selon les meilleures pratiques d’Anthropic, le workflow recommandé suit quatre phases :
- Explorer (mode Plan),
- Planifier (mode Plan),
- Implémenter (mode normal ou auto-accept),
- et Valider (mode normal).
Sur Opencode, il vous suffit d’appuyer sur Tab pour basculer entre les modes (Plan, etc. )
Ce workflow est directement issu de la documentation officielle et reflète la manière dont l’équipe de Claude Code utilise l’outil en interne. L’insight clé : les phases 1 et 2 (Explorer + Planifier) sont les moins coûteuses en termes de tokens et les plus précieuses en termes de résultat.
Cursor et son approche itérative
Cursor propose également un mode Plan accessible via le même raccourci Shift+Tab. Selon la documentation, ce mode crée des plans détaillés pour accomplir des tâches complexes. Il est idéal pour les fonctionnalités importantes qui nécessitent de nombreux changements à travers la base de données, le backend et le frontend.
Le mode Plan de Cursor lit les fichiers pertinents et pose des questions de clarification pour affiner exactement ce dont vous avez besoin, vous forçant à réfléchir aux détails avant d’écrire du code. Une fois terminé, il produit un fichier plan.md contenant une spécification avec vue d’ensemble, architecture, flux de données et changements prévus.
Codex et la commande /plan
Je mets à jour ou crée vos articles personnellement, assisté par l'IA, avec optimisation SEO incluse.
| 📝 Mise à jour | 14 € |
| ✨ Création | 49 € |
Du côté d’OpenAI, Codex propose une approche similaire avec la commande /plan ou le raccourci Shift+Tab. Selon les meilleures pratiques officielles, le mode Plan permet à Codex de rassembler le contexte, poser des questions de clarification et élaborer un plan plus solide avant l’implémentation.
Cette approche est particulièrement utile lorsque la tâche est complexe, ambiguë ou difficile à décrire. Vous pouvez également demander à Codex de vous interviewer d’abord, en lui demandant de remettre en question vos hypothèses et de transformer l’idée floue en quelque chose de concret avant d’écrire du code.
Un espace de travail visuel : Nimbalyst
La plupart des expériences en mode planification se déroulent dans un terminal ou une fenêtre de chat, mais Nimbalyst adopte une approche différente. Il s’agit d’un espace de travail visuel qui vous offre un moyen plus riche de planifier et de structurer votre travail.
Il intègre des éditeurs visuels, tels que des maquettes Markdown et des diagrammes. Vous pouvez esquisser un diagramme d’architecture et permettre immédiatement à vos agents de s’y référer pendant le développement. Tout est stocké au format Markdown sur votre système de fichiers local, sans aucun format propriétaire.
Nimbalyst supporte à la fois Claude Code (Anthropic) et Codex (OpenAI) comme agents de codage. Vous pouvez exécuter des sessions avec les deux agents côte à côte et utiliser le meilleur pour chaque tâche. L’outil propose aussi un système complet de gestion des tâches où vos agents peuvent créer des tâches, les modifier, les déplacer entre les statuts et les marquer comme terminées.
Ne négligez pas la réflexion stratégique
Nous savons que le mode planification est puissant, mais si nous passons directement au mode planification sans réfléchir d’abord à la stratégie, nous nous retrouvons avec une fonctionnalité magnifiquement planifiée qui n’est pas mise en pratique. Nos outils peuvent construire tout ce que nous leur demandons. La question est de savoir si cela vaut la peine de s’y atteler.
Avant d’ouvrir le mode planification dans n’importe quel outil, je mène une réflexion pour déterminer si je devrais réellement planifier cette fonctionnalité. C’est l’étape que la plupart des développeurs sautent, et c’est là que la retenue s’exerce réellement. Si vous travaillez seul, c’est vous et l’IA qui testez ensemble la viabilité de votre idée.
Dans une équipe, chaque personne effectue le même exercice de manière indépendante, puis vous vous réunissez pour comparer vos notes.
- Où vos points de vue convergent-ils ?
- Où divergent-ils ?
- C’est là que s’engage la véritable conversation stratégique.
Les frontières entre développeur et chef de produit s’estompent, et les meilleures équipes embrassent cette évolution.
Utilisez la dictée vocale pour capturer les idées
Je me rends sur Claude et j’ai une conversation pour façonner une idée brute. J’utilise un outil de dictée vocale pour décrire la fonctionnalité telle qu’elle me vient à l’esprit. Je me concentre sur qui est le client principal et quel est le problème central. Je décris la tâche à accomplire.
Si une solution existe déjà, je décris les lacunes et les raisons pour lesquelles les solutions actuelles ne sont pas à la hauteur. Je fournis le contexte en m’appuyant sur ce que me disent les clients. S’il s’agit d’un produit destiné au marché, j’utilise les propres mots des clients pour décrire leurs problèmes.
Nous demandons à l’IA d’agir en tant que partenaire stratégique, et non comme un simple acquiesceur. Je demande à l’IA de clarifier l’objectif, la vision et l’orientation. Mais je ne lui donne pas de liste spécifique de questions. Je laisse le LLM faire son travail et proposer des questions plus intelligentes et plus constructives que celles que je pourrais formuler moi-même.
- Je lui demande de remettre en question mes hypothèses.
- Nous savons que les LLM peuvent avoir tendance à la flagornerie, je lui demande donc d’être critique.
- Je veux qu’il m’aide à mettre en évidence les compromis que je pourrais négliger.
Le document de sortie structuré
Après quelques séries de questions, j’oriente la conversation vers le résultat dont j’ai besoin. Je lui demande de créer un document contenant :
| Élément | Description |
|---|---|
| Énoncé du problème | Un paragraphe concis sur exactement quel problème nous résolvons |
| Limites du périmètre | Ce qui est inclus et ce qui ne l’est pas |
| Décisions clés | Les choix effectués et les compromis associés |
| Flux utilisateur principaux | Comment l’utilisateur principal utilise ce produit, étape par étape |
Il vaut bien mieux réfléchir à l’expérience utilisateur avant de penser aux boutons et aux interfaces. Que voit l’utilisateur ? Que pense-t-il ? Mes conversations se terminent généralement par des documents au format Markdown que je fusionne.
Pour aller plus loin :
- OpenClaw : mon équipe d’agents IA autonomes sur Mac Mini
- Opencode : L’agent IA open source qui révolutionne le codage
Le jugement stratégique doit rester humain
Cette conversation de structuration est la compétence que l’IA ne peut pas remplacer. L’IA peut tester votre raisonnement, mettre en évidence les compromis et remettre en question vos hypothèses, mais elle ne peut pas décider ce que votre produit sera. Elle ne peut pas ressentir ce dont vos clients ont besoin.
Ce jugement stratégique nous incombe et c’est le travail le plus précieux que nous faisons aujourd’hui. Il s’agit de réflexion stratégique, de retenue, de connaître si bien votre client ou votre flux de travail que vous pouvez dire non à une bonne idée parce qu’elle n’est pas la bonne idée.
Savoir déployer la retenue n’est qu’une compétence parmi celles que nous devons maîtriser. Si nous voulons véritablement gagner un avantage concurrentiel en tant que développeurs en 2026, nous devons embrasser cette évolution où la frontière entre développeur et chef de produit s’estompe. Les meilleures équipes sont celles qui acceptent cette hybridation des rôles.
Qu’est-ce que le mode Plan dans Claude Code ?
Le mode Plan est un mode de fonctionnement en lecture seule où Claude peut analyser votre base de code, poser des questions de clarification et créer des plans d’implémentation détaillés sans modifier de fichiers ni exécuter de commandes. Il sépare la réflexion de l’action.
Comment activer le mode Plan ?
Appuyez deux fois sur Shift+Tab pour basculer en mode Plan. Vous pouvez également taper /plan dans l’invite, démarrer une session avec –permission-mode plan, ou configurer permissions.defaultMode dans settings.json.
Quand dois-je utiliser le mode Plan ?
Utilisez le mode Plan lorsque la tâche touche 3 fichiers ou plus, implique des décisions architecturales, ou lorsque vous ne pouvez pas décrire le changement de code exact en une phrase. Il est essentiel pour les refactoring complexes et les bases de code unfamiliar.
Le mode Plan ralentit-il le développement ?
Le mode Plan ajoute du temps en amont pour l’analyse, mais économise souvent du temps global en évitant les erreurs, en réduisant le débogage et en produisant de meilleures décisions architecturales. Le compromis favorise la planification lorsqu’on travaille sur du code complexe ou unfamiliar.
