Aller au contenu

Environnements de déploiement

En développement logiciel, un environnement de déploiement (parfois appelé tier) est un système informatique, ou un ensemble de systèmes (ordinateur, serveur, machine virtuelle, conteneur, etc.), sur lequel une application ou un site web est déployé et exécuté.

Chaque environnement a un rôle spécifique dans le cycle de vie d'un logiciel. Il contribue à garantir la qualité, la stabilité et la sécurité du logiciel avant son utilisation en production par des utilisateurs réels.

Le nombre d'environnements varie d'une organisation à l'autre. Le schéma le plus courant, présenté ci-dessous, en compte trois : développement, pré-production et production. On rencontre aussi fréquemment un environnement de test (ou QA, Quality Assurance) intermédiaire, voire d'autres environnements (recette, démonstration, secours en cas de sinistre, etc.).

Sources :

Environnement de développement (Dev)

  • Premier stade du cycle de développement logiciel.
  • Les développeurs y écrivent, testent et déboguent leur code source. Il s'agit souvent simplement du poste de travail de chaque développeur.
  • Configuration souple et flexible pour permettre des itérations rapides.
  • Utilisation fréquente de données factices ou de jeux de données simplifiés.
  • Plusieurs développeurs peuvent travailler en parallèle sur des fonctionnalités distinctes (par exemple dans des branches Git séparées), ce qui s'inscrit bien dans une démarche agile.
  • Outils courants :
    • IDE (Visual Studio Code, IntelliJ IDEA, PyCharm, …)
    • Gestion de versions : Git, généralement associé à une plateforme d'hébergement de dépôts (GitHub, GitLab, …)
    • Débogueurs, émulateurs et conteneurs locaux pour reproduire des conditions proches de la production

Sources :

Environnement de pré-production (Staging)

  • Réplique aussi fidèle que possible de l'environnement de production (mêmes versions logicielles, configuration similaire), mais sans trafic d'utilisateurs réels.
  • Sert à valider les fonctionnalités avant leur déploiement en production.
  • Utilisation de données proches de la réalité (données de test réalistes ou données de production anonymisées).
  • Tests effectués :
    • Performances (charge, stress)
    • Sécurité
    • Compatibilité (navigateurs, systèmes d'exploitation, API, …)
    • Acceptation utilisateur (UAT, User Acceptance Testing)
  • Utilisé aussi pour tester les processus de déploiement eux-mêmes et vérifier que les mises à jour peuvent être effectuées sans erreur.

Sources :

Environnement de production (Prod)

  • Environnement final, utilisé par les utilisateurs finaux.
  • Doit être stable, sécurisé et performant, car il traite des données réelles et du trafic en direct.
  • Déploiements préparés avec soin pour éviter les interruptions de service. Longtemps réalisés pendant des fenêtres de maintenance (service temporairement coupé), ils se font de plus en plus sans interruption grâce à des techniques comme :
    • Le déploiement progressif (rolling update) : les instances de l'application sont remplacées progressivement (une par une ou par petits groupes) par la nouvelle version.
    • Le déploiement blue-green : deux environnements de production identiques, entre lesquels on bascule le trafic.
    • Le déploiement canary : la nouvelle version est d'abord proposée à une petite partie des utilisateurs.
  • Surveillance (monitoring) permanente, avec des outils comme Prometheus (collecte de métriques), Grafana (tableaux de bord) ou la suite ELK/Elastic (centralisation et analyse des journaux), pour suivre :
    • La disponibilité
    • Les performances
    • La sécurité
  • Mise en place de politiques robustes :
    • Sauvegardes régulières (et régulièrement testées)
    • Plan de reprise après sinistre (disaster recovery) pour limiter les conséquences d'une panne majeure

Sources :

deployment-environments.png

Source image

Note

Les environnements de déploiement sont au cœur des pratiques modernes de développement logiciel, telles que DevOps, l'intégration et le déploiement continus (CI/CD) et l'utilisation de conteneurs (ex. Docker). Ils permettent de gérer de manière structurée le cycle de vie d'une application et d'en garantir la cohérence, la qualité et la sécurité à chaque étape.

Sources :

DevOps

  • DevOps est une culture et un ensemble de pratiques qui rapprochent les équipes de développement (Dev) et d'exploitation (Ops).
  • Objectif : livrer des nouvelles versions plus souvent et de manière plus fiable, en automatisant l'intégration, les tests, le déploiement et la surveillance.
  • Concepts clés :
    • Pipelines CI/CD : enchaînement automatisé d'étapes (compilation, tests, déploiement) qui fait passer le code d'un environnement à l'autre (dev → staging → prod).
    • Infrastructure as Code (IaC) : décrire l'infrastructure (serveurs, réseaux, configuration) dans des fichiers de code versionnés, pour obtenir des environnements reproductibles. Exemples : Terraform ou son équivalent open source OpenTofu (création de l'infrastructure), Ansible, Puppet ou sa version communautaire open source OpenVox (configuration des machines).

Info

OpenTofu et OpenVox sont des forks : des copies d'un logiciel reprises et développées par une communauté. Ils sont nés après que les éditeurs de Terraform (2023) et de Puppet (2025) ont restreint les conditions d'utilisation de leurs logiciels. Ils restent compatibles avec l'original et peuvent généralement le remplacer.

Sources :

Sources :

CI/CD (Continuous Integration / Continuous Delivery ou Deployment)

  • CI (intégration continue) : chaque développeur intègre fréquemment (au moins une fois par jour) ses modifications dans un dépôt partagé. Chaque intégration déclenche automatiquement une compilation et des tests, afin de détecter les erreurs le plus tôt possible.
  • CD : le sigle recouvre deux pratiques voisines.
    • Continuous Delivery (livraison continue) : chaque modification validée est automatiquement construite, testée et déployée jusqu'en pré-production. Elle est prête à partir en production à tout moment, mais la mise en production est déclenchée par une validation humaine.
    • Continuous Deployment (déploiement continu) : toute modification qui passe l'ensemble des tests automatisés est déployée en production sans intervention humaine.
  • Outils populaires : GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, Azure Pipelines.

Sources :

ci-cd.png

Source image

Docker et la conteneurisation

  • Docker permet d'emballer une application et toutes ses dépendances (bibliothèques, configuration, …) dans une image. À partir de cette image, on lance des conteneurs : des processus isolés du reste de la machine, plus légers qu'une machine virtuelle car ils partagent le noyau du système d'exploitation hôte.
  • Avantages : cohérence entre environnements (dev, staging, prod), isolation, rapidité de déploiement.
  • En CI/CD, on construit une seule image, que l'on teste puis déploie telle quelle dans tous les environnements. Seule la configuration change d'un environnement à l'autre.
  • Kubernetes est un orchestrateur de conteneurs très utilisé pour exécuter en production des images construites avec Docker. Il gère notamment :
    • Le déploiement à grande échelle et les mises à jour sans interruption
    • La mise à l'échelle (ajout ou retrait d'instances selon la charge, y compris automatiquement)
    • La tolérance aux pannes (redémarrage ou remplacement des conteneurs défaillants)
    • La répartition de la charge entre les instances

Sources :

Tip

En combinant DevOps + CI/CD + Docker/Kubernetes, les équipes réduisent fortement les écarts entre environnements, et donc les erreurs du type « ça marchait sur ma machine ». Des différences subsistent toutefois (données, volume de trafic, configuration) : c'est pourquoi la pré-production et le monitoring en production restent indispensables.

Sources :