Créer une page de connexion WordPress sur mesure, sécurité comprise

L'écran de connexion livré avec WordPress remplit sa fonction et raconte immédiatement au visiteur quel outil fait tourner le site, avec une identité visuelle qui n'est pas la vôtre. Pour un espace client, un extranet ou une plateforme d'adhérents, cette rupture est gênante. Le remplacer par une page maison est parfaitement faisable, à condition de comprendre que l'on ne touche pas seulement à l'apparence : le formulaire natif s'appuie sur des vérifications, des jetons et des redirections dont la reproduction approximative crée des ouvertures. Cet article décrit la construction complète, du formulaire aux mesures de protection qui doivent l'accompagner.

Pourquoi remplacer l'écran natif

La décision mérite d'être motivée, parce qu'elle ajoute du code à maintenir dans un domaine sensible. Trois raisons la justifient réellement, et beaucoup d'autres tiennent davantage du confort que du besoin. Le fonctionnement de l'écran d'origine et ses possibilités de réglage sont détaillés dans notre article sur la manière de créer sa propre page de connexion WordPress.

La cohérence de marque

Sur un site où la connexion fait partie du parcours normal, espace client, réservation, formation en ligne, l'écran natif brise l'expérience au moment le plus engageant. L'utilisateur passe d'un univers soigné à une page générique qui ressemble à mille autres. Cette rupture augmente les abandons et les demandes au support, deux effets mesurables. Une page reprenant l'identité du site rassure et réduit ces frictions sans changer un mot de la mécanique sous jacente. L'effet est particulièrement net sur les publics peu familiers du web, qui interprètent souvent le changement d'apparence comme une erreur de navigation.

Le parcours après connexion

Le comportement par défaut envoie l'utilisateur vers l'administration, ce qui n'a aucun sens pour un abonné qui n'y a rien à faire. Rediriger selon le rôle vers un tableau de bord dédié fait partie des raisons les plus solides de reprendre la main sur le processus. Ce réglage seul ne demande d'ailleurs pas une page complète et peut se faire par un filtre, ce qui vaut la peine d'être vérifié avant de tout réécrire. Beaucoup de projets construisent une page entière pour un besoin que trois lignes couvraient. Poser la question de la destination souhaitée dès le cahier des charges permet d'identifier ce cas de figure avant d'engager du développement.

Les champs supplémentaires

Un site imposant une sélection d'établissement, un code d'accès ou un choix de langue dès la connexion ne peut pas le faire proprement sur l'écran natif. La page maison permet d'ajouter ces éléments dans un formulaire cohérent plutôt que de les injecter par des accroches successives. Cette raison est valable, à condition que ces champs soient réellement nécessaires au moment de la connexion et non simplement souhaitables. La tentation d'en ajouter est forte et chaque champ réduit le taux de réussite au premier essai. Un champ qui peut être demandé après la connexion, dans le profil ou lors de la première action, doit l'être.

Ce qui ne justifie pas le remplacement

Changer le logo, la couleur de fond ou la police de l'écran natif se fait par quelques règles de style ajoutées via une accroche prévue à cet effet. Aucune page maison n'est nécessaire pour cela. De même, masquer l'adresse d'origine relève d'une autre technique, décrite plus loin, et ne demande pas de réécrire le formulaire. Distinguer ces besoins évite de se retrouver avec du code sur mesure là où une configuration suffisait. La règle pratique consiste à commencer par la solution la plus légère et à ne monter en complexité que lorsqu'elle se révèle insuffisante.

Le coût de maintenance

Un formulaire de connexion maison doit être relu à chaque mise à jour majeure du cœur, car les fonctions employées peuvent évoluer. Ce travail est léger et il n'est pas nul, et il incombe à quelqu'un pendant toute la vie du site. Sur un projet destiné à durer, cette charge doit être acceptée consciemment. Elle constitue le principal argument en faveur d'une solution minimale plutôt que d'une réécriture complète. Un code court, appuyé sur les fonctions du cœur, traverse les versions sans intervention dans la quasi totalité des cas.

Le choix entre extension et code

Des extensions proposent cette fonction avec une interface de réglage, ce qui convient parfaitement à un besoin standard. Le code sur mesure se justifie lorsque le parcours sort de l'ordinaire ou lorsque l'on refuse d'ajouter une dépendance supplémentaire. Les deux voies sont légitimes et le choix dépend surtout de qui maintiendra le site dans trois ans. Une équipe technique interne penchera vers le code, un client autonome vers l'extension réglable. Ce critère de reprise pèse davantage, sur la durée de vie d'un site, que la différence technique entre les deux approches.

Construire la page sans casser le mécanisme

La construction repose sur une poignée de fonctions prévues par le cœur, et le respect de leur usage garantit que la page bénéficie de toutes les vérifications existantes. S'en écarter, notamment en interrogeant directement la base, revient à réécrire un mécanisme d'authentification, ce qui n'est jamais souhaitable. Cette prudence rejoint les constats que nous formulons dans notre article sur l'audit de sécurité WordPress étape par étape.

Le gabarit de page dédié

La page se construit comme un gabarit associé à une page publiée, ce qui permet de l'appeler par une adresse propre et de la gérer depuis l'administration. Ce gabarit ne charge ni le menu ni la barre latérale et se concentre sur le formulaire. Le sélectionner sur une page vide suffit à obtenir l'adresse souhaitée. Cette approche reste préférable à une réécriture d'adresse dans la configuration du serveur, plus difficile à maintenir. Elle présente aussi l'avantage de rester visible depuis l'interface, ce qui évite qu'un intervenant ultérieur ne cherche longtemps d'où vient la page.

Le formulaire fourni par le cœur

Une fonction native produit un formulaire complet, avec ses champs, son jeton et son champ de redirection, à partir d'un tableau d'options. Elle permet de choisir les libellés, l'adresse de retour et la présence de la case de mémorisation. L'employer plutôt que d'écrire le formulaire à la main supprime d'un coup toute une catégorie d'erreurs. Le rendu peut ensuite être habillé librement, puisque seule la structure compte pour le traitement. Les identifiants et classes générés étant stables, les règles de style écrites une fois continuent de s'appliquer après les mises à jour.

Le jeton de sécurité

Si vous écrivez le formulaire vous même, le champ de vérification anti falsification doit être présent et contrôlé au traitement. Sans lui, un tiers peut faire soumettre le formulaire depuis un autre site, avec les conséquences que cela suppose. Cette vérification tient en une fonction et son oubli est la faute la plus fréquente sur les formulaires maison. Le formulaire natif l'inclut automatiquement, ce qui constitue un argument supplémentaire en sa faveur. Écrire le formulaire à la main ne se justifie que si la structure attendue par le rendu graphique s'écarte réellement de celle produite par le cœur.

Le traitement de la soumission

La fonction d'authentification du cœur prend un tableau contenant identifiant, mot de passe et mémorisation, et renvoie soit l'utilisateur, soit un objet d'erreur. Elle applique au passage l'ensemble des filtres posés par les extensions de sécurité installées, ce qui préserve leur fonctionnement. Contourner cette fonction désactive silencieusement ces protections, situation particulièrement dangereuse puisque rien ne le signale. C'est le point sur lequel il ne faut jamais improviser. La règle vaut aussi pour les extensions installées après coup : elles supposent que la connexion passe par cette fonction et cessent d'agir dès que ce n'est plus le cas.

Les messages d'erreur

Le comportement natif indique si c'est l'identifiant ou le mot de passe qui est erroné, information qui permet de vérifier l'existence d'un compte. Sur un site public, un message unique et neutre est préférable, et il se met en place par un filtre sur le rendu des erreurs. Ce choix dégrade légèrement le confort et il ferme un chemin de reconnaissance de comptes. Il se discute selon la nature du site, un extranet interne n'ayant pas les mêmes contraintes qu'une plateforme ouverte. Dans le doute, le message neutre reste le choix par défaut, quitte à l'assouplir ensuite si le support constate un volume anormal de demandes.

Les redirections

La destination après connexion se règle par un filtre recevant l'utilisateur et l'adresse demandée. Rediriger selon le rôle, vers l'administration pour les gestionnaires et vers un espace dédié pour les autres, couvre la majorité des besoins. La destination doit être validée avant d'être utilisée, une adresse fournie dans la requête ne devant jamais être suivie sans contrôle, sous peine de créer une redirection ouverte. Cette vérification est simple et régulièrement omise. Elle consiste à comparer la destination demandée au domaine du site et à retomber sur une adresse connue en cas d'écart.

Les mesures de sécurité qui accompagnent le changement

Remplacer l'écran ne protège rien par lui même et peut au contraire affaiblir l'ensemble si les protections existantes cessent de s'appliquer. Quelques mesures complémentaires rétablissent et améliorent le niveau atteint auparavant.

Neutraliser l'entrée d'origine

Laisser l'adresse native accessible en parallèle de la nouvelle page crée deux portes, dont une échappe à vos réglages de messages et de redirection. Une redirection de l'ancienne adresse vers la nouvelle règle la question, en veillant à ne pas casser le traitement de la soumission ni la procédure de réinitialisation. Ce point demande un test soigneux, car une redirection trop large empêche toute connexion, y compris la vôtre. Prévoir un moyen de rétablir l'accès avant de déployer évite une situation inconfortable. Un déploiement mené en dehors des heures d'affluence laisse par ailleurs le temps de corriger sans pression.

Limiter les tentatives

Un formulaire de connexion accessible publiquement subit des essais automatisés en permanence. Une limitation par adresse réseau et par identifiant est indispensable, et elle passe soit par une extension éprouvée, soit par un filtre maison stockant les échecs. La solution maison est formatrice et elle demande de penser au nettoyage des enregistrements et aux réseaux partagés. Pour un site classique, l'extension reste le choix raisonnable. Elle apporte en général un tableau des tentatives récentes, information utile pour ajuster les seuils au trafic réellement constaté.

Ajouter un second facteur

Le second facteur constitue la protection la plus efficace contre le rejeu d'identifiants issus de fuites. Il s'ajoute par une extension conforme au standard des codes temporels et s'intègre au formulaire maison sans difficulté particulière. Sa mise en place est développée dans notre article sur la façon d'ajouter la double authentification à WordPress. Il vaut mieux l'imposer aux seuls comptes disposant de droits élevés dans un premier temps. L'extension à l'ensemble des utilisateurs se décide ensuite, en fonction de la sensibilité des données accessibles et de l'aisance du public concerné.

Surveiller les connexions

Journaliser les tentatives réussies et échouées, avec l'horodatage et l'adresse réseau, permet de constater une anomalie avant qu'elle ne produise ses effets. Ce journal ne doit contenir aucun mot de passe, même tronqué, et sa durée de conservation doit être définie en cohérence avec les obligations applicables aux données personnelles. Nous ne sommes pas juristes et ce point mérite un avis compétent selon votre situation. Une notification par courriel lors d'une connexion administrateur complète utilement ce dispositif.

Protéger la procédure de réinitialisation

La page de connexion maison ne doit pas conduire à réécrire la réinitialisation du mot de passe, qui est correctement traitée par le cœur. Se contenter de pointer vers le parcours natif, en l'habillant si nécessaire, évite d'introduire des faiblesses dans le maillon le plus sensible. Toute tentative de reproduire ce mécanisme demande de gérer des jetons hachés, à usage unique et limités dans le temps, travail que le cœur fait déjà correctement. Le seul aménagement raisonnable consiste à appliquer la charte graphique aux écrans concernés, sans toucher à la logique.

Vérifier les droits après connexion

Une redirection vers un espace réservé ne remplace pas un contrôle de droits sur la page de destination. Un utilisateur peut toujours saisir l'adresse directement, et seule une vérification côté serveur l'en empêche. Cette évidence est régulièrement oubliée sur les espaces construits rapidement, où la sécurité repose sur le fait que le lien n'est affiché à personne. La discrétion n'a jamais constitué une protection. Une vérification en tête de gabarit, renvoyant vers la page de connexion lorsque les droits manquent, suffit à fermer ce chemin.

Vérifier, maintenir et prévoir les cas limites

Un dispositif de connexion se teste dans des situations que l'usage normal ne rencontre pas, et c'est précisément là qu'il révèle ses défauts.

La liste des cas à tester

Connexion réussie, mot de passe erroné, identifiant inexistant, compte désactivé, session expirée, accès direct à une page protégée, retour arrière après déconnexion : chacun de ces cas doit produire un comportement défini. Les parcourir prend une demi heure et met en évidence les oublis. Cette liste s'écrit une fois et se rejoue après chaque intervention sur le dispositif. C'est le meilleur investissement de tout le chantier.

Prévoir un accès de secours

Une erreur dans la redirection de l'adresse native peut vous enfermer dehors. Disposer d'un accès aux fichiers par transfert ou en ligne de commande permet de désactiver le code fautif en quelques secondes. Vérifier cet accès avant de déployer, et non après l'incident, fait partie des réflexes qui distinguent une intervention préparée d'une improvisation. Un fichier de configuration commenté est souvent tout ce dont on a besoin.

Tester après chaque mise à jour

Les fonctions employées évoluent rarement et elles évoluent parfois, et une extension de sécurité mise à jour peut modifier le comportement des filtres. Rejouer la liste de tests après les mises à jour majeures évite de découvrir un problème par un appel client. Cette vérification prend quelques minutes et elle se planifie comme les sauvegardes. Sur un site à enjeu, elle mérite d'être inscrite dans une procédure écrite.

Gérer les comptes multiples

Sur un site où un même utilisateur peut disposer de plusieurs profils, la redirection selon le rôle demande une règle explicite. Le comportement par défaut choisit le rôle le plus élevé, ce qui n'est pas toujours l'intention. Poser cette règle par écrit avant de coder évite des comportements surprenants difficiles à diagnostiquer ensuite. Ce cas est fréquent sur les plateformes mêlant clients et intervenants.

Penser aux utilisateurs en difficulté

Une part des demandes au support concerne des personnes qui ne parviennent pas à se connecter pour des raisons banales, majuscule automatique, gestionnaire de mots de passe, ancien identifiant. Prévoir un message clair, un lien de réinitialisation visible et un moyen de contact réduit sensiblement ce volume. Ces éléments coûtent quelques minutes de travail et se rentabilisent dès le premier mois d'exploitation.

Documenter le dispositif

Une note de quelques lignes indiquant où se trouve le code, quels filtres sont posés et quelles extensions interviennent fait gagner un temps considérable à la personne qui reprendra le site. Sans elle, un successeur passe une demi journée à comprendre pourquoi l'adresse native redirige. Cette documentation s'écrit au moment du développement, jamais après, et elle fait partie de la livraison au même titre que le code.