Détail du travail

Le problème

Les applications de gestion commerciale ont tendance à croître de manière désordonnée :

• logique métier dispersée,
• règles implicites non documentées,
• endpoints couplés directement aux modèles,
• difficulté à introduire des changements sans casser les flux existants.

De plus, des opérations comme :

• confirmation d'achats ou de ventes,
• mouvements de stock,
• mouvements de cash,
• backups et restaurations,

nécessitent contrôle, traçabilité et protection, pas de simples CRUDs.

La solution

J'ai conçu une API avec une architecture strictement gouvernée, où chaque responsabilité est clairement délimitée et documentée.

Architecture par couches

Séparation explicite et non négociable des responsabilités :

• Model Représente la structure de la base de données et la sérialisation (to_dict).
• Service Contient la logique métier et les règles opérationnelles.
• Controller Gère les données, les validations et l'orchestration des appels.
• API / Router Définit les endpoints et le contrat de l'API.

Si quelque chose change, on touche une seule couche, pas tout le système.

Architecture Base + Extensions

L'un des apprentissages clés de ce projet est l'usage d'une architecture Base + spécialisation :

• BaseModel
  • id
  • audit (created_at, updated_at)
  • soft delete (is_active, deleted_at)
  • to_dict()
• Les modèles réels héritent, étendent ou remplacent uniquement ce qui est nécessaire.

Il en va de même pour :

• BaseService
• BaseController
• BaseRouter

Qui implémentent le CRUD standard :

• create
• get_all
• get_by_id
• update
• delete (soft delete)
• restore

Et qui se spécialisent ensuite selon les règles métier documentées.

• cohérence sur tout le projet,
• moins de duplication,
• évolution contrôlée.

Domaine et modèle conceptuel (DDD informel)

Pendant le développement, j'ai découvert que j'appliquais, de façon naturelle, une architecture DDD informelle :

• Entities
  • users
  • products
  • customers
  • suppliers
• Aggregates
  • stock locations
  • stock par produit
  • cash accounts
• Documents
  • bons de livraison d'achat
  • bons de livraison de vente
  • dépôts de stock
  • transferts de cash
• Events
  • mouvements de stock
  • mouvements de caisse

Les documents ne sont pas que des données : ils représentent des actions qui impactent les aggregates via des events.

Fonctionnalité principale

Gestion commerciale

• Utilisateurs et rôles (ADMIN / USER)
• Produits, clients et fournisseurs

Stock

• Emplacements
• Stock par emplacement
• Dépôts entre emplacements

Cash

• Comptes de caisse
• Transferts et mouvements

Documents métier

• Bons de livraison d'achat
• Bons de livraison de vente
• Confirmation de documents
• Règles explicites par statut (DRAFT / CONFIRMED)

Sécurité, rôles et contrôle d'accès

• Authentification via JWT (access + refresh)
• Tokens incluent password_changed_at
• Invalidation automatique des tokens après changement de mot de passe

Rôles :

• ADMIN
  • gestion des utilisateurs
  • backups et restores
  • opérations critiques
• USER
  • opérations métier standard

Règles de sécurité explicites :

un utilisateur ne peut pas se supprimer lui-même ni supprimer le dernier admin.

Sauvegardes et protection des données

Le système inclut un support explicite des backups :

• Export complet de la base de données via endpoint
• Restauration depuis backup
• Service dédié pour ces opérations

La protection des données fait partie du design, pas un ajout ultérieur.

Stack technique

• Langage : Python
• Framework : Flask (WSGI)
• Base de données : SQLite
• ORM : SQLAlchemy
• Authentification : JWT
• Testing : pytest, pytest-cov
• CORS : Flask-Cors
• Configuration : python-dotenv

Opérations et déploiement

• Backend déployé sur PythonAnywhere
• Mise à jour opérationnelle documentée dans le repo
• Base de données SQLite en production
• Système fonctionnel et accessible publiquement

🔗 API en production

🔗 Dépôt GitHub

Origine du système de travail

Ce projet est l'un des premiers où j'ai commencé à formaliser l'usage de l'IA dans le développement.

Le dossier docs/ contient :

• contrats d'architecture,
• règles explicites pour l'usage de l'IA,
• modèles de base,
• catalogues d'erreurs,
• documentation comme source de vérité.

On y voit déjà des concepts qui ont ensuite évolué vers :

• travail gouverné,
• clôture formelle des décisions,
• séparation des rôles,
• et enfin l'approche PDCA + orchestrator / executor que j'utilise aujourd'hui.

Ce que démontre ce projet

Ce projet démontre ma capacité à :

• Concevoir des backends complexes avec règles métier réelles
• Construire des architectures gouvernées et extensibles
• Appliquer des principes proches du DDD
• Intégrer sécurité, contrôle et traçabilité
• Exploiter un logiciel en production
• Évoluer vers un système de travail reproductible et contrôlé

Images du projet