Une migration GRC peut afficher le bon nombre de risques et perdre pourtant ce qui rend les dossiers utilisables: leurs identifiants, les liens vers les contrôles, les propriétaires ou l’historique des preuves. La recette ne devrait donc pas se limiter à ouvrir la nouvelle application et à comparer deux totaux. Elle doit définir ce qui sera repris, comment les relations seront réconciliées et à quelles conditions le métier signera la bascule. Cette page fournit un plan d’acceptation de reprise, distinct d’un comparatif de logiciels.
Le NIST Cybersecurity Framework situe la gouvernance des risques et la communication des résultats, tandis que NIST SP 800-53A décrit des démarches d’évaluation des contrôles. Aucun de ces textes n’impose le schéma de migration ci-dessous. Celui-ci est un outil de recette à adapter aux données, aux obligations de conservation et aux capacités réellement démontrées par le logiciel choisi. Ne supposez pas qu’un fournisseur prend en charge une importation ou un export particulier sans l’avoir testé.
Délimiter le lot à reprendre
Commencez par les objets métier: risques, scénarios, actifs, contrôles, exigences, plans d’action, évaluations, preuves, exceptions et décisions. Pour chaque objet, indiquez le système source, le propriétaire, le volume, le statut et l’usage après bascule. Un registre ancien peut contenir des dossiers clos qui doivent rester consultables sans redevenir actifs. Séparez migration opérationnelle, archivage consultable et données destinées à être supprimées selon la politique applicable.
Cartographiez les relations. Un risque lié à trois contrôles, dont deux ont des preuves datées et un propriétaire distinct, n’est pas équivalent à une ligne de texte portant le nom du risque. Décrivez la cardinalité, les identifiants et les dépendances avant de demander un export. Les pièces jointes peuvent avoir leur propre stockage, des versions et des droits d’accès différents. Faites vérifier le périmètre par les utilisateurs qui devront retrouver les dossiers après la bascule.
La solution de gestion PSSI donne un contexte d’outillage. Le présent plan porte uniquement sur la fidélité des données et des relations pendant le changement de système.
Geler un inventaire de référence
Avant un essai de reprise, extrayez un inventaire daté depuis la source. Capturez le nombre d’objets par type et statut, les identifiants stables, les relations, les pièces et les responsables. Conservez les règles d’extraction et les filtres: si l’export exclut les archives, le comparatif ne devra pas reprocher à l’import leur absence. Un export CSV seul ne garantit pas la restitution des métadonnées, versions ni droits.
Évitez de copier des informations sensibles dans un rapport de recette largement partagé. Utilisez des empreintes, des totaux, des identifiants de référence et des échantillons contrôlés. La confidentialité du dossier de migration doit être adaptée à ce qu’il révèle sur les faiblesses de l’organisation. Indiquez la date et le fuseau de l’extraction, surtout si des dossiers changent pendant la migration.
Le guide d’audit RGPD éclaire le suivi de dossiers de conformité; lorsque la migration comporte des données personnelles, la base de traitement et la conservation doivent être examinées séparément. Le simple fait de déplacer des dossiers GRC ne résout pas ces questions.
Préserver les identifiants et l’histoire
Décidez quel identifiant restera visible aux équipes. L’ancien identifiant peut être repris tel quel, placé dans un champ de correspondance ou remplacé avec une table de conversion. Ce choix doit être fait avant l’import: les rapports, comptes rendus d’audit et actions ouvertes citent souvent ces valeurs. Le plan de recette vérifie que chaque identifiant ancien renvoie à un seul objet attendu et que les collisions sont identifiées. Un nouvel identifiant automatique n’est pas un problème s’il existe une correspondance stable et accessible.
Pour les preuves, précisez ce que signifie « historique »: date de collecte, auteur, période couverte, version, décision de validation et lien au contrôle. Une pièce jointe présente sans sa période peut sembler toujours valable. Une ancienne preuve expirée ne doit pas apparaître comme une preuve actuelle à cause d’un défaut de mappage. Le guide sur la validité des preuves d’audit rappelle pourquoi l’état temporel importe.
Conservez les décisions anciennes comme décisions anciennes. Si un dossier a été accepté sous conditions en 2024, l’import ne doit pas créer une nouvelle acceptation datée du jour de la migration. Distinguez date de création dans le nouveau système, date du fait historique et date de la dernière révision. Cette distinction évite d’inventer une actualité de conformité.
Construire la matrice de correspondance
Une table de mappage indique objet et champ source, objet et champ cible, transformation, propriétaire de règle et exemple vérifié. Traitez explicitement les listes de valeurs: « ouvert », « en cours » et « accepté » peuvent avoir des sens différents selon les outils. Ne forcez pas tous les anciens états dans une catégorie « terminé » pour obtenir un import sans erreurs. Quand le nouveau modèle ne représente pas fidèlement un état, décidez d’une représentation alternative ou d’un archivage lié.
Testez les relations dans les deux sens. À partir d’un risque, peut-on retrouver ses contrôles ? À partir du contrôle, peut-on retrouver tous les risques associés et les preuves pertinentes ? Une conversion de clé peut sembler correcte dans un fichier plat et créer des liens orphelins à l’import. La gestion de la conformité multi-référentiels illustre l’importance des mappages; la recette de migration doit vérifier les relations réelles, pas simplement la présence d’une fonction de mappage annoncée.
Documentez les transformations non réversibles avant de les exécuter. Réunir plusieurs champs, arrondir une échelle de risque ou éliminer un commentaire peut faire perdre une nuance utile. Le propriétaire métier doit valider cette perte ou choisir une autre voie. La migration n’est pas une occasion de réécrire silencieusement le registre pour qu’il paraisse plus homogène.
Définir des critères d’acceptation mesurables
La recette peut combiner une réconciliation exhaustive des clés et une revue d’échantillons sémantiques. Une table de décision pourrait être:
| Objet ou relation | Critère de contrôle | Preuve |
|---|---|---|
| Identifiant de risque | Correspondance univoque ou exception résolue | Table ancien/nouveau et liste des collisions |
| Contrôle lié | Relations attendues retrouvées dans les deux sens | Export des liens et échantillon navigué |
| Propriétaire | Personne ou rôle cible confirmé | Validation par responsable métier |
| Preuve historique | Fichier, période, version et état conservés | Échantillon avant/après |
| Action ouverte | Échéance et état inchangés ou conversion approuvée | Réconciliation et test utilisateur |
| Droits d’accès | Accès autorisé et accès refusé testés | Scénarios de recette documentés |
Fixez les seuils de tolérance avant l’essai. Certaines pertes sont inacceptables, même si elles concernent un seul dossier critique; d’autres anomalies mineures peuvent être corrigées après bascule si un propriétaire et une date sont définis. Ne transformez pas « 99 % des lignes importées » en acceptation implicite lorsque le 1 % restant contient les décisions les plus importantes.
Rejouer un échantillon orienté risque
Sélectionnez des dossiers de types différents: risque actif fortement lié, risque clos, exception expirée, contrôle commun à plusieurs référentiels, preuve avec plusieurs versions, action dont le propriétaire a changé et dossier à accès restreint. Échantillonnez aussi les erreurs d’import. Les cas « faciles » ne révèlent pas les limites du mappage. Pour chaque dossier, un utilisateur de la fonction explique ce qu’il doit pouvoir faire après migration et vérifie le résultat dans l’interface cible.
Un contrôle visuel de dix fiches ne suffit pas à établir l’unicité des identifiants sur tout le lot. À l’inverse, une comparaison automatisée de totaux ne vérifie pas la signification d’une décision. Les deux approches se complètent. Conservez la liste des cas testés, la raison de leur choix, le résultat et l’anomalie éventuelle. Si une capacité du produit bloque un critère, ne l’attribuez pas automatiquement à une mauvaise qualité des données.
Le guide d’échantillonnage d’audit aide à expliquer les limites d’une sélection. Une recette doit être honnête sur ce qu’elle a vérifié exhaustivement et ce qu’elle infère d’un échantillon.
Exemple: un contrôle partagé perd ses preuves
Supposons un registre fictif où le contrôle C-42 réduit les risques R-18 et R-27. Il possède une preuve validée pour le premier semestre, une preuve plus récente en attente de revue et une exception temporaire. L’import crée bien les deux risques et le contrôle, mais ne rattache que la dernière pièce. Un simple total d’objets semble correct: les deux preuves existent quelque part dans la nouvelle base. La navigation du dossier révèle pourtant que l’historique n’est plus rattaché au bon contrôle.
La recette marque le cas en échec. L’équipe recherche si la perte vient de l’export, de la table de relations ou de l’import. Elle corrige la règle, relance un essai et vérifie à la fois C-42, R-18 et R-27. Elle confirme que l’exception conserve sa date de fin et n’est pas devenue une acceptation illimitée. L’exemple montre pourquoi les liens, les états et les dates doivent être des critères explicites, pas des détails laissés à une démonstration commerciale.
Après correction, le rapport compare le nombre de relations attendues et présentes sur tout le lot. Il conserve aussi l’échantillon manuel qui vérifie le sens métier de ces liens. Un même résultat technique pourrait être insuffisant si les propriétaires ne peuvent plus accéder à la pièce nécessaire pour décider.
Préparer la bascule et le retour arrière
Définissez le dernier export, la période de gel ou de double saisie et la manière de réconcilier les changements intervenus entre l’essai et la mise en service. Sans cette règle, un import parfaitement testé peut manquer les risques créés la veille de la bascule. Désignez qui annonce le gel, qui autorise l’import final, qui vérifie les écarts et quand les utilisateurs peuvent reprendre les modifications.
Prévoyez un retour arrière réaliste. Restaurer l’ancien outil peut être impossible après plusieurs jours d’écritures dans le nouveau. Un plan peut alors préserver la source en lecture seule et définir comment exporter les nouvelles écritures si la bascule doit être interrompue. Testez ce que permet réellement chaque fournisseur et les contraintes de licence ou d’accès; ne présumez pas qu’un bouton « annuler » existe. Le plan d’action après audit fournit un contexte pour garder visibles les anomalies ouvertes.
La signature de recette devrait distinguer acceptation sans réserve, acceptation avec écarts explicitement suivis et refus. Chaque écart accepté porte un responsable, un délai et une mesure de réduction. La direction du programme ne peut pas déclarer une reprise fidèle uniquement parce que les utilisateurs ont pu se connecter.
Suivre la qualité après migration
Pendant les premières semaines, surveillez les dossiers impossibles à retrouver, les liens orphelins, les permissions inattendues et les dates incohérentes. Confrontez les rapports métier produits par le nouvel outil aux chiffres de référence. Si des écarts apparaissent, remontez à la table de conversion et à l’échantillon d’essai. Corrigez les données sous contrôle de version ou journal de changement, sans modifier silencieusement l’archive source.
Conservez une procédure pour retrouver l’ancien identifiant et les pièces historiques tant que des dossiers externes les citent. Vérifiez l’accès aux archives avec un compte normal, pas seulement avec un administrateur. Une migration réussie reste exploitable lors du prochain audit, du prochain incident et du prochain changement de propriétaire. La traçabilité des preuves d’audit traite de cet usage durable.
Le plan d’acceptation tient finalement en une question: un utilisateur peut-il retrouver un risque, comprendre ses contrôles et décisions, consulter les preuves à leur date, identifier le propriétaire et démontrer que rien de significatif n’a disparu ? Les critères écrits avant l’import permettent de répondre avec des faits plutôt qu’avec l’impression laissée par la nouvelle interface.
Traiter les objets qui n’entrent pas dans le nouveau modèle
Il arrive que le nouveau logiciel ne représente pas un type de relation, une échelle de cotation ou une étape de validation ancienne. Le projet doit dresser une liste de ces incompatibilités avant la bascule. Pour chacune, choisissez une transformation contrôlée, un stockage d’archive lié ou une modification du processus métier. Indiquez ce qui sera visible à l’utilisateur, ce qui restera seulement consultable et ce qui perdrait son sens. La décision ne doit pas être prise par le seul script d’import parce qu’il sait convertir une valeur.
Un exemple fréquent concerne les propriétaires historiques. Un ancien dossier peut porter le nom d’une personne partie de l’organisation. Il serait trompeur de remplacer ce nom dans toutes les décisions passées par celui du responsable actuel. Conservez l’auteur ou propriétaire historique comme fait, puis attribuez séparément le propriétaire opérationnel après migration. Testez qu’un utilisateur peut distinguer les deux. La même logique vaut pour les anciennes évaluations: leur date et leur méthode de calcul doivent rester visibles si elles fondent des décisions déjà prises.
Si une incompatibilité touche un petit nombre de dossiers critiques, elle peut bloquer la recette malgré une excellente correspondance globale. Documentez ces exceptions avec identifiants, conséquence métier, solution proposée, propriétaire et date. Une annexe de migration qui explique les limites est préférable à une promesse générale de reprise « complète » contredite lors du prochain audit. Après la bascule, vérifiez que le contournement reste accessible et ne dépend pas d’une licence ou d’un compte temporaire.