Publier vos fichiers automatiquement et en toute sécurité

#GitLab #CICD #WordPress #rsync #git

Avec WordPress en 2026/27 la customisation de thèmes et la création de petit plugins n’ont jamais été aussi simple. Cela implique par contre d’éditer des fichiers dans notre site et seulement tout gérer par l’admin de WordPress.

Crée un theme sur mesure avec son fichier functions .. ou un plugin pour simplifier notre utilisation.

Pendant des années, ma mise en ligne c’était du FTP. Puis du FTP un peu automatisé, avec « gulp » et son « super » plugin « vinyl-ftp ». Et depuis quelques temps avec mes expériences sur le métier de DevOps et le CI/CD, je fais un git push et .. c’est tout. Voici ce que le CI/CD a changé dans mon quotidien.

Le FTP

Le FTP, ça marche. J’ai livré des dizaines de sites comme ça. Mais il y a toujours ce moment de flottement. Est-ce que j’ai bien envoyé le functions.php ? Et la feuille de style, je l’ai poussée avant ou après ma dernière correction ? On ouvre « FileZilla », on compare les dates, on doute, on renvoie tout « pour être sûr ».

J’avais amélioré ça avec « gulp » et « vinyl-ftp », qui surveillait mes fichiers et les envoyait tout seul. C’était déjà beaucoup mieux. Mais ça restait aveugle : le script envoyait à chaque sauvegarde c’est top, mais aucune trace. Si je cassais quelque chose, il n’y avait pas de retour en arrière.

le CI/CD nous apporte quoi

Le CI/CD, c’est simplement dire à « GitLab » : à chaque fois que je pousse mon code, fais ces choses-là à ma place. Dans mon cas, deux choses : vérifier que mon PHP n’est pas cassé, puis synchroniser les fichiers sur le serveur.

Et c’est là que le déclic se fait. Le vrai gain, ce n’est pas le temps gagné — le FTP n’était pas si lent. C’est le suivi exact : je sais précisément quels fichiers sont partis, à quel moment, et avec quel commit. Plus de doute, plus de « pour être sûr ». Et par-dessus, un historique : chaque mise en production correspond à un point précis dans mon dépôt, sur lequel je peux revenir.

Comment ça marche, en gros

La mécanique tient en quatre étapes, et aucune n’est compliquée prise séparément :

Je fais un git push, mon code arrive sur « GitLab ».
« GitLab » allume une machine jetable — on appelle ça un « runner » — qui récupère mon dépôt.
Cette machine se connecte à mon serveur en SSH, avec une clé dédiée.
Elle lance « rsync », qui ne copie que les fichiers réellement modifiés.

Tout ça tient dans un seul fichier, .gitlab-ci.yml, à la racine du dépôt. Une quarantaine de lignes. Voici le cœur du truc :

deployer:production:
  stage: deployer
  image: alpine:3.20
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - |
      rsync -azc --delete \
        -e "ssh -i /root/.ssh/id_deploy -o IdentitiesOnly=yes" \
        "$chemin/" \
        "$DEPLOY_USER@$DEPLOY_HOST:$DEPLOY_PATH/$chemin/"

Deux options méritent un mot. Le -c demande à « rsync » de comparer les fichiers par leur empreinte et non par leur date : sans lui, comme la machine jetable récupère le dépôt avec des dates toutes fraîches, il renverrait l’intégralité du thème à chaque fois. Et le --delete supprime côté serveur ce qui a disparu du dépôt — puissant, mais à manier avec respect. Faites toujours un essai à blanc avec --dry-run avant le premier vrai déploiement, et cherchez le mot deleting dans le résultat.

Bonne nouvelle au passage : tout ça fonctionne très bien sur un hébergement mutualisé « cPanel » ou « Infomaniak ». Pas besoin de Docker, de VPS ou d’usine à gaz. Un accès SSH suffit.

Liens vers le tuto que Claude m’as aider à rédiger

Tutorial CI/CD publication (notion)

Les quack ..

Parce que non, ça n’a pas marché du premier coup .. et c’est bien ça que les tutos ne racontent jamais.

1. Variable ou fichier ?

Ensuite : Identity file /root/.ssh/id_deploy not accessible. La clé n’était tout simplement pas là. En cause, un détail que je n’avais pas vu : dans les réglages CI/CD de « GitLab », une variable peut être de type « Variable » ou de type « File ». En type « File », « GitLab » écrit la valeur dans un fichier et la variable contient le chemin de ce fichier. En type « Variable », elle contient le texte. Mon script attendait un chemin et recevait une clé privée complète .. forcément.

Faut-il se lancer ?

Il y a un prérequis, et je ne vais pas vous mentir dessus : il faut être à l’aise avec « git ». Commits, branches, remote .. si ces mots ne vous disent rien, commencez par là, le reste viendra tout seul. J’ai utilisé « GitLab », mais « GitHub » propose exactement la même chose avec « GitHub Actions », la logique est identique.

Comptez une bonne soirée pour la première mise en place, entre les clés SSH, les variables et les inévitables essais. Mais une fois que c’est en place, c’est en place. Mon prochain site client partira sur le même modèle, en dix minutes.

Franchement, un monde s’ouvre à vous. Et vous, vous déployez comment ? Toujours au FTP, ou vous avez sauté le pas ? J’adorerais avoir vos retours !

J’ai arrêté de pousser mes fichiers à la main