Deux tatoueurs n'ont pas le même métier

La phrase était simple : « j'ai un tatoueur qui n'a pas besoin du kanban, et un autre qui en a besoin ». Puis : « un zingueur qui fait des devis, et un menuisier qui ne veut qu'un calendrier ».

On peut lire ça comme une demande de fonctionnalités. C'est d'abord une correction. Nous rangions les clients par secteur — artisanat, restauration, beauté, services — et le secteur est utile pour beaucoup de choses : le vocabulaire d'un site, les images, la structure des pages. Il ne dit rien de la façon dont quelqu'un tient son affaire. Deux tatoueurs de la même rue, l'un planifie ses projets sur un tableau, l'autre a un carnet et n'en démordra pas. Aucune catégorie ne rattrapera cet écart, parce que l'écart n'est pas entre les métiers : il est entre les personnes.

Ce que ça oblige à construire

Une fois qu'on accepte ça, la conséquence est nette : il faut cocher, compte par compte. Ce que nous avions déjà fait pour notre propre équipe la semaine dernière, et qu'il suffisait d'étendre — sauf que ce qu'il y avait à cocher n'existait pas encore.

Un espace client qui ne montre que ce que nous produisons pour lui n'a pas besoin d'être ajustable : tout le monde veut voir son site. Le rendre ajustable n'a de sens que s'il porte aussi ce que le client, lui, produit — ses clients à lui, ses devis à lui, ses chantiers. C'est là que les besoins divergent, parce que c'est là qu'on parle de son métier et non du nôtre.

La ligne qu'il ne fallait pas franchir

Nos tables de devis et de factures existent déjà. Elles ont exactement les colonnes qu'il faut : un numéro, un destinataire, des lignes, des montants, un statut. La tentation d'y ajouter une colonne « émetteur » et d'en finir était réelle, et elle aurait été une faute.

Ces tables portent notre comptabilité. Y verser le chiffre d'affaires d'un zingueur l'aurait fait entrer dans nos statistiques, nos relances d'impayés, nos exports comptables et nos bilans mensuels. Chaque requête existante — il y en a des dizaines — aurait dû apprendre à distinguer les deux. Une seule oubliée aurait suffi, et rien ne l'aurait signalé, puisque les colonnes sont les mêmes et les nombres plausibles. On aurait découvert le problème en lisant un chiffre d'affaires qui ne veut rien dire, six mois plus tard, sans savoir depuis quand.

Des tables séparées, donc, avec un préfixe qui dit à qui appartient la donnée. Et un test qui relit les sources dans les deux sens : aucune route de l'espace client ne touche nos tables, aucune route d'administration ne touche les leurs.

Ce qu'on n'a pas réécrit, et ce qu'on n'a pas réutilisé

Pour le tableau de chantiers, l'inverse s'est produit. Le modèle de notre kanban interne portait déjà tout ce qu'il fallait, y compris la notion de tableau personnel appartenant à quelqu'un. Réécrire des colonnes, des cartes, des priorités et des échéances n'aurait servi à rien : nous avons réutilisé les tables.

Mais pas les routes. Celles de notre kanban d'équipe ne vérifient aucune appartenance — c'est cohérent chez nous, où l'équipe voit tout, et ce serait une fuite complète côté client. Un copier-coller aurait ouvert le tableau de chacun à tout le monde. Les routes de l'espace client passent donc par deux fonctions qui vérifient, à chaque écriture, que la carte et la colonne appartiennent bien à l'appelant. Deux vérifications et non une : sans la seconde, déplacer une carte aurait suffi à la pousser dans le tableau d'un autre.

Les détails qui font qu'un document est un document

Un devis d'artisan n'est pas un tableau de chiffres. La TVA se ventile par taux, parce qu'un même chantier porte couramment 10 % sur la main d'œuvre et 20 % sur les fournitures. L'arrondi se fait ligne par ligne et jamais sur le total, parce que c'est ainsi que le document imprimé présente les nombres — et qu'un centime d'écart entre l'écran et le PDF, c'est le client qui appelle. Quand la TVA est nulle, la mention de franchise en base s'ajoute d'elle-même : son absence est le reproche le plus courant fait à une facture d'artisan, et personne ne pense à la taper.

Et un document envoyé ne se réécrit plus. Ce n'était pas une contrainte technique, c'était un choix : une facture émise est une pièce comptable, en changer le montant après coup n'est pas une correction. Tant qu'elle est en brouillon, tout est ouvert ; ensuite, seul le statut bouge. Elle ne se supprime pas non plus — elle s'annule, sinon la numérotation aurait un trou, et un trou se lit comme un document disparu.

Deux choses apprises en chemin

Le calcul HT/TVA/TTC — le plus critique du dépôt — vivait dans une route qui l'exportait. Un fichier de route est exécutable, pas importable : le charger déclenchait des fonctions que seul le serveur fournit, et ce calcul-là était donc le seul du dépôt à ne pas pouvoir être testé isolément. Il a déménagé dans son propre module. La route le réexporte, aucun appelant n'a changé, et il a maintenant des tests.

Le reste s'est vu au navigateur, pas au typage : le bouton d'impression du document, posé en position fixe, recouvrait exactement le nom du destinataire. C'est le genre de chose qu'aucun test statique n'attrape et qu'on ne découvre qu'en regardant un vrai devis, avec un vrai client dessus.