Quand tu tapes mon-site.com dans un navigateur, il ne sait pas vers quel serveur envoyer la requête. Avant même d'établir une connexion HTTP, il doit résoudre un problème de traduction : passer d'un nom humain à une adresse IP machine. C'est le DNS. Et une fois que l'adresse est connue, encore faut-il que ton code soit là, quelque part sur Internet, prêt à répondre. C'est l'hébergement et le déploiement.
De l'URL à l'IP
Le DNS (Domain Name System) est l'annuaire téléphonique d'Internet. Il fait correspondre des noms lisibles comme blokby.fr à des adresses IP numériques comme 76.76.21.21.
Voici ce qui se passe chaque fois que ton navigateur charge un site :
Résolution DNS : du nom de domaine à l'adresse IP, puis requête HTTPS.
Ton OS maintient un cache local. Si tu as visité le site récemment, la réponse est déjà là et les étapes DNS sont court-circuitées. Sinon, il interroge un serveur DNS configuré (souvent celui de ton FAI, ou un public comme 1.1.1.1 de Cloudflare).
Les records DNS à connaître
Un domaine est défini par une série d'enregistrements (records) stockés chez ton registrar ou ton gestionnaire DNS. Les cinq types fondamentaux :
| Type | Rôle | Exemple |
|---|---|---|
| A | Domaine vers IPv4 | blokby.fr → 76.76.21.21 |
| AAAA | Domaine vers IPv6 | blokby.fr → 2606:4700::... |
| CNAME | Domaine vers un autre domaine | www.blokby.fr → blokby.fr |
| MX | Indique le(s) serveur(s) de mail | blokby.fr → mail.proton.me |
| TXT | Texte libre (vérifications, SPF, DKIM) | "v=spf1 include:..." |
Apex vs sous-domaine
L'apex (ou "naked domain") est le domaine sans préfixe : exemple.com. Un sous-domaine est préfixé : www.exemple.com, api.exemple.com.
Le problème historique : la RFC interdit de mettre un CNAME sur l'apex. Tu ne peux donc pas faire pointer exemple.com directement vers ma-app.vercel.app. La solution moderne est l'enregistrement ALIAS (ou ANAME), supporté par la plupart des gestionnaires DNS modernes (Cloudflare, Vercel DNS, etc.). Il se comporte comme un CNAME mais est autorisé à l'apex.
Si ton gestionnaire DNS ne supporte pas ALIAS, l'alternative est un record A avec l'IP fixe fournie par ta plateforme.
Nameservers : déléguer la zone DNS
Tu peux soit garder les nameservers de ton registrar (OVH, Namecheap, Gandi...) et y configurer tes records A, CNAME et MX directement dans leur interface, soit déléguer la zone DNS à un service tiers en changeant les nameservers chez le registrar pour qu'ils pointent vers ceux du service choisi (Cloudflare DNS, Vercel DNS...). Cette délégation se fait en une seule manipulation, et tu gères ensuite tous tes records dans l'interface du service tiers. Beaucoup d'utilisateurs choisissent Cloudflare pour cette délégation : ils bénéficient du proxy Cloudflare (protection DDoS, cache CDN), d'une interface DNS plus réactive, et de TTL très courts pour des propagations rapides.
TTL et propagation
Chaque record DNS porte un TTL (Time To Live), exprimé en secondes. C'est la durée pendant laquelle les resolvers peuvent mettre le record en cache avant de le re-demander.
L'hébergement : trois approches modernes
Pour que ton code soit accessible sur Internet, il faut un serveur qui tourne quelque part. En 2026, trois familles :
| Critère | PaaS (Vercel, Netlify, Render) | VPS (Hetzner, DigitalOcean) | Cloud managed (AWS, GCP) |
|---|---|---|---|
| Setup initial | Quelques clics | 1-2 heures | Plusieurs jours |
| Ops à gérer | Zéro | OS, nginx, certificats, mises à jour | Granularité extrême |
| Coût mensuel (petit projet) | Gratuit à ~10€ | 4-8€ | Variable, souvent plus cher |
| Mise à l'échelle | Automatique | Manuelle | Automatique mais complexe |
| Recommandé pour | Débutant à studio | Infra maîtrisée | Grande équipe, besoins spécifiques |
Pour un projet solo ou une startup early-stage, le PaaS est le choix évident : tu pousses du code, la plateforme s'occupe du reste.
Le cycle de déploiement moderne
Voici ce qui se passe entre un git push et une nouvelle version en ligne :
Tu pousses un commit
Un git push origin main envoie tes changements sur GitHub (ou GitLab, Bitbucket). Le dépôt distant est maintenant à jour.
La plateforme détecte le push
Vercel, Netlify ou Render ont une intégration GitHub. Un webhook notifie la plateforme dès qu'un commit atterrit sur la branche configurée (souvent main pour la production).
Build : compilation et bundling
La plateforme lance ton script de build (pnpm build pour Next.js par exemple). Elle compile le TypeScript, bundle les assets, génère les pages statiques. Si le build échoue, le déploiement s'arrête là.
Déploiement de la version compilée
Les fichiers compilés sont distribués sur les serveurs edge de la plateforme (CDN mondial). La nouvelle version reçoit une URL unique (ex : mon-app-git-main-abc123.vercel.app).
Le DNS fait le reste
Ton domaine personnalisé pointe déjà vers la plateforme. La plateforme route le trafic vers la nouvelle version. Aucune manipulation DNS à faire à chaque déploiement.
Preview deployments
Les plateformes PaaS modernes créent une URL unique pour chaque pull request ou branche. Pousse une PR, récupère un lien https://mon-app-pr-42-xyz.vercel.app partageble avec ton client ou ton équipe.
C'est la différence radicale avec l'époque "j'envoie le fichier via FTP et je prie". Tu peux tester une feature en isolation, recueillir du feedback, sans jamais toucher la production.
HTTPS automatique
Les plateformes PaaS provisionnent automatiquement un certificat TLS via Let's Encrypt dès que tu connectes un domaine. Quelques minutes après la validation DNS, ton site est accessible en HTTPS avec un cadenas vert.
Tu n'as plus à :
- générer une clé privée,
- faire une demande de certificat (CSR),
- l'installer sur un serveur nginx,
- ni le renouveler tous les 90 jours.
Le reverse proxy de la plateforme s'en charge. Le certificat se renouvelle automatiquement avant expiration.