TicketTool free

Contexte

Projet personnel mené en 2026 : un bot Discord de gestion de tickets (panels, claim, transcripts, automatisations) et son dashboard web d’administration.

J’utilisais l’offre payante d’un bot de tickets sur mes serveurs Discord. Je ne voulais plus payer son abonnement. Une faille de ce bot m’a été signalée sur mon serveur : une personne malveillante pouvait récupérer les transcripts de tickets d’un serveur. Je l’ai signalée à l’éditeur. Je ne sais pas si elle a été corrigée. J’ai donc refait l’outil entièrement, pour l’héberger sur un VPS à la place de l’abonnement.

J’ai conçu et spécifié le système, puis orchestré sa réalisation. La pile est discord.js 14, TypeScript strict, SQLite avec Drizzle, Fastify 5 et zod, en versions épinglées. Le serveur web tourne dans le même process que le bot.

Le problème

Dans une file de tickets, plusieurs opérateurs se disputent la prise en charge d’un même ticket (le claim), ce qui ouvre cinq risques. La règle « premier qui clique gagne » avantage un clic automatisé (auto-clicker). Deux clics simultanés ne doivent pas attribuer le même ticket deux fois. Une tâche différée (un job) peut être rejouée après un crash. Discord limite le renommage d’un canal sans l’annoncer clairement. Deux onglets du dashboard peuvent s’écraser la configuration.

Architecture et décisions

Un clic de claim traverse une chaîne ordonnée de six gardes : plafond de tickets actifs, cooldown, plafond glissant, détection de comportement, défi et fenêtre de randomisation. La chaîne s’arrête au premier verdict qui n’est pas « allow ». Les gardes reçoivent la base, une horloge et des coordinateurs injectés, sans accès à Discord, ce qui les rend testables seules.

Écran 13Claiming en file d’attente

Une fabrique choisit ensuite la stratégie de répartition parmi quatre : aucune, round-robin, moins chargé, push. Elle se replie sur « aucune » quand une dépendance manque, et le flux de claim reste intact.

La décision centrale porte sur l’attribution : un UPDATE conditionnel unique (état « en file » et aucun claimant). Une ligne modifiée désigne le gagnant, zéro ligne désigne le perdant. Une double attribution reste donc impossible, même si toutes les gardes laissent passer les deux clics.

Dans la Fig. 1, deux opérateurs cliquent au même instant sur le même ticket, et un seul l’obtient.

J’ai écrit l’OAuth2 Discord à la main avec le fetch natif de Node, et un limiteur de débit sans dépendance, pour garder une chaîne de dépendances courte. J’ai fixé une seule instance par fichier de base, parce que deux instances double-exécuteraient jobs et renommages.

Reprise après arrêt

Le planificateur de jobs est persistant et garantit une exécution au moins une fois, avec des handlers idempotents. Il réserve un job par un UPDATE atomique avant d’attendre le handler, et il reprend au démarrage les jobs restés en cours. Un échec est re-planifié à 1, 5 puis 15 minutes, puis le job passe en statut terminal à la cinquième tentative.

L’arrêt suit un ordre fixe : arrêt des entrées, drain borné, destruction du client, fermeture de la base, avec un minuteur de sortie forcée. Les renommages de canal passent par une file persistée où le dernier nom demandé gagne, avec 5 minutes de marge entre deux renommages effectifs.

Écran 14Automatisations

Sécurité du dashboard

Le dashboard écrit la configuration d’un serveur seulement si le hash SHA-256 lu avant l’édition est toujours le hash courant ; sinon il renvoie un conflit sans rien écrire. Un utilisateur autorisé par un simple rôle dashboard ne peut pas modifier la liste de ces rôles.

Écran 21bDétail d’une modification

La connexion utilise un état anti-CSRF de 16 octets à usage unique, une redirection post-login validée et une session de 32 octets dans un cookie signé de 7 jours. Le transcript HTML est autonome : les données sont en base64, le texte est échappé, le DOM est construit sans innerHTML, et l’accès est limité à 60 requêtes par minute.

Résultat

J’ai vérifié chaque livraison par trois contrôles bloquants : les tests, le lint et le typage. Les services métier sont testés sans simuler discord.js. Pour la version 1.0, le README du dépôt déclare 866 tests unitaires et de handlers verts. Il déclare aussi 20 tests de bout en bout verts. Je n’ai pas rejoué ces tests pour cette fiche.

Ce que j’ai appris, ce que je referais

J’ai placé l’exclusivité du claim dans l’UPDATE conditionnel, sous la chaîne de gardes. Je n’ai donc pas à prouver chaque garde pour la garantir. Une garde peut se tromper sans qu’un ticket soit attribué deux fois.

Quatre limites restent dans la version actuelle :

• Le pool du tirage de randomisation est en mémoire : un redémarrage le perd. Je le persisterais.
• Le tirage utilise Math.random par défaut.
• Les seuils de détection (coefficient de variation 0,05, flag de 5 minutes) sont des constantes que je n’ai pas calibrées. Je les calibrerais avec le journal des claims.
• Les jetons OAuth sont stockés en clair dans la base locale. Je les chiffrerais au repos. J’étudierais PKCE.