PROJET ETUDIANT : Architecture back-end en CLI avec Python/SQL
Ce projet est une application CRM en ligne de commande développée en Python pour la société fictive Epic Events.
L’objectif était de concevoir une architecture logicielle propre et maintenable permettant de gérer les collaborateurs, clients, contrats et événements avec un système d’authentification, de permissions et de suivi des actions.
J’ai particulièrement porté mon attention sur :
- la séparation claire des responsabilités avec une architecture MVC adaptée à une application CLI ;
- la modularité du code grâce à l’utilisation de controllers spécialisés ;
- la gestion des permissions par rôle (manager, commercial, support/technicien) ;
- la qualité du code avec typage statique, linting et refactorisation ;
- la robustesse applicative via la gestion des exceptions et la validation des entrées utilisateur ;
- la mise en place de tests unitaires et tests CLI automatisés ;
- la persistance des données avec SQLAlchemy et une architecture compatible MySQL/SQLite ;
- l’amélioration de l’expérience utilisateur en terminal grâce à Rich ;
- Le monitoring avec la journalisation et l’intégration Sentry ;
- l’automatisation de la qualité de code avec Flake8, Isort et Coverage.
Ce projet m’a permis de travailler sur des problématiques proches d’un contexte professionnel réel : architecture applicative, découplage des composants, gestion des dépendances, debugging avancé, qualité logicielle et maintenabilité du code.
Problématiques rencontrées :
1. Gestion complexe des tests CLI avec Click et les prompts interactifs
Problème : Les tests CLI échouaient à cause des prompts Click interactifs (Prompt.ask) qui bloquaient l’exécution des tests automatisés.
Solution : J’ai mis en place du mocking avec unittest.mock.patch afin de remplacer les prompts utilisateurs par des valeurs simulées pendant les tests.
Ce que j’ai appris :
- comprendre le fonctionnement interne des commandes Click ;
- distinguer les objets réellement patchés des objets instanciés ;
- améliorer la testabilité d’une application CLI.
2. Incohérences de session SQLAlchemy entre l’application et les tests
Problème : Certaines données récupérées pendant les tests semblaient incohérentes (mauvais utilisateur, mauvais rôle, objets inattendus).
Solution : J’ai identifié un problème de multiplication des sessions SQLAlchemy et uniformisé la gestion des sessions injectées dans les controllers et commandes CLI.
Ce que j’ai appris :
- mieux comprendre le cycle de vie des sessions SQLAlchemy ;
- éviter les effets de bord liés aux sessions multiples ;
- concevoir une architecture plus cohérente pour les tests.
3. Problèmes d’imports circulaires et annotations de type
Problème : L’ajout du typage statique provoquait des imports circulaires entre les différents controllers.
Solution : J’ai utilisé des annotations différées (from __future__ import annotations) et des références typées sous forme de chaînes afin de supprimer les imports inutiles.
- gérer correctement les imports circulaires ;
- améliorer le découplage entre composants ;
- utiliser les bonnes pratiques modernes de typage Python.
4. Gestion des dépendances base de données entre MySQL et SQLite
Problème : Les tests automatisés utilisaient SQLite en mémoire, mais certains composants continuaient à tenter de se connecter à MySQL, provoquant des erreurs lorsque le serveur MySQL était arrêté.
Solution : J’ai analysé la chaîne d’imports et identifié des initialisations implicites du moteur MySQL dans certains modules. J’ai ensuite refactorisé l’initialisation de la base de données pour injecter explicitement le moteur et la session utilisés par les tests.
Ce que j’ai appris :
- éviter les dépendances globales implicites ;
- mieux contrôler l’injection des dépendances ;
- séparer proprement les environnements de développement, test et production.
5. Refactorisation de logique métier trop complexe avec des lambdas
Problème : Certaines parties du code utilisaient des dictionnaires de fonctions lambda longues et difficiles à maintenir.
Solution : J’ai simplifié la logique métier en uniformisant les signatures de méthodes et en remplaçant certaines lambdas par des structures plus explicites.
Ce que j’ai appris :
- privilégier la lisibilité plutôt que l’abstraction excessive ;
- reconnaître les limites des fonctions lambda ;
- améliorer la maintenabilité d’une architecture applicative.
6. Débogage d’erreurs silencieuses et de comportements incohérents
Problème : Plusieurs comportements incohérents apparaissaient dans les tests : données inattendues, sorties console vides ou exécutions partielles sans erreur explicite.
Solution : J’ai mis en place une stratégie de debugging approfondie avec :
- affichage des identifiants de sessions SQLAlchemy ;
- vérification des objets réellement patchés ;
- instrumentation temporaire du code avec des traces d’exécution ;
- analyse des flux d’appel dans les controllers et commandes CLI.
Ce que j’ai appris :
- adopter une démarche méthodique de debugging ;
- comprendre l’importance du contexte d’exécution ;
- diagnostiquer des erreurs complexes liées aux mocks, aux imports et aux sessions partagées.
En quelques mots-clés :
- Python
- SQLAlchemy
- Architecture MVC
- CLI
- Click
- Rich
- MySQL
- SQLite
- Tests unitaires
- Tests CLI
- Unittest
- Mocking
- Patching
- Typage Python
- Refactorisation
- Clean Code
- Flake8
- Isort
- Coverage
- Logging
- Sentry
- Gestion des permissions
- Authentification
- ORM
- Validation des données
- Gestion des erreurs
- Architecture logicielle
- Débogage
- Monitoring
- Qualité logicielle
V01
Le code source : repository GitHub (à venir).
Exemple d’exécution : (A venir).
A bientôt ! 😉