Règles de validation partagées pour clients web et mobile

Pourquoi la validation diverge\n\nLa validation se désynchronise pour une raison simple : les formulaires web et mobiles sont souvent construits à des moments différents par des personnes différentes. Une équipe ajoute une règle rapide sur le site, une autre réutilise une ancienne version dans l'app, puis chacun passe à autre chose.\n\nAu début, la différence semble mineure. Puis un changement la révèle. Le mot de passe exige maintenant 12 caractères au lieu de 8. Le numéro de téléphone requiert un indicatif national. Un champ autrefois optionnel devient obligatoire. Si un seul client est mis à jour, un même utilisateur peut saisir des données valides sur un appareil et être bloqué sur un autre.\n\nC'est pourquoi les règles de validation partagées sont importantes. Sans elles, chaque client devient sa propre version de la vérité.\n\n### À quoi ressemble la dérive en pratique\n\nLes formulaires d'inscription montrent vite le problème. Sur le site, « nom de l'entreprise » peut être optionnel. Dans l'application mobile, il peut rester obligatoire parce que cet écran a été conçu des mois plus tôt. L'utilisateur remplit deux fois le même formulaire, obtient deux résultats différents et pense que le produit est défaillant.\n\nCela arrive généralement lorsque les règles sont copiées à plusieurs endroits et mises à jour manuellement. Le calendrier des sorties empirera la situation. Une modification web peut être en production aujourd'hui, tandis qu'une correction mobile attend la prochaine version de l'app.\n\nLe décalage apparaît souvent dans des endroits basiques : champs obligatoires, vérifications de format et limites métier comme l'âge, la taille de commande ou les règles de remise. Les équipes support doivent alors expliquer pourquoi un écran accepte une valeur et un autre la refuse. Avec le temps, les utilisateurs cessent de faire confiance aux messages d'erreur et les équipes perdent confiance dans leurs livraisons.\n\nLa règle en elle‑même est rarement le véritable problème. Le problème, c'est que la même règle vit à trop d'endroits.\n\n## Ce qui doit rester identique partout\n\nSi un formulaire se comporte différemment sur le web et sur mobile, les utilisateurs s'en aperçoivent immédiatement. L'approche la plus sûre est de décider quelles règles sont universelles et de les maintenir identiques sur chaque client.\n\nCommencez par les fondamentaux. Un champ ne devrait pas être obligatoire sur un appareil et optionnel sur un autre, sauf s'il existe une raison produit très claire. Les contrôles de format doivent aussi correspondre. Email, téléphone, date et champs similaires doivent suivre le même schéma partout. Même une petite différence, comme un client acceptant des espaces dans un numéro de téléphone alors qu'un autre les rejette, crée de la confusion.\n\nLes limites de longueur et les caractères autorisés nécessitent le même traitement. Si un nom d'utilisateur accepte 30 caractères sur mobile mais seulement 20 sur le web, les utilisateurs peuvent sauvegarder des données que l'autre client ne pourra plus modifier. Le même problème apparaît pour les noms, notes, codes et identifiants.\n\nLes règles métier ont autant d'importance. Si les utilisateurs doivent être au‑dessus d'un certain âge, appartenir à une région supportée ou avoir un certain statut de compte, ces contrôles doivent fonctionner de la même manière sur chaque écran.\n\nLe libellé n'a pas besoin d'être strictement identique partout, surtout sur les petits écrans mobiles, mais le sens doit rester cohérent. Si une app affiche « Saisissez une date valide » et qu'une autre affiche « Date non prise en charge », les utilisateurs peuvent penser que les règles diffèrent alors qu'elles sont identiques.\n\nUn test simple marche bien ici : si un utilisateur saisit les mêmes données sur web et mobile, il doit obtenir le même résultat et les mêmes indications de base pour corriger l'erreur.\n\n## Laisser le backend prendre la décision finale\n\nLe retour rapide côté frontend est utile, mais il ne doit jamais être la décision finale. Le backend doit toujours décider si les données sont valides.\n\nLes clients web et mobiles doivent quand même intercepter tôt les problèmes évidents. Ils doivent signaler les champs requis manquants, un mauvais format d'email, des dates impossibles et des valeurs manifestement hors plage. Cela fait gagner du temps et aide les utilisateurs à corriger les erreurs avant d'appuyer sur Envoyer.\n\nMais le backend a la vision complète. Il peut vérifier des règles métier liées à des données en direct, à l'état d'un compte, aux permissions, à l'inventaire ou à des enregistrements modifiés par un autre utilisateur une seconde plus tôt. Un code promo peut sembler valide sur le téléphone, mais le serveur sait peut‑être qu'il a expiré ou qu'il a déjà été utilisé.\n\nPour que les règles partagées fonctionnent bien, le backend doit renvoyer des erreurs dans un format que tous les clients comprennent. Évitez les réponses vagues comme « Entrée invalide. ». Utilisez des codes d'erreur stables ou des noms de règle accompagnés d'un message clair.\n\nQuelques exemples suffisent :\n\n- required pour les champs manquants\n- invalid_format pour un mauvais format d'email ou de téléphone\n- out_of_range pour des valeurs au‑dessus ou en dessous des limites\n- not_allowed pour des contrôles basés sur permissions ou statut\n- already_exists pour des emails, noms d'utilisateur ou identifiants en double\n\nCes noms doivent rester stables entre les clients. De petites différences comme email_invalid dans une app et invalid_email dans une autre créent des bugs inutiles.\n\nUn bon test backend est simple : si quelqu'un évite l'interface et envoie une requête directement à l'API, les mêmes mauvaises données doivent être rejetées pour la même raison.\n\n## Créer une source de vérité unique\n\nLa solution la plus propre est un seul livre de règles. Si chaque équipe écrit la validation dans chaque formulaire web et écran mobile, les règles vont dériver. Les règles partagées fonctionnent mieux quand elles sont définies une fois et que chaque client suit cette définition.\n\nCette source partagée peut être un schéma, un modèle backend ou une configuration produit centrale. Le format exact importe moins que l'habitude. Définissez le champ une fois avant que quiconque ne construise l'écran. Conservez ensemble le nom du champ, le type de donnée, le statut requis, le format et les limites métier.\n\nIl est également utile de regrouper les règles par objet métier plutôt que par appareil. Un utilisateur, une commande, une facture ou une requête d'inscription devrait avoir un seul ensemble de règles applicables partout. Pour chaque objet, enregistrez les champs, les contrôles requis, les règles de format, les contraintes métier et les codes d'erreur que le backend renverra.\n\nCela rend les changements plus sûrs. Si l'entreprise décide qu'un numéro de téléphone est optionnel, vous mettez à jour une définition partagée au lieu de chercher dans iPhone, Android, web et écrans d'administration.\n\nLa gestion des versions est importante aussi. Les changements de règle peuvent casser des apps plus anciennes encore installées sur les téléphones des clients. Au lieu de remplacer une règle sans laisser de trace, versionnez le changement pour que le backend puisse supporter les anciens clients pendant une courte période le temps que les nouvelles versions se déploient.\n\nUne courte étape de revue aide plus que la plupart des équipes ne l'attendent. Lorsqu'une règle change, le produit peut confirmer l'objectif métier et le support peut signaler de vrais problèmes clients, comme un champ de nom qui rejette une ponctuation courante ou une règle d'adresse trop stricte.\n\nSi vous construisez avec AppMaster, cette approche s'intègre naturellement parce que la logique backend, les apps web et les apps mobiles natives peuvent être gérées dans une même plateforme no‑code. L'idée reste la même partout : écrivez les règles une fois, centralisez‑les et laissez tous les clients les suivre.\n\n## Un plan de déploiement simple\n\nVous n'avez pas besoin d'une réécriture complète pour corriger la dérive. Commencez par un formulaire et explicitez ses règles.\n\nD'abord, listez chaque champ et décrivez‑le en langage clair. Notez le type de valeur qu'il accepte, s'il est requis, le format attendu et toute condition métier associée. « L'email est requis » ne suffit pas si un client accepte un format incorrect et qu'un autre le bloque.\n\nEnsuite, implémentez d'abord les contrôles côté backend. Après cela, reproduisez les mêmes contrôles dans le formulaire web et dans le formulaire mobile afin que les utilisateurs aient un retour rapide avant la soumission.\n\nUn ordre simple fonctionne bien :\n\n1. Rédiger une liste règle champ par champ.\n2. Mettre les règles dans la validation backend en premier.\n3. Ajouter les mêmes contrôles côté web.\n4. Ajouter les mêmes contrôles côté mobile.\n5. Tester les mêmes entrées d'exemple partout.\n\nLes tests sont l'endroit où apparaissent généralement les différences cachées. Utilisez un petit ensemble d'exemples valides et invalides pour chaque champ : valeur vide, mauvais format, valeur juste en dessous de la limite, valeur exactement à la limite et valeur juste au‑dessus. Si web et mobile correspondent tous deux au backend sur chaque cas, vous avez un système fiable.\n\n## Exemple : un formulaire d'inscription client\n\nUn formulaire d'inscription rend cela facile à visualiser. Imaginez trois champs : email, mot de passe et date de naissance.\n\nSur web et mobile, le formulaire doit réagir de la même manière avant que l'utilisateur ne le soumette. Si l'email est vide, les deux doivent bloquer et afficher le même message. Si le format est incorrect, les deux doivent le détecter aussi.\n\nLa règle sur le mot de passe doit correspondre exactement. Si le minimum est de 8 caractères, il doit être de 8 partout, pas 6 sur le web et 10 sur mobile. De petites discordances comme celle‑ci embrouillent rapidement les utilisateurs, surtout lorsqu'ils changent d'appareil.\n\nLa date de naissance est un domaine où la logique métier diverge souvent. Si votre produit n'autorise que les inscriptions de personnes de 18 ans et plus, les deux clients doivent utiliser la même règle de coupure et la même définition de « aujourd'hui ». Sinon, un utilisateur peut être approuvé sur le site et rejeté dans l'app.\n\nLe backend doit toujours tout revérifier quand la requête arrive. C'est là que vous détectez comptes en double, requêtes modifiées et versions d'app obsolètes qui envoient encore des données dépassées.\n\nLes messages doivent rester clairs et cohérents aussi. De bons exemples : « Saisissez votre adresse e‑mail », « Entrez une adresse e‑mail valide », « Le mot de passe doit contenir au moins 8 caractères » et « Un compte avec cet e‑mail existe déjà. » Quand les utilisateurs voient le même libellé partout, le support devient plus simple et la confiance augmente.\n\n## Erreurs qui provoquent la dérive\n\nLa plupart des problèmes de validation ne proviennent pas d'une règle manifestement cassée. Ils viennent de petites incohérences qui s'accumulent au fil du temps.\n\nUne erreur courante est de cacher une règle dans un seul client. L'app iPhone peut exiger un numéro de téléphone tandis que l'app web le considère optionnel. Une autre erreur est d'utiliser des motifs différents pour le même champ. Un formulaire web peut autoriser des espaces dans un code postal tandis que l'app Android les bloque, ou un client accepte un signe plus dans un numéro de téléphone tandis qu'un autre l'enlève.\n\nUn problème plus grave est de trop faire confiance à l'UI. La validation côté client aide à corriger plus vite, mais elle ne suffit jamais à elle‑seule. Les anciennes apps, les particularités de certains navigateurs et les requêtes directes à l'API peuvent tous envoyer de mauvaises données si le backend n'impose pas les mêmes contraintes métier.\n\nDes messages d'erreur peu clairs aggravent tout. « Entrée invalide » n'indique pas quoi corriger. Un message clair, oui. Les versions anciennes d'apps sont aussi faciles à oublier. Si une nouvelle version ajoute un champ obligatoire, les anciens clients peuvent continuer à envoyer des données incomplètes pendant des semaines.\n\nQuand la validation dérive régulièrement, les causes habituelles sont simples : champs requis cachés, règles de format différentes, contrôles backend faibles, messages d'erreur vagues et absence de plan pour les anciennes versions.\n\n## Contrôles de sortie qui détectent les problèmes\n\nAvant de publier, testez le même formulaire de la même manière sur chaque client. Utilisez un petit ensemble d'entrées d'exemple et faites‑les passer par l'app web, l'app mobile et l'API backend. Si un client accepte une valeur qu'un autre rejette, vos règles partagées ne sont pas encore réellement partagées.\n\nCommencez par les cas basiques. Laissez les champs requis vides, saisissez des valeurs mal formatées et essayez des cas limites comme une date au bord exact, un nom d'un seul caractère ou un champ rempli jusqu'à la longueur maximale.\n\nVotre vérification pré‑release doit répondre à quelques questions directes : le web rejette‑t‑il les mêmes mauvaises entrées que le mobile, le backend rejette‑t‑il toujours les données invalides même si un client les laisse passer, et les utilisateurs perçoivent‑ils le même sens dans le message d'erreur partout ?\n\nLa vérification backend est la plus importante. Si quelqu'un contourne l'UI, utilise une app ancienne ou envoie des données directement à l'API, le résultat doit rester sûr et prévisible.\n\nIl vaut aussi la peine de comparer les textes d'erreur côte à côte. Si le web dit « Entrez un e‑mail valide » mais le mobile dit « Erreur inconnue », les gens supposeront que les apps se comportent différemment même quand la règle est identique.\n\nAprès le lancement, surveillez les tickets support et les retours utilisateurs pendant quelques jours. Des plaintes comme « ça marchait sur mon téléphone mais pas sur le bureau » indiquent souvent une faille de validation plus vite que n'importe quel tableau de bord.\n\n## Étapes suivantes simples\n\nSi vos formulaires continuent de poser des problèmes différents sur web et mobile, ne tentez pas de corriger tous les formulaires d'un coup. Commencez par celui qui provoque le plus de problèmes récurrents, généralement l'inscription, le paiement ou l'édition de profil.\n\nDéplacez les règles strictes vers la logique backend en premier. Cela inclut champs obligatoires, vérifications de format, contrôles d'existence et limites métier comme l'âge, le type de compte ou la région. Ensuite, laissez le web et le mobile reproduire ces mêmes contrôles pour la rapidité et la clarté.\n\nRédigez les règles simplement. Au lieu de « valider le statut client », écrivez « Les clients professionnels doivent fournir un numéro d'identification fiscale » ou « Le numéro de téléphone est optionnel sauf si les alertes SMS sont activées. » Un libellé clair facilite le travail des designers, développeurs, testeurs et équipes support pour repérer les écarts avant la sortie.\n\nSi vous voulez réduire le travail répété, AppMaster peut aider car il permet aux équipes de construire backend, web et apps mobiles depuis un seul système. Cela facilite le maintien de la logique métier alignée tout en offrant un retour rapide aux utilisateurs sur chaque client.\n\nL'objectif n'est pas d'avoir des formulaires parfaits du jour au lendemain. L'objectif est moins de surprises, moins de tickets support et une validation web et mobile qui reste cohérente à mesure que votre produit grandit.