> ## Documentation Index
> Fetch the complete documentation index at: https://docs-staging-feat-init-gt-translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Assurance qualité Business-to-Consumer
> Planifiez l’assurance qualité d’une mise en œuvre Auth0 B2C IAM en définissant les environnements de test ainsi que la couverture de régression et les étapes d’approbation que chaque version doit franchir.
L’assurance qualité est essentielle pour repérer les problèmes avant qu’ils n’aient des répercussions sur vos clients et, selon la nature de votre projet, il existe plusieurs types de tests d’assurance qualité à envisager dans le cadre de votre intégration à Auth0 :
* Votre application est-elle facile à comprendre et à utiliser, même pour les personnes en situation de handicap ?
* Votre application doit-elle fonctionner dans différents navigateurs et sur différents appareils ?
* Votre application doit-elle fonctionner dans des environnements multinationaux et/ou internationaux ?
* Comment votre application se comportera-t-elle lorsqu’elle sera soumise à des charges imprévues en production ?
* Comment pouvez-vous vous assurer que votre application est protégée contre les vulnérabilités de sécurité ?
Auth0 [Universal Login](/docs/fr-ca/authenticate/login/auth0-universal-login) et les widgets d’interface associés (comme [Lock](/docs/fr-ca/libraries/lock)) ont déjà été conçus et développés selon les meilleures pratiques en matière de convivialité et d’accessibilité, et offrent une prise en charge prête à l’emploi éprouvée pour un large éventail de [navigateurs et d’appareils](/docs/fr-ca/troubleshoot/customer-support/product-support-matrix). La prise en charge de [l’internationalisation](/docs/fr-ca/customize/internationalization-and-localization) (I18N) est également offerte prête à l’emploi, avec une extensibilité intégrée conçue pour les contextes multilingues et de localisation (L10N) personnalisés.
Pour s’assurer que les exigences fonctionnelles sont respectées et que les événements imprévus sont gérés correctement, des directives sont fournies pour tester l’[intégration](#integration-testing) entre vos applications et Auth0, ainsi que pour effectuer des [tests unitaires](#unit-testing) sur des modules d’extensibilité individuels (comme les [Rules](/docs/fr-ca/customize/rules/debug-rules), les [Hooks](/docs/fr-ca/customize/hooks/update-hooks) et les scripts de base de données personnalisée). Des directives sont également fournies concernant la [politique de tests d’intrusion d’Auth0](/docs/fr-ca/troubleshoot/customer-support/operational-policies/penetration-testing-policy) pour vous aider à tester les vulnérabilités de sécurité, ainsi que sur la façon dont les tests [simulés](#mock-testing) peuvent être mis à profit conjointement avec notre [politique de tests de charge](/docs/fr-ca/troubleshoot/customer-support/operational-policies/load-testing-policy) afin de vous aider à vous assurer que vos applications fonctionnent bien sous une charge imprévue.
Tests unitaires
L’objectif des tests unitaires est de tester des unités de code individuelles. Si vous créez du code personnalisé dans Auth0 sous forme de Rules, de Hooks ou de Custom DB scripts, vous devriez envisager d’utiliser un framework de test (comme [Mocha](https://mochajs.org/)) pour tester votre code. Les entreprises qui ont obtenu le plus de succès avec Auth0 ont trouvé utile d’exécuter ces tests unitaires avant de [déployer automatiquement](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/deployment) la configuration du tenant Auth0 et les ressources connexes.
Tests d’intégration
Comme bonne pratique, il est recommandé de configurer des tenants distincts pour le développement, les tests et la production, comme indiqué dans les conseils d’Architecture relatifs à la [prise en charge du SDLC](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/architecture#sdlc-support). Auth0 vous permet de configurer des variables accessibles dans l’[extensibilité](/docs/fr-ca/customize/extensions) personnalisée; vous pouvez les considérer comme des variables d’environnement pour votre tenant Auth0. Au lieu de coder en dur des références qui changent lorsque vous déplacez du code entre les environnements de développement, de test et de production, vous pouvez utiliser un nom de variable configuré dans le tenant et référencé par le code d’extensibilité personnalisée. Il est ainsi plus facile de faire fonctionner le même code personnalisé, sans modification, dans différents tenants, puisque le code peut référencer des variables qui seront renseignées avec des valeurs propres au tenant au moment de l’exécution :
* Pour utiliser des variables dans Rules, voyez comment [configurer des valeurs](/docs/fr-ca/customize/rules/configuration)
* Pour utiliser des variables dans Hooks, voyez comment configurer les [secrets](/docs/fr-ca/customize/hooks/hook-secrets) dans l’éditeur
* Pour utiliser des variables dans Actions, consultez Explore Flows and Triggers
* Pour utiliser des variables dans Custom DB Scripts, consultez les [paramètres de configuration](/docs/fr-ca/authenticate/database-connections/custom-db/create-db-connection#step-3-add-configuration-parameters)
Nous recommandons d’utiliser des variables pour stocker les valeurs propres au tenant ainsi que tout secret sensible qui ne devrait pas être exposé dans votre code personnalisé. Si votre code personnalisé est déployé sur GitHub, l’utilisation d’une variable propre au tenant permet d’éviter l’exposition de valeurs sensibles dans votre dépôt GitHub.
Automatisation des tests
Vous pouvez automatiser l’ensemble de votre processus de compilation en y intégrant l’automatisation du déploiement ainsi que l’automatisation des tests. Cela permet de déployer vers Auth0 de nouvelles versions de la configuration ou du code personnalisé, puis d’exécuter des tests automatisés. Si les tests détectent des échecs, les capacités d’automatisation du déploiement peuvent servir à rétablir la dernière version fonctionnelle. Pour en savoir plus, consultez les [directives sur l’automatisation du déploiement](/docs/fr-ca/get-started/architecture-scenarios/business-to-consumer/deployment).
Tests simulés
Pour concilier la [politique de tests de charge](/docs/fr-ca/troubleshoot/customer-support/operational-policies/load-testing-policy) d’Auth0 et le besoin d’effectuer des tests de charge, il est courant chez les clients d’Auth0 de simuler les endpoints d’Auth0. Il s’agit d’une pratique utile pour s’assurer que votre application fonctionne avec les interfaces prévues sans avoir à limiter vos tests, et des outils comme [MockServer](http://www.mock-server.com/), [JSON Server](https://github.com/typicode/json-server) ou même [Postman](https://learning.getpostman.com/docs/postman/mock_servers/setting_up_mock/) peuvent vous y aider.
Guide de planification de projet
Nous fournissons des conseils de planification au 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)