Au fil des années, Lokad a acquis une certaine notoriété et nous avons eu le privilège de faire partie d’un nombre croissant de RFI (demande d’information), RFP (demande de proposition) et RFQ (demande de devis) liés à l’optimisation de la supply chain. Bien que je sois reconnaissant que Lokad soit considéré comme suffisamment “notable” pour être présélectionné dans ces initiatives - et régulièrement sélectionné également - je ne peux m’empêcher de contempler la folie pure et simple qui sous-tend ces processus.

Le désespéré, Gustave Courbet

J’ai longtemps été perplexe face aux pratiques bizarres qui prévalent dans le domaine des logiciels d’entreprise 1. Plus récemment, j’ai également proposé une approche que je crois fermement être supérieure à tous égards aux approches classiques 2. Cependant, aujourd’hui, je souhaite décortiquer certains éléments franchement bizarres (voire carrément insensés) des RFP que j’ai observés. En un mot, les RFP 3 sont l’action du scientisme. Une perspective, une attitude et un processus qui imitent, aux yeux du grand public, ce à quoi on s’attend d’une entreprise “scientifique”. Cependant, en pratique, les RFP sont aussi scientifiques ou rationnels qu’une séance de spiritisme.

Pour commencer, les listes de questions recueillies dans les RFP sont, sans exception, à la fois longues et dénuées de sens. Ces documents sont systématiquement le produit d’un comité qui tente de satisfaire tout le monde en énumérant toutes les questions auxquelles tout le monde pourrait penser. Pire encore, chaque fois que des experts sont sollicités - généralement des consultants - pour examiner ou améliorer la liste, le catalogue de questions est multiplié par un ordre de grandeur.

Alors que l’adage il n’y a pas de mauvaise question peut être un principe directeur valable pour une école primaire, il est carrément nuisible lorsqu’il s’agit d’une grande entreprise et de sa supply chain. Franchement, dans le monde réel, les mauvaises questions peuvent entraîner des coûts en temps perdu, en attention mal utilisée et en compromis coûteux faits pour ménager les sentiments. Il existe plusieurs catégories de telles questions 4, et dans ce qui suit, j’en identifierai sept des plus courantes et en exposerai les lacunes.

  • Les questions paresseuses. Exemple : La solution suit-elle les meilleures pratiques en matière de sécurité ? Ces questions ne font que perdre le temps de tout le monde. Aucun éditeur de logiciel d’entreprise, en pleine possession de ses moyens, ne répondra jamais négativement à une telle question.
  • Les questions stupides. Exemple : La solution gère-t-elle les MOQ (quantités minimales de commande) ? Ces questions ajoutent de la confusion. Gérer les MOQ est trivial ; c’est faire de l’optimisation quel que soit le MOQ qui est difficile.
  • Les questions “intelligentes”. Exemple : Comment la solution rationalise-t-elle les divergences de prévision par rapport au plan initial en cas de rupture de stock ? Je suppose que ces questions (apparemment précises, mais en réalité vagues) sont destinées à impressionner les collègues, mais elles ne font qu’ajouter une couche supplémentaire de confusion, bientôt aggravée par la réponse tout aussi fleurie de l’éditeur de logiciel.
  • Les questions tendancieuses. Exemple : La solution offre-t-elle la possibilité de gérer et d’ajuster les profils de saisonnalité ? Ces questions interfèrent avec la neutralité du processus et soulèvent des questions implicites supplémentaires. La question exemple sous-entend que la saisonnalité devrait être abordée par le biais de “profils” (pourquoi ?) et que les utilisateurs finaux devraient être impliqués (pourquoi ?).
  • Les questions ambiguës. Exemple : La solution permet-elle l’introduction de KPI (indicateurs clés de performance) ? Cette catégorie de questions aggrave les malentendus. Ce qui constitue un KPI est une question subjective ; l’éditeur et le client sont peu susceptibles de partager les mêmes sentiments à cet égard.
  • Les questions tangentes. Exemple : La solution peut-elle recalculer en temps réel ses suggestions de réapprovisionnement ? Ces interrogations servent à détourner l’attention des problèmes principaux. La notion de “temps réel”, dans le domaine des logiciels d’entreprise distribués, entraîne des discussions longues et trop techniques qui sont finalement sans importance si les chiffres de réapprovisionnement sont erronés dès le départ.
  • Les questions effrayantes. Exemple : La solution est-elle certifiée ISO/IEC 27001 ? De telles questions donnent du pouvoir aux mauvaises parties. Les certifications, dans les logiciels d’entreprise, donnent du pouvoir aux organismes de certification et à leur écosystème, sans apporter aucune valeur à l’entreprise cliente.

S’attendre à ce que le bon fournisseur puisse être choisi en posant les mauvaises questions n’a pas plus de sens que de s’attendre à ce qu’un calcul soit correct en utilisant des chiffres initiaux incorrects. Pourtant, c’est l’approche privilégiée par la plupart des grandes entreprises en matière de logiciels d’entreprise.

Pour aggraver les choses, de nombreux RFP (Request for Proposal) incluent une colonne “Conformité” - ou quelque chose du genre - à côté de la colonne “Réponse”, demandant au fournisseur de s’auto-diagnostiquer son degré de conformité à la question. L’idée qu’un produit logiciel puisse être “conforme” à une question est déconcertante. Cependant, en pratique, les questions des RFP sont tellement biaisées que la colonne “conformité” a un certain sens, bien que de manière bizarre et tordue.

Je tiens également à souligner que (presque?) tous les documents RFP reflètent, dans leur présentation même, un manque de soin assez brutal. Chaque paragraphe est truffé de fautes d’orthographe horribles. Il y a des questions en double et des numéros de question en double. La taille de la police passe de manière inélégante de 6 à 20 et des retours à la ligne anarchiques jonchent le document. En ce qui concerne les questions, c’est encore pire car les RFP sont généralement formatés sous forme de feuilles de calcul Microsoft Excel - réparties sur plusieurs onglets, notez bien, chacun ayant ses propres colonnes “Question” et “Réponse”, ainsi que quelques autres pour faire bonne mesure (comme l’exemple de “Conformité” mentionné ci-dessus). Le format de feuille de calcul n’a absolument aucun sens dans le contexte d’un RFP. L’expérience utilisateur - qu’il s’agisse d’écrire ou de lire un contenu de plusieurs paragraphes dans une cellule de feuille de calcul - est misérable ; d’autant plus lorsqu’il y a des centaines de questions, comme c’est généralement le cas.

Comme si cela ne suffisait pas, considérez que les outils d’e-procurement, fréquemment utilisés pour mener ces mascarades, ont été forgés dans le 9e cercle de l’enfer. Ces outils représentent les pires incarnations de logiciels d’entreprise, chacun d’entre eux étant pionnier dans la manière de faire baisser les attentes : design peu réactif, conception négligée, expérience utilisateur insensée et encombrés de listes de bogues non corrigés de la longueur de Tolkien. Grâce à l’utilisation de tels outils d’e-procurement, la folie bureaucratique est poussée à son paroxysme [^bureaucratie].

Il est naïf de penser que la forme est sans importance tant qu’il y a du fond. La forme d’un RFP, aussi atroce soit-elle, garantit que se plonger dans les questions, sans parler des réponses, est une perte de temps considérable. Par conséquent, les personnes qui devraient être à la tête du processus de sélection - des cadres tels que le directeur de la chaîne d’approvisionnement - se retirent et délèguent à des “experts”, tels que des responsables des achats ou des tiers. Les responsables des achats ont généralement peu d’idée de ce qui constitue une solution raisonnable pour leur propre entreprise. Pendant ce temps, les tiers, présentés comme des facilitateurs du RFP, sont incités à rendre l’entreprise aussi labyrinthique que possible.

Certains pourraient soutenir qu’un RFP est un moindre mal par rapport à la corruption pure et simple qui se produirait en son absence. En d’autres termes, les RFP, aussi défectueux soient-ils, restent l’option la plus sûre pour préserver l’intégrité de l’entreprise et de son processus de sélection. Cependant, c’est une affirmation assez extraordinaire et, par conséquent, elle nécessite des preuves extraordinaires. En effet, cela soulève des questions concernant le type de fraude que les RFP sont censés prévenir et, par conséquent, leur efficacité dans cette mission. Honnêtement, l’idée de canaliser un grand processus de sélection à travers une feuille de calcul tout aussi grande et désordonnée semble, à première vue, assez tirée par les cheveux. (Pardonnez mon scepticisme.)

Mes propres observations anecdotiques dans le monde des logiciels d’entreprise indiquent que de nombreux grands fournisseurs de logiciels récompensent généreusement les personnes qui occupaient autrefois des postes d’influence dans les RFP en les embauchant une décennie plus tard. L’antidote à cette (mauvaise) pratique est simple : identifier les fournisseurs qui jouent à ce jeu et les interdire purement et simplement 5. En réalité, les RFP ne font rien contre le type de corruption prévoyante qui existe dans le monde des logiciels d’entreprise.

Ainsi, mon analyse est la suivante : tout ce qui rend le processus de sélection des fournisseurs plus bureaucratique que strictement nécessaire le rend également plus vulnérable aux acteurs malveillants. Cette proposition peut être reformulée du point de vue de la sécurité informatique : la bureaucratie augmente la surface d’attaque du processus de sélection des fournisseurs, car elle répartit la confiance (et donc la vulnérabilité) sur des couches de personnes qui n’ont aucune raison d’être dignes de confiance en ce qui concerne ce processus.

Malgré tous ces problèmes, les RFP sont courants dans les logiciels d’entreprise. Pourtant, en privé, la plupart des gens - du moins ceux qui ne vivent pas des RFP - admettent que le processus n’a guère de sens, ce qui rend la prévalence des RFP d’autant plus déconcertante. La plus simple explication que je puisse avancer est que les RFP sont une forme élaborée de signalement de vertu d’entreprise 6. À l’ère des technologies de l’information, admettre qu’une décision majeure peut être prise sur la base de rien de plus qu’une supposition éclairée n’est pas acceptable et est perçu comme simpliste, peu sophistiqué et carrément non scientifique. Le processus de RFP peut ne rien apporter de valeur pour l’entreprise, mais il aborde parfaitement l’aspect du signalement de vertu.


  1. Guide d’achat de logiciels d’entreprise, Joannes Vermorel, août 2013. ↩︎

  2. Recherche de marché antagoniste pour les logiciels d’entreprise - Cours 2.4, mars 2021, Joannes Vermorel ↩︎

  3. Pour des raisons de concision, dans cette entrée, le terme “RFP” fait référence collectivement à RFI, RFP et RFQ. ↩︎

  4. Tous les exemples énumérés dans cette section sont de véritables questions de RFP que nous avons reçues au cours des 12 derniers mois. ↩︎

  5. LinkedIn facilite relativement l’identification des fournisseurs de logiciels qui embauchent des personnes qui étaient opportunément au bon endroit au bon moment. Cependant, le fait d’avoir toutes les informations pertinentes en affichage public rend cette forme de corruption encore plus astucieuse car elle ne nécessite même pas de communication explicite entre les parties ; simplement une compréhension tacite. ↩︎

  6. Un autre avantage incident des RFP pourrait également être la dilution de la responsabilité, car les RFP, par conception, impliquent un certain nombre de personnes du côté du client. ↩︎