Django - CRUD et admin intégré

Pourquoi Django ici ?

Contrairement à Flask, Django fournit une interface d'administration générée automatiquement à partir de vos modèles : CRUD, authentification, permissions, recherche et filtres — sans rien coder à la main. C'est la fonctionnalité qui justifie souvent son choix pour un panel d'admin de production, en particulier pour gérer des utilisateurs et des données sensibles dès l'initialisation d'un site.

1. Installation et création du projet

pip3 install django
django-admin startproject monsite
cd monsite
python3 manage.py startapp core

• startproject crée la structure globale (settings, urls racine).
• startapp core crée une application : dans Django, un projet est composé d'une ou plusieurs apps modulaires.
• Ici, core contiendra les tables liées à la sécurité et à l'initialisation du site.

2. Déclarer l'app dans les settings

Dans monsite/settings.py, ajoutez 'core' à la liste INSTALLED_APPS :

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'core',
]

3. Définir un modèle (core/models.py)

from django.db import models

class Utilisateur(models.Model):
    nom = models.CharField(max_length=100)
    email = models.EmailField(unique=True)
    role = models.CharField(max_length=50, choices=[
        ('admin', 'Administrateur'),
        ('editeur', 'Éditeur'),
        ('lecteur', 'Lecteur'),
    ])
    actif = models.BooleanField(default=True)
    date_creation = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return self.nom

4. Enregistrer le modèle dans l'admin (core/admin.py)

from django.contrib import admin
from .models import Utilisateur

@admin.register(Utilisateur)
class UtilisateurAdmin(admin.ModelAdmin):
    list_display = ('nom', 'email', 'role', 'actif', 'date_creation')
    list_filter = ('role', 'actif')
    search_fields = ('nom', 'email')

5. Créer les migrations et la base

python3 manage.py makemigrations
python3 manage.py migrate

Cette dernière commande crée aussi les tables système de Django (utilisateurs, permissions, sessions) — c'est là que l'authentification native prend forme.

6. Créer un superutilisateur

python3 manage.py createsuperuser

Mot de passe faible

Si Django juge le mot de passe saisi trop faible, il affiche un avertissement et demande une confirmation (Bypass password validation and create user anyway? [y/N]). En développement local, répondre y pour continuer.

7. Lancer le serveur

python3 manage.py runserver

Rendez-vous ensuite sur :

http://127.0.0.1:8000/admin/

Ne pas oublier le /admin/

Sur http://127.0.0.1:8000/ seule, Django affiche sa page d'accueil par défaut (« The install worked successfully! ») car aucune URL n'y est configurée. C'est normal — l'interface utile se trouve sur /admin/.

Vous êtes alors connecté avec le superuser, et vous voyez déjà l'interface CRUD complète pour le modèle Utilisateur, plus la gestion native des groupes et permissions.

Dépannage : connexion refusée à l'admin

« That username is already taken » lors de createsuperuser

Ce message confirme qu'un utilisateur avec ce nom existe déjà en base — le problème n'est donc pas la création, mais le mot de passe utilisé pour se connecter.

Solution : réinitialiser le mot de passe de l'utilisateur existant

python3 manage.py changepassword <votre_username>

Django demande un nouveau mot de passe deux fois, sans repasser par la création.

Vérification via le shell Django, si le doute persiste :

python3 manage.py shell

from django.contrib.auth.models import User
u = User.objects.get(username='<votre_username>')
print(u.is_active, u.is_superuser)

• is_active doit être True (un compte désactivé bloque la connexion même avec le bon mot de passe).
• is_superuser doit être True (sinon pas d'accès à /admin/).

Correction si besoin :

u.is_active = True
u.save()

Ce qui mérite attention

Cette progression (settings → app → model → admin → migration) est un excellent squelette pédagogique : chaque étape est courte, testable indépendamment, et illustre bien la philosophie « convention over configuration » de Django — à l'opposé de l'explicite total de Flask.

Un bon parallèle avec les exercices PHP/PDO existants, où la mécanique CRUD est montrée à nu : ici, Django montre ce que donne la même mécanique une fois industrialisée, avec authentification et permissions déjà pensées dès la conception du modèle.