Institut catholique des arts et métiers

Université catholique d’Afrique centrale - Université Loyola du Congo

Mandat pour le développement d’un prototype du SGE

Système de gestion d’entrepôts
SGE_MPS_01
CoFELI/ICAM/PDII-P1_Mandat_v2024-06-19, version 1.0.0a, en date du 2024-06-19

Historique
diffusion resp. description
2022-06-19 LL Première version complète.
2022-05-20 LL Esquisse des composantes
2022-03-20 MB Ébauche initiale.

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 1 / 11

Table des matières
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Parties prenantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Fonctionnalités générales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Portée du prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Esquisse du modèle métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Procédés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Récupération . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Groupes d’entités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Modalités communes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Base de données (BD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Modèle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Schéma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Application d’exploitation (AE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Intrants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Extrants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Diagramme d’utilisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Diagramme d’interaction (flux). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.6. Maquette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Application d’automatisation (AA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Intrants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Extrants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Fonctionnalités (AAF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Interface de commande (command line interface, CLI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.5. Interface dialoguée (textual based interface, TBI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.6. Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 2 / 11

Introduction
Le mandat du projet porte sur le développement d’un prototype d’un futur système de gestion d’entrepôts
envisagé par la société Amazones et Centaures (SAC).
Les objectifs sont les suivants :
1. mettre en place puis évaluer les méthodes d’analyse et de spécification ;
2. mettre en place puis évaluer les méthodes de conception et de développement ;
3. mettre en place puis évaluer les méthodes de vérification et de validation ;
4. déterminer, déployer, utiliser puis évaluer les plateformes technologiques pressenties ;
5. obtenir une rétroaction de la part des parties prenantes suite à la mise en place expérimentale du
prototype.
La portée du prototype est limitée au maintien de l’inventaire et à la traçabilité des mouvements
(entrée/réception et sortie/livraison des produits).
Les objectifs et les tâches qui en découlent sont répartis entre deux équipes :
• équipe ASV : objectifs 1 et 3,
• équipe Dev : objectifs 2 et 4,
L’objectif 5 devant être conjointement réalisé par les deux équipes en collaboration avec les parties
prenantes lors d’une phase ultérieure du projet.
L’équipe ASV est formée d’enseignantes et d’enseignants des instituts UCAC-ICAM et ULC-ICAM. Le
mandat des équipes ASV a été établi par la direction du programme en fonction de la description du
programme et des plans des modules MATH111, INFO111, INFO211, INFO221, INFO331 et GLOG211.
Une équipe Dev est formée d’étudiantes et d’étudiants de la X1 2023-2024 de ces mêmes instituts. Plusieurs
équipes Dev seront formées par la direction du programme de diplôme d’ingénieur informatique.
Le présent document présente le découpage des principales activités et tâches découlant du mandat d’une
équipe Dev.
Ce mandat est divisé en trois composantes principales :
• la base de données,
• l’application d’exploitation,
• l’application d’automatisation.
Chacune de ces composantes doit être analysée, modélisée, conçue, programmée, vérifiée, testée et validée
en accord avec la vision élaborée par les parties prenantes.
La vision est présentée à la section 1, une esquisse du modèle métier est proposée à la section 2, les
modalités communes aux trois composantes sont décrites à la section 3 et les modalités spécifiques à
chacune des composantes sont décrites aux sections 4, 5 et 6 respectivement.

1. Vision
1.1. Contexte
La gestion efficace d’un entrepôt est essentielle pour les organisations qui stockent, traitent et distribuent
des produits physiques. C’est là qu’intervient un système de gestion d’entrepôt (SGE), un outil
technologique puissant qui révolutionne la manière dont les organisations gèrent leurs opérations
logistiques. La gestion d’entrepôt ne se limite pas à l’entreposage de produits. Elle englobe un ensemble
complexe de tâches, de la réception des marchandises à leur stockage, de la préparation des commandes à
leur expédition. Une mauvaise gestion d’entrepôt peut entrainer des problèmes tels que des retards dans la
livraison, des erreurs de commande, une utilisation inefficace de l’espace de stockage et une perte de

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 3 / 11

visibilité sur les stocks disponibles. Ces problèmes peuvent avoir un impact négatif sur la réputation de
l’organisation et sur ses résultats financiers. Un SGE, en revanche, offre des solutions pour résoudre ces
défis et permet d’atteindre des niveaux élevés de performance et de satisfaction client.
Dans ce travail, nous allons modéliser et réaliser un prototype de système de gestion d’entrepôt en utilisant
les notions apprises durant toute l’année scolaire.

1.2. Parties prenantes

Les principales parties prenantes au projet sont :
• Le responsable des stocks
• Le magasinier
• Les emballeurs
• Le responsable de la logistique
• Les agents de logistique
• Les livreurs
• Le responsable informatique
• Les techniciens informatiques
• Le responsable de la sécurité physique
• Les gardes de sécurité

1.3. Fonctionnalités générales

Un entrepôt doit pouvoir remplir différentes fonctions, comme la réception de produits, leur stockage, le
contrôle de l’inventaire ou la préparation de commandes. Plus spécifiquement, un SGE propose
généralement un ensemble complet de fonctionnalités, telles que :
1. Gestion des stocks : Le SGE offre une visibilité en temps réel sur l’état des stocks, y compris la quantité,
l’emplacement et l’état des produits. Il permet de suivre les entrées, les sorties et les mouvements de
stocks avec une grande précision.
2. Optimisation de l’espace de stockage : Le SGE permet d’organiser l’espace de stockage de manière
optimale, en tenant compte de la taille, du poids et de la fréquence de rotation des produits.
3. Planification des opérations : Le SGE facilite la planification des tâches quotidiennes, comme la
réception de marchandises, la préparation des commandes, le réapprovisionnement des cellules
d’entreposage (rayons), en attribuant efficacement les ressources nécessaires.
4. Production de rapports : Le SGE génère des rapports détaillés sur les performances de l’entrepôt, offrant
ainsi aux gestionnaires des informations cruciales pour prendre des décisions informées et identifier les
domaines nécessitant des améliorations.
5. Suivi des commandes : Le SGE permet de suivre chaque étape du traitement des commandes, de la
collecte des produits dans l’entrepôt à leur expédition, en garantissant l’exactitude et la rapidité du
processus.
6. Gestion des ressources humaines : Le SGE peut aider à répartir le personnel de manière efficiente en
fonction des besoins actuels de l’entrepôt, ce qui permet d’optimiser la main-d’oeuvre.
7. Intégration avec d’autres systèmes : Le SGE peut être intégré à d’autres systèmes de gestion, tels que les
systèmes intégrés de gestion (SIG) [Enterprise Resource Planning, ERP], ce qui permet une coordination
fluide de l’ensemble de l’organisation.

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 4 / 11

1.4. Portée du prototype
Dans le cadre du prototype, à des fins didactiques, la portée du prototype est limitée aux fonctionnalités 1,
2, 3, et 4. Plus spécifiquement, le prototype du SGE :
• doit permettre d’avoir une visibilité en temps réel sur l’état des stocks, y compris la quantité,
l’emplacement et l’état des produits. Ceci permet de suivre les entrées, les sorties et les mouvements de
stocks.
• doit aider à organiser l’espace de stockage de manière optimale, en tenant compte de la taille, du poids
et de la fréquence de rotation des produits.
• doit aider à planifier des tâches quotidiennes, comme la réception de marchandises, la préparation des
commandes, le réapprovisionnement des cellules d’entreposage, en attribuant efficacement les
ressources nécessaires.
• doit générer des rapports détaillés sur les performances de l’entrepôt pour les utilisateurs. Les rapports
peuvent être générés au niveau des stocks, pour l’espace de stockage et pour les différentes opérations.

2. Esquisse du modèle métier

Le prototype du SGE couvre principalement quatre groupes d’entités (intervenant, entrepôt, produit,
artéfact) et deux procédés (réception et expédition).

2.1. Procédés
Les procédés sont exprimées du point de vue de la SAC, en particulier :
• une réception est reçue par la SAC ;
• une expédition est faite par la SAC.
La description des procédés est relative à l’agencement physique de référence de l’entrepôt tel qu’esquissé
par le gestionnaire principal des entrepôts :

Légende
• Zone de réception : reçoit les colis au moment du déchargement.
• Zone d’expédition : reçoit les colis en attente d’expédition.
• Matériel d’emballage : reçoit le matériel d’emballage à être utilisé pour la confection des colis.
• E0, E1, E2, E3 : les quatre zones de stockage de l’entrepôt, chaque zone étant composée de plusieurs
cellules d’entreposage chacune uniquement identifiée.

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 5 / 11

2.1.1. Réception
Attendu un ensemble de bons de réception en attente
• A - réception immédiate (ligne verte de gauche)
1. Arrivée d’un chargement (composé d’un ou plusieurs colis)
2. Vérification des colis en regard des bons de réception → production d’un rapport d’exception
3. Placement des colis en zone de réception (en file, en pile, autre ?)
Les colis sont en attente de prise en charge par l’équipe d’entreposage
• B - stockage du contenu d’un colis (ligne verte de droite)
1. Sélection d’un colis (selon fonction de priorisation à documenter)
2. Attribution des emplacements → itinéraire optimal au sein de l’entrepôt
3. Désassemblage du colis et stockage des produits qu’il contient
4. Confirmation du stockage → production d’un rapport d’exception
5. Disposition du matériel d’emballage (réutilisation ou recyclage)

2.1.2. Expédition
Attendu un ensemble de bons d’expédition en attente
• A - préparation d’un colis (ligne rouge de droite)
1. Sélection d’un bon d’expédition (selon fonction de priorisation à documenter)
2. Confirmation de la disponibilité → production d’un rapport d’exception
3. Détermination des emplacements → itinéraire optimal au sein de l’entrepôt
4. Prélèvement du matériel d’emballage
5. Déstockage et assemblage du colis → production d’un rapport d’exception
6. Placement du colis en zone d’expédition
Les colis sont en attente de prise en charge par le transporteur.
• B - en attente d’expédition (ligne rouge de gauche)
1. Arrivée du transporteur
2. Vérification du colis et chargement → production d’un rapport d’exception
3. Départ du transporteur

2.2. Récupération
Noter que la zone réservée au matériel d’emballage reçoît autant le matériel neuf, que le matériel récupéré
provenant des colis reçus. Lorsqu’un colis est préparé, le matériel d’emballage requis est puisé à même le
stock commun tant neuf que récupéré. On peut présumer que le personnel privilégiera, lorsque possible,
l’utilisation du matériel récupéré.

2.3. Groupes d’entités

2.3.1. Intervenants
Les intervenants sont les organisations impliquées dans la logistique, aussi bien que des membres de leur
personnel que des individus agissant en leur nom propre (donc ne représentent pas une organisation).

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 6 / 11

Structure

Organisation (idOrganisation, nom, adresse, téléphone, etc.)

Type {fournisseur, transporteur, destinataire, etc.}
Individu (idIndividu, nom, adresse, téléphone, etc.)
Rôle : {conducteur, magasinier, acheteur, vendeur, etc.}
Répertoire : Individu x Organisation x Rôle
…

Sources de données

Société Amazones et Centaures

Personnel de la Société Amazones et Centaures
Autres organisations partenaires
Personnel des autres organisations partenaires
…

2.3.2. Produits
Structure

Produit (idProduit, nom, description, marque, modèle, fournisseur)

ProduitMateriel (idProduit, longueur, largeur, hauteur, masse)
ProduitLogiciel (idProduit, …)
Lot (idLot, idProduit, quantité)
Inventaire_produit : Produit x quantité
…

• Les produits d’emballage (boites, bandes adhésives, bourrage, etc.) sont des produits dont les
caractéristiques, la disponibilité, l’état, etc. peuvent être obtenus à ce titre.
Sources de données

Fournisseurs parmi les organisations partenaires

2.3.3. Entrepot
Structure

Cellule (idCellule, longueur, largeur, hauteur, masseMaximale)

Entrepôt (idCellule, position)
Inventaire_emplacement : Cellule x Lot
Colis et contenu du colis (…)
Inventaire_colis_entrant : …
Inventaire_colis_sortant : …
…

Sources de données

Plan de l’entrepôt
Procédé de stockage et de déstockage
Bons de réception et de de livraison
Rapports d’exception

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 7 / 11

2.3.4. Artéfacts
Structure

Bon de réception (…)

Bon d’expédition (…)
Rapport d’exception (…)
…

Sources de données

Procédé d’achat
Procédé de vente
Procédé de contrôle d’inventaire
Procédé de traitement d’incident
…

3. Modalités communes
Pour chacune des trois composantes, l’équipe Dev doit :
• rédiger le document de spécification ;
• rédiger le document de conception ;
• réaliser, vérifier et tester la composante elle-même.
La documentation est typiquement divisée en trois parties :
• le document de spécification (couvrant l’analyse, la modélisation et la spécification des exigences
proprement dites) ;
• le document de conception (couvrant la conception globale et la conception détaillée retenue au
moment de la programmation) ;
• le document de vérification-validation (couvrant la stratégie de vérification, celle de validation et la
conception des tests).
Le document de spécification et celui de vérification-validation font généralement l’objet d’une rédaction
propre.
Le contenu du document de conception est le plus souvent incorporé aux artéfacts (scripts) de mise en
oeuvre et le document lui-même produit grâce des applications ou environnements spécialisé (tels que
Doxygen pour C++, JavaDoc pour Java, Sphinx pour Python, SchemaCrawler pour SQL).
Dans le cadre du présent prototype, le contenu du document de vérification-validation peut être intégré à
celui de conception.

4. Base de données (BD)

4.1. Modèle
Un document de spécification du modèle de données (SCM) contenant minimalement les sections
suivantes en plus de la page titre, de la table des matières et de la liste des références :
1. l’énoncé du problème ;
2. l’analyse du problème ;
3. le dictionnaire de données ;
4. le schéma conceptuel et ses diagrammes (notation Merise ou EAE) ;

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 8 / 11

5. la motivation des choix de modélisation ;
6. le schéma relationnel tel qu’engendré depuis le schéma conceptuel ;
7. le schéma relationnel normalisé et la motivation des choix de normalisation.

4.2. Schéma
Le schéma de la base de données doit être livré sous la forme de scripts SQL clairement documentés et
testés :
1. un script SQL de création du schéma de base de données — domaines, types, tables : SGE_cre.sql ;
2. un script SQL pour les invariants requis — types, vues, routines et déclencheurs (triggers) : SGE_inv.sql ;
3. au moins un jeu de données complètes (sous la forme de fichiers CSV, JSON ou de scripts SQL) :
SGE_jdd_01.xxx … SGE_jdd_nn.xxx (où xxx est parmi {csv, json, sql} selon le cas ;
4. un script SQL contenant les tests unitaires positifs : SGE_test-pos.sql ;
5. un script SQL contenant les tests unitaires négatifs : SGE_test-neg.sql ;
6. tout autre script SQL jugé utile.

4.3. Interface
L’interface machine-machine (IMM) de la base de données doit être livrée sous la forme de scripts SQL
clairement documentés et testés :
1. un script SQL pour l’interface de base — vues, routines et déclencheurs (triggers) : SGE_imm.sql ;
2. un script SQL pour les requêtes proposées — routines équivalentes à des sélections : SGE_req.sql ;
3. un script SQL pour les traitements proposés — routines équivalentes à des mises à jour : SGE_tra.sql ;
4. un script SQL contenant les tests unitaires positifs : SGE_test-pos.sql ;
5. un script SQL contenant les tests unitaires négatifs : SGE_test-neg.sql ;
6. tout autre script SQL jugé utile.
L’interface de base comprend les opérations d’insertion, de retrait et de modification des entités définies
par le modèle conceptuel.
Les requêtes et traitements proposés sont établis sur la base des fonctionnalités offertes par les applications
(voir ci-après).

5. Application d’exploitation (AE)

Cette application dotée d’une interface personne-machine graphique (IPMG) vise à :
• soutenir les membres du personnel dans l’exécution de leurs tâches ;
• permettre le maintien d’une description en temps réel de l’état du système logistique et de l’entrepôt sur
la base des données factuelles colligées par les membres du personnel.
La documentation technique de l’application comporte deux documents : la spécification des exigences du
logiciel (SEL) et sa spécification de conception (SCL).

5.1. Intrants
Inventaire et description des intrants de l’application.

5.2. Extrants
Inventaire et description des intrants de l’application.

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 9 / 11

5.3. Fonctionnalités
Inventaire et description des fonctionnalités offertes par l’application.
Les intrants, extrants et fonctionnalités peuvent être illustrés à l’aide d’un diagramme de contexte (DC) et
de diagrammes de flux de données (DFD).
Certaines de ces fonctionnalités induisent des requêtes et des traitements à être mis en oeuvre par la base
de données par l’entremise de son IMM.

5.4. Diagramme d’utilisation

Inventaire des fonctionnalités de leurs dépendances par type de personnes utilisatrices. La notation UML
est privilégiée.

5.5. Diagramme d’interaction (flux)

Diagramme d’interaction en termes des types de fenêtres (« écrans » ou « pages »). La notation UML est
privilégiée.

5.6. Maquette
Maquettes de chacun des types de fenêtres devant composer l’IPM.

5.7. Réalisation
5.7.1. Conception globale
1. Conception globale de l’application en termes des modules (« packages »).
2. Choisir le langage (Java ou Python) à être utilisé, le standard de programmation et les outils requis
(atelier, gestionnaire de tests, etc.).
3. Dresser l’inventaire et la répartition des modules :
° existants prélevés à partir de logithèques (« livraries ») publiques (préciser les licences applicables) ;
° modifiés (inspirés de modules disponibles dans les logithèques publiques, préciser les licences
applicables) ;
° créés (développés en propre pour l’application).
4. Dans tous les cas, préciser les licences applicables.

5.7.2. Conception détaillée

Détailler et motiver les algorithmes et structures de données utilisés pour les modules modifiés ou créés.

6. Application d’automatisation (AA)

Cette application dotée d’une interface personne-machine textuelle (IPMT) vise à faciliter l’automatisation
des processus et des tâches récurrentes du SGE.

6.1. Intrants
Voir AE.

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 10 / 11

6.2. Extrants
Voir AE.

6.3. Fonctionnalités (AAF)

Voir AE.

6.4. Interface de commande (command line interface, CLI)

• Syntaxe de la ligne de commande
• Description du traitement des erreurs

6.5. Interface dialoguée (textual based interface, TBI)

• Diagramme de flux des commandes
• Syntaxe du dialogue
• Description du traitement des erreurs

6.6. Réalisation
Voir AE.

Produit le 2024-06-19 20:12:06 -0400

Institut catholique des arts et métiers

Université catholique d’Afrique centrale - Université Loyola du Congo

© 2024, UCAC-ULC [CC BY-NC-SA 4.0] 11 / 11