FAQ, erreurs fréquentes et conseils pratiques
Cette note regroupe les questions et pièges les plus probables quand on suit ce wiki de manière progressive.
Questions fréquentes
Faut-il lire tous les chapitres ?
Non.
Le wiki est structuré pour être progressif, mais tu peux choisir un parcours selon ton objectif. Pour ça, commence par :
Pourquoi API de base est-il si important ?
Parce que presque tout le reste s’appuie dessus :
- auth,
- relations SQL,
- erreurs,
- middleware,
- tests,
- Docker,
- notifications,
- Celery,
- frontend.
Si API de base n’est pas clair, les chapitres avancés vont te sembler artificiels ou trop lourds.
Est-ce grave si je ne fais pas le frontend React ?
Non.
Le frontend est un bonus. Le cœur du wiki reste backend-first. Tu peux apprendre énormément sur FastAPI sans faire le chapitre React.
Pourquoi la route /user/token n’accepte pas simplement du JSON ?
Parce que dans ce wiki, elle est branchée sur OAuth2PasswordRequestForm.
Donc elle attend un corps compatible :
application/x-www-form-urlencoded
C’est pour cela que le frontend React doit utiliser :
URLSearchParams
et pas un simple JSON.stringify().
Pourquoi le login peut-il échouer alors que l’email et le mot de passe sont corrects ?
Parce que l’utilisateur peut être :
- non vérifié,
- mal chargé,
- ou son token/l’état peut être incohérent.
Le cas le plus fréquent dans ce wiki est :
email_verified = False
Dans ce cas, c’est normal que la connexion soit refusée tant que l’email n’a pas été validé.
Pourquoi le reset password répond toujours avec un message générique ?
Pour éviter de révéler si un compte existe ou non.
C’est une petite mesure simple, mais très utile contre l’énumération de comptes.
Pourquoi avoir d’abord utilisé BackgroundTasks, puis Celery ?
Parce que c’est le chemin pédagogique le plus clair.
BackgroundTasks
Bien pour :
- comprendre le flux,
- commencer simplement,
- éviter d’introduire Redis et worker trop tôt.
Celery
Bien pour :
- rendre les jobs plus robustes,
- sortir le travail du process FastAPI,
- monter en charge plus proprement.
Le wiki montre volontairement cette progression.
Pourquoi Docker arrive après les tests ?
Parce que Docker emballe une application.
Si l’application n’est pas encore suffisamment claire et testable, dockeriser trop tôt risque surtout de masquer les problèmes au lieu de les clarifier.
Pourquoi le frontend React demande du CORS côté FastAPI ?
Parce que dans le navigateur :
- frontend et backend tournent sur des origines différentes,
- par exemple
localhost:5173etlocalhost:8000.
Sans CORSMiddleware, les requêtes seront bloquées par le navigateur.
Erreurs fréquentes
Erreur fréquente — CORS bloque tout
Symptôme
Le frontend n’arrive pas à appeler l’API depuis le navigateur.
Cause fréquente
CORSMiddleware absent ou origine oubliée.
Réflexe
Vérifie d’abord :
C’est le chapitre qui centralise l’ajout de CORSMiddleware, le contrat frontend/backend et les appels navigateur.
Erreur fréquente — 401 Unauthorized
Symptôme
Les routes protégées refusent l’accès.
Causes fréquentes
- token absent,
- token expiré,
- header
Authorizationnon injecté, - utilisateur non trouvé,
- email non vérifié.
Réflexe
Vérifie d’abord :
Erreur fréquente — 422 Unprocessable Entity
Symptôme
La route reçoit bien la requête, mais refuse les données.
Causes fréquentes
- mauvais nom de champ,
- JSON au lieu de form-encoded,
- schéma incomplet,
- type inattendu.
Réflexe
Compare précisément :
- le schéma FastAPI attendu,
- le payload réellement envoyé.
Reviens surtout à :
- Authentification avec FastAPI — si l’erreur touche
/user/tokenou les formulaires d’auth - Frontend React consommant l’API FastAPI — si l’erreur vient d’un client React qui envoie le mauvais format
- API de base — si le problème vient d’un schéma CRUD ou d’un payload métier
Erreur fréquente — les tâches ne s’affichent pas côté frontend
Symptôme
Le dashboard est vide alors que les données existent.
Causes fréquentes
- appel du mauvais endpoint,
- token non injecté,
- oubli de
queryKeyou d’invalidation React Query, - utilisateur connecté différent.
Réflexe
Revalide :
/task/mine- le token frontend
- la session utilisateur réellement active
Erreur fréquente — le worker Celery ne fait rien
Symptôme
L’API répond, mais les mails/SMS ne partent pas.
Causes fréquentes
- worker non lancé,
- Redis non disponible,
- mauvais
REDIS_HOSTouREDIS_PORT, - mauvais chemin
-Apour Celery.
Réflexe
Reviens à :
Erreur fréquente — token de vérification ou de reset invalide
Symptôme
Le lien reçu par email ne fonctionne pas.
Causes fréquentes
- token expiré,
- mauvais
salt, - secret changé,
- URL coupée ou mal copiée.
Réflexe
Vérifie :
- la génération du token,
- la lecture du token,
- la cohérence du
salt, - l’expiration attendue.
Le meilleur chapitre à relire est :
Et si le doute porte sur l’utilisateur ou l’état de connexion autour du flow, reviens aussi à :
Conseils pratiques
Conseil pratique — ne confonds pas les responsabilités
Le backend doit porter :
- validation,
- auth,
- sécurité,
- règles métier,
- accès DB,
- jobs asynchrones.
Le frontend doit porter :
- navigation,
- état d’interface,
- formulaires,
- expérience utilisateur,
- appels API correctement branchés.
Cette séparation aide énormément à garder le projet lisible.
Conseil pratique — ne complexifie pas tout dès le début
Le wiki montre une progression utile :
- base simple,
- puis auth,
- puis données,
- puis robustesse,
- puis packaging,
- puis communication utilisateur,
- puis async,
- puis frontend bonus.
Si tu essaies de tout faire en même temps, tu risques surtout de perdre la logique d’ensemble.
Conseil pratique — quand tu bloques, reviens au dernier état stable
Exemple :
- si Celery te bloque, reviens au chapitre notifications simple,
- si React te bloque, reviens aux tests d’API backend,
- si auth te bloque, reviens à
API de basepuis auth.
C’est souvent la manière la plus rapide d’avancer proprement.
Résumé rapide
Le plus important à retenir est simple :
- les erreurs les plus pénibles viennent souvent d’une couche mal comprise,
- le wiki est justement là pour les séparer,
- et cette note sert à t’aider à retrouver rapidement le bon chapitre quand ça coince.
Si tu ne sais plus dans quel ordre reprendre, reviens à Parcours de lecture.