Votre équipe gère ses commandes dans un tableur, valide des demandes par e-mail et ouvre un ticket chaque fois qu'il faut corriger une fiche. Quelqu'un finit par dire qu'il faudrait un back-office sur mesure. C'est souvent vrai. Mais le mot recouvre aussi bien trois réglages dans l'outil que vous avez déjà qu'un logiciel à part entière, à maintenir pendant des années.
Je conçois et je construis des sites et des outils, seul, du cadrage à la mise en ligne. Le back-office de ce site, je l'ai configuré moi-même, et je vous montre plus bas ce qu'il contient. Avant cela, voici la question que je pose avant de parler d'outil, les trois chemins possibles, et la checklist que je remplis avant de lancer le chantier.
01Ce qu'un back-office doit permettre, avant de parler d'outil
La plupart des demandes arrivent sous forme de tables : il nous faut un écran pour les clients, un pour les commandes, un pour les produits. Je commence ailleurs. Je demande quelles décisions l'équipe prend chaque jour, et ce qu'il lui faut sous les yeux pour les prendre. « Valider une commande de plus de tant », « relancer un dossier incomplet », « passer un article de à relire à relu ». Chaque décision devient un écran ou une action. Les tables suivent.
Le Nielsen Norman Group fait une remarque qui change la façon de juger un outil interne. Dans son cadre CASTLE pour les logiciels de travail, il rappelle que l'utilisateur n'a pas choisi l'outil : mesurer l'adoption ou la rétention ne dit donc presque rien. Le cadre regarde plutôt la charge mentale, l'efficacité des tâches, l'apprentissage et les erreurs. Son exemple de charge mentale me parle : devoir se souvenir de la fiche qu'on vérifiait en faisant des allers-retours entre une longue liste et le détail.
C'est le même réflexe que chez Moonworkers, mon entreprise : le produit a été conçu à partir de ses utilisateurs, avec des personas et des wireframes, avant d'écrire du code. Un outil interne a des utilisateurs aussi. Ils sont simplement assis à côté de vous, ce qui rend l'oubli plus facile.
02Configurer, assembler ou développer : trois chemins vers le sur-mesure
Je range les options en trois familles, de la moins coûteuse à maintenir à la plus coûteuse.
Configurer l'outil que vous avez déjà
Un CMS, un ERP ou un CRM ont presque tous une interface d'administration réglable : listes filtrées, champs masqués, rôles, vues par statut. C'est souvent suffisant, et c'est le chemin que je propose en premier. Sanity, par exemple, affiche par défaut une longue liste par type de document. Sa documentation sur le Structure Builder montre comment construire des listes adaptées au travail éditorial, filtrées par une requête.
Assembler un outil interne
Quand les données vivent à plusieurs endroits, on peut assembler une interface au-dessus, avec une base comme Airtable ou un constructeur d'outils internes. J'ai décrit comment je monterais une base Airtable pour suivre une production de contenu : des tables reliées, des vues par statut, des automatisations simples.
Un talk publié par Retool, un éditeur d'outils internes (donc à lire comme tel), illustre bien ce cas. Dans cette conférence enregistrée, une équipe d'ingénieurs d'un prestataire de paiement raconte qu'elle recevait des tickets pour consulter des soldes, parfois traités le lendemain. Un petit outil où l'on colle un identifiant a supprimé ce goulot. Ce que je retiens surtout, c'est leur raison de ne pas tout coder : il aurait fallu construire eux-mêmes l'authentification, la restriction d'accès et les journaux d'audit.
Développer
Le développement se justifie quand le métier a des règles que personne ne vend : un calcul, un circuit de validation particulier, un écran qui doit tenir dans le geste d'un opérateur. C'est aussi le chemin le plus long à maintenir. Le code que vous écrivez aujourd'hui, quelqu'un devra le mettre à jour dans deux ans.
03Le back-office de ce site tient en quelques lignes
Ce site tourne sur Next.js et Sanity, avec le Studio intégré à l'adresse /studio. J'ai raconté ailleurs pourquoi j'ai choisi Sanity comme CMS headless. Le back-office, lui, est presque entièrement de la configuration.
Ma machine de contenu vérifie chaque article puis le publie directement par l'API, avec un statut « à relire ». Je ne crée donc presque jamais de contenu dans le Studio. Je m'en sers pour une seule décision : ai-je relu cet article en ligne, oui ou non ? J'ai automatisé la publication avant de produire plus parce que le goulot était la mise en ligne. Restait à rendre la relecture facile.
Concrètement, le Studio contient trois réglages :
- une liste « Articles à relire » en tête du menu, filtrée par une requête d'une ligne sur le statut éditorial ;
- un champ de statut à deux valeurs, « À relire » et « Relu », affiché en boutons radio ;
- le verdict du gate, sa justification et la date d'envoi, en lecture seule.
Le dernier point compte plus qu'il n'en a l'air. La documentation de Sanity sur les champs conditionnels explique que la propriété `readOnly` fige un champ, de façon fixe ou selon une condition. Je ne veux pas pouvoir modifier par erreur la trace de ce que la machine a vérifié. Je peux la lire, je ne peux pas la réécrire.
Il y a aussi une limite que j'ai apprise en mission : un site peut sembler normal à l'équipe connectée et être cassé pour les visiteurs, à cause du cache. Le back-office montre ce qui est enregistré, pas ce que voit le public. Je relis donc chaque article sur la page publique, jamais dans le formulaire.
04Les droits et le journal, la partie qu'on remet à plus tard
Dans beaucoup de cahiers des charges, les écrans sont décrits en détail et les droits tiennent en une ligne : « un administrateur et des utilisateurs ». C'est là que les problèmes arrivent, six mois après la mise en ligne.
La CNIL donne une base simple dans sa fiche Gérer les habilitations. Des profils qui séparent les tâches, une validation de chaque demande d'accès par un responsable, des droits retirés au changement de poste ou en fin de contrat, et une revue au moins annuelle avec les métiers. Elle déconseille les comptes partagés non tracés et les droits d'administrateur donnés « au cas où ».
Sa fiche Tracer les opérations précise ce qu'un journal doit garder : qui a créé, consulté, modifié ou supprimé quelle donnée, avec la date, l'heure et la nature de l'opération. Elle recommande une conservation sur une période glissante de six mois à un an, et rappelle que ces traces ne servent pas à compter les heures de travail.
Si vous développez, la documentation de Next.js sur l'authentification recommande une bibliothèque éprouvée plutôt qu'une solution maison, et des contrôles d'autorisation placés près des données plutôt que dans la mise en page. C'est exactement le travail que l'équipe du talk ne voulait pas refaire.
05La checklist que je remplis avant de lancer le chantier
Elle se remplit avec l'équipe, avant de choisir le chemin, pas après.
Les décisions et les gens
- Lister les décisions prises chaque jour ou chaque semaine, avec la personne qui les prend.
- Pour chacune, noter ce qu'il faut voir pour décider, et ce qui se passe après (un e-mail, une mise à jour, une facture).
- Repérer les décisions qui passent aujourd'hui par un ticket, un tableur ou un message à un développeur. Ce sont vos priorités.
Les droits et les traces
- Écrire les profils (qui voit, qui modifie, qui valide, qui supprime) avant les écrans.
- Décider ce qui doit être journalisé, combien de temps, et qui peut lire le journal.
- Prévoir les départs et les remplacements : qui retire les accès, et quand.
Les actions et les erreurs
- Lister les actions en masse utiles (valider vingt fiches d'un coup, exporter une sélection).
- Décider ce qui peut être annulé et ce qui ne peut pas l'être, et protéger ce second groupe par une confirmation.
- Figer en lecture seule ce qui sert de preuve : un montant validé, un statut de contrôle, une date d'envoi.
Le test
- Faire une maquette cliquable des deux ou trois écrans principaux et la tester avec les personnes qui s'en serviront. J'explique pourquoi je passe par un prototype cliquable avant de développer : on y découvre les allers-retours inutiles avant qu'ils coûtent du code.
Si la checklist tient dans les réglages de votre outil actuel, vous n'avez pas besoin de développer. C'est une issue tout à fait possible, et c'est une bonne nouvelle.
06Quand je ne ferais pas de back-office sur mesure
Je ne le recommande pas quand le besoin est encore flou. Si l'équipe change de façon de travailler tous les mois, un outil développé figera la version du mois où vous l'avez commandé. Un tableur bien tenu, ou une base assemblée, se modifie en une après-midi.
Je ne le recommande pas non plus pour contourner un logiciel de gestion qu'on n'a pas fini de paramétrer. Un écran de plus au-dessus d'un ERP mal réglé ajoute une couche à maintenir sans régler la cause. Et je ne fais pas d'applications mobiles natives : si votre outil interne doit vivre sur le téléphone des équipes de terrain, il faudra un autre interlocuteur pour cette partie.
Enfin, le sur-mesure coûte après la livraison. Chaque mise à jour du framework, chaque nouveau profil, chaque export demandé par la comptabilité passe par quelqu'un qui connaît le code. Il faut le savoir avant de signer, pas après.
07Par où commencer cette semaine
Prenez une heure avec les deux ou trois personnes qui gèrent les données au quotidien. Demandez-leur les cinq décisions qu'elles prennent le plus souvent, et où elles perdent du temps pour chacune. Notez qui a accès à quoi aujourd'hui, y compris les comptes partagés dont personne ne parle. Avec ces deux listes, vous saurez si un réglage suffit, si un outil assemblé fera l'affaire, ou si le développement se justifie.
Si vous voulez un regard extérieur sur ce choix, je fais ce type de cadrage en quelques jours, et vous pouvez voir ce que je construis et comment je travaille. On peut en parler.