Edualc's Blog

3 - Wagtail

edualc — 2026-10-25T14:26:40Z

nnn

- Python

2 - Django

edualc — 2026-10-25T14:26:38Z

nnnn

- Python

1 - Python

edualc — 2026-10-25T14:26:34Z

nnnn

- Python

01 - Installation des outils

edualc — 2026-10-25T14:18:31Z

Retour Développement d'un site en Python

Vérification de la présence de python

Python doit être installé sur la machine de développement. Sur une même machine, plusieurs versions de pythons peuvent cohabiter sans problème mais ++++

Ouvrir une fenêtre terminal
Tester la présence de python
— > python3 – version
Suivant la réponse, installer si nécessaire la version voulue de python.

Installation de django

Ouvrir une fenêtre terminal
Mettre à jour l'utilitaire PIP :
— > python -m pip install —upgrade pip
Installer django :
— > python -m pip install django
Contrôler que Django est accessible par Python :
— > python -m django —version
Une réponse telle que 6.1.1 indique la bonne installation de python et de django.

Création du projet

Le projet sera créé dans un répertoire mysite créé lui-même dans le répertoire src
— > django-admin startproject mysite src

+++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++

1. Préparer l'environnement de développement

Assurez-vous d'avoir Python 3 installé sur votre machine.

Création d'un projet :

— > django-admin startproject mysite src
— > cd src
### paramètres : Modifier LANGUAGE_CODE = 'fr-fr' dans les paramètres.
— > python manage.py runserver
— > [CTRL-c]

Utilisons un modèle utilisateur personnalisé :

https://openclassrooms.com/fr/courses/7192426-allez-plus-loin-avec-le-framework-django/7386368-personnalisez-le-modele-utilisateur
— > python manage.py startapp authentication
### paramètres : Ajoutez l'applications aux INSTALLED_APPS dans les paramètres.

Créons une application blog :

— > python manage.py startapp blog
### paramètres : Ajoutez l'applications aux INSTALLED_APPS dans les paramètres.

Etendre AbstractUser :

Nous allons ajouter deux champs supplémentaires :
ImageField contenant une photo de profil,
role , un CharField, qui différenciera les différents types d'utilisateurs
- administrateur
- éditeur
- auteur
- abonné
modifions authentication/models.py
# authentication/models.py
from django.contrib.auth.models import AbstractUser
from django.db import models

class User(AbstractUser) :
"""
On définit des rôles : créateur, abonné, lecteur, ...
On les définit comme des constantes.
On peut ainsi tester si user.role == user.CREATOR, par ex.
"""
AUTEUR = 'AUTEUR'
ABONNE = 'ABONNE'
EDITEUR = 'EDITEUR'
ADMINISTRATEUR = 'ADMINISTRATEUR'

ROLE_CHOICES = (
(AUTEUR, 'auteur'),
(ABONNE, 'abonné'),
(EDITEUR, 'éditeur'),
(ADMINISTRATEUR, 'administrateur'),
)

profile_photo = models.ImageField(verbose_name='Photo de profil')
role = models.CharField(max_length=30, choices=ROLE_CHOICES, verbose_name='Rôle')

Django a besoin du package Pillow pour utiliser ImageField
— > pip install Pillow
— > pip freeze > requirements.txt

### paramètres : Ajoutez AUTH_USER_MODEL = 'authentication.User' dans les paramètres.

Générez et exécutez les migrations initiales :

— > python manage.py makemigrations
— > python manage.py migrate

En résumé

Django utilise le modèle User pour gérer l'authentification.
C'est toujours une bonne idée d'utiliser un modèle User personnalisé
dans un projet, même si nous n'avons pas besoin de fonctionnalités
supplémentaires, car cela permet de faciliter grandement la personnalisation
par la suite.

Nous pouvons étendre AbstractUser pour enrichir le modèle User par défaut.

Nous pouvons étendre AbstractBaseUser si nous voulons encore plus
de flexibilité, et définir tous les champs nous-même.

0 - Développement d'un site en Python

edualc — 2026-10-25T11:37:12Z

Objet

Développer un site web en Python [1], un site web basé sur les outils Django [2] et Wagtail [3]

Python est un langage de programmation.

Django est ce qu'on appelle un framework, c-à-d un ensemble de code servant de base pour créer un site web. Django est basé sur python.

Wagtail est un système de gestion de contenu (CMS) construit entièrement sur Django, le framework web Python.

Cette triade (python – django – wagtail), est un outil puissant pour développer des pages web organisés en sites, projets et applications.

Dans ce projet, plusieurs applications :

Utilisateurs : une application de gestion des utilisateurs et de leurs permissions.

Blog : une application de publication de notes.

Photos : une application de diaporama

D'autres applications viendront se joindre aux premières, et toutes exploiteront la première application, Utilisateurs, pour définir les autorisations d'accès adéquates aux données (autorisations de lecture, création, modifications, etc).

Table des matières

Installation des outils
Installation de l'ossature du projet
Installation de l'application Utilisateurs
Installation des autres applications
Blog
Photos

[1] Python

[2] Django

[3] Wagtail

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 (User). Ce modèle possède de nombreuses méthodes et fonctionnalités spéciales, en particulier en ce qui concerne l'authentification et les permissions, qui lui permettent de s'intégrer automatiquement au framework Django.

La liste des champs du modèle 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.

Mais ce modèle ne répond peut-être pas à 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é.

Utilisons un modèle utilisateur personnalisé

Nous conseillons de toujours implémenter un modèle User personnalisé dans notre projet. Et ce, même s'il est identique au modèle par défaut !

Car il est difficile et compliqué de migrer vers un modèle User personnalisé après la configuration de notre site Django et l'exécution des migrations initiales.

Afin de créer un modèle User personnalisé, Django fournit deux classes de base que nous pouvons étendre pour répondre à nos besoins spécifiques :

AbstractUser

La classe AbstractUser contient tous les champs et les méthodes du User par défaut.

Si les fonctionnalités de la classe User par défaut répondent à nos besoins à elles seules, alors il est vraiment facile de l'utiliser comme modèle User personnalisé :

from django.contrib.auth.models import AbstractUser class User(AbstractUser): pass
Ceci fournit tous les champs et fonctionnalités du modèle User par défaut, avec la souplesse supplémentaire de pouvoir y ajouter des champs et des méthodes par la suite.

Mais que se passe-t-il si nous ne voulons pas utiliser tous les champs fournis dans la classe User par défaut ? Dans ce cas, nous allons plutôt étendre la classe AbstractBaseUser .

AbstractBaseUser

La classe AbstractBaseUser ne contient aucun champ, excepté password (mot de passe). Elle possède aussi une suite de méthodes pour gérer l'authentification (tout comme AbstractUser).

Lorsque nous étendeons AbstractBaseUser, nous devons spécifier tous les champs que nous voulons inclure (sauf password ). Il faut aussi un peu de configuration supplémentaire pour qu'elle s'intègre bien au système d'authentification de Django.

Les configurations clés à implémenter avec le modèle AbstractBaseUser sont les suivantes :

USERNAME_FIELD — indique le nom du champ devant être utilisé comme identifiant de connexion.

EMAIL_FIELD — indique le nom du champ contenant l'adresse e-mail principale d'un utilisateur ('email' par défaut).

REQUIRED_FIELDS — liste des champs à spécifier obligatoirement lors de l'utilisation de la commande python manage.py createsuperuser.

is_active — vaut True par défaut dans AbstractBaseUser, mais nous pouvons ajouter notre propre champ si nous voulons gérer les utilisateurs actifs et inactifs.

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