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.

Enregistrer une question que vous reposerez

Un tableau de bord est un ensemble nommé de tuiles, et une tuile est une requête que vous avez déjà lancée, plus la façon dont vous voulez la dessiner. La requête est conservée exactement telle que l’explorateur l’a soumise : une tuile porte donc la question et non une image de sa réponse. En ouvrir une relance la requête et vous replace dans l’explorateur sur cette même requête, libre de déplacer la fenêtre ou de changer la ventilation. Un tableau de bord n’est donc jamais un export périmé. C’est un ensemble de questions auxquelles le moteur répond depuis l’état vivant à chaque fois que vous le regardez.

Quand un chiffre bouge tout seul

Personne ne surveille tous les graphiques. Prodantix se charge de la surveillance : il lit une série intervalle par intervalle, calcule la ligne de base et la dispersion de cette série, puis signale les intervalles qui s’en écartent trop, dans un sens comme dans l’autre. Une chute et un pic sont tous deux rapportés, chacun avec la ligne de base dont il s’est écarté et de combien, de sorte que vous distinguez une vraie rupture d’un bruit ordinaire. La sensibilité est un réglage et non une règle figée, et le détecteur refuse de deviner : une série presque plate, ou trop courte pour avoir encore une forme, ne produit rien du tout plutôt qu’une fausse alerte.

Les personnes dont parle l’état

L’état utilisateur est une projection, et l’annuaire des personnes est l’endroit où vous le lisez une personne à la fois. La console dresse la liste de tous ceux que le projet a vus, les plus récemment actifs en tête, avec un champ de recherche et une liste qui continue de se charger à mesure que vous avancez. Chaque ligne porte ce que le moteur a accumulé sur cette personne : combien d’événements, combien de sessions distinctes, quand elle a été vue pour la première et la dernière fois, ce qu’elle a fait en dernier, à quels groupes elle appartient, ainsi que les traits réservés (nom, e-mail, téléphone, avatar) sortis dans leurs propres colonnes. Ouvrir une ligne affiche toute la table des propriétés, qui contient ce que vos événements y ont mis et non un jeu de champs figé. Les groupes ont leur propre onglet et leurs propres propriétés, car une entreprise ou un espace de travail est une chose à part entière et ses faits lui appartiennent, non à chacun de ses membres.

Une personne, plusieurs identifiants

Un visiteur arrive avant que vous sachiez qui il est. Le SDK lui donne un identifiant, il lit trois pages, et c’est seulement ensuite qu’il s’inscrit. Tant que personne n’a dit au moteur qui il est, le profil n’a tout simplement pas de nom, et l’annuaire le dit au lieu de deviner. Quand l’inscription a lieu, les identifiants sont reliés en une chaîne qui aboutit à une seule identité canonique : la trace anonyme se replie dans le compte nommé au lieu d’ouvrir un second profil. Chaque ligne indique combien d’identifiants aboutissent à elle, et le profil les énumère. Là où le moteur ne peut pas trancher seul, vous pouvez joindre deux profils à la main : vous choisissez l’identité qui subsiste, ses propriétés l’emportent en cas de conflit, et les compteurs s’additionnent. Cela ne se défait plus. Le profil tel qu’il se lisait avant la fusion reste dans la piste d’audit, donc ce qu’il disait est récupérable, mais les deux personnes ne sont plus séparables une fois jointes.

Revoir une session

L’analytique vous dit que onze personnes ont abandonné le même formulaire hier. Elle ne vous dit pas pourquoi. La relecture de session enregistre la page elle-même : le SDK navigateur capte le document et chacune de ses modifications pendant que la personne travaille, regroupe ces modifications en fragments ordonnés et les envoie à l’enregistreur, puis la console rejoue la session telle qu’elle s’est déroulée. Chaque enregistrement est classé sous le même identifiant que celui qu’utilise le reste du moteur : une session appartient donc à une personne que vous pouvez déjà retrouver, et non à un identifiant de visiteur qui n’existe que dans un outil séparé.

Ce qu’un enregistrement a le droit de garder

Le masquage est actif avant même toute configuration. Chaque caractère saisi dans un champ est remplacé par une astérisque dans le navigateur, avant l’envoi du fragment : ce qui parvient à l’enregistreur n’a donc jamais contenu le texte. La longueur et les limites des mots subsistent, ce qui garde à la relecture l’allure de la page, et les mots eux-mêmes ont disparu. Les champs de mot de passe, d’adresse e-mail et de téléphone sont masqués que le masquage soit actif ou non : le désactiver ne peut pas exposer un champ d’identifiants. Le texte visible de la page est conservé, sauf si vous demandez à le masquer aussi. Chaque fragment note s’il a été masqué et la console marque la session en conséquence, si bien que vous savez toujours laquelle des deux vous regardez. Les enregistrements résident dans un stockage privé : la console demande un lien signé de courte durée pour un fragment à la fois, et rien n’est accessible sans lui. La durée pendant laquelle une session reste consultable ensuite dépend de votre forfait.

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.

Quand ils répondent

La messagerie va dans un seul sens jusqu’à ce que quelqu’un réponde, et c’est alors un fil de support. Prodantix porte ceux-là aussi, et l’IA qui s’y trouve rédige au lieu d’envoyer. On ne donne au modèle que le fil et l’état propre de cette personne, rien d’autre : pas la conversation d’un autre client, pas le reste de votre projet. Il écrit une réponse suggérée, et cette réponse ne devient un tour du fil que lorsque votre agent appuie sur envoyer, si bien que « suggérer, pas envoyer » est la façon dont le code est construit et non une règle à ne pas oublier. Le fil porte aussi ses propres identifiants. Une clé de projet identifie un projet et voyage dans chaque page qui installe le SDK : elle ne peut donc pas tenir lieu de personne. Chaque conversation reçoit son propre jeton, limité à ce seul fil, et l’identifiant présent dans un corps de requête ne décide jamais à qui vous parlez. Ouvrir une conversation est la seule route qui ne demande rien d’autre que la clé publique, elle est donc limitée en débit par projet et par appelant.

Câbler soi-même un enchaînement

Certaines réponses tiennent en plus d’une étape, et vous voulez les disposer vous-même. Un flux de travail est un petit graphe : il démarre manuellement, ou quand quelqu’un entre dans une cohorte ou en sort, puis il avance de nœud en nœud. Un nœud d’action fait quelque chose (écrire une ligne de journal, appeler l’un de vos webhooks). Un nœud de délai attend, jusqu’à trente jours. Un nœud d’attente reste en suspens jusqu’à l’arrivée d’un signal nommé, avec sa propre sortie si le signal ne vient jamais. Un nœud de branchement teste des conditions sur l’état utilisateur et prend le chemin correspondant, ou celui de repli. Les exécutions avancent d’un nœud à la fois, et chaque étape est validée avant que la suivante soit prise, si bien qu’un redémarrage repart d’où l’exécution était réellement arrivée au lieu de la rejouer depuis le début. Les webhooks sont vérifiés avant d’être appelés : la cible doit être une adresse https publique, la requête part vers les adresses que la vérification a approuvées, les redirections ne sont pas suivies, et un appel qui reste pendu est coupé.

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é.

Une proposition attend un humain

Le moteur n’agit pas sur sa propre conclusion. Ce qu’il produit est une proposition, et une proposition est un plan écrit : ces drapeaux, ces cohortes, ce message. Avant qu’elle puisse être approuvée, chaque drapeau, cohorte et conversation qu’elle nomme est résolu contre votre propre locataire, et une référence qui ne se résout pas fait échouer la proposition entière au lieu d’être silencieusement écartée : c’est ce qui empêche un modèle ayant lu quelque chose d’hostile d’atteindre quoi que ce soit au-delà de votre projet. L’approbation est un geste humain, et c’est le moment où quelque chose se produit : l’exécution passe par les mêmes chemins de drapeaux et de messagerie que ceux que vous utilisez à la main, si bien que les permissions, la piste d’audit et les limites de votre forfait s’appliquent toujours. Approuver deux fois ne fait rien la seconde fois.

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