Développeur full-stack Python : les deux côtés de l'API à vérifier

Le développeur full-stack Python écrit l'API en Django ou en FastAPI, la base PostgreSQL derrière et les écrans React devant. L'entretien doit couvrir les deux côtés, parce que la plupart des CV penchent nettement vers l'un d'eux.

Recevoir la fiche complète

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

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

Un back Django, Django REST Framework ou FastAPI, un front React en TypeScript, PostgreSQL, Celery et Redis pour les traitements en arrière-plan, Docker et une CI pour livrer : les offres de développeur full-stack Python associent presque toujours ces briques. La personne porte une fonctionnalité de bout en bout : le modèle de données, la migration, l'endpoint, l'écran et les tests. Beaucoup de missions récentes y ajoutent un assistant ou une recherche appuyés sur un LLM, appelé depuis le back Python.

Le candidat vient presque toujours d'un côté. Un développeur Django qui a appris React plus tard connaît bien l'ORM et l'admin, et écrit parfois un front qui recharge tout à chaque clic. Un développeur React passé à FastAPI sur le tas livre des écrans soignés et une API qui lance cent requêtes SQL par page. Faites dérouler une fonctionnalité livrée seul, couche par couche : la table, l'index, la validation, le format JSON, l'état côté React, le test.

Décidez avant l'entretien quel côté pèse le plus. Sur un produit chargé en données, l'ORM et PostgreSQL passent devant. Sur une interface riche, l'état React et la vitesse de rendu. Le PDF contient 30 questions sur six axes, un cas de 20 minutes et une grille de 1 à 4.

La stack d'un développeur full-stack Python, couche par couche

Django et son ORM

Le framework web le plus répandu en Python. Il fournit l'ORM, les migrations, l'authentification et une interface d'administration prête à l'emploi. La 5.2 est la version LTS en cours, la branche 6.x a ajouté un cadre de tâches en arrière-plan et la Content Security Policy en natif. Sur ce poste, la qualité des requêtes produites par l'ORM compte plus que la connaissance des options.

Django REST Framework

La bibliothèque qui expose un projet Django en API REST : sérialiseurs, vues génériques, permissions, pagination, limitation de débit. Une bonne partie des lenteurs vient de sérialiseurs imbriqués qui déclenchent une requête SQL par objet.

FastAPI et Pydantic

Le framework d'API asynchrone bâti sur Starlette et Pydantic. Les annotations de type Python servent à valider les entrées et à générer la documentation OpenAPI. Il faut choisir soi-même l'ORM (SQLAlchemy 2.0 ou SQLModel), les migrations (Alembic) et l'authentification, et comprendre ce qui bloque la boucle asynchrone.

PostgreSQL

La base de presque toutes les offres. Le développeur full-stack doit lire un EXPLAIN ANALYZE, poser un index composite, utiliser les transactions et une colonne JSONB sans en faire un fourre-tout.

Celery et Redis

Celery exécute en arrière-plan ce qui ne doit pas bloquer une requête HTTP : envoi d'e-mails, génération de PDF, appels à un service externe, imports. Redis ou RabbitMQ sert de file de messages. Le cadre de tâches de Django 6 ne fournit pas de worker de production, donc Celery reste la norme. Interrogez la personne sur les reprises, les tâches exécutées deux fois et le lien avec la transaction en base.

React et TypeScript

Le front des offres full-stack Python. On attend les hooks, un état bien placé, des formulaires validés et des composants typés. Create React App est abandonné depuis 2025 : les projets démarrent avec Vite ou avec un framework comme Next.js ou React Router.

TanStack Query

La bibliothèque la plus utilisée pour les données serveur côté React (SWR et RTK Query font le même travail) : cache, rechargement, état de chargement, invalidation après une modification. Un profil qui recopie à la main chaque réponse d'API dans un store global n'a souvent pas rencontré ce problème.

Tests, Docker et CI

pytest côté Python, Vitest ou Jest avec Testing Library côté React, Playwright pour quelques parcours de bout en bout. Le tout lancé par une CI GitLab ou GitHub, avec la même image Docker de la recette à la production.

Le titre recouvre des postes assez différents. Dans une petite équipe produit, la même personne conçoit la table, l'API, l'écran et la mise en production. Dans une équipe plus grande, le full-stack penche d'un côté et tient l'autre sans attendre personne. Certaines offres décrivent un Django avec des templates rendus côté serveur et un peu de React, d'autres une API FastAPI seule et une application React séparée, et le niveau de front demandé n'est pas le même. Les missions qui mêlent Python, React et un LLM ajoutent des appels lents et coûteux à gérer côté back, avec des tâches de fond et du streaming de réponse. Relisez l'offre ligne par ligne avant de choisir les axes de l'entretien.

Les points techniques à couvrir des deux côtés de l'API

  • ORM Django et requêtes PostgreSQL
  • Conception d'API REST (DRF, FastAPI)
  • React, TypeScript et données serveur
  • Authentification et sécurité web
  • Tâches asynchrones avec Celery
  • Tests, CI et mise en production

Cinq questions qui obligent à passer du back au front

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 leur client et leurs produits, et le serveur exécute 151 requêtes SQL. Que corrigez-vous dans Django ?

    Une bonne réponseIl reconnaît un problème N+1. select_related pour la clé étrangère vers le client (une jointure), prefetch_related pour les produits (une seconde requête avec IN). Il vérifie le résultat avec django-debug-toolbar ou dans un test qui compte les requêtes (assertNumQueries). Avec DRF, il place ces appels dans le get_queryset de la vue, puisque le sérialiseur se contente de parcourir les relations.

    Signal d'alerte« J'ajoute un cache Redis » sans avoir regardé les requêtes, ou une boucle Python qui reconstitue les jointures à la main.

  2. Question 2 · confirmé

    Dans une route FastAPI déclarée en async def, vous appelez une bibliothèque qui fait une requête HTTP synchrone de deux secondes. Que se passe-t-il sous charge ?

    Une bonne réponseL'appel bloque la boucle d'événements : pendant deux secondes, le processus ne répond à aucune autre requête. Pour s'en sortir, il déclare la route en def simple pour que FastAPI l'exécute dans un pool de threads, ou il passe à un client asynchrone (httpx en mode async) avec await, ou il confie le travail à une tâche de fond si la réponse peut attendre. Il cite le même piège avec un pilote de base de données synchrone.

    Signal d'alerte« async rend tout plus rapide », ou aucune idée de ce qu'est la boucle d'événements.

  3. Question 3 · junior à confirmé

    Un utilisateur modifie une fiche dans un formulaire React. Comment la liste affichée à côté se met-elle à jour sans recharger la page ?

    Une bonne réponseAvec une bibliothèque de données serveur comme TanStack Query : la mutation invalide la clé de la liste, qui est rechargée, ou met à jour le cache avec la réponse de l'API. Pour une mise à jour optimiste, il garde l'ancienne valeur et revient en arrière si l'API renvoie une erreur. Côté API, la réponse du PATCH renvoie l'objet à jour, ce qui évite un aller-retour.

    Signal d'alerteUn window.location.reload(), ou les mêmes données copiées dans trois états locaux qui finissent par diverger.

  4. Question 4 · confirmé

    Le front React est servi sur app.exemple.fr et l'API Django sur api.exemple.fr. Comment gérez-vous l'authentification ?

    Une bonne réponseIl présente deux options. Une session ou un jeton dans un cookie HttpOnly, Secure et SameSite, avec la protection CSRF de Django et une configuration CORS qui autorise cette origine précise avec les credentials. Ou un JWT de courte durée avec un jeton de rafraîchissement, en sachant où il est stocké : dans localStorage, une faille XSS suffit à le voler. Il distingue CORS, qui contrôle la lecture des réponses par une autre origine, et CSRF, qui concerne les requêtes envoyées avec les cookies de l'utilisateur.

    Signal d'alerteCORS_ALLOW_ALL_ORIGINS à True « pour que ça marche », un JWT sans expiration dans localStorage, ou une confusion entre CORS et CSRF.

  5. Question 5 · confirmé à senior

    Après la création d'une commande, une tâche Celery envoie l'e-mail de confirmation. Parfois, la tâche ne trouve pas la commande en base. Pourquoi ?

    Une bonne réponseLa tâche part avant la fin de la transaction : le worker lit la base alors que la commande n'est pas encore validée, ou que la transaction a été annulée. Il envoie la tâche dans transaction.on_commit, donc après le commit. La tâche reçoit l'identifiant et pas l'objet, elle supporte d'être exécutée deux fois (une tâche peut être relivrée, surtout avec acks_late) et ses reprises sont limitées.

    Signal d'alerteUn time.sleep(2) au début de la tâche, ou l'objet entier sérialisé et passé à la tâche.

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

Django, FastAPI, React : les arbitrages du recrutement

Django ou FastAPI : faut-il exiger le framework de votre équipe ?

Pour un profil confirmé, passer de l'un à l'autre prend quelques semaines. Les deux reposent sur Python, HTTP, SQL et les tests. Les écarts portent sur l'asynchrone, central dans FastAPI, et sur tout ce que Django fournit d'office (ORM, admin, migrations, authentification) et qu'il faut assembler soi-même avec FastAPI. Exigez le framework si le poste démarre sur un code existant volumineux. Sinon, vérifiez surtout l'ORM, la conception d'API et la compréhension de async.

Quel niveau de React attendre d'un full-stack venu du back Python ?

Assez pour livrer un écran seul : composants typés en TypeScript, hooks, formulaires validés, appels d'API avec gestion du chargement et des erreurs, cache des données serveur. L'optimisation fine du rendu ou l'architecture d'un design system ne sont pas attendues, sauf si le poste le prévoit. Le signal d'alerte reste un useEffect qui relance un appel en boucle, ou un état recopié dans plusieurs composants faute de savoir où le placer.

Quel test technique proposer à un développeur full-stack Python ?

Une petite fonctionnalité sur un dépôt fourni, en direct ou en une heure : un endpoint qui liste et filtre des objets, et l'écran React qui l'affiche. Glissez dans le code de départ un problème N+1 et une validation manquante. Au débrief, demandez ce qu'il testerait et ce qui casserait avec dix fois plus de données. Évitez le projet de plusieurs jours à rendre, qui avantage les candidats qui ont du temps libre.

Faut-il poser des exercices d'algorithmique à un développeur full-stack Python ?

Un peu, s'ils ressemblent au travail réel : le coût d'une recherche dans une liste plutôt que dans un dictionnaire, un traitement par lots qui tient en mémoire, un regroupement de données. Les exercices de concours servent mal ce poste, où les problèmes de production viennent surtout des requêtes SQL, des appels réseau et de l'état côté front. Gardez le temps d'entretien pour ces sujets.

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