Ce texte s'adresse aux directions et aux personnes qui engagent leur signature sur l'achat d'un système : le secrétaire et le trésorier (skarbnik) en mairie, le président d'une société municipale (spółka komunalna), le directeur financier, le chef d'entreprise. Il s'adresse aussi au responsable informatique qui prépare une procédure ou un appel d'offres et veut savoir à quoi la direction doit prêter attention avant de valider les documents.
Pourquoi ce problème survient-il
La plupart des problèmes avec les prestataires trouvent leur origine du côté du donneur d'ordre, et ce bien avant la signature. Non par mauvaise volonté : préparer un appel d'offres est un travail pour lequel l'organisation manque souvent de temps et de compétences, et les prestataires sont ravis de faciliter la tâche. Ils apportent des descriptions toutes prêtes, des démonstrations et des devis. Résultat : le donneur d'ordre achète ce que le prestataire sait vendre, et non ce dont il a besoin. Autre difficulté : très souvent, les décisions d'achat restent entre les mains des directions métiers, l'informatique ne jouant qu'un rôle de gardien de la sécurité. L'absence de standards et de stratégie informatique à long terme fait que l'organisation réalise des achats qui ne s'inscrivent pas toujours dans le cadre censé atténuer les risques.
Je retrouve les mêmes erreurs dans les administrations et dans les entreprises. Seule la procédure d'achat diffère, pas le mécanisme.
Douze erreurs
- Des exigences rédigées à partir de l'offre ou de la présentation d'un seul prestataire. Cela restreint la concurrence et installe une dépendance avant même d'avoir choisi le prestataire. J'en parle plus en détail dans l'article sur la dépendance au fournisseur (vendor lock-in) dans le cahier des charges (SWZ).
- L'absence de propriétaire métier (business owner). Le projet a formellement un chef de projet, mais personne disposant d'un mandat de la direction ne décide de la manière dont les processus doivent fonctionner.
- L'absence de critères de réception et de scénarios de test avant la signature. La réception se transforme en litige d'interprétation, au lieu d'être une vérification que le produit du projet répond aux critères de succès du déploiement.
- La méconnaissance de l'existant. Vous achetez un nouveau système sans savoir quels contrats, licences et fonctionnalités actuels font déjà double emploi avec lui.
- Les intégrations oubliées. Avec quels systèmes le nouveau système doit-il échanger des données, dans quels sens, quels systèmes sont maîtres, quelles données, via quels formats, et le prestataire en a-t-il connaissance, garantit-il de fournir les mécanismes nécessaires et d'assumer la responsabilité de leur bon fonctionnement dans la durée ?
- Une migration des données décrite en une seule phrase. Sans préciser quelles données, sur quelle période, qui les nettoie et qui vérifie le résultat.
- Des exigences formulées comme une liste de fonctionnalités plutôt que comme une description de processus. Tout prestataire répondra « oui » à une question sur une fonctionnalité. À la question de savoir comment il traitera votre cas concret, les réponses divergent.
- La comparaison du prix de départ plutôt que du coût total. La licence n'est qu'un début. La maintenance, les évolutions et les intégrations se paient pendant des années. J'explique ce mécanisme dans l'article sur le coût total de possession (TCO) et la grenouille qui bout.
- L'absence de règles de gestion des changements de périmètre. On ne sait pas qui signale un changement, qui l'évalue et qui le valide.
- Un contrat sans conditions de sortie. Aucune clause sur l'export des données, la documentation et le transfert de la maintenance à un autre prestataire. Aucun outil d'atténuation du risque.
- Un contrat de maintenance repris du modèle du prestataire. Les niveaux de service, les délais de réaction et le coût des évolutions sont alors fixés par une seule partie.
- Une décision repoussée jusqu'au dernier moment. Lorsque l'échéance légale ou la fin du support de l'ancien système approche, il ne reste plus de place pour comparer les offres ni pour négocier.
Les erreurs un à trois sont à l'origine des autres. Si vous les éliminez, la plupart des autres deviennent visibles dès la phase de préparation, et non plus pendant l'exécution.
Pour le conseil, le conseil de surveillance ou la maison mère, l'essentiel est de savoir si la décision de choix du prestataire s'appuie sur une justification documentée. Les douze points ci-dessus constituent aussi une liste de questions à poser avant que la direction ne valide les documents de l'appel d'offres.
Exemple tiré de la pratique
Un de nos clients a reçu du prestataire de son système ERP l'assurance que l'échange des données de contreparties avec le système de gestion du courrier (EZD, système de gestion électronique des documents / e-Doręczenia, e-Delivery polonais) en cours de déploiement ne poserait aucun problème. Or un système de gestion du courrier conserve généralement les données de toutes les contreparties, et pas seulement celles pour lesquelles un événement économique survient, c'est-à-dire qui deviennent clientes ou fournisseurs. Le cycle de vie des données d'une nouvelle contrepartie commence tout simplement, le plus souvent, bien avant la survenue de ces événements économiques.
En cours de déploiement, il s'est avéré que le coût d'adaptation de l'interface API pour l'échange bidirectionnel des données de contreparties, côté prestataire du système ERP, représentait 80 % de la valeur totale du projet de mise en place du circuit des documents de coûts, intégré avec le KSeF (système polonais de facturation électronique), l'OCR, le VIES, le GUS (office statistique polonais), et enfin avec l'export des données vers le système financier et comptable. Cette seule intégration, faute d'avoir été discutée en détail avec le prestataire dès le départ, a pratiquement doublé le coût du projet.
Quand un conseiller indépendant est-il nécessaire
Si vous disposez d'une équipe expérimentée ayant déjà préparé plusieurs appels d'offres similaires, cette liste vous servira de grille de contrôle. Un regard indépendant prend tout son sens lorsque l'appel d'offres est de grande ampleur pour l'organisation, lorsque les exigences ont été élaborées au contact d'un seul prestataire, lorsque la décision devra être défendue devant un organe de contrôle, un conseil ou une maison mère, ou lorsque personne, du côté du donneur d'ordre, ne connaît ces systèmes de l'intérieur.
Je peux relire les documents avant la publication de la procédure ou l'envoi de la consultation, préparer les exigences et les scénarios de test ou évaluer les offres déjà déposées. Dans les administrations, le point de départ est un peu différent ; je le décris sur la page destinée aux collectivités territoriales (JST).