L’importance de supprimer les éléments inutiles

• Un produit devenu trop complexe peut davantage s’améliorer en supprimant les éléments inutiles qu’en ajoutant des explications, et le cas du calculateur de prix de Pinecone l’illustre bien
• Le calculateur de prix devait permettre d’estimer à l’avance les coûts basés sur l’usage, mais une simple erreur de saisie pouvait gonfler le coût estimé jusqu’à 1 000 fois et empêcher l’inscription
• En interne, on a tenté de corriger le problème en ajoutant des explications et des valeurs par défaut, mais ces modifications ont créé d’autres confusions, au point d’accumuler plus de 550 messages dans un canal Slack dédié
• Lors d’un test A/B où le calculateur a été retiré, les visiteurs non exposés avaient 16 % de chances supplémentaires de s’inscrire, 90 % de chances supplémentaires de prendre contact, sans hausse des tickets de support liés au prix
• Comme un élément ajouté une fois a tendance à rester même quand sa valeur diminue, il faut examiner consciemment la décision de retirer de gros blocs dans les produits, les projets et les processus

---

Le cas de la suppression du calculateur de prix de Pinecone

• Avec sa tarification basée sur l’usage, Pinecone avait placé un calculateur de coût sur sa page tarifaire, car il est difficile pour les utilisateurs de connaître précisément leur coût réel à l’avance
• Après avoir échangé avec des utilisateurs potentiels, l’entreprise a constaté que certains renonçaient à s’inscrire après avoir vu dans le calculateur des coûts estimés très élevés
  • Ces cas d’usage étaient pourtant relativement modestes selon les critères de Pinecone
  • Le calculateur était bien plus déroutant et sensible que prévu
  • Une petite incompréhension ou une mauvaise saisie pouvait suffire à surestimer le coût jusqu’à 1 000 fois
• Le calculateur donnait aux utilisateurs une fausse impression de certitude, et ceux-ci prenaient sa valeur comme un coût réel sans vérifier la documentation, sans contacter l’équipe ni valider par un usage direct
• En réaction rapide, l’équipe a ajouté des explications, des clauses de non-responsabilité, des détails et des valeurs par défaut, mais chaque tentative pour réduire une confusion en créait une autre
• Les discussions internes ont aussi pris de l’ampleur, avec plus de 550 messages accumulés dans un canal Slack dédié, sans compter le temps passé en réunions et en rédaction de documents
• Une personne a bien demandé : « Le calculateur est-il vraiment nécessaire ? », mais la question a d’abord été noyée dans l’avis majoritaire
• Un test A/B a ensuite été lancé pour vérifier si la suppression du calculateur — et des problèmes qu’il entraînait — faisait réellement disparaître de la valeur
  • Les visiteurs qui ne voyaient pas le calculateur avaient 16 % de chances en plus de s’inscrire par rapport à ceux qui le voyaient
  • La probabilité de prise de contact était 90 % plus élevée
  • Il n’y a pas eu d’augmentation des tickets de support liés au prix
• Dans un sondage interne, 7 personnes sur 10 pensaient que la version avec calculateur serait meilleure, mais les résultats du test ont montré l’inverse

Pourquoi il est difficile de supprimer

• Dans beaucoup d’organisations, face à un problème, on pense d’abord à ajouter plutôt qu’à retirer
  • Même quand la suppression peut apporter un gain important, elle s’impose rarement comme choix intuitif
  • L’article cite à ce sujet l’étude People systematically overlook subtractive changes
• Les systèmes de récompense valorisent eux aussi en général l’ajout de quelque chose, alors que la suppression est rarement incitée
  • Comme exemple du fait que la suppression devrait aussi être récompensée, l’article mentionne Negative 2000 Lines Of Code
• Quand quelqu’un a fortement défendu l’ajout d’un élément, il peut lui être difficile d’admettre que celui-ci n’apporte pas de valeur
• Quand on veut supprimer un élément que quelqu’un d’autre avait poussé à ajouter, cela peut donner l’impression d’attaquer son jugement ou son travail, ce qui favorise le statu quo
• On suppose souvent que ce qui existe déjà a une bonne raison d’exister, et on ne le réévalue pas
• À mesure qu’on s’habitue à l’état actuel, on devient réticent au changement lui-même avant même d’avoir réellement envisagé la suppression
• Une simplification qui coupe franchement les éléments non essentiels peut améliorer les taux de réponse des clients, rendre les systèmes plus fiables et accélérer la croissance comme les revenus
• Au-delà de petits ajustements, il faut parfois choisir de retirer de gros blocs dans les projets, les produits et les processus, et plus une suppression suscite une forte résistance dans l’équipe, plus elle peut cacher un gain important

[GN⁺]

Avis sur Hacker News

• Je ne sais pas si ce calculateur était bon ou mauvais, mais le raisonnement paraît assez absurde à première vue
  Si on cache aux utilisateurs que le coût du produit peut être élevé, il est normal que les inscriptions augmentent. Savoir s’ils s’en sortent réellement mieux dépend de la réception ultérieure d’une facture décevante, et ça, on ne peut pas le savoir avec un court test A/B sur une page d’inscription
  On voit aussi souvent des cas du type : on retire des informations de l’extrait dans les résultats de recherche, et le taux de clic augmente. Forcément, si l’information qui était dans l’extrait nécessite désormais un clic pour être vue, les clics augmentent, mais on oublie alors quelle option est réellement meilleure

  • Le problème de ce calculateur, c’est que si l’utilisateur entrait des données légèrement erronées ou comprenait mal la signification de certains indicateurs, il obtenait un devis 1000 fois supérieur au prix réel
    Le dilemme était donc : « comment corriger ce cas ? », et la solution a été : « supprimons ce calculateur bancal ». Il ne s’agissait pas de cacher un coût 1000 fois supérieur, mais d’éviter de perdre des utilisateurs à cause d’un devis erroné 1000 fois trop élevé
  • Il est aussi dommage de ne pas reconnaître la possibilité d’un dark pattern. Beaucoup d’entreprises savent qu’en retirant les informations tarifaires, elles font progresser les prospects plus loin dans le funnel, et qu’à cause du temps déjà investi, ceux-ci finissent par acheter même s’ils auraient préféré choisir un concurrent
    Les concessionnaires automobiles qui compliquent la consultation des prix en ligne pour pousser à l’e-mail ou à la visite en sont un exemple. Les calculateurs facilitent la comparaison des offres, et beaucoup d’entreprises n’aiment pas ça. Que ce soit conscient ou non, c’est une motivation à prendre en compte
  • C’est quasiment un angle mort à l’échelle de tout un secteur, et ça déborde largement de la tech pour toucher le design industriel et l’ingénierie produit en général
    Plus on est transparent avec l’utilisateur, plus cela risque de créer de la confusion. La raison est que les critères de comparaison eux-mêmes traitent l’utilisateur comme du bétail stupide qu’on peut mener à l’abattoir. Dans cette logique, toute fonctionnalité qui traite l’utilisateur comme une personne capable de réflexion crée de la confusion et nuit au taux de conversion
  • C’est tout à fait vrai. Dans mon équipe, des fanatiques des tests A/B ont fortement réduit les marges de la page de prix pour faire remonter le bouton d’inscription au-dessus de la ligne de flottaison, puis ont pris l’augmentation des clics sur ce bouton comme preuve du succès de l’expérience
    Bien sûr, la page de prix est devenue hideuse, mais ce n’était plus grave parce que « les inscriptions augmentent ». Dans ce cas, le calculateur pouvait certes être intimidant pour des personnes peu familières avec les termes, mais la décision intuitive de départ aurait dû être : « comment le simplifier ? ». Je n’aime pas cette culture du test A/B où tout doit être analysé et prouvé statistiquement
  • Est-ce qu’on ne peut pas considérer que c’était simplement la fonction d’un calculateur excessivement simplifié et souvent faux ?
    Si l’utilisateur ne reste même pas au départ, comment tester ensuite s’il est satisfait ou non ? Si on boucle la boucle et qu’on augmente l’engagement, on augmente aussi les chances de bien former le client et de le satisfaire lors des interactions ultérieures

• J’ai voté pour partager la grande sagesse du texte, mais la frontière peut vite devenir floue
  Cette manière de penser — « si on enlève cette partie, est-ce qu’on perd quelque chose de précieux ? » — s’est parfois retournée contre moi sur des projets au début de leur vie, surtout parce qu’il est difficile d’estimer la valeur future du code et des données
  Une fois, sur un nouveau projet, j’ai créé un schéma SQL initial avec des colonnes de métadonnées supplémentaires pour les tags de publication, mais la semaine suivante un ingénieur senior a tout supprimé au nom du principe YAGNI. Techniquement, il avait raison puisque ce n’était pas sur la roadmap, mais le travail initial avait pris environ une heure et le coût de conservation des données était quasiment nul
  Un an plus tard, la personne qui a finalement développé la fonctionnalité nécessitant ces colonnes, c’était moi, et j’ai dû refaire le même travail en y ajoutant cette fois une migration de base de données en production avec des utilisateurs. Il faut donc aussi se demander à l’inverse : « si on enlève cette partie, est-ce que cela fera naître quelque chose de précieux ? ». Dans cet article, la réponse était évidente ; dans mon cas, non

  • Je comprends cette situation, mais même si le produit en a eu besoin plus tard, la décision de suppression prise par le senior à l’époque pouvait quand même être la bonne
    Il me semble que SpaceX a un indicateur qui capture une idée voisine : le taux de réintroduction de la deuxième fonctionnalité supprimée. Si toutes les fonctionnalités retirées sont finalement réintroduites, on a un taux de récidive des fonctionnalités de 100 %, ce qui signifie qu’on coupe trop souvent ; 70 %, c’est élevé, et 30 % aussi
    Mais 0 % est mauvais aussi. Si on n’essaie pas suffisamment d’éliminer les fonctionnalités inutiles, on finit forcément par gonfler le produit. Au début de la vie d’un produit, ce taux peut être plus élevé, puis, à mesure qu’il mûrit, il vaut mieux qu’il redescende à un taux faible mais non nul
    Comme on ne peut pas connaître à l’avance l’ensemble exact des fonctionnalités nécessaires au meilleur produit possible à un instant donné, on peut adopter une approche probabiliste pour tailler dans l’inutile. Si besoin, on les remettra plus tard, et tant que cela n’arrive pas trop souvent, il n’y a pas lieu de remettre en cause la décision initiale de suppression
    Ou bien, au lieu d’essayer les deux options dans le monde réel et d’en observer le résultat, on peut aussi passer six mois en réunion à discuter d’hypothèses et de croyances implicites impossibles à formuler clairement
  • Le principal problème quand on ajoute quelque chose « au cas où » cela serait utile plus tard, c’est que les gens partent, oublient, et qu’un an après il existe bien une colonne de métadonnées mais plus personne ne sait à quoi elle sert
    On se demande alors : « on peut l’utiliser ? on peut la supprimer ? », et quelqu’un finit par penser à Knight Capital, où la réutilisation d’un ancien champ avait provoqué un énorme incident. Du coup, laisser les anciens champs en place paraît toujours plus sûr, et on se retrouve avec metadata puis metadata_1. L’année suivante, plus personne ne sait pourquoi il y a deux champs de métadonnées, et c’est encore plus confus
  • Dans la plupart des cas, anticiper les besoins produit des choses inutiles. Et même quand cela devient réellement nécessaire, ce qu’il faut est généralement d’une forme très différente
    Les pires codebases que j’ai connues avaient été conçues en pensant à des usages futurs complexes. Même dans cet exemple, il a fallu attendre un an avant que la colonne soit nécessaire. Donc, à mon avis, il est juste d’établir comme précédent qu’on supprime tout morceau de code qui anticipe un besoin futur. Même s’il redevient nécessaire ensuite
  • Il est facile de basculer vers l’excès dans un sens ou dans l’autre, en faisant trop ou pas assez de travail défensif et spéculatif
    Pour certains, ce sera de l’optimisation prématurée ; pour d’autres, ce sera : « j’ai déjà vu un schéma similaire auparavant et je vais ajouter ce que j’aurais aimé avoir à l’époque ». Il ne semble pas exister de moyen fiable de distinguer de façon stable quel côté a raison
  • Aurais-tu écrit ce commentaire si ce champ n’avait jamais été réajouté ?
    Dans la situation que tu décris, il y a grosso modo trois issues. Premièrement, le champ devient utile exactement sous la forme initialement implémentée. Deuxièmement, la fonctionnalité est bien développée, mais avec un autre champ ou une autre implémentation. Troisièmement, la fonctionnalité n’est jamais développée
    Même si on donne la même probabilité aux trois possibilités, le fait de l’avoir construit dès le départ n’est gagnant que dans un tiers des cas. Il faut aussi se demander quel coût cognitif cela aurait impliqué pendant tout ce temps de vérifier que les autres fonctionnalités développées entre-temps fonctionnaient correctement avec cette colonne de métadonnées
    Cette fois, ton jugement était juste et ta compréhension du projet excellente, mais la qualité de la décision doit se juger à partir des informations disponibles au moment où elle a été prise, pas avec toutes les informations connues après coup

• Le passage « lors d’un vote interne à l’entreprise, 7 personnes sur 10 pensaient que la version avec calculatrice serait meilleure » est intéressant et reflète une dynamique très classique.
  L’article était globalement bon, mais ce point aurait mérité d’être davantage souligné. Si 30 % des personnes concernées voyaient la calculatrice d’un mauvais œil, c’est le signe d’un problème potentiellement important, même si la majorité la juge acceptable.
  Il faut faire attention à la politique interne. Les gens n’aiment généralement pas critiquer le travail d’une autre équipe s’ils n’y gagnent rien politiquement. Donc si on demande à l’entreprise « est-ce que ce que notre équipe a construit a un effet net positif ? », la réponse par défaut a facilement tendance à être « oui », simplement parce que personne ne veut créer de tensions inutiles.
  Dans ce contexte, si 30 % des gens ont signalé un risque potentiel de destruction de valeur, c’est bien plus important qu’il n’y paraît. Il faut examiner très sérieusement pourquoi ils le voyaient ainsi. Dans ce cas précis, ils avaient effectivement conscience de ce point et l’histoire s’est bien terminée, mais le résultat de ce vote constituait dès le départ la preuve d’un problème sérieux.

  • Je suis d’accord sur le principe, mais il est difficile de savoir comment quantifier le caractère controversé d’un changement. Aucune fonctionnalité n’obtient 100 % de consensus. 30 %, ce n’est pas très bon, mais est-ce vraiment significativement différent de 20 % ?
    C’est encore plus compliqué quand les intérêts divergent. Les ventes veulent activer toutes sortes de dark patterns, tandis que le support client peut en avoir assez de traiter des remboursements parce qu’une extension de garantie est ajoutée automatiquement au panier.
    Le passage affirmant que retirer la calculatrice peut être meilleur pour l’utilisateur parce que cela permet de conclure plus de ventes m’a fait rire. Peut-être qu’en réalité, le bon choix pour l’utilisateur était justement de partir après avoir reçu un choc de prix approprié, mais cette possibilité est complètement ignorée.
  • Un autre problème des votes internes, c’est qu’ils introduisent la perspective de ceux qui construisent la fonctionnalité, et non celle de ceux qui l’utilisent.
    Il suffit d’imaginer que le code de la calculatrice soit un désastre comparé au reste du projet, qu’il utilise des bibliothèques obsolètes, qu’il casse à chaque mise à jour, qu’il ait des failles de sécurité, qu’il consomme anormalement beaucoup de ressources ou qu’il ruine le système de build. Personne n’a envie de gérer ça.
    Dans cette situation, si on demande si c’est une bonne idée, la plupart répondront « non » et voudront se débarrasser de ce bazar. Dans ce cas, 70 % est un excellent score. À l’inverse, si c’est une fonctionnalité sur laquelle les gens aiment travailler, alors 70 % devient un très mauvais score.
  • Le texte dit seulement que ces 30 % n’étaient pas convaincus que la version avec calculatrice « fonctionnerait mieux » ; il ne dit pas qu’ils pensaient que c’était une « mauvaise idée ».
    C’est possible, bien sûr, mais c’est un raccourci assez important. Ils pouvaient aussi penser que cela ne ferait pas vraiment de différence, ou supposer que les performances seraient moins bonnes parce que la calculatrice donne parfois de mauvaises réponses.

• Le message général est intéressant, mais cette partie fait un peu tiquer.
  Quand on lit « au moindre malentendu ou à la moindre erreur de saisie, l’estimation peut être gonflée jusqu’à 1 000 fois », est-ce que cela veut dire qu’en usage réel, il suffit de mal comprendre ou mal évaluer un indicateur pour se retrouver à payer un coût 1 000 fois supérieur à ce qui était prévu ?
  Dans les systèmes de facturation en ligne, c’est tout à fait crédible. Il m’est arrivé de mal configurer un prototype GCP en pensant que cela coûterait 2 ou 3 dollars, puis, après ne pas y avoir prêté attention pendant quelques jours, de recevoir une facture de plus de 100 dollars.
  Quand on voit le prix prévu s’envoler de manière délirante en ne bougeant qu’un peu un curseur, on comprend aussi que des clients partent. Supprimer l’outil aidera peut-être à l’inscription, mais pas les clients qui se heurteront ensuite à ce genre de problème.

  • En pratique, c’est peu probable. Les deux cas réels mentionnés montrent pourquoi.
    Un utilisateur pensait que le nombre de requêtes par seconde se calculait comme le nombre de recherches multiplié par le top-k de chaque recherche. Le top-k est le nombre de résultats qu’on veut récupérer. Si le top-k vaut 10, il saisit alors une valeur 10 fois trop élevée pour les requêtes par seconde et voit une estimation environ 10 fois supérieure à la facture réelle.
    Un autre utilisateur pensait que le nombre de vecteurs se calculait comme le nombre d’embeddings multiplié par le nombre de dimensions de chaque embedding. 1 536 étant une dimension fréquente, la valeur saisie s’est retrouvée littéralement 1 536 fois trop élevée. L’usage réel est correctement calculé par Pinecone, donc la facturation ne sera pas aussi élevée.
    La dimension d’un vecteur est une notion de base pour un ingénieur IA, et le QPS est un indicateur de base pour un administrateur de base de données, mais Pinecone compte beaucoup d’utilisateurs pour qui l’IA est nouvelle, l’administration de base de données est nouvelle, ou les deux.

• L’auteur devrait appliquer son propre conseil. Il devrait retirer le « Psst... Get the next post in your inbox » qui s’intercale au milieu de l’article, ainsi que ce bouton idiot qui vous suit pendant le scroll.
  J’ai compté pas moins de cinq façons de s’abonner sur cette seule page. Est-ce qu’il en faut vraiment cinq ? Est-ce nécessaire de les agiter devant le visage du lecteur en plein milieu du contenu ? Pense-t-on vraiment qu’interrompre les gens et les agacer fera augmenter le nombre d’abonnés ? Et est-ce vraiment ce type d’abonnés qu’on veut ?
  Supprimer quelque chose est généralement assez clair. Il suffit de sortir de cette logique de trou sans fond du « toujours plus, toujours plus, faire de l’argent, attirer le client », et de se demander ce qui est juste si l’on veut respecter l’utilisateur, comment l’aider en le traitant comme un être humain plutôt que comme une cible dont il faut vider le portefeuille.

  • Je suis d’accord, mais les données ne disent pas cela. Ces éléments pénibles contribuent très bien aux objectifs business.
    Il faut garder à l’esprit que la plupart des entreprises existent pour gagner de l’argent, pas pour offrir une expérience agréable aux lecteurs de HN.
  • Si l’on a bien compris la leçon de l’optimisation SEO des blogs, alors, quand on cherche à élargir son lectorat, il vaut manifestement la peine de multiplier les appels à l’action qui accaparent l’attention des lecteurs, même si cela agace les lecteurs les plus exigeants.
    La question de savoir ce qu’implique le respect de l’utilisateur est différente, même si elle n’est pas totalement sans rapport.

• Le fait qu’un canal Slack dédié ait été créé, que plus de 550 messages y aient accumulé des avis venus de toute l’entreprise, et que des dizaines d’heures de réunion ainsi que des milliers de mots aient été consacrés à discuter de ce qu’il faudrait encore ajouter pour réparer la calculatrice, c’est un symptôme de surrecrutement.
  Quand il y a trop de monde, l’initiative disparaît. Si l’on oublie ce qui compte vraiment et qu’on a l’impression de devoir obtenir un consensus de comité, c’est qu’il y a trop de monde.

  • Peut-être, mais cela peut aussi être un symptôme de bikeshedding, même avec seulement deux personnes.
  • Je ne vois pas comment on peut conclure à partir de cette seule phrase que l’entreprise a trop d’employés.
  • Au minimum, c’est ce qui arrive quand on mène une discussion de design dans un canal ouvert à toute l’entreprise.
    Le design par comité reste alors au moins contenu à l’intérieur du comité.

• Ne vaudrait-il pas mieux supprimer directement la structure tarifaire elle-même, si elle est à ce point complexe que les clients ne peuvent pas la modéliser utilement ?

  • D’après le texte, le principal problème n’était pas tant le grand nombre d’options que le fait que les utilisateurs les comprenaient mal.
    Autrement dit, si l’option A coûte x dollars et l’option B 10x dollars, et que la plupart des utilisateurs pensent par erreur qu’ils ont besoin de B, alors la calculatrice devient un outil qui favorise les malentendus.
    J’aime assez le modèle « tarifs sur demande ». C’est agaçant pour l’utilisateur qui veut juste connaître rapidement un ordre de grandeur, mais c’est utile pour identifier les cas où un tarif négociable ne se prête ni à un prix standard ni à une explication simple en ligne. Cela permet aussi de récupérer des utilisateurs qui seraient simplement passés à autre chose. Bien sûr, ce n’est pas adapté à la plupart des cas, comme l’e-commerce.

• Notre entreprise compte environ 250 produits, et 5 d’entre eux génèrent 80 % du chiffre d’affaires
  Les équipes de développement de ces 5 produits peinent déjà à suivre les corrections de bugs, et ont du mal à ajouter des fonctionnalités importantes et nouvelles. Peu importe qui en fait la demande, ajouter quoi que ce soit à la roadmap est en soi une bataille impossible
  L’entreprise emploie des milliers de développeurs, mais la plupart travaillent sur des produits qui ne contribuent presque pas au chiffre d’affaires
  Pour avancer, il semblerait évident qu’il faudrait couper la plupart des produits et réorganiser les équipes pour pousser les produits principaux générateurs de revenus restants. Pourtant, cela ne s’est pas produit, et il n’y a ni signe ni rumeur que cela arrive. La politique interne de l’entreprise est vraiment brutale

• J’ai vécu une expérience similaire. Sur un site web avec plusieurs produits qui semblaient assez proches, on craignait que les gens aient du mal à décider quoi acheter et qu’ils n’achètent donc rien
  Nous avons donc créé une applet de recommandation de produit qui recommandait un ou deux produits les plus adaptés après que l’utilisateur avait répondu à quelques questions. Il a fallu un peu de travail pour bien la faire, mais une fois terminée, elle fonctionnait bien
  Après l’avoir mise en ligne sur le site, le taux de conversion s’est effondré. Un test A/B a confirmé qu’elle nuisait clairement à la conversion. On ne sait toujours pas pourquoi, mais c’était bien le cas. Nous l’avons donc déplacée de la page d’accueil vers la section FAQ, et presque plus personne ne l’a utilisée

  • C’est toute la valeur des tests. Les résultats ne sont parfois pas intuitifs
  • Peut-être que l’applet de recommandation aidait réellement les gens, au point de leur faire décider, sur la base des informations supplémentaires nouvellement fournies, que le mieux était de ne pas acheter
    Les gens étaient peut-être indécis, et cela leur évitait l’effort de tester eux-mêmes différentes options pour comprendre
    S’il s’agissait d’un service, une stratégie à la Amazon Prime — faire s’inscrire les gens malgré leur manque de certitude, puis exploiter le biais des coûts irrécupérables par la suite — fonctionnait peut-être mieux. Ou alors, sans l’applet, ils se seraient inscrits en espérant que la version la moins chère leur suffirait, et l’applet brisait immédiatement cet espoir
    S’il s’agissait d’un produit physique, elle les aidait peut-être simplement à éviter un mauvais achat
    Je ne m’attendrais pas à le chercher dans la FAQ. Dans le footer, peut-être, mais pas dans la FAQ

• C’est une étude de cas intéressante, mais je reste sceptique sur les implications plus larges. Pinecone est connue pour être chère par rapport aux autres services de base de données vectorielle. Si l’on compare les prix à prestations équivalentes, il existe plusieurs meilleures options sur le marché
  Supprimer le calculateur ne résout pas le problème de fond. Cela ne fait que brouiller les coûts et rendre plus difficile pour les utilisateurs de comparer les options dès le départ. De mon point de vue, cela risque de réduire l’étape de comparaison et d’amener davantage d’utilisateurs mal informés à téléverser leurs données sans bien comprendre l’impact tarifaire
  La simplification peut avoir de la valeur, mais dans ce cas elle semble plus bénéfique pour l’entreprise que pour les utilisateurs. Au lieu de supprimer complètement le calculateur, il aurait peut-être mieux valu en améliorer la précision et l’ergonomie. En particulier pour les services B2B où les coûts peuvent augmenter rapidement, la transparence tarifaire est importante