Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

eZHumanCAPTCHACode reload
retour

Contrôle de saisie

Contrôle de saisie

Faut-il contrôler les saisies « coté client » ou « coté serveur » ?

C’est sans doutes une des questions les plus souvent posées pour les interfaces web.

Contrôler les saisies coté client, c’est à dire par du javascript inséré dans la page Html permet une meilleure réactivité de l’interface. L’utilisateur est averti plus tôt de son erreur, on ne le laisse pas s’enferrer, il peut rapidement corriger sa saisie et poursuivre son action.

En revanche, plusieurs arguments militent contre cette solution.

Le code javascript qui implémente ce contrôle de saisie est partie intégrante de l’application. Cela signifie que l’application est écrite en deux langages, éclatée en deux environnements distincts : l’un coté client, l’autre coté serveur. Sans entrer dans les détails, on perçoit bien que cette dualité posera des problèmes, en maintenance, en gestion des compétences de l’équipe, mais aussi en cohérence.

Ainsi, supposons un champ de saisie qui attend un nombre entier et que du code javascript le vérifie. Imaginons qu’un jour un changement fonctionnel autorise un nombre décimal. Il est clair que des changements seront à opérer à la fois coté serveur et coté client, et le risque est grand que des incohérences soient introduites par de tels changements.

Par ailleurs, le code javascript est plus ou moins mêlé dans une page html dont la fonction principale est de décrire de la présentation et de la mise en forme. C’est un mélange que toutes les démarches de développement cherchent à éviter. Si un graphiste est amené à retoucher cette page, il devra soigneusement éviter de toucher à ce code javascript qui n’est pas de son ressort.

Au delà des considérations portant sur le processus de développement et de maintenance, il faut souligner que les contrôles javascript, quoi qu’il en soit, ne peuvent être complets. Ces fonctions de contrôles n’ont pas à leur disposition d’autres données que celles de la page, et ne peuvent donc mettre en œuvre des contrôles que de premier niveau.

Ainsi dans tous les cas, les contrôles de saisie doivent être refaits et étendus, coté serveur. Nous disons ‘refaits’ car d’une manière générale l’application web ne doit pas faire confiance aveuglément aux requêtes qu’elle reçoit du poste client.

Ils doivent être étendus aussi pour inclure des contrôles de cohérence plus larges. Par exemple le fait qu’un champ ‘client’ contient bien un code correspondant à un client existant.

Les erreurs de saisie peuvent être rangées schématiquement de la manière suivante :

  • Contrôle syntaxique unitaire : longueur du texte, nombre, date, etc… et champs obligatoires. Ils peuvent être opérés en javascript coté client ;
  • Contrôles de conformité par rapport à des données de référence. Ils sont opérés coté serveur. Certains ne portent que sur un champ, d’autres sur la cohérence entre plusieurs saisies : le pays saisi dans le champ 2 doit être dans la liste des pays de la région indiquée dans le champ 1.
  • Autres contrôles, plus spécifiques. Dans la pratique, ils constituent une très faible proportion.

De plus, dans la pratique la bonne application de règles de gestion métier doit parfois être vérifiée dans un ordre donné, dans la mesure où telle règle pour être applicable, suppose qu’une autre règle est déjà appliquée.

Comment vérifier que le pays indiqué est bien dans la région choisie si déjà la région est incorrecte ?

Du point de vue du développement, ces contrôles ne seront jamais codés en spécifique, au cas par cas, mais feront appel à des librairies existantes. Dans certains cas, on pourra même automatiser le lien entre ces contrôles et les objets métier coté serveur, qui eux-mêmes pourront être liés à la base de données.

Bien entendu, les contrôles qui relèvent du Html natif doivent être utilisés impérativement. Il est insupportable qu’un champ de saisie laisse saisir 25 caractères pour s’entendre dire ensuite qu’il n’en faut pas plus de 20.

En outre, l’usage suivant est généralisé :

Et lorsque le format de saisie peut avoir des variantes, on indiquera dans le libellé le format attendu.