Le piège de la dérive des fonctionnalités : comment dire non à des idées qui semblent bonnes mais ne le sont pas

Vous avez livré une appli. Des utilisateurs sont venus. Et maintenant votre boîte de réception déborde de demandes de fonctionnalités qui ressemblent toutes à de bonnes idées.

« On peut ajouter l’export vers Excel ? » Raisonnable. « On peut envoyer les factures automatiquement ? » Logique. « On peut s’intégrer à Stripe ? » C’est là qu’est le vrai argent. « Vous pouvez ajouter une appli mobile ? » Tout le monde le demande. « On peut le proposer en marque blanche pour nos propres clients ? » Oh, voilà un modèle économique.

Chaque demande, prise isolément, paraît intelligente. Ensemble, elles donnent l’impression que vous construisez cinq produits différents.

C’est la dérive des fonctionnalités, et elle tue plus de petites applis créées avec l’IA que les problèmes techniques ne le feront jamais. Pas parce que vous construisez les fonctionnalités — mais parce que vous épuisez votre temps, votre argent ou votre santé mentale à essayer de le faire.

Comment la dérive des fonctionnalités tue une appli qui marche

Voici ce qui se passe. Vous dites oui aux trois premières demandes parce qu’elles semblent raisonnables. Vous demandez à votre créateur d’applis avec IA de les ajouter. Ça prend deux semaines au lieu d’une parce que chaque nouvelle fonctionnalité se heurte au code existant. Vous avez maintenant une appli qui fait cinq choses, et en fait trois bien et deux correctement.

Puis arrive la quatrième demande : « On peut avoir différents niveaux de permission ? » Soudain, vous devez repenser qui peut voir quoi sur chaque écran. Ce n’est pas une fonctionnalité ; c’est un changement d’architecture. Vous demandez à votre créateur d’applis avec IA de le faire. Ça touche à tout. Deux semaines deviennent trois. L’appli ralentit parce que vous avez ajouté de la logique à chaque vue.

À la huitième demande, vous avez arrêté de livrer du neuf à vos utilisateurs d’origine parce que vous êtes trop occupé à faire tourner la machine à demandes de fonctionnalités. Les gens qui adoraient l’appli il y a trois mois sont frustrés parce que rien de ce qu’ils ont demandé n’est terminé. Les gens qui font de nouvelles demandes sont frustrés parce que les fonctionnalités mettent une éternité à arriver.

Vous avez créé quelque chose qui marche. Vous l’avez cassé en essayant d’être tout.

Le cadre de décision

Il vous faut un filtre. Chaque demande de fonctionnalité passe par trois questions :

Question 1 : est-ce que ça a sa place dans cette appli, ou est-ce une autre appli ?

Votre première appli fait une seule chose vraiment bien. Une appli de planification planifie des choses. Une appli de facturation facture. Ce sont des applis différentes. Si quelqu’un demande à votre appli de planification de facturer, vous n’ajoutez pas une fonctionnalité — vous demandez à une appli de planification de faire de la comptabilité. C’est un autre produit.

Un bon test : « Si je prenais cette fonctionnalité et que je la livrais toute seule, est-ce que les gens voudraient l’acheter ? » Si oui, elle a probablement sa place dans une autre appli. Si la réponse est « non, ça n’a de sens qu’en tant qu’élément du tout plus grand », alors vous êtes dans le bon périmètre.

Vous recevrez des demandes du type « intègre-toi à notre CRM ». Ce que ça veut vraiment dire, c’est « sois ton propre CRM ». C’est une autre appli. Vous pouvez vous intégrer à un CRM plus tard. Vous ne pouvez pas ajouter l’équivalent d’un CRM en fonctionnalités sans devenir un CRM.

Question 2 : est-ce que ça résout un problème pour la plupart de vos utilisateurs, ou juste pour celui-ci ?

Un client adore votre appli et a une idée de fonctionnalité. C’est un vrai problème qu’il a. C’est aussi un vrai problème que lui seul a.

Si vous avez vingt utilisateurs et qu’un seul demande quelque chose, vérifiez : les dix-neuf autres attendent-ils ça aussi, ou cette personne vient-elle simplement d’y penser ? Vous pouvez leur demander directement : « Avant vous, avez-vous pensé à demander à quelqu’un d’autre s’il en a besoin ? » En général, la réponse est non.

C’est la question dangereuse, parce que l’unique client qui demande est peut-être votre client le plus important. Vous avez peut-être besoin de le garder satisfait. C’est une décision business, pas une décision produit. Mais allez-y en pleine conscience : si vous construisez quelque chose pour un seul client, vous ne faites pas grandir votre appli, vous montez une activité de conseil.

Question 3 : combien ça coûte et quel est le coût pour l’idée d’origine ?

Tout coûte quelque chose. L’export vers Excel vous coûte du temps d’ingénierie. Il coûte de la complexité à votre appli. Il coûte de la concentration. Construisez ça plutôt qu’une optimisation de performance dont vos utilisateurs se plaignent tous les jours, et vous avez fait un choix.

Demandez-vous concrètement : « Si je construis ça, qu’est-ce que je ne construis pas ? » Si la réponse est « rien, on a un temps infini », vous n’êtes pas honnête. On ne l’a pas. Le temps est fini.

Le coût pour l’idée d’origine est souvent invisible. Quand vous êtes plongé dans les demandes de fonctionnalités, vous arrêtez d’entretenir l’élément central que les gens adoraient chez vous. Le cœur ralentit. Le cœur devient plus bogué. Le cœur paraît négligé. Et au bout du compte, les gens partent parce que l’appli qui marchait à merveille marche désormais correctement et fait des choses pour lesquelles elle n’a jamais été conçue.

Un exemple concret : le formulaire d’accueil

Quelqu’un a créé un simple formulaire d’accueil pour ses clients. Les clients le remplissent, le coach le relit, et ils planifient un rendez-vous. C’est ça, l’appli.

Demande un : « Je peux marquer les dossiers urgents ? » Oui, c’est une variante du flux principal. À construire.

Demande deux : « Je peux exporter les dossiers vers Excel pour mes archives ? » C’est une fonctionnalité de document. Ce n’est pas le rôle de l’appli. Les dossiers vivent dans l’appli. S’ils ont besoin d’Excel, ils peuvent copier-coller. Mais bon, l’export peut faire sens comme commodité. À construire.

Demande trois : « Les dossiers peuvent-ils créer automatiquement des événements de calendrier ? » Là, vous faites de la planification. L’appli était faite pour l’accueil, pas pour la planification. Si quelqu’un veut les deux, il veut probablement un vrai système de planification, pas un bricolage qui en colle un par-dessus. Déclinez poliment.

Demande quatre : « Les coachs peuvent-ils envoyer des relances par SMS ? » Là, vous êtes un système de communication. Non.

À la troisième demande, vous avez atteint la frontière. L’appli, c’est l’accueil. Tout le reste est une autre appli. Vous pouvez vous intégrer à ces applis plus tard. Vous ne pouvez pas les ajouter sans devenir ces applis.

Comment dire non

Le plus dur, c’est de le dire pour de bon. Vous ne voulez pas frustrer vos utilisateurs.

Soyez honnête : « C’est une excellente idée, mais c’est un produit différent de ce qu’on construit ici. Ce qu’on construit, c’est [votre unique mission]. Si on essaie de faire de la planification, de la facturation ou du CRM, on sera corrects partout et excellents nulle part. »

Souvent, le client comprendra. Il a demandé parce que l’idée lui est venue, pas parce qu’il vous teste.

Parfois, il insistera. « Mais j’ai besoin des deux. » C’est là que vous recommandez : utilisez la vraie appli de planification. Utilisez la vraie appli de facturation. Utilisez le vrai CRM. Puis utilisez cette appli pour ce qu’elle fait bien. C’est la réponse honnête.

La tentation d’être tout

Le plus dur, quand on construit un petit produit, c’est de dire non. Non, ça donne l’impression de laisser de l’argent sur la table. Et si ce client avait vraiment payé pour les deux ? Et si cette fonctionnalité vous avait rendu dix fois plus gros ?

Peut-être. Mais vous n’êtes pas un produit dix fois plus gros si vous ne le livrez pas. Vous êtes un produit à moitié fini qui fait cinq choses mal. Les gens qui adoraient le cœur sont frustrés. Les gens qui voulaient les nouvelles fonctionnalités sont frustrés. Et vous vous êtes peint dans un coin où ajouter quoi que ce soit de neuf signifie d’abord refactoriser cinq anciennes choses.

Les produits qui grandissent sont ceux qui font une seule chose vraiment bien, puis ajoutent avec précaution. Ils n’essaient pas d’être Salesforce dès le premier jour. Ce sont l’appli vers laquelle vous vous tournez quand vous avez besoin de faire cette chose précise, et l’appli en qui vous avez confiance pour être rapide et fiable quand vous le faites.

Dites non. Protégez le cœur. Faites ça, et vous construirez quelque chose que les gens ont vraiment envie d’utiliser.