Déployer un site statique ou une application moderne
Comprendre comment une version préparée devient disponible, sans réduire la mise en ligne à un simple transfert de fichiers.
Qu’est-ce que déployer ?
Déployer un site, c’est préparer une version du site et la rendre disponible dans l’environnement où les visiteurs vont réellement l’utiliser. L’action ne consiste donc pas toujours à envoyer des fichiers sur un serveur.
| Étape | Son rôle |
|---|---|
| Développer | Modifier le projet, son contenu ou ses fonctionnalités. |
| Construire | Préparer les fichiers ou l’application pour l’environnement cible. |
| Déployer | Placer cette version ou la rendre disponible au bon endroit. |
| Publier | La rendre accessible aux visiteurs. |
| Vérifier | Contrôler que la bonne version fonctionne réellement. |
Un déploiement peut échouer, se terminer partiellement ou demander une validation. Même lorsqu’il est annoncé comme réussi, il ne garantit pas que chaque formulaire, lien ou affichage fonctionne comme prévu.
Comprendre un site statique
Un site statique sert principalement des fichiers déjà prêts : HTML, CSS, JavaScript, images, polices et autres ressources. Un générateur ou un framework peut produire ces fichiers lors d’une étape de build, même si le projet de départ est plus élaboré.
Un site vitrine, une documentation, une page de campagne ou un portfolio peuvent être statiques. Cela ne signifie pas qu’ils sont forcément très simples, sans JavaScript ou sans contenu dynamique dans le navigateur. Cela décrit surtout la manière dont la version publiée est préparée.
Comprendre une application moderne avec une partie serveur
Une application web peut avoir besoin, en plus des fichiers visibles par le navigateur, d’un serveur qui exécute du code, d’une API, d’une authentification, d’une base de données, de variables d’environnement ou d’un rendu côté serveur. Son déploiement doit alors rendre ces éléments compatibles et disponibles ensemble.
Un framework comme Next.js peut être déployé de façons différentes selon la manière dont le projet est construit et les fonctionnalités réellement utilisées. Certaines parties peuvent être préparées comme des fichiers statiques, d’autres peuvent nécessiter une partie serveur. Il n’existe pas de règle unique qui s’applique à tous les projets.
Les grandes méthodes de déploiement
| Approche | Souvent adaptée à | Atout principal | Contrepartie | Responsabilité |
|---|---|---|---|---|
| Transfert manuel | Certains hébergements et sites statiques | Contrôle direct des fichiers | Risque d’erreur manuelle et suivi à faire | Partagée avec l’hébergeur |
| Publication depuis Git | Projets suivis dans un dépôt | Version reproductible et historique | Configuration de build à maintenir | Selon la plateforme choisie |
| Plateforme managée | Sites et applications compatibles avec son modèle | Infrastructure largement prise en charge | Règles, coûts et limites du service | Souvent réduite, mais pas nulle |
| Serveur administré | Besoins spécifiques ou applications sur mesure | Souplesse de configuration | Maintenance, sécurité et surveillance | Forte |
Un client comme FileZilla reste utile pour certains hébergements et sites statiques. Il n’est pas automatiquement la bonne méthode pour toute application moderne. Le meilleur choix dépend du projet, de l’hébergement, des responsabilités et de ce que l’équipe sait maintenir.
Le principe d’un déploiement automatique depuis Git
Un dépôt Git conserve l’historique d’un projet. Certaines plateformes peuvent surveiller une branche choisie, c’est-à-dire une ligne de travail du projet. Quand une nouvelle version y est enregistrée, la plateforme peut récupérer cette version puis effectuer les étapes prévues.
- Une nouvelle version du projet est enregistrée.
- La plateforme récupère cette version.
- Elle installe les dépendances si nécessaire.
- Elle lance le build.
- Elle publie ou met à jour le résultat.
- Elle signale la réussite ou l’échec.
Cette automatisation évite certaines manipulations répétitives, mais elle ne remplace pas la vérification humaine. Une étape peut échouer ou une version techniquement déployée peut produire un résultat inattendu.
Prévisualisation, préproduction et production
Le guide sur les environnements local, préproduction et production distingue l’endroit où l’on travaille de celui où les visiteurs consultent réellement le site. Une prévisualisation est souvent une URL temporaire générée pour vérifier une version ; une préproduction est un environnement de test plus stable ; la production est le site public.
Par exemple, une modification de formulaire peut être testée sur une URL de prévisualisation avant d’être envoyée sur le site public. Cette URL n’est pas forcément protégée ni adaptée à des données sensibles : elle doit être traitée avec prudence.
Variables d’environnement et secrets
Certains réglages ne doivent pas apparaître dans les fichiers publics. Les clés API, mots de passe et autres informations sensibles sont souvent conservés sous forme de variables d’environnement, configurées dans l’hébergement ou la plateforme de déploiement.
Ne copiez jamais une clé, un mot de passe ou une information sensible dans le code public, une capture d’écran, une documentation ouverte ou un dépôt public. Vérifiez aussi que l’environnement de prévisualisation utilise les réglages appropriés.
Déployer avec prudence : vérifier et revenir en arrière
Avant
- Identifiez l’environnement visé et la version à envoyer.
- Vérifiez les variables d’environnement nécessaires.
- Prévoyez une sauvegarde ou une version précédente connue.
- Assurez-vous que les modifications ont été relues.
Après
- Vérifiez la page ou la fonctionnalité modifiée.
- Testez sur mobile si l’interface a changé.
- Consultez les erreurs visibles et les journaux fournis par la plateforme.
- Contrôlez les formulaires, paiements ou connexions sensibles lorsqu’ils sont concernés.
- Sachez comment revenir à une version précédente si un problème apparaît.
Revenir à une version connue et fonctionnelle est parfois appelé un rollback. Le principe est simple : restaurer la dernière version fiable plutôt que de multiplier les corrections précipitées sur le site public.
La chaîne dans son ensemble
Cette catégorie se termine par une vision d’ensemble. Les fichiers, la base de données, le serveur web, le protocole d’accès et la méthode de déploiement forment une chaîne, mais ce ne sont pas la même chose. Les guides sur FTP, FTPS et SFTP puis FileZilla décrivent un accès aux fichiers ; le déploiement décrit comment une version est préparée, distribuée et vérifiée.
Comprendre ces rôles aide à poser les bonnes questions avant de choisir un outil ou de modifier un site en production.
Ce qu’il faut retenir
- Déployer rend une version préparée disponible dans l’environnement des visiteurs.
- Un site statique et une application avec partie serveur peuvent demander des méthodes différentes.
- Le transfert manuel, la publication depuis Git, les plateformes managées et les serveurs administrés répondent à des contextes différents.
- Une prévisualisation aide à tester, mais ne dispense pas de vérifier la production ni de protéger les données sensibles.
- Préparer un retour arrière réduit le risque lorsqu’un problème apparaît.