Projet A1 — Suivi des dépenses d'une PME

Script oral, répartition des rôles et guide de démonstration

Master 1 COGE — Module Bases de Données — Soutenance de groupe (10 minutes)

Ce document est le script complet de votre soutenance. Il indique qui parle, quand, quoi dire, et comment réaliser
la démonstration en direct dans Access. Chaque membre du groupe doit lire l'intégralité du document au moins une
fois, pas seulement sa propre partie, car le jury peut poser des questions à n'importe qui sur n'importe quelle partie.

1. Répartition des rôles

Le jour de la soutenance, vous ne recréez rien : vous présentez la base de données déjà construite et faites une
courte démonstration en direct pour prouver qu'elle fonctionne. Voici la répartition suggérée, à ajuster selon vos
préférences.
Personne Partie prise en charge Diapo(s) Durée visée
Introduction + Contexte et
Salia DIAKITÉ 1–3 ≈ 1 min 30
cahier des charges
Modélisation des données
Souleymane MAÏGA 4 ≈ 1 min 30
(MLD, relations, intégrité)
Formulaires +
Awa DAO Démonstration, étapes 1 et 2 5 ≈ 2 min
(ajout poste et fournisseur)
Requêtes SQL (rapport
mensuel, comparatif,
Fatoumata Niamoye TOURÉ 6–9 ≈ 2 min 30
paiements en attente) +
Démonstration, étape 3
État imprimable +
Mamadou TRAORÉ Démonstration, étape 4 + 10 – 13 ≈ 2 min 30
Synthèse/conclusion

💡 Conseil
Répétez au moins une fois tous ensemble, chronomètre en main. Il vaut mieux viser 9 minutes que de dépasser les 10
minutes autorisées — un dépassement est souvent mal vu par le jury.

2. Script détaillé, partie par partie

Les phrases ci-dessous sont des propositions de formulation. Apprenez le sens général, pas le texte mot à mot —
vous serez plus naturel et plus crédible si vous parlez avec vos propres mots.

Partie 1 — Introduction et contexte (Salia DIAKITÉ)

« Bonjour, nous sommes le Groupe 1 et nous allons vous présenter notre projet de base de données : le suivi
des dépenses d'une PME, réalisé sous Microsoft Access.
Le besoin est simple à énoncer mais complet à résoudre : une PME veut suivre ses dépenses mensuelles,
comparer ce qui était prévu au budget avec ce qui a été réellement dépensé, et fiabiliser le suivi de ses
paiements fournisseurs.
Pour répondre à ce besoin, nous avons construit une base autour de trois entités : les postes de dépenses, les
fournisseurs, et les paiements, reliés entre eux par des clés primaires et étrangères. »

💡 Ce qu'il faut retenir pour les questions

Le cahier des charges demande explicitement 4 livrables : des formulaires de saisie, un rapport mensuel par poste, un
comparatif prévu/réel, et un état des paiements en attente. Toute la suite de la présentation existe pour prouver que ces
4 points sont couverts.
Partie 2 — Modélisation des données (Souleymane MAÏGA)
« Voici le Modèle Logique de Données de notre base. Trois tables : Postes_de_dépenses, Fournisseurs, et
Paiements, qui est la table centrale puisqu'elle contient les deux clés étrangères ID_Poste et ID_Fournisseur.
Un détail important : la table Paiements contient deux champs liés à la date, Date_Paiement et
Mois_de_l_operation. Ce n'est pas redondant par hasard — nous avons dû séparer les deux car un
regroupement par mois sur une date complète créait une ligne différente pour chaque jour, au lieu de
regrouper tout le mois ensemble.
Enfin, l'intégrité référentielle est activée sur les deux relations : elle empêche d'enregistrer un paiement vers
un poste ou un fournisseur qui n'existe pas, et empêche de supprimer un poste ou un fournisseur encore
utilisé. »

💡 Si le jury demande d'où vient ce choix

Répondez que c'est une correction trouvée en testant la base : signe d'une vraie démarche de vérification, pas juste
d'exécution — c'est un bon point à mettre en avant.

Partie 3 — Formulaires + Démonstration, étapes 1 et 2 (Awa DAO)

« Pour la saisie des données, nous avons créé trois formulaires, un par table. Celui des paiements est le plus
intéressant techniquement : au lieu de taper un numéro d'identifiant à la main, l'utilisateur choisit dans une
liste déroulante qui affiche directement le nom du poste ou du fournisseur.
Techniquement, cette liste interroge la table avec une requête SQL à deux colonnes : l'identifiant, rendu
invisible avec une largeur de 0 centimètre, et le libellé, qui reste affiché. La base continue donc d'enregistrer
un numéro, mais l'utilisateur ne voit et ne choisit qu'un nom — ce qui supprime tout risque d'erreur de saisie.
Pour vous le prouver concrètement, nous allons ajouter en direct un nouveau poste de dépense et un nouveau
fournisseur. »

→ Enchaîner directement avec les étapes 1 et 2 du guide de démonstration en section 3.

Partie 4 — Requêtes SQL + Démonstration, étape 3 (Fatoumata Niamoye TOURÉ)

« Nous avons construit trois requêtes, chacune illustrant une opération différente de l'algèbre relationnelle.
La première, le rapport mensuel, utilise une jointure interne et un regroupement pour additionner les
dépenses par poste et par mois — mais elle a une limite : un poste sans aucun paiement n'apparaît pas.
C'est justement pour corriger cette limite que la deuxième requête, le comparatif budget prévu et réel, utilise
une jointure externe, une LEFT JOIN : elle conserve tous les postes, même sans paiement, en affichant 0
grâce à la fonction Nz qui remplace les valeurs vides par zéro.
La troisième requête est plus simple : elle sélectionne uniquement les paiements dont le statut est « En attente
», grâce à une clause WHERE, pour donner au comptable une liste d'actions prioritaires.
Justement, le poste que nous venons d'ajouter n'a encore aucun paiement — regardons ensemble ce que
montre le comparatif. »

→ Enchaîner avec l'étape 3 du guide de démonstration.

💡 Piège fréquent à anticiper
Si le jury demande « pourquoi ne pas utiliser LEFT JOIN partout ? », répondez que le rapport mensuel doit justement
exclure les postes sans activité ce mois-ci — sinon on afficherait des lignes vides sans intérêt. Le choix de jointure
dépend du besoin, pas d'une préférence technique.

Partie 5 — État, Démonstration finale et conclusion (Mamadou TRAORÉ)

« Le rapport mensuel que nous venons de voir existe aussi sous forme d'État — c'est-à-dire sa version
imprimable, avec les postes regroupés visuellement et les sous-totaux calculés automatiquement. C'est ce
document que le comptable de la PME imprimerait chaque mois pour son suivi.
Pour finir la démonstration, ajoutons un paiement en attente pour notre nouveau fournisseur, via les listes
déroulantes du formulaire Paiements. »

→ Enchaîner avec l'étape 4 du guide de démonstration, puis reprendre :

« Ce projet nous a permis de passer d'un besoin métier réel à une base de données normalisée et fiable, avec
des interfaces pensées pour un utilisateur non-technique, et des requêtes SQL mobilisant sélection, jointures
et regroupement.
Une piste d'évolution possible serait d'automatiser une alerte lorsqu'un poste dépasse son budget prévu, en
 s'appuyant sur la requête comparatif que nous avons déjà construite.
Nous vous remercions de votre attention et sommes prêts à répondre à vos questions. »

3. Guide de démonstration en direct

Objectif : prouver que la base est réellement opérationnelle en ajoutant de vraies données pendant l'exposé, et en
montrant qu'elles se répercutent automatiquement dans les requêtes déjà construites. Prévoyez environ 2 minutes
au total pour ces 4 étapes, réparties entre les intervenants comme indiqué plus haut.

Étape 1 — Ajouter un nouveau poste de dépense (Awa DAO)

1. Ouvrir Formulaire_Postes_Depenses en Mode Formulaire.
2. Aller sur la ligne vide en bas (flèche « Nouvel enregistrement » ou Ctrl + signe +).
3. Saisir Libelle : « Formation du personnel ».
4. Saisir Montant_Prevu_Mensuel : 25000.
5. Laisser ID_Poste vide — il se génère automatiquement.

Étape 2 — Ajouter un nouveau fournisseur (Awa DAO)

1. Ouvrir Formulaire_Fournisseurs en Mode Formulaire.
2. Nouvel enregistrement.
3. Saisir Nom : « Bamako Formation SARL ».
4. Saisir un Contact au choix, par exemple un numéro fictif.

Étape 3 — Montrer l'effet dans le comparatif (Fatoumata Niamoye TOURÉ)

1. Ouvrir requête_comparatif en Mode Feuille de données (double-clic dessus).
2. Repérer la ligne « Formation du personnel ».
3. Montrer au jury que Montant_Prevu_Mensuel affiche bien 25 000, et que Total_Reel affiche 0 — et non une
case vide — grâce à Nz().
💡 Phrase clé à dire à ce moment
« Ce 0, et non une case vide, c'est la preuve concrète que notre LEFT JOIN et notre fonction Nz() fonctionnent
ensemble : le poste apparaît même sans paiement. »

Étape 4 — Ajouter un paiement et vérifier l'état des paiements en attente (Mamadou

TRAORÉ)
1. Ouvrir Formulaire_Paiements en Mode Formulaire.
2. Nouvel enregistrement.
3. Dans la liste déroulante Poste, choisir « Formation du personnel ».
4. Dans la liste déroulante Fournisseur, choisir « Bamako Formation SARL ».
5. Saisir un Montant, par exemple 25000.
6. Saisir la Date_Paiement du jour, et Mois_de_l_operation en conséquence (ex. « Août 2026 »).
7. Saisir Statut : « En attente ».
8. Ouvrir requête_paiements_en_attente et montrer que la nouvelle ligne apparaît immédiatement, sans aucune
manipulation supplémentaire.
💡 Si quelque chose ne fonctionne pas pendant la démo
Restez calme : dites simplement « nous allons vérifier la saisie » et recontrôlez l'orthographe exacte du statut (« En
attente », avec cette casse précise) ou les valeurs des listes déroulantes. Une erreur de démo en direct n'est pas grave si
vous savez l'expliquer et la corriger posément — cela montre au contraire que vous maîtrisez l'outil.
4. Explication des points qui ont posé le plus de difficulté
Cette section est là pour que chacun puisse comprendre — même sans avoir touché à Access — les décisions
techniques les plus délicates du projet. Relisez-la avant la soutenance, même si ce n'est pas votre partie à présenter.

Pourquoi deux champs de date au lieu d'un seul ?

Imaginez que vous demandiez à quelqu'un de regrouper des photos par mois, mais que chaque photo soit étiquetée
avec sa date exacte au jour près. Si on regroupe strictement par étiquette, deux photos prises à deux jours différents
du même mois de juin finissent dans deux piles séparées — alors qu'on voulait une seule pile « juin ». C'est
exactement ce qui nous est arrivé. La solution a été d'ajouter une seconde étiquette, plus grossière, contenant
uniquement le mois — c'est elle qu'on utilise pour trier en piles, pendant que la date précise reste disponible
ailleurs pour la traçabilité.

LEFT JOIN et INNER JOIN : quelle différence, en une image ?

Imaginez deux listes : la liste de tous les postes de dépenses budgétés, et la liste des paiements effectués. Un
INNER JOIN ne garde que les postes qui apparaissent dans les deux listes à la fois — s'il n'y a pas encore de
paiement pour un poste, ce poste disparaît complètement du résultat. Un LEFT JOIN, lui, garde toute la première
liste (les postes), et vient simplement compléter avec les informations de paiement quand elles existent, en laissant
un vide sinon. C'est ce vide que Nz() transforme en 0.

Que fait exactement la fonction Nz() ?

Dans une base de données, une case vide (appelée Null) n'est pas la même chose que le chiffre 0 — c'est une
absence totale de valeur. Nz() est une fonction propre à Access qui dit : « si cette case est vide, affiche 0 à la place
». C'est purement cosmétique pour l'affichage, mais essentiel pour que le rapport reste lisible et que 0 puisse être
utilisé dans d'autres calculs sans provoquer d'erreur.

Comment une liste déroulante peut-elle afficher un nom mais enregistrer un

numéro ?
La liste déroulante est configurée pour aller chercher deux informations dans la table source : le numéro
d'identifiant et le nom correspondant. On indique ensuite à Access d'afficher le nom en lui donnant une largeur
normale, et de cacher le numéro en lui donnant une largeur de 0 centimètre — il existe toujours en coulisses, il est
juste invisible à l'écran. Une dernière propriété, « Colonne liée », précise que c'est bien ce numéro caché qui doit
être enregistré dans la table lorsqu'on valide un choix.

Pourquoi l'intégrité référentielle est-elle si importante ici ?

Sans elle, rien n'empêcherait de créer un paiement qui pointe vers un fournisseur qui n'existe pas dans la base, ou
de supprimer un poste de dépense alors que des paiements y font encore référence. Cela créerait des données
incohérentes, appelées des « paiements orphelins ». L'intégrité référentielle est une règle que l'on active une fois
dans les relations, et qu'Access applique ensuite automatiquement à chaque saisie, sans qu'on ait à la revérifier
manuellement.

5. Conseils pour le jour de la soutenance

● Arrivez avec le fichier Access déjà ouvert et la base déjà chargée, pour ne pas perdre de temps précieux au
lancement.
● Désignez à l'avance la personne qui manipule le clavier/souris pendant la démonstration — les
changements de main en plein exposé font perdre du temps et donnent une impression de désorganisation.
● Gardez ce document ouvert sur un second écran ou imprimé, mais ne le lisez pas mot à mot : reformulez
avec vos propres mots pour sonner naturel.
● Répétez au moins une fois en conditions réelles, chronomètre en main, avec la démonstration incluse —
c'est souvent elle qui fait déraper le timing si elle n'a pas été répétée.
● Si une question vous prend au dépourvu, un membre du groupe peut toujours dire « je laisse [prénom]
compléter, il/elle a travaillé plus en détail sur cette partie » — ce n'est pas un échec, c'est une preuve de
travail d'équipe.
● Après la démonstration, pensez à annuler ou noter que vous allez annuler les données de test ajoutées si le
prof souhaite garder la base originale intacte pour la notation.