Digital Signage · SaaS B2B · Retail & franchises.
Conception et migration technique d'une plateforme SaaS de digital signage pour réseaux de franchises.
Le contexte
J'ai participé à cette plateforme de digital signage dès la V1 : un back-office conçu pour permettre à des réseaux de franchises de gérer le contenu diffusé sur leurs écrans en point de vente — playlists, médias, plannings de diffusion, gestion des terminaux. La V1 a été développée sous Nuxt 2. Elle posait les fondations fonctionnelles de la plateforme : le modèle de données, l'architecture multi-tenant, les workflows de gestion de contenu. Avec la croissance du parc et la multiplication des clients internationaux, la base technique atteignait ses limites : dette technique accumulée, impossibilité de faire évoluer les modules à la même vitesse, et une architecture d'API insuffisamment robuste pour les volumes montants. En juin 2025, j'ai réalisé la migration technique complète vers Nuxt 4 et une refonte de l'API. L'interface utilisateur n'a pas changé — les équipes ont retrouvé leurs repères — mais tout le socle technique a été repensé.
Ce que j'ai construit
La plateforme repose sur deux applications que j'ai développées : un back-office (Nuxt 2 puis Nuxt 4) et une API (NestJS + PostgreSQL + Redis). L'architecture globale intègre également un Player (diffusion sur les écrans) et un Portail clients — développés par d'autres équipes — avec lesquels le back-office et l'API communiquent via une architecture asynchrone Redis/BullMQ. Chaque client correspond à une instance isolée. La plateforme gère 11 rôles distincts : du super-administrateur jusqu'à l'opérateur de contenu en boutique, avec des permissions granulaires sur chaque module.
Mon Rôle
V1 : Conception et développement du back-office (Nuxt 2) et de l'API initiale. Définition du modèle de données, architecture multi-tenant, premiers modules de gestion de contenu. V2 (juin 2025) : Migration technique complète vers Nuxt 4 + Tailwind CSS 4 + PrimeVue 4, refonte de l'API NestJS (PostgreSQL + TypeORM + Redis + BullMQ), système de 11 rôles et permissions, intégration AWS. Mise en place des pipelines qualité et CI/CD.
Architecture technique
| Couche | Technologie |
|---|---|
| Front-end V1 | Nuxt 2 · Vue 2 · TypeScript |
| Front-end V2 (juin 2025) | Nuxt 4 · TypeScript · Tailwind CSS 4 · PrimeVue 4 |
| State management | Pinia |
| Validation formulaires | VeeValidate · Zod |
| API Backend | NestJS · TypeScript · PostgreSQL · TypeORM |
| Files d'attente asynchrones | Redis · BullMQ (synchro écrans, encodage) |
| Stockage médias & emails | AWS S3 · AWS SES |
| Documentation API | Swagger |
| Qualité code | Husky · Commitlint · Prettier · Lint-staged |
| CI/CD & déploiement | Docker · GitLab CI/CD · gestion des branches et MEP |
Défis techniques
Migration V1 → V2 sans rupture de service : La migration Nuxt 2 → Nuxt 4 a été réalisée sans changer l'interface utilisateur. Les équipes ont retrouvé leurs workflows à l'identique — mais sur une base technique entièrement modernisée, sans dette.
Multi-tenant avec isolation stricte : Chaque client est une instance isolée. Les données d'un réseau ne sont jamais accessibles à un autre, par construction dans l'architecture.
11 rôles distincts à orchestrer : Du super-admin jusqu'à l'opérateur en magasin, chaque rôle dispose d'un périmètre précis sur chaque module — sans chevauchement. Un challenge architectural complexe sur un modèle de permissions granulaire.
Synchronisation fiable à grande échelle : Architecture asynchrone (Redis + BullMQ) pour gérer uploads, encodages et mises à jour d'écrans sans bloquer l'interface.
Playlists hiérarchiques : Le siège définit un contenu par défaut par pays/langue. Les franchisés peuvent personnaliser localement sans affecter la configuration globale.
Médias volumineux (vidéos 4K) : Intégration AWS S3 avec URLs signées — l'API orchestre sans jamais manipuler les flux, pour des performances optimales.
Pipeline GitLab CI/CD : Build Docker automatisé sur chaque push, déploiement déclenché par branche (develop → staging → production). Mise en production maîtrisée sans intervention manuelle sur les serveurs.
Problèmes résolus
| Avant | Après |
|---|---|
| Base technique V1 (Nuxt 2) avec dette accumulée, évolution de plus en plus coûteuse | Migration technique V2 (Nuxt 4) → stack moderne, modules évolutifs, zéro changement perçu par les utilisateurs |
| Gestion des rôles insuffisante pour les grands réseaux internationaux | 11 rôles distincts avec permissions modulaires → chaque niveau dispose exactement du bon périmètre |
| Désynchronisation fréquente du contenu sur les écrans | Architecture Redis/BullMQ → synchro fiable en temps réel, sans perte de commande |
| Matériels hétérogènes difficiles à piloter depuis une interface unique | Couche d'abstraction logicielle → interopérabilité totale quel que soit le hardware |
| Déploiements manuels, risqués et chronophages | Pipeline GitLab CI/CD → build et MEP automatisés, reproductibles à chaque push |
Résultats
"La migration V2 a livré une base technique moderne sans perturber les utilisateurs existants. Les contenus sont synchronisés de façon fiable sur l'ensemble du parc d'écrans. Chaque niveau de l'organisation — siège, country manager, franchisé, opérateur boutique — dispose exactement du bon périmètre d'action. Les déploiements sont automatisés et sûrs."
En chiffres
11 rôles distincts avec permissions granulaires
+40 modules métiers interconnectés
Migration Nuxt 2 → Nuxt 4 sans changement d'UI
Synchro des écrans via Redis/BullMQ
100% des formulaires critiques validés avec Zod
Pipeline GitLab CI/CD automatisé — du push à la MEP
Pour vous
Vous gérez un réseau distribué — franchises, points de vente, agences — et votre outil de pilotage ne tient plus la charge ou accumule de la dette technique ? Vous avez besoin de déléguer précisément les droits à chaque niveau sans risque pour la configuration globale ? Cette architecture multi-tenant est applicable à tout SaaS B2B à niveaux d'accès multiples.