Tick&, un outil de ticketing ITSM libre, et ce qu'il ne sait pas encore faire

J'ai passé les derniers mois à écrire Tick&, un outil de ticketing ITSM libre et
auto-hébergeable, sous AGPL-3.0. Incidents, demandes, problèmes, changements, engagements de
service, moteur de règles, base de connaissances, formulaires de catalogue, enquêtes de
satisfaction, portail self-service. La gestion de parc est délibérément hors périmètre : je
préfère un outil qui fait bien une chose que deux à moitié.

Une démonstration tourne ici, remise à zéro toutes les heures :
https://demo.tickand.fr — cinq comptes sont proposés sur l'écran de connexion, un par
profil, pour voir ce que chacun a le droit de faire.

Le code : https://github.com/tick0001/tick

Ce qui me paraît valoir le détour

Le cloisonnement est appliqué par la base, pas par l'application. Les organisations forment
un arbre, et l'isolation repose sur le Row-Level Security de PostgreSQL — pas sur des
conditions WHERE qu'on peut oublier d'écrire dans un nouveau service. Un droit est un triplet
objet × action × portée, et l'absence de ligne vaut refus. Des tests d'intégration vérifient
qu'un compte d'une entité ne voit rien de sa voisine, en interrogeant une vraie base.

Les droits suivent le profil actif, jamais l'union des profils. Quelqu'un qui est technicien
sur un site et simple demandeur au siège ne cumule pas ses droits : il change de casquette. Ça
paraît évident dit comme ça, et c'est pourtant ce que beaucoup d'outils font de travers.

Le moteur de règles a un simulateur. On fabrique un ticket fictif, on le passe dans le
moteur, et il montre quelles règles s'appliquent et ce qu'elles produisent — avant qu'une règle
ne touche un vrai ticket.

Les plugins ne demandent pas de forker. Ils se chargent dans le processus, déclarent leurs
permissions dans un manifeste versionné, obtiennent leur propre schéma PostgreSQL, et se
retirent sans laisser de traces.

Français et anglais dès le départ, interface comme courriels.

Ce qu'il faut savoir avant de s'en servir

Et c'est la vraie raison de ce journal.

Personne ne s'en est encore servi pour de vrai. La démonstration publique fait tourner les
images publiées sur un VPS derrière Traefik, donc le chemin de déploiement est exercé tous les
jours — mais aucun centre de services n'a traité un seul vrai ticket avec Tick&. Les dix-sept
modules sont couverts, l'API compte 179 opérations documentées, la suite fait 2 337 tests dont
des tests d'intégration sur une vraie base. Rien de tout ça ne remplace un utilisateur.

La version 0.1 est étiquetée, pas éprouvée. Attendez-vous à des ruptures entre versions
mineures tant que les interfaces n'auront pas été exercées par quelqu'un d'autre que leur
auteur. Le journal des versions dit, pour chacune, ce qu'elle exige de vous avant de monter.

Le SDK de plugins reste en 0.x. Il ne se figera qu'une fois chaque point d'extension
exercé par un usage réel ; le plugin de référence n'y suffit pas.

Ce qui aiderait le plus

Dans l'ordre :

L'installer et dire ce qui a cassé. Quatre chemins sont documentés — conteneurs, archives autonomes sans Docker, Linux et Windows — dont deux ont été déroulés sur une machine vierge et deux non. Le guide Windows le dit lui-même. Un rapport qui commence par « j'ai suivi le guide et je suis bloqué à l'étape 6 » vaut plus qu'un correctif.
Écrire un plugin d'essai, pour que le SDK se heurte à un usage qui n'est pas le mien.
Dire ce qui manque par rapport à ce que vous utilisez aujourd'hui. Y compris « ce n'est pas clair » — c'est un défaut de documentation, pas un caprice.

Le déploiement par conteneurs tient en trois commandes, et il y a un Makefile pour ceux qui
n'aiment pas taper trois -f de mémoire.

Merci d'avoir lu.