Fritly

1. Introduction

Pourquoi ce projet ?

Après plusieurs années à travailler dans une friterie, j’ai réalisé qu’une bonne partie du quotidien pouvait être simplifiée. Les plannings se faisaient souvent à la main, les procédures étaient éparpillées et il n’existait pas d’outil centralisé pour tout rassembler.

L’objectif

Créer une application pensée pour les employés :

gérer facilement les horaires, absences et remplacements,
centraliser toutes les informations utiles (procédures, fiches quotidiennes, etc.),
et poser les bases pour ajouter d’autres fonctionnalités au fur et à mesure des besoins.

Une collaboration

Je développe l’application, tandis qu’un ami graphiste/designer s’occupe de l’UX/UI. L’idée est d’allier fonctionnalité et ergonomie dès le départ.

2. Fonctionnalités principales

Fritly regroupe tout ce dont les employés ont besoin pour simplifier leur quotidien. L’idée est de commencer par les fonctionnalités essentielles et d’élargir progressivement en fonction des retours et des besoins réels sur le terrain.

Les fonctionnalités actuellement prévues incluent :

Gestion des plannings (horaires, absences et remplacements)
Centralisation des procédures (recettes, nettoyage, organisation des postes)
Fiches quotidiennes pour le suivi des tâches
Collecte des suggestions et idées (ex. “burger du mois”)

De nouvelles idées seront intégrées au fur et à mesure, en fonction des besoins exprimés par les utilisateurs.

3. Stack & Tools

Fritly repose sur une stack moderne, pensée pour offrir une application performante et facile à utiliser, tout en restant simple à déployer pour les employés.

Technologies principales

Angular : pour un frontend réactif et ergonomique.
Spring Boot : pour un backend robuste et sécurisé.
PostgreSQL : pour une base de données fiable et performante.

L’application est développée comme une PWA (Progressive Web App), ce qui permet :

Une installation directe depuis le navigateur (pas besoin d’app store).
Des mises à jour instantanées pour tous les utilisateurs.
Une expérience proche du natif tout en restant légère et simple à maintenir.

Outils de conception et de gestion

Plusieurs outils accompagnent le développement du projet :

Figma : pour la création des maquettes UX/UI en collaboration avec le designer.
Jira : pour organiser les tâches et suivre la méthode Agile (Scrum simplifié).
GitLab : pour la gestion du dépôt et du CI/CD.
IntelliJ IDEA : comme IDE principal pour le développement backend.

Suivi de projet et gestion des sprints avec Jira.

Prototypage et design des interfaces avec Figma.

Gestion du code, intégration continue et déploiement via GitLab.

4. Organisation & Méthodologie

Introduction à Agile et Scrum

Agile Scrum est une méthode de gestion de projet qui privilégie la flexibilité et l’adaptation.
Plutôt que de planifier un projet en entier dès le départ, Scrum découpe le travail en cycles courts, appelés sprints.
À la fin de chaque sprint, on obtient une version fonctionnelle du produit, permettant d’ajuster rapidement les priorités en fonction des retours.

Cycle de la méthode Scrum.

Notre adaptation de Scrum

Sur Fritly, nous appliquons Scrum de manière adaptée à notre contexte.
Nous ne réalisons pas de réunions quotidiennes (« daily scrums »), car nous travaillons à temps partiel sur le projet et chacun avance selon ses disponibilités.
À la place, nous faisons des points ponctuels pour faire le bilan, réaligner les objectifs et ajuster le backlog si nécessaire.

Gestion des versions : MVP et au-delà

Actuellement, nous sommes en phase de MVP (Minimum Viable Product).
Cela signifie que nous développons d’abord une base solide avec les fonctionnalités essentielles pour rapidement tester le produit.
Après cette étape, nous prévoyons un développement itératif, avec des ajouts, améliorations et corrections, toujours guidés par les retours utilisateurs.

Qui travaille sur Fritly ?

Le projet est porté par deux personnes :

je m’occupe du développement, du déploiement, de la gestion du CI/CD, de l’analyse et de la planification,
tandis qu’un ami graphiste est responsable du design UX/UI.

Cette organisation nous permet de couvrir l’ensemble des besoins du projet malgré notre petite équipe.

5. CI/CD & Environnements

Workflow GitLab basé sur GitFlow

Le projet utilise un workflow de branches inspiré de GitFlow :

une branche main dédiée à la production,
une branche develop pour le développement,
des branches feature-fritly-* pour les nouvelles fonctionnalités,
et des branches hotfix pour les corrections urgentes.

Pour chaque nouvelles fonctionnalités, je vais créer une branche de feature nommée par rapport au ticket Jira correspondant à partir de la branche develop.
Une fois le ticket Jira terminé, une Merge Request est ouverte pour fusionner le code dans la branche develop.

Lorsque la version de la branche develop est testé, elle est fusionné sur la branche main, la branche de production.

Si je remarque un bug dans la version en production, je vais créer une branche de hotfix pour faire une correction rapide.

Ce workflow structuré permet un développement organisé, facilitant l’intégration progressive des fonctionnalités et la gestion des corrections critiques.

Schéma du workflow de branches GitLab

Pipeline CI/CD

La pipeline CI/CD a été conçue pour coller parfaitement à ce workflow.
À chaque push ou merge request (MR) sur n'importe quelle branche, une pipeline se déclenchera.
Mais le nombre de job executé sera différent en fonction du type de branche.

une branche feature/hotfix: lint, test et build
la branche develop: lint, test, build, build/push image docker et deploiement sur l'environnement de developpement
la branche main: lint, test, build, build/push image docker, migration base de donnée et deploiement sur l'environnement de production

Exemple de pipeline CI/CD en production dans GitLab

Environnements de développement et production

Dans mon workflow, j'ai 2 environenement distincts : développement et production.

C'est à dire qu'en fonction de l'environnement, le déroulement de la pipeline en interne sera différente.
En developpement, le build de l'image docker et le deploiement se fera dans une configuration spécifique pour tester l'application.
En production, c'est la même chose mais spécialement pour que ce soit accessible au publique donc plus restreint.

Pour cela, j'ai mis en place 2 machines virtuelles, configurées pour avoir un environnement de test et un environnement de production.
Ce qui permet dans ces 2 VMs de déployer les applications, c'est un environnement Docker via des docker-compose (fichier de configuration permettant de lancer des conteneurs Docker).

Schéma des environnements de déploiement

Illustration des environnements de déploiement

6. Avancement du projet

Le projet Fritly est actuellement en phase de lancement. Les premières étapes ont été consacrées à préparer un socle technique solide et à poser les bases fonctionnelles.

Analyse initiale : définition des objectifs, identification des besoins et choix des technologies.
Mise en place du pipeline CI/CD : configuration du workflow GitLab, automatisation du build, push et déploiement via Docker.
Configuration des environnements : séparation claire entre l’environnement de développement (VM interne) et de production (VM accessible).
Première ébauche de maquette : conception sur Figma pour poser l’interface et l’expérience utilisateur.

Le projet est donc en phase préparatoire, avec un socle technique prêt à accueillir les premiers développements fonctionnels.