guidetutorialflowchart-basicsreferencedevops

Diagrammes de flux de données (DFD) : niveaux, symboles et exemples pratiques

Apprenez à créer des diagrammes de flux de données avec la bonne notation. Couvre les niveaux DFD 0 à 2, les symboles Yourdon-DeMarco vs Gane-Sarson, et des exemples concrets.

10 min de lecture

Lorsqu'un système tombe en panne ou qu'un processus produit des résultats incorrects, la première question est généralement : « Où les données ont-elles mal tourné ? » Les diagrammes de flux de données (DFD) répondent à cette question en rendant explicite le mouvement des données — en indiquant exactement d'où proviennent les données, où elles vont, comment elles sont transformées et où elles sont stockées.

Contrairement aux organigrammes qui modélisent le flux de contrôle (ce qui se passe ensuite), les DFD modélisent le flux de données (quelles données se déplacent où). Cette distinction en fait l'outil idéal pour l'analyse des systèmes, la conception logicielle et la documentation des intégrations de données complexes.

Qu'est-ce qu'un diagramme de flux de données ?

Un diagramme de flux de données est une représentation visuelle de la façon dont les données circulent dans un système. Il montre :

  • Les entités externes — sources et destinations des données en dehors du système
  • Les processus — transformations qui convertissent les données d'entrée en données de sortie
  • Les entrepôts de données — endroits où les données sont stockées au repos
  • Les flux de données — le mouvement des données entre les éléments ci-dessus

Les DFD ne montrent pas le timing, la logique de décision ni qui effectue les tâches. Ils montrent uniquement le mouvement des données. Cette portée ciblée les rend utiles pour comprendre et concevoir des systèmes sans se perdre dans les détails d'implémentation.

Symboles DFD

Deux notations dominent : Yourdon-DeMarco et Gane-Sarson. Elles représentent les mêmes concepts avec des formes différentes.

Notation Yourdon-DeMarco

La notation originale d'analyse structurée, largement utilisée en ingénierie logicielle :

Élément Symbole Description
Processus Cercle (bulle) Transforme les données ; étiqueté avec un verbe
Entrepôt Rectangle ouvert Stocke les données ; étiqueté avec un nom
Entité externe Rectangle Source ou destination en dehors du système
Flux de données Flèche avec étiquette Données nommées se déplaçant entre éléments
  ┌──────────┐         ╭──────────╮        ┌═══════════════╗
  │  Client  │───────→ │ Valider  │───────→ ║ D1: Commandes ║
  └──────────┘ Commande│ commande │ Valide  ╠═══════════════╣
                       ╰──────────╯         ║               ║

Notation Gane-Sarson

Courante dans les systèmes d'information et l'analyse métier :

Élément Symbole Description
Processus Rectangle aux coins arrondis (en-tête divisé) Étiqueté avec ID et nom du processus
Entrepôt Rectangle ouvert à gauche Étiqueté avec numéro D et nom
Entité externe Rectangle Source ou destination en dehors du système
Flux de données Flèche avec étiquette Données nommées se déplaçant entre éléments
  ┌──────────┐         ┌────────────────┐        ┌═══╦════════════╗
  │  Client  │───────→ │ 1.0            │───────→ ║D1 ║ Commandes  ║
  └──────────┘ Commande│ Valider        │ Valide  ╚═══╩════════════╝
                       └────────────────┘

Quelle notation utiliser ?

Les deux transmettent les mêmes informations. Choisissez selon votre contexte :

  • Yourdon-DeMarco : préféré en ingénierie logicielle, dans les milieux académiques et lors de l'utilisation de méthodes d'analyse structurée
  • Gane-Sarson : courant dans les systèmes d'information d'entreprise et les contextes d'entreprise

Choisissez-en une et restez cohérent tout au long des diagrammes d'un projet.

Niveaux DFD

Les DFD sont organisés hiérarchiquement. Les diagrammes de niveau supérieur fournissent une vue d'ensemble ; les diagrammes de niveau inférieur fournissent des détails. Chaque niveau décompose un seul processus du niveau supérieur en ses sous-processus internes.

Niveau 0 : Diagramme de contexte

Le diagramme de contexte montre l'ensemble du système sous la forme d'un seul processus, entouré d'entités externes. Il définit les limites du système et montre quelles données franchissent cette frontière.

                   Commande client
  ┌──────────┐ ─────────────────→ ╭──────────────────────╮
  │  Client  │                    │                      │
  └──────────┘ ←─────────────────  │  Gestion de commande │
              Confirmation         │       Système        │
                                   │                      │
  ┌──────────┐ ─────────────────→ ╰──────────────────────╯
  │Fournisseur│  Mise à jour stock          │
  └──────────┘                             ↓
                                   ┌──────────────┐
                                   │ Traitement   │
                                   │ paiement     │
                                   └──────────────┘

Un diagramme de contexte devrait tenir sur une page et montrer uniquement les flux de données qui franchissent la frontière — sans détail interne. Si vous vous retrouvez à ajouter des processus internes, vous êtes au mauvais niveau.

Niveau 1 : Diagramme de vue d'ensemble

Le diagramme de niveau 1 décompose le processus de contexte unique en ses principaux sous-processus. Ce sont les domaines fonctionnels primaires du système.

  ┌──────────┐         ╭──────────╮        ╭──────────╮
  │  Client  │───────→ │ 1.0      │───────→ │ 2.0      │───┐
  └──────────┘ Commande│ Recevoir │Validée  │ Traiter  │   │
                       │ commande │         │ paiement │   │
                       ╰──────────╯         ╰──────────╯   │
                            │                              ↓
                            ↓                       ╭──────────╮
                   ┌════════════════╗               │ 3.0      │
                   ║D1: Commandes   ║────────────→  │ Exécuter │
                   ╚════════════════╝  Données cmd  │ commande │
                                                    ╰──────────╯
                                                         │
                                                         ↓
                                                  ┌──────────┐
                                                  │ Partenaire│
                                                  │ expédition│
                                                  └──────────┘

Les diagrammes de niveau 1 ont généralement 3 à 7 processus. Si vous en avez plus, envisagez de regrouper en moins de processus de niveau supérieur.

Niveau 2 : Diagramme détaillé

Le niveau 2 décompose chaque processus de niveau 1 en ses sous-étapes. Chaque bulle du niveau 1 obtient son propre diagramme de niveau 2.

Par exemple, en développant le processus 1.0 « Recevoir commande » ci-dessus :

  ┌──────────┐           ╭──────────╮           ╭──────────╮
  │  Client  │──────────→ │ 1.1      │──────────→ │ 1.2      │
  └──────────┘ Cmd brute │ Valider  │ Données    │ Vérifier │
                         │ format   │ valides    │ stock    │
                         ╰──────────╯            ╰──────────╯
                              │                      │    │
                         Invalide                    │  En stock
                         Commande              Hors  │
                              ↓               stock  ↓
                         ┌──────────┐          ╭──────────╮
                         │  Client  │          │ 1.3      │
                         └──────────┘          │ Réserver │
                                               │ articles │
                                               ╰──────────╯
                                                    │
                                                    ↓
                                           ┌════════════╗
                                           ║D1: Commandes║
                                           ╚════════════╝

Jusqu'où décomposer ?

Arrêtez de décomposer lorsqu'un processus est :

  • Assez simple pour être décrit en quelques phrases
  • Mis en œuvre par une seule personne ou une fonction système atomique
  • Déjà au niveau de détail nécessaire pour la mise en œuvre

La plupart des systèmes n'ont pas besoin de plus que le niveau 2. Le niveau 3 est rare et indique souvent que le système est trop complexe ou que la décomposition n'est pas bien structurée.

DFD vs organigramme

Ils sont souvent confondus car les deux utilisent des boîtes et des flèches. Ils répondent à des questions différentes.

Aspect Diagramme de flux de données Organigramme
Montre Comment les données circulent Comment le contrôle s'écoule dans un processus
Question principale Où vont les données ? Que se passe-t-il ensuite ?
Temps/séquence Non modélisé (transformations seul.) Central — la séquence est la structure principale
Logique décision Non représentée Explicite (losanges de décision)
Qui effectue Non montré Peut montrer avec format en couloirs
Stockage données Symbole d'entrepôt explicite Non représenté
Idéal pour Analyse de systèmes, architecture Documentation de processus, guides de procédures

Un organigramme montre les étapes dans un processus d'approbation de prêt. Un DFD montre quelles données le système de demande de prêt reçoit, où elles sont stockées et quels sont les résultats produits.

Utilisez un DFD lorsque vous analysez ou concevez un système. Utilisez un organigramme lorsque vous documentez une procédure.

Étape par étape : créer un DFD

Étape 1 : Définir les limites du système

Identifiez ce qui est à l'intérieur de votre système et ce qui est à l'extérieur :

  • À l'intérieur : processus, entrepôts de données et flux de données que vous contrôlez
  • À l'extérieur : entités externes — clients, partenaires, systèmes externes

Tout ce qui se trouve en dehors de la frontière est une entité externe. Les données qui franchissent la frontière apparaissent comme des flux dans le diagramme de contexte.

Étape 2 : Dessiner le diagramme de contexte (Niveau 0)

  1. Placez l'ensemble du système comme un seul cercle étiqueté au centre
  2. Identifiez toutes les entités externes et placez-les autour
  3. Tracez des flux de données franchissant la frontière avec des étiquettes descriptives
  4. Vérifiez la complétude : des données entrent-elles ou sortent-elles du système sans étiquette ?

Étape 3 : Identifier les processus principaux (Niveau 1)

Décomposez le système en 3 à 7 processus principaux :

  • Nommez chaque processus avec un groupe verbal (« Valider commande », « Traiter paiement »)
  • Numérotez-les (1.0, 2.0, 3.0)
  • Identifiez quels flux de données les relient

Étape 4 : Ajouter les entrepôts de données

Identifiez où les données sont stockées entre les processus :

  • Bases de données : fiches clients, historique des commandes, inventaire
  • Fichiers : journaux, configuration
  • Données externes : données transmises vers/depuis des systèmes externes (souvent représentées comme flux aux frontières, pas comme entrepôts internes)

Nommez chaque entrepôt de données avec un nom et attribuez un numéro D (D1, D2).

Étape 5 : Connecter avec des flux de données

Tracez des flèches étiquetées entre les éléments :

  • Les flux doivent avoir des noms descriptifs (« commande client », « enregistrement validé », « facture »)
  • Les flux relient les processus entre eux, les processus aux entrepôts, et les entités externes aux processus
  • Les entrepôts de données ne se connectent pas directement aux entités externes (les données doivent passer par un processus)

Étape 6 : Décomposer au Niveau 2

Pour chaque processus principal du Niveau 1, dessinez un diagramme de Niveau 2 séparé montrant ses sous-processus internes. Les flux de données entrant et sortant du processus de Niveau 1 deviennent les flux aux frontières du diagramme de Niveau 2.

Étape 7 : Vérifier la cohérence

Vérifiez que :

  • Chaque flux de données entrant dans un processus est utilisé par ce processus
  • Chaque flux de données sortant d'un processus provient de ce processus
  • Les entrepôts de données ne sont accessibles que via des processus (pas directement par des entités externes)
  • Les flux aux frontières du Niveau 1 correspondent aux flux du diagramme de contexte

Exemple concret : système de commande e-commerce

Niveau 0 : Diagramme de contexte

  ┌──────────┐  Demande commande  ╭──────────────────────╮
  │  Client  │ ─────────────────→ │                      │
  └──────────┘                   │   Système de          │
       ↑        Statut commande  │   commande e-commerce │
       └──────────────────────── │                      │
                                 ╰──────────────────────╯
  ┌──────────┐  Résultat paiement        │          ↑
  │ Passerelle│ ───────────────→          │          │
  │ paiement │ ←───────────────          │    Données
  └──────────┘  Demande charge          ↓   expédition
                                 ┌──────────────┐
                                 │  Partenaire  │
                                 │  expédition  │
                                 └──────────────┘

Niveau 1 : Processus principaux

  Client ── Demande commande ──→ ╭──────────╮
                                  │ 1.0      │ ──→ D1: Commandes
                                  │ Valider  │
                                  │ commande │
                                  ╰──────────╯
                                       │
                               Commande validée
                                       ↓
  Passerelle ←── Demande ── ╭──────────╮ ── Enregistrement ──→ D2: Paiements
  paiement       charge     │ 2.0      │    paiement
  Passerelle ── Résultat ──→ │ Traiter  │
                             │ paiement │
                             ╰──────────╯
                                       │
                              Commande confirmée
                                       ↓
                                 ╭──────────╮
  D1: Commandes ── Données ────→ │ 3.0      │ ── Demande expéd. ──→ Partenaire
  D3: Produits ─── Stock ──────→ │ Exécuter │                       expédition
                                 │ commande │
                                 ╰──────────╯
                                       │
                               Données expédition
                                       ↓
                                 ╭──────────╮
                                 │ 4.0      │ ── Mise à jour statut ──→ Client
                                 │ Suivre & │
                                 │ Notifier │
                                 ╰──────────╯

Erreurs DFD courantes

Connecter les entités externes directement aux entrepôts de données. Les entrepôts de données sont internes ; les entités externes ne peuvent pas y accéder directement. Toutes les données franchissant la frontière du système doivent passer par un processus.

Flux de données non étiquetés. Chaque flèche doit avoir un nom descriptif. « Données » ou « Info » ne sont pas descriptifs. Un flux doit être nommé selon ce que les données représentent : « commande client », « confirmation de paiement », « niveau de stock ».

Processus sans entrées ou sorties. Un processus doit avoir au moins un flux d'entrée et un flux de sortie. Un cercle sans données entrantes « crée » des données de nulle part — ce n'est pas un processus, c'est une entité externe. Un cercle sans données sortantes rejette tout — modélisez cela comme une écriture dans un entrepôt ou supprimez le processus.

Mélanger flux de contrôle et flux de données. Les décisions, la séquence et la logique de contrôle n'ont pas leur place dans les DFD. Si vous vous retrouvez à dessiner des losanges de décision, vous créez un organigramme, pas un DFD. Les DFD montrent uniquement le mouvement des données.

Trop de détails au Niveau 1. Le Niveau 1 devrait avoir 3 à 7 processus principaux. Si vous en montrez 15 au Niveau 1, vous avez sauté la décomposition hiérarchique. Regroupez les processus connexes dans des bulles de niveau supérieur et utilisez le Niveau 2 pour afficher les détails.

Niveaux incohérents. Les flux de données entrant dans le processus 2.0 dans le diagramme de Niveau 1 doivent correspondre aux flux aux frontières dans le diagramme de Niveau 2 pour le processus 2.0. L'incohérence signifie que les diagrammes ne représentent pas le même système.

Entrepôts de données partagés entre sous-systèmes sans explication. Si plusieurs processus accèdent au même entrepôt de données, assurez-vous que c'est intentionnel et que l'accès est logique. Surutiliser un seul entrepôt « base de données principale » masque d'importantes décisions d'architecture de données.

Créer des diagrammes de flux de données avec Flowova

Cartographier les flux de données manuellement est fastidieux — identifier tous les flux aux frontières, numéroter les processus de manière cohérente et maintenir la synchronisation entre les niveaux demande un effort considérable.

Le créateur de diagrammes de flux de données de Flowova génère des structures DFD à partir de descriptions de systèmes en langage naturel. Décrivez les entrées, les sorties et les principaux processus de votre système, et obtenez un diagramme brouillon que vous pouvez affiner. C'est particulièrement utile pour créer rapidement des diagrammes de contexte et des vues d'ensemble de Niveau 1, puis approfondir les détails de Niveau 2 pour les processus qui en ont besoin.

Conclusion

Les DFD sont le bon outil lorsque vous devez comprendre ou communiquer la façon dont les données circulent dans un système — non pas ce qui se passe étape par étape, mais d'où proviennent les données, ce qui les transforme, où elles sont stockées et où elles aboutissent.

Commencez par un diagramme de contexte pour établir les limites du système. Décomposez au Niveau 1 pour identifier les processus principaux. Passez au Niveau 2 uniquement pour les processus qui nécessitent des précisions supplémentaires. Nommez les flux de données de manière spécifique, évitez de mélanger la logique de contrôle dans le diagramme et vérifiez la cohérence entre les niveaux.

Ressources associées

Articles connexes

Prêt à Essayer le Générateur de Diagrammes IA ?

Rejoignez des dizaines de milliers de professionnels qui utilisent Flowova pour visualiser leurs idées. Commencez à créer des diagrammes de flux avec IA en quelques secondes.

Commencer Gratuitement