Une application de gestion opérationnelle pour le service client sur lequel je travaille — centraliser escalades, incidents et gestes commerciaux dans un outil que je code moi-même, entièrement local, sans hébergement externe.

État d’avancement global

⬜⬜⬜ 0/3 phases terminées (0%) — cadrage fonctionnel complet, développement qui démarre

Le projet en une phrase

Une application de gestion opérationnelle pour le service client sur lequel je travaille — centraliser les escalades, les incidents, les gestes commerciaux et la base de connaissances dans un seul outil que je code moi-même, entièrement local et sans aucun hébergement externe, pour remplacer une mécanique aujourd’hui éclatée entre fichiers Excel, mails et process papier.

Pourquoi ce projet

Je suis Customer Care Supervisor chez un opérateur de paris et jeux d’argent depuis 2024, après y avoir été moi-même Opérateur de 2022 à 2024. Je connais donc les deux côtés du problème : les outils dispersés qui font perdre du temps à l’agent au quotidien, et ceux qui font perdre du temps au superviseur en reporting et en suivi. Une bonne partie de mon quotidien — le mien, celui de mon équipe et celui de ma hiérarchie — repose sur des outils qui n’ont jamais été pensés ensemble : un fichier Excel pour les escalades, un autre pour certains incidents, des mails dispersés pour les gestes commerciaux, un document de procédures qu’on rouvre à chaque doute. Résultat : de la ressaisie, des informations qui se perdent, et du temps perdu à chercher plutôt qu’à traiter.

Plutôt que d’attendre un outil interne qui ne viendra peut-être jamais, j’ai décidé de le construire moi-même — à l’image de mon projet NOC, mais cette fois pour un besoin métier réel et quotidien plutôt qu’un homelab personnel.

Le but du logiciel

CCOP (Customer Care Operations Platform) doit devenir le point d’entrée unique du service client sur lequel je travaille, pour :

• Centraliser l’information — un seul endroit pour les escalades, incidents, gestes commerciaux et procédures, plutôt que des fichiers dispersés.
• Accélérer le traitement des escalades — formulaires guidés, génération automatique de l’e-mail à envoyer (objet, corps, destinataires), plutôt que de le rédiger à la main à chaque fois.
• Réduire les tâches administratives — moins de ressaisie, moins d’allers-retours entre outils.
• Automatiser une partie des analyses et du reporting — préparer les chiffres plutôt que les compiler à la main chaque semaine.
• Faciliter le suivi opérationnel — historique, statuts, droits d’accès, pour moi comme pour mon équipe.

L’outil est pensé pour être utilisé par toute la chaîne : moi-même, ma superviseure adjointe, mon manager, les coordinatrices et les opérateurs du service client.

Une contrainte de conception forte : zéro hébergement externe

CCOP manipule des données client et des données d’entreprise confidentielles. J’ai donc posé une contrainte non négociable dès le départ : aucun serveur, aucun hébergement externe, aucun appel réseau. L’application est un fichier HTML/JS/CSS autonome, et toutes les données vivent dans un unique fichier JSON stocké sur un espace cloud approuvé par l’entreprise qui l’utilisera (dans mon cas c’est OneDrive, mais d’autres entreprises utilisent peut-être un autre système) — chargé et sauvegardé directement depuis le navigateur, sans jamais transiter par un service tiers.

Un virage pris après une semaine de cadrage : construire un vrai moteur, pas un outil sur mesure

Après une première semaine à avancer module par module (en commençant par les escalades liées aux paris sportifs), j’ai pris le temps de recadrer sérieusement le projet plutôt que de continuer à coder au fil de l’eau. Le constat : coder en dur les champs, les règles et les e-mails de chaque famille de produits me forcerait à refaire tout ce travail à la main pour chacune des 12 familles concernées — et surtout, ça fermerait la porte à une ambition que je garde en tête pour la suite : que CCOP puisse un jour être utilisé (voire distribué) au-delà de mon usage personnel, sur le même principe que j’ai déjà appliqué à ce site avec « Curio », l’édition générique et distribuable de mon thème Lio Web.

État d’avancement par phase

Phase 1 — Système de rôles & droits configurable
⬜⬜⬜⬜⬜ 0% — à faire
Des rôles nommés (avec des permissions par défaut), plutôt qu’un réglage utilisateur par utilisateur figé dans le code.

Phase 2 — Cycle de vie des escalades
⬜⬜⬜⬜⬜ 0% — à faire
Filtrage par statut, archivage réversible (jamais de suppression définitive), et une action « Finaliser » qui verrouille une fiche traitée.

Phase 3 — Moteur de formulaires générique
⬜⬜⬜⬜⬜ 0% — à faire
Plutôt que d’écrire le code de chaque famille de produits à la main, l’administrateur pourra créer lui-même n’importe quelle famille, sous-produit et type de demande, avec ses propres champs, ses règles conditionnelles et son e-mail généré. Le travail déjà fait sur les paris sportifs servira de premier cas réel migré dans ce moteur, plutôt que d’être jeté.

(Modules identifiés mais volontairement mis de côté pour l’instant, le temps de poser ce socle : voir la section « Vision complète du projet » ci-dessous.)

Vision complète du projet

Le socle ci-dessus n’est que la première brique. Une fois posé, CCOP doit à terme couvrir l’ensemble de la gestion opérationnelle de mon service :

• Incident Manager — gestion des incidents spécifiques Casino / Poker / Dice, sur le même principe que l’Escalation Manager.
• Reporting Hub — préparation automatisée des chiffres et des KPI, plutôt que de les compiler à la main chaque semaine.
• Team Management — suivi de l’effectif, des compétences et de la présence de l’équipe.
• Change Management — suivi des projets d’amélioration et historique des évolutions de procédures.
• Grille horaire — planning d’équipe en vues semaine / mois / année.
• Communication interne — annonces et notes de service centralisées, pour ne plus dépendre uniquement des mails.
• Suivi qualité / Coaching — évaluations, feedback individuel et plans de progression des agents.
• Gestion des congés / absences — demandes et validations centralisées.
• Dashboard, Commercial Gesture Manager, Knowledge Base — déjà présents dans l’application sous une forme basique, mais que je recadrerai en détail un par un une fois le socle du Must Have posé.

Ces modules ne sont pas encore priorisés ni planifiés dans le temps — ils apparaîtront dans la roadmap active au fur et à mesure que je les attaque réellement.

Suivi

Je tiens à jour un changelog versionné à chaque livraison (numérotation sémantique, sections Ajouté/Modifié/Corrigé), sur le même principe que mes autres projets.