Les contraintes sont le produit : ce que construire Notis sur WhatsApp m’a appris sur l’IA, les coûts et la roadmap

J’ai appris à mes dépens que les meilleurs produits IA ne naissent pas de roadmaps parfaites. Ils naissent de contraintes impossibles à ignorer, de comportements utilisateurs impossibles à simuler, et de la volonté de livrer une architecture « moche » si elle te permet d’obtenir un vrai signal plus vite.

Pourquoi Notis a démarré sur WhatsApp (et pourquoi je le referais)

Quand les gens entendent « assistant IA sur WhatsApp intégré à Notion », ils pensent généralement à un gadget. Ce n’en est pas un. WhatsApp te donne trois avantages injustes, étrangement alignés sur la façon dont les humains utilisent vraiment un assistant.

D’abord, tu hérites de la résilience. Les problèmes de connexion, la livraison des messages, la gestion des médias : tout ça est réglé au niveau de la plateforme. Ensuite, tu hérites de la psychologie. Les gens sont déjà habitués à accepter des réponses asynchrones dans une messagerie, donc le produit peut prendre quelques secondes (ou plus) pour réfléchir sans déclencher le réflexe « c’est cassé ». Enfin, les médias sont natifs. Images, vidéos, documents arrivent comme des citoyens de première classe, ce qui compte si ton assistant est censé capturer la réalité, pas seulement du texte.

Évidemment, ça vient avec des contraintes.

WhatsApp limite les messages à 1 600 caractères. Il n’y a pas d’indicateur de saisie. Et si tu passes par Twilio, tu empiles encore d’autres limitations. Mais ces contraintes ont fini par façonner Notis en quelque chose que j’aime bien : concis, structuré, et orienté vers le travail fait dans Notion plutôt que vers l’inondation d’un chat.

L’architecture : désordonnée exprès, parce qu’apprendre coûte cher

Beaucoup de fondateurs essaient de « nettoyer » l’architecture trop tôt. J’ai fait l’inverse. J’ai optimisé pour la vitesse d’itération, l’observabilité et la capacité à changer de modèle sans réécrire le produit chaque semaine.

Aujourd’hui, le système tient essentiellement en trois couches.

L’identification, puis le « cortex préfrontal », puis un agent

Le flux commence par l’identification : qui parle, quel espace de travail, quelles permissions, quel contexte il faut récupérer.

Ensuite, je fais tourner ce que j’appelle un « cortex préfrontal ». C’est la partie qui décide quoi faire : écrire dans Notion, interroger une base de données, poser une question de clarification, résumer, programmer un rappel, ou simplement accuser réception et ne rien faire. Cette couche tournait avant sur des modèles plus lourds, et je l’ai récemment passée sur gpt-5.2, parce que c’est le meilleur compromis que j’ai trouvé entre coût et fiabilité pour ce type de routage.

Enfin, des sous-agents exécutent le plan. C’est là que vivent les choses coûteuses : requêtes Notion, logique de notification, synchronisation de bases de données, conversion de blocs, et tout ce qui touche le monde extérieur.

Pourquoi le serverless + un backend Python s’est révélé être le bon découpage

La première étape de traitement tourne en serverless sur Pipedream, parce que ça rend les intégrations et la plomberie d’événements ridiculement rapides. Mais les « vraies » opérations tournent sur un serveur Python, parce que les parties coûteuses demandent plus de contrôle : traitement par lots, cache, limites de débit et performances plus prévisibles.

Supabase sert de backend en dessous, et les documents sont vectorisés et stockés chez OpenAI pour que l’assistant puisse récupérer du contexte sans transformer chaque interaction en scan complet de la base. Il y a aussi quelques briques Node.js qui n’existent que pour une raison : convertir les blocs Notion vers et depuis le markdown sans perdre la structure.

Ce n’est pas élégant. C’est productif.

La réalité de l’économie unitaire : oui, une seule requête peut coûter plus de 1 $.

Tout le monde adore parler d’« IA à grande échelle » jusqu’au moment de regarder la facture.

Une seule requête utilisateur peut coûter plus de 1 $. Certains flux sur des modèles de raisonnement plus lourds ont atteint 5 $ par requête. Et ce n’est pas seulement le modèle de chat. La facture est un empilement : vectorisation, stockage, speech-to-text, text-to-speech, et toute la colle qui rend l’expérience fluide.

Cette pression sur les coûts impose un principe de conception : l’assistant doit faire moins de choses, mais à plus fort effet de levier. Notis ne doit pas être un jouet qui discute sans fin. Il doit être un système qui capture, organise et exécute à l’intérieur de tes outils.

Tests de prix : ce que m’apprend le test A/B

Je fais actuellement tourner un test A/B sur les prix.

Dans une version, c’est 20 $/mois et une offre à vie à 200 $.

Dans l’autre, c’est découpé par capacité : 10 $/mois pour la synchronisation dans un sens et 20 $/mois pour la synchronisation bidirectionnelle.

Les premiers résultats m’ont surpris. La variante la plus chère a mieux converti sur les premiers échantillons : 3,18 % contre 1,49 %. Ça ne veut pas dire que « le prix le plus élevé gagne toujours ». En général, ça veut dire que le cadrage est plus clair, que la valeur paraît plus sérieuse, ou que la segmentation crée du doute.

L’idée, c’est que le prix fait partie du produit. Si l’utilisateur ne relie pas instantanément le coût au résultat, il n’achète pas. Et s’il achète le mauvais forfait, tu le sentiras plus tard dans la rétention, le support et la marge.

Roadmap : trois axes, un seul état d’esprit produit

Quand je pense à la suite, je ne pense pas en fonctionnalités. Je pense en axes. Ça garde le produit cohérent au lieu d’en faire une checklist aléatoire.

Axe 1 : les connexions aux plateformes

Notion est la première intégration profonde. Mais l’avenir n’est pas « Notion uniquement ». Il est multi-maisons : Notion, Obsidian, et tout ce que les gens utilisent pour faire tourner leur travail.

C’est là que l’architecture devient une décision stratégique. Si tu veux gérer plusieurs plateformes, tu dois construire un cœur qui n’est pas marié aux bizarreries d’une seule API.

Axe 2 : les canaux de communication

WhatsApp fonctionne. Mais ce n’est pas le seul endroit où les gens veulent un assistant. Signal, des expériences à la iMessage, peut-être même des flux pensés d’abord pour la voix. Chaque canal apporte ses propres contraintes, et ces contraintes changeront ce que devient le produit.

Axe 3 : l’expansion verticale

Une fois que tu sais capturer et organiser le travail de façon fiable, l’étape suivante, c’est d’agir sur le monde.

La verticale la plus évidente, c’est la gestion d’agenda.

Planifier des réunions. Réserver un restaurant. Gérer des réservations. Coordonner des Zoom. Le but n’est pas de devenir une « app d’agenda ». C’est de devenir la couche qui transforme une intention en résultat.

Concurrence, rentabilité, et pourquoi je n’optimise pas pour le confort

Si tu construis sur Notion, tu dois accepter l’ombre de Notion AI. Ils peuvent livrer des fonctionnalités qui se ressemblent. Ils peuvent les inclure dans leur offre. Ils peuvent casser les prix.

Mon pari, c’est que Notis gagne en étant plus proche du vrai workflow de l’utilisateur. Capture d’abord par messagerie, relances proactives, contexte multi-outils, et volonté de s’intégrer en profondeur plutôt que de vivre dans une barre latérale.

Je ne prétends pas non plus que la rentabilité soit l’objectif immédiat. Au début, le travail consiste à trouver le product-market fit et à apprendre assez vite pour que la future architecture et le futur business model deviennent évidents. Ironiquement, une mauvaise rétention peut même « aider » quand tu apprends, parce qu’elle empêche les coûts d’exploser avant que le produit soit vraiment prêt.

Mais cette phase se termine. Si Notis devient quelque chose sur lequel les gens comptent chaque jour, l’architecture devra évoluer, la courbe des coûts devra s’infléchir, et le recrutement deviendra un vrai levier. Je suis de plus en plus convaincu que les profils généralistes sont le moyen le plus rapide de passer ce cap : des gens qui savent livrer, débugger, parler aux utilisateurs et affûter le produit sans se cacher derrière des process.

La vraie leçon : les contraintes sont le produit

Avec le recul, la plus grande leçon ne concerne ni les modèles ni les outils. C’est que les contraintes imposent la clarté.

La limite de caractères de WhatsApp impose la concision. Le coût par requête impose l’effet de levier. L’ambition multiplateforme impose la modularité. Et les utilisateurs imposent l’honnêteté.

Si je continue à suivre les contraintes au lieu de les combattre, Notis s’améliore, et je prends moins de décisions au feeling et plus de décisions fondées sur la réalité.