Ce qu'un panneau admin doit offrir pour que votre produit n'ait plus besoin de vous

Un bon panneau d'administration se mesure aux tickets de support qu'il évite. Pas au nombre d'écrans, pas à la beauté de son tableau de bord, mais à la rareté des moments où la personne qui fait tourner le produit doit demander l'aide d'un développeur. Si publier du contenu, rembourser un client ou modifier une règle métier exige d'ouvrir un ticket, le panneau a échoué, aussi soigné que soit le reste du produit.

Le panneau est le produit pour la personne qui l'opère

Quand on achète ou commande un logiciel, toute l'obsession va à l'application destinée à l'utilisateur final : l'onboarding, les animations, les états vides. Le panneau d'administration reçoit le budget et l'attention qui restent, c'est-à-dire presque rien. Cette priorité est inversée pour une raison simple : l'utilisateur final ouvre l'application quelques minutes à la fois, mais l'opérateur vit dans le panneau tous les jours.

L'opérateur est la personne qui approuve les fiches, répond aux réclamations, corrige une coquille dans une description et sort les chiffres du rapport mensuel. Pour cette personne, le panneau n'est pas un détail d'arrière-boutique. C'est le produit. S'il est lent, confus ou incomplet, toute l'opération ralentit avec lui, et les manques finissent comblés par la ressource la plus chère qui soit : le temps d'un développeur.

Quelles opérations de routine doivent être en libre-service

La routine, c'est tout ce qui arrive chaque semaine ou plus souvent. Tout ce qui figure dans cette liste devrait être faisable par un opérateur non technique, seul, sans toucher au code ni solliciter personne :

• Publier et dépublier du contenu : fiches, événements, offres, pages, annonces
• Gérer les utilisateurs et les permissions : inviter un collègue, changer un rôle, désactiver un compte
• Émettre des remboursements ou corriger des commandes quand quelque chose se passe mal avec un client
• Configurer les politiques : frais, limites, horaires, fenêtres d'annulation, règles de notification
• Exporter des données et sortir des rapports sans demander à personne d'interroger la base
• Voir exactement ce que voit l'utilisateur final, pour que le support parte du même écran

Le dernier point est le plus négligé. Quand un client dit que quelque chose semble anormal, l'opérateur devrait pouvoir voir la vue de ce client en quelques secondes. Sans cela, chaque conversation de support devient une course de relais entre l'opérateur, le client et, au bout du compte, un développeur avec accès à la base de données.

La règle métier comme configuration, pas comme code

Les règles d'une entreprise changent plus souvent que son logiciel ne devrait changer. Les prix bougent, les politiques se durcissent ou s'assouplissent, les saisons passent. Si chaque changement de règle est un changement de code, l'opérateur finit par négocier avec le backlog d'un développeur juste pour piloter sa propre activité.

L'un des systèmes que Cazullo construit et opère est un système de gestion de studios appelé Mahna, utilisé par des studios de yoga et de bien-être. Chaque studio a ses propres règles d'absences et de cours de rattrapage : combien d'absences un élève peut rattraper, dans quelle fenêtre et à quelles conditions selon son abonnement. Ces règles vivent dans la configuration du studio, pas dans le code. Quand un élève manque un cours, le système applique automatiquement la politique de ce studio : il accorde ou refuse le crédit de rattrapage, suit la fenêtre et montre la même réponse à tout le monde.

L'effet se ressent à l'accueil. Avant, chaque cas limite tournait à la discussion entre la réceptionniste et l'élève, et chaque ajustement de politique devenait une demande de modification adressée à un développeur. Avec la règle comme configuration, la discussion s'arrête parce que le système fait office d'arbitre, et l'ajustement prend une minute dans le panneau au lieu d'une semaine dans un backlog.

Flux de modération et de curation

Tout produit avec du contenu généré par les utilisateurs ou la communauté a besoin de modération, et tout produit qui veut paraître vivant a besoin de curation : choisir ce qui est mis en avant, ordonné et valorisé. Les deux sont un travail quotidien, et les deux doivent appartenir à l'opérateur.

La plateforme de commerce local en marque blanche de Cazullo génère pour chaque marque une application, un site et un panneau d'administration à ses couleurs. Chaque marque est gérée par une petite équipe, souvent deux ou trois personnes sans aucun ingénieur parmi elles. Leur panneau leur permet d'approuver ou de rejeter les nouvelles fiches de commerces, de masquer le contenu qui enfreint les règles, de mettre en avant les commerces et événements de leur choix et de publier des annonces. Rien de tout cela ne touche au code, et c'est la seule façon pour plusieurs marques d'opérer sur une même plateforme sans qu'une file de demandes d'ingénierie ne se forme derrière chacune.

Les signes que votre panneau échoue

L'échec s'annonce rarement. Il se manifeste par une friction que tout le monde finit par accepter comme normale. Surveillez ces signes :

• Des tickets récurrents aux développeurs pour des changements de routine : mettre à jour un prix, corriger un texte, débloquer un utilisateur à la main
• Des opérateurs qui tiennent des tableurs parallèles parce que le panneau ne répond pas aux questions qu'ils se posent vraiment
• Un flux constant de messages du type 'tu peux vite changer X' qui atterrissent dans la messagerie d'un développeur

Chacun de ces points est une tâche que le panneau devait couvrir et ne couvre pas. Pris isolément, ils paraissent petits. Additionnés, ils signifient que le produit ne tourne pas sans ses bâtisseurs, ce qui est exactement la dépendance qu'un panneau d'administration existe pour supprimer.

Checklist pour cadrer un panneau

Si vous commandez ou construisez un produit, mettez le panneau dans la première conversation, pas dans la dernière. Ces questions révèlent l'essentiel du périmètre :

• Listez chaque action que l'opérateur fera chaque semaine. Chacune mérite un écran ou un bouton, pas un ticket
• Décidez quelles règles métier changeront avec le temps et faites de chacune un réglage plutôt que du code
• Définissez les rôles et permissions dès le premier jour : qui publie, qui rembourse, qui configure
• Incluez la modération : tout contenu créé par un tiers a besoin d'un chemin pour approuver, masquer ou supprimer
• Prévoyez les exports et rapports pour les questions mensuelles de l'opérateur, pas seulement un tableau de bord
• Donnez à l'opérateur un moyen de voir ce que voit n'importe quel utilisateur final, pour le support et pour la confiance
• Consignez qui a fait quoi et quand, pour que les erreurs puissent être tracées et annulées sans enquête
• Prévoyez un vrai temps de design et de test pour le panneau, autant que pour l'application de l'utilisateur final

La recommandation est simple : cadrez le panneau d'administration comme la moitié du produit, parce que pour la personne qui l'opère, c'est exactement ce qu'il est. Un produit dont les opérations de routine sont en libre-service peut grandir sans ses bâtisseurs dans la pièce. Un produit qui a besoin d'un développeur pour chaque petit changement a un problème de masse salariale déguisé en logiciel.