Panel sztabowy

Quand on gère une seule marque, un panneau interne est simple : une équipe, un ensemble de clients, un ensemble de règles. Quand il y a deux marques, et à terme davantage, cela devient délicat. Le plus facile est de dresser un deuxième panneau à côté du premier, mais alors les mêmes comptes, les mêmes portefeuilles et les mêmes règles de commission sont maintenus en double, et chaque correction doit atterrir à deux endroits, sinon les versions divergent.

Le panneau du personnel est notre réponse à cette tension. Un seul tableau de bord réunit les clients de VulCode et d'Aphrodi, gérés depuis une seule vue, mais avec une frontière stricte : une personne affectée à une marque ne voit pas les clients de l'autre. À cela s'ajoute ce que toute équipe de support finit par demander : qui a changé ce drapeau sur le compte, et quand. Cette étude de cas explique comment nous avons concilié un noyau commun avec une séparation qui doit tenir pour de vrai, et non seulement en avoir l'air.

Gérer deux marques depuis deux panneaux séparés a l'air innocent jusqu'à ce qu'on compte tout ce qui se répète entre eux. Le modèle client est le même. Le portefeuille est le même. Le programme d'affiliation et les règles de commission sont les mêmes. Les factures, les drapeaux sur les comptes, la logique des permissions - tout est pareil, juste en deux copies que quelqu'un doit garder synchronisées à la main.

Ce n'est pas seulement du travail en double, c'est une double chance de se tromper. Une correction d'une règle de commission atterrit dans un panneau et pas dans l'autre, parce que quelqu'un a oublié. Un nouveau champ sur un compte client apparaît dans une marque et manque dans l'autre. Plus cela vit longtemps, plus les deux copies s'éloignent, jusqu'à ne plus pouvoir dire laquelle est la bonne.

Nous avons donc décidé que le noyau est unique. Les clients des deux marques vivent dans un seul back-office, sur un seul modèle de données, servis par une seule API. La différence est faite non par du code séparé mais par la portée des permissions posée sur l'ensemble commun.

Le cœur de ce panneau est le contrôle d'accès limité par marque. Le rôle d'un employé n'est pas global. Il est lié à une marque précise, et la portée de ses permissions s'arrête exactement à la frontière de cette marque. Quelqu'un de l'équipe VulCode voit les clients VulCode et eux seuls, même si ces clients sont physiquement dans le même back-office que ceux d'Aphrodi.

Ce qui compte, c'est où cette frontière est vérifiée. Si la portée n'était qu'un filtre d'interface, on pourrait la contourner en ajoutant l'id de quelqu'un d'autre à l'adresse. C'est pourquoi la vérification de la portée se trouve à l'entrée de l'API et rejette la requête avant qu'elle ne touche les données, quoi que le frontend montre ou cache.

Dans un panneau où l'on peut marquer un compte, changer un taux de commission ou déplacer un solde de portefeuille, la question "qui a fait cela" tombe inévitablement. Sans réponse, il ne reste que des suppositions après coup et une recherche de coupable de mémoire, ce qui est à la fois injuste et inutile.

C'est pourquoi chaque action sensible s'enregistre dans un journal d'audit : qui l'a effectuée, ce qu'elle concernait et quand elle s'est produite. Ce n'est pas un journal technique pour les développeurs, mais une trace lisible pour l'équipe de support. Quand une question sur un changement de compte se pose, la réponse est dans le journal, et non dans la tête de quelqu'un.

Le même mécanisme joue un second rôle, plus discret. La conscience que chaque action laisse une trace ordonne le travail d'elle-même. Il ne s'agit pas de suspicion ; dans une équipe qui gère l'argent d'autrui, la transparence est une condition de la confiance, pas un supplément.

Toute cette construction repose sur une seule séparation : ce qui est commun et ce qui est séparé. Le commun, c'est le noyau - l'API, le modèle de données, les comptes et portefeuilles des clients, et le journal d'audit. Le séparé, c'est seulement la portée des permissions et la visibilité des clients qui en découle. Rien de plus n'a besoin de se ramifier.

La conséquence de cette division est pratique et durable. Ajouter une autre marque au panneau du personnel est une configuration de portée, et non un autre panneau à construire et à maintenir. Une nouvelle règle de commission, un nouveau champ de compte, une nouvelle opération - tout cela atterrit une seule fois, dans le noyau commun, et s'applique partout d'un coup, sauf que chacun le voit dans les limites de sa marque.

L'équipe travaille depuis un seul endroit, et non depuis deux onglets de navigateur qu'elle doit garder en tête et surveiller pour qu'ils ne divergent pas. Les clients des deux marques sont là où ils doivent être, chaque employé voit exactement sa part, et la frontière entre les marques tient au niveau de l'API, et non sur la bonne volonté de l'interface.

Quand une question sur un changement de compte se pose, la réponse est dans le journal d'audit, et non dans la mémoire de quelqu'un ou dans des suppositions. Cela transforme les conversations "qui a fait cela" d'un conflit en une simple vérification de fait, ce qui, dans une équipe qui gère l'argent d'autrui, est la différence entre la confiance et une tension constante.

Le plus important, cependant, c'est que l'architecture est prête pour l'avenir. Ajouter une troisième marque ne signifie pas un troisième panneau, juste une portée de plus sur le même noyau. Le développement du back-office ne se multiplie pas par le nombre de marques, parce que ce qui est commun reste commun et ce qui est séparé se limite à ce qui doit vraiment l'être.