Beaucoup de dirigeants lancent leur projet avec cette phrase : faisons le site vitrine et le back-office ensemble, après tout ce sont tous les deux des sites web.
Cela semble économique et simple, mais en pratique, cela se transforme souvent en deux ensembles de besoins qui s'opposent, des délais qui s'allongent sans cesse et un budget qui ne cesse de grimper.
Le problème n'est pas de savoir si on peut les faire ensemble, mais plutôt si l'on a d'abord bien délimité les frontières entre les deux. Le site vitrine s'adresse aux clients, le back-office est utilisé en interne : leurs objectifs, leur rythme et leurs critères de validation sont totalement différents. Voici, à partir de l'expérience réelle de projets, une décomposition de la réflexion de planification.
1. Commencez par séparer le « faire ensemble » en deux lignes, ne les mélangez pas dans un seul cahier des charges
Le scénario d'échec le plus courant : un cahier des charges de cent points, site vitrine et back-office mélangés, et au milieu du développement on découvre que la logique d'affichage du site dépend de la conception des champs du back-office, alors que le back-office n'est pas encore finalisé.
L'approche la plus solide consiste à séparer en deux cahiers des charges, en partageant un même modèle de données.
- Ligne site vitrine : structure des rubriques, nombre de pages, formats d'affichage du contenu, exigences SEO, adaptation mobile
- Ligne back-office : qui se connecte, quelles actions sont possibles, d'où viennent les données, comment se déroule le processus de validation
- Partie commune : champs de contenu, spécifications d'images, système de catégories, flux d'états
Prenons un cas concret. Un site d'entreprise dans le secteur des équipements industriels doit être refondu, avec en parallèle un back-office permettant de publier des actualités, téléverser des produits et consulter les messages. Si dès le départ on définit clairement le champ « produit » — nom, modèle, tableau de paramètres, image principale, images de détail, catégorie d'appartenance, statut de mise en ligne — alors la page liste des produits du site et la page de gestion des produits du back-office peuvent être développées en parallèle, sans attendre que le back-office soit terminé pour commencer le site.
Mise en garde : ne lancez pas le projet avec des phrases du type « le back-office, on le fait vite fait ». Dès qu'il implique des permissions, de la validation et des journaux, la charge de travail n'est pas inférieure à celle du site vitrine.
2. Le choix technologique doit servir les deux côtés, ne privilégiez pas un seul
Lorsqu'on réalise le site vitrine et le back-office ensemble, le choix de la stack technique influence directement les coûts de maintenance futurs.
Il existe trois combinaisons courantes :
1. Un seul framework pour tout : pas de séparation front/back, site vitrine et back-office dans un même projet. Avantages : rapide, coût faible ; inconvénients : le trafic du site et les opérations du back-office s'influencent mutuellement, extension difficile par la suite.
2. Séparation front/back, API partagées entre site et back-office : le site utilise le rendu côté serveur ou la génération statique pour garantir le SEO, le back-office utilise un framework front-end pour l'interaction. C'est actuellement le choix le plus répandu pour les sites d'entreprise.
3. Site vitrine statique + back-office déployé séparément : le site passe par un CDN, le back-office est placé sur un réseau interne ou avec des restrictions d'accès. Meilleure sécurité, adapté aux activités sensibles aux données.
Si le projet peut s'étendre plus tard au développement de mini-programmes ou d'App, la conception des API doit prévoir des ouvertures dès le départ. Par exemple, une structure de retour unifiée pour les API de contenu permet aux mini-programmes et aux App de réutiliser directement, sans tout réécrire.
Mise en garde : n'utilisez pas un chemin par défaut comme admin pour le back-office, ajoutez une limitation de fréquence sur l'API de connexion. Ce sont les vérifications les plus élémentaires dans un test de sécurité web, mais beaucoup de projets ne les font pas avant la mise en ligne.
3. Les API et le modèle de permissions déterminent le coût des modifications futures
La qualité d'un back-office ne se juge pas à la beauté de l'interface, mais à deux choses : la clarté des API et la flexibilité des permissions.
Côté API, il est conseillé de produire une liste d'API avant le développement, en précisant au minimum :
- Le chemin et la méthode de requête
- Les champs d'entrée et leurs types
- La structure de retour
- La signification des codes d'erreur
- Si une connexion est requise, et quel rôle est nécessaire
Côté permissions, ne commencez pas directement par un RBAC complexe. Pour un projet de site d'entreprise de taille moyenne, trois rôles suffisent généralement : super administrateur, éditeur de contenu, lecteur seul. On étend lorsque l'activité devient réellement complexe.
Voici une leçon vécue. Le site d'un établissement d'enseignement devait présenter des cours, et le back-office devait permettre la mise en ligne et le retrait des cours. Au départ, les permissions n'étaient pas séparées : le service marketing pouvait supprimer directement des cours, et une erreur de manipulation a supprimé un cours en vente, provoquant une erreur de synchronisation sur le site. Le problème n'a été résolu qu'après l'ajout d'une « confirmation en deux étapes pour la suppression + journal des opérations ».
Mise en garde : les opérations de suppression, de modification en masse et d'export doivent obligatoirement avoir un journal et une confirmation en deux étapes. Ce n'est pas une exigence supplémentaire, c'est la base.
4. Rythme de mise en ligne : le site peut sortir d'abord, le back-office livré par lots
Beaucoup pensent qu'il faut tout terminer avant de mettre en ligne, mais ce n'est pas nécessaire.
Un rythme raisonnable serait :
- Phase 1 : pages statiques du site + back-office de base (publication de contenu, téléversement d'images)
- Phase 2 : messages, formulaires, statistiques
- Phase 3 : affinement des permissions, journal des opérations, export de données
Mettre le site en ligne d'abord permet d'être indexé plus tôt par les moteurs de recherche et de faire remonter les retours des équipes métier. Livrer le back-office par lots réduit la pression de développement et le coût des reprises.
S'il s'agit d'une activité de réservation, comme la prise de rendez-vous en magasin ou les cours d'essai, le back-office doit aussi gérer les conflits horaires, les limites de places et les notifications. Ce type de besoin est plus adapté au développement de mini-programmes : le site se charge de la présentation et de l'acquisition, le mini-programme de la conversion et de la fidélisation, et le back-office gère les données de manière unifiée.
Mise en garde : avant la mise en ligne, faites impérativement une série complète de tests, incluant la soumission de formulaires, le téléversement d'images, le changement de permissions et l'affichage mobile. Beaucoup de problèmes ne viennent pas d'un manque de développement, mais d'un manque de tests.
5. Dans quels cas faire appel à MIC Studio
Si vous rencontrez les situations suivantes, constituer une équipe interne ou faire appel à un développeur indépendant n'est peut-être pas rentable :
- Le site vitrine et le back-office doivent être faits ensemble, mais personne en interne ne sait rédiger clairement les besoins
- Vous avez déjà un site d'entreprise, vous voulez le refondre en ajoutant un back-office, et vous craignez des problèmes de migration de données
- Vous avez besoin de développement web + développement de mini-programmes + développement d'App, avec une interconnexion multi-plateformes
- Vous souhaitez faire un test de sécurité web ou un test d'intrusion avant la mise en ligne, pour détecter les failles d'API et de permissions
L'approche de MIC Studio consiste d'abord à vous aider à découper les besoins en ligne site et ligne back-office, à produire une planification compréhensible, puis à discuter du devis et des délais. Pas d'accumulation de fonctionnalités, pas de promesses irréalistes : on clarifie d'abord les frontières.
Trois conseils exécutables pour conclure
1. Écrivez d'abord les champs, puis les pages. Une fois le modèle de contenu défini, le site et le back-office peuvent être développés en parallèle.
2. Validez la liste des API et le tableau des permissions avant le développement. Ces deux documents évitent de nombreux conflits par la suite.
3. Mettez le site en ligne d'abord, livrez le back-office par lots. N'attendez pas que tout soit terminé : plus tôt en ligne, plus tôt indexé, plus tôt utilisé.
Réaliser le back-office et le site vitrine ensemble, ce n'est pas impossible, mais il faut planifier clairement avant de commencer. Bien réfléchir aux frontières est plus utile que d'écrire cent exigences supplémentaires.