Matrice : Déploiements

Comment le produit arrive en production et chez les clients : environnements, construction, chaîne de livraison, évolutions de schéma, configuration, stratégies, contrôles, livraison aux clients.

≈ 12 min de lectureLecture

En bref

8 dimensions, niveaux 0 à 5, 112 critères.
Outil : état des lieux en choisissant « Déploiements ».
Niveaux et critères : synthèse originale, références citées en bas de page.

Sur cette page

Vue d'ensemble
Chaîne de livraison
Environnements et configuration
1. Environnements
2. Configuration et secrets par environnement
Sûreté du déploiement
Sources et vérification

Périmètre

L'acheminement du produit vers la production et vers les clients : environnements, construction et intégration continue, chaîne de livraison, évolutions de schéma et de données, configuration et secrets par environnement, stratégies de déploiement et retour arrière, contrôles après déploiement, livraison chez les clients. La vie du produit installé relève du thème « Maintenance applicative », la production courante du thème « Exploitation ».

8 dimensions, six niveaux (0 à 5) et 112 critères observables. Pour situer votre produit : ouvrir l'état des lieux de ce thème. Les règles de calcul sont ici.

Vue d'ensemble#

Chaque cellule est la signature du niveau pour la dimension.

Dimension	0 · Artisanal	1 · Local outillé	2 · Partagé	3 · Industrialisé	4 · Intégré et gouverné	5 · Autonome
Environnements	Un seul environnement : on développe et on teste sur la production.	Environnement de test.	Environnements étagés.	Environnements représentatifs.	Environnements à la demande.	Environnements éphémères.
Construction et intégration continue	La construction se fait sur le poste d'un développeur.	Construction scriptée.	Construction automatique.	Intégration continue vérifiée.	Contrôles élargis.	Construction optimisée.
Chaîne de livraison et promotion	Les livrables sont copiés à la main d'un environnement à l'autre.	Procédure écrite.	Déploiement scripté.	Chaîne automatisée.	Chaîne complète.	Livraison continue.
Évolutions de schéma et de données	Les changements de structure sont appliqués à la main en production.	Scripts conservés.	Scripts versionnés.	Migrations testées.	Migrations compatibles.	Migrations sans interruption.
Configuration et secrets par environnement	Valeurs propres à un environnement écrites dans le code, mots de passe dans les scripts.	Valeurs repérées.	Configuration séparée.	Configuration versionnée.	Secrets gérés.	Configuration pilotée.
Stratégies de déploiement et retour arrière	Un déploiement défaillant se répare en avançant, dans l'urgence.	Sauvegarde avant déploiement.	Retour arrière décrit.	Retour arrière éprouvé.	Déploiement progressif.	Retour arrière automatique.
Contrôles après déploiement	On sait que le déploiement a réussi quand personne ne se plaint.	Vérification manuelle.	Contrôles de base.	Contrôles automatiques.	Contrôles de bout en bout.	Surveillance renforcée.
Livraison et installation chez les clients	Chaque installation est un travail manuel, propre au client.	Procédure d'installation.	Kit d'installation.	Installation fiable.	Livraison gérée.	Livraison automatisée.

Lien avec le modèle global

Dimensions du modèle global les plus concernées : Industrialisation et déploiement et Tests et corrections ; également Disponibilité et performance et Sécurité et conformité.

Chaîne de livraison#

Construction et intégration continue#

Chaque changement est-il construit et vérifié automatiquement, de la même façon à chaque fois ?

Niveau	Signature	Critères à réunir
0 · Artisanal	La construction se fait sur le poste d'un développeur.	Point de départ : aucun critère.
1 · Local outillé	Construction scriptée.	La construction est décrite par un script. Le code source est conservé dans un dépôt partagé.
2 · Partagé	Construction automatique.	Chaque modification déclenche une construction sur un serveur dédié. Une construction en échec est signalée à l'équipe. Le résultat de la construction est un livrable versionné, conservé.
3 · Industrialisé	Intégration continue vérifiée.	La construction exécute les tests automatiques (unitaires, intégration). Une modification qui échoue aux tests ne peut pas être intégrée. La documentation du produit est construite avec le reste.
4 · Intégré et gouverné	Contrôles élargis.	La construction exécute aussi des contrôles de style, de sécurité et de dépendances. Les tests de bout en bout, dont les parcours utilisateurs, s'exécutent automatiquement. La durée de la construction est suivie et maintenue assez courte pour être attendue.
5 · Autonome	Construction optimisée.	Seuls les éléments touchés par un changement sont reconstruits et retestés. Un test instable est détecté et isolé automatiquement. La provenance de chaque livrable est vérifiable : qui, quand, à partir de quel code.

Effet sur l'utilisateur

Un changement cassé est détecté dans l'heure, pas à la livraison.

Chaîne de livraison et promotion#

Le passage d'un environnement à l'autre est-il automatisé, tracé et validé ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Les livrables sont copiés à la main d'un environnement à l'autre.	Point de départ : aucun critère.
1 · Local outillé	Procédure écrite.	La procédure de mise en production est écrite. Chaque mise en production est consignée avec sa date.
2 · Partagé	Déploiement scripté.	Le déploiement est exécuté par un script ou une chaîne, identique pour tous les environnements. La version déployée dans chaque environnement est connue. La même version qui a été testée est promue vers l'environnement suivant.
3 · Industrialisé	Chaîne automatisée.	Une chaîne de livraison enchaîne construction, tests et déploiement dans les environnements. Des étapes de validation (tests, approbation humaine) conditionnent le passage vers la production. Chaque déploiement est tracé : qui, quoi, quand, avec quel résultat.
4 · Intégré et gouverné	Chaîne complète.	Tous les éléments du produit (code, structure de base de données, rapports, configuration) sont déployés par la même chaîne. Les différences entre deux environnements peuvent être comparées avant un déploiement. Un déploiement peut être déclenché à tout moment par une personne autorisée, sans attendre une fenêtre spéciale.
5 · Autonome	Livraison continue.	Un changement validé peut arriver en production automatiquement. Le délai entre la validation d'un changement et sa mise en production est de quelques heures. La chaîne de livraison est elle-même versionnée, testée et corrigée comme du code.

Effet sur l'utilisateur

La même chose qui a été testée est ce qui arrive en production, sans manipulation entre les deux.

Livraison et installation chez les clients#

Comment le produit est-il livré, installé et mis à jour chez chaque client ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Chaque installation est un travail manuel, propre au client.	Point de départ : aucun critère.
1 · Local outillé	Procédure d'installation.	Une procédure d'installation est écrite. Les prérequis de l'environnement client sont listés.
2 · Partagé	Kit d'installation.	Un kit d'installation unique livre tous les éléments du produit. L'installation est scriptée et paramétrée, sans modification du kit. L'installation vérifie les prérequis avant de commencer et s'arrête avec un message clair s'ils manquent.
3 · Industrialisé	Installation fiable.	Une installation interrompue peut être relancée sans corrompre l'existant. Le résultat de l'installation est contrôlé et consigné. Le même kit sert à une première installation et à une mise à jour.
4 · Intégré et gouverné	Livraison gérée.	Chaque kit livré est testé par une installation complète sur un environnement de référence avant sa publication. Les personnalisations propres aux clients sont rejouées après chaque installation. La version installée chez chaque client et la date de dernière installation sont connues.
5 · Autonome	Livraison automatisée.	Les installations et mises à jour chez les clients sont déclenchées à distance, avec leur accord, par la même chaîne. Un échec d'installation est annulé automatiquement et signalé au support. Le délai entre la publication d'une version et son installation chez les clients est mesuré.

Effet sur l'utilisateur

Installer ou mettre à jour le produit est une opération prévisible, que le client ou le support peut mener sans surprise.

Environnements et configuration#

Environnements#

Dispose-t-on d'environnements distincts, semblables à la production, pour développer et tester ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Un seul environnement : on développe et on teste sur la production.	Point de départ : aucun critère.
1 · Local outillé	Environnement de test.	Un environnement distinct de la production existe pour essayer les changements. Les accès à la production et au test sont séparés.
2 · Partagé	Environnements étagés.	Les environnements sont étagés (développement, test, production) avec un rôle défini pour chacun. La structure des environnements est identique : mêmes composants, mêmes versions. Chaque environnement a un responsable.
3 · Industrialisé	Environnements représentatifs.	Un environnement de test contient des données représentatives, masquées si elles sont sensibles. Les environnements sont décrits par du code et peuvent être recréés. Les écarts de configuration entre environnements sont listés et justifiés.
4 · Intégré et gouverné	Environnements à la demande.	Un environnement complet peut être créé en moins d'une journée pour un essai ou une reproduction. Les environnements temporaires sont supprimés automatiquement après usage. Un environnement reproduit une installation cliente donnée pour diagnostiquer un problème.
5 · Autonome	Environnements éphémères.	Chaque changement important dispose de son environnement créé et détruit automatiquement. Le coût des environnements est suivi et limité automatiquement. La conformité de chaque environnement à sa description est vérifiée en continu.

Effet sur l'utilisateur

Ce qui marche en test marche en production, parce que les deux se ressemblent et que personne ne teste sur la production.

Configuration et secrets par environnement#

La configuration propre à chaque environnement est-elle séparée du code et protégée ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Valeurs propres à un environnement écrites dans le code, mots de passe dans les scripts.	Point de départ : aucun critère.
1 · Local outillé	Valeurs repérées.	Les valeurs qui diffèrent d'un environnement à l'autre sont listées. Les mots de passe ne figurent pas dans les documents partagés.
2 · Partagé	Configuration séparée.	La configuration de chaque environnement est séparée du livrable. Le même livrable est déployé dans tous les environnements. Les secrets sont stockés dans un coffre, jamais dans le dépôt de code.
3 · Industrialisé	Configuration versionnée.	La configuration de chaque environnement est versionnée, sans les secrets. Les paramètres manquants ou invalides bloquent le déploiement avec un message clair. Un changement de configuration suit le même circuit de validation qu'un changement de code.
4 · Intégré et gouverné	Secrets gérés.	Les secrets sont fournis au déploiement par le coffre, avec des droits limités à ce qu'il faut. Les secrets sont renouvelés selon un calendrier, sans interruption de service. Les accès aux secrets sont journalisés.
5 · Autonome	Configuration pilotée.	La configuration réelle de chaque environnement est comparée en continu à la configuration voulue. Une dérive est corrigée ou signalée automatiquement. L'effet d'un changement de configuration est simulé avant son application.

Effet sur l'utilisateur

Un même livrable se déploie partout ; seules la configuration et les secrets changent, et ils ne fuient pas.

Sûreté du déploiement#

Évolutions de schéma et de données#

Les changements de structure de base de données et de données sont-ils appliqués de façon sûre, rejouable et réversible ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Les changements de structure sont appliqués à la main en production.	Point de départ : aucun critère.
1 · Local outillé	Scripts conservés.	Chaque changement de structure est écrit dans un script conservé. Les scripts sont exécutés dans l'ordre prévu.
2 · Partagé	Scripts versionnés.	Les scripts de changement de structure sont versionnés avec le code. La version de structure de chaque base est enregistrée dans la base. Un script ne s'exécute qu'une fois, ou peut être rejoué sans effet néfaste.
3 · Industrialisé	Migrations testées.	Les migrations sont testées sur une copie de données réelles avant la production. La durée et le verrouillage de chaque migration sont mesurés. Une migration longue est découpée pour limiter l'interruption.
4 · Intégré et gouverné	Migrations compatibles.	Les changements incompatibles suivent la séquence : ajouter, migrer les usages, retirer. L'ancienne et la nouvelle version du produit fonctionnent avec la structure pendant la transition. Chaque migration a un plan de retour en arrière testé, ou une sauvegarde vérifiée juste avant.
5 · Autonome	Migrations sans interruption.	Les migrations s'appliquent sans interrompre le service. Les écarts de structure entre l'attendu et le réel sont détectés automatiquement. Les données migrées sont comparées automatiquement avant et après.

Effet sur l'utilisateur

Un changement de structure ne fait perdre aucune donnée et ne bloque aucun rapport en cours de route.

Stratégies de déploiement et retour arrière#

Un déploiement peut-il être progressif, et peut-on revenir en arrière rapidement ?

Niveau	Signature	Critères à réunir
0 · Artisanal	Un déploiement défaillant se répare en avançant, dans l'urgence.	Point de départ : aucun critère.
1 · Local outillé	Sauvegarde avant déploiement.	Une sauvegarde est faite avant chaque déploiement en production. Les créneaux de déploiement évitent les moments critiques pour les utilisateurs.
2 · Partagé	Retour arrière décrit.	Chaque déploiement a une procédure de retour arrière écrite. La version précédente reste disponible après un déploiement. Les utilisateurs sont prévenus d'une interruption prévue.
3 · Industrialisé	Retour arrière éprouvé.	Le retour arrière est testé au moins une fois par version. Les conditions qui déclenchent un retour arrière sont définies à l'avance. Un déploiement peut être appliqué à un seul client ou à un seul groupe avant les autres.
4 · Intégré et gouverné	Déploiement progressif.	Une nouvelle version est d'abord exposée à un petit groupe, puis élargie selon les résultats. L'ancienne et la nouvelle version cohabitent le temps d'une bascule (par exemple deux environnements en parallèle). Les fonctions nouvelles peuvent être activées ou désactivées sans nouveau déploiement.
5 · Autonome	Retour arrière automatique.	Un déploiement qui dégrade les indicateurs de service est annulé automatiquement. Le temps de rétablissement après un déploiement défaillant est mesuré et reste très court. Les déploiements de routine ne demandent aucune interruption visible.

Effet sur l'utilisateur

Un déploiement raté se défait en minutes, sans conséquence durable pour les utilisateurs.

Contrôles après déploiement#

Vérifie-t-on, juste après un déploiement, que le produit fonctionne vraiment ?

Niveau	Signature	Critères à réunir
0 · Artisanal	On sait que le déploiement a réussi quand personne ne se plaint.	Point de départ : aucun critère.
1 · Local outillé	Vérification manuelle.	Quelques vérifications sont faites à la main après un déploiement. La liste des vérifications est écrite.
2 · Partagé	Contrôles de base.	Un jeu de contrôles rapides (disponibilité, connexion, un rapport clé, un chargement) s'exécute après chaque déploiement. Le résultat des contrôles est enregistré avec le déploiement. Un contrôle en échec déclenche une alerte immédiate.
3 · Industrialisé	Contrôles automatiques.	Les contrôles après déploiement sont entièrement automatiques. Ils comparent des chiffres de référence avant et après le déploiement. Un échec des contrôles bloque ou annule la promotion vers l'étape suivante.
4 · Intégré et gouverné	Contrôles de bout en bout.	Des parcours complets (de la source au rapport) sont rejoués après chaque déploiement. Les droits d'accès sont vérifiés par rôle après chaque déploiement. Les contrôles sont enrichis à chaque incident causé par un déploiement.
5 · Autonome	Surveillance renforcée.	Une période de surveillance renforcée suit chaque déploiement, avec des seuils plus stricts. Les contrôles se déclenchent aussi en continu en production. Le taux d'échec des changements est suivi et décroît.

Effet sur l'utilisateur

Un déploiement qui ne marche pas est constaté tout de suite, par l'équipe, avant les utilisateurs.

Origine des critères

Les dimensions s'inspirent des références citées ci-dessous ; les niveaux et les critères sont une synthèse originale, pas une reprise d'un référentiel. Ils sont proposés pour être discutés et adaptés, pas pour faire foi.

Sources et vérification#

DORA — Software delivery performance metrics — délai de modification, fréquence de déploiement, temps de rétablissement après déploiement défaillant, taux d'échec des changements ; vitesse et stabilité ne s'opposent pas
Microsoft Learn — Overview of Fabric deployment pipelines — étapes développement, test, production ; comparaison des contenus entre étapes ; appariement des éléments ; automatisation par interfaces de programmation
Martin Fowler — Parallel Change — élargir, migrer, puis retirer, pour des changements d'interface ou de schéma de base de données compatibles à chaque étape
Microsoft Learn — Operational excellence (Azure Well-Architected Framework) — principes : automatiser, adopter des pratiques de déploiement sûr, infrastructure décrite par du code, chaîne d'approvisionnement fiable
The Twelve-Factor App — III. Config — séparer strictement la configuration du code