4.2Sécurité, droits utilisateurs & groupware
L'essentiel en 30 secondes
- Le Groupware Utilisateur de WinDev fournit clé en main l'authentification, la gestion des utilisateurs et des groupes, et les droits jusqu'au niveau des fenêtres et des champs — un gain considérable face à un développement maison.
- Règle d'or : le moindre privilège — chacun n'a que les droits strictement nécessaires ; on raisonne par groupes (profils métier) et l'on ne stocke jamais un mot de passe en clair (empreinte/hachage).
- ⚠️ La sécurité de l'interface ne suffit pas : masquer un bouton n'empêche pas d'accéder aux données autrement — il faut aussi sécuriser côté données (droits HFSQL Client/Serveur, contraintes), tracer les opérations sensibles et protéger les sauvegardes.
Mini-cas filé — Yacine verrouille les droits de son négoce
Yacine, développeur WinDev dans une PME de négoce de matériel électrique à Oran, doit préparer l'application à la mise en production. Aujourd'hui, tout le monde peut tout faire : un magasinier peut valider une remise, un commercial peut supprimer une facture. Yacine active le Groupware Utilisateur : il crée des groupes qui suivent les rôles réels — commercial, magasinier, comptable, responsable, administrateur — et applique le moindre privilège, chaque groupe n'obtenant que le nécessaire. Il sait que masquer un bouton dans l'interface ne suffit pas : il sécurise aussi côté données (droits HFSQL Client/Serveur) et centralise les règles métier dans des procédures pour que les imports en bénéficient. Il trace les opérations sensibles (qui a modifié quoi, quand) pour l'audit, protège les sauvegardes et garde les mots de passe sous forme d'empreinte. Il note le réflexe : un système de droits trop fin devient ingérable — donc peu sûr ; commencer simple puis affiner là où le besoin est réel.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 4.2.
1. Le Groupware Utilisateur
La sécurité d'une application de gestion couvre plusieurs dimensions : qui peut se connecter, qui peut voir quoi, qui peut faire quoi, et comment les données sont protégées. WinDev propose le Groupware Utilisateur, un module intégré qui apporte clé en main une authentification (identifiant/mot de passe), une gestion des utilisateurs et des groupes, et surtout la définition des droits jusqu'au niveau des fenêtres et des champs : tel groupe ne voit pas ce bouton, tel autre a ce champ en lecture seule. C'est un gain de temps considérable par rapport à un développement maison, et cela couvre le besoin classique des applications d'entreprise.
2. Les principes de sécurité
Indépendamment de l'outil, on respecte quelques principes. (1) Le moindre privilège : chacun n'a que les droits strictement nécessaires — la règle d'or. (2) Ne jamais stocker de mot de passe en clair : on conserve une empreinte (hachage). (3) La sécurité de l'interface ne suffit pas : masquer un bouton n'empêche pas d'accéder aux données autrement — il faut sécuriser aussi côté données (droits HFSQL Client/Serveur, contraintes). (4) Tracer les opérations sensibles (qui a modifié quoi, quand), indispensable pour l'audit et les litiges. (5) Chiffrer ce qui doit l'être et protéger les sauvegardes : une sauvegarde volée, c'est toute la base volée.
3. Groupes, simplicité, légal
En pratique, on raisonne par groupes (profils métier) plutôt que personne par personne : les arrivées, départs et changements de poste se règlent par une simple affectation. On applique le moindre privilège avec des règles simples (consulter / créer-modifier / supprimer / valider / administrer) et on n'ajoute de la finesse que là où le besoin est réel : un système de droits trop complexe finit mal administré, donc peu sûr. Enfin, la protection des données personnelles relève d'obligations légales qui varient selon les pays (RGPD en Europe, législations locales ailleurs) : informez-vous sur le droit applicable et faites-vous conseiller — ce guide n'est pas un avis juridique.
🔎 Exemple concret — 🔎 Exemple concret — Authentifier et vérifier un droit
Le squelette d'une authentification et d'un contrôle de droit, comme celui de Yacine :
// Authentifier l'utilisateur via le Groupware Utilisateur
SI gpwOuvre("CnxNegoce") ET gpwConnecte(sLogin, sMotDePasse) ALORS
// Contrôler un droit AVANT l'action sensible
SI gpwDroit("FACTURE", gpwSuppression) ALORS
// ... suppression de la facture autorisée ...
SINON
Info("Votre profil ne permet pas de supprimer une facture.")
FIN
SINON
Erreur("Identifiant ou mot de passe incorrect.")
FIN
gpwFerme()Lecture : l'authentification identifie qui agit ; le contrôle de droit décide si l'action est permise — au niveau du rôle, pas seulement de l'écran.
Leçon : on vérifie le droit dans le traitement (et côté données), pour que les imports et traitements par lot bénéficient des mêmes contrôles.
Vocabulaire de la section
- Groupware Utilisateur
- Module intégré de WinDev apportant clé en main l'authentification, la gestion des utilisateurs et groupes, et les droits jusqu'aux fenêtres et champs.
Exemple simple : Yacine active le Groupware Utilisateur pour son application de négoce.
Ce que ce n'est pas : un développement maison de la sécurité, long et risqué.
Réflexe : droits clé en main → le Groupware Utilisateur.
- Moindre privilège
- Chacun ne dispose que des droits strictement nécessaires à son travail — limite les dégâts en cas d'erreur ou de compte compromis.
Exemple simple : Le magasinier de Yacine ne peut pas valider une remise.
Ce que ce n'est pas : donner à tous les droits d'administrateur « pour simplifier ».
Réflexe : juste le nécessaire → le moindre privilège.
- Mots de passe (⚠️)
- Ne jamais stocker un mot de passe en clair : on conserve une empreinte (hachage).
Exemple simple : Yacine vérifie que les mots de passe sont hachés côté base.
Ce que ce n'est pas : un fichier de mots de passe en clair, faille majeure.
Réflexe : protéger les identifiants → l'empreinte.
- Sécurité côté données
- Masquer un bouton ne suffit pas : il faut aussi sécuriser au niveau des données (droits HFSQL Client/Serveur, contraintes).
Exemple simple : Yacine définit les droits côté serveur, pas seulement à l'écran.
Ce que ce n'est pas : compter uniquement sur l'interface pour protéger les données.
Réflexe : vraie barrière → la sécurité côté données.
- Traçabilité
- Enregistrer qui a fait quoi et quand sur les opérations sensibles, pour l'audit, les litiges et le diagnostic d'incidents.
Exemple simple : Yacine journalise les suppressions de factures.
Ce que ce n'est pas : aucune trace des modifications sensibles.
Réflexe : pouvoir auditer → la traçabilité.
En pratique — En pratique — Sécuriser son application
- Mettez en place l'authentification et les groupes d'utilisateurs (Groupware Utilisateur) en appliquant le moindre privilège : chacun n'a que le nécessaire, comme Yacine.
- Ne stockez jamais de mot de passe en clair (empreinte) et sécurisez aussi côté données (droits HFSQL Client/Serveur), pas seulement dans l'interface.
- Tracez les opérations sensibles (qui, quoi, quand) pour l'audit et le diagnostic, et chiffrez les échanges et données sensibles.
- Protégez les sauvegardes (une sauvegarde volée = toute la base volée) et vérifiez vos obligations légales sur les données personnelles dans votre pays.
Script pas-à-pas — sécuriser comme Yacine (5 min)
1) Activez le Groupware Utilisateur et connectez un premier administrateur. 2) Créez les groupes correspondant aux rôles réels (commercial, magasinier, comptable, responsable, administrateur). 3) Affectez à chaque groupe les droits strictement nécessaires (consulter / créer-modifier / supprimer / valider / administrer). 4) Ajoutez un contrôle de droit sur une opération sensible (suppression de facture). 5) Sécurisez aussi côté HFSQL Client/Serveur et journalisez les opérations sensibles. 6) Protégez les sauvegardes et vérifiez vos obligations sur les données personnelles.
Commencez par des règles simples et affinez uniquement là où le besoin est réel : un système de droits trop fin devient ingérable, donc peu sûr.
Modèle copier-coller — ma fiche sécurité
Groupware Utilisateur : auth + utilisateurs + groupes, droits clé en main
Moindre privilege : chacun n'a QUE le necessaire
Mots de passe : jamais en clair -> empreinte (hachage)
Interface != securite : securiser AUSSI cote DONNEES (droits HFSQL C/S)
Tracabilite : qui a modifie quoi, quand (audit, litiges)
Sauvegardes : une sauvegarde volee = toute la base volee
Donnees personnelles : obligations LEGALES variables selon les paysGroupes par rôle
Yacine crée commercial, magasinier, comptable, responsable et administrateur, plutôt que des droits personne par personne.
Droit sur une opération
Yacine vérifie le droit de suppression avant de laisser supprimer une facture.
Sécurité côté données
Yacine double le contrôle d'interface par des droits HFSQL Client/Serveur.
Trace d'audit
Yacine journalise les modifications sensibles pour répondre à un contrôle comptable.
✓ Bonnes pratiques
- Raisonner par groupes (rôles métier), pas personne par personne.
- Sécuriser côté données, pas seulement à l'écran.
- Rester simple : un système de droits trop fin devient ingérable.
✗ Pièges fréquents
- Croire que masquer un bouton suffit à sécuriser.
- Stocker un mot de passe en clair (faille majeure).
- Accorder les droits d'administration « pour simplifier ».
Points clés à retenir
- Le Groupware Utilisateur apporte clé en main l'authentification, les groupes et les droits jusqu'aux fenêtres et champs.
- Règle d'or : le moindre privilège, et jamais de mot de passe en clair.
- ⚠️ La sécurité de l'interface ne suffit pas : sécuriser aussi côté données.
- Tracer les opérations sensibles et protéger les sauvegardes ; les données personnelles relèvent du droit local.
Défi 48h — appliquez demain
Comme Yacine, activez le Groupware Utilisateur sur votre application et créez au moins trois groupes correspondant à de vrais rôles métier. Appliquez le moindre privilège : vérifiez qu'un membre d'un groupe ne peut pas exécuter une action hors de son rôle. Ajoutez un contrôle de droit sur une opération sensible (suppression, validation) et vérifiez que le contrôle tient même hors de l'interface (côté données). Écrivez enfin en une phrase ce que vous tracez pour l'audit.
- Je crée des groupes par rôle et j'applique le moindre privilège.
- Je sécurise les données au bon niveau, pas seulement à l'écran.
- Je trace les opérations sensibles et protège les sauvegardes.
Questions fréquentes
Pourquoi la sécurité au niveau de l'interface ne suffit-elle pas ?
Parce que l'interface n'est qu'un chemin vers les données : masquer un bouton ou griser un champ empêche l'utilisateur normal d'agir, mais n'empêche pas d'atteindre la base autrement — accès direct, outil d'administration, connexion ODBC, fichiers copiés, export, sauvegarde récupérée, ou un import de votre propre application qui n'a pas les mêmes contrôles. La vraie barrière est au niveau des données (droits HFSQL Client/Serveur, contraintes d'intégrité) et dans des règles métier centralisées, pour que les traitements par lot en bénéficient aussi.
Comment gérer les droits utilisateurs sans complexifier à l'excès ?
En raisonnant par groupes (profils métier) plutôt que par personne, en appliquant le moindre privilège avec des règles simples, et en n'ajoutant de la finesse que là où le besoin est réel. Créez des groupes qui suivent les rôles (commercial, comptable, magasinier, responsable, administrateur) ; les personnes y sont rattachées, si bien qu'une arrivée ou un départ se règle en une affectation. Distinguez cinq niveaux essentiels : consulter, créer-modifier, supprimer, valider, administrer. Un système trop fin devient ingérable — et l'administration chaotique crée des failles : la complexité est ennemie de la sécurité.
Pourquoi sécuriser seulement l'interface d'une application ne suffit-il pas ?