5.1WebDev : sites & applications web
L'essentiel en 30 secondes
- WEBDEV partage le WLangage, l'analyse et les éditeurs avec WinDev : Yacine réutilise son modèle clients/articles/commandes pour un portail web, sans repartir de zéro.
- Le navigateur affiche, le serveur traite : le code serveur accède à HFSQL et porte la sécurité ; le code navigateur est visible et modifiable, donc jamais une protection.
- Le web ajoute ses propres notions : sessions, responsive, hébergement HTTPS et exposition publique — la syntaxe familière ne dispense pas d'apprendre le modèle web.
Mini-cas filé — Yacine ouvre un portail web pour les clients de la PME
Yacine développe l'application de gestion d'une PME de négoce de matériel électrique à Oran : clients, articles, commandes, factures et stocks. Les commerciaux veulent consulter le stock et saisir une commande depuis un navigateur, y compris chez le client. Yacine ouvre un projet WEBDEV et partage l'analyse existante : les fichiers Client, Article et Commande sont les mêmes qu'en WinDev. Il place la vérification du stock, du prix et des droits côté serveur, car le navigateur ne doit jamais décider d'un prix. Il ajoute une page responsive pour téléphone et tablette, une session pour identifier le commercial, et prévoit un hébergement avec certificat HTTPS. Il vérifie ensuite qu'une requête forgée à la main ne peut ni modifier un prix ni commander un article hors stock.
Cas autonome de cette section : il revient dans le cours, le schéma, le code et le défi 48h de la section 5.1.
1. Capitaliser sans recopier
WEBDEV est le membre de la gamme PC SOFT dédié au web : sites, intranets et applications web. Son intérêt majeur est la capitalisation : même WLangage, même analyse, mêmes éditeurs et même logique de projet. Yacine partage l'analyse de son application de gestion avec le portail web : les fichiers Client, Article, Commande et Stock ne sont pas recopiés, ils sont communs. Les procédures métier et certains composants se réutilisent également. Un développeur WinDev n'est donc pas débutant sur le web : il découvre une plateforme tout en gardant son modèle de données et son langage.
2. Serveur et navigateur
Le web fonctionne en client/serveur par nature : le navigateur affiche, le serveur traite. WEBDEV distingue le code exécuté côté serveur (sécurisé, avec accès aux données HFSQL) et le code exécuté côté navigateur (rapide, mais visible et modifiable par l'utilisateur). Conséquence absolue : un contrôle de prix, de stock ou de droit placé uniquement dans le navigateur peut être contourné. L'utilisateur peut même envoyer une requête directement au serveur, sans passer par les pages de Yacine. Toute validation qui compte se refait côté serveur. Le code navigateur sert au confort, jamais à la sécurité.
3. Sessions, responsive et hébergement
Le web est sans état : il faut gérer une session pour reconnaître le commercial d'une page à l'autre. Le responsive s'anticipe dès la conception (dispositions, zoning) pour s'adapter à l'ordinateur, à la tablette et au téléphone. L'hébergement exige un serveur d'application WEBDEV, un nom de domaine et un certificat HTTPS. Enfin, un site public est exposé : injections, usurpation de session et attaques automatisées rendent la sécurité plus critique qu'en interne. Yacine teste donc le portail sur plusieurs écrans et vérifie les droits côté serveur avant toute mise en ligne.
🔎 Exemple concret — 🔎 Exemple concret — Valider une commande côté serveur
Yacine refuse une ligne de commande forgée depuis le navigateur :
// Code SERVEUR — contrôle d'une ligne de commande WebDev
PROCEDURE ValiderLigneCommande(Ligne est une LigneCommande) : booléen
SI Ligne.Quantite <= 0 ALORS
Erreur("Quantité invalide")
RENVOYER Faux
FIN
SI Ligne.PrixUnitaireHT < PrixCatalogue(Ligne.CodeArticle) ALORS
Erreur("Prix inférieur au catalogue")
RENVOYER Faux
FIN
SI StockDisponible(Ligne.CodeArticle) < Ligne.Quantite ALORS
Erreur("Stock insuffisant")
RENVOYER Faux
FIN
RENVOYER VraiRésultat : une requête forgée à la main est rejetée par le serveur, même si la page a été modifiée.
Réflexe : tout contrôle qui compte se refait côté serveur, jamais uniquement dans le navigateur.
Vocabulaire de la section
- WEBDEV
- Membre de la gamme PC SOFT dédié au web (sites, intranets, applications web), partageant WLangage et analyse avec WinDev.
Exemple simple : Yacine ouvre un projet WEBDEV pour le portail client de sa PME.
Ce que ce n'est pas : croire qu'il faut réapprendre un autre langage.
Réflexe : WEBDEV = même WLangage, autre plateforme.
- Capitalisation
- Réutilisation des acquis WinDev (analyse, WLangage, procédures, composants) dans un projet WEBDEV.
Exemple simple : Yacine partage l'analyse Client/Article/Commande avec le portail.
Ce que ce n'est pas : recréer une seconde base pour le web.
Réflexe : capitaliser = un seul modèle de données.
- Code serveur
- Code exécuté sur le serveur web, sécurisé, avec accès aux données et aux contrôles métier.
Exemple simple : Yacine y vérifie le prix catalogue et le stock disponible.
Ce que ce n'est pas : confier la validation à la page affichée.
Réflexe : serveur = décision et sécurité.
- Code navigateur
- Code exécuté dans le navigateur de l'utilisateur : visible, modifiable, utile au confort seulement.
Exemple simple : Yacine y affiche un message de saisie invalide.
Ce que ce n'est pas : y placer un contrôle de prix ou de droit.
Réflexe : navigateur = affichage, jamais protection.
- Session web
- Contexte conservé côté serveur pour reconnaître un utilisateur d'une page à l'autre.
Exemple simple : Yacine mémorise le commercial connecté pendant sa commande.
Ce que ce n'est pas : croire que le web conserve le contexte tout seul.
Réflexe : session = identité et contexte maîtrisés.
En pratique — En pratique — Ouvrir un portail web avec WEBDEV
- Identifiez ce que vous capitalisez (analyse, WLangage, procédures, composants) et ce qui est nouveau (modèle web, sessions, responsive).
- Créez le projet WEBDEV en partageant l'analyse WinDev, puis concevez les pages de consultation du stock et de saisie de commande.
- Placez systématiquement les validations de prix, de stock et de droits dans le code serveur ; gardez le navigateur pour l'affichage et le confort.
- Prévoyez le responsive, l'hébergement HTTPS et une session commerciale, puis testez une requête forgée à la main.
Script pas-à-pas — sécuriser la connexion client (10 min)
Yacine met en place la session du commercial avant d'afficher le tableau de bord.
La session est créée côté serveur ; le navigateur ne reçoit qu'un identifiant de session, jamais le mot de passe.
Modèle copier-coller — mon portail WEBDEV
// Projet WEBDEV — portail de gestion Yacine
// Analyse partagée : Client, Article, Commande, Facture, Stock
// Pages : PAGE_Connexion, PAGE_Stock, PAGE_Commande
// Contrôles SERVEUR : prix catalogue, stock, droits du commercial
// Session : gsCommercialConnecte (côté serveur)
// Responsive : dispositions téléphone / tablette
// Hébergement : serveur WEBDEV + domaine + HTTPSPortail client
Yacine fait consulter à ses clients le stock et l'état de leurs commandes depuis un navigateur.
Intranet commercial
Yacine réserve la saisie de commande aux commerciaux identifiés par une session.
Commande sur mobile web
Yacine rend les pages responsives pour commander depuis un téléphone chez le client.
Analyse partagée
Yacine garde une seule analyse entre l'application WinDev et le portail WEBDEV.
✓ Bonnes pratiques
- Capitaliser sur l'analyse et le WLangage plutôt que de recopier.
- Mettre toute validation critique côté serveur.
- Penser session, responsive et HTTPS dès la conception.
✗ Pièges fréquents
- Placer un contrôle de prix ou de droit dans le navigateur.
- Croire que le web conserve le contexte sans session.
- Traiter l'hébergement et la sécurité après la mise en ligne.
Points clés à retenir
- WEBDEV partage le WLangage, l'analyse et les éditeurs avec WinDev.
- Le navigateur affiche et le serveur traite : la sécurité est côté serveur.
- Le web impose sessions, responsive et hébergement HTTPS.
- Un site public est exposé : la syntaxe familière ne dispense pas du modèle web.
Défi 48h — appliquez demain
Comme Yacine, ouvrez un petit projet WEBDEV en partageant une analyse existante (clients, articles, commandes). Créez une page de consultation et une page de saisie, puis placez un contrôle de prix et de stock côté serveur. Testez une requête forgée à la main et vérifiez qu'elle est refusée. Notez ce que vous avez réutilisé et ce qui était vraiment nouveau.
- Je peux expliquer ce que WEBDEV réutilise depuis WinDev.
- Je sais distinguer code serveur et code navigateur.
- Je sais pourquoi et comment valider une commande côté serveur.
Questions fréquentes
Un développeur WinDev peut-il passer facilement à WEBDEV ?
Le passage est facilité par le même WLangage, la même analyse et les mêmes éditeurs, mais il n'est pas immédiat : il faut apprendre le modèle web. Ce qui se transfère directement : le langage, le modèle de données, les fonctions HFSQL et SQL, les procédures, les composants et les concepts. Ce qui doit être appris : l'architecture serveur/navigateur, la sécurité côté serveur, les sessions, le responsive, l'hébergement (serveur, domaine, HTTPS), les performances et le référencement. Yacine réutilise son analyse de gestion mais repense la manière dont les pages se chargent et dont les droits sont vérifiés.
Pourquoi ne faut-il jamais faire de contrôle de sécurité côté navigateur ?
Parce que tout ce qui s'exécute dans le navigateur est sous le contrôle de l'utilisateur : il peut lire le code, le modifier, le désactiver ou envoyer directement une requête au serveur sans passer par les pages. Un contrôle côté navigateur est donc un confort d'utilisation, jamais une protection. Si Yacine vérifie un prix uniquement dans la page, un utilisateur peut envoyer un prix inférieur au catalogue. La règle absolue : toute validation qui compte (prix, stock, droits, montants, identifiants) est refaite côté serveur, sans exception.
Où vérifier le stock avant d'enregistrer une commande WEBDEV ?