Diagramme de flux de données : symboles, niveaux et méthode

Votre entreprise remplace son outil de gestion des notes de frais. Le projet semble simple, jusqu'au jour de la bascule : les remboursements ne partent plus, parce que personne n'avait noté que l'ancien outil envoyait chaque semaine un fichier à la banque. Ce flux n'apparaissait dans aucun document, et chacun pensait qu'un autre s'en occupait.

Le diagramme de flux de données sert à éviter ce type d'oubli. Il oblige à recenser d'où viennent les données, ce qui les transforme, où elles sont stockées et vers qui elles repartent. Vous trouverez ici les symboles à connaître, les niveaux de détail, les règles qui rendent un DFD fiable, une méthode pas à pas, un exemple complet et la façon d'en faire la base d'un plan de projet.

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

Un diagramme de flux de données est une représentation graphique du chemin suivi par les informations dans un système : un logiciel, un service ou un processus métier. Il montre quelles données entrent, quels traitements les transforment, où elles sont conservées et vers quels destinataires elles sortent. On parle aussi de DFD, de l'anglais data flow diagram.

Le DFD est né avec l'analyse structurée, à la fin des années 1970. Tom DeMarco et Ed Yourdon d'un côté, Chris Gane et Trish Sarson de l'autre, en ont fixé les deux notations encore utilisées aujourd'hui. Son principe n'a pas changé : décrire un système par ses données plutôt que par son code ou son organisation.

DFD logique et DFD physique

Un même système peut être décrit à deux niveaux d'abstraction. Les équipes commencent en général par le DFD logique, qui sert à valider le besoin, puis passent au DFD physique pour la mise en œuvre.

Ce qu'un diagramme de flux de données ne montre pas

Un DFD ne représente ni l'ordre des étapes, ni les décisions, ni les délais. Il ne dit pas si le contrôle a lieu avant ou après l'approbation, ni ce qui se passe en cas de refus. Pour ces questions, utilisez un diagramme de processus ou un logigramme, qui décrivent l'enchaînement des actions.

Les 4 symboles d'un diagramme de flux de données

Tous les DFD utilisent quatre éléments. Seule leur forme change selon la notation choisie : Yourdon-DeMarco, plus répandue dans l'enseignement, ou Gane-Sarson, fréquente dans les outils de modélisation.

Conventions de nommage

• Processus : un verbe à l'infinitif suivi d'un complément (« Valider la demande »), avec un numéro qui reprend son niveau (1, 1.1, 1.2).

• Flux : un nom qui désigne la donnée transportée (« Montant approuvé »), jamais une action.

• Magasin : un nom au pluriel (« Salariés », « Factures »), précédé d'un identifiant D1, D2 en notation Gane-Sarson.

• Entité externe : un rôle ou une organisation (« Fournisseur »), pas le nom d'une personne.

Les niveaux d'un DFD : du diagramme de contexte au niveau 2

Un diagramme de flux de données se lit par niveaux, comme une carte que l'on agrandit. Chaque niveau détaille un processus du niveau précédent, ce qui permet de faire valider le diagramme par des publics différents.

Une règle relie les niveaux entre eux : l'équilibrage. Les flux qui entrent et sortent d'un processus doivent se retrouver, ni plus ni moins, dans le diagramme qui le détaille. Si le niveau 1 fait apparaître un flux vers la banque absent du diagramme de contexte, l'un des deux est faux.

Les règles pour construire un DFD valide

Un DFD lisible ne suffit pas : il doit aussi être cohérent. Les règles suivantes, communes aux deux notations, permettent de le vérifier avant de le faire relire.

• Tout flux passe par un processus. Deux entités externes, deux magasins, ou une entité et un magasin ne sont jamais reliés directement : il faut un traitement entre eux.

• Chaque processus a au moins une entrée et une sortie. Un processus qui ne produit rien, ou qui produit sans rien recevoir, signale un oubli.

• Chaque magasin est lu et alimenté. Un magasin que personne ne remplit, ou que personne ne consulte, n'a pas sa place dans le diagramme.

• Chaque flux porte un nom. Une flèche sans libellé ne dit pas quelle donnée circule.

• Les niveaux sont équilibrés. Les flux d'un processus parent se retrouvent dans son diagramme détaillé.

• Le diagramme ne montre que des données. Les déclencheurs, les conditions et les délais relèvent d'un autre type de diagramme.

Les erreurs les plus fréquentes

Comment réaliser un diagramme de flux de données en 6 étapes

La méthode ci-dessous convient à un premier DFD comme à la cartographie d'un système existant. Elle fonctionne aussi bien sur papier qu'avec un outil de diagramme.

1. Définir le périmètre et l'objectif

Précisez le système étudié et la raison du diagramme : migrer un outil, cadrer une intégration, documenter des données personnelles. Le périmètre détermine ce qui est interne (processus, magasins) et ce qui est externe (entités).

2. Lister les entités externes et les données échangées

Recensez les personnes, services et systèmes qui envoient ou reçoivent des informations. Pour chacun, notez les données qu'il fournit et celles qu'il attend. Un simple tableau à deux colonnes suffit à ce stade.

3. Dessiner le diagramme de contexte

Placez le système au centre, sous la forme d'un seul processus, et reliez-le aux entités externes par des flux nommés. Faites valider ce niveau 0 par le sponsor avant d'aller plus loin : une entité oubliée ici le restera dans tous les niveaux.

4. Décomposer en processus principaux

Découpez le système en trois à neuf processus, ajoutez les magasins de données et reliez le tout. Vérifiez que chaque flux du diagramme de contexte arrive bien sur l'un des processus du niveau 1.

5. Vérifier les règles et faire valider par les métiers

Appliquez les règles de cohérence, puis organisez un atelier avec les personnes qui utilisent réellement le système. Quelques questions permettent de faire ressortir les flux oubliés :

• Quelles données saisissez-vous à la main alors qu'elles existent ailleurs ?

• Quels fichiers envoyez-vous ou recevez-vous par e-mail ?

• Que se passe-t-il pour les données quand une demande est refusée ou annulée ?

• Qui consulte ces informations en dehors de votre équipe ?

6. Détailler si nécessaire et tenir le DFD à jour

Ne décomposez au niveau 2 que les processus complexes ou sensibles. Rattachez ensuite le diagramme à la documentation du projet, avec une date de version et un responsable chargé de le mettre à jour quand un flux change.

Exemple de DFD : le remboursement des notes de frais

L'exemple suivant, fictif, décrit le traitement des notes de frais dans une entreprise de taille moyenne. Les tableaux remplacent le schéma : chaque ligne correspond à un élément que vous placeriez sur le diagramme.

Niveau 0 : le diagramme de contexte

Niveau 1 : les processus principaux

Ce que cet exemple révèle

• Une donnée sensible : le processus 4 lit les coordonnées bancaires des salariés dans D3. Ce magasin doit avoir un responsable et des droits d'accès définis.

• Une dépendance externe : le processus 5 attend la confirmation de la banque. En cas de migration, ce flux doit être testé en priorité.

• Une règle à documenter : le contrôle de conformité dépend de D2. Si la politique de dépenses change, le processus 2 change aussi.

DFD, logigramme et diagramme UML : quelles différences ?

En français, l'expression « diagramme de flux » désigne souvent un logigramme, qui décrit des étapes et des décisions, et non des données. Le tableau ci-dessous situe le DFD par rapport aux diagrammes voisins.

Ces diagrammes se complètent. Le DFD fixe les données à faire circuler, le diagramme de séquence précise l'ordre des échanges, et le diagramme de processus décrit le travail des équipes. Pour les autres notations, consultez notre guide du diagramme UML.

Quand utiliser un diagramme de flux de données ?

Le DFD n'est pas réservé aux informaticiens. Il est utile dès qu'un projet modifie la circulation des informations entre des équipes, des outils ou des partenaires.

Cadrer un projet SI ou une intégration

Avant de choisir un outil ou d'écrire des spécifications, le DFD liste les données que le futur système doit recevoir et produire. Il alimente directement le cahier des charges fonctionnel et limite les découvertes tardives en recette.

Préparer une migration ou un changement d'outil

Cartographier l'existant permet de repérer les flux cachés : exports manuels, fichiers envoyés par e-mail, connecteurs oubliés. Chaque flux de l'ancien système doit avoir un équivalent, ou une décision explicite de suppression, dans le nouveau.

Cartographier les flux de données personnelles (RGPD)

Le RGPD impose à la plupart des organisations de tenir un registre des activités de traitement. Un DFD facilite la cartographie des flux de données : chacun de ses éléments correspond à une rubrique du registre.

Analyser les risques de sécurité

Les équipes de sécurité s'appuient sur le DFD pour la modélisation des menaces. Elles y ajoutent des frontières de confiance, là où les données changent de réseau ou de niveau de droits, puis examinent chaque flux qui les traverse.

Du diagramme de flux de données au plan de projet avec Asana

Un DFD validé dit ce qui doit exister. Il reste à organiser le travail pour y parvenir : créer les flux manquants, corriger ceux qui posent problème, faire valider les traitements sensibles. Asana ne remplace pas votre outil de diagramme ; il prend le relais une fois le DFD validé.

Dans l'exemple des notes de frais, le flux vers la banque devient une tâche de test confiée à la trésorerie, dont dépend la bascule. L'accès à D3 fait l'objet d'une approbation du DPO. L'équipe suit l'ensemble sur un diagramme de Gantt, sans recopier le DFD à la main.

FAQ - Diagramme de flux de données

Voici les réponses à trois questions fréquentes sur le diagramme de flux de données.

Diagramme de flux de données : ce qu'il faut retenir

Un diagramme de flux de données décrit le chemin des informations avec quatre symboles : entités externes, processus, magasins et flux. Il se construit par niveaux, du diagramme de contexte aux vues détaillées, et se vérifie avec quelques règles simples, dont l'équilibrage entre niveaux.

Commencez par le contexte, faites valider chaque niveau par les personnes concernées, puis servez-vous du DFD pour organiser le travail : chaque flux à créer ou à corriger devient une tâche, chaque donnée sensible une validation.