Le Référentiel Général de Sécurité (RGS) définit les exigences de sécurité applicables aux systèmes d’information des administrations françaises. Issu de l’ordonnance n° 2005-1516 du 8 décembre 2005, il est supervisé par l’ANSSI (Agence nationale de la sécurité des systèmes d’information). En 2025, l’ANSSI a publié un nouveau guide d’homologation de sécurité qui actualise la démarche de mise en conformité (source : ANSSI, avril 2025).
Ce guide détaille le périmètre d’application du RGS, ses exigences techniques, le processus d’homologation et son articulation avec les cadres réglementaires européens NIS2 et SecNumCloud.
Qu’est-ce que le Référentiel Général de Sécurité (RGS) ?
Le RGS est un cadre réglementaire qui fixe les règles de sécurité pour les échanges électroniques entre les usagers et les autorités administratives, ainsi qu’entre administrations. Sa version actuelle (v2.0), officialisée par arrêté du Premier ministre le 13 juin 2014, couvre quatre fonctions de sécurité : l’identification électronique, la signature électronique, la confidentialité et l’horodatage électronique.
L’objectif du RGS est triple. Il vise à garantir la confidentialité des données échangées, en s’assurant que seules les personnes autorisées y accèdent. Il protège l’intégrité des informations pour prévenir toute altération non autorisée. Il assure la disponibilité des systèmes pour maintenir la continuité du service public.
Le RGS s’inscrit dans l’écosystème réglementaire européen aux côtés du règlement eIDAS, qui harmonise les services d’identification et de confiance au niveau de l’Union européenne, et du RGPD pour la protection des données personnelles.
À qui s’applique le RGS ?
Le RGS s’impose aux autorités administratives au sens de l’article 1er de l’ordonnance n° 2005-1516 : administrations de l’État, collectivités territoriales, établissements publics et toute personne de droit public ou privé chargée d’une mission de service public. Les prestataires de services de confiance (autorités de certification, prestataires d’horodatage) doivent également s’y conformer.
Les entreprises privées ne sont pas directement assujetties au RGS. Toutefois, celles qui fournissent des services numériques aux administrations ou qui traitent des données du secteur public doivent respecter les exigences du RGS dans le cadre de leurs prestations.
L’ANSSI estime que plusieurs milliers de systèmes d’information publics sont concernés par l’obligation d’homologation. La cartographie des systèmes d’information constitue un prérequis indispensable pour identifier les périmètres soumis au RGS.
Les trois niveaux de certification
Le RGS définit trois niveaux de certification croissants : RGS*, RGS** et RGS***. Chaque niveau correspond à un degré de sécurité adapté à la sensibilité des données et des échanges concernés.
RGS* couvre les besoins d’authentification et de signature électronique de base. Il s’adresse aux applications courantes ne traitant pas de données particulièrement sensibles.
RGS** renforce les exigences en ajoutant la protection des données en transit et au repos, ainsi que des mécanismes d’authentification renforcés. Ce niveau convient aux systèmes traitant des données sensibles nécessitant une protection accrue.
RGS*** impose les mesures de sécurité les plus exigeantes, adaptées aux systèmes d’information traitant des données classifiées ou critiques pour le fonctionnement de l’État.
Les exigences techniques couvrent notamment la gestion des certificats électroniques, les algorithmes cryptographiques autorisés, la protection des clés privées et la journalisation des événements de sécurité. Le RGS renvoie aux référentiels techniques de l’ANSSI pour les spécifications détaillées.
Mise en conformité avec le RGS
Les étapes d’homologation
L’homologation de sécurité est l’acte par lequel l’autorité administrative atteste que son système d’information est protégé conformément aux objectifs de sécurité fixés. Le guide d’homologation publié par l’ANSSI en avril 2025 structure la démarche en neuf étapes.
Étape 1 : définir le périmètre. Identifier le système d’information à homologuer et le référentiel réglementaire applicable (RGS, PSSI, réglementation sectorielle).
Étape 2 : analyser les risques. Conduire une analyse de risques selon une méthode reconnue telle qu’EBIOS Risk Manager, référentiel de l’ANSSI pour l’analyse des risques cyber.
Étape 3 : définir les mesures de sécurité. Déterminer les mesures techniques et organisationnelles nécessaires pour traiter les risques identifiés. L’ANSSI met à disposition MonServiceSécurisé, une solution en ligne gratuite qui génère une liste de mesures personnalisées et un dossier de décision d’homologation prêt à être signé.
Étapes 4 à 9 couvrent la mise en œuvre des mesures, les tests de vérification, la rédaction du dossier d’homologation, la décision d’homologation par l’autorité compétente, le suivi en exploitation et le renouvellement périodique. L’homologation est prononcée pour une durée maximale de cinq ans.
Le non-respect de l’obligation d’homologation expose l’administration à un risque juridique en cas d’incident de sécurité, notamment au titre du RGPD si des données personnelles sont compromises.
Comment le RGS s’articule-t-il avec NIS2 et SecNumCloud ?
Le RGS, NIS2 et SecNumCloud ne se substituent pas les uns aux autres mais se complètent dans une logique de sécurité par couches.
NIS2. La directive européenne NIS2, dont la transposition française a été votée au Sénat le 12 mars 2025, concerne entre 15 000 et 18 000 entités en France. Depuis le 17 mars 2026, l’ANSSI a publié le Référentiel Cyber France (ReCyF) qui décline 20 objectifs de sécurité pour les entités essentielles et 15 pour les entités importantes (source : ANSSI, mars 2026). Une administration déjà conforme au RGS disposera d’une base solide pour répondre aux exigences de NIS2.
SecNumCloud. Le référentiel SecNumCloud, actuellement en version 3.1, qualifie les prestataires de services cloud hébergeant des données sensibles sous souveraineté juridique européenne. Il s’appuie sur la norme ISO 27001 enrichie d’exigences spécifiques au cloud. Les administrations soumises au RGS qui externalisent des services vers le cloud doivent s’assurer que leur prestataire est qualifié SecNumCloud pour les données les plus sensibles.
Le guide d’hygiène informatique de l’ANSSI constitue un complément pratique pour les organisations qui mettent en œuvre simultanément ces différents référentiels.
Évolutions et perspectives
Quelles évolutions pour le RGS en 2025-2026 ?
Le RGS v2.0 est en vigueur depuis 2014 et n’a pas fait l’objet d’une révision formelle depuis. Toutefois, plusieurs évolutions de son environnement modifient concrètement les exigences applicables aux administrations.
La transposition de NIS2 crée un cadre de sécurité complémentaire. Les décrets techniques, en cours de publication au premier semestre 2026, définiront les mesures de sécurité spécifiques pour chacun des 18 secteurs concernés. Les administrations devront articuler leur conformité RGS avec ces nouvelles obligations.
Le guide d’homologation mis à jour en 2025 par l’ANSSI et la DINUM modernise la démarche d’homologation en intégrant les menaces actuelles (rançongiciels, attaques sur la chaîne d’approvisionnement) et en proposant des outils numériques d’accompagnement.
Impact de la doctrine « Cloud au centre »
L’évolution vers le cloud souverain, portée par la doctrine « Cloud au centre » de l’État, impose aux administrations de recourir à des hébergeurs qualifiés SecNumCloud pour les données sensibles. Cette exigence renforce l’intérêt d’une approche intégrée combinant RGS, NIS2 et SecNumCloud.
Les administrations qui migrent vers des solutions cloud doivent vérifier la qualification SecNumCloud de leur prestataire et s’assurer que l’homologation de sécurité couvre le périmètre externalisé. Le non-respect de cette doctrine expose à un risque de perte de souveraineté sur les données publiques.
Les organisations peuvent utiliser des outils de gestion de la conformité comme Legiscope pour suivre simultanément leurs obligations au titre du RGS, du RGPD et des autres référentiels applicables.
Avertissement juridique. Cet article fournit des informations générales sur le RGS et ne constitue pas un conseil juridique. La mise en conformité doit être adaptée au contexte spécifique de chaque administration ou prestataire. Il est recommandé de consulter les publications officielles de l’ANSSI et, le cas échéant, un expert en sécurité des systèmes d’information.
FAQ
Qu’est-ce que le Référentiel Général de Sécurité (RGS) ?
Le RGS est un ensemble de règles fixées par l’ANSSI s’imposant aux systèmes d’information des autorités administratives (État, collectivités, établissements publics). Il définit les exigences de sécurité pour les téléservices, la messagerie, et l’authentification dans les échanges dématérialisés.
Qui est soumis au Référentiel Général de Sécurité ?
Les autorités administratives au sens de l’article L. 100-3 du CRPA : administrations de l’État, régions, départements, communes et groupements, établissements publics à caractère administratif. Les prestataires de services aux autorités administratives doivent également se conformer au RGS pour les systèmes concernés.
Quelle est la différence entre le RGS et SecNumCloud ?
Le RGS s’applique aux systèmes d’information des autorités administratives pour leurs téléservices et échanges dématérialisés. SecNumCloud qualifie les prestataires d’hébergement cloud. Un projet d’administration nécessite souvent les deux : conformité RGS pour le système et hébergeur qualifié SecNumCloud pour les données sensibles.
Comment le RGS s’articule-t-il avec le RGPD et NIS2 ?
Le RGS couvre la sécurité des systèmes d’information des administrations. Le RGPD protège les données personnelles traitées. NIS2 ajoute des exigences de résilience pour les administrations désignées comme entités essentielles. Ces trois référentiels sont complémentaires et s’appliquent simultanément aux systèmes d’information administratifs.
Conclusion
Le RGS reste le cadre de référence pour la sécurité des échanges électroniques des administrations françaises. Son articulation avec NIS2 et SecNumCloud dessine un écosystème réglementaire cohérent qui renforce la posture de cybersécurité du secteur public. Les administrations doivent maintenir une démarche d’homologation active, s’appuyer sur les outils mis à disposition par l’ANSSI et anticiper les obligations issues de la transposition de NIS2 pour garantir la protection de leurs systèmes d’information et des données des citoyens.
Dernière vérification : mars 2026
Legiscope automates this for you
Stop doing compliance manually. Legiscope's AI handles ROPA creation, DPA audits, and gap analysis — in minutes, not weeks.
Start free trial
