La transition des projets digitaux expliquée simplement : de la gestion de projet au support

    Découvrez les similitudes et les divergences qui existent entre la gestion de projet informatique et la gestion des services de support et profitez de conseils de première main pour réussir le passage de relais entre les équipes de développement et de support.

    Abonnez-vous à notre blog

    Le cycle de vie d'un projet digital ne s'arrête pas au lancement de la plateforme - qu'il s'agisse d'un système de gestion de contenu, d'un site Internet, d'un portail Intranet ou de tout autre système d'entreprise. Une fois la plateforme mise en service, la continuité du projet est le plus souvent assurée par une équipe de support. Cela signifie que le projet quitte sa phase de développement pour entrer dans sa phase d'exécution et qu'à partir de maintenant la priorité est de surveiller et de maintenir sa disponibilité et ses performances. Cela veut dire également que le projet passe des mains du chef de projet à celles d'un gestionnaire de services.

    Chef de projet vs gestionnaire de services

    Bien que la gestion de projet et la gestion de services puissent sembler proches, elles constituent deux fonctions distinctes dans l'organisation. Le chef de projet s'occupe de réaliser et mettre en œuvre un produit dans un délai donné. Passée la mise en œuvre, le gestionnaire de services prend le relais pour fournir au client les services informatiques convenus. Le gestionnaire de services veille à la bonne exécution des services de support et notamment à ce que les nouveaux incidents soient traités correctement, affectés aux bonnes personnes et résolus à temps conformément aux accords de niveau de service et indicateurs-clés de performance stipulés dans le contrat de support. L'estimation et la planification des demandes de modification, mises à jour logicielles et nouvelles versions entrent aussi dans le champ de la gestion de services.

    La gestion de projet est une activité ponctuelle, tandis que la gestion de services est un processus. Néanmoins, même si les deux fonctions diffèrent, elles ont un objectif commun, qui consiste à gérer une équipe afin de donner satisfaction au client. Dès l'entrée en vigueur du contrat, l'équipe de support doit être prête et efficace. Sans un minimum de préparation, les choses peuvent vite devenir stressantes.

    Du point de vue du client, la transition entre l'équipe de projet et l'équipe de support peut être déroutante. De nouveaux termes et concepts apparaissent : accord de niveau de service (SLA), indicateur-clé de performance (KPI), incident, problème, demande de modification, calendrier de sortie ou mise à jour, disponibilité de service, rapport de performance, etc.

    Une bonne transition

    La transition n'est pas une date ni une réunion d'une heure sur un planning, il s'agit d'un processus qui peut prendre du temps et doit être planifié en conséquence. Idéalement, l'équipe de support doit entrer en action avant la mise en service. De la même manière, l'équipe de projet doit rester disponible lors des premiers jours voire lors des premières semaines de la phase d'exécution afin de pouvoir prêter main-forte si besoin.

    Une bonne transition

    Sachant que le chef de projet peut être déjà tourné vers sa prochaine mission, le gestionnaire de services doit être prêt à s'immerger et à s'impliquer totalement dans la nouvelle application dès son entrée en service. Des complications peuvent survenir si la transition n'est pas gérée correctement.

    Que peuvent faire les équipes de projet et de support pour assurer une transition sans heurts ? Voici quelques conseils pour réussir le passage de relais.

    1. Tenir la documentation à jour

    Durant la phase de développement, l'équipe de projet doit soigneusement tenir à jour la documentation (architecture logicielle, documentation fonctionnelle et technique, procédures de sauvegarde et restauration, instructions de déploiement, etc.) afin que plus tard l'équipe de support puisse résoudre les problèmes plus rapidement.

    Dans certains cas, un problème présenté comme un bug peut en fait être considéré comme un comportement normal par une autre partie. Par ailleurs, une documentation à jour peut servir d'arbitre en cas de contentieux entre les parties.

    2. Assurer un transfert de savoir efficace

    Lorsque les premiers problèmes sont remontés à l'équipe de support, et afin que celle-ci puisse les traiter au mieux, il est important qu'elle comprenne rapidement la portée du problème et l'endroit où il intervient dans l'application.

    À cette fin, il est utile d'organiser des réunions entre l'équipe de projet et l'équipe de support pour passer en revue l'analyse fonctionnelle et technique, le code, etc. Impliquer les consultants de support lors du développement, par exemple lors du sprint final, est une excellente façon de leur permettre de bien appréhender l'application et d'accélérer la prise en main de leurs fonctions.

    L'équipe de support peut également être présentée aux parties concernées côté client avant la mise en service de l'application dans le but de prendre un bon départ et s'adapter plus rapidement aux différents intérêts et différentes priorités, préoccupations et façons de travailler chez le client.

    Après la mise en service, l'équipe de projet doit rester disponible pour assister l'équipe de support si des éclaircissements sont nécessaires.

    3. Configurer l'outil de surveillance à l'avance

    En mode support, l'application est surveillée en continu. Des données sur la disponibilité et les performances de l'application sont collectées chaque jour pour produire les futurs rapports de service. Des alertes doivent être configurées et envoyées en cas d'interruption de service. La plupart du temps, la configuration de l'outil de surveillance est réalisée par l'équipe de projet dans l'environnement de production et le gestionnaire de services se contente de vérifier que tout est en règle lors du passage de relais. Si la configuration n'a pas été effectuée par l'équipe de projet à ce moment-là, l'équipe de support s'en occupe et se charge de contrôler l'outil de surveillance et de l'adapter si nécessaire.

    4. Programmer/planifier/communiquer un calendrier de sortie

    En mode support, périodiquement de nouvelles versions de l'application sont déployées ou un module ou framework mis à jour. Une fois la date connue, l'équipe de support communique un calendrier de sortie aux parties concernées côté client. Chez AMPLEXOR, ce document liste les dates de sortie prévues des versions et parfois également les dates des réunions de service ou des livraisons de rapports de service.

    5. Organiser une formation à temps

    Il arrive quelquefois que l'équipe de projet emploie des technologies que l'équipe de support ne connaît pas encore, auquel cas une formation doit être organisée à temps. Chez AMPLEXOR, nous recourons sans cesse à de nouvelles technologies innovantes dans nos projets et nous veillons à ce que notre équipe de support soit toujours à la page au moyen d'un coaching régulier, de camps d'entraînement ou de formations présentielles.

    6. Ne pas chercher à réinventer la roue

    Une application peut être développée de différentes façons, à l'aide de différentes techniques ou frameworks pour un même résultat. Le fait d'avoir des règles qui énoncent les techniques qui marchent et les bonnes pratiques à suivre par les développeurs comme par l'équipe de support permet d'assurer un mode opératoire commun et facilite le travail de support.

    Conclusion

    Chez AMPLEXOR, nous mettons tout en œuvre pour assurer une bonne transition entre nos équipes de projet et de support. Bien entendu, notre liste de conseils n'est pas exhaustive et nous prenons bien d'autres mesures pour que cette transition se déroule sans heurts pour nos clients. Dans tous les cas, la clé reste une bonne communication et souvent un simple coup de fil ou une discussion cordiale fera beaucoup pour résoudre des situations qui, au premier abord, semblaient compliquées.

    Publié sur    Dernière mise à jour le 18/06/2019

    #Stratégie Digitale

    À propos de l'auteur

    Cristophe Pepe is Service Manager at Amplexor, based in Belgium. With over 15 years of experience in Java development, J2EE architecture and Alfresco ECM and BPM projects, Cristophe joined the team in 2011 as ECM consultant. Over the years, he got to expand his expertise to WCM and Drupal, and since April 2017, Cristophe is responsible for managing support services for the Drupal and Alfresco customers at Amplexor Service Center.

    SUBSCRIBE TO OUR BLOG