Cartographie des flux de données : méthode et outils pour les projets SI institutionnels
- Ce qu’est une cartographie des flux de données et pourquoi elle précède toute décision SI
- La méthode utilisée dans les projets institutionnels en santé et finance
- Les outils adaptés selon la complexité du périmètre
Pourquoi cartographier les flux de données
Une donnée qui entre dans un système institutionnel ne reste pas dans ce système. Elle est transmise à d’autres applications, transformée par des traitements intermédiaires, agrégée avec d’autres sources, exportée vers des outils de reporting. Cette circulation est rarement documentée formellement, ce qui crée des angles morts majeurs dans les projets de transformation SI.
Quand une institution décide de remplacer un système ou d’en ajouter un nouveau, les équipes IT connaissent généralement les interfaces documentées. Elles ne connaissent pas toujours les flux informels : les exports manuels planifiés par des scripts non documentés, les alimentations de tableurs partagés par des collaborateurs qui ont quitté l’organisation, les dépendances entre systèmes qui n’ont jamais été formalisées.
Modifier un système sans avoir cartographié ces flux peut produire des interruptions de service dans des processus apparemment sans lien avec le projet. C’est l’une des causes les plus fréquentes de dérapage dans les projets SI institutionnels.
Règle fondamentale : La cartographie des flux de données doit précéder la rédaction de toute spécification technique d’interface. On ne peut pas spécifier correctement comment des systèmes doivent communiquer si on n’a pas documenté comment ils communiquent actuellement.
Les trois niveaux de cartographie
Niveau 1 : la cartographie fonctionnelle
Elle représente les flux de données du point de vue des processus métier : quelle information part de quel service, vers quel autre service, pour quelle finalité. C’est la cartographie que comprennent les directions métier et les DSI. Elle est produite lors des entretiens avec les parties prenantes et complétée par l’observation des pratiques réelles. Son format habituel est un diagramme de flux simplifié ou une matrice origine-destination.
Niveau 2 : la cartographie technique
Elle représente les flux au niveau des systèmes et des interfaces : quel système alimente quel autre système, selon quel protocole, à quelle fréquence, avec quel volume de données. C’est la cartographie que produisent et lisent les équipes IT. Elle est construite à partir de l’analyse de l’architecture existante, des logs de transfert et des interviews techniques. Son format habituel est un diagramme d’architecture ou un catalogue d’interfaces.
Niveau 3 : la cartographie de la qualité des données
Elle documente l’état des données à chaque étape du flux : taux de complétude, cohérence avec les référentiels, fréquence des anomalies détectées. C’est la cartographie la plus révélatrice et la moins souvent produite. Elle est construite par analyse statistique des données existantes. Son format habituel est un rapport de qualité par flux ou par champ de données.
En pratique : Dans un projet de refonte du SI d’un hôpital universitaire suisse, la cartographie de niveau 3 a révélé que 31% des enregistrements patients avaient au moins un champ identifiant incohérent entre le système de gestion des admissions et le système de gestion des soins. Cette incohérence, invisible depuis la cartographie de niveau 1, aurait compromis la fiabilité de tous les indicateurs de pilotage du futur système.
Méthode : comment conduire une cartographie des flux
- Définir le périmètre : quels systèmes, quels services, quelles catégories de données sont dans le scope. Une cartographie exhaustive de tout le SI d’une grande institution n’est pas réaliste dans un délai de projet raisonnable. Il faut prioriser les flux les plus critiques.
- Conduire les entretiens métier : identifier avec chaque service quelles données il produit, quelles données il consomme, et comment il les obtient dans la pratique. Les réponses sur « comment dans la pratique » sont souvent différentes des réponses sur « comment selon le processus officiel ».
- Analyser la couche technique : croiser les informations des entretiens avec l’analyse de l’architecture existante, les journaux de transfert et les configurations des interfaces. Cette étape révèle les flux qui n’ont pas été mentionnés lors des entretiens.
- Qualifier la qualité des données : pour les flux critiques, analyser un échantillon de données réelles pour évaluer leur complétude, leur cohérence et leur fiabilité.
- Produire la documentation : un catalogue des flux avec pour chaque flux : systèmes source et destination, fréquence, volume, format, responsable, contraintes de qualité et de conformité.
Les outils adaptés selon le contexte
| Outil | Usage | Adapté pour |
|---|---|---|
| Swimlane / BPMN | Cartographie fonctionnelle des processus et flux métier | Entretiens parties prenantes, documentation processus |
| Lucidchart / draw.io | Diagrammes d’architecture et flux techniques | Documentation IT, revues d’architecture |
| SQL / Python | Analyse de qualité des données sur les bases existantes | Audit qualité données, détection d’anomalies |
| Excel / matrice | Catalogue des interfaces et référentiel des flux | Documentation de référence, partage avec non-techniciens |
| Confluence / SharePoint | Documentation centralisée et versionnée | Projets multi-équipes, documentation long terme |
Point d’attention : Le choix de l’outil est secondaire. Une cartographie rigoureuse conduite avec des post-its et de la rigueur analytique vaut plus qu’une cartographie superficielle produite avec un outil sophistiqué. La qualité dépend de la méthode d’investigation, pas de l’outil de représentation.
Questions fréquentes
La cartographie des flux est-elle différente de la cartographie des processus ?
Les deux sont complémentaires mais distinctes. La cartographie des processus décrit comment le travail est organisé et exécuté. La cartographie des flux de données décrit comment les informations circulent entre les systèmes et les services. Dans un projet SI, les deux sont nécessaires : la première pour comprendre les besoins fonctionnels, la seconde pour comprendre les contraintes d’architecture et de qualité des données.
Combien de temps faut-il pour cartographier les flux d’un SI institutionnel ?
Entre une et quatre semaines selon le périmètre. La phase d’entretiens métier est généralement la plus longue, car elle dépend de la disponibilité des parties prenantes. L’analyse technique peut être parallélisée avec les entretiens si l’équipe IT est disponible simultanément.
Qui est responsable de maintenir la cartographie à jour après le projet ?
C’est une question de gouvernance qui doit être tranchée avant la fin du projet, pas après. Idéalement, chaque flux a un responsable désigné côté métier et un responsable technique côté IT. La cartographie est mise à jour à chaque modification d’interface ou de processus. Sans propriétaire désigné, elle sera obsolète dans les six mois suivant le déploiement.
La cartographie des flux est-elle requise pour les projets de conformité LPD ?
Oui. Le registre des traitements exigé par la LPD nécessite une connaissance précise de quelles données personnelles sont traitées, par quels systèmes, dans quels flux. La cartographie des flux de données fournit la base factuelle nécessaire à la construction de ce registre. Les deux démarches sont complémentaires et peuvent être conduites simultanément.
Vos flux de données ne sont pas documentés ?
C’est le point de départ de la plupart des projets de transformation SI. Un premier échange permet d’évaluer le périmètre et la méthode appropriés à votre situation.
Prendre rendez-vous
