Projet produit et architecture
Isiforecast
Une plateforme de prévision et de pilotage supply conçue pour transformer l'historique de ventes en décisions concrètes sur le stock, les promotions et l'approvisionnement.
Le produit relie la prévision à de vrais workflows supply: promotions, cycle de vie, ruptures, commandes et planification, avec une architecture pensée pour rester exploitable à mesure que le périmètre métier s'affine.
Vue d’ensemble
Contexte
Projet client B2B pour un cabinet de conseil en logistique au service d'entreprises avec des enjeux retail.
Période
Mars 2025 - aujourd'hui
Stack
Docker · Python · PyTorch · SQL
Publication
septembre 2024
Mon rôle
Lead Full-Stack & ML Engineer
J'ai piloté le projet de bout en bout, de l'architecture aux workflows métier. Quand l'approche initiale sur la partie calcul n'a pas pu être menée jusqu'à un niveau exploitable dans le cadre du partenariat académique, j'ai repris la conception du moteur de prévision et structuré l'ensemble du produit autour d'une architecture plus robuste.
Responsabilités principales
- Conception de l'architecture et des choix techniques structurants
- Développement backend, API et règles métier
- Intégration des briques de prévision et refonte du serveur de calcul
- Développement frontend orienté usages métier supply
- Mise en place de l'infrastructure, du déploiement et des bases de fiabilité
- Clarification des besoins client et cadrage produit
Points de preuve
Architecture
Frontend React, backend Django et microservice forecasting dédié
Périmètre métier
Prévision, promotions, cycle de vie, ruptures et approvisionnement
Maturité
Préproduction privée avec tests, workflows asynchrones et environnements dédiés
Configuration d'équipe
- Développement majoritairement en solo
- Partenariat académique initial avec contribution partielle sur la couche calcul
- Collaboration directe avec le client pour préciser les priorités métier
Le problème à résoudre
Dans beaucoup d'environnements retail, la prévision et le pilotage stock restent dispersés entre fichiers Excel, exports manuels et outils peu intégrés. Même lorsqu'une prévision existe, les équipes doivent encore tenir compte des promotions, des cycles de vie, des ruptures, des produits de substitution, des contraintes fournisseurs et des logiques de réapprovisionnement.
Le besoin n'était donc pas de produire une simple courbe de forecast, mais de centraliser ces workflows dans une plateforme réellement exploitable par des équipes métier et reliée à leurs décisions opérationnelles.
Comment j'ai structuré la solution
J'ai conçu ISIFORECAST comme une plateforme full-stack articulée autour de trois couches : un frontend React pour les usages métier, un backend Django pour l'orchestration et la logique applicative, et un microservice de calcul dédié aux entraînements et prédictions de séries temporelles.
Cette séparation permet de faire évoluer le moteur de prévision sans rigidifier le produit, tout en gardant le backend responsable des workflows, des données et des règles métier.
Le périmètre va au-delà de la prévision pure : import de données, consultation des forecasts, gestion des promotions, cycles de vie, ruptures et aide à la décision sur les stocks et commandes.
Captures
Défis qui ont structuré le projet
Reprendre la couche de calcul sur des bases plus solides
Problème
Le travail initial sur la partie calcul n'a pas eu le temps d'aboutir à un niveau exploitable pour un produit de préproduction.
Solution
J'ai repensé le serveur de calcul, clarifié la séparation entre moteur de prévision et logique applicative, puis reconstruit une architecture plus propre et plus évolutive.
Ne pas limiter le produit à une démo de forecasting
Problème
Le client n'avait pas besoin d'un modèle isolé, mais d'un outil utilisable dans de vrais workflows retail et supply.
Solution
J'ai élargi la plateforme pour intégrer promotions, cycles de vie, ruptures, données fournisseurs et logique d'approvisionnement afin de relier la prévision aux décisions métier.
Construire de la crédibilité avant les KPI de production
Problème
Le projet est encore en préproduction, donc les métriques d'usage ou d'impact final ne sont pas encore stabilisées.
Solution
J'ai choisi de mettre en avant des preuves de maturité concrètes : architecture multi-service, couverture de tests, gestion de traitements asynchrones, support de volumes réalistes et environnements dédiés.
Résultats et impact
- Centralisation des workflows de prévision et de planification dans un seul produit
- Réduction de la dépendance aux fichiers Excel et aux exports manuels
- Une plateforme pensée pour la décision opérationnelle, pas pour une simple démonstration de modèle
- Une architecture plus claire et plus robuste après la reprise du moteur de calcul
- Des fondations crédibles pour un passage en production futur
Preuves visibles
L'environnement reste privé, mais la crédibilité du projet repose déjà sur des captures réelles de l'interface et sur des signaux tangibles de maturité technique.
- Captures de modules réels : données, prévision, commandes et planification
- Architecture multi-service avec couche de calcul dédiée
- Support de bases contenant quelques milliers de SKU
- Tests frontend/backend et gestion des traitements asynchrones