Aller au contenu principal

FAQ, erreurs fréquentes et conseils pratiques

Repères utiles :

info

Cette note regroupe des questions fréquentes, des erreurs de débutant, des pièges de conception et des conseils pratiques pour mieux utiliser le reste du wiki. Elle sert de couche de raffinement pédagogique transversale, afin d'éviter les malentendus les plus courants autour de Django et Django REST Framework.

1. À quoi sert cette note​

Maintenant que le wiki contient les grands chapitres principaux, il devient utile d'ajouter une note transversale qui répond à des questions du type :

  • Je suis perdu, je commence par quoi ?
  • Django ou DRF ?
  • Est-ce que je suis en train de sur-ingénierer mon backend ?
  • Pourquoi tout le monde insiste autant sur les permissions ?
  • Est-ce que l'admin Django suffit ?
  • Mon projet ressemble à quel use case ?

Cette note n'est pas un remplacement des grands tutoriels. Elle sert plutôt à :

  • lever rapidement des blocages
  • éviter les contresens
  • renforcer la pédagogie du wiki
  • donner des repères simples avant de replonger dans les chapitres détaillés

2. FAQ rapide​

Q1 — Est-ce que Django et DRF sont la même chose ?​

Non.

La manière la plus simple de le retenir est la suivante :

  • Django = le socle backend général
  • DRF = la couche spécialisée pour construire des APIs plus proprement sur ce socle

Si ce point est encore flou, relis :

Q2 — Est-ce qu'il faut toujours utiliser DRF si on choisit Django ?​

Non.

Si ton projet est surtout :

  • pages HTML simples
  • formulaires classiques
  • très peu d'API

alors Django seul peut suffire.

DRF devient surtout intéressant quand tu veux une API JSON propre, maintenable, pensée pour un frontend séparé, un mobile, des systèmes externes ou une architecture plus API-centric.

Q3 — Est-ce que Django DRF est “trop lourd” ?​

Cela dépend du projet.

Pour un besoin minuscule ou très jetable, il peut être plus structuré que nécessaire. Mais pour un produit réel avec :

  • utilisateurs
  • données
  • permissions
  • logique métier
  • durée de vie

ce qui semble “plus lourd” au début devient souvent “plus rassurant” plus tard.

Q4 — Est-ce que Django DRF est adapté aux produits sérieux ?​

Oui, très souvent.

Le wiki entier montre justement que Django DRF est très pertinent pour :

  • web/mobile
  • rôles et permissions
  • SaaS / outils internes
  • produits data-centric
  • back-office / admin
  • APIs B2B
  • produits IA avec vraie couche backend

Q5 — Est-ce que DRF sert juste à “retourner du JSON” ?​

Non.

C'est une vision beaucoup trop pauvre. DRF aide aussi à structurer :

  • les serializers
  • les permissions
  • les représentations de données
  • les vues API
  • les routes cohérentes
  • la stabilité de l'API

Q6 — Est-ce que l'admin Django suffit comme back-office ?​

Parfois oui, parfois non.

L'admin Django peut être :

  • largement suffisant dans certains produits
  • très utile comme première étape
  • excellent pour l'exploitation et la supervision
  • insuffisant si l'équipe interne a besoin de parcours métier très spécifiques

Si tu hésites sur ce sujet, relis :

Q7 — Est-ce qu'une application data-centric est forcément “ennuyeuse” ou purement CRUD ?​

Non.

Une application centrée donnée peut être très riche. Elle peut contenir :

  • des workflows
  • des permissions
  • des audits
  • du reporting
  • des relations complexes
  • des cas métier profonds

Relis :

Q8 — Est-ce qu'un produit IA rend Django DRF inutile parce que “tout se passe dans le modèle” ?​

Absolument pas.

Le modèle ne remplace pas :

  • la gestion des utilisateurs
  • les jobs
  • les résultats
  • les permissions
  • les artefacts
  • la traçabilité
  • le back-office
  • les intégrations

Relis :

3. Les 10 erreurs les plus fréquentes​

Erreur 1 — Commencer directement par le code sans clarifier le problème​

C'est probablement l'erreur la plus fréquente.

On crée trop vite :

  • modèle
  • serializer
  • viewset
  • router

sans avoir clarifié :

  • le besoin réel
  • les acteurs
  • les permissions
  • la logique métier

Relis :

Erreur 2 — Confondre authentification et autorisation​

Très classique.

  • authentification = qui est cette personne ?
  • autorisation / permissions = a-t-elle le droit ?

Relis :

Erreur 3 — Traiter une API comme une exportation brute de la base​

Une API bien pensée n'est pas juste une fenêtre brute sur les tables. Elle exprime des besoins produit et des règles métier.

Erreur 4 — Sous-estimer l'importance du modèle de données​

Beaucoup de problèmes backend viennent d'un modèle de données trop flou, trop tordu ou trop peu réfléchi.

Relis :

Erreur 5 — Croire que le frontend doit porter une grande partie de la logique sensible​

Le frontend peut guider l'expérience. Le backend doit garder les règles importantes.

Erreur 6 — Reporter permissions, audit et exploitation à plus tard​

Cela fonctionne rarement bien. Ces sujets structurent très tôt la qualité du système.

Erreur 7 — Construire un produit IA comme une simple démo d'inférence​

Un vrai produit IA a presque toujours besoin d'une couche produit forte autour du modèle.

Erreur 8 — Construire un back-office sur mesure trop tôt​

L'inverse est aussi vrai : parfois l'admin Django suffit très bien au début.

Erreur 9 — Penser qu'une API interne peut être brouillonne parce qu'elle n'est pas publique​

Les APIs internes créent aussi beaucoup de dette quand elles sont mal conçues.

Erreur 10 — Lire les chapitres dans le désordre sans socle​

Cela produit souvent une compréhension fragmentée. Pour éviter cela, voir :

4. Les signes qu'un projet est probablement un bon candidat pour Django DRF​

Si tu te reconnais dans plusieurs de ces points, Django DRF est probablement une bonne piste :

  • ton produit a des utilisateurs et des rôles
  • tu as des données relationnelles importantes
  • tu veux une API claire
  • tu veux un backend qui dure
  • tu as besoin d'un back-office ou d'admin interne
  • tu as des workflows et validations métier
  • tu veux une base structurée plutôt qu'un assemblage improvisé

5. Les signes qu'il faut au moins réfléchir avant de choisir Django DRF​

Pose-toi un peu plus de questions si :

  • ton besoin est minuscule et très temporaire
  • tu n'as quasiment pas de données structurées
  • tu n'as pas de logique métier significative
  • tu n'as pas de permissions ou presque pas de sécurité spécifique
  • tu veux un micro-service extrêmement réduit

Cela ne veut pas dire que Django DRF est mauvais. Cela veut juste dire qu'il faut vérifier si sa valeur ajoutée est bien alignée avec ton besoin.

6. Conseils pratiques pour bien utiliser ce wiki​

Conseil 1 — Utilise les chapitres comme des cartes mentales, pas comme des checklists de commandes​

Ce wiki sert d'abord à t'aider à penser correctement.

Conseil 2 — Commence toujours par identifier ton problème réel​

Ne cherche pas “le meilleur framework” de manière abstraite. Cherche le bon outil pour le bon type de backend.

Conseil 3 — Si tu hésites entre plusieurs use cases, lis-en deux​

Les vrais projets hybrident souvent plusieurs logiques. Par exemple :

  • SaaS + rôles/permissions
  • produit IA + data-centric
  • web/mobile + back-office

Conseil 4 — Ne confonds pas V1 simple et architecture faible​

Une architecture sobre peut être bonne. Une architecture floue est rarement une bonne chose.

Conseil 5 — Garde en tête la durée de vie du projet​

Beaucoup de décisions n'ont l'air coûteuses qu'au début. Mais elles évitent beaucoup de souffrance plus tard.

7. Questions de repérage ultra rapides​

“Mon projet ressemble à quoi ?”​

“Je suis perdu, je lis quoi en premier ?”​

Commence par :

“Je veux comprendre vite, sans tout lire”​

Commence par :

8. Rappels importants à garder en tête​

  • Django n'est pas “juste pour les sites web classiques”
  • DRF n'est pas “juste pour retourner du JSON”
  • une API n'est pas “juste une table exposée”
  • l'authentification n'est pas la permission
  • une bonne architecture produit se pense tôt
  • la donnée, les permissions, le back-office et l'exploitation ne sont pas des détails secondaires

9. Résumé final​

Cette note existe pour rendre tout le reste du wiki plus facile à utiliser.

L'idée la plus importante à retenir est la suivante :

la plupart des erreurs autour de Django DRF ne viennent pas d'un manque de syntaxe, mais d'un manque de clarté sur le problème réel, la structure du backend et la place des responsabilités.

10. Pour aller plus loin​

Si tu veux avancer intelligemment à partir d'ici :