> ## 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. > Description de l’utilisation de l’outil de migration des Rules dans l’Auth0 Dashboard # Outil de migration Simplifiez le processus de migration des Rules vers les Actions à l’aide de l’outil de migration des Rules dans l’[Auth0 Dashboard](https://manage.auth0.com/). En plus de faciliter le passage d’une Rule à une Action, ce nouvel outil offre aussi des conseils intégrés et des correctifs pour les modèles de Rule courants.
## Avant la migration
Avant de commencer la migration, consultez [Passer de Rules à Actions](/docs/fr-ca/customize/actions/migrate/migrate-from-rules-to-actions). Ce guide de migration est une excellente ressource pour comprendre les différences entre Rules et Actions et vous accompagner tout au long du processus de migration.
### Ordre de migration des Rules
Les Rules s’exécutent avant les Actions, ce qui signifie qu’elles doivent être migrées dans l’ordre inverse de leur exécution. Migrez d’abord la dernière Rule à s’exécuter dans votre flux actuel, puis remontez jusqu’à la première Rule en suivant l’ordre chronologique inverse. Si vous ne respectez pas cet ordre de migration, des erreurs peuvent survenir en raison d’effets secondaires imprévus liés aux dépendances dans l’ordre des Rules et des Actions.
### Effectuer un retour arrière en toute sécurité
L’outil de migration vous permet d’effectuer un retour arrière facilement et en toute sécurité en cas de problème. Réactivez votre Rule et ignorez la logique de l’Action correspondante.
## Migration d’une Rule
Pour commencer la migration de votre Rule, sélectionnez **Auth Pipeline > Rules**. Une fois cette option sélectionnée, vos Rules s’affichent et vous pouvez les migrer individuellement. Seule la migration démarre lorsque vous choisissez **Migrate to Action**. En tant que développeur, vous pouvez choisir quand activer la nouvelle Action.
### Migrate to Action
Après avoir sélectionné **Migrate to Action**, l’outil vous invite à créer une nouvelle Action. Après avoir sélectionné **Create,** la nouvelle Action est créée et l’Actions Editor s’affiche. Si la Rule est migrée vers Actions et qu’elle est toujours active, la Rule se termine avant que la logique ne s’exécute. Cela fonctionne par l’appel de `api.rules.wasExecuted()`. Si la fonction `wasExecuted` reçoit une chaîne contenant l’ID de la Rule, elle renvoie `true` si la Rule a déjà été exécutée (sinon, elle renvoie `false`). C’est un outil utile pour éviter que votre logique ne s’exécute deux fois. Dès que vous désactivez la Rule référencée, la fonction renvoie `false` et la logique métier s’exécute alors dans l’Action. La valeur de l’ID de la Rule est renseignée automatiquement pour toute Rule migrée à l’aide de la fonctionnalité **Migrate to Action**. Pour en savoir plus sur la fonction `api.rules.wasExecuted()`, consultez [Actions Triggers: post-login - API Object](/docs/fr-ca/customize/actions/explore-triggers/signup-and-login-triggers/login-trigger/post-login-api-object).
## Réécrire le code de la Rule
Sélectionnez le bouton **Rules** dans l’Actions Editor pour charger l’outil de migration des Rules. Vous pourrez alors consulter rapidement le code de la Rule migrée. Vous devriez vérifier le code de la Rule sélectionnée dans la barre latérale. Copiez le contenu de la fonction Rule et collez-le sous le commentaire `// YOUR CODE HERE` dans l’Action. Il est probable que ce code ne soit pas adapté au modèle de programmation des Actions. L’Actions Editor indique les endroits où le code doit être refactorisé. L’éditeur propose aussi des suggestions pour corriger automatiquement la plupart des cas. Pour examiner la suggestion ou le correctif, survolez le code souligné : Vous pourrez peut-être appliquer des mises à jour propres aux Actions en sélectionnant une option dans la fenêtre modale **Quick Fix**. Lorsque vous sélectionnez le correctif recommandé, votre code est automatiquement mis à jour pour être compatible. Dans certaines situations, les correctifs ne peuvent pas être appliqués automatiquement, mais des indications sont tout de même fournies : Par exemple : dans le cas de la fonction `callback` de la Rule, il est recommandé d’utiliser [`api.access.deny`](/docs/fr-ca/customize/actions/explore-triggers/signup-and-login-triggers/pre-user-registration-trigger/pre-user-registration-api-object) pour les erreurs, ou simplement `return` en cas de réussite.
### Tester la nouvelle Action
Les Actions peuvent être testées directement dans l’éditeur, puisqu’il s’agit d’une étape essentielle de la migration. Pour en savoir plus, consultez [Test Actions](/docs/fr-ca/customize/actions/test-actions). Nous vous recommandons fortement de valider toute la logique de migration dans un tenant de développement avant de l’activer en production.
### Activation automatique de l’Action
Lorsque le code de l’Action est mis à jour et que vous êtes prêt à effectuer le changement : 1. Sélectionnez **Deploy**. 2. Dans l’alerte qui confirme votre déploiement, sélectionnez **Add to flow**. 3. Ajoutez l’Action que vous venez de créer au flux, puis sélectionnez **Apply.** 4. Sélectionnez **Continue**, **puis désactivez toutes les Rules sélectionnées** pour activer simultanément la nouvelle Action et désactiver la Rule d’origine. Si vous n’êtes pas prêt, sélectionnez **Cancel**; vous pourrez désactiver la Rule plus tard pour activer la logique de l’Action migrée. Pour en savoir plus sur l’ajout de votre Action au flux, consultez [Write your first Action](/docs/fr-ca/customize/actions/write-your-first-action). Si vous réactivez une Rule, la logique de l’Action correspondante est ignorée.
## Migrer les Rules restantes
Ce processus peut être répété pour migrer chaque Rule de votre flux de connexion. Rappelez-vous que les Rules doivent être migrées dans l’ordre inverse de celui dans lequel elles s’exécutent dans le flux de connexion.