Auth0 cesse d'exécuter les Rules et les Hooks après le 18 novembre. Une Rule qui refuse des connexions cesse de les refuser

La page « Deprecations and Migrations » d'Auth0 donne trois dates pour les Rules et les Hooks : dépréciés le 16 mai 2023, en lecture seule depuis le 18 novembre 2024, fin de vie le 18 novembre 2026. La phrase qui suit est courte : « After November 18, 2026, Rules and Hooks will stop being executed and removed », c'est-à-dire qu'après le 18 novembre 2026, les Rules et les Hooks cesseront d'être exécutés et seront supprimés.

L'avertissement en haut de la documentation des Rules et des Hooks précise qui est concerné. Aucun des deux produits n'est disponible pour les tenants créés à partir du 16 octobre 2023. Les tenants existants qui les avaient les ont gardés, et le remplaçant s'appelle Actions, qu'Auth0 a introduit en 2020.

La population est donc précise : tout tenant Auth0 créé avant le 16 octobre 2023 qui a encore une Rule ou un Hook actif. Avant les Actions, les Rules étaient la façon de personnaliser une connexion Auth0, donc c'est souvent du vieux code sur un chemin critique.

Je suis CTO d'une LegalTech et je publie des apps iOS en développeur indépendant. La connexion est la partie d'un produit que j'ai le moins envie de voir modifiée par le calendrier d'un fournisseur. Voici comment je lis cette échéance, et ce que je vérifierais avant.

« Cesser d'être exécuté » ne veut pas dire « échouer »

Regarde ce que la page ne dit pas. Elle ne dit pas que les connexions échoueront le 19 novembre. Elle dit que le code cesse de tourner. Ça paraît plus sûr que ça ne l'est.

Les Rules s'exécutent dans le pipeline post-login. Elles font typiquement quatre choses : ajouter des claims personnalisés aux jetons d'ID et d'accès, déclencher l'authentification multifacteur, écrire des métadonnées utilisateur et refuser l'accès. Les Hooks couvrent d'autres moments : l'échange d'identifiants client, la pré-inscription d'un utilisateur, sa post-inscription, le changement de mot de passe et l'envoi de messages sur téléphone.

Quand ce code cesse de tourner, chaque effet disparaît de son côté, et aucun ne s'annonce :

• Une Rule qui ajoutait un claim de rôles cesse de l'ajouter. Rien sur la page ne dit que la connexion échoue, donc pars du principe qu'elle réussit et que ton API reçoit des jetons sans le claim, et la suite dépend de la façon dont ton API traite un claim manquant.
• Une Rule qui positionnait context.multifactor pour certains utilisateurs cesse de déclencher la MFA pour eux. Sauf si la MFA est exigée autrement, ils se connectent sans.
• Une Rule qui refusait des connexions (e-mail non vérifié, mauvais domaine, indicateur de compte bloqué) cesse de les refuser.
• Un Hook de pré-inscription qui filtrait les inscriptions cesse de filtrer.

Une connexion cassée se signale vite. Un contrôle qui a cessé de tourner en silence, c'est quelqu'un d'autre qui le trouve, plus tard.

Le code est figé depuis presque deux ans

D'après la même page, les Rules et les Hooks sont en lecture seule depuis le 18 novembre 2024. Tu peux les activer et les désactiver et changer leurs valeurs de configuration ou leurs secrets, mais tu ne peux pas modifier leur code source : ni dans le Dashboard, ni par la Management API, ni avec Terraform, ni avec l'Auth0 Deploy CLI. La page prévient aussi que les flux CI/CD automatisés ne doivent pas tenter d'opérations de gestion non prises en charge sur eux.

Autrement dit : chaque Rule encore active est du code que, selon Auth0, personne ne peut modifier depuis le 18 novembre 2024. Si l'une d'elles a un bug, les seuls remèdes restants sont de la désactiver ou de la migrer.

La date a déjà bougé. Le billet de blog d'Auth0 du 15 mai 2023 disait que les Rules et les Hooks seraient supprimés de tous les tenants le 18 novembre 2024. Cette date est devenue celle du passage en lecture seule, et la page des dépréciations garde la ligne « Auth0 has delayed the removal of Rules and Hooks functionality to a future date » (Auth0 a repoussé à une date ultérieure la suppression des fonctionnalités Rules et Hooks). La page générale « Migration Process » d'Auth0 dit aussi que les dates de fin de vie peuvent varier selon les types de forfait. Je ne compterais pas sur un second report. Si tu es sous contrat Enterprise et que tu penses avoir des conditions différentes, obtiens-les par écrit.

Ce que les guides de migration ne mettent pas en avant

Auth0 publie deux guides, Rules vers Actions et Hooks vers Actions, plus un outil « Migrate to Action » dans le Dashboard. Ils sont bons. Quatre détails méritent plus d'attention qu'ils n'en reçoivent.

L'ordre compte. Les Rules s'exécutent avant les Actions. La page d'outillage de migration d'Auth0 dit de migrer dans l'ordre inverse : la dernière Rule du flux d'abord, puis en remontant jusqu'à la première. Les Actions migrées peuvent appeler api.rules.wasExecuted() avec l'ID de la Rule pour que la même logique ne tourne pas deux fois pendant que les deux sont actives.

Les guides citent des runtimes périmés. Le guide des Rules te demande encore de choisir Node 16 en créant l'Action, celui des Hooks Node 18, une version que le projet Node.js a cessé de prendre en charge le 30 avril 2025. La même page des dépréciations dit que les runtimes d'extensibilité Node 12 et 16 ont atteint leur fin de vie le 15 août 2025, et qu'une fois supprimés, le code d'extensibilité est forcé de tourner sur Node 22. J'écrirais et testerais chaque Action migrée sur Node 22.

Certaines habitudes des Rules ne survivent pas. Les Actions n'ont ni jeton d'accès à la Management API ni objet global auth0. Pour appeler la Management API, tu enregistres une application machine à machine et tu l'autorises. Les secrets se définissent par Action, alors que les Rules partageaient une configuration globale. Le cache des Actions conserve les éléments 24 heures au maximum, 20 entrées par déclencheur, 8 ko au total, et n'est pas garanti d'une exécution à l'autre. Un déclencheur doit se terminer en 20 secondes. Côté Hooks, les Actions ne peuvent pas conserver de données comme des jetons d'accès d'une exécution à l'autre.

Certaines choses n'ont pas encore d'équivalent. La page « Actions Migration Limitations » d'Auth0 les liste : pas de remplacement pour context.connectionOptions, pas d'accès aux jetons du fournisseur d'identité amont via user.identities, les claims standard d'un jeton d'ID ne peuvent pas être supprimés, les Actions renvoient « access denied » mais pas « unauthorized », et pour les comptes liés, les Actions ne permettent de modifier que l'utilisateur principal. Une Rule qui dépend de l'un de ces points ne se migre pas en copier-coller. C'est une refonte, et c'est la première à regarder, pas la dernière.

Ce que je vérifierais avant le 18 novembre

Si je reprenais un tenant Auth0 sur une mission freelance, voici l'ordre que je suivrais.

1. Liste tous les tenants, pas seulement la production. Développement, staging, l'ancien tenant de démo qu'un client utilise encore. Note chaque date de création. Tout ce qui date d'avant le 16 octobre 2023 est à vérifier.
2. Liste chaque Rule activée (Auth Pipeline > Rules dans le Dashboard) et chaque Hook activé. Copie le code de chacun : un code en lecture seule se lit encore, et le guide d'Auth0 commence lui-même par le copier.
3. Note chaque effet et son consommateur. « Ajoute https://example.com/roles au jeton d'accès, lu par l'API de facturation. » Le consommateur est l'endroit où l'échec se verra, donc c'est lui que tu testes.
4. Décide ce que veut dire un claim manquant. Si ton API traite un claim de rôles manquant comme un utilisateur ordinaire, une Rule supprimée dégrade les gens. Si elle le traite comme « aucune restriction », tu as une faille. Le choix sûr par défaut est de refuser, et tu peux le livrer avant de migrer quoi que ce soit.
5. Migre la dernière Rule en premier, sur Node 22, dans un tenant de développement. Utilise l'outil du Dashboard, garde wasExecuted en place, puis désactive la Rule.
6. Compare les jetons. Décode un jeton d'ID et un jeton d'accès émis avant la migration et un émis après, pour le même utilisateur de test. Chaque claim personnalisé présent avant doit toujours être là après.
7. Nettoie la configuration de déploiement. Si Terraform ou le Deploy CLI déclare encore des Rules ou des Hooks, retire-les une fois les Actions en ligne, pour que ton pipeline cesse de gérer des ressources qu'Auth0 supprime après le 18 novembre.

C'est aussi le genre d'inventaire que je confierais à Claude Code : lire les Rules copiées, lister chaque claim, chaque refus et chaque appel externe qu'elles font, et chercher dans le code chaque consommateur de ces claims. Le jugement reste à moi. La lecture va plus vite.

Pour une petite entreprise dont une app a été construite par une agence avant fin 2023, la question est plus simple. Demande à celui qui détient le compte Auth0 si le tenant a des Rules ou des Hooks actifs. Si personne ne sait qui le détient, c'est la première chose à régler.

Auth0 a donné deux ans de plus à ce code. Passe les dernières semaines à découvrir ce qu'il faisait.

Sources

• Auth0 Docs, « Deprecations and Migrations » (consulté le 19 octobre 2026)
• Auth0 Docs, « Auth0 Rules » (consulté le 19 octobre 2026)
• Auth0 Docs, « Auth0 Hooks » (consulté le 19 octobre 2026)
• Auth0 Blog, « Preparing for Rules and Hooks End of Life » (15 mai 2023)
• Auth0 Docs, « Migrate from Rules to Actions » (consulté le 19 octobre 2026)
• Auth0 Docs, « Migrate from Hooks to Actions » (consulté le 19 octobre 2026)
• Auth0 Docs, « Migration tooling » (consulté le 19 octobre 2026)
• Auth0 Docs, « Actions Migration Limitations » (consulté le 19 octobre 2026)
• Auth0 Docs, « Actions Limitations » (consulté le 19 octobre 2026)
• Auth0 Docs, « Migration Process » (consulté le 19 octobre 2026)
• Node.js Release Working Group, calendrier des versions (consulté le 19 octobre 2026)