Un cahier des charges pour un logiciel GRC doit permettre de décider si la solution soutient les opérations de votre organisation. Une liste de fonctionnalités comme « risques, audit, conformité » ne dit pas si un responsable saura retrouver la preuve d’une décision, traiter un contrôle défaillant ou récupérer son historique à la sortie du contrat.
Le livrable proposé est une matrice d’exigences assortie de scénarios de recette. Elle est indépendante des marques et ne constitue ni un classement de logiciels ni une description des capacités d’un produit particulier. Les références au NIST Cybersecurity Framework et aux méthodes d’évaluation de NIST SP 800-53A, consultées le 26 septembre 2026, fournissent le contexte de gestion des risques et de vérification. Les critères d’achat ci-dessous restent à définir par l’acheteur.
Décrire le travail avant le logiciel
Recensez les processus à soutenir : analyse de risques, définition des contrôles, collecte et examen des preuves, plans d’action, suivi des fournisseurs et préparation des audits. Pour chaque processus, choisissez un exemple réel anonymisé, une personne utilisatrice et un résultat attendu. Ce matériau évite que le fournisseur choisisse uniquement les démonstrations les plus favorables à son produit.
Indiquez aussi les limites du projet. Une première étape peut concerner deux entités et un seul périmètre technique. Cela doit apparaître dans l’offre et dans les conditions d’acceptation. Une fonctionnalité utile à un futur programme international ne justifie pas nécessairement une complexité immédiate pour une petite équipe.
La sélection d’une solution de gestion PSSI traite un besoin plus ciblé. Si votre projet se limite à la publication de politiques et à leur approbation, vérifiez que l’élargissement vers une plateforme GRC répond à des opérations identifiées. Le volume du catalogue commercial n’est pas un objectif de projet.
Rédiger des exigences observables
Utilisez une formulation comportant un acteur, une action, un objet et une preuve de résultat. « Le responsable du contrôle retrouve la version de la preuve examinée lors de la décision » peut être testé. « Gestion documentaire avancée » ne définit aucun résultat vérifiable.
| Domaine | Exigence à adapter | Scénario de recette | Preuve à conserver |
|---|---|---|---|
| Risques | Conserver hypothèses, traitement et décision | Modifier une hypothèse après acceptation | Historique compréhensible des deux décisions |
| Contrôles | Relier activité, responsable et échec | Faire échouer un contrôle partagé | Effets visibles sur les périmètres concernés |
| Preuves | Distinguer collecte, examen et validité | Fournir une pièce ancienne mais authentique | Alerte et conclusion de l’évaluateur |
| Accès | Séparer entités et responsabilités | Utiliser deux profils de revue | Résultats des accès permis et refusés |
| Actions | Relancer et escalader un retard | Dépasser une échéance de correction | Journal et responsabilité actuelle |
| Export | Restituer données, relations et pièces | Reconstituer une décision hors du produit | Dossier lisible et complet |
Ajoutez à chaque ligne une priorité, le périmètre, le responsable de validation, les dépendances et l’écart acceptable. Distinguez ce qui est disponible dans la version proposée, ce qui nécessite une configuration, ce qui nécessite une prestation et ce qui figure seulement dans une feuille de route.
Fixer les conditions bloquantes avant les démonstrations
Certaines exigences peuvent être éliminatoires : séparation de données entre entités, export des preuves, accès administrateur contrôlé ou conservation des décisions. Définissez-les avant de rencontrer les fournisseurs. Une interface séduisante ne doit pas modifier implicitement vos obligations ou vos limites de risque.
Les autres critères peuvent être pondérés. Documentez cependant le sens des notes : observé et reproductible, observé avec réserve, déclaré, absent. Une note attribuée à une promesse n’a pas la même valeur qu’une note attribuée à une opération réalisée par votre propre équipe.
Prévoyez une catégorie « inconnu ». Une réponse incomplète ne doit pas devenir zéro si le besoin n’a pas encore été vérifié, ni une réussite si le fournisseur promet de répondre plus tard. Le statut inconnu déclenche une action et empêche une conclusion prématurée sur un critère essentiel.
Tester la chaîne risque, contrôle et preuve
Dans un scénario fictif, une organisation dépend d’un prestataire pour restaurer ses dossiers clients. Le risque est documenté, un contrôle de restauration lui est associé et une preuve de test est déposée. Le démonstrateur doit expliquer qui a examiné cette preuve et quelle conclusion elle autorise.
Changez ensuite un fait : la preuve ne couvre plus la nouvelle application. Observez si le système conserve la décision historique, signale la limite actuelle et permet d’ouvrir une action. Un écran indiquant « conforme » parce qu’un fichier est présent ne répond pas à ce scénario.
Le catalogue de contrôles aide à préparer les objets utilisés dans l’essai. Vérifiez que les liens entre risque, activité, preuve et action restent compréhensibles à l’export. Une relation visible seulement dans une interface peut devenir difficile à exploiter après un changement de solution.
Le script de démonstration d’un outil de risques cyber complète cette recette par trois situations adverses, une décision de risque et une contre-démonstration conduite par l’équipe utilisatrice.
Examiner les permissions avec des profils réalistes
Préparez au moins les rôles de contributeur, propriétaire de contrôle, évaluateur, auditeur et administrateur. Une petite structure peut cumuler des rôles, mais le produit doit être évalué sur les séparations dont vous avez besoin. Testez les données accessibles, les modifications autorisées et les actions visibles dans l’historique.
Choisissez un dossier contenant une pièce sensible et une synthèse partageable. Vérifiez si le partage de la synthèse expose involontairement la pièce. Faites aussi transférer la propriété du contrôle lors du départ d’un utilisateur. Le nouveau responsable doit pouvoir reprendre le travail sans perdre l’attribution des décisions anciennes.
Demandez comment sont administrés les comptes techniques et les intégrations. Quels droits sont nécessaires ? Qui peut créer une connexion ? Comment découvre-t-on une connexion inutilisée ? Ces questions font partie de l’exploitation du logiciel, même si elles apparaissent rarement dans une démonstration centrée sur les tableaux de bord.
Demander une démonstration d’échec d’intégration
Une connexion qui fonctionne au démarrage ne démontre pas sa fiabilité pendant le contrat. Dans un environnement de démonstration autorisé, interrompez une source ou retirez une permission limitée. Vérifiez la date de dernière collecte réussie, le message d’erreur, le responsable alerté et le traitement des preuves anciennes.
La reprise doit être observée : les doublons sont-ils identifiés, les périodes manquantes restent-elles visibles, les données sont-elles attribuées au bon périmètre ? Définissez ce que votre équipe doit faire manuellement et mesurez ce travail pendant le pilote.
L’évaluation d’un logiciel d’audit RGPD peut fournir un contexte complémentaire lorsque les processus de protection des données font partie du projet. Ne présumez pas qu’un connecteur technique établit une conclusion juridique ou que la même preuve convient à chaque exigence.
Vérifier la réutilisation entre référentiels
Demandez au fournisseur de relier un contrôle à deux exigences proches, puis introduisez une différence de périmètre ou de période. La démonstration doit montrer comment cette différence est conservée. Réutiliser une preuve peut réduire la collecte ; cela ne rend pas identiques les obligations ni les décisions attendues.
Le guide des solutions multi-référentiels situe ce besoin. Dans le cahier des charges, exigez une traçabilité des correspondances, de leur source et des validations internes. Une correspondance livrée par défaut doit pouvoir être examinée et adaptée sans effacer son origine.
Testez aussi le changement de version d’un référentiel. Les anciens dossiers doivent rester interprétables et les contrôles concernés par la modification doivent pouvoir être identifiés. Évitez de faire dépendre votre décision d’une simple affirmation selon laquelle les mises à jour sont « automatiques ».
Chiffrer le coût du fonctionnement
Demandez des offres fondées sur le même périmètre : utilisateurs, entités, modules, intégrations, stockage, support, migration et durée. Séparez abonnement, prestations initiales et travail récurrent. Les montants doivent venir d’offres écrites ; ce cahier des charges ne fournit aucun tarif de marché.
Ajoutez le temps interne : qualification des preuves, maintenance des propriétaires, correction des connexions et traitement des exceptions. Dans un exemple de calcul, dix heures mensuelles de revue et six heures de maintenance représentent seize heures de capacité à prévoir, avant les campagnes d’audit. Ces chiffres illustrent une formule, pas une mesure moyenne du secteur.
Enregistrez les hypothèses qui peuvent faire varier ce coût. Une nouvelle entité, un changement d’annuaire ou un nouveau périmètre technique peut demander plus de configuration que l’ajout de quelques utilisateurs. Le pilote doit identifier les unités de travail qui expliquent cette variation.
Réussir une sortie avant d’accepter l’entrée
Exportez un ensemble comprenant un risque, deux versions d’une preuve, une action fermée et une exception ouverte. Confiez-le à une personne absente de la démonstration. Elle doit retrouver qui a décidé quoi, quand et sur quel périmètre, sans consulter l’interface du fournisseur.
Contrôlez les pièces jointes, les identifiants, les relations, les dates, les statuts et les limites de format. Demandez quelles opérations restent disponibles après résiliation et pendant combien de temps, selon les conditions proposées. Un export CSV de titres ne remplace pas un dossier de preuve exploitable.
Prononcer une acceptation motivée
Le procès-verbal final reprend chaque exigence essentielle, le résultat observé, les réserves, le propriétaire de la correction et la date convenue. Les fonctions futures restent des engagements à confirmer, pas des résultats de recette. Si une étape demeure extérieure au logiciel, décrivez le processus complet et l’équipe qui l’assume.
La décision peut être une acceptation, une acceptation conditionnelle ou un refus sur un point essentiel. Elle doit être lisible par la direction, les achats et les futurs exploitants. Une méthode d’audit documentée aide à conserver cette distinction entre constat, limite et conclusion. Le cahier des charges a rempli son rôle lorsque la décision d’achat peut être expliquée à partir de résultats observés.