Netlify et Vercel sont la réponse simple pour un site statique, mais beaucoup ne bougent pas : le domaine est déjà chez un hébergeur cPanel, l'entreprise paie le serveur, ou le site doit cohabiter avec autre chose. Tout cela se tient — un export statique, ce sont des fichiers, et le FTP déplace des fichiers.
La seule chose qui rate systématiquement, c'est d'envoyer le dossier au lieu de son contenu. Le reste est mécanique.
Avant de commencer
Il vous faut trois éléments depuis votre panneau d'hébergement, en général sous Comptes FTP :
- Hôte :
ftp.votredomaine.com, ou une adresse IP - Identifiant et mot de passe : ceux du compte FTP, pas de votre panneau
- Port : 21 pour FTP, 22 pour SFTP
Utilisez SFTP si c'est proposé. Le FTP simple transmet votre mot de passe en clair. La plupart des hébergeurs acceptent SFTP sur le port 22, avec le même déroulé.
Il vous faut aussi un client FTP. FileZilla est gratuit et multiplateforme ; Cyberduck et WinSCP conviennent aussi.
Étape 1 : décompressez et vérifiez
Décompressez l'export quelque part de retrouvable. Avant tout envoi, lancez-le en local et parcourez-le.
Ces deux minutes valent le coup. Un lien cassé se diagnostique bien plus facilement sur localhost qu'une fois en ligne, quand vous devinez si le problème vient de l'export ou du serveur.
Étape 2 : connectez-vous
Ouvrez FileZilla et remplissez la barre de connexion rapide :
Hôte : sftp://ftp.votredomaine.com
Identifiant : votre-user-ftp
Mot de passe : votre-mot-de-passe
Port : 22
Le préfixe sftp:// compte : sans lui, FileZilla utilise du FTP simple quel que soit le port.
Deux panneaux apparaissent. À gauche votre ordinateur, à droite le serveur.
Étape 3 : trouvez la racine web
Côté serveur, cherchez l'un de ceux-ci :
public_html: cPanel, la plupart des mutualiséswww: certains fournisseurshtdocs: XAMPP et configurations ancienneshttpdocs: Plesk
Ce dossier est ce que voient les visiteurs sur votre domaine. Si vous arrivez à un endroit où cohabitent logs, tmp et public_html, vous êtes un niveau trop haut : entrez dans public_html.
Étape 4 : envoyez le contenu, pas le dossier
C'est l'étape qui rate.
Votre export décompressé ressemble sans doute à ceci :
mon-site-export/
├── index.html
├── about/
├── contact/
├── assets/
└── README.md
Ouvrez mon-site-export à gauche, sélectionnez tout ce qui est à l'intérieur, et glissez-le dans public_html.
Si vous glissez le dossier mon-site-export lui-même, votre site se retrouve sur votredomaine.com/mon-site-export/ et l'accueil renvoie une 404. À la fin, public_html/index.html doit exister. S'il est dans public_html/mon-site-export/index.html, remontez-le d'un niveau.
Vous pouvez ignorer README.md : c'est de la documentation pour vous, pas une partie du site. Le garder ne gêne pas.
Les exports volumineux prennent du temps. La file de transfert de FileZilla affiche la progression ; laissez-la tourner.
Étape 5 : vérifiez
Ouvrez votre domaine. L'accueil doit s'afficher. Ensuite :
- Parcourez le menu : les liens internes sont relatifs, ils doivent se résoudre sans configuration
- Ouvrez DevTools → Réseau et cherchez les 404 : un média manquant vient presque toujours d'un envoi partiel ; renvoyez ce dossier
- Ouvrez directement une page profonde, par exemple
votredomaine.com/about/. Si l'accueil marche et pas les pages profondes, voir ci-dessous.
Ce qui coince en mutualisé
Les pages profondes renvoient une 404, pas l'accueil
Votre export utilise des URL de type dossier (/about/index.html servi sur /about/). Apache le fait par défaut via DirectoryIndex, mais certains hébergeurs le désactivent. Ajoutez un .htaccess dans public_html :
DirectoryIndex index.html
Options +FollowSymLinks
Sur nginx cela ne se corrige pas depuis un fichier : demandez au support d'activer index index.html; pour le dossier.
Page blanche avec des erreurs de module
Le serveur envoie les .mjs avec le mauvais type de contenu et le navigateur refuse de les exécuter. Ajoutez au .htaccess :
AddType text/javascript .mjs
Même cause que le problème local en file://, à une autre couche.
Polices ou images manquantes
Sur l'offre gratuite, les médias restent liés au CDN de la plateforme d'origine plutôt qu'empaquetés. Ils se chargeront tant que le visiteur est connecté et que le site d'origine existe. Pour que tout soit autonome sur votre serveur, utilisez l'option de téléchargement des médias.
L'ancien site s'affiche encore
Cache du navigateur, ou de votre hébergeur. Rechargez de force (Cmd+Maj+R / Ctrl+F5), puis cherchez un bouton de purge dans votre panneau. Si Cloudflare est devant le domaine, il a sa propre purge.
Erreurs de permissions
Les fichiers doivent être en 644 et les dossiers en 755. FileZilla sait le faire : sélectionnez tout, clic droit, Permissions de fichier, et cochez Récursion dans les sous-dossiers.
Le maintenir à jour
Le FTP n'a pas de gestion de versions : tout renvoyer à chaque modification lasse vite. Deux façons d'alléger cela :
Synchronisez au lieu de tout renvoyer. La comparaison de dossiers de FileZilla met en évidence les différences pour n'envoyer que ce qui a changé.
Automatisez. Si votre hébergeur accepte SSH, rsync tient en une commande :
rsync -avz --delete ./mon-site-export/ user@votredomaine.com:~/public_html/
--delete retire du serveur ce qui n'existe plus en local, ce qui garde les choses propres — et supprimera aussi tout autre contenu vivant dans public_html, donc vérifiez avant de lancer.
Si vous faites cela chaque semaine, c'est un signal raisonnable pour passer à un hébergeur avec déploiement Git. Les options d'hébergement statique gratuit décrivent à quoi cela ressemblerait.
