CBTicket

Suivre nos demandes, à notre façon

Nous avions besoin d’un outil de suivi de demandes calé sur notre manière de travailler : relié à nos issues GitLab, hébergé en France, sans cookie, et capable de servir aussi bien nos échanges internes que ceux avec nos interlocuteurs. Les SaaS génériques imposent leur modèle ; les trackers de développeurs ne parlent pas aux non-techniciens. Nous voulions le nôtre.

CBTicket est ce produit : une application de ticketing multi-organisations et white-label, conçue, spécifiée et mise en production en une dizaine de jours — de l’idée à la première version utile —, puis approfondie dans la foulée. C’est notre preuve de vitesse, sur un outil que nous utilisons nous-mêmes tous les jours.

Le pari : montrer qu’on peut aller vite sans rien céder sur la rigueur. La suite de cette page le détaille — d’abord ce que l’outil fait, ensuite comment il est construit.

Ce que ça fait, concrètement

• Une organisation en arbre, façon revendeur. Les organisations s’imbriquent : Codebase opère l’outil, héberge ses propres clients, qui hébergent les leurs. Chacun ne voit que son périmètre.
• Du white-label par point de vue. La marque affichée (nom, logo, couleur) s’adapte à l’organisation depuis laquelle on regarde — un même ticket apparaît sous « CB Ticket » pour nous et sous « Néroli Ticket » pour le client concerné, sans dupliquer le produit.
• Trois populations sur la même URL. Super-admin, gestionnaire et demandeur partagent l’application mais pas la même vue : le demandeur suit l’avancement de sa demande sans jamais voir les coulisses (notes internes, assignations).
• Des tickets riches. Conversation, notes internes réservées à l’équipe, pièces jointes, labels, types, priorités, liens entre tickets (doublon, blocage) et mentions.
• Un pont GitLab. Un ticket se relie à une issue GitLab : le suivi côté client et le travail côté dev restent synchronisés, chacun dans son outil.
• Souveraineté et RGPD par défaut. Hébergement en France, sans cookie, données maîtrisées de bout en bout.

Le détail d’un ticket réunit, sur une seule page, la conversation, les pièces jointes, les labels, les liens vers d’autres tickets, le lien vers l’issue GitLab et un journal d’audit — qui a changé quoi, et quand.

Selon l’organisation depuis laquelle on se connecte, l’interface change de marque, et le demandeur dispose d’une vue épurée — l’avancement de sa demande, étape par étape, sans voir les échanges internes de l’équipe.

Les écrans ci-dessus tournent sur des données de démonstration entièrement fictives (organisations et personnes inventées).

Comment c’est construit — et pourquoi c’est rassurant

CBTicket a été construit vite, mais pas à la va-vite. La vitesse tient justement à la rigueur de la méthode, et c’est ce qui la rend crédible :

• Une méthode spec-driven. Chaque évolution est spécifiée, revue et tracée avant d’être codée — 38 changes archivés à ce jour, sur 19 capabilities. Le code suit la décision, jamais l’inverse.
• Des autorisations verrouillées. Le code qui décide qui voit quoi est verrouillé et gardé par des property tests : impossible d’élargir par accident ce qu’une organisation ou un demandeur a le droit de voir.
• Une qualité mesurée, pas promise. ~880 tests sous un seuil de couverture à 80 % : une régression qui ferait passer la barre en dessous casse la livraison.
• La sécurité par conception. Authentification déléguée à Better Auth, audit type OWASP, secrets chiffrés, isolation stricte des données entre organisations.
• Un déploiement data-safe. Les 26 migrations Prisma sont rejouables et réversibles : on livre une nouvelle version sans remettre en cause les données existantes.

Sous le capot

Pour les équipes techniques, le choix assumé est celui de la simplicité — un monolithe clair plutôt qu’une architecture distribuée prématurée :

• Application Next.js (App Router) + TypeScript, UI Tailwind / shadcn.
• Données Prisma sur PostgreSQL ; modèle multi-tenant en arbre, white-label par organisation.
• Identité Better Auth, droits dérivés de la place dans l’arbre d’organisations.
• Infrastructure déploiement Kamal, provisioning Ansible, hébergement Scaleway (France), e-mail transactionnel et stockage objet compatible S3.

Un monolithe n’est pas un manque : c’est le bon niveau de complexité pour ce produit, et un gage de maintenabilité.

En résumé

CBTicket, c’est une idée passée en production en une dizaine de jours, puis approfondie sans jamais sacrifier la rigueur : spec-driven, autorisations verrouillées, ~880 tests sous un seuil de couverture, sécurité renforcée, souveraineté des données. La preuve, sur notre propre outil, que vite et bien ne s’opposent pas — et exactement le type de prise en charge que je peux mettre au service de votre projet.