Un nouveau rapport « Participants par session » vous permet de visualiser et d'exporter, en quelques clics, la liste complète des participants inscrits à chacun de vos ateliers et sessions de programme.

Fini les croisements manuels entre les inscriptions et l'agenda : vous obtenez une vision fiable du taux de remplissage de chaque session, ce qui facilite la préparation des salles, la relance des inscrits et le reporting post-événement. 📊

• Nouveau rapport dédié listant les participants rattachés à chaque session de votre programme
• Filtres avancés pour cibler les sessions, les dates ou les segments de participants qui vous intéressent
• Export Excel du rapport, traité en arrière-plan par lots afin de rester rapide et stable même sur des événements comptant un très grand volume d'inscriptions
• Champs personnalisés inclus dans l'export, avec un formatage cohérent et lisible des données des participants
• Disponible dans toutes les langues prises en charge par la plateforme (français, anglais, espagnol, italien, coréen, arabe, catalan, etc.)

Les participants déjà enregistrés (check-in effectué) ne peuvent plus être rejetés ni annulés, que ce soit depuis le back-office, les pages publiques ou l'API. Une fois qu'une personne est sur place, son statut est verrouillé.

Pourquoi c'est important : un rejet ou une annulation accidentelle après l'arrivée d'un participant fausse vos rapports de présence, perturbe le contrôle d'accès et oblige vos équipes à corriger les données à la main. Cette protection élimine ce risque à la source. 🔒

Ce qui change concrètement :

• Les actions de rejet et d'annulation sont désactivées pour tout participant enregistré, dans la liste des participants comme dans le panneau d'actions.
• La règle s'applique également aux groupes de participants, aux inscriptions publiques et aux appels API (v3), afin qu'aucun canal ne puisse contourner la protection.
• Les paiements traités via Stripe tiennent désormais compte de cette même règle pour éviter les annulations incohérentes.
• Les textes liés à l'annulation ont été revus et traduits dans toutes les langues prises en charge, pour que le message affiché soit clair sur la raison du blocage.

Les requêtes qui déterminent les destinataires des notifications d'événement ont été enrichies, et les informations de sessions (workshops) renvoyées par l'API sont désormais plus complètes.

Concrètement, cela signifie que vos communications atteignent les bonnes personnes, au bon moment, sans manipulation manuelle de listes : moins de risques d'oubli, moins d'envois non pertinents et un gain de temps réel pour vos équipes lors de la préparation d'un événement. 🎯

• Requêtes de destinataires de notifications étendues pour couvrir davantage de cas de ciblage
• Données de sessions (workshops) enrichies dans l'API v3 afin d'alimenter ces segmentations
• Meilleure cohérence entre les informations affichées dans la plateforme et celles utilisées pour l'envoi des notifications

Les limites minimum et maximum d'ateliers (workshops) par participant se comportent désormais de manière cohérente lors de la configuration d'un événement : les règles que vous définissez sont celles qui s'appliquent réellement au moment de l'inscription. 🎟️

Pourquoi c'est important : lorsque ces limites ne s'appliquent pas correctement, certains participants réservent trop d'ateliers, d'autres sont bloqués alors qu'ils devraient pouvoir s'inscrire — et votre équipe finit par corriger les inscriptions à la main. Ce correctif garantit une planification des capacités fiable, de la configuration jusqu'au check-in.

• 🔧 Correction de la validation du nombre minimum et maximum d'ateliers qu'un participant peut sélectionner.
• 🌐 Messages associés mis à jour dans l'ensemble des langues prises en charge, pour un retour clair et cohérent.

Les traductions allemandes de plusieurs sections de la plateforme ont été revues afin d'utiliser une terminologie plus précise et plus proche des usages réels.

Pourquoi c'est important : vos équipes et participants germanophones comprennent plus rapidement les libellés, ce qui réduit les hésitations, les erreurs de manipulation et les demandes de support. 🇩🇪

• Mise à jour des libellés des modules de l'application
• Révision des textes liés aux pages d'événement
• Terminologie affinée dans les paramètres de sécurité
• Traductions corrigées dans la section des intervenants

Les e-mails de notification peuvent désormais être envoyés via votre configuration SMTP personnalisée, au même titre que vos autres communications.

Pourquoi c'est important : vos notifications partent désormais de votre propre domaine et de votre infrastructure d'envoi, ce qui renforce la cohérence de votre image de marque, améliore la délivrabilité et évite que vos messages importants n'atterrissent dans les spams. 📬

• Prise en charge du SMTP personnalisé dans le service d'envoi des notifications
• Cohérence totale entre les notifications et le reste de vos e-mails sortants
• Aucune action requise si vous utilisez la configuration d'envoi par défaut

L'ensemble de la nouvelle interface du créateur de sites et des paramètres d'apparence est désormais disponible dans les langues prises en charge par la plateforme.

Vos équipes locales travaillent dans leur langue, ce qui réduit les erreurs de configuration et accélère la prise en main de l'outil. 🌍

• Traductions ajoutées pour le créateur de sites, le menu latéral et les paramètres d'apparence
• Couverture incluant notamment le français, l'allemand, l'arabe et le catalan
• Libellés revus pour plus de clarté

Un mécanisme de mise en cache dédié aux thèmes a été introduit afin d'accélérer le rendu des pages publiques et du formulaire d'inscription.

Les styles du thème ne sont plus recalculés à chaque visite : vos pages s'affichent plus vite, ce qui améliore l'expérience des participants et les taux de conversion à l'inscription. 🚀

• Nouveau gestionnaire de cache pour les thèmes
• Invalidation automatique du cache lors de la modification des paramètres d'apparence
• Rendu optimisé du thème sur les pages publiques et les contenus intégrés

Le sérialiseur d'événement de l'API v4 expose de nouvelles données publiques, utiles pour construire des sites et des intégrations personnalisés.

Vos développeurs récupèrent en un seul appel les éléments nécessaires à l'affichage d'une page d'événement complète, sans requêtes supplémentaires ni valeurs codées en dur.

• Ajout de la carte statique du lieu dans les attributs publics de l'événement
• Ajout de la langue par défaut de l'événement
• Corrections de cohérence sur les attributs retournés

Les pages publiques, y compris la page d'annulation de participation, prennent désormais en charge des balises (tags) qui sont automatiquement remplacées par les informations réelles du participant et de l'événement.

Vous personnalisez ainsi les messages affichés à chaque participant — nom, événement, dates — sans créer une page différente pour chaque cas, pour une communication plus proche et moins générique. ✨

• Balises dynamiques disponibles sur les pages publiques du participant
• Prise en charge également sur la page d'annulation de participation
• Remplacement automatique par les données du participant et de l'événement

Les thèmes et les sites web peuvent désormais être dupliqués, afin de réutiliser une configuration existante comme point de départ.

Pour les organisateurs qui gèrent des événements récurrents ou des séries d'événements, c'est plusieurs heures de paramétrage économisées à chaque nouvelle édition — et la garantie d'une identité visuelle parfaitement homogène. ⏱️

• Duplication disponible sur les thèmes et sur les sites web
• Reprise complète de la configuration existante comme base de travail

Lorsque vous intégrez le formulaire d'inscription dans votre propre site via une iframe, celle-ci communique désormais sa hauteur réelle à la page hôte et se redimensionne automatiquement.

Plus de barres de défilement internes ni d'espaces vides sous le formulaire : l'intégration ressemble enfin à une partie native de votre site, sans bricolage CSS côté client.

• Communication de la hauteur du contenu via postMessage
• Redimensionnement dynamique lors du changement d'étape ou d'affichage de messages d'erreur
• Correctifs de mise en cache pour garantir un redimensionnement fiable à chaque chargement

Le thème défini dans les paramètres d'apparence est désormais appliqué automatiquement au formulaire d'inscription public de votre événement.

Vos participants vivent une expérience visuellement continue, du site de l'événement jusqu'à la confirmation d'inscription, ce qui renforce la confiance et réduit les abandons en cours de parcours.

• Couleurs, typographies et styles d'angles hérités du thème de l'événement
• Styles du formulaire affinés suite aux retours de design et de QA
• Rendu cohérent, que le formulaire soit affiché en page complète ou intégré

Un nouvel espace Paramètres d'apparence vous permet de définir l'identité visuelle de votre événement sans écrire une seule ligne de code, avec un aperçu immédiat du rendu.

Fini les allers-retours avec une équipe technique pour obtenir des pages aux couleurs de votre marque : vous ajustez, vous visualisez, vous publiez. 🎨

• Nouveau sélecteur de couleurs et nuancier (swatch) pour définir la palette de votre événement
• Choix du style des angles : carrés, arrondis ou en pilule, appliqué de façon cohérente à l'ensemble des composants
• Bannière d'aperçu permettant de visualiser le résultat avant publication
• Palette de couleurs par défaut revue pour un rendu plus moderne et plus lisible

Le calendrier d'événements public reste désormais accessible même lorsque les champs de dates du filtre sont vides. Auparavant, un sélecteur de date laissé vide envoyait une valeur « Invalid Date » qui provoquait une erreur serveur (500) et rendait le calendrier totalement inutilisable.

Pourquoi c'est important : vos visiteurs ne tombent plus sur une page en erreur au moment d'explorer vos événements — un clic malencontreux ne coûte plus une inscription potentielle. 🗓️

• Les paramètres start_date et end_date invalides sont désormais ignorés au lieu de déclencher une erreur sur l'appel au calendrier.
• Lorsqu'une seule date est renseignée, le filtre s'applique correctement sur cette borne uniquement.
• Les dates valides continuent de filtrer les résultats exactement comme avant, sans changement de comportement.

Les noms et descriptions des articles de vente acceptent désormais tous les caractères Unicode, y compris les alphabets chinois, japonais et coréen (CJK) ainsi que les emojis et autres caractères codés sur 4 octets.

Auparavant, la création d'un article contenant ces caractères était rejetée en raison d'un encodage limité (latin1), ce qui obligeait les organisateurs à renommer leurs produits ou à les translittérer. Désormais, la billetterie et la boutique reflètent fidèlement la langue de votre audience, sans perte de sens ni caractères altérés. 🌏

• Conversion des champs nom et description des articles de vente vers l'encodage utf8mb4
• Prise en charge complète des caractères CJK, des accents et des emojis à la création comme à la modification
• Aucune action requise de votre côté : la migration s'applique automatiquement aux articles existants

Un gain direct pour les événements internationaux : moins d'erreurs à la création, aucun contenu tronqué et une expérience d'achat cohérente pour les participants, quelle que soit leur langue.

Les participants reçoivent désormais automatiquement une notification lorsque leur programme d'activités est modifié : inscription à une session, retrait d'un atelier ou mise à jour de leur agenda personnel. Plus besoin d'envoyer des communications manuelles après chaque ajustement de planning.

Pourquoi c'est important : les changements de dernière minute sont inévitables dans l'organisation d'un événement. En informant les participants en temps réel, vous réduisez les absences, les arrivées dans la mauvaise salle et le volume de questions adressées à vos équipes sur place. 🎯

• Notification déclenchée automatiquement lors de l'ajout ou du retrait d'une activité dans l'agenda d'un participant
• Prise en charge des modifications effectuées depuis les sessions et les ateliers, quelle que soit l'origine du changement (back-office ou inscription du participant)
• Communication cohérente sur l'ensemble des points d'entrée de gestion des inscriptions aux activités

Les appels à l'API utilisant la forme simplifiée ?page=1 ne provoquent plus d'erreur : la pagination interprète correctement une valeur scalaire comme numéro de page.

Jusqu'à présent, la pagination attendait strictement le format JSON:API (page[number] et page[size]). Toute requête envoyant un paramètre page sous forme de valeur simple déclenchait une erreur de type et faisait échouer l'appel, obligeant les intégrateurs à adapter leur code ou à déboguer une réponse inattendue.

• Les paramètres page scalaires (ex. ?page=1) sont désormais traités comme le numéro de page
• Le format JSON:API (page[number] / page[size]) continue de fonctionner exactement comme avant, sans aucune modification nécessaire
• Plus d'erreurs inattendues lors de la pagination des listes retournées par l'API

Pourquoi c'est important : vos intégrations et scripts fonctionnent avec la syntaxe de pagination la plus courante, sans contournement ni temps perdu à diagnostiquer un appel qui échoue. 🚀

Vous pouvez désormais utiliser des emojis et tous les caractères spéciaux sur 4 octets dans les textes de vos modules, fiches d'intervenants et informations de leads, sans provoquer d'erreur d'enregistrement. 🎉

Jusqu'à présent, ces champs étaient stockés dans un encodage limité (utf8mb3) qui ne supportait pas les caractères sur 4 octets. Résultat : toute tentative d'enregistrer un emoji, certains idéogrammes ou symboles rares déclenchait une erreur et faisait perdre le contenu saisi. Les colonnes concernées ont été migrées vers l'encodage utf8mb4.

• Les textes des modules d'application acceptent désormais les emojis et caractères étendus
• Les profils d'intervenants (biographies, titres, descriptions) prennent en charge l'ensemble des caractères Unicode
• Les champs de texte liés aux leads ne renvoient plus d'erreur lors de l'enregistrement

Pourquoi c'est important : vos équipes marketing et contenu peuvent rédiger des textes engageants et modernes sans contourner les limitations techniques, et plus aucune saisie n'est perdue à cause d'un simple emoji.

L'envoi d'un e-mail de test depuis une campagne de notifications massives ne dépend plus du chargement complet de la liste de destinataires : le système récupère désormais un seul destinataire d'exemple, ce qui évite les erreurs sur les événements comptant un très grand nombre de participants.

Pourquoi c'est important : vous pouvez vérifier le rendu de vos e-mails avant l'envoi réel, quelle que soit la taille de votre audience, sans blocage ni message d'erreur à la dernière minute. ✅

• Chargement optimisé : la recherche du destinataire d'exemple est limitée à un seul enregistrement au lieu de parcourir toute la liste filtrée de participants, ce qui évite la saturation de la mémoire de tri de la base de données.
• Robustesse renforcée : si la récupération du destinataire d'exemple échoue malgré tout, l'envoi du test se poursuit sans interruption plutôt que de renvoyer une erreur.
• Gestion des erreurs améliorée dans l'envoi des notifications par e-mail, pour des messages plus clairs et une expérience plus fiable.

L'appel à la liste des villes d'une région inexistante ne provoque plus d'erreur serveur : l'API renvoie maintenant une réponse 404 explicite, accompagnée d'un message d'erreur traduit.

Pourquoi c'est important : une erreur 500 bloque une intégration et oblige vos équipes techniques à enquêter sans indice, alors qu'un 404 clair indique immédiatement que la région demandée n'existe pas — moins de temps perdu en débogage et des intégrations plus fiables.

• Correction de l'erreur serveur sur GET /api/v3/countries/:country_id/regions/:region_id/cities lorsque l'identifiant de région est invalide ou absent (par exemple la valeur d'exemple présente dans la documentation).
• Retour d'un statut 404 Not Found au lieu d'une erreur 500 inattendue.
• Message d'erreur désormais traduit dans l'ensemble des langues prises en charge (arabe, allemand, anglais, espagnol, français, etc.), pour une expérience cohérente quelle que soit la langue de l'intégration.
• Couverture de tests ajoutée afin de garantir la stabilité de ce comportement dans la durée. ✅

La règle limitant le nombre de sessions auxquelles un participant peut s'inscrire est désormais appliquée au niveau de la définition de l'atelier, et non plus uniquement session par session. Les inscriptions multiples sont donc bloquées de manière cohérente, quel que soit le canal utilisé — interface d'administration, site de l'événement ou API.

Pourquoi c'est important : vos quotas de places sont enfin respectés partout, ce qui évite les surréservations, les doublons à corriger à la main et les échanges pénibles avec les participants la veille de l'événement. 🎯

• Validation du nombre maximum de sessions déplacée au niveau de la définition de l'atelier
• Comportement identique entre l'interface et l'API, sans contournement possible
• Messages d'erreur clairs et traduits dans toutes les langues prises en charge (français, anglais, espagnol, allemand, arabe, etc.)
• Couverture de tests renforcée pour garantir la fiabilité de la règle dans la durée

Un nouvel endpoint de statistiques de sessions est désormais disponible dans l'API v4 : récupérez en une seule requête les chiffres clés de chaque session (inscriptions, capacité, participation) sans avoir à agréger les données vous-même.

Pourquoi c'est important : vos équipes peuvent alimenter leurs tableaux de bord, rapports et outils internes en temps réel, et repérer immédiatement les sessions complètes ou sous-remplies pour ajuster la programmation avant le jour J. ⏱️

• Nouvel endpoint de statistiques de sessions exposé dans l'API v4
• Données de session enrichies grâce à la mise à jour du sérialiseur d'ateliers
• Documentation OpenAPI / Swagger v4 mise à jour pour faciliter l'intégration
• Couverture de tests ajoutée pour garantir la fiabilité des résultats retournés

En cas de refus ou d'erreur lors du paiement, le participant voit désormais un message clair et traduit à l'écran, au lieu d'un échec silencieux.

Pourquoi c'est important : un participant qui comprend l'erreur peut corriger lui-même sa saisie et retenter le paiement dans la seconde — moins de tickets support pour vos équipes et davantage d'inscriptions finalisées.

• Affichage des messages d'erreur renvoyés par la passerelle directement dans le checkout
• Textes disponibles en plusieurs langues
• Levée d'une erreur explicite lorsque les identifiants de la passerelle sont absents ou mal configurés, pour un diagnostic immédiat côté organisateur

Les champs personnalisés de type texte peuvent désormais être soumis à une validation alphanumérique, afin que les données saisies par vos participants respectent le format attendu par la passerelle de paiement.

Pourquoi c'est important : les caractères spéciaux dans un nom, une adresse ou un numéro de document sont l'une des causes les plus fréquentes de rejet d'une transaction. En bloquant l'erreur au moment de la saisie, vous évitez les paiements échoués et les relances manuelles auprès des participants. ✅

• Validation appliquée uniquement aux champs de saisie texte, pour ne pas perturber les autres types de champs
• Messages d'erreur traduits dans toutes les langues prises en charge par la plateforme
• Configuration directement accessible depuis les champs personnalisés du type de participant

Le nouvel endpoint de check-in par lot de l'API v4 permet d'enregistrer plusieurs participants en une seule requête, au lieu d'un appel par personne.

Pour les événements à forte affluence, cela change tout : vos bornes d'accueil, lecteurs de badges et applications tierces peuvent désormais synchroniser les arrivées en masse, ce qui réduit drastiquement le nombre d'appels réseau et évite les files d'attente à l'entrée. 🚪

• Check-in par lot disponible sur l'endpoint des participants de l'API v4
• Traitement centralisé via un service dédié, avec un retour clair pour chaque participant du lot (succès ou motif d'échec)
• Messages et libellés traduits dans l'ensemble des langues prises en charge par la plateforme
• Idéal pour les intégrations hors ligne : les scans accumulés pendant une perte de connexion peuvent être renvoyés d'un seul coup une fois le réseau rétabli

Consultez la documentation de l'API v4 pour connaître le format de la requête et les codes de réponse.

Chaque facture générée par Eventtia reçoit désormais un numéro unique, même lorsque plusieurs paiements sont confirmés exactement au même moment.

Auparavant, lorsque plusieurs inscriptions ou paiements étaient traités simultanément sur un même événement, le compteur de facturation pouvait attribuer le même numéro à deux factures différentes. Ce type de doublon oblige les équipes finance à corriger manuellement les documents et peut poser problème lors des contrôles comptables ou fiscaux. 🧾

• La génération du numéro de facture est désormais sérialisée : l'incrément du compteur de l'événement est protégé par une transaction, garantissant qu'aucun autre processus ne puisse lire la même valeur.
• En cas de collision malgré tout (contrainte d'unicité sur événement + numéro), la création de la facture est automatiquement relancée avec le numéro suivant, sans erreur visible pour l'organisateur ni pour le participant.

Pourquoi c'est important : vos séquences de facturation restent continues et fiables, ce qui évite les corrections manuelles, les écarts de rapprochement comptable et les échanges inutiles avec vos participants.

La récupération des types de participants s'appuie désormais sur un gestionnaire de cache dédié, ce qui réduit le nombre de requêtes exécutées à chaque affichage ou soumission d'un formulaire d'inscription.

À chaque chargement de page d'inscription, la liste des types de participants de l'événement était interrogée à répétition. Avec la mise en cache, ces données sont servies instantanément, ce qui allège la charge sur la base de données et accélère l'affichage, en particulier lors des pics d'inscription.

• Nouveau gestionnaire de cache pour les types de participants
• Moins d'appels répétés à la base de données pendant le parcours d'inscription
• Temps de réponse plus stables lors des fortes affluences

Pourquoi c'est important : vos pages d'inscription restent rapides et réactives au moment où cela compte le plus — l'ouverture des inscriptions. ⚡

Les formulaires d'inscription publics ne renvoient plus d'erreur serveur lorsqu'un paramètre attendee_type erroné ou inexistant est présent dans l'URL.

Auparavant, un lien mal copié, un paramètre modifié manuellement ou un identifiant appartenant à un autre événement pouvait provoquer une erreur 500 au moment d'enregistrer un brouillon d'inscription : le participant était bloqué et perdait sa saisie. Désormais, le type de participant n'est assigné que s'il est validé comme appartenant réellement à l'événement ; dans le cas contraire, le paramètre est simplement ignoré et l'inscription se poursuit avec le type par défaut.

• Validation systématique de l'identifiant du type de participant avant son assignation
• Les paramètres hors périmètre ou hors plage sont ignorés au lieu de faire échouer la requête
• Enregistrement des brouillons d'inscription désormais fiable, même avec des liens altérés

Pourquoi c'est important : moins d'inscriptions interrompues, c'est moins d'abandons à l'entrée de votre tunnel d'enregistrement et moins de tickets de support à traiter pour vos équipes. 🎯

Les participants dont le prénom ou le nom était vide rencontraient une erreur au moment d'afficher la page de confirmation d'inscription. Ce n'est plus le cas : le message de succès s'affiche désormais correctement dans tous les cas.

Pourquoi c'est important : une inscription interrompue à la dernière étape est une inscription perdue. Vos participants terminent maintenant leur parcours sans blocage, et vos équipes n'ont plus à traiter les demandes de support liées à ces échecs.

• Correction du rendu des balises dynamiques (wildcards) utilisées dans le message de confirmation lorsque le prénom ou le nom du participant est vide
• Plus d'erreur serveur sur le récapitulatif d'inscription pour les profils incomplets
• Comportement validé par de nouveaux tests automatisés afin d'éviter toute régression 🛡️

Le téléchargement d'un export Excel dont le fichier n'a pas encore été généré affiche désormais une page 404 claire au lieu de provoquer une erreur applicative.

Auparavant, si un organisateur cliquait sur le lien de téléchargement avant que le traitement de l'export soit terminé (ou si le fichier n'avait jamais été enregistré), la plateforme tentait d'envoyer un fichier inexistant et renvoyait une erreur technique. Le comportement est maintenant maîtrisé et cohérent avec le reste de l'application.

• Fin des erreurs techniques lors du téléchargement d'un export sans fichier associé
• Réponse 404 standard affichée à la place, plus facile à comprendre pour les organisateurs
• Comportement couvert par des tests automatisés pour éviter toute régression

Pourquoi c'est important : vos équipes ne perdent plus de temps à se demander si la plateforme est en panne — elles savent simplement que l'export n'est pas encore prêt et peuvent réessayer quelques instants plus tard. 📄

Les salles Zoom associées à vos ateliers conservent désormais correctement leurs informations lorsqu'elles sont modifiées depuis les paramètres avancés d'une définition d'atelier. Auparavant, certaines modifications n'étaient pas appliquées comme prévu, ce qui pouvait entraîner des liens de connexion incorrects ou obsolètes pour les participants.

Pourquoi c'est important : vos organisateurs n'ont plus besoin de vérifier manuellement chaque salle avant le début d'une session, et vos participants rejoignent le bon espace virtuel du premier coup — moins de support de dernière minute, moins de sessions démarrées en retard.

• Correction de la mise à jour des salles Zoom modifiées depuis les paramètres avancés des ateliers
• Affichage fiabilisé des informations de salle dans l'interface de configuration

Les descriptions des endpoints et des champs de l'API v4 ont été réécrites et enrichies pour être plus claires, plus complètes et directement exploitables — aussi bien par les développeurs que par les agents et outils automatisés (MCP) qui consomment notre spécification.

Pourquoi c'est important : une documentation explicite réduit les allers-retours avec le support et accélère vos intégrations, car il n'est plus nécessaire de deviner à quoi sert un champ ou quelles valeurs il accepte.

• Descriptions améliorées pour les participants (attendees), les types de participants (attendee_types) et leurs champs personnalisés
• Descriptions améliorées pour les événements (events) et les points de contrôle (checkpoints)
• Définitions plus précises dans la spécification OpenAPI v4, optimisées pour une consommation par les assistants et intégrations basés sur MCP 🤖

Les types déclarés dans la spécification OpenAPI de l'API v4 ne correspondaient pas toujours aux données réellement renvoyées : c'est désormais corrigé pour les champs availability, payment_status et total_amount.

Pourquoi c'est important : vos intégrations générées automatiquement à partir du schéma (clients SDK, validateurs, connecteurs no-code) ne casseront plus à cause d'un type inattendu, ce qui vous évite des heures de débogage sur des erreurs de parsing difficiles à diagnostiquer.

• Correction du type du champ availability
• Correction du type du champ payment_status
• Correction du type du champ total_amount
• Mise à jour du fichier openapi/v4/swagger.json et des tests associés pour garantir que la documentation reste alignée avec le comportement réel de l'API ✅

Les rapports d'ateliers exportés vers Excel incluent désormais une colonne Statut, qui indique directement l'état de chaque atelier sans avoir à revenir dans la plateforme pour le vérifier un par un.

Pourquoi c'est important : lorsque vous préparez la logistique d'un événement ou que vous partagez un rapport avec votre équipe, savoir immédiatement quels ateliers sont actifs, annulés ou en attente évite les allers-retours, les erreurs de planification et les relances inutiles. 📊

• Nouvelle colonne Statut ajoutée à l'export Excel des ateliers
• Libellés traduits dans toutes les langues prises en charge par la plateforme (français, anglais, espagnol, allemand, catalan, arabe, etc.)
• Aucune action requise de votre part : la colonne apparaît automatiquement dans vos prochains exports

Les lieux de rendez-vous d'affaires acceptent désormais pleinement les caractères accentués et spéciaux (é, ü, ř, ñ, caractères tchèques, etc.) sans provoquer d'erreur lors de leur création ou de leur recherche.

Auparavant, les tables de lieux et de paramètres de networking étaient stockées dans un encodage limité (latin1). Dès qu'un nom de salle ou de table contenait un caractère hors de ce jeu, la comparaison échouait avec une erreur de collation et empêchait tout simplement l'ajout du lieu. Concrètement, un organisateur d'un événement à Prague, Bogotá ou Montréal ne pouvait pas nommer ses espaces dans sa propre langue. 🌍

• Migration des tables de lieux de rendez-vous d'affaires vers l'encodage utf8mb4
• Migration des paramètres de rendez-vous d'affaires vers le même encodage
• Fin des erreurs de type « Illegal mix of collations » lors de l'ajout ou de la recherche d'un lieu

Pourquoi c'est important : vos espaces de networking portent enfin le nom exact que vos participants verront sur place, sans contournement ni caractères de remplacement, quelle que soit la langue de votre événement.

Correction d'un problème qui affectait la duplication des types de participants : les réglages liés aux sessions et ateliers n'étaient pas toujours repris correctement sur le nouveau type, ce qui pouvait entraîner des règles d'accès ou d'inscription différentes de celles attendues.

Résultat : ce que vous voyez sur le type d'origine est désormais exactement ce que vous obtenez sur sa copie, sans vérification manuelle à faire après coup.

• Les paramètres d'ateliers et de sessions sont fidèlement copiés lors de la duplication
• Fiabilisation générale de la copie des paramètres entre types de participants

La duplication d'un type de participant (ou d'un événement entier) copie désormais l'intégralité de ses paramètres, et plus seulement ses informations de base. Vous repartez d'une configuration identique, prête à l'emploi, dès la création.

Pour les équipes qui organisent des événements récurrents ou plusieurs éditions d'un même format, cela supprime des dizaines de réglages à repositionner manuellement — et autant d'occasions d'oublier une option critique le jour J. 🎯

• Tous les paramètres d'un type de participant sont repris lors de la duplication d'un type existant
• Les paramètres sont également conservés lors du clonage complet d'un événement
• Le formulaire de création d'un type de participant indique plus clairement ce qui sera copié depuis le type source

L'export Excel du rapport récapitulatif des réunions (Meetings Summary Report) gère désormais correctement les erreurs : en cas de problème lors de la génération, le message est clairement affiché dans la fenêtre d'export au lieu de laisser le processus bloqué ou sans réponse.

Pourquoi c'est important : vous savez immédiatement si votre export a réussi ou échoué, sans devoir attendre ni relancer plusieurs fois la génération pour comprendre ce qui s'est passé. ⏱️

• Correction de la gestion des erreurs lors de la génération du rapport récapitulatif des réunions
• Retour d'information plus clair dans la fenêtre modale d'export
• Traitement plus robuste des exports Excel côté rapports de networking

L'API V4 expose désormais vos points de contrôle (checkpoints) : vous pouvez récupérer la liste complète des points de contrôle d'un événement ou consulter le détail de l'un d'entre eux, directement depuis vos propres outils.

Pourquoi c'est important : vos équipes techniques peuvent synchroniser les données d'accès et de scan avec leurs systèmes internes (CRM, outils de reporting, applications d'accueil) sans passer par des exports manuels, ce qui réduit les erreurs de saisie et accélère la mise en place de vos contrôles d'accès sur site.

• Nouvel endpoint index : récupération de la liste des points de contrôle disponibles pour un événement
• Nouvel endpoint show : consultation du détail d'un point de contrôle spécifique
• Endpoints alignés sur les conventions de l'API V4, pour une intégration cohérente avec le reste de vos appels 🔌

Un nouveau filtre « imprimé » est désormais disponible sur les participants via l'API, ce qui vous permet de distinguer instantanément ceux dont le badge a déjà été imprimé de ceux qui restent à traiter.

Le jour J, savoir qui a récupéré son badge évite les doublons d'impression, réduit les files d'attente à l'accueil et vous donne une vision fiable de l'avancement du check-in, sans export ni recoupement manuel. 🎟️

• Nouveau filtre sur le statut d'impression du badge dans l'endpoint des participants de l'API v4
• Filtre également pris en charge sur l'API v3 pour assurer la compatibilité avec vos intégrations existantes
• Documentation Swagger mise à jour afin que le nouveau paramètre soit immédiatement exploitable par vos équipes techniques
• Combinable avec vos filtres actuels pour créer des listes ciblées (par exemple, les participants inscrits mais dont le badge n'a pas encore été imprimé)

Lorsque vous utilisez l'option Renvoyer sur un e-mail massif, vous êtes maintenant redirigé directement vers la page d'édition du message dupliqué, prêt à être ajusté et envoyé.

Auparavant, la duplication s'effectuait correctement en arrière-plan, mais la redirection ne pointait pas vers la copie créée : vous deviez revenir à la liste des messages et retrouver le duplicata manuellement avant de pouvoir le modifier.

Pourquoi c'est important : vos communications partent plus vite, sans étapes inutiles ni risque de modifier ou de renvoyer le mauvais message. ✉️

• Correction de la redirection après la duplication d'un e-mail massif
• Accès immédiat à l'édition de la copie créée depuis l'action « Renvoyer »

La suppression de la dernière session d'un atelier renvoie désormais un message d'erreur explicite au lieu d'une erreur serveur inattendue. Vous savez immédiatement pourquoi l'action est bloquée et pouvez poursuivre votre configuration sans interruption.

Auparavant, tenter de supprimer la dernière session restante d'un atelier provoquait une erreur 500 sur le parcours de suppression de session (API v4), sans aucune indication sur la cause du problème. L'organisateur se retrouvait bloqué, sans savoir si la session avait été supprimée ou non.

• L'API renvoie maintenant un statut 422 accompagné d'un message d'erreur traduit et lisible lorsque la dernière session ne peut pas être archivée
• Fin des erreurs serveur inattendues sur le parcours de suppression de session
• Retour d'information immédiat et compréhensible pour les organisateurs qui gèrent l'agenda de leurs ateliers

👉 Moins de tickets support, moins de doutes sur l'état réel de vos sessions, et une gestion d'agenda plus sereine.

Accéder à un type de participant qui n'existe plus — parce qu'il a été archivé, supprimé ou qu'il appartient à un autre événement — provoquait une page d'erreur bloquante. Vous êtes désormais simplement redirigé vers la liste des types de participants, accompagné d'un message clair indiquant que l'élément est introuvable.

• Les pages d'édition et de groupes d'un type de participant gèrent maintenant correctement les identifiants inconnus, archivés ou provenant d'un autre événement
• Redirection automatique vers la liste avec le message « élément non trouvé » au lieu d'une erreur serveur

Pourquoi c'est important : un lien obsolète, un favori enregistré ou un identifiant modifié dans l'URL ne vous coupe plus dans votre travail — vous restez dans l'application et pouvez continuer votre configuration sans avoir à recharger ni à contacter le support. ✅

Le logo de votre événement s'affiche désormais correctement dans l'agenda de networking des participants, sans interrompre le chargement de la page.

Cette correction évite qu'une page d'agenda vide ou en erreur soit présentée à vos participants au moment où ils consultent leurs rendez-vous : votre image de marque reste visible tout au long du parcours de networking. 🎯

• Résolution de l'URL du logo via le CDN avant son affichage, alignée sur le comportement déjà en place dans l'agenda des exposants
• Correction de l'erreur d'affichage provoquée par le traitement de la pièce jointe dans la nouvelle version du framework
• Rendu du logo désormais cohérent entre les agendas participants et exposants

La recherche lors de l'attribution des lieux accepte maintenant sans erreur les noms d'entreprises, de contacts et de lieux contenant des caractères spéciaux, comme les apostrophes.

Auparavant, rechercher une société telle que « L'Atelier » ou un contact comme « O'Brien » provoquait une erreur serveur (500) et interrompait complètement le processus d'attribution des lieux. Les filtres de recherche sont désormais correctement sécurisés, ce qui garantit des résultats fiables quel que soit le nom saisi.

• Correction des filtres de recherche par entreprise, nom de contact et lieu dans le module d'attribution des lieux
• Fin des erreurs serveur causées par les apostrophes et autres caractères spéciaux
• Recherche plus sûre et plus stable grâce à des requêtes correctement paramétrées 🔒

Pourquoi c'est important : les organisateurs qui gèrent des rendez-vous d'affaires n'ont plus à contourner ce blocage ni à modifier les noms des participants pour terminer l'attribution des lieux, ce qui évite des pertes de temps et des erreurs de planification le jour J.

La mise à jour d'un participant depuis l'espace exposant ne provoque plus d'erreur serveur lorsque le participant n'existe plus. Un message clair indiquant que le participant est introuvable s'affiche désormais à la place.

Auparavant, si un participant avait été supprimé, archivé ou rattaché à un autre événement, la tentative de mise à jour se terminait par une erreur 500 et l'exposant perdait le contexte de son action, sans comprendre l'origine du problème.

• Vérification de l'existence du participant avant toute tentative d'enregistrement ou de réservation
• Redirection accompagnée d'une alerte explicite « participant introuvable » au lieu d'une page d'erreur

Pourquoi c'est important : les exposants gardent la maîtrise de leurs listes de participants et savent immédiatement quoi faire, ce qui évite des tickets de support et des relances inutiles auprès de vos équipes. 🎯

La recherche par mots-clés dans les listes de diffusion renvoyait une erreur serveur au lieu de résultats : elle est désormais entièrement corrigée et retourne les contacts attendus dès la première tentative.

En cause : les paramètres de recherche n'étaient pas correctement transmis à la requête, ce qui provoquait une erreur 500 côté base de données à chaque tentative de filtrage par mots-clés. La requête est maintenant construite avec des paramètres liés (bind), ce qui la rend à la fois fiable et plus sûre.

• Correction de l'erreur serveur lors d'une recherche par mots-clés dans une liste de diffusion
• Résultats de recherche cohérents et complets sur les enregistrements de la liste
• Requête sécurisée grâce à l'utilisation de paramètres liés
• Couverture de tests ajoutée pour éviter toute régression future

Pourquoi c'est important : retrouver un contact dans une liste de diffusion volumineuse ne nécessite plus de parcourir les pages manuellement — vous gagnez un temps précieux avant chaque envoi de campagne. ✉️

L'affichage dans le navigateur d'un message de campagne dont l'historique n'existe plus renvoie désormais une réponse 404 (page introuvable) claire, au lieu d'une erreur serveur 500.

Auparavant, lorsqu'un destinataire cliquait sur le lien « Voir ce message dans mon navigateur » d'un envoi massif dont le journal avait été supprimé ou n'avait jamais été généré, l'application tentait de charger une vue inexistante et échouait brutalement. Vos destinataires obtiennent maintenant un comportement prévisible et vos équipes ne voient plus ces erreurs polluer les rapports de suivi.

• Réponse 404 explicite lorsqu'un message ou son journal d'envoi est introuvable
• Fin des erreurs 500 sur l'aperçu navigateur des envois massifs
• Moins de bruit dans la supervision technique : les vraies anomalies restent visibles 🔍

La modification d'un participant qui n'existe plus — ou qui appartient à un autre événement — renvoie désormais une réponse claire de refus d'accès au lieu de provoquer une erreur inattendue de l'application.

Auparavant, lorsque l'identifiant du participant était obsolète (participant supprimé, lien mis en cache, onglet resté ouvert trop longtemps) ou provenait d'un autre événement, le système tentait de lire le type de participant sur un enregistrement inexistant, ce qui interrompait l'opération de façon imprévisible.

• Les autorisations sont maintenant vérifiées avant toute lecture des données du participant
• Les identifiants obsolètes ou provenant d'un autre événement retournent un refus d'accès (403) cohérent
• Couverture de tests ajoutée pour garantir ce comportement dans le temps

Pourquoi c'est important : vos équipes ne rencontrent plus d'erreurs déroutantes lors de la gestion des participants, et les données d'un événement restent strictement isolées de celles des autres. 🔒