Comprendre le cycle de vie des données
Présentation du schéma “Le cycle de vie des données”
Last updated
Présentation du schéma “Le cycle de vie des données”
Last updated
Source : ODF, version : V1.1, date : 20 déc. 18, Licence : CC-BY-SA
Historique des modifications : 1.0 : version initiale (jan.18) 1.1 : diverses corrections (suppression -NC dans licence, références url)
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 et d’utilisation des données dans une organisation : il décrit ce processus de la création des données dans les systèmes d’information, à leur publication et à leur réutilisation. 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.
Le schéma présente les différentes phases du cycle de vie. Il vise la compréhension de la circulation des données au sein d’une administration et souligne le fait que les données sont retravaillées tout au long de leur parcours.
La première phase consiste dans le choix, l’implémentation et/ou le paramétrage de l’application-métier, et elle se termine par la planification de la gestion des données (et notamment l’archivage). Elle implique souvent la Direction des Systèmes d’Information en relation avec le métier qui a besoin des 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 premier choix déterminant concerne l’application-métier, 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 permet qu’un export au format pdf compliquera la tâche de mise à disposition du jeu de données. Ensuite, le paramétrage de l’application métier conduit à la production de la structure générale de la base de données interne.
Les outils du SI contraignent la structuration des données. Par exemple : le nommage des champ, leur présence (obligatoire ou pas), le format et la codification de ces champs
Les choix qui sont effectués à ce moment-là 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.
C’est lors de la phase d’acquisition de donnée, que la donnée est produite : cela correspond à la phase où on remplit un formulaire manuellement (en ligne ou sur papier). Ce formulaire peut être dans une application métier. On peut aussi réaliser un relevé automatisé et systématique de données (ex. : comptage des voitures sur la voirie). A ce stade, les données ne peuvent pas être saisies n’importe comment. La saisie des données est guidée par l’intitulé des champs du formulaire, et parfois même par le format de la cellule. Peut-être vous êtes vous déjà posé cette question : Comment ça se fait que je ne peux écrire que des chiffres dans cette cellule? Pourquoi on saisit une date dans un format imposé ? A contrario, si vous pouvez saisir sans contrainte, à votre avis, est-ce bon signe sur la qualité des données qui seront produites? Les questions qui se posent lors de la planification se déclinent au moment de la saisie et de la production des données.
Les données sont soit saisies manuellement par un producteur de données (un agent à l’Etat civil, par exemple), soit 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 dans la base dont nous étudions le cycle de vie en T1. Les données peuvent donc être amenées à dialoguer avec d’autres données pour limiter la saisie manuelle d’informations existant déjà dans d’autres applications. Cela impose une 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.
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 bénéficier de plusieurs formes 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 T1 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.
Dans cette phase 3, iI s’agit de travailler à la validation-métier, sur le “fond”, de la donnée. Les étapes précédentes en garantissent la validation sur la forme. A partir de ce moment, la donnée est fiable : elle peut ê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 à ce stade que les outils permettent de figer les données une fois validées (sauf besoin contraire qui nécessite 2 ou 3 temps de validation en fonction de la procédure) afin d’en garantir la fiabilité et d’en assurer la pérennité. Le format des données dans la base 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 opendata : é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 ê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 partie open data : la publication des données publiques consiste à donner 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 qu’ils puissent être réutilisés, il est important que les données soient clairement présentées et documentées et que les fichiers soient lisibles par des machines. La mise en ligne des données est une obligation pour les collectivités de plus de 3500 habitants et les administrations de plus de 50 agents depuis la loi pour une république numérique, dite Loi Lemaire.
partie utilisation par une autre application : Les données peuvent être transférées dans une autre base, comme le montre la flèche [1] sur le schéma et comme cela a été dit en T1. Il est dès lors essentiel que les données correspondent aux besoins dans l’autre application :
sur le fond : il est nécessaire d’assurer la fiabilité, l’exhaustivité et la ponctualité des données afin d’éviter de fausser les données de l’application de “destination”.
sur la forme : qualité et homogénéité afin de garantir l’interopérabilité entre les deux applications.
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 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.
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 soient 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.
Nombreux sont les sujets, agents ou usagers de service public, qui jouent un rôle dans la formation et la circulation 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 comme de nombreux acteurs sont concernés, cela a aussi des conséquence 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 les agents et décideurs dans leur mission courante et l’ouverture des données s’en trouve largement facilitée.
