Local, préproduction et production

Pourquoi plusieurs environnements existent

L’Atelier Martin possède un site utilisé par ses clients. L’entreprise veut modifier un formulaire de contact, changer le design d’une page et tester une nouvelle extension. Faire ces essais directement sur le site public peut casser une page, rendre le formulaire indisponible ou afficher une erreur aux visiteurs.

Un site peut aussi recevoir des demandes, des commandes et des contenus déjà indexés. Une modification incomplète peut donc avoir des conséquences concrètes : perte de données, interruption de service ou contenu temporaire visible dans les moteurs de recherche.

Les environnements séparent la préparation du site de son usage réel. Ils permettent de travailler sur plusieurs versions d’un même projet, avec du code, des réglages et des données adaptés à chaque situation.

L’environnement local

Un environnement local fonctionne sur l’ordinateur du développeur, de l’agence ou du créateur du site. Il peut contenir les fichiers du projet, une copie du code, une base de données locale, un petit serveur local, des outils de développement et des données de test.

Le site local n’est généralement pas accessible au public. Il sert à préparer et essayer une modification avant de l’envoyer ailleurs. Il peut ressembler au site réel, sans être exactement le même.

« Local » ne veut pas toujours dire totalement hors ligne. Les outils peuvent encore télécharger des dépendances, contacter une API, charger une ressource externe ou utiliser Internet pour certains services.

Les avantages et limites du local

Travailler en local permet de tester rapidement sans perturber les visiteurs, d’expérimenter, de reproduire une erreur ou de préparer plusieurs versions. Un travail incomplet ne devient pas visible publiquement par accident.

Le local a aussi ses limites. L’ordinateur peut utiliser un autre système, une autre version de PHP ou de Node.js, une autre base de données ou d’autres permissions que le serveur. Les emails peuvent ne pas partir comme en production et les performances observées ne représentent pas forcément la réalité.

La préproduction

La préproduction est une version du site installée sur un serveur, mais destinée aux tests et aux validations. Elle est aussi appelée staging, recette, environnement de test ou environnement de validation selon les équipes.

Elle rapproche les essais des conditions réelles : adresse accessible, HTTPS, intégrations, affichage mobile, formulaires et cache. Elle peut aussi être montrée au client avant publication. Une préproduction n’est pas une copie parfaite de la production, mais elle aide à repérer ce que le local ne révèle pas.

Protéger la préproduction

Une préproduction ne doit pas forcément être publique. Elle peut être protégée par un mot de passe, une authentification, une restriction d’adresse IP ou un accès privé. Il est également utile de demander aux moteurs de ne pas l’indexer.

Un fichier robots.txt ou une balise noindex ne protège pas l’accès. Ces réglages donnent une indication aux moteurs, mais une personne qui connaît l’adresse peut encore atteindre le site si aucune barrière d’accès n’est en place.

Une préproduction indexée peut créer du contenu dupliqué, faire apparaître une mauvaise version dans les résultats, exposer des pages incomplètes ou laisser des URLs temporaires circuler. Ces risques justifient une protection adaptée au projet.

La production

La production est l’environnement officiel, celui utilisé par les visiteurs ou les utilisateurs. Elle reçoit les formulaires, les comptes, les paiements, les emails et les données réelles. C’est aussi la version que les moteurs peuvent indexer.

Une petite correction directe peut parfois être acceptable sur un projet simple et peu risqué. Mais plus un projet est important, plus il est utile de limiter les changements non testés. La production n’est pas un bon endroit pour découvrir qu’une extension est incompatible ou qu’un réglage manque.

Pourquoi éviter les modifications non testées

Une modification peut provoquer une erreur de code, un conflit d’extension, un contenu cassé, un problème de cache, une mauvaise configuration ou une interruption de service. Sans préparation, il peut aussi être difficile de revenir à l’état précédent.

Le niveau de prudence doit suivre le risque. Modifier un texte sur un petit site n’a pas le même impact qu’installer une mise à jour sur une boutique qui reçoit des commandes. Le guide sur les types d’hébergement rappelle aussi que le niveau de gestion et de support varie selon l’offre.

Les différences entre environnements

Un site qui fonctionne en local peut échouer en préproduction ou en production. Les versions de PHP ou de Node.js, le serveur web, le système d’exploitation, la base de données, les permissions, les noms de domaine, HTTPS, le cache, les dépendances et les ressources disponibles peuvent différer.

Des fichiers peuvent manquer, une variable de configuration peut être absente ou un service externe peut refuser une adresse inconnue. « Cela fonctionne chez moi » est donc une information utile, mais pas une preuve que le site fonctionnera partout.

Code, configuration et données

Le code décrit le fonctionnement du projet. Les fichiers envoyés peuvent contenir des images ou des documents. La configuration indique comment le projet doit se connecter à ses services. Les secrets comprennent par exemple des clés API et des identifiants. La base de données et les contenus créés par les utilisateurs évoluent séparément.

Tout ne doit pas être copié de la même manière. Le code peut passer du local vers la préproduction puis la production. Les commandes réelles ne doivent pas être remplacées par une ancienne base de test. Les clés API peuvent être différentes, les emails neutralisés en préproduction et les paiements placés en mode test.

Les variables d’environnement servent à fournir une configuration adaptée au contexte : adresse de base de données, clé API, URL du site, mode test ou production, niveau de journalisation ou identifiants d’un service. Elles évitent de mélanger ces réglages au code. Leur mise en œuvre sera détaillée dans un guide ultérieur.

Le principe d’un déploiement

Un déploiement consiste à rendre une nouvelle version disponible dans un environnement. Il peut inclure l’envoi de fichiers, la récupération du code, l’installation de dépendances, la compilation du projet, une migration de base de données, la reconstruction du cache, le redémarrage d’un service et des vérifications.

Un déploiement web n’est donc pas toujours un simple transfert FTP. Il peut être manuel ou automatisé selon le projet et le service utilisé. Les plateformes et services managés peuvent simplifier des étapes, sans supprimer le besoin de vérifier le résultat. Le guide sur l’auto-hébergement, le managé et le SaaS explique cette répartition des responsabilités.

1. Préparer la modification en local.
2. Tester le fonctionnement principal.
3. Enregistrer ou versionner les changements.
4. Sauvegarder ce qui doit l’être.
5. Déployer en préproduction.
6. Tester dans un contexte proche du réel.
7. Faire valider si nécessaire.
8. Préparer un retour arrière.
9. Déployer en production.
10. Vérifier le site après publication.
11. Surveiller les erreurs importantes.

Prévoir un retour arrière

Un rollback, ou retour arrière, consiste à revenir à une situation stable. Il peut s’agir de redéployer une ancienne version, restaurer une sauvegarde, annuler une migration ou réactiver une ancienne configuration.

Cette possibilité se prépare avant le déploiement, pas après la découverte d’un problème. Revenir au code précédent ne restaure pas forcément les données. Une commande supprimée, une migration de base de données ou un contenu modifié peut demander une action distincte.

Exemple complet

L’Atelier Martin ajoute un formulaire de demande de devis. L’équipe le construit en local avec de fausses adresses email. Elle vérifie les champs, les messages d’erreur et l’affichage mobile, puis le déploie sur staging.atelier-martin.fr.

La préproduction est protégée. L’entreprise teste le formulaire, valide le design et vérifie que les notifications de test ne contactent pas de vrais clients. Avant la mise en ligne, le site public est sauvegardé et une version précédente reste prête à être redéployée.

Après le déploiement en production, l’équipe envoie une vraie demande de test et confirme sa réception. Si le formulaire avait été modifié directement sur le site public, les visiteurs auraient pu tomber sur une erreur, perdre une demande ou recevoir un message inadapté.

Tableau comparatif

Ce qu’il faut retenir

• Le local sert à préparer et essayer sans exposer le travail au public.
• La préproduction aide à tester dans un contexte proche du réel et doit souvent être protégée.
• La production contient la version officielle et les données réelles.
• Code, configuration, secrets et données ne suivent pas toujours le même chemin.
• Un déploiement prudent inclut des vérifications et une possibilité de retour arrière.

Questions fréquentes