Panel klienta VulCode

VulCode est notre propre marque, nous avons donc construit ce panneau pour nous-mêmes, et cela s'est avéré être le client le plus difficile possible. Quand on construit pour soi-même, il n'y a personne derrière qui se cacher : chaque raccourci, chaque chiffre qui ne tombe pas juste vous revient directement. C'est pourquoi ce projet devait dès le départ être le modèle de ce à quoi ressemble un panneau client chez nous, et non un pis-aller à usage interne.

La tâche semblait simple : donner au client un seul endroit où il voit tout ce qui le concerne et règle lui-même les affaires qui nécessitaient auparavant un e-mail. En pratique, cela signifiait relier plusieurs mondes à la fois - l'état des projets, les factures, les tickets de support et un programme d'affiliation qui compte de l'argent réel - en un seul écran cohérent qui fonctionne de la même façon sur un bureau et dans une poche. Cette étude de cas montre où étaient les vrais pièges et comment nous les avons contournés.

Avant le panneau, chaque question sur une étape de projet ou un document se terminait par un e-mail, et la réponse dépendait de qui le lisait et s'il se souvenait du contexte. Cela ne passe pas à l'échelle, même avec une douzaine de clients : la même information vivait dans la boîte de réception d'une seule personne, et le client attendait au lieu de simplement regarder.

Le panneau inverse cela. Le client se connecte et a immédiatement devant lui ses projets avec le statut des travaux, une liste de factures avec ce qui est payé et ce qui est dû, et l'historique de tous les tickets qu'il a jamais ouverts. Rien n'a besoin d'être déterré dans les e-mails, car la source de vérité est une seule vue, et non la mémoire de quelqu'un.

L'effet se ressent des deux côtés. Le client cesse d'attendre un humain pour apprendre des choses que le système connaît déjà. L'équipe cesse de répondre aux mêmes questions pour la centième fois, parce que la réponse est déjà à l'écran avant que quiconque la tape.

Un programme d'affiliation a l'air innocent jusqu'à ce qu'on commence à compter les commissions sur des montants avec des grosze. C'est là que commencent les drames classiques : dix pour cent de 19.99 zł calculés sur un nombre à virgule flottante peuvent donner trois résultats légèrement différents dans la liste des commissions, dans le portefeuille et sur le versement, et alors les soldes ne s'additionnent plus et personne ne fait confiance au panneau.

C'est pourquoi, dans tout le panneau, nous gardons l'argent sous forme d'entiers en grosze et calculons chaque commission sur des entiers. Il n'y a jamais ici de fraction de złoty qui pourrait s'arrondir une fois dans un sens et une fois dans l'autre. Une opération, une règle d'arrondi vers le bas, le même résultat partout où ce montant apparaît.

Un panneau client montre de l'argent et des documents, donc la question "qui a le droit de voir cela" n'est pas cosmétique. Le client ne doit voir que ses propres données, l'équipe seulement ce à quoi elle est autorisée, et la frontière entre eux ne peut pas dépendre du fait que le frontend a caché un bouton ou non.

Nous l'avons construit sur un contrôle d'accès basé sur les rôles et une authentification sécurisée, mais la décision clé est architecturale : la portée de ce qui peut être vu et fait est vérifiée par le backend à l'entrée de l'API, et non par l'interface. Le frontend peut montrer ou cacher ce qu'il veut, mais si une requête concerne les données d'autrui, l'API la rejette avant même qu'elle n'atteigne la base de données.

C'est le même principe que nous appliquons partout : on garde la frontière là où les données extérieures entrent, c'est-à-dire à l'API, et on ne compte pas sur le fait que l'utilisateur n'échangera pas un identifiant dans l'adresse.

Le client n'est pas tout le temps devant un ordinateur. Il vérifie une facture dans le tramway, réagit à une notification de ticket depuis son téléphone. Construire une application mobile séparée pour cela signifierait un deuxième code à maintenir et la certitude que tôt ou tard les deux versions divergent.

À la place, le panneau est une application web qui s'installe sur le téléphone en tant que PWA, avec un manifeste et un service worker. Le même code, le même backend, la même logique de commission. Sur un ordinateur, c'est un bureau complet, sur un téléphone, une icône sur l'écran d'accueil et une fenêtre sans barre de navigateur, se comportant comme une application native.

Le plus facile est de construire un panneau qui a l'air bien sur des chiffres préparés à l'avance. Il a l'air bien jusqu'à ce que quelqu'un clique et qu'il s'avère qu'il n'y a rien en dessous. Nous avons pris le chemin inverse : dès le premier jour, le panneau repose sur un vrai backend, et chaque écran montre ce qui est réellement dans la base de données.

Ce choix coûte plus cher au départ, car il faut une API fonctionnelle avant que quoi que ce soit ne soit dessiné. Mais il paie immédiatement, car il n'y a pas de moment "on branchera les données plus tard" où font habituellement surface toutes les hypothèses qui n'ont pas survécu au contact avec la réalité. Ce que l'on voit dans le panneau est ce que le système sait vraiment.

Le client obtient un seul endroit où il voit son état et gère lui-même les affaires qui nécessitaient auparavant un e-mail à l'équipe. Il entre, vérifie un projet, télécharge une facture, répond dans un ticket, regarde le solde de commission du programme d'affiliation, et s'il se trouve en déplacement, il fait la même chose depuis un téléphone, parce que c'est la même application. Rien de tout cela ne dépend du fait que quelqu'un de l'équipe soit à la boîte de réception.

De notre côté, le gain est tout aussi concret. Le programme d'affiliation fonctionne sans que personne ne recalcule quoi que ce soit à la main, parce qu'il est gardé par du code sur des entiers, et non par un tableur que quelqu'un doit rapprocher. Les soldes correspondent, car il n'y a aucun endroit où une erreur d'arrondi pourrait naître. L'équipe récupère le temps qui partait auparavant dans la réponse aux mêmes questions.

Le plus important, cependant, c'est que ce panneau est devenu notre modèle. Le noyau sur lequel il repose - rôles, portefeuilles, commissions, tickets, i18n, mode application - est assez propre pour avoir été transféré sur d'autres marques sans réécriture. Nous avons commencé par le client le plus difficile, nous-mêmes, et il en est ressorti une architecture que nous n'avons ensuite fait qu'habiller de nouvelles couleurs.