Pourquoi le choix de la plateforme cyber GRC IA compte
Beaucoup de solutions GRC annoncent désormais de l'intelligence artificielle, et toutes les approches ne se valent pas. Certaines ajoutent un assistant en surcouche d'un outil existant, d'autres, comme Vailor, ont été conçues autour de l'IA dès le départ. Ce guide détaille les critères qui permettent de faire la différence avant de signer.
Critère n°1 : architecture IA native ou IA ajoutée
La première question est de savoir où l'IA intervient réellement. Dans une plateforme conçue pour l'IA, elle travaille au cœur du parcours : elle lit les documents que vous chargez, préremplit les champs de l'analyse à partir d'extraits cités, et chaque proposition passe par un expert avant d'être retenue. Dans un outil où l'IA a été ajoutée après coup, elle se limite souvent à un assistant de rédaction à côté des écrans existants. Demandez à voir d'où vient chaque proposition, et qui la valide.
Critère n°2 : souveraineté des données
Pour les organisations françaises et européennes, la maîtrise des données n'est pas négociable. Vérifiez où elles sont hébergées, quels modèles sont utilisés, si vos données servent à les entraîner et quels modes de déploiement sont possibles. En SaaS, Vailor stocke les données en France (AWS, région Paris), et ses traitements d'IA passent par AWS Bedrock dans des régions de l'Union européenne. Vailor s'installe aussi dans votre infrastructure (Docker). Vos données ne servent jamais à entraîner des modèles, et vous choisissez le modèle, y compris un modèle auto-hébergé.
Critère n°3 : expertise métier GRC
L'IA généraliste ne suffit pas pour la GRC. Votre plateforme doit connaître les méthodes d'analyse de risque (EBIOS RM, analyse flash, votre méthode maison), les référentiels réglementaires (NIS2, DORA, NIST CSF 2.0) et produire des livrables que vos instances savent lire. Vailor couvre EBIOS RM de bout en bout, propose une analyse flash pour les projets moins critiques, et exporte ses livrables en PDF, Word et PowerPoint, avec une synthèse décideur.
Éprouver la plateforme sur vos données, pas sur une démo
Une démonstration commerciale se déroule toujours sur un jeu de données choisi parce qu’il se comporte bien. Le seul test qui vous renseigne consiste à rejouer dans la plateforme une analyse de risque que vos équipes ont déjà produite, avec vos actifs, vos référentiels et votre vocabulaire interne, puis à comparer les deux livrables ligne à ligne. Cadrez ce pilote avant de le lancer : un périmètre réel mais borné (un processus métier, une filiale, un domaine applicatif), quatre à six semaines, et des critères de réussite écrits à l’avance. Mesurez la reprise plutôt que l’allure du livrable : combien de scénarios de risque partent à la corbeille, combien de mesures proposées sont hors sujet, combien de temps un analyste passe à corriger. Tout gain annoncé par un éditeur, Vailor compris, doit se vérifier sur votre périmètre, pas dans une présentation. Testez aussi les cas ingrats : un actif mal documenté, un fournisseur qui répond à moitié, un référentiel maison que personne n’a jamais mis en correspondance. Ce sont eux qui décident.
Ce qu’il faut avoir préparé avant le premier atelier
Les pilotes qui s’enlisent butent rarement sur la technologie : c’est la matière première qui manque. Avant de démarrer, réunissez un inventaire d’actifs même incomplet mais à jour, la liste des processus métier et de leurs responsables, le registre de risques existant tel quel, et les sources de preuve que vous utilisez déjà (tickets, résultats de scans, comptes rendus d’audit). Nommez aussi la personne qui valide ce que l’IA produit : sans validateur désigné, les livrables s’empilent en attente et le pilote s’éteint de lui-même. Côté DSI, prévoyez le raccordement à votre annuaire, la définition des habilitations par périmètre et l’examen du traitement avec votre délégué à la protection des données. Les prérequis varient aussi avec la taille et le secteur : une entité essentielle au sens de NIS2 ne relève pas du même régime de supervision qu’une entité importante, et une entité financière soumise à DORA doit raccorder dès le départ son registre d’informations sur ses prestataires informatiques. Ces différences déterminent les modules que vous ouvrez en premier.
Réversibilité, traçabilité et indicateurs après la mise en service
Trois exigences se négocient au contrat, pas une fois la plateforme installée. La réversibilité d’abord : vos analyses, votre registre de risques, vos plans d’action et vos preuves doivent pouvoir sortir dans un format ouvert et réimportable, sans intervention de l’éditeur. La traçabilité ensuite : chaque contenu généré doit porter ses sources, le modèle et la version qui l’ont produit, et le nom de la personne qui l’a validé. Un auditeur ou un organisme de certification demandera qui a écrit quoi, et une sortie non tracée se transforme en écart. Le suivi enfin : relevez votre point de départ avant le déploiement, sinon vous n’aurez rien à comparer. Quatre indicateurs suffisent : le délai entre l’ouverture d’une analyse et la validation de son livrable, la part des contenus générés acceptés sans réécriture substantielle, la proportion de mesures adossées à une preuve datée et récente, et l’ancienneté du plus vieil écart non traité. Revoyez-les au bout d’un trimestre, avec les mêmes définitions.
Conclusion : les questions à poser aux éditeurs
Avant de choisir votre plateforme cyber GRC IA, posez ces questions. Où l'IA intervient-elle, et qui valide ses propositions ? Où sont hébergées les données, et servent-elles à entraîner des modèles ? Quels modèles sont utilisés, et pouvez-vous choisir le vôtre ? Quelles méthodes et quels référentiels sont disponibles aujourd'hui, et lesquels sont seulement annoncés ? Posez-les aussi à Vailor : réservez 30 minutes, on écoute votre contexte et on vous répond concrètement.