Ces deux dimensions sontorthogonales<\/strong>. Un diagramme de contexte peut \u00eatre physique ; un diagramme de niveau 3 peut \u00eatre logique. Traiter \u00ab logique \u00bb comme synonyme de \u00ab de haut niveau \u00bb et \u00ab physique \u00bb comme synonyme de \u00ab d\u00e9taill\u00e9 \u00bb est une erreur fondamentale qui sape la puissance analytique du DFD.<\/p>\n Ce guide fournit une r\u00e9f\u00e9rence compl\u00e8te et autonome pour ma\u00eetriser l’axe logique\/physique. Il \u00e9tablit des d\u00e9finitions pr\u00e9cises, d\u00e9limite des r\u00e8gles de transformation strictes, identifie des anti-mod\u00e8les courants et d\u00e9montre comment le maintien de cette s\u00e9paration constitue la principale d\u00e9fense contre la dette architecturale. Que vous \u00e9licitez des exigences m\u00e9tier ou sp\u00e9cifiez des contrats de microservices, comprendre cette dichotomie fait la diff\u00e9rence entre un DFD qui capture une v\u00e9rit\u00e9 m\u00e9tier durable et un autre qui ne fait que documenter une impl\u00e9mentation technique transitoire.<\/p>\n Avant d’examiner les mod\u00e8les individuellement, nous devons \u00e9tablir le syst\u00e8me de coordonn\u00e9es. La qualit\u00e9 du DFD d\u00e9pend de deux axes ind\u00e9pendants :<\/p>\n L’analyse critique :<\/strong> Vous pouvez \u2014 et devriez souvent \u2014 produire un DFD logique de niveau 2<\/strong> (processus m\u00e9tier d\u00e9taill\u00e9, sans technologie) et un Diagramme de contexte physique<\/strong> (p\u00e9rim\u00e8tre du syst\u00e8me d\u00e9fini par des API et protocoles sp\u00e9cifiques). Ce ne sont pas des contradictions ; ce sont des points de vue diff\u00e9rents servant diff\u00e9rentes parties prenantes \u00e0 diff\u00e9rents moments.<\/p>\n Un DFD logique mod\u00e9lise les fonctions m\u00e9tier essentielles<\/strong>, d\u00e9pouill\u00e9es de tout biais d’impl\u00e9mentation. Elles repr\u00e9sentent ce que l’organisation doit<\/em> faire pour accomplir sa mission, que le travail soit effectu\u00e9 par des humains, des formulaires papier, des mainframes ou des agents d’intelligence artificielle.<\/p>\n Vocabulaire :<\/strong> Activit\u00e9s m\u00e9tier ( Exclut :<\/strong> Noms de bases de donn\u00e9es, protocoles API, formats de fichiers, mat\u00e9riel, \u00e9diteurs de logiciels, d\u00e9cisions d’automatisation, contraintes temporelles, silos d\u00e9partementaux (sauf si fonctionnellement pertinents).<\/p>\n<\/li>\n Stabilit\u00e9 :<\/strong> \u00c9lev\u00e9e. Les r\u00e8gles m\u00e9tier \u00e9voluent lentement ; la technologie \u00e9volue rapidement. Un DFD logique bien con\u00e7u reste valide sur plusieurs g\u00e9n\u00e9rations technologiques.<\/p>\n<\/li>\n Public cible principal :<\/strong>\u00a0Parties prenantes m\u00e9tier, experts du domaine, propri\u00e9taires de produit, auditeurs.<\/p>\n<\/li>\n<\/ul>\n Un DFD physique mod\u00e9lise les\u00a0l’impl\u00e9mentation concr\u00e8te<\/strong>des exigences logiques. Il sp\u00e9cifie exactement comment les donn\u00e9es circulent \u00e0 travers des technologies, des personnes et des infrastructures sp\u00e9cifiques.<\/p>\n Vocabulaire :<\/strong>\u00a0Services ( Inclut :<\/strong>\u00a0Tous les choix technologiques, les s\u00e9parations manuel vs. automatis\u00e9, les distinctions par lots vs. temps r\u00e9el, les m\u00e9canismes de gestion des erreurs, les contr\u00f4les de s\u00e9curit\u00e9, les points d’int\u00e9gration.<\/p>\n<\/li>\n Stabilit\u00e9 :<\/strong>\u00a0Faible. Li\u00e9 directement \u00e0 la pile technologique actuelle et \u00e0 la structure organisationnelle. On s’attend \u00e0 ce qu’il \u00e9volue \u00e0 chaque cycle de publication.<\/p>\n<\/li>\n Public principal :<\/strong>\u00a0Architectes, d\u00e9veloppeurs, ing\u00e9nieurs DevOps, testeurs QA.<\/p>\n<\/li>\n<\/ul>\n Le DFD logique est la base d’une analyse rigoureuse des syst\u00e8mes. Sans lui, les DFD physiques deviennent des esquisses techniques sans ancrage qui ne peuvent pas \u00eatre valid\u00e9es par rapport aux besoins m\u00e9tier.<\/p>\n Les noms de processus sont des verbes m\u00e9tier purs :<\/strong>\u00a0 Les d\u00e9p\u00f4ts de donn\u00e9es sont conceptuels :<\/strong>\u00a0 Les entit\u00e9s externes sont des acteurs m\u00e9tier :<\/strong>\u00a0 Les flux d\u00e9crivent le contenu d’information :<\/strong>\u00a0 Aucune fuite technologique :<\/strong>Z\u00e9ro r\u00e9f\u00e9rence aux bases de donn\u00e9es, files d’attente de messages, langages de programmation, frameworks, fournisseurs de cloud ou protocoles r\u00e9seau.<\/p>\n<\/li>\n Les processus manuels sont inclus :<\/strong> Si un humain effectue actuellement une \u00e9tape, elle appara\u00eet comme un processus. Le DFD logique documente la r\u00e9alit\u00e9 commerciale actuelle<\/em>et non une automatisation id\u00e9ale.<\/p>\n<\/li>\n<\/ol>\n![\"The](\"https:\/\/www.ai-diagrams.com\/wp-content\/uploads\/2026\/08\/img_6a7eca6f1c7aa.png\")
<\/p>\n
\n1. D\u00e9finitions fondamentales : Orthogonalit\u00e9 de l’intention et de la granularit\u00e9<\/h2>\n
\n\n
\n \nAxe<\/th>\n Question \u00e0 laquelle il r\u00e9pond<\/th>\n Valeurs<\/th>\n R\u00e9gule<\/th>\n<\/tr>\n<\/thead>\n \n Hi\u00e9rarchie (Niveau)<\/strong><\/td>\n \u00c0 quel point la vue est-elle d\u00e9taill\u00e9e ?<\/em><\/td>\n Contexte (0), Niveau 1, Niveau 2\u2026 Primitif fonctionnel<\/td>\n Profondeur de d\u00e9composition ; arborescence de num\u00e9rotation<\/td>\n<\/tr>\n \n Intention (Type)<\/strong><\/td>\n Quel est l’objectif de la mod\u00e9lisation ?<\/em><\/td>\n Logique, Physique<\/td>\n Abstraction par rapport \u00e0 l’impl\u00e9mentation ou engagement envers celle-ci<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 1.1 DFD logique : La v\u00e9rit\u00e9 m\u00e9tier<\/h3>\n
\n
Valider la solvabilit\u00e9<\/code>), donn\u00e9es conceptuelles (Fiche client<\/code>,\u00a0Commande<\/code>), r\u00f4les organisationnels (Analyste cr\u00e9dit<\/code>).<\/p>\n<\/li>\n1.2 DFD physique : La r\u00e9alisation technique<\/h3>\n
\n
CreditCheckService v2.1<\/code>), sch\u00e9mas (postgres.customers<\/code>), protocoles (HTTPS\/JSON<\/code>,\u00a0Sujet Kafka : credit-events<\/code>), fichiers (\/var\/log\/audit.csv<\/code>), titres de poste sp\u00e9cifiques ou d\u00e9partements.<\/p>\n<\/li>\n
\n2. Le DFD logique en d\u00e9tail : Capturer les exigences durables<\/h2>\n
2.1 Caract\u00e9ristiques d’un DFD logique bien structur\u00e9<\/h3>\n
\n
Calculer la responsabilit\u00e9 fiscale<\/code>, pas\u00a0Invoquer TaxCalcAPI<\/code>.\u00a0Aviser le client du retard<\/code>, pas Envoyer un message SQS<\/code>.<\/p>\n<\/li>\nD1 Client<\/code>,\u00a0D2 Historique des commandes<\/code>\u2014jamais MySQL customers_tbl<\/code> ou Bac S3 orders-archive<\/code>.<\/p>\n<\/li>\nOrgane de r\u00e9glementation<\/code>,\u00a0Partenaire d'exp\u00e9dition<\/code>\u2014pas Point de terminaison REST de l'IRS<\/code> ou Passerelle SOAP de FedEx<\/code>.<\/p>\n<\/li>\nR\u00e9sultat de l'\u00e9valuation fiscale<\/code>, pas Charge utile JSON avec le champ tax_amount<\/code>.<\/p>\n<\/li>\n2.2 Exemple : Syst\u00e8me d’adh\u00e9sion logique (Niveau 1)<\/h3>\n
![\"\"](\"https:\/\/www.ai-diagrams.com\/wp-content\/uploads\/2026\/08\/img_6a7ec9a9988a1.png\")
<\/p>\n
\n
\n