a. Faire un état des lieux

Vos utilisateurs sont les premiers clients de votre projet de déploiement. Leur implication dans les phases initiales vous assurera deux choses : une vision subjective de ce qu’ils ressentent dans l’utilisation quotidienne de leur outil de travail (dysfonctionnements, adéquation des outils, lenteur perçue, etc.) et une adhésion au projet grâce au sentiment de considération qu’ils retireront de leur participation (cette adhésion au projet vous sera particulièrement utile lors du déploiement, lorsque vous viendrez bousculer leur environnement informatique).

Organisez avec des représentants des différents services concernés (informatique, support, utilisateurs, achats) une réunion de présentation du projet, de ce qui le motive (opportunité, fin de support d’un matériel ou d’un logiciel important, inadéquation avec l’évolution des métiers) et des objectifs que vous souhaitez atteindre.

Dressez un état des lieux de votre parc actuel : constitution et culture des populations utilisatrices, inventaire des matériels rencontrés, contraintes métier, implantations géographiques, existence de collaborateurs avec un handicap, formats des échanges de fichiers informatiques avec les partenaires ou les clients, engagements contractuels avec les fournisseurs, etc. Cet état des lieux peut également être complété, si cela est possible, d’une synthèse des problèmes rencontrés le plus fréquemment par le support informatique. Si des éléments ressortent comme étant traitables au niveau du poste de travail, identifiez les actions à mener et prenez-les en compte lors de la conception. Par exemple, si un utilitaire provoque régulièrement un plantage, vérifiez auprès de l’éditeur la disponibilité d’une version plus récente corrigeant le problème et prévoyez de l’inclure dans votre nouveau socle.

b. Formuler une expression de besoin

Une fois l’état des lieux réalisé, formaliser une expression de besoin va permettre de collecter les demandes des utilisateurs et de préparer la définition du socle. Les besoins peuvent être répartis en trois catégories : le matériel, les applications et les services.

Les besoins matériels évoluent avec le temps parce que de nouveaux usages sont rendus possibles par l’évolution des technologies. Avec la démocratisation de l’informatique dans les foyers, les besoins en matériel sont souvent exprimés en fonction de ce dont les utilisateurs disposent chez eux : un écran plat plus grand, un ordinateur plus rapide, une souris sans fil, une webcam, etc. Il paraît aujourd’hui dépassé de proposer un écran cathodique parce que les écrans plats sont devenus la norme en usage domestique, les deux permettant pourtant, à diagonale égale, de remplir les mêmes fonctions. L’expression de besoin synthétisera donc, pour chaque population, les besoins matériels exprimés, sans critères techniques, mais avec des critères qualitatifs : poste fixe ou nomade ; ultraléger, léger ou normal ; simple ou double écran ; silencieux ou non ; importante vitesse de calcul requise ; présence de périphériques nécessaires au métier ; etc.

Une attention particulière doit être portée à l’expression de besoin en termes d’applications. Il faut en effet bien distinguer le besoin “réel” (un applicatif métier, un utilitaire de compression de fichiers, un traitement de texte, etc.) du besoin “de confort” (logiciel de synchronisation avec le téléphone personnel, lecteur de vidéos, navigateur web alternatif, barre d’outils du navigateur web, etc.). Il n’est pas rare, sur un parc informatique non maîtrisé, de voir remonter dans les inventaires logiciels bon nombre d’applications personnelles, de jeux et de sharewares en tous genres (quand il ne s’agit pas de logiciels piratés). Attendez-vous à ce que ce type de besoin soit exprimé, les utilisateurs considérant que ces logiciels sont nécessaires parce qu’ils ont l’habitude de les avoir sur leur poste. La définition du socle sera le moment de faire le tri.

Enfin, la partie services permettra de formaliser ce qu’attendent les utilisateurs en termes de support (horaires, suivi des incidents, intervention sur site), de sauvegarde et de restauration (procédure, délai, conservation) ou encore de gestion de la demande (formulation, suivi, historique). Le support dispose-t-il d’un outil permettant de prendre la main à distance sur le poste de l’utilisateur ? Un utilisateur peut-il obtenir la restauration d’un fichier supprimé sur son poste ? Ces questions ne sont que quelques exemples montrant que cette partie ne doit pas être négligée car elle peut avoir un impact très important sur la définition technique de votre futur poste de travail ainsi que sur la qualité du service rendu, et donc sur la satisfaction de vos utilisateurs.

c. Définir un socle

Une fois l’état des lieux réalisé et l’expression de besoin formalisée, reprenez ces éléments en statuant sur chaque demande (acceptée, refusée, étude complémentaire nécessaire) et en arbitrant les besoins matériels. On retrouvera dans la définition du socle la même structure que celle de l’expression de besoin.

Il est probable que vous ayez à définir au moins deux plates-formes matérielles, la première pour les fixes et la seconde pour les nomades. Une troisième peut également s’avérer nécessaire pour les dirigeants ou les itinérants ayant besoin d’une configuration “ultraportable”, basée généralement sur un portable d’un poids inférieur à 1,5 kg et d’une taille réduite (écran inférieur à 14″).

Gardez en tête les objectifs que vous vous êtes fixés : standardisation du poste de travail et des outils, consolidation des fournisseurs, mutualisation de l’expérience du support entre les différents types de matériels. Selon vos rapports avec les fournisseurs et le volume potentiel de commande (en cas de renouvellement du parc), négociez avec eux le prêt de matériel de test que vous qualifierez et testerez avant de faire votre choix. Le matériel retenu devra permettre de répondre aux besoins actuels mais aussi à ceux qui ne manqueront pas d’être exprimés pendant la durée d’amortissement du parc (de 3 à 5 ans selon les entreprises).

Le choix du système d’exploitation est loin d’être anodin. Il aura en effet une influence majeure sur de nombreux points : compatibilité des matériels et des applications héritées, disponibilité des pilotes de périphériques, support de la part des fournisseurs sur cette version, etc. Enfin, selon votre contrat de licence, l’éditeur peut ou non vous autoriser à installer la version précédente (ce qui est appelé « droit de downgrade »). Chaque nouvelle version a néanmoins l’avantage de disposer d’une fin de support plus lointaine, et d’offrir en général de plus en plus de fonctionnalités. Prêtez également une attention particulière aux prérequis matériels et à la configuration recommandée par l’éditeur.

La question des applications à embarquer dans le socle se pose dans les mêmes termes que pour le système d’exploitation : la version prévue est-elle supportée sur cet OS ? Les partenaires de l’entreprise sauront-ils lire les fichiers produits par celle-ci ? D’autre part, n’embarquez dans le socle que les applications communes à tous les utilisateurs et pour lesquelles vous disposez de licences en suffisance. Prévoyez également le déploiement, à la demande, des applications optionnelles spécifiques à chaque métier.

Si une application n’est plus supportée par le nouveau système d’exploitation que vous souhaitez mettre en place, il est probable que l’éditeur vous demande la souscription d’un contrat de maintenance rétroactif depuis la fin de votre dernier contrat pour vous fournir une version compatible.

La définition du socle contiendra également tout le paramétrage du matériel, du système d’exploitation et des applications embarquées. En voici quelques exemples :

a. Packaging des applications

Le packaging des applications consiste à utiliser une technologie standard et automatisable pour les installer, garantissant ainsi la reproductibilité de l’installation sur tous les postes de travail, ou lors des évolutions du socle. Il existe de nombreuses façons d’installer une application, pouvant aller de la simple copie de fichiers pour les plus simples à de véritables programmes très avancés pour les plus complexes. Cependant, la plupart des éditeurs ne développent pas eux-mêmes le “moteur” du logiciel d’installation, mais font appel à des produits spécialisés, Microsoft Windows Installer et Flexera InstallShield étant les deux plus connus. Sauf cas particulier, il est en général possible d’utiliser le programme d’installation tel qu’il est fourni par l’éditeur pour réaliser une installation automatisée grâce à certains paramètres standard.

L’installation automatisée d’une application fournie sous forme d’un fichier Windows Installer (extension .msi) se fait, par exemple, grâce au paramètre /qb (automatique avec barre de progression) ou /qn (automatique sans aucune interface), comme le montre la ligne de commande ci-dessous :

msiexec.exe /i application.msi /qn

Il est également possible de créer un fichier de transformation (extension .mst) qui contiendra les réponses apportées normalement par l’opérateur aux questions posées par l’assistant d’installation. La création d’un tel fichier nécessite un outil de manipulation des packages Windows Installer tel que InstEd, Wise for Windows Installer ou Flexera AdminStudio.

Les programmes d’installation utilisant le moteur InstallShield s’automatisent en deux étapes : tout d’abord par la réalisation d’un fichier de réponse à l’aide des paramètres -r et -f1, comme indiqué ci-dessous :

setup.exe -r -f1c:\mesreponses.iss

puis par sa réutilisation lors des futures installations avec les paramètres -s et -f1 :

setup.exe -s -f1c:\mesreponses.iss

Lorsqu’ils existent, l’utilisation des paramètres d’installation automatique prévus par l’éditeur doit rester la solution privilégiée. Cependant, si les possibilités offertes ne répondent pas à vos besoins, vous pouvez envisager d’extraire du programme d’installation d’origine les fichiers sources, et de recréer un package ex nihilo. Enfin, la méthode du snapshot, qui consiste à faire un différentiel entre l’état d’un poste de travail avant et après installation du logiciel, et à enregistrer le contenu dans un nouveau programme d’installation, doit rester le dernier recours, tant les packages générés peuvent inclure des éléments non souhaités. Malgré le perfectionnement des ateliers de packaging, ces deux dernières solutions présentent de nombreux risques et vous feront perdre dans la plupart des cas le support de l’éditeur en cas de problème. À noter que celui-ci fournit dans certains cas un kit de création de fichiers de réponses, dont l’utilisation est obligatoire pour déployer automatiquement le produit tout en conservant le support, c’est le cas notamment de Microsoft Office ou d’Adobe Reader.

La taille et la complexité de l’application ainsi que le support ou non de l’éditeur en cas de repackaging détermineront la méthodologie à adopter. Si toutefois vous choisissez de créer vous-même ou de faire créer par une société de services un package d’installation, ayez bien en tête que cela nécessite de très bonnes compétences dans de nombreux domaines (ingénierie des systèmes d’exploitation, programmation, scripting, moteurs d’installation) et que les bons packageurs se paient le prix fort.

Si certaines applications s’avéraient incompatibles entre elles ou avec le socle, il peut être intéressant d’envisager leur virtualisation, avec des technologies comme Citrix XenApp, VMware ThinApp ou Microsoft App-V (cf. chapitre Choisir une solution de déploiement – Apport des solutions de virtualisation).

Le site http://www.itninja.com est une source de référence concernant le packaging et l’installation automatisée d’applications.

b. Prototypage

Lors du prototypage vous allez pour la première fois mettre en œuvre les différents éléments sélectionnés lors de la définition du socle : matériel, périphériques, système d’exploitation et applications. C’est également le moment de finaliser la façon dont votre nouveau poste de travail va s’inscrire dans son futur écosystème, le système d’information de l’entreprise : quels outils vont être utilisés pour créer le poste ? Comment celui-ci va-t-il être déployé ? Comment la distribution des applications ou des mises à jour se fera-t-elle ?

Le chapitre Choisir une solution de déploiement vous présentera les avantages et inconvénients des différentes possibilités offertes par les outils Microsoft, et vous aidera ainsi à déterminer la solution la plus appropriée à votre projet. Selon la solution retenue, la phase de prototypage sera plus ou moins longue à mettre en œuvre, mais sera constituée de trois étapes majeures :

Bien que déconseillé pour des questions de support et d’évolutivité, il peut également s’avérer nécessaire de développer des outils spécifiques pour réaliser des tâches particulières à votre organisation, lors du déploiement d’un poste de travail : mise à jour d’un workflow, envoi d’un e-mail de notification, génération et stockage d’un mot de passe administrateur local, etc. Ces outils seront développés et testés lors du prototypage.

Consultez la documentation du Microsoft Deployment Toolkit pour connaître les possibilités d’extension du système de déploiement (écrans et scripts personnalisés, Web Services, etc.).

c. Homologation

Après la réalisation d’un prototype incluant le matériel, le système d’exploitation cible et les applications retenues, deux phases d’homologation seront nécessaires.

La première homologation, dite “technique”, concerne la reconnaissance, la stabilité et le bon fonctionnement du matériel avec les pilotes retenus, ainsi que la compatibilité des applications entre elles et avec le système d’exploitation.

La seconde, dite “fonctionnelle”, se place d’un point de vue services et permet de s’assurer que toutes les fonctions des logiciels sont opérationnelles, que les procédures nécessaires au support se déroulent correctement, que l’environnement utilisateur est celui défini lors de la conception, que les restrictions de sécurité sont appliquées et ne peuvent pas être contournées, etc.

Chaque phase d’homologation doit être préparée à l’aide d’un plan de test et faire l’objet d’un bilan, précisant si celle-ci s’est déroulée conformément au plan de test, et dans le cas contraire, les anomalies relevées. Tandis que l’homologation technique pourra se faire avec la maîtrise d’œuvre, réalisatrice du projet, l’homologation fonctionnelle se fera avec la maîtrise d’ouvrage, décisionnaire sur le projet. En cas d’absence d’une maîtrise d’ouvrage définie, les utilisateurs experts sur chaque application pourront s’y substituer.

a. Pré-pilote

Le pré-pilote concerne une population restreinte à fortes compétences techniques et faisant preuve d’une bonne autonomie face à l’outil informatique. En un mot, des utilisateurs à même d’accepter les dysfonctionnements éventuels, d’y trouver un contournement, et de vous remonter les problèmes avec précision. L’ensemble de l’écosystème autour du déploiement n’est pas nécessairement opérationnel lors de cette phase (système de gestion des incidents, prise de contrôle à distance, télédistribution, etc.).

Le personnel du service informatique, les développeurs et les maîtres d’œuvre techniques sont de bons candidats à cette phase. Celle-ci permet également d’avoir un premier ressenti de la part des utilisateurs finaux si ceux-ci n’ont pas participé aux homologations techniques ou fonctionnelles.

Lors de cette phase le support aux utilisateurs participant au pré-pilote est en général assuré directement par l’équipe projet. Toutefois, selon l’organisation en place, il arrive que l’équipe soit en deuxième niveau une fois la prise d’appel et la création de ticket d’incident réalisée par le premier niveau.

Taille suggérée : trois à dix utilisateurs maximum dans une PME, moins d’une cinquantaine dans un grand compte.

b. Pilote

La phase pilote va consister au déploiement du nouveau poste sur un échantillon réduit de la population, mais suffisamment représentatif des utilisateurs types et des cultures rencontrées dans l’entreprise. Les participants n’ont pas nécessairement de compétences informatiques particulières, ils sont juste utilisateurs finaux d’un outil mis à leur disposition. Le pilote est l’occasion de tester en situation réelle et éventuellement d’affiner les outils de support aux utilisateurs.

Quelques utilisateurs volontaires exerçant chacun une fonction particulière dans l’entreprise, si possible utilisant des outils différents, pourront constituer une bonne population pour un pilote opérationnel.

La phase pilote doit permettre de transférer progressivement la responsabilité du support de deuxième niveau de l’équipe projet vers les équipes régulières.

Taille suggérée : une trentaine d’utilisateurs maximum dans une PME, moins de trois cents dans un grand compte.

c. Déploiement de masse

Comme son nom l’indique, le déploiement de masse consiste en la généralisation du déploiement sur l’ensemble de l’entreprise. Selon la structure, l’organisation et l’implantation de celle-ci, plusieurs scénarios de déploiement sont possibles : par entité (service, direction, département, business unit), par métier (développeurs, commerciaux, administratifs), par site géographique, par site réseau, par culture, etc. À ce stade, tous les outils et les procédures de support aux utilisateurs doivent être opérationnels, et les opérateurs chargés de ce support formés aux nouveaux outils.

Le déploiement généralisé peut également se faire à l’occasion du renouvellement du matériel, mais prendra dans ce cas beaucoup plus longtemps (annuel, bisannuel, trisannuel, etc.). D’un point de vue logistique, et à condition que la population ne soit pas trop importante, il est également possible de procéder à un déploiement généralisé par la constitution d’un fonds de roulement de quelques postes, sur lesquels le nouveau master est installé, puis de fournir ces postes aux utilisateurs en échange de l’ancien, afin de reconstituer le fonds de roulement.

1. Ressources matérielles

Si vous envisagez un déploiement par renouvellement du parc, la préparation des ressources matérielles est particulièrement importante. À titre d’exemple, voici quelques questions auxquelles répondre concernant les aspects logistiques d’un déploiement :

D’autre part, lorsque la phase de conception a duré plusieurs mois, il arrive parfois que le constructeur du matériel ait opéré de légères modifications sur le matériel, tout en conservant la même référence sur son catalogue (modification d’une puce Wi-Fi, d’une version de firmware, etc.). Avant de lancer la commande de l’ensemble du matériel, faites-vous livrer un exemplaire de poste sur lequel vous ferez un ultime test de votre socle.

Enfin, si vous financez votre matériel via une société de leasing, assurez-vous de l’état de la relation commerciale entre le fabricant et cette société : état de l’encours, règlement des factures, contentieux, etc. Un problème survenant entre le fabricant et la société de leasing aura forcément un impact sur votre planning, mieux vaut prendre les devants.

2. Ressources humaines

L’aspect humain est primordial dans tout projet, qu’il soit informatique ou d’une autre nature. À ce titre, la connaissance des intervenants par tous les acteurs du projet est importante pour assurer un déploiement fluide et garantir la satisfaction des utilisateurs.

Établissez une liste de contacts à laquelle tous les membres du projet pourront se référer en cas de besoin, en précisant les rôles de chacun : opérateurs et techniciens chargés du déploiement, chef(s) de projet, homologateurs, utilisateurs pilotes, fournisseurs et transporteurs, techniciens et responsable du support, sponsor du projet au niveau de la direction, etc.

Selon l’activité de l’entreprise, il est parfois nécessaire de procéder aux déploiements en dehors des heures ouvrées notamment lorsque les utilisateurs ne peuvent interrompre leur travail (salles de marché, industrie, surveillance). Si tel est le cas, l’organisation du déploiement va s’en trouver profondément affectée et vous devrez solliciter le personnel du service informatique pendant des plages horaires auxquelles il n’est pas nécessairement habitué (soirs, nuits, week-end). Même si le volontariat est la solution privilégiée pour déterminer qui participera aux déploiements, le service des ressources humaines de l’entreprise doit dans tous les cas être informé des contraintes du projet, prévenir les organismes nécessaires, et donner des réponses claires aux questions que vont se poser les techniciens : rémunération particulière pour le travail en heures supplémentaires ou non ouvrées, récupération éventuelle, etc.

3. Phasage

Une fois le socle défini et validé, les aspects matériels et humains organisés, encore faut-il établir un calendrier pour le déploiement. Étalé de plusieurs semaines à plusieurs mois (voire plusieurs années dans les environnements très vastes), celui-ci devra prendre en compte les contraintes évoquées plus haut, mais également la stratégie de l’entreprise ainsi que les aspects budgétaires.

Établissez un macro-planning depuis la conception jusqu’à la fin du support en fonction des éléments clés puis détaillez ce planning pour chaque phase.

Ce macro-planning pourra s’exprimer en unités assez grandes, telles que le trimestre ou le semestre, mais également contenir des dates clés plus précises (sortie d’un produit, fin de support de la part d’un éditeur, déménagement, acquisition d’une société, contrainte légale). Il donne une vue générale du projet et permet d’en percevoir rapidement les jalons.

Le planning détaillé utilisera plutôt comme échelle le numéro de semaine dans l’année, voire même le jour unitaire. Il prend en compte les contraintes humaines et matérielles (vacances, travaux, livraisons, jours fériés, etc.) et permet de suivre la progression du projet et de contrôler le respect des délais annoncés.

Si vous êtes familiers avec eux, les logiciels de gestion de projet du type Microsoft Project peuvent vous aider à planifier votre projet de déploiement. Dans le cas contraire, un tableau de type Microsoft Excel pourra également convenir et vous évitera de perdre du temps sur les diagrammes de Gantt recalculés automatiquement, les plannings de ressources, les erreurs de surallocation, etc.

4. Communication et formation

Le remplacement d’un poste de travail par un autre, s’il peut sembler anodin vu du service informatique, pourra être vécu comme un bouleversement important par l’utilisateur. Dès que les bruits de couloir vont commencer à se répandre au sujet d’un projet imminent de changement des postes de travail, les interrogations et les questions vont alimenter les conversations autour de la machine à café. De l’utilisateur débutant qui va vous demander s’il retrouvera ses documents si vous lui changez son écran, à celui qui vous donnera son avis argumenté concernant la version de Windows que vous allez déployer, chacun ressent différemment ce type de projet, à la lumière de ses propres connaissances en informatique.

Comme dans tout projet, une communication maîtrisée permet, à défaut de le garantir, de mettre toutes les chances de réussite de votre côté. À tous les stades du projet, les informations doivent circuler entre les utilisateurs, les équipes en charge du projet et la direction : les difficultés éprouvées par les utilisateurs du nouveau socle doivent être remontées au support, les problèmes rencontrés par les techniciens doivent être corrigés par l’équipe en charge de la conception, la direction doit être tenue informée de l’avancement et des risques identifiés.

Mais avant de démarrer les phases opérationnelles, vous devrez communiquer avec vos utilisateurs pour collecter leurs besoins et leurs attentes, définir avec eux leur nouvel outil de travail, en un mot, les impliquer dans le processus de conception. Cette implication d’utilisateurs sélectionnés vous sera utile au moment du déploiement et des premières difficultés rencontrées : ces utilisateurs pourront être les relais nécessaires pour expliquer, former et justifier les choix effectués. D’autre part, un appui de la part des directions fonctionnelles est extrêmement important et permettra à tous les utilisateurs finaux de sentir que ce projet n’est pas “encore un projet de la DSI” mais bien un projet qui s’inscrit dans la stratégie de l’entreprise. Le service ou la personne habituellement en charge de la communication dans l’entreprise devra véhiculer les messages importants tout au long du projet : présentation du projet (objectifs, dates clés, équipes en charge), déploiement (annonces aux populations concernées) et support (chiffres clés, résumé).

En amont du déploiement et selon le degré de changement qu’il va provoquer, réfléchissez également à la mise en place de formations au nouveau poste de travail. Elles peuvent être internes ou externes, collectives ou individuelles, obligatoires ou optionnelles, mais dans tous les cas, elles permettront de rassurer les utilisateurs les moins expérimentés, de satisfaire la curiosité des technophiles et vous éviteront le reproche d’avoir imposé unilatéralement et sans ménagement un outil de travail inadapté. L’utilisation de mini-quizz et de fiches de retour à l’issue de ces formations vous permettra d’en mesurer la qualité et la perception par les utilisateurs. D’autre part, la diffusion de triptyques ou de plaquettes résumant les informations essentielles du nouveau poste de travail (raccourcis-clavier, nouvelles façons de faire, nouvelles icônes, nouveaux services, nouveaux contacts) rassurera les utilisateurs débutants.

Enfin, un sponsor par la direction à l’origine du projet (généralement la Direction Informatique ou équivalent) vous assurera un budget et vous facilitera la communication avec les comités de direction, mais vous demandera en retour un travail de reporting conséquent pour faire connaître aux “payeurs” l’avancée des déploiements, les risques de dérives s’ils existent, les difficultés rencontrées, les budgets consommés, etc.

1. Mesure de l’avancement

L’avancement d’un projet peut se mesurer à l’aide d’une multitude de critères : jours-homme consommés, sommes dépensées par rapport au budget alloué, nombre de tâches réalisées, jalons franchis, etc. Dans le cas d’un projet de déploiement, l’indicateur le plus pertinent est peut-être celui du nombre de nouveaux postes déployés par rapport au nombre total d’anciens postes à remplacer.

Mais pour connaître cet indicateur, encore faut-il en maîtriser les composantes : combien de machines neuves ont été livrées au stock, combien sont en cours de préparation, combien sont hors service, combien d’utilisateurs n’ont pas été disponibles lors du rendez-vous pour le remplacement, etc. La connaissance de ces éléments sous-jacents implique que toutes les équipes du projet tiennent à jour leurs propres indicateurs, et vous les remontent régulièrement (quotidiennement ou au moins de manière hebdomadaire). L’utilisation de fiches pour la réception du matériel (sauf si cela est déjà géré par une application interne de stock ou d’immobilisations), pour la préparation des postes (nom de l’utilisateur final, applications particulières installées, particularités de la configuration) ainsi que pour la réception (procès-verbal de recette signé par l’utilisateur), vous permettra d’avoir un suivi de l’avancement des différentes étapes de votre déploiement.

Compilés, ces chiffres donneront une vue détaillée du projet, et permettront également de connaître les causes d’une éventuelle dérive. La tenue d’un comité de pilotage hebdomadaire composé des chefs d’équipes et du chef de projet peut également permettre d’identifier rapidement les risques et de trouver un moyen de les adresser : absences de techniciens, fermeture temporaire de sites, grèves, problèmes d’approvisionnement, etc.

2. Organisation de la remontée d’incidents

Lorsque le déploiement commencera, toutes les équipes devront être prêtes à traiter les premiers incidents (qui ne manqueront pas d’arriver), et éventuellement à corriger les problèmes qui n’auraient pas été identifiés lors du pilote et de l’homologation. Afin d’identifier les problèmes à temps et de les traiter au plus tôt, la remontée d’incidents doit être organisée et intégrée à tous les niveaux d’intervention : techniciens chargés du déploiement, personnel du support, ingénieurs système ayant conçu le socle, maîtrise d’ouvrage l’ayant défini, etc.

Même si l’entreprise est équipée d’un système de gestion des incidents ou des demandes dans lequel chaque utilisateur peut ouvrir un ticket, il peut être intéressant, pendant la phase de déploiement mais également à long terme, de mettre en place des utilisateurs référents (appelés parfois “correspondants informatiques”). Contacts privilégiés entre la Direction des systèmes d’information (DSI) et les directions fonctionnelles, généralement à l’aise avec l’outil technologique, ces utilisateurs vous permettront d’avoir un point de centralisation des incidents communs à plusieurs utilisateurs, mais également d’obtenir des informations plus précises sur le problème rencontré, la procédure de reproduction, l’éventuel contournement trouvé, etc. De préférence intégrés aux phases pilotes, ces utilisateurs pourront servir de relais pour redescendre l’information lorsqu’une solution aux problèmes aura été trouvée.

Une fois les incidents remontés au niveau du service informatique ou du groupe de projet, encore faut-il qu’ils soient traités. Un comité de projet, regroupant par exemple le chef de projet, le responsable du support, la maîtrise d’ouvrage et la maîtrise d’œuvre, peut se réunir régulièrement pour faire le point sur les incidents spécifiques au déploiement, détecter au plus tôt ceux nécessitant un traitement particulier ou une modification du socle, mettre en place et suivre les actions correctives nécessaires.

La création de catégories spécifiques au projet dans le système de gestion des demandes ou des incidents permettra de suivre de manière plus précise ceux liés au projet, mais également de produire des statistiques précises lors du bilan de projet.