Just like cabinetmakers, blacksmiths and stone masons, statisticians work with raw, imperfect materials, full of knots and flaws. They use their own tools and methods to polish, assemble and shape them. These materials that they work with and contribute to creating are data. Data swarm and spring up everywhere, ceaselessly, and in all areas of life, seeming to present a fantastic opportunity for all artisans in the field. However, they are strange, abundant and incredibly heterogeneous materials: they give the appearance of being easily accessible, yet they elude us and resist attempts to give them an operational definition. Everyone has their own perception of data and the idea of restoring the neutrality of the observer is not to be taken lightly. The aim of this article is to equip you with the tools to better understand data and to see the impact that the proposed characterisations have on a statistician’s work.

A priori, it goes without saying that there is a link between statistics and data: “Statistics is the discipline that concerns the [study of phenomena through the] collection, organisation, analysis, interpretation, and presentation of data [in a way that makes them understandable to all].”

However, it may also be of interest to look further back in time. A close look at the classic literature on the role of the statistician (Ouvrir dans un nouvel ongletVolle, 1980), or at the many courses in mathematical statistics, reveals that the word “data”, while unquestionably present, plays less of a central role than one might imagine. There is often talk of results of experiments: the concept of experimentation, in this case random, plays a central role in another discipline, namely probability, which is already known to have strong links to the discipline of statistics. Another term that comes up frequently is observations. We think of statistical data as being the results of observations regarding defined variables and the subsequent treatments applied to them. This implies the use of an entire arsenal of means of observation, via a scientific experiment (in the field of epidemiology, for example), or via a survey, among other possibilities.

Admittedly, official statisticians have been venturing beyond this framework for decades, making use of administrative data (typically DADS). However, in some respects, the reporting process has many points in common with the survey process: by bending the concept a little, one could consider that the administrative reports form part of an observation process, even though they are produced for routine operations (Rivière, 2018).

Since the turn of the millennium and particularly over the last ten years or so, there has been a significant paradigm shift: it is no longer down to the statistician alone to build their own data acquisition process, as there are now multiple data sources in the world, whether they be fully open (open data), open subject to conditions (data accessible by researchers), via agreements, or even open in various forms in return for payment. They therefore potentially have access to a very rich array of materials. However, they have no knowledge of how those materials were drawn up and, in particular, there is no guarantee that they are the result of an observational approach.

However, acts such as conducting a survey or a scientific experiment, or organising a reporting process give a very specific and indeed biased view of what data can be. In each of these situations, it is almost like taking a snapshot of a moment in time by examining the current situation, either through questioning or by using sensors to probe the physical world. Observation is a specific method of collecting data, but it is not the only possible means of doing so. If the available data are the result of another approach, the statistician must be aware of this in order to avoid errors when converting the materials or when interpreting the results.

All of this forces us to rethink our understanding of the many facets of the word “data”.

Characterising the concept of data is made all the more delicate by the fact that many of the works on the subject of data simply avoid the issue of its definition. Its etymology provides an original starting point: datum and its plural data come from the Latin dare, which means “to give”. In Howard Becker’s opinion, the choice of this word was an accident of history (Becker, 1952): rather than pointing to “what has been given” to scientists by nature, the focus should have been on what scientists chose to take, the selections that they made from all of the potential data. In order to capture the partial and selective nature inherent in data, it would have been better to choose captum rather than datum.

Let’s try the dictionaries. Here we find several, rather disparate explanations:

The usual definitions therefore vary between the status, function, origin and representation of data.

From among the literature on databases, we can cite (Elmasri and Navathe, 2016), a reference work that briefly and incidentally defines the concept: “By data, we mean known facts that can be recorded and that have implicit meaning”. In this case, the medium and the importance of semantics are highlighted, and we also come across the idea of fact.

(Borgman, 2015) studies the subject in greater depth and arrives at the following definition: “[...] data are representations of observations, objects or other entities used as evidence of phenomena for the purposes of research or scholarship”. Here, we find the idea of representing reality (used to define information) and it is interesting to note that this is not simply limited to observations. The words “entity” and “object” appear, with entity subsequently being defined by the author as “something that actually exists”, physically or digitally. However, we are looking here at use in an academic context.

(Kitchin, 2014) dedicated an entire chapter to exploring the word “data”. He explains, for example, the “matter” from which data are made: they are abstract, discrete, aggregable and have a meaning that is independent of their format, medium or context. He also draws a key distinction between fact and data: if a fact is incorrect, it is no longer a fact; however, if data are incorrect, they are still data. Therefore, data are what exists prior to the interpretation that transforms them into facts, evidence and information (Box 1).

More generally, it is possible to build a pyramid: data > information > knowledge > wisdom (Figure 1), where each layer precedes the next and is deduced from the previous by means of a “distillation process” (abstract, organise, analyse, interpret, etc.), which adds meaning and organisation and reveals connections. This quotation from (Weinberger, 2012) allows us to visualise this: “Information is to data what wine is to the vine”), together with the quotation from (Escarpit, 1991): “To inform is to give form”.

Figure 1. Knowledge Value Chain

One of the difficulties posed by the concept of data is that it involves two very distinct subjects at the same time: on the one hand there is the value (number, code, character string) that can be found on any medium, together with a certain means of presentation and, on the other hand, there is the status of that value, its semantics, what it is supposed to represent. This means mixing operational concerns with more abstract considerations.

If we assimilate data to value, we immediately come up against a contradiction. When we find the number 324 in a file, what are we talking about? The height of the Eiffel Tower in metres? The area of a field in hectares? The melting point of a metal in degrees Celsius? The maximum speed of a vehicle in km/h? The number of inhabitants in a village?

Taken in isolation, the line “324; 3; 1889” is nothing but a string of characters, devoid of any meaning. At best it is a sequence of three numbers separated by semicolons, but it is absolutely not data. The simple fact of specifying that these are the characteristics of the Eiffel Tower, namely its height, number of levels and the year of its inauguration, changes everything and completely changes the status of this insignificant series of figures: intuitively, they are indeed data. The notion of data is therefore inseparable from the concept to which it refers. It also depends on other aspects such as the unit of measurement in this case.

All this naturally leads us to a definition that is often cited, particularly in the literature on data quality (Olson, 2003; Loshin, 2010; Berti-Équille, 2012; Sadiq, 2013). In one of the first major works on the subject, Redman analyses several known definitions and searches for the most appropriate using the following criteria: three linguistic criteria (clarity, correspondence with common usage, absence of mention of the word “information”) and three usage criteria (applicability, possibility of introducing a quality dimension, consideration of the elements of concept and representation) (Redman, 1996).

This process led him to a definition that is well known among computer scientists: data is defined as a triplet (entity, attribute, value), the entity being a model of real world objects (physical or abstract), the attribute being characterised by a set of possible values, or domain. Due to the importance of this last point, we will make a slight change to the wording of the definition proposed by Redman, while remaining true to the initial logic, by suggesting that data be defined by means of the following triplet:

We will now try to follow the thread of each of these dimensions in order to better understand certain specificities of the concept of data, particularly when it comes to statistical use.

The concept is nothing more than the supposed meaning of data, what it is supposed to represent, how it can be represented by a definition. Here are a few examples: the area of a field, the turnover of a company, the profession of an employee, but also the size of a monument, the make of a vehicle, the value of a share on the stock market, the number of goals scored by a player, the risk rating of a client, a patient’s diagnosis, etc. At INSEE, definitions such as these are centralised within the RMéS repository (Bonnans, 2019).

These examples serve to verify that the concept is always defined as a specific attribute of an entity or object. In official statistics, in the case of a traditional survey approach or the processing of administrative reports, the entity in question is often an individual (or a household) or a company, but it could also be a dwelling, a construction site, a hospital stay or a school. And in the wording of the concept itself, there is often a tendency to remove the reference to the object, as it is self-evident.

We should add that, strictly speaking, data does not refer to an object in general, but to a given object or entity: what would make sense would be if it were the very precise area of a field, the profession of an identified person, the number of goals scored by a given player, the turnover of such-and-such a company.

The attribute also needs to be specified, particularly in terms of time: the profession on such-and-such a date, the number of goals scored in such-and-such a season, the turnover in such-and-such a year, etc. An object can have many attributes, but some of them play a specific role: identifying traits. These are the attributes that allow the object to be unambiguously identified, and therefore allow instances to be distinguished from one another: the things that naturally come to mind are surname, first name and date of birth in the case of an individual; the address in the case of an establishment; for a hospital stay, it could be the date of admission, the identifier of the medical establishment and the identifier of the individual. One of the features of identifying traits is that they are either irremovable (date of birth) or rarely changed (address).

But let’s return to the objects. Cases where individuals or companies are involved present undeniable advantages that we do not always consider:

Conversely, data likely to be obtained from other sources may refer to objects that are more difficult to understand, as they require inside information: the telephone line, the bank account, the electricity meter. They can even relate to volatile objects: data such as the amount of a transaction or the date of a traffic accident refer to objects (transaction, accident) that are associated with an event and that therefore do not have any temporal consistency.

As a result, there is no reference population for certain types of object that would provide a degree of stability and allow for macroscopic comparisons, consistency checks or margin calibration: for example, it is not easy to draw upon a repository of accidents or transactions to compare with a known total, or establish a framework or a limit. In the case of telephone lines and bank accounts, the operators have this information, but are under no obligation to share it. Furthermore, a statistician or data scientist must be able to work backwards to find entities that are of use for the analysis that they want to perform: for example, at the individual, household or company level. However, on the one hand, there is no bijection between the two (a person can have multiple bank accounts and multiple telephone lines) and, on the other hand, it is not immediately obvious that this link exists between the two (not to mention the legal issues that would arise).

While the concept that we are discussing remains abstract, the domain requires us to address more operational considerations. (Olson, 2003) describes it as all of the “acceptable values for encoding a specific fact”. He specifies that the domain is generic and independent of the manner in which it will be physically implemented. In order to define the domain, the rules that the values must comply with must be clarified, independently of the applications that will use them. If they are properly defined via a metadata repository, the work of the developers of user applications becomes much easier.

The domain depends on the nature of the value and its type. If it is a quantity, for example, it will often be represented by an interval; negatives can be accepted for a temperature in degrees Celsius, but not for the height of a monument. It can refer to a unit of measurement (degree Celsius, metre), which will form an integral part of the definition of the domain, but this is not mandatory, particularly where whole numbers are involved (number of children).

In the case of a date, the expected formats should be specified, e.g. dd-mm-yy, or yy-mm-dd, and it is often the case that all of the possible entries are defined by an interval, which does not have the same meaning as a numerical interval, given the specific nature of dates (day ≤ 31, month ≤ 12).

If it is an alphanumerical code, the domain is sometimes defined by intension, for example, in the case of identifiers with complex structures within large repositories (NIR or social security number for individuals, SIRET for business establishments), telephone numbers and even names (Elmasri and Navathe, 2015). Characterising the domain using the list of extensions would actually present two disadvantages: not only would the list be too long to explain (there are millions of them), more importantly, it is also constantly evolving. It is therefore better to specify the domain based on the rules restricting the set of possibilities: for example the NIR has a very precise structure with the first character representing the person’s sex, the two following characters representing the year of birth, followed by the month, etc.

The more common approach is to express the set as an extension: this is the approach taken in the case of a questionnaire by linking codes to responses (A – Strongly agree, B – Somewhat agree, C – Somewhat disagree, D – Strongly disagree) or by discretising a quantitative variable (e.g. age brackets).

This list of codes can also be derived from a classification... without actually being one itself. Indeed, classifications such as those for professions, economic activities and diseases are presented in the form of tree structures at different levels (Amossé, 2020); for example, in the French Classification of Activities (NAF), there are levels for section, division, group, class, sub-class, etc. Therefore, if the concept of data is economic activity, the domain cannot be the classification in its entirety: this would need to be a level within that classification or, more generally, any cut-off deemed relevant on the basis thereof, ultimately resulting in a “flat” list.

We could go on and on with other types of data, but in all cases, specifying the domain means naming it and defining a certain number of properties that are to be respected: data typing, coupled with a list of acceptable values, elements such as length restrictions (or any other rules restricting the range of possibilities), rules relating to the presentation of missing values and even more technical points, such as the usable character set.

Basically, specifying a domain also requires choices to be made regarding granularity, which are decisive for subsequent use: the fineness of the description within a classification (cf. the example of the industry classification), the unit of measurement for a distance (m, km, light years), the precision of a date (year, day, minute, second, nanosecond). This also involves linking instructions to the admissible values, commentaries that are indispensable when it comes to creating the data (e.g. in the above example, if you want to say “somewhat agree”, you will enter B) and interpreting them (when someone reads B, they will understand what it means).

With the domain, we therefore establish a semantic and technical convention, shared by all designers and users of data, which, like the concept, is inseparable from the data. Armed with the concept and the domain, we have a kind of receptacle, at least in theory, into which we now need to feed a value (or not, for that matter).

With the third element of the triptych, the value, we are entering a more tangible reality. This is the number, code, date or character string that will be linked to a domain and a concept. This time, the latter is instantiated: the value will relate to a well-defined entity and attribute, such as the socio-professional category of a particular employee of a particular establishment (in accordance with the PCS-ESE classification and on 1 November 2020), the mass (in megatons) of the sun, the altitude (in m) of Mont- Blanc, etc.

One thing needs to be clarified here: the value is linked to the instantiated concept, it refers to it… but that does not mean that it represents it faithfully, it provides no guarantee of accuracy at any given time: it is possible to find different values for the altitude of Mont-Blanc depending on where you look; a professional code submitted may be incorrect as a result of it no longer being up to date or because the person who has entered the code made a mistake, etc. This means that no guarantees are provided with regard to the reliability of data by the triptych of concept-domain-value. It makes it possible to provide a basis for the value, to give it a status other than a simple number or a meaningless code, but its reliability relates to other subjects, in particular the way in which the data was constructed.

In the absence of any certainty with regard to quality, the reference to the domain can provide us with a guarantee of conformity, reliability from a syntactic point of view (Batini and Scannapieco, 2016): as a minimum, the data should belong to it (for example, the fact that data representing dates does indeed have the properties that a date must have). Conformity of this nature is common... but not mandatory: this time, everything depends on the checks that would have been performed automatically on the value. The input tools will very often be designed so as to ensure that values can be selected from among the permissible ones displayed on the screen (prepared list of codes), or even to reject the value if it does not fall within the specified domain: this is the case, for example, when data is being collected by an interviewer. When dealing with digitalised and standardised data exchanges, the exchange protocol makes it possible to guarantee properties that go beyond even belonging to a domain: this is the case for social declarations (Renne, 2018). More generally, database management systems implicitly incorporate typing controls. In all of these situations, the structure ensures that the value is compliant, i.e. it falls within the set of admissible values. Nevertheless, in some cases, data may be input or calculated automatically without any checks being carried out and then saved in a file without any guarantee of conformity.

Finally, on a practical level, the value is found on a medium (physical or logical) that has no reason to be the same as the concept and the domain. And it refers to a certain number of coding standards that are, for the most part, completely unknown to the end users.

As was the case for the concept and the domain, the value therefore also brings its own rules, which in this case are of a more technical nature, and the technical choices will therefore already have been made: this applies to the data type, as well as to the way in which missing values are to be taken into account, for example. Therefore, as with the other two elements of the triptych, the value requires conventions. However, with this third and final dimension, we can see that individual reasoning, datum by datum, is largely artificial.

In fact, “data” as a material is peculiar in that it cannot be considered alone, as a grain of data separated from the rest. (Borgman, 2015) explains that “[...] data have no value or meaning in isolation; they exist within a knowledge infrastructure – an ecology of people, practices, technologies, institutions, material objects, and relationships”. In order to give them meaning, to extract information from them, they must be compared with their close equals in order to make comparisons and access the necessary environment in which to interpret them.

In addition, data are always presented together as a group, they work in a pack, as it were. Most of the time, this involves several instances of the same concept, for a shared attribute (for example, n individuals and, for each individual, the professional code), or several attributes of the same instance of the object (all of the data included in the tax return submitted by a certain individual), or several temporal specifications for the same instance and the same attribute (for example, the number of employees at a particular company, year by year).

This method of recording data as a group rather than individually requires documented rules for retrieving a specific datum from among a vast data set, and this depends on the way in which the data have been stored. They need to be placed somewhere, but at the same time, consideration must be given to the ways in which they can be retrieved.

There are numerous possibilities for this. Historically, data were presented in a structured file and a traditional technique consisted in characterising each datum using a range of columns within the file as “fixed positional”, or using the number of the order in which the datum appears in a list as “fixed delimited”. Approaches such as these require a large amount of documentation, which is generally quite cumbersome and complex to update.

There are other ways of doing this, such as adopting an XML-type markup language, where we once again come across the idea, at least in part, that the value must be enveloped by a concept and a domain: each value appears between two tags, which are themselves linked to the formal verification rules within the XML schemas, together with a name describing the concept. The characterisation of the data is therefore self-sufficient and no longer dependent on documentation. Another example is the JSON format, which is lighter than XML, less verbose, efficient, but at the same time less rich.

However, the most widespread option is of course to store the data in a database managed by a DBMS (database management system): this brings about excellent standardisation and provides guarantees with regard to the integrity of the data and the language with which they can be accessed (SQL); relational databases offer the possibility of making many changes on a frequent basis and are therefore highly suitable for use in business processes (Ouvrir dans un nouvel ongletCodd, 1970). Another concept, namely data warehouses, are designed to facilitate analysis work, which makes them useful as aids to decision-making: these are then fixed data, which must comply with a binding framework with common axes of analysis and therefore common classifications in particular, even though the information comes from many different sources. The technique involving the use of data lakes also concerns fixed data; however, these are designed to be much less restrictive than data warehouses, even though all of the standardisation work has to be carried out at the time that the data are accessed.

There are even data structuring techniques that are designed for situations in which there is no time to store data (real-time systems in particular): these are known as Data Stream Management Systems, or DSMS (Garofalakis, Gehrke et Rastogi, 2016).

All in all, there are numerous methods for recording data in an organised manner; the differences in the methods should not be perceived as being of a technical nature, but rather as a function of the intended use of the data (management, decision-making, real time) and any possible constraints on them (in terms of volume, in particular). In each case, we come across the concept and the domain in some form, be it as (meta)data or in the associated documentation. Finally, it should be noted that reasoning on a dataset rather than on a single datum gives rise to other concepts: first of all, there is a need for overall coherence, from both a structural and a semantic point of view. The scope that this dataset represents becomes a subject of interest that is to be analysed as such and that fully involves statisticians. Finally, knowledge of the information source associated with this dataset represents a quality criterion (Loshin, 2010). This means that data cannot be approached without questioning the ecosystem in which it is found.

The triplet (concept, domain, value) provides a useful framework, but is not enough to exhaust everything that the material of “data” carries with it.

Data are not a given, they are not inherent in nature: their existence results from a need; they are embedded in an environment. The fact that they are very strictly defined does not make them pure and perfect, because they are intrinsically linked to a use. They are only there to contribute to an objective and not to make reference information available to the public.

(Ouvrir dans un nouvel ongletDenis, 2018) therefore seeks to “unravel the data threads”. He gives the simple example of a death: here, the concept and domain are easy to define. However, he highlights the large number of players who are concerned by this information, and the way in which the uses vary depending on their activities: insurance companies, administration, etc. For example, insurers require proof: the fact that a person is considered dead in their computer system means that there is proof. However, a dead person may be registered as living within the same system, simply because the proof has not been submitted: as a result, the data does not reflect the true information, it prepares for a use within the scope of the business process. More generally, the desired data may result from events for which there is no guarantee that they will occur and be declared at the same time (for example, the cessation of a company’s activities).

Another example: when a person retires, the amount of the pension they receive depends on their career data. The majority of these data are submitted automatically, but there are some that are not and in some cases, the future retiree needs to submit proof of their career (pay slips in particular) at the last minute. Therefore, the career data of an individual who is not close to retirement may still contain “gaps” as a result of the fact that certain periods of employment have not yet been declared: the career as it appears in the operational system will therefore not correspond to the actual career.

The available data are therefore not necessarily as close to the evaluation of the concept, to the “true data”, as one would imagine. The business processes do not aim to produce “the truth”, but this does not mean that the data are “bad”. To understand the data is to understand the objective, the rules of the processes that gave rise to them.

More generally, where data are derived from a legal framework (e.g. social security), it is inevitable that there will be discrepancies in the data as they should appear in accordance with the law, i.e. data as they would be if one had a perfect view of reality... and data such as they are found in the databases (Boydens, 2000). This means that there is a discrepancy between the theoretical data and the data actually recovered, which is linked to reactivity with regard to events. This allows for a different approach to the “quality” of data: quality relates to the data’s fitness for use rather than to its accuracy.

It is therefore necessary to understand where data come from, how they come about (sensor, input interface, automatic calculation, etc.) and to have knowledge of the event triggering the creation of data, as well as the subsequent processes that make use of those data (e.g. triggering of a benefit or a refund). We then see data less as an absolute truth and more as an essential link in a complex chain. This can help us to identify the reasons why data are missing (see the example of career data for a pension scheme) or inaccurate without the business process being deficient (see the example of a death as seen by an insurance company).

Compared with the previous examples, the traditional methods of obtaining data in statistics, namely surveys, appear to be an oddity: the data are not directly linked to a use by a downstream business process, they are simply used to feed into the calculation of aggregated data, statistics, which are a goal in themselves.

In a digitised world where data are a constant feature in our lives and those of our organisations, people tend to think that the increase in the number of sources of data on all subjects would make a statistician’s job easier. To coin a phrase, they’re practically tripping over them.

This view is largely incorrect, as it is based on a significant misunderstanding with regard to the meaning of the word “data”: what they can actually access, more or less easily, are considerable quantities of values (numbers, codes, descriptions, dates, etc.), but not the equivalent in data. This is because these values remain dead letter unless you have a robust key that allows them to be interpreted: the concept, domain, and also the scope need to be adequately explained. These values cannot be used for analytical purposes on the basis of weak or non-existent conventions or vague, insecure and implicit characterisations.

The primary responsibility of a statistician when confronted with external datasets is to reveal and unravel a web of conventions underlying those datasets (Martin, 2020): conventions concerning the definition, objects, time scales, nomenclatures, formats, missing values, etc., all of which will allow them to reconstitute the concept-domain-value triptych and to characterise the population covered. The existing conventions must be actively sought and used, as they are important allies: accounting standards, for example, are of great use to business statisticians (they offer guarantees of quality), as well as the legal bases of concepts, which can lead to the quality of the data being established or, on the contrary, a need to remedy any deviations.

But this is not enough: the living, evolving data linked to business processes must be replaced with observations. These should be fixed in time at the same moment t (for example, the situation of companies as at 31/12/2019) or over the same period (for example, company activities during the 2019 calendar year), and must refer to objects that are separate from and homogeneous with one another, as well as their attributes. This homogenisation work is a key element of the work of a statistician, but it actually began long before official statistics with the metric system and the unification of weights and measures (Desrosières, 1993).

In other words, it is a case of reconstructing a posteriori a pseudo-observational device using data that were not designed for this purpose. In order to do so, public statisticians use a powerful set of conventions, which is widely shared: registers, classifications, definitions of concepts, statistical units, notation conventions, which translate into a vast set of metadata. The classifications are widely coordinated (those belonging to INSEE or the ATIH, for example), and the conventions relating to the reference populations allow for the calibration, monitoring and comparison of the statistics obtained.

With uncontrolled external data, the statistician will also be faced with a multitude of shortcomings within those data, which can cast doubt on them and their quality. And this is still true even if they are perfect for their intended purpose. In order to avoid this classic pitfall, the statistician will need to understand the operational environment of the original data to determine the way in which they can be used. This will have an impact on the steps for the automatic and manual check and for the imputation of dubious or missing values. Matching and therefore the identification of objects forces the statistician to question their meaning and stability, as well as their links to the statistical units under consideration (Christen, 2012). The final validation of the aggregates and their interpretation will refer to the meaning of the reference population covered.

These external data are just one of the inputs to a statistician’s work and they are used to develop new data, in this case aggregated data known as “statistics”. As data, they will have their own characterisations with a particularly stringent requirement with regard to consistency, which highlights the essential role of metadata.

There is no data in nature. None whatsoever. In other words, data are not given, they have to be constructed, taken (captum vs datum). They require upstream modelling work, abstraction, specification of concepts and domains, before you can even think about producing values. They are themselves dependent on choices linked to uses. However, they do exist in the vast digital world, and it seems logical that official statistics is looking into ways in which these can be used effectively for its own needs, even if it means inventing new ones suitable for fuelling the public debate.

This represents a profound change for public statisticians, even though they have long-standing experience of using administrative data. Up until the 19^th century and even at the start of the 20^th century, the census was the main format used by official statistics. During the second half of the 20^th century, surveys took on a leading role with end-to-end process that made use of a veritable arsenal of mathematical and technical resources. Without taking away from the other formats, the 21^st century would belong to data: statisticians are also computer scientists, explorers of the digital realms and are, in fact, data scientists. However, if we reread (Ouvrir dans un nouvel ongletVolle, 1980), we can see that the foundations remain the same: registers, classifications, codes, definitions, statistical units, everything that we now group together under the heading metadata. In addition to the key role taken by IT, the other major change in the business lies in the need to immerse oneself in the original functions of the data in order to make better use of them. It is this need for openness to external processes (and not just to user needs), this versatility, this agility, this curiosity tinged with great rigour, that will be the hallmark of a new generation of statisticians.