Validate : qu'est-ce que c'est, validation des champs de saisie et implémentation dans Android

Qu'est-ce que la validation de champ dans Android ?

La validation de champ est la vérification d'une seule valeur saisie par l'utilisateur selon les règles spécifiées. Chaque champ a son propre type de données : email, nombre, téléphone, mot de passe, texte. Chaque type a ses propres critères : format, longueur, plage de valeurs, obligation. La validation de champ répond à la question : la saisie dans ce champ est-elle correcte ?

La différence entre la validation de champ et la validation de formulaire est qu'un champ est vérifié indépendamment des autres champs. L'email est validé selon un motif d'email, le téléphone selon un motif de téléphone. Si un champ est invalide, l'utilisateur voit une erreur pour ce champ spécifique. Le formulaire peut rester non envoyé même si un champ échoue à la validation. La validation de champ est la brique de base pour la validation complète du formulaire.

Selon les recherches UX, les utilisateurs s'attendent à voir une erreur de validation au plus tard 1 à 2 secondes après avoir terminé la saisie. Un retard de plus de 3 secondes est perçu comme un problème de l'application. C'est pourquoi la validation en temps réel via TextWatcher est préférable à une vérification uniquement lorsque le bouton d'envoi est pressé.

Principales méthodes de validation de champs

Il existe trois approches principales pour la validation de champs dans Android. La première est la vérification manuelle via des opérateurs conditionnels (if, when). Le développeur écrit une fonction qui prend une chaîne et retourne un Boolean ou un message d'erreur. Cette approche donne un contrôle total sur la logique, mais nécessite d'écrire du code pour chaque champ et chaque condition.

La deuxième approche est l'utilisation de classes intégrées d'Android. Par exemple, Patterns.EMAIL_ADDRESS.matcher(email).matches() valide un email selon un motif standard. Patterns.PHONE.matcher(phone).matches() valide un numéro de téléphone. TextUtils.isEmpty() vérifie le vide. Ces méthodes couvrent les scénarios de base sans ajouter de dépendances externes.

La troisième approche est les bibliothèques de validation. Des bibliothèques comme InputValidator, AndroidValidator ou Commons Validator fournissent des annotations prêtes à l'emploi et des chaînes de validation. Le développeur décrit les règles de manière déclarative : @Email, @NotEmpty, @MinLength(6). La bibliothèque elle-même effectue la validation et retourne une liste d'erreurs. Cela accélère le développement mais ajoute une dépendance.

Validation d'email, de téléphone et de mot de passe

Pour l'email, la validation standard inclut la vérification de la présence du symbole @, d'une partie domaine et de l'absence d'espaces et de caractères cyrilliques. Android fournit Patterns.EMAIL_ADDRESS, qui couvre la plupart des adresses email légitimes. Cependant, si une validation spécifique est requise (par exemple, uniquement les domaines d'entreprise), une expression régulière personnalisée doit être écrite. L'email est validé après la saisie complète, pas après chaque caractère.

Le numéro de téléphone est validé selon un masque de pays ou de région. Pour les numéros internationaux, le format E.164 est utilisé : +code du pays, code de l'opérateur, numéro. La bibliothèque libphonenumber de Google est la norme industrielle pour la validation des téléphones. Elle détermine le pays par le code, vérifie la longueur et le format du numéro. Dans Android, PhoneNumberUtils.isGlobalPhoneNumber peut être utilisé pour la validation de base.

Le mot de passe a plusieurs critères de complexité : longueur minimale, présence de lettres majuscules et minuscules, de chiffres, de caractères spéciaux. Android n'a pas de classe intégrée pour la validation des mots de passe — chaque projet définit ses propres exigences. Généralement, un mot de passe est validé via une expression régulière ou un ensemble de conditions. Il est important de ne pas révéler les exigences exactes dans le message d'erreur : « Le mot de passe est trop simple » est mieux que « Une lettre majuscule et un chiffre sont requis ».

data class ValidationResult(
    val isValid: Boolean,
    val errorMessage: String? = null
)

fun validatePassword(password: String): ValidationResult {
    if (password.length < 6)
        return ValidationResult(false, "Minimum 6 characters")
    if (!password.any { it.isUpperCase() })
        return ValidationResult(false, "Uppercase letter required")
    return ValidationResult(true)
}

Dans l'exemple, validatePassword retourne un ValidationResult avec un champ isValid et un message d'erreur optionnel. Cette approche est pratique pour la composition : plusieurs vérifications sont effectuées séquentiellement et la première erreur trouvée est retournée. La validation d'email et de téléphone suit le même principe — chacune retourne un résultat avec un message ou un succès.

Quand effectuer la validation ?

Le moment de la validation affecte considérablement l'UX. Il existe trois stratégies : validation après chaque caractère (instantanée), après la perte de focus (onFocusLost) et à l'envoi du formulaire (onSubmit). Chaque stratégie convient à différents scénarios. La validation instantanée est bonne pour les champs avec des contraintes strictes — numéro de téléphone, code PIN. OnFocusLost convient pour l'email et le nom. OnSubmit convient pour les champs obligatoires.

Selon les Material Design Guidelines, il est recommandé de combiner les stratégies : un champ doit être validé à la perte de focus et également à l'envoi du formulaire. La validation instantanée est appropriée lorsque la contrainte est évidente — par exemple, la longueur maximale du champ. Si une erreur est affichée après chaque caractère pour l'email, l'utilisateur verra un message avant de terminer la saisie. C'est agaçant et réduit la conversion.

La règle de la première erreur : lors de l'envoi d'un formulaire, affichez une erreur uniquement pour le premier champ invalide. Ne submergez pas l'utilisateur avec une liste de 10 erreurs. Après avoir corrigé la première erreur, la suivante peut être affichée. Ce guide étape par étape réduit la charge cognitive et aide l'utilisateur à remplir le formulaire plus rapidement.

Outils et bibliothèques pour la validation

Le SDK Android fournit des outils de base pour Validate : Patterns pour l'email et le téléphone, TextUtils pour vérifier le vide, des expressions régulières pour des motifs arbitraires. Pour les projets avec 1 à 3 champs, cela suffit. Cependant, dans les formulaires avec 10+ champs, la validation manuelle devient difficile à maintenir — chaque nouveau champ nécessite une fonction séparée et une logique d'envoi mise à jour.

Bibliothèques de validation populaires : Android Saripaar (annotations @Email, @NotEmpty, @Password), Apache Commons Validator (validation d'email, d'URL, de numéro de carte de crédit), RxBinding + RxJava pour la validation réactive. Saripaar permet de placer des annotations directement sur les champs de saisie et d'appeler la validation en une ligne : validator.validate(). La bibliothèque affiche automatiquement les erreurs via setError.

Google recommande d'utiliser Material Design Components avec TextInputLayout. La validation intégrée via setError, setHelperText et setCounterEnabled couvre les scénarios de base sans bibliothèques tierces. Pour les projets complexes (fintech, santé), il est préférable d'utiliser une combinaison : Material Components + validation personnalisée avec des motifs de la couche domaine de Clean Architecture.

Erreurs courantes dans la validation de champs

La première erreur est d'afficher une erreur avant le début de la saisie. Si un champ est obligatoire mais que l'utilisateur n'a pas commencé à le remplir, n'affichez pas « Champ obligatoire ». Cela crée une fausse impression de problème. Une erreur ne devrait apparaître qu'après que l'utilisateur a interagi avec le champ : a commencé à taper, a quitté le champ, a tenté d'envoyer le formulaire.

La deuxième erreur est un message d'erreur peu clair. Le message doit être spécifique et suggérer comment résoudre le problème. « Email invalide » est mauvais. « L'email doit contenir @ et un domaine, par exemple user@example.com » est bon. L'utilisateur doit comprendre exactement ce qui ne va pas et comment le corriger sans consulter la documentation.

La troisième erreur est de bloquer l'envoi sans explication. Si le bouton d'envoi est inactif en raison d'erreurs de validation, l'utilisateur doit voir quels champs sont invalides. Un bouton gris sans messages est une impasse pour l'utilisateur. Mettez toujours en surbrillance les champs avec des erreurs et affichez le texte d'erreur à côté de chaque champ invalide.