Apprenons avec un exemple.
\nTout au long de ce tutoriel, nous vous guiderons dans la création d’une application simple de sondage.
\nCela consistera en deux parties :
\nUn site public qui permet à des gens de voir les sondages et d’y répondre.
Un site d’administration qui permet d’ajouter, de modifier et de supprimer des sondages.
Nous supposerons que Django est déjà installé. Vous pouvez savoir si Django est installé et sa version en exécutant la commande suivante :
\n$ python -m django --version\nSi Django est installé, vous devriez voir apparaître la version de l’installation. Dans le cas contraire, vous obtiendrez une erreur disant « No module named django » (aucun module nommé django).
\nCe didacticiel est écrit pour Django 1.9 et Python 3.4 (ou plus récent). Si la version de Django ne correspond pas, référez-vous au didacticiel correspondant à votre version de Django en utilisant le sélecteur de version au bas de cette page, ou mettez à jour Django à la version la plus récente. Si vous utilisez encore Python 2.7, il sera nécessaire d’ajuster légèrement les exemples de code, comme expliqué dans les commentaires.
\nConsultez Comment installer Django pour tout conseil sur la manière de supprimer d’anciennes versions de Django pour en installer une nouvelle.
\n\nSi c’est la première fois que vous utilisez Django, vous devrez vous occuper de quelques éléments de configuration initiaux. Plus précisément, vous devrez lancer la génération automatique de code qui mettra en place un projet Django – un ensemble de réglages particuliers à une instance de Django, qui comprend la configuration de la base de données, des options spécifiques à Django et d’autres propres à l’application.
\nDepuis un terminal en ligne de commande, déplacez-vous à l’aide de la commande cd dans un répertoire dans lequel vous souhaitez conserver votre code, puis lancez la commande suivante :
$ django-admin startproject mysite\nCela va créer un répertoire mysite dans le répertoire courant. Si cela ne fonctionne pas, consultez Problèmes d’exécution de django-admin.
Voyons ce que startproject a créé :
mysite/\n manage.py\n mysite/\n __init__.py\n settings.py\n urls.py\n wsgi.py\nCes fichiers sont :
\nLe premier répertoire racine mysite/ n’est qu’un contenant pour votre projet. Son nom n’a pas d’importance pour Django ; vous pouvez le renommer comme vous voulez.
manage.py : un utilitaire en ligne de commande qui vous permet d’interagir avec ce projet Django de différentes façons. Vous trouverez toutes les informations nécessaires sur manage.py dans django-admin et manage.py.
Le sous-répertoire mysite/ correspond au paquet Python effectif de votre projet. C’est le nom du paquet Python que vous devrez utiliser pour importer ce qu’il contient (par ex. mysite.urls).
mysite/__init__.py: An empty file that tells Python that this\ndirectory should be considered a Python package. If you’re a Python beginner,\nread more about packages in the official Python docs.
mysite/settings.py : réglages et configuration de ce projet Django. Les réglages de Django vous apprendra tout sur le fonctionnement des réglages.
mysite/urls.py : les déclarations des URL de ce projet Django, une sorte de « table des matières » de votre site Django. Vous pouvez en lire plus sur les URL dans Distribution des URL.
mysite/wsgi.py : un point d’entrée pour les serveurs Web compatibles WSGI pour déployer votre projet. Voir Comment déployer avec WSGI pour plus de détails.
Vérifions que votre projet Django fonctionne. Déplacez-vous dans le répertoire mysite si ce n’est pas déjà fait, et lancez les commandes suivantes :
$ python manage.py runserver\nVous verrez les messages suivants défiler en ligne de commande :
\nPerforming system checks...\n\nSystem check identified no issues (0 silenced).\n\nYou have unapplied migrations; your app may not work properly until they are applied.\nRun 'python manage.py migrate' to apply them.\n\n09 août 2026 - 15:50:53\nDjango version 1.9, using settings 'mysite.settings'\nStarting development server at http://127.0.0.1:8000/\nQuit the server with CONTROL-C.\n\n
Vous avez démarré le serveur de développement de Django, un serveur Web léger entièrement écrit en Python. Nous l’avons inclus avec Django de façon à vous permettre de développer rapidement, sans avoir à vous occuper de la configuration d’un serveur de production – comme Apache – tant que vous n’en avez pas besoin.
\nC’est le moment de noter soigneusement ceci : n’utilisez jamais ce serveur pour quoi que ce soit qui s’approche d’un environnement de production. Il est fait seulement pour tester votre travail pendant le développement (notre métier est le développement d’environnements Web, pas de serveurs Web).
\nMaintenant que le serveur tourne, allez à l’adresse http://127.0.0.1:8000 avec votre navigateur Web. Vous verrez une page avec le message « Welcome to Django » sur un joli fond bleu pastel. Ça marche !
\n\n\nMaintenant que votre environnement – un « projet » – est en place, vous êtes prêt à commencer à travailler.
\nChaque application que vous écrivez avec Django est en fait un paquet Python qui respecte certaines conventions. Django est livré avec un utilitaire qui génère automatiquement la structure des répertoires de base d’une application, ce qui vous permet de vous concentrer sur l’écriture du code, plutôt que sur la création de répertoires.
\n\nYour apps can live anywhere on your Python path. In\nthis tutorial, we’ll create our poll app right next to your manage.py\nfile so that it can be imported as its own top-level module, rather than a\nsubmodule of mysite.
Pour créer votre application, assurez-vous d’être dans le même répertoire que manage.py et saisissez cette commande :
$ python manage.py startapp polls\nCela va créer un répertoire polls, qui est structuré de la façon suivante :
polls/\n __init__.py\n admin.py\n apps.py\n migrations/\n __init__.py\n models.py\n tests.py\n views.py\nCette structure de répertoire accueillera l’application de sondage.
\nÉcrivons la première vue. Ouvrez le fichier polls/views.py et placez-y le code Python suivant :
polls/views.pyfrom django.http import HttpResponse\n\n\ndef index(request):\n return HttpResponse("Hello, world. You're at the polls index.")\nC’est la vue Django la plus simple possible. Pour appeler cette vue, il s’agit de l’associer à une URL, et pour cela nous avons besoin d’un URLconf.
\nPour créer un URLconf dans le répertoire polls, créez un fichier nommé urls.py. Votre répertoire d’application devrait maintenant ressembler à ceci :
polls/\n __init__.py\n admin.py\n apps.py\n migrations/\n __init__.py\n models.py\n tests.py\n urls.py\n views.py\nDans le fichier polls/urls.py, insérez le code suivant :
polls/urls.pyfrom django.conf.urls import url\n\nfrom . import views\n\nurlpatterns = [\n url(r'^$', views.index, name='index'),\n]\nL’étape suivante est de faire pointer l’URLconf racine vers le module polls.urls. Dans mysite/urls.py, ajoutez une importation django.conf.urls.include et insérez un appel include() dans la liste urlpatterns, ce qui donnera :
mysite/urls.pyfrom django.conf.urls import include, url\nfrom django.contrib import admin\n\nurlpatterns = [\n url(r'^polls/', include('polls.urls')),\n url(r'^admin/', admin.site.urls),\n]\nThe include() function allows referencing other\nURLconfs. Note that the regular expressions for the\ninclude() function doesn’t have a $ (end-of-string\nmatch character) but rather a trailing slash. Whenever Django encounters\ninclude(), it chops off whatever part of the URL\nmatched up to that point and sends the remaining string to the included URLconf\nfor further processing.
L’idée derrière include() est de faciliter la connexion d’URL. Comme l’application de sondages possède son propre URLconf (polls/urls.py), ses URL peuvent être injectés sous « /polls/ », sous « /fun_polls/ » ou sous « /content/polls/ » ou tout autre chemin racine sans que cela change quoi que ce soit au fonctionnement de l’application.
Vous avez maintenant relié une vue index dans la configuration d’URL. Vérifions qu’elle fonctionne en lançant la commande suivante :
$ python manage.py runserver\nOuvrez http://localhost:8000/polls/ dans votre navigateur et vous devriez voir le texte « Hello, world. You’re at the polls index. » qui a été défini dans la vue index.
La fonction url() reçoit quatre paramètres, dont deux sont obligatoires : regex et view, et deux facultatifs : kwargs et name. À ce stade, il est interessant d’examiner le rôle de chacun de ces paramètres.
url() : regexLien vers cette rubrique#Le terme « regex » est communément utilisé comme raccourci pour « expression régulière », qui consiste en une syntaxe pour retrouver des motifs dans des chaînes de caractères, ou dans ce cas, dans des modèles d’URL. Django commence par la première expression régulière puis continue de parcourir la liste en comparant l’URL reçue avec chaque expression jusqu’à ce qu’il en trouve une qui correspond.
\nNotez que ces expressions régulières ne cherchent pas dans les paramètres GET et POST, ni dans le nom de domaine. Par exemple, dans une requête vers https://www.example.com/myapp/, l’URLconf va chercher myapp/. Dans une requête vers https://www.example.com/myapp/?page=3, l’URLconf va aussi chercher myapp/.
Si vous avez besoin d’aide avec les expressions régulières, jetez un oeil à l”article Wikipedia et à la documentation du module Python re. À noter aussi que le livre « Mastering Regular Expressions », écrit par Jeffrey Friedl, est remarquable. En pratique, il n’y a cependant pas besoin d’être un expert des expressions régulières, car il suffit de savoir capturer des motifs simples. En fait, les expressions complexes risquent de pénaliser les performances, et il faut plutôt éviter de faire appel à tout le potentiel des expressions régulières.
Enfin, une note sur la performance : ces expressions régulières sont compilées la première fois que le module contenant l’URLconf est chargé. Elles sont extrêmement rapides (tant qu’elles ne sont pas trop complexes, comme indiqué ci-dessus).
\nurl() : viewLien vers cette rubrique#Lorsque Django trouve une expression régulière qui correspond, il appelle la fonction de vue spécifiée, avec un objet HttpRequest comme premier paramètre et toutes valeurs « capturées » par l’expression régulière comme autres paramètres. Si l’expression régulière utilise des captures simples, les valeurs sont passées comme paramètres positionnels ; si ce sont des captures nommées, les valeurs sont passées comme paramètres nommés. Nous montrerons cela par un exemple un peu plus loin.
url() : kwargsLien vers cette rubrique#Des paramètres nommés arbitraires peuvent être transmis dans un dictionnaire vers la vue cible. Nous n’allons pas exploiter cette fonctionnalité dans ce tutoriel.
\nurl() : nameLien vers cette rubrique#Naming your URL lets you refer to it unambiguously from elsewhere in Django,\nespecially from within templates. This powerful feature allows you to make\nglobal changes to the URL patterns of your project while only touching a single\nfile.
\nLorsque vous serez familiarisé avec le flux de base des requêtes et réponses, lisez la partie 2 de ce tutoriel pour commencer de travailler avec la base de données.
\n