Développeur Python Django : ORM, migrations et API DRF en production

Django fournit l'ORM, l'admin, les migrations et la sécurité de base, ce qui permet de livrer vite. Les problèmes arrivent avec le volume : requêtes en trop, migrations qui bloquent une table, tâches exécutées deux fois.

Recevoir la fiche complète

Mis à jour le Par l'équipe Delectus5 min de lecture

La fiche Développeur Python Django : technologies, chaîne du poste, une question et la grille d'évaluation

Un développeur Python Django construit des applications web et des API avec Django et Django REST Framework, le plus souvent sur PostgreSQL. Les offres ajoutent Celery avec Redis ou RabbitMQ pour les tâches en arrière-plan, Docker et une CI GitLab ou GitHub, et souvent un front React ou Angular que la personne touche un peu. Beaucoup de postes portent sur un produit déjà en ligne depuis plusieurs années, avec un historique de migrations long.

Django rend les premières semaines faciles, et beaucoup de CV en profitent. Un tutoriel suffit pour un CRUD avec l'admin et un ModelViewSet. La différence se voit sur ce que le framework ne fait pas à votre place : compter les requêtes d'une page, écrire une migration sans verrouiller une table de production, filtrer les données par utilisateur dans une API, rendre une tâche Celery idempotente. Demandez un exemple chiffré de page accélérée ou d'incident de migration.

Côté versions, Django 5.2 est la LTS supportée jusqu'en avril 2028, et la 6.x apporte un framework de tâches et la politique de sécurité du contenu intégrés. Le PDF rassemble 30 questions, un cas de 20 minutes et une grille de 1 à 4.

L'outillage d'un développeur Django, expliqué au recruteur

Django

Le framework web Python dit « batteries incluses » : ORM, migrations, admin, formulaires, authentification et protections de sécurité sont livrés ensemble. La version 6.1 est la plus récente, la 5.2 est la version LTS supportée jusqu'en avril 2028, et la prochaine LTS, la 6.2, est prévue pour avril 2027. Demandez sur quelle version tourne le projet du candidat.

ORM Django

Les tables sont décrites en classes Python et interrogées par des QuerySets. C'est le premier sujet de l'entretien : select_related, prefetch_related, annotate, expressions F et transactions décident des performances. Un ORM mal utilisé produit des centaines de requêtes là où deux suffisent.

Migrations

Chaque changement de modèle produit un fichier de migration, appliqué avec migrate. Sur une petite base, tout passe. Sur une table de plusieurs dizaines de millions de lignes, une migration mal écrite verrouille la table pendant des minutes : la personne doit savoir découper et lire le SQL généré.

Django REST Framework

La bibliothèque standard pour écrire des API avec Django : serializers, viewsets, routeurs, permissions, pagination, throttling. Les failles d'accès aux données viennent souvent d'un get_queryset qui ne filtre pas par utilisateur. Django Ninja, plus récent et typé, apparaît dans certaines offres.

Celery et tâches en arrière-plan

Celery exécute les e-mails, exports et appels externes hors de la requête, avec Redis ou RabbitMQ comme file. Une tâche peut s'exécuter plus d'une fois, elle doit donc être idempotente. Django 6.0 a ajouté une API de tâches standard, sans worker fourni : un outil externe reste nécessaire en production.

Admin Django

Un back-office généré à partir des modèles, très utilisé par les équipes internes. Bien réglé, il évite d'écrire des écrans de gestion. Mal réglé sur une grosse table, il devient lent et ouvre des droits trop larges.

Sécurité Django

Protection CSRF, échappement automatique dans les templates, requêtes paramétrées par l'ORM, hachage des mots de passe, en-têtes de sécurité, et depuis la 6.0 une politique de sécurité du contenu (CSP) intégrée. La commande check --deploy signale les réglages manquants avant une mise en production.

PostgreSQL et déploiement

PostgreSQL est la base la plus courante dans les offres. L'application tourne sous Gunicorn ou, en ASGI, sous uvicorn, dans des conteneurs Docker, avec les fichiers statiques et les fichiers déposés servis hors de Django.

Tests avec pytest-django

pytest-django ou le TestCase de Django, factory_boy pour les données, assertNumQueries pour bloquer le retour des requêtes N+1. Une CI qui teste sur PostgreSQL, comme la production, évite des surprises sur les contraintes et les verrous.

Le développeur Python Django travaille le plus souvent sur un produit déjà en ligne : il ajoute des fonctions, fait évoluer le modèle de données, expose des API à un front React, Angular ou mobile et suit les tâches en arrière-plan. Selon l'équipe, il prend aussi en charge le déploiement Docker et une partie du front. Les postes juniors portent surtout sur des vues, des serializers et des tests. Les postes seniors ajoutent les migrations sur de gros volumes, la sécurité des API et les montées de version de Django. Aucune certification de référence n'existe pour Django : le niveau se juge sur des cas concrets.

Six compétences Django à contrôler en entretien

  • ORM Django et performance des requêtes
  • Migrations de schéma sur une base en production
  • API avec Django REST Framework
  • Tâches Celery idempotentes
  • Sécurité et réglages de production
  • Tests et montées de version Django

Les questions qui montrent l'expérience Django en production

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

  1. Question 1 · confirmé

    Une page liste 50 commandes avec le nom du client et les produits de chacune. La barre de débogage affiche 151 requêtes SQL. Que corrigez-vous ?

    Une bonne réponseUn problème N+1 : une requête pour la liste, puis une par commande pour le client et une par commande pour les produits. select_related('client') fait une jointure sur la clé étrangère, prefetch_related('lignes__produit') charge les produits en une requête séparée, avec un objet Prefetch si on veut filtrer. La personne vérifie le résultat avec django-debug-toolbar ou assertNumQueries dans un test.

    Signal d'alerteMettre la page en cache, ou passer tout de suite en SQL brut, sans connaître select_related ni prefetch_related.

  2. Question 2 · senior

    Vous devez ajouter une colonne obligatoire avec une valeur par défaut à une table PostgreSQL de 80 millions de lignes, en production. Comment écrivez-vous la migration ?

    Une bonne réponseLa personne lit d'abord le SQL généré avec sqlmigrate. Elle découpe : colonne ajoutée sans contrainte bloquante (ou avec db_default, disponible depuis Django 5.0), remplissage par lots dans une migration de données hors transaction, contrainte NOT NULL posée ensuite. Un index se crée avec AddIndexConcurrently. Elle sait qu'un verrou sur la table bloque les écritures, règle un lock_timeout, et déploie un code qui fonctionne avec l'ancien et le nouveau schéma.

    Signal d'alerte« makemigrations puis migrate, comme en local », sans aucune idée des verrous ni de la durée sur une grosse table.

  3. Question 3 · confirmé

    Dans une API Django REST Framework, un utilisateur lit les factures d'un autre client en changeant l'identifiant dans l'URL. Où est l'erreur, et comment la corrigez-vous ?

    Une bonne réponseLa vue vérifie que l'utilisateur est connecté, pas que la facture lui appartient. La correction : get_queryset filtre sur l'organisation ou l'utilisateur de la requête, si bien qu'une facture d'un autre client renvoie une 404. Une permission objet (has_object_permission) complète pour les règles plus fines. Un test automatisé couvre le cas.

    Signal d'alerteRemplacer les identifiants par des UUID et considérer le problème réglé, ou contrôler l'accès côté front.

  4. Question 4 · confirmé

    Une tâche Celery envoie un e-mail de confirmation puis met à jour la commande. Certains clients reçoivent deux e-mails. Pourquoi, et que changez-vous ?

    Une bonne réponseCelery peut exécuter une tâche plus d'une fois : nouvelle tentative après une erreur, worker arrêté avec acks_late, message relivré par Redis après le délai de visibilité. La tâche doit être idempotente : un indicateur « e-mail envoyé » vérifié et posé de façon atomique en base (select_for_update ou contrainte d'unicité). La tâche reçoit un identifiant, pas un objet, et elle est lancée avec transaction.on_commit.

    Signal d'alerte« Celery n'exécute jamais deux fois une tâche », ou supprimer les nouvelles tentatives pour éviter les doublons.

  5. Question 5 · junior à confirmé

    Avant une mise en production, quels réglages Django vérifiez-vous ?

    Une bonne réponseDEBUG à False, SECRET_KEY lue dans l'environnement et absente du dépôt, ALLOWED_HOSTS, redirection HTTPS, HSTS et cookies Secure, CSRF_TRUSTED_ORIGINS. La commande manage.py check --deploy liste ce qui manque. Viennent ensuite les fichiers statiques (collectstatic), la journalisation, la durée de vie des connexions à la base et, depuis Django 6.0, la politique de sécurité du contenu (SECURE_CSP).

    Signal d'alerteDEBUG laissé à True « pour voir les erreurs », ou une SECRET_KEY écrite dans settings.py et poussée sur le dépôt.

Recevez la fiche d'entretien complète en PDF

La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.

  • 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
  • Le niveau visé pour chaque question
  • Une mise en situation de 20 minutes et ce qu'on attend du candidat
  • La grille d'évaluation de 1 à 4, axe par axe

Questions fréquentes sur le recrutement d'un développeur Django

Développeur Django ou développeur FastAPI : lequel chercher ?

Cela dépend du projet en place. Django convient aux applications complètes avec une base relationnelle, un back-office et des utilisateurs, grâce à son ORM, son admin et ses migrations. FastAPI sert surtout à écrire des API asynchrones typées, souvent sans admin. Un bon développeur Python passe de l'un à l'autre, mais les pièges ne sont pas les mêmes. Pour un produit Django existant, l'expérience de l'ORM et des migrations compte plus que le reste.

Quelles compétences demander en plus de Django ?

Le Python lui-même (typage, générateurs, gestion des exceptions), le SQL et PostgreSQL, Django REST Framework pour les API, Celery pour les tâches, pytest pour les tests, Docker et une CI. Selon le poste, un peu de front (templates Django, HTMX, React) et des notions de sécurité web. Sur un poste senior, ajoutez la conduite de migrations sur de gros volumes et les montées de version de Django.

Test technique Django : exercice en direct ou projet à rendre ?

Un exercice court en entretien suffit souvent. Donnez une vue DRF qui déclenche des dizaines de requêtes et ne filtre pas les données par utilisateur, puis demandez de la corriger en expliquant. En 30 minutes, vous voyez l'ORM, la sécurité et la façon de tester. Un projet à rendre chez soi prend du temps au candidat et montre moins bien ses réflexes de production.

Un développeur Python sans Django peut-il prendre le poste ?

Oui, si le poste laisse du temps d'apprentissage et qu'un développeur Django expérimenté relit son code. Le Python, le SQL et les tests se transfèrent. Les conventions de Django (applications, migrations, ORM, admin, middleware) s'apprennent vite, mais les pièges de production arrivent plus tard : requêtes N+1, migrations bloquantes, permissions oubliées. Sur un poste seul ou senior, exigez une expérience Django en production.

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.

Les fiches voisines

Toutes les fiches →

Voyez Delectus sur vos propres offres.

Commencez gratuitement. Passez à l'échelle quand vous êtes prêt.

Demander une démo

Votre ATS, connecté à Delectus

  • Workable
  • Teamtailor
  • iCIMS
  • Lever
  • SmartRecruiters
  • Jobvite
  • Greenhouse
  • Pinpoint