Les champs de localisation des formulaires et des pages de lieux prennent désormais en charge la recherche : il suffit de commencer à taper pour filtrer la liste des pays et des villes, au lieu de faire défiler des centaines d'options.

Pourquoi c'est important : vos participants remplissent leurs informations plus rapidement et avec moins d'erreurs de saisie, ce qui réduit les abandons en cours d'inscription. ✨

• Recherche dynamique dans le sélecteur de localisation des formulaires
• Recherche dynamique dans le sélecteur de villes
• Chargement optimisé des listes pour un affichage plus fluide, même avec un grand volume de données

L'accès à un groupe de participants inexistant affiche désormais une page 404 claire au lieu de provoquer une erreur d'application.

Jusqu'à présent, lorsqu'un organisateur tentait d'éditer un groupe de participants qui n'existait pas, qui appartenait à un autre événement ou qui ne contenait aucun participant pouvant le rejoindre, la page renvoyait une erreur technique inattendue. Le comportement est maintenant aligné sur celui du reste de la plateforme (chargement des événements et pages publiques des groupes) : une réponse 404 standard est renvoyée.

Pourquoi c'est important : vous savez immédiatement que le lien ou l'identifiant utilisé n'est plus valide, au lieu de perdre du temps à diagnostiquer une erreur système — moins de confusion, moins de tickets au support.

• Réponse 404 cohérente lorsqu'un groupe de participants est introuvable ou inaccessible
• Même comportement pour les groupes appartenant à un autre événement ou sans participants éligibles
• Couverture de tests renforcée pour éviter toute régression

La page d'édition des participants exposants reste désormais accessible même lorsqu'aucune réservation de stand n'est associée au compte : au lieu d'une erreur 500, l'application renvoie une réponse d'accès contrôlée (403) et évite tout plantage.

Auparavant, si l'identifiant de réservation était absent ou appartenait à un autre compte, le chargement de l'événement échouait et bloquait complètement l'exposant dans la gestion de ses participants. Ce correctif supprime ce point de blocage et garantit un comportement prévisible pour vos exposants.

• Gestion sécurisée des réservations de stand manquantes ou appartenant à un autre compte
• Remplacement de l'erreur 500 par une réponse d'autorisation claire
• Couverture de tests renforcée pour éviter toute régression sur ce parcours

Les liens de site web des sponsors ne sont plus limités en longueur : vous pouvez désormais enregistrer des URL avec paramètres de suivi (UTM, campagnes, redirections) sans que le formulaire échoue.

Auparavant, toute adresse dépassant 255 caractères provoquait une erreur au moment de l'enregistrement, et le travail saisi dans le formulaire était perdu. Concrètement, vos équipes marketing peuvent suivre précisément le trafic généré pour chaque partenaire, sans devoir raccourcir ou bricoler les liens. 🔗

• Le champ site web des sponsors accepte désormais des URL de grande longueur
• Ajout d'une validation du format de l'adresse, avec un message d'erreur clair directement dans le formulaire
• Messages d'erreur traduits dans toutes les langues prises en charge (français, anglais, espagnol, allemand, arabe, etc.)

La page de détail d'un message groupé ne se chargeait plus lorsqu'aucun filtre d'audience ne lui était associé. Ce problème est corrigé : la portée estimée affiche désormais simplement 0 destinataire au lieu de provoquer une erreur.

Pourquoi c'est important : vous pouvez de nouveau consulter et modifier tous vos messages sans interruption, y compris ceux créés en brouillon avant d'avoir défini une audience. 🎯

• La portée estimée renvoie 0 lorsque le message n'a aucun filtre d'audience sélectionné
• Plus d'erreur serveur à l'ouverture de la page de détail d'un message groupé

L'envoi d'un e-mail de test depuis le module de messagerie massive n'échoue désormais plus lorsque le code QR du participant d'exemple n'est pas disponible : la pièce jointe est simplement ignorée et l'e-mail part normalement.

Auparavant, le système tentait de lire le fichier du code QR sans vérifier son existence. Comme les participants en ligne ne génèrent pas de code QR et que le dossier temporaire est régulièrement nettoyé par la tâche de maintenance, l'envoi se soldait par une erreur serveur accompagnée d'un message d'erreur illisible — vous obligeant à relancer l'opération sans comprendre la cause.

Pourquoi c'est important : vous pouvez prévisualiser et valider vos campagnes d'e-mails en toute confiance, à tout moment et quel que soit le type de participant, sans blocage inattendu avant un envoi en masse. ✅

• Vérification de la présence du fichier de code QR avant de l'attacher à l'e-mail de test
• Plus d'erreur 500 ni de message d'erreur technique lors de l'envoi d'un e-mail de test
• Comportement fiable pour les participants en ligne comme pour les participants sur site

L'éditeur d'emails groupés affiche désormais un message d'accès refusé clair au lieu de planter lorsque l'événement associé n'est plus disponible.

Auparavant, si vous tentiez d'ouvrir l'éditeur d'emails groupés pour un événement archivé ou pour un événement n'appartenant pas à votre compte, la page retournait une erreur serveur inattendue. L'application tente maintenant de récupérer l'événement avant toute vérification et renvoie une réponse d'accès refusé (403) propre lorsqu'il est introuvable.

• Correction de l'erreur serveur survenant à l'ouverture de l'éditeur d'emails groupés pour un événement archivé ou inaccessible
• Message d'accès refusé explicite à la place d'une page d'erreur

Pourquoi c'est important : vos équipes marketing ne perdent plus de temps à diagnostiquer une page cassée et comprennent immédiatement pourquoi un événement n'est pas accessible. ✅

Les paramètres d'événement vérifient maintenant la cohérence de vos réglages au moment où vous les modifiez, et vous signalent immédiatement toute configuration problématique — par exemple une date de fin d'inscription incompatible avec les dates de l'événement.

Pourquoi c'est important : vous détectez les erreurs de configuration avant qu'elles n'impactent vos participants, plutôt que de les découvrir après coup via des inscriptions bloquées ou des demandes au support. ✅

• Nouvelles validations appliquées lors de la modification du formulaire d'inscription et des paramètres de l'événement.
• Messages d'avertissement affichés directement dans l'écran de configuration de l'événement.
• Libellés disponibles dans l'ensemble des langues prises en charge par la plateforme.

La date de fin d'un événement est désormais validée automatiquement au moment de l'enregistrement : impossible de créer ou de modifier un événement dont la date de fin précède la date de début.

Pourquoi c'est important : une date incohérente se propage partout — inscriptions, agendas, communications et rapports. Cette vérification en amont évite des corrections manuelles coûteuses et des messages erronés envoyés à vos participants.

• Nouvelle règle de validation sur la date de fin de l'événement
• Message d'erreur explicite affiché directement dans le formulaire
• Traductions disponibles dans toutes les langues prises en charge (français, anglais, espagnol, allemand, arabe, etc.) 🌍

La gestion de la date de fin d'inscription a été corrigée : la date limite que vous définissez est désormais appliquée correctement, sans messages d'erreur en double et sans blocage inattendu des inscriptions en brouillon. 🗓️

Pourquoi c'est important : vous gardez la maîtrise totale de votre fenêtre d'inscription, sans perdre d'inscriptions légitimes ni devoir accompagner des participants confrontés à des erreurs qu'ils n'auraient jamais dû voir.

• Correction de la double validation qui générait des messages d'erreur redondants lorsqu'un participant s'inscrivait à l'approche de la date de clôture.
• Les inscriptions en brouillon ne sont plus bloquées par la date de fin d'inscription : les inscriptions incomplètes ou en cours peuvent être enregistrées et finalisées sans friction.
• Messages d'erreur retravaillés et traduits dans toutes les langues disponibles (FR, EN, ES, DE, AR…) pour être compréhensibles par vos participants.

La page de confirmation affichée à la fin d'une inscription de groupe ne génère plus d'erreur 500 lorsqu'aucun participant confirmé n'est encore associé au groupe.

Auparavant, le message de succès tentait d'afficher les informations du dernier participant non brouillon du groupe. Si ce participant était absent — un cas qui survient notamment lorsque toutes les inscriptions du groupe sont encore à l'état de brouillon — l'affichage échouait et l'organisateur comme l'inscrit se retrouvaient face à une page d'erreur, juste après avoir complété le formulaire.

• Le récapitulatif d'inscription de groupe s'affiche désormais correctement, même en l'absence de participant confirmé
• Le message de succès est simplement omis plutôt que de faire échouer toute la page
• Couverture de tests ajoutée pour éviter toute régression sur ce scénario

Pourquoi c'est important : le dernier écran du parcours d'inscription est celui qui rassure vos participants. En supprimant cette erreur, vous évitez les abandons de dernière minute et les tickets de support liés à des inscriptions pourtant bien enregistrées. ✅

L'export Excel du rapport « Participants par session » identifie désormais correctement l'inscrit principal (primary registrant) de chaque inscription de groupe.

Auparavant, cette information pouvait être attribuée à la mauvaise personne ou rester vide dans le fichier exporté, ce qui faussait l'analyse de la participation aux sessions et obligeait les organisateurs à recouper manuellement les données avant de les partager.

• Correction de la colonne inscrit principal dans le processus d'export Excel du rapport des sessions
• Les inscriptions liées à un même groupe sont désormais rattachées au bon contact principal
• Les rapports générés peuvent être exploités directement, sans retraitement manuel ⏱️

Les paiements par carte via Stripe se finalisent désormais correctement, y compris lorsque plusieurs sessions de paiement sont ouvertes en parallèle pour un même participant.

Auparavant, un participant qui relançait son paiement, ouvrait un second onglet ou revenait en arrière dans le tunnel d'inscription pouvait générer plusieurs sessions Stripe concurrentes. Résultat : des transactions bloquées en attente, des statuts de paiement incohérents et des inscriptions non confirmées malgré un débit réussi. C'est précisément ce que ces corrections éliminent.

• Gestion fiabilisée des sessions Stripe multiples : seule la session pertinente est prise en compte et confirmée
• Statuts de paiement synchronisés de bout en bout entre Stripe et Eventtia, pour éviter les inscriptions "fantômes"
• Traitement renforcé des retours de paiement (succès, échec, abandon) afin d'éviter les doublons de transaction

Pourquoi c'est important : moins de paiements en échec signifie moins de tickets de support, moins de réconciliations manuelles pour vos équipes finance et, surtout, des participants qui finalisent leur inscription du premier coup. 💳

Chaque participant ne reçoit désormais qu'une seule et unique facture, même en cas d'inscriptions simultanées ou de clics répétés sur le bouton de paiement. La génération des factures est maintenant sérialisée et protégée au niveau de la base de données, ce qui élimine les doublons à la source.

Pourquoi c'est important : plus besoin de traquer et d'annuler manuellement des factures en double avant de clôturer votre comptabilité — vos participants reçoivent le bon document du premier coup, et vos rapports de revenus reflètent la réalité. 🎯

• Génération des factures sérialisée par participant afin d'éviter toute création concurrente
• Ajout d'un index sur l'identifiant unique (uuid) des factures, garantissant l'unicité et accélérant la recherche de factures
• Couverture de tests renforcée pour prévenir toute régression sur ce scénario

Les libellés et messages liés aux paiements sont désormais traduits et harmonisés dans l'ensemble des langues prises en charge, dont l'arabe, le japonais, le coréen et le néerlandais.

Vos participants internationaux comprennent immédiatement l'état de leur transaction — confirmation, échec ou action requise — sans retomber sur un message en anglais au moment le plus sensible du parcours d'inscription.

• Traductions complétées et uniformisées pour les statuts et messages de paiement
• Terminologie cohérente entre le tunnel d'inscription et les confirmations envoyées aux participants

Pourquoi c'est important : un message de paiement incompris est une inscription abandonnée. Une communication claire dans la langue du participant réduit les abandons en fin de parcours et les demandes d'assistance adressées à vos équipes. 🌍

La connexion via SSO ne tombe plus en erreur lorsqu'un paramètre de langue invalide est présent dans l'URL : les langues non prises en charge sont désormais ignorées et l'utilisateur est redirigé vers sa langue préférée.

Auparavant, toute valeur inattendue transmise dans le paramètre locale (par exemple des chaînes générées par des scanners ou des liens malformés) était appliquée directement, ce qui provoquait une erreur 500 sur /users/sso et bloquait complètement l'accès à l'événement. Vos participants arrivent maintenant toujours sur une page fonctionnelle, même lorsque le lien de connexion a été altéré en chemin.

• Validation des langues reçues en paramètre : seules les langues réellement disponibles sont acceptées
• Retour automatique à la langue préférée de l'utilisateur lorsque la valeur est invalide
• Plus d'interruption du parcours de connexion SSO, et moins de tickets de support liés à des liens cassés 🎯

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 ✅