Collection et certification
Consulter sa collection, y ajouter un exemplaire, en demander la certification et consulter les preuves d'authenticité.
Ma contributionLe projet en quelques mots
Le sujet, imaginé par l'enseignant, portait sur PECz : une plateforme permettant à des collectionneurs de gérer leurs cartes, d'en faire certifier l'authenticité, et de les échanger sur une place de marché. La difficulté n'est pas technique mais analytique - traduire un besoin métier flou en un modèle cohérent et défendable.
Le travail a été réparti entre six étudiants, chacun prenant en charge un pan fonctionnel du système, avant une phase d'unification des modèles produits.
Place de marché
Enchères, mises, primes de recherche et gestion des paiements.
Autres membresAdministration et comptes
Gestion des utilisateurs, certification des vendeurs et panneau d'administration.
Autres membresMa démarche, du besoin au modèle
Mon périmètre a suivi la progression classique de la méthode : partir de ce que l'utilisateur veut obtenir, puis descendre progressivement vers la structure interne du système, chaque niveau devant rester cohérent avec le précédent.
Cadrer les cas d'utilisation
Huit cas d'utilisation reliés à quatre acteurs externes : le collectionneur, la base mondiale de cartes, le service de certification et la blockchain.
Spécifier le cas principal
Rédaction détaillée : acteurs et intérêts, préconditions et postconditions, scénario nominal en dix étapes, scénarios alternatifs, exigences de performance et de sécurité, glossaire.
Modéliser les interactions
Diagramme de séquence distinguant les responsabilités : ce qui relève de l'affichage, du pilotage, des données métier et des systèmes externes.
Structurer les classes
Diagramme de classes d'analyse : six classes avec leurs attributs, leurs opérations et leurs relations, directement dérivées du scénario précédent.
Le choix de conception le plus structurant
Le sujet mettait en avant la blockchain. La tentation était de la placer au centre du modèle. Nous avons fait le choix inverse, et je l'ai justifié directement dans le diagramme :
Le besoin profond n'est pas la « blockchain » ni la technique, mais la production d'une preuve de confiance exploitable pour la collection, la vente et la traçabilité.Note portée sur mon diagramme de cas d'utilisation
La blockchain est donc modélisée comme un système externe au service d'un besoin, et non comme un objectif en soi. Cette décision a une conséquence concrète dans la spécification : si le service est injoignable, le système continue d'afficher les données de la collection en signalant simplement que les preuves d'authenticité sont momentanément indisponibles. Le cœur du service reste utilisable.
La même logique m'a conduit à séparer deux notions que l'on confond facilement : la carte de référence, définition générique et publique d'une carte, et l'exemplaire réellement possédé, avec son état physique et son propriétaire. Un exemplaire est rattaché à une référence plutôt qu'à une saisie libre, ce qui rend la collection exploitable et comparable.
Ce qui a été livré
Diagramme de cas d'utilisation
Huit cas d'utilisation et quatre acteurs externes, avec relations d'inclusion pour les étapes obligatoires, et des notes explicitant l'objectif métier de chaque choix de modélisation.
Spécification détaillée
Le cas principal rédigé selon la trame de la méthode : identité, parties prenantes, conditions, scénario nominal, alternatives et exceptions, exigences spéciales et glossaire.
Diagramme de séquence
Le déroulé complet des échanges, séparé en deux temps - l'accès à la collection puis la sélection d'un exemplaire - avec la distinction entre interface, contrôleur, entités et systèmes externes.
Diagramme de classes d'analyse
Six classes typées avec leurs attributs et opérations, dont un agrégateur chargé d'assembler les données locales avant d'y adjoindre les preuves fournies par la blockchain.
L'unification : du morceau au système
Chaque membre ayant modélisé son périmètre de son côté, la dernière étape a consisté à fusionner ces travaux en un diagramme de classes unique couvrant tout le système. C'est un travail collectif, et c'est le plus révélateur de l'exercice : il fait apparaître les incohérences que le découpage avait masquées.
Interface
9 classes
Les écrans et les passerelles vers l'extérieur : vue de la collection, interface d'enchères, panneau d'administration, dépôt de preuve vidéo, service de notation, blockchain.
Contrôle
6 classes
Un contrôleur par grande fonction : collection, certification, enchères, primes de recherche, comptes utilisateurs et certification des vendeurs.
Entités
12 classes
Les objets métier durables : utilisateur, compte et solde, carte de référence, exemplaire possédé, certificat, événement de traçabilité, enchère, prime, preuve vidéo, journal d'audit.
Le modèle final s'organise en cinq domaines fonctionnels - utilisateurs, collection, certification, enchères et primes - tout en conservant la séparation en trois couches appliquée par chacun dans son périmètre.
L'exercice a eu un effet direct sur mon propre modèle : la classe que j'avais
nommée CardInstance est devenue OwnedCopy, et s'est
enrichie d'opérations venues du périmètre certification d'un autre membre -
rattacher un certificat, enregistrer un événement de traçabilité. Nous avions
modélisé le même objet métier sous deux angles différents ; l'unification a
obligé à n'en garder qu'un.
Synthèse du projet
Travail réalisé
La conception complète d'un pan fonctionnel : du diagramme de cas d'utilisation à la structure de classes, en passant par une spécification rédigée et un diagramme de séquence, le tout produit en une semaine de travail intensif.
Ce que le projet m'a apporté
L'habitude de justifier un choix de modélisation plutôt que de le subir. Écrire noir sur blanc pourquoi la blockchain n'était pas l'objectif du système m'a obligé à formuler le besoin réel - un exercice qui ressemble beaucoup à ce que demande un client quand il faut lui expliquer une architecture.