> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Découvrez comment l’architecture de votre tenant Auth0 influe sur votre mise en œuvre de la gestion des identités et des accès (IAM) Business to Consumer (B2C).

# Architecture (B2C)

Comprendre votre <Tooltip tip="Votre logiciel qui s’appuie sur Auth0 pour l’authentification et la gestion des identités." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Application">application</Tooltip> est essentiel pour comprendre comment Auth0 peut être mis à profit pour répondre à vos besoins. D’après notre expérience, les clients qui réussissent le mieux commencent par une visualisation de l’architecture proposée — ou, dans bien des cas, existante — et s’en servent comme point de référence à mesure qu’ils avancent. Il est aussi important de comprendre où votre application s’inscrit dans votre organisation; les [Accounts and Tenants](/docs/fr-ca/get-started/auth0-overview/create-tenants) d’Auth0 constituent la base du regroupement et de la structuration des ressources Auth0, et il se peut que vous deviez tirer parti d’un déploiement Auth0 existant pour profiter du [Single Sign-On (SSO)](/docs/fr-ca/authenticate/single-sign-on), d’une [gestion centralisée des profils](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/profile-management), d’une facturation consolidée, ou d’éléments du même genre.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Si vous avez plusieurs applications et que vous devez tirer parti du SSO, nous vous recommandons de consulter d’abord notre guide de formation [How to Implement Single Sign-On](https://auth0.com/learn/how-to-implement-single-sign-on/) avant de poursuivre.
</Callout>

Investir du temps dès le départ pour définir le paysage architectural est, d’après notre expérience, un effort qui porte ses fruits à long terme. Voici donc quelques éléments à prendre en considération lorsque vous examinez les fonctionnalités et le flux de travail :

* À quoi l’URL devrait-elle ressembler lorsqu’Auth0 doit présenter une page web à un utilisateur ?
* Comment Auth0 peut-il être structuré pour prendre en charge votre SDLC (Software Development Lifecycle) ?
* Comment pouvez-vous vous assurer que vos tenants Auth0 sont correctement associés à votre contrat ?
* Que devez-vous prendre en considération s’il existe d’autres projets dans votre organisation qui s’intègrent à Auth0 ? En particulier les projets qui ciblent leur propre domaine d’utilisateurs, ou un domaine d’utilisateurs différent (par exemple, des applications que seuls les employés utiliseront) ?

<Tooltip tip="Produit Auth0 qui permet aux clients B2B de catégoriser les utilisateurs finaux et de définir des rôles précis, l’expérience de connexion et l’accès aux ressources." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Organizations">
  Organizations
</Tooltip>

couvrent souvent plus d’un domaine d’utilisateurs — clients, employés et affiliés étant les cas les plus fréquents, avec généralement peu ou pas de chevauchement : les employés, par exemple, n’utilisent pas les mêmes
applications que les clients, et vice-versa. Dans certains cas, il peut aussi être nécessaire de segmenter davantage à l’intérieur d’un même domaine — par exemple, des groupes distincts de clients qui utilisent des produits différents et non connectés.
Auth0 offre un moyen de séparer vos utilisateurs et les éléments connexes, et la section [provisionnement du tenant](#tenant-provision) traite cela plus en détail. Si vous devez provisionner un

<Tooltip tip="Un groupe d’utilisateurs logiquement isolé qui partage un accès commun avec des privilèges précis à une seule instance logicielle." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Tenant">
  tenant
</Tooltip>

indépendant, vous voudrez aussi [l’associer à votre compte Auth0 existant](#tenant-association), afin de profiter pleinement des avantages offerts par le niveau de

<Tooltip tip="Entente qui définit les fonctionnalités et les quotas offerts pour chacun de vos tenants." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=Subscription">
  subscription
</Tooltip>

de votre organisation.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Il n’est pas rare que les entreprises aient des exigences en matière d’identité qui couvrent plusieurs communautés d’utilisateurs : clients, partenaires, employés, etc. Assurez-vous donc de tenir compte des autres projets ou des besoins futurs lorsque vous concevez votre architecture.
</Callout>

De plus, vous avez sans doute déjà un ensemble établi de processus et de procédures dans le cadre de votre Software Development Lifecycle (SDLC). Vous voudrez donc aussi consulter nos conseils sur la [prise en charge du SDLC](#sdlc-support) relativement au provisionnement du tenant d’Auth0.

Pour les applications destinées aux clients, nous constatons généralement qu’[OpenID Connect (OIDC)](/docs/fr-ca/authenticate/protocols/openid-connect-protocol) est le protocole le plus souvent utilisé. OIDC s’appuie sur des flux web avec des URL de navigateur présentées à l’utilisateur. Par défaut, les URL destinées aux clients dans le cadre de la prise en charge d’OIDC par Auth0 portent l’image de marque d’Auth0; toutefois, nous recommandons d’utiliser la fonctionnalité de [domaine personnalisé](#custom-domains) d’Auth0 afin d’assurer une identité d’entreprise cohérente et de répondre aux éventuelles préoccupations des utilisateurs en matière de confiance avant qu’elles ne se posent.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  D’autres groupes au sein de votre organisation utilisent peut-être aussi Auth0; il n’est pas rare que nos clients aient des départements distincts au service de différentes communautés d’utilisateurs. Les identifier pourrait influencer vos choix de conception, et le faire tôt peut vous éviter de prendre des décisions qui pourraient s’avérer coûteuses par la suite.
</Callout>

<div id="tenant-provision">
  ## Provisionnement du tenant
</div>

Tout commence par un tenant Auth0. C’est là que vous configurerez votre utilisation d’Auth0 et que les ressources Auth0, comme les [Applications](/docs/fr-ca/get-started/applications), les [Connections](/docs/fr-ca/authenticate/identity-providers) et les [profils utilisateur](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/profile-management), sont définies, gérées et stockées. L’accès à un tenant Auth0 se fait au moyen du [Dashboard](/docs/fr-ca/get-started/auth0-overview/dashboard) Auth0, et à partir du Dashboard, vous pouvez aussi créer d’autres tenants associés; vous pouvez créer plus d’un tenant Auth0 afin de structurer vos tenants de façon à isoler différents domaines d’utilisateurs et à prendre en charge votre [cycle de vie du développement logiciel](#sdlc-support) (SDLC).

<Warning>
  Les noms de tenant ne peuvent pas être modifiés ni réutilisés une fois supprimés. Assurez-vous donc d’être satisfait de votre ou de vos noms avant de créer vos tenants Auth0.
</Warning>

Déterminer le niveau d’isolation requis pour vos domaines d’utilisateurs est une étape importante et, combiné à vos exigences en matière d’image de marque, vous aidera ensuite à déterminer le nombre de tenants Auth0 nécessaires dans votre environnement de production. Comme nous vous recommandons de créer une suite complète de [tenants prenant en charge le SDLC](#sdlc-support) pour chaque tenant Auth0 que vous exploiterez dans un environnement de production, le nombre de tenants Auth0 à gérer peut rapidement augmenter. Vous devriez donc réfléchir attentivement avant de créer plusieurs tenants Auth0 pour la production et consulter nos conseils sur l’[image de marque](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/branding) avant de prendre votre décision finale.

<div id="tenant-association">
  ## Association de tenant
</div>

Pour vous assurer que vos [tenants sont tous associés à votre entente contractuelle avec Auth0](/docs/fr-ca/get-started/auth0-overview/create-tenants/child-tenants) et qu’ils offrent les mêmes fonctionnalités, assurez-vous que tous vos tenants sont associés au compte de votre entreprise. Si certains développeurs souhaitent créer leurs propres sandboxes pour faire des tests, assurez-vous qu’ils sont eux aussi associés à votre compte afin d’avoir les mêmes autorisations. Pour ce faire, communiquez avec votre représentant Auth0 ou le [Auth0 Support Center](https://support.auth0.com).

<div id="custom-domains">
  ## Domaines personnalisés
</div>

Lorsque vous configurez votre tenant Auth0, l’URL pour accéder à ce tenant sera de la forme `https://yourTenant.auth0.com`. Fournir un [Custom Domain](/docs/fr-ca/customize/custom-domains) (aussi appelé URL vanity) pour votre tenant Auth0 n’est pas seulement un élément important pour répondre à vos exigences d’image de marque, mais vous procure aussi, et surtout, des avantages en matière de sécurité :

* Par défaut, certains navigateurs compliquent la communication dans une iFrame si vous n’avez pas de domaine partagé. Par exemple, [l’ITP de Safari entraîne des problèmes de renouvellement de jeton Auth0](https://support.auth0.com/center/s/article/troubleshoot-auth0-token-renewal-issues-in-safari-with-itp-enabled).
* Il est [plus difficile d’hameçonner votre domaine si vous avez une URL vanity](https://auth0.com/blog/introducing-custom-domains-preview-with-auth0/), car l’attaquant doit lui aussi créer une URL vanity pour imiter la vôtre. Par exemple, avec un <Tooltip tip="Domaine personnalisé : domaine tiers avec un nom spécialisé, ou vanity." cta="Voir le glossaire" href="/docs/fr-ca/glossary?term=custom+domain">domaine personnalisé</Tooltip>, vous pouvez utiliser votre propre certificat pour obtenir une « validation étendue », ce qui rend l’hameçonnage encore plus difficile.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Vous ne pouvez avoir qu’un seul domaine personnalisé par tenant Auth0. En effet, dans Auth0, un tenant est conçu pour représenter un « domaine » d’utilisateurs. Si vous avez besoin de plus d’une URL vanity, il est probable que vous ayez plus d’un domaine d’utilisateurs et que vous deviez utiliser plusieurs tenants.
</Callout>

Votre nom de domaine personnalisé doit aussi inspirer confiance à l’utilisateur et lui indiquer qu’il s’agit du bon endroit où saisir ses identifiants. Nous vous recommandons également de créer votre domaine personnalisé dans tous les environnements dès le départ afin de vous assurer d’effectuer des tests cohérents d’un environnement à l’autre. **Il est extrêmement important d’apprendre à vos utilisateurs à repérer les URL suspectes lorsqu’ils saisissent leurs identifiants !**

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Créez un domaine personnalisé (c.-à-d. `CNAME`) pour votre tenant Auth0, et créez-en aussi un en développement afin de vous assurer que vous avez correctement configuré le `CNAME`. Par exemple, vous pourriez créer un `CNAME` qui fait pointer `login.mycompany.com` vers `mycompany-prod.auth0.com`.
</Callout>

Dans presque tous les cas, les clients ont obtenu les meilleurs résultats en adoptant une stratégie de domaine centralisé pour l’authentication couvrant plusieurs images de marque de produits ou de services. Cette stratégie offre aux utilisateurs une expérience cohérente et réduit aussi la complexité liée au déploiement et à la maintenance de plusieurs tenants Auth0 dans un environnement de production. Si vous envisagez d’avoir plusieurs domaines pour différentes images de marque, veuillez consulter les directives sur l’[image de marque](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/branding) avant de commencer la mise en œuvre.

<div id="sdlc-support">
  ## Prise en charge du SDLC
</div>

Chaque entreprise a son propre cycle de vie du développement logiciel (SDLC), et vous voudrez harmoniser votre démarche avec cette stratégie tout au long du processus de développement. Par exemple, vous devez pouvoir tester votre intégration avec Auth0 de la même manière que vous testez les applications elles-mêmes. Il est donc important de [structurer les tenants Auth0 pour soutenir votre SDLC](/docs/fr-ca/get-started/auth0-overview/create-tenants/set-up-multiple-environments). Nos clients suivent généralement un modèle uniforme en ce qui a trait aux bonnes pratiques d’organisation des tenants :

| Environnement | Exemple de nom de tenant          | Description                                                                                |
| ------------- | --------------------------------- | ------------------------------------------------------------------------------------------ |
| Développement | **company-dev**                   | Un environnement partagé où s’effectue la majeure partie de votre travail de développement |
| AQ/Tests      | **company-qa** ou **company-uat** | Un environnement destiné aux tests formels des changements apportés                        |
| Production    | **company-prod**                  | Le tenant de production                                                                    |

Dans certains cas, vous pourriez aussi vouloir créer un ou plusieurs sandboxes (p. ex., **company-sandbox1**, **company-sandbox2**) afin de tester des changements sans compromettre votre environnement de développement. C’est aussi un bon endroit pour tester des scripts de déploiement et d’autres éléments du genre.

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  Vous pouvez également profiter de nos [listes de vérification de mise en œuvre](/docs/fr-ca/get-started/architecture-scenarios/checklists), que vous pouvez télécharger et personnaliser selon les besoins de votre projet de mise en œuvre.
</Callout>

<div id="project-planning-guide">
  ## Guide de planification de projet
</div>

Nous mettons à votre disposition un guide de planification en format PDF que vous pouvez télécharger et consulter pour en savoir plus sur les stratégies que nous recommandons.

[Guide de planification de projet B2C IAM](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)