Beaucoup de dirigeants disent au moment de lancer le projet : faire le site vitrine et le back-office ensemble, c'est plus simple.
Cela semble raisonnable, mais c'est en réalité la combinaison la plus risquée. Le site vitrine s'adresse aux clients : il vise la vitesse d'ouverture, l'expression visuelle et le parcours de conversion. Le back-office s'adresse aux collaborateurs internes : il vise l'exactitude des données, l'efficacité des opérations et la clarté des permissions. Ces deux ensembles n'ont pas les mêmes objectifs ; les forcer dans un seul projet aboutit le plus souvent à un site vitrine en retard et un back-office à moitié terminé.
Voici comment décomposer le sujet, en suivant l'ordre réel d'un projet.
Distinguer d'abord deux axes : l'axe vitrine et l'axe métier
La première étape de la planification n'est pas de dessiner des pages, mais de délimiter les périmètres.
Le site vitrine relève de l'axe vitrine, dont le cœur est la présentation de contenu et l'acquisition de prospects. Le back-office relève de l'axe métier, dont le cœur est la saisie, la validation et les statistiques de données. Ces deux axes peuvent partager un nom de domaine et un système de comptes, mais la structure du code, le rythme d'itération et les critères de validation doivent être séparés.
L'erreur courante consiste à considérer le back-office comme une fonctionnalité annexe du site vitrine : on fait d'abord le site, puis on « ajoute quelques pages » au back-office. Résultat : le back-office n'a pas de conception de modèle de données indépendante, les champs sont ajoutés au coup par coup, et trois mois plus tard personne n'ose plus y toucher.
L'approche plus sûre consiste à définir d'abord la structure de données du back-office, puis à laisser le site vitrine consommer ces données. Par exemple, les pages produits, actualités et références du site vitrine sont toutes alimentées depuis le back-office ; le front se charge uniquement de l'affichage. Ainsi, lors d'une refonte du site vitrine, le back-office n'est pas touché, et lorsqu'on ajoute des champs au back-office, le site vitrine suit automatiquement.
Définir le modèle de données avant de dessiner les pages
C'est l'étape la plus souvent sautée et la plus coûteuse de tout le développement web.
Prenons un cas concret. Une entreprise de vente d'équipements veut créer un site vitrine et un système de gestion back-office. Le back-office doit gérer les catégories de produits, les paramètres produits, les informations sur les distributeurs et les demandes de devis. Si l'on commence par dessiner des maquettes page par page, on aboutit facilement à une conception au niveau des pages du type « page liste produits » et « page détail produit », pour découvrir ensuite que les paramètres varient selon les catégories, ce qui impose de tout refaire.
Le bon ordre est le suivant : lister d'abord les entités. Produit, catégorie, paramètre, distributeur, demande de devis : quels champs possède chaque entité, quelles sont leurs relations. Dessinez-en un schéma de structure de tables, puis discutez des pages.
Un modèle de données erroné entraîne la reprise de toutes les pages en aval. Passer deux ou trois jours de plus à cette étape permet d'économiser deux semaines de discussions stériles par la suite.
Permissions et système de comptes : prévoir les extensions dès le départ
Dans un back-office, c'est sur les permissions que les besoins surgissent le plus souvent après coup.
Au départ, il n'y a peut-être que deux rôles : administrateur et employé. Six mois après la mise en ligne apparaissent des besoins du type « le responsable régional ne voit que les données de sa région » ou « la finance ne voit que les montants des commandes sans pouvoir changer leur statut ». Si le système de comptes est figé dès le départ sur deux niveaux de rôles, chaque ajout de rôle imposera de modifier le code.
Il est recommandé, dès la phase de développement web, d'adopter une structure rôle + points de permission, les points de permission étant divisés par module : gestion des produits, consultation des commandes, export de données, par exemple. Les rôles peuvent combiner librement les points de permission. Ainsi, ajouter un rôle ne demande qu'une configuration, sans nouvelle version.
Côté site vitrine, il faut aussi réfléchir en amont : faut-il une connexion membre, faut-il relier les comptes au back-office ? Si le site vitrine propose des fonctions de rendez-vous ou d'inscription, les données utilisateurs et les données clients du back-office forment-elles un seul ou deux ensembles ? Cette décision influencera la réutilisation possible lors des phases de développement de mini-programmes et d'applications.
Ne pas tout mener en parallèle jusqu'au bout : livrer en décalé
Beaucoup de projets échouent non pas parce qu'ils sont irréalisables, mais parce que le rythme de validation est désordonné.
Développer et livrer le site vitrine et le back-office en même temps signifie devoir valider au même moment deux ensembles totalement différents : les ressources de test sont insuffisantes, les problèmes s'accumulent et personne ne sait plus quel maillon est en cause.
Une planification plus réaliste consiste à livrer d'abord une version utilisable du back-office, puis à enchaîner avec le site vitrine. Le back-office valide d'abord la gestion de contenu et les processus métier essentiels ; le site vitrine se connecte directement aux données réelles pour construire ses pages. Ainsi, lors de la validation du site vitrine, on voit de vraies données et non des données fictives, ce qui fait apparaître les problèmes plus tôt.
Si le temps est serré, on peut inverser : mettre en ligne d'abord une version statique du site vitrine pour assurer la présence externe, et livrer le back-office en deux phases. Mais attention : après la mise en ligne de la version statique, il faut impérativement préciser quand le back-office sera connecté, sinon on risque de maintenir deux jeux de contenu à long terme.
Sécurité et tests : ne pas les laisser pour la fin
Le back-office contient des données internes ; les tests de sécurité ne peuvent pas attendre la semaine précédant la mise en ligne.
Les points de base incluent : limitation du nombre d'échecs de connexion, tests d'accès non autorisé, validation du type de fichiers téléversés, validation des paramètres d'API. Ces mesures coûtent très peu en phase de développement ; les ajouter après la mise en ligne impose de modifier l'architecture. Si le back-office expose des API externes, il faut aussi mener une campagne de tests inversés pour vérifier si les API peuvent être contournées et si les paramètres peuvent être falsifiés.
Côté site vitrine, l'accent doit être mis sur la soumission de formulaires et le téléversement de fichiers : beaucoup de sites d'entreprise reçoivent des demandes de devis indésirables parce que les formulaires n'ont pas de validation de base.
Dans quels cas faire appel à MIC Studio
Si l'équipe ne dispose pas de développeurs back-end et front-end dédiés, ou en dispose mais sans capacité disponible, confier ensemble le site vitrine et le back-office à une équipe externe est raisonnable.
Les cas adaptés sont globalement les suivants : les besoins sont déjà relativement clairs, l'entreprise sait quelles données elle doit gérer et ce que le site vitrine doit présenter ; elle souhaite que le back-office et le site vitrine partagent le même jeu de données et ne veut pas maintenir deux contenus ; elle prévoit ensuite de développer des mini-programmes ou une application et souhaite réutiliser les API sous-jacentes.
Les cas moins adaptés sont ceux où les besoins changent encore constamment et où l'on n'a même pas clarifié quels champs gérer. À ce stade, un travail de cadrage des besoins en amont est plus rentable qu'un développement direct.
Dans ce type de projet, MIC Studio commence par produire la structure de données et la conception des permissions, puis, après validation, passe au développement des pages et des API ; le site d'entreprise et le back-office avancent en parallèle mais sont validés séparément.
Trois recommandations concrètes
Premièrement, rédiger une page de liste de données au lancement du projet. Listez toutes les entités et tous les champs à gérer dans le back-office, sans dessin, en texte clair. Cette page permet d'éviter la moitié des changements de besoins par la suite.
Deuxièmement, valider séparément le site vitrine et le back-office. Le back-office valide d'abord les processus métier, puis le site vitrine se connecte aux données réelles. N'attendez pas que les deux soient terminés pour tout tester ensemble.
Troisièmement, traiter permissions et sécurité dès la phase de développement. La structure rôle/points de permission, la validation des API et la limitation des connexions ne sont pas des finitions avant mise en ligne, mais font partie de l'architecture.
Faire le site vitrine et le back-office ensemble ne pose pas de problème ; la question est de savoir si on les planifie comme deux objets distincts.