Le second volet de la trilogie sur les contrats informatiques a pour objectif de dresser une typologie des situations à risque les plus fréquemment rencontrées (I) et les écueils à éviter (II).
I. Les situations à risques
Elles peuvent être regroupées en cinq catégories et se manifestent à toutes les phases d’un projet informatique aussi bien lors du lancement, que pendant la conception, la réalisation, l’intégration ou la recette.
1.1 Les cas de remise en cause du besoin.
• La gestion des implicites :
Au moment de la conception, lorsque le prestataire réalise l’analyse d’écart entre les fonctionnalités standards du produit retenu et les besoins des utilisateurs, la principale source de conflits à laquelle se heurte les parties est celle de la profondeur du besoin du client. Le client se rend compte que l’intégrateur ne connait pas son métier aussi bien que lui ou qu’une spécificité structurante pour l’entreprise n’a pas été identifiée en amont.
• L’absence d’homogénéité des besoins :
Les parties ne se préoccupent pas toujours, avant le démarrage d’un projet, de l’amélioration des processus et de l’organisation métier. Elles pensent pouvoir, à tort, fédérer les besoins des utilisateurs au travers de l’outil retenu. Les attentes sont dès lors déçues. Le client reprochant de ne pas retrouver dans le progiciel ses habitudes de travail, le prestataire n’arrivant pas à convaincre le client à rentrer dans la logique du progiciel.
• Le référentiel qui évolue :
Le référentiel de départ est la plupart du temps le cahier des charges. Il est ensuite transformé, dans les méthodes classiques, en spécifications générales puis en spécifications détaillées. Alors que les parties valident ces documents de conception, la phase de réalisation, voire celle de recette, fait émerger des besoins fonctionnels plus complexes que ceux prévus à l’origine, de nouvelles fonctionnalités qui n’avaient pas été identifiées, des régressions fonctionnelles de la nouvelle solution par rapport au système existant.
1.2 Les cas de remise en cause des choix effectués lors de l’appel d’offre.
• Les changements de stratégie politique :
Les cas sont nombreux. Le client acquiert, à la suite d’un rachat, une société dont la solution informatique est plus aboutie que celle objet du projet en cours. L’intégrateur signe un contrat avec un plus gros client. L’éditeur modifie les priorités de sa roadmap.
• Le changement de priorité :
Entre deux projets informatiques, le client comme le prestataire, peut changer de priorité. Les raisons peuvent tenir à l’absence de disponibilité des équipes, le consultant expert qui n’arrive pas, l’émergence d’une nouvelle règlementation.
• L’absence de conduite du changement :
La solution applicative est destinée aux utilisateurs qui ne sont pas toujours les plus consultés lors du choix. Si le client ne met pas en place les outils et les moyens de communication pour accompagner et parfois convaincre les utilisateurs du bien-fondé de ce choix, il laisse une certaine latitude pour rejeter la solution et refuser de se l’approprier.
1.3 Les cas de mauvaise gouvernance des projets.
• Les équipes sous dimensionnées :
C’est une critique qui peut être faite à tous les acteurs impliqués dans le chantier : côté DSI, prestataire ou client, chacun souffre du manque de ressources, de disponibilité ou de compétences internes à un moment ou à un autre du projet.
• Les facteurs humains mal appréhendés :
Les changements d’hommes clés (Sponsor/Directeur de projet), les équipes d’avant-vente différentes de celles du « build » ou du « run » ou l’absence de stabilité pendant l’exécution sont autant de cause de perte de confiance.
• Les affrontements internes au sein de la MOA :
Les divergences entre les différentes entités métiers du client sont à l’origine d’échec retentissant : l’absence d’entité « leader » ou « pilote » disposant des moyens et/ou de l’autorité nécessaires pour imposer le core system à l’ensemble des entités concernées.
1.4 Les cas de défaillance du pilotage.
• La mauvaise programmation des intervenants qui se manifeste par :
le manque d’anticipation entre les tâches « à faire », « faites » et « restant à faire »,
l’absence de tenue des instances de pilotage ou de rédaction des comptes rendus qui brouille la lecture du déroulement du projet,
les fiches d’intervention non signées qui deviennent source de discussions financières dont les parties n’arrivent pas à sortir.
• La gestion du projet par le planning :
Sous la pression de la direction Générale ou d’une direction métier, les parties signent souvent des projets sur la base de planning irréaliste laissant une marge de manœuvre trop étroite pour faire face aux aléas. On sait en effet que les causes de dérapage du planning sont légions et protéiformes (retard de fourniture de la plateforme, consultant retardé, utilisateurs indisponibles, mauvais diagnostique de la cause d’une anomalie …).
• L’absence de décision ou d’arbitrage :
Le projet souffre souvent d’un processus clair d’arbitrage interne ou d’un refus de prise en compte des alertes. La tentation est grande de laisser en suspens les sujets délicats ou de reporter leur traitement à un moment plus opportun qui ne se présente finalement pas.
II. Les écueils à éviter
• La confusion des rôles :
Lorsque le projet dérape, la tentation est forte de pallier les carences de l’autre partie. Or, il faut éviter de prendre en charge, directement ou par l’intermédiaire d’une société tierce, les tâches relevant de l’autre partie. En effet, on ne résout pas les difficultés du projet en réalisant des tâches qui relève de la maîtrise d’ouvrage ou de la maîtrise d’œuvre, sauf à renégocier les mécanismes de gouvernance et de pilotage initialement prévus au contrat.
• Le « colmatage » par avenants :
En dépit des difficultés relationnelles que cela peut engendrer, il ne faut ne pas hésiter à laisser s’exprimer les alertes et les voir traitées jusqu’à leur terme. L’avenant doit refléter la réalité du compromis auquel les parties ont abouti. Ce n’est pas le cas de l’avenant qui résout une partie du problème mais pas sa globalité.
• Les prestations non indispensables :
Éviter, autant que possible, de réaliser des études ou plus généralement des travaux non indispensables et/ou non prévus, sans devis voire commande préalable. On oublie souvent de faire l’analyse d’impact de toutes nouvelles prestations, sur le plan du planning, de l’homogénéité de la solution ou sur les ressources, en ne traitant que les aspects financiers.
En conclusion, la phase d’exécution d’un projet informatique est l’épicentre des situations pathologiques quasiment inévitables. Les connaître permet à la fois de les anticiper et de les traiter au bon moment dans le cadre d’un plan d’action ou grâce à l’intervention d’un expert indépendant capable d’avoir le recul suffisant pour mettre d’accord les parties.
