Passer au contenu principal

Flux de travail

BBC-Partners Solutions - Direction Innovation et Technologie

1. Vue d'ensemble des flux

La DIT gère quatre flux principaux :

Flux Description Déclencheur
Flux de développement De l'expression de besoin à la livraison Demande projet
Flux de déploiement Du code validé à la mise en production Code prêt
Flux de support Traitement des incidents et demandes Incident/Demande
Flux de demande Réception et traitement des demandes Sollicitation

2. Flux de développement

2.1 Diagramme global

┌─────────────────────────────────────────────────────────────────────────────┐
│                           FLUX DE DÉVELOPPEMENT                             │
└─────────────────────────────────────────────────────────────────────────────┘

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  1.      │    │  2.      │    │  3.      │    │  4.      │    │  5.      │
│ DEMANDE  │───▶│ ANALYSE  │───▶│CONCEPTION│───▶│RÉALISATION───▶│LIVRAISON │
│          │    │          │    │          │    │          │    │          │
└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
     │               │               │               │               │
     ▼               ▼               ▼               ▼               ▼
┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ Cahier   │    │ Specs    │    │ Dossier  │    │ Code +   │    │ Version  │
│ des      │    │ techniques│   │ de       │    │ Tests    │    │ déployée │
│ charges  │    │ détaillées│   │ conception│   │          │    │          │
└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘

2.2 Étapes détaillées

Étape 1 : Réception de la demande

Attribut Description
Origine DPS (projets clients) ou interne (produit Maintex)
Entrée Expression de besoin, cahier des charges
Responsable Directeur DIT
Sortie Demande qualifiée et acceptée

Actions :

  1. Réception de la demande formalisée
  2. Vérification de la complétude des informations
  3. Évaluation préliminaire de faisabilité
  4. Validation de la prise en charge
  5. Inscription au backlog

Étape 2 : Analyse technique

Attribut Description
Durée 2 à 5 jours selon complexité
Responsable Responsable de pôle concerné
Participants Équipe technique, Scrum Master
Sortie Spécifications techniques

Actions :

  1. Étude fonctionnelle détaillée
  2. Identification des contraintes techniques
  3. Définition des interfaces et APIs
  4. Estimation des charges (Planning Poker)
  5. Identification des risques
  6. Rédaction des spécifications techniques

Étape 3 : Conception

Attribut Description
Durée 1 à 3 jours selon complexité
Responsable Responsable de pôle
Participants Développeurs seniors, DevOps si infrastructure
Sortie Dossier de conception

Actions :

  1. Définition de l'architecture technique
  2. Modélisation des données
  3. Conception des interfaces utilisateur (maquettes)
  4. Définition du plan de tests
  5. Validation de la conception
  6. Découpage en user stories

Étape 4 : Réalisation

Attribut Description
Durée Variable (sprints successifs)
Responsable Scrum Master (facilitation), Équipe (réalisation)
Méthode Agile Scrum (sprints de 2 semaines)
Sortie Code testé et documenté

Actions :

  1. Sprint Planning : sélection des user stories
  2. Développement itératif
  3. Tests unitaires et d'intégration
  4. Revue de code
  5. Documentation technique
  6. Sprint Review et démonstration
  7. Rétrospective et amélioration continue

Étape 5 : Livraison

Attribut Description
Durée 1 à 2 jours
Responsable DevOps + Responsable de pôle
Participants DPS (recette), Client (validation)
Sortie Version en production

Actions :

  1. Préparation de la release
  2. Déploiement en environnement de recette
  3. Tests de validation (DPS/Client)
  4. Corrections éventuelles
  5. Déploiement en production
  6. Vérification post-déploiement
  7. Communication de la mise en production

3. Flux de déploiement (CI/CD)

3.1 Diagramme du pipeline

┌─────────────────────────────────────────────────────────────────────────────┐
│                           PIPELINE CI/CD                                    │
└─────────────────────────────────────────────────────────────────────────────┘

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  COMMIT  │───▶│  BUILD   │───▶│  TEST    │───▶│ STAGING  │───▶│PRODUCTION│
│          │    │          │    │          │    │          │    │          │
└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
     │               │               │               │               │
     ▼               ▼               ▼               ▼               ▼
 Déclenché       Compilation     Tests auto      Déploiement    Déploiement
 par push        + Lint          + Qualité       automatique    manuel/auto

3.2 Environnements

Environnement Objectif Déploiement Accès
Développement (Dev) Tests développeur Automatique (chaque commit) Équipe DIT
Staging (Recette) Validation fonctionnelle Automatique (merge sur develop) DIT + DPS
Production Utilisateurs finaux Manuel (après validation) Tous utilisateurs

3.3 Étapes du pipeline

Commit et push

  • Déclenchement automatique du pipeline
  • Vérification des conventions de commit

Build

  • Compilation du code
  • Vérification syntaxique (linting)
  • Analyse statique du code
  • Construction des artefacts (images Docker, packages)

Tests automatisés

  • Exécution des tests unitaires
  • Exécution des tests d'intégration
  • Calcul de la couverture de code
  • Rapport de qualité

Déploiement Staging

  • Déploiement automatique sur l'environnement de recette
  • Tests de fumée (smoke tests)
  • Notification à l'équipe

Déploiement Production

  • Approbation manuelle requise
  • Déploiement avec stratégie de rollback
  • Tests de vérification post-déploiement
  • Notification des parties prenantes

3.4 Critères de passage

Étape Critères de passage
Build Compilation réussie, 0 erreur de lint
Test 100% tests passés, couverture ≥ 70%
Staging Déploiement réussi, smoke tests passés
Production Approbation responsable, staging validé

4. Flux de support et maintenance

4.1 Diagramme du flux

┌─────────────────────────────────────────────────────────────────────────────┐
│                           FLUX DE SUPPORT                                   │
└─────────────────────────────────────────────────────────────────────────────┘

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│ INCIDENT │───▶│DIAGNOSTIC│───▶│RÉSOLUTION│───▶│VALIDATION│───▶│ CLÔTURE  │
│          │    │          │    │          │    │          │    │          │
└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
     │               │               │               │               │
     ▼               ▼               ▼               ▼               ▼
 Signalement     Analyse         Correction      Test et         Documentation
 et création     cause           ou workaround   validation      et retour
 ticket          racine                          utilisateur

4.2 Niveaux de support

Niveau Responsable Périmètre
Niveau 1 DPS Premier contact, qualification, incidents simples
Niveau 2 DIT (Pôle concerné) Incidents techniques, configuration
Niveau 3 DIT (Expert/R&D) Incidents complexes, bugs profonds

4.3 Processus détaillé

Signalement (Niveau 1 - DPS)

  1. Réception du signalement utilisateur
  2. Création du ticket dans l'outil de suivi
  3. Tentative de résolution de premier niveau
  4. Escalade vers DIT si nécessaire

Diagnostic (Niveau 2/3 - DIT)

  1. Analyse du ticket et reproduction du problème
  2. Identification de la cause racine
  3. Classification de la sévérité
  4. Estimation du délai de résolution

Résolution (DIT)

  1. Développement de la correction (ou workaround)
  2. Tests de non-régression
  3. Revue de code
  4. Préparation du déploiement

Validation

  1. Déploiement en environnement de test
  2. Validation par le demandeur (DPS ou utilisateur)
  3. Déploiement en production

Clôture

  1. Confirmation de résolution
  2. Documentation de la solution
  3. Mise à jour de la base de connaissances
  4. Clôture du ticket

4.4 SLA internes (DIT ↔ DPS)

Sévérité Temps de prise en charge Temps de résolution cible
Critique 1 heure 4 heures
Majeur 4 heures 2 jours ouvrés
Mineur 1 jour ouvré 5 jours ouvrés
Cosmétique 2 jours ouvrés Sprint suivant

5. Flux de gestion des demandes

5.1 Types de demandes

Type Description Origine Traitement
Évolution produit Nouvelle fonctionnalité Maintex Interne, Clients Backlog produit
Projet client Développement sur mesure DPS Projet dédié
Intégration Odoo Module ou personnalisation DPS Projet dédié
Support technique Question, assistance DPS, Interne Traitement direct

5.2 Processus de demande

┌─────────────────────────────────────────────────────────────────────────────┐
│                        FLUX DE DEMANDE                                      │
└─────────────────────────────────────────────────────────────────────────────┘

                              ┌──────────┐
                              │ DEMANDE  │
                              │ entrante │
                              └────┬─────┘
                                   │
                              ┌────▼─────┐
                              │QUALIFICATION
                              │(Directeur DIT)
                              └────┬─────┘
                                   │
              ┌────────────────────┼────────────────────┐
              │                    │                    │
       ┌──────▼──────┐      ┌──────▼──────┐     ┌──────▼──────┐
       │  ÉVOLUTION  │      │   PROJET    │     │  SUPPORT    │
       │   PRODUIT   │      │   CLIENT    │     │  TECHNIQUE  │
       └──────┬──────┘      └──────┬──────┘     └──────┬──────┘
              │                    │                    │
       ┌──────▼──────┐      ┌──────▼──────┐     ┌──────▼──────┐
       │  Backlog    │      │  Cadrage    │     │  Traitement │
       │  Maintex    │      │  projet     │     │  direct     │
       └─────────────┘      └─────────────┘     └─────────────┘

5.3 Informations requises pour une demande

Demande de projet/évolution

Information Description Obligatoire
Contexte Situation actuelle, problème à résoudre Oui
Objectif Résultat attendu Oui
Périmètre Fonctionnalités souhaitées Oui
Contraintes Délais, budget, techniques Oui
Priorité Urgence de la demande Oui
Demandeur Nom et contact Oui
Documents Cahier des charges, maquettes Si disponible

Demande de support

Information Description Obligatoire
Description Problème rencontré Oui
Contexte Application, environnement, utilisateur Oui
Reproduction Étapes pour reproduire Oui
Impact Conséquences du problème Oui
Captures Screenshots, logs Si disponible

6. Matrice flux / acteurs

Flux DPS Directeur DIT Scrum Master Resp. Pôle Développeur DevOps
Demande Initie Valide Informe Consulte - -
Analyse Consulte Valide Participe Réalise Participe Consulte
Conception - Valide Participe Réalise Participe Consulte
Réalisation - Supervise Facilite Coordonne Réalise Support
Livraison Valide Valide Coordonne Supervise Participe Réalise
Support N1 Réalise - - - - -
Support N2/3 Escalade Supervise - Coordonne Réalise Réalise

Documents connexes

Document maintenu par la DIT - BBC-Partners Solutions

Aucun commentaire à afficher

Retour en haut