01Le déploiement sur un seul écran
La vue d'ensemble ouvre la journée. Santé du système : maintenance, passerelle API, base de données, cache. Signaux sur les disjoncteurs, les prestataires et les erreurs non résolues. Le travail sous forme de files comptées : 12 revues KYC en attente dont la plus ancienne à 5 h 02 min, 8 écarts de rapprochement avec 18 240 € prêts à créditer, 2 validations en attente. Les actions privilégiées récentes et la santé par prestataire se trouvent en dessous. Rien sur cet écran n'exige un second outil.
- Système, signaux et files en une seule lecture verticale
- Chaque carte renvoie vers la file qu'elle compte
- Santé des prestataires par rail : dégradé, opérationnel, en reprise
02Le copilote opérateur
Un dock copilote s'ouvre à côté de n'importe quelle vue avec des amorces contextuelles : pourquoi les rechargements échouent, résumer les incidents ouverts. Il est en lecture seule et n'exécute aucune action. Et il se dégrade honnêtement : tant que le endpoint du modèle n'est pas branché, le dock le dit clairement au lieu d'inventer des réponses.
03Insights
L'activité sur un écran : 42 180 utilisateurs, 12 408 actifs, un taux d'activation de 61,8 %, un taux de succès de 96,4 %, et des flux d'argent de +1,84 M€ entrants et −1,52 M€ sortants sur 30 jours. Les entonnoirs KYC et d'onboarding sont à côté, si bien qu'une baisse d'activation se voit dès la semaine où elle commence. Les indicateurs financiers restent réservés au rôle financier.
04Triage des erreurs
Le flux d'alertes arrive dédupliqué. 142 occurrences d'une même WebhookSignatureError, touchant 38 utilisateurs, se regroupent en une seule ligne critique avec actions d'acquittement et de résolution, et la vue se rafraîchit toutes les 10 secondes. Les opérateurs résolvent des signatures, pas des pages de bruit.
- Une ligne par signature d'erreur, comptabilisée
- Utilisateurs concernés rattachés à chaque signature
- Acquittement et résolution comme actions auditées
05Des utilisateurs, trouvables par n'importe quoi
12 408 comptes, recherchables par nom, e-mail, téléphone ou ID, avec le statut KYC et le statut du compte sur chaque ligne, et des onglets pour KYC en attente, vérifiés, rejetés, bloqués et archivés. Chaque ligne s'ouvre sur un User 360 : soldes, cartes, appareils, niveau KYC et historique complet d'un client sur un seul écran.
06File de revue KYC
Les revues en attente arrivent sous forme de file comptée, horloge visible : 12 dans la démo, chaque ligne indiquant le prestataire, le statut, le dernier motif et depuis combien de temps le demandeur attend. Un nouvel essai de liveness bloqué à 5 h 02 min s'affiche en rouge. Approuvez, rejetez ou réinitialisez dans la console ; chaque décision exige un motif, est auditée et met à jour le statut du compte partout à la fois.
- En attente, prétraités, rejetés et tous, en onglets
- Motifs sur la ligne : revue d'adresse, nouvel essai liveness, revue de document
- Temps d'attente visible, le plus ancien signalé
07Exploration du ledger
Chaque ligne d'argent s'ouvre jusqu'au bout. Le transfert TR-90211, un paiement pair à pair de 120,00 € abouti, affiche l'émetteur, le destinataire et les deux jambes du ledger passées : un débit de −120,00 € et un crédit de +120,00 €, en partie double et équilibrés. Aucune vue de synthèse ne s'interpose entre l'opérateur et le ledger.
08Rechargements crypto
Les dépôts on-chain sont des lignes à part entière, pas un export venu d'ailleurs. Un rechargement réussi sur le réseau Base affiche 250,00 USDC créditant le ledger EUR, avec le taux de change, les frais, l'adresse du wallet et le hash de la transaction dans le panneau latéral. Deux rails, une console, traçable jusqu'à la chaîne.
09Rapprochement
Les dépôts SEPA entrants sont rapprochés automatiquement des utilisateurs ; les exceptions atterrissent dans une file de travail comptée : lignes rapprochées prêtes à créditer, payeur inconnu avec deux correspondances candidates, et onglets prêt, à vérifier, non rapproché et historique. Créditer se fait en un clic quand la correspondance est nette, et par une décision motivée quand elle ne l'est pas ; chaque crédit manuel exige un motif, avec des plafonds de montant lus depuis la config.
- Associez un paiement à un utilisateur, puis créditez et rapprochez
- Payeurs ambigus mis en attente de revue avec leurs candidats
- Relevés bancaires importés directement dans la file
10Tracer
Collez une référence, obtenez toute l'histoire. La trace 9F21-0716 s'ouvre en trace de sauts : demande soumise, ledger validé selon la politique, cotation du prestataire enregistrée, confirmation on-chain sur Base à 12 sur 12, règlement livré, chaque saut chronométré, de +42 ms à +22 s. Lecture seule par conception : Tracer explique, il ne modifie jamais.
- Une référence, chaque saut de la demande au règlement
- La politique et la cotation appliquées à chaque saut, enregistrées
- Clé d'idempotence visible sur la trace
11Boîte de validations
Les crédits au-dessus du seuil attendent un second opérateur. La boîte se divise entre ce qui attend votre validation et ce que vous avez demandé : d'un côté un crédit commercial de 500,00 € et un remboursement de rechargement échoué de 120,00 €, de l'autre votre propre annulation de frais de 40,00 € en attente d'un cosignataire. Vous ne pouvez pas valider ce que vous avez demandé, mais vous pouvez le retirer.
12Le journal d'audit
18 942 actions d'opérateurs dans une table en ajout seul : heure, opérateur, action, cible, motif écrit, et la requête sous-jacente avec son code de réponse. Les actions système arrivent dans la même colonne vertébrale que celles des humains. Filtrez par opérateur, action ou date ; exportez en CSV quand quelqu'un hors de la console le demande.
- Ajout seul : les entrées ne sont jamais modifiées ni supprimées
- Motif et requête attachés à chaque ligne
- Filtrable, paginé, exportable
13Inspection et rejeu des webhooks
18 204 événements entrants de prestataires, chacun avec sa vérification de signature sur la ligne. Un événement en échec peut être rejoué pour réappliquer un verdict manqué, avec motif obligatoire et sans notification en double, mais seulement si sa signature est valide ; les signatures invalides ne sont pas fiables et le rejeu est bloqué. Afficher un payload brut envoie des PII non masquées vers votre navigateur : l'opération écrit donc un événement d'audit.
14Feature flags et config distante
38 clés typées réparties sur 8 domaines (interrupteurs, montants, énumérations) pour les cartes, les rechargements, le KYC et le reste de la surface d'exécution. Chaque clé indique qui l'a modifiée en dernier et quand ; chaque changement est comparé, motivé et audité. Un plafond de dépense ou un changement de prestataire est une modification dans la console, pas une release sur les stores.
- Contrôles typés : aucune chaîne de config en texte libre
- Historique par clé : qui, quoi, quand, pourquoi
- Les changements prennent effet sans release de l'app
15Kill switches
Quand quelque chose doit s'arrêter, ça s'arrête d'ici. Un gel global affiche l'écran de maintenance au lancement de l'app ; des kill switches par fonctionnalité coupent individuellement les cartes, les rechargements, les virements ou le KYC : 4 actifs, 0 désactivé dans la démo. Un contournement d'OTP pour la QA dispose de son propre interrupteur, désactivé par défaut. Chaque changement est journalisé et doublement confirmé.
16Opérateurs et rôles
L'équipe se gère là où le travail se fait. Six comptes d'opérateurs couvrent des rôles de superadmin à auditeur, chaque fiche montrant son activité récente auditée. Les changements de rôle passent par une boîte de dialogue de motif, et personne ne peut modifier son propre rôle ni se désactiver : il faut un second superadmin.
- Six rôles : superadmin, ops, conformité, ingénieur, support, auditeur
- Les actions récentes de chaque opérateur sur sa fiche
- Pas d'auto-promotion, pas d'auto-désactivation
17Actions avec motif obligatoire
Une action privilégiée s'explique avant de s'exécuter. Geler la carte 4417 ouvre une boîte de dialogue qui indique le périmètre d'impact, exige un motif écrit et, parce que nous sommes en production, oblige l'opérateur à saisir PROD avant que le bouton de confirmation ne s'active. Le motif est inscrit dans le journal d'audit immuable, à côté de l'action elle-même.
18Circuit breakers et santé des prestataires
Côté ingénierie, on suit en direct les circuit breakers et la santé des prestataires. Quand un prestataire se dégrade, l'état du breaker apparaît dans la console avant l'arrivée des tickets du support — et le retour à la normale aussi.
19Back-office des liens de paiement
Les liens créés par les clients ont leur vue opérateur : 214 liens payés, actifs ou expirés dans la démo, chacun avec son virement de règlement rattaché et un lien d'ouverture dans Tracer pour la trace complète. Révoquer un lien n'est pas un remboursement — la console vous le rappelle avant d'agir.
20Whitelists de connexion et PII masquées
L'accès à la console est soumis à une whitelist, et ce que voient les opérateurs est minimisé par défaut : e-mail et téléphone restent masqués tant qu'on ne les révèle pas volontairement, et les métriques financières sont réservées au rôle financier. Voir davantage est un acte délibéré, journalisé.
21Crédits manuels et approvisionnement
Approvisionner un utilisateur est un vrai flux de la console, pas une écriture en base. Chaque crédit porte un motif écrit, et les crédits au-delà du seuil passent par la boîte d'approbations pour la validation d'un second opérateur.
22Gestion des cartes
Les cartes de toute la base : gel et dégel avec le périmètre d'impact indiqué, variantes de cartes gérées par programme, et chaque carte accessible depuis le User 360 auquel elle appartient. Les actions destructrices passent par la même boîte de dialogue à motif obligatoire que le reste.
23Comptes bancaires
Les comptes bancaires de la plateforme ont leur propre vue, et les relevés bancaires importés alimentent directement la file de rapprochement. Le rail sur lequel l'argent circule réellement se voit dans la même console que le ledger où il arrive.
24Palette de commandes et recherche
⌘K ouvre la palette depuis n'importe où ; la recherche accepte un nom, un e-mail, un téléphone ou un ID et mène à la bonne fiche. La console est conçue pour se piloter au clavier, même les mauvais jours.
25Campagnes, parrainages et codes d'invitation
Les leviers de croissance vivent dans la même console : campagnes configurées et suivies, programmes de parrainage monitorés, codes d'invitation émis et révoqués. Les Ops lancent leurs promotions sans second outil d'administration.
26Versions d'app et onglets mobiles
Voyez quelles versions de l'app sont en circulation et configurez à distance la disposition des onglets de l'application mobile. Le shell de l'app se pilote depuis la console — changer un onglet, c'est de la config, pas une release.
27Contenu, FAQ et chat
Le contenu in-app, les entrées de FAQ et le chat client se gèrent dans la console. La personne qui répond à une demande de support a le User 360 à un clic, pas dans un autre onglet d'un autre système.
28Opérations crypto
Le volet crypto a sa propre section : vue d'ensemble crypto, wallets, registre d'actifs et actions crypto — à côté de la file des recharges. Les opérateurs voient la surface on-chain avec la même profondeur que le ledger fiat.
29Exports
Les données sortent proprement quand il le faut : export CSV du journal d'audit et des tables opérationnelles, filtré exactement comme affiché. Ce que demande un auditeur se télécharge, sans ticket d'ingénierie.
30Whitelabel et environnements
La console tourne sous votre marque — le déploiement de démo s'appelle YourBrand, pas Protocore. Une bannière permanente indique l'environnement, les vues de production portent un badge prod, et les actions en production demandent à l'opérateur de saisir PROD. Personne ne confond les déploiements.
