Aller au contenu principal

Plan directeur

Repères utiles :

info

Cette note définit la vision générale du wiki, son périmètre, sa structure éditoriale, la liste des grands cas d'usage à couvrir et le niveau de qualité attendu.

1. Pourquoi ce wiki existe​

L'objectif n'est pas de produire une simple collection de notes sur Django et DRF.

L'objectif est de construire un grand wiki pédagogique, en français, qui aide une personne à comprendre :

  • ce qu'est Django
  • ce qu'est Django REST Framework
  • quand utiliser Django DRF
  • quand ne pas l'utiliser
  • comment penser un projet backend proprement
  • comment aborder différents cas d'usage réels sans se perdre

Autrement dit, on veut une ressource qui serve à la fois de :

  • guide d'apprentissage
  • guide de décision
  • référence structurée
  • base évolutive pouvant être enrichie au fil du temps

2. Public cible​

Ce wiki doit pouvoir parler à plusieurs profils :

Débutant motivé​

Quelqu'un qui a entendu parler de Django ou DRF, mais ne comprend pas encore clairement à quoi cela sert ni comment l'utiliser.

Développeur junior ou intermédiaire​

Quelqu'un qui a déjà vu des APIs, mais qui veut mieux comprendre comment raisonner en termes de cas d'usage, d'architecture, de permissions, de backend métier, etc.

Lecteur en phase de cadrage produit​

Quelqu'un qui ne cherche pas d'abord du code, mais une réponse claire à des questions du type :

  • est-ce que Django DRF est adapté à mon besoin ?
  • comment structurer mon backend ?
  • quel use case correspond à mon projet ?

3. Ce que ce wiki doit être​

Ce wiki doit être :

  • clair
  • pédagogique
  • progressif
  • structuré
  • non bâclé
  • réutilisable dans le temps
  • améliorable par itérations

4. Ce que ce wiki ne doit pas être​

Ce wiki ne doit pas devenir :

  • une simple suite de mini-notes trop courtes
  • un pense-bête réservé à quelqu'un qui connaît déjà tout
  • une encyclopédie froide sans fil pédagogique
  • une accumulation de jargon non expliqué
  • un tutoriel purement technique qui oublie le contexte métier

5. Grande structure du wiki​

Le wiki est organisé autour de cinq blocs majeurs.

Bloc A — Pilotage​

Ce bloc contient les notes qui définissent la structure du projet documentaire.

Exemples :

  • plan directeur
  • schema éditorial
  • template de tutoriel
  • journal des itérations

Bloc B — Fondations​

Ce bloc pose le socle indispensable avant de traiter les gros cas d'usage.

Exemples de futures notes :

  • qu'est-ce que Django ?
  • qu'est-ce que DRF ?
  • comment fonctionne une API avec Django DRF ?
  • quelles sont les briques de base ?
  • comment penser modèles, serializers, vues, routeurs et permissions ?

Bloc C — Use Cases​

C'est le cœur du wiki. Chaque gros cas d'usage aura un tutoriel complet.

Bloc D — Comparaisons et clarifications​

Ce bloc aide à prendre des décisions et à éviter les confusions.

Exemples :

  • Django seul vs Django + DRF
  • Django DRF vs FastAPI
  • auth vs permissions
  • admin Django vs back-office sur mesure

Bloc E — Glossaire et notions de soutien​

Ce bloc lève les ambiguïtés de vocabulaire. Il permet de soulager les tutoriels principaux en externalisant certaines définitions.

6. Liste des grands use cases à couvrir​

Voici le backlog principal initial du wiki.

Use case 1 — Backend pour application web ou mobile avec Django DRF​

But : expliquer comment Django DRF devient la couche backend d'un frontend séparé.

À couvrir plus tard :

  • séparation front / back
  • API JSON
  • auth
  • gestion des ressources
  • interactions avec React, Next.js, Vue, Flutter ou React Native

Use case 2 — Application métier / SaaS / outil interne avec Django DRF​

But : montrer pourquoi Django DRF est fort pour les logiciels métiers structurés.

À couvrir plus tard :

  • logique métier
  • workflow
  • utilisateurs multiples
  • validation métier
  • productivité côté admin

Use case 3 — API avec utilisateurs, rôles et permissions avec Django DRF​

But : expliquer comment construire un backend où tous les utilisateurs ne voient pas ni ne font la même chose.

À couvrir plus tard :

  • authentification
  • autorisation
  • rôles
  • permissions par ressource
  • erreurs fréquentes dans la gestion des accès

Use case 4 — Application centrée base de données avec Django DRF​

But : montrer comment utiliser Django DRF quand le cœur du système est la donnée structurée.

À couvrir plus tard :

  • modèles relationnels
  • CRUD enrichi
  • filtres
  • recherche
  • pagination
  • cohérence métier

Use case 5 — API B2B / API interne avec Django DRF​

But : montrer comment exposer un backend robuste pour d'autres systèmes, équipes ou clients.

À couvrir plus tard :

  • API stable
  • contrats d'usage
  • sécurité
  • versionnement
  • maintenabilité

Use case 6 — Produit avec back-office et admin Django​

But : montrer l'intérêt de Django quand on veut à la fois une API et un back-office utile rapidement.

À couvrir plus tard :

  • admin Django
  • usages métier du back-office
  • modération
  • support opérationnel
  • limites de l'admin par défaut

Use case 7 — Backend produit autour d'un système IA avec Django DRF​

But : relier Django DRF à un produit plus intelligent que la simple API CRUD.

À couvrir plus tard :

  • gestion des utilisateurs
  • gestion des jobs ou analyses
  • stockage des résultats
  • historique
  • permissions
  • couche produit autour de l'inférence ou du workflow IA

7. Décision pédagogique importante​

Avant d'écrire le premier gros use case, il faut poser un socle de fondation.

Pourquoi ? Parce que sinon les tutoriels use case seront obligés de réexpliquer les mêmes bases à chaque fois.

Donc l'ordre logique recommandé devient :

  1. cadrage global
  2. règles éditoriales
  3. template standard
  4. socle de fondation
  5. premier gros use case
  6. enrichissements itératifs

8. Ce qu'on entend par “tutoriel complet”​

Dans ce wiki, un vrai tutoriel complet n'est pas une note courte.

Un tutoriel est considéré comme complet s'il permet au lecteur de répondre à ces questions :

  • de quoi parle exactement ce use case ?
  • à quel problème répond-il ?
  • pourquoi Django DRF est pertinent ici ?
  • quelles sont les limites de cette approche ?
  • quels sont les concepts que je dois comprendre avant d'aller plus loin ?
  • à quoi ressemble une architecture typique ?
  • comment penser la mise en œuvre étape par étape ?
  • quelles erreurs vais-je probablement rencontrer ?
  • comment faire évoluer cette base ensuite ?

9. Niveau de détail attendu​

Le niveau de détail attendu est volontairement élevé.

Cela signifie que :

  • les sections de contexte sont importantes
  • les définitions sont importantes
  • les exemples sont importants
  • les transitions entre sections sont importantes
  • les explications intermédiaires sont importantes

On privilégie donc :

  • la compréhension profonde
  • la cohérence pédagogique
  • la clarté du parcours lecteur

plutôt que :

  • la concision excessive
  • la vitesse de rédaction
  • l'effet de résumé rapide

10. Charte de qualité rédactionnelle​

Chaque futur tutoriel devra respecter cette charte :

1. Expliquer le vocabulaire​

Si un terme peut perdre un lecteur, il doit être défini ou relié à une note de glossaire.

2. Donner une intuition avant le détail​

Avant de plonger dans les composants, on explique la logique générale.

3. Relier technique et métier​

Un tutoriel doit montrer le lien entre :

  • besoin réel
  • décision architecturale
  • choix Django DRF

4. Éviter les raccourcis implicites​

Pas de “c'est évident” caché.

5. Laisser une porte ouverte à l'amélioration​

La note doit pouvoir être enrichie plus tard sans devoir être entièrement réécrite.

11. Stratégie d'itération​

Le wiki sera construit par incréments. Chaque itération peut servir à :

  • créer une nouvelle note de fondation
  • écrire un gros tutoriel use case
  • enrichir un tutoriel existant
  • ajouter un glossaire de soutien
  • clarifier un point de confusion
  • ajouter une comparaison structurante

Itération 1 — Cadrage​

Fait dans cette phase :

  • structure du wiki
  • plan directeur
  • schema éditorial
  • template de tutoriel

Itération 2 — Socle de fondation recommandé​

Contenu recommandé :

  • qu'est-ce que Django ?
  • qu'est-ce que DRF ?
  • comment penser une API avec Django DRF ?
  • quelles sont les briques de base ?

Itération 3 — Premier gros tutoriel use case recommandé​

Recommandation : commencer par Backend pour application web ou mobile avec Django DRF

Pourquoi ce choix ? Parce qu'il est concret, très fréquent et qu'il permet d'introduire naturellement la séparation front/back, l'API JSON, l'auth et la structure globale d'un backend.

12. Critère de réussite du wiki​

Le wiki réussira si, au fil des itérations, il devient capable de faire trois choses en même temps :

  1. former quelqu'un qui découvre Django DRF
  2. aider à décider si Django DRF est adapté à un projet donné
  3. servir de référence durable pour revenir sur un use case précis

13. Décision prise à la fin de cette itération​

Décision retenue :

  • on ne commence pas directement par un gros chapitre technique isolé
  • on pose d'abord une structure durable
  • on prépare le terrain pour un wiki cohérent et évolutif
  • le prochain incrément recommandé est le socle de fondation
success

Cette itération valide la base du projet documentaire. Le wiki a désormais une structure, une direction claire et une exigence qualité explicite.