Bim! est un jeu libre (code AGPL3 et assets CC-by-sa 4.0) multijoueur de type dernier survivant, et qui se joue uniquement en ligne. Il n’est disponible que pour les systèmes Android.

Le jeu est développé depuis plus de deux ans. Jusque-là restreint à quelques pays sur le PlayStore, la sortie de la version 12 marque la mise à disposition de l’app à tous les pays en mode tests ouverts ; c’est-à-dire que vous pouvez installer l’app et même laisser des commentaires mais ceux-ci ne seront pas visibles dans le PlayStore.

En plus du PlayStore, le jeu est disponible sur GitHub, F-Droid, et d’autres magasins alternatifs.

La suite de la dépêche présente les nouveautés des versions publiées depuis la dernière communication en ces pages, soit les versions 11 et 12.

Sommaire

• Historique du développement
• Nouveautés des versions 11 et 12
  • Nouveautés sur le serveur
  • Nouveautés sur le client.
    • Affichage de statistiques du serveur
    • Boutons pour la boutique et les stats sur le lobby.
    • Intégration d’un outil d’analytics
    • Écran de sélection des fonctionnalités de jeu.
• Quelques statistiques

Bim! est un jeu « à la bomberman ». Deux à quatre joueurs sont dans une arène, le dernier survivant a gagné. Pour combattre, les joueurs posent des bombes dont ils peuvent augmenter la puissance en trouvant les améliorations disséminées dans l’arène. De plus, d’autres bonus peuvent être découverts pour faire varier l’expérience de jeu.

Un pilier dans la création de ce jeu est de proposer aux joueurs de partager un bon moment d’amusement avec d’autres personnes. C’est pourquoi il ne propose aucun mode hors-ligne ni de bots en guise d’adversaires.

Le jeu est disponible en allemand, anglais, brésilien, breton, français, portugais, et turc.

Historique du développement

Le développement du jeu a été régulièrement conté dans des journaux sur LinuxFr.org, au rythme d’un journal toutes les deux versions. J’en profite pour remercier profondément tous ceux qui ont testé ou commenté jusqu’ici :)

Le premier journal, dix mois après la création du dépôt, intitulé Bim! On parle de dev de jeu mobile, de gestion de projet, de dépendances, etc., présente le début du projet, les choix de technos, la mise en place d’outils de dev, et le chemin pour arriver à une première application et un environnement de dev robuste. Au final on obtient une application humble sur laquelle on va pouvoir construire, et bien qu’elle soit en mode texte le mode de jeu en réseau est déjà fonctionnel.

Première version avec gameplay, dans un terminal	Première version de l’app graphique

Dans le deuxième journal, Dev update du jeu Bim!, on présente les résultats d’une première version graphique, et des problèmes liés à la gestion de sticks logiciels. Des assets temporaires sont utilisés en attendant de valider le fonctionnel.

Le troisième journal, Bim! Ça joue là, marque la mise à disposition du premier APK. Les joueurs peu regardants sur l’esthétique du jeu peuvent faire des matchs.

Clique sur l’image pour voir une vidéo du jeu.

Le quatrième journal, Version 2 de Bim!, avec des menus, présente l’interface des premiers menus. L’interface du jeu lui-même est toujours à base de placeholders mais les menus s’approchent d’une esthétique convenable. On y parle aussi de réglages liés au jeu en réseau.

Dans le cinquième journal, Sortie de Bim! en version 3 pour les fêtes, on parle de l’arrivée de l’écran de paramétrage, ainsi que de réglages graphiques suite à des sessions de tests avec joueurs. C’est aussi dans cette version qu’est introduite l’enregistrement des parties sur le serveur afin d’aider à déboguer a posteriori.

Écran des paramètres	Interface de visualisation des parties enregistrées

Le sixième journal, De beaux graphismes dans la version 4 de Bim!, marque un tournant avec le remplacement des assets du jeu par des graphismes convenables. Ça change tout. L’avatar du joueur, la bombe, les flammes, et les caisses sont le résultat d’une commande à Aryeom. Pour le reste c’est de mon fait, parfois avec des ressources libres trouvées sur le web. On y parle aussi de conso mémoire, d’équité dans la répartition des bonus, et de recherche graphique.

Capture d’une partie	Recherche d’adversaire

La version présentée dans le septième journal, Sortie de Bim! en version 6, est la première à ne plus utiliser d’éléments graphiques provisoires. C’est aussi celle qui introduit le mode de jeu avec brouillard de guerre.

Clique sur l’image pour voir une vidéo du jeu.

Dans la version du huitième journal, Ça bouge dans Bim! en version 8, les joueurs sont enfin animés. C’est aussi une version qui contient des contributions externes, notamment le bonus d’invisibilité. Enfin, les joueurs gagnent maintenant des pièces en jouant, leur permettant d’acheter les modes de jeu supplémentaires.

Animations du personnage	Vidéo du bonus d’invisibilité

Enfin, le neuvième et dernier journal en date, Sortie de Bim! en version 10, avec un bouclier et des stats, marque l’arrivée du bonus « bouclier » ainsi que d’une refonte graphique des bonus. Cette version est aussi la première à proposer une boutique ainsi qu’à présenter les stats de jeu au joueur. Enfin, grâce à Weblate des contributeurs à travers le monde ont pu proposer de nouvelles traductions.

Boutique	Statistiques	Bonus

Nouveautés des versions 11 et 12

Il n’y a qu’une nouveauté de gameplay dans ces versions, il s’agit d’une modification du comportement des flammes pour qu’elles puissent se croiser. Auparavant une flamme qui en rencontrait une autre était bloquée, ce qui réduisait de fait son pouvoir de destruction. Dorénavant elles s’étendront jusqu’au prochain obstacle solide. Cela rend les fins de parties et les mêlées vachement plus fun.

Du côté des outils j’ai intégré l’instrumentalisation avec Tracy, et j’ai commencé à faire quelques mesures de perf, pour voir où le jeu se situe. Très sympa comme outil, ça me permet de prendre des mesures par frame et de regarder comment l’application se comporte. Il y a aussi la possibilité de tracer des données personnalisées, ce dont je me sers pour suivre le trafic réseau.

Sur cette frame on a une petite pile d’appels (c’est moi qui indique manuellement quelles fonctions doivent être mesurées) qui correspond à l’update du jeu. En rouge on a l’étape de synchronisation avec le serveur, où on joue ce qu’il nous a envoyé pour ensuite simuler les itérations locales. En bleu on a la préparation de l’affichage. Tout cela est inclus dans la section « update », qui contient d’autres trucs non tracés et prend donc une milliseconde sur mon Pixel 3a. Sur la droite il y a une section « draw » qui n’a pas de pile d’appels. Il s’agit de l’affichage proprement dit, géré par Axmol. Ça prend donc 14 ms, ce qui est un peu trop à mon goût. Il faudra que je creuse.

Nouveautés sur le serveur

Le serveur de jeu maintient maintenant des statistiques d’activité sur une fenêtre glissante, à savoir le nombre de parties jouées et le nombre de joueurs connectés. Ces deux métriques sont disponibles en instantané, sur la dernière heure, les 24 dernières heures, et les 30 derniers jours. Ces statistiques sont disponibles dans les logs du serveur mais aussi à la demande des clients.

Ce travail est basé sur une contribution de HanevyN. Dans le cadre de l’utilisation de Bim! comme outil d’apprentissage du C++ présenté dans le journal sur la version 8, cette personne avait choisi la tâche d’intégrer des statistiques au serveur. Le problème à résoudre était mal spécifié, mais nous avons trouvé une reformulation plus réaliste qui a ensuite bien occupé ce contributeur. Lorsqu’il n’a plus pu se charger de ce développement j’ai pris la suite pour le finaliser et l’intégrer au dépôt.

Nouveautés sur le client.

Les transitions entre les écrans sont maintenant animées ! C’est vachement plus agréable. Avec l’arrivée d’animations dans les menus j’ai dû remettre le framerate à 60 dans ces derniers parce que sinon c’était trop saccadé.

Affichage de statistiques du serveur

Autre nouveauté sur le client, il affiche maintenant une statistique du serveur. À l’origine de cette fonctionnalité il y a une demande d’un utilisateur reçue par courriel :

Bim is such a great game, but sometimes I join for a casual match, and there is no one playing. Sometimes I sit in the lobby for 2 minutes to check if someone else's game ends and join them, but it would be even greater to have a games in progress count in the lobby.

Le problème de cette personne est qu’elle lance une recherche d’adversaire et la laisse tourner sans jamais voir de joueur la rejoindre. C’est très frustrant en effet. Cette personne propose d’avoir une indication sur l’écran principal de l’application du nombre de parties en cours.

C’est quelque chose que j’avais auparavant refusé de faire, car la plupart du temps cela affichera zéro, et si c’est zéro sans doute que les joueurs qui ouvrent l’app ne vont pas tenter de lancer un match, ce qui ne va pas aider à faire monter le compteur.

Cependant, suite à ce message, j’ai réfléchi à la possibilité de suggérer l’activité sur le serveur mais de manière toujours positive. L’idée est d’indiquer le nombre de parties en cours mais de se rabattre sur une indication du nombre de joueurs connectés s’il n’y a pas assez de matchs en cours. Et s’il n’y a pas trop de joueurs, alors on se rabat sur des mesures agrégées sur la dernière heure, puis les 24 dernières heures, puis les 30 derniers jours. Ça tombe bien, j’avais toutes ces mesures sur le serveur !

Ça me semble être un bon compromis. On ne voit pas qu’il n’y a personne, mais on voit que le jeu n’est pas à l’abandon.

Boutons pour la boutique et les stats sur le lobby.

J’ai fait pas mal d’UI dans ces versions à commencer par ajouter un bouton permettant d’accéder à la boutique et un autre pour afficher les statistiques du joueur. Auparavant on accédait à la première en cliquant sur le solde de pièces et les secondes étaient affichées directement sur l’écran principal.

Le plus simple pour moi, quand je dois faire ce genre de bouton, est de commencer par des croquis pour dégrossir les idées.

En haut à gauche on voit la base du bouton. L’icône est trop petite, et le libellé trop rigide ; je l’ai donc incliné (c’est une des lignes directrices que j’applique pour l’interface, d’avoir des inclinaisons, pour donner un sentiment de dynamisme). Pour l’icône je me suis posé plein de questions sur la taille du store, la forme de la porte, les proportions… D’où le lot de croquis.

Pour l’icône des statistiques c’était plus simple, il y avait moins de questions. Enfin, il y a surtout eu des questions de couleurs mais ça je ne le travaille pas sur le carnet.

Au final ça donne ça. J’ai peut-être fait un peu de zèle pour l’icône de la boutique, sans doute que je voulais impressionner mon enfant qui me regardait dessiner dans GIMP (ça a marché :)).

Intégration d’un outil d’analytics

L’application Android intègre maintenant une remontée de statistiques anonymes sur son utilisation. L’outil que j’ai choisi est PostHog, qui a le bon goût d’être libre, auto-hébergeable, de proposer le stockage des données en Europe, d’avoir une offre gratuite, et de permettre une remontée des statistiques sans identification de l’utilisateur.

Grâce à cet outil j’ai maintenant une idée de ce qu’il se passe sur le client ; notamment le nombre d’utilisateurs par jour, ou encore la proportion de joueurs qui cherchent et trouvent un adversaire.

Écran de sélection des fonctionnalités de jeu.

Le déblocage et la sélection des fonctionnalités de jeu se faisaient auparavant sur l’écran de recherche d’adversaire. Les joueurs pouvaient activer la chute de blocs, les boucliers, le brouillard, ou encore l’invisibilité depuis cet endroit. Dans la nouvelle version cette sélection se fait maintenant sur un écran dédié, accessible depuis le lobby. De plus, seules deux options peuvent être activées par joueur. Cela permettra d’avoir un peu plus de variété et de surprise dans les matchs en combinant les fonctionnalités activées par les uns et les autres.

Cet écran a été un très gros chantier, avec pas mal de code qui n’était pas prêt mais que je ne le savais pas et que donc j’ai dû m’interrompre plein de fois pour préparer ce code que j’aurais dû écrire en amont. Galère.

Déjà sur les croquis ont voit que ça n’allait pas être simple.

J’avais envisagé une vue grille (en haut à gauche) pour ensuite m’orienter sur une liste de fiches présentant chaque fonctionnalité (milieu gauche). J’avais besoin d’emplacements où poser les éléments sélectionnés par le joueur, que je mettais en haut sur les croquis, sans trop savoir s’ils allaient être en ligne ou en pyramide, inclinés ou horizontaux.

Étonnamment dès lors que j’ai ouvert GIMP pour faire une maquette j’ai abandonné l’idée des fiches en faveur de la grille. La longue liste de fiches m’a semblé soudain peu attrayante par rapport à une grande grille qui montrerait au premier coup d’œil la variété de l’offre.

J’ai ajouté une zone de présentation de chaque fonctionnalité ainsi qu’une petite notice explicative, et j’ai fait beaucoup d’essais pour déterminer la couleur des contours des boutons.

Et au final, quand j’ai mis ça dans l’application, eh bien j’ai jeté la petite explication pour la fusionner dans la nouvelle boîte de présentation des fonctionnalités ! On avance clairement à tâtons sur cet écran.

Il faut savoir qu’il y a aussi beaucoup d’animations liées aux interactions sur cet écran, mais évidemment ça ne se voit pas sur les images :)

Quelques statistiques

À chaque communication je présente quelques statistiques du jeu. Comme d’habitude je vais sortir des graphiques à partir des logs du serveur, mais cette fois j’ai aussi des mesures intégrées au client grâce à PostHog ; je vais donc pouvoir sortir quelques graphes supplémentaires. Commençons par le nombre de joueurs par jour :

On y voit clairement le déploiement des deux mises à jour. Dès lors que ça arrive sur F-Droid il y a plein de joueurs qui débarquent. Ensuite voici le nombre de parties par jour (logs serveur) :

Une chouette info que me donnent les mesures sur le client est la proportion de joueurs qui lancent une recherche d’adversaire et trouve effectivement quelqu’un :

Sur un autre graphe que je n’affiche pas ici, j’apprends que les joueurs restent en moyenne 17 secondes sur la recherche d’adversaire avant de laisser tomber.

En termes de répartition du nombre de joueurs par partie, cela donne :

Nombre de joueurs	Nombre de parties
2	708
3	182
4	42

Et enfin, pour la répartition des joueurs par pays, on a :

Ce sera tout pour cette fois. On se retrouve en match :)

Cette année, la date de la journée Ada Lovelace, une journée dont l’objectif est d’accroître la visibilité des contributions des femmes dans les domaines scientifiques, technologiques, mathématiques et ingénierie (STEM), est le 15 octobre 2025.

Pour l’occasion, en 2023, LinuxFr avait consacré une dépêche à Lorinda Cherry, Evi Nemeth et Jude Milhon. En 2024, cela avait donné lieu à une mini-série sur la participation des femmes à la conquête de l’espace. Cette année, on se penchera sur les compilateurs, créés par Grace Hopper, et qui ont valu à Frances Allen un prix Turing en 2006 et on dressera le portrait de Delphine Demange, lauréate du prix Gilles Kahn 2013.

Sommaire

• Qu’est-ce qu’un compilateur ?
  • La naissance des compilateurs
  • À quoi ça sert ?
  • Comment ça marche ?
• Delphine Demange : comment vérifier que les compilateurs font leur travail correctement
  • Parcours
  • La vérification des logiciels
• Quelques autres sources d’information
• Questions et remerciements

Qu’est-ce qu’un compilateur ?

La naissance des compilateurs

Le premier compilateur, il s’appelait « translator » (traducteur) à l’époque, a été inventé par Grace Murray Hopper pour l’UNIVAC 1 en 1951, l’A-O System. Soit après la sortie de l’IBM 604 (1948), avant celle de l’IBM 650 (1954) et un peu avant le FORTRAN, langage compilé, créé vers 1953 par John Backus pour l’IBM 701 et lancé en 1957. La même année où IBM embauche Frances Allen pour former des scientifiques et des ingénieurs réticents à l’utilisation du langage. Elle sera, en 2006, la première femme à obtenir un prix Turing. Elle raconte, dans les Annals of History of Computing (Volume 6, N°1, janvier 1984) que :

L’une des façons dont le laboratoire de recherche a convaincu les gens à utiliser ce langage a été d’imposer son utilisation via un règlement.

Elle ajoutera :

le compilateur FORTRAN a établi la norme en matière d’efficacité du code objet. Mais surtout, il a démontré la faisabilité de l’utilisation des langages de haut niveau. Lorsque j’ai enseigné le FORTRAN en 1957, l’utilisation de ce langage a rencontré une forte résistance. Cette résistance a rapidement été érodée par le type de code produit par le compilateur.

John Backus, qui trouvait par ailleurs que Grace Murray Hopper était difficile à égaler, détaillait dans ces mêmes annales les auteurs et l’autrice du compilateur. Peter Sheridan avait écrit la section 1 qui analysait les expressions algébriques, les traduisait en code et optimisait ce code. Pour la section 2, Harlan Herrick avait inventé l’instruction DO, rédigé : « la partie de la section 1 qui regroupe toutes les informations sources non utilisées dans les expressions algébriques dans des tableaux nécessaires aux sections suivantes. ».

C’est également à Herrick que l’on doit l’introduction des mots clés GO TO ! Roy Nutt a conçu la majeure partie du langage d’entrée/sortie et rédigé la partie de la section 1 qui traduisait les instructions d’E/S en boucles DO. Il a également rédigé la section 6, qui assemblait le programme symbolique final et complétait le traitement des instructions d’E/S. C’est également à Nutt que l’on doit l’introduction de l’instruction FORMAT. Bob Nelson et Irv Ziller ont rédigé la section 2, qui s’est avérée être la plus grande section du compilateur. Elle analysait les références aux tableaux dans les boucles DO et produisait un code hautement optimisé pour le reste du programme source. Leur travail a eu un impact important sur le niveau global d’optimisation que j’ai mentionné précédemment. Dick Goldberg a rédigé la section 3, qui rassemblait le code compilé par les sections 1 et 2 et produisait d'autres informations nécessaires aux sections suivantes. Les gens continuaient à se concerter et à demander aux auteurs des sections précédentes de produire un peu plus, quelques tableaux supplémentaires dont ils avaient finalement besoin. Dick a également joué un rôle important dans le débogage de la section 5. Lois Haibt (en) a rédigé la section 4, qui effectuait une analyse statistique de la fréquence d'exécution […] Ici, la section 4 a également préparé de nombreux tableaux pour la section 5, si je comprends bien. Sheldon Best a écrit la section 5, qui a converti le programme utilisant de nombreux registres d'index en un programme en utilisant trois. Ses méthodes ont eu un impact considérable sur les travaux ultérieurs dans ce domaine et ont eu un effet majeur sur le niveau d'optimisation du compilateur. Enfin, David Sayre a rédigé un manuel du programmeur exceptionnellement clair et concis et a aidé Dick Goldberg à déboguer la section 5.

Schéma de la structure du compilateur de l’ordinateur IBM 704 adapté de celui fait par Frances Allen dans les « Annals of History of Computing », Volume 6, N°1, janvier 1984 (page 24).

De leur côté, les Soviétiques, qui fabriquaient aussi des ordinateurs, utilisaient également des compilateurs. Dans son article sur les ordinateurs soviétiques, Yves Logé rapporte qu’ils utilisaient, en 1955, les langages de compilation : PP2 – PP et BESM. Le BESM étant un ordinateur sorti en 1953. La fondatrice de la programmation théorique en Ukraine, Katerina Yushchenko (en), y a fort probablement contribué.

À quoi ça sert ?

En août 2001, dans un entretien (en) avec Janet Abbate qui lui demandait comment elle définirait un compilateur, Frances Allen répondait :

Je pense qu’un compilateur sert à traduire ce que l’utilisateur de l’application […] demande […] à la machine de manière à obtenir la bonne réponse, mais aussi à utiliser au mieux les ressources de la machine. C’est ça, l’optimisation. On peut se contenter de transposer les choses sans tirer parti des registres et de nombreuses autres unités de calcul, mais cela ne serait pas aussi efficace. L’optimisation consiste donc à tirer parti des ressources de la machine et à très bien connaître cette dernière. C’est en quelque sorte combler un fossé, afin que l’utilisateur n’ait pas besoin de tout savoir !

Plus généralement, un compilateur est décrit comme un programme dans un langage de haut niveau qui traduit le code-source en code objet pour le rendre exécutable en détectant les erreurs et en l’optimisant par la même occasion.

Le code source est envoyé au compilateur qui le traduit en langage machine.

Les compilateurs sont des outils essentiels et très complexes qui interviennent dans tous les programmes, notamment des logiciels très critiques :

Par exemple, les programmes embarqués dans les systèmes bancaires, dans les systèmes de contrôle de vol des avions, ou même dans la chirurgie assistée par ordinateur ou les centrales nucléaires […] : la présence d’erreur durant leur exécution pourrait avoir des conséquences désastreuses, que ce soit en termes de vies humaines, de dégâts écologiques, ou de coût financier. (Delphine Demange, Semantic foundations of intermediate program representations, Thèse soutenue le 19 octobre 2012.)

Comment ça marche ?

Réponse rapide : avec beaucoup de mathématiques. Réponse un peu plus détaillée : à partir de différents types d’analyses après une phase de pré-traitement qui permet de déterminer comment traiter les informations.

1. L’analyse lexicale : découpe le code en unités lexicales ou « tokens » qui vont permettre au compilateur de traiter les données par la suite. Ce faisant le compilateur sépare les différents types d’éléments : variables, opérateurs, séparateurs, mots-clés, etc.
2. L’analyse syntaxique : vérifie que le programme source ne contient pas d’erreur de syntaxe et que le code source est correct et, évidemment le compilateur signale les erreurs qu’il a pu trouver à ce stade.
3. L’analyse sémantique : après la syntaxe, c’est le sens du code qui est examiné. Le compilateur va ainsi vérifier s’il y a des erreurs de logique, passant, que le code fait bien ce qu’il est censé faire. À ce stade, le compilateur va aussi signaler les erreurs, voire, rejeter un code incorrect.
4. L’optimisation : permet de nettoyer le code pour le rendre plus rapide à exécuter. À l’heure actuelle avec des processus très gourmands en ressources, c’est une étape-clé, ça n’a pas toujours été forcément le cas.
5. La génération du code final : c’est la dernière phase dont le résultat est le code exécutable.

Delphine Demange : comment vérifier que les compilateurs font leur travail correctement

Parcours

Delphine Demange entre en licence d’informatique à l’université de Rennes 1 en 2004. Elle y obtiendra un magistère Informatique et télécommunications en 2006 puis fera le mastère de recherche en informatique de la même université en 2008. Elle achèvera cette partie de ses études par un stage de master à l’IRISA (équipe Celtique), en vérification de programme. Au bout des cinq mois de stage, en 2009, elle s’inscrira en thèse. Une thèse, Fondements sémantiques des représentations intermédiaires de programmes (en), soutenue en 2012 et qui lui vaudra le prix de thèse Gilles Kahn 2013 de la SIF, et qui porte sur :

la vérification formelle de logiciel, c’est-à-dire à l’ensemble des techniques et d’outils scientifiques qui permettent d’assurer qu’un logiciel remplit ces exigences [de qualité des systèmes critiques]. (Résumé étendu de sa thèse).

Elle part ensuite pour les USA, à l’Université de Pennsylvanie pour une année de post-doctorat. Là, elle travaillera sur un projet alliant vérification et sécurité. De retour en France, elle passe des concours. Elle est, depuis 2013, maîtresse de conférence à l’université Rennes 1.

En février 2024, elle donnait un cours au Collège de France : Représentations intermédiaires pour la compilation : s’affranchir du graphe de flot de contrôle.

On peut retrouver ses communications et articles ainsi que sa thèse, toutes en anglais, sur HAL science ouverte.

La vérification des logiciels

Comme elle le dit en résumé de sa thèse :

Nos vies quotidiennes dépendent de plus en plus, sans même parfois que nous nous en rendions compte, de l’utilisation de programmes informatiques. Ces programmes n’ont toutefois pas tous le même niveau de criticité. Par exemple, les programmes embarqués dans les systèmes bancaires, dans les systèmes de contrôle de vol des avions, ou même dans la chirurgie assistée par ordinateur ou les centrales nucléaires sont appelés systèmes critiques : la présence d’erreur durant leur exécution pourrait avoir des conséquences désastreuses, que ce soit en termes de vies humaines, de dégâts écologiques, ou de coût financier. Ce type de programme requiert donc de fortes garanties : leur exécution ne devrait pas échouer, et leur correction fonctionnelle devrait être garantie.

Elle ajoute plus loin que les compilateurs étant des logiciels, ils sont à leur tour susceptibles d’avoir des bugs comme n’importe quel autre programme. Il est donc nécessaire qu’ils répondent aux mêmes exigences infaillibilité que les systèmes critiques sur lesquels ils travaillent.

Dans un entretien accordé au site de l’université de Rennes en 2014, elle précise que son travail a pour but final :

d’assurer, par une preuve mathématique et assistée par ordinateur, que les compilateurs compilent correctement les programmes (i.e. ils n’ajoutent pas de nouveaux comportements aux programmes), et que les vérifieurs calculent des propriétés sur des modèles corrects des programmes (si le modèle du programme ne comporte pas d’erreur, alors le programme d’origine n’en comporte pas non plus).

Ses travaux de thèse portant les représentations intermédiaires (IR) des programmes sur lesquels travaillent les compilateurs et vérificateurs. Ces IR simplifient les analyses de ces outils qui peuvent analyser des programmes très complexes. Elle continue, depuis, ses recherches dans le même domaine avec :

la vérification des techniques de compilation optimisantes pour les langages de haut-niveau, en y incluant les aspects les plus difficiles des langages modernes, comme la gestion de la mémoire, la concurrence et les modèles de mémoire faibles. (entretien, Université de Rennes).

Tout cela demande beaucoup de mathématique, parfait pour quelqu’un qui a hésité entre les maths et l’informatique.

Quelques autres sources d’information

Sur les compilateurs, internet est bien pourvu en ressources en français sur le sujet, par exemple :

— Compilation informatique : définition concrète et rôle, Journal du net, 2016,
— Comment fonctionnent les compilateurs, IBM, [sd],
— Qu’est-ce qu’une conception de compilateur ? Types, outils de construction, exemple, Kaia Céruléen, GURU99, [septembre 2025 ?],
— Cours de compilation, [sd],
— Compilation, pdf à télécharger,
— Langages de programmation et compilation, Jean-Christophe Filliâtre, septembre 2016,
— Représentations intermédiaires pour la compilation : s’affranchir du graphe de flot de contrôle, cours au Collège de France, 15 février 2024
— Fondements sémantiques des représentations intermédiaires de programmes, thèse, en anglais, de Delphine Demange.

Sinon on peut aussi lire ou relire l’hommage à France Allen sur LinuxFr. Il y a aussi, en anglais, cet article Early Computers and Computing Institutions (en) qui raconte les débuts de FORTRAN. C’est très intéressant. Mais il faut soit l’acheter (15,50 dollars pour les membres ou 30 dollars pour les non-membres) ou faire partie d’une structure adhérente.

Questions et remerciements

Compte de tenu de l’importance des compilateurs, la question se pose de la raison pour laquelle la personne qui a été à l’origine du premier compilateur et du COBOL, Grace Murray Hopper (1906-1992) n’a pas reçu le prix Turing pourtant créé de son vivant, en 1966, et à une époque où elle était encore active. Le récipiendaire du prix Turing 1966 ayant d’ailleurs été Alan J. Perlis pour la construction de compilateurs.

Question complémentaire, pourquoi France Allen n’a reçu son prix Turing qu’en 2006 « pour ses contributions pionnières à la théorie et à la pratique des techniques utilisés par les compilateurs optimiseurs qui ont jeté les bases des compilateurs optimiseurs modernes et de l’exécution parallèle automatique. » Frances (“Fran“) Elizabeth Allen. A.M. Turing Award 2006 (en), alors qu’elle avait pris sa retraite depuis 2002. Elle reste toujours aussi importante : un de ses textes de 1970 fait partie de la bibliographie de la thèse de Delphine Demange.

Dernière question, dans son discours de remise du prix Turing en 2007, Frances Allen disait qu’après une phase de stagnation des compilateurs, on devrait avoir une phase de progrès significatifs dans le domaine. Est-ce que vous avez une idée de ce à quoi elle aurait pu penser ?

Un très grand merci à vmagnin pour son aide et les documents qu’il m’a envoyés pour m’aider à rédiger cette dépêche.