Tous les projets

Mobile, desktop & console

Stock Management · app mobile Flutter

Une application mobile qui fonctionne d’abord hors ligne, pour que les petits commerces sachent à tout moment ce qu’ils ont en stock, ce qui va manquer et ce qui s’est passé.

  • Projet individuel
questions auxquelles l’app répond
3
modules métier
5
couches par module
3
connexion nécessaire pour l’utiliser
0

01Le point de départ

Contexte & mission

Le problème

Un client demande un article, le gérant se tourne vers l’étagère : il n’en reste plus. Le problème n’est pas technique, c’est un problème d’information : le stock existe, mais personne ne sait exactement ce qu’il contient ni quand réapprovisionner.

La mission

Construire un outil qui tienne dans la poche du gérant, fonctionne sans connexion et réponde à trois questions : qu’ai-je en stock et combien cela vaut-il ? qu’est-ce qui va manquer ? que s’est-il passé, quand et pourquoi ?

Mon rôle

Projet conçu et développé seul.

02Réalisation

Ce que j’ai fait

  1. Catalogue avec seuils d’alerte

    Chaque produit a un nom, une description, un prix, une quantité et son propre seuil d’alerte, et peut être rattaché à un fournisseur.

  2. Mouvements traçables

    Chaque entrée (réception, réapprovisionnement) et chaque sortie (vente, perte, casse) est enregistrée avec sa quantité, sa date et son motif ; la quantité du produit se met à jour automatiquement.

  3. Tableau de bord

    Nombre de produits, produits disponibles et en rupture, valeur totale du stock, graphique circulaire et liste des produits à réapprovisionner en priorité.

  4. Hors ligne d’abord

    Données locales avec Hive : l’application reste utilisable sans réseau. Le repository tente la source distante (Dio) puis bascule sur les données locales.

  5. Clean Architecture

    Cinq modules (auth, produits, fournisseurs, stock, tableau de bord), chacun en trois couches : data, domain, presentation. État géré avec BLoC, dépendances injectées avec get_it.

03Conception

Architecture

Clean Architecture organisée par fonctionnalité. La logique métier reste indépendante du framework, de l’API et de la base : chaque action suit le même chemin, de l’écran au repository, qui choisit entre source distante et source locale.

Le trajet d’une action
  1. ÉcranMaterial Design 3
  2. BLoCÉvénements · états
  3. Cas d’usageDomaine
  4. RepositoryDistant puis local
  5. HiveHors ligne
En appui
  • DioAPI REST à venir
  • get_itInjection de dépendances

04Impact

Résultats

  • Le gérant sait à tout moment ce qu’il a, ce que cela vaut et ce qui va manquer.
  • Chaque mouvement de stock est traçable : quantité, date et motif.
  • Une couche réseau déjà prête pour une future synchronisation avec une API.

05Bilan

Ce que j’en retiens

Ce que ce projet démontre

Que je structure une application mobile avec la même rigueur qu’un backend : couches nettes, état prévisible, données disponibles sans réseau.

06Technologies

Stack complète

  • Flutter
  • Dart
  • flutter_bloc
  • get_it
  • Dio
  • Hive
  • fl_chart
  • Material Design 3
  • Clean Architecture