TPMS Expertic - Étude de cas de la plateforme d'exploitation des TPE

Vue d'ensemble

TPMS gère les opérations des terminaux de paiement électronique entre banques, chargés de compte, clients, tickets, inventaire et workflows de support. L'étude de cas publique utilise des captures d'écran anonymisées et évite identifiants, données clients et détails sensibles.

Problème

Les opérations TPE impliquent des demandes de banques, la coordination des chargés de compte, des interventions et des changements d'inventaire traçables. Sans plateforme unique adaptée aux rôles, le statut des tickets, le stock, les pièces jointes et les données des banques et clients se fragmentent.

Contexte

L'implémentation utilise un frontend Next.js, un backend NestJS et Prisma/PostgreSQL. Elle sépare les expériences du chargé de compte et de l'employé de banque et couvre les workflows d'intervention, de consommables, de vérification réseau et de déblocage.

Mon rôle

Développeur full-stack sur TPMS, un outil interne d'Expertic que j'ai construit avec mon collègue Sohaib Benabdallah pendant mon poste là-bas. C'est la propriété de l'entreprise Expertic ; l'étude de cas le présente donc comme une réalisation commune d'Expertic, pas comme mon propre produit, en insistant sur l'implémentation, l'architecture et la conception des workflows.

Objectifs

• Centraliser les demandes de service TPE et les flux d'inventaire dans une seule plateforme web authentifiée
• Donner aux employés de banque un espace cloisonné pour créer et suivre des demandes
• Donner aux chargés de compte le contrôle opérationnel des tickets, banques, clients, modèles de TPE, consommables et stock mort
• Garder l'autorisation explicite grâce à l'authentification JWT, aux gardes de rôle et aux politiques CASL
• Soutenir les passages de relais opérationnels avec des notifications, des pièces jointes et l'import/export Excel

Décisions techniques

• Utiliser Next.js App Router et TypeScript pour des pages de tableau de bord propres à chaque rôle et des motifs d'interface réutilisables
• Utiliser une couche d'API Axios centrale pour que les écrans appellent des fonctions d'endpoints typées au lieu de requêtes codées en dur
• Utiliser des modules de routes NestJS découpés par rôle et par ressource, pour garder explicites les API de l'employé de banque et du chargé de compte
• Utiliser Prisma avec PostgreSQL pour le modèle de données central : utilisateurs, banques, clients, TPE, types de terminaux, tickets, pièces jointes et entités de stock
• Utiliser JWT, des gardes globales, des contrôles de rôle sur les endpoints et des permissions CASL pour appliquer l'accès au niveau de l'API
• Utiliser les Server-Sent Events pour les flux de notifications en direct et des modèles d'e-mails pour les mises à jour opérationnelles
• Prendre en charge les pièces jointes et l'import/export de modèles Excel pour un vrai travail d'exploitation, en plus des formulaires CRUD

Architecture

Le frontend est un tableau de bord Next.js adapté aux rôles. Des sessions adossées à JWT appellent des fonctions Axios typées, puis les requêtes passent dans des modules NestJS cloisonnés par rôle. Les gardes et CASL protègent les tickets, l'inventaire, les banques, les clients, les consommables, le stock mort, les notifications, les pièces jointes et les flux Excel. Prisma persiste le modèle dans PostgreSQL.

Fonctionnalités clés

• Tableau de bord du chargé de compte pour le suivi des tickets, le téléchargement de modèles Excel, l'import Excel et la création de nouvelles demandes
• Tableau de bord de l'employé de banque avec suivi cloisonné des tickets et navigation simplifiée
• Formulaire de nouvelle demande à onglets couvrant les workflows d'intervention, de consommables, de choix du réseau et de déblocage
• Gestion des banques avec sous-comptes et affectation de modèles de TPE
• Gestion des fabricants et modèles de TPE avec vues groupées et actions de détail
• Inventaire des consommables avec état du stock et prise en charge des demandes
• Gestion du stock mort pour les chargés de compte et inventaire affecté en lecture seule pour les employés de banque
• Écrans de profil et de paramètres pour les deux rôles

Défis

• Garder distinctes les capacités du chargé de compte et de l'employé de banque sans dupliquer chaque écran et chaque concept d'API
• Modéliser plusieurs types de tickets qui partagent les données clients et banques mais ont des exigences de validation différentes
• Rendre des tableaux opérationnels denses interrogeables et filtrables sans ralentir le travail quotidien
• Gérer les pièces jointes et les flux Excel à côté des appels JSON normaux de l'API
• Présenter le projet publiquement sans exposer de données de production privées ni de métriques non étayées

Résultats

• Une étude de cas full-stack avec captures d'écran, un schéma d'architecture Mermaid et des détails fondés sur l'implémentation
• Couvre un travail de tableau de bord qui dépasse les pages marketing : navigation adaptée aux rôles, tableaux de données, fenêtres modales, formulaires, paramètres et API opérationnelles
• Couvre l'architecture backend avec modules NestJS, Prisma, authentification JWT, autorisation CASL, notifications, téléversements et flux Excel
• Garde le texte public centré sur l'architecture et la contribution plutôt que sur des données confidentielles ou des métriques non vérifiées

Ce que j'ai appris

• Un logiciel d'exploitation vit ou meurt selon la clarté de ses frontières de rôles et la prévisibilité de ses passages de relais
• Les systèmes de tickets ont besoin de primitives partagées souples, car chaque type de demande a sa propre validation et son propre cycle de vie
• Un travail interne doit montrer l'architecture, les workflows et des visuels anonymisés plutôt que des données confidentielles
• De petits choix d'implémentation comme le nommage des endpoints, les filtres de tableaux et la gestion de l'état des modales comptent énormément dans les outils d'administration