C'est dans ce contexte qu'e-venement, le seul logiciel libre de billetterie informatisée, vient de sortir en version 1.8.0, appelée "Breton Beer". Les nouveautés sont multiples et importantes. Dans les grandes lignes :
- Édition de bons de commande et de factures directement depuis le logiciel ;
- Placement numéroté graphique nettement amélioré ;
- Nouvelle interface de vente de billets, totalement interactive, beaucoup plus efficace et ergonomique, améliorant largement son usage sur écran tactile ;
- Arrivée dans l'aire des web services du module de billetterie informatisée.
Notons également avec cette version 1.8.0 la publication des manuels utilisateurs de e-venement sous licences libres (CC by-sa 2.0). En plus des éléments apportés par la version 1.8.0 (déjà évoqués précédemment), e-venement c'était déjà :
- Gestion des relations publiques ;
- Billetterie informatisée conforme au Code Général des Impôts ;
- Placement numéroté graphique ;
- Vente en ligne ;
- Syndication RSS ;
- ...
Développé principalement par Libre Informatique, SSLL créée en 2006 avec la sortie initiale de e-venement, le projet est hébergé par gna.org et son architecture s'appuie sur PHP5 / PostgreSQL >8.2 / Javascript (JQuery en grande partie) pour la partie serveur ; Mozilla Firefox >3.0 pour la partie client.
L'avenir ? Consolider et élargir l'approche "web service" de e-venement, préparer l'agrément du Centre National de la Cinématographique (Web Cinedi), préparer la migration vers le framework Symfony (pour la version 2.0) et continuer à agrandir le nombre de structures équipées !
Aux volontaires testeurs, déployeurs, développeurs... connaisseurs potentiels de Symfony ce progiciel est disponible sur la plateforme gna.org. N'hésitez pas à nous contacter, n'hésitez pas à en parler...
Aller plus loin
- e-venement (406 clics)
- Les manuels utilisateurs (124 clics)
- Le projet sur gna.org (84 clics)
- Libre Informatique (27 clics)
- La news sur le site de Libre Informatique (18 clics)
# Une solution libre, c'est pas génial çà !
Posté par MARCOU Alexis (site web personnel) . Évalué à 5.
Même une fête d'école primaire d'un petit village, pourra avoir son système de billetterie pour son spectacle de fin d'année !!
Bonne continuation !!
[^] # Re: Une solution libre, c'est pas génial çà !
Posté par Baptiste SIMON (site web personnel) . Évalué à 5.
| à des solutions propriétaires hors de prix...
même si les raisons en sont _parfois_ compréhensibles face aux exigences en la matière, tant d'un point de vue légal que d'un point de vues attentes des clients... il est vrai que certains en font vraiment leur choux gras ce qui, d'un point de vue éthique, fait mal au coeur quand on sait combien la culture est subventionnée par les fonds publics pour pouvoir exister.
| Bonne continuation !!
merci ;c)
# Mozilla Firefox >3.0
Posté par Zenitram (site web personnel) . Évalué à 2.
Est-ce tellement high-tech qu'il n'était pas possible d'utiliser des formats standardisés tel que HTML et CSS dans leur version multi-navigateurs, qui passent donc sur d'autres navigateurs (Konqueror, Safari, Opera, IE...)?
Ou alors je n'ai pas compris du tout le sens de cette phrase (reprise aussi sur Wikipedia)... Est-ce le seul navigateur "validé"? Un éclaircissement ou la suppression de cette limite serait peut-être utile.
[^] # Re: Mozilla Firefox >3.0
Posté par Baptiste SIMON (site web personnel) . Évalué à 6.
e-venement est un progiciel... autrement dit un logiciel métier, développé sous la forme client/serveur web pour ses intérêts techniques. comme tout logiciel métier, développé et supporté par une société qui peut s'en porter garante, certaines contraintes sont imposées, au risque de faire décupler les coûts.
l'objectif ici est donc de proposer une solution "garantie"... pour laquelle pouvons donc border les limites. l'une d'entre-elle est le logiciel "client" utilisé pour supporter l'affichage du logiciel. nous avons choisi Mozilla Firefox pour sa portabilité, sa distribution sous licences libre et open source, ...
ainsi Mozilla Firefox >= (je corrige) 3.0 est le seul navigateur validé par nos services et pour lequel nous validerons des évolutions tant internes qu'externes. nous avons des clients qui utilisent d'autres navigateurs, mais nous n'assurons pas les correctifs pour ceux-ci.
il ne s'agit pas d'un site Internet... il s'agit d'une application métier, dont les contraintes techniques et juridiques sont lourdes et nombreuses. si nous pouvons donner des garanties, nous en prenons aussi. le navigateur ici n'est qu'une coquille, un moyen, pas une finalité. je corrige mais valide également l'information : seul Mozilla Firefox >= 3.0 est supporté pour e-venement par Libre Informatique.
si des personnes motivées sont motivées pour se tapper les tests sur d'autres navigateurs, apporter d'éventuels correctifs ne mettant pas en danger le support de Mozilla Firefox... il s'agit d'un logiciel et d'un projet libre !! :c) welcome !
# Pas mal!
Posté par YLD . Évalué à 3.
Il existe aussi une bibliothèque PECL pour les serveurs d'impression Windows, mais elle impose d'installer le serveur HTTP sur une machine Windows (qui dispose des bons drivers installés) [http://www.php.net/manual/en/ref.printer.php#40705].
Autres questions sur les billets;
Quid des mécanismes de sécurité et/ou de vérification des billets (codes barres avec lecteurs optiques pour les solutions bon marché) ?
Les codes barres permettent en outre de gérer relativement facilement des cartes d'abonnements ou de fidélité, des billets couplés, etc. PHP-Barcode est une bibliothèque très complète permettant de générer des codes barres [http://www.ashberg.de/php-barcode/].
Est-il d'ores et déjà possible d'utiliser des billets hautement personnalisés (et ultra coûteux), hologrammes, impressions ultra-violet, papier brûlé (je ne connais pas le terme exact), sur bande ou autre format?
Une petite critique enfin, la définition des vidéos est insuffisante pour être facilement lisible.
Et pourquoi est-ce que les manuels mentionnent la société Synesia en colophon?
Bravo sinon.
J'ai bien noté l'appel à contributions, mais je vais probablement devoir attendre la version «Breton chouchenn» (trop de travail et plus de public).
[^] # Re: Pas mal!
Posté par Baptiste SIMON (site web personnel) . Évalué à 1.
merde... dois-je comprendre que c'est râpé ou qu'un espoir existe toujours (vu la fin du message).
| l'apparition d'une fenêtre d'impression à cliquer pour chaque billet est difficilement
| supportable lors de gros événements
en fait, la nouvelle version (datant de la 1.8) apporte un nouveau mécanisme pour l'édition de billets. on n'a plus à imprimer les billets tarif par tarif et manifestation par manifestation... on imprime tous les billets d'une manifestation d'un coup, et on peut ensuite imprimer des billets ajoutés à la dernière minutes sans aucune difficulté.
cela dit, ton idée d'envoyer directement les impressions à un serveur via HTTP/IPP fait entre serveurs est très bonne, mais il se pose le problème d'un serveur distant... ben oui, l'intérêt d'e-venement est aussi d'être multi-sites... le serveur n'a pas toujours accès aux imprimantes locales !
bon j'avoue que la question devrait être creusée d'avantage, mais on a toujours calé. on avait bien pensé à une requête en AJAX vers un serveur d'impression... mais la politique de sécurité de JS nous bloque. franchement, on est preneurs d'idées !!! en gros on a un serveur Apache/PHP distant et des clients Firefox dans les locaux des imprimantes à utiliser. ces imprimantes sont souvent connectées en éthernet, on y accède via le protocole HP Direct (son nom réel m'échappe) et le driver est HP IIP+. que de l'assez classique je pense.
| Quid des mécanismes de sécurité et/ou de vérification des billets (codes
| barres avec lecteurs optiques pour les solutions bon marché) ?
on attend un client dans le domaine pour y apporter ces modifications... un lecteur de code-barre étant un clavier USB la plupart du temps, il faut juste ajouter une interface qui fasse le focus sur un input-text et valide automatiquement une fois qu'on a le nombre de nombre de chars voulus. vérifs en base, et l'écran passe au vert ou au rouge selon la réponse... et on passe au suivant.
on a déjà fait pas mal d'offres dans ce contexte... mais on a toujours été malheureux au moment des réponses... :c/
| PHP-Barcode est une bibliothèque très complète permettant de générer des
| codes barres [http://www.ashberg.de/php-barcode/].
j'en avais déjà entendu parler... je retiens encore plus alors...
| Et pourquoi est-ce que les manuels mentionnent la société Synesia en colophon?
pur montage administratif... :c) Libre Informatique est hébergé administrativement par Synesia, voilà tout. :c)
| J'ai bien noté l'appel à contributions, mais je vais probablement devoir attendre
| la version «Breton chouchenn» (trop de travail et plus de public).
yes... reste attentif par ici ou abonne toi à la mailing-list gna... et j'espère qu'on te comptera un jour parmi nos utilisateurs (comblés si possible).
[^] # Re: Pas mal!
Posté par YLD . Évalué à 2.
L'impression peut être centralisée sur un serveur d'impression central.(CUPS permet de relayer vers des serveurs d'impression Windows). A charge pour le serveur central d'identifier les clients (IP, ou certificat par exemple), il pourra alors gérer les impressions selon le client et sa requête.
Sinon, il reste possible de mettre possible de mettre des serveurs HTTP un peu partout pour qu'ils discutent entre eux, solution beaucoup plus lourde, mais déjà utilisée par la concurrencel (pour afficher sur un second écran des panneaux « achat », « réservation » ou des annonces pour les prochaines manifestations par exemple).
L'identification par IP impose d'être sûr de son réseau. Des tunnels (sécurisés) entre les différents sites peuvent permettre d'accéder aux serveurs d'impression, à moins de vouloir les laisser avec les postes de caisse sur l'Internet.
dois-je comprendre que c'est râpé
Hmpf, oui, pour l'instant du moins. J'ai eu à utiliser d'autres solutions pour répondre à un cahier des charges musclé (expositions, musée, séances de cinéma, spectacles, évènements, abonnements, vente en ligne). La solution la plus proche de nos desiderata plantait régulièrement saturant CPU et mémoire. Une autre proposait une fonction spéciale pour rebooter le serveur depuis un poste de caisse et relancer l'ensemble du système. Celle que nous avons choisi promettait d'évoluer, mais elle était ultra-bugguée. C'est peu de le dire...
Juste un exemple, mais je me souviens m'être trouvé face à une foule de spectateurs furibards à l'encontre des pauvres caissiers, au motif que l'intégralité des postes de caisse étaient bloqués. C'était dû à des requêtes statistiques faites depuis un autre poste qui écrabouillaient les performances du serveur monstrueux hébergeant la base de données très, très mal indexée et à une connexion vers ladite base depuis un tableur où l'utilisatrice pouvait requêter librement).
Nous avons essuyé les plâtres pendant presque deux ans à coup de grosses colères et de menaces. Il a fallu plus d'une personne à plein temps pour prendre des coups et mettre de l'huile, déterminer quelles fonctionnalités étaient utilisables, comment contourner tel ou tel bug, vérifier que les résolutions des dysfonctionnement passés n'en (re)créaient pas d'autres, etc. Durant ce laps de temps, deux autres personnes furent embauchées, pour reprendre ou vérifier l'ensemble des comptes produit par le système...
Aujourd'hui le produit est stabilisé. Mais c'est vrai qu'il est scandaleux que toutes ces institutions culturelles (ou touristiques) (para)publiques qui représentent tout de même des « budgets billetteries » et une part du public non négligeables n'aient jamais songé à développer des solutions communes. L'une des rares coopération massive récente à ma connaissance a consisté à négocier des milliers de licences Microsoft pour des clopinettes (et uniquement au niveau parisien).
Comme quoi la division fait aussi le règne.
[^] # Re: Pas mal!
Posté par Baptiste SIMON (site web personnel) . Évalué à 1.
| (CUPS permet de relayer vers des serveurs d'impression Windows). A
| charge pour le serveur central d'identifier les clients (IP, ou certificat
| par exemple), il pourra alors gérer les impressions selon le client et sa
| requête.
les lieux de billetterie sont souvent distants du serveur central chez nos clients, sont également souvent multiples, parfois à plusieurs dizaines de km les uns des autres... donc la solution proposée (de faire envoyer par le serveur billetterie une impression au serveur d'impression) est très séduisante, mais pour la plupart des cas inutilisable.
cela dit, si quelqu'un veut développer ce genre d'option, avec grand plaisir !! et si un de nos clients le souhaite, on peut le faire, sans problème.
| dois-je comprendre que c'est râpé
| Hmpf, oui, pour l'instant du moins. J'ai eu à utiliser d'autres solutions pour
| répondre à un cahier des charges musclé (expositions, musée, séances de
| cinéma, spectacles, évènements, abonnements, vente en ligne).
e-venement est en cours d'agrément CNC (cinéma), en cours d'adaptation pour les musées, gère les évènements de toutes natures et aura un module générique de vente en ligne dans quelques mois si tout va bien (il en existe déjà, mais non génériques). quand je dis "en cours", c'est que ça serait déjà fait si nous avions eu les financements plus tôt... mais ils sont entrain d'arriver ! ;c)
de là à savoir s'il est buggué... en tout cas il n'est pas "ultra-buggé" et jamais nous n'avons eu à rebooter un serveur depuis 4 ans !!!!!!!!! surtout depuis un poste billetterie !
# image serveur virtuel
Posté par KiKouN . Évalué à 1.
C'est pourquoi j'aimerai savoir s'il est possible de produire des images virtuelles d'un serveur e-venement ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.