Publié le 4 août 2026

AGOV dans les architectures cloud, SaaS et Hyperscale

Interaction avec Microsoft Entra ID, Microsoft 365, AWS, Google Cloud et d’autres plateformes

1. Contexte

AGOV est le service d’authentification des autorités suisses. Les applications cibles peuvent être raccordées à AGOV au moyen d’OpenID Connect, en abrégé OIDC, ou de SAML 2.0, soit directement, soit par l’intermédiaire d’un système existant de gestion des identités et des accès.

AGOV n’est pas lié à un modèle d’exploitation particulier. Une application cible peut notamment être exploitée :

dans un centre de calcul de l’autorité compétente
auprès d’un prestataire public ou privé
dans un cloud privé
sous la forme d’un logiciel en tant que service (SaaS)
sur une plateforme hyperscale
ou dans une architecture hybride ou interorganisationnelle

Il est nécessaire que l’application cible elle-même ou un composant IAM placé en amont prenne en charge un profil OIDC ou SAML compatible avec AGOV.

AGOV n’exclut pas le raccordement de solutions SaaS, cloud ou hyperscale. La possibilité technique de raccordement doit toutefois être distinguée de l’admissibilité juridique, sécuritaire et organisationnelle du modèle d’exploitation concerné.

2. Identité, contexte organisationnel et autorisation

AGOV authentifie des personnes physiques. Il confirme à l’application cible raccordée quelle personne s’est connectée et avec quel niveau de qualité d’authentification ou de vérification de l’identité.

Un compte AGOV représente toujours exactement une personne physique. Il ne représente notamment pas :

l’appartenance à une autorité ou à une organisation
une fonction professionnelle
un pouvoir de représentation
un rôle métier
une licence cloud
une autorisation applicative
ou une attribution de ressources

Ces informations et ces décisions restent de la compétence de l’autorité responsable, de son IAM organisationnel, de la plateforme cloud ou de l’application métier concernée.

Le modèle fondamental de répartition des responsabilités est le suivant :

AGOV authentifie la personne physique.

L’IAM organisationnel attribue la personne à une organisation, à une fonction ou à un rôle.

La plateforme cloud gère ses comptes, licences, groupes, rôles et jetons spécifiques.

L’application métier décide de l’autorisation concrète.

3. Modèles d’intégration

3.1 Raccordement direct

Une application cible peut être raccordée directement à AGOV en tant que relying party OIDC ou service provider SAML.

Application ↔ AGOV

Ce modèle convient notamment aux applications développées par les autorités, aux portails de cyberadministration et aux solutions standard disposant d’un raccordement OIDC ou SAML librement configurable.

3.2 Raccordement par l’intermédiaire d’un IAM existant ou d’un courtier d’identité

Plusieurs applications peuvent être raccordées à AGOV par l’intermédiaire d’un composant IAM commun.

Applications ↔ IAM ou courtier d'identité (Identity-Broker) ↔ AGOV

La couche d’intermédiation peut notamment :

harmoniser différents profils de protocole
transformer des claims et des attributs
compléter des identifiants internes de personnes
obtenir les appartenances organisationnelles à partir d’annuaires séparés
attribuer des groupes et des rôles
regrouper plusieurs applications dans un domaine SSO
encapsuler vis-à-vis d’AGOV les particularités propres à un produit.

Le raccordement au moyen d’un système IAM existant fait partie du modèle d’intégration prévu pour AGOV.

3.3 Raccordement par l’intermédiaire de l’IAM d’une plateforme cloud

L’IAM d’une plateforme cloud peut agir vis-à-vis d’AGOV en tant que relying party ou couche d’identité intermédiaire.

Application cloud ↔ IAM cloud ↔ AGOV

Dans ce modèle, AGOV authentifie la personne physique. La plateforme cloud émet ensuite ses propres jetons et gère les comptes, rôles et décisions d’accès spécifiques à la plateforme.

4. Prise en charge des protocoles et interopérabilité concrète

La prise en charge d’OIDC ou de SAML constitue la base technique d’un raccordement. Pour l’intégration concrète, il convient en outre de vérifier que les profils et les processus utilisés par AGOV et par la plateforme cible concordent.

Il faut notamment tenir compte des éléments suivants :

profils OIDC ou SAML
issuer, audience et entity IDs
procédures de redirection et de callback
identifiants stables de personnes
claims et attributs
mécanismes de signature et de chiffrement
renouvellement des clés et des certificats
durée des sessions et nouvelle authentification
niveaux d’authentification et step-up
single logout
exigences des navigateurs, applications mobiles, clients de bureau ou outils en ligne de commande.

Des divergences sur certains points n’excluent pas fondamentalement une intégration. Selon la situation, elles peuvent être résolues par une configuration, une extension du profil d’intégration, une évolution d’AGOV ou l’utilisation d’un courtier d’identité contrôlé.

5. Microsoft Entra ID et Microsoft 365

Microsoft 365 utilise Microsoft Entra ID comme plateforme d’annuaire, de jetons, de licences et d’accès.

Un domaine Microsoft 365 peut en principe être fédéré avec un fournisseur d’identité SAML externe. Microsoft utilise à cet effet un profil d’intégration spécifique comprenant des exigences définies pour les points de terminaison, les identifiants, les claims, les signatures et les procédures des clients.

Un modèle d’intégration possible est le suivant :

Microsoft 365 ↔ Microsoft Entra ID ↔ AGOV ou courtier d’identité (Identity-Broker)

AGOV authentifie la personne physique. Microsoft Entra ID reste notamment responsable de :

comptes d’utilisateurs Microsoft 365
User Principal Names
licences
groupes
rôles
attributions d’applications
jetons Microsoft
Microsoft Graph
règles d’accès spécifiques à Microsoft.

Une fédération directe entre AGOV et Microsoft Entra ID suppose que les profils et processus utilisés soient compatibles. Lorsqu’une exigence propre au produit n’est pas directement remplie, une couche d’intermédiation appropriée peut être utilisée ou une demande d’évolution correspondante peut être adressée à AGOV.

La fédération d’un domaine Microsoft 365 doit être distinguée des scénarios Microsoft Entra External ID. Ceux-ci concernent notamment l’accès de personnes externes à certaines ressources protégées par Entra et doivent être évalués séparément sur les plans technique et organisationnel.

6. Amazon Web Services

Il convient de distinguer plusieurs scénarios d’utilisation d’AWS.

6.1 Accès au niveau de gestion AWS

AWS IAM Identity Center peut être utilisé pour l’accès nominatif aux comptes AWS et à AWS Management Console. IAM Identity Center peut déléguer l’authentification à un fournisseur d’identité SAML externe.

AWS Management Console ↔ AWS IAM Identity Center ↔ AGOV ou courtier d’identité (Identity-Broker)

AGOV authentifie la personne physique. AWS gère notamment :

comptes AWS
permission sets
rôles IAM
groupes
politiques de ressources
sessions et jetons AWS

La fédération SAML ne remplace pas la mise à disposition des utilisateurs, groupes et attributions de rôles nécessaires dans AWS. Ceux-ci sont gérés séparément, par exemple au moyen de SCIM, d’une administration manuelle ou d’un IAM organisationnel placé en amont.

6.2 Applications hébergées sur AWS

Une application hébergée sur AWS peut être raccordée directement à AGOV au moyen d’OIDC ou de SAML.

Application sur AWS ↔ AGOV

Amazon Cognito peut également être utilisé comme couche d’intermédiation.

Application sur AWS ↔ Amazon Cognito ↔ AGOV

Dans ce modèle, Cognito émet les jetons spécifiques au produit et attribue les attributs à l’application.

6.3 Workloads techniques

Les processus techniques, serveurs, conteneurs, fonctions et comptes de service ne sont pas authentifiés au moyen d’AGOV. Les procédures prévues pour les identités techniques, les justificatifs de courte durée et la workload federation doivent être utilisées.

7. Google cloud

Google Cloud permet, au moyen de Workforce Identity Federation, d’intégrer des fournisseurs d’identité OIDC ou SAML externes pour les personnes physiques.

Google Cloud ↔ Workforce Identity Federation ↔ AGOV

AGOV authentifie la personne physique. Google Cloud attribue l’identité et les attributs autorisés à ses propres rôles IAM et autorisations de ressources.

Google Cloud reste notamment responsable de :

workforce pools
mappage des attributs
principal sets
rôles Google Cloud IAM
politiques de ressources
jetons Google de courte durée.

Workforce Identity Federation pour les personnes physiques doit être distinguée de Workload Identity Federation pour les processus techniques.

Google Cloud Workforce Identity Federation ne doit en outre pas être assimilée à Google Workspace. Le raccordement de Google Workspace constitue un scénario produit distinct.

8. Autres plateformes cloud et SaaS

8.1 Oracle Cloud Infrastructure

OCI IAM Identity Domains peut déléguer l’authentification à un fournisseur d’identité SAML externe.

Oracle Cloud ↔ OCI IAM Identity Domain ↔ AGOV ou courtier d’identité (Identity-Broker)

Les groupes, rôles, policies et autorisations cloud restent gérés dans OCI ou dans l’IAM organisationnel compétent.

8.2 SAP Business Technology Platform

Selon le service et l’architecture, SAP BTP peut être raccordé directement à AGOV au moyen de SAML ou indirectement par l’intermédiaire de SAP Cloud Identity Services.

Modèle direct :

Application SAP BTP ↔ AGOV

Modèle avec intermédiation :

Application SAP BTP ↔ SAP Cloud Identity Services ↔ AGOV

Les «role collections», rôles métier et autorisations propres à SAP restent en dehors d’AGOV.

8.3 Salesforce

Salesforce peut fonctionner en tant que service provider SAML vis-à-vis d’AGOV ou d’un courtier d’identité (Identity-Broker).

Salesforce ↔ AGOV ou Identity-Broker (Identity-Broker)

Les objets utilisateurs, profils, permission sets, licences et autorisations métier restent dans Salesforce ou dans l’IAM organisationnel compétent.

8.4 ServiceNow et autres solutions SaaS

ServiceNow et de nombreux autres produits SaaS prennent en charge le raccordement de fournisseurs d’identité externes au moyen d’OIDC ou de SAML.

Lorsqu’une solution SaaS permet de choisir un fournisseur d’identité OIDC ou SAML propre au client, un raccordement direct ou indirect à AGOV peut en principe être examiné et réalisé.

9. Vue d’ensemble

Plateforme ou scénario
Voie de raccordement possible à AGOV
Responsabilité restante

Application métier développée en propre
Directement au moyen d’OIDC ou de SAML
Rôles métier, autorisations, sessions et données métier

Microsoft 365
Par Microsoft Entra ID, directement en cas de compatibilité des profils ou par un courtier
Comptes, UPN, licences, groupes, rôles et jetons Microsoft

AWS Management Console
SAML par AWS IAM Identity Center
Comptes AWS, permission sets, rôles IAM et provisioning

Application métier sur AWS
Directement au moyen d’OIDC ou de SAML ou par Amazon Cognito
Profils applicatifs, ressources AWS et droits métier

Google Cloud
OIDC ou SAML par Workforce Identity Federation
Mappage d’attributs, rôles IAM et politiques de ressources

Oracle Cloud
SAML par OCI IAM Identity Domains
Groupes, rôles et policies OCI

SAP BTP
Directement au moyen de SAML ou par SAP Cloud Identity Services
Role collections et rôles métier SAP

Salesforce
SAML directement ou par un courtier
Profils, permission sets, licences et autorisations métier

Autres solutions SaaS
OIDC ou SAML après examen du profil d’intégration concret
Comptes, rôles, données et processus propres au produit

10. Exigences adressées à AGOV

AGOV est orienté vers les besoins des autorités suisses et évolue en conséquence.

Lorsqu’une relying party a besoin, pour le raccordement d’une plateforme cloud ou SaaS :

d’un claim supplémentaire
d’un attribut particulier
d’une variante de signature complémentaire
d’un comportement spécifique du protocole
d’une extension d’un profil d’intégration existant
ou d’une fonction supplémentaire fondée sur des standards

Elle peut soumettre cette exigence à la Chancellerie fédérale par les canaux prévus pour le raccordement, les échanges et la gouvernance.

Les exigences d’interopérabilité propres à certains produits font partie de l’évolution régulière d’AGOV. Elles ne constituent pas, en elles-mêmes, un motif d’exclusion de la plateforme concernée.

La Chancellerie fédérale examine notamment ces exigences en fonction de :

la sécurité
la protection des données
la conformité aux standards
l’utilité pour plusieurs autorités et relying parties
les effets sur les intégrations existantes
l’exploitabilité
les coûts
la prévention de dépendances inutiles à un fournisseur

Une évolution d’AGOV est particulièrement appropriée lorsqu’une exigence repose sur des standards ouverts, améliore l’interopérabilité et n’entraîne pas le transfert dans AGOV de rôles métier, d’appartenances organisationnelles ou d’autorisations propres à un produit.

Lorsqu’une exigence concerne exclusivement un produit particulier ou repose fortement sur des mécanismes propriétaires, l’utilisation d’un courtier d’identité contrôlé peut constituer la solution la plus appropriée.

11. Hyperscalers, souveraineté numérique et E-Government

11.1 Domaine de compétence d’AGOV

AGOV règle l’authentification et les conditions IAM nécessaires à cette dernière.

L’utilisation d’AGOV ne décide pas si une application métier peut être exploitée localement, dans un cloud privé, sous la forme d’une solution SaaS ou sur une plateforme hyperscale.

AGOV ne fixe pas, pour cette évaluation, de prescriptions matérielles supplémentaires relatives au cloud ou à la souveraineté qui iraient au-delà du cadre IAM applicable à AGOV, en particulier de l’ordonnance sur les systèmes de gestion des données d’identification et les services d’annuaires de la Confédération, OIAM.

Un raccordement à AGOV ne constitue donc ni une autorisation ni une exclusion d’une plateforme cloud déterminée.

11.2 Responsabilité de la relying party

L’autorité responsable du processus métier, respectivement la relying party, évalue l’admissibilité du modèle d’exploitation choisi.

Elle reste notamment responsable de :

la base légale du processus métier
la finalité et la proportionnalité du traitement des données
le choix de la solution cloud, SaaS ou de plateforme
la classification et le besoin de protection des données
l’attribution des rôles et des droits d’accès
la sécurité de l’information
la protection des données
le traitement de données sur mandat
les éventuels sous-traitants ultérieurs
les communications de données à l’étranger
la conservation et l’effacement
la journalisation et la traçabilité
la continuité des activités
la capacité de sortie et de migration
l’information des personnes concernées

L’utilisation d’AGOV ne transfère pas cette responsabilité à la Chancellerie fédérale ou au service d’authentification.

11.3 Données des citoyens

Les applications de cyberadministration traitent fréquemment des données personnelles de citoyennes et de citoyens. Selon le processus métier, il peut s’agir de données sensibles, fiscales, sanitaires, sociales, procédurales ou d’autres informations présentant un besoin de protection accru.

Avant tout traitement sur une plateforme SaaS ou hyperscale, l’autorité compétente doit notamment examiner :

l’existence d’une base légale suffisante
les données nécessaires à la finalité concernée
les conséquences d’une atteinte à la confidentialité, à l’intégrité, à la disponibilité ou à la traçabilité
les lieux de traitement des données, sauvegardes, journaux et données de télémétrie
les possibilités d’accès administratif et technique du fournisseur
les sous-traitants impliqués
les accès possibles depuis l’étranger
le contrôle des clés cryptographiques
la possibilité d’exporter et d’effacer complètement les données
la possibilité de migrer vers une autre plateforme
la continuité de l’exploitation en cas de panne, de fin de contrat ou de changement géopolitique

11.4 Souveraineté numérique

La souveraineté numérique n’est pas un état binaire. Elle désigne la capacité de contrôle et d’action nécessaire à une autorité dans l’espace numérique.

Lors de l’utilisation d’un hyperscaler, il convient notamment de mettre en balance :

le contrôle juridique et technique
la dépendance à un fournisseur unique
la capacité de changement et de rapatriement
le contrôle des données et des clés cryptographiques
la disponibilité d’alternatives
la maîtrise de l’architecture globale
les compétences propres d’exploitation et de pilotage
la capacité de faire appliquer les contrats
les risques de concentration et de cascade
la résilience face aux crises et aux changements géopolitiques

Un fournisseur international n’est pas exclu du seul fait de son caractère international. De même, une solution n’est pas souveraine du seul fait que les données sont enregistrées dans un centre de calcul situé en Suisse.

La capacité réelle de contrôle et d’action de l’autorité compétente est déterminante.

11.5 Contribution d’AGOV

AGOV peut renforcer la souveraineté numérique d’une architecture cloud en évitant que l’authentification primaire de la personne physique doive être entièrement transférée au fournisseur cloud.

Cela peut notamment réduire les dépendances suivantes :

mots de passe supplémentaires auprès du fournisseur cloud
procédures d’authentification propriétaires
transfert complet de l’identité primaire de la personne dans un annuaire cloud commercial
vérifications d’identité différentes pour chaque plateforme
dépendance durable de l’authentification étatique à un seul écosystème fournisseur

L’utilisation d’AGOV ne supprime toutefois pas les autres dépendances liées à une plateforme cloud. Le stockage des données, la logique applicative, l’administration, la gestion des autorisations, la disponibilité et la capacité de sortie doivent continuer à être évalués séparément.

12. Conclusion

AGOV peut être utilisé pour des applications exploitées localement, des produits SaaS et des applications fonctionnant sur des plateformes hyperscale.

Le raccordement s’effectue directement ou par l’intermédiaire d’un IAM existant ou d’un courtier d’identité, au moyen d’OIDC ou de SAML.

Les exigences d’interopérabilité propres à certains produits peuvent être soumises à la Chancellerie fédérale dans le cadre ordinaire. Elles font partie de la gouvernance produit d’AGOV et de l’évolution du service.

AGOV authentifie la personne physique. Il ne décide pas de l’admissibilité d’une plateforme cloud, du traitement des données des citoyens ou des droits d’accès métier.

L’autorité responsable, respectivement la relying party, évalue la base légale, le besoin de protection, la sécurité de l’information, la protection des données, la souveraineté numérique ainsi que les mesures techniques, organisationnelles et contractuelles nécessaires.

Une authentification pilotée par les autorités peut ainsi être combinée avec des technologies cloud modernes sans mélanger les responsabilités d’AGOV, de la relying party et du fournisseur cloud.