Un modèle utilisateur personnalisé remplace le User par défaut de Django pour adapter votre application — en ajoutant des champs, en changeant l'identifiant de connexion (par exemple email au lieu de username), ou en personnalisant le comportement. Le conseil critique, souvent répété : configurer un modèle utilisateur personnalisé dès le très début d'un projet, même si vous n'avez pas encore besoin de modifications, car le changer plus tard est extrêmement douloureux.
The default User has fixed fields (username, email, first/last name) and uses
USERNAME as the login field. Real apps often need:
✓ Email-based login (no username)
✓ Extra fields (phone, avatar, role, preferences) on the user itself
✓ Custom authentication behavior
⚠️ Changing the user model AFTER migrations exist is VERY hard — the User model is
referenced by auth, admin, sessions, foreign keys throughout the database.
Swapping it later requires complex, risky data migrations.
→ ALWAYS define a custom user model at project START (before the first migration),
even an empty one, so you can extend it freely later. Django's docs strongly
recommend this for EVERY new project.
C'est la leçon pratique clé : configurer un modèle utilisateur personnalisé le premier jour ne coûte presque rien, mais en ajouter un rétroactivement à un projet établi est une entreprise majeure et sujette aux erreurs — vous le faites donc en amont comme assurance.
# models.py — add fields, keep Django's auth behavior
from django.contrib.auth.models import AbstractUser
class User(AbstractUser):
phone = models.CharField(max_length=20, blank=True)
avatar = models.ImageField(upload_to="avatars/", blank=True)
is_premium = models.BooleanField(default=False)
# settings.py — tell Django to use it
AUTH_USER_MODEL = "myapp.User"
AbstractUser conserve tous les champs par défaut de Django et la mécanique d'authentification — vous ajoutez simplement des champs. L'approche la plus simple et la plus courante.
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager, PermissionsMixin
class User(AbstractBaseUser, PermissionsMixin):
email = models.EmailField(unique=True)
USERNAME_FIELD = "email" # log in with EMAIL instead of username
REQUIRED_FIELDS = []
objects = CustomUserManager() # a manager defining create_user/create_superuser
AbstractBaseUser vous donne un contrôle total sur le modèle utilisateur (par exemple en supprimant entièrement username pour une connexion par email uniquement) — plus de travail, mais une flexibilité maximale.
from django.conf import settings
from django.contrib.auth import get_user_model
# in models — reference via settings.AUTH_USER_MODEL
author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
# in code — get the active user model dynamically
User = get_user_model() # NOT a direct import of the default User
Toujours référencer le modèle utilisateur via settings.AUTH_USER_MODEL (dans les modèles) et get_user_model() (dans le code), jamais en important le User par défaut directement — pour que votre code fonctionne avec le modèle personnalisé.
Utiliser un modèle utilisateur personnalisé est une connaissance importante avec une leçon pratique critique, fréquemment soulignée, que tout développeur Django devrait intérioriser : le configurer dès le très début de chaque projet.
La raison pour laquelle cela importe tant est l'asymétrie grave en termes de difficulté — définir un modèle utilisateur personnalisé le premier jour (même une simple sous-classe AbstractUser) coûte presque rien et offre une flexibilité inestimable, tandis que basculer vers un modèle utilisateur personnalisé après que le projet ait des migrations et des données est extrêmement douloureux et risqué, car le modèle User est profondément référencé dans Django (authentification, admin, sessions) et par des clés étrangères dans toute votre base de données, nécessitant des migrations de données complexes et sujettes aux erreurs pour changer.
C'est pourquoi la propre documentation de Django recommande vivement un modèle utilisateur personnalisé pour chaque nouveau projet, quel que soit le besoin immédiat — c'est une assurance contre un cauchemar de migration futur.
Au-delà de ce conseil critique de timing, comprendre comment créer des modèles utilisateur personnalisés — AbstractUser pour ajouter simplement des champs tout en conservant le comportement d'authentification de Django (le cas courant et facile), et AbstractBaseUser pour un contrôle total comme la connexion par email (en supprimant entièrement username) — est précieux pour répondre aux exigences réelles de l'application (champs utilisateur supplémentaires, identifiants de connexion alternatifs, authentification personnalisée).
Également important, savoir référencer le modèle utilisateur correctement (via settings.AUTH_USER_MODEL et get_user_model(), jamais une importation directe) pour que le code fonctionne avec n'importe quel modèle utilisateur configuré.
Parce que presque chaque application réelle a des besoins spécifiques à l'utilisateur au-delà des valeurs par défaut de Django (et même celles qui n'en ont pas bénéficient de la flexibilité), et parce que le coût de ne pas configurer cela tôt est si élevé, comprendre les modèles utilisateur personnalisés — en particulier l'impératif d'en établir un au démarrage du projet — est une connaissance importante et pratiquement critique qui prévient une erreur commune et sérieuse au niveau du projet, ce qui en fait une sagesse de best-practice Django fréquemment citée.