Ne demandez jamais à un cabinet de conseil de choisir votre GRC.

Je vais commencer par un conseil assez étrange venant de quelqu’un dont c’est notamment le métier : ne demandez jamais à un cabinet de conseil de choisir votre prochain outil de GRC.

Ou, plus exactement, ne lui achetez pas ce que les cabinets savent si bien produire : une magnifique grille de dépouillement.

Vous connaissez probablement l’exercice.

On commence avec quelques besoins assez simples. Gérer les risques. Documenter les contrôles. Piloter les plans d’action. Organiser les campagnes. Préparer les missions d’audit. Consolider le reporting.

Puis arrive le consultant.

Quelques semaines plus tard, votre besoin s’est transformé en un classeur comportant 247 lignes, parfois 300. Chaque fonctionnalité est décrite, pondérée, notée. Les éditeurs remplissent les cases. On organise les démonstrations. On additionne les scores.

Et à la fin, une plateforme obtient 87,4 %, une autre 84,7 %.

La première est donc, scientifiquement, votre meilleure GRC.

Évidemment, c’est absurde.

Le prix au kilo de features

Le problème n’est pas que ces grilles soient mal faites.

Au contraire : elles peuvent être remarquablement bien faites.

Le problème est qu'elles donnent une apparence d'objectivité à une décision qui repose en grande partie sur autre chose.

Pour justifier plusieurs dizaines de milliers d’euros d’honoraires, le conseil a par ailleurs une tentation naturelle : enrichir la question.

Il connaît des fonctionnalités auxquelles vous n’aviez pas pensé. Il connaît les pratiques observées ailleurs. Il possède déjà des questionnaires extrêmement complets issus de missions précédentes.

Tout cela semble être une excellente nouvelle.

Jusqu’au moment où le projet devient une course aux fonctionnalités.

Une fonction dont personne n’avait exprimé le besoin devient soudain un critère. Puis elle est pondérée. Puis les éditeurs sont interrogés dessus. Puis elle contribue au score final.

Nous finissons par mesurer avec une précision remarquable des choses dont l’entreprise n’avait peut-être pas besoin.

Les bonnes GRC savent à peu près toutes faire de la GRC

Il faut accepter une réalité assez peu favorable aux appels d’offres interminables : les grandes plateformes GRC sérieuses couvrent aujourd’hui une très grande partie des besoins fondamentaux.

Audit interne, risques, contrôle interne, conformité, plans d’action, workflows, campagnes, reporting, référentiels : les philosophies diffèrent, les ergonomies diffèrent, les architectures diffèrent, mais nous ne sommes plus face à des produits dont l’un saurait gérer un risque et l’autre non.

Bien sûr, certaines fonctions peuvent être réellement discriminantes. Une exigence réglementaire particulière, une architecture technique, une volumétrie, un besoin d'intégration ou un cas métier très spécifique peuvent éliminer un candidat.

Il faut les identifier.

Mais une fois ces critères réellement discriminants traités, continuer à empiler les fonctionnalités n’améliore plus nécessairement la décision.

Cela peut même la dégrader.

Parce qu'on cesse progressivement de choisir la plateforme qui correspond à l'entreprise pour choisir celle qui obtient le meilleur prix au kilo de features.

Votre premier critère n'est probablement pas dans le RFP

Pour moi, le premier critère de choix d'une GRC est pourtant ailleurs :

la culture de l'entreprise.

Et c'est un critère difficile à mettre dans une cellule Excel.

Comment les décisions sont-elles prises ? Quelle est l'autonomie des métiers ? Quelle est la maturité des fonctions de contrôle ? Les utilisateurs acceptent-ils des processus fortement structurés ? Les référentiels sont-ils déjà partagés ? Les trois lignes de défense travaillent-elles réellement ensemble ? Jusqu'où peut-on imposer une méthode commune ?

Ces questions sont infiniment plus importantes qu'une comparaison entre deux moteurs de workflow.

Car les logiciels changent vite.

Les humains, beaucoup moins.

Et vouloir tirer un changement culturel majeur par la technologie reste l'une des meilleures façons de fabriquer un projet difficile.

Une plateforme extraordinairement sophistiquée ne rendra pas spontanément une organisation mature. Elle peut au contraire matérialiser dans l'outil une organisation théorique que personne ne fera réellement vivre.

Avant la cible, regardez le point de départ

C'est pourquoi je commencerais tout projet de sélection d'une GRC non par un benchmark des solutions, mais par un diagnostic de maturité.

Pas un diagnostic destiné à distribuer des bons et des mauvais points.

Un diagnostic destiné à répondre à trois questions très concrètes :

• Où sommes-nous réellement aujourd'hui ?

• Où pouvons-nous raisonnablement être un an après le go-live ?

• Et où voulons-nous pouvoir être dans cinq ans, lorsque le choix technologique pourra lui-même être remis en question ?

Entre ces trois points apparaît quelque chose de beaucoup plus utile qu'une grille de 300 fonctionnalités :

une trajectoire.

Et cette trajectoire permet ensuite de regarder les logiciels autrement.

Certaines fonctionnalités deviennent indispensables immédiatement. D'autres devront pouvoir être activées demain. Certaines sont séduisantes mais inutiles. D'autres encore supposent un niveau de maturité que l'organisation n'aura vraisemblablement jamais intérêt à atteindre.

La roadmap fonctionnelle cesse alors d'être celle de l'éditeur.

Elle devient celle de l'entreprise.

Sept démonstrations. Trois finalistes. Pas trois cents critères.

Cela ne signifie évidemment pas qu'il faille choisir sa GRC au hasard.

Ma méthode serait même assez structurée.

D'abord, les besoins.

Les vrais. Ceux qui correspondent aux pratiques, irritants et ambitions de l'organisation, pas ceux récupérés dans le cahier des charges du voisin.

Ensuite, un marché suffisamment ouvert pour ne pas décider trop tôt : jusqu'à sept démonstrations me paraît raisonnable pour comprendre les philosophies des différentes solutions.

Puis trois finalistes.

Et seulement à ce moment-là, une grille de décision.

Mais une grille courte, priorisée et directement rattachée aux besoins identifiés.

À ce stade, j'assume également un mot qui met généralement les méthodologues mal à l'aise :

le feeling compte. Beaucoup.

Pas le coup de cœur pour un commercial ou une belle démonstration.

Le feeling des futurs utilisateurs face au produit.

Est-ce qu'ils comprennent sa logique ? Se projettent-ils dedans ? Ont-ils envie de l'utiliser ? L'équipe qui administrera la plateforme semble-t-elle pouvoir se l'approprier ? La philosophie du produit ressemble-t-elle à celle de l'organisation ?

Ce ne sont pas des critères irrationnels.

Pour un logiciel dont la valeur dépend directement de son adoption, ils sont au contraire extrêmement rationnels.

Alors, à quoi sert le consultant ?

À beaucoup de choses.

Mais pas à vous annoncer que la solution A obtient 87,4 % contre 84,7 % pour la solution B.

Achetez-lui un diagnostic de maturité.

Demandez-lui de challenger vos besoins. De vous empêcher de reproduire dans un logiciel quinze années de sédimentation méthodologique. De distinguer ce qui est indispensable de ce qui est simplement séduisant. De confronter vos ambitions à votre capacité réelle de transformation.

Demandez-lui de connaître le marché, évidemment. De vous montrer plusieurs chemins possibles. De vous signaler les impasses. De vous aider à comprendre ce que chaque choix implique.

Puis choisissez.

Nous implémentons nous-mêmes plusieurs plateformes GRC. Et certains de mes meilleurs projets ne sont pas ceux où nous avons démontré à un client qu'une solution était « la meilleure ».

Ce sont ceux où nous avons pu lui présenter les choix qui correspondaient réellement à sa situation, avec leurs conséquences.

Le client savait d'où il partait.

Il savait où il voulait aller.

Il savait ce qu'il pouvait raisonnablement changer.

Et c'est lui qui a choisi.

C'est probablement ainsi que cela devrait toujours se passer.