Le passage est FACILITÉ (même WLangage, même analyse, mêmes éditeurs) mais pas immédiat : il faut apprendre le MODÈLE WEB lui-même — architecture serveur/navigateur, sessions, responsive, sécurité, hébergement — qui n'a pas d'équivalent sur le poste de travail. Ce qui se transfère directement : (1) Le WLANGAGE : mêmes variables, structures de contrôle, procédures, classes, fonctions de manipulation de chaînes et de données. Vous écrivez le même code. (2) L'ANALYSE : le modèle de données est identique et peut même être PARTAGÉ entre une application WinDev et un site WEBDEV. Tout votre savoir-faire en modélisation reste valable. (3) Les fonctions HFSQL et le SQL : identiques. (4) La logique de PROJET et les éditeurs : environnement familier, mêmes réflexes, même aide F1. (5) Les concepts : procédures, composants, états, requêtes. (6) Résultat : vous n'êtes pas un débutant, vous êtes un développeur qui découvre une plateforme. Ce qu'il faut vraiment APPRENDRE : (1) L'architecture SERVEUR / NAVIGATEUR. C'est le changement de paradigme majeur. Sur le poste, tout s'exécute au même endroit. Sur le web, le navigateur AFFICHE et le serveur TRAITE, avec des allers-retours entre les deux. Comprendre ce qui s'exécute où — et ce que cela implique — est le vrai apprentissage. (2) La SÉCURITÉ. Point critique : le code côté navigateur est VISIBLE et MODIFIABLE par l'utilisateur. Un contrôle de saisie placé côté navigateur peut être contourné en quelques secondes. Toute validation qui compte doit être refaite côté SERVEUR. C'est contre-intuitif quand on vient du poste de travail, où l'interface était une barrière raisonnable. (3) Les SESSIONS : le web est sans état par nature ; il faut gérer le contexte de l'utilisateur d'une page à l'autre. (4) Le RESPONSIVE : votre site sera consulté sur des écrans de toutes tailles. Ce n'est plus une option. (5) L'HÉBERGEMENT et l'exploitation : serveur d'application, nom de domaine, certificat HTTPS, sauvegardes, supervision, mises à jour. (6) Les performances : temps de chargement, poids des pages — un site lent perd ses visiteurs (et son référencement). (7) Le RÉFÉRENCEMENT pour un site public. Les erreurs classiques du « WinDeviste » débutant en web : (1) Raisonner comme sur un poste : croire qu'un contrôle d'interface protège quelque chose. (2) Mettre trop de traitements côté navigateur pour « aller vite », en oubliant que c'est visible et contournable. (3) Négliger le responsive et découvrir tard que le site est inutilisable sur mobile. (4) Sous-estimer la sécurité : un site est exposé au monde entier, y compris à des robots qui testent automatiquement les failles. (5) Oublier que l'utilisateur peut ouvrir plusieurs onglets, revenir en arrière, ou rester inactif puis reprendre. Comment aborder la transition : (1) Commencez par un projet SIMPLE pour assimiler le modèle. (2) Formez-vous spécifiquement aux notions web (même si vous connaissez déjà le WLangage). (3) Soyez particulièrement rigoureux sur la SÉCURITÉ dès le début. (4) Testez sur plusieurs navigateurs et tailles d'écran. En résumé : la transition est réellement FACILITÉE — même WLangage, même ANALYSE (parfois littéralement partagée), mêmes fonctions HFSQL, mêmes éditeurs et mêmes réflexes — de sorte qu'un développeur WinDev n'aborde pas WEBDEV en débutant, mais en professionnel qui change de plateforme. C'est d'ailleurs l'un des arguments majeurs de la gamme PC SOFT. Mais ne confondez pas syntaxe familière et maîtrise : le MODÈLE WEB doit s'apprendre. Le point central est l'architecture SERVEUR/NAVIGATEUR — le navigateur affiche, le serveur traite — avec sa conséquence critique en matière de SÉCURITÉ : le code côté navigateur est VISIBLE et MODIFIABLE, donc tout contrôle qui compte doit être refait côté serveur, ce qui heurte les habitudes prises sur le poste de travail où l'interface constituait une barrière raisonnable. S'y ajoutent les SESSIONS (le web est sans état), le RESPONSIVE (obligatoire), l'HÉBERGEMENT et l'exploitation (serveur d'application, domaine, HTTPS, supervision), les performances et le référencement. Les pièges classiques du développeur venu du poste : croire qu'un contrôle d'interface protège, trop en faire côté navigateur, négliger le responsive et sous-estimer une exposition publique où des robots testent automatiquement les failles.

Parce que tout ce qui s'exécute dans le navigateur est ENTIÈREMENT sous le contrôle de l'utilisateur : il peut le lire, le modifier, le désactiver ou l'ignorer — un contrôle côté navigateur est donc un CONFORT d'utilisation, jamais une protection. Ce qu'un utilisateur peut faire côté navigateur : (1) LIRE le code qui s'exécute chez lui : il est téléchargé sur sa machine, donc consultable. Toute logique qui s'y trouve est publique. (2) MODIFIER ou DÉSACTIVER ce code : outils de développement intégrés aux navigateurs, extensions, ou simple désactivation. (3) ENVOYER directement des requêtes au serveur sans passer par vos pages : c'est le point décisif. Il peut fabriquer une requête à la main, avec les valeurs de son choix, et l'envoyer à votre serveur comme si elle venait de votre formulaire. Votre interface n'existe alors plus du tout dans l'équation. (4) Contourner totalement le parcours prévu (accéder directement à une page, sauter des étapes). Les conséquences si l'on s'y fie : (1) Un contrôle de saisie contourné : vous vérifiez côté navigateur qu'un montant est positif ? Un utilisateur enverra un montant négatif directement au serveur. (2) Un droit contourné : vous masquez un bouton « Supprimer » aux non-administrateurs ? Il suffit d'appeler l'action correspondante directement. (3) Des données FALSIFIÉES : prix, quantités, identifiants d'autres utilisateurs, statuts — tout ce qui vient du navigateur peut avoir été manipulé. (4) Des injections : si le serveur fait confiance aux données reçues, il devient vulnérable (injection dans les requêtes, contenu malveillant). (5) Et il n'est pas nécessaire d'être un expert : des outils automatisés balaient les sites publics en permanence à la recherche de ces faiblesses. La règle absolue : (1) TOUTE validation qui compte se fait côté SERVEUR. Sans exception. Le serveur ne doit JAMAIS faire confiance à ce qui vient du navigateur. (2) Refaites côté serveur tous les contrôles : validité des données, droits de l'utilisateur, cohérence métier, appartenance des données (cet enregistrement appartient-il bien à cet utilisateur ?). (3) Vérifiez les DROITS à chaque action sensible, pas seulement à l'affichage du bouton. (4) Ne transmettez pas d'informations sensibles au navigateur en pensant qu'elles y sont cachées. À quoi sert alors le code côté navigateur ? (1) Au CONFORT et à la RÉACTIVITÉ : signaler immédiatement une erreur de format sans attendre un aller-retour serveur, afficher/masquer des zones, calculer un aperçu, améliorer l'ergonomie. (2) C'est très utile — mais c'est de l'expérience utilisateur, pas de la sécurité. (3) La bonne approche : les DEUX. Contrôle côté navigateur pour la réactivité ET contrôle côté serveur pour la sécurité. Le premier est agréable, le second est obligatoire. (4) Ne considérez jamais le premier comme dispensant du second. En résumé : ne placez jamais un contrôle de SÉCURITÉ côté navigateur parce que tout ce qui s'y exécute appartient à l'utilisateur — il peut lire le code, le modifier, le désactiver, et surtout ENVOYER DIRECTEMENT des requêtes à votre serveur sans jamais passer par vos pages, ce qui fait purement et simplement disparaître votre interface de l'équation. Un montant refusé à l'écran sera envoyé tel quel, un bouton masqué verra son action appelée directement, et des données comme un prix, une quantité ou un identifiant peuvent arriver falsifiées. Ces contournements ne demandent aucune expertise particulière, et des outils automatisés scrutent en permanence les sites publics à la recherche de telles faiblesses. La règle absolue est donc que le serveur ne fasse JAMAIS confiance à ce qui vient du navigateur : refaites côté SERVEUR toutes les validations (format, cohérence métier, DROITS à chaque action sensible et non seulement à l'affichage, appartenance des données à l'utilisateur). Le code côté navigateur garde toute son utilité, mais pour le CONFORT et la RÉACTIVITÉ — signaler une erreur de format immédiatement, afficher un aperçu, fluidifier l'ergonomie. Faites donc les deux : côté navigateur pour l'expérience, côté serveur pour la sécurité, le premier ne dispensant jamais du second.