Panel klienta Aphrodi

Nous avons construit le panneau client VulCode pour nous-mêmes, et il en est ressorti un noyau que nous prétendions multimarque. Aphrodi était l'occasion de le vérifier pour de vrai. Aphrodi est une marque distincte avec sa propre identité forte, donc son panneau ne pouvait pas ressembler à un VulCode repeint. Il devait donner l'impression de faire partie d'Aphrodi et en même temps reposer sur le même code que le panneau de la marque sœur.

C'est plus difficile qu'il n'y paraît. Dire "multimarque" est facile ; prouver qu'en dessous il n'y a pas simplement un répertoire copié avec des couleurs échangées à la main est plus difficile. Cette étude de cas explique comment nous avons mis notre propre architecture à rude épreuve et ce que signifie le fait qu'elle ait réussi.

La supercherie la plus fréquente dans les projets de ce type est que le multimarque n'existe que sur la diapositive. Dans le code se trouvent deux répertoires presque identiques où quelqu'un a échangé à la main la palette et le logo. Cela ressemble à un noyau commun jusqu'à ce que la première correction arrive. Alors il s'avère qu'il faut la coller deux fois, et à la troisième version la mise en page commence à diverger.

Nous voulions le contraire : que le panneau Aphrodi et le panneau VulCode soient physiquement le même code, et non deux copies vivant côte à côte. La différence entre eux doit être une déclaration, pas un doublon. Si nous améliorons la façon dont les commissions sont comptées ou l'aspect de la vue des factures, les deux marques doivent recevoir cette amélioration dans le même commit, sans rien réécrire.

C'était le vrai test de notre architecture. Si ajouter une deuxième marque avait exigé de ramifier le code, cela aurait voulu dire que le noyau n'était pas multimarque du tout, nous l'avions juste appelé ainsi.

La solution est simple à décrire et exigeante à réaliser : le noyau est unique, et une marque entre comme un ensemble de tokens. Couleurs, polices, rayons, ambiance - tout ce qui distingue Aphrodi de VulCode - sont des données que le noyau lit et auxquelles il réagit. La logique, les écrans et tout le flux sont communs. Seule la couche visuelle change, et non pas en échangeant des fichiers mais en choisissant un ensemble de tokens.

Grâce à cela, les marques ne sont pas deux dépôts ni deux répertoires. Ce sont deux entrées dans une seule map. Le panneau sait pour quelle marque il rend et va chercher les bons tokens, tandis que le reste du code n'a même pas besoin de savoir qu'il y a plus d'une marque.

La valeur de cette approche se voit le mieux dans le travail quotidien. Quand nous améliorons la vue des projets ou la manière dont le panneau affiche la facturation, il n'y a pas de question "avons-nous fait la même chose dans l'autre marque". La correction arrive une fois et attrape les deux, parce que c'est physiquement le même code. Toute une classe de bugs disparaît, où une marque prend de l'avance sur l'autre parce que quelqu'un a oublié de synchroniser les copies.

La séparation est nette et facile à décrire. Sont communs les fonctionnalités, les écrans, la logique et l'API. Sont séparés seulement la palette, la typographie, l'ambiance et les petits détails qui construisent l'identité d'une marque. Cette ligne passe exactement où elle doit : le noyau ne sait rien des couleurs, et la couche de marque ne sait rien de la façon dont les commissions sont comptées.

Un client Aphrodi obtient un outil qui ressemble et donne l'impression d'être Aphrodi, et non VulCode dans d'autres couleurs. Il dispose de l'ensemble complet des fonctionnalités d'un panneau client, aussi soigné que dans la marque sœur, parce qu'en dessous c'est exactement le même noyau éprouvé. Rien n'a été simplifié juste parce que c'est la deuxième marque.

De notre côté, le gain est structurel. Nous ne maintenons pas deux panneaux séparés, juste un noyau avec une couche de marque par-dessus. L'architecture a réussi le test dont il était question dans le projet : le multimarque s'est révélé réel, non déclaré. La prochaine marque n'est pas un autre projet de zéro, juste une entrée dans la map de tokens et une poignée d'assets, prête à s'asseoir sur la même fondation déjà soignée.