Comment mettre son site en ligne : la méthode pas à pas

Mettre son site en ligne suit cinq étapes : souscrire un hébergement, pointer le nom de domaine vers le serveur, transférer les fichiers dans le répertoire racine, importer la base de données, puis vérifier chaque page. Comptez une demi-journée de travail, plus un délai de propagation DNS pouvant atteindre 48 heures.

Choisir l’hébergeur qui accueillera votre site

Le site est conçu, testé en local, prêt à partir. Il lui manque un serveur accessible 24 heures sur 24 pour le servir aux visiteurs. Ce serveur, c’est l’hébergement web, un espace loué chez un prestataire spécialisé. Si la distinction entre l’adresse et le serveur reste floue pour vous, notre article sur la différence entre nom de domaine et hébergement web pose les bases avant d’aller plus loin.

Mutualisé, VPS ou infogéré : quel format pour démarrer ?

Pour une première mise en ligne, l’hébergement mutualisé constitue le point d’entrée logique. Plusieurs sites partagent le même serveur physique, ce qui tire les tarifs vers le bas : les grilles publiques d’OVHcloud, d’o2switch et de Hostinger affichent en 2026 des offres entre 2 et 14 euros par mois. Un site vitrine, un portfolio de graphiste ou un blog s’en contentent largement.

Le VPS, serveur privé virtuel, réserve une portion garantie de ressources. Il devient pertinent quand le trafic grimpe ou quand le site exécute des traitements lourds. L’offre infogérée ajoute une couche de service : l’hébergeur gère les mises à jour, la sécurité et la supervision à votre place, contre un tarif supérieur.

Inutile de surdimensionner dès le départ. Un changement de formule chez le même prestataire s’effectue en quelques clics, sans re-transférer les fichiers. La vraie question à trancher maintenant : votre site est-il statique, simple assemblage de pages HTML, ou dynamique, avec un CMS et une base de données ? La réponse détermine la moitié des étapes qui suivent.

Les critères qui comptent vraiment au moment de signer

Au-delà du prix mensuel, quatre éléments méritent une vérification avant de souscrire :

• Le certificat SSL inclus, indispensable pour afficher le cadenas HTTPS
• Le type de stockage, les disques SSD ou NVMe accélérant nettement le chargement
• Un support technique joignable, idéalement en français et 7 jours sur 7
• Un taux de disponibilité garanti contractuellement, la référence du marché se situant à 99,9 %

Le HTTPS n’est plus une option : d’après le rapport de transparence de Google publié en 2025, environ 95 % du trafic web transitant par ses services est désormais chiffré. Un hébergeur qui facture le certificat en supplément part avec un train de retard, puisque Let’s Encrypt, l’autorité de certification à but non lucratif, délivre le même service gratuitement et protège 762 millions de sites selon son bilan de décembre 2025.

Ces critères se retrouvent chez les acteurs français récents du marché : mettez votre site en ligne avec ZKillu, et vous cochez ces cases dès le premier palier, avec des plans mutualisés sur disques SSD et NVMe facturés de 1 à 6,49 euros par mois, certificat SSL inclus, support en français 7 jours sur 7 et migration assistée depuis un ancien hébergeur. L’installateur WordPress en un clic simplifie aussi la suite des opérations pour les sites construits sur ce CMS. Une fois le compte activé, l’hébergeur envoie les identifiants du serveur : c’est le sésame des étapes suivantes.

Relier le nom de domaine au serveur d’hébergement

Le serveur existe, mais personne ne le trouvera en tapant votre adresse tant que le DNS ne fait pas le lien. Le nom de domaine, acheté chez un registrar, doit pointer vers l’hébergement souscrit. L’extension française reste une valeur sûre pour un public local : l’Afnic, le registre du .fr, recensait 4 319 120 noms de domaine actifs au 31 décembre 2025.

Deux méthodes de pointage coexistent. La première consiste à remplacer les serveurs de noms (NS) du domaine par ceux fournis par l’hébergeur : toute la gestion DNS bascule alors chez lui. La seconde conserve la gestion chez le registrar et modifie uniquement les enregistrements ciblés :

• L’enregistrement A, qui associe le domaine à l’adresse IP du serveur
• L’enregistrement CNAME, souvent utilisé pour faire suivre le sous-domaine www
• L’enregistrement MX, à préserver soigneusement si des boîtes e-mail existent déjà

L’erreur classique : écraser les enregistrements MX en changeant les serveurs de noms, et couper les e-mails professionnels du jour au lendemain. Notez la configuration existante avant toute modification.

Composer avec le délai de propagation DNS

La modification DNS ne prend pas effet instantanément. Chaque fournisseur d’accès conserve en cache les anciennes réponses pendant une durée variable. Pour un domaine en .fr, l’Afnic indique que le processus complet s’effectue en une dizaine d’heures en moyenne, la fourchette courante s’étendant jusqu’à 24 ou 48 heures tous opérateurs confondus.

Concrètement, un visiteur à Lyon peut voir le nouveau site pendant qu’un autre à Lille tombe encore sur la page de parking du registrar. Rien d’anormal. Lancez le pointage DNS en premier, poursuivez le transfert des fichiers pendant la propagation : les deux chantiers avancent en parallèle sans se gêner.

Des outils gratuits de vérification DNS interrogent des serveurs répartis sur plusieurs continents et montrent en temps réel quelles zones du globe voient déjà la nouvelle adresse IP. Pratique pour distinguer une propagation en cours, situation normale, d’une erreur de saisie dans l’enregistrement A, qui elle ne se résoudra jamais toute seule. Autre paramètre à connaître : le TTL, la durée de vie en cache de chaque enregistrement. L’abaisser à 300 secondes quelques jours avant une bascule planifiée raccourcit d’autant la période de flottement.

Transférer les fichiers dans le répertoire racine

Le cœur de la mise en ligne : copier les fichiers du site depuis votre ordinateur vers le serveur. Deux voies principales existent, et le choix dépend surtout du volume à transférer et de vos habitudes de travail.

La méthode FTP avec un client dédié

Le protocole FTP, et sa version chiffrée SFTP à privilégier, reste l’outil standard pour envoyer des fichiers vers un serveur. FileZilla, client gratuit et open source, fait référence depuis des années. La connexion réclame quatre informations fournies par l’hébergeur dans l’e-mail d’activation :

• L’adresse du serveur, souvent de la forme ftp.votredomaine.fr
• L’identifiant du compte FTP
• Le mot de passe associé
• Le port de connexion, 21 pour le FTP classique, 22 pour le SFTP

Une fois connecté, l’interface affiche deux panneaux : vos dossiers locaux à gauche, l’arborescence du serveur à droite. Un glisser-déposer suffit à lancer le transfert. Pour un site complet avec images, comptez de quelques minutes à une heure selon le poids total et le débit montant de votre connexion.

Un transfert interrompu se reprend là où il s’était arrêté, FileZilla listant les fichiers en échec dans un onglet dédié. Vérifiez cet onglet avant de fermer le logiciel : trois images manquantes sur deux cents ne se remarquent pas dans la file de transfert, mais se voient immédiatement sur le site. Côté droits d’accès, les valeurs standard conviennent dans la grande majorité des cas, 644 pour les fichiers et 755 pour les dossiers. Un réglage plus permissif type 777 ouvre une faille de sécurité et déclenche même une erreur chez certains hébergeurs.

Le gestionnaire de fichiers de l’hébergeur

L’alternative sans logiciel : le gestionnaire de fichiers intégré au panneau d’administration de l’hébergement, cPanel ou équivalent maison. Il fonctionne directement dans le navigateur et accepte l’envoi d’une archive ZIP, décompressée ensuite sur le serveur en un clic. Cette approche va plus vite pour un site léger, mais devient laborieuse dès que les mises à jour de fichiers se multiplient.

Reste le point qui fait échouer une mise en ligne sur deux chez les débutants : le répertoire racine. Le serveur ne sert au public qu’un seul dossier, nommé selon l’hébergeur www, public_html ou htdocs. Les fichiers doivent y être placés directement, avec le fichier index.html ou index.php à la racine de ce dossier, pas dans un sous-dossier mon-site glissé par mégarde lors du transfert. Un doute sur le nom exact ? La documentation de l’hébergeur le précise toujours.

Le cas WordPress simplifie le tableau : l’installateur en un clic proposé par la plupart des hébergeurs dépose le CMS directement au bon endroit, et l’extension de migration duplique le site local sans manipulation FTP manuelle. Pour un site construit avec un créateur en ligne type Wix ou Squarespace, la question du transfert ne se pose même pas, l’hébergement étant intégré à l’abonnement, comme le détaille notre guide pour créer un site internet soi-même gratuitement.

Importer la base de données et ajuster la configuration

Un site statique en HTML et CSS s’arrête à l’étape précédente. Un site dynamique, WordPress en tête, stocke ses contenus dans une base de données MySQL qu’il faut déménager elle aussi. Sans elle, les fichiers transférés affichent une erreur de connexion à la base au lieu de vos pages.

La procédure passe par phpMyAdmin, l’outil de gestion de bases installé chez la quasi-totalité des hébergeurs mutualisés :

1. Exporter la base locale au format SQL depuis le phpMyAdmin de votre environnement de développement
2. Créer une base vide sur le serveur, avec un utilisateur et un mot de passe dédiés
3. Importer le fichier SQL dans cette nouvelle base via le phpMyAdmin de l’hébergeur
4. Reporter les nouveaux identifiants dans le fichier de configuration du site

Adapter la configuration du CMS au serveur

Pour WordPress, le fichier wp-config.php centralise quatre valeurs à mettre à jour : nom de la base, utilisateur, mot de passe et adresse du serveur MySQL, souvent localhost. Dernier piège, les URL enregistrées en base : un site développé en local sous une adresse type localhost/monsite conserve cette adresse dans ses réglages et ses contenus. Les extensions de migration gèrent ce remplacement automatiquement, sinon la modification s’effectue dans les options du CMS puis par un rechercher-remplacer dans la base.

Un export récent de la base fait aussi office de sauvegarde de secours. Prenez l’habitude d’en générer un avant chaque opération lourde : une base écrasée sans copie ne se récupère pas.

Pensez aussi aux réglages qui n’avaient aucune importance en local. Le fuseau horaire du site, l’adresse e-mail d’expéditeur des notifications ou les clés d’API de services externes, cartographie ou paiement, pointent parfois encore vers des valeurs de test. Un passage en revue des écrans de réglages du CMS, ligne par ligne, prend dix minutes et épargne des heures de débogage plus tard.

Vérifier le site après la mise en ligne

Les fichiers sont en place, la base répond, le DNS propage. Avant d’annoncer l’adresse à vos contacts, une passe de vérification systématique évite de laisser des défauts visibles aux premiers visiteurs. Cette phase de contrôle prolonge la logique qualité des étapes de création d’un site web professionnel, où les tests précèdent toujours la publication.

Le tour d’horizon couvre sept points :

• Le certificat SSL actif, avec redirection automatique de HTTP vers HTTPS
• Chaque page principale ouverte une par une, menus et liens internes cliqués
• Le formulaire de contact testé avec un envoi réel, réception vérifiée
• L’affichage contrôlé sur smartphone, tablette et desktop
• Les images chargées correctement, sans lien cassé ni fichier manquant
• La vitesse de chargement mesurée avec PageSpeed Insights
• L’absence d’erreurs 404 sur les adresses importantes de l’ancienne version du site, le cas échéant

Le test du formulaire de contact mérite une insistance particulière. Un envoi qui semble fonctionner côté visiteur peut très bien ne jamais arriver dans votre boîte : les messages expédiés par le serveur web atterrissent fréquemment en courrier indésirable tant que l’authentification SPF et DKIM du domaine n’est pas configurée. Envoyez un message de test, contrôlez sa réception, y compris dans le dossier spam, et corrigez la configuration e-mail avant qu’un prospect réel n’écrive dans le vide.

Le rendu visuel mérite un œil critique une fois le site sur son vrai serveur : polices de substitution, images compressées différemment ou couleurs altérées par un cache trahissent parfois le passage du local à la production. Si l’harmonie générale cloche, revoyez votre palette de couleurs de site web directement sur la version en ligne plutôt que sur la maquette.

Un piège spécifique aux sites développés sous CMS mérite une vérification à part : la case de blocage des moteurs de recherche. WordPress propose une option Demander aux moteurs de ne pas indexer ce site, souvent cochée pendant le développement pour éviter qu’une version inachevée n’apparaisse dans Google. Oubliée après la mise en ligne, elle condamne le site à l’invisibilité totale, sans aucun message d’erreur pour alerter. Même contrôle sur le fichier robots.txt, qui ne doit plus contenir de directive bloquant l’ensemble du site.

Dernière brique, la visibilité : déclarez le site dans Google Search Console et soumettez le sitemap XML. Google découvre alors l’existence des pages sans attendre qu’un lien externe l’y amène. L’indexation démarre en général sous quelques jours, le positionnement se construit ensuite sur des semaines. La Search Console signale au passage les erreurs d’exploration, les pages exclues et les problèmes d’ergonomie mobile : un tableau de bord gratuit qui remplace avantageusement les suppositions.

Prochaine étape : planifier une sauvegarde automatique hebdomadaire des fichiers et de la base, puis noter dans un agenda la date de renouvellement du domaine et de l’hébergement. Un site en ligne se maintient, il ne se publie pas une fois pour toutes.