RGS (référentiel général de sécurité) : guide complet 2026

Le RGS (référentiel général de sécurité) est le cadre réglementaire français qui fixe les règles de sécurité applicables aux systèmes d'information des autorités administratives lorsqu'elles échangent des informations par voie électronique, entre elles ou avec les usagers. Créé par l'ordonnance n° 2005-1516 du 8 décembre 2005 et précisé par le décret n° 2010-112 du 2 février 2010, il impose avant tout une analyse de risques conclue par une homologation de sécurité, et il encadre les fonctions d'identification, de signature électronique, de confidentialité et d'horodatage. Sa version 2.0, en vigueur depuis le 1er juillet 2014, repose sur des annexes techniques (certificats, cryptographie, audit) et sur la qualification des produits et des prestataires, pilotée par l'ANSSI. En 2026, le RGS reste pleinement applicable, mais ses règles cryptographiques viennent d'être actualisées pour intégrer la menace quantique. Ce guide détaille les textes, les obligations, les annexes et une feuille de route de mise en conformité, en lien avec le système de management présenté dans notre guide complet de la norme ISO 27001.

Qu'est-ce que le RGS (référentiel général de sécurité) ?

Le RGS répond à une question simple : comment un usager peut-il faire confiance à une démarche administrative réalisée en ligne ? Selon l'article 1er du décret n° 2010-112, le référentiel fixe les règles auxquelles les systèmes d'information des autorités administratives doivent se conformer pour protéger la confidentialité et l'intégrité des informations échangées, la disponibilité et l'intégrité des systèmes, ainsi que l'identification de leurs utilisateurs.

Ces règles sont organisées par niveaux de sécurité, définis pour chaque fonction de sécurité. Une administration ne choisit donc pas une liste de mesures au hasard : elle part de ses risques, en déduit les fonctions nécessaires, puis retient pour chacune le niveau prévu par le référentiel. La conformité d'un produit ou d'un service à ce niveau peut ensuite être attestée par une qualification.

Un référentiel d'obligations, pas une norme de certification

Le RGS se distingue de la norme ISO/IEC 27001, qui est volontaire et conduit à la certification d'un système de management par un organisme accrédité. Le référentiel général de sécurité est un texte réglementaire : il s'impose aux autorités administratives, sans « certificat RGS » délivré à l'administration elle-même. La preuve de conformité d'un système repose sur sa décision d'homologation ; seuls les produits et les services de confiance peuvent être qualifiés.

Pour les organismes qui ne sont pas soumis au texte, l'Agence nationale de la sécurité des systèmes d'information (ANSSI) présente le RGS comme un guide de bonnes pratiques conforme à l'état de l'art. De nombreuses entreprises reprennent ainsi sa logique d'homologation ou ses exigences cryptographiques dans leurs propres politiques, sans y être juridiquement tenues, notamment lorsqu'elles travaillent pour le secteur public.

Les fonctions de sécurité couvertes

L'ordonnance de 2005 cite quatre fonctions de sécurité de manière non limitative. Le corps du RGS v2.0 et ses annexes les déclinent en exigences techniques et organisationnelles, auxquelles s'ajoute un volet consacré à l'audit de sécurité des systèmes d'information :

• l'identification et l'authentification des usagers, des agents et des serveurs, souvent fondées sur des certificats électroniques ;
• la signature électronique, et par extension le cachet électronique d'une personne morale, pour garantir l'origine et l'intégrité d'un document ;
• la confidentialité, assurée par le chiffrement des échanges et des données stockées ;
• l'horodatage électronique, qui prouve l'existence d'une donnée à une date donnée grâce à des contremarques de temps ;
• l'audit de sécurité, encadré par un référentiel d'exigences applicable aux prestataires d'audit (annexe C).

Le socle juridique : ordonnance 2005-1516, décret 2010-112 et arrêtés

Le RGS repose sur une chaîne de textes hiérarchisés. Comprendre cette chaîne évite deux erreurs fréquentes : croire que le RGS est une simple recommandation de l'Agence nationale de la sécurité des systèmes d'information (ANSSI), ou au contraire penser que chaque guide technique publié depuis 2014 a automatiquement la même valeur juridique que le référentiel approuvé par arrêté.

L'article 9 de l'ordonnance n° 2005-1516

L'article 9 de l'ordonnance du 8 décembre 2005, que l'ANSSI surnomme « ordonnance RGS », pose trois principes. D'abord, un référentiel fixe les règles des fonctions qui contribuent à la sécurité des informations échangées par voie électronique. Ensuite, toute autorité administrative qui met en place un système d'information détermine les fonctions de sécurité nécessaires, choisit leur niveau parmi ceux prévus et respecte les règles correspondantes.

Enfin, le troisième alinéa permet aux produits de sécurité et aux prestataires de services de confiance d'obtenir une qualification attestant leur conformité à un niveau du RGS. Pour les prestataires, cette délivrance peut être confiée à un organisme privé habilité. L'article 1er de la même ordonnance définit le téléservice comme un système d'information par lequel l'usager accomplit en ligne une démarche ou une formalité administrative.

Le décret n° 2010-112, colonne vertébrale du dispositif

Le décret n° 2010-112 du 2 février 2010 précise l'ordonnance en sept chapitres : le référentiel lui-même (articles 1 et 2), les fonctions de sécurité des systèmes d'information (articles 3 à 5), la qualification des produits (articles 6 à 9), celle des prestataires de services de confiance (articles 10 à 19), la validation des certificats électroniques (articles 20 à 23), le référencement (article 24) et des dispositions diverses.

Son article 2, modifié en 2019, prévoit que le RGS et ses mises à jour sont approuvés par arrêté du Premier ministre publié au Journal officiel. L'ANSSI concourt à son élaboration en liaison avec la direction interministérielle du numérique (DINUM), et le référentiel doit être mis à la disposition du public par voie électronique. Cette procédure explique pourquoi une simple publication de guide ne modifie pas, à elle seule, le texte approuvé.

Les versions du RGS : de la v1.0 de 2010 à la v2.0 de 2014

La première version du référentiel général de sécurité (RGS) a été approuvée par un arrêté du 6 mai 2010. La version 2.0, toujours en vigueur, l'a été par l'arrêté du 13 juin 2014, publié au Journal officiel du 24 juin et entré en vigueur le 1er juillet 2014. Ce texte a aussi fixé les modalités de la procédure de validation des certificats électroniques délivrés aux autorités administratives et à leurs agents.

Une mesure transitoire, modifiée par un arrêté du 10 juin 2015, a permis de continuer à émettre pendant deux ans des certificats et des contremarques de temps conformes aux annexes de la version 1.0. Les autorités administratives devaient les accepter pendant leur durée de vie, plafonnée à trois ans. En 2026, ces délais sont échus : seuls comptent les documents de la version 2.0 et leurs mises à jour publiées.

Qui doit appliquer le RGS en 2026 ?

Le RGS vise d'abord les autorités administratives au sens de l'ordonnance de 2005. La page de l'ANSSI consacrée au RGS en dresse la liste, qui dépasse largement le seul périmètre des ministères :

• les administrations de l'État et leurs services déconcentrés ;
• les collectivités territoriales, des communes aux régions ;
• les établissements publics à caractère administratif ;
• les organismes gérant des régimes de protection sociale ;
• les autres organismes chargés de la gestion d'un service public administratif ;
• les commissions de coordination des actions de prévention des expulsions locatives.

Le texte s'adresse aussi aux organismes publics et privés qui fournissent des produits de sécurité ou des services de confiance, puisqu'il détaille les normes et exigences qu'ils doivent respecter. Il concerne enfin les organismes chargés de la qualification. Selon l'ANSSI, c'est l'Agence elle-même qui qualifie les produits, tandis que les services de confiance sont qualifiés par LSTI, organisme accrédité par le Cofrac et habilité par l'ANSSI.

Le guide d'achat publié par l'ANSSI en 2015 précise le périmètre : les règles sont obligatoires pour les autorités administratives qui échangent par voie électronique, notamment via des téléservices, et leur application est recommandée pour les autres systèmes d'information, y compris ceux de niveau Diffusion Restreinte. Le RGS ne s'applique pas aux systèmes traitant d'informations classifiées, régis par l'instruction générale interministérielle n° 1300 et par des produits agréés.

Une entreprise privée n'est donc pas directement assujettie. Elle le devient en pratique lorsqu'elle opère un téléservice pour une administration, qui lui transfère ses exigences par contrat, ou lorsqu'elle sollicite une qualification de service de confiance. L'ANSSI rappelle en revanche que l'obligation de recourir à des produits conformes ne peut pas être imposée aux citoyens ni aux entreprises qui utilisent le téléservice.

La démarche de conformité imposée par le RGS

Le cœur opérationnel du RGS se trouve dans les articles 3 à 5 du décret n° 2010-112. L'article 3 impose à l'autorité administrative d'identifier l'ensemble des risques pesant sur le système et ses informations, de fixer des objectifs de sécurité proportionnés, puis d'en déduire les fonctions de sécurité et leur niveau. Elle doit aussi réexaminer régulièrement la sécurité du système au regard de l'évolution des risques.

L'article 4 traite des moyens : l'autorité recourt à des produits et à des prestataires qualifiés, ou à tout autre produit ou prestataire dont elle a vérifié la conformité au référentiel. L'article 5 conclut la démarche : l'administration atteste formellement auprès des utilisateurs que le système est protégé conformément aux objectifs fixés. Le corps du RGS v2.0 traduit ces obligations en une démarche en cinq étapes :

1. Analyser les risques du système d'information, en tenant compte de ses conditions d'emploi, des informations traitées et des menaces, par exemple avec la méthode EBIOS Risk Manager.
2. Fixer les objectifs de sécurité en disponibilité, intégrité, confidentialité et identification des utilisateurs, à la mesure du besoin de protection.
3. Choisir les fonctions de sécurité et leur niveau, puis les mesures et les produits qui les mettent en œuvre, de préférence qualifiés.
4. Homologuer le système par une décision formelle de l'autorité, appuyée sur un dossier, avant sa mise en service.
5. Assurer le suivi opérationnel : maintien en condition de sécurité, contrôles, réexamen des risques et renouvellement de l'homologation.

Le chapitre 7 du référentiel complète ces exigences par des recommandations sur la méthodologie, les procédures et l'organisation de la sécurité des systèmes d'information. Elles ne sont pas obligatoires, mais elles constituent une base utile pour les petites collectivités qui ne disposent pas d'une politique de sécurité structurée et cherchent un cadre de départ cohérent avec la réglementation.

L'homologation de sécurité, obligation centrale du RGS

Pour l'Agence nationale de la sécurité des systèmes d'information (ANSSI), l'homologation est la première et la plus importante obligation du RGS. Elle débute par une analyse de risques qui détermine les besoins propres au système étudié, puis les mesures nécessaires et suffisantes pour y répondre. La décision d'homologation matérialise l'acceptation, par une autorité identifiée, des risques résiduels qui subsistent après ces mesures.

Depuis une modification de 2016, l'article 5 du décret précise que, pour un téléservice, cette attestation est rendue accessible aux usagers selon les modalités prévues à l'article L. 112-10 du code des relations entre le public et l'administration pour la décision de création du service. Autrement dit, l'homologation d'un téléservice ne reste pas un document interne : son existence doit pouvoir être portée à la connaissance des usagers.

Le guide d'homologation ANSSI–DINUM de 2025 : ce qui change

Fin mars 2025, l'Agence nationale de la sécurité des systèmes d'information (ANSSI) et la direction interministérielle du numérique (DINUM) ont publié un nouveau guide de l'homologation de sécurité, qui remplace la démarche en neuf étapes de 2014. Le processus tient désormais en quatre étapes : constituer le comité d'homologation, identifier le niveau de la démarche selon la criticité et l'exposition du système, évaluer les pièces du dossier pour émettre un avis, puis organiser la commission d'homologation.

Le guide introduit trois niveaux de démarche progressifs et supprime les homologations provisoires au profit d'un type unique, dont seule la durée varie. Les systèmes peu critiques et peu exposés peuvent suivre une démarche simplifiée fondée sur la confiance. Le guide admet aussi qu'un système soit homologué alors que des risques jugés acceptables par l'autorité ne sont pas encore traités ; la décision sert alors également à valider le plan d'action de renforcement.

Pour les systèmes soumis au référentiel général de sécurité (RGS), le guide ne fixe aucune exigence sur l'identité de l'autorité d'homologation, mais l'ANSSI y recommande de ne pas dépasser trois ans de validité. Il mentionne des audits organisationnels, de configuration et d'architecture, confiés à un prestataire d'audit de la sécurité des systèmes d'information (PASSI) qualifié. Pour les obligations propres aux opérateurs régulés, consultez notre analyse de l'homologation ANSSI applicable aux OIV et aux OSE.

MonServiceSécurisé : outiller l'homologation RGS

MonServiceSécurisé est un service gratuit, en ligne et collaboratif, développé par l'Agence nationale de la sécurité des systèmes d'information (ANSSI) avec BetaGouv et la direction interministérielle du numérique (DINUM). Il s'adresse aux entités publiques et aux prestataires privés qui travaillent pour elles. L'outil évalue les besoins de sécurité d'un service, propose des mesures personnalisées, calcule un indice cyber indicatif et produit un dossier de décision d'homologation prêt à être signé.

Ces chiffres montrent que l'homologation n'est plus réservée aux grands ministères : les collectivités et les opérateurs publics de services numériques s'en sont emparés. L'outil ne remplace pas pour autant l'analyse de risques d'un système complexe, ni l'audit d'architecture d'un téléservice exposé sur Internet qui traite des données sensibles.

Niveaux de sécurité et qualification des produits et prestataires

Le RGS associe chaque fonction de sécurité à des niveaux. Pour les services de confiance, l'ANSSI indique que le référentiel prévoit plusieurs niveaux de qualification croissants, notés une, deux ou trois étoiles, pour répondre à des enjeux de sécurité distincts. Le niveau retenu découle de l'analyse de risques : un portail d'information n'exige pas le même niveau d'authentification qu'un téléservice manipulant des données fiscales ou de santé.

La qualification des produits de sécurité par l'ANSSI

Selon les articles 6 à 9 du décret n° 2010-112, la demande de qualification d'un produit est adressée à l'Agence nationale de la sécurité des systèmes d'information (ANSSI) par un commanditaire, fabricant, fournisseur ou autorité administrative. Le produit est évalué au regard des règles du RGS, dans le cadre prévu par le décret de 2002 relatif à l'évaluation et à la certification de la sécurité des technologies de l'information.

Le directeur général de l'ANSSI délivre ensuite la qualification pour l'un des niveaux fixés par le référentiel. L'attestation précise les objectifs de sécurité satisfaits, sa durée de validité, le degré de qualification obtenu et, le cas échéant, des conditions ou des réserves. Tout changement de circonstances peut conduire à suspendre ou à retirer la qualification, après que le commanditaire a pu présenter ses observations.

La qualification RGS des prestataires de services de confiance

Pour les prestataires de services de confiance (PSCo), le décret n° 2010-112 organise un schéma délégué. Le directeur général de l'Agence nationale de la sécurité des systèmes d'information (ANSSI) habilite des organismes de qualification, après vérification de leur accréditation par le Cofrac et d'un audit de leur compétence technique. L'habilitation, renouvelable, vaut trois ans au plus. Le prestataire s'adresse ensuite à l'un de ces organismes, qui évalue ses fonctions de sécurité et transmet un rapport à l'ANSSI.

La qualification d'un prestataire est valable trois ans au maximum, renouvelable, et les attestations délivrées sont rendues publiques. Les administrations de l'État qui recourent à un prestataire qualifié doivent en informer l'ANSSI. Surtout, recourir à un service qualifié au titre du RGS fait présumer la conformité au niveau de qualification concerné, ce qui simplifie considérablement la preuve lors de l'homologation.

La qualification n'est pas pour autant obligatoire : l'article 4 du décret autorise tout autre produit ou prestataire, à condition que l'autorité administrative se soit assurée de sa conformité. La charge de la preuve repose alors sur elle, avec des analyses ou des audits à documenter. La même logique de visa de sécurité se retrouve dans la qualification SecNumCloud des offres d'informatique en nuage, qui relève d'un référentiel distinct.

Les annexes A et C du RGS v2.0 : certificats, horodatage et audit

Le référentiel général de sécurité RGS se compose d'un corps de texte et de neuf annexes. Les annexes A traitent des certificats électroniques et de l'horodatage, les annexes B de la cryptographie et l'annexe C des prestataires d'audit. Le tableau suivant résume leur objet et leur version de référence selon la page documentaire de l'ANSSI, consultée en novembre 2026.

L'annexe A1 s'adresse aux administrations qui déploient des téléservices nécessitant des certificats électroniques. Les annexes A2 à A5 visent les prestataires qui souhaitent être qualifiés : A2 et A3 décrivent les politiques de certification types, A4 regroupe les règles communes sur les profils et les algorithmes, et A5 fixe la politique d'horodatage type des prestataires qui délivrent des contremarques de temps.

Pour les certificats serveur TLS reconnus par les navigateurs, l'ANSSI indique qu'en cas d'incompatibilité entre le RGS et les exigences du CA/Browser Forum, ces dernières priment. Les incompatibilités et les solutions retenues doivent être signalées à l'adresse RGS@ssi.gouv.fr avant leur mise en œuvre. Cette précision évite de bloquer un téléservice à cause d'un profil de certificat refusé par les navigateurs.

L'annexe C contient le référentiel d'exigences des prestataires d'audit de la sécurité des systèmes d'information (PASSI). Ce référentiel a depuis évolué dans le cadre des qualifications de l'ANSSI, qui publie des modalités de transition vers ses versions plus récentes. Avant de commander un audit pour un dossier d'homologation, vérifiez donc la version du référentiel PASSI au titre de laquelle le prestataire est qualifié.

Annexes cryptographiques B1 à B3 : ce qui change avec le guide ANSSI 2026

Les annexes B1 à B3 du RGS s'adressent à la fois aux autorités administratives, aux prestataires de services de confiance et aux développeurs de produits. Elles fixent les règles et recommandations applicables aux mécanismes cryptographiques : choix et dimensionnement des algorithmes (B1, version 2.04 de janvier 2020), gestion des clés (B2, version 2.00 de juin 2012) et mécanismes d'authentification (B3, version 1.0 de janvier 2010).

Le 19 mars 2026, l'Agence nationale de la sécurité des systèmes d'information (ANSSI) a publié deux documents sur les mécanismes cryptographiques : un guide de sélection d'algorithmes et la version 3.00 des « Règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques », datée du 20 mars 2026. L'Agence présente ce second document comme une évolution des règles issues du RGS, qui intègre la cryptographie post-quantique et peut servir de référentiel pour évaluer des produits.

Les règles et recommandations à retenir

Le document distingue des règles, dont le respect conditionne la sécurité d'un mécanisme, et des recommandations, qui décrivent l'état de l'art avec une marge de sécurité confortable. Des règles et recommandations dites post-quantiques s'y ajoutent lorsqu'une résistance aux ordinateurs quantiques est visée. Les points suivants concernent directement les téléservices et les infrastructures de gestion de clés :

• la taille minimale des clés symétriques est de 128 bits, et au moins 192 bits sont recommandés lorsqu'une sécurité post-quantique est visée ;
• une primitive de chiffrement par bloc doit traiter des blocs d'au moins 128 bits, ce qui rend le Triple-DES non conforme ;
• les fonctions de hachage doivent produire des empreintes d'au moins 256 bits : SHA-1 n'est pas conforme, et 384 bits sont recommandés pour une sécurité post-quantique ;
• le chiffrement authentifié AES-GCM est conforme, à condition de ne jamais réutiliser un vecteur d'initialisation sous une même clé ;
• l'ANSSI recommande d'employer des mécanismes éprouvés et reconnus par la communauté académique.

La recommandation la plus structurante porte sur le long terme : dès qu'un mécanisme doit être utilisé au-delà du 1er janvier 2030, ou qu'il existe un risque d'attaque rétroactive, l'ANSSI recommande de viser une sécurité post-quantique. Le scénario visé est celui du « store now, decrypt later » : un attaquant enregistre aujourd'hui des échanges chiffrés pour les déchiffrer plus tard, lorsqu'il disposera d'un ordinateur quantique suffisant.

Le document ne contient volontairement aucun tableau récapitulatif des tailles minimales : l'ANSSI estime qu'une valeur isolée serait source d'erreur. Il vise une validité d'au moins quinze ans et prévoit une mise à jour tous les deux à cinq ans. Au moment de la rédaction, la page documentaire du RGS 2.0 référençait encore la version 2.04 de l'annexe B1 : précisez dans vos marchés et vos dossiers d'homologation la version que vous retenez.

Contrôler la cryptographie d'un téléservice avant l'audit

Avant l'audit de configuration attendu pour une homologation au titre du référentiel général de sécurité (RGS), l'équipe d'exploitation peut vérifier elle-même que le téléservice respecte les règles cryptographiques de l'Agence nationale de la sécurité des systèmes d'information (ANSSI) : signature et taille de clé du certificat, protocoles TLS et suites de chiffrement acceptés. Les commandes suivantes sont à exécuter uniquement sur vos propres services ou dans le cadre d'une mission autorisée ; le domaine utilisé est fictif.

openssl s_client -connect teleservice.collectivite.example:443 -servername teleservice.collectivite.example </dev/null 2>/dev/null | openssl x509 -noout -text | grep -E "Issuer:|Subject:|Not After|Signature Algorithm|Public-Key"

testssl.sh --protocols --server-defaults --cipher-per-proto teleservice.collectivite.example

nmap --script ssl-enum-ciphers -p 443 teleservice.collectivite.example

La première commande affiche l'émetteur, la date d'expiration, l'algorithme de signature et la taille de la clé publique du certificat. Les deux suivantes listent les protocoles et suites acceptés, ce qui permet de repérer un Triple-DES, une empreinte SHA-1 ou un protocole obsolète. Ces constats alimentent le plan d'action, mais ne remplacent pas l'audit de configuration attendu dans le dossier d'homologation.

RGS et eIDAS : articuler les deux cadres des services de confiance

Le règlement européen n° 910/2014, dit eIDAS, s'applique aux services de confiance depuis le 1er juillet 2016 et a été révisé en 2024 par le règlement (UE) 2024/1183. Il ne remplace pas le RGS. Selon l'analyse de l'ANSSI sur l'articulation entre eIDAS et le RGS, le référentiel continue de s'appliquer aux échanges entre autorités administratives et usagers.

Deux exceptions s'imposent toutefois aux administrations. Elles doivent accepter les moyens d'identification électronique non conformes au RGS qui remplissent les conditions de l'article 6 d'eIDAS, ainsi que les signatures et cachets électroniques répondant aux conditions fixées par le règlement pour les services publics (article 27 pour les signatures, article 37 pour les cachets). Un téléservice ne peut donc pas écarter une telle signature au seul motif qu'elle ne relève pas du RGS.

Les deux textes n'ont pas le même périmètre. Le RGS couvre les échanges entre administrations et avec le public, prévoit trois niveaux de qualification et traite des certificats d'authentification de personnes et de machines, de chiffrement et de signature de code, absents d'eIDAS. Le règlement couvre en revanche la validation et la conservation des signatures et cachets, ainsi que l'envoi recommandé électronique, que le RGS ne traite pas.

Le règlement eIDAS n'oblige pas les administrations à recourir à des services qualifiés ou à des moyens d'identification notifiés : il fixe surtout des règles d'interopérabilité et de reconnaissance mutuelle. Pour un besoin de certification ou d'horodatage qualifié, l'ANSSI recommande de choisir un service qualifié à la fois au titre du RGS et d'eIDAS, et elle indique que des travaux de mise à jour du RGS sont menés pour simplifier cette articulation.

RGS, PSSIE, ISO 27001 : positionner le référentiel parmi les cadres connexes

Le RGS est souvent confondu avec d'autres cadres de sécurité. La politique de sécurité des systèmes d'information de l'État (PSSIE), instituée par la circulaire du Premier ministre n° 5725/SG du 17 juillet 2014, fixe un socle de règles pour les seuls systèmes de l'État. Le RGS, lui, vise toutes les autorités administratives, collectivités comprises, et se concentre sur les échanges électroniques et les fonctions de sécurité associées.

Ces cadres se complètent plus qu'ils ne s'opposent. Une collectivité certifiée ISO/IEC 27001 dispose déjà d'une analyse de risques, d'une déclaration d'applicabilité et d'un pilotage des mesures, que le guide d'homologation de 2025 rapproche explicitement de son propre suivi des mesures. Elle doit néanmoins produire une décision d'homologation propre à chaque téléservice, car la certification porte sur un système de management, et non sur un système d'information.

Les entreprises privées rencontrent plutôt des référentiels sectoriels fondés sur une logique voisine d'exigences et de preuves. C'est le cas du référentiel de maturité cyber de la DGA pour la défense ou du référentiel AERO EXCELLENCE pour la filière aéronautique. Un fournisseur qui travaille à la fois pour l'administration et pour ces filières gagne à mutualiser analyses de risques, cartographie et preuves d'audit.

Feuille de route : mettre un téléservice en conformité avec le RGS

La mise en conformité d'un téléservice suit une trajectoire assez stable d'un projet à l'autre. L'ordre ci-dessous reprend les obligations du décret n° 2010-112 et les étapes du guide d'homologation de 2025 publié par l'Agence nationale de la sécurité des systèmes d'information (ANSSI) et la DINUM, en les traduisant en livrables concrets pour une direction des systèmes d'information :

1. Inventorier les téléservices et les systèmes d'échange concernés, puis désigner pour chacun l'autorité d'homologation et le responsable de la sécurité.
2. Cartographier le système selon trois vues, métier, applicative et infrastructure, en distinguant le périmètre homologué de son écosystème (hébergeur, API, prestataires).
3. Analyser les risques avec une méthode reconnue comme EBIOS Risk Manager, puis formaliser les objectifs de sécurité.
4. Choisir les fonctions et leurs niveaux (une, deux ou trois étoiles), puis sélectionner des produits et prestataires qualifiés en vérifiant leurs attestations.
5. Aligner la cryptographie sur la version 3.00 du guide ANSSI et inscrire la migration post-quantique dans le cycle de renouvellement.
6. Faire auditer l'organisation, la configuration et l'architecture par un prestataire PASSI qualifié, puis traiter les écarts majeurs.
7. Homologuer en commission, signer la décision et rendre l'attestation accessible aux usagers.
8. Maintenir la sécurité, suivre le plan d'action et réexaminer l'homologation à chaque changement majeur, et au plus tard après trois ans comme le recommande l'ANSSI.

Lorsqu'un téléservice est hébergé chez un fournisseur d'informatique en nuage, la frontière de responsabilité doit être explicite : le guide de 2025 rappelle que le périmètre homologué correspond au périmètre de responsabilité de l'autorité, l'hébergeur relevant de l'écosystème. Notre checklist d'audit de sécurité cloud aide à recueillir les garanties contractuelles et techniques à joindre au dossier.

Retour terrain : Cas typique rencontré en mission — une collectivité ouvre un téléservice de demandes administratives sous la pression du calendrier, puis engage la démarche RGS a posteriori, sur quelques mois. L'audit relève classiquement une analyse de risques restée générique, des comptes d'administration partagés chez l'hébergeur et une configuration TLS tolérant des suites obsolètes. L'autorité homologue alors pour une durée réduite, avec un plan d'action daté et suivi en commission : une décision lucide vaut mieux qu'une homologation de façade.

Erreurs fréquentes et points de vigilance en 2026

Les écarts relevés autour du RGS ne sont pas toujours techniques. Ils proviennent souvent d'une lecture documentaire du texte, d'un suivi insuffisant des qualifications ou d'une confusion entre les cadres réglementaires. Les points suivants méritent une vérification systématique lors d'une revue de conformité ou d'un renouvellement d'homologation :

• traiter l'homologation comme une signature de fin de projet, sans analyse de risques à jour ni plan d'action suivi ;
• oublier de rendre l'attestation accessible aux usagers d'un téléservice, pourtant prévue par l'article 5 du décret ;
• laisser expirer la qualification d'un prestataire de certification ou d'horodatage sans clause de renouvellement ;
• conserver des suites TLS ou des certificats reposant sur SHA-1, le Triple-DES ou des clés symétriques de moins de 128 bits ;
• refuser des signatures ou des moyens d'identification conformes à eIDAS au motif qu'ils ne relèvent pas du RGS ;
• reporter la réflexion post-quantique alors que certaines données doivent rester confidentielles bien au-delà de 2030.

Le dernier point est souvent sous-estimé. Un téléservice qui collecte des pièces justificatives ou des données sociales conserve parfois ces informations pendant de longues années. Si les échanges sont interceptés aujourd'hui, leur confidentialité dépend de la robustesse future des mécanismes d'échange de clés. Inventorier dès maintenant les usages cryptographiques critiques permet de planifier la transition sans refonte précipitée.

Retour terrain : Cas typique rencontré en mission — en préparant un audit, je constate que l'homologation d'un téléservice est échue depuis longtemps sans que personne ne l'ait relevé, et que le prestataire d'horodatage ne figure plus parmi les services qualifiés. Le service fonctionne, mais sa valeur probante et sa conformité sont fragilisées. La correction passe par une homologation provisoire, un changement de prestataire et surtout une échéance inscrite au calendrier de la gouvernance, avec alerte avant expiration.

À lire aussi : la PSSIE ; le cachet électronique qualifié ; les produits certifiés CSPN.

Questions fréquentes

Conclusion

Plus de vingt ans après l'ordonnance de 2005, le RGS reste le socle de la confiance numérique dans les échanges administratifs. Son exigence centrale n'a pas changé : analyser les risques, choisir des fonctions de sécurité d'un niveau adapté et faire homologuer chaque système par une autorité qui assume les risques résiduels. Ce qui évolue, ce sont les outils : guide d'homologation simplifié en 2025, règles cryptographiques intégrant la menace quantique en 2026, articulation avec eIDAS en cours de simplification.

Pour une administration comme pour ses prestataires, la priorité de 2026 consiste à vérifier trois points : des homologations à jour, des qualifications valides et une cryptographie alignée sur le guide de l'ANSSI. Une organisation déjà engagée dans un système de management de la sécurité trouvera dans notre guide ISO 27001 les bases pour mutualiser analyse de risques, preuves et amélioration continue.