Comprendre les projets informatiques
et le digital interne d'Entreprise
Le cycle en V reste encore la méthode la plus répandue pour gérer un projet informatique, tout simplement par ce que tous les acteurs projets ne sont pas "compatibles" avec une méthode agile.
Pour cette raison, j'ai choisi de détailler chacune des étapes "classiques" d'un cycle en V pour pour faire comprendre les actions et responsabilités de chaque acteur, et les objectifs de chacune de ces étapes.
Les projets informatiques
Les étapes
La pertinence du projet
C'est la maîtrise d'ouvrage qui doit décider de la pertinence du projet. Pour prendre sa décision, elle doit identifier un véritable retour sur investissement, ou si ce retour sur investissement n'est pas flagrant à première vue, la maîtrise d'ouvrage doit mettre en avant un impératif absolu (pour répondre à des obligations légales, pour sécuriser le système d'information, ...).
Il faut surtout veiller à répondre à la bonne question lorsqu'on réfléchit à un projet à lancer. Exemple, si un outil n'est pas utilisé dans l'entreprise, et que l'on souhaite se lancer dans un projet informatique pour améliorer son usage, il faut envisager tous les cas de figure expliquant ce manque d'intérêt pour identifier la bonne réponse.
Dans cet exemple, est-ce que les utilisateurs boudent l'outil à cause de problèmes de performance, à cause d'une ergonomie inadaptée, d'un look non attractif, ou parce qu'il ne leur apporte rien au quotidien, ou tout simplement, ... qu'ils n'en ont jamais entendu parlé?
Une décision réfléchie
Le lancement d'un projet ne saurait se décider entre deux cafés, ni sur le coin d'une table. Ce ne doit pas être une réponse à un effet de mode. C'est une réponse à un besoin réel de l'entreprise, avec un retour sur investissement parfaitement identifié. Lancer un projet est une action lourde qui comporte des impacts importants sur des collaborateurs et sur l'entreprise. Cela coûte de l'énergie et donc de l'argent.
Au commencement du projet est l'idée ; celle qui est à l'origine du besoin qui sera décrit ensuite pour permettre la réalisation. Généralement, le besoin est issu de la MOA ou du terrain (utilisateurs). Dans certains cas, la maîtrise d'oeuvre peut en être à l'origine : pour faire un "pallier technique" (changer de version) ou pour améliorer des caractéristiques techniques (performances, ...).
Prise de conscience d'un besoin
Cette prise de conscience de besoin provient d'une maîtrise d'ouvrage. La direction marketing peut par exemple se rendre compte qu'elle a besoin d'un outil d'aide à la prise de décision mettant en oeuvre des techniques informatiques.
Elle peut provenir aussi d'une maîtrise d'ouvrage qui, au vu de certains changements de paramètres de l'entreprise (augmentation du nombre de clients, ...) détecte le besoin d'améliorer certains pans du système d'information.
Avant projet
Expression de besoins
Avant toutes choses, ne croyez surtout pas que la transmission de la connaissance du besoin est une tâche simple et sûre.
Que cette transmission soit orale ou écrite, le message est déformé à chaque fois qu'un intermédiaire l'interprète et le communique aux autres acteurs projets.
Raison de plus pour soigner l'expression de besoin et pour valider la non déperdition et la non transformation de l'information à chaque étape.
Une première étape essentielle
Une fois la pertinence du projet validée, la maîtrise d'ouvrage peut lancer une étude sur les besoins que la future application doit couvrir. Cette étude peut se réaliser en collaboration avec une maîtrise d'ouvrage déléguée, ou avec l'aide d'informaticiens de la maîtrise d'oeuvre en qualité de consultants si des premiers avis techniques ou d'expertise fonctionnelle sont nécessaires.
Au cours de cette étape est rédigé un document d'expression de besoins qui décrira de façon formalisée les grandes lignes du projet, ainsi que son périmètre fonctionnel. Ce document sera validé par la maîtrise d'ouvrage, et pourra aussi être visé par les utilisateurs finaux ou d'autres acteurs impliqués dans le projet.
Que doit contenir ce document ?
Les maîtrises d'ouvrage de toutes les entreprises voient dans la rédaction de l'expression de besoin (la célèbre "EB " dans le jargon des informaticiens) un exercice difficile. Les maîtrises d'ouvrage s'imaginent souvent que les maîtrises d'oeuvre demandent ce document uniquement pour gagner du temps, ou pour les torturer.
Plus sérieusement, le document "expression de besoin", lorsqu'il est correctement écrit, est la première brique du projet. Toutes les discussions pourront commencer sur la base de ce document qui pourra être diffusé à toutes les personnes impliquées. Il est fort possible qu'à l'issue des discussions, le projet soit très différent de ce que l'expression de besoins originale décrivait, mais qu'importe : c'est bien la première brique concrète du projet.
La rédaction de l'expression de besoin permet aussi à la maîtrise d'ouvrage de poser ses idées, et de les confronter à des cas inattendus qui apparaissent au cours de la rédaction du document. Le document lui permet aussi de faire valider le besoin par certains décideurs de l'entreprise.
Exprimer ses besoins, sans plus
Il arrive que des maîtrises d'ouvrage confondent besoins fonctionnels et besoins techniques. C'est souvent le cas lorsque les personnes responsables de la maîtrise d'ouvrage ont des connaissances techniques . Dans de tels cas, les expressions de besoin peuvent être pollulées par des descriptions techniques, souvent incorrectes, qui déforment le vrai besoin.
Exemple : "J'ai besoin d'un outil qui me permette de gérer la liste des clients, et d'accéder à leurs commandes" est bien une demande fonctionnelle.
Par contre, "J'ai besoin d'une base de données SQL server qui me permettent de faire des jointes entre la table client et la table des commandes" est une expression de besoins pollulée par des considérations techniques qui n'ont pas lieu d'apparaître à ce stade.
Dans d'autres cas encore, la maîtrise d'ouvrage peut être consciente qu'il y a un besoin à combler grâce à un outil informatique, mais est bien incapable de l'exprimer de façon formelle. La maîtrise d'ouvrage va alors s'appuyer exagérément sur la maîtrise d'oeuvre pour décrire ce besoin, en lui demandant ce qu'il est possible de faire. Dans un tel cas, une certaine lacune apparaît au niveau de la maîtrise d'ouvrage : l'appel à une maîtrise d'ouvrage déléguée est certainement à privilégier.
Spécifications
Entre la simple expression de besoin et le détail des fonctionnalités, il y a un gouffre.
Imaginons le parallèle entre le monde informatique et le monde des voitures. Un client (la maîtrise d'ouvrage) vient voir son garagiste (la maîtrise d'oeuvre) pour acheter une voiture. Le besoin du client tient en une phase : "je voudrais acheter une voiture".
Cette demande est claire, mais elle n'est pas suffisante pour permettre au garagiste de proposer le véhicule le plus adapté à son client. Pour cela, le garagiste va devoir poser plusieurs questions supplémentaires : "essence ou diesel, berline ou familiale, quelle puissance, quel équipement, quelle couleur, etc...".
La situation est identique dans un projet informatique : le besoin fonctionnel nécessite d'être détaillé pour être réalisé.
Une complexité croissante
Plus on approche les équipes qui vont techniquement réaliser le projet informatique, plus la complexité augmente. D'un simple besoin qui tient en une phrase découle quelque fois un document qui peut contenir plusieurs centaines de pages.
Voici une illustration à partir d'un besoin tout simple exprimé par un utilisateur. Son besoin tient dans une phrase : "j'ai besoin de statistiques supplémentaires". Ce besoin lui semble légitime, simple et suffisant. Il envoie un mail à la maîtrise d'ouvrage de l'application qui doit instruire la demande :
La maîtrise d'ouvrage qui connaît mieux l'ensemble du système, complète ce besoin, en précisant de quelles statistiques il s'agit, en précisant les noms des données manipulées, et en précisant la forme à donner à ces statistiques. Il communique ce besoin à la maîtrise d'oeuvre.
La maîtrise d'oeuvre a une vue complète, fonctionnelle mais aussi technique. Le chef de projet côté Maîtrise d'oeuvre identifie les impacts fonctionnels de cette demande, en indiquant par exemple les fonctions à ajouter, que la maîtrise d'ouvrage n'avait pas identifié. Un document de spécification détaillé est écrit, et validé par les deux parties.
Les équipes techniques réalisent ensuite des études pour expliquer de façon claire et sans ambiguïté toutes les tâches que doivent réaliser les développeurs. L'objectif ici est que les développeurs aient le moins de questions à se poser au moment du développement. Pour cela, il faut donc entrer encore plus loin dans les détails.
Un cahier des charges
Contrairement au document d'expression des besoins, le cahier des charges détaillé dresse la liste exhaustive de toutes les fonctionnalités, même les plus anodines.
Dans la réalité de tous les jours, ce document est bien souvent réduit à son strict minimum, lorsqu'il n'est tout simplement pas oublié. C'est que cette démarche est souvent identifiée comme une perte de temps par la maîtrise d'ouvrage et par la maîtrise d'oeuvre, car elle retarde le développement.
La rédaction de ce document apporte pourtant de nombreux avantages qui, au contraire, fait gagner par la suite un temps très précieux. L'étude dans le détail permet d'identifier toutes les incohérences du projet :
-
incohérences fonctionnelles,
-
incohérences d'architecture matérielle,
-
etc...
Le document doit être réalisé en collaboration avec la maîtrise d'ouvrage car les zones d'ombre fonctionnels apparaissent régulièrement au cours de la rédaction : la maîtrise d'ouvrage doit souvent trancher. Il sera signé et validé par l'ensemble des acteurs.
Un document contractuel
Ce document constitue un élément contractuel qui assainie les relations entre les différents intervenants. C'est un contrat fonctionnel entre la Maîtrise d'ouvrage et sa maîtrise d'oeuvre, et entre la maîtrise d'oeuvre et le prestataire chargé de la réalisation. Il permet en effet de figer au plus près le périmètre fonctionnel de l'application, et limite au maximum les dérives fonctionnelles ou du moins, clarifie les responsabilités si cela arrive :
-
La maîtrise d'ouvrage est assurée de disposer en fin de projet d'une application réalisant les fonctionnalités décrites dans le document qu'elle a validé en toute connaissance de cause,
-
La maîtrise d'oeuvre est assurée que la maîtrise d'ouvrage ne modifiera pas en cours de route les fonctionnalités (dans la théorie). Elle est aussi assurée contractuellement que le prestataire va lui livrer ce qui est décrit dans le document. En cas de non conformatité, ce dernier ne pourra pas se retrancher derrière des spécifications trop floues.
-
le prestataire est assuré (dans la théorie) que son périmètre d'intervention et fonctionnel ne va pas s'étendre comme un élastique au fur et à mesure du temps. C'est important, essentiellement dans les prestations réalisées au forfait (pour un prix fixe arrêté à la signature du contrat).
Important
ce document est important, car lui seul permettra de juger, lors de la recette, de la conformité de ce qui a été livré. Sans ce document, la maîtrise d'oeuvre ou le prestataire chargé de la réalisation auront toute liberté en terme d'ergonomie, ou de règles de gestion. En cas d'erreur, aucun document n'attestera qu'il s'agit d'une non conformité prise en charge par la clause de garantie de prestation.
Au final, ce qui n'apparaît que comme une demande toute simple à l'origine peut s'avérer être quelque chose de plus ou moins complexe à réaliser au final, avec des études plus ou moins compliquées :
Etudes techniques
S'il est important d'identifier toutes les fonctionnalités utiles, il arrive un moment où il est nécessaire de faire le parallèle avec la réalité technique et de lancer des alertes si nécessaire. C'est de la responsabilité de la maîtrise d'oeuvre.
Les enjeux
Les enjeux de cette étude technique sont importants. Les conclusions posent parfois des problèmes de mésententes entre les maîtrises d'ouvrage et les maîtrises d'oeuvre.
-
Identifier au plus tôt les contraintes techniques : l'étude technique permet d'identifier les contraintes techniques qui existent pour réaliser le projet. Ces contraintes peuvent remettre en cause une fonctionnalité existante (régression) ou une nouvelle fonctionnalité prévue.
-
Identifier les charges de travail : certaines fonctionnalités semblent quelque fois anodines, mais peuvent coûter techniquement très chères. La responsabilité du chef de projet maîtrise d'oeuvre est d'identifier ces fonctionnalités, et d'en informer la maîtrise d'ouvrage.
-
Identifier les moyens à mettre en oeuvre : un nouveau projet peut nécessiter la mise en place d'une nouvelle architecture technique complète. Mieux vaut identifier ce point au plus tôt pour l'intégrer dans le budget, et surtout être capable de commander les matériels à temps pour en disposer le moment venu.
-
etc...
Source potentielle de conflits
Les conclusions des études techniques sont potentiellement sources de conflits entre la maîtrise d'ouvrage et la maîtrise d'oeuvre. L'annonce par la maîtrise d'oeuvre de l'infaisabilité technique d'une fonctionnalité qui a l'air simple à énoncer peut irriter la maîtrise d'ouvrage.
Il faut avouer que sur le plan technique, la maîtrise d'ouvrage se sent, face à sa maîtrise d'oeuvre, comme tout propriétaire de voiture face à son garagiste qui lui annonce qu'il faut changer toute la distribution. Comment savoir si le diagnostic est correct, ou tout simplement si le garagiste est sincère ?
Il arrive alors parfois que la maîtrise d'ouvrage refuse d'entendre les arguments de la maîtrise d'oeuvre, et joue le forcing pour faire passer une fonctionnalité, coûte que coûte. Inversement, des maîtrises d'oeuvre peuvent être tentées d'avancer des impossiblités techniques pour se débarasser de projets potentiellement dangereux.
Dans tous les cas, seule une excellente relation gagnant / gagnant entre la maîtrise d'ouvrage et la maîtrise d'oeuvre permet de travailler dans un climat de confiance récipropre.
Lancement projet
La planification
La maîtrise d'oeuvre va établir le plannig de réalisation du projet, en tenant compte des différentes contraintes de tous les acteurs du projet :
-
présences des principaux acteurs
-
dates jalons incontournables
-
charges incompressibles de certaines tâches
-
etc...
De la même manière Il arrive que la maîtrise d'ouvrage exerce une pression à ce niveau pour réduire les délais de réalisation. Plusieurs raisons possibles peuvent expliquer cette action :
-
volonté de "mettre la pression" : il arrive que certaines maîtrises d'ouvrage pensent bien faire en mettant la pression sur les équipes de la maîtrise d'oeuvre. Ce faisant, elles pensent se mettre des marges de sécurité pour se garantir que la date finale "officieuse" (celle que seule la MOA connaît, et qui est plus tardive que celle annoncée à la MOE). Ce raisonnement comporte quelques risques notamment des risques techniques et fonctionnelles dus à la précipitation.
-
respect de dates impératives : pour des raisons justifiées ou pas, certaines dates sont impératives. Dans ce cas, la solution est de "lotir" l'application, c'est à dire de décomposer le projet en plusieurs "lots fonctionnels" indépendants, de sorte que la livraison du premier lot coïncide avec les dates imposées.
Go / No Go
Après avoir validé ensemble le chiffrage et la planification, maîtrise d'ouvage et maîtrise d'oeuvre vont décider de lancer ou de ne pas lancer le projet. Un "GO" équivaut à l'ordre de lancement du projet. Après le GO, le rôle du chef de projet maîtrise d'oeuvre est de respecter scrupuleusement ce à quoi il s'est engagé en terme de coût, de délais, et de qualité.
Attention cependant à ne pas tarder pour lancer le GO. Tant que le lancement n'est pas déclarer, tous les plannings gardent comme date de fin la date initiale. Or si la date de lancement glisse dans le temps, il serait logique que la date de fin glisse d'un même délai, ce qui n'est pas toujours le cas.
Après les études fonctionnelles (cahier des charges détaillé) et l'étude technique, la maîtrise d'oeuvre est désormais capable établir un chiffrage complet du projet : elle dispose des fonctions à développer, ainsi que des informations techniques qui vont impacter le chiffrage final.
Le chiffrage du projet
La maîtrise d'oeuvre va pouvoir réaliser le chiffrage de la réalisation du projet. Ce chiffrage comprendra tous les coûts qui impactent son domaine de responsabilité. Si ce domaine se borne au seul développement, le chiffrage ne tiendra compte que de ces seules charges.
Il arrive que la maîtrise d'ouvrage exerce une pression à ce niveau pour réduire le budget final du projet. Plusieurs raisons possibles peuvent expliquer cette action :
-
manque de confiance dans le chiffrage réalisé par la maîtrise d'oeuvre : la maîtrise d'ouvrage a l'impression que la maîtrise d'oeuvre se "fait du gras" sur son dos. Dans un tel cas, cela est symptomatique d'une relation "gagnant / perdant " dans le partenariat maîtrise d'ouvrage / maîtrise d'oeuvre, qui augure mal pour la suite du projet.
-
baisse des crédits attribués au projet : pour des raisons conjoncturelles, les crédits pouvant être utilisés dans le cadre du projet ont été revus à la baisse. Dans un tel cas, la seule solution consiste pour la maîtrise d'oeuvre à demander à la maîtrise d'ouvrage de supprimer certaines fonctionnalités, à la hauteur de la coupe budgétaire
-
Volonté de "challenger" la MOE : en se disant que la MOE a forcément pris des marges de sécurité, la MOA peut chercher à explorer le chiffrage pour réduire cette marge artificielle qui peut gréver sa capacité de financement.
-
Volonté de bien vérifier que le périmètre est compris : si, pour un besoin simple, le budget de réalisation est important, sans autres explications, il est normal et même recommandée que la MOA s'interroge et cherche à vérifier que le périmètre est bien compris.
A lire le dossier spécial sur le chiffrage, en cliquant ici
Développement
Ecriture du code
Le développement consiste à développer les programmes nécessaires au fonctionnement de l'application ou à paramétrer un progiciel. C'est souvent une opération de longue haleine qui requiert des développeurs compétents.
Le chef de projet doit porter une attention très particulière au travail de ses équipes, car les risques de dérapage au cours de cette phase sont hélas assez nombreux :
le non respect des spécifications détaillées : de la même manière qu'un maçon qui construit votre maison mettra votre salle de bain à la place du salon parce qu'il n'a pas pris le soin de consulter le plan, il arrive que des développeurs programment une application à leur mode, sans prendre de temps à lire les spécifications détaillées. L'application développée est alors non conforme à ce qui a été demandée.
les erreurs techniques : les développeurs débutants tombent tous le plus souvent dans les mêmes pièges, principalement des problèmes liés à la performance des algorithmes. Certains choix techniques malheureux peuvent aussi mettre en danger la réussite du projet.
Le non respect des règles de l'art : en terme de développements informatiques, il y a des choses qui doivent être faites d'une certaine façon, pour respecter la qualité ou pour garantir la sécurité. Par exemple, de la même manière qu'un électricien ne doit pas couler les fils électriques dans le béton, en dehors d'une gaine, le développeur ne doit pas mettre de mots de passe applicatif "en dur" dans l'application.
etc...
Lors que le GO officiel de lancement a été donné, l'étape de développement de l'application peut commencer. Les développeurs (programmeurs) entrent en scène pour rendre concret un projet qui n'existe pour le moment que sur le papier.
La préparation
Maîtrise d'ouvrage et développeurs informatiques ont parfois ceci en commun : ils veulent démarrer le développement le plus vite possible.
Pour la Maîtrise d'ouvrage, savoir que les premières lignes de code sont en train d'être écrites rassure sur le respect du planning. Pour les développeurs, et particulièrement les plus férus de technologie, écrire les premières lignes de code fait entrer de plein pied dans le projet.
Il ne faut cependant pas se précipiter. Avant de lancer les développements, les étapes de spécification fonctionnelle détaillée et d'études techniques doivent avoir été menées à terme.
Avant de commencer à écrire les premières lignes de code, l'ensemble du projet, en termes de fonctionnalités, doit être connu et décrit. Les développeurs à ce stade, ne doivent avoir aucune question à se poser : position d'un champ par rapport à un autre (ergonomie), règle de gestion (fonctionnel), ... Tout manque de précision peut obliger à faire d'importantes modifications dans toute l'application. Il faudra aussi particulièrement veiller à ce que tous les développeurs travaillent sur ... les bonnes versions des documents de spécification !
Au préalable, une certaine charge de travail doit être consacrée à la réflexion sur la construction du projet. Il s'agit donc ici d'une seconde phase d'études techniques qui permet de définir les algorithmes, les petits mécanismes informatiques à mettre en place (interfaces, ...), les normes à respecter sur tout le projet, etc... A l'issue de cette phase d'étude le développement peut commencer .
Recette
Une recette par rapport
à un référentiel
Une recette ne peut se faire que par rapport à un référentiel de départ. Ce référentiel sera constitué du cahier des charges détaillé et du document réalisé dans le cadre de l'étude technique.
L'existence de ces documents est primordial pour réaliser une recette. Dans le cas contraire, sur quelle base est-il possible de déterminer une non conformité ?
Une étape obligatoire
La recette n'est pas une étape que les acteurs des projets aiment réaliser. Il arrive alors parfois que, par manque de temps, chaque acteur se repose sur la personne suivante pour tester une application. De fil en aiguille, c'est ainsi qu'une application non testée peut être mise en production.
Les dérives
La maîtrise d'ouvrage retournera à sa maîtrise d'oeuvre l'ensemble des non conformités qu'elle aura relevé. Prudence cependant, car parmi des demandes légitimes de correction de non conformité se cacheront des demandes d'évolutions.
En effet, il n'est pas rare que la maîtrise d'ouvrage change d'avis sur certaines fonctionnalités lorsque le projet est quasi terminé. Les demandes d'évolution sont alors remontées de la même manière qu'une demande de correction de non conformité.
L'acceptation ou le refus d'intégrer ces demandes subliminales (lorsqu'elles impactent le projet) est de la responsabilité du chef de projets maîtrise d'oeuvre. Mais sachez que les projets peuvent déraper tout simplement parce que des demandes de modification majeures du périmètre sont formulées lors de la recette.
Le projet informatique est, certes, un projet technique, mais aussi et surtout un projet humain. Pour cette raison, nul n'étant à l'abri d'une erreur, la recette s'avère indispensable avant de mettre une application en production.
A quoi ça sert ?
La recette consiste à tester les programmes livrés par le prestataire ou la maîtrise d'oeuvre. Pour donner un exemple concret, ne pas faire une recette reviendrait à signer le bon de livraison de votre nouvelle maison fraîchement construite sans jamais avoir un pied dedans pour vérifier si les murs sont bien positionnés, ou si les installations de plomberie et d'électricité fonctionnent. Ne pas faire de recette d'une application, c'est signer le bon de livraison sans inspection.
La recette est une opération importante et complexe. C'est souvent considérée comme une tâche "ingrate". On la convie donc souvent à des débutants ou à des stagiaires qui tapent un peu n'importe quoi sur le clavier, au petit bonheur la chance. Bien au contraire, c'est une étape cruciale qui réclame des compétences fonctionnelles et informatiques ainsi qu'une grande rigueur.
En effet, la recette est la dernière étape avant la livraison au client final. Par définition vous n'aurez qu'une seule chance de faire bonne impression du premier coup !
Dans le cadre d'une réalisation en prestation, la recette est aussi la seule étape qui permet de vérifier que les programmes livrés sont conformes aux spécifications. Si la recette est mal réalisée des dysfonctionnements ne seront pas repérés. Si malgré cela vous validez la livraison, la prise en compte des résolutions des bugs sera longue et coûteuse.
Préparation de la recette
La recette est une opération complexe et rigoureuse. Elle se prépare en établissant un document (plan de recette) qui décrit de façon plus ou moins fine l'ensemble des points de contrôle que vous allez réaliser. L'intérêt de ce document est triple :
-
Guide mémoire : vous vous faîtes par ce biais un guide mémoire et méthodologique de tous les points de contrôle, de manière à n'en oublier aucun.
-
Demandes de correction : vous pouvez vous servir de ce document pour noter les remarques et les non conformités que vous avez pu remarquer au fil de vos tests.
-
Trace des corrections effectuées : grâce à ce document, vous pouvez suivre les corrections effectuées par les dévelopeurs, et lire leurs remarques.
-
Délégation : vous pouvez vous servir de ce document pour confier la recette à une personne moins impliquée dans le projet. Les procédures que vous aurez écrites doivent alors être assez détaillées pour lui permettre de réaliser les contrôles nécessaires.
Ce document doit être envoyé au prestataire chargé du développement, avant qu'il ne livre ses réalisations. L'intérêt est de l'inciter à dérouler lui même le plan de recette, afin de repérer avant livraison les éventuelles erreurs.
Mise en production
Eviter l'effet tunnel
L'effet tunnel, c'est le nom que l'on donne à cette phase particulière du développement. Après une période d'études fonctionnelles au cours de laquelle la Maîtrise d'ouvrage a été fortement impliquée, l'implication retombe subitement pendant le développement. La maîtrise d'ouvrage entre alors dans un "tunnel " pendant la traversée duquel elle ne reçoit plus aucune information sur l'avancement de son projet.
Il est impératif de mettre tout en oeuvre pour éviter cet effet tunnel :
-
réunion d'avancement avec la maîtrise d'ouvrage
-
démonstration quand c'est possible des modules déjà développés
A défaut, la maîtrise d'ouvrage risque d'apprende (un peu tard) tel ou tel problème technique. Sans rencontre régulière la Maîtrise d'ouvrage ne sera pas non plus capable de lever des alertes en cas de non conformité d'une partie du projet avec ses demandes. Cet effet tunnel disparaît ou en tout cas s'estompe beaucoup dans un mode projet agile.
La mise en production consiste à installer les programmes sur l'environnement réel. Une fois que ce sera fait, les utiisateurs finaux pourront commencer à travailler avec l'outil, à saisir des données.
Avant cela, maîtrise d'ouvrage et maîtrise d'oeuvre devront avoir terminé la recette de l'outil. La maîtrise d'ouvrage, après avoir validé que l'outil livré correspond en tout point à ses attentes, donnera le GO de mise en production à la maîtrise d'oeuvre.
Côté maîtrise d'oeuvre, cette mise en production doit se préparer. Une "check list" doit être rédigée pour inventorier de façon formelle toutes les tâches à réaliser. La rédaction d'un tel document offre de nombreux avantages :
-
Réflexion : permettre de réfléchir à l'ensemble des tâches à réaliser, et surtout à l'ordre dans lequel il faut les réaliser. En rédigeant un tel document, les contraintes techniques apparaissent plus facilement
-
Guide d'installation : la check list permet de ne rien oublier pendant l'opération de mise en production. Au fur et à mesure que la liste est déroulée, les opérations réalisées doivent être cochées
Mise en service
L'étape précédente (mise en production) a pour objectif de mettre l'outil "en ligne" sur le plan technique. Cela signifie que sur un plan purement technique, l'outil est en place et est opérationnel.
Ca ne veut pas forcément dire que les utilisateurs peuvent commencer à l'utiliser. Dans la plupart des cas, l'outil doit être enrichi de données pour être utilisable : catalogues de produits, informations clients, référentiels, plans tarifaires, etc.
Selon l'importance du projet, et ses impacts sur l'existant, de nombreuses mesures de sécurité doivent être prises, comme par exemple faire des sauvegardes de l'existant avant la mise en production, avec des procédures de restauration pour revenir en situation précédente, si les choses venaient à mal se passer.
Sur le plan humain, cette opération doit s'accompagner d'une information auprès de tous les acteurs du projet, directs ou indirects. Toutes ces actions auront été préparés par la maîtrise d'ouvrage lors de l'étape de l'accompagnement.
La saisie de ces informations n'est possible "en réel" qu'après la mise en production. Pendant une certaine période, les administrateurs ou contributeurs à l'outil s'activeront pour préparer l'ouverture aux utilisateurs ; cette ouverture s'appelle la mise en service. La mise en service correspond à l'ouverture du service à tous les utilisateurs. A partir de ce moment là, la vie de l'outil commence.
Accompagnement
Tandis que l'équipe de la maîtrise d'oeuvre travaille à la mise au point technique de l'outil informatique, la maîtrise d'ouvrage, de son côté, doit travailler à l'accompagenement des utilisateurs. La tâche n'est pas simple.
Frein au changement
C'est humain : les hommes opposent une résistance farouche à tout changement de leur environnement. C'est ce qu'on appelle le frein au changement.
L'outil informatique concentre les reproches parcequ'il est impersonnel. Attendez-vous donc à quelques mécontents. S'il n'est pas possible d'éviter les réactions négatives dûes à cette résistance, il est cependant possible d'en limiter les dégats, en accompagnant l'utilisateur dans cette évolution.
L'accompagnement
Accompagner l'utilisateur, c'est aller au devant de lui, si possible dès la conception de l'outil pour l'impliquer dans la démarche. Cette implication doit cependant être nuancée. Il n'est pas question ici de prendre pour argent comptant toutes les idées fonctionnelles des utilisateurs qui ne maîtrisent aucune des contraintes du système informatique.
Accompagner l'utilisateur, c'est aussi l'informer avant la mise en production, en produisant par exemple des petites plaquettes d'information qui seront distribuées. C'est faire des séances d'information sur la mise en place de l'outil. C'est surtout de montrer tous les avantages de l'outil, et tous les gains que les utilisateurs pourront tirer de son utilisation.
Accompagner l'utilisateur, c'est aussi préparer des séances de formation pour l'aider à utiliser l'outil. C'est encore préparer une "hot line" téléphonique que les nouveaux utilisateurs pourront appeler lors de leurs premières utilisations, pour avoir une réponse rapide à leurs questions.
L'implication de la MOA
Il arrive que des maîtrises d'ouvrage estime que leur projet informatique n'est qu'une affaire d'informaticiens. Ils négligent alors complètement cette étape importante.
Il est important de rappeler ici la nécessité d'une forte implication de la maîtrise d'ouvrage. La réussite du projet dépend de plusieurs choses : le bon accueil que les utilisateurs réserveront à l'outil entre en compte pour une bonne partie.
Pérennisation
La pérennisation du projet consiste à prendre les mesures nécessaires qui devront permettre à l'application de pouvoir vivre et évoluer au fil des années.
Pourquoi pérenniser ?
Une fois l'application mise en production, une équipe technique aura la charge de devoir intervenir en cas de problème. Les risques potentiels d'interruption de service sont nombreux : panne de serveurs, de réseau, ou tout simplement bug ou problèmes systèmes...
En cas de problème grave, il faut donner à l'équipe technique tous les moyens pour permettre une intervention la plus rapide possible. Ces moyens permettront de connaître rapidement, en consultant une documentation prévue à cet effet, quels sont les actions à réaliser sur le système dans le cas d'un plantage. Une telle documentation fait partie des moyens de pérennisation de l'application.
Comment pérenniser ?
La pérennisation passe principalement par la gestion de la connaissance de l'application, pour permettre aux équipes chargées de la production de pouvoir intervenir en cas de problème. Ces informations indispensables sont :
-
Connaissance fonctionnelle : description des fonctionnalités de l'application, des principales règles de gestion, de l'architecture générale de l'outil (échanges avec d'autres Systèmes d'information, etc...).
-
Connaissance architecture serveurs : noms des serveurs utilisés, paramétrages nécessaires, ...
-
Connaissance architecture logicielle : explication sur les programmes développés, description des "points chauds" s'il en existe, etc...
La pérennisation passe par une documentation qui référence toutes ces connaissances :
-
Le cahier des charges détaillés projet peut être la référence fonctionnelle de l'application si le périmètre n'a pas trop évoluer au fil du temps, depuis sa conception,
-
Les documents d'études techniques peuvent être un bon support des connaissances techniques de l'application: principes de fonctionnement des mécanismes informatiques mis en oeuvre au sein de l'application, etc...
Un document de production peut centraliser l'ensemble des informations qu'il est essentiel de connaître pour pouvoir intervenir sur l'application, en cas de problème.
