Pourquoi Notis peut sembler « buggé » et « trop cher » (et ce qui se passe vraiment)

Il m’a fallu plus de temps que je ne voudrais l’admettre pour entendre les retours de résiliation sans les traduire immédiatement par « on est en train d’échouer ». Quand quelqu’un résilie en disant « trop cher » ou « buggé », le réflexe, c’est de filer droit vers des ajustements de prix et une chasse aux bugs.

Mais après suffisamment de conversations, des schémas apparaissent. Ces deux raisons sont réelles, mais elles servent souvent de raccourcis. La plupart du temps, ce sont les symptômes d’un problème de cadrage et d’un problème d’attentes.

Les deux raisons de résiliation qui reviennent sans cesse

En résumé : les gens résilient Notis pour deux « raisons », et elles sont toutes les deux souvent mal comprises.

La première, c’est le prix. Les utilisateurs comparent le coût à des abonnements SaaS subventionnés au lieu de le comparer au retour sur investissement, ou à ce qu’ils paieraient pour un assistant de direction.

La seconde, c’est « buggé ». Les utilisateurs disent que c’est buggé quand ils demandent des capacités non prises en charge, utilisent les mauvais paramètres, n’ont pas accordé les permissions ou donnent des instructions floues. Quand ils voient des refus ou des hallucinations, ils les interprètent comme de l’instabilité.

Quand « buggé » veut surtout dire « les attentes ne correspondent pas à la réalité »

Les produits d’IA ont un problème d’UX redoutable : l’interface, c’est le langage, et le langage fait croire que le système comprend tout ce qu’on est capable de décrire.

Alors quand Notis ne livre pas exactement ce que quelqu’un avait imaginé, l’étiquette la plus facile, c’est « buggé ». Parfois, c’est un vrai problème produit. Souvent, c’est un décalage entre ce que l’utilisateur attend et ce que le système est réellement configuré pour faire.

« Buggé », c’est souvent ce qu’on dit quand les limites n’ont jamais été rendues explicites.

Les causes cachées : capacités, permissions, paramètres, clarté

Il existe toute une catégorie d’échecs qui ressemblent à de l’instabilité vus de l’extérieur, mais qui ne sont en réalité que des contraintes qui font leur travail.

Si on demande à l’assistant quelque chose qu’il ne sait pas faire, soit il refuse, soit il essaie de deviner. S’il n’a pas les bonnes permissions, il ne peut pas lire ou écrire là où tu l’attends. Si les paramètres sont mauvais, il peut se comporter d’une manière qui paraît incohérente. Et si la consigne est floue, le résultat le sera aussi.

Rien de tout ça n’est une faute de l’utilisateur. C’est simplement ce qui arrive quand un système qui s’exprime avec aisance a malgré tout des limites strictes.

Le changement de regard qui change tout

J’ai commencé à voir Notis moins comme de la « magie » et plus comme une interface vers des systèmes et des contraintes.

Quand tu le traites comme un coéquipier, déléguer devient une compétence. Quand tu le traites comme un génie de la lampe, chaque cas particulier devient une déception.

Quand « trop cher » veut surtout dire « mauvaise base de comparaison »

Les plaintes sur le prix ne vivent jamais dans le vide. Elles vivent dans une comparaison mentale.

Si la comparaison, c’est « un abonnement SaaS de plus », alors n’importe quel prix un peu significatif peut paraître élevé. Si la comparaison, c’est « ce que ça remplace », le même chiffre peut paraître évident.

Dès que le cadre passe des abonnements aux résultats, la conversation change aussi.

Raisonner en retour sur investissement plutôt qu’en abonnement

Le cadre le plus sain, c’est la valeur créée.

Si un outil produit de façon fiable des résultats significatifs, réduit ta dette de relances et garde ton système organisé sans que tu fasses le travail manuel, alors la bonne question n’est pas « est-ce moins cher que les autres applis ? ». C’est « est-ce que ça vaut le coup au regard de ce que ça rapporte ? ».

La version simple que j’utilise : payer 150 si ça crée de façon fiable 1 500 de valeur. Pas parce que je veux que tout le monde parle en tableurs, mais parce que ça évite que la conversation devienne émotionnelle.

Le cadre de l’assistant est plus honnête que celui du SaaS

L’autre comparaison qui compte, c’est un assistant de direction, ou des heures de prestataire.

Notis n’est pas un Dashboard passif. Il est conçu pour prendre des entrées brouillonnes et les transformer en travail structuré. Ça, c’est du travail. Quand tu l’ancres dans le travail, les gens ont tendance à l’évaluer d’une manière qui correspond à ce qu’ils en attendent vraiment.

Ce que je change dans notre façon de poser les attentes

La pire version d’un produit d’IA, c’est celle qui se vend comme si elle n’avait aucune limite.

Je préfère gagner plus lentement et garder la confiance que gagner vite et générer du churn. Le bon réflexe n’est donc pas de sous-vendre. C’est d’être explicite sur les limites et de rendre les « modes de réussite » évidents.

Ça veut dire traiter l’onboarding comme un apprentissage de la délégation.

Ça veut dire faire comprendre que « non pris en charge » n’est pas un bug, et qu’un refus est souvent un garde-fou, pas un plantage.

Ça veut dire rappeler que la clarté n’est pas seulement une question de bonne communication. En IA, la clarté est une fonctionnalité.

Le produit, ce n’est pas seulement des fonctionnalités. C’est le modèle mental que les gens emportent avec eux pendant leur première semaine.

Ce que j’aurais aimé intégrer plus tôt

Si quelqu’un dit « buggé », ne te contente pas de chasser les défauts. Demande-lui ce qu’il attendait, ce qu’il a essayé et ce qu’il croyait que le produit savait faire.

Si quelqu’un dit « trop cher », ne te contente pas de défendre le prix. Demande-lui à quoi il l’a comparé, quel résultat il espérait et à quoi aurait ressemblé un produit qui « vaut le coup ».

La plupart des retours de résiliation ont de la valeur. L’erreur, c’est de prendre les mots au pied de la lettre.

Si tu évalues Notis, voici comment y réfléchir

Si tu veux un outil d’IA qui ressemble à une version moins chère d’une centaine d’abonnements SaaS, tu seras probablement déçu.

Si tu veux un assistant à qui déléguer, dont le but est de transformer des entrées du monde réel en travail structuré et en suivi, tu l’évalueras sur le bon axe.

Et s’il te paraît un jour « buggé », la première chose que je vérifierais, ce n’est pas ta patience. C’est la configuration, les permissions, la clarté de la consigne et le fait que la tâche entre bien dans le périmètre.

C’est toute la différence entre « l’IA n’est pas fiable » et « l’IA est un système auquel tu peux vraiment faire confiance ».