Composer une vue de pilotage, sans jamais voir une personne
Un constructeur sur grille assemble des indicateurs, des séries, des répartitions et des tableaux en une vue propre à un besoin ; la vue s’enregistre, se partage dans l’espace, se décline par rôle. Derrière chaque widget, une seule requête d’agrégats à vocabulaire fermé : aucune expression libre, aucun champ de contact, aucune ligne individuelle — par construction, pas par convention.
Les widgets se composent un par un ; chaque compte porte la marque de son seuil, chaque taux vient avec la population sur laquelle il est calculé.
Un constructeur sur grille
Douze colonnes, une palette, un éditeur piloté par le catalogue.
Une grille de douze colonnes, glisser-déposer et redimensionnement ; une palette de widgets ; un éditeur de widget qui suit le catalogue — famille, métriques, dimensions, filtres, visualisation — avec un aperçu en direct.
Six widgets : indicateur (valeur et variation par rapport à la période précédente), série (une seule échelle, jamais de double axe), répartition en barres par dimension, tableau des lignes de la requête, entonnoir des étapes d’un parcours, texte.
Des filtres globaux — période, comparaison avec la période précédente — et des widgets « listes récentes » : dernières campagnes, dernières exécutions de workflows.
Des noms lisibles : les identifiants de campagne, de parcours, d’étape, de template, de liste et de segment sont rendus par leur nom, résolus sur les seules valeurs présentes dans la réponse — jamais un inventaire de l’espace, et jamais un nom inventé pour une ressource disparue.
Une méthode de visualisation plutôt que des options infinies : ordre fixe des couleurs par entité, palette validée en clair et en sombre, légende dès deux séries, infobulles, vue tableau toujours disponible.
Un widget que le rôle ne peut pas servir affiche « indisponible pour votre rôle » — jamais une erreur, jamais un zéro trompeur : la garde d’un widget est déduite de sa requête.
Un catalogue fermé, filtré par rôle
Chaque métrique, dimension et filtre appartient à un catalogue publié. Ce qui n’y est pas ne se demande pas.
Six familles : messages (envoyés, remis, rebonds durs et doux, plaintes, désinscriptions, ouvertures, clics, échecs, objectifs atteints, taux dérivés), parcours (issues par étape, la troisième issue « non mesurable » comprise), contacts (effectifs par statut, par liste, par segment, par finalité de consentement, créés sur la période), événements (par nom et par jour), délivrabilité (rebonds par classe, plaintes, taux), workflows (exécutions et échecs).
Des dimensions : jour, semaine, mois, campagne, parcours, étape, template, liste, segment, variante, nom d’événement, classe de rebond, finalité de consentement, statut de contact, route de remise — MTA, Mailjet ou Brevo.
Le catalogue renvoyé dépend de la classe de la clé : la console ne propose que ce que la clé peut demander, et un rôle d’exploitation n’obtient jamais une dimension qui ramènerait à une personne.
Une requête tient dans des bornes : une famille à la fois, deux dimensions au plus dont une de temps, dix métriques, deux ans de période, cinq mille lignes ; la réponse est mise en cache soixante secondes, par espace et par classe de clé.
Les totaux d’une vue viennent d’une requête agrégée séparée, jamais de la somme des lignes — qui sont tronquées et déjà masquées. Un taux total est le rapport des totaux, et vaut « non mesurable » quand il ne l’est pas.
Ce qu’aucune entrée du catalogue n’atteint
Aucun attribut classé santé ; aucun segment dérivé d’un critère de santé — écarté au chargement, jamais dans un plan de requête, et son nom ne sort pas non plus.
Aucune colonne nominative — adresse, empreinte d’adresse, prénom, nom, identifiant externe, attributs — ni en sélection ni en filtre : un test le vérifie sur le SQL rendu de chaque famille.
Aucune requête libre : ni SQL, ni expression, ni nom de colonne accepté par le réseau.
Toute requête est rattachée à l’espace de la clé qui l’émet ; le cache porte l’espace et la classe de la clé.
Les règles de conformité sont dans la requête
Un widget ne peut pas s’en affranchir : elles vivent dans la requête, pas dans l’affichage.
Les taux d’ouverture et de clic sont calculés sur la population consentante, jamais sur le total envoyé, et valent « non mesurable » quand cette population est nulle — jamais zéro : la règle des trois issues s’applique à toute série, pas seulement aux parcours.
Demander un taux fondé sur le consentement renvoie d’office son dénominateur et son numérateur, ainsi que la note réglementaire — la même constante que sur les autres statistiques. Un taux dont on ne montre pas la base ne dit pas sur quoi il est calculé.
Tout compte de personnes passe par le seuil d’affichage de l’espace, quelle que soit la classe de la clé ; les comptes de messages sont masqués pour les rôles d’exploitation.
Un taux dont le numérateur ou le dénominateur est masqué vaut « non mesurable » : une division reconstruirait le compte masqué. Une moyenne sur une cohorte sous le seuil aussi.
Jamais de donnée individuelle dans un widget : la réponse est faite de lignes d’agrégats, et chaque compte porte la marque de son seuil.
Comparer, viser, annoter
Une courbe qui décroche un mardi appelle toujours la même question : que s’est-il passé ce jour-là ?
Comparaison de périodes, et des objectifs à seuils colorés, toujours accompagnés d’une icône et d’un libellé — jamais la couleur seule.
Des annotations sur les séries, d’un vocabulaire fermé de quatre natures : campagne envoyée (à sa date effective), version de parcours publiée, échec d’une exécution de workflow — le nom du workflow, jamais le message d’erreur —, changement de route de remise.
Une annotation porte toujours le nom d’une ressource — jamais un contact, une adresse, un effectif — et renvoie vers l’écran qui la concerne quand il en existe un.
Enregistrer, partager, exporter
Un tableau de bord est un document de l’espace ; les agrégats, eux, restent à l’API.
Des tableaux enregistrés par espace, avec un propriétaire, une visibilité privée ou d’espace, et un tableau par défaut par rôle — qui devient la page d’accueil de l’espace pour ce rôle. Liste, création, duplication.
Quatre modèles de départ : pilotage des campagnes, parcours et conversion, délivrabilité et réputation, consentements et audience. Un modèle est copié dans l’espace à la première ouverture, jamais imposé.
Export d’un widget en CSV ou en PNG, et d’un tableau de bord en PDF, dans le navigateur, sans dépendance.
Envoi périodique par un workflow — planification, requête d’agrégats, format, e-mail — qui livre les lignes : le PDF côté serveur est écarté, parce qu’il demanderait un navigateur dans le périmètre pour composer ce que le navigateur de l’utilisateur sait déjà produire.
La vue de plateforme
L’opérateur voit des comptes, jamais des contacts.
Une route distincte, jamais un drapeau sur la route d’espace : une clé d’espace ne la voit pas — introuvable, jamais interdite.
Trois familles, en comptes seulement : messages, délivrabilité, workflows. Jamais la famille contacts — ce sont des personnes —, jamais une issue de parcours ni le journal d’événements d’un espace.
Des dimensions : jour, semaine, mois, espace, route de remise, classe de rebond. Aucun nom de campagne, de parcours, de template, de liste ni de segment : le seul nom rendu est celui d’un espace.
Le seuil d’affichage de la plateforme s’applique à chaque ligne et à chaque total ; cinq cents lignes au plus — une vue de plateforme se lit, elle ne s’exporte pas.
Chaque requête écrit une entrée de journal qui nomme les espaces réellement lus et les métriques demandées — jamais une valeur.
Pas de constructeur côté plateforme : l’onglet technique reste une page fixe, et il n’existe pas d’annotations de plateforme.
