Une plateforme d’hébergement souveraine pour plusieurs centaines de sites

Le point de départ

L’université héberge elle-même les sites de sa communauté : laboratoires, équipes de recherche, directions, enseignants. La plateforme qui les portait arrivait en fin de vie. Le socle système et les versions de langage étaient sortis du support, les sites n’étaient plus maintenables, et un pare-feu applicatif générique avait été posé en protection de dernier recours — sauf qu’il n’était compatible avec aucun des CMS hébergés. Résultat : les webmestres n’arrivaient plus à mettre à jour ni parfois à publier sur leurs propres sites.

La sécurité ne pouvait donc plus s’obtenir par ajouts successifs : sur ce socle, chaque protection posée cassait autre chose. Et le parc n’est pas homogène — à côté des sites de laboratoires, il porte des outils dont l’indisponibilité a des conséquences réelles, comme un calculateur clinique utilisé par des praticiens ou un outil mobilisé lors d’examens nationaux.

Le brief initial n’était pas la solution

La demande de départ était précise : monter un nouveau serveur sous Docker avec un panneau d’hébergement du marché, du type cPanel ou Plesk, puis y déplacer les sites tels quels sur une version de langage récente.

J’ai commencé par vérifier que ça tenait. Ça ne tenait pas. Ces panneaux sont faits pour administrer des comptes d’hébergement, pas pour piloter une flotte de conteneurs. Et déplacer des centaines de sites d’un bloc revenait à échanger un problème de sécurité contre une avalanche d’erreurs 500 dès le pilote.

J’ai donc repris le besoin réel avec les équipes, rédigé le cahier des charges, comparé les solutions du marché, puis conçu une architecture sur mesure assemblée à partir de briques open source et pilotée par une couche Python. Je l’ai proposée sous forme de POC de trois mois, pour que la décision se prenne sur une plateforme qui tourne et non sur un document. Le POC a convaincu : la mission est devenue un an de conception et de mise en production, sur un périmètre bien plus large que prévu au départ. Le cahier des charges et la feuille de route ont été tenus à jour d’un bout à l’autre.

L’architecture

Le plan de contrôle et le plan d’hébergement sont séparés. D’un côté les portails, l’API et les files de traitement ; de l’autre les nœuds qui font tourner les sites. Les deux communiquent par des tunnels, jamais en accès direct. Tout est conteneurisé, de bout en bout.

Ce que j’ai fait

• Une architecture plan de contrôle / plan d’hébergement, entièrement conteneurisée, conçue et mise en production depuis la feuille blanche.
• Une API d’orchestration en Python : provisionnement, migrations, sauvegardes et exploitation courante passent tous par le même point d’entrée, donc par les mêmes contrôles.
• Une interface en ligne de commande adossée à ces mêmes routes, pour que le support de niveau 3 agisse finement sans jamais toucher aux serveurs à la main.
• Le circuit de validation institutionnel, intégré à l’automatisation plutôt que posé à côté : une demande d’hébergement ou de nom de domaine part en validation auprès de la direction compétente, qui est notifiée, consulte le dossier, puis approuve ou refuse en justifiant. Le déploiement ou la migration ne se déclenche qu’après l’accord — l’automatisation n’a pas contourné la gouvernance, elle l’exécute.
• La migration des sites depuis la plateforme historique, site par site et par bascule de proxy — sans coupure de service, avec un retour arrière possible à chaque étape et une reprise automatique des incompatibilités détectées à l’arrivée.
• Plusieurs piles d’exécution en parallèle, plutôt qu’un déménagement en bloc : les applications métier qui ne peuvent pas être modernisées au rythme du reste tournent sur leur pile d’origine, isolées et encadrées, le temps que leur code soit corrigé.
• La gouvernance des extensions à l’échelle de la flotte : la DSI impose ou interdit une extension, et l’interdiction s’applique partout, y compris dans l’interface WordPress où le bouton d’installation est remplacé par un refus explicite.
• Un thème WordPress institutionnel entièrement en blocs (FSE), déployé par défaut sur chaque nouveau site, avec les déclinaisons graphiques des composantes.
• La sécurité et la résilience : pare-feu applicatif, détection d’intrusion, et sauvegardes isolées du réseau de production, en flux chiffré, avec rotation et rapport quotidien.
• La documentation d’exploitation par niveau de support, versionnée avec le code et publiée automatiquement vers le wiki de la DSI, et une documentation d’API générée depuis les tests.

La mission a aussi porté un site à part entière : l’intranet d’une direction de l’université, construit sur le thème en blocs de la plateforme. Entièrement privé derrière l’authentification centralisée, avec trois niveaux d’accès — la direction en édition, le personnel et les doctorants en lecture, le reste refusé automatiquement. Modèles d’actualités et d’événements en FSE, compositions prêtes à l’emploi, et trois blocs Gutenberg sur mesure — accordéon imbriqué, grille de boutons à icônes, carrousel — écrits pour rester conformes au RGAA. Côté RGPD, pas de bandeau de consentement intrusif : les cartes et les vidéos intégrées ne se chargent qu’après accord explicite. Livré en une vingtaine de jours, formation des éditeurs comprise.

Le périmètre était partagé : les deux interfaces web — le self-service des webmestres et le back-office d’administration de la flotte — ont été développées par un autre développeur, sur l’API et les workflows que j’ai conçus, documentés et maintenus.

Le résultat

89

routes d’API d’orchestration

190+

commandes d’exploitation en CLI

0

coupure de service sur les sites migrés

1 an

de mission, conception comprise

Une fois la demande validée, un site se crée en une commande, avec sa base, son conteneur, son certificat, son alias DNS et son accès délégué. Une montée de version se joue de façon outillée et réversible, site par site, sans exiger que tout le parc bouge en même temps — et un site fragile n’oblige plus à ralentir les autres.

Le dimensionnement a été établi par l’expérience, pas par estimation : des tests de charge successifs par paliers, jusqu’à 250 sites sur un seul nœud — soit plus de cinq cents conteneurs en comptant les bases de données. Ces paliers ont servi à figer une doctrine d’urbanisation : capacité de référence par nœud, gabarit standard des suivants, et bascule en architecture multi-nœuds au-delà. Chaque grappe de sites coûte donc une machine connue à l’avance, et une panne matérielle n’emporte jamais tout le parc. Le rythme de reprise, lui, est fixé par la gouvernance de l’université — chaque migration attend l’accord de la direction concernée — et non par l’outillage.

Le point qui compte pour la DSI : tout est documenté. La plateforme n’est pas restée dans la tête de la personne qui l’a construite, ce qui était une condition explicite du projet.

« Il s’est tout de suite approprié le projet, de la conception à la réalisation, soulevant les questions pertinentes et proposant des options techniques adaptées, pragmatiques mais sans concession sur la qualité et la sécurité. Son professionnalisme est remarquable : travailleur, transparent, véritable expert dans son domaine, il documente tout et c’est très appréciable. […] Bref, je le recommande sans aucune retenue. »

Ce que ça dit du reste

C’est le cas extrême de l’industrialisation : quelques centaines de sites obligent à écrire des règles là où une poignée de sites tolère encore la main. Mais la démarche est la même à toutes les échelles — rendre les gestes reproductibles, garder un retour arrière, et laisser derrière soi une documentation qui permet à quelqu’un d’autre de reprendre.

Le reste tient en une habitude : je vérifie la solution demandée avant de la construire. Sur un site vitrine comme sur une flotte, ça évite de payer deux fois — une fois pour la mauvaise réponse, une fois pour la bonne.

Si vous gérez un parc de sites WordPress qui grossit plus vite que votre équipe, c’est ce type de chantier dont il est question — le déroulé d’une mission, les briques et les jalons sont détaillés sur la page industrialisation & MCO de parc.