Discussion :

[thebloodyman]

il me semble que tu oublie la raison principale pour laquelle on fait de la validation: l'erreur humaine. Un minimum de temps à faire de la validation, même basique, permet d'éviter de grosse pertes de temps en aval quand il faut corriger toute la DB parce qu'un opérateur à encodé une donnée de travers pendant 2 ans et que, maintenant qu'on a besoin de ces donénes, elle ne sont pas là / sont erronés.

Tu sembles faire références là à des applis avec des données sensibles alors que moi non.

Ce que tu ne valide pas a aussi un coût, il est juste moins visible, mais il faut en tenir compte (formation supplémentaire pour expliquer ce qu'on ne peut pas faire, dans quel format il faut encoder les numéros de registre natinaux, intervention sur des processus bloqués car données mal encodées, etc.).

C'est le rôle des contrôles coté client.

Les risques qu'il peut y avoir coté serveur, je les évoqués dans mon post précédent :

Maintenant, pour les applis web intranet à 1 ou 2 utilisateurs qui font de la gestion de contenu, je vois très mal le mec contrefaire des requêtes ou envoyer n'importe quoi au serveur via des url tapées à la main puisque de toute façon, 1.ils ne gagneront rien à part faire planté ou buggé l'appli 2.ca leur tombera dessus si ils font n'importe quoi (il y a qu'eux qui utilisent l'appli ) ?

Donc pour moi, la question n'est pas de former les quelques utilisateurs de l'apli (puisque les contrôles clients sont déja la) mais simplement leur demander de ne pas essayer de pirater leur outil de travail.

Je précise que je parle toujours d'appli intranet avec peu d'utilisateurs (entre 1 et 5) et pas de données sensibles.

[OButterlin]

Pour moi, le contrôle est nécessaire lorsque la valeur d'une propriété est déterminée par des règles (Je ne m'amuse pas à contrôler un champ texte s'il n'est pas nécessaire).

Certains contrôles peuvent être effectués côté client, en particulier :
- champ obligatoire
- champ numérique
- structure particulière de la donnée
- valeur comprise entre a et b
- liste de caractères autorisés restreints
- etc...

Par contre, certains contrôle ne peuvent pas être fait côté client (hors ajax) :
- intégrité référencielle
- liste de valeurs possibles dépendantes d'autres champs non présent dans l'ihm
- etc...

Donc, à choisir un endroit unique, je mettrais tout côté serveur.