Une démonstration de logiciel de risques cyber convainc facilement lorsqu’elle montre un tableau de bord déjà rempli. Elle aide beaucoup moins à décider si votre équipe saura qualifier un scénario contesté, conserver une hypothèse incertaine et faire accepter un risque par la bonne personne. Demandez au fournisseur de partir de trois situations que vous apportez. Observez le trajet entre les faits, l’analyse, la décision et le suivi plutôt que le seul aspect du graphique final.
Ce guide propose un script de démonstration et une grille de recette. Le logiciel de gestion de PSSI traite le pilotage de la politique, tandis que le logiciel de conformité multi-référentiels compare des architectures d’outillage. Ici, l’objet est plus étroit : un outil permet-il de tenir une décision de risque cyber quand les données et les responsables changent ? Le NIST SP 1303 décrit l’intégration de l’information sur les risques cyber à la gestion des risques de l’entreprise. Il inspire cette méthode ; il n’impose pas un logiciel ni une formule de score en droit français.
Fixer la décision que la démonstration doit rendre possible
Avant d’inviter des éditeurs, écrivez la décision attendue. Par exemple : financer une deuxième voie d’authentification, accepter temporairement un délai de restauration, ou réduire l’accès d’un prestataire. Identifiez qui propose, qui possède le service, qui évalue le risque, qui accepte le risque résiduel et qui vérifie l’action. Sans ces rôles, un outil peut produire une liste de « risques élevés » qui ne déclenche rien.
Délimitez le périmètre : une entité, deux services, un fournisseur, quelques actifs et une période. Un projet pilote n’a pas besoin d’importer tout le registre d’entreprise. Il doit conserver assez de relations pour révéler un défaut de modèle. Un risque appartient-il à l’application, au service métier, à l’entité juridique ou à leur combinaison ? La réponse change la personne appelée à agir. Le guide de cartographie SI aide à préparer ces liens avant la réunion.
Préparez une fiche d’observation partagée. Une personne conduit le scénario ; une autre note les clics, les décisions impossibles, les contournements et les questions ouvertes. Les réponses commerciales orales sont utiles, mais la recette porte sur ce qui est visible dans l’environnement testé et inclus dans l’offre envisagée. Une fonction annoncée pour une future version reste une hypothèse contractuelle, pas un résultat acquis.
Constituer trois scénarios différents
Le premier scénario concerne un accès administrateur conservé après la fin d’une mission. Il teste la découverte de l’actif, le lien avec le fournisseur, le propriétaire du risque, la mesure immédiate et l’exception si la suppression menace une opération. L’audit des droits privilégiés donne une base de preuve concrète ; la démonstration doit pouvoir y rattacher la décision sans absorber tous les journaux.
Le deuxième scénario porte sur la restauration. Les sauvegardes réussissent dans le tableau de bord, mais le dernier essai n’a pas pu rétablir un service dans son délai métier. Il faut représenter l’écart entre une preuve technique rassurante et une capacité opérationnelle insuffisante. Le plan de continuité peut fixer les objectifs de service ; l’outil de risque doit enregistrer la source, la limite de l’essai et les options de traitement.
Le troisième scénario introduit une dépendance externe : un fournisseur d’identité dessert deux entités, dont une activité critique. Une panne affecte un service plus gravement que l’autre. Testez si l’outil accepte deux évaluations du même fournisseur sans écraser leurs conséquences distinctes. Le NIST Cybersecurity Framework 2.0 fournit un vocabulaire de résultats de sécurité ; il ne donne pas la note à attribuer à ce fournisseur.
Fournir des données imparfaites mais maîtrisées
Utilisez des données fictives avec des incohérences réalistes : application renommée, rapport de test ancien, propriétaire ayant changé d’équipe, échéance contractuelle différente de l’échéance technique. Une démonstration uniquement alimentée par des fiches parfaites teste la capacité de saisie, pas la capacité de décider. L’équipe doit savoir ce qu’elle veut voir : contrôle des doublons, provenance, gestion des inconnues et demande de validation.
Ne remettez pas de secrets, d’adresses internes sensibles ou de données personnelles réelles pour obtenir une meilleure démo. Si un essai sur données réelles est indispensable, cadrez séparément le traitement, les accès, la conservation et la sortie. Le script peut fonctionner avec des identifiants factices et des extraits de preuves expurgés. La vraisemblance du scénario réside dans les relations, non dans l’exposition de votre SI.
Demandez à l’éditeur de décrire les prérequis de préparation. Une démonstration exigeant plusieurs jours de paramétrage sur mesure n’est pas nécessairement mauvaise ; elle doit simplement être évaluée avec son coût, ses compétences et les droits nécessaires. Notez ce qui fonctionne immédiatement, ce qui relève d’une configuration standard et ce qui demande une prestation spécifique.
Script de recette utilisable pendant la réunion
| Étape | Action demandée | Résultat observé |
|---|---|---|
| Créer | Décrire le service, l’événement et la conséquence | Scénario intelligible sans score forcé |
| Relier | Associer actifs, fournisseur, preuve et propriétaire | Relations visibles et modifiables |
| Qualifier | Renseigner probabilité, impact et incertitude | Hypothèses séparées des faits établis |
| Décider | Comparer réduire, transférer, éviter, accepter | Justification et autorité conservées |
| Agir | Attribuer mesure, échéance, dépendance | Retard et blocage visibles |
| Changer | Remplacer une hypothèse ou un propriétaire | Historique et réévaluation explicables |
| Vérifier | Ajouter résultat d’essai et risque restant | Fermeture distincte de l’action déclarée |
| Sortir | Exporter puis retrouver la décision | Données, liens et pièces réutilisables |
La grille n’est pas un classement universel de fournisseurs. Elle sert à observer la capacité d’une offre dans votre contexte. Fixez avant la démonstration quels résultats sont indispensables, souhaitables ou secondaires. Un joli tableau de bord ne doit pas compenser l’impossibilité de reconstituer une acceptation de risque, si c’est précisément la décision que le comité doit défendre.
Tester la formulation du scénario avant son calcul
Une fiche intitulée « risque phishing » ne relie ni cause, ni événement, ni conséquence. Demandez à l’outil de représenter : « un prestataire conserve un droit administrateur après la fin de mission ; son compte est compromis ; une sauvegarde peut être supprimée ; le service ne peut plus reprendre dans le délai prévu ». Les contrôles existants et leur efficacité sont alors discutables. La description doit rester lisible par le propriétaire métier sans effacer les éléments techniques.
Observez si le produit force l’utilisateur à choisir une menace ou une valeur avant de pouvoir enregistrer une incertitude. Une hypothèse non confirmée devrait pouvoir être marquée comme telle, avec sa source et une tâche de vérification. Faire semblant de connaître une probabilité « 4 sur 5 » permet de produire un graphique, mais pas une décision honnête. Pour les conséquences, demandez comment sont séparés arrêt du service, perte de données, impact contractuel et effet sur les personnes.
La méthode EBIOS Risk Manager peut convenir à certains ateliers structurés. Vérifiez la méthode réellement utilisée par votre organisation avant d’acheter une interface qui impose une taxonomie incompatible. Le logiciel doit soutenir le raisonnement et conserver les arbitrages, pas obliger toutes les équipes à adopter son score par défaut.
Faire jouer la décision à ses vrais acteurs
Au cours de la démonstration, demandez au propriétaire du service de proposer une mesure, au RSSI d’en examiner l’effet et à un décideur habilité d’accepter ou de refuser le risque restant. Si la même personne clique sur tous les boutons, on ne teste pas la séparation des responsabilités. Observez les permissions, les notifications et ce que le destinataire voit sans formation préalable.
Une acceptation devrait indiquer le périmètre, les faits retenus, l’incertitude, les mesures en vigueur, la durée et la condition de réexamen. L’existence d’un bouton « accepter » ne garantit pas cette qualité. Demandez ce qui se passe si l’auteur de la fiche quitte l’entreprise, si le propriétaire change ou si le service devient plus critique. La décision précédente doit rester compréhensible, sans devenir automatiquement valide pour le nouveau contexte.
Le cahier des charges GRC centré sur les preuves fournit un cadre d’achat plus large. Ce script peut en devenir la partie « gestion des risques », avec des critères de recette vérifiables plutôt qu’une liste de fonctions déclaratives.
Noter les incertitudes sans en faire des zéros
Une donnée inconnue ne signifie ni risque nul ni pire cas certain. Testez trois situations : fréquence d’incident inconnue, preuve de restauration périmée, sous-traitant secondaire non confirmé. L’outil devrait permettre d’identifier la question, la personne chargée de répondre et le moment où la décision doit être revue. S’il convertit systématiquement « inconnu » en valeur numérique silencieuse, demandez comment retrouver l’hypothèse et la contester.
Pour un risque critique, une décision provisoire peut être nécessaire avant que toutes les données soient disponibles. Elle peut contenir une mesure conservatoire, une limite de temps et un responsable de collecte. Le logiciel doit montrer cette situation distinctement d’une acceptation définitive. Une couleur rouge permanente sans action attribuée est peu utile ; une couleur verte issue d’un champ vide est dangereuse.
L’approche du NIST SP 1303 aide à relier les informations cyber à des arbitrages plus larges de l’entreprise. Elle invite à communiquer le risque dans un langage de décision ; elle ne garantit pas qu’une matrice « impact × probabilité » capture à elle seule toutes les dépendances.
Vérifier que les contrôles changent réellement l’analyse
Ajoutez au scénario un contrôle compensatoire, par exemple la suppression du privilège permanent et l’activation sur demande. L’outil doit montrer quel facteur est réduit et sur quelle preuve il s’appuie. Un simple changement de score sans lien avec une action, une date et un résultat vérifié ne démontre pas que le risque a diminué. La distinction objectif, activité et preuve aide à préparer ce test.
Faites échouer le contrôle : l’essai de restauration révèle une clé indisponible, ou la revue des comptes découvre un deuxième accès. Observez si la décision d’acceptation est signalée comme potentiellement caduque et qui reçoit l’alerte. La réponse peut être manuelle ; elle doit être assignable et traçable. Une automatisation spectaculaire, mais impossible à vérifier sur un cas concret, ne vaut pas nécessairement mieux qu’un circuit simple bien tenu.
Comparer des offres avec des critères pondérés
Une pondération n’est utile que si elle reflète vos contraintes. Dans un exemple fictif, l’équipe retient cinq critères : fidélité du scénario, gouvernance des décisions, gestion des incertitudes, preuve des actions et réversibilité. Elle donne plus de poids à la gouvernance parce que plusieurs entités partagent les mêmes fournisseurs ; une autre organisation choisirait différemment. Fixez les poids avant de voir les résultats pour éviter de justifier après coup l’offre favorite.
Attribuez une note à chaque critère sur une observation, accompagnée d’une phrase et d’une capture ou référence. « Fonction présente » n’est pas un résultat si seul le commercial peut la montrer sur son compte préparé. Distinguez fonctionnalité disponible, configuration possible, développement promis et prestation de conseil. Une note élevée sur un écran peu utilisé ne doit pas masquer un critère éliminatoire : absence d’export exploitable ou impossibilité de séparer les entités.
Ne publiez pas un classement de marché tiré de cette recette. Elle porte sur votre périmètre, vos données et une version précise de l’offre. La grille sert à rendre la décision d’achat défendable, pas à décréter le meilleur logiciel de gestion de risques cyber pour toutes les organisations.
Examiner le coût complet et la sortie
Demandez une offre chiffrée sur le même périmètre à chaque candidat : nombre d’entités, lecteurs, contributeurs, risques, preuves, connecteurs et environnements. Ajoutez reprise de données, nettoyage, paramétrage, formation et administration. Une fonction qui réduit la ressaisie peut demander une intégration coûteuse à maintenir. Le coût d’un logiciel de conformité aide à préparer les postes, sans fournir un prix universel pour ce besoin cyber.
La sortie doit être testée pendant la démo. Exportez un risque avec son histoire, ses preuves, ses décisions et les identifiants des services et fournisseurs. Vérifiez si une autre équipe peut le relire sans l’interface d’origine. Demandez quelles pièces sont incluses, lesquelles restent des liens expirables et ce que prévoit le contrat à la fin de l’abonnement. Un outil qui centralise toutes les décisions crée aussi une dépendance à sa structure de données.
Organiser la contre-démonstration par l’équipe utilisatrice
Réservez un temps où un futur utilisateur réalise lui-même les opérations, sans que le fournisseur pilote chaque écran. Donnez-lui une fiche courte : retrouver un scénario, remplacer un propriétaire, joindre une preuve devenue disponible, soumettre une décision et exporter l’état avant modification. L’observation révèle les permissions manquantes, les termes incompris et la formation réellement nécessaire. Un parcours fluide effectué par un spécialiste de l’éditeur peut cacher plusieurs étapes que votre équipe ne saurait reproduire.
Demandez ensuite à une personne chargée de l’audit de relire le même cas avec des droits limités. Peut-elle voir la source d’un score et la date d’une preuve sans pouvoir modifier la décision ? Le responsable métier voit-il l’effet sur son service sans accéder aux autres entités ? Notez les contournements proposés, par exemple un export manuel envoyé par courriel ou un rôle administrateur accordé à tous les lecteurs. Ils doivent être évalués comme partie du coût et du risque de l’option, pas oubliés après la démonstration.
Conclure la démonstration par une décision limitée
Le compte rendu devrait dire ce qui a été effectivement démontré, ce qui doit être confirmé dans un pilote et quelles conditions contractuelles restent ouvertes. Un essai concluant sur trois scénarios ne prouve pas que l’outil couvre tous les référentiels, ni que ses connecteurs fonctionnent dans votre SI. Il justifie de poursuivre ou non le processus d’achat et d’investir dans la vérification des points restants.
Si aucune offre ne passe un critère essentiel, révisez le besoin ou le calendrier au lieu d’ajouter des points à une promesse. Il est parfois plus utile de clarifier les propriétaires des risques et d’améliorer le registre existant avant de migrer. Le logiciel peut soutenir une décision déjà définie ; il ne peut pas nommer à votre place la personne qui acceptera les conséquences d’un risque résiduel.