Vercel et Netlify
Comprendre les plateformes qui reçoivent un projet web, préparent sa version à publier et le déploient sur une infrastructure gérée.
À quoi servent Vercel et Netlify ?
Vercel et Netlify ne sont pas des éditeurs visuels de site comme Wix ou Squarespace. Ce sont surtout des plateformes qui reçoivent un projet web, construisent sa version à publier et la déploient sur une infrastructure gérée.
Elles sont souvent utilisées pour des sites statiques, documentations, sites marketing, frontends modernes ou applications web avec fonctions et services côté serveur selon le projet. Le projet est généralement conçu ailleurs, dans des fichiers et du code, puis publié sur la plateforme. Elles ne remplacent pas automatiquement un CMS, une base de données, une messagerie ou un outil de paiement.
Le principe du dépôt Git
Un projet contient des fichiers. Git conserve l’historique de leurs modifications ; un dépôt Git est l’emplacement où cet historique est organisé. Comme un dossier de travail qui garderait les versions successives, il permet de retrouver ce qui a changé. Une plateforme peut être reliée à ce dépôt pour détecter les nouvelles versions.
Du code à la version publiée
- Le projet est modifié.
- Une nouvelle version est enregistrée dans le dépôt.
- La plateforme récupère les fichiers.
- Elle prépare ce dont le projet a besoin.
- Elle lance un build si nécessaire.
- Elle publie le résultat ou signale un échec.
Un build transforme souvent le projet de développement en version exploitable par les visiteurs. Le guide sur le déploiement apporte les repères généraux sans répéter ici son contenu.
Déploiement automatique et prévisualisation
Ces plateformes peuvent créer une prévisualisation pour tester une modification, une version de production destinée aux visiteurs et un historique de déploiements permettant parfois de revenir à une version précédente. Une prévisualisation ne doit pas exposer de données sensibles, et un déploiement réussi techniquement ne garantit pas que le site fonctionne correctement pour les visiteurs.
Les repères sur la préproduction, les sauvegardes, la restauration et les accès restent utiles.
Site statique, fonctions et application moderne
Un site statique est principalement composé de fichiers déjà générés. Une application peut exécuter des fonctions côté serveur, utiliser une API, une base de données ou des variables d’environnement. Des services externes peuvent être reliés au projet, sans être systématiquement remplacés par la plateforme. Un site moderne ne nécessite pas forcément des fonctions serveur, et ces plateformes ne conviennent pas à toutes les architectures.
Vercel et Netlify : ressemblances et différences à examiner
| Point | Vercel | Netlify |
|---|---|---|
| Rôle principal | Déploiement et hébergement géré à vérifier selon le projet | Déploiement et hébergement géré à vérifier selon le projet |
| Git, prévisualisations et statique | Capacités à vérifier selon l’offre et le framework | Capacités à vérifier selon l’offre et le projet |
| Fonctions, domaines et variables | Dépend de l’architecture et de la configuration | Dépend de l’architecture et de la configuration |
| Historique, intégrations et retour | À vérifier avant de choisir | À vérifier avant de choisir |
Ce tableau ne compare ni prix, ni quotas, ni formules. Les capacités exactes évoluent et dépendent notamment de l’offre, du framework et de l’architecture.
Variables d’environnement et secrets
Les identifiants sensibles, clés API et réglages privés ne doivent pas être ajoutés au code public. La plateforme permet généralement de définir des variables d’environnement, utilisées lors du build ou à l’exécution selon le projet. Elles doivent être documentées, protégées et séparées selon les environnements. Une prévisualisation ne doit pas recevoir des accès de production sans réflexion.
Ce qu’il faut avoir avant de choisir
- Savoir si le projet est un site visuel, statique ou une application.
- Connaître le framework ou la technologie utilisée si elle existe.
- Savoir où se trouvent les fichiers et le dépôt.
- Identifier le processus de build, sans le détailler.
- Savoir qui gère le domaine et les DNS.
- Lister variables d’environnement et services externes.
- Prévoir sauvegardes, accès, surveillance et retour arrière.
- Vérifier la portabilité avant de lier le projet à une plateforme.
Portabilité et responsabilité
Le code et les fichiers peuvent souvent rester dans un dépôt indépendant, mais variables d’environnement, domaines, redirections, fonctions, intégrations et règles de déploiement peuvent être propres à une plateforme. Cela ne signifie pas qu’un changement est impossible : une migration demande un inventaire et des tests, comme le rappelle le guide sur la migration.
Les plateformes comme Shopify, Webflow, Wix et Squarespace répondent à une logique plus intégrée. Le prochain guide expliquera pourquoi certaines plateformes incluent directement l’hébergement, sans créer de lien tant qu’il reste à venir.