Gantt de mise en production logicielle : du gel du code à la production
Un diagramme de Gantt modifiable pour une version logicielle : fonctionnalités terminées, gel du code, non-régression, performance, recette, validation, déploiement, test de fumée et suivi, avec dépendances et jalons.
Qu'est-ce que le processus gantt de mise en production logicielle : du gel du code à la production ?
La partie risquée d'une mise en production est rarement le code. Ce sont les quelques jours entre la dernière fonctionnalité et le premier utilisateur, quand les tests, la documentation et le déploiement doivent se terminer dans le bon ordre alors que la date est déjà connue de tous. Un diagramme de Gantt convient bien à cette période : les tâches sont courtes, les dépendances sont réelles et un jour de retard quelque part se voit partout en aval.
Ce modèle commence à « Valider le périmètre de la version » et se termine à « Rétrospective de la version ». Le développement s'achève avec le jalon « Fonctionnalités terminées », tandis que « Corriger les défauts connus » démarre cinq jours ouvrés après le début de « Terminer les fonctionnalités restantes », si bien que la correction des défauts chevauche la fin du développement. Les deux doivent être terminés avant le jalon « Gel du code ». Après le gel, trois flux de tests démarrent : « Tests de non-régression », « Contrôles de performance et de sécurité » et « Recette utilisateur », qui commence deux jours ouvrés après le début du gel. « Corriger les bloquants » attend les trois.
Les notes de version et le runbook sont rédigés pendant les tests, pas après, de sorte que « Déployer en production » attend « Validation de la version », « Rédiger les notes de version » et « Mettre à jour le runbook et le plan de retour arrière ». Après le déploiement, « Test de fumée en production » conditionne à la fois l'annonce et la période de surveillance. Activez le chemin critique pour voir quel flux de tests fixe la date. Les durées sont des jours ouvrés indicatifs (du lundi au vendredi) ; remplacez-les par les vôtres.
Pour l'ensemble du projet qui mène à une version, voyez le [modèle de diagramme de Gantt de projet logiciel](/fr/templates/modele-diagramme-de-gantt-projet-logiciel). Ce modèle ne se connecte ni à un dépôt de code ni à un outil de tickets, et il ne suit ni les défauts ni les déploiements : il planifie le calendrier. Les dépendances sont expliquées dans le [guide des dépendances d'un diagramme de Gantt](/fr/guides/dependances-diagramme-de-gantt).
Ce que couvre cet organigramme
Dans ce modèle
- Quatre groupes, Développement, Tests, Livraison et Assistance, avec 17 tâches et trois jalons : « Fonctionnalités terminées », « Gel du code » et « Validation de la version ».
- Des travaux qui se chevauchent : « Corriger les défauts connus » commence cinq jours ouvrés après le début de « Terminer les fonctionnalités restantes ».
- Trois flux de tests après le gel : « Tests de non-régression », « Contrôles de performance et de sécurité » et « Recette utilisateur », avec une jonction à « Corriger les bloquants ».
- Une préparation qui n'attend pas les tests : « Rédiger les notes de version » et « Mettre à jour le runbook et le plan de retour arrière » démarrent tous deux au « Gel du code ».
- Une fin sous conditions : « Déployer en production » attend « Validation de la version », et « Test de fumée en production » conditionne « Annoncer la version » et « Surveiller et traiter les premiers incidents ».
Quand utiliser ce modèle
- Vous livrez à date fixe et voulez voir ce que demande réellement la période entre le gel et la production.
- Les tests, la documentation et l'exploitation sont assurés par des personnes différentes et ont besoin d'un seul planning.
- Vous voulez une liste de contrôle de version avec des durées et des dépendances plutôt qu'une simple liste.
- Il vous faut un plan de départ pour un cycle de versions régulier, que vous pourrez réutiliser à chaque itération.
Le plan, tâche par tâche
Toutes les tâches du diagramme avec leur durée en jours ouvrés et ce qu'elles attendent. Une dépendance est un numéro d'étape ; SS signifie début à début, FF fin à fin et +n un décalage en jours ouvrés.
| # | Tâche | Groupe | Jours ouvrés | Dépend de |
|---|---|---|---|---|
| 1 | Valider le périmètre de la version | Développement | 2 | |
| 2 | Terminer les fonctionnalités restantes | Développement | 10 | 1 |
| 3 | Fonctionnalités terminées | Développement | Jalon | 2 |
| 4 | Corriger les défauts connus | Développement | 6 | 2SS+5 |
| 5 | Gel du code | Développement | Jalon | 3, 4 |
| 6 | Tests de non-régression | Tests | 5 | 5 |
| 7 | Contrôles de performance et de sécurité | Tests | 4 | 5 |
| 8 | Recette utilisateur | Tests | 6 | 5SS+2 |
| 9 | Corriger les bloquants | Tests | 3 | 6, 7, 8 |
| 10 | Validation de la version | Livraison | Jalon | 9 |
| 11 | Rédiger les notes de version | Livraison | 3 | 5 |
| 12 | Mettre à jour le runbook et le plan de retour arrière | Livraison | 3 | 5 |
| 13 | Déployer en production | Livraison | 1 | 10, 11, 12 |
| 14 | Test de fumée en production | Livraison | 1 | 13 |
| 15 | Annoncer la version | Assistance | 1 | 14 |
| 16 | Surveiller et traiter les premiers incidents | Assistance | 5 | 14 |
| 17 | Rétrospective de la version | Assistance | 1 | 16 |
Comment cela fonctionne
Remplacer les tâches par les vôtres
Renommez les 17 tâches et les quatre groupes. Ajoutez ou retirez des flux de tests pour refléter votre façon de tester.
Définir le gel comme jalon
Faites du « Gel du code » une tâche de durée nulle qui dépend de tout ce qui doit être terminé avant le début des tests, et faites dépendre chaque flux de tests de ce jalon.
Laisser la préparation chevaucher les tests
Faites démarrer les notes de version et le runbook au gel, avec leurs propres liens, et non après les tests, pour qu'ils ne repoussent pas la date.
Joindre les flux avant la validation
Faites dépendre la tâche de correction de chaque flux de tests, afin que la validation ne puisse pas apparaître avant la fin de tous.
Vérifier le chemin critique
Utilisez Affichage, puis Chemin critique. Si un flux de tests est l'enchaînement le plus long, raccourcir le développement n'avancera pas la version.
Réutiliser le plan
Après la version, dupliquez le diagramme, ajustez les durées d'après la rétrospective et servez-vous-en pour le cycle suivant.
Questions fréquentes
Qu'est-ce qu'un diagramme de Gantt de mise en production logicielle ?
Un diagramme de Gantt du calendrier qui va de la dernière fonctionnalité aux premiers jours en production : gel, tests, validation, déploiement et surveillance, avec les dépendances entre ces étapes.
Se connecte-t-il à Jira ou à GitHub ?
Non, il n'y a aucune intégration. Vous saisissez ou collez les tâches et leurs dépendances, et le planning en est calculé.
Puis-je mener des flux de tests en parallèle ?
Oui. Donnez à chaque flux une dépendance envers le gel et faites dépendre la tâche suivante de tous. Le chemin critique montre lequel fixe la date.
Les durées sont-elles réalistes ?
Ce sont des jours ouvrés indicatifs. Remplacez-les par l'historique de vos propres versions.
En quoi est-ce différent du modèle de projet logiciel ?
Le modèle de projet logiciel planifie toute une réalisation, des exigences au lancement. Celui-ci ne planifie que la période de mise en production, avec plus de détail.
