Administration Django : de la première connexion aux bons réglages de ModelAdmin

Administration Django : de la première connexion aux bons réglages de ModelAdmin

L’administration Django permet de consulter, ajouter, modifier et supprimer des données sans développer toutes les pages de gestion. Pour l’utiliser, il faut raccorder ses URL, préparer la base de données, créer un compte autorisé et enregistrer les modèles concernés. Cette interface est destinée aux équipes internes : elle ne remplace pas, à elle seule, une application conçue pour vos clients.

Une interface fondée sur les modèles, pas sur vos parcours métier

Le site d’administration exploite les métadonnées des modèles Django pour construire des listes et des formulaires. Les champs, leurs types et leurs relations servent de base aux écrans proposés. Un modèle représentant un livre peut ainsi disposer d’une liste d’ouvrages et d’un formulaire permettant de renseigner son titre et son auteur.

Testez vos connaissances sur l’administration Django

Répondez aux sept questions, puis validez pour découvrir votre score et les corrections.

Réponses sélectionnées : 0 sur 7 Score : en attente de validation
1. Quel est le rôle principal de l’administration Django ?
2. Quelle affirmation distingue correctement admin.site.urls de manage.py ?
3. Dans quel ordre exécute-t-on habituellement ces commandes pour préparer puis lancer le projet ?
4. Que faut-il faire pour qu’un modèle apparaisse dans l’administration Django ?
5. À quoi sert une classe dérivée de ModelAdmin ?
6. Que signifie l’attribut is_staff pour un utilisateur Django ?
7. Quel est l’effet des permissions dans l’administration Django ?

Après validation, les bonnes réponses et les explications s’affichent sous chaque question.

Il couvre les opérations CRUD : création, lecture, mise à jour et suppression. C’est particulièrement utile pour préparer des données de test, corriger un enregistrement ou confier la gestion d’un catalogue à une équipe de confiance.

La distinction importante est celle-ci : l’administration présente vos données, tandis qu’une interface métier accompagne une tâche. Valider une commande avec plusieurs contrôles successifs ou guider un client dans une inscription justifie souvent des vues personnalisées. À l’inverse, corriger le nom d’un auteur convient parfaitement à l’administration native.

Deux outils portent par ailleurs des noms proches sans remplir le même rôle : le site admin fonctionne dans le navigateur ; django-admin et manage.py exécutent des commandes dans le terminal. Ces commandes préparent et entretiennent le projet, mais ne constituent pas son interface web.

Préparer le projet et ouvrir /admin/

Un projet créé avec la structure standard de Django contient généralement les réglages nécessaires. Si vous avez allégé ou personnalisé sa configuration, vérifiez les éléments suivants avant de chercher un problème de connexion.

Guide officiel pour utiliser et personnaliser l’admin Django : Apprenez à activer, configurer et personnaliser l’interface d’administration de Django grâce à cette documentation de référence.

  • Dans INSTALLED_APPS : django.contrib.admin et ses 4 dépendances, django.contrib.auth, django.contrib.contenttypes, django.contrib.messages et django.contrib.sessions.
  • Dans TEMPLATES : un moteur DjangoTemplates et les 3 processeurs de contexte request, auth et messages, issus respectivement de django.template.context_processors, django.contrib.auth.context_processors et django.contrib.messages.context_processors.
  • Dans MIDDLEWARE : les 3 composants SessionMiddleware, AuthenticationMiddleware et MessageMiddleware, avec les sessions placées avant l’authentification.
  • Dans la configuration des URL : une route vers admin.site.urls.

Dans le fichier urls.py du projet, les imports sont from django.contrib import admin et from django.urls import path. La liste urlpatterns doit ensuite contenir path("admin/", admin.site.urls). Ce raccordement rend l’administration accessible sous le chemin /admin/ ; vous pouvez choisir un autre préfixe.

Exécuter les commandes dans le bon ordre

  1. Depuis le dossier contenant manage.py, lancez python manage.py migrate pour appliquer les migrations, notamment celles des comptes et des sessions.
  2. Exécutez python manage.py createsuperuser, puis renseignez les informations demandées.
  3. Démarrez le serveur de développement avec python manage.py runserver.
  4. Ouvrez http://127.0.0.1:8000/admin/ dans votre navigateur et connectez-vous.

Le super-utilisateur permet de vérifier rapidement le fonctionnement de l’ensemble. Pour l’usage quotidien, préférez ensuite des comptes dotés uniquement des droits nécessaires. Le serveur runserver reste un outil de développement, pas une solution de mise en production.

manage.py utilise les commandes de Django tout en définissant le module de réglages du projet via DJANGO_SETTINGS_MODULE. Avec django-admin, ce contexte doit être fourni autrement si la commande en a besoin. Pour débuter dans un projet existant, manage.py est donc généralement le point d’entrée le plus simple.

Enregistrer un modèle et vérifier les opérations disponibles

Créer un modèle ne suffit pas à le faire apparaître dans l’administration. Il faut aussi l’enregistrer auprès du site, généralement depuis le fichier admin.py de son application. Cette application doit elle-même figurer dans INSTALLED_APPS.

Pour un modèle Book déjà défini dans models.py, ajoutez les imports from django.contrib import admin et from .models import Book, puis l’instruction admin.site.register(Book). Cet enregistrement simple suffit pour obtenir une première interface de gestion. N’enregistrez pas une seconde fois le même modèle sur le même site.

Si le modèle vient d’être créé ou modifié, exécutez d’abord python manage.py makemigrations, puis python manage.py migrate. L’enregistrement dans admin.py détermine sa présence dans l’interface ; les migrations mettent à jour la structure de la base. Ce sont deux opérations distinctes.

Une fois connecté, ouvrez la liste du modèle, ajoutez un enregistrement et vérifiez le formulaire généré. Les relations peuvent proposer la sélection d’objets associés. Une méthode __str__ pertinente sur vos modèles rend ces choix plus lisibles qu’un simple identifiant technique.

Testez ensuite la modification et la suppression sur des données sans risque. Les boutons disponibles dépendent des permissions du compte : l’absence d’une opération n’indique pas nécessairement un problème de configuration.

Adapter ModelAdmin aux tâches réellement effectuées

Une classe ModelAdmin configure la présentation d’un modèle sans changer sa structure en base. Elle devient utile dès que la liste standard oblige les utilisateurs à ouvrir chaque fiche ou que le formulaire affiche trop de champs.

Pour l’utiliser, créez dans admin.py une classe héritant de admin.ModelAdmin, puis associez-la au modèle avec admin.site.register(Book, BookAdmin). L’autre possibilité est de placer le décorateur @admin.register(Book) au-dessus de la classe BookAdmin. Choisissez une seule de ces méthodes.

BesoinOptionApplication concrète
Choisir les colonneslist_displayAfficher le titre et l’auteur dans la liste.
Rechercher et filtrersearch_fields, list_filterRechercher un titre et filtrer sur un champ adapté.
Organiser le formulairefields ou excludeChoisir et ordonner les champs, ou en retirer certains.
Naviguer par datedate_hierarchyExplorer les objets selon un champ de date existant.
Clarifier les valeurs absentesempty_value_displayAfficher un libellé explicite à la place d’une valeur vide.

Par exemple, si Book possède les champs title et author, la classe peut définir list_display = ("title", "author") et search_fields = ("title",). Les noms doivent correspondre à votre modèle ; un exemple recopié avec des champs inexistants ne fonctionnera pas.

Pensez à la liste comme à une vigie : elle devrait faire apparaître les anomalies avant même l’ouverture d’une fiche. Afficher une date manquante, un statut ou un responsable permet de repérer un dossier oublié. Le bon choix de colonnes ne sert donc pas seulement à lire les données, mais à détecter ce qui réclame une intervention.

Les actions d’administration permettent aussi de traiter une sélection d’objets. Réservez les opérations en masse à des usages clairement définis, avec des contrôles de permission et des retours compréhensibles. Une action de publication ne doit pas contourner les validations exigées ailleurs dans l’application.

Diagnostiquer les blocages et limiter les privilèges

Une erreur 404 sur /admin/ invite d’abord à vérifier le routage, le préfixe choisi et le serveur effectivement interrogé. Si la connexion échoue, contrôlez les identifiants, puis les attributs du compte : l’accès standard exige un utilisateur actif disposant de is_staff.

Le statut is_staff ouvre l’accès à l’administration, mais n’accorde pas automatiquement tous les droits sur les modèles. Attribuez les permissions de consultation, d’ajout, de modification et de suppression selon les responsabilités, éventuellement au moyen de groupes. Un modèle absent peut ainsi révéler un enregistrement manquant, une application non installée ou des permissions insuffisantes.

Avant de livrer l’outil, testez-le avec un compte non super-utilisateur représentatif de chaque rôle. Vérifiez ce qu’il voit et ce qu’il peut réellement modifier. En production, utilisez HTTPS, protégez les identifiants et conservez une configuration de déploiement adaptée.

Enfin, si les utilisateurs doivent mémoriser une succession de manipulations pour accomplir une seule tâche, réévaluez le choix d’interface. Personnalisez ModelAdmin pour mieux gérer les données ; créez des vues dédiées pour guider un processus.