Créer une application web avec Django en cinq étapes

Une application web Django utile ne commence pas par une page d’accueil ni par une collection de bibliothèques. Elle commence par une action précise qu’un utilisateur doit pouvoir accomplir de bout en bout : créer une demande, publier une annonce, réserver un créneau ou suivre une tâche. Django devient particulièrement efficace lorsqu’il sert ce parcours complet, avec des données fiables, des droits d’accès et un moyen de vérifier que tout continue de fonctionner après chaque modification.

Pourquoi Django reste un choix solide pour un premier produit

Django est un framework Python conçu pour construire des applications web côté serveur. Son idée directrice est souvent résumée par l’expression « batteries incluses » : il fournit déjà un système d’authentification, un accès structuré à la base de données, des formulaires, des migrations de schéma, une interface d’administration et des protections courantes, notamment contre les requêtes frauduleuses entre sites. Vous consacrez donc davantage de temps au problème métier qu’à réassembler des fondations techniques.

Son architecture repose sur les modèles, qui décrivent les données, les vues, qui traitent une requête et décident de la réponse, et les templates, qui génèrent les pages HTML. Le terme employé par Django est MVT, pour modèle-vue-template. Ce découpage est moins un dogme qu’un garde-fou : une règle de réservation n’a rien à faire dans une page HTML, et un mot de passe n’a rien à faire dans un fichier de configuration envoyé sur un dépôt de code.

Django ne choisit toutefois ni votre cible, ni vos règles métier, ni le niveau de simplicité acceptable pour un premier lancement. Il ne transforme pas non plus automatiquement une interface d’administration en produit destiné au public. Son vrai intérêt apparaît lorsque vous acceptez de livrer une première version étroite, mais cohérente.

La méthode en cinq étapes, avant d’écrire trop de code

Étape 1 : cadrer un besoin assez petit pour être terminé

Formulez le premier usage sous la forme : « un utilisateur identifié peut réaliser telle action et voir tel résultat ». Pour un outil de suivi personnel, cela peut être : « une personne connectée crée une tâche, lui attribue un statut et retrouve uniquement ses propres tâches ». Cette phrase impose déjà des décisions utiles : il faut un compte, un objet Tâche, une propriété de propriétaire, une page de liste et un formulaire.

Évitez d’ouvrir le projet par des fonctions qui ne créent aucune valeur seule : messagerie, recommandations, application mobile, tableaux de bord exhaustifs, import de tous les formats possibles. Elles pourront venir plus tard si le parcours initial prouve son intérêt. Dessinez ensuite trois écrans maximum sur papier : une liste, une fiche et un formulaire. L’objectif n’est pas l’esthétique définitive ; c’est de rendre visibles les données dont vous aurez réellement besoin.

• Utilisateur : définissez un rôle initial, par exemple membre connecté ; l’administrateur reste un rôle technique séparé.
• Action : employez un verbe observable, comme créer, modifier, annuler ou valider ; « gérer » est trop vague pour guider le code.
• Règle : notez une contrainte non négociable, par exemple « une tâche appartient à un seul compte » ou « une date de fin ne précède pas la date de début ».
• Critère d’acceptation : décrivez une vérification simple : après enregistrement, la nouvelle tâche apparaît dans la liste de son créateur.

Étape 2 : installer un environnement reproductible

Installez une version de Python encore maintenue, puis créez un dossier dédié au projet. Dans ce dossier, la commande python -m venv .venv crée un environnement isolé. Activez-le avec la commande adaptée à votre système, puis installez Django avec python -m pip install Django. Vous évitez ainsi qu’un autre projet Python modifie silencieusement vos dépendances.

Créez ensuite le projet avec django-admin startproject config ., puis une application métier, par exemple python manage.py startapp tasks. Ajoutez cette application à la configuration Django, lancez les migrations initiales avec python manage.py migrate, puis démarrez le serveur local par python manage.py runserver. À ce stade, une page de développement doit s’ouvrir sur votre ordinateur : c’est le premier contrôle, avant toute fonctionnalité.

Conservez les dépendances dans un fichier partageable, par exemple avec python -m pip freeze > requirements.txt. Séparez dès le départ les secrets du code : clé secrète Django, mots de passe de base de données et clés de services externes doivent être chargés par des variables d’environnement. Ne placez ni ces valeurs ni le fichier qui les contient dans un dépôt partagé. Le serveur de développement Django est fait pour travailler localement, jamais pour recevoir du trafic public.

Étape 3 : faire du modèle de données votre première interface

Avant les pages, décrivez les objets qui existent réellement. Dans une application de tâches, un modèle Tâche peut comporter un titre court, une description facultative, un statut limité à quelques choix, une échéance facultative, une date de création et une relation vers le compte propriétaire. Les champs ne sont pas de simples colonnes : leurs types, leurs valeurs obligatoires et leurs contraintes traduisent les règles de votre produit.

Après chaque modification de modèle, générez la migration avec python manage.py makemigrations, lisez son contenu, puis appliquez-la par python manage.py migrate. Enregistrez le modèle dans l’administration Django et créez quelques données de test. Cette interface, accessible aux seuls administrateurs, est un formidable banc d’essai : elle permet de contrôler les champs, les listes et les relations avant de fabriquer une interface publique.

SQLite convient très bien à l’apprentissage, aux démonstrations et à un prototype local : elle ne réclame aucun serveur de base de données distinct. Pour une application publique appelée à recevoir des écritures simultanées ou à tenir dans la durée, partez sur PostgreSQL dès le déploiement. Ce changement n’autorise pas une modélisation approximative : les migrations, les sauvegardes et les contraintes de données restent les éléments déterminants.

Étape 4 : relier pages, formulaires et permissions

Une fonction complète suit un chemin court : une URL reçoit la requête, une vue récupère ou enregistre les données, un template affiche le résultat. Organisez vos URL par usage, par exemple une liste à /tasks/, une création à /tasks/new/ et une modification associée à l’identifiant d’une tâche. Un fichier de templates partagé peut contenir le squelette HTML, la navigation et les messages ; chaque page métier n’ajoute alors que son contenu propre.

Pour créer ou modifier un objet, utilisez un formulaire Django fondé sur le modèle plutôt que de lire directement les champs envoyés par le navigateur. Il centralise la validation et réaffiche les erreurs près du champ concerné. Dans un formulaire HTML envoyé en POST, incluez le jeton csrf_token fourni par Django. Après un enregistrement réussi, redirigez vers la page de résultat : ce schéma évite qu’un rechargement du navigateur crée deux fois la même donnée.

La règle de sécurité la plus souvent oubliée est la propriété des objets. Ne récupérez pas une tâche avec son seul identifiant si un membre ne doit voir que les siennes. Filtrez la requête avec l’utilisateur connecté, ou vérifiez explicitement l’autorisation avant toute lecture, modification ou suppression. Cacher un bouton n’est pas une permission : un utilisateur peut toujours tenter de saisir l’URL directement.

Étape 5 : tester, chiffrer et déployer sans improviser

Testez d’abord les règles qui coûteraient le plus cher si elles cassaient : une tâche ne doit pas être accessible par un autre compte, un formulaire invalide ne doit pas enregistrer de donnée, un changement de statut doit respecter vos contraintes. Django exécute les tests avec python manage.py test dans une base de test isolée. Ajoutez un test quand vous corrigez un bug : la correction devient alors un filet de sécurité durable.

Pour publier, choisissez un hébergement compatible avec Python et Django, disposant d’une base PostgreSQL persistante ou permettant de s’y connecter, de variables d’environnement, de HTTPS et de journaux consultables. Préparez la commande de démarrage WSGI ou ASGI demandée par l’hébergeur, appliquez les migrations, collectez les fichiers statiques avec python manage.py collectstatic et contrôlez l’affichage depuis un compte utilisateur ordinaire. Une sauvegarde de base testée à la restauration vaut davantage qu’une sauvegarde dont personne ne sait se servir.

Diagnostiquer un échec et faire évoluer le projet

Si une page renvoie une erreur, ne modifiez pas plusieurs fichiers au hasard. Reproduisez le problème avec l’action la plus courte, consultez le journal d’erreurs du serveur, puis vérifiez dans cet ordre : l’URL appelée, la vue, le template, les données attendues et les migrations appliquées. Une erreur « table inexistante » renvoie souvent à une migration oubliée ; un refus sur un formulaire renvoie fréquemment au jeton CSRF ou à une session expirée ; une page vide peut venir d’un contexte que la vue n’a pas transmis.

En production, corrigez d’abord la régression dans une copie locale ou de préproduction, ajoutez le test qui aurait dû l’empêcher, puis déployez. Si une migration risque de détruire ou de transformer beaucoup de données, réalisez une sauvegarde et planifiez un retour arrière avant l’opération. Évitez de découper trop tôt l’application en microservices : un projet Django bien organisé en applications métier séparées reste plus simple à tester, à déployer et à comprendre.

La checklist de lancement d’une application Django