> ## 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. > Fonctionnalité de provisionnement des utilisateurs et considérations relatives à votre mise en œuvre de B2C IAM. # Provisioning (B2C) Il est important de déterminer dès le départ comment les utilisateurs s’inscriront, car les décisions prises ici influenceront bon nombre de celles que vous devrez prendre par la suite. Nous avons constaté qu’il existe un ensemble de modèles courants pour l’ajout des utilisateurs à votre système, ainsi que certains points à considérer dans la conception du workflow. Bien qu’Auth0 prenne en charge de nombreux workflows, les workflows Web qui utilisent [Universal Login](/docs/fr-ca/authenticate/login/auth0-universal-login) d’Auth0 pour l’inscription sont considérés comme une pratique exemplaire, tant dans l’industrie que chez Auth0, puisqu’ils offrent des fonctionnalités optimales et le meilleur niveau de sécurité. Auth0 prend en charge l’inscription des utilisateurs au moyen de différents [fournisseurs d’identité](/docs/fr-ca/authenticate/identity-providers). Pendant l’inscription, Auth0 provisionne le profil utilisateur afin qu’il contienne les renseignements du compte de l’utilisateur. Il y a plusieurs éléments à prendre en compte en ce qui concerne les fonctionnalités et le workflow : * Devriez-vous utiliser Auth0 comme magasin d’identités ? * Pouvez-vous utiliser votre propre magasin d’identités existant avec Auth0 ? * Comment migrer les identités des utilisateurs de votre magasin d’identités vers Auth0 ? * Vos utilisateurs peuvent-ils s’inscrire à l’aide de leurs comptes sociaux existants, comme Google et Facebook ? Auth0 offre un stockage des identités prêt à l’emploi qui peut être utilisé pour stocker les informations d’authentification des utilisateurs de façon sûre et sécurisée. Consultez [Self Sign Up](#self-sign-up) pour en savoir plus. Si vous disposez déjà d’un ancien magasin d’identités et que vous souhaitez en transférer la gestion, les capacités de [User Migration](#user-migration) vous offrent plusieurs options pour le faire. Autrement, si vous devez conserver votre ancien magasin d’identités — peut-être parce que vous avez des applications que vous n’êtes pas encore prêt à migrer ou qui ne peuvent pas l’être —, vous pouvez utiliser la capacité de [identity store proxy](#identity-store-proxy). Permettre à vos clients d’utiliser leur propre identité est aussi une option intéressante et, bien que nous constations que nos clients ne le font généralement pas au départ, vous pouvez utiliser la capacité de [Social Sign Up](#social-sign-up) pour l’offrir.
## Migration des utilisateurs
En plus d’héberger le [profil utilisateur](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/profile-management), Auth0 peut aussi servir de [proxy](#identity-store-proxy) pour votre propre ancien magasin d’identités et offrir une solution de remplacement sécurisée hébergée par Auth0. Ces deux capacités sont prises en charge au moyen des [Database Connections](/docs/fr-ca/authenticate/database-connections) d’Auth0. Si vous décidez d’utiliser Auth0 pour remplacer votre ancien magasin d’identités, vous pouvez [migrer les utilisateurs](/docs/fr-ca/manage-users/user-migration) soit en une seule opération avec une migration en bloc, soit progressivement avec une migration automatique. Les clients optent souvent pour une approche en deux étapes pour la migration des utilisateurs : ils utilisent d’abord la migration automatique pour migrer le plus d’utilisateurs possible, puis la migration en bloc pour les utilisateurs restants. Consultez [Scénarios de migration des utilisateurs](/docs/fr-ca/manage-users/user-migration/user-migration-scenarios) pour plus d’information. La migration automatique est à privilégier, car elle permet de migrer les utilisateurs individuellement et aussi de leur conserver leur mot de passe actuel dans presque tous les cas. Pour la migration en bloc, nous recommandons d’utiliser la [Management API](https://auth0.com/docs/api/management/v2#!/Jobs/post_users_imports) plutôt que l’[extension User Import/Export](/docs/fr-ca/manage-users/user-migration/user-import-export-extension) dans tous les cas sauf les plus simples, puisque la Management API offre plus de souplesse et un meilleur contrôle. Avec la migration en bloc, les utilisateurs doivent généralement **réinitialiser leur mot de passe une fois la migration terminée**, sauf si les mots de passe sont stockés sous forme de hachage dans votre ancien magasin d’identités à l’aide de bcrypt (ou si vous pouvez les générer au format bcrypt). Dans ce cas, vous pourriez être en mesure d’utiliser la migration en bloc et de **préserver les mots de passe des utilisateurs** dans le cadre du processus, selon l’algorithme bcrypt et le nombre de tours de salage utilisés. Consultez [Exemples de schéma d’importation en bloc pour Database](/docs/fr-ca/manage-users/user-migration/bulk-user-import-schema) pour plus d’information. Les requêtes à la Management API sont assujetties à la [politique de limitation du débit d’Auth0](/docs/fr-ca/troubleshoot/customer-support/operational-policies/rate-limit-policy). Vous devez en tenir compte et, pour vous aider, Auth0 recommande généralement d’utiliser l’[Auth0 SDK](/docs/fr-ca/libraries) approprié à votre environnement de développement plutôt que d’appeler directement nos API.
### Proxy du magasin d’identités
Les types de Database Connections d’Auth0 peuvent aussi être configurés pour agir comme proxy d’un magasin d’identités existant (hérité). Si vous devez conserver des identités utilisateur définies dans votre propre magasin d’identités hérité — par exemple, si vous avez une ou plusieurs applications essentielles à l’entreprise que vous ne pouvez pas migrer vers Auth0, mais qui doivent tout de même avoir accès à ces identités — vous pouvez facilement l’intégrer à Auth0. Consultez [Authentifier les utilisateurs à l’aide de votre base de données](/docs/fr-ca/authenticate/database-connections/custom-db) pour en savoir plus.
## Inscription libre-service
L’inscription libre-service s’appuie sur les Auth0 [Database Connections](/docs/fr-ca/authenticate/database-connections) pour stocker le user ID, le mot de passe et, au besoin, les renseignements d’identité liés au username recueillis auprès des nouveaux utilisateurs pendant le processus d’inscription. Les politiques de database connection qui régissent, par exemple, la [longueur minimale du nom d’utilisateur](/docs/fr-ca/authenticate/database-connections/require-username) ou la [robustesse et la complexité du mot de passe](/docs/fr-ca/authenticate/database-connections/password-options) peuvent être configurées dans le Auth0 Dashboard. Auth0 [Universal Login](/docs/fr-ca/authenticate/login/auth0-universal-login), de même que les widgets Auth0 comme [Lock](https://auth0.com/lock), s’intègrent aux Database Connections pour offrir d’emblée des fonctionnalités complètes d’interface utilisateur pour l’inscription. Ces éléments d’interface sont entièrement réactifs et, grâce à leur riche configuration et à leurs nombreuses options de personnalisation, vous pouvez déployer des fonctionnalités d’inscription libre-service et de login.
## Inscription sociale
L’inscription sociale est synonyme de connexion par [authentification sociale](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/authentication) — il n’y a pas vraiment de distinction ici *à proprement parler*, puisque le [profil](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/profile-management) utilisateur est créé automatiquement lors de la première connexion sociale.
## Guide de planification de projet
Nous offrons 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)