Conduire un benchmark de solutions sans parti pris
Un benchmark de solutions sert souvent à justifier un choix déjà fait. Bien conduit, il fait l'inverse : il rend la décision explicable, y compris à ceux qui l'auraient prise autrement.

L’erreur la plus fréquente dans un benchmark de solutions ne se voit pas dans le rapport final. Elle a lieu avant : quelqu’un a déjà vu une démonstration convaincante, la grille d’évaluation est écrite ensuite, et elle épouse, souvent sans malice, les points forts de la solution préférée. Le document est soigné, les colonnes sont pleines, et la conclusion était connue d’avance.
Un benchmark de solutions sans parti pris ne repose pas sur la bonne volonté des évaluateurs. Il repose sur un ordre des opérations qui rend le biais difficile, et sur des traces écrites qui permettent de le détecter.
Pourquoi l’ordre des étapes compte plus que la grille
Tout évaluateur arrive avec des préférences : un outil qu’il connaît, un éditeur avec qui il a déjà travaillé, une technologie qu’il juge moderne. Le problème n’est pas d’en avoir, mais de les laisser définir les règles du jeu. La parade est simple dans son principe : tout ce qui sert à juger (le besoin, les critères, leur poids, les seuils éliminatoires) est écrit et validé avant le premier contact avec un éditeur.
Cette discipline a un deuxième avantage. Elle oblige les métiers, la direction informatique, les achats et la conformité à se mettre d’accord sur ce qui compte, au moment où cet accord est encore possible. Après les démonstrations, chacun défend sa solution.
La méthode en sept étapes
- Formuler la décision à prendre. Pas « choisir un outil de gestion documentaire », mais « permettre au service juridique de retrouver un contrat et son historique en quelques minutes, sur dix ans d’archives ». Une décision précise produit des critères précis.
- Décrire les cas d’usage réels. Cinq à dix situations concrètes, tirées du quotidien des équipes, avec leurs volumes et leurs contraintes. Ce sont elles qui serviront de banc d’essai.
- Écrire les critères et les seuils éliminatoires. Séparer ce qui est indispensable (hébergement dans une juridiction donnée, conformité à une norme, compatibilité avec un système existant) de ce qui se compare. Un critère éliminatoire non satisfait arrête l’évaluation, sans compensation possible.
- Fixer la pondération et la faire valider. Le poids de chaque critère est arrêté, daté et signé par le comité de décision avant l’examen des solutions. Le modifier ensuite doit rester possible, mais justifié par écrit.
- Déclarer les intérêts. Chaque évaluateur, interne ou externe, indique ses liens avec les éditeurs en lice : contrat, partenariat, ancien employeur, revente. Une déclaration n’exclut pas forcément ; elle permet d’en tenir compte.
- Évaluer sur les cas, pas sur les démonstrations. Chaque éditeur traite les mêmes scénarios, si possible sur un jeu de données représentatif fourni par vous. Les réponses sont notées par au moins deux évaluateurs, séparément, puis confrontées.
- Restituer les écarts, pas seulement le classement. Le rapport montre où chaque solution excelle et où elle échoue, les points de désaccord entre évaluateurs et les risques résiduels. Un classement seul ne permet pas de décider en connaissance de cause.
La démonstration préparée par l’éditeur montre ce que la solution fait de mieux, sur des données faites pour elle. Elle informe, elle ne prouve rien. Une évaluation qui s’en contente mesure surtout le talent de l’avant-vente.
Construire une grille qui résiste à la contestation
Une bonne grille ne cherche pas l’exhaustivité. Elle couvre quelques familles de critères, chacune décomposée en questions vérifiables. L’exemple ci-dessous est une structure de départ, à adapter ; les poids sont illustratifs et dépendent entièrement de votre contexte.
| Famille | Questions vérifiables | Comment le vérifier | Poids illustratif |
|---|---|---|---|
| Couverture fonctionnelle | Chaque cas d’usage est-il traité sans développement spécifique ? | Essai sur vos scénarios | 30 % |
| Intégration | Quels échanges avec vos systèmes existants, par quels moyens documentés ? | Documentation technique, essai de connexion | 20 % |
| Sécurité et conformité | Hébergement, chiffrement, journalisation, conformité aux textes qui vous concernent | Pièces justificatives, questionnaire signé | 20 % |
| Réversibilité | Peut-on récupérer toutes ses données, dans un format ouvert, à quel coût ? | Clauses contractuelles, test d’export | 15 % |
| Pérennité et support | Feuille de route, organisation du support, présence dans votre région | Entretiens, références vérifiables | 15 % |
Trois règles rendent la notation défendable. Chaque note est accompagnée d’une justification d’une ou deux phrases, qui renvoie à une preuve. L’échelle est courte (de 0 à 3, par exemple) et chaque niveau est défini par écrit : « 3 : le cas est traité sans paramétrage particulier ». Enfin, les écarts de notation entre évaluateurs sont discutés, pas moyennés en silence : un écart important signale souvent une question mal posée ou une information manquante.
Le prix, à part et sur la durée
Intégrer le prix comme un critère parmi d’autres produit un effet pervers : une solution médiocre mais bon marché peut l’emporter sur une solution adaptée. Mieux vaut l’évaluer en second temps, sur les seules solutions qui franchissent le seuil de qualité, et en coût complet : licences ou abonnements, intégration, migration des données existantes, formation, exploitation sur la durée du contrat, et coût de sortie. Ce dernier poste, rarement chiffré, est souvent celui qui crée la dépendance.
Quand le benchmark sert un appel d’offres public
Pour un acheteur public, la méthode a une conséquence juridique : les critères d’attribution et leur pondération doivent être annoncés aux candidats dans les documents de la consultation, et appliqués tels quels. Un benchmark préalable bien mené produit donc directement la matière du règlement de consultation. À l’inverse, un benchmark biaisé expose l’acheteur à un recours d’un candidat écarté. La neutralité n’est pas ici une vertu morale, mais une condition de sécurité de la procédure.
La même logique vaut pour les bailleurs internationaux, dont les règles de passation exigent généralement une évaluation documentée et traçable.
Avant de lancer le vôtre
Une question suffit pour tester la solidité d’un benchmark : un évaluateur qui préférait une autre solution pourrait-il, en lisant le dossier, comprendre pourquoi elle n’a pas été retenue, et reconnaître que les règles étaient les mêmes pour tous ? Si oui, la décision est défendable. Si non, il manque une trace quelque part.
Notre expertise benchmark et appels d’offres applique cette méthode, y compris quand nos propres produits pourraient figurer parmi les solutions comparées : ce cas est alors déclaré d’emblée. Pour conserver la preuve des arbitrages (qui a fixé la pondération, quand, sur quelle base), notre produit Gouvernance sert précisément à cela.
Questions fréquentes
Combien de solutions faut-il comparer ?
Assez pour que le marché soit représenté, pas plus que ce que l'équipe peut évaluer sérieusement. En pratique, une présélection large sur dossier, puis trois à cinq solutions évaluées en profondeur sur vos cas d'usage.
Peut-on confier le benchmark à un prestataire qui vend aussi des solutions ?
Oui, à condition qu'il le déclare d'emblée, que la grille soit fixée par vous avant son intervention et que ses propres produits soient évalués avec les mêmes critères. À défaut, l'indépendance ne peut pas être démontrée.
Que faire si aucune solution ne satisfait les critères éliminatoires ?
C'est un résultat, pas un échec. Il faut alors revoir le besoin (un critère était-il réellement éliminatoire ?), envisager un développement spécifique ou différer le projet. Abaisser un critère après coup pour faire passer une solution ruine la crédibilité de tout l'exercice.
Faut-il intégrer le prix dans la grille ?
Oui, mais à part : on évalue d'abord la qualité, puis on rapporte le coût complet sur la durée (licences, intégration, exploitation, sortie) aux solutions qui ont franchi le seuil de qualité.
À lire ensuite
Tout guides de décision
ComparatifsForfait, régie, centre de services : comparer les modèles de contrats ITLe choix entre forfait, régie et centre de services est souvent dicté par l'habitude ou par les achats. Il devrait… · 6 min
ComparatifsLicences logicielles : abonnement, perpétuelle, à l’usageLe choix d'un modèle de licence engage un budget pour des années, et parfois davantage : la capacité à changer de… · 7 min
TerrainUn benchmark de GED raconté : critères et décisionTrois démonstrations impeccables, une commission incapable de les départager. Ce scénario type suit un benchmark GED de bout en bout,… · 5 min