Benjamin Geer

Optimiser des requêtes PostgreSQL avec un jeu de données ouvert

Tue, 10 Mar 2026 13:49:30 +0100

Aperçu #

Ce billet illustre brièvement quelques techniques d’optimisation des bases de données, en utilisant la BRÉF (Base Révisée des Élu·es de France), qui contient des données sur les représentant·es élu·es en France de 1948 à 2020. La BRÉF est basée sur des données publiques, dans lesquelles une équipe de chercheurs a corrigé beaucoup d’erreurs et d’incohérences. Elle est publiée sous la forme d’une base de données PostgreSQL qui comprend plusieurs tables et offre beaucoup de possibilités de jointures et d’optimisations.

J’utiliserai ici cette base de données pour développer et optimiser une requête SQL comprenant plusieurs jointures, pour obtenir des informations sur les maires et les communes où elles et ils ont été élu·es. Je construirai la requête à partir d’éléments plus simples, que j’optimiserai au fur et à mesure. Dans le cadre de cet exercice, je pars du principe que nous ne pouvons pas modifier le schéma de la base de données et que nous sommes prêts à payer un certain coût, en espace de stockage et en termes de performances de mise à jour, pour améliorer les performances des requêtes (d’autant plus que la base de données n’est pas très grande et que les mises à jour sont rares). Je me concentrerai donc sur ce que nous pouvons faire en créant des index. Pour identifier et tester des optimisations possibles, nous aurons deux sources d’information :

Les plans d’exécution de PostgreSQL, que nous pouvons obtenir en utilisant la commande EXPLAIN.
Des tests de performance exécutés par mon outil sqlstopwatch, qui exécute des requêtes à maintes reprises et indique le temps de réponse moyen de chaque requête.

Optimiser une requête simple #

Dans la terminologie du BRÉF,

le mandat correspond à la position élective (député, sénateur, etc.) tandis que le terme fonction recouvre une fonction exécutive dans le cadre d’un mandat. Ainsi, une personne peut être élue à la position de conseiller·e municipal·e, puis à celle de maire au sein de ce conseil municipal.

Il y a donc des tables qui s’appellent Mandate et Function et nous commencerons par celles-ci.

Trouvons d’abord toutes les fonctions de type MAIRE. Nous utiliserons EXPLAIN ANALYZE pour que Postgres exécute la requête, puis affiche le plan d’exécution (EXPLAIN) en indiquant le temps nécessaire à son exécution (ANALYZE).

EXPLAIN ANALYZE
SELECT "MandateId"
FROM "Function"
WHERE "FunctionType" = 'MAIRE'

QUERY PLAN
Seq Scan on "Function"  (cost=0.00..5596.96 rows=113829 width=4)
  (actual time=0.010..17.567 rows=114192 loops=1)
  Filter: (("FunctionType")::text = 'MAIRE'::text)
  Rows Removed by Filter: 158845
Planning Time: 0.217 ms
Execution Time: 20.136 ms

Le plan d’exécution est un arbre et chaque node a un coût estimé dont les unités sont arbitraires. Il faut noter que « le coût d’un nœud père comprend le coût de tous ses fils ». Seq Scan veut dire que la base de données parcourt toute la table Function à la recherche de chaînes correspondantes. Pour éviter cela, créons un index sur la colonne FunctionType, puis exécutons EXPLAIN ANALYZE à nouveau avec la même requête. (Dans cet exercice nous nous limiterons à utiliser des index de type B-Tree, que la commande CREATE INDEX utilise par défaut.)

1
2
3

CREATE INDEX index_function ON "Function" (
    "FunctionType"
)

Il en résulte un plan d’exécution différent :

QUERY PLAN
Bitmap Heap Scan on "Function"  (cost=1286.60..4893.46 rows=113829 width=4)
  (actual time=3.764..11.449 rows=114192 loops=1)
  Recheck Cond: (("FunctionType")::text = 'MAIRE'::text)
  Heap Blocks: exact=822
  ->  Bitmap Index Scan on index_function
      (cost=0.00..1258.14 rows=113829 width=0)
      (actual time=3.589..3.589 rows=114192 loops=1)
        Index Cond: (("FunctionType")::text = 'MAIRE'::text)
Planning Time: 0.314 ms
Execution Time: 13.551 ms

Postgres a effectué un parcours de bitmap, que Tom Lane, un des développeurs de Postgres, a expliqué dans ce message publié sur une liste de diffusion.

Un parcours de bitmap récupère tous les pointeurs de n-uplets de l’index en une seule fois, les trie en mémoire à l’aide d’une structure de données appelée « bitmap », puis visite les n-uplets de la table dans l’ordre physique de leur emplacement… Si le bitmap devient trop volumineux, nous le convertissons en bitmap « avec perte », dans lequel nous ne notons que les pages contenant des n-uplets correspondants au lieu de noter chaque n-uplet individuellement. Dans ce cas-là, quand nous lisons ces pages de la table, il faut examiner chaque n-uplet de chaque page lue et revérifier la condition du parcours pour déterminer les n-uplets à renvoyer.

Ceci est plus efficace qu’un parcours de table, mais nous payons toujours le prix de l’accès à la table pour récupérer les n-uplets (c’est-à-dire les lignes) et celui de la revérification de la condition du parcours. Comme il ne nous faut que la colonne MandateId, nous pouvons la mettre elle aussi dans l’index, pour créer un index couvrant pour cette requête :

CREATE INDEX index_function ON "Function" (
    "FunctionType"
)
INCLUDE (
    "MandateId"
)

Cela nous donne un autre plan d’exécution :

QUERY PLAN
Index Only Scan using index_function on "Function"
  (cost=0.42..4490.35 rows=115003 width=4)
  (actual time=0.027..7.354 rows=114192 loops=1)
  Index Cond: ("FunctionType" = 'MAIRE'::text)
  Heap Fetches: 0
Planning Time: 0.184 ms
Execution Time: 9.025 ms

Maintenant Postgres peut faire un parcours d’index seul, parce que toutes les colonnes qu’il nous faut sont dans l’index. Cela semble être une amélioration, mais faisons un test de performance pour vérifier. Testons plusieurs requêtes qui cherchent différentes fonctions, y compris celle de maire. Nous ferons le test d’abord sans index, puis avec chacun des index ci-dessus.

SELECT "MandateId"
FROM "Function"
WHERE "FunctionType" = 'MAIRE'
FETCH FIRST 750 ROWS ONLY

SELECT "MandateId"
FROM "Function"
WHERE "FunctionType" = 'MAIRE DELEGUE'
FETCH FIRST 750 ROWS ONLY

SELECT "MandateId"
FROM "Function"
WHERE "FunctionType" = 'PRESIDENT DU CONSEIL REGIONAL'
FETCH FIRST 750 ROWS ONLY

SELECT "MandateId"
FROM "Function"
WHERE "FunctionType" = 'PREMIER ADJOINT AU MAIRE'
FETCH FIRST 750 ROWS ONLY

Il est clair qu’il vaut mieux avoir un index que ne pas en avoir. Par rapport à l’index qui ne contient que FunctionType, celui qui comprend aussi MandateId (et permet donc un parcours d’index seul) ne change pas grand-chose pour certaines valeurs de FunctionType, mais il est plus de deux fois plus rapide pour MAIRE.

Trier #

Nous aimerions obtenir des résultats triés par date de début de fonction :

EXPLAIN ANALYZE
SELECT "MandateId"
FROM "Function"
WHERE "FunctionType" = 'MAIRE'
ORDER BY "FunctionStartDate"

Sans index, la base de données indique que cette requête prend environ deux fois plus de temps que sans le tri :

QUERY PLAN
Sort  (cost=15354.29..15644.28 rows=115995 width=8)
      (actual time=32.564..37.109 rows=114192 loops=1)
  Sort Key: "FunctionStartDate"
  Sort Method: external merge  Disk: 2016kB
  ->  Seq Scan on "Function"
      (cost=0.00..5596.96 rows=115995 width=8)
      (actual time=0.016..17.797 rows=114192 loops=1)
        Filter: (("FunctionType")::text = 'MAIRE'::text)
        Rows Removed by Filter: 158845
Planning Time: 0.398 ms
Execution Time: 40.132 ms

Il est intéressant de noter que si nous utilisons l’index de la section précédente avec cette requête, cela ne change pas le plan d’exécution cette fois-ci. Postgres a décidé que notre index n’apportera probablement pas d’avantage à cette requête. Pour que l’index vaille la peine d’être utilisé ici, ajoutons-y la colonne FunctionStartDate, pour que les entrées pour chaque type de fonction soient triées par date de début dans l’index :

CREATE INDEX index_function ON "Function" (
    "FunctionType",
    "FunctionStartDate"
)
INCLUDE (
    "MandateId"
)

QUERY PLAN
Index Only Scan using index_function on "Function"
  (cost=0.42..4743.89 rows=115995 width=8)
  (actual time=0.052..9.744 rows=114192 loops=1)
  Index Cond: ("FunctionType" = 'MAIRE'::text)
  Heap Fetches: 0
Planning Time: 0.432 ms
Execution Time: 12.275 ms

Cela nous donne à nouveau un parcours d’index seul, qui semble plus efficace. Faisons un test de performance pour comparer l’index précédent à celui-ci. Nous utiliserons les requêtes de la section précédente, en ajoutant ORDER BY "FunctionStartDate" à chacune d’elles.

Il semble que plus il y a de lignes à trier, plus il soit avantageux d’utiliser un index qui est déjà trié dans l’ordre demandé par la clause ORDER BY. Cet avantage est très important dans le cas de MAIRE (114 192 lignes) et PREMIER ADJOINT AU MAIRE (37 511 lignes) et moins important dans les autres cas, qui renvoient beaucoup moins de lignes.

Ajouter des jointures #

Maintenant que nous avons MandateId, nous pouvons récupérer des clés étrangères sur la ligne correspondante de la table Mandate, puis effectuer des jointures pour obtenir plus d’informations sur la personne qui a été élue et la commune où l’élection a eu lieu. Commençons par la commune. La table Area contient des données sur différents niveaux géographiques, y compris les communes. Avant de pouvoir nous renseigner sur la commune, nous devons obtenir son identifiant dans la table Mandate. Regardons d’abord le plan d’exécution d’une requête qui fait cela, sans l’exécuter :

EXPLAIN
SELECT
    func."FunctionStartDate",
    m."AreaId"
FROM 
    "Function" func,
    "Mandate" m
WHERE
    func."FunctionType" = 'MAIRE'
    AND func."MandateId" = m."MandateId"
ORDER BY func."FunctionStartDate"
FETCH FIRST 750 ROWS ONLY

QUERY PLAN
Limit  (cost=0.85..968.89 rows=750 width=36)
  ->  Nested Loop  (cost=0.85..147087.20 rows=113957 width=36)
        ->  Index Only Scan using index_function on "Function" func
            (cost=0.42..4664.34 rows=113957 width=8)
              Index Cond: ("FunctionType" = 'MAIRE'::text)
        ->  Index Scan using "pk_Mandat" on "Mandate" m
            (cost=0.43..1.25 rows=1 width=36)
              Index Cond: ("MandateId" = func."MandateId")

La base de données fait toujours un Index Only Scan pour la table Fonction, mais elle fait un Index Scan pour la table Mandate, en utilisant l’index de clé primaire de cette table. Cela veut dire qu’elle parcourt l’index jusqu’à ce qu’elle trouve le MandateId correspondant, puis récupère la ligne correspondante de la table Mandate pour obtenir l’AreaId. Nous pouvons créer un index qui contient AreaId pour effectuer un parcours d’index seul :

`1`	`CREATE INDEX index_mandate ON "Mandate" ("MandateId") INCLUDE ("AreaId")`

Voici le plan d’exécution qui en résulte :

QUERY PLAN
Limit  (cost=0.85..505.54 rows=750 width=10)
  ->  Nested Loop  (cost=0.85..76310.71 rows=113401 width=10)
        ->  Index Only Scan using index_function on "Function" func
            (cost=0.42..4643.26 rows=113401 width=8)
              Index Cond: ("FunctionType" = 'MAIRE'::text)
        ->  Index Only Scan using index_mandate on "Mandate" m
            (cost=0.43..0.63 rows=1 width=10)
              Index Cond: ("MandateId" = func."MandateId")

Il semble que le coût ait baissé. Faisons un test de performance, encore une fois avec différentes valeurs pour FunctionType, pour comparer l’index de clé primaire à l’index couvrant. Dans les deux cas nous garderons notre index le plus performant sur Function.

L’index couvrant ne fait pas une grande différence, mais semble toutefois utile.

Maintenant que nous avons l’AreaId de la commune, nous pouvons obtenir son nom et son code géographique (qui n’est pas la même chose que le code postal). Nous aimerions aussi avoir le nom de la personne qui a été élue.

SELECT
    func."FunctionStartDate",
    area."AreaCode" as code_commune,
    area."AreaName" as commune,
    indiv."FirstName",
    indiv."LastName"
FROM "Function" func
JOIN "Mandate" m ON func."MandateId" = m."MandateId"
JOIN "Area" area ON m."AreaId" = area."AreaId"
JOIN "Individual" indiv ON m."IndividualId" = indiv."IndividualId"
WHERE func."FunctionType" = 'MAIRE'
ORDER BY func."FunctionStartDate"
FETCH FIRST 100 ROWS ONLY

Comme il y a plusieurs jointures, j’ai utilisé le mot-clé JOIN pour que la requête soit un peu plus facile à lire. (Cela ne change pas le plan d’exécution.) Et comme la requête renvoie maintenant davantage de colonnes, j’ai demandé moins de lignes, pour que les résultats du test de performance ne soient pas dominés par le temps qu’il faut pour renvoyer les résultats de la requête.

Pour la jointure entre Mandate et Individual, nous ajoutons IndividualId à notre index sur Mandate :

1
2
3

CREATE INDEX index_mandate ON "Mandate" ("MandateId") INCLUDE (
    "AreaId", "IndividualId"
)

Puis nous créons des index couvrants sur Area et Individual pour notre requête :

CREATE INDEX index_area ON "Area" ("AreaId") INCLUDE ("AreaCode", "AreaName");

CREATE INDEX index_indiv ON "Individual" ("IndividualId") INCLUDE (
    "FirstName", "LastName"
);

Cela donne le plan d’exécution suivant :

QUERY PLAN
Limit  (cost=1.57..132.35 rows=100 width=38)
  ->  Nested Loop  (cost=1.57..148131.29 rows=113274 width=38)
        ->  Nested Loop  (cost=1.15..96170.50 rows=113274 width=34)
              ->  Nested Loop  (cost=0.85..82875.64 rows=113274 width=22)
                    ->  Index Only Scan using index_function on "Function" func
                        (cost=0.42..4636.71 rows=113274 width=8)
                          Index Cond: ("FunctionType" = 'MAIRE'::text)
                    ->  Index Only Scan using index_mandate on "Mandate" m
                        (cost=0.43..0.69 rows=1 width=22)
                          Index Cond: ("MandateId" = func."MandateId")
              ->  Memoize  (cost=0.30..0.32 rows=1 width=24)
                    Cache Key: m."AreaId"
                    Cache Mode: logical
                    ->  Index Only Scan using index_area on "Area" area
                        (cost=0.29..0.31 rows=1 width=24)
                          Index Cond: ("AreaId" = (m."AreaId")::text)
        ->  Index Only Scan using index_indiv on "Individual" indiv
            (cost=0.42..0.46 rows=1 width=28)
              Index Cond: ("IndividualId" = (m."IndividualId")::text)

Toutes les données viennent des index, les tables n’étant pas utilisés du tout. Si nous ne créons pas les deux derniers index, il y a des Index Scan plutôt que des Index Only Scan sur Area et Individual. Comparons la performance de cette requête avec et sans ces deux index.

Il y a très peu de différence, mais garderons les index.

Comparons maintenant la performance de cette dernière requête sans aucun index (à part les index de clé primaire qui ont été créés par défaut) et avec tous les index que nous avons créés :

Cette requête est 14 à 24 fois plus rapide avec les index que sans eux.

Encore plus de jointures #

Essayons de récupérer le nom du département auquel la commune appartient. Nous pouvons ajouter une jointure sur la table Inclusion pour trouver l’Area qui représente le département :

EXPLAIN
SELECT
    func."FunctionStartDate",
    area1."AreaCode" as code_commune,
    area1."AreaName" as commune,
    area2."AreaName" as departement,
    indiv."FirstName",
    indiv."LastName"
FROM "Function" func
JOIN "Mandate" m ON func."MandateId" = m."MandateId"
JOIN "Area" area1 ON m."AreaId" = area1."AreaId"
JOIN "Inclusion" incl on m."AreaId" = incl."IncludedAreaId"
JOIN "Area" area2 on incl."IncludingAreaId" = area2."AreaId"
JOIN "Individual" indiv ON m."IndividualId" = indiv."IndividualId"
WHERE func."FunctionType" = 'MAIRE'
AND area2."AreaType" = 'Département'
ORDER BY func."FunctionStartDate"
FETCH FIRST 100 ROWS ONLY

QUERY PLAN
Limit  (cost=35292.57..35304.24 rows=100 width=51)
  ->  Gather Merge  (cost=35292.57..35351.14 rows=502 width=51)
        Workers Planned: 2
        ->  Sort  (cost=34292.55..34293.18 rows=251 width=51)
              Sort Key: func."FunctionStartDate"
              ->  Nested Loop  (cost=30010.19..34282.96 rows=251 width=51)
                    ->  Parallel Hash Join  (cost=30009.76..34167.82 rows=251 width=47)
                          Hash Cond: (func."MandateId" = m."MandateId")
                          ->  Parallel Index Only Scan using index_function on "Function" func
                              (cost=0.42..3980.29 rows=47235 width=8)
                                Index Cond: ("FunctionType" = 'MAIRE'::text)
                          ->  Parallel Hash  (cost=29971.32..29971.32 rows=3042 width=47)
                                ->  Hash Join  (cost=2914.37..29971.32 rows=3042 width=47)
                                      Hash Cond: ((m."AreaId")::text = (area1."AreaId")::text)
                                      ->  Parallel Seq Scan on "Mandate" m
                                          (cost=0.00..24881.12 rows=572112 width=22)
                                      ->  Hash  (cost=2911.27..2911.27 rows=248 width=43)
                                            ->  Nested Loop
                                                (cost=967.16..2911.27 rows=248 width=43)
                                                  ->  Hash Join
                                                      (cost=966.88..2832.29 rows=248 width=19)
                                                        Hash Cond:
                                                        ((incl."IncludingAreaId")::text =
                                                         (area2."AreaId")::text)
                                                        ->  Seq Scan on "Inclusion" incl
                                                            (cost=0.00..1607.70
                                                             rows=98170 width=15)
                                                        ->  Hash
                                                            (cost=965.40..965.40
                                                             rows=118 width=19)
                                                              ->  Seq Scan on "Area" area2
                                                                  (cost=0.00..965.40
                                                                   rows=118 width=19)
                                                                    Filter:
                                                                    (("AreaType")::text =
                                                                    'Département'::text)
                                                  ->  Index Only Scan using index_area
                                                      on "Area" area1
                                                      (cost=0.29..0.32 rows=1 width=24)
                                                        Index Cond:
                                                        ("AreaId" =
                                                         (incl."IncludedAreaId")::text)
                    ->  Index Only Scan using index_indiv on "Individual" indiv
                        (cost=0.42..0.46 rows=1 width=28)
                          Index Cond: ("IndividualId" = (m."IndividualId")::text)

Qu’est-ce qui s’est passé ? Postgres a décidé qu’une jointure de hachage serait plus efficace que l’ajout d’une autre boucle imbriquée. Plutôt que d’utiliser notre index sur la table Mandate, il compte lire environ 500 000 lignes et les mettre dans une table de hachage en mémoire. Il utilise l’index trié par date sur Fonction, mais comme une table de hachage n’est pas triée, il doit ensuite trier les résultats à nouveau. En utilisant EXPLAIN ANALYZE, nous pouvons constater que la requête prend à peu près 600 ms. Le simple fait d’obtenir le nom du département a ralenti notre requête de plusieurs centaines de fois.

Nous avons plusieurs options :

Donner à l’optimiseur une meilleure option que la jointure de hachage.
Optimiser la jointure de hachage en demandant moins de colonnes (ce qui n’est pas vraiment possible dans notre cas) ou moins de lignes (nous pourrions, par exemple, ajouter une condition WHERE comme func."FunctionStartDate" < DATE '1975-01-01').
Effectuer la jointure dans l’application. Dans le cas présent, comme il n’y a que 101 départements en France et qu’ils changent très rarement, l’application pourrait les lire au démarrage. Le code géographique de chaque commune (que nous avons déjà obtenu avec la requête précédente) contient le code du département. Il serait donc facile pour l’application de chercher le département en mémoire.

Essayons la première option. Nous pouvons ajouter cet index :

1
2
3

CREATE INDEX index_inclusion ON "Inclusion" ("IncludedAreaId") INCLUDE (
    "IncludingAreaId"
);

Cela nous donne à nouveau un plan d’exécution à boucles imbriquées :

QUERY PLAN
Limit  (cost=1002.32..10605.10 rows=100 width=51)
  ->  Nested Loop  (cost=1002.32..58907.08 rows=603 width=51)
        ->  Gather Merge  (cost=1001.89..58630.47 rows=603 width=47)
              Workers Planned: 2
              ->  Nested Loop  (cost=1.87..57560.84 rows=251 width=47)
                    ->  Nested Loop  (cost=1.58..57476.99 rows=272 width=41)
                          ->  Nested Loop  (cost=1.28..53851.27 rows=107699 width=37)
                                ->  Nested Loop  (cost=0.85..36596.43 rows=47235 width=22)
                                      ->  Parallel Index Only Scan using index_function
                                          on "Function" func
                                          (cost=0.42..3980.29 rows=47235 width=8)
                                            Index Cond: ("FunctionType" = 'MAIRE'::text)
                                      ->  Index Only Scan using index_mandate on "Mandate" m
                                          (cost=0.43..0.69 rows=1 width=22)
                                            Index Cond: ("MandateId" = func."MandateId")
                                ->  Memoize  (cost=0.43..0.46 rows=2 width=15)
                                      Cache Key: m."AreaId"
                                      Cache Mode: logical
                                      ->  Index Only Scan using index_inclusion
                                          on "Inclusion" incl
                                          (cost=0.42..0.45 rows=2 width=15)
                                            Index Cond: ("IncludedAreaId" = (m."AreaId")::text)
                          ->  Memoize  (cost=0.30..0.34 rows=1 width=19)
                                Cache Key: incl."IncludingAreaId"
                                Cache Mode: logical
                                ->  Index Scan using "pk_Territoire" on "Area" area2
                                    (cost=0.29..0.33 rows=1 width=19)
                                      Index Cond:
                                      (("AreaId")::text = (incl."IncludingAreaId")::text)
                                      Filter: (("AreaType")::text = 'Département'::text)
                    ->  Index Only Scan using index_area on "Area" area1
                        (cost=0.29..0.31 rows=1 width=24)
                          Index Cond: ("AreaId" = (m."AreaId")::text)
        ->  Index Only Scan using index_indiv on "Individual" indiv
            (cost=0.42..0.46 rows=1 width=28)
              Index Cond: ("IndividualId" = (m."IndividualId")::text)

Le coût reste pourtant assez élevé, et EXPLAIN ANALYZE indique que la requête prend 12 ms environ. Un test de performance indique qu’elle peut être 10 à 20 fois plus lente que notre requête précédente :

Il serait plus efficace de garder la requête précédente et d’effectuer la jointure dans l’application.

Conclusion #

Cette exercice a démontré quelques points importants sur l’optimisation des bases de données :

À chaque fois que nous modifions une requête, il faut revérifier le plan d’exécution pour connaître l’effet de la modification sur les performances.
Des requêtes différentes peuvent avoir besoin d’index différents.
Un parcours d’index seul peut être le meilleur moyen d’améliorer la performance d’une requête dans certains cas, mais il faut vérifier cette hypothèse en la testant.
Parfois la meilleure optimisation est de demander moins de données.

Tous les scripts et les fichiers de configuration que j’ai utilisés pour cet exercice se trouvent dans ce dépôt git.

Pour en savoir plus sur ce sujet, je recommande le site web Use the Index, Luke! de Markus Winand, ainsi que son livre SQL : Au cœur des performances.

Comparer les performances de requêtes SQL

Thu, 29 Jan 2026 18:25:18 +0100

J’ai réalisé un petit programme en Rust, sqlstopwatch, pour comparer les performances de différentes requêtes SQL. J’ai été inspiré par l’article Benchmarking SQL publié par le projet jOOQ, dans lequel le code du test est implémenté en SQL. Je voulais quelque chose de semblable, mais j’avais quelques exigences supplémentaires :

Un programme en ligne de commande avec une interface utilisateur simple en mode texte (TUI) qui affiche une barre de progression.
Le programme devrait prendre en charge PostgreSQL, MySQL et SQLite.
Il devrait lire les requêtes SQL et les paramètres du test dans un fichier de configuration indiqué sur la ligne de commande.
Il devrait afficher les résultats sous forme de table dans le terminal ou les enregistrer dans un fichier au format CSV que je puisse utiliser pour générer un diagramme.

L’interface utilisateur a été facile à réaliser avec Ratatui. Pour interagir avec la base de données, j’ai utilisé la bibliothèque asynchrone sqlx, qui fournit une bibliothèque SQLite embarquée.

J’ai pensé à utiliser le format TOML pour le fichier de configuration, mais le fichier doit fournir les identifiants de connexion. Dans les environnements de test, il se peut que les identifiants doivent être chargés à partir de variables d’environnement ou de fichiers sur un système de fichiers monté, mais TOML ne permet pas d’effectuer de telles opérations. En plus, on pourrait vouloir générer plusieurs requêtes similaires pour les comparer, comme je l’ai fait dans ce projet d’optimisation de base de données. Par conséquent, il vaut mieux que le fichier de configuration soit un programme dans un langage de script. Mon exercice d’implémentation d’un interpréteur de langage de script m’avait permis d’apprécier à sa juste valeur la machine virtuelle Lua. Le fichier de configuration est donc un script en Lua, que je trouve plus commode de rédiger en Fennel, un dialect de Lisp qui se compile en Lua. Grâce à la bibliothèque mlua, il a été très facile d’embarquer un interpréteur Lua dans le programme et d’utiliser Serde pour convertir des tables Lua en structs Rust.

Créer un client Bittorrent en Rust

Thu, 15 Jan 2026 15:16:01 +0100

Aperçu #

Pour mon deuxième exercice d’apprentissage de Rust (après OrganicLox), j’ai décidé de réaliser un client pour Bittorrent, le protocole de transfert de données pair-à-pair. Les clients Bittorrent que j’ai utilisés ont des interfaces graphiques complexes qui semblent destinées aux gens qui téléchargent des torrents à longueur de journée, plutôt que pour l’utilisateur occasionnel comme moi, qui veut tout simplement obtenir un seul fichier. Et comme beaucoup d’applications à interface graphique, les clients Bittorrent ont tendance à accumuler des fichiers qui occupent de l’espace disque dans des répertoires obscurs. Je fais beaucoup de choses dans le terminal et quand j’ai besoin de télécharger un fichier, mon réflexe est d’utiliser curl. Je me suis donc dit, pourquoi ne pas créer quelque chose comme curl pour Bittorrent ? En pensant à l’indicateur de progression de curl, l’idée m’est venue à l’esprit de faire quelque chose de semblable avec Ratatui, une bibliothèque de création d’environnements en mode texte (TUI), que je voulais de toute façon essayer.

La réalisation d’un client Bittorrent semblait être une bonne occasion d’apprendre la programmation asynchrone en Rust. J’avais lu beaucoup de critiques d’async en Rust, mais je l’ai trouvé agréable à utiliser (en utilisant la bibliothèque Tokio) et certainement plus confortable que les infrastructures logicielles comparables que j’avais utilisées en Scala (Akka et Cats Effect). J’aime particulièrement le fait qu’une fonction async peut être exécutée dans une tâche existante ou dans sa propre tâche, à la différence du Future de Scala, qui est affecté à un fil d’exécution et se lance dès sa construction. L’approche de Rust semble mieux adapté au remaniement et à la maintenabilité. En même temps, je suis content de ne pas avoir à gérer la complexité liée à l’utilisation des monades comme dans Cats Effect.

Le résultat est Sayaca, qui porte le nom d’un oiseau sud-américain qui joue un rôle important dans la dispersion des graines (le verbe anglais to seed veut dire ensemencer, et dans la terminologie de Bittorrent, envoyer des données aux autres pairs).

La conception #

Ma première tâche a été de réaliser un analyseur syntaxique pour Bencode, le format de données utilisées dans le protocole Bittorrent. Au niveau conceptuel, Bencode ressemble à JSON, mais il est destiné à la représentation de données binaires plutôt que textuelles. J’avais envie d’essayer d’utiliser une bibliothèque de combinateurs d’analyseurs syntaxiques, et je n’ai pas eu de mal à implémenter l’analyseur en utilisant nom. Comme je voulais être en mesure de sérialiser et de désérialiser des structs en Rust au format Bencode, j’ai ajouté la prise en charge de la bibliothèque Serde. J’ai publié la crate issue de ce travail sous le nom de bside.

La principale difficulté dans la conception du client résidait dans le caractère confus des spécifications Bittorrent. Il y a des ambigüités (le mot piece a deux sens différents) et les implémentations se sont écartées des spécifications (par exemple, les identifiants de pair ne sont pas utilisés pour identifier les pairs). Une grande partie des informations relatives au protocole ne figure pas dans les spécifications officielles, mais dans d’autres documents dispersés sur le Web. Il y a une longue liste (non mise à jour depuis 2018) de projets d’extension du protocole qui sont pris en charge par de nombreux clients. Une extension dite de chiffrement (qui semble en réalité décrire une forme de brouillage) semble être largement mise en œuvre, mais d’après ce que je peux en juger, depuis 2023, sa spécification n’est conservée que dans la Wayback Machine de l’Internet Archive. Il existe un projet de spécification du protocole BitTorrent v2 (non mis à jour depuis 2017) qui tente de corriger certains défauts du protocole d’origine, comme sa dépendance vis-à-vis de la fonction de hachage SHA-1 (qui n’est plus considérée comme sécurisée depuis 2005). J’aurais pu errer longtemps dans un dédale de documents et dans le code source des clients existants. Pour simplifier les choses, j’ai décidé de ne mettre en œuvre que le protocole d’origine et l’extension IPv6 tracker.

Quand un client Bittorrent enregistre des données sur le disque, il devrait offrir de bonnes performances avec des fichiers volumineux, être capable d’interrompre un téléchargement et de le reprendre plus tard (ce qui signifie qu’il doit noter quels fragments ont été téléchargées) et gérer les torrents qui comprennent plusieurs fichiers. Pour faire tout cela, et pour que les choses soient claires pour l’utilisateur, j’ai choisi d’enregistrer les données téléchargées dans un fichier intermédiaire (avec l’extension .sayaca), dans le même répertoire où les fichiers finaux seront enregistrés. Le fichier intermédiaire contient un champ de bits indiquant les fragments qui ont été téléchargés (il s’agit du même champ de bits qu’il faut de toute façon envoyer aux pairs). Pour lire et écrire ce fichier, Sayaca utilise la projection en mémoire, ce qui devrait offrir de bonnes performances d’entrée-sortie avec des fichiers volumineux. Une fois le téléchargement terminé, il copie les données depuis le fichier intermédiaire vers les fichiers finaux. Lorsque le programme se ferme, le fichier intermédiaire est supprimé s’il n’est plus nécessaire.

Comme un client Bittorrent est tributaire des entrées-sorties (I/O bound), j’ai décidé d’employer une architecture événementielle dans laquelle une seule tâche accomplit la majeure partie du travail, comme dans Redis. Cette tâche principale délègue toute les entrées-sorties réseau à d’autres tâches, avec lesquelles elle communique via des canaux. Cela a été très simple à mettre en œuvre et a eu l’avantage de rendre facile la création de tests unitaires pour la tâche principale.

Une grande partie du travail effectué par un client Bittorrent revient à tenir une sorte de comptabilité. Dans Sayaca, ce travail est la responsabilité du Bookkeeper (« comptable »). Par exemple, dans l’algorithme recommandé de sélection des fragments à demander aux pairs, le client essaie de demander d’abord les fragments les plus rares. Cela nécessite une structure de données qui note les fragments dont dispose chaque pair, ainsi que la rareté de chaque fragment, entre autres. Il y a plusieurs façons de réaliser cela et j’ai décidé d’utiliser un tableau associatif ordonné, trié par ordre de rareté, pour stocker les identificateurs de fragments et les ensembles de pairs qui les possèdent. Le Bookkeeper peut ainsi trouver facilement un fragment, choisi au hasard parmi les plus rares, associé à un pair choisi au hasard parmi ceux qui possèdent ce fragment et qui nous ont autorisé à leur envoyer des demandes. Ainsi une grande partie du travail du client consiste à mettre à jour le Bookkeper lors de la réception de nouvelles informations et à l’interroger pour savoir ce qu’il faut faire ensuite.

J’aime bien les TUI et il a été facile de créer un TUI simple avec Ratatui. Mais comme le client est une bibliothèque qui communique avec son interface utilisateur via des canaux, il serait simple d’intégrer le client dans une autre interface utilisateur, comme une interface en ligne de commande plus accessible.

D’autres approches possibles #

J’ai choisi d’utiliser Tokio parce que je voulais en savoir plus à son sujet et sur async, mais je pense que le programme n’aurait probablement pas été très différent si j’avais utilisé des fils d’exécution à la place, avec la même communication via des canaux.

Mona Ja‘bub, Conduire la société vers le changement

Wed, 03 Dec 2025 00:00:00 +0000

[Version française du texte publié en espagnol.¹]

Mona Salem Said Ja‘bub, قيادة المجتمع نحو التغيير: التجربة التربوية لثورة ظفار (1969-1992) [Conduire la société vers le changement : l’expérience éducative de la révolution du Dhofar (1969-1992)], Beyrouth : مركز دراسات الوحدة العربية [Centre d’études de l’unité arabe], première édition 2010, deuxième édition 2023, 368 pages.

Ce premier livre de Mona Ja‘bub, historienne omanaise, a été salué dans le monde arabe pour son approche de l’histoire sociale et culturelle de la révolution du Dhofar en Oman. Publié par une maison d’édition arabe prestigieuse spécialisée dans les sciences sociales, le livre a d’abord été retiré par les autorités omanaises du Salon international du livre de Mascate en 2012, puis remis en vente le lendemain, signe d’un assouplissement de la censure. Il se concentre sur des questions de genre et de circulation des idées et, en se penchant sur des événements historiques peu connus en dehors du monde arabe, apporte une contribution originale à l’étude de la réception mondiale du maoïsme et du marxisme dans les années 1960 et 1970.

De 1968 à 1975, la province du Dhofar du Sultanat d’Oman a connu une révolution marxiste-léniniste contre le sultan Saïd et son successeur Qaboos, qui dépendaient de l’empire britannique. À l’époque, le Dhofar avait une économie de subsistance et sa population vivait dans une pauvreté extrême. Sur la côte il y avait des pêcheurs, sur la plaine il y avait un peu d’agriculture et surtout des arbres à encens, et dans les hautes terres on élevait du bétail. Même après le commencement de l’exportation du pétrole en 1967, l’État percevait des impôts sans fournir de services à la population : la médecine moderne était inconnue, la seule école était réservée à la cour du sultan et au Dhofar la majeure partie de la population et la quasi totalité des femmes étaient analphabètes. Dans le système tribal dhofari, les terres appartenaient à des tribus, non pas à des individus, et certaines tribus avaient plus de prestige que d’autres et portaient des armes. En bas de l’échelle sociale il y avaient des personnes réduites en esclavage par les tribus et par le sultan.

Une rébellion armée dhofarie d’inspiration panarabiste, lancée en 1965 par des Dhofaris vivant au Koweït et soutenue par l’Égypte de Nasser, a été discréditée par la défaite de l’Égypte et de ses alliés dans la guerre de juin 1967 contre Israël. Quelques mois plus tard, des militants dhofaris se sont rendus en Chine pour être formés à la révolution. Ils sont retournés chez eux convaincus par le maoïsme, sur un bateau chargé d’armes et de nourriture. Tout cela a permis aux communistes dhofaris de prendre la direction de qui s’appelait désormais le Front populaire pour la libération d’Oman et du Golfe arabe (comme il a changé de nom plusieurs fois, je l’appellerai simplement Front populaire). Ce virage à gauche a été renforcé par le soutien indéfectible apporté à la révolution dhofarie par le Yémen du Sud, voisin de l’Oman, qui est devenu, en 1970, le seul pays communiste du monde arabe.

L’application de la théorie marxiste au contexte local était pourtant controversée. Quand le Front populaire a commandé un rapport à un marxiste de Bahreïn sur la structure des classes sociales au Dhofar, le rapport a conclu qu’il n’y avait pas de classes au Dhofar, mais seulement des tribus. Cette conclusion a déplu aux cadres du Front populaire et le rapport n’a pas été publié. Ils reconnaissaient qu’il n’y avait ni prolétariat ni bourgeoisie au Dhofar, mais affirmaient que les tribus étaient en réalité des classes.

Le Front populaire a interdit l’esclavage dans le territoire libéré. Il a aboli la propriété tribale, toutes les terres devenant des biens publics. Sous l’impulsion de militantes féministes dans ses rangs, il a fait de la libération des femmes un des piliers de sa doctrine. Les femmes ont donc porté des armes dans l’armée révolutionnaire, l’alphabétisation des femmes a été une priorité et la polygamie a été abolie.

Mais les militants considéraient que la transformation sociale qu’ils souhaitaient nécessitait non seulement des décrets imposés par la force, mais aussi un système d’enseignement capable d’amener ses élèves à adopter des valeurs et des comportements qui allaient à l’encontre des traditions. D’autres chercheurs se sont penchés sur les aspects politiques de la révolution dhofarie, mais l’originalité du livre de Mona Ja‘bub est qu’il se concentre sur l’activité éducative du Front populaire et surtout sur l’école et le collège qu’il a établis au Yémen, près de la frontière omanaise. Ja‘bub a pu réaliser des entretiens avec de nombreux anciens militants et anciens élèves de ces établissements, ce qui lui a permis de dresser un portrait intime de cette tentative d’adapter la théorie marxiste à un contexte très différent de l’économie industrielle que Marx avait à l’esprit.

L’appartenance des dhofaris à la nation arabe restait fondamentale dans l’idéologie du Front populaire. La langue arabe standard, qu’ils considéraient comme la langue nationale des arabes, occupait donc une place centrale dans la culture que les enseignants révolutionnaires voulaient inculquer à leurs élèves. Dans le monde arabe, de nombreux dialectes arabes, dont certains sont mutuellement inintelligibles, sont utilisés dans la vie quotidienne, alors que l’arabe standard, que peu de gens savent parler, est réservé principalement à l’écrit et aux discours soutenus. Cependant, au Dhofar, la langue de la vie quotidienne n’était pas arabe du tout : c’était le Shehri, un cousin éloigné de l’arabe. Non seulement les élèves ne comprenaient pas l’arabe standard, ils ne comprenaient aucun dialecte arabe. Dans un premier temps, les enseignants ont fait face à cette situation en obligeant les élèves à parler toujours en arabe standard (ce qui aurait été considéré comme bizarre dans tous les autres pays arabes) et en leur interdisant de parler en Shehri, même en dehors des cours, sous peine d’être punis. Si les élèves avaient besoin d’un mot qu’ils ne connaissaient pas en arabe, ils ne pouvaient avoir recours qu’à des gestes. Les enseignants ont affirmé aux élèves que cela faisait partie de leur devoir envers leur patrie arabe. Ja‘bub nous montre que les élèves n’ont pas seulement obéi à de telles règles par peur : ils les ont vraiment intériorisées. Une ancienne élève se rappelle qu’un jour à la cantine scolaire, en parlant au cuisinier, elle a laissé échapper un mot en Shehri et en a tout de suite eu honte. Elle s’est dénoncée elle-même à la direction et ne s’est sentie soulagée qu’après s’être excusée devant tous les autres élèves. Plus tard, un nouveau directeur a abrogé l’interdiction du Shehri et a mis en place une politique de valorisation de la culture dhofarie.

Les établissements scolaires du Front populaire manquaient cruellement de moyens pendant les premières années de leur existence. Au début, il n’y avait pas de bâtiments, seulement des tentes. Faute de manuels scolaires, les élèves copiaient leurs cours à la main. Pendant quatre ans, le seul livre disponible en quantité suffisante pour l’enseignement de la lecture et de l’écriture en arabe était une traduction du Petit livre rouge de Mao Tse-Toung, dont la Chine envoyait un grand nombre d’exemplaires avec chaque livraison d’armes. C’était aussi le manuel d’instruction politique le plus important du Front, à côté de textes de Marx, d’Engels, de Lénine, de Staline, de Ho Chi Minh et de Che Guevara. Mao était de loin la figure la plus admirée par la population dhofarie et beaucoup de gens portaient des badges de Mao, non seulement, selon l’autrice, parce qu’il leur envoyait des armes et de la nourriture, mais aussi parce que ses idées correspondaient à leurs préoccupations, qu’il avait une conception bien développée de la lutte anticoloniale et qu’il écrivait pour un public de paysans.

Le marxisme enseigné passait pourtant par un filtre : au moins pendant les premières années de la révolution, les cadres et enseignants du Front n’évoquaient pas la critique marxiste de la religion, sans doute pour éviter des conflits avec une population composée de musulmans très pieux. Au contraire, sans proposer d’enseignement religieux, ils affirmaient qu’il n’y avait pas de contradiction entre le socialisme et l’islam. Sur ce point, l’autrice est d’accord. Pour elle, avant la révolution, la société dhofarie était déjà basée sur une sorte de communisme tribal dans lequel l’État était presque absent. Elle affirme que la population de la péninsule arabique était déjà à l’aise avec l’idée de la domination du prolétariat, car cette idée se trouve dans le Coran, et elle cite le verset : « Or, Nous voulions apporter Notre aide à ces opprimés sur Terre, pour faire d’eux des dirigeants et des héritiers » (28:5)². Il s’agit d’un des versets préférés de la gauche islamique depuis les années 1970.

En 1970, la Grande-Bretagne a remplacé le sultan d’Oman par son fils Qaboos. Sans se démarquer de l’autoritarisme de son père, Qaboos a cherché non seulement à vaincre la révolution sur le plan militaire, mais aussi à gagner le soutien de la population, en favorisant le développement économique, en construisant des écoles publiques, en restaurant certains des privilèges des tribus, en proclamant sans cesse que l’islam était le fondement de son règne et en affirmant que le Front populaire s’opposait à l’islam. Selon Ja‘bub, bien que cette accusation ait longtemps été fausse, les dirigeants du Front, ayant l’impression d’avoir acquis la confiance totale de la population, ont fini par dire ouvertement que la religion est l’opium du peuple. Leurs soldats se sont donc rebellés contre eux et cela a entraîné une scission au sein du Front. Pour Ja‘bub, si les révolutionnaires avaient poursuivi leur utilisation sélective de la pensée marxiste, en l’adaptant à la société locale et à ses croyances islamiques, ils auraient pu avoir plus de succès que tous les autres mouvements de gauche dans le monde arabe.

Après la défaite militaire de la révolution en 1975, qu’est-ce qu’il est advenu du changement social qu’elle avait amené ? Les réponses que Ja‘bub apportent à cette question sont parmi les parties les plus intéressantes du livre. Les révolutionnaires ont encouragé et fêté des mariages entre personnes issues des tribus et anciens esclaves. Les anciens élèves se souviennent de s’être réjouis de ces mariages. Pendant la révolution, les mots associés au racisme sont devenus répugnants pour eux et ils se sont même interdit d’utiliser le mot « noir » pour désigner la couleur de la peau de quelqu’un. C’est avec fierté qu’ils disent à l’autrice que, à l’époque, comme ils étaient convaincus que le tribalisme était injuste et réactionnaire, ils ont spontanément cessé d’écrire le nom de leur tribu quand ils écrivaient leur nom. Mais Ja‘bub observe que, quand elle les a rencontrés pour la première fois, la première question qu’ils lui ont posée était « De quelle tribu êtes-vous ? » et que leur conversation était parsemée de remarques sur la qualité de la tribu de telle ou telle personne. L’esclavage est toujours interdit, mais le mépris des tribus envers les anciens esclaves est revenu. De même, les femmes qui ont été scolarisées par le Front populaire sont aujourd’hui parmi les Omanaises plus conservatrices et les plus attachées aux signes extérieurs de la tradition patriarcale. Certes, elles sont devenus médecins, enseignantes ou managers. Mais elles ont répudié le féminisme que le Front populaire avait prôné et pratiqué.

Selon Ja‘bub, la théorie marxiste ne peut pas être appliquée telle quelle à l’ordre social tribal qui existait à Dhofar avant la révolution. Cependant, il y avait de l’injustice sociale, et une grande partie des fondateurs et dirigeants de la révolution appartenaient aux catégories sociales non tribales qui souffraient de cette injustice. Ce livre, qui est devenu une référence importante pour les recherches historiques sur la péninsule arabique, constitue donc une contribution utile aux débats sur la pertinence des concepts marxistes dans différents contextes sociaux. Il donne aussi un aperçu fascinant de la capacité d’une population à adhérer sincèrement à des valeurs révolutionnaires dans un quasi-État construit par des militants, puis à les abandonner avec l’arrivée de l’État suivant.

Bibliographie #

Geer, Benjamin. 2025. “Mona Salem Said Ja‘bub, Qiyadat al-mujtama‘ nahw al-taghyir: al-tajriba al-tarbawiyya li-thawrat Dhufar (1969-1992) [Conducir la sociedad hacia el cambio: la experiencia educativa de la revolución de Dhofar].” Prismas. Revista de historia intelectual 29 (1): 412–14. https://doi.org/10.48160/18520499prismas29.1626.

Geer, « Mona Ja‘bub, Qiyadat al-mujtama‘ nahw al-taghyir ». ↩︎
Traduction de Mohammed Chiadmi. ↩︎

Créer une machine virtuelle en Rust

Sun, 12 Oct 2025 00:00:00 +0000

Aperçu #

Pour m’aider à apprendre le langage Rust, j’ai décidé de réaliser un interpréteur pour Lox, le langage de script que Robert Nystrom a créé pour son livre Crafting Interpreters. Je m’intéresse aux langages de script qui sont destinés à être embarqués dans des applications, et cet exercice m’a semblé un bon moyen d’en savoir plus sur la construction de ce type de langage.

Le livre de Nystrom présente, étape par étape, le développement de deux versions de l’interpréteur. Alors que la première, en Java, parcourt un arbre de syntaxe abstraite (AST) pour exécuter un script, la deuxième, en C, comporte une machine virtuelle qui exécute du bytecode. Cette deuxième version m’intéressait davantage. Au fil des ans, j’avais réalisé deux interpréteurs qui parcourent des arbres de syntaxe abstraite, en commençant par Apache FreeMarker, ainsi qu’un compilateur source à source optimisant utilisant l’inférence de types. Mais je n’avais pas encore fait de machine virtuelle. L’idée me rappelait de bons souvenirs de programmation en assembleur sur l’Apple II quand j’avais quinze ans. Le jeu d’instructions de la machine virtuelle de Nystrom est plus simple que celle du processeur Motorola 6502 de l’Apple II, mais le principe est le même. J’ai donc sauté la première partie du livre pour aller directement à celle où il s’agit de la machine virtuelle.

Le résultat est OrganicLox. La conception est globalement celle présentée dans le livre, mais j’ai essayé de coder dans un Rust courant, en visant des performances raisonnables, sans écrire de code non sécurisé. Les fonctionnalités d’OrganicLox devraient être identiques à celles du programme clox de Nystrom : au moins, ses 246 tests automatisés passent.

J’ai décidé de ne pas créer mon propre ramasse-miettes, car tout le monde semble s’accorder à dire que les ramasse-miettes sont particulièrement difficiles à réaliser en Rust. Par souci de simplicité, j’ai opté plutôt pour le comptage des références (au moyen de Rc). Sur la branche main, cela veut dire que les cycles de propriétés d’objets ne seront pas nettoyés. Sur la branche with_dumpster_gc, j’ai remplacé Rc par la crate dumpster, qui assure le comptage des références et nettoie aussi les cycles.

Ce que j’ai préféré #

J’ai beaucoup aimé ce livre : les explications claires de Nystrom, ses illustrations utiles, son style léger et son humour ont rendu le livre agréable à lire.

Pour moi, la mise en œuvre des variables locales et des fermetures dans une machine virtuelle à pile ont été parmi les aspects les plus intéressants de la conception que présente Nystrom, conception qui s’inspire largement de celle de l’interpréteur Lua. J’ai aimé apprendre que le compilateur associe les variables locales à des positions spécifiques sur la pile, de sorte que la machine virtuelle n’a besoin de connaître que ces positions et non pas les noms des variables concernés.

La mise en œuvre des upvalues, à savoir les variables qui sont capturées par les fermetures et qui doivent donc éventuellement être allouées sur le tas, n’a pas été simple à faire correctement. En corrigeant un bogue, j’ai été heureux de me rendre compte que l’appel récursif d’une function définie dans une portée locale nécessite que la fermeture de la fonction soit une des ses propres upvalues.

Ce que j’aurais souhaité #

Les explications de Nystrom sont tantôt ascendantes, tantôt descendantes. L’approche ascendante a présenté plus de difficultés quant à la traduction de sa conception en Rust, car je devais deviner où il voulait en venir. Plusieurs fois j’ai dû remanier beaucoup de code parce que je n’avais pas deviné juste. Comme l’implémentation de Lox dans toutes sortes de langages de programmation semble être un exercice courant, il aurait été utile d’avoir plus souvent une vue d’ensemble de la conception.

Cela m’a fait plaisir de découvrir la technique de Pratt pour construire un analyseur syntaxique descendant reposant sur la précédence des opérateurs et de constater qu’il est vraiment possible de générer du bytecode sans d’abord construire un AST. Mais il aurait peut-être été plus utile de construire un AST et d’apprendre quelque chose sur la conception d’une deuxième phase pour optimiser le bytecode.

La performance #

L’optimisation principale que j’ai faite au départ a été de faire en sorte que l’analyseur lexical mette tous les identificateurs dans un pool de chaînes de caractères (en utilisant string_interner), pour que ni le compilateur ni la machine virtuelle aient à comparer des chaînes représentant des identificateurs.

Après avoir fini le chapitre 24, j’ai passé un peu de temps à me pencher sur la performance, en suivant les conseils du Rust Performance Book. J’ai fait des tests de performance avec criterion et du profilage avec perf et hotspot, j’ai ajusté la configuration du compilateur Rust and j’ai marqué quelques fonctions inline.

Ensuite j’ai regardé quelques autres versions de Lox en Rust et j’ai remarqué que tout le monde semble avoir eu du mal à obtenir des performances proches de celles du clox de Nystrom et que les versions qui y arrivent comportent beaucoup de code non sécurisé, ce que je voulais éviter.

Je recommande vivement billet de blog de Manuel Cerón sur sa tentative impressionnante, déterminée et partiellement réussie d’égaler la vitesse de clox en Rust en écrivant de plus en plus de code non sécurisé.

À titre de comparaison, voici les résultats de l’exécution de quelques-uns des tests de performance de Nystrom sur les versions suivantes :

Le clox de Nystrom
La version sécurisée du loxido de Cerón
La version non sécurisée de loxido
OrganicLox avec Rc
OrganicLox avec le ramasse-miettes dumpster

OrganicLox avec Rc est donc deux à quatre fois plus lent que clox, ce qui est peut-être typique des interpréteurs réalisés en Rust par rapport à ceux réalisés en C. La version avec dumpster est beaucoup plus lente. Il semble clair qu’un ramasse-miettes rapide est essentiel pour une machine virtuelle très performante.

Quelle est l’importance de ces différences ? Les tests de performance sont conçus pour simuler des scénarios extrêmes, par exemple en utilisant de longues boucles ou la récursivité profonde, ou en créant une charge de travail importante pour le ramasse-miettes. Ils ne sont donc pas forcément représentatifs des cas d’utilisation réels. Il arrive souvent que les scripts exécutés par une application dans un interpréteur embarqué sont courts et font très peu de travail. On pourrait se faire une idée plus réaliste de la performance d’une machine virtuelle dans un tel scénario en exécutant la suite de tests d’intégration de Nystrom, qui exécute 246 scripts courts en Lox et vérifie leurs sorties. Voici une comparaison :

Dans une application où chaque cycle CPU compte, les écarts entre les performances de ces différentes implémentations pourraient avoir beaucoup d’importance. Mais dans d’autres cas d’utilisation, ils pourraient être insignifiants.

D’autres approches possibles #

Il est tentant d’essayer d’ajouter un compilateur à la volée (JIT) pour améliorer la performance de l’interpréteur, soit en en écrivant un à partir de zéro, soit en en utilisant un backend existant comme LLVM ou Cranelift. Roto et Dora sont des exemples en Rust de cette approche. Mais même si on adopte cette démarche, il n’est pas facile d’atteindre un haut niveau de performance. Dans ces tests de performance, le nouveau JIT de Python n’a aucun effet mesurable sur les performances (voir aussi ces résultats de tests de la performance de Dora).

Voilà une raison d’envisager d’utiliser un interpréteur existant qui a déjà bénéficié d’années de développement, plutôt que d’en créer un nouveau. Le langage Lua est une option largement utilisée, mais il n’est pas assez rapide pour certaines applications. La machine virtuelle LuaJIT est un ordre de grandeur plus rapide que la machine virtuelle Lua standard pour certains cas d’utilisation, mais c’est un compilateur à la volée basé sur les arbres de traces, ce qui a des avantages et des inconvénients. Les développeurs de Lua ont publié un article intéressant qui traite des limites de cette approche et propose une autre solution (un langage supplémentaire à typage statique, un peu comme Cython).

Pour certains cas d’utilisation, si des scripts embarqués ne font pas beaucoup de travail, leurs performances pourraient ne pas être critiques. S’ils font tellement de travail que leurs performances sont insuffisantes, une autre option consiste à ne pas intégrer d’interpréteur du tout. Cloudflare, qui avait investi massivement pendant plus de 20 ans dans des scripts en utilisant LuaJIT embarqué dans OpenResty, les a récemment remplacés par du code Rust.

Calculer des mesures de centralité avec le réseau de transport en commun parisien

Fri, 29 Aug 2025 00:00:00 +0000

J’ai pensé qu’il serait intéressant d’essayer un peu d’analyse de réseau élémentaire en utilisant le réseau du métro et du RER parisiens, en commençant par des indices de centralité. Il s’agit de mesures qui classent les sommets d’un graphe en fonction de leur importance, selon une définition quelconque de l’importance. Par exemple, dans un réseau de transport, la centralité d’une station pourrait donner une indication de la probabilité que les passagers passent par cette station au cours de leur itinéraire. Un opérateur de transports en commun pourrait utiliser ces informations pour évaluer les inconvénients que causerait la fermeture de certaines stations, par exemple en raison d’inondations ou de travaux, et pour l’aider à identifier les moyens les plus efficaces d’améliorer la résilience du réseau. J’utiliserai ici Python, networkx et SQLite.

Construire le graphe #

J’ai choisi ici de faire un seul graphe qui comprend le métro et le RER. Le premier problème est de construire ce graphe en établissant la liste de liens et la liste de sommets. Les établissements qui régissent les transports en commun parisiens ne fournissent pas de tel jeu de données, mais ils fournissent un jeu de données GTFS qui représente les horaires prévus sur toutes les lignes de transport pendant les 30 prochains jours. (Je tiens à remercier Oliver Blanthorn de me l’avoir signalé.) Les données GTFS représentent les courses (les séquences d’arrêts) que les trains devraient parcourir sur les lignes de métro ou de RER. Pour construire la liste de liens du réseau, nous pouvons parcourir chaque course, en enregistrant un lien entre chaque arrêt et l’arrêt suivant. Certaines courses vont dans une direction, d’autres dans la direction inverse, et beaucoup ne comprennent pas tous les arrêts de la ligne, mais en les parcourant toutes, nous devrions accumuler un graphe orienté complet du réseau. Il faudra parcourir environ 64 000 courses, qui comprennent au total presque 1,5 million d’arrêts, et une grande partie des données sera redonante pour nous, mais cela n’a pas d’importance tant que le traitement des données ne prend pas trop de temps.

Il s’agit donc de réaliser un procédé ETL (Extract, transform, load). D’abord j’ai créé un script shell qui télécharge les données GTFS, ainsi que plusieurs fichiers d’un jeu de données qui s’appelle Référentiel des lignes de transport en commun d’île-de-France, dont nous aurons également besoin. Comme tous ces fichiers sont au format CSV et utilisent des identifiants uniques pour relier les données des différents fichiers, notre tâche sera plus facile si nous utilisons une base de données relationnelle. Dans un deuxième script shell, j’importe les fichiers pertinents dans une base de données intermédiaire gérée par SQLite et je crée quelques index pour accélérer les requêtes de l’étape de transformation. Ce script s’exécute en 21 secondes environ sur mon ordinateur portable et la taille de la base de données obtenue est de 2,1 Go.

Enfin, j’ai créé un script Python pour les étapes de transformation et de chargement. Il lit la base de données intermédiaire et construit la base de données de sortie, qui ne contient que la table de liens et la table de sommets. Comme la base de données de sortie est petite (132 Ko), le script la crée en mémore pour améliorer la performance de cette étape, puis la sauvegarde quand elle est complète. L’exécution de ce script prend environ 8 secondes.

Dans le Référentiel, les liens entre le métro et le RER sont représentés par des zones de correspondance et des pôles d’échange, qui peuvent comprendre plusieurs stations reliées par des couloirs. Pour inclure ces relations dans le graphe, j’ai choisi d’ajouter des liens entre toutes les stations faisant partie du même groupe.

La base de données de sortie représente un multigraphe orienté, puisque deux stations peuvent être reliées par plusieurs lignes. Dans un tel cas, nous pouvons considérer que les deux stations en question ont un lien plus fort que deux stations qui ne sont reliées que par une seule ligne. Toutes choses étant égales par ailleurs, plus il y a de lignes entre deux stations, plus il y aura de passagers qui voyagent entre les deux. Nous conserverons ces informations sur les liens multiples en faisant nos calculs.

Visualiser des parties du graphe #

Visualisons d’abord une partie des données pour vérifier qu’elles sont correctes. Nous pouvons créer une fonction qui affiche le graphe d’un réseau de transport. Ici, nous nous intéressons uniquement aux sommets et aux liens, et non pas à leur position géographique. Pour repérer facilement les lignes, nous pouvons utiliser les couleurs précisées pour le plan du réseau, qui se trouvent dans le jeu de données GTFS, ainsi que le noir pour les liens que j’ai ajoutés pour les zones de correspondance et les pôles d’échange.

%config InlineBackend.figure_formats = ['svg']
import sqlite3
import pandas as pd
import networkx as nx
import numpy as np
import matplotlib.pyplot as plt
import itertools as it


def draw_graph(G, title, height, label_x_offset):
    plt.figure(figsize=(12, height))
    plt.margins(x=0.18, y=0)
    plt.title(title)

    pos = nx.nx_agraph.graphviz_layout(G, prog="dot")

    # See https://networkx.org/documentation/stable/auto_examples/drawing/plot_multigraphs.html
    connectionstyle = [f"arc3,rad={r}" for r in it.accumulate([0.15] * 4)]

    nx.draw_networkx_nodes(G, pos, node_size=30, node_color="#000000")

    edge_colors = [
        f"#{G[source_node_id][target_node_id][edge_key]["route_color"]}"
        for source_node_id, target_node_id, edge_key in G.edges
    ]

    nx.draw_networkx_edges(
        G, pos, edge_color=edge_colors, connectionstyle=connectionstyle
    )

    label_pos = {
        node_id: (node_pos[0] + label_x_offset, node_pos[1])
        for node_id, node_pos in pos.items()
    }

    text = nx.draw_networkx_labels(
        G,
        label_pos,
        labels=nx.get_node_attributes(G, "node_name"),
        horizontalalignment="left",
        verticalalignment="bottom",
        font_size=6,
    )

    for _, t in text.items():
        t.set_rotation(15)

Essayons avec les lignes de métro 1 et 4 et le RER A:

DATABASE = "../../../notebook-data/paris-rail-data/paris-graph.db"

conn = sqlite3.connect(f"file:{DATABASE}?mode=ro")

nodes = pd.read_sql_query(
    """select distinct
        nodes.node_id, nodes.node_name
    from nodes
    inner join edges on
        nodes.node_id = edges.source_node_id or
        nodes.node_id = edges.target_node_id
    where
        (edges.route_type = 1 and edges.route_name = '1') or
        (edges.route_type = 1 and edges.route_name = '4') or
        (edges.route_type = 2 and edges.route_name = 'A') or
        (edges.route_type is null and
            (edges.route_name = 'PdE Châtelet - Les Halles' or
            edges.route_name = 'ZdC Gare de Lyon'))""",
    conn,
    index_col="node_id",
)

edges = pd.read_sql_query(
    """select * from edges where
        (edges.route_type = 1 and edges.route_name = '1') or
        (edges.route_type = 1 and edges.route_name = '4') or
        (edges.route_type = 2 and edges.route_name = 'A') or
        (edges.route_type is null and
            (edges.route_name = 'PdE Châtelet - Les Halles' or
            edges.route_name = 'ZdC Gare de Lyon'))""",
    conn,
).replace({np.nan: None})

G = nx.from_pandas_edgelist(
    edges,
    source="source_node_id",
    target="target_node_id",
    edge_attr=True,
    create_using=nx.MultiDiGraph(),
)

node_attributes = nodes.to_dict(orient="index")
nx.set_node_attributes(G, node_attributes)

draw_graph(
    G,
    title="Les lignes de métro 1 et 4 et le RER A",
    height=20,
    label_x_offset=6,
)

Cela semble correct.

Visualiser les résultats #

Les fonctions proposées par networkx pour le calcul des mesures de centralité renvoient un dictionnaire dont les clés sont des identifiants de sommet et dont les valeurs sont des scores de centralité. Nous pouvons créer une fonction qui accepte un tel dictionnaire et affiche un diagramme à barres des 25 stations les plus importantes par ordre décroissant de centralité.

def centrality_chart(centrality_dict, title):
    names_and_scores = [
        (node_attributes[item[0]]["node_name"], item[1])
        for item in centrality_dict.items()
    ]

    top_25 = sorted(names_and_scores, key=lambda t: t[1], reverse=True)[:25]

    top_25_df = pd.DataFrame(
        top_25,
        columns=["Station", "Score de centralité"],
    ).set_index("Station")

    ax = top_25_df.plot.barh(title=title)
    ax.invert_yaxis()

La centralité de degré #

Lisons d’abord l’intégralité du graphe :

nodes = pd.read_sql_query(
    "select * from nodes",
    conn,
    index_col="node_id",
)

edges = pd.read_sql_query(
    "select * from edges",
    conn,
).replace({np.nan: None})

conn.close()

G = nx.from_pandas_edgelist(
    edges,
    source="source_node_id",
    target="target_node_id",
    edge_attr=True,
    create_using=nx.MultiDiGraph(),
)

node_attributes = nodes.to_dict(orient="index")
nx.set_node_attributes(G, node_attributes)
print(f"{len(G.nodes)} sommets et {len(G.edges)} liens chargés.")

563 sommets et 1363 liens chargés.

La mesure de centralité la plus simple est la centralité de degré : pour chaque sommet, nous pouvons compter ses liens entrants ou sortants et normaliser le résultat en le divisant par $n - 1$, où $n$ est le nombre de sommets. Dans ce cas présent, les resultats sont les mêmes pour la centralité de degré entrant et la centralité de degré sortant.

1
2

in_degree_centrality_dict = nx.in_degree_centrality(G)
centrality_chart(in_degree_centrality_dict, "Centralité de degré entrant")

On voit tout de suite que les stations ayant les scores le plus élevés sont surtout des stations de métro plutôt que des stations RER. Une explication possible serait la structure apparemment plus radiale du réseau RER par rapport au métro. En plus d’être situées sur plusieurs lignes, plusieurs de ces stations (telles que Havre-Caumartin) font partie d’un pôle d’échange.

La centralité de vecteur propre #

Avec la centralité de vecteur propre, chaque sommet reçoit un score proportionnel à la somme des scores de ses voisins. Un sommet peut ainsi obtenir un score élevé en ayant beaucoup de voisins et/ou en ayant des voisins dont le score est élevé. Dans un graphe non orienté à $n$ sommets, la centralité de vecteur propre $x_i$ d’un sommet $i$, dont l’ensemble des voisins est $M(i)$, est définie par :

$$ x_i = \frac{1}{\lambda} \sum_{j \in M(i)} x_j $$

où $\lambda$ est une constante. Nous pouvons écrire cette équation en utilisant la matrice d’adjacence $A$ du réseau, dans laquelle $a_{ij}$ est égal à 1 s’il y a un lien entre les sommets $i$ et $j$ et à 0 s’il n’y en a pas :

$$ x_i = \frac{1}{\lambda} \sum_{j = 1}^n a_{ij} x_j $$

Cela équivaut à :

$$ \mathbf{x} = \frac{1}{\lambda} A\mathbf{x} $$

où $\mathbf{x}$ est un vecteur dont les éléments sont les scores de centralité. On peut donc écrire :

$$ A\mathbf{x} = \lambda\mathbf{x} $$

Il s’ensuit que $\lambda$ est une valeur propre de $A$ et que $\mathbf{x}$ est le vecteur propre correspondant. Étant donné les valeurs propres et les vecteurs propres de la matrice, il est simple de choisir le vecteur propre pertinent, car (selon le théorème de Perron-Frobenius), pour une matrice (comme la matrice d’adjacence) qui n’a pas d’éléments négatifs, seul le vecteur propre associé à la plus grande valeur propre peut être choisi de façon à ce qu’il n’ait pas d’éléments négatifs. Avec un graphe orienté comme notre réseau de transport, on peut choisir un vecteur propre à gauche ou un vecteur propre à droite. On préfère d’habitude le vecteur propre à gauche (et c’est ce que fait networkx), de sorte que le score d’un sommet dépend de ses liens entrants plutôt que de ses liens sortants. Cela ne change pas grand-chose dans le cas présent, car presque tous les liens entrants de notre réseau ont un lien sortant correspondant.

Lorsque la centralité de vecteur propre est utilisée avec un graphe orienté, celui-ci doit être fortement connexe. C’est le cas de notre réseau de transport, car chaque station est accessible depuis toutes les autres :

`1`	`nx.is_strongly_connected(G)`

True

Nous utiliserons ici la fonction networkx.eigenvector_centrality_numpy, qui construit d’abord la matrice d’adjacence. Dans un multigraphe orienté comme le nôtre, s’il y a $n$ liens allant dans le même sens entre deux sommets, networkx les représente par la valeur $n$ dans la matrice, ce qui équivaut à un seul lien d’intensité $n$. Ensuite il obtient le vecteur propre pertinent et renvoie un dictionnaire qui contient chaque identifiant de sommet et l’élément correspondant du vecteur propre.

1
2

eigenvector_centrality_dict = nx.eigenvector_centrality_numpy(G)
centrality_chart(eigenvector_centrality_dict, "Centralité de vecteur propre")

Si on compare ces résultats à ceux obtenus pour la centralité de degré, on peut constater que la station Havre-Caumartin, qui se trouve au milieu du pôle d’échange Paris Saint-Lazare - Opéra (qui comprend six stations), obtient un score plus élevé parce qu’elle est adjacente à deux stations, Saint-Lazare et Opéra, qui ont des scores élevés. Plusieurs autres stations, dont Saint-Augustin, Auber et and Haussmann Saint-Lazare, obtiennent des scores plus élevés pour la même raison.

La centralité d’intermédiarité #

La centralité d’intermédiarité compte le nombre de fois où un sommet se trouve sur un des plus courts chemins (c’est-à-dire qui traversent le moins de sommets possible) entre chaque paire d’autres sommets. Pour un sommet $v$, elle est définie par :

$$ c_B(v) =\sum_{s \neq v \neq t} \frac{\sigma(s, t|v)}{\sigma(s, t)} $$

où $s$ et $t$ sont n’importe quels autres sommets du réseau, $\sigma(s, t)$ est le nombre de plus courts chemins de $s$ à $t$ et $\sigma(s, t|v)$ est le nombre de ces chemins qui passent par $v$. Dans un réseau de transport, un station dont $c_B(v)$ a une valeur élevée est une station par laquelle beaucoup de passagers passeront probablement s’ils choissisent un des plus courts chemins menant à leur destination.

1
2

betweenness_centrality_dict = nx.betweenness_centrality(G)
centrality_chart(betweenness_centrality_dict, "Centralité d’intermédiarité")

La plupart des stations figurant sur cette liste sont des stations RER plutôt que des stations de métro, ce qui est logique, car le RER couvre une plus grande distance entre les arrêts. Ainsi, si le même trajet peut être effectué en métro ou en RER, le trajet le plus court sera généralement celui en RER. Il n’est pas surprenant de voir Châtelet les Halles en tête de liste, compte tenu de sa situation géographique centrale et du grand nombre de lignes qui passent par son pôle d’échange. Il semble qu’il y ait aussi d’autres configurations qui peuvent donner un score élevé à une station. Par exemple, Juvisy se trouve sur un long tronçon du RER C où il y a peu de correspondances, et elle est reliée à un tronçon semblable du RER D. Il semble donc probable que beaucoup de plus courts chemins doivent passer par cette station.

Conclusion #

Ceci n’est qu’une brève exploration de quelques mesures de centralité pour ce réseau, avec quelques exemples illustrant comment différentes définitions de l’importance d’un sommet peuvent donner lieu à des scores différents. Tous les scripts utilisés ici se trouvent dans le dépôt Git de ce blog, ainsi que le calepin Jupyter à partir duquel j’ai généré cette page. N’hésitez pas à me contacter pour toute question ou suggestion.

Mal partum

Thu, 06 Mar 2025 00:00:00 +0000

En 2024 j’ai fait les sous-titres anglais du court-métrage Mal partum, un beau documentaire sur la dépression post-partum. Émilie D. s’est appuyée sur son expérience personnelle pour réaliser un film qui apporte des connaissances pratiques dont nous pouvons tous nous servir.

Shady Lewis, Sur le méridien de Greenwich

Fri, 10 Jan 2025 00:00:00 +0000

Le roman Sur le méridien de Greenwich, de l’écrivain égyptien Shady Lewis, est sorti en 2019. Depuis que je l’ai lu en arabe en 2023, j’ai offert la version arabe originale ou la traduction française à plusieurs amis (il y a assi une traduction allemande), et je vais maintenant offrir à d’autres amis la traduction anglaise qui sortira le mois prochain. Avec une grande sensibilité, Lewis a écrit un roman comique très drôle sur l’immigration, le racisme et la bureaucratie à Londres, où il est travailleur social. Lors d’une conférence à l’Institut du monde arabe à Paris en avril 2023, il a dit que, lorsque l’actualité nous abreuve d’horreurs tous les jours au point de nous y habituer, l’humour peut raviver nos sentiments. Le traitement m’a fait beaucoup de bien.

Sherif Younis, La marche sacrée

Thu, 26 Sep 2024 00:00:00 +0000

[Version française du texte publié en espagnol.¹]

Sherif Younis, الزحف المقدس: مظاهرات التنحي وتشكل عبادة ناصر [La marche sacrée : les manifestations contre la démission de Nasser et la formation de son culte], 1ère édition, Le Caire, Dar Mirit, 2005. 2ème édition revue et corrigée, Beyrouth et Le Caire, Dar al-Tanwir, 2012, 196 pages.

En juin 1967, lorsque la dictature militaire égyptienne de Gamal Abdel Nasser a subi une défaite militaire écrasante lors de la guerre des Six Jours contre Israël, le président Nasser a immédiatement annoncé sa démission. Peu après, des foules ont manifesté pendant deux jours dans toute l’Égypte pour le supplier de revenir sur cette décision, et Nasser a répondu au tollé en restant en fonction. Dans La Marche sacrée, l’historien égyptien Sherif Younis s’interroge sur ce qui a poussé le peuple égyptien à réclamer le maintien de Nasser au pouvoir. Comment un régime autoritaire et impitoyable envers la population, qui exigeait la passivité politique sous peine d’emprisonnement et de torture, a-t-il pu susciter une telle ferveur ? Certains historiens du nassérisme soutiennent que ces manifestations répondaient aux émotions sincères des manifestants, alors que d’autres pensent qu’elles ont été organisées par le régime. Adoptant une approche originale dans l’étude du nassérisme, Younis se démarque de ces deux interprétations. Pour lui, les manifestations de soutien au président, sans doute spontanées, étaient aussi un produit de l’idéologie que le régime avait mis en place après le coup d’État militaire de 1952.

Spécialiste de l’histoire égyptienne moderne, Younis est l’un des historiens égyptiens les plus importants des dernières décennies. Ses recherches reflètent une certaine empreinte foucauldienne. Il a traduit, de l’anglais vers l’arabe, des classiques comme Metahistory de Hayden White (1973), ainsi que des travaux fondamentaux sur l’histoire égyptienne, comme All the Pasha’s Men de Khaled Fahmy (1997) et Rule of Experts de Timothy Mitchell (2002). Ses ouvrages et traductions alimentent souvent les débats intellectuels en Égypte et dans le monde arabe en général. Compte tenu de l’importance de l’auteur, La Marche sacrée est sans aucun doute une des contributions les plus importantes des dernières décennies aux débats en arabe sur le nassérisme.

L’historiographie du nassérisme est souvent apologétique ou, dans certains cas, hagiographique, justifiant le régime de Nasser en invoquant son anticolonialisme, son nationalisme arabe ou ses prétendues politiques socialistes. Parfois elle tente d’analyser le nassérisme au moyen de théories répandues telles que le marxisme gramscien ou la théorie de la modernisation, sans arriver à expliquer pourquoi ce régime a adopté une forme plutôt qu’une autre et pourquoi il a duré près de deux décennies malgré ses échecs répétés. À la différence de ces démarches, l’étude de Younis ce concentre sur l’idéologie et s’attache à analyser les concepts fondamentaux du nassérisme. Grâce à une lecture détaillée de sources primaires (discours officiels, propagande et articles de presse d’intellectuels nasséristes entre autres) Younis se démarque des analyses marxistes qui associent le nassérisme à une classe sociale. Il soutient au contraire que la clé de l’énigme du régime réside dans le fait qu’il ne représentait aucune classe ou groupe particulier en dehors de sa propre élite. Cette élite nassériste était constituée d’une petite clique d’officiers qui, avec Nasser à leur tête, ont pris le pouvoir en 1952 et mis fin à la domination britannique et à la monarchie égyptienne. Comme l’explique Younis, les membres de ce groupe avaient des préférences politiques diverses (islamistes ou communistes, par exemple) et étaient unis par un patriotisme flou et une attirance pour l’autoritarisme.

L’auteur rappelle qu’avec la création des Officiers libres en septembre 1949, Nasser et son groupe ont renoncé à tout lien avec les partis et les organisations politiques en Égypte et se sont efforcés de rester strictement indépendants de toutes les forces présentes dans le champ politique. En effet, ils considéraient que l’existence même de divisions politiques au sein du peuple égyptien étaient néfaste et profitait aux puissances coloniales. Pour l’élite nassériste, il fallait donc avant tout vider l’espace public de toute organisation politique qui ne représentait qu’une partie du peuple et mettait ainsi la nation en danger. En associant la division à la corruption, le régime se présentait comme un moyen de purifier le peuple. Younis montre que le nassérisme a conçu le peuple comme un ensemble d’individus atomisés, qui devaient s’aligner derrière Nasser comme dans un défilé militaire. C’est ce que le discours officiel appelait la « marche sacrée » : les officiers devaient incarner la conscience et la volonté d’un peuple idéal. Selon Younis, dans cette conception « théologique » de la politique, deux sens du terme « peuple » coexistaient : d’une part, le peuple idéal et invisible qui, comme un dieu, transmet sa révélation aux officiers de manière directe et inexplicable. D’autre part, le peuple réel et présent qui, faible et corrompu, avait besoin d’être guidé et transformé en peuple idéal. L’idéologie officielle présentait Nasser comme l’intermédiaire indispensable entre ces deux phases du peuple, c’est-à-dire comme un prophète.

Pour Younis, cette conception de Nasser est devenue crédible pour la population surtout grâce à la politique étrangère du régime, qui était attribuée exclusivement au chef et qui visait à réaliser certaines des ambitions du mouvement nationaliste : mettre fin à l’humiliation de la colonisation et restaurer la gloire de la patrie. L’exemple le plus important de cette politique a été l’annonce de la nationalisation du canal de Suez en 1956 et l’échec de l’invasion israélienne, britannique et française qui l’a suivie.

Younis montre que l’autorité de Nasser reposait sur l’idée que seul le chef pouvait maintenir une communication directe avec le peuple. Cette communication avait en théorie des caractéristiques surnaturelles, qui étaient censées rendre superflues les institutions représentatives supprimées par le régime. La passivité politique et la perte des libertés devaient être, pour le peuple égyptien, le prix à payer pour la dignité nationale. Selon Younis, cette idéologie a contribué à créer un sentiment de dépendance au sein de la population, ce qui explique les manifestations contre la démission de Nasser après la défaite contre Israël. Le lien affectif entre les manifestants et Nasser était le résultat du rétrécissement du champ politique imposé par le régime (qui découlait de son rejet du multipartisme), de la réalisation d’une partie des revendications du mouvement nationaliste et, enfin, de la diffusion efficace d’une théologie officielle fondée sur le culte de Nasser. Ainsi, habitués à l’idée que seul Nasser pouvait agir et que leur rôle était celui de simples spectateurs et admirateurs, les manifestants ont exigé que « le seul père qu’ils connaissaient » reste en fonction.

Younis a continué à élaborer cette analyse dans son livre نداء الشعب: تاريخ نقدي للإيديولوجيا الناصرية [L’appel du peuple : histoire critique de l’idéologie nassériste] (754 pages), publié en 2012, dans lequel il examine en détail les racines historiques de cette idéologie ainsi que les institutions et les politiques qui ont contribué à sa diffusion et à son évolution depuis le coup d’État de 1952 jusqu’à la mort de Nasser en 1970. Mais La Marche sacrée apporte déjà une contribution importante à la compréhension du nationalisme égyptien et des ressemblances entre le nationalisme et la religion. En particulier, l’utilisation de la catégorie de « prophète » pour analyser la domination symbolique exercée par un dictateur perçu comme un « héros national », ainsi que l’idée que le nationalisme implique une déification du peuple (ou de la nation), nous incitent à explorer tout un ensemble d’outils issus de la sociologie de la religion pour analyser la structure sociale et idéologique du nationalisme, dans le contexte égyptien et au-delà. Ce serait également l’occasion de se pencher sur un autre dieu, la « patrie », qui a reçu moins d’attention de la part de Younis.

Bibliographie #

Geer, Benjamin. 2022. “Sherif Younis, Al-zahf al-muqaddas: muzaharat al-tanahhi wa-tashakkul ‘ibadat Nasir [La Marcha Sagrada: las manifestaciones contra la dimisión de Nasser y la formación de su culto].” Prismas. Revista de historia intelectual 26 (2): 369–70. https://doi.org/10.48160/18520499prismas26.1350.

Geer, « Sherif Younis, Al-zahf al-muqaddas ». ↩︎

Lire la presse avec un pass de la BnF

Sat, 21 Sep 2024 00:00:00 +0000

Beaucoup de titres de presse sont réservés aux abonnés et les abonnements peuvent coûter cher. Pour s’informer à moindre coût, on peut acheter un Pass Lecture/Culture de la Bibliothèque nationale de France. Le prix est actuellement 24 € par an, ou 15 € au tarif réduit. Ce pass donne accès à un grand nombre de titres du monde entier, y compris :

Voici un petit tutoriel pour en tirer le meilleur parti. En somme, c’est moins commode que de s’abonner directement à chaque titre, mais ça coûte beaucoup moins cher. Notez bien qu’après l’achat du pass, il faudra attendre quelques jours pour qu’il commence à fonctionner.

Comment ça marche #

Le moyen d’accéder aux articles dépend du titre de presse. Il y a plusieurs cas de figure :

Lecture sur le site original #

C’est possible avec quelques titres :

Mediapart
Alternatives économiques
Arrêt sur images
The New York Times

Pour les trois premiers, il suffit de s’identifier dans son Espace personnel BnF et ensuite de trouver le bon lien qui donne access au site de la publication à travers le serveur de la BnF. Les liens vers Mediapart, Alternatives économiques et Arrêt sur images se trouvent sur le site easyBnF (qui n’est pas affilié à la BnF).

Le cas de The New York Times est un peu différent. Quand vous visitez easyBnF et cliquez sur The New York Times, il faut suivre les instructions affichées. Cela vous permettra de créer rapidement un pass New York Times gratuit qui vous y donnera accès pendant trois jours. (Récemment cette fonctionnalité d’easyBnF semblait être en panne, mais j’ai fait la même chose en cherchant le titre du journal dans la base de données de la BnF et en suivant les instructions qui s’y sont affichées.)

Lecture au format PDF sur Europresse #

C’est possible pour certains titres, y compris :

Courrier international
Le Monde
Le Monde diplomatique
Libération

Le mode d’emploi :

Identifiez-vous dans votre Espace personnel BnF.
Visitez easyBnF et cliquez sur Europresse.
Cliquez sur Publications PDF et cherchez le titre voulu.

Lecture sur le site d’Europresse #

Cela vaut entre autres pour :

Le Monde
Libération

En effet, pour les titres auxquels Europresse donne accès mais qu’il ne propose pas au format PDF, il affiche le texte intégral des articles sur son propre site. L’inconvénient, c’est qu’il ne propose aucune navigation et s’attend à ce que vous trouviez chaque article en utilisant son moteur de recherche.

Sur un ordinateur (avec Firefox ou Chrome) ou sur Android (avec Firefox), je vous conseille d’installer plutôt l’extension Ophirofox dans votre navigateur. Quand vous naviguez sur le site d’un journal compatible, l’extension ajoute un bouton Lire sur Europresse sur les articles réservés aux abonnés. En réalité ce bouton ne fait qu’ouvrir le site d’Europresse, saisir le titre de l’article que vous regardiez et lancer la recherche, ce qui fait gagner du temps.

Ophirofox n’est pas disponible pour iPhone. Dans ce cas-là :

Copiez le titre de l’article.
Visitez easyBnF et cliquez sur Europresse.
Cliquez sur Recherche avancée.
Collez le titre la où il y a écrit dans le titre.
Cliquez sur Recherche.

Lecture sur PressReader #

Cela vaut entre autres pour :

The Wall Street Journal
The Economist
Süddeutsche Zeitung
Der Tagesspiegel

Pour y arriver :

Sur easyBnF, cliquez sur PressReader.
Cliquez sur Select Publication.
Trouvez le titre voulu et cliquez dessus.
Cliquez sur une page pour l’agrandir.

Les boutons en bas à gauche permettent d’afficher soit chaque page au format PDF, soit le texte des articles.

كوكبنا

Fri, 20 Sep 2024 15:00:00 +0000

Un podcast en arabe que j’ai commencé en 2021, sur l’écologie, la migration et les inégalités, et que j’aimerais me remettre à publier un jour : كوكبنا.شبكة.

Tondauer

Fri, 20 Sep 2024 14:00:00 +0000

En 2020 j’ai commencé un projet qui s’appelle Tondauer, pour faire des éditions de partitions sous licence Creative Commons. C’est arrivé à cause du confinement lié au Covid-19 cette année-là. J’apprenais à jouer le Prélude Op. 104a, n° 2 (MSV U 123) de Felix Mendelssohn, parce qu’il convenait bien à mon sentiment de frustration et à mon humeur agitée à l’époque.

J’ai commencé par une édition du XIXe siècle qui pouvait être téléchargée gratuitement. Puis j’ai acheté une édition qui proposait des doigtés, et je me suis demandé pourquoi elle avait des notes différentes. J’ai cherché sans succès le manuscrit du compositeur, ne trouvant qu’un brouillon antérieur. Ayant lu la biographie de Mendelssohn écrite par R. Larry Todd, je lui ai envoyé un mail pour lui demander s’il savait où se trouvait le manuscrit de la version finale. Il m’a répondu que celui-ci n’avait pas été trouvé. Cela signifiait que les seules sources étaient les premières éditions, publiées après la mort du compositeur.

En travaillant dans le domaine des humanités numériques, j’avais appris quelque chose sur la façon dont les éditions critiques sont réalisées. J’ai donc décidé de faire ma propre édition critique. Pendant plusieurs mois, au fur et à mesure de la réouverture des bibliothèques et des archives, j’ai reçu des reproductions numériques des deux premières éditions, une allemande et une britannique. Les deux éditeurs avaient travaillés ensemble pour les publier simultanément, mais elles ne contenaient pas non plus les mêmes notes. Dans mon édition, j’ai essayé d’expliquer de façon plausible ce qui s’était passé et de reconstituer au mieux les intentions du compositeur. Finalement j’ai essayé de faire l’édition que j’aurais voulu avoir, en ajoutant des doigtés grâce à l’aide de Penelope Roskell.

Plus récemment, j’ai travaillé avec la musicologue Florence Launay sur des éditions d’œuvres oubliées de compositrices, en commençant par les Preludes for Piano d’Armande de Polignac. Ces pièces subsistaient uniquement dans un seul exemplaire de la première édition, conservé par les descendants de la compositrice. Florence l’avait photocopié et des pianistes avaient enregistré ces pièces en utilisant des photocopies de cette photocopie. Maintenant que nous avons publié une édition corrigée avec la préface de Florence, j’espère que d’autres pianistes prendront plaisir à jouer ces Préludes.

Ressources sociologiques

Fri, 20 Sep 2024 13:00:00 +0000

Mon ancien blog (2013-2021) sur la sociologie de l’autonomie et l’autonomie de la sociologie.

أبحاث لفتت نظري

Fri, 20 Sep 2024 12:00:00 +0000

Mon ancien blog en arabe (2009-2014), sur lequel je résumais des recherches que je trouvais intéressantes : أبحاث لفتت نظري.

À propos

Fri, 20 Sep 2024 00:00:00 +0000

Je suis développeur de logiciels et ancien universitaire (sociologie, histoire conceptuelle, linguistique cognitive, culture arabe, humanités numériques). J’habite en région parisienne.

Voici un court essai, écrit en anglais en 2018, sur ma vie professionnelle : An Accidental Career.

Un entretien plus détaillé datant de 2017 : Surviving sociology in Egypt and elsewhere.

Logiciels libres #

Codeberg

Mes projets actuels de logiciels libres sont sur Codeberg.

Le code source de ce site web est ici.

Travaux de recherche #

ORCID

Vous pouvez télécharger toutes mes publications en libre accès sur ma page ORCID. Dans certains cas, il faut cliquer sur Afficher plus de détails pour afficher l’URL de la version en libre accès.

Contact #

Signal : benjamingeer.11

Matrix : @benjamingeer:matrix.org

Mail : ben@benjamingeer.name

Mastodon : @benjamingeer@piaille.fr

Fanny Hensel – Septembre

Fri, 22 Sep 2023 00:00:00 +0000

En 1841, Fanny Hensel (1805–1847) a écrit Das Jahr (L’année), un grand cycle pour piano comprenant un mouvement pour chaque mois de l’année. Elle a publié « Septembre » en 1846 dans son Op. 2, mais Das Jahr a été publié en entier pour la première fois en 1989. Plus tard, un magnifique manuscrit autographe remanié a été trouvé, dans lequel chaque mouvement est copié sur du papier d’une couleur différente, accompagné d’une illustration dessinée par le mari de la compositrice, Wilhelm, et précédé d’un épigramme poétique. Furore Verlag a publié une édition critique.

Pour Marian Wilson Kimber, une considération de la musique, de la poésie et des illustrations dans leur ensemble laisse penser que l’œuvre représente non seulement le cycle de l’année, mais aussi les étapes de la vie d’un individu.¹

L’épigramme pour « Septembre » vient du poème An den Mond (À la lune) de Goethe :

Fließe, fließe, lieber Fluß
Nimmer werd’ ich froh.

Traduction :

Coule, coule, chère rivière
Jamais je ne serai heureux.

Il y a des interprétations innombrables du poème. Pour Tobias Klein :

Le repli dans la nature et surtout dans la solitude de la nuit est présenté comme une consolation face aux déceptions et aux frustrations que l’individu rencontre dans la société. … La rivière apparaît dans ce contexte comme un symbole de changement et d’évanescence, mais aussi d’ambivalence, car elle peut être à la fois destructrice … et revigorante …²

La pièce présente « une application astucieuse de l’effet à trois mains », « dans laquelle une mélodie jouée par les pouces dans le registre moyen du piano est entourée de notes plus graves et plus aigües jouées par les autres doigts, pour créer l’illusion de trois mains au clavier ».³ Le harpiste Elias Parish-Alvars (1808–1849) a inventé cette technique, le pianiste Sigismund Thalberg (1812–1871) l’a transférée au piano⁴ et elle s’est répandue dans les années 1830. Dans « Septembre », la voix supérieure semble évoquer le courant de la rivière.

Le développement harmonique ingénieux du mouvement⁵ est un exemple de l’anticipation chez Hensel de l’avant-garde de la seconde moitié du XIXe siècle.⁶

Bibliographie #

Klein, Tobias. n.d. “Interpretation: An den Mond – Johann Wolfgang von Goethe.” https://lyrik.antikoerperchen.de/johann-wolfgang-von-goethe-an-den-mond,textbearbeitung,372.html.

Manning, Laurence. 2015. “Fanny Hensel, compositrice de l’avenir ? Anticipations du langage musical wagnérien dans l’œuvre pour piano de la maturité de Hensel.” Les Cahiers de la Société québécoise de recherche en musique 16 (1–2): 121. https://doi.org/10.7202/1039618ar.

Todd, R. Larry. 2010. Fanny Hensel: The Other Mendelssohn. Oxford University Press.

Walker, Alan. 1987. Franz Liszt: The Virtuoso Years, 1811–1847. Cornell University Press.

Wilson Kimber, Marian. 2008. “Fanny Hensel’s Seasons of Life: Poetic Epigrams, Vignettes, and Meaning in Das Jahr.” Journal of Musicological Research 27 (4): 359–95. https://doi.org/10.1080/01411890802384409.

Kimber, « Fanny Hensel’s Seasons of Life ». ↩︎
Klein, « Interpretation: An den Mond ». ↩︎
Todd, Fanny Hensel, 264, 233. ↩︎
Walker, Franz Liszt, 234. ↩︎
Todd, Fanny Hensel, 275–77. ↩︎
Manning, « Fanny Hensel, compositrice de l’avenir ». ↩︎

Chopin, Valse, op. 64, n° 2

Sat, 20 May 2023 00:00:00 +0000

Frédéric Chopin, Valse, op. 64 n° 2.

Benjamin Geer, piano.

Enregistrée le 20 mai 2023.

J. S. Bach, tr. Busoni – Ich ruf’ zu dir, Herr

Sun, 19 Sep 2021 00:00:00 +0000

J. S. Bach, Ich ruf’ zu dir, Herr, transcription de Ferruccio Busoni pour le piano.

Benjamin Geer, piano.

Enregistré le 8 juillet 2021.

J’ai essayé d’être guitariste de jazz

Sun, 11 Apr 2021 00:00:00 +0000

J’ai commencé à jouer de la guitare de jazz à peu près au moment d’aller à l’université. Je voulais allier la tradition d’improvisation du jazz à l’harmonie non-tonale et des structures à grande échelle. Mais je pensais qu’il fallait commencer par le bebop.

En 1995–96, alors que je travaillais comme assistant d’anglais en France, j’ai pu jouer dans un orchestre de jazz ainsi que dans un quintette :

Voici des enregistrements antérieurs qui datent de 1991 :

À l’age de 30 ans environ j’ai arrêté de jouer, surtout parce que j’étais frustré par la lenteur de mes progrès ainsi que par la difficulté de concilier la musique et la nécessité de gagner ma vie en faisant autre chose. Je regrette de ne pas avoir continué.