Console d'administration d'un parc de sites WordPress
Une interface unique pour attribuer sites et outils à une équipe, notifier en temps réel et ouvrir une session WordPress sans partager de mot de passe.
Rôle · Conception, back-end WordPress et front-end Next.js (solo)
0
mot de passe transmis à un intervenant
6 types de ressources pilotés depuis un seul écran
types de ressources pilotés depuis un seul écran
4 sources réunies dans une même recherche
sources réunies dans une même recherche
- Client
- Projet interne
- Période
- Septembre - décembre 2025
- Durée
- 4 mois
- Livrables
- Console d’administration : comptes, sites, catégories et outils au même endroit
- Espace intervenant cloisonné - chacun ne voit que ce qui lui est attribué
- Ouverture de session WordPress déléguée, sans transmission d’identifiant
- Notifications en temps réel à chaque accès donné ou retiré
- Recherche globale réunissant comptes, sites, catégories et outils
Le problème
Une agence qui entretient plusieurs dizaines de sites WordPress se heurte vite au même mur : chaque site a ses identifiants, chaque outil sous licence a sa clé, et tout cela circule par messagerie. Les accès sont partagés entre plusieurs intervenants sans que personne ne sache précisément qui détient quoi. Quand quelqu'un arrive ou s'en va, les mots de passe restent en circulation, et rien ne dit sur quels sites il est intervenu.
L'application répond à ce besoin par une console unique. Un administrateur y déclare les sites, les catégories et les outils, puis attribue à chaque intervenant exactement ce dont il a besoin. L'intervenant, de son côté, ne voit que ce qui lui a été attribué et ouvre une session sur un site sans jamais recevoir son mot de passe.
Le parti technique structurant est le découplage : WordPress reste la source de vérité - c'est déjà l'outil du métier, et un plugin dédié y expose les attributions, les notifications et la recherche. L'application Next.js n'a pas de base de données propre ; elle est une tête d'affichage et une couche d'orchestration au-dessus de l'API REST.
Dix modules, dix problèmes réglés
| Module | Ce qu'il règle |
|---|---|
| Comptes et rôles | Ouvrir, modifier ou fermer un accès depuis un seul écran ; fermer un compte retire d'un coup toutes les attributions qui y étaient rattachées. |
| Sites | Le parc décrit une fois pour toutes - adresse, catégorie, identifiants - puis filtré : chacun ne voit que les siens. |
| Catégories | Un classement qui survit à la suppression : les sites d'une catégorie effacée basculent en « non classé » au lieu de disparaître. |
| Outils et licences | Clés de licence et comptes partagés cessent de circuler par messagerie : ils s'attribuent exactement comme un site. |
| Attributions | Donner ou reprendre un accès en deux gestes, sans doublon possible : la sélection est comparée à l'existant avant écriture. |
| Ouverture de session | Un lien à usage unique ouvre le tableau de bord du site sans qu'aucun mot de passe ne change de main. |
| Notifications | Chaque accès donné, repris ou utilisé remonte en temps réel : l'activité sur le parc cesse d'être invisible. |
| Recherche globale | Une fenêtre unique interroge comptes, sites, catégories et outils - plus besoin de savoir dans quel écran chercher. |
| Présence | Un battement toutes les trente secondes indique qui travaille, sans que personne ait à le déclarer. |
| Tableau de bord | Les compteurs du parc restent visibles pendant toute la navigation, dont ce qui n'est encore attribué à personne. |
Les écrans, sur jeu de démonstration
Chaque compte porte son rôle et les sites qu'on lui a confiés. Fermer le compte retire les attributions avec lui. Les licences et comptes partagés s'administrent comme les sites, au lieu de circuler par messagerie. Supprimer une catégorie ne supprime pas ses sites : ils repassent en « non classé ».
Le parcours d'attribution, de bout en bout
L'administrateur attribue
Depuis la table des sites ou des outils, il sélectionne un ou plusieurs intervenants. La requête compare d'abord la sélection aux attributions déjà en place et n'écrit que le complément.
L'attribution est écrite dans WordPress
Le plugin métier enregistre le lien intervenant / ressource et renvoie son identifiant. Le libellé lisible de la ressource est récupéré dans la foulée, avec un repli sur un identifiant technique si l'appel échoue.
La notification part par deux chemins
Elle est d'abord persistée dans WordPress, ce qui la rend consultable au prochain chargement, puis diffusée sur le canal privé de l'intervenant concerné. Un échec de diffusion n'annule jamais l'attribution.
L'intervenant ouvre le site
Depuis sa liste, il demande une ouverture de session. L'application négocie auprès du site cible un lien à usage unique, dont le jeton expire au bout de cinq minutes, et prévient les administrateurs de l'accès - sans que le mot de passe transite jamais par l'interface.
Décisions d'architecture
Le gabarit de départ imposait une base de données dédiée, avec sa couche de mapping objet-relationnel et ses migrations. Or les sites, les utilisateurs et les catégories existaient déjà dans WordPress.
- Options envisagées
- Recopier les données dans une base propre et les synchroniser en continu, ou traiter WordPress comme la seule source de vérité et n'écrire aucune donnée localement.
- Choix retenu
- Source de vérité unique dans WordPress. La couche de persistance du gabarit a été entièrement retirée : plus aucune dépendance de mapping objet-relationnel, aucun schéma, aucune migration.
- Pourquoi
- Deux copies d'une même donnée, c'est un travail de synchronisation permanent et une classe entière d'incohérences. Les entités vivent déjà dans WordPress, où les équipes les administrent par ailleurs. Le coût déplacé est réel et assumé : chaque écran dépend de la latence de l'API distante, ce que le cache client compense.
Une attribution doit apparaître chez l'intervenant sans qu'il recharge sa page, mais l'infrastructure ne comportait pas de serveur de sockets.
- Options envisagées
- Interroger le serveur à intervalle régulier, tenir un serveur de sockets, ou s'appuyer sur un service de diffusion géré.
- Choix retenu
- Service de diffusion géré, avec un canal privé par utilisateur. L'interrogation périodique est explicitement désactivée ; il ne reste qu'un rafraîchissement au retour sur l'onglet.
- Pourquoi
- L'interrogation périodique consomme des requêtes en continu pour un événement rare, et un serveur de sockets aurait été une brique à exploiter pour une seule fonction. Le repli est explicite : si l'abonnement n'aboutit pas en quatre secondes, le cache est invalidé et les données sont rechargées - la fonctionnalité se dégrade sans jamais se bloquer.
Marquer une notification comme lue, ou en supprimer une, suppose un aller-retour réseau vers WordPress. L'attente était perceptible sur des gestes répétitifs.
- Options envisagées
- Attendre la confirmation du serveur avant de redessiner, ou appliquer le changement immédiatement et corriger en cas d'échec.
- Choix retenu
- Mise à jour optimiste sur les quatre mutations de la liste, avec capture de l'état antérieur, restauration en cas d'erreur et réconciliation systématique.
- Pourquoi
- Sur des gestes à faible enjeu et à fort taux de succès, l'attente coûte plus qu'un rare retour en arrière. Le point de vigilance est la discipline : sans restauration de l'état capturé, une erreur laisserait l'interface durablement fausse.
L'indicateur de présence supposait un état partagé entre requêtes, alors qu'aucun magasin externe n'était provisionné.
- Options envisagées
- Ajouter un magasin clé-valeur en mémoire distribuée, une table dédiée, ou accepter un registre en mémoire du processus.
- Choix retenu
- Registre en mémoire du processus, purgé toutes les cinq minutes, avec la limite documentée dans le fichier lui-même.
- Pourquoi
- La présence est une donnée de confort dont la perte est sans conséquence : au pire, un intervenant apparaît hors ligne jusqu'à son prochain battement, trente secondes plus tard. Provisionner une brique d'infrastructure pour cela aurait été disproportionné. La limite est réelle et connue - l'état ne survit pas à un redémarrage et ne se partage pas entre plusieurs instances.
Limites connues
L'état actuel est celui d'un projet livré fonctionnellement, pas durci. Trois chantiers restent ouverts et identifiés : le contrôle d'accès est arbitré côté navigateur, sans garde équivalente sur les routes serveur ; les identifiants des sites gérés transitent en clair jusqu'au client au lieu de rester côté serveur ; et des secrets ont été écrits en dur pendant la phase de mise au point, ce qui impose une rotation avant toute publication. Les nommer relève du même travail que les avoir écrits.
L'identité visuelle fait partie du travail
L'outil n'a pas seulement été développé : il a été nommé, dessiné et animé. Le logo part d'un fennec stylisé - un animal choisi pour ce qu'il évoque de vigilance et de rapidité, deux qualités qu'on attend d'un système d'accès - dans lequel se lit l'initiale de la structure. Continuité avec l'identité mère, sans en être une copie.
La palette tient en deux teintes chaudes posées sur un fond sombre, et la typographie est une sans-serif géométrique en capitales : lisible sur écran, sobre, et qui laisse le logo porter la personnalité. Le fond sombre n'est pas un effet de mode - c'est un choix de lisibilité pour une interface qu'on garde ouverte toute la journée.
L'animation de marque
Stack
- Next.js 15
- React 19
- TypeScript
- NextAuth
- TanStack Query
- Pusher
- Tailwind CSS 4
- Radix UI
- Zod
- WordPress REST
- PHP
- JWT
Ce que ça change, en trois chiffres
0
mot de passe transmis à un intervenant
Méthode de mesure · La session s’ouvre par un lien à usage unique demandé au site cible au moment du clic.
6 types de ressources pilotés depuis un seul écran
types de ressources pilotés depuis un seul écran
Méthode de mesure · Comptes, sites, catégories, outils, attributions et notifications, chacun avec ses écrans.
4 sources réunies dans une même recherche
sources réunies dans une même recherche
Méthode de mesure · Une seule fenêtre interroge les comptes, les sites, les catégories et les outils.