Initialisation

Les données sont disponibles sur le site data.gouv aux adresses suivantes :

• Fichier détail individuel ;
• Fichier détail logement.

Dans la suite de ce guide, il sera fait l’hypothèse pour Python et R que les données sont récupérées depuis les URL stables, enregistrées dans un même dossier et qu’il existe une variable ad hoc enregistrant ce chemin dans Python ou R. En ce qui concerne Observable, il est proposé d’utiliser directement l’URL de mise à disposition des fichiers.

path_data = 'C:/MesDocuments/dossierpersonnel'
# remplacer par l'emplacement où sont stockées 
# les données

path_data <- 'C:/MesDocuments/dossierpersonnel'
# remplacer par l'emplacement où sont stockées 
# les données

path_data <- 'C:/MesDocuments/dossierpersonnel'
# remplacer par l'emplacement où sont stockées 
# les données

Il est proposé, pour initialiser la connexion entre les données Parquet et le langage client (Javascript, R ou Python) d’utiliser des vues. Ceci permet de faire référence de manière répétée à la même source de données par le biais d’un alias (table_logement ou table_individu).

```{ojs}
url_table_logement = "https://www.data.gouv.fr/fr/datasets/r/f314175a-6d33-4ee4-b5eb-2cb6c29df2c2"
url_table_individu = "https://www.data.gouv.fr/fr/datasets/r/c8e1b241-75fe-43e9-a266-830fc30ec61d"
url_doc_logement = "https://www.data.gouv.fr/fr/datasets/r/c274705f-98db-4d9b-9674-578e04f03198"
url_doc_individu = "https://www.data.gouv.fr/fr/datasets/r/1c6c6ab2-b766-41a4-90f0-043173d5e9d1"

renommage_documentation = `SELECT 
  COD_VAR AS nom_variable, 
  LIB_VAR AS description_variable, 
  TYPE_VAR AS type_variable, 
  COD_MOD AS code_modalite, 
  LIB_MOD AS description_modalite,
  LONG_VAR as longueur_variable`

db = {
  const configuredClient = await DuckDBClient.of();

  await configuredClient.query(`
    CREATE OR REPLACE VIEW table_individu 
    AS SELECT *
    FROM read_parquet('${url_table_individu}')`
  ) ;

  await configuredClient.query(`
    CREATE OR REPLACE VIEW table_logement 
    AS SELECT *
    FROM read_parquet('${url_table_logement}')`
  ) ;

  await configuredClient.query(`
    CREATE OR REPLACE VIEW documentation_logement
    AS ${renommage_documentation} FROM read_csv_auto('${url_doc_logement}', header=true)`
  ) ;
  
  await configuredClient.query(`
    CREATE OR REPLACE VIEW documentation_indiv
    AS ${renommage_documentation} FROM read_csv_auto('${url_doc_individu}', header=true)`
  ) ;

  return configuredClient
}
```

url_table_logement = "https://static.data.gouv.fr/resources/recensement-de-la-population-fichiers-detail-logements-ordinaires-en-2020-1/20231023-123618/fd-logemt-2020.parquet"
url_table_individu = "https://static.data.gouv.fr/resources/recensement-de-la-population-fichiers-detail-individus-localises-au-canton-ou-ville-2020-1/20231023-122841/fd-indcvi-2020.parquet"
url_doc_logement = "https://www.data.gouv.fr/fr/datasets/r/c274705f-98db-4d9b-9674-578e04f03198"
url_doc_individu = "https://www.data.gouv.fr/fr/datasets/r/1c6c6ab2-b766-41a4-90f0-043173d5e9d1"

renommage_documentation = `SELECT 
  COD_VAR AS nom_variable, 
  LIB_VAR AS description_variable, 
  TYPE_VAR AS type_variable, 
  COD_MOD AS code_modalite, 
  LIB_MOD AS description_modalite,
  LONG_VAR as longueur_variable`

db = {
  const configuredClient = await DuckDBClient.of();

  await configuredClient.query(`
    CREATE OR REPLACE VIEW table_individu 
    AS SELECT *
    FROM read_parquet('${url_table_individu}')`
  ) ;

  await configuredClient.query(`
    CREATE OR REPLACE VIEW table_logement 
    AS SELECT *
    FROM read_parquet('${url_table_logement}')`
  ) ;
  
  await configuredClient.query(`
    CREATE OR REPLACE VIEW documentation_indiv
    AS ${renommage_documentation} FROM read_csv_auto('${url_doc_individu}', header=true)`
  ) ;

  await configuredClient.query(`
    CREATE OR REPLACE VIEW documentation_logement
    AS ${renommage_documentation} FROM read_csv_auto('${url_doc_logement}', header=true)`
  ) ;

  return configuredClient
}

import duckdb
import os

if not os.path.isdir(path_data):
    raise ValueError("path_data n'est pas un répertoire valide.")

duckdb.sql(f'''
  CREATE OR REPLACE VIEW table_individu
  AS SELECT * FROM read_parquet("{path_data}/FD_INDCVI_2020.parquet")
'''
)

duckdb.sql(f'''
  CREATE OR REPLACE VIEW table_logement
  AS SELECT * FROM read_parquet("{path_data}/FD_LOGEMT_2020.parquet")
'''
)

duckdb.sql(f'''
  CREATE OR REPLACE VIEW documentation_indiv
  AS SELECT COD_VAR AS nom_variable,
     LIB_VAR AS description_variable,
     TYPE_VAR AS type_variable,
     COD_MOD AS code_modalite,
     LIB_MOD AS description_modalite,
     LONG_VAR as longueur_variable
  FROM read_csv_auto("{path_data}/dictionnaire_variables_indcvi_2020.csv", header=true)
'''
)

duckdb.sql(f'''
  CREATE OR REPLACE VIEW documentation_logement
  AS SELECT COD_VAR AS nom_variable,
     LIB_VAR AS description_variable,
     TYPE_VAR AS type_variable,
     COD_MOD AS code_modalite,
     LIB_MOD AS description_modalite,
     LONG_VAR as longueur_variable
  FROM read_csv_auto("{path_data}/dictionnaire_variables_logemt_2020.csv", header=true)
'''
)

library(duckdb)
library(glue)

# Pour créer une base de données en mémoire
con <- dbConnect(duckdb())

path_data_sql <- DBI::SQL(path_data)


renommage_documentation <-  DBI::SQL(paste(
"SELECT",
"COD_VAR AS nom_variable,",
"LIB_VAR AS description_variable,",
"TYPE_VAR AS type_variable,",
"COD_MOD AS code_modalite,",
"LIB_MOD AS description_modalite,",
"LONG_VAR as longueur_variable"
))


dbExecute(
  con,
  glue_sql(  
    'CREATE OR REPLACE VIEW table_individu AS ',
    'SELECT * FROM read_parquet("{path_data_sql}/FD_INDCVI_2020.parquet")',
    .con=con
  )
)

dbExecute(
  con,
  glue_sql(  
    'CREATE OR REPLACE VIEW table_logement AS ',
    'SELECT * FROM read_parquet("{path_data_sql}/FD_LOGEMT_2020.parquet")',
    .con=con
  )
)

dbExecute(
  con,
  glue_sql(
  'CREATE OR REPLACE VIEW documentation_indiv AS ',
  '{renommage_documentation} FROM ',
  'read_csv_auto("{path_data_sql}/dictionnaire_variables_indcvi_2020.csv", header=true)',
  .con=con
  )
)

dbExecute(
  con,
  glue_sql(
  'CREATE OR REPLACE VIEW documentation_logement AS ',
  '{renommage_documentation} FROM ',
  'read_csv_auto("{path_data_sql}/dictionnaire_variables_logemt_2020.csv", header=true)',
  .con=con
  )
)

library(duckdb)
library(dplyr)
library(stringr)
library(glue)

# Pour créer une base de données en mémoire
con <- dbConnect(duckdb())

path_data_sql <- DBI::SQL(path_data)

renommage_documentation <-  DBI::SQL(paste(
"SELECT",
"COD_VAR AS nom_variable,",
"LIB_VAR AS description_variable,",
"TYPE_VAR AS type_variable,",
"COD_MOD AS code_modalite,",
"LIB_MOD AS description_modalite,",
"LONG_VAR as longueur_variable"
))


dbExecute(
  con,
  glue_sql(  
    'CREATE OR REPLACE VIEW table_individu AS ',
    'SELECT * FROM read_parquet("{path_data_sql}/FD_INDCVI_2020.parquet")',
    .con=con
  )
)

table_individu <- tbl(con, "table_individu")
# La requête pourrait aussi s'écrire directement dans l'appel à tbl :
table_individu_direct <- tbl(con, glue('read_parquet("{path_data}/FD_INDCVI_2020.parquet")'))
print(table_individu_direct)

dbExecute(
  con,
  glue_sql(  
    'CREATE OR REPLACE VIEW table_logement AS ',
    'SELECT * FROM read_parquet("{path_data_sql}/FD_LOGEMT_2020.parquet")',
    .con=con
  )
)
table_logement <- tbl(con, "table_logement")

dbExecute(
  con,
  glue_sql(
  'CREATE OR REPLACE VIEW documentation_indiv AS ',
  '{renommage_documentation} FROM ',
  'read_csv_auto("{path_data_sql}/dictionnaire_variables_indcvi_2020.csv", header=true)',
  .con=con
  )
)
documentation_indiv <- tbl(con, "documentation_indiv")

dbExecute(
  con,
  glue_sql(
  'CREATE OR REPLACE VIEW documentation_logement AS ',
  '{renommage_documentation} FROM ',
  'read_csv_auto("{path_data_sql}/dictionnaire_variables_logemt_2020.csv", header=true)',
  .con=con
  )
)
documentation_logement <- tbl(con, "documentation_logement")

Pour rapidement avoir une idée des informations présentes dans ces données, le code ci-dessous peut être utilisé :

```{ojs}
schema_table_logement = db.query(
  "SELECT * FROM documentation_logement"
  )
Inputs.table(documentation_logement)

schema_table_individu = db.query(
  "SELECT * FROM documentation_indiv"
  )
Inputs.table(schema_table_individu)
```

schema_table_individu = duckdb.sql(
  "SELECT * FROM documentation_indiv"
  ).to_df()
display(schema_table_individu.head(2))

schema_table_logement = duckdb.sql(
  "SELECT * FROM documentation_logement"
  ).to_df()
display(schema_table_logement.head(2))

schema_table_individu <- dbGetQuery(
  con,
  "SELECT * FROM documentation_indiv"
)
print(head(schema_table_individu))

schema_table_logement <- dbGetQuery(
  con,
  "SELECT * FROM documentation_logement"
)
print(head(schema_table_logement))

print(head(documentation_indiv))

print(head(documentation_logement))

schema_table_individu = db.query(
  "SELECT * FROM documentation_indiv"
  )
schema_table_logement = db.query(
  "SELECT * FROM documentation_logement"
  )

Voici le dictionnaire des variables de la table logement:

viewof search_logement = Inputs.search(schema_table_logement, {
  placeholder: "Rechercher une information dans la table logement"
})

Inputs.table(search_logement)

Et voici celui de la table individus:

viewof search_individus = Inputs.search(schema_table_individu, {
  placeholder: "Rechercher une information dans la table individus"
})

Inputs.table(search_individus)

Pour découvrir les informations présentes dans la base, il est possible d’utiliser les fonctions pré-implémentées de DuckDB pour la manipulation de données textuelles. Par exemple, pour extraire toutes les modalités des variables dont la description contient le terme “catégorie” :

```{ojs}
query = "SELECT * FROM documentation_logement WHERE CONTAINS(description_variable, 'Catégorie')"
Inputs.table(
    db.query(query)
)
```

query = "SELECT * FROM documentation_logement WHERE CONTAINS(description_variable, 'Catégorie')"
duckdb.sql(query)

query <- "SELECT * FROM documentation_logement WHERE CONTAINS(description_variable, 'Catégorie')"
dbGetQuery(con, query)

documentation_logement %>%
  filter(str_detect(description_variable, "catégorie"))

query = "SELECT * FROM documentation_logement WHERE CONTAINS(description_variable, 'Catégorie')"
Inputs.table(
    db.query(query)
)

Cette approche peut permettre de récupérer les modalités d’une variable. Dans cette base de données, les valeurs Z sont à part. Il est possible d’avoir du détail sur celles-ci avec la requête suivante :

```{ojs}
Inputs.table(
  db.query(
    "SELECT * FROM documentation_indiv WHERE CONTAINS(code_modalite, 'Z')"
  ),
  {
    columns: [
      "nom_variable","code_modalite",
      "description_modalite", "description_variable",
      "type_variable"
      ]
  }
)
```

duckdb.sql(
  "SELECT * FROM documentation_indiv WHERE CONTAINS(code_modalite, 'Z')"
)

query <- "SELECT * FROM documentation_indiv WHERE CONTAINS(code_modalite, 'Z')"
dbGetQuery(con, query)

documentation_indiv %>%
  filter(str_detect(code_modalite, "Z"))

Inputs.table(
  db.query(
    "SELECT * FROM documentation_indiv WHERE CONTAINS(code_modalite, 'Z')"
  ),
  {
    columns: [
      "nom_variable","code_modalite",
      "description_modalite", "description_variable",
      "type_variable"
      ]
  }
)

Lecture et affichage de quelques valeurs

Pour visualiser un nombre limité de valeurs, par exemple 5, deux approches sont possibles :

• Sélectionner un échantillon restreint sur les premières lignes du Parquet, par exemple les 5 premières lignes ;
• Sélectionner un échantillon aléatoire.

Pour les premières lignes, la commande à utiliser est LIMIT.

```{ojs}
Inputs.table(
    db.query("SELECT * FROM table_logement LIMIT 5")
)
```

duckdb.sql("SELECT * FROM table_logement LIMIT 5")

dbGetQuery(
  con,
  "SELECT * FROM table_logement LIMIT 5"
)

table_logement %>% head(5)

Inputs.table(
    db.query("SELECT * FROM table_logement LIMIT 5")
)

Pour un échantillon aléatoire, la commande à utiliser est USING SAMPLE.

Inputs.table(
    db.query("SELECT * FROM table_logement USIN SAMPLE 5")
)

```{ojs}
Inputs.table(
    db.query("SELECT * FROM table_logement USING SAMPLE 5")
)
```

duckdb.sql("SELECT * FROM table_logement USING SAMPLE 5")

dbGetQuery(
  con,
  "SELECT * FROM table_logement USING SAMPLE 5"
)

tbl(con, sql("SELECT * FROM table_logement USING SAMPLE 5"))

Inputs.table(
    db.query("SELECT * FROM table_logement USING SAMPLE 5")
)

Sélectionner des observations ou des variables

```{ojs}
Inputs.table(
    db.query("SELECT IPONDI AS poids, AGED, VOIT FROM table_individu LIMIT 10")
)
```

duckdb.sql("SELECT IPONDI AS poids, AGED, VOIT FROM table_individu LIMIT 10")

dbGetQuery(
  con,
  "SELECT IPONDI AS poids, AGED, VOIT FROM table_individu LIMIT 10"
)

table_individu %>%
  select(poids = IPONDI, AGED, VOIT) %>%
  head(10)

Inputs.table(
    db.query("SELECT IPONDI AS poids, AGED, VOIT FROM table_individu LIMIT 10")
)

```{ojs}
Inputs.table(
    db.query("SELECT IPONDI AS poids, COLUMNS('.*AGE.*') FROM table_individu LIMIT 10")
)
```

duckdb.sql("SELECT IPONDI AS poids, COLUMNS('.*AGE.*') FROM table_individu LIMIT 10")

dbGetQuery(
  con,
  "SELECT IPONDI AS poids, COLUMNS('.*AGE.*') FROM table_individu LIMIT 10"
)

table_individu %>%
  select(poids = IPONDI, contains("AGE")) %>%
  head(10)

Inputs.table(
    db.query("SELECT IPONDI AS poids, COLUMNS('.*AGE.*') FROM table_individu LIMIT 10")
)

```{ojs}
Inputs.table(
    db.query("SELECT * FROM table_individu WHERE DEPT IN ('11', '31', '34') LIMIT 10")
)
```

duckdb.sql("SELECT * FROM table_individu WHERE DEPT IN ('11', '31', '34')")

dbGetQuery(
  con,
  "SELECT * FROM table_individu WHERE DEPT IN ('11', '31', '34')"
)

table_individu %>%
  filter(DEPT %in% c("11", "31", "34")) %>%
  head(10)

Inputs.table(
    db.query("SELECT * FROM table_individu WHERE DEPT IN ('11', '31', '34') LIMIT 10")
)

```{ojs}
liste_regions = ["11", "31", "34"]
liste_regions_sql = liste_regions.map(item => `'${item}'`).join(",")
Inputs.table(
    db.query(`SELECT * FROM table_individu WHERE DEPT IN (${liste_regions_sql}) LIMIT 10`)
)
```

con = duckdb.connect()

con.execute('''
  CREATE OR REPLACE VIEW table_individu
  AS SELECT * FROM read_parquet("FD_INDCVI_2020.parquet")
'''
)

liste_regions = ["11", "31", "34"]

dep_slots = ", ".join(["?" for _ in liste_regions])
query = "SELECT * FROM table_individu WHERE DEPT IN ({})".format(dep_slots)
liste_regions_sql = ", ".join([f"'{dep}'" for dep in liste_regions])
con.execute(query, liste_regions).fetchdf()

liste_regions <- c("11", "31", "34")
liste_regions_sql <- glue_sql_collapse(
  lapply(
    liste_regions, function(dep) glue_sql("'{`dep`}'", .con=con)
    ),
  ", "
)
query <- glue_sql(
  "SELECT * FROM table_individu WHERE DEPT IN ({liste_regions_sql})",
  .con=con
)
dbGetQuery(con, query)

liste_regions <- c("11", "31", "34")
table_individu %>%
  filter(DEPT %in% liste_regions)

liste_regions = ["11", "31", "34"]
liste_regions_sql = liste_regions.map(item => `'${item}'`).join(",")
Inputs.table(
    db.query(`SELECT * FROM table_individu WHERE DEPT IN (${liste_regions_sql}) LIMIT 10`)
)

```{ojs}
Inputs.table(
    db.query(
        "SELECT * FROM table_logement WHERE COMMUNE = '06088' and AEMM > 2020"
    )
)
```

query = "SELECT * FROM table_logement WHERE COMMUNE = '06088' and AEMM > 2020"
duckdb.sql(query)

dbGetQuery(
  con,
  "SELECT * FROM table_logement WHERE COMMUNE = '06088' and AEMM > 2020"
)

table_logement %>%
  filter(COMMUNE == "06088") %>%
  filter(AEMM > 2020)
# Peut aussi s'écrire en une fois :
# table_logement %>% filter(COMMUNE == "06088", AEMM > 2020)

Inputs.table(
    db.query(
        "SELECT * FROM table_logement WHERE COMMUNE = '06088' and AEMM > 2020"
    )
)

Statistiques agrégées

Le langage SQL permet d’exécuter de manière très efficace des requêtes complexes afin de construire, à partir de données fines, des statistiques agrégées.

Cette partie illustre d’abord ceci avec deux exemples de statistiques agrégées renvoyant une unique statistique :

• Extraire la liste des codes arrondissements de Paris, Lyon, Marseille où au moins une personne a été recensée ;
• Reproduire l’exemple de Mauvière (2022) permettant de calculer le nombre d’habitants de Toulouse qui ont changé de logement en un an ;

Ensuite, des statistiques plus fines sont construites par le biais d’agrégations par groupe :

• Calculer le nombre de personnes recensées par cohorte pour les départements de l’Aude (11), de la Haute-Garonne (31) et de l’Hérault (34) ;
• Calculer le nombre de centenaires recensés par département.

La fonction DISTINCT appliquée à la variable ARM permet d’extraire la liste des codes arrondissements présents dans la base de données.

```{ojs}
Inputs.table(
    db.query(
        "SELECT DISTINCT(ARM) FROM table_logement WHERE NOT CONTAINS(ARM, 'ZZZZZ') ORDER BY ARM"
    )
)
```

query = "SELECT DISTINCT(ARM) " +\
    "FROM table_logement " +\
    "WHERE NOT CONTAINS(ARM, 'ZZZZZ') " +\
    "ORDER BY ARM"
duckdb.sql(query)

query <- glue_sql(
    "SELECT DISTINCT(ARM) ",
    "FROM table_logement ",
    "WHERE NOT CONTAINS(ARM, 'ZZZZZ') ",
    "ORDER BY ARM",
    .con=con
)
dbGetQuery(con, query)

table_logement %>%
  filter(str_detect(ARM, "ZZZZZ", negate = TRUE)) %>%
  summarise(ARM = distinct(ARM)) %>%
  arrange(ARM)

Inputs.table(
    db.query(
        "SELECT DISTINCT(ARM) FROM table_logement WHERE NOT CONTAINS(ARM, 'ZZZZZ') ORDER BY ARM"
    )
)

Il est possible d’extraire des statistiques beaucoup plus raffinées par le biais d’une requête SQL plus complexe. Par exemple pour calculer le nombre d’habitants de Toulouse qui ont changé de logement en un an:

```{ojs}
Inputs.table(
  db.query(
    `
    SELECT CAST(
      SUM(IPONDL*CAST(INPER AS INT)) AS INT
    ) AS habitants_toulouse_demenagement
    FROM table_logement
    WHERE COMMUNE == '31555' AND IRANM NOT IN ('1', 'Z') AND INPER != 'Y'
    `
  )
)
```

query = \
"""
SELECT CAST(
  SUM(IPONDL*CAST(INPER AS INT)) AS INT
) AS habitants_toulouse_demenagement
FROM table_logement
WHERE COMMUNE == '31555' AND IRANM NOT IN ('1', 'Z') AND INPER != 'Y'
"""
duckdb.sql(query).df()

query <- paste(
  "SELECT CAST(SUM(IPONDL*CAST(INPER AS INT)) AS INT) ",
  "AS habitants_toulouse_demenagement",
  "FROM table_logement",
  "WHERE COMMUNE == '31555' AND IRANM NOT IN ('1', 'Z') AND INPER != 'Y'",
  sep = " ")
dbGetQuery(con, query)

table_logement %>%
  filter(COMMUNE == '31555', !IRANM %in% c('1', 'Z'), INPER != "Y") %>%
  mutate(INPER = as.integer(INPER)) %>%
  summarise(habitants_toulouse_demenagement = as.integer(sum(IPONDL * INPER)))

Inputs.table(
  db.query(
    `
    SELECT CAST(
      SUM(IPONDL*CAST(INPER AS INT)) AS INT
    ) AS habitants_toulouse_demenagement
    FROM table_logement
    WHERE COMMUNE == '31555' AND IRANM NOT IN ('1', 'Z') AND INPER != 'Y'
    `
  )
)

Pour représenter la pyramide des âges recensés dans ces trois départements, il est possible de procéder en deux étapes

• Effectuer une agrégation par le biais de DuckDB et transformer ces résultats sous forme de dataframe
• Utiliser ce dataframe avec un package d’analyse graphique pour représenter la pyramide des âges.

```{ojs}
Plot = require("https://cdn.jsdelivr.net/npm/@observablehq/plot@0.6.11/dist/plot.umd.min.js")
```

```{ojs}
pyramide_ages = db.query(
`
SELECT
  CAST(SUM(IPONDI) AS INT) AS individus,
  CAST(AGED AS INT) AS AGED,
  DEPT AS departement
FROM table_individu
  WHERE DEPT IN ('11', '31', '34')
GROUP BY AGED, DEPT ORDER BY DEPT, AGED
`
)
Inputs.table(pyramide_ages)
```

```{ojs}
Plot.plot({
  x: {label: null},
  y: {percent: true},
  marks: [
    Plot.barY(
        pyramide_ages,
        {x: "AGED", y: d => d.individus/1000, fy: 'departement', fill: "departement", tip: true}
        ),
    Plot.ruleX([18], {stroke: "red"}),
    Plot.tickY(
        pyramide_ages,
        {x: "AGED", y: d => d.individus/1000, fy: 'departement'}
        ),
    Plot.ruleY([0]),
    Plot.axisY({label: "Population (en milliers)"}),
    Plot.axisX({ticks: d3.ticks(0, 120, 10), label: "Âge", fontSize: 12})
  ]
})
```

import matplotlib.pyplot as plt
from plotnine import *

pyramide_ages = duckdb.sql(
"""
SELECT
  SUM(IPONDI) AS individus,
  CAST(AGED AS int) AS AGED,
  DEPT AS departement
FROM table_individu
  WHERE DEPT IN ('11', '31', '34')
GROUP BY AGED, DEPT ORDER BY DEPT, AGED
"""
).to_df()

(
    ggplot(pyramide_ages, aes(x = "AGED", y = "individus")) +
    geom_bar(
      aes(fill = "departement"),
      stat = "identity", show_legend=False
    ) +
    geom_vline(xintercept = 18, color = "grey", linetype = "dashed") +
    facet_wrap('departement', scales = "free_y", nrow = 3) +
    theme_minimal() +
    labs(y = "Individus recensés", x = "Âge")
)

library(labeling)
library(ggplot2)

query <- paste(
  "SELECT SUM(IPONDI) AS individus, AGED, DEPT AS departement",
  "FROM table_individu",
  "WHERE DEPT IN ('11', '31', '34')",
  "GROUP BY AGED, DEPT",
  "ORDER BY DEPT, AGED",
  sep = " "
)
pyramide_ages <- dbGetQuery(con, query)

ggplot(pyramide_ages, aes(x = AGED, y = individus)) +
  geom_bar(aes(fill = departement), stat = "identity") +
  geom_vline(xintercept = 18, color = "grey", linetype = "dashed") +
  facet_wrap(~departement, scales = "free_y", nrow = 3) +
  theme_minimal() +
  labs(y = "Individus recensés", x = "Âge")

library(labeling)
library(ggplot2)

pyramide_ages <- table_individu %>%
  filter(DEPT %in% c('11', '31', '34')) %>%
  group_by(AGED, departement = DEPT) %>%
  summarise(individus = sum(IPONDI), .groups = "drop") %>%
  arrange(departement, AGED) %>%
  collect()

ggplot(pyramide_ages, aes(x = AGED, y = individus)) +
  geom_bar(aes(fill = departement), stat = "identity") +
  geom_vline(xintercept = 18, color = "grey", linetype = "dashed") +
  facet_wrap(~departement, scales = "free_y", nrow = 3) +
  theme_minimal() +
  labs(y = "Individus recensés", x = "Âge")

pyramide_ages = db.query(
`
SELECT
  CAST(SUM(IPONDI) AS INT) AS individus,
  CAST(AGED AS INT) AS AGED,
  DEPT AS departement
FROM table_individu
  WHERE DEPT IN ('11', '31', '34')
GROUP BY AGED, DEPT ORDER BY DEPT, AGED
`
)
Inputs.table(pyramide_ages)

Plot.plot({
  x: {label: null},
  y: {percent: true},
  marks: [
    Plot.barY(
        pyramide_ages,
        {x: "AGED", y: d => d.individus/1000, fy: 'departement', fill: "departement", tip: true}
        ),
    Plot.ruleX([18], {stroke: "red"}),
    Plot.tickY(
        pyramide_ages,
        {x: "AGED", y: d => d.individus/1000, fy: 'departement'}
        ),
    Plot.ruleY([0]),
    Plot.axisY({label: "Population (en milliers)"}),
    Plot.axisX({ticks: d3.ticks(0, 120, 10), label: "Âge", fontSize: 12})
  ]
})

Si on s’intéresse plus spécifiquement au nombre de centenaires recensés par département et qu’on désire classer ces derniers par ordre décroissant.

```{ojs}
db.query(
`
SELECT
  SUM(IPONDI) AS individus_recenses,
  DEPT
FROM table_individu
  WHERE AGED >= 100
GROUP BY DEPT
ORDER BY individus_recenses DESC
`
)
```

duckdb.sql(
"""
SELECT
  SUM(IPONDI) AS individus_recenses,
  DEPT
FROM table_individu
  WHERE AGED >= 100
GROUP BY DEPT
ORDER BY individus_recenses DESC
"""
)

query <- paste(
  "SELECT SUM(IPONDI) AS individus_recenses, DEPT",
  "FROM table_individu",
  "WHERE AGED >= 100",
  "GROUP BY DEPT",
  "ORDER BY individus_recenses DESC",
  sep = " "
)
dbGetQuery(con, query)

table_individu %>%
  filter(AGED >= 100) %>%
  group_by(DEPT) %>%
  summarise(individus_recenses = as.integer(sum(IPONDI)), .groups = "drop") %>%
  arrange(desc(individus_recenses))

Inputs.table(
  db.query(
  `
  SELECT
    CAST(SUM(IPONDI) AS INT) AS individus_recenses,
    DEPT
  FROM table_individu
    WHERE AGED >= 100
  GROUP BY DEPT
  ORDER BY individus_recenses DESC
  `
  )
)

Associer à d’autres sources de données

Le code officiel géographique (COG) est utile pour illuster l’ajout d’information annexe. Le code commune va être utilisé pour associer les deux bases de données. Cette variable porte des noms différents dans les deux bases, ce qui n’est pas un problème.

Il est proposé, ci-dessous, de télécharger les données de manière reproductible, via une fonction adaptée (ici à travers le package requests pour Python ou via download.file en R). Bien que DuckDB permette l’import direct depuis un url, ceci implique l’installation en amont de l’extension httpfs.

L’association de sources de données passe généralement par un JOIN. Pour illustrer cette clause, il est possible d’associer les agrégats de la table logement à un niveau communal avec celles du COG grâce au code commune.

import requests
import os

url_cog = "https://www.insee.fr/fr/statistiques/fichier/6800675/v_commune_2023.csv"
if os.path.exists("cog.csv") is False:
  response = requests.get(url_cog)
  with open("cog.csv", mode="wb") as file:
      file.write(response.content)

url <- "https://www.insee.fr/fr/statistiques/fichier/6800675/v_commune_2023.csv"
download.file(url, "cog.csv")

```{ojs}
db2 = {
  const configuredClient = await db ;
  await configuredClient.query(
    `
    CREATE OR REPLACE VIEW cog2023 AS
    SELECT * FROM read_csv_auto('cog.csv', header = true)
    `
    )

  return configuredClient ;

}
```

```{ojs}
Inputs.table(
  db2.query(
    `
    SELECT cog2023.NCCENR, CAST(SUM(table_logement.IPONDL) AS INT) AS recenses
    FROM table_logement
    LEFT OUTER JOIN cog2023 ON table_logement.COMMUNE = cog2023.COM
    GROUP BY cog2023.NCCENR
    ORDER BY recenses;
    `
  )  
)
```

import requests
import os

url_cog = "https://www.insee.fr/fr/statistiques/fichier/6800675/v_commune_2023.csv"
if os.path.exists("cog.csv") is False:
  response = requests.get(url_cog)
  with open("cog.csv", mode="wb") as file:
      file.write(response.content)

duckdb.sql(
  'CREATE OR REPLACE VIEW cog2023 AS ' +\
  'SELECT * FROM read_csv_auto("cog.csv", header=true)'
)

duckdb.sql(
"""
SELECT cog2023.NCCENR, CAST(SUM(table_logement.IPONDL) AS INT) AS recenses
FROM table_logement
LEFT OUTER JOIN cog2023 ON table_logement.COMMUNE = cog2023.COM
GROUP BY cog2023.NCCENR
ORDER BY recenses;
"""
)

url <- "https://www.insee.fr/fr/statistiques/fichier/6800675/v_commune_2023.csv"
download.file(url, "cog.csv")

dbExecute(
  con,
  glue_sql(
    "CREATE OR REPLACE VIEW cog2023 AS ",
    "SELECT * FROM read_csv_auto("cog.csv", header=true)",
    .con=con
  )
)

query <- paste(
  "SELECT cog2023.NCCENR, CAST(SUM(table_logement.IPONDL) AS INT) AS recenses",
  "FROM table_logement",
  "LEFT OUTER JOIN cog2023 ON table_logement.COMMUNE = cog2023.COM",
  "GROUP BY cog2023.NCCENR ORDER BY recenses",
  sep = " "
)
dbGetQuery(con, query)

url <- "https://www.insee.fr/fr/statistiques/fichier/6800675/v_commune_2023.csv"
download.file(url, "cog.csv")

cog <- tbl(con, glue('read_csv_auto("{path_data}/cog.csv", header = true)'))

table_logement %>%
  left_join(cog, by = c("COMMUNE" = "COM")) %>%
  group_by(NCCENR) %>%
  summarise(recenses = as.integer(sum(IPONDL)), .groups = "drop") %>%
  arrange(recenses)

proxy = "https://corsproxy.io/?"
url_cog = "https://www.insee.fr/fr/statistiques/fichier/6800675/v_commune_2023.csv"
db2 = {
  const configuredClient = await db ;
  await configuredClient.query(
    `
    CREATE OR REPLACE VIEW cog2023 AS
    SELECT * FROM read_csv_auto('${proxy + url_cog}', header = true)
    `
    )

  return configuredClient ;

}

Les données du code officiel géographique présentent l’aspect suivant :

Inputs.table(
  db2.query(`SELECT * FROM cog2023 LIMIT 10`)
)

Voici par exemple le résultat d’une fusion avec une agrégation produite à la volée sur la table logement :

Inputs.table(
  db2.query(
    `
    SELECT cog2023.NCCENR, CAST(SUM(table_logement.IPONDL) AS INT) AS recenses
    FROM table_logement
    LEFT OUTER JOIN cog2023 ON table_logement.COMMUNE = cog2023.COM
    GROUP BY cog2023.NCCENR
    ORDER BY recenses;
    `
  )  
)

Contexte

L’écosystème de la data science est en mouvement accéléré depuis 10 ans et le rôle du data scientist dans les organisations valorisant de la donnée évolue continuellement (Davenport et Patil 2022). Les data scientists modernes sont amenés à utiliser de plus en plus de langages et doivent être capables de maîtriser plusieurs architectures informatiques. La frontière est ainsi moins nette que par le passé entre statisticiens et informaticiens. De plus, les innovations récentes dans le monde du développement logiciel, notamment l’adoption massive de l’approche DevOps - approche qui consiste à automatiser la production de livrables dès la conception du prototype - a également fait évoluer les pratiques des data scientists.

Ce besoin de ressources informatiques croissantes, de flexibilité dans le prototypage de solutions informatiques et l’évolution des pratiques consistant à mettre à disposition en continu des livrables ont eu des implications importantes sur les architectures informatiques dominantes dans l’écosystème de la donnée. Pour répondre au besoin croissant de puissance de traitement, les serveurs partagés, organisés sous forme de clusters, se sont développés dans de nombreuses organisations. Après avoir connue son heure de gloire au début des années 2010, l’infrastructure HDFS (Hadoop Distributed File System), qui reposait sur des clusters où les données et la puissance de traitement étaient distribuées et collocalisées, a laissé place à des infrastructures plus scalables, basées sur l’approche de la conteneurisation.

De HDFS à la conteneurisation

La conteneurisation, qui repose sur l’idée que les serveurs de stockage de la donnée peuvent être dissociés de ceux effectuant les traitements, sert de fondement aux principales plateformes cloud actuelles fournissant des services à la demande.

Ce nouveau paradigme part de deux constats. Le premier est que les échanges de données entre les noeuds d’un serveur sont aujourd’hui peu coûteux. Avec des flux réseaux suffisants et une technologie performante, il est donc possible d’échanger à un coût modéré de gros volumes de données au sein d’une infrastructure. Le deuxième constat est que la maintenance d’une infrastructure conteneurisée, faite pour être très malléable, est plus légère que celle d’une infrastructure basée sur des machines virtuelles ou sur les infrastructrures calibrées pour l’analytique big data comme HDFS reposant sur la collocalisation des données et des traitements¹.

Les données étant stockées sur des serveurs différents de ceux exécutant les traitements, l’accès à celles-ci se fait à travers des API qui permettent de traiter le système de stockage distant comme un système de fichiers classique. Onyxia a adopté une implémentation open source du système de stockage S3 appelée MinIO.

En ce qui concerne le traitement des données, le fait d’utiliser un système de conteneurs, c’est-à-dire une configuration logicielle portable minimaliste prête à l’emploi (par opposition aux machines virtuelles qui impliquent un système d’exploitation complet), offre une grande liberté sur le choix des logiciels de traitement. De nombreuses technologies open source devenues standards dans le monde de la data science (Jupyter, RStudio, ElasticSearch…) existent déjà sous cette forme et peuvent ainsi être adoptées dans une telle infrastructure pour fournir des services prêts-à-l’emploi pour les data scientists. La mise en musique de toutes ces petites boites auto-suffisantes, notamment l’optimisation des ressources concurrentes sur un serveur, est permise par la technologie d’orchestration Kubernetes.

La solution Onyxia

Onyxia en bref

Onyxia propose principalement deux composants de valeur :

• une interface web qui agit comme la porte d’entrée du data scientist sur son datalab, lui facilitant l’accès aux technologies cloud et lui permettant de démarrer ses environnements de traitement de la donnée. L’interface ergonomique permet aux utilisateurs de données néophytes de démarrer des services standardisés sans se préoccuper de la configuration mais aussi aux data scientists plus aguerris de bénéficier de vastes possibilités de personnalisation du service.
• des catalogues de logiciels : une petite vingtaine de services interactifs dont les plus utilisés sont RStudio, Jupyter, VScode, une quinzaine de services spécialisés dans les bases de données (Postgres, ElasticSearch…), 5 services d’automatisation (MLflow…) et 2 services de dataviz (Redash et Superset)

Le catalogue des services disponibles dans Onyxia.

Ces deux composants peuvent être adaptés en fonction des besoins internes de chaque organisation. Tous les services interactifs sont automatiquement connectés à l’espace de stockage S3, et au coffre de secret Vault. La gestion des droits d’accès aux données stockées dans l’espace de stockage S3 ou dans des services de bases de données (ElasticSearch, PostGreSQL…) est automatisée afin que chaque service puisse accéder aux données sur lesquelles l’utilisateur détient des droits.

Onyxia étant un ensemble malléable de logiciels conteneurisés, il est possible de ne pas adopter l’ensemble des services proposés par l’équipe de l’Insee qui maintient Onyxia. Il est également possible de changer certaines des briques de base pour l’adapter à des éléments d’infrastructure interne. Par exemple, il est possible d’adapter la destination du service de stockage ou les configurations des environnements data science pour l’adapter à des ressources.

L’interface et les services proposés par Onyxia

L’une des principales forces d’Onyxia est d’offrir une multiplicité de services différents avec une interconnexion entre eux gérée de manière cohérente.

Les conteneurs sont démarrés comme des services à la demande et la configuration automatique de ceux-ci permet d’assurer aux data scientists l’accès aux données disponibles dans des espaces de stockage ou des bases de données créées par l’utilisateur.

Le catalogue de services se présente par le biais d’un formulaire ergonomique où l’utilisateur choisit la brique qu’il désire utiliser:

Les data scientists et statisticiens n’ont donc pas besoin de connaître les détails du fonctionnement des briques techniques d’Onyxia pour utiliser la plateforme. Les éléments techniques comme la connexion au système de stockage sont, par défaut, déjà configurés :

L’interface ergonomique permet de paramétrer certaines configurations si besoin, notamment les ressources à disposition du conteneur. Néanmoins l’allocation dynamique des ressources offre déjà de la flexibilité :

L’utilisateur a accès à l’ensemble des services qu’il a ouvert depuis une page dédiée :

Les services interactifs comme Jupyter, VSCode ou RStudio permettent alors à l’utilisateur d’accéder à une interface pour exécuter des traitements Python ou R.

L’accès aux données peut se faire depuis la ligne de commande (via un utilitaire Minio Client) ou par un package Python ou R dédié qui permet de traiter le système de stockage distant comme un système local. Les traitements sont exécutés sur les serveurs de la plateforme qui héberge les notebooks, indépendamment de la machine par laquelle l’utilisateur accède au service. Par exemple, dans le cas du SSPCloud, les traitements sont exécutés depuis des serveurs hébergés à l’Insee.

La communauté Onyxia

Tous les composants sont proposés en open source par l’Insee ce qui permet de fédérer une communauté d’utilisateurs et de développeurs de ce produit. Il s’agit d’un bel exemple de mutualisation au sein de l’État et au delà. Les dépôts peuvent être retrouvés sur le Github de l’équipe innovation (celui de l’interface web, celui des images pour la data-science…). La communauté peut proposer de nouveaux services dans le catalogue.

Cette approche bottom up a déjà permis d’adapter des services aux besoins des utilisateurs ou d’améliorer la solution grâce à des retours des ré-utilisateurs d’Onyxia.

Les plateformes basées sur Onyxia

La plateforme d’origine, le SSPCloud, est ouverte à tous les agents de l’État et à plusieurs écoles. Celle-ci est exclusivement limitée à l’exploitation de données open data. Cette stratégie d’offreur de services de traitement sur l’open data permet de montrer l’expertise de l’Insee sur les sujets data science.

Les principaux usages de cette plateforme sont les suivants :

• la formation ;
• l’organisation de hackathons ;
• la mise à disposition de services innovants et visualisations utilisant de l’open data ;

Grâce à la mise à disposition de la solution Onyxia sur Github, il est néanmoins possible d’adapter cette plateforme pour des datalab internes, sur données plus sensibles.

L’Insee n’est donc désormais plus seul et fédère de nombreux acteurs autour de son projet. Fin 2021, Eurostat a été la première organisation en dehors de l’Insee à choisir Onyxia pour construire son Cloud Agnostic Data Lab. Expertise France pour le projet DATAFID a fait le choix d’Onyxia tout comme le CASD, le GENES ou encore le BercyHub avec le projet Nubonyxia.

D’autres organisations sont plus dans une phase de POC ou d’étude : l’INS norvégien, Pole Emploi, Data4Good, le ministère de l’Intérieur, le ministère de la Justice, l’Inria…

Dans le cadre du TOSIT, association qui réunit de gros acteurs publics et privés autour de solutions open source, un certain nombre d’entreprises s’intéressent à Onyxia.

Vidéo de présentation d’Onyxia

Références

Les secrets de la performance

Les benchmarks disponibles sont clairs : Polars est un ours qui court vite !

Le benchmark suivant, effectué par H2O, propose un comparatif de la vitesse des principaux frameworks de manipulation de données pour effectuer une agrégation par groupe avec un jeu de données de 50GB:

Polars devance des solutions connues pour leur efficacité sur ce type d’opérations, comme le package R data.table. L’utilisateur habituel de Pandas ne pourrait même pas traiter ces données, qui excèdent les capacités computationnelles de sa machine.

import polars as pl

# Création d'une requête
q = (
    pl.scan_csv("iris.csv") # Lecture lazy
    .filter(pl.col("sepal_length") > 5)
    .groupby("species")
    .agg(pl.all().sum())
)

# Exécution de la requête
df = q.collect()

df = pl.read_csv("iris.csv")

df_res = df.lazy() # ←  ici :)
  .filter(pl.col("sepal_length") > 5)
  .groupby("species")
  .agg(pl.all().sum())
  .collect()

# La même requête que tout à l'heure va lire le fichier "en flux"
df = q.collect(streaming=True)

Une API fluide

C’est un reproche régulièrement fait à Pandas : la syntaxe de manipulations des données est parfois complexe ou peu lisible, et les choix d’écriture ne sont pas transparents du point de vue des performances.

L’API proposée par Polars est à la fois expressive et transparente. Voici un exemple d’exploitation de la BPE, issu du notebook accompagnant ce post :

df.lazy()
  .filter(
    pl.col("TYPEQU") == "B316"
  )
  .groupby("DEP")
  .agg(
    pl.count().alias("NB_STATION_SERVICE")
  )
  .collect()

On retrouve une sémantique d’opérations de haut niveau qui s’enchaînent à la manière de ce que l’on peut faire en dplyr.

Les autres concurrents

Pandas et Polars ne sont pas seuls dans le grand zoo de la manipulation de données en Python : des solutions comme Vaex ou Dask ont des arguments à faire valoir. DuckDB, un autre framework de manipulation de données, s’intègre quand à lui très bien avec Polars dans la ménagerie.

Le duo DuckDB-Polars illustré par Dall-E-2

Ressources supplémentaires

• Awesome Polars par Damien Dotta (INSEE)
• Polars pour R
• rhosignal.com/tags/polars/
• kevinheavey.github.io/modern-polars/

Le notebook accompagnant ce post:

L’année du réseau

Le réseau comporte deux canaux de communication: une liste de diffusion mail et un canal de discussions instantanées. Intéressons nous d’abord à la liste de diffusion mail !

Pendant l’année 2022, 7 newsletters ont été diffusées par mail. Chacune a permis d’augmenter sensiblement le nombre de personnes dans la liste de diffusion. A la fin de l’année, il y avait 312 inscrits¹ dans la liste de diffusion.

Le réseau a organisé trois événements pendant l’année 2022. D’abord, avant l’été, deux open hours ont eu lieu. Cet événement informel prenant la forme de retour d’expérience a été l’occasion de discussions stimulantes autour de d’usage de la data science pour l’administration. En novembre, l’événement autour d’Observable animé par Nicolas Lambert a réuni près de 50 personnes.

Répartition des modes d’accès au réseau

Le réseau propose deux canaux de diffusion de l’information: une liste de diffusion par mail et un canal de discussion instantanée qui utilise la messagerie sécurisée de l’Etat Tchap. Environ 55% des membres de la liste de diffusion (soit plus de 180 personnes) sont également inscrits sur le canal de discussion instantanée.

Composition du réseau

La diffusion d’informations par le réseau a permis de réunir des data scientists de 27 organisations différentes. L’Insee, qui représente 47% de l’effectif du réseau, est majoritaire. Suivent dans le palmarès, les services statistiques du Ministère de la Santé (DREES) et du Ministère du Développement Durable (SDES).

Évolution de la composition du réseau

La diffusion progressive d’informations par le biais des newsletters a permis de diversifier progressivement la composition de la liste de diffusion. Alors que la première newsletter de l’année 2022 avait été diffusée auprès de 14 institutions, ce sont des agents de 27 organisations qui ont reçues la dernière.

Les événements organisés par le réseau ou les présentations spéciales, comme celle pour les administrateurs de l’INSEE en poste à l’ENSAE, ont également pu motiver des personnes à intégrer le réseau.

Programme 10%

Les membres du réseau des data scientists ont été particulièrement actifs dans le cadre du programme interministériel 10%, issu des recommandations d’un rapport INSEE-DINUM “Évaluation des besoins de l’État en compétences et expertises en matière de donnée”.

La saison 1 a donné sa chance à quatre projets, portés par différentes administrations. Si l’un d’eux existait déjà depuis plus de deux ans (projet Gouvdown), trois sont nés pour l’occasion, avec la mise en ligne de code immédiate (Cartiflette) ou postérieure au bootcamp de lancement (Socratext et matchSIRET) .

Tous les projets sont ouverts et disponible sur Github. Une statistique qui permet de représenter leur succès est le nombre de ⭐: c’est un peu un mélange entre un site en favori sous Firefox puisque cela permet de facilement retrouver un projet dans Github et le nombre de followers d’une page sur Facebook ou sur Twitter puisque cela permet de suivre l’activité d’un dépôt Github.

Autres actualités du réseau

Les IA créatrices de contenu à l’honneur

Si l’année 2022 a été particulièrement riche dans le domaine de la data science, c’est principalement grâce à deux coups médiatiques d’OpenAI, à savoir Dall-E et ChatGPT.

Ces deux outils ont beaucoup fait parler d’eux, au-delà de la sphère traditionnelle de la data science. Le buzz a été intense sur Twitter ou sur Mastodon, le réseau social dont le nombre d’utilisateurs a nettement augmenté en réaction au rachat de Twitter par Elon Musk en fin d’année.

Ces innovations, parce qu’elles pourraient avoir des effets à long terme sur la manière dont le grand public appréhende l’intelligence artificielle, ont beaucoup intéressé les médias traditionnels, notamment Le Monde, The Economist et sa “Nouvelle Frontière” ou le Guardian qui s’interroge sur la nature des tâches que l’intelligence artificielle pourra remplacer à terme : procédurales et régies par des règles bien définies ou bien également des activités nécessitant de la créativité et des capacités d’analyse ?

Pour une fois, il ne s’agit donc pas de souligner exclusivement les limites de ces modèles voire leurs dérives (deep fake, biais racistes…) mais aussi de s’enthousiasmer sur leur potentiel créatif. Il est difficile de rester insensible à certaines des créations artistiques des modèles Dall-E, Stable Diffusion, Midjourney et consorts ou de résister à la tentation de tester la capacité de ChatGPT à répondre à des questions complexes Les chercheurs, et pas des moindres (notamment Andrew Ng ou Gaël Varoquaux) se sont également saisis de cette question et ont souligné les biais de raisonnement et excès de confiance de ces IA.

Si vous désirez utiliser Python de manière créative pour générer du contenu avec Stable Diffusion, vous pouvez consulter ce tutoriel qui fonctionne sur le SSPCloud ou sur Google Colab.

Le succès des modèles de diffusion

Ces IA génératrices de contenu reposent toutes, à plusieurs niveaux, sur des réseaux de neurone.

Le premier étage de la fusée est un modèle de langage (large language model) qui synthétise un langage en un ensemble complexe de paramètres. Les plus connus sont BERT et GPT-3. L’inflation dans le nombre de paramètres n’est pas prête de s’arrêter. Si les ressources nécessaires à entraîner en 2018 le modèle BERT (110 millions de paramètres) avaient déjà été critiquées en raison de leur coût financier et environnemental, cette complexité a encore augmenté depuis. Le modèle GPT-3, sorti en 2020, et qui sert de base à Dall-E et ChatGPT intègre 175 milliards de paramètres. Un chiffre qui apparaît minime par rapport aux 17O trillions de paramètres attendus pour le modèle GPT-4 en 2023.

En ce qui concerne les IA créatrices de contenu visuel, le deuxième étage de la fusée est un modèle d’analyse d’image qui apprend à associer des images à une description textuelle afin de détecter des structures communes entre des mots ou des séquences de mots et des formes sur des images. Il s’agit de déconstruire une forme en une structure minimale de pixels qui permet de l’identifier.

Ensuite, pour générer une image à partir d’une description inédite intervient le modèle de diffusion qui reconstruit une image à partir du mélange de l’ensemble des pixels qui traduisent les concepts principaux d’une instruction. L’une des explications les plus pédagogiques pour comprendre le fonctionnement de ces modèles vient du Washington Post.

Sinon, on peut demander directement à ChatGPT de nous expliquer:

L’actualité dans le monde du deep learning

Si le succès d’estime de ces IA génératrices consacre les modèles de diffusion, l’année du deep learning ne se réduit pas à cette actualité.

L’année a notamment été marquée par la compétition entre les librairies et écosystèmes TensorFlow, développé par Google, et PyTorch projet initié par Facebook/Meta. PyTorch, plus récent, bénéficie d’une dynamique plus ascendante que TensorFlow. Le succès d’HuggingFace, plateforme de mise à disposition de modèles, et où les implémentations PyTorch sont systématiques alors que celles en TensorFlow sont rares a participé à la diffusion de PyTorch.

Preuve du succès de PyTorch, cet écosystème est dissocié de Meta depuis septembre afin de devenir un outil généraliste géré par la Linux Foundation. À l’inverse, Google semble se détacher graduellement de TensorFlow pour privilégier son nouvel écosystème JAX.

Du changement côté RStudio

Depuis quelques années, RStudio a fait le choix de devenir un écosystème de data science généraliste et non plus exclusivement attaché au langage R.

Cette année, cela s’est traduit par la publication, très commentée, de Quarto qui vise à proposer, dans de nombreux langages de programmation, des fonctionalités de publications reproductibles équivalentes à l’un des produits emblématiques de RStudio, à savoir R Markdown. Rien de mieux pour être convaincu de l’intérêt de cet outil que d’observer la galerie d’exemples, d’explorer la documentation très riche, ou de tester soi-même sur un exemple. Cet été, RStudio a également annoncé que Shiny, un autre produit emblématique, serait maintenant disponible sous Python, comme alternative à Dash ou Streamlit.

L’année 2022 a été l’occasion, pour RStudio, d’un autre changement, symbolique celui-ci. Afin de détacher son image du langage R, l’entreprise a en effet changé de nom pour devenir posit. L’entreprise n’a néanmoins pas abandonné son activité foisonnante dans R puisque Hadley Wickham a commencé à publier de nouveaux chapitres pour une nouvelle édition augmentée de l’ouvrage de référence R For Data Science.

Observable devient un incontournable dans le monde de la dataviz

Pour permettre des visualisations interactives, cela fait plusieurs années que JavaScript est un incontournable et que le web assembly retient de plus en plus d’attention.

Les journaux traditionnels utilisent ainsi de plus en plus le data scrollytelling , cette technique de narration qui consiste à présenter des informations sous forme de récit interactif, en utilisant une combinaison de texte et de graphiques qui apparaissent et disparaissent en fonction des actions du lecteur. L’un des exemples les plus réussis des dernières années a sans doute été la visualisation du New York Times “How the virus got out”. Cette approche a également été adoptée par le Ministère de l’Agriculture pour diffuser les chiffrés clés du recensement agricole. Nos voisins anglais ne sont pas en reste puisque les derniers résultats du recensement sont proposés sur un site web remarquable de fluidité.

Afin de permettre une diffusion accrue de visualisations en JavaScript, Mike Bostock, déjà créateur de la librairie de dataviz de référence D3.js, est à l’origine de la plateforme observable, sorte de Github de la dataviz permettant du partage et de la réutilisation de notebooks réactifs. En cette année 2022, la plateforme a connu un véritable boom et est devenu un incontournable dans le domaine. L’une des raisons est l’ajout de fonctionalités qui permettent d’étendre le public cible au delà des développeurs web, déjà accoutumés à Javascript. Parmi les fonctionalités les plus remarquables, la possibilité depuis Novembre d’utiliser des requêtes SQL grâce à DuckDB permet aux habitués de R ou de Python de retrouver des manipulations auxquels ils sont habitués. La librairie Plot offre une grammaire proche de ggplot2.

La communauté des cartographes a été particulièrement active sur Observable, notamment à l’occasion du #30daymapchallenge. Nicolas Bertin (neocarto), dont on ne peut que recommander l’introduction à Observable faite pour le réseau, ou Eric Mauvière font partie des comptes à suivre dans la communauté francophone.

Observable, en tant que langage construit sur JavaScript, est également disponible pour les utilisateurs de Quarto, ce qui permet de mettre à disposition des visualisation réactives sans passer nécessairement par la plateforme observablehq.com pour mettre à disposition des visualisations réactives, ce qui constitue une alternative intéressante aux applications qui nécessitent un serveur en arrière plan, comme Shiny ou Dash.

Les autres actualités en France

Le rapport du conseil d’État pour la construction d’une IA de “confiance” a donc été publié en une année 2022 où les avancées techniques des dernières années commencent à être accessibles grâce à des outils plus grand public, ce qui va nécessairement soulever des enjeux éthiques et juridiques.

Le projet Onyxia, qui vise à proposer une infrastructure de data science à l’état de l’art pour data scientists, a organisé son deuxième Openlab. L’occasion de revenir sur le projet, sa philosophie, ses dernières avancées mais aussi d’échanger sur les perspectives de réutilisation dans de multiples environnements et de nouer des partenariats qui permettront au projet de grandir encore en 2023.

Traiter un texte comme une information numérique : les approches possibles

Construction d’un plongement lexical

Un plongement lexical se construit en parcourant un grand corpus de textes et en repérant les mots qui apparaissent souvent dans le même contexte. L’ensemble des articles Wikipedia est un des corpus de prédilection des personnes ayant construit des plongements lexicaux. Il comporte en effet des phrases complètes, contrairement à des informations issues de commentaires de réseaux sociaux, et propose des rapprochements intéressants entre des personnes, des lieux, etc.

Le contexte d’un mot est défini par une fenêtre de taille fixe autour de ce mot. La taille de la fenêtre est un paramètre de la construction de l’embedding. Le corpus fournit un grand ensemble d’exemples mots-contexte, qui peuvent servir à entraîner un réseau de neurones.

Plus précisément, il existe deux approches :

• Continuous bag of words (CBOW), où le modèle est entraîné à prédire un mot à partir de son contexte ;
• Skip-gram, où le modèle tente de prédire le contexte à partir d’un seul mot.

Bonus : le plongement lexical en version ludique

Le résultat d’un plongement lexical peut avoir de nombreux usages. Il rend notamment possible le calcul de la proximité entre deux mots quelconques.

Une manière de procéder est de calculer la similarité cosinus entre les vecteurs de plongement des deux mots. Plus précisément, la similarité entre deux mots de représentations vectorielles \(u\) et \(v\) est définie comme le cosinus de leur angle \( \) :

Le calcul de la proximité entre les mots est à la base du jeu cemantix. Le principe est proche du jeu Wordle mais s’en distingue sur un point : il y a certes un mot à trouver chaque jour et il s’agit de faire des propositions de mots mais le jeu répond en donnant la proximité entre les mots proposés et le mot du jour. Ainsi, au fil des propositions, on a une vision de plus en plus précise du champ lexical associé au mot mystère, jusqu’à finalement le trouver.