GRC Engineering : ce que la tendance change pour les RSSI

Le GRC Engineering (que l'on peut traduire par « ingénierie de la GRC ») consiste à appliquer les méthodes du génie logiciel à la gouvernance, à la gestion des risques et à la conformité : automatiser les tâches répétitives, exprimer certains contrôles sous forme de code, collecter les preuves automatiquement et surveiller la conformité en continu. Né dans une communauté de praticiens américains, le terme s'est diffusé en 2025, porté par le SANS Institute puis par les éditeurs de logiciels de conformité. Il reste presque inconnu en France. Voici d'où il vient, ce qu'il recouvre, et ce qu'un RSSI peut en tirer, même sans développeurs.

La GRC traditionnelle fonctionne par cycles : on remplit un questionnaire, on rassemble des preuves avant l'audit, on produit un rapport, puis on recommence l'année suivante. Le GRC Engineering part d'un constat simple : une grande partie de ce travail est répétitive, manuelle et décalée dans le temps par rapport à l'état réel des systèmes. Il propose donc de traiter la GRC comme les équipes de développement traitent leur logiciel, avec de l'automatisation, des tests et des mesures.

Les définitions varient selon les auteurs, mais trois idées reviennent partout :

• Automatiser ce qui peut l'être : collecte de preuves, relances, consolidation, calcul des indicateurs.
• Tester plutôt que déclarer : l'état de conformité se déduit de ce que montrent les systèmes, pas seulement de ce qu'affirment les personnes.
• Surveiller en continu plutôt qu'une fois par an, pour détecter un écart au moment où il apparaît.

What is GRC engineering : une traduction

Le terme anglais n'a pas d'équivalent consacré en français. « Ingénierie de la GRC » est la traduction la plus fidèle ; on rencontre aussi « GRC automatisée ». Dans ce dossier, nous employons « GRC Engineering » pour le mouvement et ses outils, et GRC Ops pour la manière de mener la GRC en continu à l'échelle d'une organisation, avec ou sans code.

Un manifeste de praticiens

Le texte de référence est le GRC Engineering Manifesto, publié sur grc.engineering par neuf praticiens, parmi lesquels Ayoub Fandi, Justin Pagano, Charles Nwatu et Terra Cooke. Construit sur le modèle du manifeste agile, il oppose des paires de valeurs : il préfère l'automatisation précoce aux processus manuels, la « GRC as code » aux réglages propres à un outil, des résultats mesurables sur le risque à une conformité de case à cocher, une assurance continue et approfondie à une surveillance périodique superficielle, et des solutions ouvertes, construites par les praticiens, aux modèles fermés. Il y ajoute des principes : intégrer la GRC dès la conception des systèmes, traiter la GRC comme un produit, et fonder les contrôles sur une connaissance à jour des menaces.

Une communauté, puis le SANS

Autour du manifeste s'est formée une communauté : la lettre d'information The GRC Engineer d'Ayoub Fandi, un blog collectif, et le GRC Engineering Club, une communauté payante qui propose des laboratoires dans le cloud, des formations et des groupes locaux dans plusieurs dizaines de villes. Le SANS Institute, organisme de formation en cybersécurité très suivi aux États-Unis, a consacré en juin 2025 un webinaire au sujet, centré sur la policy as code, puis en août 2025 un article d'AJ Yawn qui présente le GRC Engineering comme l'usage du développement logiciel, de l'automatisation et du cloud pour rationaliser les processus de GRC.

Un signal venu des autorités américaines

Du côté des administrations, le programme fédéral américain de qualification des services cloud a lancé en mars 2025 FedRAMP 20x. Sa première phase a testé des indicateurs de sécurité validés automatiquement, capables de montrer l'état d'un fournisseur presque en temps réel, à la place d'évaluations annuelles statiques. C'est l'application la plus visible des idées du GRC Engineering par un régulateur.

Derrière le terme se cachent plusieurs pratiques, d'inégale difficulté. Le tableau ci-dessous les résume.

Plusieurs briques techniques sont matures. Le langage de règles Open Policy Agent, très utilisé pour la policy as code, est devenu un projet « gradué » de la Cloud Native Computing Foundation en février 2021, le plus haut niveau de maturité de cette fondation. Le NIST a publié en juin 2021 la version 1.0 d'OSCAL, un ensemble de formats ouverts (XML, JSON, YAML) pour décrire référentiels, plans de sécurité et résultats d'évaluation de façon exploitable par des programmes. Et la surveillance continue de la sécurité fait l'objet d'un guide du NIST depuis 2011.

À noter : tous les promoteurs du mouvement ne mettent pas le code au centre. Ayoub Fandi, coauteur du manifeste, résume sa position par une formule : non pas « policy as code », mais « policy from code », c'est-à-dire déduire l'état de conformité des données produites par les systèmes, plutôt que d'écrire les politiques en code. Il présente la programmation comme un atout, pas comme une condition.

Prenons une exigence présente dans presque tous les référentiels : l'authentification multifacteur des comptes administrateurs. En GRC classique, elle figure sur une ligne de tableur, et quelqu'un répond « conforme » une fois par an, capture d'écran à l'appui. En GRC Engineering, elle suit un tout autre chemin.

1. La règle : l'exigence est traduite en condition vérifiable (« aucun compte du groupe administrateurs sans second facteur »).
2. Le test : un script interroge l'annuaire chaque jour et compare le résultat à la règle.
3. La preuve : chaque exécution produit un résultat daté et conservé, que l'auditeur peut consulter sans demander de capture d'écran.
4. Le tableau de bord : le résultat alimente un indicateur ; un écart ouvre une action, assignée à un responsable, et le test suivant confirme la correction.

Ce circuit est puissant pour les contrôles techniques répétitifs. Il ne dit rien, en revanche, de la pertinence de la règle elle-même : c'est l'analyse de risques qui détermine quels comptes protéger et avec quel niveau d'exigence.

La plupart des RSSI français, en particulier dans les hôpitaux, les collectivités et les ETI, n'ont pas d'ingénieur dédié à l'automatisation de la conformité. Le GRC Engineering n'en reste pas moins une source d'idées très concrètes.

1. Écrire des contrôles, pas seulement des exigences

Chaque exigence importante devrait avoir un contrôle associé : qui le réalise, à quelle fréquence, avec quelle preuve attendue. C'est l'étape la plus utile, et elle ne demande aucun code.

2. Relier les référentiels entre eux

ISO 27001, NIS 2, DORA, RGPD et votre PSSI se recoupent largement. Un même contrôle, relié à plusieurs exigences, évite de répondre cinq fois à la même question.

3. Automatiser d'abord ce qui ne demande pas d'expertise

Relances, consolidation des réponses, calcul des taux de conformité, génération des rapports : une plateforme GRC le fait sans développement, et c'est souvent là que se perd le plus de temps.

4. Demander la preuve à la source

Plutôt qu'une capture d'écran, demandez l'export daté produit par l'outil lui-même. Vos équipes d'exploitation savent souvent le générer, et certains de leurs outils (annuaire, gestion des correctifs, sauvegarde) produisent déjà des rapports réguliers.

5. Mesurer des résultats, pas des activités

« 95 % des questionnaires renvoyés » mesure une activité. « Délai moyen de correction des écarts critiques » mesure un résultat. Les textes européens vont dans ce sens : le règlement d'exécution 2024/2690 demande de déterminer quelles mesures surveiller, comment et quand, et DORA exige une surveillance permanente des systèmes TIC.

6. Commencer petit avec l'exploitation

Si vos équipes techniques savent écrire des scripts, choisissez avec elles deux ou trois contrôles techniques faciles à automatiser. Le plus important n'est pas l'outil mais la collaboration entre GRC et exploitation, que le manifeste appelle un « partenariat à destin partagé ».

• Un modèle né dans le cloud. Le mouvement vient d'entreprises technologiques américaines, souvent entièrement hébergées dans le cloud et soumises à des attestations comme SOC 2. Un système d'information hospitalier ou une collectivité, avec des applications anciennes installées sur site, n'offre pas les mêmes points d'accès pour automatiser.
• Tout ne se code pas. La qualité d'une analyse de risques, la sensibilisation des agents, la gestion de crise ou la pertinence d'un contrat ne se vérifient pas par un script.
• Un contrôle automatisé se maintient. Un script qui ne tourne plus, ou qui teste la mauvaise chose, donne une fausse assurance. Il faut un responsable et une revue, comme pour tout contrôle.
• Automatiser la case à cocher reste une case à cocher. Le manifeste lui-même met en garde contre la conformité de façade : vérifier mille fois une règle mal choisie ne réduit aucun risque.
• Des chiffres souvent promotionnels. Une bonne partie de la littérature est publiée par des éditeurs ou des formateurs ; les gains annoncés sont rarement mesurés de manière indépendante.
• L'audit demeure. ISO 27001 et DORA exigent toujours un audit interne et une revue par la direction. Le GRC Engineering les facilite, il ne les supprime pas.

Le GRC Engineering décrit une discipline et un profil : le praticien de la GRC qui sait automatiser. Notre guide GRC Ops en tire une définition pour toute l'organisation : une GRC menée en continu, avec des données partagées, des preuves au fil de l'eau et un pilotage par indicateurs, que l'automatisation passe par du code ou par une plateforme. Pour aller plus loin, lisez nos articles sur la conformité continue, qui détaille le passage de l'audit annuel au contrôle permanent, sur la gestion de la conformité (méthode, rôles, indicateurs) et sur l'IA appliquée à la GRC, la suite logique de l'automatisation.

Pour automatiser les relances, la consolidation et les indicateurs sans écrire de code, voyez notre page logiciel GRC.