Bandeau
PL Conseil - Audit et accompagnement des entreprises
PL Conseil - Notre mission : Accompagner les entreprises en difficulté ou souhaitant se développer

PL Conseil accompagne l’Entreprise dans toutes les étapes de ses projets, de l’audit à la formation en passant par la rédaction du cahier des charges et le suivi de la mise en œuvre. PL Conseil - Chef de projet - Consultant - Assistance et conseil - Formation gestion du temps des priorités et du stress - QVT - Brainstorming

Logiciels : Maitrise d’ouvrage / Editeur de logiciel - unis pour le meilleur et pour le pire ?
Article mis en ligne le 6 janvier 2016
dernière modification le 21 mai 2018
logo imprimer

A l’attention des Maitres d’ouvrage…
Vous venez de choisir l’éditeur de votre future solution logicielle ? Parfait ! Comme toute union, l’objectif commun est d’en partager le meilleur ! Et tout le monde est, à priori, dans cet état d’esprit. Quels sont alors les facteurs qui font parfois évoluer ce partenariat vers des litiges, des conflits ou pire, l’abandon du projet voire des actions en justice ?
En cas de litige, chacun protègera ses arrières et s’appuiera sur des éléments tangibles pour faire valoir ses droits (écrits, fonctionnalités logicielles absentes ou dysfonctionnements vérifiés par un expert, témoignages, testimoniaux clients …)
Par principe de précaution, rappelez-vous que le principe de base est que « les paroles s’envolent mais les écrits restent ».
Sans être malheureusement exhaustif, parcourons ici les phases habituelles d’un projet de mise en œuvre d’un logiciel comportant des adaptations fonctionnelles, et voyons les litiges les plus fréquents et la façon la plus simple de les éviter.

1/ L’Avant-projet – la phase « commerciale »
Que votre choix passe par un appel d’offre public ou non, vous avez rédigé votre cahier des charges ou CCTP , vous avez étudié les solutions, fait une « short-list », vu les démonstrations des principaux produits sélectionnés, et eu les réponses des éditeurs pour toute demande spécifique sortant du cadre standard de leur produit (évolutions, fonctionnalités complémentaires, spécifique pur…).
Cette phase est fondamentale pour la suite du projet. Les « non-dit » sont ici lourds de conséquence.
Cette phase doit mobiliser plusieurs types d’acteurs :

  • La Direction (DG, Direction d’établissement, etc…) qui engage le budget et prend la décision.
  • L’informatique (DSI, chef de projet, responsable d’exploitation, etc…)
  • Un groupe utilisateur représentatif de tous les pans applicatifs du projet (responsables de domaines, leaders et experts métiers)
  • Éventuellement un conseil en Assistance à la Maitrise d’ouvrage (pl conseil)

Rappelez-vous ici que « plus une erreur est faite en amont, plus elle coutera cher et sera longue à corriger »
Il est capital que les utilisateurs soient fortement sollicités lors de la rédaction de votre cahier des charges.
Les points importants seront forcément écrits et contractuels.

Toutes les phases suivantes pouvant faire l’objet de litiges, il est primordial que les réponses de la maitrise d’œuvre soient aussi précises et écrites.
Coté Maitre d’œuvre, nous mettons ici l’accent sur les qualités techniques du commercial. Un commercial issu de la technique est souvent plus efficient dans ses démonstrations et fournit une réponse immédiate de faisabilité à des demandes d’évolutions. Vérifiez dans tous les cas que la Direction Technique de cet éditeur est compétente, et ne repose pas que sur une seule personne ! Les réponses techniques doivent être précises, rapides, étayées d’exemples et si possible de réalisations antérieures, bref, prouvées et incontestables. En cas de doute, vérifiez auprès des références de l’éditeur. Utilisez également Internet pour avoir des avis d’utilisateurs.

2/ Démarrage du projet – la réunion de lancement
L’instance projet assiste à la réunion de lancement dans laquelle la maitrise d’œuvre rappelle l’organisation, le planning, les enjeux et les fonctionnalités attendues.
En général, il y a peu de surprises dans ce type de réunion et un rappel du cahier des charges ou des accords commerciaux ne sont pas discutables.

3/ Les phases d’intégration (du progiciel standard)
Avec l’appui du groupe projet, la maitrise d’œuvre commence l’intégration de base du logiciel, et finalise les études concernant les adaptations souhaitées.
En entrant des données réelles et un paramétrage propre à l’entreprise, cette phase peut mettre en lumière certaines lacunes ou dysfonctionnements du logiciel par rapport aux attentes de la maitrise d’ouvrage.
En cas de litige, le premier réflexe sera de faire référence au cahier des charges ou CCTP. Veillez donc à la précision de ce cahier des charges.
« Seuls les écrits restent…. ». Ici, les arguments du type « le commercial nous a dit que… » n’ont aucun poids. Si vous êtes certains de vos propos, cela ne vous servira qu’à valider (ou pas) la confiance que vous aviez mis dans votre prestataire et son honnêteté !

4/ Suivi du projet - COPRO (comité de projet) et COPIL (comité de pilotage)
Lors des différents comités, les points d’attention et parfois de tensions ! sont généralement :

  • Les délais – les retards sont-ils justifiés ? acceptables ? quelles sont les incidences et les impacts ? Le nouveau planning est-il acceptable ? raisonnable ? l’engagement sera-t-il tenu ?
  • La qualité (ou conformité des réalisations avec les attentes)
  • Le coût du projet
  • La maitrise des charges (capacité à faire côté MOE) et le contrôle de l’ensemble des tâches.
  • La disponibilité des ressources (MOA) pour les phases d’études, d’intégration et de recettes
  • L’organisation du changement (formation, procédures…) et le pilotage interne de la migration des systèmes (reprise de données, bascules, phase transitoire…).
    La maîtrise d’ouvrage (ou son AMOA) sera attentive à la qualité du suivi de projet, à la clarté du planning, à la transparence des informations et au respect des engagements (en particulier sur les dates de livraison, le contenu conforme aux engagements, et la qualité - absence de bugs et de régressions).

5/ livraisons complémentaires
Lors de livraisons complémentaires de fonctionnalités spécifiques, que l’éditeur annonce avoir développées pour votre compte (et donc que vous financez sans doute), les sources de litiges sont :

  • Une fonctionnalité absente - l’éditeur peut cependant proposer une solution de contournement avec le détournement de fonctionnalités existantes (phase d’intégration et de paramétrage) – notez dans ce cas que cela impliquera une gestion du changement supérieure à ce qui était prévu en développant une fonctionnalité spécifique et parfaitement adaptée à vos services. Notez également que ce manque est une moins-value sur votre projet – quantifiez-la et négociez ! un avoir ou une remise….
  • Une fonctionnalité mal développée parce que mal étudiée. Étudiez les responsabilités de chacun.
  • Une fonctionnalité mal (ou pas) recettée par le Maître d’œuvre avant la livraison. Dans un processus qualitatif et professionnel, une telle livraison n’est pas acceptable, quel que soit l’argument de l’éditeur. Vous n’êtes pas le pôle recette de votre éditeur ! faites la part des choses s’il s’agit d’un bug dans une situation très complexe (donc acceptable) ou de fonctionnalités basiques qui n’ont jamais été recettées. Dans ce cas, arrêtez immédiatement cette recette et provoquez une réunion d’urgence entre MOA et MOE.
  • Une fonctionnalité bien développée (conforme à son cahier des charges) mais non utilisable (par exemple un problème d’ergonomie détecté par l’utilisateur lors de la recette (écran mal conçu, traitement trop long…) qui rendra cette fonctionnalité impossible à utiliser !). Dans ce cas, vous pourrez argumenter en rappelant la définition de la qualité « c’est évident, c’est implicite ! » mais le litige sera là, et il faudra négocier en recherchant l’origine de ce non-dit, et la responsabilité de chacun. Pour éviter cela, il faut, encore une fois, largement solliciter l’utilisateur lors de la rédaction du cahier des charges (CCTP ou ateliers spécifiques).

6/ La recette
La VABF (Validation d’Aptitude au Bon Fonctionnement)
Vous effectuerez en interne (avec éventuellement l’aide de votre AMOA - PL Conseil), la recette complète du logiciel et des fonctionnalités spécifiques. Le plan qualité du projet précisera les conditions dans lesquelles s’effectuent les recettes et les modalités contractuelles de corrections de bugs ou des dysfonctionnements.
Veillez à ce que cela soit respecté.
La VSR (Vérification de Service Régulier)
Cette phase s’accompagne d’un procès-verbal de recette de type VSR, met fin au projet, et déclenche le dernier règlement au prestataire.

7/Le SAV – Le service Assistance
Après signature de la recette, le projet entre dans une phase de maintenance et change d’interlocuteurs :
Le chef de projet de l’éditeur laisse sa place au service Assistance, les instances sont dissoutes (le COPIL peut subsister dans un cadre global de suivi interne), le chef de projet de la maitrise d’ouvrage passe le relai au référent (ou au consultant AMOA déjà présent) qui centralise les demandes et sert d’interface entre la Maîtrise d’ouvrage et le service Assistance de l’éditeur.
Les problèmes observés ici peuvent être liés à la montée en charge, à une volumétrie mal estimée et trop importante, à des temps de réponse qui se dégradent, à des bugs survenant dans des situations très spécifiques, à des dysfonctionnements liés à une livraison (Régressions), à des problèmes liés à des mises à jour de logiciels périphériques impactant la solution (Navigateurs, Bureautique…), à des problèmes liés au matériel (hébergement, serveurs, PC, mémoire, etc…).
Prévoyez dans l’expression de vos besoins des aspects liés à la volumétrie, aux temps de réponse (métrologie), à la continuité du service. Exigez de l’éditeur des solutions qui ne seront pas limitées aux seules solutions habituelles de reprise d’activité après incident (PRAI).

8/ La formation
Le plan de formation est proposé par l’éditeur et discuté en COPRO pour en définir les modalités de mise en œuvre puis validé en COPIL.
Certains éditeurs confient les formations aux chefs de projet ou à certains techniciens connaissant parfaitement l’application. Un formateur à part entière est bien sûr très efficace, mais l’intérêt ici est de disposer de quelqu’un qui connait parfaitement votre contexte et pourra adapter la formation à votre procédure interne. Toutefois, cette organisation présente un travers qu’il faut absolument éliminer en début de formation : Le formateur doit assumer son rôle et uniquement son rôle, il n’est pas là pour résoudre en direct un problème technique, ou faire un cahier des charges sur des évolutions demandées par les participants ! Vous veillerez que toutes les remarques internes soient centralisées par un participant (idéalement le référent ou l’AMOA PL Conseil) puis qualifiées, classifiées et transmises à l’éditeur.

Enfin, spécifiez dans vos accords, au chapitre formation, si vous souhaitez que celle-ci soit standard ou adaptée à votre procédure et basée sur vos données, cela évitera les questions (et un avenant pour une tâche de préparation) le moment venu.

En résumé, la plupart du temps, et pour toutes ces phases, les litiges découlent souvent de non-dits (ou plus exactement de « non-écrits » !) et d’engagements non respectés.

Les risques augmentent naturellement :

  • Si le projet est important (budget, charges, durée),
  • Si les délais sont serrés,
  • Si le projet est complétement novateur,
  • Si le pourcentage de ressources mobilisées côté éditeur est important,
  • S’il y a de nombreuses adaptations logicielles,
  • Si le besoin n’est pas parfaitement défini et clair pour tout le monde.

Et ils diminuent :

  • Si les responsables opérationnels (chef de projets MOE et MOA – ou AMOA) sont expérimentés, savent prendre du recul, savent communiquer et cherchent des solutions posément de façon honnête et objective.
  • Si les responsables opérationnels partagent la même volonté de réussir, et font preuve d’imagination (souvent issues de l’expérience de chacun) pour résoudre les problèmes,
  • Si les délais sont raisonnables,
  • S’il y a peu (ou pas) d’adaptations logicielles,
  • Si tous les aspects techniques sont identifiés et maîtrisés,
  • Si l’éditeur à la « capacité à faire » et n’a pas un plan de charge déjà surchargé et des ressources en contentions permanentes,
  • Si le besoin est précis et clair, lisible à tous les niveaux (Direction, utilisateurs, informaticien, experts métier ou techniciens…).

« Avant de travailler avec des entreprises, on travaille avec des hommes ! ».
De nombreux éditeurs ont été mis en difficulté (litige simple, abandon du projet, négociation, action en justice, procès …) par manque d’engagement et sous-estimation du projet (ou d’une étape) et des impacts qu’un échec pouvait engendrer chez leur client.
Faites le bon choix et donnez un sens à cet adage !

Pour plus d’informations et des conseils sur notre mission d’AMOA, n’hésitez pas à nous contacter.


Forum
Répondre à cet article

Calendrier

octobre 2018 :

Rien pour ce mois

septembre 2018 | novembre 2018

Pas d'évènements à venir

Actus

OUTILS : Diagramme de causes et effets (5M, 6M, 7M…)

Kaoru Ishikawa (1915 - 1989) , ingénieur chimiste japonais, mis au point le (...)

Pilotage de projets : mensonges, omissions et approximations...

Si le processus de suivi de projet est un principe simple ne nécessitant (...)

QVT : Le Burnout ! c’est quoi ? Symptômes, diagnostic, test et solutions. Et vous, vous en êtes où ?

Définition

Utilisé pour la première fois en 1969, le terme « Burnout », ou (...)

Logiciels : Maitrise d’ouvrage / Editeur de logiciel - unis pour le meilleur et pour le pire ?

A l’attention des Maitres d’ouvrage… Vous venez de choisir l’éditeur de votre (...)

Gestion de projet : Les outils

Voici une liste non exhaustive de quelques logiciels de gestion de projets (...)

Site PL CONSEIL

Consultez le site PL CONSEIL - http://pl-conseil.net

Shopping...

— -



pucePlan du site puceContact

RSS Valid XHTML 1.0 Strict

2013-2018 © PL Conseil - Audit et accompagnement des entreprises - Tous droits réservés
Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.87.58