Ce qui se passe vraiment lors d'un déploiement : placer les artefacts dans les environnements

Vous avez construit votre application, exécuté les tests et stocké un artefact vérifié. Voici maintenant le moment que tout le monde remarque : le déploiement. C'est à ce moment que votre nouvelle version commence à tourner dans un environnement réel — que ce soit un serveur de staging pour des tests internes ou la production où les utilisateurs finaux en dépendent.

Le déploiement est l'action de placer un artefact dans un environnement cible et de le rendre actif. Mais si vous pensez que déployer se résume à copier des fichiers sur un serveur, vous allez être surpris. La façon de déployer dépend entièrement de ce que vous déployez : du code applicatif, des changements de base de données ou de la configuration d'infrastructure. Chacun a ses propres mécanismes, risques et stratégies.

Le déploiement n'est pas universel

Quand vous déployez une application, vous remplacez une version en cours d'exécution par une nouvelle. Cela peut signifier envoyer une nouvelle image conteneur à Kubernetes, remplacer des fichiers binaires sur un serveur ou redémarrer un service. L'objectif est simple : arrêter l'ancienne version et démarrer la nouvelle avec un minimum de perturbation.

Le déploiement de base de données est un tout autre défi. Vous ne remplacez pas des fichiers ; vous exécutez des scripts de migration qui modifient les schémas ou transforment les données. Une base de données contient de l'état — enregistrements utilisateurs, commandes, configurations — qui doit rester cohérent avant, pendant et après le changement. Vous ne pouvez pas simplement « écraser » une base de données comme vous remplaceriez un fichier JAR. Une migration qui ajoute une colonne peut être sûre, mais une qui renomme une table pourrait casser toutes les requêtes en cours. Et contrairement au code applicatif, les changements de base de données sont souvent irréversibles ou nécessitent des scripts de rollback minutieux.

Le déploiement d'infrastructure ajoute une autre couche. Ici, vous appliquez de la configuration à des fournisseurs cloud ou à des outils de provisionnement comme Terraform, Pulumi ou Ansible. Le déploiement crée, modifie ou détruit des ressources : machines virtuelles, équilibreurs de charge, bases de données, règles réseau. Une erreur dans le déploiement d'infrastructure peut supprimer une base de données de production ou exposer des données sensibles sur Internet. Les enjeux sont élevés et la boucle de rétroaction est plus lente que pour le déploiement applicatif.

Le diagramme suivant compare les trois flux de déploiement côte à côte :

Différentes stratégies pour différents artefacts

Étant donné que chaque type d'artefact se comporte différemment, la stratégie de déploiement qui fonctionne pour l'un peut ne pas fonctionner pour un autre.

Pour les applications, vous avez plusieurs stratégies bien connues :

Par exemple, un manifeste de Déploiement Kubernetes pour une mise à jour progressive pourrait ressembler à ceci :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
      - name: app
        image: my-app:v2.1.0
        ports:
        - containerPort: 8080

• Mise à jour progressive (Rolling update) : Remplacez les instances une par une. L'ancienne version cède progressivement la place à la nouvelle. Pas de temps d'arrêt, mais les anciennes et nouvelles versions cohabitent brièvement.
• Blue-green : Démarrez un environnement complet (vert) à côté de l'environnement actuel (bleu). Une fois l'environnement vert prêt et vérifié, basculez tout le trafic vers lui. Bascule instantanée, mais double du coût d'infrastructure pendant le basculement.
• Canary : Envoyez la nouvelle version à un petit sous-ensemble d'utilisateurs en premier. Surveillez les erreurs ou la dégradation des performances. Si tout va bien, augmentez progressivement le trafic. Sinon, annulez le canari sans affecter la plupart des utilisateurs.

Ces stratégies fonctionnent car les instances applicatives sont sans état ou peuvent être vidées proprement. Vous pouvez exécuter plusieurs versions simultanément sans corrompre les données.

Les bases de données n'ont pas ce luxe. Vous ne pouvez pas exécuter deux versions d'un schéma en même temps et vous attendre à un comportement cohérent. Une mise à jour progressive pour une migration de base de données est rarement possible car le changement de schéma est global — chaque requête voit la même structure. Les déploiements canary pour les bases de données sont tout aussi délicats. Vous pourriez exécuter la migration sur un réplica d'abord, mais au moment où vous le promouvez en primaire, tous les utilisateurs sont affectés. Les changements de base de données sont généralement tout-ou-rien : vous appliquez la migration, vous la vérifiez, et si quelque chose se passe mal, vous exécutez une migration de rollback.

Les déploiements d'infrastructure se situent quelque part entre les deux. Vous pouvez utiliser le blue-green pour l'infrastructure en provisionnant un ensemble parallèle de ressources et en basculant les cibles DNS ou de l'équilibreur de charge. Mais les changements d'infrastructure ont souvent des dépendances : vous ne pouvez pas créer une nouvelle instance de base de données sans également mettre à jour la configuration de l'application qui pointe vers elle. Et les changements d'infrastructure peuvent être lents — provisionner un nouveau cluster de serveurs peut prendre des minutes, pas des secondes.

Deux principes non négociables

Quel que soit ce que vous déployez ou la stratégie que vous choisissez, deux principes s'appliquent à chaque déploiement.

Premièrement : les déploiements doivent être reproductibles. Si vous exécutez le même pipeline deux fois avec le même artefact, vous devriez obtenir le même résultat. Cela signifie que vous devez déployer l'artefact que vous avez déjà vérifié, et non le reconstruire à partir des sources au moment du déploiement. Reconstruire introduit de l'incertitude : peut-être que le serveur de build avait une version de bibliothèque différente, peut-être que le réseau était lent, peut-être que le compilateur a optimisé différemment. Utilisez exactement le même binaire, la même image conteneur ou le même package qui a passé vos tests.

La reproductibilité exige également que votre environnement cible soit dans un état connu. Si vous ne pouvez pas garantir ce qui est déjà en cours d'exécution, vous ne pouvez pas prédire ce qui se passera lorsque vous déploierez. L'infrastructure-as-code aide ici : elle définit l'état souhaité de votre environnement, de sorte que votre déploiement sache à quoi s'attendre.

Deuxièmement : chaque déploiement doit être enregistré. Consignez ce qui a été déployé, quelle version, quel commit, quel environnement, l'horodatage exact, et qui ou quoi l'a déclenché. Ce n'est pas de la paperasse pour les auditeurs de conformité. C'est votre première ligne de défense quand quelque chose tourne mal. Lorsque les utilisateurs commencent à signaler des erreurs après un déploiement, le journal de déploiement vous dit exactement ce qui a changé. Sans cela, vous devinez. Était-ce le changement de code ? La mise à jour de configuration ? La migration de base de données ? Le changement d'infrastructure ? Un bon journal de déploiement réduit immédiatement la recherche.

Le déploiement n'est pas terminé quand l'artefact est placé

Voici une erreur courante : le pipeline marque le déploiement comme réussi au moment où l'artefact atterrit dans l'environnement. Mais placer l'artefact n'est que la moitié du travail. Vous devez vérifier que la nouvelle version fonctionne réellement correctement.

La vérification après déploiement est une étape distincte. Elle vérifie que le service répond aux health checks, que la migration de base de données s'est terminée sans erreur, que les ressources d'infrastructure sont dans l'état souhaité. Certaines équipes exécutent des tests de fumée (smoke tests) — un ensemble rapide de parcours utilisateur critiques — pour confirmer que le déploiement n'a rien cassé d'évident.

Tant que la vérification n'est pas réussie, le déploiement n'est pas terminé. Si la vérification échoue, le pipeline doit déclencher un rollback ou alerter l'équipe immédiatement. Attendre que quelqu'un remarque un problème des heures plus tard va à l'encontre du but de l'automatisation.

Checklist pratique avant votre prochain déploiement

Avant d'appuyer sur le bouton de déploiement ou de laisser votre pipeline s'exécuter, parcourez cette courte checklist :

• L'artefact est-il le même que celui qui a passé tous les tests ? (Pas de reconstruction au moment du déploiement.)
• L'environnement cible est-il dans un état connu ? (Pas de modifications manuelles qui pourraient entrer en conflit.)
• La stratégie de déploiement est-elle appropriée pour le type d'artefact ? (Rolling pour les applications, migration pour les bases de données, provisionnement pour l'infrastructure.)
• Existe-t-il un plan de rollback ? (Pouvez-vous revenir rapidement en arrière ? Pour les bases de données, avez-vous un script de migration de rollback prêt ?)
• Le déploiement sera-t-il enregistré automatiquement ? (Version, commit, horodatage, déclencheur.)
• Y a-t-il une étape de vérification après le déploiement ? (Health checks, tests de fumée ou alertes de monitoring.)

Ce qu'il faut retenir

Le déploiement est le moment où votre travail rencontre la réalité. Ce n'est pas une opération de copie de fichiers. C'est un transfert soigneusement planifié entre votre pipeline et votre système en cours d'exécution. Le type d'artefact détermine la stratégie, l'état de l'environnement détermine le risque, et le journal de déploiement détermine la rapidité avec laquelle vous pouvez vous remettre d'un échec. Traitez le déploiement avec la même rigueur que l'écriture de code — car un mauvais déploiement peut annuler des semaines de bon travail en quelques secondes.