Valider une saisie en C# : TryParse, Regex et ErrorProvider

Valider une saisie, c'est vérifier qu'une valeur tapée par l'utilisateur est complète, au bon format et cohérente avant de l'utiliser ou de l'enregistrer. En WinForms, on s'appuie sur trois outils : les méthodes TryParse pour convertir sans planter, les expressions régulières pour contrôler un format, et le composant ErrorProvider pour signaler l'erreur à côté du champ concerné.

Pourquoi valider à plusieurs endroits

Une même règle peut être vérifiée à trois niveaux, qui n'ont pas le même but.

La validation de l'interface ne suffit jamais : un autre formulaire, une API ou un import peuvent créer des patients sans passer par elle. Inversement, une validation seulement dans la base produit des messages incompréhensibles (« Duplicate entry '2900575123456' for key 'numeroSecu' »). On valide donc à chaque niveau, chacun pour sa raison.

Les trois questions de toute validation

Pour chaque champ, pose-toi trois questions dans l'ordre :

1. Présence : le champ est-il obligatoire ? string.IsNullOrWhiteSpace(texte) refuse le vide et les espaces seuls.
2. Format : la valeur a-t-elle la bonne forme ? Un nombre, une date, 13 chiffres, une adresse électronique.
3. Cohérence : la valeur a-t-elle un sens, seule ou avec les autres ? Une naissance dans le futur, une durée de 0 jour, une date de fin avant la date de début.

Convertir sans planter : TryParse

Text est toujours une chaîne. Pour obtenir un nombre, int.Parse lève une FormatException si l'utilisateur tape « abc », et une OverflowException s'il tape un nombre trop grand. int.TryParse ne lève jamais d'exception : il renvoie true ou false et place le résultat dans une variable out.

if (!int.TryParse(txtDuree.Text, out int duree))
{
    errorProvider.SetError(txtDuree, "Saisis un nombre entier de jours.");
    return;
}
// ici, duree est un int valide

Attention à la culture pour les nombres décimaux. En France, le séparateur décimal est la virgule ; decimal.TryParse("12.50", …) échoue avec la culture française, et decimal.TryParse("12,50", …) échoue avec une culture anglaise. Par défaut, TryParse utilise la culture de Windows (en général française sur les postes de tes utilisateurs). Pour ne pas dépendre du poste, précise-la :

using System.Globalization;

var fr = new CultureInfo("fr-FR");
bool ok = decimal.TryParse(txtPrix.Text, NumberStyles.Number, fr, out decimal prix);
// "12,50" → true, 12,50    "1 250,50" → true, 1250,50    "12.50" → false

DateTime.TryParse existe aussi, mais 01/02/2026 signifie 1er février en France et 2 janvier aux États-Unis : pour une date, le DateTimePicker du chapitre 2 évite toute ambiguïté.

Contrôler un format : les expressions régulières

Une expression régulière (ou regex) décrit la forme d'un texte. Regex.IsMatch(texte, motif) dit si le texte correspond.

using System.Text.RegularExpressions;

bool valide = Regex.IsMatch(txtSecu.Text, @"^\d{13}$");

• ^ et $ : le début et la fin du texte. Sans eux, « abc1234567890123xyz » serait accepté, puisqu'il contient 13 chiffres.
• \d : un chiffre ; {13} : exactement 13 fois.
• Le @ devant la chaîne (chaîne verbatim) évite de doubler les barres obliques inverses.

Signaler l'erreur : ErrorProvider

Une MessageBox par champ invalide est pénible : l'utilisateur la ferme, puis doit chercher le champ fautif. Le composant ErrorProvider affiche une petite icône rouge à côté du champ ; le message apparaît au survol de la souris.

Glisse un ErrorProvider depuis la Boîte à outils : il se range sous le formulaire, dans la barre des composants non visuels. Renomme-le errorProvider. Ensuite, deux appels suffisent :

errorProvider.SetError(txtNom, "Le nom est obligatoire.");   // affiche l'icône et le message
errorProvider.SetError(txtNom, "");                          // efface l'erreur de ce champ
errorProvider.Clear();                                       // efface toutes les erreurs

Valider au bon moment : Validating et ValidateChildren

Chaque contrôle déclenche l'événement Validating quand il va perdre le focus. Mettre e.Cancel à true signale que sa valeur est invalide.

private void txtNom_Validating(object? sender, CancelEventArgs e)
{
    if (string.IsNullOrWhiteSpace(txtNom.Text))
    {
        errorProvider.SetError(txtNom, "Le nom est obligatoire.");
        e.Cancel = true;
    }
    else
    {
        errorProvider.SetError(txtNom, "");
    }
}

private void txtSecu_Validating(object? sender, CancelEventArgs e)
{
    string secu = txtSecu.Text.Trim();
    if (secu.Length > 0 && !Regex.IsMatch(secu, @"^\d{13}$"))
    {
        errorProvider.SetError(txtSecu, "13 chiffres attendus, sans espace (ex. 2900575123456).");
        e.Cancel = true;
    }
    else
    {
        errorProvider.SetError(txtSecu, "");
    }
}

Par défaut, e.Cancel = true retient le focus dans le champ : l'utilisateur ne peut plus aller ailleurs tant qu'il n'a pas corrigé, ce qui est vite exaspérant. Trois réglages rendent l'ensemble agréable :

public FrmPatientEdition(Patient? patient = null)
{
    InitializeComponent();
    AutoValidate = AutoValidate.EnableAllowFocusChange;   // l'erreur s'affiche, mais on peut changer de champ
    btnAnnuler.CausesValidation = false;                  // cliquer sur Annuler ne valide rien
    // …
}

private void btnEnregistrer_Click(object? sender, EventArgs e)
{
    if (!ValidateChildren()) return;   // déclenche Validating sur tous les champs
    // …
}

• AutoValidate.EnableAllowFocusChange garde la validation à la sortie du champ, sans bloquer le focus.
• CausesValidation = false sur Annuler : sans ce réglage, cliquer sur Annuler depuis un champ vide déclenche sa validation et affiche une erreur absurde.
• ValidateChildren() valide tous les champs, même ceux que l'utilisateur n'a jamais visités, et renvoie false si l'un d'eux a mis e.Cancel à true. C'est indispensable : un champ obligatoire jamais visité n'a jamais déclenché son Validating.

L'événement Validated, qui suit Validating quand la valeur est correcte, sert rarement ; c'est dans Validating qu'on place les contrôles.

La règle métier, deuxième barrière

Même si l'interface a tout vérifié, la classe Patient contrôle ses propres données (chapitre 1) : son set lève une ArgumentException quand le nom est vide ou que le numéro n'a pas 13 chiffres. Le formulaire l'intercepte avec un try … catch :

private void btnEnregistrer_Click(object? sender, EventArgs e)
{
    if (!ValidateChildren()) return;

    try
    {
        Resultat = new Patient
        {
            NumPatient = _numPatient,
            Nom = txtNom.Text,
            Prenom = string.IsNullOrWhiteSpace(txtPrenom.Text) ? null : txtPrenom.Text.Trim(),
            DateNaissance = dtpNaissance.Checked ? dtpNaissance.Value.Date : null,
            NumeroSecu = string.IsNullOrWhiteSpace(txtSecu.Text) ? null : txtSecu.Text.Trim(),
        };
    }
    catch (ArgumentException ex)
    {
        MessageBox.Show(ex.Message, "Saisie incorrecte", MessageBoxButtons.OK, MessageBoxIcon.Warning);
        return;
    }

    DialogResult = DialogResult.OK;
}

Les règles qui demandent la base de données (« ce numéro est-il déjà pris par un autre patient ? ») ne peuvent pas se vérifier dans la fiche : c'est le service de la couche métier qui s'en charge au moment d'enregistrer, et qui lève une RegleMetierException que la fenêtre principale affiche (chapitre 8).

Les exceptions : intercepter ce qu'on sait traiter

Une exception est un objet qui signale une erreur et interrompt le code jusqu'au premier catch capable de la traiter. Si personne ne la traite, l'application affiche une boîte d'erreur et peut se fermer.

try
{
    await _service.EnregistrerAsync(patient);
}
catch (RegleMetierException ex)          // une règle refusée : on l'explique
{
    MessageBox.Show(ex.Message, "Enregistrement refusé", MessageBoxButtons.OK, MessageBoxIcon.Warning);
}
catch (Exception ex)                     // tout le reste : panne réseau, base arrêtée…
{
    MessageBox.Show($"L'enregistrement a échoué.\n{ex.Message}", "Erreur",
        MessageBoxButtons.OK, MessageBoxIcon.Error);
}

Trois règles pour des catch utiles :

• intercepte d'abord les exceptions précises, puis les plus générales : le premier catch qui correspond gagne ;
• n'écris jamais de catch { } vide : l'erreur disparaît, et le bug avec elle ;
• ne te sers pas des exceptions pour la validation ordinaire de l'interface : TryParse et un if sont plus simples et plus rapides qu'un try { int.Parse(…) }.

Exercices

private void txtRpps_Validating(object? sender, CancelEventArgs e)
{
    string rpps = txtRpps.Text.Trim();
    if (rpps.Length > 0 && !Regex.IsMatch(rpps, @"^\d{11}$"))
    {
        errorProvider.SetError(txtRpps, "Le numéro RPPS compte 11 chiffres.");
        e.Cancel = true;
    }
    else
    {
        errorProvider.SetError(txtRpps, "");
    }
}

btnAnnuler.CausesValidation = false;