Le problème, c'est que tu peux tout construire.
Avant l'IA, ta roadmap était filtrée par une contrainte simple : le temps. Tu avais quarante idées et le budget pour trois. La contrainte choisissait à ta place. Elle choisissait souvent mal, mais elle choisissait.
Cette contrainte a sauté. Aujourd'hui tu décris une fonctionnalité le vendredi soir, elle tourne le samedi matin. Trois autres suivent dans le week-end.
C'est une excellente nouvelle. Et c'est un piège, parce que le garde-fou qui te protégeait de toi-même a disparu en même temps.
Construire une fonctionnalité est devenu quasi gratuit. La garder ne l'est pas.
Le vrai prix d'une feature, ce n'est pas de l'écrire
Une fonctionnalité, c'est comme un animal de compagnie. Le prix d'achat, c'est la partie facile. Ce qui coûte, ce sont les années à s'en occuper.
Chaque fonctionnalité que tu gardes dans ton produit :
- prend de la place à l'écran, et rend les autres plus difficiles à trouver
- s'ajoute à ce qu'il faut revérifier à chaque modification, même sur une partie qui n'a rien à voir
- s'ajoute à ce qu'il faut expliquer à chaque nouvel utilisateur
- s'ajoute à ce qui peut casser un dimanche soir
- s'ajoute à ce que ton prestataire doit comprendre avant d'oser toucher quoi que ce soit
Le temps passé à écrire une fonctionnalité représente une petite partie de ce qu'elle te coûtera sur sa vie. Le reste, c'est le support, les corrections, et le fait qu'elle complique tout ce qui l'entoure. J'ai détaillé cette facture dans le coût caché du vibe coding.
Et cette facture-là, l'IA ne l'a pas divisée.
Ce que l'IA a changé, et ce qu'elle n'a pas changé
| Avant l'IA | Avec l'IA | |
|---|---|---|
| Écrire la fonctionnalité | Lent et cher | Rapide et pas cher |
| La maintenir | Cher | Cher |
| L'expliquer à tes utilisateurs | Cher | Cher |
| Assumer qu'elle complique le produit | Cher | Cher |
| Décider si elle mérite d'exister | Gratuit | Gratuit |
L'IA a divisé une seule ligne de ce tableau.
Conséquence : le goulot d'étranglement a bougé. Il n'est plus dans tes mains, il est dans ta tête. La compétence rare aujourd'hui, ce n'est plus de savoir construire. C'est de savoir quoi construire, et surtout quoi ne pas construire.
Le piège : confondre vitesse et progrès
Tu as ajouté sept écrans ce week-end. La sensation est formidable. C'est la sensation d'avancer, pas la preuve d'avoir avancé.
Les symptômes sont toujours les mêmes :
- Ton menu a douze entrées et tu ne saurais pas dire laquelle sert vraiment.
- Ta page d'accueil liste huit arguments, donc aucun ne ressort.
- Ton onboarding s'allonge, parce qu'il y a de plus en plus à expliquer.
- Un bug dans un coin en réveille deux ailleurs. Chaque correction demande un peu plus de prudence, jusqu'à ce que même l'IA s'y perde.
- Tu n'as toujours pas de client qui paie, mais tu as un back-office complet.
Le dernier point est le plus fréquent, et le plus humain. Construire est confortable : tu contrôles, tu vois le résultat, personne ne te dit non. Parler à tes utilisateurs ne l'est pas. L'IA rend le confort encore plus accessible qu'avant.
Comment reconnaître la bonne feature
Trois tests. Ils prennent dix minutes et ils t'économisent des semaines.
1. Le test du "qui l'a demandée"
Ouvre un fichier, et à chaque demande note trois choses : qui, combien de fois, dans quel contexte.
Une idée qui te vient sous la douche n'a pas le même poids que trois clients qui décrivent le même blocage avec des mots différents. Si la ligne est vide, ce n'est pas leur besoin, c'est ton envie. Ce n'est pas interdit de construire son envie. Mais il faut être lucide sur la question.
2. Le test du pari écrit
Avant de lancer la construction, écris une phrase :
Si je construis X, alors Y va bouger de tant, sous tant de semaines.
Si tu ne sais pas quoi mettre dans Y, ou si tu n'as aucun moyen de le mesurer, tu ne construis pas une fonctionnalité. Tu construis une intuition. Note le pari quelque part, et reviens le lire un mois plus tard. C'est la manière la plus rapide d'apprendre à choisir.
3. Le test du retrait
Imagine que tu la supprimes lundi matin. Qui râle ?
Si la réponse est "personne, sauf moi", tu as ta réponse. Fais l'exercice sur ce que tu as déjà construit, pas seulement sur ce que tu envisages. C'est souvent douloureux, et c'est justement l'intérêt.
Utilise l'IA sur la bonne question
La vitesse de l'IA est une vraie force. Le tout est de l'utiliser au bon endroit.
Fais trois versions d'une fonctionnalité, pas une version de trois fonctionnalités. Construis le même parcours de trois façons différentes, montre-les à cinq utilisateurs, jette-en deux. Le code est devenu bon marché : sers-t'en pour jeter, pas pour accumuler.
Teste la porte avant de construire la pièce. Ajoute l'entrée dans ton menu, mets une page qui dit "bientôt disponible", compte les clics pendant deux semaines. Vingt minutes de travail au lieu de trois semaines, et tu sais si la demande existe vraiment.
Sers-toi de l'IA sur ce qui n'est pas du code. Donne-lui tes échanges de support, tes retours utilisateurs, tes appels retranscrits, et demande-lui ce qui revient le plus souvent. C'est là que se cache la bonne fonctionnalité, pas dans ta liste d'idées.
Et garde ça en tête si tu travailles avec des agents : un agent amplifie ce que tu lui demandes. Si tu lui demandes la mauvaise chose, il la fera très bien, et très vite.
Supprime aussi vite que tu ajoutes
Une fois par mois, regarde ce que personne n'utilise, et enlève-le.
"Et si quelqu'un s'en sert ?" Cache la fonctionnalité avant de la supprimer. Si personne ne se plaint en deux semaines, la question est réglée. Si quelqu'un se plaint, tu viens d'apprendre quelque chose d'utile pour presque rien.
Un produit se construit autant par ce que tu retires que par ce que tu ajoutes. C'est vrai côté produit, et c'est vrai côté technique : la meilleure architecture est celle qui fait exactement ce dont tu as besoin, pas celle qui impressionne.
Le seul cas où empiler a du sens
Soyons honnêtes : il existe un moment où produire beaucoup et vite est la bonne stratégie.
C'est le tout début, quand tu ne sais pas encore ce que veulent tes utilisateurs. Là, multiplier les tentatives est une façon de chercher, et l'IA est un formidable accélérateur pour ça.
Mais il y a deux conditions. Tu jettes ce qui ne prend pas. Et tu regardes vraiment les chiffres, pas juste la sensation.
Explorer, ce n'est pas accumuler. La différence entre les deux, c'est ce que tu acceptes de supprimer.
À retenir
- L'IA a rendu la construction quasi gratuite. La maintenance, le support et la complexité coûtent toujours autant.
- Le goulot d'étranglement est passé de "savoir faire" à "savoir quoi faire".
- Trois tests avant de construire : qui l'a demandée, le pari écrit, le retrait.
- Supprime au moins autant que tu ajoutes.
La question n'est plus "est-ce que je peux le construire ?". La réponse est oui, presque toujours. La question est devenue : "est-ce que ça mérite d'exister dans mon produit ?"
Tu veux avancer vite sans t'éparpiller ?
C'est la moitié de mon travail : construire vite avec l'IA, et dire non aux fonctionnalités qui vont te coûter cher pour rien. Si tu cherches quelqu'un pour construire ou reprendre ton produit, découvre mon offre de développement sur mesure.
Ton app a déjà grossi dans tous les sens et tu ne sais plus quoi garder ? Réserve un audit : en 3 jours, tu sais ce qui est solide, ce qui est risqué, et quoi corriger en premier.
Et pour recevoir ce genre d'articles, inscris-toi à la newsletter. Pas de spam, juste ce qu'il faut savoir.
