Jour 08 : Définition des rôles utilisateurs et permissions

Créer un site comme Créa-code, pensé pour former, accompagner et motiver des développeurs débutants ou confirmés, nécessite bien plus que de belles interfaces ou des exercices bien construits. L’un des fondements invisibles, mais cruciaux, réside dans la manière dont nous allons gérer les utilisateurs, leurs droits d’accès, et leurs permissions.

Aujourd’hui, nous allons réfléchir à la notion de rôles dans notre site, avant même d’avoir écrit une seule ligne de code. Ce travail en amont vous évitera de futurs pièges et vous garantira une structure claire, sécurisée et évolutive. C’est l’une des clés de tout projet web sérieux.

Pourquoi penser aux rôles si tôt ?

Lorsqu’on démarre un projet web, on a souvent tendance à se concentrer sur le visible : l’interface graphique, les pages, les boutons, les interactions. Pourtant, sous cette couche apparente, se cache une logique d’accès qui régit ce que chaque utilisateur peut ou ne peut pas faire. C’est ce qu’on appelle la gestion des rôles et des permissions.

En pensant aux rôles dès maintenant, vous anticipez les besoins à venir. Vous structurez votre site en tenant compte des différents profils d’utilisateurs, de leur niveau d’accès, et des fonctionnalités auxquelles ils auront droit. Ce choix influence directement :

• la manière dont vous organisez les pages,
• la visibilité de certains éléments,
• le code qui devra vérifier les autorisations,
• et bien sûr, la sécurité globale du site.

Ne pas y réfléchir à temps, c’est risquer de devoir revenir en arrière dans quelques semaines, au prix de nombreuses heures perdues. C’est aussi prendre le risque d’ouvrir la porte à des failles d’accès, ou à des comportements inattendus sur le site. En résumé, définir les rôles au tout début, c’est poser des fondations solides pour tout le reste du projet.

Les trois rôles prévus sur Créa-Code

Pour le site code.crea-troyes.fr, nous avons choisi de faire simple mais efficace. Inutile, dans un premier temps, de multiplier les types de comptes. Trois rôles suffisent pour couvrir tous les besoins fonctionnels du site.

Le visiteur public

C’est toute personne qui arrive sur le site sans être connectée. Il peut s’agir d’un curieux, d’un étudiant en repérage, ou d’un visiteur venu via Google. Ce profil n’a aucun compte et ne bénéficie donc d’aucune personnalisation ni suivi.

Le visiteur public peut consulter la page d’accueil et s’informer sur le concept du site. En revanche, il ne peut pas accéder aux exercices, aux quizz et aux missions (ou challenges) de codage ou aux fonctionnalités sociales (comme les commentaires). S’il souhaite aller plus loin, il devra créer un compte gratuitement.

Le visiteur connecté (ou utilisateur)

Dès lors qu’un visiteur crée un compte gratuit et se connecte, il devient un visiteur connecté. Ce rôle débloque l’ensemble des fonctionnalités de la plateforme.

Il peut ainsi :

• accéder à tous les exercices classés par niveau et par langage,
• enregistrer sa progression,
• gagner des points d’expérience (XP),
• remporter des badges,
• commenter les exercices.

Ce rôle constitue le cœur de la communauté active du site. C’est pour ce profil que nous allons créer une grande partie des contenus interactifs.

L’administrateur

Ce rôle est réservé aux administrateurs. L’administrateur dispose d’un accès complet au back-office du site. Il peut gérer les utilisateurs, modérer les commentaires, créer ou modifier les exercices, visualiser les statistiques de fréquentation, ou encore intervenir en cas de problème.

Ce rôle doit être sécurisé au maximum, car une compromission du compte administrateur peut mettre en danger l’ensemble du site.

Réflexion sur les permissions de chaque rôle

Avant même d’implémenter quoi que ce soit, il est très utile de se poser une question simple : “Qu’a le droit de faire chaque type d’utilisateur ?”

Prenons un exemple concret. Si un utilisateur tente d’accéder à une page d’exercice alors qu’il n’est pas connecté, doit-il voir un message d’erreur ? Une redirection vers la page de connexion ? Une incitation à s’inscrire ?

Ces décisions doivent être claires dès le départ. Elles guideront nos conditions d’affichage dans les templates, nos contrôles côté serveur, et la structure même de notre base de données.

Voici une représentation simplifiée de ces permissions :

Cette grille nous sera très utile dans les semaines à venir. Nous pourrons nous y référer pour implémenter les différents comportements dans nos contrôleurs, nos vues, et nos fonctions PHP.

Choix de la base de données et modélisation

Une fois les rôles définis, nous allons devoir créer une structure de base de données capable de stocker toutes les informations nécessaires à la gestion des utilisateurs.

Pourquoi MySQL ?

Le choix de MySQL (ou de son équivalent libre MariaDB) s’impose naturellement ici pour plusieurs raisons :

• il est parfaitement compatible avec PHP, le langage utilisé pour développer le site,
• il est simple à héberger, que ce soit sur un serveur local (MAMP) ou en production,
• il dispose d’outils graphiques comme phpMyAdmin qui facilitent son utilisation,
• il gère très bien les relations entre tables, ce qui sera essentiel quand nous ajouterons les badges, l’historique des exercices, ou les commentaires.

Pour organiser votre base, nous allons créer une base de données principale nommée creacode. Toutes nos tables y seront regroupées.

Une base de données est un système organisé qui permet de stocker, gérer et retrouver facilement des informations.

Imaginez une grande armoire avec des tiroirs bien rangés : chaque tiroir contient des fiches (ou des enregistrements), et chaque fiche suit un modèle précis (appelé une structure ou un schéma). Cela permet de garder des données claires, accessibles et exploitables rapidement.

Plus concrètement, une base de données peut contenir des utilisateurs, des produits, des commandes, des messages, etc… Elle est utilisée dans presque tous les sites web et applications modernes.

Sur un site comme code.crea-troyes.fr, une base de données peut stocker :

• les comptes utilisateurs (email, mot de passe, avatar…),
• les exercices proposés,
• les réponses des utilisateurs,
• les scores, badges, et niveaux.

Une base de données = une mémoire numérique organisée, indispensable pour développer des sites dynamiques et interactifs.

Des formations informatique pour tous !

Débutant ou curieux ? Apprenez le développement web, le référencement, le webmarketing, la bureautique, à maîtriser vos appareils Apple et bien plus encore…

Formateur indépendant, professionnel du web depuis 2006, je vous accompagne pas à pas et en cours particulier, que vous soyez débutant ou que vous souhaitiez progresser. En visio, à votre rythme, et toujours avec pédagogie.

Découvrez mes formations Qui suis-je ?

Structure complète de la table users

Maintenant que nous avons défini nos trois rôles (visiteur public, utilisateur connecté et administrateur), il est temps de penser à la table principale qui stockera les informations de chaque utilisateur.

Cette table s’appellera tout naturellement users. C’est une table centrale dans notre base, car tout ou presque y sera lié : les exercices réalisés, les points d’expérience, les badges, les commentaires postés, les connexions, etc.

Voici un exemple de structure SQL, suivi d’une explication claire de chaque colonne.

Script SQL de création de la table users

CREATE TABLE users (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    pseudo VARCHAR(50) NOT NULL UNIQUE,
    email VARCHAR(100) NOT NULL UNIQUE,
    mot_de_passe VARCHAR(255) NOT NULL,
    role_id INT UNSIGNED NOT NULL DEFAULT 1,
    date_inscription DATETIME DEFAULT CURRENT_TIMESTAMP,
    xp INT UNSIGNED DEFAULT 0,
    avatar_id TINYINT UNSIGNED DEFAULT 1,
    bio TEXT DEFAULT NULL,
    email_verifie BOOLEAN DEFAULT FALSE,
    token_verification VARCHAR(255) DEFAULT NULL,
    dernier_login DATETIME DEFAULT NULL,
    statut_compte ENUM('actif', 'suspendu', 'supprimé') DEFAULT 'actif',
    FOREIGN KEY (role_id) REFERENCES roles(id),
    FOREIGN KEY (avatar_id) REFERENCES avatars(id)
);

Explication des champs

Prenons le temps de comprendre chaque colonne, en précisant pourquoi elle est utile et comment elle sera utilisée dans le site.

• id : c’est l’identifiant unique de chaque utilisateur. Il est auto-incrémenté, c’est-à-dire que MySQL l’attribue automatiquement à chaque nouveau compte.
• pseudo : c’est le nom que l’utilisateur choisit pour être affiché publiquement. Il doit être unique (deux personnes ne peuvent pas avoir le même pseudo).
• email : c’est l’adresse mail utilisée pour se connecter. Elle doit aussi être unique. C’est également l’adresse à laquelle seront envoyés les emails de confirmation, de réinitialisation de mot de passe, etc.
• mot_de_passe : ce champ stockera le mot de passe chiffré de l’utilisateur. Il ne s’agit jamais de stocker un mot de passe “en clair”. Nous reviendrons sur ce point dans la section sécurité.
• role : ce champ indique si l’utilisateur est un simple utilisateur, un visiteur (rare ici, mais utile si vous créez un compte sans activer l’accès), ou un administrateur.
• date_inscription : stocke la date et l’heure à laquelle l’utilisateur s’est inscrit. Cela vous permettra de suivre l’évolution du site et, à terme, de faire des analyses sur la fidélité des membres.
• xp : il s’agit des points d’expérience que l’utilisateur gagnera au fil des exercices. Vous pouvez utiliser cette valeur pour débloquer des niveaux, accorder des badges, ou simplement afficher une progression.
• avatar_id : ce champ permet de stocker le chemin vers une image de profil choisie par l’utilisateur. S’il est vide, vous pouvez afficher une image par défaut.
• bio : champ optionnel dans lequel l’utilisateur pourra écrire une petite description de lui-même, visible sur sa fiche profil.
• email_verifie : champ de type booléen (vrai/faux), qui vous permettra de vérifier si l’utilisateur a bien confirmé son adresse mail. C’est une bonne pratique pour éviter les comptes spam.
• token_verification : quand un utilisateur crée un compte, vous pouvez générer un jeton de vérification à usage unique, qui sera envoyé par e-mail. Ce champ servira à le stocker temporairement.
• dernier_login : à chaque fois qu’un utilisateur se connecte, vous pouvez enregistrer ici la date et l’heure. C’est utile pour afficher “Dernière connexion : il y a 3 jours” sur le profil, ou détecter les comptes inactifs.
• statut_compte : ce champ permet de savoir si le compte est actif, suspendu (ex : triche), ou supprimé (sans le supprimer vraiment de la base). C’est une méthode souple avec ENUM pour gérer les abus ou les départs.

Pourquoi ne pas stocker les badges dans users ?

Principe de normalisation

En base de données relationnelle, on suit souvent les règles de normalisation pour éviter la duplication d’informations, faciliter les mises à jour et améliorer la lisibilité.

Un utilisateur peut avoir 0, 1, 10 ou 100 badges. Si on stockait cela dans la table users, il faudrait :

• soit une liste de badges dans un seul champ (badges = "html,css,php"), ce qui est contre-productif,
• soit une colonne par badge (badge_html, badge_css, etc.), ce qui est inflexible et lourd.

Ce que l’on veut : une relation de type plusieurs-à-plusieurs. Un utilisateur peut avoir plusieurs badges. Un même badge peut être attribué à plusieurs utilisateurs.

Créer une table users avec le code SQL fourni avec phpMyAdmin

1. Accédez à phpMyAdmin

Ouvrez votre navigateur et tapez http://localhost/phpmyadmin (si vous êtes en local) ou accédez à l’URL de phpMyAdmin de votre hébergeur.
Connectez-vous si nécessaire.

2. Créez une base de données (si ce n’est pas encore fait)

Dans le menu de gauche, cliquez sur « Nouvelle base de données » ou « Créer ».

Dans le champ prévu, entrez un nom simple comme creacode ou mon_projet_web.
Laissez le jeu de caractères par défaut (souvent utf8mb4_general_ci), puis validez en cliquant sur « Créer ».

3. Sélectionnez votre base de données

Dans la colonne de gauche, cliquez sur le nom de la base que vous venez de créer (ou celle que vous utilisez déjà).
Vous accédez alors à une page indiquant qu’il n’y a pas encore de table.

4. Accédez à l’onglet SQL

En haut de l’interface, cliquez sur l’onglet « SQL ».
Un grand champ vide apparaît : c’est ici que vous pouvez coller du code SQL manuellement. Collez le code SQL de la table users.

Ce script va créer une table avec toutes les colonnes utiles pour gérer vos utilisateurs : adresse mail, mot de passe, rôle, avatar, dates d’inscription et de connexion, statut actif, tokens de vérification et de réinitialisation de mot de passe.

5. Exécutez le script

Juste en dessous de la zone de texte, cliquez sur le bouton « Exécuter » (ou « Go » selon la langue).
phpMyAdmin va exécuter le code, et si tout est correct, vous verrez un message de confirmation vert.

6. Vérifiez que la table a été créée

Dans le menu de gauche, la table users s’affiche désormais sous le nom de votre base de données.
Cliquez dessus pour visualiser les colonnes, et accédez à l’onglet « Structure » pour les détails de chaque champ.

La sécurité : un pilier fondamental

Lorsque l’on parle d’utilisateurs et de base de données, la sécurité ne peut pas être une option. Dès que vous stockez des données personnelles, vous avez une responsabilité légale et morale. Voici les points essentiels à garder à l’esprit dès maintenant.

Ne jamais stocker les mots de passe en clair

C’est la base de la sécurité. Dans le champ mot_de_passe, vous ne devez jamais enregistrer le mot de passe brut tel que saisi par l’utilisateur.

Il faudra utiliser une fonction de hachage sécurisé, comme password_hash() en PHP. Cette fonction convertira le mot de passe en une série de caractères incompréhensibles (et non réversible), que vous pourrez ensuite comparer lors de la connexion avec password_verify().

Toujours vérifier les rôles côté serveur

Même si vous cachez certaines fonctionnalités dans l’interface, un utilisateur malveillant peut très bien forcer un lien ou appeler une URL directe. Vous devez donc vérifier le rôle de l’utilisateur dans le code serveur, avant d’exécuter une action sensible (accès admin, suppression d’un exercice, etc.).

Ne pas tout mélanger dans une seule table

Comme vu précédemment, les badges ou les données liées ne doivent pas être intégrés directement dans la table users. Il vaut mieux créer des tables liées. Cela simplifie la gestion, rend les traitements plus rapides, et renforce la sécurité.

Utiliser HTTPS sur l’ensemble du site

Même si cela semble aller de soi, il est impératif que toutes les communications entre les utilisateurs et votre serveur soient chiffrées. Pour cela, il faudra activer un certificat SSL (souvent gratuit via Let’s Encrypt) pour que votre site soit en https://.

En consacrant ce 8e jour à la structure des utilisateurs, nous avons fait un choix stratégique. Vous ne codez pas encore, mais vous construisez des fondations solides. Vous comprenez déjà :

• pourquoi il faut penser aux rôles en amont,
• quels rôles seront présents sur votre site,
• comment organiser proprement les permissions,
• comment modéliser la table users,
• et comment garantir une bonne sécurité de base.

Ce travail, invisible pour les utilisateurs, est pourtant essentiel. C’est lui qui va conditionner la fiabilité, la modularité, et la pérennité de votre projet.

Dans les prochains jours, nous pourrons commencer à concevoir nos premières pages de connexion et d’inscription, ou poser les bases de l’architecture MVC. Et nous le ferons avec une clarté d’esprit et une base de données bien pensée.

Alban

Fondateur de l’agence Créa-troyes.
Intervenant en Freelance.
Contactez-moi

crea-troyes.fr