Technique<\/p>\n
Git c\u00f4t\u00e9 serveur, c’est lourd. Sur un h\u00e9bergement mutualis\u00e9 sans acc\u00e8s root, c’est carr\u00e9ment un probl\u00e8me. Voici l’alternative que j’utilise depuis 18 mois.<\/p>\n
Je dois modifier un mu-plugin (par exemple ajouter une r\u00e8gle de s\u00e9curit\u00e9 dans Un seul script bash en SSH qui :<\/p>\n Le tout en 30 lignes de bash. Pas de Git, pas de runners CI, pas de pipeline. Juste un script qui fait une chose et la fait bien.<\/p>\n Pour mon cas d’usage (un seul op\u00e9rateur, neuf sites, mu-plugins qui changent rarement), Git apporterait une complexit\u00e9 disproportionn\u00e9e par rapport au b\u00e9n\u00e9fice. Le co\u00fbt de la complexit\u00e9 Git (branches, merges, rebases, conflits, runners CI) d\u00e9passe largement le b\u00e9n\u00e9fice du versioning fin pour un d\u00e9ploiement qui se r\u00e9sume \u00e0 “copier ce fichier sur N machines identiques”.<\/p>\n Le versioning, je le fais via les archives daily ( Si vous \u00eates plusieurs d\u00e9veloppeurs avec des changements concurrents, ou si vos sites ont des configurations vraiment divergentes, Git devient n\u00e9cessaire. Mais pour un solo entrepreneur avec un portfolio uniforme, DISPATCH est radicalement plus simple et largement suffisant.<\/p>\n","protected":false},"excerpt":{"rendered":" Technique Comment je d\u00e9ploie un mu-plugin sur neuf sites en une commande. Git c\u00f4t\u00e9 serveur, c’est lourd. Sur un h\u00e9bergement mutualis\u00e9 sans acc\u00e8s root, c’est carr\u00e9ment un probl\u00e8me. Voici l’alternative que j’utilise depuis 18 mois. Le probl\u00e8me Je dois modifier un mu-plugin (par exemple ajouter une r\u00e8gle de s\u00e9curit\u00e9 dans security-hardening.php) et le d\u00e9ployer sur […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-62","post","type-post","status-publish","format-standard","hentry","category-non-classe"],"yoast_head":"\nsecurity-hardening.php<\/code>) et le d\u00e9ployer sur mes neuf sites WordPress. Solution na\u00efve : modifier sur le premier site via FTP, tester, puis r\u00e9p\u00e9ter neuf fois. C’est tedious et source d’erreurs.<\/p>\nLe pattern DISPATCH<\/h3>\n
\n
~\/upload-pack\/<\/code><\/li>\nSITES=(seed patashop sleepwell ...)<\/code>)<\/li>\nwp-content\/mu-plugins\/<\/code><\/li>\nL’exemple concret<\/h3>\n
#!\/bin\/bash\nSOURCE=~\/upload-pack\/security-hardening.php\nSITES=(seed patashop sleepwell bienetre40 shopbluedolomites tcbluedolomites maneuro yakapa bluedolomites)\n\nfor SITE in \"${SITES[@]}\"; do\n DEST=\"$HOME\/$SITE\/wp-content\/mu-plugins\/security-hardening.php\"\n cp \"$SOURCE\" \"$DEST\"\n chmod 644 \"$DEST\"\n echo \"\u2713 $SITE : d\u00e9ploy\u00e9\"\ndone\n<\/code><\/pre>\nPourquoi c’est suffisant<\/h3>\n
~\/_archives\/2026-06-03\/<\/code>) \u2014 ce qui me donne un historique chronologique des fichiers sans complexit\u00e9 d’arborescence Git.<\/p>\nQuand utiliser autre chose<\/h3>\n