C’est bon, votre serveur Nest.JS que vous testez sur l’environnement de DEV depuis quelques semaines marche au poil. Il suffit de cliquer sur un bouton pour le déployer en PROD.
Sauf que voilà, vous utilisez la promotion de code et votre image DOCKER de votre pipeline est configurée en node:latest. C’est cette nuit que la version a été changée en v20 avec tous les superbes changements cassants côté dépendance crypto.
Pourtant vous l’aviez bien testée…
C’est dommage, il aurait pourtant suffi d’utiliser le PACKAGE qui tournait bien en DEV et le déployer, sans ne RIEN CHANGER.
Ce scénario n’est pas un cas isolé. Builds non-reproductibles, dépendances qui changent entre deux environnements, temps de déploiement rallongé parce qu’on recompile à chaque étape, échec de conformité lors d’un audit parce qu’on ne peut pas prouver que le binaire en prod est bien celui qui a été testé… Autant de problèmes qui coûtent du temps, de la confiance et parfois de la disponibilité.
Dans cet article, artefact désigne tout livrable issu d’un build : image Docker, archive JAR/WAR, bundle JavaScript, binaire compilé, package npm, chart Helm… Le principe de promotion s’applique à tous.
Pipeline CI/CD : deux approches
Sur mes différents projets, il y a toujours au moins deux grandes catégories d’environnements (DEV / PROD) et cela peut monter selon les besoins (UAT, STAGING, PRE-PROD…).
Chaque équipe ayant sa propre inertie, le délai entre chaque étape peut se compter en jours.
Alors si je dois re-télécharger à chaque étape mes dépendances, compiler tout en croisant les doigts que l’environnement de BUILD n’ait pas bougé, les problèmes ne tardent pas à arriver.
Comment je faisais avant : la promotion de code
Je poussais sur une branche DEV, c’était parti pour l’INSTALL, BUILD, TESTS et DEPLOY en environnement de DEV.
Quand on voulait déployer en prod, un petit coup de PR et passage sur une branche RELEASE (PROD par exemple), puis c’était reparti pour INSTALL, BUILD, TESTS et DEPLOY en environnement de (PRE-)PROD.
Dans cette approche, c’est la politique de changement de branche qui définit le type d’artefact que je fais.
- Quand je pousse sur DEV, cela déploie sur l’environnement DEV.
- Quand je pousse sur PROD, cela déploie sur l’environnement PROD.
Avantages
- Facile à comprendre, nom de la branche == environnement
- Facile à versionner, la dernière version sur la branche qui passe les tests == la dernière version déployée
- Rapide à mettre en place pour une équipe avec plusieurs personnes
Inconvénients
- Le code est peut-être identique, mais rien ne nous assure que les versions compilées le soient. Une version DEV peut être différente de PROD. Les dépendances ou l’image Docker qui a fait le build sont peut-être différentes.
- Plus long à valider, et donc à déployer. Les tests de DEV auront soit été évités, soit été repassés pour le même code (parce qu’artefact différent).
La promotion d’artefact : déployer la MÊME chose en DEV et PROD
Je garde toujours une politique de branche. Mais je décorrèle le déploiement de l’acte de pousser sur une branche.
Il s’agit de deux choses distinctes. Le fait de pousser sur une branche déclenche le niveau maximal auquel un artefact peut aller.
- Quand je pousse sur DEV, l’artefact construit n’ira pas plus loin que l’environnement de DEV
- Quand je tag une version release, l’artefact traversera tous les environnements jusqu’à la PROD
Et comment cela se passe ?
- Envoi : une version est envoyée à mon gestionnaire de version
- Compilation et Packaging : pour générer un artefact optimal, qu’on versionne.
Une approche sémantique (
Majeur.Mineur.Patchpar exemple) c’est un minimum, et avec un identifiant unique de build c’est encore mieux (Majeur.Mineur.Patch.Build) ! Si possible, ajout de suffixe pour différencier les versions DEV / PROD (vous avez le choix :SNAPSHOT,RC… Cette partie-là dépend de l’organisation de l’équipe.) - Tests statiques : on passe toute la phase d’analyse statique du code (qualité, tests unitaires…) pour ne pas pousser ce qui ne passe déjà pas la première barrière
- Livraison et stockage : la version est livrée sur un gestionnaire d’artefacts (Nexus par exemple) de DEV
- Audits d’artefact : les étapes de CI de tests et d’audits viennent récupérer l’artefact et s’appuient dessus pour le tester
- Déploiement de la DEV : on récupère l’artefact et on le pousse dans l’environnement de DEV
Si la version est identifiée comme “Release”, et que c’est OK, on passe au niveau supérieur !
- Promotion : l’artefact de DEV est promu. Il passe en PROD et est “scellé” : pas possible de pousser une version avec le même numéro ni d’éditer son contenu
- Déploiement des environnements PRE-PROD : chaque environnement PRE-PROD récupère le dernier artefact et passe les différents tests (migration, performances, acceptances…)
- Passage en PROD : lors de la release
Un bug de régression critique est rencontré en PROD ?
Il suffit de cibler une version antérieure fonctionnelle et de lancer le Rollback.
- Maintenez au moins les 3 dernières versions stables dans votre registre de production
- Automatisez le rollback dans votre pipeline : un clic, pas un processus manuel
- Testez le rollback régulièrement — un rollback qui n’a jamais été testé ne fonctionne pas quand on en a besoin
(Bien sûr, la gestion de version de la DB c’est un problème tout entier que nous n’aborderons pas ici.)
Pourquoi séparer les registres DEV et PROD ?
Cela permet une meilleure gestion des droits d’accès en fonction des équipes.
On peut appliquer des politiques différentes : par exemple, les artefacts de développement peuvent être supprimés plus rapidement, tandis que ceux de production doivent être conservés plus longtemps pour garantir un rollback rapide.
Les outils du marché
La promotion d’artefacts s’appuie sur un registre d’artefacts (artifact registry). Voici les principaux :
| Outil | Types d’artefacts | Hébergement |
|---|---|---|
| Sonatype Nexus | Docker, Maven, npm, PyPI, NuGet… | Self-hosted / Cloud |
| JFrog Artifactory | Universel (tous formats) | Self-hosted / Cloud |
| GitHub Packages | Docker, npm, Maven, NuGet, RubyGems | Cloud |
| GitLab Container Registry | Docker, packages génériques | Cloud / Self-hosted |
| AWS ECR | Docker | Cloud (AWS) |
| Azure ACR | Docker, Helm, OCI | Cloud (Azure) |
| Google Artifact Registry | Docker, Maven, npm, Python, Go | Cloud (GCP) |
| Docker Hub | Docker | Cloud |
Tous ces registres supportent le principe de promotion. Ce qui compte, c’est la discipline du pipeline : un artefact construit une seule fois, versionné, testé, puis promu. L’outil est secondaire.
Sécurité et traçabilité
La promotion d’artefacts n’est pas qu’une question de fiabilité — c’est aussi un levier majeur pour la sécurité de la supply chain logicielle.
- Signature d’artefacts : des outils comme cosign ou Notary permettent de signer cryptographiquement chaque artefact. Seuls les artefacts signés sont autorisés à être promus.
- SBOM (Software Bill of Materials) : généré au moment du build, le SBOM est indispensable pour répondre aux exigences réglementaires (EU Cyber Resilience Act, NIST SSDF).
Comme une liste d’ingrédients sur un produit alimentaire, mais pour votre logiciel. Le SBOM inventorie tous les composants embarqués dans un artefact : librairies, versions, licences, dépendances transitives. En cas de vulnérabilité (type Log4Shell), il permet d’identifier en quelques secondes si vous êtes concerné.
- Audit trail : chaque promotion laisse une trace — qui a promu quoi, quand, depuis quel pipeline. En cas d’incident de sécurité, cette traçabilité est précieuse.
Un artefact signé + promu = preuve vérifiable que le binaire en production est exactement celui qui a été construit, testé et approuvé. C’est la base de toute démarche de supply chain security sérieuse.
Avantages
-
Fiabilité accrue — Avec la promotion d’artefacts, nous savons exactement ce que nous déployons. Rien n’est à ajouter, tout y est. Un artefact qui fonctionne à chaque étape de tests fonctionnera de la même manière en production (sous réserve des différences d’environnement, mais cela ne devrait jamais arriver… ou presque).
-
Gain de temps côté CI et CD — On évite toute l’étape de
BUILD & PACKAGE+ réduction de certaines étapes duTESTSet duDELIVER(la promotion de l’artefact peut se faire côté gestionnaire d’artefacts directement), ce qui accélère les cycles de livraison. -
Facilité d’audit — Chaque artefact est versionné et accessible, ce qui simplifie les audits externes. Besoin de réaliser des benchmarks de sécurité, de performance ou d’accessibilité sur une version précédente ? Aucun problème ! Tout est à portée de main.
-
Sécurité et conformité — Signature cryptographique, SBOM, audit trail : la promotion d’artefacts fournit les preuves vérifiables dont vous avez besoin pour la compliance et la supply chain security.
Inconvénients
- Nécessite un cycle de release bien identifié au sein de l’équipe
- Implique des outils particuliers comme un registre d’artefacts, des pipelines bien pensées et une bonne rigueur du flow
En conclusion : comment choisir ?
Choisissez la promotion de code si :
- Le projet est jeune, l’équipe petite, le cycle de release encore naissant
- Vous n’avez pas encore de registre d’artefacts ni de pipeline mature
- La rapidité de mise en place prime sur la fiabilité
Choisissez la promotion d’artefacts si :
- Vous êtes en phase de
RUNet la stabilité est critique - Plusieurs environnements doivent être traversés (DEV → UAT → STAGING → PROD)
- Vous avez besoin d’un rollback rapide et fiable
- L’équipe est suffisamment mature pour maintenir un registre et un flow de release
Dans une phase de
RUNoù la stabilité prime, j’ai beaucoup plus confiance dans la promotion d’artefacts. C’est l’assurance que ce qui a été testé est exactement ce qui tourne en production.
TL;DR
- La promotion de code rebuild à chaque environnement — simple à mettre en place, mais aucune garantie que le binaire en PROD soit celui testé en DEV
- La promotion d’artefact construit une seule fois, puis promeut le même binaire de DEV à PROD — reproductible et auditable
- Séparez vos registres DEV et PROD pour des politiques de rétention et d’accès adaptées
- Signez vos artefacts et générez un SBOM pour sécuriser votre supply chain
- Le choix dépend de la maturité : promotion de code pour démarrer vite, promotion d’artefacts dès que la stabilité devient critique
Pipeline CI/CD, stratégie de promotion, supply chain security : nous aidons les équipes tech à fiabiliser leur chaîne de livraison. Parlons-en.
