Checklist pratique

Repères utiles

• FastAPI LLM Wiki
• Parcours de lecture
• FAQ, erreurs fréquentes et conseils pratiques
• API de base
• Advanced FastAPI
• Tests avec FastAPI
• Docker avec FastAPI
• Frontend React consommant l’API FastAPI

remarque

Cette checklist transforme le wiki en plan d’exécution pratique. Elle ne remplace pas les chapitres : elle aide à vérifier, étape par étape, que ton projet FastAPI devient vraiment exploitable.

Pourquoi cette checklist existe

Le Parcours de lecture répond surtout à la question :

Dans quel ordre lire le wiki ?

Cette note répond à une autre question :

Comment savoir que mon API est réellement propre, testable et prête à évoluer ?

Elle sert donc de pont entre :

• la lecture pédagogique,
• l’implémentation dans ton propre projet,
• et la vérification concrète de ce que tu as construit.

Utilise-la comme une checklist de maturité : tu peux cocher progressivement les points au fil des chapitres.

Comment l’utiliser

Tu peux t’en servir de trois façons.

1. Avant de commencer

Lis rapidement cette note pour comprendre le chemin global :

• socle,
• auth,
• ownership,
• robustesse,
• tests,
• Docker,
• async,
• frontend bonus.

2. Pendant la lecture

Après chaque chapitre, reviens ici et coche les points associés. Cela évite de lire passivement sans vérifier que tu sais refaire les étapes.

3. Sur ton propre projet

Quand tu construis une vraie API, utilise cette note comme une grille de revue. Si plusieurs cases importantes restent floues, il vaut mieux revenir au chapitre concerné avant d’ajouter une nouvelle couche.

Checklist 0 — choisir le bon chemin

Avant d’écrire du code, clarifie ton objectif.

• Je sais si je veux seulement apprendre FastAPI ou construire une API produit.
• J’ai identifié mon point d’entrée avec Parcours de lecture.
• Je sais que API de base est le socle du reste du wiki.
• Je sais que Frontend React consommant l’API FastAPI est un bonus, pas une obligation.
• Je garde FAQ, erreurs fréquentes et conseils pratiques à portée de main pour débloquer les erreurs fréquentes.

Si tu hésites encore, commence par API de base. C’est le chapitre qui rend tout le reste plus compréhensible.

Checklist 1 — poser le socle FastAPI

Chapitre principal : API de base.

À la fin du socle, tu dois pouvoir dire :

• Je sais créer un projet FastAPI proprement.
• Je sais où placer main.py, la configuration, les routes, les schémas, les services et la base de données.
• Je comprends le rôle d’un service layer.
• Je comprends pourquoi les routes doivent rester fines.
• Je sais brancher PostgreSQL ou au moins comprendre où la connexion base de données intervient.
• Je sais lancer l’API localement.
• Je sais ouvrir /docs et utiliser la documentation interactive.
• Je sais appeler les endpoints principaux avec curl.
• Je sais vérifier qu’une donnée a bien été créée, lue, modifiée ou supprimée.

Signal de maîtrise

Tu n’as pas seulement copié le code : tu peux expliquer le trajet complet :

requête HTTP → route FastAPI → schéma Pydantic → service → base de données → réponse JSON

Si ce trajet n’est pas clair, reviens au socle avant d’aller vers l’auth ou Docker.

Checklist 2 — ajouter identité et sécurité

Chapitre principal : Authentification avec FastAPI.

À ce stade, tu dois vérifier :

• Je comprends la différence entre inscription, login et utilisateur courant.
• Je sais pourquoi un mot de passe doit être hashé.
• Je comprends le rôle d’un JWT.
• Je sais pourquoi OAuth2PasswordRequestForm attend du application/x-www-form-urlencoded.
• Je sais protéger une route avec une dépendance d’utilisateur courant.
• Je sais expliquer pourquoi le logout côté JWT est souvent plus subtil qu’un simple endpoint.
• Je sais tester un endpoint protégé avec un token.

Signal de maîtrise

Tu peux prendre une route existante et répondre précisément :

Est-ce que cette route doit être publique, authentifiée, ou réservée à un owner précis ?

Si la réponse est floue, ne passe pas tout de suite aux notifications ou au frontend.

Checklist 3 — relier les données au bon utilisateur

Chapitre principal : Relations SQL avec FastAPI.

Cette étape transforme une API technique en API applicative.

• Mes données importantes sont reliées à un utilisateur quand c’est nécessaire.
• Je comprends la différence entre user_id en base et current_user dans le code FastAPI.
• Je sais filtrer les données par owner.
• Je sais éviter qu’un utilisateur lise ou modifie les données d’un autre.
• Je sais écrire une requête qui récupère seulement les objets autorisés.
• Je comprends pourquoi l’ownership doit être vérifié côté backend, pas seulement côté frontend.

Signal de maîtrise

Tu sais expliquer pourquoi cette règle est dangereuse :

“Si l’ID est dans l’URL, je fais confiance au frontend.”

Le frontend peut aider l’expérience utilisateur, mais il ne doit jamais être la barrière de sécurité principale.

Checklist 4 — rendre l’API robuste et observable

Chapitres principaux :

• Gestion d’erreurs avec FastAPI
• Middleware avec FastAPI
• Réponses personnalisées avec FastAPI

À vérifier :

• Les erreurs métier importantes ont des réponses propres et cohérentes.
• Je ne renvoie pas des exceptions brutes au client.
• Je sais choisir un bon statut HTTP.
• Je sais centraliser certains handlers d’erreurs.
• Je comprends ce qu’un middleware peut faire proprement.
• Je sais ajouter un request ID ou une mesure de durée sans polluer toutes les routes.
• Je sais quand utiliser response_model.
• Je sais quand utiliser response_class.
• Je sais éviter de mélanger validation de données, rendu de réponse et logique métier.

Signal de maîtrise

Ton API devient plus facile à diagnostiquer :

• les erreurs sont lisibles,
• les logs racontent le trajet de la requête,
• les réponses ont une forme prévisible.

Checklist 5 — verrouiller avec des tests

Chapitre principal : Tests avec FastAPI.

Avant de dire qu’un comportement est stable, vérifie :

• Je sais lancer les tests avec pytest.
• Je sais tester un endpoint public.
• Je sais tester un endpoint protégé.
• Je sais préparer un utilisateur de test.
• Je sais utiliser un client de test adapté.
• Je sais isoler la base de test ou utiliser une configuration dédiée.
• Je sais tester un cas de succès et au moins un cas d’erreur.
• Je sais vérifier que l’ownership est réellement respecté.

Signal de maîtrise

Tu peux modifier une route ou un service et savoir rapidement si tu as cassé :

• l’auth,
• les permissions,
• la validation,
• ou le format de réponse.

Sans tests, le projet peut fonctionner “à la main” tout en restant fragile.

Checklist 6 — préparer une exécution reproductible

Chapitre principal : Docker avec FastAPI.

À vérifier :

• Je sais pourquoi Docker arrive après un socle clair et testable.
• Je comprends la différence entre image et container.
• Je sais écrire un Dockerfile lisible.
• Je sais lancer l’API avec Docker Compose.
• Je sais brancher PostgreSQL via Compose.
• Je sais adapter les variables d’environnement entre local et container.
• Je sais lire les logs d’un service containerisé.
• Je sais redémarrer proprement la stack.

Signal de maîtrise

Tu peux expliquer ce qui change entre :

localhost côté machine

et :

nom du service côté réseau Docker Compose

C’est une différence essentielle pour éviter les erreurs de connexion à la base.

Checklist 7 — gérer les communications utilisateur et l’async

Chapitres principaux :

• Notifications et communication utilisateur avec FastAPI
• Tâches asynchrones avec Celery et FastAPI

À vérifier :

• Je sais distinguer email de vérification, reset password et notification simple.
• Je comprends pourquoi un lien de reset doit expirer.
• Je sais éviter de révéler si un compte existe dans une réponse de reset password.
• Je sais pourquoi BackgroundTasks est utile pour commencer simplement.
• Je sais pourquoi Celery devient utile quand les tâches deviennent plus lourdes ou critiques.
• Je comprends le rôle de Redis dans l’architecture Celery.
• Je sais qu’un worker Celery doit tourner séparément de FastAPI.
• Je sais relire les logs du worker quand une tâche ne part pas.

Signal de maîtrise

Tu sais expliquer cette progression :

d’abord rendre le flow compréhensible, puis seulement ensuite externaliser l’exécution.

Si tu ajoutes Celery avant de comprendre le flow métier, tu risques surtout de rendre le problème plus difficile à déboguer.

Checklist 8 — brancher un frontend sans déplacer la logique de sécurité

Chapitre principal : Frontend React consommant l’API FastAPI.

À vérifier :

• Je sais activer CORS côté FastAPI quand le navigateur appelle l’API.
• Je sais envoyer le login au bon format attendu par le backend.
• Je sais centraliser les appels API côté frontend.
• Je sais ajouter le header Authorization: Bearer ... au bon endroit.
• Je sais protéger une route frontend sans croire que cela remplace la sécurité backend.
• Je sais invalider ou recharger les données après une mutation.
• Je sais distinguer confort UX côté React et règles de sécurité côté FastAPI.

Signal de maîtrise

Ton frontend facilite l’usage, mais ton backend reste l’autorité :

• il valide,
• il authentifie,
• il vérifie l’ownership,
• il décide ce qui est autorisé.

Checklist finale — avant de dire “mon API est propre”

Une API FastAPI est beaucoup plus crédible si tu peux cocher ces points :

• Le projet se lance depuis une machine propre avec des instructions claires.
• Les variables d’environnement importantes sont documentées.
• Les routes principales sont visibles dans /docs.
• Les routes sensibles exigent une authentification.
• Les données utilisateur sont filtrées par ownership.
• Les erreurs fréquentes renvoient des réponses cohérentes.
• Les tests couvrent au moins les flows critiques.
• Docker ou un équivalent rend l’exécution reproductible.
• Les tâches longues ne bloquent pas inutilement le cycle HTTP.
• Le frontend, s’il existe, respecte le contrat réel de l’API.
• Je sais expliquer l’architecture à quelqu’un d’autre sans ouvrir tous les fichiers.

Signaux d’alerte

Reviens à un chapitre précédent si :

• tu ajoutes Docker alors que tu ne sais pas encore lancer l’API localement ;
• tu ajoutes un frontend alors que l’auth backend est floue ;
• tu ajoutes Celery alors que le flow métier n’est pas clair ;
• tu copies des routes sans savoir où mettre la logique métier ;
• tu testes uniquement dans /docs sans aucun test automatisé ;
• tu relies les données à un utilisateur côté interface, mais pas côté base/backend ;
• tu ne sais pas expliquer pourquoi une erreur renvoie tel statut HTTP.

Résumé rapide

Cette checklist condense le wiki en un chemin d’exécution :

1. poser le socle avec API de base ;
2. ajouter identité, ownership et robustesse avec Advanced FastAPI ;
3. verrouiller avec Tests avec FastAPI ;
4. rendre l’exécution reproductible avec Docker avec FastAPI ;
5. ajouter les flows utilisateur, l’async et éventuellement le frontend ;
6. revenir à FAQ, erreurs fréquentes et conseils pratiques dès qu’un point devient flou.

Le but n’est pas d’aller vite. Le but est d’obtenir une API que tu peux comprendre, relancer, tester, expliquer et faire évoluer.