Vos tests sont terminés, les bugs les plus critiques sont corrigés, vous êtes fin prêt à déployer votre projet.
Quelle que soit la qualité des développements et des tests que vous avez supervisés sur l’ensemble des composants de votre projet, il existe sans doute encore de nombreux bugs que ni vous ni vos testeurs n’aurez détectés.
Tout l’intérêt de la phase pilote est de limiter les risques induits par ces bugs ! Voyons ensemble quelles sont les étapes pour préparer cette phase.
Déterminez le périmètre du pilote
L’objectif du pilote est de finaliser votre projet et d’en sécuriser le déploiement.
Vous profiterez de cette phase pour éprouver :
vos processus, procédures et délais de déploiement ;
la qualité de vos réalisations ;
l’autonomie des utilisateurs ;
l’autonomie des équipes support ;
les performances de votre solution.
Cette phase permet également d’analyser, de prioriser et de corriger les bugs résiduels et les éventuels besoins complémentaires rencontrés lors de cette phase.
En fonction de la taille de votre société et de son organisation, vous définirez une stratégie basée sur un ou plusieurs sites pilotes, sur une ou plusieurs phases. Je vous propose une liste (non exhaustive) de critères qui peuvent vous aider à définir votre stratégie.
La taille de vos sites
L’activité de vos sites (administratifs, industriels, commerciaux, magasins, etc.)
Le nombre d’utilisateurs sur vos sites
La géographie (régionale, nationale, continentale)
Les cas d’usages de votre solution
Par exemple, voici ma stratégie pilote pour le projet DVF sur mes 989 agences :
Pilote n° 1
Date de déploiement : 06/01/2020
Durée : 1 mois
Sites pilotes :
Agence 003 - Clermont-Ferrand
Agence 004 - Tiers
Siège - SOC001 - Clermont-Ferrand
Pilote n° 2
Date de déploiement : 09/03/2020
Durée : 15 jours
Sites pilotes :
Agence 087 - Milan
Agence 044 - Rome
Siège - SOC002 - Rome
Pilote n° 3
Date de déploiement : 09/04/2020
Durée : 15 jours
Sites pilotes :
Agence 854 - New York
Agence 867 - Houston
Siège - SOC003 - New York
Pourquoi ces choix ?
Mon premier pilote : Le siège social et deux agences en Auvergne sont situés à proximité de l’équipe projet. Il me sera facile de me rendre sur place afin d’accompagner les tout premiers utilisateurs de ma solution et ainsi, de réagir très rapidement.
Clermont-Ferrand est une grosse agence, Tiers est une petite agence. Les organisations sont différentes, mon pilote est donc suffisamment significatif tout en étant sur un périmètre réduit.
Le pilote n° 2 : Deux agences italiennes ainsi que leur siège me permettront de m’assurer de la validité de mes process et du fonctionnement de l’application dans un environnement européen.
Le pilote n° 3 : Le choix des États-Unis me permettra en plus de m’assurer de la performance de l’application dans un contexte multizone géographique, de la cohérence de l’application tenant compte du décalage horaire et des éventuelles organisations support en mode “Follow the Sun” (24 heures sur 24 : lorsque le support Europe va se coucher, c’est le support Amérique du Nord qui prend le relai !).
Initialisez les données
Toujours selon le contexte de votre projet, il sera peut-être nécessaire d’initialiser le jeu de données qui permettra à votre solution de fonctionner. J’entends par là par exemple :
La création des utilisateurs ainsi que leur rôle
L’initialisation des éventuels fichiers paramètres
L’initialisation des données de nos tables
Dans le cas de notre projet DVF, vous devrez initialiser la date de dernière extraction de la table “Devis” de votre base de données sur l’ensemble des enregistrements “Devis validés”. Sinon, votre première extraction contiendra tous les devis de l’agence depuis sa création. Ce n’est pas ce que l’on veut, car à la date de déploiement, l’ensemble des devis validés sont censés avoir déjà été facturés par le siège.
Surveillez le fonctionnement du pilote
L’objectif de cette phase consiste à observer et mesurer l’ensemble des dysfonctionnements induits par le déploiement de votre solution afin de les corriger.
À ce stade, votre application est considérée comme étant “en production”. À ce titre, les utilisateurs, les équipes support et l’équipe projet utilisent les process définis par l’entreprise. Souvent, dans les grandes entreprises, on parle d’ITSM faisant référence aux process ITIL, avec, en particulier, l’incident management. En quelques mots, il s’agit d’une méthodologie établie pour gérer efficacement le support des applications et infrastructures.
Qu’allez-vous mesurer et comment ?
Le processus de déploiement
Votre produit va bientôt être déployé sur 989 sites. Il est impensable que ce travail soit réalisé à la main, vous allez donc automatiser et documenter un maximum d’étapes et de points de contrôle. Vous allez également prendre soin d’évaluer, le plus précisément possible, le temps nécessaire à chacune des étapes.
Vous profiterez de ce premier déploiement grandeur nature pour vérifier vos théories et, le cas échéant, analyser les dérives afin de les corriger pour les prochains déploiements.
Le suivi des performances
Jour après jour, vous relèverez les temps de traitement à chaque étape afin d’analyser et de corriger les éventuelles dérives avant de déployer votre solution à grande échelle.
Bien sûr, cette analyse n’aura de sens que si elle est faite au regard de la volumétrie. Par exemple, le temps d’affichage de la liste des devis d’une agence augmente-t-il au fur et à mesure du déploiement ?
L’analyse des incidents
L’objectif ici est de mesurer et d’améliorer la stabilité de votre solution en production.
Idéalement, vous utiliserez votre outil ITSM de gestion du help desk pour traquer tous les dysfonctionnements. Si cet outil vous le permet, vous ferez une extraction de vos incidents dans un tableur. Sinon, relevez manuellement chacun d’entre eux dans un tableau.
Vous devrez suivre :
Les incidents remontés par vos utilisateurs
Les dysfonctionnements relevés par les équipes support
Les éventuelles remontées de vos outils de monitoring
Vous devrez donc, pour chaque brique de votre solution, analyser :
Les incidents classés par type
Problèmes de formation
Problèmes de données
Problème logiciel
Problèmes système et matériels (CPU, mémoire, disque)
Problèmes réseau
Erreurs humaines
Les performances des équipes support :
Capacité à comprendre les retours utilisateurs
Capacité à escalader (c’est-à-dire remonter l’incident) au niveau de support supérieur
Capacité à analyser
Capacité à résoudre
Cette analyse mettra en lumière les éventuels besoins suivants :
Complément de formation des utilisateurs
Amélioration des documentations support
Complément de formation/accompagnement des équipes support
Analyse et résolution des bugs résiduels
Dans le contexte de notre projet, voici un exemple de tableau de suivi des pilotes, à télécharger au format xls ou au format ods, qui nous permettra de faire toutes ces mesures.
Validez le pilote
Cela fait maintenant 2 mois que votre solution est déployée dans vos premières agences françaises. L’expérience de cette première étape vous a permis de déployer sur d’autres pilotes en Italie et aux États-Unis, comme prévu par votre stratégie initiale.
Votre équipe projet et vous avez résolu les difficultés les plus importantes, vous êtes confiant et fin prêt pour la suite.
La validation de votre pilote est une étape importante dans votre projet, car c’est le moment où le COPIL va décider ou non de vous autoriser à déployer votre solution à grande échelle. À vous donc d’être convaincant devant cette instance de décision.
Au-delà de ce que nous avons déjà vu :
Une page d’en-tête
Un agenda
Un rappel des objectifs et enjeux du projet
Vos pros-cons et votre préconisation
Questions-réponses
Vous présentez plus spécifiquement au COPIL :
Le résultat de votre analyse des pilotes
Vos propositions de scénarios de déploiement incluant budget, planning et dispositif
Le résultat de votre analyse des pilotes
Le résultat de cette analyse est ni plus ni moins qu’une synthèse des trois onglets (déploiement, performances et incidents) du tableau de suivi des pilotes, à télécharger au format xls ou au format ods, que nous venons de remplir ensemble. Faites preuve d’imagination et représentez graphiquement les chiffres concernant :
Le temps nécessaire pour chaque déploiement
L’analyse des incidents par type
Le temps de résolution des incidents par les équipes support
L’analyse de performance
Vous montrerez également :
Les actions engagées en vue d’améliorer ces chiffres
Ce qu’il reste à faire
Proposition de scénarios de déploiement
On en a souvent parlé : il n’y a pas de règle toute faite pour écrire un scénario, c’est à vous d’analyser la situation et d’imaginer la meilleure solution.
Je vous propose trois scénarios possibles, à vous de choisir ceux que vous présenterez au COPIL.
Par vagues successives
Il s’agit dans ce cas de planifier des lots de déploiements sur une période donnée. Chaque vague concerne un nombre sensiblement équivalent d’agences.
Dans notre exemple, nous avons 989 sites, dont 9 ont fait l’objet de nos 3 pilotes. Il nous en reste donc 980 à déployer.
On peut donc imaginer 9 vagues de 100 sites et une dernière de 80 sites, le tout planifié sur 10 mois.
L’avantage principal d’une telle approche est de vous permettre de surveiller et d’anticiper au mieux les éventuels problèmes de performance ainsi que le dimensionnement des équipes support.
Par vagues progressives
C’est une alternative aux vagues successives.
Votre première vague concernera 10 sites, par exemple. La seconde 50. La troisième 100. La quatrième 200. Et ainsi de suite jusqu’à avoir déployé la solution sur l’ensemble du périmètre.
L’avantage dans ce cas est de vous assurer en plus du dimensionnement de l’équipe de déploiement.
Big Bang
Le principe du Big Bang consiste à déployer votre solution en une fois sur l’ensemble du périmètre.
L’avantage est que l’ensemble de vos utilisateurs utilisent la même solution en même temps, cela facilite le support qui n’a pas à se poser de question quant aux logiciels utilisés.
Les risques induits par cette approche sont de deux natures :
la performance des infrastructures face à une montée en charge brutale ;
l’apparition de nouveaux bugs non décelés jusque là ;
le nombre important d’appels au support et donc la capacité des équipes à répondre aux sollicitations.
En résumé
Nous avons mis en place une phase pilote et nous avons suivi avec attention son bon fonctionnement. Pour ce faire, nous avons :
construit trois tableaux afin de suivre et corriger les bugs les plus importants ;
mesuré l’efficacité de notre scénario de déploiement ;
et mesuré l’évolution de la performance de notre application.
Cela nous a permis de proposer au COPIL plusieurs scénarios de déploiement.
Alors, laquelle de ces trois propositions vous semble être la plus adaptée au contexte du projet “Devis vers Factures” :
Un déploiement par vagues successives ?
Un déploiement par vagues progressives ?
Un Big Bang ?
Peut-être avez-vous une autre proposition ?
En ce qui me concerne, je préfère le déploiement par vagues progressives qui me permettra de :
surveiller et anticiper au mieux les éventuels problèmes de performance de l’application liés à la montée en charge ;
m’assurer que le dimensionnement des équipes support est adapté ;
m’assurer que le dimensionnement des équipes de déploiement est adapté.
Cela me permettra donc de prendre les mesures adéquates en cas de dérive. Passons à la dernière phase du projet !
