Un client du secteur bancaire nous a demandé, un vendredi après-midi, d’activer l’authentification à deux facteurs sur l’ensemble des comptes administrateurs de son site vitrine. Rien d’exceptionnel en soi : le site recevait des tentatives de connexion suspectes chaque semaine. Le problème est apparu deux heures plus tard, quand l’intégratrice en charge des pages produits n’arrivait plus à sauvegarder ses modifications dans Elementor.
Le 2FA en lui-même fonctionne très bien avec WordPress. C’est son interaction avec le flux de connexion à l’éditeur Elementor qui mérite une attention particulière, surtout quand le plugin de 2FA touche aussi aux sessions AJAX ou au chargement de scripts en arrière-plan.
Ce qui se passe réellement à la connexion
Elementor charge son éditeur dans un contexte qui dépend fortement de la session WordPress active et des nonces générés à l’ouverture de page. Un plugin de 2FA mal configuré peut interrompre ce cycle de deux façons : en redirigeant systématiquement vers un écran de vérification même pour les requêtes internes (AJAX, REST), ou en invalidant la session après un délai plus court que celui attendu par l’éditeur.
Sur le site en question, le plugin de 2FA utilisé imposait une revalidation toutes les vingt minutes, alors que les sessions d’édition Elementor dépassent souvent une heure sur des pages complexes avec beaucoup de widgets. Résultat : l’éditeur perdait la main en plein milieu d’une modification, sans message d’erreur clair, juste un blocage silencieux des appels vers admin-ajax.php.
Checklist avant d’activer le 2FA sur un site Elementor
- Vérifier que le plugin de 2FA n’intercepte pas les requêtes
action=elementor_ajaxune fois la session ouverte. - Contrôler la durée de vie de session comparée à la durée moyenne d’une séance d’édition sur le site (souvent sous-estimée).
- Exclure les appels REST liés à l’éditeur (
/wp-json/elementor/v1/) des règles de re-authentification strictes si le plugin de 2FA propose ce niveau de filtrage. - Tester la sauvegarde d’un widget complexe (formulaire, popup) juste après expiration théorique de la fenêtre de confiance du 2FA.
- Documenter un compte de secours avec 2FA désactivé, accessible uniquement en cas de blocage total, jamais utilisé en production courante.
- Vérifier que le mode de prévisualisation (preview) d’Elementor n’ouvre pas un nouvel onglet non authentifié qui déclenche une boucle de connexion.
Le piège de l’exclusion mal ciblée
Face à ce type de blocage, le réflexe est souvent d’exclure purement et simplement l’URL de l’éditeur (?elementor en paramètre GET) de toute vérification 2FA. C’est une fausse bonne idée : cela revient à créer une porte dérobée sur exactement la fonctionnalité qui permet de modifier le contenu public du site. Un attaquant qui devine ce paramètre contournerait la protection que vous venez d’installer.
La bonne approche consiste à distinguer deux couches : l’authentification initiale sur wp-login.php, qui doit rester strictement protégée par le 2FA, et la persistance de session pendant l’édition, qui doit simplement être suffisamment longue pour ne pas interrompre un travail en cours. Ce sont deux réglages différents dans la plupart des plugins de 2FA sérieux, et confondre les deux mène soit à une sécurité illusoire, soit à un éditeur inutilisable.
Un compromis qui fonctionne en production
Sur ce projet, la solution retenue a combiné trois éléments : une durée de session à deux heures pour les rôles ayant accès à Elementor, un cookie de confiance sur l’appareil valable sept jours pour les postes de l’agence identifiés, et un compte de secours séparé, avec un mot de passe fort mais sans 2FA, gardé hors ligne dans un coffre-fort numérique de l’agence pour les cas de blocage matériel (téléphone perdu, application d’authentification cassée).
Ce dernier point est souvent négligé. Un 2FA basé sur une application mobile TOTP sans code de secours imprimé revient à parier que personne ne perdra jamais son téléphone. Sur un site où l’éditeur Elementor est utilisé quotidiennement par plusieurs personnes, ce pari finit toujours par être perdu, généralement le jour où une mise à jour urgente doit sortir.
Le 2FA protège la porte d’entrée, pas la pièce dans laquelle on travaille. Sur un site géré avec Elementor, il faut sécuriser les deux séparément, avec des règles différentes.
Notre verdict
Activer le 2FA sur un site Elementor Pro ne pose aucun problème de fond : la compatibilité technique existe. Le vrai travail consiste à cartographier les points de friction entre le cycle de session du plugin de sécurité et le cycle de travail réel de l’éditeur visuel, puis à ajuster les durées en conséquence plutôt que de multiplier les exclusions hasardeuses. Sur un site à forte visibilité, mieux vaut une heure de tests supplémentaire avant la mise en production qu’un ticket de support paniqué un vendredi soir.
