Conseils

Pourquoi un appel d'offres ERP prend-il si longtemps, et comment le raccourcir ?

Par Marc Adedjouma · Fondateur de We Make Smart · Lecture : 8 minutes

Réponse courte : un appel d'offres ERP classique dure quatre à sept mois dans le meilleur des cas, et dépasse souvent l'année dans une PME. Ce n'est pas la complexité du choix qui prend du temps, c'est la méthode : un dossier de consultation long à rédiger, une diffusion large qui produit des dizaines de réponses incomparables, puis des mois de dépouillement. On raccourcit ce délai non pas en allant plus vite à chaque étape, mais en supprimant celles qui ne produisent rien : un cahier des charges par cas d'usage démontrables, un préfiltre documenté du marché, et des démonstrations sur les cas réels de l'entreprise ramènent la sélection à une trentaine de jours, avec plus de transparence, pas moins.

Quand un dirigeant de PME lance un appel d'offres pour choisir son ERP, il le fait souvent parce que c'est le modèle qu'il connaît : on écrit un cahier des charges, on le diffuse, on compare les réponses. C'est rassurant parce que ça ressemble à un processus rigoureux. Le problème, c'est que ce processus a été conçu pour les marchés publics et les grandes entreprises, où le temps et les équipes dédiées existent. Transposé à une PME, il produit l'inverse de ce qu'il promet.

Combien de temps dure réellement un appel d'offres ERP ?

Quatre à sept mois quand tout se passe bien, huit à douze mois dans la réalité d'une PME où les gens ont un vrai métier à côté. Le délai se décompose en cinq phases dont aucune ne peut être sautée dans ce modèle.

La rédaction du dossier de consultation prend quatre à huit semaines, souvent avec l'aide d'un cabinet, parce qu'il faut décrire l'entreprise, ses processus et ses attentes dans un format que des éditeurs qui ne la connaissent pas pourront exploiter. La diffusion et le délai de réponse ajoutent quatre à six semaines : les éditeurs posent des questions, demandent des précisions, réclament des extensions. Le dépouillement des réponses, quand il y en a vingt ou trente, occupe deux à quatre semaines de lecture et de grilles de notation. Les soutenances et démonstrations des finalistes se calent sur les agendas de chacun, trois à six semaines. Et la négociation finale avec contractualisation prend encore deux à quatre semaines.

Le total est connu de tous ceux qui ont vécu l'exercice. Ce qui l'est moins, c'est que chaque glissement se cumule : un éditeur qui demande une semaine de plus, une équipe projet absorbée par un pic d'activité, un comité de direction qui ne trouve pas de créneau, et le projet passe de six mois à dix sans que personne n'ait mal fait son travail.

Pourquoi le dépouillement est-il la phase la plus longue et la moins utile ?

Parce que les réponses reçues ne répondent pas à la même question. Chaque éditeur reformule le besoin dans les termes de son produit, ce qui rend les propositions incomparables, et le temps de dépouillement sert à reconstruire une base commune qui aurait dû exister dès le départ.

C'est le paradoxe central de l'appel d'offres large. Plus il y a de réponses, plus le processus semble rigoureux, et moins il l'est en réalité. Vingt propositions avec vingt périmètres différents, vingt modèles de prix, vingt façons de présenter les mêmes fonctionnalités, ce n'est pas de la transparence, c'est du bruit. L'équipe qui dépouille passe des semaines à normaliser ce qui ne l'est pas, à relancer les éditeurs pour clarifier, à construire des grilles qui finissent par comparer des estimations vagues à d'autres estimations vagues.

Et au bout de ce travail, le dirigeant se retrouve souvent dans la situation qu'il voulait éviter : choisir par lassitude, parce que le processus a épuisé tout le monde et qu'il faut conclure. C'est le cycle que décrit notre article sur pourquoi les PME mettent six mois à ne pas choisir leur ERP : la longueur du processus produit la mauvaise décision qu'il était censé empêcher.

Un appel d'offres large garantit-il plus de transparence ?

Non. Il garantit plus de réponses, ce qui n'est pas la même chose. La transparence d'une sélection ne se mesure pas au nombre de propositions reçues mais à la comparabilité des réponses et à la traçabilité des décisions. Trois solutions testées sur les mêmes cas réels valent plus que cinquante propositions écrites chacune dans son propre langage.

C'est l'objection la plus fréquente quand on propose une méthode plus courte : « mais comment être sûr qu'on n'a rien raté ? ». La réponse tient en deux points. D'abord, un préfiltre documenté examine bien l'ensemble du marché, mais il le fait en amont, sur des critères objectifs (taille de clients, secteur, périmètre fonctionnel, modèle de prix, intégrations disponibles) et il produit une liste écrite des solutions examinées avec le motif de chaque écart. Le dirigeant voit tout ce qui a été regardé et pourquoi chaque candidat a été retenu ou écarté. Ce n'est pas moins de visibilité qu'un appel d'offres, c'est plus : dans l'appel d'offres, il ne voit que ceux qui ont répondu, et il ne sait rien de ceux qui n'ont pas répondu ni de ceux qui n'ont pas été sollicités.

Ensuite, la preuve ne vient pas de la réponse écrite mais de la démonstration. Un éditeur qui répond à un appel d'offres par écrit peut tout promettre. Un éditeur qui fait une démonstration sur les cas d'usage réels de l'entreprise ne peut pas mentir : soit il montre que l'outil fait ce qui est demandé, soit il ne le montre pas. Trois démonstrations sur les mêmes scénarios, c'est une comparaison. Trente réponses écrites, c'est une pile.

Comment ramener la sélection d'un ERP à un mois ?

En remplaçant les trois phases les plus longues par leurs équivalents plus courts et plus précis : le dossier de consultation par un cahier des charges en cas d'usage démontrables, la diffusion large par un préfiltre documenté du marché, et le dépouillement par des démonstrations sur les cas réels. Le travail de comparaison se fait en amont, dans la rédaction du besoin, au lieu d'en aval, dans la lecture des réponses.

Le cahier des charges d'abord. Au lieu d'un document de quarante pages qui décrit l'entreprise et ses attentes en prose, on rédige des cas d'usage : « montrez-moi qu'un commercial peut établir un devis conforme aux tarifs sans ressaisir les données du client ». Chaque ligne est une épreuve que l'éditeur devra passer en démonstration. Cette précision fait deux choses : elle rend les réponses comparables par construction, et elle permet aux éditeurs de s'engager au forfait parce qu'ils savent exactement ce qui leur est demandé. La méthode de rédaction est détaillée dans notre article sur le cahier des charges ERP.

Le préfiltre ensuite. Un cabinet indépendant qui suit le marché en permanence dispose d'une base documentée des solutions existantes. Appliquer les critères du cahier des charges à cette base élimine en quelques jours ce qu'un appel d'offres mettrait des mois à découvrir : les solutions hors gabarit, hors secteur, hors budget. Ce qui reste, c'est une présélection justifiée, et le rapport montre combien de solutions ont été examinées et pourquoi chacune a été retenue ou écartée.

Les démonstrations enfin. Trois finalistes, chacun confronté aux mêmes cas d'usage, sur les données de l'entreprise. Pas le scénario de vente de l'éditeur, mais le scénario de travail du client. C'est là que se fait la vraie comparaison, et elle tient en deux ou trois semaines selon les agendas.

Une trentaine de jours entre le lancement du cadrage et la décision documentée, contre quatre à sept mois. Et un second gain, moins visible mais plus coûteux : parce que la sélection part des cas d'usage réels, elle oriente vers des outils qui couvrent le métier en standard, à 80 ou 85 %, plutôt que vers l'outil le plus vendeur qui demandera ensuite des développements spécifiques. Moins de spécifiques, c'est un déploiement plus court, moins d'avenants, et un outil qui suit les mises à jour de l'éditeur au lieu de casser à chaque version.

Dans quels cas un appel d'offres classique reste-t-il pertinent ?

Quand la réglementation l'impose (marchés publics, certaines structures parapubliques), ou quand l'organisation dispose d'une équipe projet dédiée et du temps nécessaire. Pour une PME dont les équipes ont un métier à côté et dont le calendrier est contraint par un événement (croissance, réorganisation, nouvelle activité), le coût en temps de l'appel d'offres large dépasse presque toujours son bénéfice en exhaustivité.

La question à se poser n'est pas « quelle méthode est la plus rigoureuse en théorie » mais « quelle méthode produit la bonne décision dans le temps dont je dispose ». Une entreprise qui doit avoir son outil opérationnel avant un événement daté n'a pas sept mois de sélection suivis de neuf mois de déploiement. Elle a besoin de choisir vite et bien, puis de déployer un outil qui ne demande pas un an de développements. La méthode courte n'est pas un raccourci, c'est l'adaptation de la rigueur à la réalité d'une PME.