> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/guides-enrolment/fr/inscription/enrolment-form/validation-rules.md).
# Règles de validation
Les règles de validation protègent la qualité des données au moment de la capture. Elles empêchent les valeurs incomplètes ou mal formatées d’entrer dans les profils clients et les systèmes en aval.
Choisissez les règles en fonction de l’objectif de chaque champ. Une validation stricte est utile pour les identifiants. Les champs d’enrichissement facultatifs doivent rester faciles à compléter.
Exemples concrets
* Un programme de fidélité exige une adresse e-mail et vérifie son format avant l’inscription.
* Un formulaire de billetterie limite une référence de réservation à la longueur de caractères attendue.
* Un formulaire d’adhésion compare l’e-mail de confirmation avec le champ e-mail d’origine.
### Comment fonctionne la validation
La validation est configurée au niveau de chaque champ individuel. Chaque règle vérifie si une valeur répond aux exigences de données avant l’envoi du formulaire.
Utilisez un petit nombre de règles adaptées à l’objectif du champ. Des formulaires trop restrictifs peuvent augmenter les abandons et générer du travail de support.
### Règles de validation disponibles
#### Obligatoire
* Indique si le champ doit être renseigné.
* Pour les cases à cocher et les interrupteurs, cela signifie que la case doit être cochée.
#### `minLength`
* Définit le **nombre minimum de caractères** requis pour la valeur d’un champ.
* Utile pour des champs comme les noms ou les numéros d’identification.
#### `maxLength`
* Définit le **nombre maximum de caractères** autorisé dans le champ.
* Aide à empêcher les saisies excessivement longues qui pourraient perturber la mise en page ou le stockage.
#### `email`
* Combine deux niveaux de validation :
1. **Vérification par expression régulière**: utilise l’expression régulière par défaut suivante pour valider le format :
```js
/^[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?:[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?\.)+[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?$/
```
Cette expression régulière peut être **remplacée** par une expression personnalisée si nécessaire.
2. **Vérification du domaine via DNS**: Wallet Crew vérifie que le domaine de l’e-mail accepte les messages en vérifiant la présence de **enregistrements MX**.
#### `phone`
* Valide les numéros de téléphone à l’aide du composant [react-phone-number-input](https://catamphetamine.gitlab.io/react-phone-number-input/) .
* Cette validation s’appuie sur la bibliothèque internationale de Google pour la validation des numéros de téléphone.
* Veille à ce que les numéros soient correctement formatés et que les indicatifs de pays soient reconnus.
#### `expression`
* Permet aux administrateurs de définir une **expression régulière personnalisée** pour valider le champ.
* Option flexible pour imposer des données au format spécifique (par ex. codes postaux, identifiants).
#### `égalité`
* Compare la valeur du champ à :
* La valeur d’un autre champ (par ex. « Confirmer le mot de passe »)
* Une valeur constante statique
* Garantit la cohérence et la correspondance lorsque cela est nécessaire.
### Configurer efficacement les règles
Commencez avec le minimum nécessaire pour identifier un client et émettre une Carte. Ajoutez d’autres règles uniquement lorsqu’elles améliorent un résultat opérationnel ou de conformité.
* Utilisez `obligatoire` uniquement pour les informations nécessaires lors de l’inscription.
* Utilisez `email` et `phone` pour les identifiants de contact client.
* Utilisez `égalité` pour les champs de confirmation, comme les adresses e-mail répétées.
* Testez les expressions régulières personnalisées avec des valeurs attendues et invalides avant la publication.
{% hint style="warning" %}
Personnalisez l’expression e-mail par défaut uniquement lorsqu’il existe une exigence documentée. Une expression trop restrictive peut rejeter des adresses e-mail clients valides.
{% endhint %}
### Validez le formulaire avant publication
Soumettez le formulaire avec des valeurs représentatives valides et invalides. Confirmez que les champs obligatoires bloquent les envois vides, que les règles de format affichent des erreurs claires et que les champs d’égalité rejettent les valeurs non concordantes.
Vérifiez également le résultat sur mobile et sur ordinateur. La plupart des parcours d’inscription commencent sur un téléphone après un scan de code QR ou un clic sur un lien de campagne.
### FAQ
Quels champs doivent être obligatoires ?
Rendez obligatoires uniquement les champs nécessaires pour identifier le client, émettre la Carte ou répondre à une exigence de conformité documentée. Les champs facultatifs peuvent être collectés plus tard.
Quand faut-il utiliser une règle d’expression ?
Utilisez une règle d’expression lorsqu’un identifiant métier nécessite un format spécifique que les règles standard ne couvrent pas. Testez l’expression avec des exemples valides et invalides avant la publication.
Une adresse e-mail peut-elle être confirmée ?
Oui. Ajoutez un deuxième champ e-mail et appliquez la `égalité` règle pour le comparer au champ d’origine.
Pourquoi une adresse e-mail pourtant valide échoue-t-elle à la validation ?
La règle e-mail vérifie à la fois le format de l’adresse et si le domaine accepte les messages via des enregistrements MX. Confirmez que le domaine est correctement orthographié et qu’il dispose d’enregistrements de messagerie valides.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.thewalletcrew.io/guides-enrolment/fr/inscription/enrolment-form/validation-rules.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.