6.1Cas concrets
L'essentiel en 30 secondes
- Assembler : analyser les données → dessiner les fenêtres → coder en WLangage → générer les états → déployer — c'est l'enchaînement qui fait une application fiable.
- Prouver : une application existe quand les données restent cohérentes (transactions, intégrité), quand elle tourne chez le client et quand elle se met à jour sans perdre une ligne.
- Arbitrer : Classic ou Client/Serveur, mono-poste ou multi-postes, exécutable ou mise à jour automatique : c'est le contexte d'usage qui décide, pas la mode.
Fil Yacine — trois situations, une méthode
Yacine est développeur WinDev dans une PME de négoce de matériel électrique à Oran. Il maintient et fait évoluer l'application maison qui gère clients, produits, commandes, factures et stocks. Il relit trois situations marquantes du trimestre — la construction de l'application de A à Z, le passage de la base Classic au Client/Serveur multi-postes, et le déploiement chez des commerciaux itinérants. Les cas ci-dessous reprennent son enchaînement des niveaux 0 à 5 : analyser, dessiner, coder, interroger, fiabiliser, déployer.
Chaque cas suit le déroulé Contexte → Étapes → Résultat : rejouez-le sur vos propres applications.
Pourquoi des cas concrets
Les niveaux précédents ont posé les briques (analyse, fenêtres, WLangage, HFSQL, requêtes, états, procédures, sécurité, déploiement) ; ici on les assemble de bout en bout. C'est l'enchaînement des bons réflexes — une analyse propre, des champs liés, des requêtes bornées, des transactions et une recette sur machine vierge — qui distingue une application de gestion fiable d'une démo qui marche seulement sur le poste du développeur.
Rejouer de bout en bout
Un cas ne se copie pas : il se rejoue. On reprend l'ordre de la démarche, on adapte au contexte (nombre de postes, volume de données, contraintes du magasin) et on garde la même exigence de preuve à chaque étape.
De l'écran au terrain
Le vrai test d'une application n'est pas « elle s'ouvre chez moi », mais « elle tient dans la durée » : les données restent cohérentes, les droits sont respectés, les sauvegardes existent et une mise à jour ne casse pas l'existant.
Cas 1 — Construire l'application de gestion du négoce de A à Z
Contexte : Yacine doit livrer à sa PME une application qui gère clients, produits, commandes, factures et stocks, avec un suivi simple pour le patron et une saisie rapide au comptoir.
Déroulé :
- Concevoir l'analyse : fichiers, rubriques, liaisons et clés, en pensant intégrité et évolutions futures (N0.4, N1.1).
- Dessiner les fenêtres et les champs, soigner l'ergonomie et le nommage (N1.2).
- Coder les traitements en WLangage : variables, conditions, boucles, événements (N1.3, N2.5).
- Lier les champs aux données et maîtriser les enregistrements (HAjoute, HModifie, HEnDehors) (N1.4).
- Générer une première version avec le RAD, puis produire les états utiles (facture, stock) (N1.5, N2.3).
- Écrire les requêtes et choisir les bons modes de parcours et de tables fichier (N2.2, N2.4).
Résultat : Une application cohérente : analyse solide, fenêtres liées, traitement propre des enregistrements et états générés — une base saine pour les évolutions à venir.
Cas 2 — Faire passer la base de Classic au Client/Serveur
Contexte : L'application tourne d'abord en HFSQL Classic sur un poste. Avec plusieurs utilisateurs au comptoir et au magasin, les ralentissements et les risques de conflits deviennent visibles.
Déroulé :
- Choisir le mode adapté et préparer le passage en HFSQL Client/Serveur (N2.1, N4.1).
- Reprendre les requêtes : filtres côté base, rubriques indexées, requêtes bornées (N2.2).
- Définir les droits et les groupes d'utilisateurs selon les rôles réels (N4.2).
- Encadrer les écritures par des transactions et gérer les blocages en multi-utilisateurs (N4.1).
- Tester la charge et la cohérence avec plusieurs postes simultanés (N4.5).
- Mettre en place les sauvegardes et la restauration avant la bascule (N4.1).
Résultat : Une base partagée fiable : données centralisées, réponses rapides, droits respectés et écritures cohérentes — le multi-postes devient un atout, pas un risque.
Cas 3 — Déployer et maintenir chez des commerciaux itinérants
Contexte : Les commerciaux travaillent sur route et doivent recevoir les nouvelles versions sans informaticien sur place, sans perdre leurs données ni bloquer leur tournée.
Déroulé :
- Préparer l'exécutable et ses dépendances, avec un installeur complet (N4.4).
- Mettre en place l'installation et la mise à jour automatique (N4.4).
- Arbitrer ce qui reste local et ce qui vient du serveur, et gérer la synchronisation (N4.1).
- Sécuriser les accès et les données personnelles des clients (N4.2).
- Recetter chaque version sur une machine vierge avant diffusion (N4.5).
- Suivre les versions et le code avec le gestionnaire de sources (N5.4).
Résultat : Un parc déployé proprement : versions maîtrisées, mises à jour sans perte de données et commerciaux autonomes — la maintenance devient prévisible.
Script prêt à dire — cadrer une application (30 s)
« L'application : [gestion du négoce / passage Client-Serveur / déploiement]. Ma démarche : vérifier l'analyse, dessiner les fenêtres, lier les champs, coder les traitements, générer les états, puis recetter et déployer. »
À garder pour cadrer un projet avec votre direction ou un client.
Script prêt à dire — expliquer sa méthode (30 s)
« Je pars toujours de l'analyse, je lie les champs plutôt que de bricoler à l'écran, je borne mes requêtes et je teste sur une machine vierge avant de livrer — c'est ce qui évite les mauvaises surprises. »
Utile pour expliquer votre démarche sans jargon inutile.
Modèle copier-coller — démarche de construction
1. Analyser : fichiers + rubriques + liaisons + clés
2. Dessiner : fenêtres + champs + ergonomie
3. Coder : WLangage (événements, procédures)
4. Lier : champs <-> rubriques, HAjoute/HModifie/HEnDehors
5. Restituer : requêtes bornées + états
6. Fiabiliser : erreurs + droits + tests
7. Déployer : exécutable + mise à jour + recette machine viergeModèle copier-coller — fiche de recette avant livraison
Version : [x.y] Date : [..]
Analyse modifiée : oui/non (migration testée sur copie)
Données : sauvegarde faite ? oui/non
Parcours testés : connexion, saisie, modification, suppression
Droits vérifiés : profil [comptoir / magasin / patron]
Impression : facture + état de stock OK
Installation testée sur machine vierge : oui/non
Retour arrière prévu : oui/nonTPE / petit budget
Rester en HFSQL Classic sur un ou deux postes, se concentrer sur l'analyse et les états utiles, et ne complexifier que si le besoin est réel.
PME Oran
Adapter aux réalités locales : coupures, postes hétérogènes, contenus et libellés en français, formation rapide des utilisateurs au comptoir.
Remote / multi-sites
Centraliser les données en Client/Serveur, doubler la traçabilité et prévoir une procédure claire de mise à jour à distance.
Interculturel
Expliciter les intitulés avant de transposer : un nom de rubrique ou un libellé évident pour l'un doit parler à tout nouvel arrivant.
Défi 48h — appliquez demain
Prenez une application réelle et rejouez l'enchaînement : analyse vérifiée, fenêtres liées, 1 traitement codé, 1 état généré et 1 test sur machine vierge.
- Je sais enchaîner analyse, fenêtres, code, requêtes, états, fiabilisation et déploiement sur une application réelle.
- J'ai une démarche rejouable (analyse d'abord, champs liés, requêtes bornées, recette machine vierge).
- J'ai fait le défi 48h ou planifié sa date.
Yacine livre l'application du négoce. Quel enchaînement respecte le guide ?