Coopérative Code Commun · Documentation · Budget contributif · Discord · 🇬🇧 English
🇬🇧 English speakers: TiBillet is a federated, open-source toolkit for ticketing, POS, NFC cashless payments, memberships, and local currencies — built as a digital commons by the Code Commun Cooperative. Read more in English →
TiBillet est un ensemble d'outils libres pour les lieux culturels, les festivals, les associations et les tiers-lieux : billetterie en ligne, caisse enregistreuse, cashless par carte NFC, gestion d'adhésions, monnaie locale et monnaie temps.
Mais TiBillet n'est pas qu'un logiciel. C'est un commun numérique, construit par et pour les gens qui s'en servent. Plusieurs centaines de lieux et organisations, plus d'une vingtaine en contribution active, une coopérative pensé comme un commun juridique, et l'idée simple que les outils qui font tourner nos lieux de vie ne devraient appartenir à personne d'autre qu'à ceux qui les utilisent.
Le principe : Un outil de création de fédération a travers des agendas et billetteries, une caisse enregistreuse et carte NFC unique, valable dans tout le réseau. Pas de frais d'activation, pas de date d'expiration, pas de dark pattern. Vous rechargez quand vous voulez, vous dépensez où vous voulez, vous vous faites rembourser quand vous voulez. Et la carte sert aussi de carte d'adhésion, de porte-monnaie local et/ou de monnaie temps.
Alternatives à : Weezevent, HelloAsso, Cyclos, L'Addition, Ulule, Caisses et POS JVC...
Mais TiBillet va encore plus loin car pensé pour créer des fédérations : Une billetterie peut se fédérer à d'autres pour créer des agendas communs. Des caisses peuvent lire les mêmes cartes NFC pour faire des monnaies locales. Des collectifs peuvent fédérér des producteurs pour créer une caisse sociale alimentaire.
| Module | Description | Détails | |
|---|---|---|---|
| 🎫 | Billetterie & Agenda | Événements, tarifs, réservations en ligne, QR codes, scan à l'entrée | → BaseBillet/ |
| 🏪 | Caisse enregistreuse | Point de vente tactile, grille d'articles, multi-moyens de paiement, conforme LNE | → laboutik/ |
| 💳 | Cashless NFC | Carte sans contact, rechargement en ligne ou sur place, paiement fédéré multi-lieux : Cashless de festival. | → fedow_core/ |
| 🤝 | Adhésions | Cotisations en ligne ou sur place, vérification au scan, tarifs préférentiels | → BaseBillet/ |
| 🪙 | Monnaie locale & temps | Euros, monnaie cadeau, monnaie temps — plusieurs devises sur une seule carte | → fedow_core/ |
| 📊 | Rapports & comptabilité | Clôtures de caisse, export FEC, bilans billetterie, PDF et CSV | → laboutik/ |
| 📦 | Inventaire | Stock par produit, alertes, journal de mouvements, mise à jour temps réel | → inventaire/ |
| 🗳️ | Budget contributif | Initiatives, votes, financement participatif, co-rémunération transparente, suivi d'engagement bénévoles. | → crowds/ |
| 🖨️ | Impression thermique | Tickets, reçus, clôtures — Sunmi Cloud, LAN, imprimante interne, impréssion de commande en cuisine | → laboutik/ |
| 🌐 | API sémantique | Schema.org / JSON-LD, clé API, endpoints REST | → api_v2/ |
Documentation en cours d'écriture collaborative et disponible en français sur : https://tibillet.coop/
L'ancienne documentation EN/FR est toujours disponible ici : https://tibillet.github.io/documentation_v2/
TiBillet n'est pas un prototype. C'est un outil en production depuis 2018, né au Manapany Festival à La Réunion, aujourd'hui déployé sur plusieurs dizaines de lieux — des cafés associatifs aux festivals de 15 000 personnes.
Quelques exemples de ce que TiBillet rend possible aujourd'hui :
- 4 festivals à Montpellier partagent la même carte NFC pour 15 000 festivaliers. Une carte, quatre lieux, zéro bracelet jetable.
- Un collectif citoyen en Normandie distribue 100 cartes pour de l'aide alimentaire solidaire (Sécurité Sociale de l'Alimentation). Chaque carte est créditée de 100 €, peu importe ce que la personne a payé. Pas de contrôle, pas de case "précaire" à cocher — juste de la dignité.
- La Raffinerie à La Réunion, une ancienne sucrière reconvertie en tiers-lieu, utilise une monnaie temps : les heures passées sur les chantiers participatifs du mercredi sont comptabilisées sur la carte, échangeables contre des services ou des boissons au bar associatif le soir.
- Des bars associatifs vérifient l'adhésion automatiquement au scan NFC — fini le fichier Excel que personne ne consultait.
TiBillet tourne dans Docker. Pour lancer l'environnement de développement :
git clone https://github.com/TiBillet/Lespass.git
cd Lespass
cp env_example .env # Configurer les variables d'environnement
# (les valeurs par défaut conviennent pour le dev)
# Certificat HTTPS de dev (mkcert) — cf. TLS_CERT_NAME dans le .env.
# Une seule fois par machine : installer mkcert, puis sa CA locale
sudo apt install libnss3-tools mkcert # Fedora : sudo dnf install nss-tools mkcert
mkcert -install
# Dans le dépôt (guillemets simples OBLIGATOIRES autour du wildcard) :
mkdir -p certs
mkcert -cert-file certs/dev.pem -key-file certs/dev-key.pem 'tibillet.localhost' '*.tibillet.localhost'
# Vérifier : la sortie doit contenir DNS:tibillet.localhost, DNS:*.tibillet.localhost
openssl x509 -in certs/dev.pem -noout -ext subjectAltName
# Créer le network (une seule fois par machine)
docker network create frontend
# Lancer la stack (le premier lancement build l'image : compter ~15 min) :
docker compose up -d
# Données de démo / dev (base remise à zéro, fixtures installées).
# Arrêter Celery pendant le flush : sinon il crée la Configuration du lieu en même
# temps que `install` -> IntegrityError "BaseBillet_configuration_pkey".
docker compose stop lespass_celery
docker exec lespass_django ./flush.sh --no-runserver
docker compose start lespass_celery
# Lancer le serveur de dev (aussi pour les fois suivantes, sans refaire le flush)
docker exec -ti lespass_django bash -ic rsp
# Les e-mails (confirmation de compte, etc.) arrivent dans Mailpit :
# https://mailpit.tibillet.localhostL'application est accessible sur
https://lespass.tibillet.localhosthttps://lespass.tibillet.localhost/laboutik/caisse/(caisse LaBoutik, intégrée à Lespass)
Prérequis : Docker, Docker Compose, et un reverse proxy Traefik (inclus dans le compose).
Refaire un flush : Fedow a sa propre base (volume
fedow_database), queflush.shne vide pas. Un second flush échoue alors avecPublic pem not match. Repartir de volumes vides, puis rejouer la séquence de flush :docker compose down -v && docker compose up -d.
Pour les détails d'installation, de configuration et de déploiement en production : → Documentation complète
La suite se lance via make (logique : scripts/lancer_tests.sh) ; make help liste
toutes les commandes et les familles E2E. Les tests qui appellent le vrai Stripe (mode
test) tournent a chaque fois : aucun test n'est ignore, ce qui ne peut pas tourner ECHOUE.
make test # Python (~11 min) — modeles, vues, API, paiements Stripe reels compris
make e2e # E2E navigateur (~14 min) — Playwright, exige `stripe listen` dans byobu
make e2e-visible adhesion # une famille E2E, dans un Chromium visible (liste : make help)
make coverage # pytest + couverture du code (total + rapport HTML dans htmlcov/)
make test ARGS="tests/pytest/test_stripe_refund.py -k panier" # cibler
make e2e-visible LENTEUR=1500 ARGS="tests/e2e/test_panier_flow.py" # suivre pas a pas (ms entre deux actions)
make coverage FICHIERS="BaseBillet/services_panier.py" # detail ligne a ligne de ces fichiersLes deux suites exigent le serveur live (le script le verifie) : une partie des tests l'appelle en HTTP.
Prerequis de make e2e et make e2e-visible : le serveur Django tourne derriere Traefik
(alias rsp dans le pane byobu — manage.py runserver en mode daphne, requis
pour les WebSockets), et Chromium est installe dans le conteneur :
# Le venv Poetry n'est pas /DjangoFiles/.venv : on demande son chemin a Poetry.
VENV=$(docker exec lespass_django poetry env info -p)
docker exec -u root lespass_django "$VENV/bin/playwright" install-deps chromium
docker exec lespass_django poetry run playwright install chromiumOrdre conseille : lancer les E2E avant pytest. Les E2E creent de vraies ventes dans le tenant de developpement, qu'un test pytest comptant large peut ramasser.
Voir tests/README.md pour la documentation complete (architecture, pieges,
variables d'environnement) et tests/PIEGES.md pour les pieges deja rencontres.
Carte Stripe de test : 4242 4242 4242 4242, exp 12/42, CVC 424.
Le code arrive en production en deux temps : une release (l'image Docker du commit,
construite sur la machine du mainteneur et poussee sur Docker Hub), puis la mise a jour
du serveur, sans coupure : migration dans un conteneur jetable pendant que l'ancien code
sert, puis workers gunicorn remplaces un par un. Sans migration a faire, make update prend
la voie courte : pas besoin de release, une a deux minutes.
# Machine du mainteneur : main pousse, VERSION incremente sur main (docker login fait)
make release # construit origin/main, quelle que soit la branche courante, et pousse :latest et :$VERSION
REFAIRE_LA_BASE=1 make release # idem en reconstruisant tout (systeme, venv)
# Nouveau serveur, une fois : .env (secrets generes, valeurs A_REMPLIR), dossiers, controles
make env # relancable : ne remplace jamais un .env existant, refait les controles
# Serveur de production, dans byobu, a toute heure (attend la fin d'une sauvegarde en cours)
make update # met la prod a jour sur le dernier commit pousse
make update MIGRER=1 # force la migration (MIGRER=0 la saute ; EXECUTEUR=standard : un lieu apres l'autre)
make update COMPLET=1 # sans migration, passe quand meme par l'image de la release
make update_nuit # programme make update a 02:05 avec at, cible figee maintenant (memes variables)make update s'arrete avant de toucher a quoi que ce soit si les dependances, le
dockerfile, le compose, supervisor ou nginx ont change : c'est alors une « grosse mise
a jour », avec une coupure planifiee. Le journal de chaque passage est dans
logs/mise_a_jour_*.journal. Detail (verrou avec la sauvegarde, grosse mise a jour, retour en
arriere) : TECH_DOC/SESSIONS/DEPLOIEMENT/SPEC.md.
TiBillet est en cours d'unification en mono-repo. Les trois services historiques (Lespass, LaBoutik, Fedow) deviennent un seul projet Django multi-tenant :
TiBillet (mono-repo)
├── BaseBillet/ Billetterie, adhésions, événements
├── laboutik/ Caisse enregistreuse, POS
├── fedow_core/ Portefeuille fédéré, tokens, multi-devises
├── crowds/ Budget contributif, financement participatif
├── inventaire/ Gestion de stock POS
├── api_v2/ API sémantique schema.org
├── Administration/ Admin Django (Unfold)
├── AuthBillet/ Authentification, SSO
├── PaiementStripe/ Paiements, webhooks Stripe
└── ...
Stack : Django 4.2, Python 3.11, PostgreSQL 13 (multi-tenant via django-tenants), Redis, Celery, HTMX + Bootstrap 5, Django Channels (WebSocket).
Pas de SPA, pas de framework JavaScript lourd. Le rendu est côté serveur. Les interactions dynamiques passent par HTMX. Le JavaScript est minimal (toasts et petites interactions). C'est un choix délibéré : le code doit pouvoir être lu et modifié par des développeur·euses non-expert·es qui rejoignent la coopérative.
TiBillet est sous licence AGPLv3. Ça garantit que le code restera libre — personne ne peut le verrouiller, le fermer, le privatiser.
Mais on pense que le logiciel libre, aussi génial soit-il, ne suffit pas. Un dépôt Git avec une licence libre, c'est une ressource ouverte. Ce n'est pas encore un commun. Des tanks roulent sur Linux. Les plus grandes entreprises du monde construisent leur fortune sur du logiciel libre. La licence protège le code. Elle ne protège ni les usages, ni les gens.
Nous n'avons pas choisi de "faire un commun". On fabrique en commun, parce que TiBillet n'aurait jamais pu être construit autrement.
La monnaie temps de la Raffinerie, c'est une idée qui a émergé des chantiers du mercredi matin — pas d'un cahier des charges. La SSA en Normandie, c'est un collectif citoyen qui a dit "on a besoin de ça" et qu'on a accompagné sur place. Le mode festival, c'est le retour de dix ans de bénévoles derrière des tireuses à bière à 2h du matin. Aucun de ces usages n'aurait été inventé par une équipe de développeurs seuls dans un bureau, ni par un modèle d'IA entraîné sur du code — parce que ces solutions viennent des gens qui vivent les problèmes, pas de ceux qui imaginent les résoudre.
On s'appuie sur les travaux d'Elinor Ostrom pour penser ce qu'on fait. Un commun, c'est trois choses indissociables :
- Une ressource partagée — le logiciel, oui, mais surtout tout ce qu'il permet : l'agenda fédéré, la carte partagée, les données qui restent chez vous.
- Une communauté vivante — les lieux qui s'en servent, qui remontent des besoins, qui testent, qui documentent. C'est le point de départ, pas un bonus.
- Une gouvernance organisée — la coopérative Code Commun, structurée en SCIC avec trois collèges (animateur·ices, contributeur·ices, utilisateur·ices), où chaque voix compte pareil.
« Un logiciel libre qui dort au fond d'une forge Git ne change pas le monde. Un commun vivant, partagé, documenté et soutenu, si. » — Charte Code Commun
Pour aller plus loin : Qu'est-ce qu'un commun numérique ? · Charte et valeurs
TiBillet ne fonctionne pas avec des "issues" et des "pull requests" dans le vide. On construit ensemble.
On met les sous sur la table — littéralement. Sur codecommun.tibillet.coop/contrib, vous trouverez les chantiers en cours, les budgets associés et les contributions de chacun·e. Vous choisissez une tâche, vous décidez comment vous voulez être rémunéré·e (ou pas — le bénévolat est bienvenu aussi), et c'est validé collectivement.
C'est ce qu'on appelle le budget contributif : pas de manager qui attribue les tâches, pas de hiérarchie qui décide des salaires. Chacun·e évalue ses besoins en transparence.
- Sessions de pair à pair — Tous les jeudis et vendredis, en visio, on code ensemble. Pas besoin d'être expert·e.
- Déplacements sur le terrain — On ne construit pas depuis un bureau. On va dans les lieux, on installe, on forme, on écoute les retours. C'est comme ça qu'émergent les vraies fonctionnalités.
- Réunions mensuelles ouvertes — Le premier lundi de chaque mois, tout le monde est invité. On parle de ce qui marche, de ce qui coince, de ce qu'on veut construire ensuite.
- Discord & Matrix — Pour le quotidien, les questions, les coups de main.
- Venez discuter sur Discord — on vous accueille, on vous oriente.
- Consultez les chantiers sur le budget contributif — il y a des tâches de tous niveaux, de la documentation à l'architecture Django.
- Lisez le GUIDELINES.md pour les conventions de code (FALC, HTMX, ViewSets, etc.).
- Proposez une idée — si un besoin revient dans 3-4 lieux, on s'y colle.
Le code suit le principe FALC (Facile À Lire et Comprendre) : noms de variables explicites, commentaires bilingues FR/EN, logique lisible de haut en bas, pas de magie. Parce qu'un commun numérique, ça implique que le code soit accessible à celles et ceux qui veulent s'en emparer.
TiBillet est porté par la Coopérative Code Commun, une SCIC (Société Coopérative d'Intérêt Collectif) basée à La Réunion.
- Lauréat France 2030 — Appel à projet "Billetterie innovante" du ministère de la Culture.
- JetBrains — Licences open source.
AGPLv3 — Libre, et ça le restera.
- Discord : discord.gg/ecb5jtP7vY
- Matrix : https://matrix.to/#/#tibillet:tiers-lieux.org
- Email : contact@tibillet.re
- Site : tibillet.coop
- Coopérative : codecommun.coop