Article original sous http://www.journaldunet.com - de Antoine CROCHET-DAMAIS publié en janvier 2008

Des objectifs qui ne sont pas alignés sur la stratégie

Les experts interrogés s’accordent à penser qu’un des principaux facteurs d’échec d’un projet réside dans le non-alignement de celui-ci sur la stratégie de l’entreprise (ou de l’administration) dans laquelle il est mis en œuvre.

Chef de projet au sein de la société de services informatiques Aedian, Frédéric Joliot intervient depuis une dizaine d’années sur des missions de développement de systèmes. Centré sur des projets au forfait, il a commencé par des chantiers sur des systèmes MVS dans le domaine de la banque et l’assurance, avant de poursuivre aujourd’hui sur le terrain des plates-formes intranet et extranet (dans l’univers J2EE).

"Il est important que le projet s’inscrive dans une vision portée par le management de l’entreprise, sans quoi la mission sera d’emblée mal partie", souligne-t-il. Bref, il ne sert à rien de lancer l’idée de l’automatisation d’un processus si cette vision ne s’inscrit pas dans une démarche de management.

"C’est un élément qui permettra de structurer le cahier des charges, et de le rendre cohérent", ajoute David Feldman, directeur de LCA - société de conseils spécialisée dans la sécurisation des projets informatiques tant sur le plan juridique qu’opérationnel."Il est important en outre que l’intégrateur ait pris connaissance de ces enjeux pour les respecter au mieux."

Afin de décliner au mieux ces enjeux sous forme de besoins, l’étape de réalisation du cahier des charges ne doit surtout pas être négligée. "Il devra être le plus complet possible, et le plus en phase possible avec les axes stratégiques de l’entreprise qui le concernent", poursuit Frédéric Joliot. "Plus une divergence apparaît tôt par rapport aux objectifs cadres, plus il sera difficile ensuite de rectifier le problème".

Un contrat mal ficelé

"Dans tous les projets que j’ai vu dériver et aller en contentieux, le contrat était soit incomplet soit confus ou encore déséquilibré au détriment de l’une ou l’autre des parties", constate David Feldman chez LCA. Traditionnellement, un contrat spécifie notamment l’objet et la durée du projet. Il fournit une définition globale de la prestation à réaliser. Enfin il aborde les questions de prix, ainsi que les conditions de paiement, d’assurance, de résiliation (...).

"Il est recommandé d’élaborer un plan d’assurance qualité en annexe au contrat", poursuit David Feldman. Ce document a pour but de spécifier le plan d’organisation du projet en détaillant les rôles (MOA, MOE) des différents acteurs, ainsi que les instances de gouvernance (comité opérationnel, stratégique). Des réunions qui permettent aux différents acteurs de se rencontrer pour mettre à plat l’état d’avancement des travaux (sur la base d’indicateurs préalablement remontés), les points de blocage, et revoir ensemble les grands scénarios le cas échéant. L’idée étant d’éviter au maximum les intermédiaires, qui alourdissent l’organisation du projet.

"Dans le cas où ces éléments d’organisation ne sont pas clairement définis, un client peut s’attendre par exemple à ce que son prestataire joue un rôle d’assistance à la maîtrise d’œuvre, ce que celui-ci n’aurait pas compris", poursuit David Feldman.

Le plan d’assurance qualité intègre également le plan de conduite du projet, c’est-à-dire les différentes phases de la mission (analyse éventuellement, développement, intégration, recette) et le timing. Et enfin un plan de gestion du projet qui décrit les processus de suivi des évolutions, la gestion du planning, des recettes, éventuellement celle de la gestion du changement (formation et accompagnement des utilisateurs) sans oublier la gestion des risques.

"Pour éviter que le projet dérive, il est important d’évaluer les risques susceptibles d’avoir un impact sur le déroulement des travaux", ajoute Frédéric Joliot d’Aedian. "Il peut s’agir par exemple de gérer le départ d’un collaborateur clef pour le projet ou encore mettre en place un plan de formation sachant que le client ne maîtrise pas encore la technologie en cours de mise en place."

Une mauvaise gestion des évolutions critiques

C’est un grand classique. En cours de projet, les utilisateurs peuvent être amenés à exprimer de nouveaux besoins, ou à redéfinir des besoins déjà exprimés en amont. "A la vue d’un pilote, les utilisateurs peuvent en effet vouloir affiner le travail d’analyse et modifier leur point de vue initial. C’est humain", analyse David Feldman de LCA. Afin d’anticiper cette éventualité, un processus de gouvernance adapté doit être mis noir sur blanc au sein du plan d’assurance qualité.

La nature de ce processus ? "Dans le cas d’une nouvelle demande, qu’elle soit purement fonctionnelle ou technique, elle est d’abord évaluée au niveau financier par le prestataire. Si l’ajout conduit à un dépassement de budget, voire de délais, il devra alors être validé par le comité de pilotage qui évaluera si ce surcoût en vaut la chandelle au regard des enjeux du projet au niveau de la stratégie de l’entreprise.

"Il est clair que si ce process de prise en compte de nouvelles requêtes n’est pas prévu à l’avance, le projet aura toutes les chances de s’enliser", prévient David Feldman.

Certaines astuces peuvent également apporter une solution à cette situation délicate. "Beaucoup de choses sont envisageables. Si une nouvelle fonction est demandée par les utilisateurs, il est possible par exemple de déprogrammer un développement pour le remplacer par un nouveau, toujours dans l’optique de rester en ligne avec le budget et le planning initial", commente Frédéric Joliot d’Aedian.

Le cas échéant, un avenant au contrat initial pourra éventuellement être rédigé afin de prendre en compte les nouveaux travaux à réaliser, avec à la clés une réévaluation de la charge de travail, du planning et du budget nécessaire. "Si au contraire, c’est le prestataire qui a sous-évalué la charge de travail nécessaire vis-à-vis des besoins initiaux, il n’y aura naturellement aucune raison d’en demander plus au client", précise-t-on chez Aedian.

Le facteur humain

Actuellement directeur de projet chez Euler Hermes, Benoît Bernheim est en charge du déploiement du progiciel SAP pour cette compagnie d’assurance. Dans le passé, il a notamment travaillé pour le compte de la société de services Capgemini, pour laquelle il a notamment assuré des missions d’implantation d’ERP pour de gros clients. A ce titre, Benoît Bernheim a développé une vision sur la manière d’anticiper les causes de dérive d’un projet informatique.

Pour le directeur de projet, l’un des points les plus critiques réside dans la gestion des facteurs humains. "D’abord, un projet doit être supporté par des responsables métier, et surtout pas uniquement par l’informatique. Il est important qu’il soit supporté par les bonnes personnes, c’est-à-dire des acteurs capables de comprendre les enjeux et d’arbitrer sur les priorités, à la fois en amont lors de la phase d’analyse comme lors de l’étape de mise en œuvre."

Benoît Bernheim rappelle l’importance d’arriver rapidement à une première application, mettant en valeur l’intérêt de la démarche du point de vue des utilisateurs. "Il est crucial de montrer qu’un premier ROI est possible. Côté utilisateurs, ce premier développement permettra éventuellement de recadrer ou réorienter une analyse fonctionnelle sur des bases plus concrètes.

Benoît Bernheim ajoute : "cette politique permet également de conserver une bonne dynamique de groupe au sein de l’équipe d’intégration et de développement. Dans le cas d’échéances trop espacées, les intervenants ont en effet tendance à s’user sur la longueur." Ce qui peut d’ailleurs engendrer des erreurs et des négligences... et ce d’autant plus si le projet est important ou complexe.

"Dans l’optique de relancer la dynamique du groupe, il est important d’institutionnaliser l’aboutissement des grandes étapes de la mission, en organisant par exemple à cette occasion une réunion avec l’équipe pour réaliser un bilan et redescendre les décisions prises par les comités opérationnels et stratégiques", détaille Benoît Bernheim.

"Ce peut être également l’occasion d’une rencontre entre l’informatique et les utilisateurs. L’objectif est d’éviter que tout se passe par mail, et de réduire les couches intermédiaires. Enfin, il peut être appréciable de fêter la finalisation de ces grandes étapes, en commençant la réunion par un petit déjeuner par exemple."

Entre les réunions, le chef de projet aura pour tâche d’entretenir la confiance entre utilisateurs et équipe informatique. "Il gére les différents intervenants informatiques, notamment en termes de compétences. Il s’assure de la qualité au regard des indicateurs définis en amont - en termes de coûts, de délai (...) - et informe le client des avancées", précise-t-on chez Aedian.