Prodantix

Prodantix est fait pour les gens qui construisent des logiciels. Toute équipe produit se pose les mêmes trois questions : que font vraiment les gens dans notre application, qui devrait avoir accès à quelle partie, et quel est le bon moment pour leur dire quelque chose.

La plupart des entreprises achètent un outil différent pour chacune de ces tâches, et c’est là que les ennuis commencent. Chaque outil conserve sa propre fiche séparée de vos utilisateurs, et ces fiches s’écartent peu à peu. L’un pense qu’une cliente a fini de configurer son compte. L’autre n’a pas suivi et lui envoie les instructions d’une étape qu’elle a terminée la semaine dernière. Personne ne s’en aperçoit avant qu’elle ne se plaigne, ou avant que deux tableaux de bord n’affichent des chiffres différents.

Comment le moteur est construit

Quatre primitives composent le moteur, et tout le reste est bâti dessus. Mieux vaut les prendre dans l’ordre, car chacune alimente la suivante. La référence des concepts les traite en détail.

Événement

Une seule chose qu’un utilisateur a faite, saisie au moment où elle se produit : une inscription terminée, une page ouverte, un formulaire abandonné à mi-parcours. Les événements sont le signal brut, et la seule chose qui entre dans le système depuis l’extérieur. Tout le reste en découle.

État utilisateur

Une projection vivante et interrogeable de tout ce que l’on sait d’un utilisateur, dérivée de ses événements et mise à jour dès qu’un nouveau arrive. C’est la source de vérité que lisent l’analytique, les feature flags et la messagerie. Ce n’est pas un agrégat nocturne, ni une copie qu’un traitement maintient alignée. Il n’y en a qu’une.

Décision

Une règle évaluée sur l’état utilisateur : qui appartient à une cohorte, qui reçoit un flag, qui remplit les conditions d’un message. Comme une décision lit l’état vivant au moment où on la pose, elle ne peut pas répondre à partir d’une image périmée.

Action

Ce que fait le moteur quand une décision se déclenche : exposer une fonctionnalité, envoyer un message, lancer un workflow. L’action est elle-même enregistrée comme un événement, et c’est ce qui referme la boucle : ce que le moteur a fait devient une partie de ce qu’il sait.

L’analytique, c’est lire l’état

L’analytique dans Prodantix n’est pas un entrepôt à part qui garderait sa propre copie de vos utilisateurs. C’est la lecture directe de l’état utilisateur. Entonnoirs, rétention et cohortes sont des requêtes sur la même projection vivante sur laquelle agit le reste du moteur : pas d’aller-retour SQL vers un entrepôt, pas d’attente d’un agrégat nocturne, l’état est déjà taillé pour la question. Les cohortes sont ici des objets de premier ordre : nommées, définies par des clauses, avec une appartenance tenue à jour à mesure que les gens deviennent éligibles ou cessent de l’être.

Montrer des choses différentes à des personnes différentes

Les équipes veulent souvent proposer une nouveauté à une poignée d’utilisateurs d’abord, pour voir ce que cela donne avant que tout le monde y ait droit. Prodantix décide qui voit quoi en évaluant des conditions sur l’état utilisateur : un attribut, un opérateur et une valeur, vérifiés au moment où le flag est interrogé plutôt que cherchés dans une liste stockée. Vous pouvez donner une nouvelle fonction à deux pour cent des clients, observer comment ils s’en servent, puis l’élargir ou la retirer sans attendre une autre mise en production.

Des messages qui arrivent tant qu’ils servent encore

Un message ne vaut la peine d’être envoyé que tant qu’il aide encore. Prodantix peut l’envoyer à l’instant où une personne fait quelque chose, ou ne le fait pas. Si un client atteint la limite de sa formule, il l’apprend sur le moment, et non le lendemain matin, alors qu’il a déjà renoncé et est parti ailleurs.

L’orchestration IA, et comment la boucle se referme

Les surfaces ci-dessus vous laissent encore câbler les étapes : remarquer quelque chose, déterminer à qui cela s’applique, décider quoi en faire. Prodantix peut exécuter cette boucle lui-même. Le moteur détecte le moment décisif dans l’état vivant, sélectionne la cohorte concernée et choisit l’action. Ce qui dépasse la simple automatisation, c’est la dernière partie : l’action est enregistrée comme un événement et se replie donc dans l’état utilisateur que lira la décision suivante. Le comportement du système devient une partie de ce qu’il sait de la personne, au lieu d’être quelque chose qui lui est arrivé de côté.

Faire entrer les événements

Tout commence par un événement envoyé au point d’entrée d’ingestion, que le moteur intègre aussitôt à l’état utilisateur. Les SDK couvrent le web, le mobile et le serveur. React est la seule exception : son cycle de vie exige un adaptateur dédié, un provider et un hook qui installent le client une seule fois et résistent au StrictMode. Le guide de démarrage le branche en quelques lignes.

Clés et environnements

Chaque appel SDK porte une clé de projet, obtenue depuis la console. Créer un projet produit deux environnements, live et test, chacun avec sa clé : vous développez avec la clé de test et livrez avec la clé live. Les deux clés ne s’affichent qu’une seule fois, juste après la création, car le serveur ne conserve qu’une empreinte et aucun écran ne peut les réafficher. La rotation émet un remplacement pour l’environnement choisi, et vous décidez si l’ancienne clé cesse aussitôt ou après un délai de grâce.

Quatre façons de lui parler

REST s’étend sur trois hôtes, un pour les flags et la messagerie, un pour l’ingestion d’événements et un pour le rejeu de session, chacun servant son propre document OpenAPI à /openapi.json. L’ingestion répond 202, ce qui signifie que l’événement a été accepté pour traitement et non stocké : un événement mal formé peut encore être écarté plus loin dans la chaîne. GraphQL couvre tout le modèle applicatif, y compris les projets, les flags, les workflows, l’analytique, la messagerie, les cohortes et la facturation. La surface temps réel diffuse les changements de flags, les messages et les exécutions de workflow, et coupe immédiatement les connexions non authentifiées. La surface MCP permet aux agents de lire et d’écrire via des appels d’outils : elle est de machine à machine et refuse les requêtes de navigateur.

Les données restent les vôtres

Vous pouvez faire tourner Prodantix sur nos serveurs ou sur les vôtres, cela fonctionne pareil. Tout ce que vous y mettez, vous pouvez le ressortir intégralement, quand vous voulez. Nous ne vendons pas vos données et nous ne les utilisons pas pour entraîner des modèles d’IA. Par construction, Prodantix finit par détenir le dossier le plus complet que vous ayez sur vos clients, où que ce soit : cette promesse pèse donc plus lourd ici qu’ailleurs.

À qui cela s’adresse

Prodantix convient aux équipes qui font tourner deux ou trois outils séparés pour cela et en ont assez de les voir se contredire. Il devient vraiment utile quand vous avez assez de clients pour ne plus pouvoir suivre ce qu’ils font en demandant autour de vous.

Visiter Prodantix: prodantix.com