Quels champs mettre dans un formulaire d’inscription à un événement ?
Un formulaire d’inscription doit recueillir les informations nécessaires à une tâche précise, puis s’arrêter. Une liste universelle de champs « essentiels » peut collecter des données inutilisées. Pour un atelier gratuit, une adresse de réponse peut être nécessaire, mais pas un numéro de téléphone. Reliez chaque question à une action, un responsable et une durée de conservation.
La rédaction de Boletolibre
Publié
Définir le travail du formulaire
Énumérez les tâches : réserver une place, confirmer, identifier à l’entrée, prévoir un repas, organiser une aide ou facturer. Pour chaque réponse, nommez la personne qui l’utilisera. Sans action, supprimez la question; si elle ne sert que plus tard, demandez-la plus tard.
Distinguez demande, place confirmée et paiement. Une demande examinée manuellement n’assure pas une place. Si une autre plateforme inscrit les participants, votre site peut n’avoir besoin que d’un lien clair. Le W3C conseille de ne demander que ce qui sert au processus. Inventoriez champ, objectif, statut, destinataire et date d’effacement.[1]
Choisir quelques champs de base
Demandez une adresse courriel si les décisions y sont envoyées. Pour l’identité, recueillez seulement le nom nécessaire au contrôle ou au badge; un nom légal n’est pas automatiquement requis. Le choix de billet ou de séance ne sert que s’il existe des options. Un téléphone suppose un vrai besoin d’appel ou de message.
Le nom d’entreprise peut aider une facture professionnelle, pas tous les ateliers. Adresse postale, naissance, poste, réseau social et taille d’entreprise ne doivent pas être copiés d’un modèle. Le tableau aide à décider; il ne remplace pas une analyse juridique.
| Champ possible | Décision de départ | Question utile |
|---|---|---|
| Courriel de réponse | Obligatoire si les avis y arrivent | Qui confirme et informe ? |
| Nom à l’entrée | Précision nécessaire seulement | Qui vérifie la personne ? |
| Billet ou séance | Conditionnel aux options | Quelle affectation change ? |
| Téléphone | Omettre sans usage défini | Qui appelle et pourquoi ? |
| Repas ou accessibilité | Facultatif ou conditionnel | Qui agit et peut le lire ? |
| Employeur ou réseau | Souvent omettre | Quelle tâche en dépend ? |
Poser les questions supplémentaires au bon moment
Une question conditionnelle suit un choix : un repas commandé peut nécessiter une préférence alimentaire; une participation en ligne n’exige pas de trajet. Proposez un contact privé pour les adaptations d’accessibilité sans demander systématiquement un diagnostic. Voyez si l’aide peut être organisée sans détails sensibles dans la liste générale.
Facultatif veut dire que l’inscription aboutit sans réponse. Conditionnel veut dire que seule la branche pertinente affiche la question. Expliquez l’usage et limitez l’accès. Le personnel d’entrée n’a pas besoin des notes de restauration.
Séparer le paiement du formulaire ordinaire
Pour un événement payant, affichez le choix et le prix avant de passer à un prestataire de paiement adapté. Évitez tout champ libre pour numéro de carte ou code de contrôle. Le prestataire gère ses données et renvoie réussite, échec ou annulation. Ouvrir la caisse n’est pas payer.
Séparez inscription, paiement et admission. Dites quand une place est retenue et où demander de l’aide. Les données de facturation ne servent que si une transaction ou facture le nécessite. Un événement gratuit n’a pas de champs de paiement. Les règles précises dépendent du service et du pays.
Distinguer conditions, vie privée et publicité
Présentez les conditions applicables et l’information sur les données. Ne rassemblez pas conditions, avis et publicité dans une case vague. Les avis pratiques diffèrent du marketing. Une autorisation publicitaire requise par les règles applicables doit être distincte et non présélectionnée.
L’article 5 du RGPD de l’UE traite finalité, minimisation et limitation de conservation; l’autorité britannique explique un principe comparable chez elle. Ces textes ne donnent ni liste universelle de champs ni obligation générale de fonder chaque inscription sur le consentement. Vérifiez les règles applicables.[5][6]
Rendre chaque champ utilisable
Donnez une étiquette visible et précise à chaque champ. Indiquez en mots ce qui est obligatoire ou facultatif et le format attendu. Un simple texte indicatif dans le champ ne remplace pas l’étiquette. Suivez le parcours de la personne plutôt que la structure de votre base.[2][3]
Expliquez comment corriger une erreur sans effacer le reste. Testez clavier, téléphone, branches conditionnelles et passage au paiement. Les ressources W3C couvrent étiquettes, instructions et validation sans certifier automatiquement la conformité juridique.[4]
Exemple : un atelier de quartier fictif
L’atelier fictif de Cedar Street est gratuit, limité à 30 places avec examen manuel. Les réponses partent par courriel et un nom d’usage sert à l’entrée. Le formulaire demande ces deux éléments; une séance seulement si plusieurs ont lieu en parallèle. L’envoi est une demande, pas une admission garantie.
Il propose du thé sans repas : pas de préférences alimentaires. Un contact privé permet de demander un aménagement sans livrer d’informations médicales dans le formulaire. Téléphone, employeur, naissance, adresse et réseaux sociaux sont omis. Un futur paiement demanderait un autre parcours. L’exemple n’annonce aucune fonction Boletolibre.
| Décision | À noter |
|---|---|
| Tâche | Que fait-on avec la réponse ? |
| Statut | Obligatoire, facultatif, conditionnel, omis ? |
| Responsable | Qui voit et utilise la donnée ? |
| Moment | Maintenant, plus tard, jamais ? |
| Conservation | Quand supprimer donnée et exports ? |
Revoir les accès et la conservation ensuite
Avant l’ouverture, essayez chaque branche. Ne donnez aux équipes que les exports utiles : à l’entrée, nom et statut suffisent souvent, pas l’historique des courriels ni les notes privées. Nommez une personne pour les corrections.
Après l’événement, revoyez chaque champ et sa durée légitime. Supprimez les exports superflus selon les obligations applicables et fermez les accès temporaires. Le prochain formulaire doit garder les bonnes décisions, pas toutes les anciennes questions.
Sources et lectures complémentaires
- WAI : ne demander que les données utilesW3C WAI · Consulté
- WAI : étiquettes visibles et associéesW3C WAI · Consulté
- WAI : indiquer obligatoire et facultatifW3C WAI · Consulté
- WAI : validation utileW3C WAI · Consulté
- Article 5 RGPD dans l’UEEUR-Lex · Consulté
- Minimisation selon l’autorité britanniqueUK Information Commissioner's Office · Consulté