RGS ANSSI : le référentiel général de sécurité et l'homologation des
téléservices publics

On reconnaît un dossier d'homologation du secteur public à son épaisseur, rarement à ce qu'il démontre. Une analyse de risques livrée par un cabinet, une politique de sécurité recopiée d'un ministère, une matrice de conformité cochée en vert, une décision signée sans date de fin, et nulle part la trace qu'on a essayé d'entrer dans le téléservice avant de l'ouvrir aux usagers. Le système est homologué. Il n'a pas été testé.

Le RGS ANSSI, le référentiel général de sécurité, demande pourtant tout autre chose que de constituer un dossier. Il impose aux autorités administratives une démarche en cinq étapes dont l'homologation n'est que la quatrième, il fixe les niveaux de sécurité des certificats et des prestataires, et son guide d'accompagnement, réécrit par l'ANSSI et la DINUM, pose au responsable une question à laquelle aucune matrice de conformité ne répond : comment la sécurité du système a-t-elle été éprouvée ? Un test d'intrusion, lui, y répond, et ce que NIS2 prépare pour les administrations ne va pas rendre la question plus facile à esquiver.

RGS ANSSI : ce que le référentiel est, et d'où il vient

Le RGS n'est pas une norme que l'ANSSI aurait rédigée de sa propre initiative. Il est prévu par l'article 9 de l'ordonnance n° 2005-1516 du 8 décembre 2005 relative aux échanges électroniques entre les usagers et les autorités administratives, et entre autorités administratives. L'article dit qu'un référentiel général de sécurité "fixe les règles que doivent respecter les fonctions des systèmes d'information" qui assurent l'identification, la signature électronique, la confidentialité et l'horodatage. Le même texte crée, à l'article 11, son jumeau pour l'interopérabilité, le RGI.

Le périmètre est écrit à l'article 1er de l'ordonnance. Sont des autorités administratives les administrations de l'État, les collectivités territoriales, les établissements publics à caractère administratif, les organismes gérant des régimes de protection sociale et les autres organismes chargés de la gestion d'un service public administratif. Le corps du RGS précise l'étendue matérielle : il "s'applique aux systèmes d'information mis en œuvre par les autorités administratives dans leurs relations entre elles et avec les usagers", et ajoute qu'il "peut aussi être considéré comme un recueil de bonnes pratiques pour tous les autres organismes". Une entreprise privée qui lit le RGS y trouve donc une méthode, pas une obligation. Un éditeur qui vend un téléservice à une commune, en revanche, hérite du sujet par contrat.

Le décret d'application est le décret n° 2010-112 du 2 février 2010, que le référentiel lui-même appelle "décret RGS". Il prévoit que le référentiel et ses mises à jour sont approuvés par arrêté du Premier ministre (article 2), et c'est l'arrêté du 13 juin 2014 qui a approuvé la version 2.0, toujours en vigueur. Un second arrêté, du 10 juin 2015, a prorogé les délais de mise en œuvre. La première version datait du 6 mai 2010. Deux versions en seize ans, dont la dernière a douze ans : la page RGS de l'ANSSI le présente comme un cadre stable ; seuls son annexe B1 sur les mécanismes cryptographiques (version 2.04, 2020) et un erratum de l'annexe A3 (2016) ont bougé depuis.

Un point que le RGS assume noir sur blanc : il "n'impose aucune technologie particulière et laisse aux autorités administratives le choix des mesures à mettre en œuvre". Ses règles techniques ne portent que sur la sécurisation des échanges, et sur quelques fonctions nommées, la certification, l'horodatage et l'audit. Tout le reste relève de la démarche de sécurisation que le décret organise sans la détailler. C'est ce qui distingue le RGS d'un référentiel comme SecNumCloud, qui liste des exigences vérifiables une à une, et ce qui le rapproche des logiques de gouvernance, risques et conformité où l'on prouve une décision plutôt qu'un état.

La démarche du décret RGS, en cinq étapes

L'article 3 du décret impose à l'autorité administrative d'identifier les risques qui pèsent sur son système, d'en déduire des objectifs de sécurité, puis les fonctions et mesures qui les satisfont. L'article 4 lui demande de recourir à des produits de sécurité et à des prestataires de services de confiance qualifiés. L'article 5 lui demande d'"attester formellement auprès des utilisateurs" que le système est protégé conformément à ces objectifs, et, pour un téléservice, de rendre cette attestation accessible aux usagers. Le RGS traduit ce bloc en une suite ordonnée, et prévoit une voie de rattrapage pour les systèmes déjà en production, ce qui est le cas de la plupart des téléservices qu'on homologue aujourd'hui.

Dans ce parcours, deux points passent souvent à la trappe. Le RGS recommande de s'appuyer sur l'ISO 27005 pour le cadre théorique de l'analyse de risques, et sur EBIOS pour sa mise en pratique ; la version 2014 cite encore EBIOS 2010, que l'ANSSI a depuis remplacée par EBIOS Risk Manager et ses cinq ateliers, méthode que le guide de l'homologation rend d'ailleurs obligatoire quand l'ANSSI est elle-même autorité d'homologation. Et lorsque le système manipule des certificats, c'est cette analyse de risques qui doit trancher les usages et les niveaux de sécurité, une, deux ou trois étoiles, à exiger.

L'homologation de sécurité : une décision, pas un document

Le corps du RGS le formule sans détour : les systèmes d'information qui entrent dans le champ de l'ordonnance "doivent faire l'objet, avant leur mise en service opérationnelle, d'une décision d'homologation de sécurité". Cette décision est prononcée par une autorité d'homologation désignée par l'autorité administrative responsable du système. Elle "atteste, au nom de l'autorité administrative, que le système d'information est protégé conformément aux objectifs de sécurité fixés et que les risques résiduels sont acceptés". Trois mots comptent dans cette phrase : risques résiduels acceptés. Homologuer n'est pas déclarer qu'un système est sûr. C'est signer qu'on connaît ce qui reste, et qu'on le prend.

Le référentiel lui-même renvoie, pour la méthode, au guide publié par l'ANSSI. Ce guide a changé. L'édition historique, connue sous le titre "L'homologation de sécurité en neuf étapes simples", a été remplacée par Le guide de l'homologation de sécurité des systèmes d'information, coécrit par l'ANSSI et la DINUM dans la collection "Gestion des risques cyber", déposé en avril 2025 et diffusé en version 2.2 datée de mars 2026. L'avant-propos de la DINUM en donne la raison sans ménagement : l'homologation était devenue "une démarche lourde, complexe voire contre-productive". La nouvelle version resserre le tout en quatre étapes, et module la charge documentaire selon la criticité et l'exposition du système.

Le dossier d'homologation, pièce par pièce

Le guide pose une règle que les dossiers épais violent presque tous : la documentation "doit exister pour le suivi et la sécurisation du système d'information, mais ne doit pas être spécifiquement rédigée pour la démarche d'homologation". Autrement dit, si le dossier d'architecture n'existait pas avant qu'on parle d'homologuer, le problème vient de bien plus loin que la démarche. Le dossier s'ouvre par un document d'accompagnement d'une à deux pages qui répond à une liste de questions, dont celle-ci, en toutes lettres : "Comment la sécurité du système d'information a-t-elle été éprouvée ?" Puis viennent, selon le niveau de démarche retenu, le dossier d'architecture technique, la matrice de conformité, l'analyse de risques, les procédures d'exploitation, les plans de maintien en condition opérationnelle et en condition de sécurité, le plan d'action, le plan de résilience, les audits et, pour un système déjà exploité, son historique d'incidents et d'homologations passées.

Sur la durée, le RGS ne fixe rien, et le guide comble le vide par une recommandation ferme : quand aucune réglementation n'impose de maximum, "l'ANSSI recommande fortement de ne pas dépasser trois ans". Un système dont le plan d'action est lourd "ne peut pas être homologué sur une période trop longue", une revue de sécurité doit avoir lieu au moins une fois par an, et le texte insiste : "il n'y a pas de renouvellement automatique d'une homologation". La décision sans date de fin aperçue en ouverture ne coche donc aucune de ces cases, même si elle en porte le titre, le tampon et la signature de la bonne autorité.

Certificats et prestataires : les niveaux d'étoiles

Quand une autorité administrative met en œuvre l'une des fonctions de sécurité du référentiel (authentifier un agent, signer un acte, chiffrer un échange, horodater un dépôt), elle doit s'appuyer sur des certificats électroniques délivrés par un prestataire de services de certification électronique, un PSCE, selon les politiques de certification type des annexes A2 (certificats de personne) et A3 (services applicatifs). Ces annexes distinguent "trois niveaux de sécurité, aux exigences croissantes : (*), (**) et (***)", et c'est l'autorité administrative qui détermine, usage par usage, le niveau requis. Le certificat dit à double usage, authentification et signature en un seul, n'existe qu'aux niveaux une et deux étoiles. L'horodatage relève d'un prestataire de services d'horodatage électronique, un PSHE, avec un niveau unique décrit à l'annexe A5.

Pour les prestataires, le chapitre 5 du référentiel organise la qualification par catégorie : un organisme de qualification accrédité par le COFRAC et habilité par l'ANSSI évalue la conformité aux annexes, et la qualification "est accordée pour une durée de trois ans".

La troisième ligne est celle qui concerne un pentester. L'annexe C du RGS est le référentiel d'exigences des prestataires d'audit, et couvre explicitement "les activités d'audit organisationnel, de code source, de configuration et d'architecture, ainsi que les tests d'intrusion". C'est ce référentiel, révisé depuis, qu'on appelle aujourd'hui la qualification PASSI. Autant le dire tout de suite : own2pwn n'est pas qualifié PASSI. Savoir si c'est rédhibitoire dépend du régime auquel le système est soumis et pas du seul RGS, et j'y reviens plus bas, tableau des régimes d'homologation à l'appui.

Ce qu'eIDAS change, et ce qu'il ne change pas

Le règlement européen (UE) n° 910/2014, dit eIDAS, s'applique depuis le 1er juillet 2016. Il définit les services de confiance, les prestataires qualifiés, l'organe de contrôle que chaque État membre désigne (article 17), et les listes de confiance nationales (article 22). En France, l'ANSSI est cet organe de contrôle : elle prononce les décisions de qualification après audit par un organisme d'évaluation accrédité, audit qu'un prestataire qualifié doit repasser "au moins tous les vingt-quatre mois". Beaucoup en ont conclu que le RGS était mort. L'ANSSI dit l'inverse, sur une page dédiée à l'articulation entre eIDAS et le RGS : le référentiel "continue aussi à s'appliquer aux échanges entre autorités administratives et usagers, à deux exceptions près".

Les deux exceptions sont des obligations d'acceptation. Une autorité administrative doit accepter les moyens d'identification électronique non conformes au RGS mais répondant à l'article 6 du règlement, et les signatures ou cachets non conformes au RGS mais répondant à son article 27. Pour le reste, les deux cadres se recouvrent sans se confondre : les certificats d'authentification de machines ou de signature de code n'existent que dans le RGS, l'envoi recommandé électronique n'existe que dans eIDAS. D'où la recommandation de l'ANSSI aux administrations qui ont besoin d'un service de certification ou d'horodatage : choisir un prestataire qualifié "à la fois au sens du RGS et du règlement eIDAS". La même page annonce des travaux de mise à jour du RGS pour simplifier l'articulation. Au moment de la rédaction (septembre 2026), la version en vigueur reste la 2.0 de 2014.

Ce que NIS2 change pour les administrations et les collectivités

La directive (UE) 2022/2555 fait entrer l'administration publique dans son annexe I, secteur n° 10, avec deux types d'entités : celles des pouvoirs publics centraux et celles du niveau régional, telles que chaque État membre les définit. L'article 3, paragraphe 1, point d) range d'office les entités des pouvoirs publics centraux parmi les entités essentielles, la catégorie la plus contrainte. Pour le niveau local, l'article 2, paragraphe 5, point a) laisse aux États membres la faculté d'y appliquer la directive. Et l'article 2, paragraphe 7, exclut les entités de l'administration publique qui exercent leurs activités dans les domaines de la sécurité nationale, de la sécurité publique, de la défense ou de l'application de la loi.

La France a choisi d'user de cette faculté. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, déposé au Sénat le 15 octobre 2024 et adopté par lui en première lecture le 12 mars 2025, "fait en outre le choix d'inclure dans la transposition près de 1 500 collectivités territoriales, groupements de collectivités et organismes placés sous leur tutelle", selon la présentation du Sénat. La commission spéciale de l'Assemblée nationale a déposé son rapport le 10 septembre 2025. Au moment de la rédaction (septembre 2026), je ne trouve pas de loi promulguée sur Legifrance et le dossier législatif s'arrête à ce rapport : la navette n'est pas close, le texte peut encore être inscrit à l'ordre du jour d'une prochaine session, et les seuils exacts qui feront d'une commune ou d'une intercommunalité une entité essentielle ou importante restent à lire dans le texte définitif. Tout ce qui suit sur le droit français est donc à prendre au conditionnel. Le cadre général de la directive, lui, est détaillé dans le guide NIS2, qui est concerné et quelles obligations.

Ce qui ne dépend pas de la loi française, c'est la nature de l'obligation. Le RGS demande une décision ; NIS2 demande des mesures, une supervision et des sanctions. L'article 21, paragraphe 2, liste dix familles de mesures qu'une entité doit prendre "au moins", et deux d'entre elles absorbent presque entièrement la logique d'homologation : le point a), les politiques d'analyse des risques et de sécurité des systèmes d'information, et le point f), "des politiques et des procédures pour évaluer l'efficacité des mesures de gestion des risques en matière de cybersécurité". Une administration qui homologue sérieusement dispose déjà, pour chaque système, d'une analyse de risques, d'un plan d'action et d'audits datés. Une administration qui homologue sur dossier n'a que le dossier. L'ANSSI a mis en circulation, en version de travail, un référentiel d'objectifs pour NIS2, le ReCyF, qui devrait rendre la différence visible dès les premiers contrôles.

Un pentest comme pièce du dossier d'homologation

Retour à la question du document d'accompagnement : comment la sécurité du système a-t-elle été éprouvée ? Le guide y consacre une section entière. Une fois les mesures appliquées, "il convient de tester la robustesse d'un système d'information face aux menaces numériques par l'intermédiaire d'une série d'audits". Il en distingue six types réglementaires (conformité, organisationnel, configuration, architecture, technique, TEMPEST) et en ajoute trois "adaptés à la nature du système" : les revues de code, "les tests de pénétration ou d'intrusion (pentest)" et les primes à la recherche de bogues, le bug bounty. Le partage est moins net qu'il n'y paraît : l'audit technique y inclut d'ailleurs explicitement l'intrusion, puisqu'il "regroupe tous les audits ayant attrait aux éléments techniques (architecture, configuration, intrusion)". Trois exigences de forme accompagnent la liste, et elles disqualifient pas mal de rapports : l'audit "doit être effectué par des auditeurs indépendants et de confiance", "le temps consacré à un audit doit être suffisant", et "l'auditeur doit être libre de proposer ses propres scénarios".

Cette dernière phrase est celle qui sépare un pentest d'une passe de scanner. Un scanner exécute les scénarios de son éditeur ; un pentester en invente à partir de ce qu'il voit, et c'est précisément ce que le guide attend, puisqu'il assigne aux audits le rôle d'"identifier des scénarios qui n'auraient pas été pris en compte lors de l'analyse de risque". Dans un dossier d'homologation, le rapport nourrit l'analyse de risques, dont il révise la vraisemblance de certains scénarios, et le plan d'action, où chaque vulnérabilité doit devenir une action datée, mesurable et attribuée. Sur la manière de commander ce test et de choisir entre boîte noire et boîte blanche, le guide du pentest en entreprise, quand et quel type commander s'applique sans changement à un téléservice public.

Reste la question de la qualification du prestataire. Pour un système d'information d'importance vitale, le tableau du guide est sans ambiguïté : PASSI obligatoire, et own2pwn ne peut pas tenir ce rôle. Pour un téléservice soumis au seul RGS, le référentiel demande de recourir à des prestataires qualifiés "ou, à défaut", de s'assurer de leur conformité et de l'attester auprès de l'ANSSI ; le guide, lui, n'impose aucune identité d'auditeur pour ce régime. C'est l'autorité d'homologation qui tranche, et elle tranche d'autant plus facilement que le rapport respecte les trois exigences de forme ci-dessus, cadre le périmètre exactement sur le système homologué, date chaque constat, et prévoit un retest pour documenter la levée des réserves dans la fenêtre de douze mois. Un pentest web en boîte noire conçu pour ça livre un rapport que le comité peut verser tel quel, et un retest qui ferme la boucle devant la commission suivante.

À retenir

• Le RGS ANSSI est un cadre légal, pas un guide : article 9 de l'ordonnance 2005-1516, décret 2010-112, version 2.0 approuvée par arrêté du 13 juin 2014. Il s'impose aux autorités administratives pour leurs échanges entre elles et avec les usagers, et n'est qu'un recueil de bonnes pratiques pour les autres.
• L'homologation est une décision d'acceptation des risques résiduels, prononcée avant la mise en service par une autorité désignée, rendue accessible aux usagers pour un téléservice, et sans renouvellement automatique. Trois ans au plus, selon l'ANSSI.
• Le guide ANSSI-DINUM de 2025 remplace les neuf étapes par quatre : comité, niveau de démarche et dossier, avis, commission. Un avis sous réserve ouvre douze mois pour corriger.
• Les étoiles vivent dans les annexes A2 et A3 : trois niveaux de certificats fixés par l'analyse de risques, prestataires PSCE, PSHE et audit qualifiés pour trois ans.
• eIDAS n'a pas abrogé le RGS : il oblige seulement à accepter les identifications de l'article 6 et les signatures de l'article 27, et l'ANSSI recommande la double qualification.
• NIS2 place les administrations centrales en entités essentielles et laisse le niveau local au choix de la France, qui a annoncé près de 1 500 collectivités ; au moment de la rédaction (septembre 2026), la loi de transposition n'est pas promulguée et le texte reste en navette.

Un téléservice qui attend sa commission avec la case "sécurité éprouvée" encore vide n'a pas besoin d'un document de plus dans son dossier. Un test d'intrusion web cadré sur le périmètre homologué remplit cette case avec des constats datés, et le retest inclus documente la levée des réserves devant la commission suivante. Reste à choisir qui cadre ce test : mieux vaut la personne qui signera la décision d'homologation que le prestataire qui exploite le téléservice.

Questions fréquentes sur le RGS et l'homologation