Cas pratiques Django

Contexte : Un modèle a été créé mais n'apparaît pas dans l'interface admin. Le Problème : Le modèle n'est pas enregistré dans admin.py. Contraintes : Utiliser admin.site.register. Livrable attendu : Enregistrer correctement le modèle afin qu'il soit accessible via l'interface admin.

Contexte : Une page HTML doit être rendue côté serveur. Le Problème : Le template n'est pas trouvé lors du rendu. Contraintes : Vérifier la configuration TEMPLATES dans settings.py. Livrable attendu : Configurer correctement le dossier templates et implémenter une vue rendant un template HTML valide.

Contexte : Un nouveau champ a été ajouté à un modèle mais n'apparaît pas en base. Le Problème : Les migrations n'ont pas été générées ou appliquées. Contraintes : Utiliser makemigrations et migrate. Livrable attendu : Générer et appliquer correctement les migrations afin de synchroniser le schéma de base de données.

Contexte : Une vue Django provoque une erreur serveur lors de l'accès à la route. Le Problème : La fonction ne retourne pas d'objet HttpResponse. Code actuel : def home(request): data = {"message": "ok"} Contraintes : Utiliser JsonResponse ou HttpResponse. Livrable attendu : Corriger la vue afin qu'elle retourne une réponse HTTP valide contenant le JSON attendu.

Contexte : Une application doit permettre la soumission d'un formulaire côté serveur. Le Problème : Aucun formulaire Django n'est implémenté. Contraintes : Utiliser forms.Form. Livrable attendu : Créer un formulaire simple avec validation basique et afficher les données soumises en cas de succès.

Contexte : Une application doit stocker des utilisateurs personnalisés dans la base de données. Le Problème : Aucun modèle n'est défini pour représenter les données. Contraintes : Créer un modèle Django simple avec au moins deux champs et générer les migrations. Livrable attendu : Définir un modèle UserProfile, exécuter makemigrations et migrate, puis vérifier la création correcte en base.

Contexte : Vous démarrez un nouveau projet Django pour une application interne. Le Problème : Aucune vue n'est encore configurée pour répondre à une requête HTTP. Contraintes : Créer une app Django, définir une vue fonctionnelle simple et configurer l'URL correspondante. Livrable attendu : Implémenter une vue retournant une réponse JSON { "status": "ok" } accessible via la route /health correctement déclarée dans urls.py.

Contexte : L'équipe souhaite standardiser l'utilisation des Class-Based Views. Le Problème : Les vues actuelles sont uniquement fonctionnelles. Contraintes : Créer une vue héritant de View. Livrable attendu : Implémenter une Class-Based View répondant à une requête GET et retourner une réponse JSON simple.

Contexte : Une route doit afficher un objet en fonction de son identifiant. Le Problème : Le paramètre n'est pas correctement transmis à la vue. Contraintes : Utiliser path converters dans urls.py. Livrable attendu : Configurer une route du type /users/<int:id>/ et afficher l'id reçu dans la réponse.

Contexte : Les paramètres sensibles (SECRET_KEY, DEBUG) sont codés en dur. Le Problème : L'application n'est pas prête pour la production. Contraintes : Utiliser des variables d'environnement. Livrable attendu : Configurer settings.py pour lire les variables sensibles depuis l'environnement avec valeurs par défaut appropriées.

Contexte : L'application doit être déployée en production. Le Problème : DEBUG est activé et certaines configurations sensibles sont exposées. Contraintes : Configurer ALLOWED_HOSTS, DEBUG=False et variables d'environnement. Livrable attendu : Adapter la configuration settings.py pour un environnement production sécurisé et prêt au déploiement.

Contexte : Les erreurs API sont retournées avec des formats incohérents. Le Problème : Aucune gestion centralisée des exceptions n'est définie. Contraintes : Configurer un custom exception handler DRF. Livrable attendu : Mettre en place un gestionnaire global garantissant un format d'erreur uniforme pour toutes les réponses API.

Contexte : Une application doit limiter l'accès à certaines ressources selon le rôle utilisateur. Le Problème : Les permissions actuelles sont globales et non adaptées. Contraintes : Utiliser les permissions DRF ou créer une permission personnalisée. Livrable attendu : Mettre en place un système RBAC permettant de contrôler dynamiquement l'accès aux endpoints.

Contexte : Certaines actions doivent déclencher automatiquement des traitements secondaires. Le Problème : La logique est dupliquée dans plusieurs vues. Contraintes : Utiliser les signaux Django (post_save, pre_delete). Livrable attendu : Mettre en place un signal déclenchant une action métier automatiquement après création ou modification d'un modèle.

Contexte : L'application doit permettre l'upload d'images utilisateur. Le Problème : Aucun contrôle sur type ou taille de fichier. Contraintes : Utiliser FileField/ImageField avec validation personnalisée. Livrable attendu : Mettre en place un système d'upload sécurisé avec validation stricte et gestion d'erreur appropriée.

Contexte : Une API doit sécuriser ses endpoints pour des utilisateurs authentifiés. Le Problème : Aucun système d'authentification par token n'est configuré. Contraintes : Intégrer djangorestframework-simplejwt. Livrable attendu : Mettre en place une authentification JWT complète avec génération de token et protection des routes via permissions.

Contexte : Une API retourne de grandes listes d'objets. Le Problème : Toutes les données sont envoyées en une seule réponse. Contraintes : Utiliser ou personnaliser PageNumberPagination. Livrable attendu : Mettre en place une pagination efficace limitant le nombre d'éléments par requête et incluant métadonnées.

Contexte : Certaines vues sont coûteuses en calcul ou en requêtes base de données. Le Problème : Les performances se dégradent sous charge. Contraintes : Utiliser le framework de cache Django avec backend Redis ou mémoire. Livrable attendu : Implémenter un système de cache sur une vue ou une requête afin d'améliorer les performances.

Contexte : Une page liste des objets liés via relations ForeignKey ou ManyToMany. Le Problème : Les requêtes SQL sont trop nombreuses (N+1 problem). Contraintes : Utiliser select_related et prefetch_related pour optimiser. Livrable attendu : Refactoriser la requête ORM afin de réduire drastiquement le nombre de requêtes générées.

Contexte : Votre application Django doit exposer une API REST pour un front-end moderne. Le Problème : Les vues actuelles sont basées sur des templates HTML et ne suivent pas une architecture API propre. Contraintes : Utiliser Django REST Framework, créer serializers, views et router séparés. Livrable attendu : Mettre en place une API REST modulaire avec ViewSet, serializer et routes automatiques via DefaultRouter.

Contexte : Votre application Django a grandi rapidement et mélange vues, logique métier et accès base de données. Le Problème : Le couplage fort complique les tests unitaires et rend les évolutions risquées. Contraintes : Appliquer une architecture hexagonale (ports & adapters) en isolant le domaine métier de Django ORM et des vues. Livrable attendu : Proposer une structure séparant entités métier, cas d’usage, interfaces de repository et implémentations concrètes, afin d’améliorer testabilité, maintenabilité et évolutivité.

Contexte : Une application SaaS doit gérer des rôles complexes et permissions dynamiques. Le Problème : Les permissions actuelles sont statiques et insuffisantes. Contraintes : Implémenter un système RBAC ou ABAC personnalisé avec intégration DRF. Livrable attendu : Concevoir un moteur d’autorisation flexible capable de gérer rôles hiérarchiques, permissions dynamiques et multi-tenant.

Contexte : Une application SaaS doit gérer plusieurs organisations avec isolation stricte des données. Le Problème : Les données des différents tenants ne sont pas isolées correctement. Contraintes : Implémenter un système multi-tenant (par schéma ou par champ tenant_id) avec middleware dédié. Livrable attendu : Concevoir une architecture garantissant l’isolation des données entre tenants et empêchant tout accès croisé non autorisé.

Contexte : Une opération critique modifie plusieurs modèles en base. Le Problème : En cas d’erreur intermédiaire, l’état devient incohérent. Contraintes : Utiliser transaction.atomic et gestion d’erreurs avancée. Livrable attendu : Concevoir une logique garantissant atomicité et cohérence via transactions et rollbacks sécurisés.

Contexte : Une API Django REST doit gérer des sessions longue durée de manière sécurisée. Le Problème : Les refresh tokens actuels ne sont ni rotatifs ni invalidables. Contraintes : Implémenter JWT avec rotation automatique et blacklist. Livrable attendu : Concevoir un système complet incluant génération, rotation, révocation et sécurisation des refresh tokens conformément aux bonnes pratiques.

Contexte : L’application est déployée en production sur plusieurs instances. Le Problème : Les performances et erreurs sont difficiles à analyser. Contraintes : Intégrer logs structurés, métriques et monitoring (Prometheus ou équivalent). Livrable attendu : Mettre en place une architecture d’observabilité complète facilitant le debug, l’analyse de performance et la détection d’anomalies.

Contexte : L’application monolithique doit évoluer vers une architecture distribuée. Le Problème : Les modules sont fortement couplés et déployés ensemble. Contraintes : Utiliser un message broker (RabbitMQ ou Kafka) pour communication asynchrone. Livrable attendu : Proposer une architecture microservices découplant les domaines métier et permettant communication événementielle fiable.

Contexte : Une API Django subit une forte charge sur certains endpoints critiques. Le Problème : Les requêtes ORM deviennent un goulot d’étranglement. Contraintes : Intégrer Redis comme backend de cache et implémenter une stratégie d’invalidation fine. Livrable attendu : Mettre en place un système de cache distribué performant avec TTL et invalidation ciblée afin d’améliorer la latence et la scalabilité.

Contexte : L’application doit être déployée dans un environnement cloud avec autoscaling. Le Problème : L’architecture actuelle dépend d’états locaux et n’est pas optimisée pour la scalabilité. Contraintes : Rendre l’application stateless, externaliser sessions et cache. Livrable attendu : Proposer une architecture cloud-native compatible Docker et scalabilité horizontale avec gestion externe des états.

Contexte : L’application est exposée publiquement et doit respecter des standards élevés de sécurité. Le Problème : Certaines protections contre XSS, CSRF ou injections sont insuffisantes. Contraintes : Configurer correctement middleware de sécurité, validation stricte et headers HTTP sécurisés. Livrable attendu : Mettre en place une stratégie de sécurisation complète alignée avec les recommandations OWASP.