Flux de données¶

Comprendre d'ou viennent les données, ou elles vont, et quelles transformations elles subissent en chemin.

Pourquoi modéliser les flux¶

Les diagrammes de composants montrent ce qui existe. Les diagrammes de sequence montrent ce qui se passe pour un scenario. Mais ni l'un ni l'autre ne répondent a une question simple : comment les données traversent-elles le système ?

Un DFD (Data Flow Diagram) répond a cette question. Il montre les sources de données, les transformations, les stockages et les destinations. C'est un outil d'analyse indispensable dans trois contextes :

1. Comprehension d'un SI existant : quand on hérité d'un système, le DFD est la première carte qu'on dessine. Il révélé les flux implicites, les copies cachees, les transformations non documentees.
2. Conception d'un nouveau système : avant d'implémenter, on trace les flux pour vérifier que chaque donnée a une source et une destination.
3. Analyse de sécurité : le threat modeling (STRIDE, PASTA) utilise les DFD pour identifier les frontieres de confiance et les points d'attaque.

Éléments d'un DFD¶

Le DFD utilise une notation volontairement simple — quatre éléments seulement.

Règles fondamentales¶

• Un processus doit avoir au moins une entree et une sortie.
• Un data store ne produit pas de données spontanement — un processus doit les lire.
• Une entité externe est hors du périmètre du système — on ne la contrôle pas.
• Les flux sont toujours etiquetes — un flux sans nom est un flux mal compris.

Niveaux de DFD¶

Les DFD se decomposent en niveaux de détail croissant. Chaque niveau zoome dans un processus du niveau supérieur.

Niveau 0 — Diagramme de contexte¶

Le niveau 0 montre le système comme une seule boite noire, entoure de ses entités externes. Il répond a : "quelles données entrent et sortent du système ?"

graph LR
    CLI[Client] --"commande"--> SYS((Plateforme e-commerce))
    SYS --"confirmation, facture"--> CLI

    FOUR[Fournisseur] --"catalogue produits"--> SYS
    SYS --"bons de commande"--> FOUR

    BANK[Banque] --"confirmation paiement"--> SYS
    SYS --"demande de debit"--> BANK

    TRANS[Transporteur] --"statut livraison"--> SYS
    SYS --"demande d'expedition"--> TRANS

    FISC[Administration fiscale] --"reglementations"--> SYS
    SYS --"declarations TVA"--> FISC

Niveau 1 — Decomposition principale¶

Le niveau 1 eclate le système en processus principaux et montre les data stores.

graph TD
    CLI[Client] --"commande"--> P1((Gerer les commandes))
    P1 --"confirmation"--> CLI

    P1 --"articles commandes"--> P2((Gerer le stock))
    FOUR[Fournisseur] --"catalogue"--> P2

    P1 --"montant a debiter"--> P3((Traiter le paiement))
    BANK[Banque] --"confirmation"--> P3
    P3 --"demande debit"--> BANK
    P3 --"paiement valide"--> P1

    P1 --"colis a expedier"--> P4((Gerer la livraison))
    TRANS[Transporteur] --"statut"--> P4
    P4 --"demande expedition"--> TRANS
    P4 --"statut livraison"--> P1

    P1 --"donnees commande"--> D1[(Base commandes)]
    D1 --"historique"--> P1
    P2 --"niveaux stock"--> D2[(Base stock)]
    D2 --"disponibilite"--> P2
    P3 --"transactions"--> D3[(Base paiements)]

Niveau 2 — Détail d'un processus¶

Le niveau 2 decompose un processus du niveau 1. Par exemple, "Gérer les commandes" se decompose en : valider la commande, calculer le total, vérifier le stock, confirmer au client.

DFD vs diagramme d'activité vs BPMN¶

Les trois notations peuvent représenter des processus, mais avec des perspectives différentes.

La règle : si la question est "ou vont les données", on utilise un DFD. Si la question est "dans quel ordre les étapes s'enchainent", on utilise un diagramme d'activité ou BPMN.

Data mapping¶

Le data mapping complète le DFD en repondant a trois questions pour chaque donnée :

1. D'ou vient-elle ? (source)
2. Ou va-t-elle ? (destination)
3. Quelle transformation subit-elle ? (règle de mapping)

Matrice de data mapping¶

Pourquoi le data mapping est critique¶

Le data mapping révélé les problèmes que les autres diagrammes masquent :

• Données sans source : d'ou vient cette information ? Personne ne sait. C'est souvent une saisie manuelle cachee ou un défaut de conception.
• Transformations implicites : le prix HT devient TTC "quelque part". Ou exactement ? Qui est responsable du calcul ? Avec quelle règle de TVA ?
• Copies multiples : la même donnée existe dans trois bases différentes. Laquelle fait référence ? Comment les synchroniser ?
• Formats incompatibles : le système source envoie une date en ISO 8601, le système cible attend un timestamp Unix. La conversion est-elle documentee ?

Flux entre zones de confiance¶

Le DFD est l'outil de base du threat modeling. En ajoutant des frontieres de confiance au DFD, on identifie les points ou les données passent d'une zone protégée a une zone non protégée — et vice versa.

Zones de confiance typiques¶

Identifier les menaces aux frontieres¶

Chaque flux qui traverse une frontiere de confiance est un point d'attaque potentiel.

graph TD
    subgraph "Zone : Internet public"
        CLI[Client navigateur]
    end

    subgraph "Zone : DMZ"
        WAF[WAF / Reverse proxy]
        GW[API Gateway]
    end

    subgraph "Zone : Reseau interne"
        SVC[Services metier]
    end

    subgraph "Zone : Donnees"
        DB[(Base de donnees)]
        SEC[Secrets manager]
    end

    CLI --"HTTPS"--> WAF
    WAF --"HTTP interne"--> GW
    GW --"gRPC / mTLS"--> SVC
    SVC --"SQL / TLS"--> DB
    SVC --"API"--> SEC

À chaque frontiere traversee, on appliqué STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) pour identifier les menaces. Le chapitre sécurité (08) détaillé cette méthode.

Cartographier les flux d'un SI existant¶

La cartographie des flux est souvent le premier travail quand on hérité d'un SI existant. Voici une méthode pragmatique en cinq étapes.

Méthode de cartographie¶

Signaux d'alerte¶

Pendant la cartographie, certains patterns révèlent des problèmes structurels :

• Flux en etoile : un système central par lequel tout transite — point de défaillance unique
• Boucles de données : A envoie a B qui envoie a C qui envoie a A — la source de vérité est perdue
• Flux sans propriétaire : personne ne sait qui maintient cette intégration — elle cassera sans que personne ne s'en rende compte
• Copies fantomes : des exports CSV/Excel que des équipes copient manuellement dans d'autres systèmes — shadow IT des données

Quand utiliser un DFD¶

Le DFD n'est pas toujours le bon outil. Voici un guide de décision rapide.

Erreurs classiques¶

Chapitre suivant : Du modèle au code — traçabilité, génération de code, reverse engineering et la question des modèles vivants vs jetables.