Quand choisir Django pour un SaaS ?
Nous le proposons notamment pour un logiciel métier, un espace client ou une plateforme où les données et les droits d’accès structurent les parcours. Son ORM, ses vues, ses gabarits et son administration évitent de réassembler ces fondations pour chaque projet. L’administration facilite le travail interne ; l’interface client reste à concevoir.
Le cadrage précise les utilisateurs, leurs actions, les données partagées et les intégrations nécessaires. Une simple vitrine sans logique métier ne justifie pas à elle seule une application Django.
Une architecture lisible dès la V1
Notre point de départ proposé est un monolithe modulaire : un déploiement cohérent, des applications organisées par domaine métier et des migrations versionnées. Nous explicitons les contraintes de données et les contrôles d’accès avant d’ouvrir un parcours.
- Données : modèles et contraintes pour représenter les règles qui doivent toujours rester vraies.
- Parcours : vues, validation et permissions ; gabarits Django ou interface distincte selon les interactions requises.
- Intégrations : contrats d’échange explicites ; une API lorsque le produit en a besoin.
- Traitements longs : séparer le travail lourd du temps de réponse HTTP et prévoir son suivi.
Cette proposition se discute avec votre équipe : elle ne suppose ni microservices ni réécriture de l’existant. La présentation officielle de Django explique les responsabilités de ses modèles, vues et gabarits.
Les limites à cadrer avant de construire
Django ne décide ni du produit ni de son ergonomie. Une interface très interactive, un calcul intensif ou une chaîne vidéo demandent des choix complémentaires, à justifier par l’usage. Nous mesurons les requêtes et les traitements avant de promettre un gain de performance.
L’asynchrone n’est pas un accélérateur automatique. En Django 5.2, les transactions ne fonctionnent pas encore en mode asynchrone : la documentation recommande de regrouper le code transactionnel dans une fonction synchrone appelée avec sync_to_async. Le choix WSGI/ASGI et les middlewares se vérifient sur l’application réelle. Voir les capacités et limites asynchrones.
Une recette définie avant la production
Nous proposons une recette fondée sur les risques du parcours livré, avec des critères observables :
- Tester le parcours principal et ses refus : rôle insuffisant, donnée d’un autre client, contenu privé ou formulaire invalide.
- Vérifier les règles métier et les intégrations : erreurs du fournisseur, événement reçu deux fois et reprise après interruption.
- Exécuter les tests avec le moteur de base prévu en production, puis contrôler les migrations sur une base neuve et une copie de préproduction adaptée.
- Vérifier l’interface au clavier et sur mobile ; consigner séparément les contrôles automatiques et la recette visuelle.
- Avant bascule, contrôler la configuration de production avec
check --deploy, les secrets, HTTPS, les fichiers statiques, la journalisation et une restauration de sauvegarde.
Ce sont des critères à convenir pour votre projet, pas une certification. Les références sont le guide des tests Django et la liste de contrôle du déploiement.