Industrialisation & MCO de parc WordPress
Des centaines de sites tenus par des règles, plus à la main.
Inventaire, socle imposé à la flotte, provisionnement en une commande, montées de version outillées et sauvegardes dont la restauration est prouvée. Pour les DSI, les institutions et les éditeurs dont le parc a dépassé ce qu’une équipe peut tenir geste par geste.
J’ai conçu et mis en production la plateforme d’hébergement de l’Université Paris-Saclay, qui reprend un parc de plusieurs centaines de sites WordPress et d’applications PHP. Les sites basculent par vagues, sans coupure de service, sur une architecture éprouvée en charge par paliers et conçue pour s’étendre nœud par nœud. Les équipes de la DSI l’ont fait évoluer depuis sans moi. Le brief de départ était d’installer un panneau du marché ; le premier livrable a été d’expliquer pourquoi ça ne tiendrait pas.
- 500
- sites dans le parc de l’université
- 1 an
- de mission, conception comprise
- 0
- outil propriétaire imposé
- L’infrastructure reste à votre nom
- Briques open source, aucun éditeur imposé
- Documentation versionnée avec le code
- Pilote réversible avant tout engagement
Pour qui
Quatre parcs qui ont atteint leur limite
Aucune n’est un problème de compétence, et ce n’est pas une formule de politesse : ce sont des problèmes d’échelle. Les mêmes gestes, refaits à la main sur cinquante sites, finissent par coûter plus cher que l’outil qui les remplace.
Chaque site du parc est un cas particulier
Versions de PHP différentes, thèmes bricolés, extensions installées au fil des demandes. Personne ne sait dire ce qui tourne où, et la moindre montée de version se termine en tickets. L’inventaire n’existe pas, donc le risque non plus — jusqu’au jour où il se manifeste.
La sécurité ne s’obtient plus par ajouts
On a posé un pare-feu, un plugin de sécurité, une règle de plus. Chaque protection casse autre chose, et les webmestres ne parviennent plus à publier. À ce stade le problème n’est plus la faille, c’est le socle : il faut le refaire, pas le rafistoler.
Le parc grossit plus vite que l’équipe
Créer un site prend une demi-journée d’interventions manuelles, et on en crée un par semaine. L’équipe passe son temps en exploitation courante au lieu de traiter ce qui compte. Ce n’est pas un problème d’effectif, c’est un problème de gestes non outillés.
Une personne tient tout dans sa tête
Le parc marche parce que quelqu’un sait. Rien n’est écrit, rien n’est reproductible, et son départ ou ses congés deviennent un risque d’exploitation. C’est la situation la plus courante, et celle dont personne n’aime parler en réunion.
Ce qu’on industrialise
Remplacer des interventions par des règles
Industrialiser un parc, ce n’est pas acheter un outil, c’est faire en sorte qu’un geste correct soit le geste par défaut. Voici les six chantiers, dans l’ordre où ils se traitent — et le premier n’est pas technique.
L’inventaire d’abord
Ce qui tourne, sur quelle version, avec quelles extensions, quel trafic et quelle criticité. Sans cet état des lieux, toute décision suivante est un pari. C’est aussi ce qui permet de dire à une direction combien de sites sont réellement exposés, avec des chiffres plutôt qu’une impression.
Un socle imposé à la flotte
Thème parent, MU-plugins de configuration, réglages de sécurité et constantes appliqués partout, versionnés, redéployables. Un site nouvellement créé naît conforme au lieu d’être mis en conformité après coup.
La gouvernance des extensions
Une liste d’extensions autorisées, une liste d’interdites, et l’interdiction qui s’applique réellement — jusque dans l’interface WordPress, où le bouton d’installation est remplacé par un refus explicite. Une règle qu’on ne peut pas contourner vaut mieux qu’une note de service.
Le provisionnement en une commande
Créer un site, le migrer, le sauvegarder, le supprimer : les mêmes opérations passent par le même point d’entrée, donc par les mêmes contrôles et les mêmes traces. Ce qui prenait une demi-journée devient une commande, et surtout devient reproductible à l’identique.
Les montées de version outillées
PHP, WordPress, extensions : par vagues, sur un échantillon d’abord, avec un plan de repli à chaque étape. Les applications qui ne peuvent pas suivre le rythme tournent sur leur pile d’origine, isolées et encadrées, le temps que leur code soit corrigé — plutôt que de bloquer tout le parc.
Sauvegardes isolées et restauration prouvée
Copies sorties du réseau de production, en flux chiffré, avec rotation et rapport. Et la restauration réellement essayée : une sauvegarde jamais restaurée est une hypothèse, pas une garantie. C’est ce qui transforme un incident en incident, au lieu d’en faire une crise.
Le détail de ces chantiers sur un parc réel se lit dans l’étude de cas de l’Université Paris-Saclay : architecture, circuit de validation, migration sans coupure et chiffres à l’appui.
Méthode
On ne migre rien avant d’avoir prouvé que ça tient
Une industrialisation ratée coûte plus cher que l’absence d’industrialisation, parce qu’elle laisse un parc à moitié migré que plus personne ne sait exploiter. D’où l’ordre ci-dessous, et surtout d’où le pilote : il existe pour que vous puissiez dire non au bout de quelques semaines plutôt qu’au bout d’un an.
1. Vérifier que la demande est la bonne
À Paris-Saclay, le brief était d’installer un panneau d’hébergement du marché et d’y déplacer les sites tels quels. J’ai vérifié : ça ne tenait pas. Ces panneaux administrent des comptes d’hébergement, ils ne pilotent pas une flotte de conteneurs. Le premier livrable est souvent la remise en cause du cahier des charges, écrite et argumentée.
2. Cadrer et chiffrer
Inventaire du parc, besoin réel repris avec les équipes, comparaison des solutions du marché, architecture cible et feuille de route. À l’issue du cadrage vous avez de quoi arbitrer, y compris celui de ne rien faire ou de confier la suite à quelqu’un d’autre.
3. Prouver sur un périmètre réduit
Un pilote de six à douze semaines sur une poignée de sites représentatifs, plutôt qu’un document de cinquante pages. La décision d’engager la suite se prend sur une plateforme qui tourne. À Saclay, ce pilote de trois mois est devenu un an de mission — mais la décision restait réversible au bout de trois mois.
4. Industrialiser, puis transmettre
Migration par vagues avec retour arrière possible à chaque étape, documentation d’exploitation par niveau de support versionnée avec le code, documentation d’API générée depuis les tests. L’objectif est que vos équipes reprennent la main : la mission Saclay s’est terminée par la passation aux équipes de la DSI, et c’est ainsi qu’elle devait finir.
Sur quoi ça tourne
Le choix des briques vient après l’inventaire
Cette section existe parce que vous allez me poser la question, et qu’un prestataire qui répond par un nom de produit avant d’avoir vu votre parc vous vend son habitude. Ce sont des briques que je sais assembler, pas une pile imposée.
Exécution
Conteneurs Docker ou Podman, sur vos machines ou celles de votre hébergeur. Podman avec systemd quand la réversibilité prime : pas d’orchestrateur propriétaire, des unités que n’importe quel administrateur système sait relancer. Kubernetes seulement si vous en avez déjà, et k3s plutôt qu’une distribution complète.
Plan de contrôle
Pour un parc modeste et une équipe autonome, une plateforme existante suffit — Coolify tient bien ce rôle. Au-delà, quand la gouvernance est le vrai besoin, c’est une API d’orchestration sur mesure en Python : c’est ce qui a été construit à Saclay, parce qu’aucun produit du marché ne sait exécuter un circuit de validation institutionnel.
Exploitation
Ansible pour l’idempotence et l’inventaire, parce que c’est ce que vos équipes savent déjà lire et reprendre. WP-CLI pour les gestes WordPress en masse. Sauvegardes par Restic ou Borg vers un dépôt isolé du réseau de production.
Gouvernance WordPress
Composer pour déclarer le cœur, le thème et les extensions avec leurs versions : le parc devient reproductible et auditable, et une mise à jour se relit avant de s’appliquer. Thème parent et MU-plugins pour ce qui doit être imposé, SSO pour que les accès suivent votre annuaire et pas une liste de comptes locaux.
La règle qui décide, quand deux options se valent
Je choisis celle que vos équipes pourront reprendre sans moi. Un orchestrateur élégant que personne chez vous ne sait déboguer un dimanche est un mauvais choix, même s’il est meilleur sur le papier. C’est aussi pour ça que je me méfie des plateformes portées par un seul éditeur : elles font gagner trois semaines à l’installation et posent une question désagréable cinq ans plus tard.
Tout ce qui est déployé est open source, l’infrastructure reste à votre nom, et la documentation d’exploitation vit dans le dépôt plutôt que dans ma tête. Si la mission s’arrête, le parc continue — c’est la seule définition de la réussite qui m’intéresse.
La preuve
Une plateforme souveraine pour plusieurs centaines de sites
Ce qui est décrit plus haut n’est pas une méthode théorique : c’est ce qui a été conçu, mis en production puis transmis à l’Université Paris-Saclay, pour un parc de sites WordPress et d’applications PHP portant aussi des outils métier dont l’indisponibilité avait des conséquences réelles.
- 89
- routes d’API d’orchestration
- 190+
- commandes d’exploitation en CLI
- 0
- coupure de service sur les sites migrés
Un pilote de trois mois devenu un an de mission, sur un périmètre bien plus large que le brief initial. Provisionnement, migrations, sauvegardes et exploitation courante passent tous par le même point d’entrée, donc par les mêmes contrôles. Le circuit de validation de l’université est exécuté par l’automatisation plutôt que contourné par elle.
« Damien a travaillé avec nous plusieurs mois sur la refonte d’une plateforme sécurisée d’hébergement de sites web pour notre communauté de chercheurs, enseignants, directions, laboratoires… 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. Cerise sur le gâteau, c’est quelqu’un de très agréable, souriant, communiquant, d’humeur égale. Bref, je le recommande sans aucune retenue. »
Comment ça se contractualise
Trois jalons, chacun décidé séparément
Une mission d’industrialisation ne se vend pas au forfait : personne ne peut chiffrer honnêtement la migration d’un parc qu’il n’a pas inventorié. Elle se découpe donc en jalons, et vous décidez à chacun d’eux — y compris de ne pas continuer.
Cadrage
2 500 € HT
cinq jours, déduits de la mise en œuvre
Inventaire du parc, besoin réel repris avec vos équipes, architecture cible et feuille de route chiffrée. Livrable exploitable même si vous vous arrêtez là, ou si vous confiez la suite à quelqu’un d’autre.
Pilote
6 à 12 semaines
décidé et facturé à part
Une poignée de sites représentatifs sur la plateforme cible, en conditions réelles. Séparé de la suite : c’est ce qui rend le renoncement possible, et c’est exactement à ça qu’il sert. À Saclay, ce pilote a duré trois mois — le haut de la fourchette.
Mise en œuvre
500 € HT / jour
au temps passé
Migration par vagues, outillage, documentation d’exploitation et transfert aux équipes. Sur une feuille de route établie au cadrage et tenue à jour d’un bout à l’autre.
Ce que je ne fais pas
- Je ne revends ni hébergement ni licence : l’infrastructure reste à votre nom, chez qui vous voulez
- Je ne pose pas mon outillage chez un client qui tourne déjà sous le sien — on part de votre socle
- Je n’industrialise pas un parc que personne ne veut exploiter ensuite : sans équipe pour reprendre, ça ne tient pas
- Jusqu’à une dizaine de sites tenus à la main, ce n’est pas encore de l’industrialisation : c’est de la maintenance
Le dernier point est le plus fréquent, et c’est souvent une bonne nouvelle : quelques sites tenus par la même personne relèvent d’un contrat de maintenance, qui coûte une fraction du prix et suffit largement.
Questions
Ce qu’on me demande avant de lancer un cadrage
À partir de combien de sites est-ce que ça vaut le coup ?
Le nombre de sites compte moins que la répétition des gestes. Jusqu’à dix sites tenus par la même personne, un contrat de maintenance coûte moins cher et suffit — c’est exactement là que s’arrête cette offre-là, les deux se rejoignent sans laisser de trou. Au-delà, ou dès que créer un site, le migrer ou le mettre à jour demande une suite d’actions manuelles refaite à l’identique plusieurs fois par mois, l’industrialisation se rembourse. Le vrai déclencheur est d’ailleurs souvent une échéance de sécurité ou une fin de support de version, pas un seuil de volume.
Combien ça coûte, et comment c’est facturé ?
Un forfait de cadrage à 2 500 € HT d’abord, soit cinq jours : inventaire du parc, architecture cible et feuille de route chiffrée. Il est déduit de la mise en œuvre si vous me la confiez, et le livrable reste exploitable par quelqu’un d’autre si vous vous arrêtez là. Puis la mise en œuvre au temps passé, à 500 € HT la journée. Le pilote, de six à douze semaines, se décide et se facture séparément du reste : c’est volontaire, il sert justement à ce que vous puissiez arrêter là.
Vous imposez votre plateforme ?
Non, et c’est un point sur lequel je ne transige pas. Le choix des briques vient après l’inventaire, jamais avant, et il tient compte de ce que vos équipes savent déjà exploiter. Poser un outil que personne chez vous ne sait reprendre, c’est fabriquer une dépendance à moi — l’inverse exact de ce que vous achetez. Toute la sortie est prévue dès le départ : infrastructure à votre nom, code et documentation chez vous, briques open source.
Que devient tout ça quand la mission se termine ?
Vos équipes exploitent, et je sors. C’est ce qui s’est passé à l’Université Paris-Saclay : la plateforme a été transmise aux équipes de la DSI, avec la documentation d’exploitation par niveau de support versionnée avec le code et publiée automatiquement vers leur wiki, et une documentation d’API générée depuis les tests. La mission s’est arrêtée en juillet 2026 ; la plateforme, elle, continue d’être développée par les équipes de l’université. C’est la seule preuve qui vaille : une industrialisation réussie se reconnaît à ce qu’elle continue sans son auteur.
On a des applications qui ne peuvent pas être modernisées tout de suite.
C’est la règle plutôt que l’exception, et ce n’est pas bloquant. Plusieurs piles d’exécution peuvent tourner en parallèle : les applications qui ne suivent pas le rythme restent sur leur pile d’origine, isolées et encadrées, le temps que leur code soit repris. C’est exactement ce qui a été fait à Saclay, où le parc portait aussi des outils métier dont l’indisponibilité avait des conséquences réelles.
Vous êtes seul. Un parc de plusieurs centaines de sites, ça se tient à une personne ?
La conception et l’outillage, oui — c’est même là qu’un intervenant unique est un avantage, parce que l’architecture reste cohérente. L’exploitation courante, non, et ce n’est pas le but : tout l’objet de la démarche est que vos équipes tiennent le parc sans moi. À Saclay j’ai encadré un développeur sur les interfaces, et le support de niveau 3 disposait d’une interface en ligne de commande pour agir sans jamais toucher aux serveurs à la main.
En quoi est-ce différent de votre contrat de maintenance ?
La maintenance tient des sites un par un, avec un abonnement mensuel par site : c’est adapté jusqu’à quelques sites. L’industrialisation traite le parc comme un ensemble, en remplaçant les interventions par des règles communes, et se vend en mission. Les deux se rejoignent sur le fond — un site à jour, sauvegardé et récupérable — mais pas sur le mécanisme ni sur l’acheteur.
Un parc de quelques sites seulement ? Le contrat de maintenance est fait pour ça.
Contact
Dites-moi ce qui coince
Un appel de quinze minutes suffit généralement à savoir si le sujet est pour moi. Si ce n’est pas le cas, je vous le dis franchement — et j’oriente quand je peux.