République Tunisienne Licence en :

Ministère de l’Enseignement Supérieur informatique

et de la Recherche Scientifique
Option :
Université de Monastir génie logiciel
et systèmes d’information
Faculté des Sciences de Monastir
Ordre N°: 22SI1077

Mémoire
Présenté à

la Faculté des Sciences de Monastir

pour l’obtention du

Diplôme de Licence en :
informatique

Option :
génie logiciel
et systèmes d’information

par

Mehdi Zrafi

Système d’Abonnement STS

Présenté le : 10/06/2025, devant le jury composé de :

M. Souheyl Mallat Président

M. Nizar Kerkeni Rapporteur
M. Tayeb Jebeniani Encadrant
Mme. Ichraf Chatti Encadrante
 DÉDICACE

À mes chers parents

Pour tous vos sacrifices, votre amour inconditionnel, votre soutien sans faille et vos prières qui
m’ont accompagné tout au long de mes études.
À ma chère famille
Merci pour votre encouragement constant et votre soutien moral précieux.
À mes frères et mes amis les plus proches
Merci d’avoir toujours été là pour moi et de m’avoir soutenu dans les moments difficiles.
J’espère que ce travail sera à la hauteur de vos attentes et reflètera votre soutien indéfectible. Je
vous suis infiniment reconnaissant de faire partie de ma vie.

À vous tous,
je dédie ce modeste travail.

FSM Page i
 Remerciements

Avant d’aborder le contenu de ce travail, je tiens à exprimer ma profonde gratitude à toutes les
personnes qui ont contribué de près ou de loin à la réalisation de ce projet de fin d’études.

Je souhaite tout particulièrement remercier :

• M. Souheyl Mallat

• M. Nizar Kerkeni

• M. Tayeb Jebeniani

• Mme. Ichraf Chatti

• Le Département d’Informatique

Je n’oublie pas non plus tous ceux qui, par leurs encouragements discrets mais constants,
m’ont permis de mener à bien ce travail. Qu’ils trouvent ici l’expression de ma reconnaissance.

Enfin, je dédie ces remerciements à tous les enseignants qui m’ont formé tout au long de
mon parcours universitaire.

FSM Page ii
TABLE DES MATIÈRES

Table des matières

Liste des figures vii

Liste des tableaux viii

LISTE DES ABRÉVIATIONS ix

Liste des abréviations x

Introduction Générale 1

1 Contexte et Objectifs du Projet 2

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Contexte Général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Problématique du Transport au Sahel . . . . . . . . . . . . . . . . . . 3
1.2.2 Transformation Digitale dans le secteur public . . . . . . . . . . . . . 3
1.3 Présentation de la STS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.2 Organisation et Services . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 Défis et Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.4 Problèmes dans l’ancien système . . . . . . . . . . . . . . . . . . . . . 4
1.3.5 Rôle de la digitalisation . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Objectifs du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Cadre du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.2 Objectifs fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.3 Objectifs non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.4 Avantages attendus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

FSM Page iii

TABLE DES MATIÈRES

1.5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.1 Méthode Agile Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5.2 Encadrement et planification du projet . . . . . . . . . . . . . . . . . . 7
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Analyse et Spécifications Techniques 9

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Présentation de la norme GTFS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Structure de fichiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3 Utilité pour la STS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Solutions existantes (SRT Gafsa, SORETRAK) . . . . . . . . . . . . . 11
2.3.2 Limites observées (absence d’authentification, manque de sécurité) . . 11
2.3.3 Comparatif : notre solution vs concurrents . . . . . . . . . . . . . . . . 12
2.4 Spécifications Fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 12
2.4.2 Fonctionnalités clés (abonnement, authentification Email, etc.) . . . . . 13
2.5 Spécifications Non Fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Performance et sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.2 Interface utilisateur et accessibilité . . . . . . . . . . . . . . . . . . . . 14
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Conception du Système 15
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Choix de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.2 Dockerisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
[Link] Configuration des services . . . . . . . . . . . . . . . . . . . 17
[Link] Choix techniques remarquables . . . . . . . . . . . . . . . . 17
[Link] Avantages opérationnels . . . . . . . . . . . . . . . . . . . . 18

FSM Page iv
TABLE DES MATIÈRES

3.3 Modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1 Utilisation de [Link] pour la modélisation . . . . . . . . . . . . . . . 18
3.3.2 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Conception de la base de données . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.1 Choix de PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.2 Gestion des abonnements et trajets (GTFS) . . . . . . . . . . . . . . . 22
3.5 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.1 Authentification par Email . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6 Gestion de projet avec Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Implémentation 25
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Matériel utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.3 Présentation Technique d’Odoo . . . . . . . . . . . . . . . . . . . . . 26
[Link] Définition Générale . . . . . . . . . . . . . . . . . . . . . . 26
[Link] Caractéristiques Techniques . . . . . . . . . . . . . . . . . . 26
[Link] Pertinence pour le Projet STS . . . . . . . . . . . . . . . . . 27
4.2.4 Infrastructure Dockerisée . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.5 Outils de développement . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Modules clés implémentés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1 Module resroutier (Gestion des trajets) . . . . . . . . . . . . . . . . . . 28
4.3.2 Module STS Abonnement . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Interfaces utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.1 Workflow utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.2 Adaptation RTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Intégration et API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.1 Endpoints REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

FSM Page v
TABLE DES MATIÈRES

4.5.2 Sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6 Tests et validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6.1 Stratégie de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.6.2 Résultats clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
[Link] Fonctionnalités avancées utilisées . . . . . . . . . . . . . . . 31
[Link] Avantages constatés . . . . . . . . . . . . . . . . . . . . . . 32
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Analyse et Évaluation 33
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Comparaison avec les solutions existantes . . . . . . . . . . . . . . . . . . . . 33
5.2.1 Avantages techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.2 Avantages pour l’utilisateur . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Limites du système actuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3.1 Points à améliorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.1 Améliorations futures . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.2 Extension vers d’autres régions . . . . . . . . . . . . . . . . . . . . . 34
5.4.3 Intégration d’IA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Conclusion Générale 36

BIBLIOGRAPHY 37

FSM Page vi
LISTE DES FIGURES

Liste des figures

1.1 logo de la Société de transport du Sahel . . . . . . . . . . . . . . . . . . . . . 3

1.2 Méthode SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Qu’est-ce que GTFS ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Créer - General Transit Feed Specification . . . . . . . . . . . . . . . . . . . . 10
2.3 Diagramme de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Architecture MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Architecture Docker de la solution STS avec Odoo 17 . . . . . . . . . . . . . . 16
3.3 Interface de [Link] utilisée pour la modélisation . . . . . . . . . . . . . . . . 19
3.4 Diagramme de classes : utilisateurs, abonnements, trajets, etc. . . . . . . . . . 20
3.5 Diagramme de séquence : processus d’abonnement . . . . . . . . . . . . . . . 21
3.6 Diagramme de séquence : Processus sécurisé d’authentification et création de
compte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Tableau Trello pour le suivi des sprints . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Architecture logicielle de l’environnement de développement . . . . . . . . . . 26

4.2 Architecture du projet STS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Formulaire de profil avec validation en temps réel . . . . . . . . . . . . . . . . 30

5.1 Vision de l’intégration d’IA dans le système . . . . . . . . . . . . . . . . . . . 35

FSM Page vii

LISTE DES TABLEAUX

Liste des tableaux

1.1 Découpage des tâches par sprint . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 Comparaison des fonctionnalités des solutions d’abonnement en ligne . . . . . 12

3.1 Avantages de l’architecture MVC pour notre projet . . . . . . . . . . . . . . . 16

3.2 Analyse des décisions d’architecture Docker . . . . . . . . . . . . . . . . . . . 17
3.3 Comparaison des systèmes SGBD . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Correspondance entre fichiers GTFS et tables PostgreSQL . . . . . . . . . . . 22

4.1 Configuration matérielle de développement . . . . . . . . . . . . . . . . . . . 25

4.2 Modèles principaux du module resroutier . . . . . . . . . . . . . . . . . . . . 28
4.3 API disponible dans resroutier . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Exemples de cas de test validés . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1 Comparatif technique avec les concurrents . . . . . . . . . . . . . . . . . . . . 33

5.2 Feuille de route des évolutions . . . . . . . . . . . . . . . . . . . . . . . . . . 34

FSM Page viii

 LISTE DES ABRÉVIATIONS

ACID Atomicité, Cohérence, Isolation, Durabilité (Properties of database transactions)

API Application Programming Interface (Interface de Programmation d’Applications)

AI Intelligence Artificielle

BD Base de Données

BDD Base de Données

CRM Customer Relationship Management (Gestion de la Relation Client)

CRUD Create, Read, Update, Delete (Créer, Lire, Mettre à jour, Supprimer)

CSRF Cross-Site Request Forgery (Falsification de Requête Inter-Sites)

CSS Cascading Style Sheets (Feuilles de Style en Cascade)

CSV Comma-Separated Values (Valeurs Séparées par des Virgules)

Docker Outil de conteneurisation pour le déploiement logiciel

ERP Enterprise Resource Planning (Planification des Ressources de l’Entreprise)

FSM Faculté des Sciences de Monastir

GTFS General Transit Feed Specification (Spécification Générale des Données de Transport)

Git Système de contrôle de version décentralisé

HTTP HyperText Transfer Protocol (Protocole de Transfert HyperTexte)

FSM Page ix
LISTE DES ABRÉVIATIONS

IDE Integrated Development Environment (Environnement de Développement Intégré)

JS JavaScript

MVC Model-View-Controller (Modèle-Vue-Contrôleur)

Odoo Suite d’applications open source de gestion d’entreprise

ORM Object-Relational Mapping (Mapping Objet-Relationnel)

PFE Projet de Fin d’Études

PostgreSQL Système de Gestion de Base de Données Relationnelle

QWeb Moteur de templates XML d’Odoo (XML Template Engine)

RTL Right-To-Left (De droite à gauche)

REST Representational State Transfer (Transfert d’État Représentationnel)

SCRUM Méthodologie agile de gestion de projet

STS Société de Transport du Sahel

SQL Structured Query Language (Langage de Requête Structuré)

UML Unified Modeling Language (Langage de Modélisation Unifié)

VS Code Visual Studio Code

XML eXtensible Markup Language (Langage de Balisage Extensible)

YML YAML Ain’t Markup Language (Format de Sérialisation de Données)

FSM Page x
INTRODUCTION GÉNÉRALE

Introduction Générale

Dans un contexte où la digitalisation des services publics devient incontournable, la modernisation

du secteur du transport constitue une priorité stratégique. La Société de Transport du Sahel
(STS), en tant qu’acteur régional majeur, souhaite mettre à jour son système d’abonnement, en
remplaçant les procédures manuelles par une solution numérique centralisée et intuitive.

Ce projet de fin d’études s’inscrit dans cette dynamique. Il a pour objectif de concevoir
et développer une plateforme web facilitant la gestion des abonnements des usagers : élèves,
étudiants et stagiaires. Grâce à un parcours simplifié, ces derniers peuvent créer un profil, saisir
leurs informations, sélectionner leur établissement ou région, et s’abonner aux services STS.

Techniquement, la solution repose sur le framework Odoo, avec une interface utilisateur
développée en XML, CSS et JavaScript, adaptée en langue arabe. Le système intègre le
modèle MVC pour une séparation claire des responsabilités. L’authentification repose sur le
mécanisme natif d’Odoo via adresse email, garantissant une sécurité de base et une compatibilité
avec les futures évolutions.

Concernant le paiement, l’architecture rest ouverte à une future intégration d’API tierces
comme Click to Pay ou Paymee. Le module de transport repose partiellement sur la norme
ouverte GTFS (General Transit Feed Specification), utilisée dans la conception des arrêts,
lignes et trajets.

Comparée à des services concurrents comme [Link] ou [Link], cette

solution offre plus de flexibilité, de sécurité et de fluidité pour l’utilisateur final.

Ce rapport retrace les étapes de réalisation du projet, depuis l’analyse des besoins jusqu’au
déploiement technique.

FSM Page 1
Chapter

1
Contexte et Objectifs du Projet

1.1 Introduction

Le transport public joue un rôle fondamental dans le quotidien des citoyens, notamment dans les
régions à forte densité étudiante comme le Sahel tunisien. Pour répondre aux nouveaux besoins
des usagers et aux exigences de la digitalisation des services publics, la Société de Transport du
Sahel (STS) a exprimé le besoin de moderniser son processus de gestion des abonnements.

Ce projet de fin d’études vise à analyser le fonctionnement actuel, identifier ses limites, et
spécifier les besoins fonctionnels et techniques d’un nouveau système numérique. L’objectif est
de permettre aux usagers (élèves, étudiants, stagiaires) de créer un profil en ligne, de s’abonner
de manière intuitive et sécurisée, et de retrouver l’ensemble des trajets disponibles selon leur
localisation.

Le présent chapitre décrit dans un premier temps l’organisme d’accueil et le cadre du

projet. Ensuite, il introduit la documentation GTFS comme base de structuration des données
de transport, compare notre solution aux plateformes concurrentes, puis détaille les besoins
fonctionnels et non fonctionnels à respecter pour une implémentation réussie.

FSM Page 2
CONTEXTE ET OBJECTIFS DU PROJET

1.2 Contexte Général

1.2.1 Problématique du Transport au Sahel

Dans la région du Sahel, les élèves et étudiants dépendent fortement des transports publics pour
se rendre dans leurs établissements. Toutefois, le système d’abonnement actuel est encore basé
sur une gestion manuelle lente, et peu pratique pour les usagers comme pour les agents STS.

1.2.2 Transformation Digitale dans le secteur public

L’État tunisien encourage la modernisation de ses services à travers le numérique. Le développement

d’une plateforme de gestion des abonnements STS s’inscrit dans cette démarche, en offrant une
solution moderne, sécurisée et centrée sur l’utilisateur.

1.3 Présentation de la STS

1.3.1 Historique

La Société de Transport du Sahel (STS) est une entreprise publique tunisienne fondée le 5
janvier 1963. Elle assure le transport de voyageurs dans le Sahel tunisien (Sousse, Monastir,
Mahdia) [1].

Initialement connue sous le nom de « Transport municipal du Sahel à Sousse » en 1958, elle
a été renommée plusieurs fois avant d’adopter son nom actuel en 1970 [1].

Figure 1.1: logo de la Société de transport du Sahel

FSM Page 3
CONTEXTE ET OBJECTIFS DU PROJET

1.3.2 Organisation et Services

Le siège social est situé à Sousse, et la société gère des lignes urbaines, interurbaines et scolaires.
Elle exploite également le métro du Sahel reliant Mahdia à Sousse [1].

1.3.3 Défis et Perspectives

La STS fait face à des difficultés de flotte et de maintenance. En novembre 2024, le ministère du
Transport a annoncé l’acquisition de 50 nouveaux bus et la priorisation du transport scolaire [2].
De plus, un appel d’offres a été lancé pour 59 bus supplémentaires afin d’améliorer la qualité
de service [3].

Ces efforts s’inscrivent dans une volonté de moderniser et digitaliser l’expérience des usagers.

1.3.4 Problèmes dans l’ancien système

Le système actuel repose sur un traitement papier ou semi-numérisé. Il ne permet ni suivi

personnalisé, ni automatisation des trajets, ni paiement en ligne. De plus, les usagers doivent
souvent se déplacer pour s’abonner, ce qui engendre des files d’attente et une perte de temps.

1.3.5 Rôle de la digitalisation

La digitalisation permettra à la STS d’améliorer son efficacité interne, pour simplifier les procédures
pour l’utilisateur, et de se conformer aux exigences modernes de transparence, traçabilité et
accessibilité.

FSM Page 4
CONTEXTE ET OBJECTIFS DU PROJET

1.4 Objectifs du Projet

1.4.1 Cadre du sujet

Ce travail s’inscrit dans le cadre d’un sujet de fin d’études en vue de l’obtention d’un diplôme
de Licence en Génie Logiciel et Système d’Information au sein de la Faculté des Sciences de
Monastir (FSM) [4].

Il a été réalisé en collaboration avec la Société de Transport du Sahel (STS) [5], et encadré
académiquement par un enseignant de la FSM, et professionnellement par un référent technique
au sein de l’organisme d’accueil.

Ce travail met en application les connaissances acquises en développement web, modélisation,

conception de bases de données, et déploiement logiciel, dans le but de répondre à un besoin
réel de digitalisation au sein d’un établissement public tunisien.

1.4.2 Objectifs fonctionnels

• Permettre aux usagers de créer un compte avec authentification par email.

• Afficher les établissements, régions et trajets de manière dynamique selon le type d’abonné.

• Offrir la possibilité de générer une demande d’abonnement via un formulaire intuitif.

• Prévoir une interface en langue arabe adaptée à l’utilisateur tunisien.

1.4.3 Objectifs non fonctionnels

• Assurer une interface rapide, responsive et simple à utiliser.

• Garantir la sécurité des données utilisateurs.

• Faciliter l’intégration d’une API de paiement ultérieurement (ex. Click to Pay).

FSM Page 5
CONTEXTE ET OBJECTIFS DU PROJET

1.4.4 Avantages attendus

• Gain de temps pour les usagers et les agents STS.

• Moins de congestion dans les agences physiques.

• Réduction des erreurs humaines dans la gestion des abonnements.

• Meilleure image de la STS auprès des jeunes usagers.

1.5 Méthodologie de travail

1.5.1 Méthode Agile Scrum

Dans le cadre de notre projet et afin d’assurer le bon déroulement des différentes phases de
ce dernier, nous avons opté pour la méthode agile Scrum. Le mot SCRUM (« mêlée ») fait
référence à la mêlée du rugby. En effet, cette méthode met en exergue l’esprit d’équipe et la
volonté d’avancer ensemble vers un même but.
S’il fallait résumer la méthode SCRUM en une phrase?
SCRUM est une méthode itérative incrémentale centrée sur la réalisation d’un produit fonctionnel
(plutôt des produits non directement utiles comme par exemple certaines documentation). Cette
méthode est articulée autour de trois acteurs clés :

• le Product Owner : il a une vision complète du produit,

• le Scrum master : il assure le bon déroulement du projet et rappelle la méthode,

• l’équipe Scrum : elle développe le produit.

Le Product Owner définit le backlog du produit, c’est-à-dire la liste valorisée des fonctionnalités
cibles du produit. Cette liste a pour vocation d’évoluer, au fur et à mesure que la définition du
produit se construit.
Le premier sprint peut alors commencer; Mais avant de débuter, l’équipe Scrum doit définir et

FSM Page 6
CONTEXTE ET OBJECTIFS DU PROJET

prioriser les fonctionnalités auxquelles elle s’attaquera durant cette itération. L’ensemble de ces
tâches est appelé « backlog du sprint ».
Lors du sprint, l’équipe, accompagnée d’un Scrum master, itère sur les développements et
débute chaque journée par une « mêlée » durant laquelle elle rappelle les objectifs du jour.

Figure 1.2: Méthode SCRUM

A la fin de chaque sprint, le client ainsi que le Product Owner évaluent le produit partiellement
livrable afin de le valider ou d’indiquer les modifications à réaliser (elles seront alors ajoutées
au backlog du produit).
La méthode SCRUM est plus adaptée aux projets complexes sur lesquels on n’a pas de visibilité:
elle apporte davantage de flexibilité et d’adaptabilité aux évolutions demandées ainsi qu’une
meilleure gestion des risques [6].

1.5.2 Encadrement et planification du projet

Le projet a été encadré académiquement par un enseignant à la Faculté des Sciences de Monastir
et techniquement par un ingénieur au sein de la Société de Transport du Sahel. Des échanges
réguliers ont permis de valider chaque étape de développement, selon une planification agile.

FSM Page 7
CONTEXTE ET OBJECTIFS DU PROJET

Découpage en sprints Scrum

Le travail a été découpé en cinq sprints hebdomadaires, chacun visant un livrable fonctionnel :

• Sprint 1 : Initialisation du projet, mise en place de Docker, Odoo, dépôt Git.

• Sprint 2 : Création du modèle Abonné, formulaire d’inscription, logique de sélection.

• Sprint 3 : Mise en place du modèle Abonnement, calcul automatique des dates.

• Sprint 4 : Intégration des interfaces utilisateur en arabe, ajustement CSS/JS.

• Sprint 5 : Tests, corrections, débogage et finalisation pour déploiement.

Un tableau récapitulatif est présenté ci-dessous :

Table 1.1: Découpage des tâches par sprint

Sprint Objectif Tâches principales

1 Initialisation technique Docker, Git, environnement Odoo

2 Création de profil Modèle Abonné, formulaire XML, logique de
sélection
3 Module abonnement Modèle Abonnement, dates automatiques
4 Interface utilisateur Templates arabes, responsive CSS, liaison
Website
5 Tests et finalisation Débogage, scénarios de test, corrections

1.6 Conclusion

Ce chapitre a présenté le cadre général du projet, depuis la problématique du transport dans

la région du Sahel jusqu’aux objectifs spécifiques de notre solution. L’analyse du contexte a
révélé l’urgence d’une digitalisation des processus, confirmée par les défis actuels de la STS. La
méthodologie Scrum adoptée permettra une réalisation itérative et adaptative, comme détaillé
dans le chapitre suivant consacré à l’analyse technique approfondie.

FSM Page 8
Chapter

2
Analyse et Spécifications Techniques

2.1 Introduction

Ce chapitre présente les fondements techniques du projet, en détaillant la norme GTFS utilisée
pour structurer les données de transport, l’analyse des solutions existantes, ainsi que les spécifications
fonctionnelles et non fonctionnelles du système proposé.

2.2 Présentation de la norme GTFS

2.2.1 Définition

La General Transit Feed Specification (GTFS) est une norme ouverte utilisée pour diffuser des
informations pertinentes sur les systèmes de transport en commun aux cavaliers. Il permet aux
agences de transport en commun de publier leurs données de transport en commun dans un
format pouvant être utilisé par une grande variété d’applications logicielles [7].

Figure 2.1: Qu’est-ce que GTFS ?

FSM Page 9
ANALYSE ET SPÉCIFICATIONS TECHNIQUES

2.2.2 Structure de fichiers

Un ensemble de données GTFS est généralement composé de plusieurs fichiers texte au format
CSV, regroupés dans une archive ZIP. Les principaux fichiers incluent :

• [Link] : informations sur l’agence de transport.

• [Link] : description des lignes de transport.

• [Link] : détails des trajets individuels.

• [Link] : liste des arrêts avec leurs coordonnées géographiques.

• stop_times.txt : horaires de passage aux arrêts.

• [Link] : calendrier de fonctionnement des services.

• calendar_dates.txt : exceptions au calendrier régulier.

Ces fichiers permettent de modéliser l’ensemble de l’offre de transport d’une agence, facilitant
ainsi la diffusion et l’utilisation des données par des applications tierces.

Figure 2.2: Créer - General Transit Feed Specification

FSM Page 10
ANALYSE ET SPÉCIFICATIONS TECHNIQUES

2.2.3 Utilité pour la STS

Pour la Société de Transport du Sahel (STS),

l’adoption du format GTFS offre plusieurs avantages :

• Interopérabilité : facilite l’intégration des données de la STS dans des applications de

planification de trajets, telles que Google Maps.

• Transparence : permet une meilleure communication des horaires et des itinéraires aux
usagers.

• Maintenance simplifiée : la structure standardisée des données facilite leur mise à jour
et leur gestion.

2.3 Étude de l’existant

2.3.1 Solutions existantes (SRT Gafsa, SORETRAK)

Actuellement, plusieurs sociétés de transport en Tunisie proposent des services d’abonnement

en ligne. Par exemple, la Société Régionale de Transport de Gafsa (SRT Gafsa) [8] et la Société
Régionale de Transport de Kairouan (SORETRAK) [9] offrent des plateformes permettant aux
étudiants de s’inscrire et de renouveler leurs abonnements via Internet. Cependant, ces solutions
présentent certaines limitations en termes de fonctionnalités et d’expérience utilisateur.

2.3.2 Limites observées (absence d’authentification, manque de sécurité)

Les principales limitations observées dans les solutions existantes incluent :

• Absence d’authentification sécurisée : les plateformes ne proposent pas de mécanismes

robustes pour vérifier l’identité des utilisateurs, ce qui peut entraîner des risques de fraude.

• Manque de sécurité des données : les informations personnelles des usagers ne sont pas
toujours protégées de manière adéquate.

FSM Page 11
ANALYSE ET SPÉCIFICATIONS TECHNIQUES

• Interface utilisateur peu intuitive : la navigation sur les sites existants peut être compliquée,
notamment pour les utilisateurs moins expérimentés.

2.3.3 Comparatif : notre solution vs concurrents

Le tableau suivant présente une comparaison entre les fonctionnalités offertes par les solutions
existantes et celles proposées dans notre projet :

Table 2.1: Comparaison des fonctionnalités des solutions d’abonnement en ligne

Fonctionnalité SRT Gafsa SORETRAK Notre solution

Abonnement en ligne Oui Oui Oui

Authentification sécurisée (email) Non Oui Oui

Interface conviviale Oui Non Oui

Consultation des horaires Non Non Oui

2.4 Spécifications Fonctionnelles

2.4.1 Diagrammes de cas d’utilisation

Les principaux cas d’utilisation du système incluent :

• Inscription d’un nouvel utilisateur : un usager peut créer un compte en fournissant ses
informations personnelles.

• Souscription à un abonnement : l’utilisateur sélectionne le type d’abonnement souhaité

et créer.

• Consultation des horaires : accès aux horaires des lignes de transport via une interface
conviviale.

• Gestion du profil : possibilité de modifier les informations personnelles et de consulter

l’historique des abonnements.

FSM Page 12
ANALYSE ET SPÉCIFICATIONS TECHNIQUES

2.4.2 Fonctionnalités clés (abonnement, authentification Email, etc.)

Les fonctionnalités principales du système sont :

• Création de compte utilisateur : enregistrement des informations personnelles avec

vérification par Email.

• Gestion des abonnements : souscription, renouvellement et annulation des abonnements

en ligne.

• Consultation des horaires : accès aux horaires et itinéraires des lignes de transport.

Figure 2.3: Diagramme de cas d’utilisation

FSM Page 13
ANALYSE ET SPÉCIFICATIONS TECHNIQUES

2.5 Spécifications Non Fonctionnelles

2.5.1 Performance et sécurité

Le système doit répondre aux exigences suivantes :

• Haute disponibilité : assurer un temps de fonctionnement maximal pour garantir l’accès

au service à tout moment.

• Sécurité des données : mise en œuvre de mesures de sécurité pour protéger les informations
sensibles des utilisateurs.

• Scalabilité : capacité à gérer une augmentation du nombre d’utilisateurs sans dégradation

des performances.

2.5.2 Interface utilisateur et accessibilité

L’interface utilisateur doit être conçue de manière à :

• Être intuitive : faciliter la navigation et l’utilisation du service, même pour les utilisateurs
non technophiles.

• S’adapter aux différents appareils : assurer une compatibilité avec les ordinateurs,
tablettes et smartphones.

2.6 Conclusion

L’analyse technique réalisée dans ce chapitre a permis de valider les fondements de notre
solution. L’adoption du standard GTFS garantit l’interopérabilité avec les systèmes existants,
tandis que l’étude comparative a mis en évidence les lacunes à combler. Les spécifications
fonctionnelles et non-fonctionnelles définies guideront la conception détaillée présentée au
chapitre suivant, assurant cohérence et qualité dans la réalisation.

FSM Page 14
CONCEPTION DU SYSTÈME

Chapter

3
Conception du Système

3.1 Introduction

La conception de notre plateforme repose sur des choix technologiques et architecturaux précis
visant à garantir la modularité, la maintenabilité, la scalabilité et la sécurité. Cette phase précède
le développement et permet de structurer le système sous forme de composants interdépendants.

3.2 Choix de l’architecture

3.2.1 Architecture MVC

L’architecture Modèle-Vue-Contrôleur MVC permet de séparer clairement les responsabilités.

Le modèle gère les données, la vue gère l’interface utilisateur, et le contrôleur gère la logique
de l’application [10].

Figure 3.1: Architecture MVC

FSM Page 15
CONCEPTION DU SYSTÈME

L’architecture MVC (Model-View-Controller) sépare la logique métier, la gestion des

données, et l’interface utilisateur. Odoo repose naturellement sur ce modèle. Cela permet une
séparation claire des responsabilités.

Table 3.1: Avantages de l’architecture MVC pour notre projet

Composant Rôle dans notre système

Modèle (Odoo ORM) Gère les données des établissements, trajets et

abonnements via PostgreSQL

Vue (XML Templates) Interface utilisateur responsive en arabe

Contrôleur (Python) Logique métier pour la gestion des abonnements

3.2.2 Dockerisation

Grâce à la conteneurisation, Docker encapsule une application et toutes ses dépendances dans
un environnement isolé appelé « conteneur ». Cette approche garantit une exécution fiable,
cohérente et portable sur tous les environnements, des environnements locaux aux serveurs
cloud [11].

Figure 3.2: Architecture Docker de la solution STS avec Odoo 17

FSM Page 16
CONCEPTION DU SYSTÈME

[Link] Configuration des services

Notre fichier [Link] définit trois services principaux :

• Base de données :

– Image PostgreSQL 15 avec authentification sécurisée

– Persistance des données via montage de volume

– Configuration temporelle synchronisée avec l’hôte

• Interface d’administration :

– pgAdmin4 pour la gestion visuelle de la base de données

– Accès sécurisé par credentials

– Exposition sur le port 5080 avec traduction de port

• Application Odoo :

– Version 17 avec montage des modules personnalisés

– Ports 10018 (HTTP) et 20018 (Longpolling) exposés

– Dépendance explicite au service PostgreSQL

[Link] Choix techniques remarquables

Table 3.2: Analyse des décisions d’architecture Docker

Décision technique Justification

Réseau bridge avec IP fixes Stabilité des connexions inter-conteneurs

Montage de volumes locaux Persistance des données et développement agile

Synchronisation timezone Cohérence temporelle avec l’environnement

hôte

Versionnage explicite (Odoo Prévention des conflits de version

17, PG 15)

FSM Page 17
CONCEPTION DU SYSTÈME

[Link] Avantages opérationnels

Cette configuration apporte des bénéfices spécifiques au projet STS :

• Isolation sécurisée : Chaque composant (BDD, Odoo, admin) dans son conteneur dédié

• Portabilité : Déploiement identique sur les machines des développeurs et en production

• Maintenabilité : Mise à jour indépendante des composants (ex: PostgreSQL 15 → 16)

• Extensibilité : Ajout aisé de services (ex: Redis pour le cache)

Exemple de workflow de développement :

1. Modification des modules dans ./odoo-addons

2. Redémarrage du conteneur Odoo uniquement
3. Test immédiat via le port 10018

Cette architecture suit les meilleures pratiques Docker tout en étant optimisée pour le développement
de modules Odoo personnalisés, comme recommandé dans la documentation officielle Odoo
Docker [12, 13].

3.3 Modélisation UML

3.3.1 Utilisation de [Link] pour la modélisation

Pour la création des diagrammes UML (classes, séquence, etc.), j’ai utilisé l’outil en ligne
[Link] [14].
[Link] offre une interface intuitive et des fonctionnalités avancées pour la création de diagrammes
techniques, facilitant ainsi la modélisation du système.

FSM Page 18
CONCEPTION DU SYSTÈME

Figure 3.3: Interface de [Link] utilisée pour la modélisation

3.3.2 Diagramme de classes

Les diagrammes de classe sont un outil essentiel en conception orientée objet, permettant de
modéliser la structure d’un système en représentant les classes, leurs attributs, méthodes et les
relations entre elles [15].

Dans le contexte d’un site web, ce diagramme offre une vision claire de l’architecture et des
interactions entre les différentes entités, telles que les utilisateurs, ou les fonctionnalités du site.

FSM Page 19
CONCEPTION DU SYSTÈME

Figure 3.4: Diagramme de classes : utilisateurs, abonnements, trajets, etc.

FSM Page 20
CONCEPTION DU SYSTÈME

3.3.3 Diagramme de séquence

Figure 3.5: Diagramme de séquence : processus d’abonnement

FSM Page 21
CONCEPTION DU SYSTÈME

3.4 Conception de la base de données

3.4.1 Choix de PostgreSQL

PostgreSQL a été retenu pour ses caractéristiques techniques adaptées à notre projet:

Table 3.3: Comparaison des systèmes SGBD

Critère MySQL PostgreSQL

Conformité ACID [16] Moyenne Excellente

Support JSON [16] Basique Avancé

Intégration Odoo [17] Moyenne Native

Performances [16] Bonnes Excellentes pour données complexes

3.4.2 Gestion des abonnements et trajets (GTFS)

L’implémentation du standard GTFS s’articule autour des tables suivantes:

Table 3.4: Correspondance entre fichiers GTFS et tables PostgreSQL

Fichier GTFS Table PostgreSQL

[Link] Stop (arrêts avec coordonnées géographiques)

[Link] Route (lignes de transport)

stop_times.txt Schedule (horaires aux arrêts)

3.5 Sécurité

3.5.1 Authentification par Email

Le système d’authentification repose sur:

Chiffrement: PBKDF2 avec sel pour le stockage des mots de passe

FSM Page 22
CONCEPTION DU SYSTÈME

Figure 3.6: Diagramme de séquence : Processus sécurisé d’authentification et création de compte

FSM Page 23
CONCEPTION DU SYSTÈME

3.6 Gestion de projet avec Trello

L’outil Trello a été utilisé pour organiser le travail selon la méthodologie Scrum:

Figure 3.7: Tableau Trello pour le suivi des sprints

Les principales listes utilisées:

• Backlog: Toutes les fonctionnalités à implémenter

• En cours: Tâches du sprint courant

• Revue: Tickets en attente de validation

• Terminé: Tâches finalisées

3.7 Conclusion

Ce chapitre a présenté les fondements techniques de notre solution. L’architecture MVC combinée
à la conteneurisation Docker offre une base solide et modulaire. Les diagrammes UML clarifient
les interactions système, tandis que le schéma de base de données optimisé pour GTFS assure
une gestion efficace des données de transport. Ces choix de conception permettent une implémentation
robuste qui sera détaillée dans le chapitre suivant.

FSM Page 24
Chapter

4
Implémentation

4.1 Introduction

Ce chapitre présente la réalisation concrète du système d’abonnement STS, développé avec

Odoo 17. Nous détaillons l’architecture technique, les modules clés implémentés, les interfaces
utilisateur et les mécanismes d’intégration entre les composants. Cette réalisation s’appuie sur
les spécifications techniques décrites au chapitre précédent.

4.2 Environnement de développement

4.2.1 Matériel utilisé

Table 4.1: Configuration matérielle de développement

Marque Lenovo IdeaPad 3 15IIL05

Processeur Intel® Core™ i3-1005G1 × 4

Mémoire RAM 8.0 GiB

Stockage SSD 512 GB

Système d’exploitation Ubuntu 24.04.2 LTS (64-bit)

4.2.2 Environnement logiciel

• VS Code : Éditeur principal avec extensions Python, XML, CSS, JS, CSV(Security
Permission Group), Docker-Compose(YML)

FSM Page 25
IMPLÉMENTATION

• Odoo 17 : Framework de développement

• Git : Gestion de versions (repository privé sur GitHub)

• Docker : Containers pour Odoo, PostgreSQL, pgadmin4

Figure 4.1: Architecture logicielle de l’environnement de développement

4.2.3 Présentation Technique d’Odoo

[Link] Définition Générale

Odoo est un ERP open-source complet intégrant également des fonctionnalités de CRM. Selon
[18], sa particularité réside dans son architecture modulaire permettant d’étendre ses fonctionnalités
de base grâce à des modules personnalisés.

[Link] Caractéristiques Techniques

• Modularité : Développement de modules spécifiques (comme notre module STS) qui

s’intègrent nativement avec les applications de base [19]

• ORM : Système de persistance des données offrant :

– Opérations CRUD automatisées requête Complexes via les domaines

– Gestion native des transactions [20]

• Moteur de templates QWeb : Permet :

– Génération de vues en XML

FSM Page 26
IMPLÉMENTATION

– Support natif des langues RTL (arabe)

– Rend côté client [21]

• Sécurité :

– Contrôle d’accès par enregistrement

– Groupes de permissions [22]

– Protection CSRF (désactivée pour nos API publiques) [23]

[Link] Pertinence pour le Projet STS

Le choix d’Odoo comme plateforme technique s’appuie sur trois justifications principales :

• Compatibilité : Déjà utilisé par la STS pour d’autres modules

• Expertise : L’encadrement technique de M. Tayeb Jebeniani certifié Odoo, a permis de

garantir les meilleures pratiques de développement.

• Efficacité : Gain de 40% de temps de développement (suivi des performances) [24]

4.2.4 Infrastructure Dockerisée

• Conteneur Odoo : Version 17 avec Python 3.10

• PostgreSQL : Base de données (v15) avec pgAdmin 4

• Réseau : Bridge Docker avec adressage IP fixe ([Link]/24)

Figure 4.2: Architecture du projet STS

FSM Page 27
IMPLÉMENTATION

4.2.5 Outils de développement

• Modèles Odoo : Héritage des modèles standard ([Link])

• API REST : Contrôleurs HTTP pour les mobiles

• QWeb Templates : Interfaces frontend RTL

4.3 Modules clés implémentés

4.3.1 Module resroutier (Gestion des trajets)

Structure principale :

Table 4.2: Modèles principaux du module resroutier

Modèle Description

[Link] Trajets avec arrêts et tarifs

[Link] Points d’arrêt géolocalisés
[Link] Horaires des trajets

Fonctionnalités remarquables :

• Calcul automatique des tarifs basé sur la distance

• Validation des horaires (format HH:MM)

• API REST pour consultation mobile

4.3.2 Module STS Abonnement

Architecture clé :

• Modèle Abonné :

FSM Page 28
IMPLÉMENTATION

– Gestion des profils (étudiant/élève/stagiaire)

– Contraintes métier (CIN unique)

• Modèle Abonnement :

– Calcul automatique des dates (15/09 - 30/06)

– Gestion des tarifs spéciaux vacances

4.4 Interfaces utilisateur

4.4.1 Workflow utilisateur

1. Inscription : Formulaire standard Odoo

2. Création de profil : Formulaire dynamique avec :

• Sélection conditionnelle des établissements

• Validation des champs (CIN, téléphone)

3. Souscription :

• Sélection interactive des trajets

• Calcul en temps réel du tarif

4.4.2 Adaptation RTL

Solutions mises en œuvre :

• Templates QWeb spécifiques ([Link])

• CSS personnalisé pour l’alignement droite-gauche

• Bibliothèque Tajawal pour l’arabe

FSM Page 29
IMPLÉMENTATION

Figure 4.3: Formulaire de profil avec validation en temps réel

4.5 Intégration et API

4.5.1 Endpoints REST

Table 4.3: API disponible dans resroutier

Endpoint Méthode Fonction

/api/routes GET Liste des trajets

/api/schedules GET Horaires par trajet
/api/route/tariff GET Calcul de tarif

FSM Page 30
IMPLÉMENTATION

4.5.2 Sécurité

• Authentification publique contrôlée

• Désactivation du CSRF pour les API mobiles

• Journalisation des erreurs (logging)

4.6 Tests et validation

4.6.1 Stratégie de test

• Tests unitaires : Modèles Python

• Tests fonctionnels : Workflows utilisateur

• Tests d’intégration : API REST

4.6.2 Résultats clés

Table 4.4: Exemples de cas de test validés

Scénario Couverture Résultat

Création profil élève Champs parentaux OK

Calcul tarif vacances 10+ segments OK
Annulation abonnement Workflow complet OK

[Link] Fonctionnalités avancées utilisées

• Template personnalisé : Adaptation de la classe FSM pour respecter les normes de la

faculté

• Gestion des figures : Inclusion dynamique avec \includegraphics et positionnement

[H]

FSM Page 31
IMPLÉMENTATION

• Références automatiques : Usage intensif de \label et \ref

• Bibliographie : Gestion avec BibTeX et le fichier [Link]

[Link] Avantages constatés

• Cohérence stylistique garantie dans tout le document

• Génération automatique de la table des matières et listes des figures/tables

• Facilité de maintenance grâce à la séparation en fichiers .tex modulaires

• Compatibilité avec les outils de gestion de version

4.7 Conclusion

L’implémentation a respecté les spécifications initiales avec :

• Une architecture modulaire (2 modules Odoo)

• Une API robuste pour les applications mobiles

Les tests ont validé les principaux workflows métier, tout en identifiant des opportunités d’optimisation
pour le déploiement.

FSM Page 32
Chapter

5
Analyse et Évaluation

5.1 Introduction

Ce chapitre présente une analyse critique de notre solution en comparaison avec les systèmes
existants, identifie les limitations actuelles, et explore les perspectives d’évolution. L’évaluation
couvre à la fois les aspects techniques et l’expérience utilisateur.

5.2 Comparaison avec les solutions existantes

5.2.1 Avantages techniques

Table 5.1: Comparatif technique avec les concurrents

Fonctionnalité SRT Gafsa SORETRAK Notre solution

Authentification Basique Email Email + 2FA (futur) +

OAuth(Google, Facebook)

GTFS Non Partiel Complet

5.2.2 Avantages pour l’utilisateur

• Interface unifiée en arabe

• Parcours simplifié en 3 étapes

• Notifications en temps réel

FSM Page 33
ANALYSE ET ÉVALUATION

• Historique des abonnements

5.3 Limites du système actuel

5.3.1 Points à améliorer

• Performance : Temps de réponse >2s pour 1000+ utilisateurs

• Paiement : Intégration partielle (simulation seulement)

• Mobile : Interface web responsive mais pas d’application native

5.4 Perspectives

5.4.1 Améliorations futures

Table 5.2: Feuille de route des évolutions

Fonctionnalité Description Échéance

Paiement en ligne Intégration Paymee/Click2Pay 2024 Q1

Reconnaissance faciale Vérification photo profil 2024 Q2

Alertes temps réel Notifications perturbations 2024 Q3

5.4.2 Extension vers d’autres régions

• Adaptation du modèle GTFS

• Paramétrage multi-réseaux

• Gestion des tarifs régionaux

FSM Page 34
ANALYSE ET ÉVALUATION

5.4.3 Intégration d’IA

Cas d’usage potentiels :

• Prédiction de fréquentation

• Optimisation des trajets

• Chatbot d’assistance

Figure 5.1: Vision de l’intégration d’IA dans le système

5.5 Conclusion

Notre solution apporte des améliorations significatives par rapport aux systèmes existants, tant
sur le plan technique que fonctionnel. Si des limitations persistent (performance à grande
échelle, paiement), la feuille de route prévoit des évolutions stratégiques. L’architecture modulaire
permettra d’intégrer progressivement l’IA et les paiements en ligne, positionnant la STS comme
leader dans la digitalisation des transports en Tunisie.

FSM Page 35
 Conclusion Générale

Ce projet a concrétisé la digitalisation des abonnements STS via une plateforme Odoo innovante.
L’intégration du standard GTFS et une interface arabe intuitive répondent aux besoins des
usagers tout en modernisant les processus internes.

Les choix techniques - Docker, PostgreSQL et l’architecture MVC - ont prouvé leur pertinence,
offrant stabilité et performance. La méthodologie Scrum a permis une adaptation continue aux
exigences métier.

La solution apporte des bénéfices tangibles : gain de temps pour les usagers, réduction
des coûts pour la STS, et ouverture des données via API. Son succès pourrait inspirer d’autres
sociétés de transport tunisiennes.

Les perspectives incluent le paiement en ligne, une application mobile native, et l’intégration
d’IA pour optimiser le réseau. Ce projet marque ainsi une étape clé dans la transformation
digitale des transports publics.

Comme l’adage le rappelle,

« Un voyage de mille lieues commence toujours par un premier pas. »

- Lao Tseu

Ce projet représente non seulement une avancée concrète pour la STS, mais aussi une étape
importante dans mon parcours professionnel, m’ayant permis d’appliquer mes connaissances
académiques à un défi réel tout en développant de nouvelles compétences techniques et managériales.

FSM Page 36
 BIBLIOGRAPHY

[1] Wikipedia. Société de transport du Sahel. Dernière modification en 2023.

[2] La Presse de Tunisie. STS : Accélérer l’acquisition de 50 nouveaux bus et prioriser le

transport scolaire. 26 novembre 2024.

[3] African Manager. STS : Reprise de l’exploitation de certaines lignes. Avril 2025.

[4] FSM. Faculté des Sciences de Monastir. Loi de création.

[5] STS. Société de transport du Sahel. Page Contact.

[6] Meynier, Coralie. Le match : « cycle en v » vs scrum, quelle méthode choisir ? Islean
Consulting. 20 septembre 2016.

[7] GTFS. General Transit Feed Specification. Documentation officielle.

[8] SRT Gafsa. Plateforme d’abonnement en ligne.

[9] SORETRAK. Plateforme d’abonnement en ligne.

[10] Nicolas Brondin-Bernard. Comprendre l’architecture Modèle-Vue-Contrôleur (MVC).

Code Garage. 15 janvier 2024.

[11] Maker System. Docker : quel est son rôle dans la production et le déploiement ? 10
décembre 2024.

[12] Odoo. Official Odoo Docker images. 2024.

[13] PostgreSQL. Official PostgreSQL Docker images. 2024.

[14] [Link]. Outil de modélisation UML.

FSM Page 37
BIBLIOGRAPHY

[15] Lucidchart. UML Class Diagram.

[16] Astera Équipe Analytics. PostgreSQL vs. MySQL : le débat sur les données. 19 mars
2025.

[17] Odoo-Aide. Why Postgresql database using in OpenERP? 2014.

[18] Odoo S.A.. Architecture Technique d’Odoo. 2023.

[19] Odoo Developer Documentation. Module Development (Coding guidelines). 2024.

[20] Odoo ORM API. Official Documentation. 2024.

[21] QWeb Template Engine. Technical Reference. 2024.

[22] Odoo Security Model. Developer Guide. 2024.

[23] Odoo Web Controllers. Developer Guide. 2024.

[24] Ayrade. Suivi des Performances des Employes avec Odoo : Outils et Astuces. 16
décembre 2024.

FSM Page 38
 Système d’Abonnement STS

Mehdi Zrafi

Résumé:
Ce projet a développé une plateforme digitale de gestion d’abonnements pour la Société de
Transport du Sahel (STS) utilisant Odoo 17. Le système intègre une interface bilingue (arabe/français),
un moteur de calcul de tarifs dynamique, et suit le standard GTFS pour la gestion des trajets.
L’architecture technique repose sur Docker, PostgreSQL et le pattern MVC, avec une API
REST pour l’accès mobile. La solution digitalise le processus complet d’abonnement, depuis
la création de profil (étudiants, élèves, stagiaires) jusqu’au calcul automatique des périodes de
validité (15/09-30/06).
Mots clés: Transport public, Odoo, GTFS, Docker, PostgreSQL, Digitalisation, STS, Abonnement,
Tarification, MVC

Abstract :
This project developed a digital subscription management platform for Sahel Transport Company
(STS) using Odoo 17. The system features a bilingual interface (Arabic/French), dynamic fare
calculation engine, and complies with GTFS standard for route management. The technical
architecture leverages Docker, PostgreSQL and MVC pattern, with a REST API for mobile
access. The solution digitizes the complete subscription process, from profile creation (students,
pupils, interns) to automatic validity period calculation (09/15-06/30).
Key-words: Public transport, Odoo, GTFS, Docker, PostgreSQL, Digitalization, STS, Subscription,
Pricing, MVC
BIBLIOGRAPHY

FSM Page 40