Plateforme d’engagement pilotée par les événements · console web et API

Du premier contact à la conversion, chaque événement compte.

Missivia suit un prospect depuis sa première interaction jusqu’à ce qu’il devienne client, et au-delà.

Les événements natifs et métier déclenchent séquences de nurturing, parcours, campagnes et messages de service, avec scoring, conditions, délais et objectifs de conversion.

Chaque message respecte le consentement par finalité et une autorisation calculée côté serveur ; l’e-mail est le premier canal, d’autres suivront.

  • Événements natifs et métier
  • Déclencheurs, délais et anti-doublon
  • Séquences, parcours et objectifs de conversion
  • Scoring et segments dynamiques
  • Consentement par finalité
  • Autorisations calculées côté serveur
ÉVÉNEMENTSDÉCISIONSMESSAGESOuverture, clicévénement natifCommande passéeévénement métierEntrée en segmentévénement natifDéclencheurcondition · délaiParcoursattente · brancheobjectif → sortieMessage remisconsentement vérifiéRelance bornéeau plus un envoiObjectif atteintconversion comptée
Ce qui entre, ce qui décide, ce qui sort. Les impulsions suivent le chemin réel d’un événement jusqu’au message.
Ce que fait la plateforme

Huit domaines, dans l’ordre où ils servent

On part de ce qui arrive — un événement —, on en tire une réaction, on décide qui a le droit d’en faire quoi, on compose le message, on prouve le consentement, on branche vos outils, on remet — puis on livre ce qui doit sortir vers vos partenaires, sous gouvernance, et on pilote l’ensemble. Le détail — grammaire des événements et des parcours, matrice d’autorisation, classes de données, conventions de l’API, catalogue des nœuds et des métriques — vit sur sa propre page.

01

Événements, déclencheurs et parcours de conversion

Les événements natifs — ouverture, clic, rebond, désinscription, entrée dans un segment — et les événements métier poussés par vos outils avec leur charge utile déclenchent la suite : séquences de nurturing, parcours à branches, campagnes, messages de service. Conditions, délais, anti-doublon, attentes d’événement, tests A/B, et des objectifs de conversion qui arrêtent le parcours dès que la commande est passée ou le rendez-vous pris.

Voir le détail
02

Autorisations et accès

Une organisation, ses espaces, ses rôles et ses clés d’API composent une autorisation unique, calculée par le serveur à chaque appel. Les droits sont hérités du rôle, cumulés par permission nominative, et plafonnés par la classe de la clé. Une ressource qui appartient à un autre espace est introuvable, jamais interdite.

Voir le détail
03

Templates, kits et pages publiques

Un éditeur de templates sans exécution de code, des fragments réutilisables figés dans chaque version envoyée, un aperçu en direct. Un contenu qui lit le dernier événement de chaque type, pour écrire à partir de ce qui vient de se passer. L’import d’un kit HTML livré par une agence, une bibliothèque de fichiers dans le périmètre, et des pages de désinscription et de préférences à votre marque.

Voir le détail
04

Consentement, données sensibles et traçabilité

Un prospect entre avec sa preuve de consentement : un registre d’actes par finalité qui garde le libellé exact présenté, la date, la source et l’adresse du formulaire. Deux pixels tenus sous deux régimes distincts. Les attributs sensibles chiffrés hors de la fiche et lisibles sur permission nominative. Un journal d’audit en ajout seul, des durées de conservation, une anonymisation irréversible et un export de réversibilité. Limitation du traitement et opposition au profilage sont appliquées par le serveur.

Voir le détail
05

API, intégration et exploitation

Un contrat publié avant le code : identifiants opaques, pagination par curseur, créations idempotentes, erreurs normalisées. C’est par là que vos outils poussent leurs événements et récupèrent ce qui se passe : webhooks signés, journal d’événements, exports sans donnée personnelle. Un bac à sable où rien ne part, et une mise en production par artefacts, sans aucune opération manuelle. Une action menée depuis la console porte toujours son acteur, et rejoint le journal d’audit chaîné.

Voir le détail
06

Remise et délivrabilité (canal e-mail)

Premier canal ouvert, l’e-mail est remis par défaut par la plateforme elle-même : les messages sont confiés directement aux serveurs de messagerie des destinataires, depuis ses propres adresses IP — MTA Missivia, ou un routeur externe au choix de l’espace — Mailjet et Brevo sont intégrés, et toute solution de routage qui expose une API peut l’être de la même façon — avec notre suivi et notre désinscription conservés. Domaines expéditeurs vérifiés en SPF, DKIM et DMARC, montée en charge par IP, traitement des retours et des plaintes, pause automatique au franchissement des seuils d’un espace. Le corps est rendu et signé au moment de la tentative, jamais stocké ; TLS est obligatoire pour un espace de santé ; un verdict tardif corrige le statut.

Voir le détail
07

Workflows et livraisons

Un graphe versionné de nœuds typés où circulent des lots : segments, listes, événements ou statistiques en source ; projection, filtre, agrégation, jonction ; CSV, JSON, XML ou Excel, chiffrés PGP ; dépôt SFTP, HTTP, S3 ou e-mail vers des destinations déclarées par l’espace, chacune avec la classe de données qu’elle peut recevoir. Des fichiers en entrée, un coffre de secrets, l’essai d’une étape sans effet de bord et la reprise depuis le nœud en échec. Pas de code arbitraire ; une donnée de santé ne sort que chiffrée, vers une connexion SFTP attestée, et chaque sortie est journalisée par noms de champs, jamais par valeurs.

Voir le détail
08

Tableaux de bord

Un constructeur sur grille — indicateurs, séries, répartitions, tableaux, entonnoirs — enregistré et partagé par espace, avec un tableau par défaut par rôle et quatre modèles de départ. Chaque widget interroge un catalogue fermé de métriques et de dimensions, filtré par rôle : taux calculés sur la population consentante, « non mesurable » plutôt que zéro, seuil d’affichage sur tout compte de personnes, jamais une donnée individuelle. Comparaison de périodes, objectifs, annotations, exports PNG et PDF.

Voir le détail
Comment ça marche

Quatre temps, du fait constaté au message remis

Rien ne part d’une intention : tout part d’un fait. Voici ce qui se passe entre l’événement et la boîte de réception.

Ouverture, clic, rebondévénement natifCommande passéeévénement métierLe déclencheur évaluecondition · délai · anti-doublonLe parcours avanceattente · branche · test A/Bobjectif atteint → sortieLe message est remisconsentement par finalité vérifié
  1. Un événement arrive

    Natif — une ouverture, un clic, un rebond, une entrée dans un segment — ou métier, poussé par vos outils avec sa charge utile : « commande passée », « rendez-vous pris ».

    ÉvénementDéclencheurParcoursMessage
  2. Le déclencheur l’évalue

    Une condition sur la charge utile et sur la fiche, un délai de zéro à trente jours, un anti-doublon explicite : à chaque fois, une seule fois, ou au plus une fois par période.

    Chaque décision — déclenché, écarté avec sa raison, exécuté — est écrite au journal du contact.

    ÉvénementDéclencheurParcoursMessage
  3. Le parcours avance

    Attente relative ou datée, attente d’un événement, condition, aiguillage, répartition pondérée, test A/B.

    Toute étape qui dépend d’une ouverture ou d’un clic a trois issues, jamais deux : l’a fait, ne l’a pas fait à temps, ne peut pas être mesuré. Dès que l’objectif de conversion est atteint, l’inscription s’arrête, où qu’elle en soit.

    ÉvénementDéclencheurParcoursMessage
  4. Le message est remis

    Le consentement de la finalité est vérifié au moment du rendu, l’autorisation est calculée côté serveur, et la remise se fait par le premier canal ouvert : l’e-mail, confié directement au serveur de messagerie du destinataire.

    ÉvénementDéclencheurParcoursMessage
  • 20personnes : seuil sous lequel un compteur servi à un rôle de plateforme est masqué
  • 2pixels distincts, tenus sous deux régimes juridiques
  • 3issues à toute étape mesurée : fait, pas fait, non mesurable
  • 24 hde rejeu d’une clé d’idempotence, sans aucun effet de bord
Autorisations

Une seule décision, côté serveur, à chaque appel

Cinq éléments composent l’autorisation — et l’interface qui appelle n’en décide aucun.

  1. 1

    Espace

    Déduit du jeton. L’appel ne peut pas en désigner un autre.

  2. 2

    Rôle

    Un jeu de capacités hérité en bloc, pas une case à cocher par écran.

  3. 3

    Permissions nominatives

    Cumulatives, accordées à une personne désignée, journalisées.

  4. 4

    Classe de la clé

    Elle plafonne l’ensemble : ce qu’elle n’atteint pas, aucun rôle ne le rend.

  5. 5

    Décision

    Une matrice unique tranche, et écrit sa décision — refus compris.

Une ressource qui appartient à un autre espace est introuvable, jamais interdite : l’existence d’un accès aux personnes n’est pas observable de l’extérieur.

Voir la matrice, rôle par rôle →

Données sensibles

Ce qui est sensible ne voyage pas

La classe d’un attribut décide, côté serveur, de l’endroit où la valeur est écrite, de qui peut la relire et de ce qui en est journalisé. Une valeur sensible n’est jamais une variable de fusion : on différencie le message en choisissant le parcours.

Fiche contactnom, adresse, attributsindex à sens uniquesur permission nominativeTable chiffréeAES-256-GCM, hors de la ficheMessage remissans l’attribut sensible
La valeur sensible n’est jamais écrite avec la fiche, et ne part jamais dans un message.

Un produit Dataventure

Missivia est la plateforme d’engagement des outils de collecte de leads de Dataventure Group, ouverte aux partenaires comme plateforme à espaces multiples. Chaque espace a ses clés, ses domaines, ses quotas et ses rôles. L’e-mail est le canal servi aujourd’hui ; la plateforme est conçue pour en accueillir d’autres, avec le même registre de consentement et les mêmes autorisations.