Comprendre le cycle de vie des données
Présentation du schéma “Le cycle de vie des données”
Dernière mise à jour
Présentation du schéma “Le cycle de vie des données”
Dernière mise à jour
Source : OpenDataFrance - Licence : CC-BY-SA
Version : v2.0, date : mai 2022
Crédits : Document élaboré avec les partenaires des territoires d’expérimentation dans le cadre du sprint “cycle de vie des données” OpenDataLocale et en particulier les archives du CD83
Le cycle de vie des données présente le processus de production, d’utilisation et de conservation ou destruction des données dans une organisation. Il liste les différentes étapes et les acteurs intervenants. Le cycle de vie des données s’applique à l’ensemble des données des organisations. Il permet de repérer la manière d’utiliser les données en fonction de leurs caractéristiques et de préciser les différents usages des données en fonction de leur spécificité. Il présente les différentes interventions nécessaires tout au long de la vie des données dans et hors de l’organisation.
Il existe un cycle par usage. Une donnée peut donc appartenir à plusieurs cycles de vie.
Le schéma présente les différentes phases du cycle de vie. Il est un outil utile pour diffuser, auprès de tous, la bonne compréhension de la circulation des données au sein d’une organisation ainsi que les bonnes pratiques qui y sont attachées.
La première phase réside dans dans le choix, l’implémentation et/ou le paramétrage de l’application-métier. Ce premier choix est déterminant car il conditionne l’ensemble du processus d’acquisition et de gestion de la donnée. A l’heure de l’ouverture des données, une application qui ne permettrait qu’un export au format pdf, par exemple, compliquerait la tâche de mise à disposition du jeu de données.
Si la donnée est créée au moment où elle est saisie, cette dernière est conditionnée par les choix effectués en amont sur notamment l’application métier, dans les champs des formulaires. Lors de la phase de planification de la gestion des données, certaines décisions sont prises et déterminent la manière dont les données seront structurées. Le paramétrage de l’application métier conduit ainsi à la production de la structure générale de la base de données interne.
Les choix qui sont effectués à cette étape ont des conséquences déterminantes sur le cycle de vie des données : cela a des implications sur la possibilité d’exporter des données et des métadonnées, et sur le choix du/des formats d’export (csv, xml, json...). La qualité des données est clairement un enjeu de cette phase car c’est à ce moment-là que sont définies les règles. L’application doit avant tout répondre aux besoins métiers tout en prenant en compte les besoins techniques et juridiques (archives, CNIL…). C’est à ce stade que la gouvernance est cruciale pour impliquer les personnes concernées et réaliser les bons arbitrages.
La phase d’acquisition de données correspond à la "production" de la donnée.
Les données peuvent être saisies manuellement par un producteur de données (un agent à l’Etat civil, par exemple), ou produites grâce à un capteur (comme lors du comptage du public dans un lieu). Dans le cas d’une captation automatique, représentée par la flèche marquée [1] sur le schéma, on importe des données issues d’une autre application. Les données peuvent donc être récupérées, via des protocoles informatiques, pour limiter la saisie manuelle d’informations existant déjà dans d’autres applications. Cela impose une parfaite correspondance entre l’objet décrit dans chaque champ, le nom et les valeurs possibles de ce champ. Par exemple : dans le cadre d’un marché public, la donnée “identification de l’acheteur” est le SIRET de l’acheteur, elle est donc normée de facto (suite unique de 14 chiffres pour chaque entité), en revanche le “nom de l’acheteur” doit être normalisé en définissant la règle de nommage à utiliser (Par exemple, on a le choix entre Conseil Départemental du Tarn, Département du Tarn, CD Tarn, CD81...). Il est possible de définir les caractères autorisés (majuscules en début de mot ou pour la totalité du mot, minuscules pour toute ou partie du mot, accents, etc.). L’arrêté du 14 avril 2017 relatif aux données essentielles dans la commande publique est un bon exemple de normalisation des données. C'est la question de la standardisation. A ce stade du cycle, il est fondamental que la saisie des données soit guidée. Car la saisie sans contrainte a une forte incidence sur l'hétérogénéité et la complétude, donc sur la qualité. La préparation de la phase de production, via du paramétrage et de la formation, est donc capitale pour la suite du cycle.
Dans cette phase T3, iI s’agit de travailler à la validation-métier, sur le “fond”, de la donnée. Les étapes précédentes garantissent la validation sur la forme. Et ce n'est qu'à l'issue de cette phase de validation que la donnée est considérée fiable : elle peut alors être utilisée par le métier, partagée au sein de la collectivité et publiée en ligne à destination des citoyens et des organisations. L’exemple du budget est intéressant : dans une collectivité, chaque entité ou service fait sa demande de budget ; cette demande fait l’objet d’un arbitrage et les montants attribués peuvent être modifiés avant validation. La validation formalise le moment où la donnée correspond à une réalité, à une décision de la collectivité et où elle peut être publiée. Il est important que les outils permettent de figer les données une fois validées afin de garantir la fiabilité et la pérennité.
Le format des données dans la base métier peut ne pas être le même que le format d’export défini pour l’open data. Ce qui est important, c’est que la donnée disponible comporte toutes les informations nécessaires à son formatage open data : éléments nécessaires pour codifier une date, une entité juridique (SIRENE), une adresse ou une localisation (format de projection et niveau de précision), etc.
Juste après la validation, les données peuvent donc être utilisées par d’autres applications-métiers ou être publiées en ligne. Ici, il y a deux branches pour illustrer la diversité des usages :
La publication en open data qui consiste à donner un accès à des fichiers contenant des copies des données sur des sites web (ou portail) avec une licence (la Licence Ouverte ou Licence OdBL). Pour rendre en rendre l'exploitation possible, il est important que les données soient clairement présentées et documentées (métadonnées) et que les fichiers soient lisibles par des machines, dans des formats non propriétaires. Rappelons que la mise en ligne des données est une obligation pour les collectivités de plus de 3500 habitants et 50 agents (ETP) depuis la loi pour une république numérique, dite Loi Lemaire.
L'utilisation par une autre application : dans cette hypothèse, les données correspondent aux besoins de cette application ce qui impose, sur le fond, d’assurer la fiabilité, l’exhaustivité et la fraîcheur des données afin d’éviter de fausser les données de l’application de “destination”. Sur la forme, une standardisation sera la garantie d'une interopérabilité entre les deux applications et assurera qualité et homogénéité.
Pour être possible et facile à mettre en place, il est préférable de prévoir et d’anticiper cette phase de mise à disposition en vue de la réutilisation.
Le numérique laisse penser que tout peut être entreposé et gardé dans les serveurs informatiques sans limite de temps. Or, on ne peut pas tout conserver! Comme dans l’univers du papier, il faut savoir faire un tri. Ce tri consiste à faire le choix de conserver ou détruire certaines données. Il y a des lois qui encadrent la durée de conservation et qui définissent si les données doivent être détruites ou conservées définitivement. Cela dépend de la valeur des données :
la valeur juridique (combien de temps ai-je besoin de conserver pour prouver un délit ou, plus largement, prouver les actes),
la valeur informationnelle (pendant combien de temps ai-je besoin de l’information pour travailler),
la valeur patrimoniale (quand il n’y a plus de valeur juridique ou informationnelle, on l’évalue sous l’angle de la valeur patrimoniale : il est possible d’identifier intérêt pour l’histoire).
Point de vigilance : il peut être intéressant d’avoir réalisé le travail de recensement et d’évaluation de cette fin de cycle (conservation ou destruction) le plus en amont possible. En effet, dans l’environnement numérique, il est beaucoup plus difficile, voire impossible, de réaliser les actions d’“archives” si cela n’a pas été prévu en amont. Associer des compétences expertes sur cette dimension (archivistes) est essentiel.
NB : Les données publiées en open data sont généralement des copies (extrait, normalisation, agrégation) de données-métier. Les données-métier possèdent une logique d’archivage propre, établie en concertation entre les métiers, les archives et la DSI. A priori, il n’y a pas de nécessité absolu pour les données publiées en open data d'être archivées. Cependant, cette pratique est utile si l’on veut conserver l’historique et le contenu des données publiées à un moment donné. Cette décision doit être prise en concertation avec le service des Archives qui décidera de son intérêt juridique, opérationnel ou historique et de son coût.
Nombreux sont les acteurs, agents ou usagers de service public, qui jouent un rôle dans la production, la circulation et l'utilisation de la donnée. L’open data révèle l’importance de la gestion de la donnée (ou de sa gouvernance) durant tout son cycle de vie. Cela a des impacts fonctionnels et techniques mais également organisationnelle. L’amélioration des processus de gestion des données apporte des bénéfices importants à la collectivité dans la maîtrise de son patrimoine informationnel. Cela profite à tous et l’ouverture des données s’en trouve largement facilitée.
Le procédé de vérification et de contrôle qualité est nécessaire pour s’assurer de la fiabilité des données. Il peut prendre la forme de contrôles automatiques ou manuels (c’est pourquoi les procédures de la première phase doivent être réalisées avec précision et de façon exhaustive). Par exemple, dans le cas d’utilisateurs devant saisir manuellement des champs normalisés (tel qu’une date), une application bien paramétrée contraindra la saisie (le champ se présentera sous la forme de date définie : jj/mm/aaaa) ; à l’opposé, une application moins performante nécessitera un contrôle humain. Les phases et T2 peuvent se répéter tant que la donnée n’est pas prête à être validée. La procédure-métier peut nécessiter des modifications, des traitements, des corrections ou des enrichissements.
