Déployer sur votre propre serveur signifie confier à un agent un accès de type SSH à une machine que vous payez, sur laquelle d'autres choses vivent peut-être déjà. C'est un niveau de confiance différent de la publication sur un sous-domaine gratuit, et la configuration le reflète — quelques champs, remplis une fois, puis chaque build après ça n'est qu'un bouton. Voici ce que les gens demandent réellement avant et après en avoir configuré une.
De quoi ai-je besoin pour créer une cible ?
Cinq choses, dans Paramètres → Déploiement :
- Un nom que vous reconnaîtrez plus tard — « prod-vps », « client-hostgator », peu importe ce qui survit dans une liste déroulante à 23h
- Hôte et port
- Identifiants SFTP
- Un chemin de webroot
Pas de token API, pas de CLI à installer sur le serveur, pas de tâche cron à surveiller. Si votre hébergeur fournit un accès SFTP — ce qui couvre presque tous les hébergements mutualisés, tous les VPS, toutes les instances WordPress gérées — vous en avez pour environ deux minutes.
Mot de passe ou clé ?
Une clé, si votre hébergeur le permet. Les mots de passe fonctionnent très bien et nous les stockons de manière limitée à votre compte, mais une clé, c'est un secret de moins qui traîne quelque part — la différence entre « révoquer une clé » et « réinitialiser un mot de passe partout où il a pu être réutilisé » si quelque chose tourne mal plus tard. Beaucoup d'installations SFTP d'hébergement mutualisé bon marché ne proposent que l'authentification par mot de passe, et c'est aussi très bien. Simplement, ne réutilisez pas ce mot de passe ailleurs.
Comment trouver le bon chemin de webroot ?
C'est le champ que les gens se trompent la première fois, parce que la mauvaise réponse a encore l'air plausible. Ce n'est pas votre répertoire personnel, ce n'est pas /var/www — c'est le dossier exact que votre serveur web est configuré pour servir.
| Serveur | Webroot typique |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — ou un chemin qu'un développeur précédent a nommé il y a trois ans pour des raisons que personne ne se rappelle |
Si vous n'êtes pas sûr, déposez un fichier jetable test.txt dans le dossier que vous pensez être le bon avec n'importe quel client SFTP, puis vérifiez s'il se charge à yoursite.com/test.txt. Si vous vous trompez, le déploiement affichera quand même un succès — l'agent écrit fidèlement les fichiers dans le mauvais dossier, et vous vous retrouvez à fixer un site en production qui n'a pas changé, en vous demandant pourquoi.
Une seule cible peut-elle couvrir plusieurs domaines ?
Oui, et c'est ce qui fait gagner du temps une fois passé votre premier site. Une cible correspond à un serveur et un ensemble d'identifiants — elle n'est pas liée à un seul domaine. Dans Gestion des domaines, vous rattachez chaque domaine à une cible avec sa propre substitution de webroot. Vous faites tourner trois sites sur un VPS avec des blocs serveur Nginx ?
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
Une cible, trois rattachements. Vous ne saisissez pas trois fois un mot de passe SSH, et vous ne maintenez pas trois cibles quasi identiques qui finissent par diverger le jour où vous changez une clé et oubliez l'une d'elles. Cliquez sur déployer pour n'importe lequel des trois domaines et il sait déjà quel serveur et quel dossier utiliser — vous ne choisissez jamais au moment du déploiement.
Que fait réellement l'agent quand il se connecte ?
D'abord, il regarde autour de lui — en lecture seule, rien n'est encore écrit. Cette inspection vérifie :
- Un dossier vide
- Une version antérieure de ce même build
- Une ancienne installation WordPress
- Une page « bientôt disponible » que votre hébergeur y a déposée par défaut
Cela détermine la stratégie. Un webroot vide reçoit un envoi simple. Un webroot contenant déjà quelque chose est traité avec plus de précaution, car beaucoup d'installations réelles ont des éléments qui cohabitent avec le site et qui ne doivent pas disparaître :
- A
.well-knowndossier pour la validation SSL - Un
uploadsrépertoire que personne n'a mis dans git - A
wp-config.phpque personne ne veut voir touché
Le travail ici se rapproche davantage de « déterminer ce qui a changé et le réconcilier » que de « effacer et remplacer ».
Ensuite, avant qu'un seul octet ne soit écrasé, le webroot existant est capturé comme une version sur votre propre hébergement. Pas un enregistrement en base de données, pas un diff que nous calculons en espérant qu'il soit correct — un véritable instantané de ce qui s'y trouvait. Cela compte le plus lors du tout premier déploiement sur une cible donnée, car ce déploiement arrive toujours par-dessus quelque chose, même si ce quelque chose est rien. Dossier vide, instantané vide. Site statique vieux de cinq ans dont plus personne ne se souvient l'avoir créé — préservé exactement, gratuitement, avant même d'être touché. Ce premier déploiement est aussi celui dont vous êtes le moins sûr, donc c'est celui où cela compte le plus.
Est-ce que ça envoie mon code source ou le site déjà construit ?
Le site construit, toujours. Pour un site statique, ce sont les pages générées. Pour un build de framework — Next.js, Vite, peu importe ce que le type de site exige — c'est la sortie compilée, le dossier dist ou build , jamais l'arborescence source. Je pense que c'est la bonne décision même si cela signifie que vous ne pouvez pas vous connecter en SSH et exécuter npm run dev contre ce qui se trouve sur le serveur. Téléverser la source signifierait que votre webroot de production a besoin d'un runtime Node et d'une chaîne d'outils de build juste pour servir du HTML — transformant une machine d'hébergement mutualisé qui n'a jamais été conçue pour exécuter un pipeline de build en une machine qui le fait, et transformant chaque déploiement en « espérons que le serveur ait assez de mémoire pour terminer npm install ». Ne livrer que la sortie compilée garde le webroot exactement conforme à ce qu'attend un serveur de fichiers statiques. Ennuyeux. Ennuyeux est ce que vous voulez à 2h du matin quand quelque chose ne va pas et que vous fixez ce dossier en essayant de comprendre ce qui est réellement servi.
Comment savoir si un déploiement a vraiment fonctionné ?
Après le téléversement, l'agent atteint l'URL en production et vérifie qu'elle se résout — pas de 500, pas de page blanche. Ce qu'il trouve, ainsi que tout ce qu'il a remarqué pendant l'inspection et sur lequel il souhaite votre avis (« ce webroot a un dossier wp-content que j'ai laissé intact, confirmez que c'est attendu »), arrive dans le fil de discussion du build. C'est le schéma qui traverse toute cette plateforme : pas de succès silencieux, pas d'échec silencieux qui se transforme en ticket de support. L'agent vous dit ce qu'il a vu et ce qu'il a décidé, dans le même fil où vous avez demandé le build.
Que contient réellement l'historique des versions ?
Chaque déploiement ajoute une version — pas seulement le premier. L'historique n'est donc pas vos builds placés sur une frise chronologique abstraite ; c'est la séquence littérale de ce qui a été servi depuis ce webroot, dans l'ordre, en partant de ce qui s'y trouvait avant votre arrivée. La version un est toujours cet état pré-plateforme, capturé automatiquement. Vous n'avez pas à y penser.
Que restaure réellement le retour en arrière ?
La version précédente en production, exactement — pas une reconstruction d'un ancien build, pas une approximation. Les fichiers réels qui servaient le trafic auparavant. C'est une garantie sensiblement plus forte que la plupart des fonctionnalités de « rollback » que j'ai utilisées ailleurs, qui signifient généralement « redéployer depuis un ancien commit » en supposant tacitement que votre processus de build est déterministe et que votre environnement n'a pas dérivé depuis. Ici, le retour en arrière est une restauration d'un instantané connu et fonctionnel, ce qui explique qu'on puisse s'y fier sous pression — vous n'avez pas à vous demander si le rollback pourrait se comporter différemment de ce qu'il est censé restaurer.
Et le moment où vous en avez vraiment besoin n'est jamais un moment calme ; c'est « le nouveau build a cassé le paiement et le site est en production, là, maintenant ».
Un clic, version précédente restaurée, terminé. La raison pour laquelle nous traitons ceci comme une fonctionnalité de premier plan plutôt qu'un ajout après coup est expliquée dans Itérer sans crainte — à lire une fois, avant d'en avoir besoin. L'historique et le contrôle de restauration se trouvent tous deux sur la fiche de build et dans la vue d'historique propre à la cible.
Est-ce que ça sauvegarde aussi ma base de données ?
Non, et je préfère le dire clairement plutôt que de laisser quiconque supposer le contraire. L'historique des versions sur l'hôte couvre ce que ce pipeline de déploiement a placé dans le webroot. Si votre site a une base de données, des fichiers téléchargés par les utilisateurs, ou toute autre chose qui évolue en dehors des déploiements, c'est une préoccupation totalement distincte — le retour en arrière n'y touche pas et ne doit pas être confondu avec une stratégie de sauvegarde qui le ferait.
