Mettre un site en ligne de A à Z
Votre site tourne sur votre machine. Entre lui et une adresse que le monde peut taper, il y a quatre pièces à assembler, une poignée de décisions à prendre et une liste de choses à ne surtout pas envoyer sur le serveur. Voici le chemin complet, dans l'ordre.
Avant d'appliquer ce mémo
Les manipulations décrites ici peuvent entraîner une perte de données ou l'indisponibilité d'un service. Avant d'en appliquer une seule : faites une sauvegarde complète et vérifiez qu'elle se restaure, travaillez d'abord sur un environnement sans enjeu, et n'exécutez aucune commande dont vous ne comprenez pas l'effet.
Ce mémo est un contenu pédagogique de portée générale. Il ne tient pas compte de votre situation, n'a pas valeur de conseil professionnel, et son application relève de votre seule responsabilité. Avertissement et limites d'usage
1. Mettre en ligne, ça veut dire quoi ? Le vrai contenu de la peur
Une seule idée à retenir
Mettre un site en ligne, c'est copier des fichiers sur un ordinateur allumé en permanence, puis dire au réseau mondial que le nom de votre entreprise désigne cet ordinateur-là. Rien de plus. Tout le reste est de l'organisation.
Si l'opération intimide, ce n'est pas à cause de sa difficulté technique. C'est parce qu'elle est publique et irréversible en apparence : jusqu'ici, une erreur ne se voyait que sur votre écran. À partir de maintenant, elle se voit par tout le monde, y compris par un client. Ce mémo est écrit pour supprimer cette part de risque, pas pour la minimiser.
! Le contresens le plus fréquent
Beaucoup de débutants croient qu'il faut « un serveur », au sens d'une machine qu'on installe et qu'on administre. Dans l'immense majorité des cas, non : vous louez quelques gigaoctets sur une machine déjà installée, déjà sécurisée, déjà sauvegardée par quelqu'un dont c'est le métier. C'est ce qu'on appelle l'hébergement mutualisé, et c'est le bon choix pour un premier site, un site vitrine, une boutique qui démarre.
Passer directement à un serveur qu'on administre soi-même, c'est ajouter un métier à un projet qui n'en demandait pas.
2. Les quatre pièces du puzzle Ce qu'il faut avoir, et dans quel ordre
Quel que soit le site, quelle que soit la technologie, la mise en ligne assemble toujours les quatre mêmes pièces. Les confondre est la première source de blocage : quand « le site ne marche pas », la question utile est laquelle des quatre est en cause.
monentreprise.com
L'adresse que l'on tape
la machine allumée
Stocke les fichiers, exécute le code
Ce qui s'achète séparément
- Le nom de domaine se loue à l'année, chez un bureau d'enregistrement
- L'hébergement se loue au mois ou à l'année, chez un hébergeur
- Le certificat est gratuit dans l'immense majorité des cas
Domaine et hébergement peuvent venir du même fournisseur, ce qui simplifie les réglages, ou de deux fournisseurs différents, ce qui vous rend plus libre de changer d'avis. Les deux sont défendables.
L'ordre qui évite d'attendre
- Réserver le nom de domaine 10 min
- Souscrire l'hébergement 10 min
- Pointer les DNS vers l'hébergement à faire tôt
- Transférer le code pendant que les DNS se propagent
- Activer le certificat, une fois le domaine résolu
Le point 3 se fait en premier possible : c'est la seule étape dont le délai ne dépend pas de vous.
3. Choisir où l'héberger Cinq familles, et celle qui vous convient
Le marché de l'hébergement pousse vers le haut de gamme : cloud computing, conteneurs, orchestration, mise à l'échelle automatique. Ces outils existent pour de vraies raisons, mais ils répondent à des problèmes que la plupart des sites n'ont pas. Choisissez d'après votre situation réelle, pas d'après ce que vous lisez.
| Famille | Ce que c'est | Pour qui | Ce que ça vous demande |
|---|---|---|---|
| Hébergement statique | Un espace qui sert uniquement des fichiers HTML, CSS, images. Aucun code exécuté côté serveur. | Site vitrine, portfolio, documentation, jeu web | Presque rien Déposer des fichiers |
| Mutualisé | Une part d'une machine partagée entre de nombreux clients, avec PHP, une base de données et une interface d'administration. | Vitrine dynamique, CMS, boutique qui démarre, application PHP | Peu Aucune administration système |
| Serveur privé virtuel | Une machine virtuelle entière, à vous. Vous installez et sécurisez tout. | Besoins que le mutualisé refuse : version précise, service permanent, trafic important | Beaucoup Mises à jour, pare-feu, sauvegardes |
| Plateforme gérée | Vous poussez votre code, la plateforme construit et déploie. Le système reste invisible. | Applications modernes, équipes qui livrent souvent | Moyen Comprendre le pipeline de déploiement |
| Serverless | Votre code s'exécute à la demande, facturé à l'usage. Aucun serveur permanent. | Traitements ponctuels, pics très irréguliers, API | Élevé Repenser l'architecture |
1 Ce qu'il faut vérifier avant de signer
- La version du langage proposée, et surtout si vous pouvez en changer
- L'accès SSH, indispensable pour déployer par Git
- Le certificat inclus et renouvelé automatiquement
- Les sauvegardes : fréquence, durée de conservation, et surtout si vous pouvez déclencher une restauration
- La localisation des serveurs, qui décide du droit applicable à vos données
- Le nombre de bases de données et de sites autorisés sur l'offre
2 Ce qui compte moins qu'on ne le dit
L'espace disque. Un site vitrine complet tient dans quelques centaines de mégaoctets. Les offres illimitées répondent à une angoisse, pas à un besoin.
La promesse de disponibilité. Tout le monde affiche le même chiffre. Ce qui se vérifie vraiment, c'est la réactivité du support un dimanche soir.
Le prix de la première année. Regardez le tarif de renouvellement, souvent très différent.
4. Le nom de domaine et les DNS Juste ce qu'il faut pour ne rien casser
Le système de noms de domaine est l'annuaire du réseau : il traduit un nom lisible en adresse numérique. Vous n'avez pas besoin d'en comprendre le fonctionnement interne. Vous avez besoin de savoir quelles lignes remplir, et laquelle casse la messagerie si on y touche.
| Type | À quoi ça sert | Exemple de valeur | Si vous vous trompez |
|---|---|---|---|
| A | Fait pointer le domaine vers l'adresse de l'hébergement | 92.0.2.10 |
Le site est injoignable |
| CNAME | Fait d'un sous-domaine l'alias d'un autre nom | www → monsite.com |
Seule l'adresse en www échoue |
| MX | Désigne le serveur qui reçoit vos courriels | mail.monhebergeur.net |
Vous ne recevez plus rien |
| TXT | Porte les vérifications de propriété et les protections antispam | v=spf1 include:... |
Vos courriels partent en indésirable |
| NS | Indique quel service gère la zone entière | ns1.monhebergeur.net |
Toutes les lignes ci-dessus sont ignorées |
! La migration qui coupe les mails
C'est l'accident classique. On change d'hébergeur, on suit la procédure fournie, qui consiste souvent à basculer les serveurs de noms (NS) vers le nouvel hébergeur. En basculant les NS, on abandonne d'un coup toute la zone, y compris les lignes MX et TXT qui faisaient fonctionner la messagerie hébergée ailleurs.
La parade tient en deux gestes : photographier la zone avant de toucher à quoi que ce soit, et recréer les MX et TXT chez le nouveau gestionnaire avant de basculer, pas après.
Le TTL, ou pourquoi ça n'est pas instantané
Chaque ligne DNS porte une durée de vie, exprimée en secondes : c'est le temps pendant lequel les serveurs du monde entier ont le droit de garder l'ancienne réponse en mémoire. Une valeur de 3600 signifie qu'un changement peut mettre une heure à être vu partout.
Avant une migration prévue, abaissez le TTL des lignes concernées un ou deux jours à l'avance. Le jour J, la bascule sera presque immédiate. Remontez-le ensuite.
Vérifier au lieu de croire
Votre navigateur et votre système gardent eux aussi les réponses en mémoire : « chez moi ça marche » ne prouve rien. Interrogez directement l'annuaire.
Les trois commandes qui répondent vraiment
# Où pointe le domaine, vu depuis un résolveur public dig +short monsite.com @1.1.1.1 # Qui reçoit les mails dig +short MX monsite.com # La zone telle que la voient les serveurs officiels dig NS monsite.com +short
www, et redirigez l'autre vers elle. Servir le même contenu sur deux adresses différentes divise votre référencement et complique les statistiques. Le choix entre les deux n'a aucune importance ; ne pas choisir, si.5. Transférer le code Trois méthodes, trois niveaux de discipline
| Méthode | Principe | Ce qu'elle coûte | Verdict |
|---|---|---|---|
| FTP / SFTP | On glisse les fichiers depuis un logiciel, comme dans un explorateur. | Aucune trace de ce qui a été envoyé, aucun retour arrière, oublis fréquents. | Pour dépanner |
| rsync par SSH | Une commande synchronise un dossier local avec le serveur, en n'envoyant que les différences. | Une ligne de commande à comprendre. Toujours pas d'historique. | Bon compromis |
| Git | Le serveur récupère lui-même une version précise du dépôt. | Il faut versionner son projet, ce qui est de toute façon indispensable. | La bonne méthode |
1 Pourquoi Git change tout
Avec le FTP, la question « qu'est-ce qui tourne exactement en production ? » n'a pas de réponse fiable. Avec Git, elle en a une, exacte, au commit près. Et surtout, revenir en arrière devient une commande au lieu d'une reconstitution de mémoire à trois heures du matin.
Le principe est simple : le serveur héberge une copie du dépôt et va chercher la version voulue. Personne n'édite jamais de fichier directement sur le serveur.
Le déploiement par Git, la première fois puis les suivantes
# --- Sur le serveur, une seule fois --- cd ~/monsite.com git clone git@forge:compte/monsite.git . # Les fichiers propres au serveur ne viennent jamais du dépôt cp .env.exemple .env nano .env # --- À chaque mise à jour, ensuite --- cd ~/monsite.com git pull --ff-only # puis, selon le projet : migrations, vidage du cache, droits
La clé de déploiement
Pour que le serveur récupère un dépôt privé, il lui faut une identité. On génère sur le serveur une paire de clés dédiée, et on déclare la partie publique sur la forge en lecture seule.
Une clé de déploiement ne doit jamais pouvoir écrire dans le dépôt : si le serveur est compromis, l'attaquant ne doit pas pouvoir pousser du code dans votre projet.
Le verrou humain
Le déploiement peut être automatisé de bout en bout, du commit à la production. Tant que le site vit sans surveillance permanente, préférez conserver un geste manuel pour la dernière étape.
Cette commande tapée à la main est la dernière occasion de ne pas envoyer en production quelque chose qui n'était pas prêt. Automatisez la construction et les tests ; gardez la main sur la publication.
6. Ce qui ne doit jamais partir sur le serveur La section la plus consultée du mémo
Une fois qu'un fichier est accessible publiquement, considérez qu'il a été lu. Les robots parcourent les adresses courantes en permanence, et un fichier retiré dix minutes plus tard a pu être copié. Cette liste vaut d'être relue avant chaque première mise en ligne.
! Jamais accessible depuis le web
- Le fichier de configuration contenant les mots de passe de base de données, clés d'interface et jetons
- Les sauvegardes, en particulier les exports de base de données. Un fichier
.sqllaissé à la racine est une fuite de données intégrale - Les fichiers de travail : archives, notes, devis, maquettes, exports comptables
- Le dossier
.git, qui contient tout l'historique, y compris ce que vous croyiez avoir supprimé - Les journaux applicatifs, souvent bavards sur les chemins internes et les identifiants
- Les fichiers d'installation et pages de diagnostic laissées après la mise en service
- Les copies de travail :
index-old.php,config.php.bak,test.php
La protection structurelle
La meilleure défense n'est pas une règle d'accès, c'est une racine web qui ne contient rien de sensible. On place dans le dossier public uniquement le point d'entrée et les ressources destinées au navigateur ; tout le reste vit au-dessus, hors d'atteinte.
La disposition qui protège par construction
monsite.com/ ├── app/ # code, jamais accessible ├── config/ # configuration, jamais accessible ├── storage/ # journaux, cache, jamais accessible ├── .env # secrets, jamais accessible └── public/ # SEUL dossier servi par le web ├── index.php └── assets/
Le filet, pas la digue
Un fichier .gitignore tenu à jour empêche les secrets de partir dans le dépôt, et une règle de refus dans la configuration du serveur bloque l'accès aux extensions sensibles.
Ce sont des filets utiles, mais ce ne sont que des filets : ils dépendent d'une liste que quelqu'un doit maintenir. La disposition des dossiers, elle, protège même les fichiers auxquels personne n'avait pensé.
/.env, /.git/config, /backup.sql, /phpinfo.php, /config.php.bak. Chacune doit renvoyer une erreur. Ce contrôle prend moins d'une minute et détecte la quasi-totalité des expositions accidentelles.7. Droits, dossiers inscriptibles et panne du dimanche Le sujet qu'on découvre en panique
Sur un serveur, chaque fichier appartient à un utilisateur et porte des permissions : qui peut le lire, l'écrire, l'exécuter. Le programme qui sert votre site tourne sous une identité précise, et une grande partie des pannes inexpliquées vient de là.
Lisibles par le serveur, modifiables par vous seul.
Traversables par le serveur, modifiables par vous seul.
Tout le monde peut tout écrire. C'est la réponse qu'on trouve sur les forums, et c'est une porte ouverte.
1 Les seuls dossiers qui doivent être inscriptibles
Un site n'a besoin d'écrire que dans très peu d'endroits. Identifiez-les explicitement, et n'ouvrez que ceux-là :
- Le dossier des fichiers déposés par les visiteurs ou l'administrateur
- Le dossier de cache, s'il en existe un
- Le dossier des journaux
- Le dossier des sessions, quand il n'est pas géré par le système
Tout le reste, y compris le code, doit être en lecture seule pour le serveur. Un code que le serveur peut modifier est un code qu'un attaquant peut réécrire.
La panne du dimanche soir, et sa cause
Le scénario se répète : tout fonctionnait, personne n'a rien touché, et le formulaire ne s'envoie plus, ou les images n'apparaissent plus. Neuf fois sur dix, un fichier a été créé par une identité différente de l'habituelle, souvent parce qu'une opération a été menée depuis une autre voie que d'ordinaire.
Avant de chercher plus loin, vérifiez le propriétaire et les droits des fichiers récemment créés. C'est le contrôle le plus rentable, et le plus souvent oublié.
8. HTTPS, du certificat au cadenas Obligatoire, gratuit, et souvent mal fini
Votre hébergeur appellera ça un certificat SSL, parfois TLS, parfois les deux dans la même phrase : c'est le même objet, TLS étant simplement la version moderne du protocole. Il chiffre les échanges entre le navigateur et le serveur. Sans lui, tout ce qui transite se lit en clair sur le chemin : formulaires, mots de passe, contenus. Un site sans HTTPS est signalé comme non sécurisé par les navigateurs, pénalisé en référencement naturel, et non conforme dès qu'il collecte la moindre donnée personnelle.
1 Les quatre étapes, dans l'ordre
- Attendre que le domaine pointe vers l'hébergement. La délivrance du certificat vérifie que vous contrôlez bien le domaine : tant que les DNS ne sont pas à jour, elle échoue.
- Activer le certificat, en une case à cocher chez la plupart des hébergeurs.
- Rediriger tout le trafic non chiffré vers sa version chiffrée, de façon permanente.
- Corriger le contenu mixte, c'est-à-dire les ressources encore appelées en clair depuis une page chiffrée.
Le contenu mixte, ou le cadenas qui ne vient pas
Le certificat est actif, la redirection fonctionne, et pourtant le cadenas n'apparaît pas. C'est presque toujours qu'une image, une feuille de style ou un script est encore appelé avec une adresse en clair, souvent écrite en dur dans un contenu.
La console du navigateur nomme précisément les ressources fautives. Pour les contenus stockés en base, un remplacement global des anciennes adresses règle le problème en une fois.
Le renouvellement, le vrai risque
Les certificats gratuits ont une durée de vie courte et se renouvellent automatiquement. Tant que le renouvellement fonctionne, personne n'y pense ; le jour où il échoue silencieusement, le site devient inaccessible avec un avertissement de sécurité effrayant.
Mettez en place une alerte sur la date d'expiration. C'est le seul moyen d'être prévenu avant vos visiteurs.
9. La checklist avant d'annoncer À cocher, pas à lire
Le moment le plus dangereux n'est pas la mise en ligne : c'est l'annonce. Tant que personne ne connaît l'adresse, une erreur se corrige tranquillement. Voici ce qui se vérifie avant d'envoyer le lien.
A Le site répond
- La page d'accueil s'affiche sur l'adresse définitive, avec le cadenas
- La forme non retenue (avec ou sans
www) redirige vers la bonne - Trois pages profondes tirées au hasard s'affichent correctement
- Une adresse inexistante renvoie une vraie page d'erreur, pas un message technique
- Le responsive design tient sur un vrai téléphone, pas seulement en fenêtre rétrécie
B Rien ne fuit
- Le test des trente secondes de la section 6 est passé
- L'affichage des erreurs techniques est désactivé pour les visiteurs
- Les comptes et mots de passe de démonstration sont supprimés
- Les pages d'installation et de diagnostic ont été retirées
C Le site fonctionne vraiment
- Le formulaire de contact envoie un message, et vous l'avez reçu, pas seulement vu passer
- Ce message n'est pas arrivé dans les indésirables
- Le parcours d'achat va jusqu'au paiement, en conditions de test
- Les liens vers les documents et pièces jointes fonctionnent
D On peut vous trouver, et vous mesurer
- Le site n'est plus interdit d'indexation, réglage souvent laissé de la phase de test, et qui annule tout votre SEO sans prévenir
- Le plan du site est déposé auprès des moteurs de recherche
- La mesure d'audience est en place et remonte une visite
- Les mentions légales et la politique de confidentialité sont publiées
- Le bandeau de consentement fonctionne, y compris le refus
E On peut revenir en arrière
- Une sauvegarde des fichiers et de la base a été prise après la mise en ligne
- Vous savez exactement quelle commande ramène la version précédente
- Vous avez noté quelque part les accès, et ils ne sont pas dans un fichier du site
10. Le lendemain Sauvegarder, surveiller, mettre à jour
Un site vit plusieurs années. Ces trois habitudes, prises dès le premier jour, coûtent quelques minutes par mois et évitent la quasi-totalité des catastrophes.
1 Sauvegarder, c'est-à-dire pouvoir restaurer
La sauvegarde de votre hébergeur est un filet, pas une garantie : elle vous protège d'une panne matérielle, pas d'une erreur de votre côté découverte trois semaines plus tard, ni d'un différend avec le prestataire.
- Trois copies des données, sur deux supports différents, dont une hors du serveur
- Les fichiers déposés et la base de données, pas seulement le code, qui est déjà dans votre dépôt
- Une conservation assez longue pour couvrir une erreur découverte tardivement
Surveiller sans y penser
- Une surveillance de disponibilité qui vous alerte quand le site ne répond plus
- Une alerte sur l'expiration du domaine et du certificat
- Une lecture rapide des journaux d'erreurs, une fois par mois
L'objectif n'est pas de tout savoir, c'est d'apprendre les pannes autrement que par un client mécontent.
Mettre à jour sans casser
Les mises à jour de sécurité ne sont pas optionnelles : la grande majorité des sites compromis le sont par une faille connue et corrigée depuis des mois.
La méthode qui tient dans la durée : appliquer les correctifs de sécurité rapidement, tester les montées de version majeures ailleurs qu'en production, et toujours sauvegarder juste avant.
11. Quand ça casse Lire un message, revenir en arrière
Le réflexe utile n'est pas de deviner, c'est de lire. Le serveur écrit ce qui s'est passé ; encore faut-il savoir où regarder et par quoi commencer.
| Symptôme | Cause la plus fréquente | Premier réflexe |
|---|---|---|
| Page blanche | Erreur du code, avec affichage désactivé | Ouvrir le journal d'erreurs, dernière ligne |
| Erreur 500 | Configuration du serveur, ou droits d'un fichier | Journal d'erreurs, puis droits des fichiers récents |
| Erreur 403 | Droits insuffisants, ou fichier d'accueil manquant | Vérifier les permissions du dossier |
| Erreur 404 générale | Règles de réécriture d'adresses absentes | Vérifier la présence du fichier de configuration du dossier |
| Site injoignable | DNS, domaine expiré ou certificat périmé | Interroger le DNS avant de toucher au site |
| Lenteur soudaine | Base de données, ou trafic automatisé | Journal d'accès : compter les requêtes par adresse |
Lire un journal sans s'y noyer
Un journal se lit par la fin : la dernière erreur est presque toujours la vôtre. Le reste est du bruit accumulé.
Les commandes qui suffisent dans neuf cas sur dix
# Les vingt dernières erreurs tail -n 20 logs/error.log # Suivre en direct pendant qu'on rejoue le bug tail -f logs/error.log # Qui frappe le plus fort, par adresse awk '{print $1}' logs/access.log | sort | uniq -c | sort -rn | head
Revenir en arrière
Devant un site cassé en production, la bonne décision est presque toujours de revenir à l'état d'avant, puis de comprendre à tête reposée. Réparer en direct sur la production rallonge la panne et improvise des corrections qu'on retrouve six mois plus tard.
C'est précisément ce que rend possible le déploiement par Git : la version précédente est identifiée, elle se remet en place en une commande, et vous savez exactement ce que vous venez de remettre.
12. Ce qu'on apprend ensuite Feuille de route, sans brûler d'étape
Étape 1 : Publier, et recommencer
Mettez en ligne un site simple, de bout en bout, puis refaites-le une seconde fois. La deuxième fois prend une heure au lieu d'une journée, et c'est à ce moment que le chemin devient clair.
Étape 2 : Versionner et déployer par Git
Abandonnez le FTP dès que possible. Le jour où vous saurez revenir en arrière en une commande, la mise en production cessera d'être un moment de tension.
Étape 3 : Séparer les environnements
Un endroit pour essayer, un endroit pour montrer, un endroit qui sert les visiteurs. C'est ce qui permet de tester une montée de version sans risquer le site en service.
Étape 4 : Automatiser ce qui est répétitif
Tests et construction automatiques à chaque modification, puis publication déclenchée par vous. Automatisez la vérification avant d'automatiser la mise en ligne.
Étape 5 : Reproduire l'environnement
La conteneurisation, puis la description de l'infrastructure sous forme de code. À ce stade seulement, et si le besoin est réel : ces outils résolvent des problèmes d'échelle, pas des problèmes de débutant.
Les cinq règles qui résument ce mémo
- Ce qui est en ligne doit être connu au commit près.
- Rien de sensible dans la racine web, jamais, même cinq minutes.
- Une sauvegarde non restaurée n'est pas une sauvegarde.
- Le retour arrière se prépare avant la mise en ligne, pas pendant la panne.
- La dernière commande de publication reste tapée à la main.
Mémo publié par NET&PRO à titre pédagogique. Information générale, sans garantie d'exactitude, d'exhaustivité ni d'actualité, et sans valeur de conseil personnalisé. Avertissement et limites d'usage
Dans le glossaire
Les mots croisés au fil de ce mémo, définis en une phrase. Ils sont soulignés dans le texte : un clic y mène directement.
Mémos liés
Le Backend de A à Z
Du serveur web aux applis hybrides IA/humain : langages, frameworks, bases de données, API, architectures.
Lire le mémoL'Open Source de A à Z
Du noyau Linux à l'IA libre : histoire, licences, état des lieux, tournant IA open source 2025-2026, stack de référence, modèles économiques et bonnes pratiques.
Lire le mémoLes sauvegardes de A à Z
Quoi sauvegarder, où, à quelle fréquence, comment automatiser et chiffrer, et le seul contrôle qui prouve que ça marche : restaurer pour de vrai.
Lire le mémoSur le blog
Le faire vous-même
Mettre un site en ligne n'a rien de mystérieux, et le faire une fois soi-même apprend plus que dix explications.
- Le temps réel : une journée pour un premier site, en comptant les erreurs, qui sont formatrices.
- Les outils gratuits : un hébergement d'entrée de gamme, un certificat automatique, et le mémo comme liste de contrôle.
- Le piège : ouvrir les comptes à votre adresse personnelle ou à celle d'un prestataire. Ils doivent être au nom de l'entreprise dès le premier jour.
Si vous préférez me le confier
Sur ce sujet, voici ce que je fais pour mes clients. Les formules disent ce qui est compris, ce qui ne l'est pas, et ce que ça coûte au bout de trois ans.