Skip to content
Extraits de code Groupes Projets
Sélectionner une révision Git
  • 0fd6181d67f5043bd6dfd0c06dbf18b878a5f97c
  • master par défaut protégée
  • tichadou2015-master-patch-52256
3 résultats

pipotron.txt

Blame
  • 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.