> ## 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. # Personnaliser les modèles de courriel > Instructions pour utiliser les modèles de courriel afin de personnaliser l’apparence et le contenu des courriels envoyés par les flux de travail par courriel d’Auth0. Pour personnaliser les modèles de courriel, vous devez [configurer un fournisseur de courriel SMTP externe](/docs/fr-ca/customize/email/smtp-email-providers). Les modèles de courriel ne sont pas offerts lorsque vous utilisez le fournisseur de courriel intégré d’Auth0.
## Personnaliser les modèles de courriel
Pour personnaliser un modèle de courriel : 1. Accédez à [Dashboard > Branding > Email Templates](https://manage.auth0.com/#/templates). 2. Dans la liste déroulante **Template**, sélectionnez le modèle de courriel que vous souhaitez mettre à jour. 3. Sur la page du modèle de courriel, mettez à jour les champs que vous souhaitez personnaliser. Les champs **Adresse d’expéditeur**, **Objet**, **Redirect To** et **Message** prennent en charge Liquid. Pour en savoir plus, consultez [la syntaxe Liquid prise en charge](/docs/fr-ca/customize/email/email-templates/supported-liquid-syntax). 4. Cliquez sur **Save** pour enregistrer vos modifications, sur **Try** pour les tester, ou sur **Reset** pour rétablir la version précédente de vos modifications.
### Adresse d’expéditeur
Le champ **Adresse d’expéditeur** définit l’adresse courriel que les utilisateurs voient comme expéditeur lorsqu’ils reçoivent un courriel d’Auth0. S’il n’est pas défini, les courriels utilisent l’adresse courriel du champ **De** configuré pour votre fournisseur de services de courriel. Lorsque vous définissez le champ **Adresse d’expéditeur**, pour permettre à Auth0 d’envoyer en votre nom des courriels signés numériquement, vous devez configurer deux mécanismes d’authentification des courriels : * [Sender Policy Framework (SPF)](https://en.wikipedia.org/wiki/Sender_Policy_Framework), qui autorise des adresses IP précises à envoyer des courriels à partir d’un domaine * [DomainKeys Identified Mail (DKIM)](https://en.wikipedia.org/wiki/DKIM), qui signe les courriels de façon cryptographique afin que les serveurs de messagerie puissent vérifier qu’ils proviennent bien du domaine indiqué Sans configuration de SPF et de DKIM, les courriels pourraient ne pas être livrés, être bloqués par des filtres antipourriel, ou afficher « Au nom de » et révéler l’expéditeur (votre fournisseur de services de courriel) en plus de l’adresse d’expéditeur. Pour configurer SPF et DKIM, vous devez créer des enregistrements TXT pour votre domaine. Les valeurs des enregistrements TXT et les autres détails du processus varient ; suivez donc les instructions de votre fournisseur de services de courriel pour cette configuration. En général, l’enregistrement TXT pour SPF doit avoir le nom d’hôte défini à `@` ou laissé vide, et la valeur définie à `v=spf1 include: -all`. L’enregistrement TXT pour DKIM doit avoir le nom d’hôte défini sur le domaine que vous utilisez pour envoyer des courriels, et la valeur définie à la signature DKIM que vous générez avec votre fournisseur.
### Objet
Le champ **Objet** définit l’objet du courriel. S’il n’est pas défini, Auth0 renseigne automatiquement l’objet selon le type de courriel.
### Message
Le champ **Message** sert à définir le contenu HTML du corps du message. Chaque modèle comprend un corps de message par défaut, que vous pouvez modifier ou supprimer complètement pour rédiger le vôtre.
### URL lifetime et Redirect To
Les modèles de courriel qui incluent un lien (**Verification Email (Link)**, **Change Password (Link)** et **Blocked Account Email**) comportent deux champs supplémentaires pour gérer ces liens : * Le champ **URL lifetime** définit combien de temps un lien reste valide avant d’expirer. Par défaut, sa durée de validité est de 432 000 secondes (cinq jours). * Le champ **Redirect To** définit l’URL vers laquelle l’utilisateur est redirigé après avoir effectué l’action associée au lien inclus. Les tenants créés à compter du **5 mai 2026** et ayant un abonnement non Enterprise ne peuvent pas personnaliser le champ **Redirect To** (`resultUrl` dans la Management API). Les tenants créés avant cette date sont exemptés, quel que soit le type d’abonnement. Cette restriction a été ajoutée pour atténuer un vecteur d’abus de redirection ouverte. Toute tentative de définir `resultUrl` sur un tenant concerné renvoie : ```text theme={null} 403 — Customizations for resultUrl are not allowed for non-enterprise tenants ``` Pour personnaliser le champ **Redirect To** sur un tenant non Enterprise créé à compter du 5 mai 2026, communiquez avec votre équipe de compte Auth0 afin de discuter d’une mise à niveau de votre abonnement. Universal Login ignore actuellement la valeur du champ **Redirect To** dans le modèle **Password Reset** et redirige plutôt vers la [route de connexion par défaut](/docs/fr-ca/authenticate/login/auth0-universal-login/configure-default-login-routes) ou une [page d’erreur](/docs/fr-ca/authenticate/login/auth0-universal-login/error-pages). Pour personnaliser l’URL **Redirect To** de réinitialisation du mot de passe lorsque vous utilisez Universal Login, utilisez [`api.transaction.setResultURL()` du déclencheur `post-challenge` d’Actions](/docs/fr-ca/customize/actions/explore-triggers/password-reset-triggers/post-challenge-trigger/post-challenge-api-object#api-transaction-setresulturl-url,-options) Deux paramètres de requête sont ajoutés à l’URL **Redirect To** : * `success` défini à `true` ou `false`, pour indiquer si l’action a réussi * `message` défini comme description supplémentaire du résultat, par exemple « L’accès a expiré. » ou « Votre adresse e-mail a été vérifiée. Vous pouvez continuer à utiliser l’application. » Si vous rencontrez des problèmes avec l’emplacement des paramètres de requête dans les URL **Redirect To** pour les applications monopage (SPA), la solution de contournement suivante pourrait vous aider. [RFC 3986](https://tools.ietf.org/html/rfc3986#section-3) définit l’ordre attendu d’une URL comme `scheme|authority|path|query|fragment`. Toutefois, les frameworks SPA (comme Angular) s’attendent généralement à des URL au format `scheme|authority|path|fragment|query`, où la requête vient après le fragment. Cela peut poser un problème quant à l’emplacement des paramètres de requête dans les URL **Redirect To**. Si l’URL **Redirect To** de votre SPA est `http://localhost:3000/#/register`, l’utilisateur est redirigé vers `http://localhost:3000/?exampleParameter=exampleValue#/register` plutôt que vers `http://localhost:3000/#/register?exampleParameter=exampleValue`. Pour contourner cette limitation des frameworks SPA, vous pouvez : 1. Ajouter une URL côté serveur comme URL **Redirect To**, avec un paramètre `route` qui enregistre la route SPA à utiliser pour la redirection. Par exemple, `http://localhost:3000/register?route=register`. 2. Créer un contrôleur de route côté serveur qui lit `route` et les autres paramètres de l’URL, redirige vers la route SPA indiquée dans le paramètre `route`, puis ajoute les autres paramètres reçus d’Auth0. Par exemple : ```javascript lines wrap theme={null} var express = require('express'); var router = express.Router(); // Pour lire les paramètres de chaîne de requête et les convertir en chaîne : var qs = require('qs'); router.get('/register', function(req, res, next) { // Récupérer le paramètre route qui contient la route // côté client de la SPA vers laquelle l’utilisateur doit être redirigé. var route = req.query.route; // Supprimer route des paramètres de requête. delete req.query.route; // Envoyer une redirection 302 vers la route attendue. res.redirect('http://localhost:3000/#/' + route + '?' + qs.stringify(req.query)); }); module.exports = router; ```
## Tester les modèles mis à jour
Pour tester, cliquez sur **Try**, saisissez une adresse courriel valide que vous pouvez consulter, puis choisissez le type de connexion approprié. Auth0 envoie le courriel pour une application par défaut qui porte le nom de votre tenant (et non le nom convivial de votre tenant). Pour tester les modèles pour différentes applications, créez un exemple d’utilisateur afin de parcourir les flux pertinents. Vous pouvez déclencher manuellement des courriels de vérification pour des applications et des utilisateurs précis à l’aide du point de terminaison [Send an email address verification email](https://auth0.com/docs/api/management/v2#!/Jobs/post_verification_email) de la Management API.
## Exemples de cas d’utilisation de personnalisation
La personnalisation des modèles de courriel permet de répondre à de nombreux cas d’utilisation. Par exemple : Vous pouvez configurer différentes URL **Redirect To** selon le nom de votre application. Par exemple : ```liquid theme={null} {% if application.name == 'JWT.io' %} https://jwt.io {% else %} https://auth0.com {% endif %} ``` Comme le nom de l’application est encodé pour des raisons de sécurité, utilisez une valeur encodée (surtout si le nom de votre application contient un caractère qui change une fois encodé). Par exemple, utilisez `My%20App` au lieu de `My App`. À l’aide de Liquid, vous pouvez utiliser le paramètre `request_language` pour récupérer la langue à partir de la valeur de l’en-tête, ou utiliser par défaut la langue définie dans le navigateur de l’utilisateur. Par exemple : ```liquid lines theme={null} {% assign language = request_language %} {% if language %} {% assign language = request_language | slice: 0,2 %} {% endif %} {% if language == 'es' %} Cuenta de Example: bloqueada {% elsif language == 'de' %} Ihr Example wurde gesperrt {% elsif language == 'fr' %} Compte Example bloqué {% elsif language == 'ja' %} Example アカウントがブロックされました {% elsif language == 'pt' %} Conta da Example bloqueada {% elsif language == 'zh' %} Example　帐户被阻止 {% else %} Example account blocked {% endif %} ``` Vous pouvez également utiliser la propriété `user_metadata.lang` pour adapter le contenu selon la langue préférée de l’utilisateur. Par exemple, vous pouvez [utiliser une Action](/docs/fr-ca/customize/actions/actions-overview) pour définir la propriété `user_metadata.lang`, puis lire le paramètre `user_metadata.lang` dans vos modèles de courriel afin d’envoyer des courriels dans la langue appropriée. Pour un contrôle plus précis, vous pouvez envoyer des courriels en dehors de leurs flux de travail habituels et créer des tickets (des URL générées pour des actions de flux de courriel, comme les réinitialisations de mot de passe) à l’aide de la Management API. Les points de terminaison de courriel et de ticket de la Management API comprennent des paramètres supplémentaires qui vous permettent de personnaliser leur comportement. Pour en savoir plus, consultez [Personnaliser la gestion des courriels et des tickets avec la Management API](/docs/fr-ca/customize/email/manage-email-flow).