Aller au contenu principal

SCHEMA

Repères utiles :

Domain​

Ce wiki couvre Django et Django REST Framework sous la forme d'un grand guide pédagogique en français, organisé autour de cas d'usage concrets.

L'objectif n'est pas seulement d'expliquer des concepts isolés. L'objectif est de permettre à une personne de comprendre quand utiliser Django DRF, pourquoi, comment structurer un projet, et comment avancer pas à pas sans se perdre.

Core Promise​

Chaque contenu du wiki doit respecter cette promesse :

  • être compréhensible par un débutant motivé
  • être utile à un lecteur intermédiaire
  • être suffisamment structuré pour servir de référence durable
  • être ouvert à l'amélioration, à la réécriture et à l'enrichissement

Editorial Principles​

1. Pédagogie avant densité brute​

On ne cherche pas à impressionner le lecteur. On cherche à l'aider à comprendre.

Donc :

  • définir les termes avant de les utiliser intensivement
  • expliquer le pourquoi avant le comment
  • éviter les sauts implicites
  • reformuler quand un concept risque d'être flou

2. Aucun tutoriel bâclé​

Un tutoriel ne doit jamais être :

  • trop court
  • purement théorique si un exemple concret est nécessaire
  • purement technique si le lecteur n'a pas d'ancrage métier
  • une succession d'étapes non expliquées

3. Progressivité obligatoire​

Chaque tutoriel doit aller du plus simple au plus structurant :

  1. le problème
  2. le contexte
  3. le vocabulaire
  4. la logique globale
  5. la mise en œuvre
  6. les erreurs fréquentes
  7. les améliorations possibles

4. Une note doit pouvoir vivre dans le temps​

Chaque note doit pouvoir être :

  • enrichie
  • corrigée
  • scindée si elle devient trop grosse
  • reliée à d'autres notes via des wikilinks

5. Le wiki doit prendre le lecteur par la main​

Le lecteur ne doit pas avoir l'impression qu'on suppose qu'il sait déjà tout. Le texte doit guider, rassurer, expliquer et contextualiser.

Folder Structure​

Projects/Django DRF LLM Wiki/
├── SCHEMA.md
├── index.md
├── log.md
├── Django DRF LLM Wiki - Plan directeur.md
├── Django DRF LLM Wiki - Template de tutoriel.md
├── Foundations/
├── Use Cases/
├── Glossaire/
├── Comparisons/
└── Sources/

Page Types​

1. Schema​

Définit les règles du wiki.

2. Meta / Pilotage​

Pages de cadrage, feuille de route, décisions éditoriales.

3. Foundation​

Pages de socle : Django, DRF, ORM, serializer, router, viewset, permissions, auth, architecture générale.

4. Use Case​

Tutoriels longs et complets orientés cas d'usage. Exemples :

  • backend pour app web/mobile
  • application métier / SaaS
  • API avec rôles et permissions
  • backend produit autour d'un système IA

5. Glossary​

Pages de vocabulaire pour lever les ambiguïtés.

6. Comparison​

Comparaisons structurées. Exemples :

  • Django vs DRF
  • Django DRF vs FastAPI
  • API monolithique vs architecture plus distribuée

7. Source​

Sources brutes ou notes de matière première si l'on ajoute plus tard des références officielles, docs ou supports de cours.

Required Frontmatter​

Chaque nouvelle note doit au minimum contenir :

---
title: Nom de la note
tags:
  - django
  - drf
created: YYYY-MM-DD
updated: YYYY-MM-DD
type: meta | foundation | use-case | glossary | comparison | source | schema
status: draft | active | revised
---

Naming Conventions​

  • Les notes doivent avoir des noms lisibles, humains et explicites.
  • On privilégie les titres longs mais clairs plutôt que des abréviations cryptiques.
  • Les titres de tutoriels doivent indiquer immédiatement le sujet.

Exemples :

  • Django DRF LLM Wiki - Plan directeur
  • Backend pour application web ou mobile avec Django DRF
  • API avec utilisateurs, rôles et permissions avec Django DRF

Pedagogical Checklist​

Chaque tutoriel doit, si pertinent, couvrir :

  • pour qui est le tutoriel
  • le problème concret à résoudre
  • quand utiliser Django DRF pour ce cas
  • quand ne pas l'utiliser
  • les prérequis
  • le vocabulaire indispensable
  • la vision d'ensemble
  • l'architecture type
  • une progression étape par étape
  • une structure de mini-projet ou de fichiers quand le use case s'y prête
  • une implémentation guidée avec code pour les chapitres pratiques
  • une méthode claire pour vérifier ou tester ce qui a été construit
  • les erreurs fréquentes
  • les bonnes pratiques
  • les limites
  • les pistes d'amélioration
  • un résumé final

Minimum Quality Bar​

Une note n'est pas considérée comme suffisante si elle :

  • fait seulement une introduction générale
  • ne donne pas de contexte métier
  • ne clarifie pas le vocabulaire clé
  • liste des étapes sans explication pédagogique
  • laisse trop de zones implicites

Splitting Rule​

Si une note devient trop longue ou mélange plusieurs intentions, on la scinde.

Exemples :

  • un tutoriel principal
  • une note annexe de glossaire
  • une note annexe d'erreurs fréquentes
  • une note annexe de comparaison

Dès que le wiki grandit, chaque note doit essayer de pointer vers :

  • une note de fondation
  • une note de glossaire ou comparaison
  • une note sœur liée à un autre cas d'usage

Tag Taxonomy​

Tags principaux autorisés pour ce wiki :

  • django
  • drf
  • llm-wiki
  • pedagogy
  • tutorial
  • foundation
  • use-case
  • backend
  • api
  • orm
  • serializer
  • viewset
  • router
  • auth
  • permissions
  • admin
  • saas
  • b2b
  • mobile
  • web
  • database
  • architecture
  • glossary
  • comparison
  • ia
  • product

Revision Policy​

Le wiki est pensé pour l'itération. Donc :

  • on a le droit de réécrire une note
  • on a le droit d'enrichir une note existante
  • on a le droit de déplacer une section si sa place est meilleure ailleurs
  • on documente les grandes évolutions dans log.md

Decision for Iteration 1​

L'itération 1 établit :

  • la structure de base du wiki
  • le plan directeur
  • le template éditorial standard
  • le backlog initial des grands cas d'usage

Le prochain incrément recommandé est la création du socle de fondation avant d'attaquer le premier gros use case.