Beaucoup de dirigeants disent au lancement du projet : faire le site vitrine et le back-office ensemble, c'est plus simple.
Cela semble raisonnable, mais en pratique, trois situations reviennent le plus souvent : le site vitrine est mis en ligne en premier alors que le back-office est encore en cours de modification ; un champ du back-office change et toutes les pages du site vitrine doivent être refaites ; chacun des deux côtés est confié à une personne différente, les API ne correspondent pas, et on finit par s'attendre mutuellement.
Le problème n'est pas de « tout faire ensemble », mais de ne pas avoir planifié l'ordre. Voici un découpage basé sur l'expérience réelle de projets.
Définir d'abord les données du back-office, puis les pages du site vitrine
Le site vitrine est la couche de présentation, le back-office est la couche de données. Inverser l'ordre rend les reprises presque inévitables.
Prenons un cas concret : une entreprise d'équipements industriels veut refondre son site vitrine et créer en parallèle un back-office permettant aux commerciaux de mettre à jour eux-mêmes les paramètres produits, les cas clients et les actualités. Si l'on dessine d'abord la page d'accueil du site vitrine avant de réfléchir à la façon de remplir le back-office, le résultat courant est un back-office aux champs conçus de manière arbitraire — par exemple « caractéristiques produit » réduit à une seule zone de texte riche — alors que le site vitrine veut afficher trois éléments côte à côte ; l'éditeur doit alors mettre en page manuellement, et six mois plus tard le contenu est chaotique.
Une approche plus sûre consiste à lister d'abord le modèle de contenu : quels champs pour un produit, quel produit associer à un cas client, faut-il catégoriser les actualités, faut-il plusieurs tailles d'images. Une fois les champs définis, la structure des pages du site vitrine découle naturellement.
Piège à éviter : ne pas faire correspondre directement les champs du back-office aux champs de la base de données. Les noms de champs visibles par l'éditeur doivent être compréhensibles ; les champs techniques sont stockés séparément, sinon l'équipe opérationnelle abandonne la maintenance après deux saisies.
L'API d'abord, ne pas attendre la fin des deux côtés pour l'intégration
Lorsque le site vitrine et le back-office sont développés en parallèle, la plus grande perte de temps vient de l'intégration.
Il est recommandé de figer la documentation d'API dès la première semaine de développement, même sous forme d'accord écrit : ce que renvoie l'API de liste, comment s'appellent les paramètres de pagination, si les URL d'images sont relatives ou absolues. Le front-end peut faire tourner les pages avec des données fictives, le back-office produit selon le même contrat.
Un détail souvent négligé : le site vitrine et le développement de mini-programmes partagent souvent la même API. Si l'entreprise prévoit ensuite un mini-programme de réservation, la conception des API du back-office doit anticiper le filtrage des champs pour le mobile, et ne pas renvoyer tous les gros champs du PC. Il en va de même pour le développement d'App : ajoutez le numéro de version d'API dès le départ, les modifications ultérieures seront bien plus simples.
Piège à éviter : ne pas mélanger chinois et anglais dans les noms de champs d'API, et ne pas faire un seul endpoint à trois usages. Mieux vaut deux API de plus qu'une API universelle.
Permissions et workflow de publication : à clarifier dès la première version
Le back-office ne compte pas qu'un seul rôle d'administrateur.
Dans les projets réels, les rôles courants sont au minimum : super administrateur, éditeur de contenu, commercial ou responsable régional. Si la première version ne prévoit qu'un seul compte, l'ajout ultérieur de permissions obligera à modifier les tables de données, ce qui coûte bien plus cher qu'une conception initiale.
Le workflow de publication est identique. Le contenu du site vitrine doit-il être validé avant mise en ligne ? Les actualités doivent-elles pouvoir rester en brouillon ? Ce ne sont pas des fonctionnalités « à voir plus tard », mais des éléments qui influencent la structure des tables.
Une approche applicable : ajouter un champ de statut à la table de contenu (brouillon, en attente de validation, publié) et une portée d'action à la table des rôles. La première version peut n'ouvrir que deux rôles, mais la structure doit être prévue.
Piège à éviter : ne pas coder les permissions en dur dans les pages. Masquer un bouton côté front-end ne constitue pas un contrôle d'accès ; la couche API doit vérifier. Dès qu'un site d'entreprise traite des demandes de devis et des informations clients, ce point est particulièrement important.
Découper le calendrier de mise en ligne en deux phases, ne pas tout lier à une seule publication
Faire le site vitrine et le back-office ensemble ne signifie pas les mettre en ligne ensemble.
Un rythme plus sûr : mettre d'abord en ligne le back-office et valider la saisie de contenu ; publier ensuite le site vitrine, rempli avec de vraies données. Ainsi, le site vitrine est complet dès sa première apparition, au lieu d'être complété après la mise en ligne.
Si le temps est serré, on peut aussi publier d'abord une version statique du site vitrine, développer le back-office en parallèle et basculer la source de données la deuxième semaine. À condition que la structure des pages ait été définie selon le modèle de contenu précédent, pour éviter de refaire la mise en page lors du basculement.
Piège à éviter : prévoir du temps pour les tests de sécurité avant la mise en ligne. Un site d'entreprise implique des soumissions de formulaires et une connexion au back-office ; les problèmes courants d'injection, d'élévation de privilèges et de mots de passe faibles doivent être vérifiés. Cette charge de travail est distincte du développement web lui-même ; ne l'oubliez pas dans la planification.
Dans quels cas faire appel à MIC Studio
Si l'équipe dispose de développeurs front-end et back-end stables, il suffit de planifier soi-même selon l'ordre ci-dessus, sans intervention externe.
Mais dans les cas suivants, faire appel à une équipe externe fait gagner du temps : premièrement, la refonte du site vitrine et le back-office démarrent en même temps, avec une seule personne en interne pour le suivi, et il faut quelqu'un pour coordonner besoins et planning ; deuxièmement, un système existant doit être complété par du développement de mini-programme ou d'App, les API doivent être réutilisées, et il faut quelqu'un pour structurer d'abord les données ; troisièmement, avant la mise en ligne, il faut réaliser des tests de sécurité web ou des tests d'intrusion, et l'équipe interne n'a pas l'expérience correspondante.
Lorsque MIC Studio prend en charge ce type de projet, elle commence généralement par une phase de clarification des besoins et d'inventaire des champs, puis passe à la planification du développement web, afin d'éviter les modifications en cours de route. Aucune promesse de classement, aucune publicité exagérée : clarifier les frontières et les délais est plus important.
Trois recommandations concrètes
1. La première semaine du projet, produire d'abord le modèle de contenu et la liste des rôles, puis dessiner les pages. Tant que les champs ne sont pas définis, ne pas se précipiter sur les maquettes.
2. Démarrer en parallèle la documentation d'API et les données fictives du front-end : le temps d'intégration peut être réduit de plus de moitié.
3. Découper la mise en ligne : back-office d'abord, site vitrine ensuite, en laissant entre les deux du temps pour les tests de sécurité et le remplissage du contenu.
Une fois ces trois points réalisés, faire le site vitrine et le back-office ensemble n'est plus un risque, mais un choix économiquement avantageux.