Kit de ressources (old)
  • Description des ressources
  • 10 commandements de l'ouverture des données publiques
  • Fiches pratiques
    • Premiers pas
      • Comprendre le cycle de vie des données
      • Les données prioritaires
      • Préparer les données pour une publication en open data
      • Comment publier en open data en présence de données à caractère personnel
      • Documenter les données avant publication
      • Produire un fichier CSV de qualité
      • Choisir un portail open data
      • Comment publier un jeu de données sur data.gouv.fr
      • Comment afficher sur son site web des données publiées sur data.gouv.fr
    • Aspects juridiques
      • Choix des licences open data
      • Clauses à insérer dans les marchés publics
      • Guide pédagogique RGPD
      • Exemple de délibération en vue du lancement d’un projet open data dans une commune
      • Inventaire des lois en rapport avec l'open data
      • Foire aux questions sur la licence ODbL
      • Mentions légales pour un portail open data
    • Animations territoriales
      • Dataposition Agent/Elu
      • Identifier les collectivités de son périmètre d'intervention
      • Convention d'accompagnement
  • Exemple de documents
    • Cahiers de Charge AMO Data
    • Consultation pour un portail OpenData
    • Fiche de poste Chef de projet Data
  • Références
    • Prestataires Conseil en opendata
  • Fiches pédagogiques
    • Pour comprendre
      • Définition : les données
      • Les données ayant un caractère particulier
      • Définition : Les données ouvertes
      • Le glossaire de la donnée
      • Les acteurs publics nationaux de l’ouverture des données
      • Les acteurs associatifs de l’ouverture des données
      • Les acteurs économiques de l’ouverture des données
      • Les acteurs publics territoriaux de l’ouverture des données
      • Les métiers autour des données
    • Pour agir
      • Ouvrir les données pour la démocratie
      • Ouvrir les données pour la modernisation de l’action publique
      • Ouvrir les données pour l’innovation économique
      • Ouvrir les données : une obligation légale
      • Les premières étapes pour s’engager dans une démarche d’ouverture des données
      • Dispositifs de publication des données en open data
    • Pour animer
      • Les réutilisations de données
      • Les tiers-lieux et acteurs de la médiation numérique
      • Autres formats d’animation de l’ouverture des données
      • Hackathon
      • Infolab
      • Cartopartie
      • Animation territoriale Open data
      • Transparence, Concertation, Observatoire
    • A revoir
      • Recommandations pour favoriser l'interopérabilité des données open data
      • Jeux de données des communes les plus fréquemment ouverts
  • Supports de formation
    • L'ouverture des données publiques pour et par les collectivités territoriales
    • Archives
      • Comprendre l'open data
      • Mener un projet d'ouverture de données dans ma collectivité
  • Jeux sérieux
    • Les explorateurs des données territoriales
    • Belle Colline
    • Datopolis
  • Formations en ligne
    • Webinaires DCANT
      • Webinaire DCANT #5 - Comment mettre en œuvre l'open data dans les territoires
      • Webinaire DCANT #10 - RGPD et collectivités territoriales
      • Webinaire DCANT #13 - Moissonnage des données territoriales sur datagouv
    • L'open data et vous (CEREMA/CNFPT/ODF)
    • Programme e-Learning du Portail Européen de Données
    • Webinaire "La data dans les territoires"
  • Ressources complémentaires
    • Fiches OpenDataLab (Occitanie)
    • Etude Cycle de la donnée et transformation du SI (FNCCR)
    • Guide pratique opendata du ministère de la culture
    • Infolab.io (Fing)
    • Open Data Canvas
    • 1, 2, 3 data, expérimenter !
  • Vidéos pédagogiques tierces
    • Le b.a.-ba de la donnée
    • L'open data à la loupe
    • Grand Lyon Data
    • Open data et secteur public
  • RGPD - Protection des données personnelles
    • L'atelier RGPD de la CNIL
    • Kit RGPD de Mégalis Bretagne
  • Espace ressources partenaires
    • INET
Powered by GitBook
On this page
  • Définition
  • Le schéma du cycle de vie des données
  • Explication “phase par phase”
  • T0 : Planification de la gestion des données
  • T1 : Acquisition de données
  • T2 : Vérification - contrôle qualité des données
  • T3 : Validation des données
  • T4 : La réutilisation
  • T5 : archives et tri des données
  • 4 - Conclusion
  1. Fiches pratiques
  2. Premiers pas

Comprendre le cycle de vie des données

Présentation du schéma “Le cycle de vie des données”

PreviousPremiers pasNextLes données prioritaires

Last updated 6 years ago

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

Définition

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 du cycle de vie des données

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.

Explication “phase par phase”

T0 : Planification de la gestion des données

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.

T1 : Acquisition de données

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.

T2 : Vérification - contrôle qualité des données

T3 : Validation des données

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.

T4 : La réutilisation

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.

    • 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.

T5 : archives et tri des données

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.

4 - Conclusion

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.

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 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.

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 . Il est dès lors essentiel que les données correspondent aux besoins dans l’autre application :

T1
T1
https://frama.link/cycle_de_vie_donnees