Description : niveau de stabilité structurelle de l’application selon son couplage, sa robustesse et sa facilité d’évolution.
Exemple : stable si les responsabilités sont bien séparées ; fragile si un changement mineur casse plusieurs zones.
Description : besoin métier central que l’application doit satisfaire.
Exemple : dématérialiser une demande d’accès site, gérer un processus de validation, centraliser les dossiers clients.
Description : personnes, rôles ou systèmes qui utilisent directement ou indirectement l’application.
Exemple : utilisateur final, administrateur, valideur sécurité, API partenaire.
Description : actions principales permises par le système du point de vue métier.
Exemple : créer une demande, valider un dossier, rejeter un accès, exporter un rapport.
Une ligne = un cas d’usage
Description : trajectoire complète de l’objet métier depuis sa création jusqu’à sa clôture ou son archivage.
Exemple : brouillon → soumis → en cours d’instruction → validé → archivé.
Description : statuts significatifs traversés par l’objet métier dans le workflow.
Exemple : draft, pending, approved, refused, archived.
Description : changements d’état sensibles car ils déclenchent des règles, notifications, contrôles ou effets irréversibles.
Exemple : soumettre, approuver, payer, livrer, annuler.
Description : objets métier et données structurantes manipulés par l’application.
Exemple : demande, utilisateur, badge, véhicule, paiement.
Description : manière de garantir qu’un enregistrement est identifiable de façon unique et non dupliqué.
Exemple : UUID, clé métier, combinaison nom + date de naissance + type de demande.
Description : support et mécanisme utilisés pour stocker durablement les données.
Exemple : MySQL, PostgreSQL, MariaDB, fichiers, API tierce, event store.
Description : règles garantissant la cohérence et la validité des données stockées.
Exemple : une demande ne peut pas référencer un utilisateur inexistant ; un numéro de badge doit être unique.
Description : capacité à retrouver les actions passées, les modifications, les auteurs et les dates.
Exemple : journal d’audit, logs métier, historique des changements de statut.
Description : comment le système gère les accès simultanés, les conflits d’écriture, les mises à jour concurrentes et la cohérence finale des données.
Exemple : deux utilisateurs modifient le même dossier en même temps ; le système applique un verrou, une version, une transaction ou une stratégie de retry pour éviter l’écrasement silencieux.
Description : règles de décision ou de validation qui traduisent directement le métier.
Exemple : une dérogation est obligatoire si l’accès demandé dépasse 30 jours ; un dossier incomplet ne peut pas être soumis.
Description : vérités qui doivent rester vraies en permanence, quel que soit le scénario.
Exemple : une demande validée doit toujours avoir un demandeur identifié ; un paiement marqué payé doit avoir une référence.
Description : bornes fonctionnelles et états interdits définis par le métier.
Exemple : un utilisateur standard ne peut pas approuver son propre dossier ; une demande refusée ne peut pas être livrée.
Description : répartition de ce que chaque acteur ou profil est autorisé ou chargé de faire.
Exemple : ROLE_ADMIN paramètre, ROLE_VALIDATOR approuve, ROLE_USER crée et consulte.
Description : modules internes, équipes ou services externes intervenant dans le traitement.
Exemple : back-office, service sécurité, API paiement, service de notification.
Description : systèmes tiers ou composants externes dont dépend le bon fonctionnement du produit.
Exemple : API SSO, Microservice KYC, service email, passerelle de paiement.
Description : suppositions non écrites sur lesquelles le système semble reposer.
Exemple : on suppose que les données d’un partenaire sont toujours fiables ; on suppose qu’un dossier est traité dans l’ordre.
Description : scénarios extrêmes, rares ou dégradés qui révèlent la solidité du système.
Exemple : double clic sur soumettre, données partielles, timeout API, deux validations simultanées.
Une ligne = un cas limite
Description : limites de performance ou d’organisation quand le volume, le trafic ou le nombre d’utilisateurs augmente.
Exemple : passer de 100 à 10 000 dossiers par jour sans dégrader les temps de réponse.
Description : capacité du système à intégrer de nouvelles règles, nouveaux flux ou nouveaux périmètres.
Exemple : ajouter un nouveau statut métier ou une nouvelle source de données sans refonte complète.
Description : éléments qui devraient être configurables plutôt que codés en dur.
Exemple : délais, seuils, libellés, listes de validation, adresses email métier.
Description : points solides observés dans le produit, le code ou l’architecture.
Exemple : workflow clair, bonne séparation des responsabilités, données traçables.
Description : zones de fragilité, dette technique ou manque de couverture fonctionnelle.
Exemple : logique dupliquée, couplage fort, absence de tests, règles métier dispersées.
Description : actions rapides à faible effort et fort impact.
Exemple : centraliser une validation, ajouter un log critique, corriger un doublon de règle.
Description : améliorations plus profondes visant la qualité structurelle du système.
Exemple : extraire un service métier, découpler une dépendance externe, refondre un workflow trop rigide.
Description : direction souhaitée pour stabiliser et faire évoluer le système.
Exemple : architecture modulaire, DDD léger, séparation application / domaine / infrastructure.
Description : qualités techniques et fonctionnelles recherchées à terme.
Exemple : robuste, idempotent, testable, observable, scalable, sécurisé.