Pendant longtemps, j'ai utilisé « héberger » et « déployer » à peu près comme des synonymes. Je disais « je vais déployer mon site » et « je vais héberger mon site » pour parler de la même chose : le mettre en ligne. Ce n'est qu'en construisant ce site-ci, avec GitHub, Render et un nom de domaine acheté sur Hostinger, que j'ai compris que je mélangeais en réalité trois rôles complètement différents.
Le lieu et l'action
Voici la distinction qui a fini par me débloquer : l'hébergement, c'est un lieu. Le déploiement, c'est une action.
L'hébergement, c'est le service qui garde tes fichiers quelque part, en permanence, et qui répond aux visiteurs quand ils tapent ton adresse. C'est une infrastructure statique dans le temps - elle ne bouge pas tant que tu ne fais rien.
Le déploiement, c'est le moment où tu publies une nouvelle version de ton site sur cet hébergement. C'est un événement, pas un endroit. Chaque fois que tu modifies ton code et que tu le mets en ligne, tu fais un déploiement.
L'analogie qui m'a le plus aidé : l'hébergement, c'est l'appartement où tu vis. Le déploiement, c'est le déménagement - l'action de faire entrer tes nouveaux meubles dedans. Tu peux avoir le même appartement pendant des années et déménager dedans plusieurs fois par semaine, à chaque fois que tu changes quelque chose.
Ce que ça donne concrètement, dans mon setup
Pour ce site, ma configuration se répartit en trois rôles bien distincts, et ça m'a pris du temps de comprendre qu'ils ne se recouvraient pas :
GitHub n'est ni l'un ni l'autre à proprement parler. C'est mon dépôt de code - la source de vérité de mes fichiers, avec tout l'historique des versions. Rien n'y est « en ligne » pour un visiteur normal.
Render, lui, est mon hébergeur. C'est le service qui sert réellement mon site aux visiteurs, vingt-quatre heures sur vingt-quatre. Il est configuré pour surveiller mon dépôt GitHub, et à chaque nouveau commit sur la branche connectée, il récupère les fichiers, les publie, et l'ancienne version est remplacée par la nouvelle. C'est ce mécanisme-là qu'on appelle déployer.
Hostinger, enfin, n'est ni l'un ni l'autre non plus. C'est mon registrar de domaine - l'endroit où j'ai acheté mon nom de domaine. Il ne sert aucun fichier ; il pointe juste le nom de domaine vers l'adresse de Render via un enregistrement DNS. Un peu comme un panneau routier qui indique « c'est par là » sans jamais contenir le site lui-même.
Pourquoi cette distinction compte vraiment
Ce n'est pas juste du vocabulaire pour faire sérieux. Comprendre cette séparation m'a évité plusieurs erreurs, et m'en évitera sûrement d'autres :
Le jour où mon site ne se met pas à jour après un git push, je sais maintenant où chercher : pas dans GitHub (le code y est bien arrivé), pas dans Hostinger (le nom de domaine pointe toujours au bon endroit), mais dans les réglages de déploiement de Render - peut-être que l'auto-déploiement n'est pas activé, ou que le build a échoué silencieusement.
Le jour où je voudrai changer d'hébergeur - passer de Render à autre chose - je saurai que ça ne touche ni mon code sur GitHub, ni mon nom de domaine sur Hostinger. Je n'aurai qu'à reconnecter le nouvel hébergeur au même dépôt, et rediriger le DNS vers la nouvelle adresse.
Et le jour où quelqu'un me dira « ton déploiement a échoué », je saurai immédiatement que ça ne veut pas dire que mon hébergement est cassé - ça veut dire qu'une tentative de mise à jour a échoué, mais que l'ancienne version de mon site, elle, tourne probablement toujours très bien.
Ce que je retiens
Trois services, trois rôles, et aucun des trois ne fait le travail des deux autres. Le code vit sur GitHub. Le site vit sur Render. L'adresse pointe depuis Hostinger. Une fois qu'on a compris que ce sont trois briques séparées et pas trois façons de dire la même chose, tout le reste - les erreurs de déploiement, les changements d'hébergeur, la configuration DNS - devient beaucoup moins mystérieux.