Beaucoup d'entreprises, lorsqu'elles réalisent leur site vitrine, ajoutent souvent : « Faisons aussi le back-office en même temps. » Cela semble être une formalité, mais en pratique, cela se transforme souvent en deux ensembles de besoins qui s'affrontent.
Le site vitrine doit être beau, rapide et indexable par les moteurs de recherche ; le back-office doit permettre de modifier le contenu, de consulter les données et de gérer les permissions. Les deux partagent un même modèle de données, mais servent des utilisateurs totalement différents. Si la planification est mal faite, le résultat le plus courant est : le site vitrine est mis en ligne en premier, le back-office modifie un champ et tout le front-end s'effondre ; ou bien le back-office est terminé, mais le site vitrine découvre que la structure du contenu ne correspond pas du tout.
Cet article suit l'ordre réel d'un projet pour clarifier la planification du site vitrine et du back-office dans le développement web.
Distinguer d'abord deux axes : logique d'affichage et logique d'édition
Le site vitrine relève de la logique d'affichage, le back-office de la logique d'édition. Ces deux axes doivent être conçus séparément, mais partager un même modèle de données.
La méthode concrète consiste à définir d'abord le modèle de contenu, puis les pages. Par exemple, les rubriques courantes d'un site d'entreprise : actualités, produits, réalisations, recrutement. Quels champs contient chaque rubrique, lesquels sont obligatoires, quelle est la taille des images, le multilingue est-il pris en charge : tout cela doit être défini avant de dessiner les pages.
Point à éviter : ne pas faire correspondre directement le back-office aux modules de la page. Dans de nombreux projets, le back-office est conçu comme « texte du premier écran de la page d'accueil », « image du deuxième écran de la page d'accueil », et lorsque le site vitrine est refondu, tout le back-office devient obsolète. La bonne approche est que le back-office gère le contenu, la page gère la présentation, et le lien entre les deux se fait par mappage de champs.
Un autre piège concerne les permissions. Le back-office doit au minimum avoir trois rôles : administrateur, éditeur et lecture seule. Cela est souvent négligé dans les projets de site web d'entreprise, et l'on découvre après la mise en ligne qu'un stagiaire peut supprimer des données.
Sur le planning, le back-office doit achever la couche de données avant le site vitrine
L'ordre le plus sûr est : modèle de données → API du back-office → interface du back-office → pages du site vitrine.
Les pages du site vitrine dépendent de données réelles. Si le back-office n'est pas encore opérationnel, le front-end ne peut travailler qu'avec des données fictives, et les problèmes exploseront lors de l'intégration. Il faut d'abord que le back-office puisse saisir, modifier et renvoyer une structure correcte, puis le site vitrine se connecte ; les reprises seront bien moindres.
Prenons un cas concret : une entreprise de location d'équipements dont le site vitrine doit afficher une liste d'équipements et une réservation en ligne, tandis que le back-office doit gérer les informations des équipements, les enregistrements de réservation et les transitions d'état. Si l'on commence par le site vitrine, les champs du formulaire de réservation et la structure des enregistrements du back-office risquent fort de ne pas correspondre : par exemple, le site vitrine collecte « durée de location souhaitée », mais le back-office ne stocke que « date de début ». Ce type de problème n'est découvert qu'à l'intégration, et sa correction nécessite de modifier la base de données.
Il faut donc réserver au back-office au moins un tiers du temps en amont, et ne pas le considérer comme un accessoire du site vitrine.
Convenir d'abord des interfaces, ne pas attendre la fin des maquettes
La relation entre le site vitrine et le back-office est une relation d'interface. Les noms de champs, les types, le mode de pagination et les codes d'erreur des interfaces doivent idéalement être consignés dans un document simple avant le développement.
Pas besoin d'être très formel, un tableau d'une page suffit : chemin de l'interface, paramètres d'entrée, exemple de retour, cas d'exception. Cela permet d'économiser beaucoup de communication orale.
Point à éviter : le téléversement d'images. Le site vitrine et le back-office doivent tous deux gérer les images, mais avec des exigences différentes. Le site vitrine exige compression, CDN et chargement différé ; le back-office exige l'image originale, le recadrage et le tri. La logique de téléversement doit idéalement être unifiée dans un seul service, et non écrite séparément des deux côtés.
Il en va de même pour la recherche et le filtrage. Les conditions de filtrage du back-office sont souvent plus complexes que celles du site vitrine. Si l'interface est conçue uniquement pour le site vitrine, le back-office devra ajouter un autre système de requête. Concevoir dès le départ les paramètres de filtrage de manière combinable simplifie la suite.
La sécurité et l'accès administrateur doivent être traités séparément
Le back-office est la surface d'attaque la plus importante. Une étape souvent omise dans le développement web est le test de sécurité du back-office.
Au minimum, il faut : ajouter un captcha et une limitation des échecs de connexion au back-office ; imposer une complexité minimale du mot de passe administrateur ; effectuer une vérification des permissions sur les interfaces, sans se contenter de masquer les menus côté front-end ; conserver une trace des journaux d'opérations.
S'il s'agit d'un projet de développement de mini-programme ou de développement d'App, le back-office doit souvent se connecter à plusieurs clients, et le modèle de permissions devient plus complexe. Il est alors conseillé de scinder le back-office en deux blocs : « gestion de contenu » et « gestion métier », le premier pour les opérations, le second pour les équipes métier, afin de réduire les erreurs de manipulation.
Point à éviter : ne pas utiliser le même système de comptes que le site vitrine pour gérer le back-office. Les utilisateurs front-end et les administrateurs doivent avoir deux tables et deux logiques de connexion distinctes.
Rédiger les critères de recette à l'avance, ne pas attendre la veille de la mise en ligne
La recette du site vitrine porte sur la vitesse de chargement, l'adaptation mobile et les éléments SEO de base (titre, description, données structurées). La recette du back-office porte sur trois points : peut-on saisir complètement, peut-on afficher correctement sur le site vitrine, les permissions sont-elles correctes.
Il est conseillé d'établir une liste de recette, chaque ligne correspondant à une action de vérification concrète. Par exemple : « ajouter une actualité, elle apparaît sur la page de liste du site vitrine en moins d'une minute », « le rôle éditeur ne peut pas supprimer de données », « après téléversement, l'image affichée sur le site vitrine ne dépasse pas 300 Ko ».
Aligner la liste avec les développeurs dès le début du projet est bien plus efficace que de formuler des exigences à la dernière minute avant la mise en ligne.
Dans quels cas faire appel à MIC Studio
Si l'équipe n'a pas de développeur back-end dédié, ou si le site vitrine et le back-office doivent être livrés à la même échéance, externaliser une partie est raisonnable. Lorsque MIC Studio réalise le développement intégré d'un site web d'entreprise et de son back-office, nous commençons généralement par aider le client à clarifier le modèle de contenu et les conventions d'interface, avant de passer au développement.
Les cas adaptés à notre intervention : le site vitrine doit être refondu et le back-office restructuré en même temps ; les sites vitrines avec des flux métier tels que la réservation ou l'inscription ; les projets multi-clients où le back-office doit se connecter à un mini-programme ou une App. S'il ne s'agit que de modifier quelques lignes de texte, il n'est pas nécessaire de suivre le processus complet d'un projet.
Trois recommandations concrètes
Premièrement, avant de commencer, rédiger une page de modèle de contenu définissant les rubriques, les champs et les champs obligatoires, et faire suivre ce document au site vitrine comme au back-office.
Deuxièmement, sur le planning, faire fonctionner d'abord la couche de données du back-office, puis connecter le site vitrine aux interfaces réelles, afin de réduire les reprises lors de l'intégration.
Troisièmement, avant la mise en ligne, effectuer un contrôle de sécurité et un test des permissions du back-office, sans attendre qu'un incident survienne pour corriger.