Distribution
de contenus
par bornes.
Architecture cible de la plateforme de publication backoffice et de synchronisation multi-protocoles vers les bornes.
D'un monolithe
à quatre rôles.
Aujourd'hui, application web, base de données, stockage de fichiers et serveur SFTP cohabitent sur une seule machine. L'objectif est de découpler ces responsabilités en quatre VM, tout en préparant une transition douce du SFTP vers HTTP pour la synchronisation des bornes.
Existant
Une machine unique héberge le développement, le stockage, le serveur web du backoffice et le ProFTPD utilisé par les bornes pour se synchroniser. Tout est couplé : impossible de faire évoluer un composant sans risque sur les autres, aucune isolation entre rôles, scalabilité nulle.
Cible
Une plateforme distribuée sur quatre VM aux responsabilités strictes. Le backoffice pousse des fichiers taggés ; chaque borne, via son utilisateur dédié, n'accède qu'aux fichiers que ses tags autorisent. La synchronisation continue en SFTP pour les bornes existantes, et monte en HTTP pour les nouvelles.
Les quatre
machines virtuelles.
App
- Nginx + PHP-FPM
- Backoffice (humains)
- API
/manifest&/upload - Aucune donnée persistante locale
- Duplicable pour HA future
DB
- MariaDB / MySQL
- Une seule base, deux consommateurs
- Vues compatibles ProFTPD
- Backups quotidiens
- Bind sur réseau privé uniquement
Storage
- Nginx HTTPS public (URL signées)
- Nginx HTTP interne (uploads)
- NFS export (lectures internes)
- /srv/storage — gros volume
- Snapshots & backup externes
ProFTPD
- ProFTPD + mod_sql + mod_vroot
- Auth via VM DB
- Fichiers via NFS depuis Storage
- Aucune donnée locale
- Éteindra le jour J de la bascule
Vue d'ensemble
réseau & flux.
Trois entrées Internet : le backoffice et l'API HTTP des bornes via la VM App,
le téléchargement direct des fichiers via la VM Storage (URL signées HMAC),
et le SFTP via la VM ProFTPD. Tout le reste est confiné dans le réseau privé
10.0.0.0/24.
Quatre scénarios
de bout en bout.
Les flux ci-dessous représentent les quatre cas d'usage principaux : un humain qui publie, une borne moderne qui synchronise en HTTP, une borne legacy qui synchronise en SFTP, et un humain qui navigue dans le backoffice.
Le backoffice publie un fichier
Standard
Un humain uploade promo-mai.mp4
(2 Go) avec les tags [borne-paris-01, region-sud].
▸ Résultat : le fichier est dans /srv/storage/ab/cd/<sha>,
référencé en DB, et toute borne portant un des deux tags va désormais le voir, en HTTP comme en SFTP.
Une borne synchronise en HTTP
Cible
La borne borne-paris-01
interroge l'API, reçoit un manifest avec URL signées, télécharge en direct depuis Storage.
▸ Point clé : la VM App ne voit jamais passer les 2 Go, juste un manifest JSON. Le téléchargement va direct de Storage à la borne.
Une borne synchronise en SFTP (legacy)
TransitionMême borne, même fichier, mais via le protocole historique. ProFTPD authentifie via la DB et sert les fichiers depuis le mount NFS de Storage.
▸ Le trafic est relayé par ProFTPD : moins efficace que le mode HTTP direct, mais opérationnel pour la transition. ProFTPD sera éteint quand la dernière borne sera migrée.
Navigation backoffice & preview
Standard
Un humain navigue dans la liste des fichiers, prévisualise une vidéo,
édite ses tags. Le streaming de preview utilise X-Accel-Redirect
via le mount NFS pour ne pas charger PHP.
▸ X-Accel-Redirect permet à PHP de déléguer le streaming à Nginx tout en gardant la main sur l'autorisation. Le code PHP retourne juste un header, pas de body.
Tableau
des flux réseau.
| De | Vers | Port | Protocole | Usage |
|---|---|---|---|---|
| Internet | App | 443 | HTTPS | Backoffice humains + API bornes HTTP |
| Internet | Storage | 443 | HTTPS | Téléchargement bornes (URL signées HMAC) |
| Internet | ProFTPD | 22 | SFTP | Bornes SFTP (transition) |
| App | DB | 3306 | MySQL | Requêtes SQL |
| App | Storage | 8080 | HTTP | Upload backoffice (PUT) |
| App | Storage | 2049 | NFS | Lecture fichiers (preview, audit) |
| ProFTPD | DB | 3306 | MySQL | Authentification + vroot mappings |
| ProFTPD | Storage | 2049 | NFS | Lecture fichiers à servir |
| App | ProFTPD | 8081 | HTTP | Webhook resync vroot |
Six points
structurants.
Une seule source de vérité
La VM DB est référente. Les vues SQL exposent la même donnée aux deux protocoles (HTTP et SFTP) sans duplication.
Tags = vroot dynamique
Pas de mapping manuel. Un fichier taggué borne-paris devient automatiquement visible par toutes les bornes du tag.
VM App jamais dans le flux gros
Les téléchargements de plusieurs Go vont en direct Storage ↔ borne. PHP traite seulement l'autorisation.
URL signées HMAC natives
Module secure_link de Nginx, vérification HMAC sans dépendance externe. 100 % PHP + Nginx.
Transition douce SFTP → HTTP
Les deux protocoles coexistent sur la même donnée. ProFTPD s'éteint quand la dernière borne est migrée.
Préparé pour la HA
App et ProFTPD stateless, duplicables. DB et Storage centralisés. Le jour J : zéro refactoring applicatif.
État des lieux
& obstacles.
L'architecture cible décrite plus haut se heurte à un existant contraint. Un backoffice PHP monolithique qui fonctionne mais n'est plus adapté, une base de données qui cumule les problèmes (tables mutualisées, non sécurisée, exposée au WAN), un parc de bornes fragmenté avec secrets en dur, et une machine monolithique qui héberge bien plus que le backoffice — boîte mail comprise.
Diagramme de l'existant
Problèmes identifiés
Le backoffice PHP : fonctionnel mais inadapté
Sévérité haute- Il fonctionne — mais il n'est plus adapté. Le backoffice tourne aujourd'hui, les équipes l'utilisent. Ce n'est pas l'usage actuel qui pose problème, c'est tout ce qu'on ne peut plus faire avec : nouvelles fonctionnalités, nouveaux usages, intégration de protocoles modernes, audit de sécurité, scalabilité.
- Monolithique, ancien, non décomposable. Toutes les responsabilités (auth, upload, gestion fichiers, exposition SFTP) cohabitent dans le même code base. Impossible d'isoler ou de faire évoluer une fonction sans risque transverse.
- Performance et stabilité : suffisantes pour l'existant. Adéquates à l'usage actuel, mais pas dimensionnées pour les évolutions à venir (volume bornes, taille des fichiers, nouveaux flux). Pas de marge.
- Surface de sécurité étendue. Couplages internes qui rendent les audits et les correctifs de sécurité longs, risqués, et difficiles à valider.
- Non re-codable en l'état actuel. Pas de volonté ni d'approbation hiérarchique de procéder à une réécriture, secondairement renforcé par un manque de ressources humaines. L'obstacle est politique avant d'être technique ou budgétaire.
La base de données
Sévérité critique- Tables mutualisées entre périmètres. Plusieurs applications/scopes écrivent dans les mêmes tables — impossible d'ajouter ou modifier un schéma sans risque transverse.
- Non sécurisée. Permissions trop larges, pas de cloisonnement par rôle, credentials partagés.
- Exposée au WAN. Le port MariaDB/MySQL accepte des connexions depuis Internet. C'est le point bloquant n°1 à traiter, indépendamment du reste.
- Aucune politique de migration possible. On ne peut pas ajouter de tables propres dedans sans aggraver le couplage.
Stockage & SFTP couplés au monolithe
Sévérité moyenne- Fichiers sur le même disque que le code. Un crash applicatif peut affecter le stockage. Backup, audit et capacité sont liés.
- ProFTPD lit le stockage local et la même DB. Le sync des bornes est dépendant de la santé globale du monolithe.
- Dev et prod confondus. Une opération de dev peut affecter la prod, pas d'environnement d'essai isolé.
Les applications clientes des bornes
Sévérité haute- Code écrit en dur sur chaque borne. Pas de configuration externalisée. Une modification de protocole, d'URL ou de credentials impose une mise à jour applicative sur le terrain. Des outils de prise en main à distance existent et donnent un accès direct, mais l'opération reste coûteuse en temps : intervention borne par borne, sans parallélisation possible.
- Fragmentation du parc. Plusieurs versions du même module coexistent sur les bornes. Le comportement d'une fonctionnalité n'est pas homogène — il dépend de la version installée localement.
- Deux mots de passe partagés, en dur — un par protocole. Un secret unique pour les requêtes SQL directes, un autre pour le SFTP. Distincts par protocole, mais chacun est partagé entre toutes les bornes du parc et hardcodé dans le code client. C'est le secret SQL qui explique l'exposition de la DB au WAN (catégorie B) : les bornes attaquent la base en direct depuis Internet.
- Pas de rotation possible. Changer l'un des deux mots de passe oblige à redéployer toutes les bornes une à une (cf. premier point). Si une seule borne est compromise, c'est l'ensemble du parc qui l'est, pour le protocole concerné.
- Migration ≈ 33 % du parc applicatif borne. Environ un tiers des applications déployées sur les bornes doivent être réadaptées au nouveau protocole (HTTP + auth propre, secrets gérés). Le ratio concerne le nombre d'applis à reprendre, pas le volume de code par appli.
Une machine fourre-tout aux actifs précieux
Sévérité haute- La machine monolithique n'héberge pas que le backoffice. On y trouve aussi la boîte mail, et probablement d'autres services accumulés au fil du temps : scripts cron, partages, secrets locaux, dépôts de fichiers, configurations critiques.
- Des actifs précieux à préserver. Mails archivés, identifiants stockés, configurations métier uniques — autant d'éléments qui doivent être préservés et migrés au moment de la bascule. Le risque principal : découvrir une dépendance non documentée le jour J.
Contraintes induites pour la migration
▸ Le nouveau monde se construit en parallèle. Le jour J, on bascule. Voir § 08.
▸ Donnant-donnant : un effort un peu plus large maintenant, contre un parc cohérent et beaucoup plus simple à maintenir ensuite. Pas de coût client supplémentaire — l'intervention est de toute façon prévue.
Stratégie : V2 propre, puis bascule maîtrisée
On abandonne l'idée d'envelopper indéfiniment le legacy. Le backoffice fonctionne, mais il n'est plus adapté — on le laisse tourner jusqu'au jour J, et on construit en parallèle un backoffice V2, propre, sur la nouvelle architecture 4 VM décrite au § 02. Le jour de la bascule, on accepte une fenêtre de coupure courte (≈ 1 jour) pour faire les choses bien — plutôt que des mois de cohabitation fragile entre deux mondes.
Inventorier la machine actuelle
Audit complet de tout ce qui tourne sur la machine monolithique : backoffice, DB, ProFTPD, mais aussi boîte mail, scripts, secrets, partages, configurations. On ne migre bien que ce qu'on a identifié. Sans cet inventaire, la bascule est impossible.
Construire la V2 en parallèle
Développement du nouveau backoffice sur l'infra 4 VM, sans rien casser de l'existant. La V2 a sa propre DB propre, sa propre UI, sa propre logique métier. Pendant ce temps, le legacy continue de tourner normalement.
Préparer la migration des données
Scripts de migration : transfert des fichiers vers la nouvelle VM Storage, import des users/tags/fichiers depuis la DB legacy vers la nouvelle DB propre, migration de la boîte mail et des autres actifs identifiés. Tout est répété en blanc sur un environnement de staging avant le jour J.
Le jour J — bascule en 1 journée
Coupure courte mais réelle. On gèle l'ancien, on rejoue la migration en réel, on bascule le DNS, on vérifie, on rouvre. Une journée de downtime planifiée et communiquée vaut mieux que six mois de cohabitation chaotique. Le legacy est ensuite figé en lecture seule, puis éteint quand on est sûr de la V2.
▸ Conséquence sur le schéma cible : la « VM DB » présentée au § 02 n'est pas la DB actuelle. Tout est neuf : nouveau code, nouvelle base, nouvelle UI. La machine monolithique sera éteinte une fois la bascule validée et tous ses actifs périphériques migrés.
Une V2 propre,
une journée de bascule.
Le backoffice actuel fonctionne. Il n'a pas besoin d'être patché en urgence. Mais il n'est plus adapté aux besoins à venir, et son architecture interdit toute évolution sereine. La bonne réponse n'est pas de l'envelopper indéfiniment — c'est de construire une V2 propre à côté, puis de basculer.
La V2 n'est pas seulement plus propre techniquement et plus belle visuellement. C'est aussi l'occasion de débloquer les fonctionnalités attendues par les contributeurs et les clients — celles qui dorment dans le backlog faute de pouvoir les coder dans le legacy. Backoffice innovant = clients contents = ARGENT ! Le projet n'est plus une dépense, c'est un investissement.
Une journée de coupure planifiée vaut mieux que six mois de cohabitation chaotique entre deux mondes. Le jour J, on bascule. Le legacy est figé, puis éteint quand on est sûr de la V2 et qu'on a migré tous les actifs périphériques de la machine actuelle (boîte mail incluse).
Le périmètre de la V2
La V2 n'est pas une rustine sur l'existant. C'est un nouveau backoffice complet, écrit proprement, sur la nouvelle infra. Le legacy n'est pas touché — il continue à tourner jusqu'au jour de la bascule, puis il est éteint.
Nouveau code, base saine
- Application PHP propre, architecturée par responsabilités
- UI moderne, ergonomique, accessible
- Auth & gestion des secrets externalisées
- API HTTP
/manifest,/upload, signed URLs - Tests minimaux sur les points névralgiques
Pourquoi from scratch : reprendre le code legacy reviendrait à hériter de tous ses problèmes. Coût marginal d'une réécriture propre vs un patching infini : largement favorable à la réécriture.
Adaptation côté client
- Module de communication serveur (SFTP → HTTP)
- Module de credentials (hardcodé → stockage local propre)
- Module de checksum & reprise sur erreur
- Mécanisme de rotation à distance des secrets
Pourquoi obligatoire : environ un tiers des applis du parc parlent à l'ancien serveur. Sans adaptation côté client, le nouveau protocole n'a pas d'usage. Tournée d'enrôlement nécessaire (accès direct disponible, mais borne par borne).
Outillage de bascule
- Inventaire & cartographie de la machine actuelle
- Migration des fichiers vers la VM Storage
- Import users / tags / fichiers vers la DB V2
- Migration boîte mail & autres actifs périphériques
- Rejeu sur staging avant le jour J
Pourquoi crucial : la qualité de la migration conditionne la durée de la coupure. Un script éprouvé en staging = bascule en quelques heures. Improvisation = bascule qui s'étale sur des jours.
L'opportunité : refonte visuelle, technique et fonctionnelle
Puisqu'on écrit une V2 complète, autant la faire juste, mais aussi utile. Pas seulement remplacer le moteur ni moderniser la peinture — mais aussi ajouter ce qui manque : les fonctionnalités attendues par les contributeurs, les capacités qui font la différence face à la concurrence, ce qui transforme un outil interne en levier de valeur business.
Une UI à la hauteur de l'usage
La V2 est l'occasion de refondre la couche de présentation : ergonomie, accessibilité, cohérence graphique, expérience contributeur. Une UI moderne et claire est un gain de productivité direct et un argument de rétention des talents.
- Design system cohérent, documenté
- Workflow de publication repensé (drag & drop, tags, prévisualisation)
- Accessibilité & responsive
- Identité visuelle modernisée
Une base saine pour 10 ans
La V2 est aussi l'occasion de poser un socle technique propre : séparation des responsabilités, gestion des secrets externalisée, schéma DB normalisé, tests minimaux. Sans cathédrale — juste l'essentiel pour ne pas reconstruire la même dette.
- Couche d'auth & secrets séparée du métier
- Schéma DB normalisé, isolé par périmètre
- Tests minimaux sur les modules sensibles
- Documentation à jour des points névralgiques
Innovation = valeur business
La V2 est surtout l'occasion d'ajouter les fonctionnalités attendues, longtemps repoussées par l'inadaptabilité du legacy. Backoffice innovant = clients contents = ARGENT ! C'est l'argument qui transforme un coût en investissement.
- Nouvelles fonctionnalités en backlog depuis des mois
- Capacité à répondre aux demandes clients en jours, pas en mois
- Différenciation produit vs concurrence
- Effet rétention & acquisition mesurable
L'argument économique consolidé : coupler refonte visuelle, réécriture technique et enrichissement fonctionnel dans le même projet V2 transforme une dépense en investissement. Le retour sur investissement n'est plus seulement défensif (risques évités, dette maîtrisée) — il devient offensif : nouvelles fonctionnalités vendables, satisfaction client mesurable, capacité d'innovation retrouvée. Un backoffice qui suit le rythme du marché, c'est du chiffre d'affaires qui ne fuit pas.
Crédibilité technique vis-à-vis des partenaires
Une infrastructure propre n'est pas seulement utile en interne. Elle ouvre des portes vers l'écosystème : intégration de partenaires, échanges de données, éligibilité à des appels d'offres exigeants. C'est un levier commercial sous-estimé.
Ce qu'il faut faire entendre à la direction
Le backoffice fonctionne. Il n'y a pas d'urgence à l'arrêter aujourd'hui. Mais il faut accepter, et financer, une V2 propre — avec un jour de bascule assumé. Deux options s'offrent à la décision :
Cohabitation prolongée
Maintenir le legacy en parallèle de la V2 pendant des mois, synchroniser les deux mondes, multiplier les ponts. Pas de downtime apparent, mais une dette opérationnelle permanente et un risque de divergence des données.
Coût : élevé et étalé. Complexité, fragilité, double maintenance, équipes mobilisées sur deux fronts. Le jour où on voudra couper le legacy, le problème sera entier.
Bascule en 1 jour, V2 propre
La V2 est développée à part, testée, puis déployée le jour J avec une fenêtre de coupure planifiée et communiquée. Migration complète des données et actifs périphériques dans la même opération. Le legacy s'éteint proprement après validation.
Coût : concentré sur la phase projet, mais propre, net et borné. 1 journée de down planifiée pour faire du propre plutôt que des mois de cohabitation chaotique.
Une fois livrée, la V2 est un actif pérenne.
Le système devient stable. Le legacy s'éteint, la maintenance se réduit à l'essentiel, les équipes ne courent plus après les bugs et les contournements. Les ressources qui passaient leur temps à « tenir » l'existant sont libérées — et peuvent enfin contribuer à ce qui fait vraiment la valeur : nouvelles applications, nouveaux produits, nouveaux marchés.
Le projet V2 n'est pas une fin. C'est le point de départ de tout ce qu'on ne peut pas faire aujourd'hui.