Question 1

Pourquoi homologuer un système d'information ?

Accepted Answer

Parce que la collectivité y est tenue pour ses téléservices et que la décision protège ceux qui la prennent. Le référentiel général de sécurité (RGS) oblige les autorités administratives, collectivités comprises, à attester formellement la sécurité des systèmes qu'elles ouvrent aux usagers. L'homologation est la forme que prend cette attestation.
Au-delà de l'obligation, la démarche rend visible un risque que le service informatique porte souvent seul. La fiche méthode de l'Agence nationale de la sécurité des systèmes d'information (ANSSI) destinée aux décideurs la présente comme « un outil de prise de conscience pour les dirigeants » : l'élu apprend ce qui arriverait en cas d'attaque réussie sur l'état civil, la paie ou le portail famille, et ce que coûterait la réduction de ce risque.
La décision structure aussi les arbitrages budgétaires. Le dossier chiffre les mesures qui restent à mettre en œuvre : la collectivité compare ainsi les investissements de sécurité entre systèmes et les programme sur plusieurs exercices.
Enfin, la démarche prépare la collectivité aux autres exigences : les assureurs et les partenaires demandent de plus en plus la preuve d'une gestion des risques, et le projet de loi de transposition de la directive NIS 2, en discussion au Parlement au 30 septembre 2026, prévoit des obligations de gestion des risques pour une partie des collectivités. Un système déjà homologué dispose de sa cartographie, de son analyse de risques et de son plan d'action : l'essentiel du travail est fait.

Question 2

Comment homologuer un système d'information ?

Accepted Answer

Par les quatre étapes du guide publié en avril 2025 par l'ANSSI et la Direction interministérielle du numérique (DINUM) : constituer le comité d'homologation, choisir le niveau de la démarche, faire évaluer les pièces du dossier, puis réunir la commission où l'autorité décide.

Constituer le comité d'homologation. Il réunit les personnes aptes à vérifier la pertinence des mesures de sécurité appliquées au système. Il instruit le dossier ; il ne le rédige pas et n'audite pas lui-même le système.
Identifier le niveau de la démarche. Le guide croise la criticité du système (mineure, modérée, importante, maximale) et son exposition aux menaces (nulle, faible, importante, totale). Le résultat, simplifié, intermédiaire ou renforcé, fixe la liste des pièces à produire.
Évaluer le dossier et émettre un avis. Le comité vérifie que les étapes de sécurisation ont été respectées et propose une décision et une durée d'homologation.
Organiser la commission d'homologation. L'autorité décide par échanges électroniques ou en réunion ; la fiche méthode pour les décideurs recommande que cette réunion n'excède pas une heure.

Pour les systèmes simples, MonServiceSécurisé, service gratuit de l'ANSSI, guide la démarche en ligne : la collectivité décrit son service, obtient une liste de mesures de sécurité personnalisées, puis un dossier de décision prêt à être signé. Le guide précise que l'homologation peut être prononcée avant la fin des travaux de sécurisation, dès lors que les risques restants sont jugés acceptables par l'autorité.

Question 3

Qui est l'autorité d'homologation ?

Accepted Answer

C'est la personne dont le niveau hiérarchique est suffisant pour assumer les risques et les choix stratégiques et financiers qui en découlent. Dans une collectivité, cette responsabilité revient à l'exécutif, maire ou président, qui représente la personne morale et peut déléguer sa signature à un élu ou à un cadre de direction.
La fiche méthode de l'ANSSI « Identifier l'autorité d'homologation » propose quatre questions pour la désigner dans une organisation complexe : quelle direction métier utilise le système, qui le finance, qui dispose des leviers de décision, et qui est la personne morale juridiquement responsable. Pour un logiciel de gestion de la petite enfance, la réponse conduit à l'exécutif ou à l'élu délégué, jamais au seul prestataire informatique.
La délégation de signature est admise : l'exécutif peut confier la décision à un représentant, par exemple le directeur général des services. La fiche rappelle toutefois que « l'autorité première reste juridiquement responsable, notamment en cas de survenance d'un incident ». Déléguer la signature ne transfère donc pas la responsabilité.
Le guide déconseille de désigner plusieurs autorités pour un même système, source de dilution des responsabilités. Pour un système mutualisé entre une intercommunalité et ses communes, les partenaires choisissent une seule autorité par concertation ; la responsabilité partagée reste un dernier recours.

Question 4

Qu'est-ce qu'un dossier d'homologation ?

Accepted Answer

C'est l'ensemble des pièces qui donnent à l'autorité les moyens de comprendre le système d'information, les risques liés à son emploi et les mesures prises. Son contenu dépend du niveau de la démarche : un site vitrine peu exposé ne demande pas les mêmes pièces qu'un logiciel de paie accessible depuis Internet.
Le guide de l'ANSSI et de la DINUM cite notamment :

la cartographie du système, en trois vues (métier, applicative, infrastructure) ;
l'analyse de risques, avec la méthode EBIOS Risk Manager (expression des besoins et identification des objectifs de sécurité) fortement recommandée ; pour un système de criticité mineure et d'exposition quasi nulle, une étude de conformité au guide d'hygiène informatique suffit ;
les plans de maintien en condition opérationnelle et de sécurité, et le plan de résilience ;
les rapports d'audit, obligatoires pour certains systèmes réglementés ;
le plan d'action et la liste des risques résiduels.

Le guide insiste sur deux règles. Les pièces doivent exister pour l'exploitation du système et « ne doivent pas être spécifiquement rédigées pour la démarche d'homologation » : un dossier fabriqué pour la signature ne sert à rien le jour de l'incident. Elles doivent aussi être protégées et accessibles aux seules personnes qui ont besoin d'en connaître, car elles décrivent précisément les faiblesses du système. Un document de synthèse destiné à l'autorité accompagne l'ensemble.

Question 5

Qui est soumis au RGS ?

Accepted Answer

Les autorités administratives au sens de l'ordonnance n° 2005-1516 du 8 décembre 2005 : administrations de l'État, collectivités territoriales, établissements publics à caractère administratif, organismes chargés des régimes de protection sociale et autres organismes chargés d'un service public administratif. Toutes les collectivités, de la petite commune à la Région, sont donc concernées.
Selon la page de l'ANSSI consacrée au référentiel général de sécurité, le RGS s'adresse aussi à deux autres publics : les organismes publics et privés qui fournissent des produits ou des services de confiance (certificats électroniques, horodatage, signature), et les organismes chargés de qualifier ces produits et services.
Pour une collectivité, deux familles d'exigences en découlent. La première, que l'ANSSI qualifie de « plus importante », est de conduire une homologation de sécurité de ses systèmes d'information, démarche qui commence par une analyse de risques. La seconde porte sur les fonctions de sécurité : lorsqu'un téléservice recourt à l'identification électronique, à la signature, à la confidentialité ou à l'horodatage, la collectivité fixe le niveau de sécurité visé et emploie des services conformes. Le recours à un service qualifié au titre du RGS vaut présomption de conformité.
Les organismes qui ne sont pas des autorités administratives, comme une association ou une entreprise, peuvent utiliser le RGS comme un guide de bonnes pratiques, sans obligation.

Question 6

Qu'est-ce que l'homologation de sécurité (RGS) ?

Accepted Answer

C'est l'attestation formelle, exigée par le décret n° 2010-112 du 2 février 2010, par laquelle une autorité administrative déclare aux utilisateurs de son système d'information que celui-ci est protégé conformément aux objectifs de sécurité qu'elle a fixés. Pour un téléservice, cette attestation doit être accessible aux usagers.
Le décret organise la démarche en deux temps. Son article 3 demande à l'autorité d'identifier les risques qui pèsent sur le système, de fixer des objectifs de sécurité proportionnés, puis d'en déduire les fonctions de sécurité à mettre en œuvre ; il impose aussi de réexaminer régulièrement la sécurité au regard de l'évolution des risques. Son article 5 impose l'attestation formelle qui clôt cette analyse.
Le référentiel lui-même, approuvé par l'arrêté du 13 juin 2014, décrit cette attestation comme une homologation de sécurité et en détaille la démarche. L'ANSSI en tient la doctrine à jour avec la DINUM ; la version en vigueur est le guide de l'homologation de sécurité des systèmes d'information d'avril 2025.
Deux points distinguent l'homologation RGS d'une certification. Elle est prononcée par la collectivité elle-même, et non par un organisme extérieur. Elle est limitée dans le temps : l'ANSSI recommande une durée maximale de trois ans, avec une revue annuelle et une nouvelle homologation après tout changement notable ou incident de sécurité. L'homologation d'un système cesse lorsque celui-ci est démantelé.

Cas d'usage	Description & Retours d'expérience	Bénéfices pour le territoire
Homologuer le site internet et les téléservices de la commune	Une commune décrit son site et ses démarches en ligne dans MonServiceSécurisé, applique les mesures de sécurité proposées et fait signer la décision d'homologation par le maire avant publication de l'attestation. Retour d'expérience à venir sur ce cas d'usage.	Des démarches en ligne conformes au RGS, une responsabilité assumée par l'élu
Faire auditer son système d'information avant de décider	Une commune sollicite un audit de l'ANSSI pour évaluer ses serveurs et ses pratiques ; l'audit met au jour les fragilités (stockage local, accès multiples, absence de haute disponibilité) qui fondent la décision de migrer vers un environnement hébergé en France. Retour d'expérience : Ville-la-Grand (74) déploie un environnement numérique souverain pour moderniser le travail collectif	Des risques connus et hiérarchisés avant d'engager la dépense
Mutualiser l'homologation pour les communes d'un territoire	Un opérateur public de services numériques homologue les sites internet qu'il héberge pour ses collectivités adhérentes, sur une méthode et un dossier communs. Retour d'expérience à venir sur ce cas d'usage.	Une démarche accessible aux communes sans service informatique
Réhomologuer après un changement notable	Une collectivité qui change d'hébergeur ou ouvre un nouveau téléservice sur un système existant relance la démarche, comme le prévoit le guide de l'ANSSI après tout changement ayant un impact sur les risques. Retour d'expérience à venir sur ce cas d'usage.	Une sécurité qui suit l'évolution du système au lieu d'un dossier figé

Recherches récentes

Recherches populaires

Parcourir par étape

Autres ressources

Recherches populaires

Homologation de sécurité

Définition simple : qu'est-ce que l'homologation de sécurité ?

Les enjeux de l'homologation pour les collectivités

Définition technique : démarche et dossier d'homologation

Définition juridique et réglementaire de l'homologation de sécurité

Le référentiel général de sécurité

Les obligations du décret du 2 février 2010

Les suites à engager

Cas d'usage de l'homologation de sécurité pour les collectivités

Questions fréquemment associées à Homologation de sécurité

Le guide de l'homologation de sécurité des systèmes d'information

Le référentiel général de sécurité (RGS)

Décret n° 2010-112 du 2 février 2010 (articles 3 et 5)

Arrêté du 13 juin 2014 portant approbation du référentiel général de sécurité

MonServiceSécurisé

Cybersécurité

ANSSI

NIS 2

RGPD

SecNumCloud

Ville-la-Grand (74) déploie un environnement numérique souverain pour moderniser le travail collectif

Se préparer à la mise en œuvre de la directive NIS 2

Vous souhaitez en savoir plus sur le numérique et l'IA ?

Votre avis nous intéresse

Si vous acceptez d'être recontacté au sujet de ce commentaire, merci de préciser votre email (politique de confidentialité)

Définitions