Edualc's Blog

Django -01- gestion des utilisateurs

edualc — 2026-09-01T17:06:13Z

https://contentgardeningstudio.com/python/gerer-des-comptes-utilisateurs-et-profils-personnalises-pour-votre-site-django/

https://openclassrooms.com/fr/courses/7192426-allez-plus-loin-avec-le-framework-django/7386368-personnalisez-le-modele-utilisateur

Notre ambition est de publier notre site. Mais pour qui et pour y faire quoi ? Nous voulons en rendre certaines parties publiques et d'autres restreintes à des personnes choisies. Nous pouvons aussi donner des droits pour certaines parties du site, à des personnes autorisées, tels que créer ou modifier tel ou tel article, telle ou telle donnée.

Après avoir créé un projet lors de l'installation de Django, nous allons construire une application d'authentification à partir de ces premiers principes : les utilisateurs pourront se connecter et se déconnecter de notre application web.

Django fournit un modèle d'utilisateurs, mais il peut ne pas répondre à tous nos besoins. Par exemple, nous pourrions vouloir ajouter des champs supplémentaires comme une photo de profil ou des liens vers des réseaux sociaux. Dans ces cas, il est recommandé de créer un modèle d'utilisateur personnalisé.

Le modèle User¶

class models.User

username¶ Obligatoire. Au maximum 150 caractères. Les noms d'utilisateur peuvent contenir des caractères alphanumériques (_, @, +, . et -).
first_name¶ Facultatif (blank=True). 150 caractères ou moins.
last_name¶ Facultatif (blank=True). 150 caractères ou moins.
email¶ Facultatif (blank=True). Adresse électronique.
password¶ Obligatoire. Une empreinte avec métadonnées du mot de passe (Django ne stocke pas le mot de passe en clair). La longueur des mots de passe réels n'est pas limitée, ni les caractères qu'ils contiennent. Les métadonnées de ce champ peuvent aussi marquer le mot de passe comme inutilisable. Voir la documentation sur les mots de passe.
groups¶ Une relation plusieurs-à-plusieurs vers Group.
user_permissions¶ Une relation plusieurs-à-plusieurs vers Permission.
is_staff¶ Valeur booléenne. Permet à cet utilisateur d'accéder au site d'administration.
is_active¶ Valeur booléenne. Marque ce compte utilisateur comme actif. Nous recommandons de définir ce drapeau à False au lieu de supprimer le compte. Ainsi, si vos applications comportent des clés étrangères vers des utilisateurs, les clés étrangères ne seront pas cassées.

Ceci ne détermine pas forcément si l'utilisateur peut se connecter ou non. Les moteurs d'authentification ne sont pas obligés de vérifier le drapeau is_active, mais le moteur par défaut (ModelBackend) et le moteur RemoteUserBackend le font. Vous pouvez utiliser AllowAllUsersModelBackend ou AllowAllUsersRemoteUserBackend si vous voulez autoriser les utilisateurs inactifs à se connecter. Dans ce cas, vous devrez aussi adapter le formulaire AuthenticationForm utilisé par la vue LoginView car il rejette les utilisateurs inactifs. Soyez conscient que les méthodes de contrôle des permissions telles que has_perm() ainsi que l'authentification dans le site d'administration de Django renvoient toutes False pour les utilisateurs inactifs.

is_superuser¶ Valeur booléenne. Considère cet utilisateur comme ayant toutes les permissions sans devoir lui en attribuer aucune en particulier.
last_login¶ Horodatage de la dernière connexion de l'utilisateur.
date_joined¶ L'horodatage de la création du compte.

Quatre possibilités s'offrent à nous :
1 - Ne rien faire. Django nous offre déjà une solution acceptable
2 - Compléter la solution offerte par Django en ajoutant des champs au modèle fourni par Django
3 - Compléter la solution offerte par Django créant un enregistrement en relation 1 à 1
4 - Partir d'une page blanche et tout définir nous-même.

Nous choisirons les solutions 2 et 3, c-à-d compléter la solution existante et créer un enregistrement qui complétera les données de base

Création de l'application authentification

Les données Django
https://docs.djangoproject.com/fr/6.1/ref/contrib/auth/#fields
Pour créer un modèle d'utilisateur personnalisé, vous devez créer une classe qui hérite de la classe abstraite

il faut installer Pillow
python -m pip install Pillow

>> python manage.py migrate

Débuts

edualc — 2026-09-01T16:24:00Z

Initiation à Affinity (Photo)

SQLAlchemy - Opérations CRUD avec les Sessions SQLAlchemy

edualc — 2026-08-22T14:37:45Z

La Session est le composant central de l'ORM SQLAlchemy. Elle implémente le pattern Unit of Work : les modifications sont accumulées en mémoire puis envoyées à la base de données en une seule transaction lors du commit(). Cette approche garantit la cohérence des données et optimise les performances en regroupant les opérations.

 from sqlalchemy.orm import sessionmaker # Créer une factory de sessions SessionLocal = sessionmaker(bind=engine_dev) # === CREATE : Ajouter des données === with SessionLocal() as session: # Créer un utilisateur avec des articles alice = Utilisateur( nom="Alice Dupont", email="alice@example.com", articles=[ Article(titre="Introduction à Python", contenu="Python est un langage..."), Article(titre="SQLAlchemy pour débutants", contenu="SQLAlchemy est un ORM...") ] ) session.add(alice) session.commit() print(f"Créé : {alice}") print(f"Articles : {alice.articles}") # Sortie : # Créé : Utilisateur(id=1, nom='Alice Dupont') # Articles : [Article(id=1, titre='Introduction à Python'), Article(id=2, titre='SQLAlchemy pour débutants')] # === READ : Lire des données === with SessionLocal() as session: # Par clé primaire user = session.get(Utilisateur, 1) print(f"Trouvé : {user}") # Avec filtre from sqlalchemy import select stmt = select(Utilisateur).where(Utilisateur.email == "alice@example.com") user = session.execute(stmt).scalar_one() print(f"Par email : {user}") # Sortie : # Trouvé : Utilisateur(id=1, nom='Alice Dupont') # Par email : Utilisateur(id=1, nom='Alice Dupont') # === UPDATE : Mettre à jour === with SessionLocal() as session: user = session.get(Utilisateur, 1) user.nom = "Alice Martin" session.commit() print(f"Mis à jour : {user}") # Sortie : Mis à jour : Utilisateur(id=1, nom='Alice Martin') # === DELETE : Supprimer === with SessionLocal() as session: user = session.get(Utilisateur, 1) session.delete(user) # Supprime aussi les articles (cascade) session.commit() print("Utilisateur et articles supprimés")

L'utilisation du context manager with SessionLocal() as session garantit que la session est correctement fermée, même en cas d'exception. C'est une bonne pratique essentielle qui évite les fuites de connexions. En cas d'erreur pendant le commit, la session effectue automatiquement un rollback.

Remarquez l'utilisation de select() au lieu de session.query(). La méthode session.query() est l'ancienne API 1.x, toujours fonctionnelle mais considérée comme legacy. Le style 2.0 avec select() est plus explicite, plus composable et compatible avec le mode async. Adoptez-le systématiquement pour tout nouveau code.

SQLAlchemy - Définir les Modèles avec le Nouveau Style Déclaratif 2.0

edualc — 2026-08-21T14:30:13Z

tutoriel sqlalchemy
Précédent

SQLAlchemy 2 introduit un nouveau style déclaratif basé sur DeclarativeBase et Mapped. Ce style offre un typage natif complet compatible avec mypy et Pyright

Les annotations de type sont désormais utilisées pour définir les colonnes, ce qui rend le code plus lisible et vérifiable statiquement.

 from datetime import datetime from typing import Optional, List from sqlalchemy import String, ForeignKey, func from sqlalchemy.orm import ( DeclarativeBase, Mapped, mapped_column, relationship, Session ) # Classe de base pour tous les modèles class Base(DeclarativeBase): pass # Modèle Utilisateur class Utilisateur(Base): __tablename__ = "utilisateurs" id: Mapped[int] = mapped_column(primary_key=True) nom: Mapped[str] = mapped_column(String(100)) email: Mapped[str] = mapped_column(String(255), unique=True, index=True) actif: Mapped[bool] = mapped_column(default=True) date_creation: Mapped[datetime] = mapped_column( server_default=func.now() ) # Relation one-to-many vers les articles articles: Mapped[List["Article"]] = relationship( back_populates="auteur", cascade="all, delete-orphan" ) def __repr__(self) -> str: return f"Utilisateur(id={self.id}, nom='{self.nom}')" # Modèle Article class Article(Base): __tablename__ = "articles" id: Mapped[int] = mapped_column(primary_key=True) titre: Mapped[str] = mapped_column(String(200)) contenu: Mapped[str] = mapped_column(String(5000)) publie: Mapped[bool] = mapped_column(default=False) auteur_id: Mapped[int] = mapped_column(ForeignKey("utilisateurs.id")) date_publication: Mapped[Optional[datetime]] = mapped_column( nullable=True ) # Relation many-to-one vers l'utilisateur auteur: Mapped["Utilisateur"] = relationship( back_populates="articles" ) def __repr__(self) -> str: return f"Article(id={self.id}, titre='{self.titre}')" # Créer toutes les tables Base.metadata.create_all(engine_dev) print("Tables créées avec succès !") # Sortie : # CREATE TABLE utilisateurs (...) # CREATE TABLE articles (...) # Tables créées avec succès !

Notez l'utilisation de Mapped[str] au lieu du classique Column(String). Ce nouveau style déclaratif 2.0 apporte plusieurs avantages : autocomplétion dans les IDE, vérification de types statique, et une syntaxe plus concise. Le type Python Optional[datetime] se traduit automatiquement en colonne nullable, tandis que Mapped[str] crée une colonne NOT NULL par défaut.

La directive cascade="all, delete-orphan" sur la relation articles signifie que la suppression d'un utilisateur supprime automatiquement tous ses articles. C'est le comportement souhaité dans la plupart des cas, mais attention en production : vérifiez toujours que les cascades correspondent à votre logique métier.

SQLAlchemy - Créer le Moteur et la Connexion à la Base de Données

edualc — 2026-08-16T15:19:07Z

tutoriel sqlalchemy
Précédant

Engine

Le point de départ de toute application SQLAlchemy est un objet appelé « Engine ».

C'est le point d'entrée de toute interaction avec la base de données dans SQLAlchemy.
Il gère le pool de connexions, le dialecte SQL spécifique au SGBD, et la création des connexions.
Il est généralement créé une seule fois pour un serveur de base de données donné.
Il est configuré à l'aide d'une chaîne d'URL décrivant la manière de se connecter à l'hôte ou au système backend de la base de données.
L'objet Engine est créé à l'aide de la fonction create_engine()

rappel : La syntaxe générale des URL est la suivante : protocole:partie_spécifique

Les URL commencent par un protocole Internet ou autre suivi du caractère deux-points ; la partie_spécifique est souvent constituée d'un nom de domaine et / ou d'un chemin d'accès.
exemples :

https://www.lesoir.be/
sqlite+pysqlite :////mondisque/mesdonnées/mabasededonnées.db

SQLite

Protocole
SQLite se connecte à des bases de données basées sur des fichiers, en utilisant par défaut le module intégré de Python sqlite3, spécifié par sqlite

La DBAPI Python est un pilote tiers qu'utilise SQLAlchemy pour interagir avec une base de données spécifique. Ici, nous utilisons le nom pysqlite qui, dans les usages actuels de Python, désigne l'interface de la bibliothèque standard sqlite3 pour SQLite. Si ce paramètre est omis, SQLAlchemy utilisera une DBAPI par défaut adaptée à la base de données choisie.

Comme SQLite se connecte à des fichiers locaux, l'URL est constituée comme suit :
protocole -> sqlite+pysqlite
partie_spécifique -> la partie « file » de l'URL correspond au nom du fichier de la base de données.

Pour un chemin d'accès relatif, cela nécessite trois barres obliques :
# sqlite :///« path »
# où « path » est relatif
exemple : engine = create_engine("sqlite+pysqlite :///foo.db")

Et pour un chemin de fichier absolu, les trois barres obliques sont suivies du chemin absolu :

# Unix/Mac - 4 barres obliques initiales au total
engine = create_engine("sqlite+pysqlite :////absolute/path/to/foo.db")

# Windows - 3 barres obliques initiales
engine = create_engine("sqlite+pysqlite :///C :\path\to\foo.db")

# Windows alternative using raw string
engine = create_engine(r"sqlite+pysqlite :///C :\path\to\foo.db")

Pour utiliser une base de données SQLite en mémoire (:memory :), spécifiez une URL vide :
engine = create_engine("sqlite+pysqlite ://")

Lazy Connecting

L'objet Engine, tel qu'il est renvoyé par create_engine(), n'a pas encore tenté de se connecter à la base de données ; cette connexion ne s'établit que lorsqu'il est sollicité pour la première fois pour effectuer une opération sur la base. Il s'agit d'un modèle de conception logiciel connu sous le nom d'initialisation paresseuse (*lazy initialization*).

Plus de précisions sur la connexion à SQLite sur SQLite.

PostgreSQL
Créons un moteur pour PostgreSQL (production).

from sqlalchemy import create_engine, text

# PostgreSQL pour la production
engine = create_engine(
"postgresql+psycopg2 ://user:password@localhost:5432/mabase",
pool_size=10, # Connexions maintenues en pool
max_overflow=20, # Connexions supplémentaires autorisées
pool_recycle=3600, # Recyclage des connexions après 1h
pool_pre_ping=True, # Vérification de connexion avant utilisation
echo=False # Désactivé en production
)

Tester la connexion
with engine.connect() as conn :
result = conn.execute(text("SELECT 1"))
print(f"Connexion réussie : result.scalar()")
# Sortie : Connexion réussie : 1

Le paramètre echo=True est indispensable pendant le développement : il affiche chaque requête SQL générée par SQLAlchemy dans la console. Désactivez-le en production pour éviter de polluer les logs. Le pool_pre_ping=True est crucial en production car il vérifie que chaque connexion est encore valide avant de l'utiliser, évitant les erreurs “connection closed” après un redémarrage de la base de données.

La chaîne de connexion suit le format dialect+driver ://user:password@host:port/database. Pour PostgreSQL, le driver par défaut est psycopg2. Pour MySQL, utilisez mysql+pymysql ://. Pour SQLite, la syntaxe sqlite :///fichier.db crée un fichier local, tandis que sqlite :///:memory : crée une base en mémoire (idéale pour les tests unitaires).

Définir les Modèles avec le Nouveau Style Déclaratif 2.0

SQLAlchemy - installation

edualc — 2026-08-16T12:18:06Z

tutoriel sqlalchemy
Créer le Moteur et la Connexion à la Base de Données

Prérequis et Versions Requises pour SQLAlchemy 2

Avant de commencer ce tutoriel SQLAlchemy, assurons-nous que notre environnement de développement respecte les versions minimales suivantes. SQLAlchemy 2.0.49 nécessite Python 3.7 au minimum, mais nous recommandons Python 3.11 ou 3.12 pour bénéficier du typage natif et des performances optimales du runtime.

Étape 1 : Installer SQLAlchemy 2 et Configurer l'Environnement

L'installation de SQLAlchemy 2 se fait en quelques commandes. Commençons par créer un environnement virtuel propre et installer toutes les dépendances nécessaires pour ce tutoriel, y compris les drivers de base de données et les outils de développement.

Mettons à jour PIP
pip install —upgrade pip

Installons SQLAlchemy 2 et les drivers
pip install sqlalchemy
pip install psycopg2-binary # Driver PostgreSQL (facultatif)
pip install aiosqlite # Driver async SQLite
pip install alembic # Migrations de schéma

Vérifions l'installation
python -c "import sqlalchemy ; print(sqlalchemy.__version__)"
# Sortie attendue : 2.0.49 ou plus

Étape 2 : Comprendre l'Architecture Core vs ORM de SQLAlchemy

Contrairement à Django ORM qui fusionne la couche SQL et la couche objet, SQLAlchemy sépare ces deux responsabilités en deux composants distincts : le Core et l'ORM. Cette architecture unique est ce qui distingue SQLAlchemy de tous les autres ORM Python et lui confère sa flexibilité légendaire.

Le Core est un système de construction SQL complet. Il fournit un langage d'expressions SQL pythonique, la gestion des métadonnées de schéma, le pooling de connexions et la coercition de types. Vous pouvez utiliser le Core seul, sans jamais toucher à l'ORM, pour des opérations SQL brutes avec une abstraction propre. C'est idéal pour les scripts de migration de données, les ETL, ou les requêtes complexes de reporting.

L'ORM s'appuie sur le Core pour fournir le mapping objet-relationnel classique : classes Python mappées sur des tables SQL, relations entre objets, chargement différé et eager, et gestion des sessions avec le pattern Unit of Work. L'ORM de SQLAlchemy 2 offre des fonctionnalités de chargement eager avancées pour les collections et objets liés, avec des options pour l'accès individuel, les jointures ou les requêtes par collection, le tout mis en cache dans les sessions.

Caractéristique SQLAlchemy Core SQLAlchemy ORM Django ORM
Approche SQL Expression Language Mapping objet-relationnel Active Record
Flexibilité SQL Totale Élevée (via Core) Limitée
Support async Oui (asyncio natif) Oui (asyncio natif) Partiel (Django 4.1+)
Typage Python Complet Complet Partiel
Dialectes DB 15+ (PostgreSQL, MySQL, SQLite, Oracle…) 15+ (idem) 4 (PostgreSQL, MySQL, SQLite, Oracle)
Introspection de schéma Oui (reflect) Oui (automap) Oui (inspectdb)
Migrations Alembic (séparé) Alembic (séparé) Intégrées

Cette séparation Core/ORM signifie que nous pouvons commencer avec le Core pour des opérations simples, puis adopter l'ORM graduellement. Nous pouvons même mélanger les deux dans le même projet : utiliser l'ORM pour les opérations CRUD standard et le Core pour les requêtes analytiques complexes. C'est un avantage majeur par rapport à des ORMs plus légers comme Peewee ou Tortoise ORM, qui offrent moins de contrôle sur le SQL généré.

Créer le Moteur et la Connexion à la Base de Données

API : Définition et Guide Complet

edualc — 2026-07-13T08:03:19Z

https://www.kern-it.be/fr/definitions/api/

https://developer.mozilla.org/fr/docs/Learn_web_development/Extensions/Client-side_APIs/Introduction

https://fastapi.tiangolo.com/fr/

uuid c'est quoi

edualc — 2026-07-13T07:56:37Z

https://developer.mozilla.org/fr/docs/Glossary/UUID

Un UUID (Universally Unique IDentifier) est un identifiant informatique unique à l'échelle mondiale, généré de manière décentralisée sans nécessiter d'autorité centrale. Il se présente généralement sous la forme d'une chaîne alphanumérique de 36 caractères séparés par des tirets (ex : 158c9998-18da-4bef-a8db-4891b1736574)

Les formulaires

edualc — 2026-07-13T06:46:16Z

Le rôle de Django dans les formulaires
La gestion des formulaires est une affaire complexe.
La fonctionnalité des formulaires de Django peut simplifier et automatiser de larges portions de ce travail et peut aussi le faire de manière plus sécurisée que la plupart des programmeurs ne pourraient le faire en écrivant leur propre code.

Django gère trois parties distinctes du travail induit par les formulaires :

préparation et restructuration des données en vue de leur présentation

création des formulaires HTML pour les données

réception et traitement des formulaires et des données envoyés par le client

Il est possible d'écrire du code qui fait tout cela manuellement, mais Django peut s'en charger à votre place.

Django admin

edualc — 2026-07-11T14:09:55Z

ADMIN

Django admin

https://docs.djangoproject.com/fr/5.2/ref/contrib/admin/

grappelli admin

http://www.grappelliproject.com/
https://django-grappelli.readthedocs.io/
https://github.com/sehmaschine/django-grappelli

pip install django-grappelli

Open settings.py and

* add grappelli to your INSTALLED_APPS (before django.contrib.admin) :

INSTALLED_APPS = (
'grappelli',
'django.contrib.admin',
)

* Add the request context processor

TEMPLATES = [

...
'OPTIONS' :
'context_processors' : [
...
'django.template.context_processors.request',
...
],
,
,
]

* Ajouter STATIC_ROOT

STATIC_ROOT = 'static_root/'

Open urls.py and

* Add URL-patterns for grappelli before admin :

urlpatterns = [
path('grappelli/', include('grappelli.urls')), # grappelli URLS
path('admin/', admin.site.urls), # admin site
]

Collect the media files :

python manage.py collectstatic