SCHEMA

Repères utiles

• FastAPI LLM Wiki
• Plan directeur
• Template de tutoriel
• Parcours de lecture
• FAQ, erreurs fréquentes et conseils pratiques
• Journal d’itération

Domain

Ce wiki couvre FastAPI sous la forme d'un grand guide pédagogique en français, centré sur la construction d'APIs concrètes, lisibles et progressivement enrichissables.

L'objectif n'est pas seulement d'expliquer FastAPI comme un framework abstrait. L'objectif est de montrer comment construire une vraie API pas à pas, avec une architecture claire, du code guidé, une logique compréhensible, et une progression durable.

Core Promise

Chaque note de ce wiki doit respecter cette promesse :

• être compréhensible par un débutant motivé
• être assez concrète pour être vraiment utilisée
• montrer du code réel, pas seulement des généralités
• expliquer pourquoi chaque fichier existe et à quoi il sert
• donner au lecteur un chemin clair pour lancer, tester et faire évoluer ce qu'il construit

Editorial Principles

1. Le code est obligatoire quand le sujet est pratique

Pour ce wiki, un gros tutoriel pratique n'est pas recevable s'il reste au niveau de la théorie.

Donc :

• on montre les commandes
• on montre l'arborescence du projet
• on montre les fichiers
• on montre le code
• on montre comment vérifier que cela fonctionne

2. L'architecture doit être visible

Le lecteur doit comprendre très tôt :

• où entre la requête HTTP
• où vit la logique métier
• où se trouve la base de données
• comment les dépendances sont injectées
• comment les données circulent de l'appel API jusqu'à la réponse JSON

3. Progressivité obligatoire

Chaque gros tutoriel doit aller du plus rassurant au plus structurant :

1. le problème concret
2. le contexte
3. le vocabulaire
4. la vision d'ensemble
5. l'arborescence
6. l'implémentation guidée avec code
7. la vérification guidée
8. les erreurs fréquentes
9. les pistes d'évolution

4. Le wiki doit prendre le lecteur par la main

On ne suppose pas que le lecteur comprend déjà :

• les imports
• les schémas Pydantic
• les sessions SQLAlchemy
• l'injection de dépendances
• l'intérêt d'un service layer

Tout cela doit être expliqué dans le corps des notes.

5. Fidélité d'architecture, pas copier-coller aveugle

Le wiki peut s'inspirer d'un repo réel tout en améliorant :

• la pédagogie
• le setup
• les exemples
• la robustesse

L'objectif est de reprendre la même logique d'architecture sans figer les imperfections du repo source comme des vérités absolues.

Folder Structure

FastAPI LLM Wiki/
├── SCHEMA.md
├── index.md
├── log.md
├── FastAPI LLM Wiki - Plan directeur.md
├── FastAPI LLM Wiki - Template de tutoriel.md
├── Parcours de lecture du FastAPI LLM Wiki.md
├── FAQ - erreurs fréquentes - conseils pratiques FastAPI.md
├── Foundations/
└── Use Cases/
    ├── API de base/
    │   └── API de base.md
    └── Advanced FastAPI/
        ├── Advanced FastAPI.md
        └── ... autres chapitres du bloc avancé

Page Types

1. Schema

Définit les règles éditoriales et pédagogiques du wiki.

2. Meta / Pilotage

Définit la vision globale, les décisions structurantes, les templates et les journaux d'évolution.

3. Foundation

Regroupe les notes de socle si l'on décide ensuite d'expliquer séparément FastAPI, HTTP, Pydantic, SQLModel, PostgreSQL, l'async, ou la logique d'architecture.

4. Use Case

Gros tutoriels pratiques et structurés.

Les use cases peuvent être regroupés physiquement par grand bloc pédagogique quand cela améliore la lisibilité dans Obsidian.

Exemples actuels pour ce wiki :

• dossier Use Cases/API de base/
• dossier Use Cases/Advanced FastAPI/
• note API de base
• note Authentification avec FastAPI
• note Docker avec FastAPI

5. Navigation / Raffinement

Notes transversales qui aident à lire, parcourir et consolider le wiki sans ajouter un nouveau gros cas d'usage.

Ces notes restent des notes de pilotage/meta : elles ne changent pas de nature documentaire simplement parce qu’elles orientent la lecture.

Exemples actuels :

• Parcours de lecture du FastAPI LLM Wiki
• FAQ - erreurs fréquentes - conseils pratiques FastAPI

Choix structurel pour cette version

Ce wiki reste volontairement léger.

Donc, pour cette version :

• pas de dossier Glossaire/
• pas de dossier Comparisons/
• pas de dossier Sources/

Ces éléments ne sont pas prioritaires ici et ont été supprimés pour garder une structure claire, utile et sans bruit.

Required Frontmatter

Chaque nouvelle note doit au minimum contenir :

---
title: Nom de la note
tags:
  - fastapi
  - llm-wiki
created: YYYY-MM-DD
updated: YYYY-MM-DD
type: meta | foundation | use-case | schema
status: draft | active | revised
---

Naming Conventions

• Les noms de notes doivent être humains, explicites et pédagogiques.
• On privilégie la clarté à la brièveté.
• Les titres de gros tutoriels doivent dire immédiatement ce que l'on construit.
• Quand l'utilisateur impose un nom de section, on le respecte.

Exemples :

• FastAPI LLM Wiki - Plan directeur
• FastAPI LLM Wiki - Template de tutoriel
• API de base

Pedagogical Checklist

Chaque gros tutoriel doit, si pertinent, couvrir :

• pour qui il est écrit
• le problème concret à résoudre
• quand utiliser FastAPI pour ce cas
• quand ne pas l'utiliser
• les prérequis
• le vocabulaire indispensable
• la vision d'ensemble
• l'architecture type
• la structure du mini-projet
• des repères utiles avant de lire le code
• une implémentation guidée avec code
• des commandes à lancer
• une méthode de vérification claire
• les erreurs fréquentes
• les bonnes pratiques
• les pistes d'évolution
• une checklist de validation quand le chapitre est pratique
• un résumé final
• un Pour aller plus loin qui route clairement vers la suite logique

Minimum Quality Bar

Une note n'est pas suffisante si elle :

• se contente d'une introduction conceptuelle
• parle d'architecture sans montrer où vit le code
• donne du code sans explication pédagogique
• ne montre pas comment lancer ou tester l'API
• laisse le lecteur seul face à des implicites techniques importants

Link Policy

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

• une note de pilotage
• une note sœur utile
• un futur chapitre lié quand cela aide la progression
• si pertinent, une note de navigation comme Parcours de lecture ou FAQ, erreurs fréquentes et conseils pratiques
• en fin de chapitre, au moins un renvoi global et un renvoi pratique vers la suite la plus logique

Tag Taxonomy

Tags principaux autorisés pour ce wiki :

• fastapi
• llm-wiki
• pedagogy
• tutorial
• backend
• api
• python
• postgres
• sqlmodel
• pydantic
• async
• architecture
• use-case
• foundation
• schema
• index
• plan
• log
• template
• navigation
• reading-path
• faq
• troubleshooting

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'améliorer le code montré
• on a le droit d'ajouter une meilleure séquence pédagogique
• on documente les changements importants dans log.md

Decision for Current Version

La version actuelle établit maintenant :

• la structure de base du wiki
• le plan directeur
• le template éditorial standard
• le socle pratique API de base
• le hub Advanced FastAPI
• dix sous-chapitres avancés rédigés
• une couche de navigation avec Parcours de lecture et FAQ, erreurs fréquentes et conseils pratiques
• une harmonisation finale des sorties de chapitre et de l’ordre de lecture

Décisions spécifiques importantes :

• la première grande section ne s'appelle pas "section 1"
• elle s'appelle API de base
• elle doit montrer du code obligatoire, pas seulement des explications
• elle s'appuie sur l'architecture du repo task-organizer-API
• les dossiers Glossaire/, Comparisons/ et Sources/ ont été supprimés car inutiles pour cette version
• les notes de navigation/raffinement restent des notes meta
• la version 1 est désormais considérée comme complète et stabilisée