Une erreur est survenue de notre côté
Sélectionner une révision Git
pipotron.txt 42,89 Kio
D’avril à octobre 2018, dans le cadre de mon stage de fin d’études à l’ENSIIE, j’ai eu
l’occasion de découvrir le monde du conseil auprès de la société Beijaflore en participant, entre
autres, à la réalisation d’une mission chez un client, tout en organisant ou en participant à des
activités avec d’autres consultants Beijaflore.
Beijaflore est un cabinet de conseil fondé en 2000 qui regroupe plus d’un millier de
collaborateurs répartis entre Paris, Bruxelles, Sao Paulo et New York et qui accompagne les
entreprises dans leurs projets de transformation digitale.
Cet accompagnement se fait au travers des 3 grands pôles – ou Business Unit – du
cabinet :
La BU IT Advisory, qui a pour mission de promouvoir des solutions
technologiques et d’implémenter des méthodologies innovantes pour
accompagner les DSI des grands comptes dans leurs projets de
transformation SI.
La BU Cyber Risk & Security, qui accompagne les grands groupes dans
l’évaluation des risques informatique et le déploiement des systèmes de
protection.
La BU Business Consulting, à laquelle je suis rattaché au cours de mon stage,
pour laquelle l’objectif est de mettre en place des solutions business et des
méthodologies innovantes. En effet, l’évolution permanente des marchés
oblige les entreprises à se doter d’outils novateurs pour maintenir leur
attractivité et leur niveau de compétitivité. Transformation digitale,
amélioration de l’expérience clients et data management sont au cœur de
leurs enjeux.
Les consultants Beijaflore répondent à ces problématiques pour différentes grandes
entreprises, que ce soit depuis le siège de Beijaflore, dans le XVIe arrondissement de Paris, ou
directement dans les locaux du client concerné, au plus près de ses équipes.
C’est donc au sein de Beijaflore que j’ai pu effectuer mon stage de fin d’études à l’ENSIIE,
du 30 avril 2018 au 26 octobre de la même année, en tant que consultant stagiaire.
Aussi connu sous le nom de transition numérique, elle est le cœur de cible du marché
de Beijaflore. En effet, pour toute entreprise, quel que soit son domaine, tout est affaire
d’information.
Celle-ci permet de garder des traces, peut être un support pour l’action ou une aide à la
prise de décision et à la coordination du travail : elle est ce qui permet à l’entreprise de
fonctionner.
Avec l’arrivée des ordinateurs et des algorithmes automatisés qui les accompagnent,
puis ensuite d’internet, qui a permis une démultiplication des transmissions d’informations, les
entreprises traditionnelles ont dû peu à peu se transformer en entreprises numériques, en
entreprises qui, pour être toujours plus performantes dans leurs process, les ont optimisés et
en ont créé de nouveaux avec les outils digitaux qui s’offraient à elles.
Cette transformation passe aussi par une dématérialisation de nombreux éléments, qui
pose alors une question de sécurité : des données numériques ne se protègent pas du tout de
la même manière que des données inscrites sur du papier par exemple. Elle nécessite une prise
de conscience globale, chez l’ensemble des collaborateurs d’une entreprise qui peuvent, à leur
insu, créer d’importantes brèches de sécurité.
Ainsi, la digitalisation crée toujours de nouvelles opportunités, de nouvelles possibilités,
mais elle amène avec elle également son lot de dangers, contre lesquels les entreprises se
doivent de se prémunir.
Informer et éduquer les entreprises à ces nouvelles menaces, c’est un des axes de travail
des sociétés de conseil du numérique. On se rend alors compte que la transformation digitale
est, d’une part, une nécessité et un besoin pour les entreprises traditionnelles, et, d’autre part,
une source de revenus qui se chiffre en milliards d’euros pour les sociétés de conseil et les
entreprises de services du numérique.
Alors que la transition numérique a commencé il y a plus de vingt ans, les entreprises
du marché français n’en ont pris conscience que relativement récemment. Bien qu’on ait pu voir
fleurir de nombreuses startups toutes aussi innovantes les unes que les autres, et qui s’appuient
sur le numérique, le big data, le machine learning et les nouvelles technologies en règle générale,
les entreprises traditionnelles n’ont, elles, que peu anticipé les choses.
Cette transformation digitale était vue jusqu’à récemment comme une source de coûts
par les directions de ces entreprises, qu’il s’agisse des PME ou des grands groupes du CAC40.
Mais les choses ont changé, et de nombreux projets, à plus ou moins grande échelle, naissent
afin de faire évoluer la façon de fonctionner des entreprises, pour les rendre plus adaptables,
plus réactives, tout simplement plus ancrées dans la réalité d’un monde digital.
Au-delà de l’entreprise, le fonctionnement de toute la société a changé : le toutconnecté fait désormais partie intégrante de la vie de chacun, les entreprises leaders sur le
marché mondiale, les GAFAM – Google, Apple, Facebook, Amazon et Microsoft – sont toutes
issues du numérique, les échanges de données n’ont jamais été aussi importants, conduisant
même les entités politiques à les encadrer, via par exemple le Règlement Général sur la
Protection des Données – ou RGPD.
En France c‘est ce changement sociétal qui provoque la transformation des entreprises,
et non l’inverse, ce qui peut paraitre regrettable, mais qui est une aubaine pour les sociétés de
conseil – comme Beijaflore – qui vont servir de support à la transition pour le marché français,
grâce à l’expérience qu’elles ont déjà accumulée.
Les changements provoqués par la transformation digitale ont d’abord été matériels,
puis ont influencé les processus et enfin ont été stratégiques, car les nouvelles technologies de
l’information et de la communication ont ouvert la voie à de nouvelles approches pour
l’élaboration des stratégies d’entreprise.
L’alignement stratégique – la démarche consistant à faire se correspondre la stratégie
générale de l’entreprise et sa stratégie de développement technologique – tend à créer des
conflits entre les Directions Générales et les Directions des Systèmes d’Information.
En effet, là où la Direction Générale voit la Direction des Systèmes d’Information comme
une charge, coûteuse et très demandeuse en investissements, en particulier avec l’accélération
de la transformation digitale ces dernières années, se trouve en réalité de nombreux atouts pour
son activité.
Au-delà du soutien aux activités permis par l’automatisation de nombreuses tâches ou
le stockage massif de données, les SI sont des éléments-clé d’innovation porteurs de potentiel,
et c’est pourquoi une ouverture d’esprit, tant côté DG que côté DSI, est primordiale, car il faut
aussi se rappeler que la Direction Générale a, bien entendu, une vision d’ensemble plus étendue
du travail effectué par l’entreprise, de ses besoins, de ses résultats et de ses capacités.
Ainsi, le consultant, élément par nature extérieur à l’entreprise, trouve ici sa place en
apportant un regard neuf, extérieur, mais surtout impartial sur les questions d’évolution de
l’entreprise en terme de digitalisation.
Afin d’être pertinente, la stratégie d’entreprise au sein de la transformation digitale doit
se concrétiser en projet.
Importer les nouvelles technologies dans l’organisation de l’entreprise sans y apporter
de réelle réflexion ne suffit pas, car, d’une part, cela impose des changements d’organisation
non négligeables, qui doivent conduire à une révision des process, et, d’autre part, il faut réussir
à cerner l’apport de ces technologies à l’entreprise, que ce soit pour l’utilisateur, collaborateur
de l’entreprise, ou le client. Pour cela, un recueil des besoins doit être effectué et analysé.
Au cours de mon stage, le périmètre se restreint autour de projet SI à destination
d’utilisateurs qui sont des collaborateurs internes à l’entreprise, l’aspect recueil des besoins
d’hypothétiques clients ne sera donc pas approfondi dans ce rapport.
On peut constater que dans une très large majorité de projets SI, les besoins sont avant
tout mal exprimés, car les commanditaires de ces projets ont des difficultés à définir ce qui leur
serait utile.
Ainsi, il existe une nécessité d’échange entre l’utilisateur final et le chargé du projet afin
de formaliser et représenter ses besoins et les solutions techniquement possibles pour y
répondre. En tant que consultant, il est primordial de reformuler ce que le commanditaire va
exprimer, et de lui apporter son expérience et son expertise.
Alors, le travail du chef de projet est celui d’un Analyste SI, qui doit :
1. Coopérer, par le dialogue, avec l’ensemble des acteurs TI – Technologies de
l’Information – qui emploient bien souvent un langage très distinct de celui de
l’utilisateur final
2. Analyser et interpréter, par le biais de recherches et en formulant de
nombreuses hypothèses
3. Interagir et présenter, de manière claire, à chaque acteur du projet, les
différents besoins et solutions
4. Organiser l’ensemble du projet, tel un chef d’orchestre, afin de s’assurer que
chacun remplit son rôle
5. Obtenir un résultat
Pour effectuer le recueil des besoins, le chef de projet passe par différentes étapes :
La découverte, où il faut comprendre, rechercher, recueillir, faire émerger les
attentes de l’utilisateur final
L’analyse, au cours de laquelle on liste les besoins
Le tri, où ceux-ci sont priorisés
La vérification de la pertinence, la cohérence et la complétude des besoins
exprimés
La spécification technique, qui consiste à exprimer les besoins aux
développeurs, en adaptant son langage
Les besoins ne sont pas donnés, ils se construisent.
Une fois les besoins exprimés, recueillis, rédigés et validés par le chef de projet, la
hiérarchie et les utilisateurs, la phase plus concrète du projet peut commencer, avec, dans le cas
du projet informatique, ce qui nous intéresse ici, le début de la phase de développement.
C’est ici que nous pouvons constater les premières différences majeures entre un projet
agile et un projet en cycle en V.
Lors du développement en cycle en V – système plus traditionnel – l’objectif est de
répondre strictement aux besoins et spécifications énoncées au début du projet. Cela rend le
projet plus facile à estimer en coût et en temps, mais permet aussi de s’assurer qu’il gardera
bien sa fonction initiale.
Au contraire, la gestion de projet agile permet, comme son nom l’indique, plus d’agilité
sur le projet. L’objectif est de faire des réunions régulières entre les équipes de développement,
le chef de projet et le « product owner », qui est bien souvent le client qui a commandé
l’application ou le site web, mais peut aussi être un interne de l’entreprise pour le
développement d’outils internes.
L’objectif est alors d’optimiser le temps de développement en revoyant à chaque
réunion le planning pour les différentes tâches. De plus, cela permet de garder une bonne vision
du projet, en analysant à chaque fois les fonctionnalités que l’on développe pour les inscrire
dans le projet global, ce qui conduit parfois à l’annulation du développement de certaines
fonctionnalités ou à des ajouts. Attention néanmoins, ce qu’on appelle souvent en France
« démarche agile » correspond souvent au simple découpage d’un projet dont chaque partie
sera alors gérée en cycle en V.
Cependant, quelle que soit la démarche adoptée, chaque projet a besoin d’un ou
plusieurs pilotes. Le pilote du projet – qui dans la méthode SCRUM de la démarche agile,
s’assimile au SCRUM Master – est celui qui est chargé de garder une vision sur l’ensemble des
paramètres du projet : les ressources humaines, le coût, la gestion des délais, les tâches à
effectuer…
Son rôle, c’est aussi de savoir transmettre cette vision à l’ensemble des protagonistes,
afin que chacun puisse s’adapter en permanence, et au final, optimiser le déroulement du
projet.
Une fois le projet développé, deux phases sont encore nécessaires avant de clôturer le
projet. La première est la recette du projet. Il s’agit de s’assurer que le produit obtenu est bien
conforme aux spécifications énoncées initialement. On s’assure alors que l’ensemble des
fonctionnalités désirées est bien présent et que ces dernières fonctionnent correctement, grâce
à des batteries de tests préétablis.
Cette recette se déroule en général en deux temps : un premier temps en interne, chez
le fournisseur, qui permet d’éliminer les bugs importants, de vérifier que le contrat est bien
rempli et de s’assurer que l’outil a une cohérence global. Le second temps se déroule chez le
client ou le demandeur, afin de tester la comptabilité de l’outil avec son système d’information,
et qu’il confirme que les fonctionnalités sont bien celles qu’il attendait. C’est aussi lors de ce
second temps qu’on s’assurera définitivement des bonnes performances de l’outil.
Enfin, dernière étape du projet, la mise en place d’un support, qui répondra aux
différentes sollicitations des utilisateurs ou du client, au minimum pour ce qui concerne les bugs
et anomalies, et au mieux pour se charger de la formation des utilisateurs et des demandes
d’évolution de l’outil développé.
En tant que Consultant Stagiaire chez Beijaflore, j’ai effectué la majeure partie de mon
stage en pilotage de projet pour un client : Bouygues Immobilier.
Bouygues Immobilier est un promoteur immobilier du groupe Bouygues, côté au CAC
40. Autrement dénommé « développeur-opérateur urbain », la société réalise depuis près de 60
ans, des projets de logements, d’immeubles de bureaux, de commerces et d’aménagement de
quartier durables, de la prospection des terrains à construire jusqu’à la remise des clés au
propriétaire, en passant par toutes les étapes traditionnelles de la promotion immobilière –
achat des terrains, parcours client, relations avec les entreprises de construction, gestion de la
légalité…
Bouygues Immobilier est par ailleurs un excellent représentant de la transformation
digitale d’une entreprise, dans un domaine – la promotion immobilière – qui n’a pourtant
initialement rien à voir avec le digital et le numérique.
En effet, tant par l’évolution de ses outils internes que par ses propositions
commerciales auprès de sa clientèle – avec un objectif de 70% de logements construits classés
comme « logements connectés », réel nouveau besoin chez les acheteurs – l’entreprise a su, non
seulement profiter de cette transformation digitale, mais également accompagner ces
bouleversements dans notre environnement et notre manière de vivre.
Depuis l’année 2016, Bouygues Immobilier déploie Opéra, une application métier qui
recouvre 90% des métiers de l’entreprise, utilisée pour gérer, à terme, l’ensemble des projets
et opérations immobiliers de l’entreprise, ainsi que la commercialisation, et qui sert d’interface
avec les autres outils du SI Bouygues Immobilier, ce pour plus d’un millier de collaborateurs.
Je suis donc intervenu au sein d'un bureau d'étude de la DSI Bouygues Immobilier : le
bureau Gestion des opérations, projet OPERA, en tant que pilote de projet.
Le projet a débuté il y a plus de 8 ans, avant le premier déploiement en 2016. Le
déploiement de l’application se fait région par région. A mon arrivée, l’application était déjà
déployée sur un peu plus de la moitié des régions, correspondant à 900 utilisateurs. Les
déploiements se sont ensuite succédés jusqu’à ce que toute la France et les filiales de Bouygues
Immobilier y aient accès, pour un total de 1700 utilisateurs.
L’application a été développée grâce à la mise en commun des expertises de trois
équipes :
Deux équipes Bouygues Immobilier, une orientée métier, qui a la connaissance
des besoins du terrain et qui a permis de définir les spécifications, et l’autre,
orientée fonctionnel, qui a permis de définir l’architecture de l’application en
prenant en compte la structure de l’époque du SI de l’entreprise.
Une équipe de développeur externe à l’entreprise chargée de rédiger les lignes
de codes nécessaires au fonctionnement de l’application à partir du cahier des
charges et des spécifications techniques demandées par les deux autres
équipes.
A la suite du premier déploiement, l’ensemble de l’équipe Opéra est devenue une
équipe de support, et s’est réorganisée, tout en conservant les trois équipes originales, pour
s’organiser dans le format qu’elle a encore aujourd’hui. C’est à partir de ce moment que l’outil
de gestion d’incidents EasyVista a été utilisé, et que les équipes ont commencé à réceptionner
les tickets – que l’on appelle parfois incidents par abus de langage – créés, soit directement sur
l’outil EasyVista par les utilisateurs, soit suite à la réception d’un appel téléphonique d’un
utilisateur par le premier niveau de support.
En effet, en accord avec la méthode de management de Systèmes d’Information ITIL –
Information Technology Infrastructure Library, une méthode regroupant les meilleures pratiques
pour organiser et améliorer ses SI, réduire les risques et augmenter la qualité de ses services,
mise en place par une association d’experts issu de grandes entreprises de services – le support
Opéra est construit en trois niveaux de support, chacun plus spécialisé que le précédent.
Le premier groupe, nommé Support Métier a été créé afin de réceptionner les appels
des utilisateurs confrontés à un problème sur l’application et de procéder à une première analyse
de ces problème. C’est ce qu’on appelle le support de Niveau 1, chargé de résoudre les incidents
de complexité faible, de « qualifier » – comprendre « classer » – les tickets et, le cas échéant, de
transférer les dossiers plus complexes aux groupes de support de Niveau 2.
Le groupe Fonctionnel, qui est l’extension de l’équipe fonctionnelle qui a
participé au développement de l’application, et qui va être chargé de résoudre
les anomalies liées à des erreurs informatiques en association avec l’équipe de
développement externe, grâce, entre autres, à l’utilisation des outils de gestion
de fiches d’anomalies ALM et JIRA. Lorsqu’une anomalie rencontrée par un
utilisateur sur Opéra est liée à une liaison avec une autre application, le groupe
Fonctionnel va également pouvoir transférer le ticket à un groupe de troisième
niveau, généralement le bureau d’étude de Bouygues Immobilier chargé de
l’application concernée.
Le groupe Données, chargé de la reprise de données, qui va s’assurer qu’aucune
information n’est perdue, et le cas échéant, qui va corriger les données erronées
lors de chaque migration et chaque déploiement de l’application.
Le groupe Métier Niveau 2 – appelé simplement « Niveau 2 » par les autres
équipes du projet – issu d’une partie de l’équipe métier chargée du
développement de l’application, qui assiste les utilisateurs sur l’utilisation
d’Opéra lorsque ceux-ci rencontrent d’importantes difficultés, et qui permet au
Support Métier de monter en compétence sur les cas les plus récurrents de
difficultés d’utilisation grâce à la création de notes techniques d’utilisation de
l’application. Lorsque ces cas deviennent trop spécifiques dans le métier pour
être parfaitement saisis par les collaborateurs du Niveau 2, ceux-ci vont
transférer les tickets au groupe de troisième niveau.
Parmi les groupes de troisième niveau, un seul fait réellement partie du groupe Opéra :
le groupe Opéra Métier Niveau 3 – appelé couramment « Opéra Métier » – issu lui aussi de
l’équipe métier chargée du développement de l’application, qui va s’occuper des cas d’usages
très spécifiques rencontrés par les utilisateurs, des demandes d’évolution – comme des
demandes d’ajout de fonctionnalités par exemple – et qui va se déplacer en région, auprès des
équipes sur le terrain, pour former les nouveaux utilisateurs.
Sous la méthode ITIL, on considère également que l’équipe de développement externe,
qui répond aux sollicitations du groupe Fonctionnel, et les autres bureaux d’étude chargés de
résoudre les anomalies rencontrées sur Opéra liées aux autres applications avec lesquelles il y a
des passerelles, font partie du troisième niveau de support d’Opéra, mais ces équipes ne font
pas à proprement parler de « l’équipe Opéra ».
L’ensemble du support du projet Opéra représente un effectif de plus de 30
collaborateurs.
Résumé visuel de la répartition par niveau des équipes support Opéra
Opéra est donc un projet d’application qui permet de gérer l’activité principale de
Bouygues Immobilier : la gestion d’opérations immobilières et leur commercialisation. Afin de
concevoir un peu mieux l’utilité de cette application, j’illustre, en simplifiant, le parcours d’un
projet immobilier sur la page suivante.
EasyVista est une solution web SaaS – Software as a Service, ou Logiciel en tant que
Service en français – d’ITSM – Information Technology Service Management – adaptable dont
la raison d’être est la gestion d’incidents. Cet outil permet aux utilisateurs de créer et renseigner
des tickets afin de signaler les incidents qu’ils rencontrent sur les applications du SI, puis de
suivre l’avancement de leur analyse par les équipes de support.
Du côté des équipes de support, il s’agit d’avoir une visibilité ciblée sur les incidents
rentrant dans leur domaine de compétence, groupe par groupe voire individu par individu. Pour
cela, EasyVista dispose d’un système de groupes, qui permet à tous les membres d’un groupe
d’être notifiés lorsqu’un incident leur est attribué.
Ce système de notification permet également aux utilisateurs d’être notifiés lors de la
résolution d’un incident ou si un complément d’information de sa part est nécessaire pour
correctement traiter l’incident.
Chez Bouygues Immobilier, EasyVista est utilisé pour l’ensemble des applications à
maintenir, mais nous nous y intéressons ici principalement pour son intérêt au sein du projet
que j’accompagne : Opéra.
Au cours de ma mission, cet outil me sert sous trois facettes différentes :
En premier lieu, il me permet de consulter rapidement certains incidents, soit ceux qui
ont un comportement non conforme, soit ceux attribués à l’équipe de support niveau 1 que je
pilote afin d’avoir un regard pertinent sur l’orientation de leur activité.
Liste des incidents à traiter par l’équipe support niveau 1
Ensuite, il me permet, grâce à des fonctions d’extraction, de récupérer toutes les
informations qui me sont nécessaires pour produire les nombreux indicateurs sur le projet dans
son ensemble.
Enfin, je suis chargé d’une partie de la modération de cet outil, pour, par exemple
ajouter ou retirer des membres de groupes, ou bien recueillir les besoins des collaborateurs du
support pour formuler et faire remonter les demandes d’évolutions de l’outil auprès de son
administrateur.
Couramment appelé ALM, c’est un outil d’assistance au développement et à la
maintenance d’applications, que ce soit pour les activités de gestion de projet ou pour les
activités d'ingénierie logicielle.
En l’occurrence, ALM était l’outil qui, à mon arrivée, permettait à l’équipe fonctionnelle
de créer des fiches contenant les informations nécessaires pour corriger les anomalies
rencontrées par les utilisateurs sur l’outil OPERA. En plus de la description du problème
rencontré et des différentes actions tentées ou effectuées pour le corriger, chacune de ces fiches
contient de très nombreux détails – priorité, domaine, statut (nouvelle, testée, mise en
production…), version dans laquelle l’anomalie a été détectée, etc… – et l’outil permet d’extraire
l’ensemble de ces données, fonction très utile pour la production d’indicateurs.
Bien qu’en faisant évoluer EasyVista, il serait possible d’obtenir les mêmes
fonctionnalités et informations en évitant de la redondanc, l’utilité majeure de l’outil est de
permettre une communication entre les équipes de support de Bouygues Immobilier et l’équipe
de développement et de maintenance de l’outil, externe à l’entreprise, sans surcharger cette
dernière d’incidents qui ne la concerne pas.
Au cours de mon stage, cet outil de gestion des anomalies a été abandonné au profit
d’un autre, et j’ai dû m’assurer de la bonne transition entre les deux outils, en faisant, entre
autres, du mapping de données et des notices de conseil d’utilisation aux collaborateurs.
JIRA est un système de gestion d’incidents et de gestion de projets. C’est en particulier
pour son affinité avec la méthode agile que la transition d’ALM vers JIRA a été effectuée au sein
de Bouygues Immobilier sur le projet OPERA.
JIRA permet l’affichage des fiches d’anomalie sous Tableau Kanban
De plus, l’équipe de développement et maintenance de l’outil utilisait déjà cet outil, ce
qui a permis une fluidification des communications et des corrections entre les équipes.
Sa fonctionnalité est globalement la même qu’ALM : gérer la correction des anomalies
rencontrées sur l’outil OPERA.
Au-delà du pilotage de la transition entre les deux outils, mon utilisation de JIRA ne passe
pas par la création de fiche et la correction des anomalies. J’ai en effet un emploi passif de l’outil,
qui me sert pour extraire des données afin de produire des indicateurs toujours plus précis et
pertinents, ainsi que pour surveiller et suivre les différentes fiches, pour pouvoir m’assurer que chaque collaborateur a la visibilité sur les tâches qu’il a à effectuer, ou bien pour gérer les
priorités et urgences selon le besoin du moment.
Ce célèbre logiciel tableur développé et distribué par Microsoft dans sa suite
bureautique Microsoft Office permet de manipuler de nombreuses feuilles de calcul. Au cours
de mon stage, il me permet de stocker et trier de nombreuses données, d’effectuer des calculs,
de synthétiser les dites données sous formes de tableaux croisés dynamiques et de produire de
nombreux graphiques.
Grâce à son système de gestion des macro-commandes – ou macros – le logiciel permet
un gain de temps considérable sur le traitement de nombreuses données. En effet, lorsque j’ai
dû manipuler quotidiennement un tableau de plus de 10 000 lignes et 80 colonnes, dont plus de la moitié effectue des calculs, qui n’est qu’une partie d’un fichier Excel de plus de 20 Mo – même
après l’avoir optimisé –il m’a rapidement paru pertinent d’automatiser le tout via les macros et
le langage Visual Basic for Applications – VBA.
Sur le projet Opéra, le nombre de logs quotidiens produits par l’application est de
plusieurs millions.
Kibana permet donc, d’une part de consulter ces logs individuellement, via des fonctions
de recherche ou de tri, et d’autre part de créer, à partir de ces logs, de nombreux graphiques,
par répartition en fonction des différentes informations listées ci-dessus, ce qui permet de
former des tableaux de bord – ou dashboard – qui donnent une visibilité simple pour les
différents spécialistes techniques acteurs du projet.
Mon poste dans l’équipe Opéra est celui de « Pilote de projet ». L’objectif du pilotage
d’un projet est d’avoir une visibilité sur ce qui est réalisé, faire des prévisions et comparer ce
prévisionnel au réalisé. Son rôle passe également par la communication. En effet, chaque
responsable des différentes équipes n’a pas forcément la visibilité ou le temps nécessaire pour
mesurer l’impact de l’ensemble des décisions qu’il a à prendre, et c’est le rôle du pilote
d’assurer un suivi fiable du projet pour donner une vue d’ensemble de ce dernier, mesurer son
avancement, et ce via la production et diffusion d’indicateurs, aussi appelés KPI - Key
Performance Indicator, ou indicateurs clés de performance en français.
Sur le projet Opéra en particulier, ces indicateurs sont très nombreux. Grâce aux
différents outils utilisés – EasyVista, ALM, JIRA – de nombreuses extractions de données sont
possibles, et avec Excel, le calcul de valeurs et la production de graphiques est facilitée.
En particulier, j’ai créé sur un fichier Excel un tableau de données massif duquel je retire,
via des Tableaux Croisés Dynamiques – tableaux se servant de tableaux à deux dimensions pour
créer des tableaux à trois dimensions via de multiples conditions mises à dispositions de
l’utilisateur – des filtres et des tris, une très large majorité des indicateurs que je communique
ensuite aux différentes équipes ou à la hiérarchie, qui prête bien entendu une forte attention à
ce projet qui impacte l’ensemble des activités de Bouygues Immobilier.
Ce tableau est séparé en plusieurs grandes parties distinctes, qui se différencient sur les
captures d’écran ci-dessous par différentes couleurs, afin que les collaborateurs qui souhaitent
consulter les données brutes puissent se repérer plus facilement.
Son type, son domaine et son chiffrage, qui définissent différentes
classifications permettant de situer ce qui va être impacté sur l’application
Deuxième partie du tableau de données
Puis, on retrouve en orange toutes les colonnes purement calculées, sur lesquelles, en
général, on va appliquer les filtres qui nous intéressent, et qui vont permettre de produire
d’autres tableaux et des graphiques toujours plus parlants et pertinents pour les différentes
équipes.
Enfin, en jaune et en vert, on retrouve une partie un peu particulière. En effet, j’ai pu
observer que, à cause de la structure du SI de Bouygues Immobilier, certaines informations
extraites d’EasyVista pouvaient être erronées, comme la localisation de certains utilisateurs, ou
le groupe et l’intervenant qui s’occupent du ticket au moment M.
Après avoir remonté ces dysfonctionnements aux personnes responsables de cette
partie du SI, j’ai donc dû, en attendant leur correction, créer de nouvelles colonnes qui, par des
comparaisons ou des liaisons avec des tableaux d’association, que j’ai pu créer avec mes
connaissances du fonctionnement général de l’entreprise, vont donner la bonne information sur
les données en question.
Avec ce tableau donc, je peux extraire de nombreuses données et informations, que je
convertis souvent en graphiques – mais pas seulement – afin d’organiser des communications
régulières sur certains sujets, par mail ou lors de réunion, ou encore d’illustrer l’avancement et
l’état du projet lors des différents comités de direction – Comex – ou de pilotage – Copil – avec
des présentations Powerpoint.
Au-delà du pilotage global du projet, je suis en particulier chargé du pilotage du Support
Métier. Cette cellule, en m’excluant, est composée de 5 personnes, et est le point d’entrée et
de sortie des demandes des utilisateurs concernant l’outil Opéra que ce soit au téléphone ou en
passant par EasyVista.
Piloter cette équipe, c’est m’assurer qu’ils ont bien en main tous les éléments
nécessaires pour faire face aux demandes utilisateurs. Par exemple, à chaque mise en
production d’une nouvelle version de l’application, à chaque mise à jour, je dois m’assurer que
chacun soit au courant afin qu’il puisse répondre rapidement aux sollicitations des utilisateurs
n’ayant pas lu la communication prévenant de l’indisponibilité temporaire de l’application.
C’est aussi surveiller le « backlog », c’est-à-dire le stock d’incidents qui sont en cours de
traitement par le Support Métier. En effet, ce backlog se doit d’être la plus bas possible : soit le
problème rencontré est à la portée de l’équipe et une solution peut être apportée à l’utilisateur
rapidement (à la condition que ce dernier soit disponible), soit le problème est trop complexe
et il doit être transféré le plus rapidement possible à l’équipe support de deuxième niveau
compétente.
Bien entendu, un dysfonctionnement majeur, ou les congés et absences des
collaborateurs, réduisant ainsi la capacité de traitement de l’équipe, sont des exemples
d’éléments à prendre en compte lorsqu’on observe le nombre d’incidents présents dans ce
backlog, il faut donc avoir tous les éléments en main et toujours essayer de comprendre
pourquoi l’objectif fixé n’est pas atteint lorsque le stock est trop important.
Lorsque cela arrive, il faut alors réfléchir à une solution. Connaissant les différents profils
de l’équipe, j’ai pu demander au collaborateur le plus expérimenté sur l’application de cesser de
répondre aux appels téléphoniques pour se concentrer uniquement sur les incidents en stock,
afin de le vider. Cette décision fut d’ailleurs efficace, permettant de réduire en deux jours le
backlog de 80%.
J’ai donc un regard tout particulier sur le Support Métier, qui me permet de prioriser
leur activité, toujours en passant par des indicateurs que je crée.
Et cette priorisation passe par une compréhension et une étude toujours plus
approfondie des différents incidents. Par exemple, sur le graphique ci-dessus, on peut compter
13 incidents dans la backlog du Support Métier, dont 6 sont ont plus de deux semaines
d’ancienneté, ce qui n’est pas censé être acceptable pour un support de premier niveau.
Cependant, en approfondissant l’analyse, on se rend compte que 5 d’entre eux ne sont pas
traitables en l’état, car le collaborateur ayant créé le ticket n’a pas donné assez d’informations,
et a donc été relancé, ou doit être relancé de nouveau.
On observe également que les 4 incidents restant anciens de plus de deux semaines sont
« redirigés », ce qui signifie qu’ils ont déjà subi un cycle d’analyse par d’autres groupes de
support : cela ne fait donc pas plus de deux semaines qu’ils sont dans le backlog. On comprend
alors qu’il n’y a que 4 incidents qui n’ont pas encore été traités par le Support Métier, qu’ils
datent de la veille, probablement de la fin de journée, et que c’est un chiffre tout à fait
acceptable.
Toujours dans l’objectif de fluidifier leur activité, et aussi pour préparer l’arrivée
éventuelle de nouveaux arrivants au Support Métier, nous avons, avec un autre pilote du projet
et le collaborateur le plus expérimenté du Niveau 1, entamé la création de notices, qui, à terme,
vont permettre aux collaborateurs en manque d’expérience de savoir, en un coup d’œil sur la
notice, ce qu’il faut faire face à tel ou tel type de ticket, principalement selon la catégorisation
de ce dernier.
Bien que cette tâche prenne plusieurs heures par semaine et prive le Support Métier
d’une part conséquente de sa puissance de travail, ce projet permettra, à long terme, un gain
de temps et une efficacité toujours meilleurs.
Enfin, piloter une équipe, c’est aussi savoir gérer l’humain, comprendre les capacités de
chacun, leur compréhension du projet, leur implication, leur cadre de vie, et c’est aussi savoir
éventuellement gérer les tensions qui peuvent apparaitre entre collaborateurs et rester à leur
écoute.
Au sein du pilotage du projet Opéra, j’ai également la mission d’analyser les logs
produits par l’application, notamment grâce à l’outil Kibana.
Mon rôle avec cet outil est de surveiller les logs d’exceptions : des logs qui apparaissent
en cas d’erreur ou de comportement inhabituel d’une fonction, logs que Kibana permet d’isoler
simplement. En moyenne sur les premiers mois de mon stage, le nombre de logs d’exception
allait de 600 à 2000 par jour (contre plusieurs millions de logs standards). Ce nombre peut
considérablement augmenter lorsqu’une anomalie importante apparait intempestivement.
L’objectif de cette surveillance est double. L’observation d’un grand nombre d’erreurs
sur un même domaine va me conduire à analyser au cas par cas les logs d’erreur de ce domaine
afin de définir quelles fonctionnalités sont impactées pour les utilisateurs, et quelles sont les
fonctions qui provoquent ces exceptions. Cela permet de créer le plus rapidement possible une
communication à envoyer aux utilisateurs afin de les prévenir du dysfonctionnement, évitant
ainsi une surcharge de création de tickets peu utiles au support métier, le problème ayant été
identifié. Dans le même temps, je communique auprès de l’équipe fonctionnelle pour que
l’erreur en question soit approfondie et corrigée.
En parallèle de la surveillance des exceptions par domaine ou par type, il existe un réel
enjeu à surveiller ces exceptions par utilisateur. En effet, sur ces projets de grande ampleur qui
changent de nombreux process d’entreprise établis depuis de nombreuses années, un des
points majeurs est la satisfaction utilisateur. Il s’agit alors d’identifier les actions tentées et
échouées par les utilisateurs afin de les contacter et de rendre le support proactif, ce qui conduit
à une identification plus rapide de l’anomalie rencontrée ou à un meilleur accompagnement de
l’utilisateur sur un usage de l’application.
Le pilotage global du projet Opéra commence, comme pour tout pilotage de projet, par
une comparaison entre le prévisionnel et le réalisé. Sur ce projet, les chiffres qui vont nous
intéresser sont le nombre de tickets créés par les utilisateurs.
En effet, piloter un projet c’est aussi faire un suivi des ressources, et en l’occurrence,
des ressources humaines qui traitent les incidents rencontrés. Au-delà de ce qu’on a pu voir
précédemment, il est dans mes attributions de m’intéresser aux incidents de plus de deux mois
d’ancienneté. Je dois alors analyser chacun de ces incidents, déterminer la raison de son
ancienneté – anomalie très complexe, incident peu critique et/ou urgent, manque de main
d’œuvre… – et relancer les collaborateurs responsables de la gestion de ces incidents le cas
échéant.
Lorsque je suis arrivé sur la mission, l’équipe utilisait l’outil ALM, décrit plus haut. Il avait
été décidé d’opérer une transition de cet outil vers l’outil JIRA, il a été convenu de me confier la
responsabilité de l’accompagnement de cette transition, qui s’est effectuée en trois étapes.
L’objectif était de laisser l’ancien outil en lecture seule, de transférer toutes les fiches de gestion
d’anomalies non encore résolues sur le nouvel outil, et de permettre les nouvelles ouvertures
de fiches sur le nouvel outil.
La première étape fut d’analyser les capacités des deux outils afin de s’assurer que
toutes les données critiques puissent être transférées, et, lorsque qu’il y avait une
incompatibilité, trouver une solution, soit en récupérant un champ de donnes inutilisé dans le
nouvel outil, soit en contactant le distributeur de l’application afin de faire une demande
d’évolution.
La deuxième partie consistait en la préparation de notices d’utilisation à destination
des collaborateurs du projet afin qu’ils puissent correctement utiliser le nouvel outil. Ce travail
consistait principalement en la parallélisation des process des deux outils, qui me permettait
d’expliquer, via des captures d’écran, comment réaliser les tâches qu’ils effectuaient sur ALM,
sur JIRA.
Enfin, la troisième étape fut d’adapter tous les indicateurs aux nouvelles données,
adapter l’utilisation d’EasyVista, et créer de nouvelles formules, macros et tables de
comparaison pour pouvoir gérer deux sources de données en même temps et prioriser l’une –
celle de JIRA, désormais plus à jour – par rapport à l’autre – ALM, en lecture seule.
Être pilote – mais aussi être consultant – c’est aussi savoir s’exprimer, savoir synthétiser
des informations puis les présenter pour que ses interlocuteurs puissent comprendre les
tenants et les aboutissants, même s’ils ne sont pas des spécialistes du sujet abordé.
Et j’ai dû, au cours de ce stage, réaliser cet exercice à de nombreuses reprises,
notamment en animant des réunions de pilotage, en général hebdomadaires, réunissant tous
les pilotes du projet Opéra ainsi que le directeur des SI afin de donner à la fois une vision globale
de l’avancée du projet, faire un rappel sur les jalons proches ou que nous venions de passer, et
se pencher sur les sujets importants du moment, pour comprendre pourquoi nous avions affaire
à une difficulté ou, au contraire, pourquoi nous n’avions pas affaire à une difficulté alors que
nous en attendions une, et, le cas échéant, réagir en conséquence.
Au-delà des intérêts économiques sur la gestion des ressources humaines, faire appel à
des consultants a un autre avantage majeur : apporter une vision neuve sur un projet ou une
situation. Or, un individu avec un regard nouveau saura voir la complexité de certains process
et proposer une manière plus efficace de faire les choses.
Par exemple, à mon arrivée sur le projet, tous les incidents ouverts devaient repasser
par le Support Métier pour être clôturés. J’ai donc soulevé le sujet, ne comprenant pas la raison
de ce process. Comme personne n’a soulevé d’élément bloquant à la simplification du process,
celui-ci a pu être modifié, après une présentation générale à l’ensemble de l’équipe.
Ce stage de fin de troisième année à l’ENSIIE fut pour moi l’occasion de découvrir le
monde du conseil et consiste en ma première expérience réelle du pilotage de projet. En effet
de nombreux enseignements de l’ENSIIE, surtout dans le parcours Organisation des Entreprises
que j’ai eu l’occasion de suivre, apprennent la théorie de la gestion de projet, mais rien ne vaut
l’immersion sur un cas concret, avec de réelles répercussions sur le mode de fonctionnement
d’une entreprise.
Le projet OPERA est un projet de très grande ampleur que j’accompagne du mieux que
je puisse afin de permettre à l’ensemble des collaborateurs de l’entreprise d’être toujours plus
efficaces et épanouis dans leur travail. L’équipe a parfaitement su m’intégrer et me faire monter
en compétences sur tous les domaines nécessaires, que ce soit le pilotage de projet en lui-même
ou l’immobilier en général.
L’équipe Beijaflore m’a également permis de progresser, grâce à l’apport de leur
expérience et en m’aidant à surmonter les difficultés que j’ai pu rencontrer, tout en me laissant
organiser quelques évènements de cohésion.
Cette bonne relation que j’ai pu créer avec les différentes équipes et la qualité de mon
travail semblent avoir convaincu tout le monde, ce qui m’a permis de signer en CDI chez
Beijaflore et de voir ma mission prolongée jusqu’à la fin du projet Opéra chez Bouygues
Immobilier.