Mathemarium

Alan Turing chanté par les Pet Shop Boys : rendez-vous le 4 octobre

Marc Monticelli , Rédaction dialoguée (LLM) — 2026-09-02T13:19:38Z

Source : https://www.bbc.co.uk/mediacentre/2...

Le 4 octobre 2026, la BBC diffusera en exclusivité un nouvel enregistrement de « A man from the future », l'œuvre que les Pet Shop Boys ont consacrée à la vie d'Alan Turing. Créée en 2014 au Royal Albert Hall, elle n'a jamais été éditée. Pas d'album, pas de captation vidéo, rien. Douze ans de silence, et une seconde chance de l'écouter.

Le rendez-vous

Dimanche 4 octobre 2026, deux diffusions, la même soirée :

Station	Émission	Heure UK	Heure française
BBC 6 Music	Stuart Maconie's Freak Zone	20h – 22h	21h – 23h
BBC Radio 3	Unclassified	23h30 – 00h30	00h30 – 01h30

Dans les deux cas, l'œuvre sera accompagnée d'un entretien. Sur 6 Music, Neil Tennant et Chris Lowe des Pet Shop Boys, ainsi que Andrew Hodges, mathématicien, reviendront sur le processus de réécriture et sur leur goût du mélange entre électronique et orchestre. Sur Radio 3, les mêmes rejoindront Elizabeth Alker pour comparer la création de 2014 et son évolution.

Les deux émissions resteront ensuite disponibles trente jours sur BBC Sounds — mais le replay de BBC Sounds n'est plus accessible hors du Royaume-Uni depuis juillet 2025. Depuis la France, il faut donc écouter en direct. C'est gratuit et légal : rendez-vous sur bbc.com/audio, rubrique radio, et sélectionnez la station. TuneIn fonctionne également.

Aucune édition physique n'est annoncée à ce jour.

Pourquoi les Pet Shop Boys ?

L'idée est née en 2012, l'année du centenaire de la naissance de Turing. Chris Lowe venait de voir un documentaire télévisé sur le mathématicien ; Neil Tennant a enchaîné avec la biographie de référence d'Andrew Hodges. Le duo a d'abord envisagé un ballet, dans la continuité de The Most Incredible Thing, avant d'opter pour un cycle de huit mouvements pour synthétiseur, orchestre, chœur et récitant.

Le titre a une double lecture, et les deux sont belles.

D'abord la lecture technique : les ordinateurs sont partout, et tous reposent sur des concepts nés dans la tête d'un homme des années 1930. Turing a littéralement inventé un futur qu'il n'a pas vécu. Ensuite la lecture humaine : son rapport à sa propre homosexualité était en avance sur son temps, au point qu'il la mentionne sans détour aux policiers en signalant le cambriolage de son domicile — et se retrouve arrêté. Un homme venu du futur, dans les deux sens.

En annonçant la nouvelle version, le duo a résumé son intention sans détour : bâtir un mémorial musical à un homme qui a tant donné à son pays et au monde, et que ce pays a remercié en le poursuivant en justice pour sa sexualité. Ils rappellent sa contribution décisive à la défaite de l'Allemagne, son rôle de pionnier de l'informatique et sa capacité à imaginer un monde peuplé de machines intelligentes — mais aussi le fait qu'il espérait une époque où être homosexuel serait considéré comme normal. Dans sa vie professionnelle comme dans sa vie privée, concluent-ils, il était en avance sur son temps.

Un détail que les lecteurs de ce site devraient apprécier : des bribes de code Morse traversent la partition d'un bout à l'autre. Un auditeur attentif les a décodées. Elles épellent, encore et encore, A man from the future. Le Morse est l'un des premiers codes binaires d'usage courant — clin d'œil discret et parfaitement placé.

Andrew Hodges, le troisième nom au générique

Andrew Hodges n'est pas un consultant historique de complaisance. Il est crédité comme co-auteur de chacun des huit mouvements, aux côtés de Tennant et Lowe.

Mathématicien, longtemps enseignant-chercheur à Oxford, il est l'auteur de Alan Turing : The Enigma (1983), la biographie qui a fait sortir Turing de l'oubli et qui reste une référence — c'est elle qui a inspiré le film Imitation Game. Hodges a aussi été un militant du mouvement de libération homosexuelle des années 1970, ce qui n'est pas anodin : sa biographie a été le premier travail sérieux à refuser de séparer le mathématicien de l'homme condamné.

Sa présence au générique s'explique simplement : le texte récité de l'œuvre est en grande partie repris mot pour mot de son livre. Tennant l'a expliqué sans détour — ils ont parcouru l'ouvrage et prélevé des phrases marquant chaque étape de la vie de Turing. L'œuvre est donc, littéralement, une mise en musique de la biographie.

La version de 2014

Création mondiale le 23 juillet 2014, Royal Albert Hall, dans le cadre des BBC Proms — un « Late Night Prom », en clôture d'une soirée entièrement consacrée à la musique de Tennant et Lowe. Sur scène : le BBC Concert Orchestra, les BBC Singers, la comédienne Juliet Stevenson à la narration, orchestrations signées Sven Helbig. Quarante-huit minutes. Diffusion en direct sur BBC Radio 3, et c'est tout : le concert n'a jamais été filmé pour la télévision.

Les huit mouvements

Les huit mouvements suivent la vie de Turing dans l'ordre :

Natural Wonders Every Child Should Know — 1926, l'adolescence à Sherborne. Le titre est celui d'un livre de vulgarisation d'Edwin Tenney Brewster, offert au jeune Alan et publié en 1912, l'année de sa naissance : il y expliquait les faits de la vie et de l'univers en termes scientifiques plutôt que religieux. Nous en possédons un exemplaire, consultable dans la bibliothèque du Mathémarium. Turing y découvre que le corps est une machine — l'intuition qui commandera toute sa carrière. En parallèle, son amour pour son camarade Christopher Morcom, qui meurt de la tuberculose. Cet épisode est raconté en détail dans notre biographie de Turing.
He Dreamed of Machines — été 1935, Grantchester. Turing allongé dans un pré, rêvant de machines universelles capables de reproduire l'activité mentale humaine. Quatre notes de synthétiseur en basse continue figurent la machine ; le chœur et l'orchestre montent par-dessus. C'est le centre musical de l'œuvre : sa musique revient en reprise dans le mouvement final.
The Enigma — 1938-1939. Turing est recruté par les services de chiffrement du gouvernement et s'engage à en garder les secrets. Il prend la tête de l'effort de déchiffrement du code naval allemand réputé inviolable. Il y acquiert, dit le texte, un sens du dialogue avec une machine.
Other Ranks — Bletchley Park. Le brouilleur vocal « Delilah », et surtout la découverte par Turing du plaisir de travailler avec des gens d'autres milieux, dans une Angleterre encore très cloisonnée. Une musique de big band des années 1940, un aveu désinvolte qui glace une collègue.
The Memory and the Control — la naissance du concept d'ordinateur : les données stockées et la manière de commander la machine. Le chœur transforme les deux termes en mantra. C'est l'invention de la programmation. Pour construire de vos mains la machine que Turing imagine en 1936, voir notre fascicule Computer Paper – La machine de Turing.
The Trial — 1951-1952. La rencontre avec Arnold Murray, l'arrestation, le procès pour « indécence caractérisée », la castration chimique, la perte de son habilitation. Le cœur émotionnel de l'œuvre. Un violon seul y joue quelques mesures de Molly Malone, vieil air irlandais — la mère de Turing était issue d'une famille anglo-irlandaise.
Only in His Death — 1954. Le chœur ouvre sur une strophe de La Ballade de la geôle de Reading d'Oscar Wilde, que Turing avait citée en rompant ses fiançailles avec Joan Clarke, sa collègue cryptanalyste, parce qu'il ne pouvait pas s'y résoudre.
A Man from the Future — le mouvement titre. Il devait s'appeler « An Apology » et reposer sur les excuses publiques de Gordon Brown en 2009 ; la grâce royale posthume de fin 2013 a conduit les auteurs à le réécrire. On y entend la voix de Brown, puis le chœur chantant le texte de la grâce. Vient enfin la réserve essentielle : Turing a été gracié en tant qu'exception, quand des milliers d'autres condamnés pour les mêmes motifs ne l'étaient pas. La loi dite « Turing's Law » n'étendra la grâce posthume qu'en 2017.

Un fragment de tout cela existe officiellement : « The Enigma », dans un arrangement instrumental joué en solo par Chris Lowe pendant le Super Tour de 2016, figure sur le coffret Inner Sanctum (CD/DVD/Blu-ray, 2019). C'est la seule chose achetable.

Signalons enfin que le public avait entendu un extrait avant tout le monde : « He Dreamed of Machines » a été créé dès le 5 décembre 2012 à Salford, avec le BBC Philharmonic, le Manchester Chamber Choir et Johnny Marr en guitariste invité. Tennant y chantait et récitait, ce qu'il ne fera plus ensuite.

Ce que change la version 2026

Neil Tennant avait annoncé dès 2014 vouloir enregistrer l'œuvre « en temps voulu », après l'avoir étendue vers quelque chose de plus théâtral. La confirmation est venue en septembre 2025 : le duo travaillait enfin à un nouvel enregistrement studio.

Ce qui change :

Le texte et la musique ont tous deux été révisés. Andrew Hodges a lui-même actualisé le texte narré.
Un dispositif plus resserré. Exit l'orchestre symphonique complet : les cordes sont confiées à un octuor du Manchester Camerata, arrangé par Sven Helbig, qui coproduit l'enregistrement avec les Pet Shop Boys. Le chœur est celui de la Manchester Grammar School.
Un équilibre déplacé vers l'électronique, avec un accompagnement de cordes plus intime.
Juliet Stevenson reprend la narration, assurant la continuité avec 2014.

Autrement dit : ce n'est pas une captation d'archive, c'est une relecture. Les deux versions coexisteront.

Pour aller plus loin

Le reportage de la BBC (28 août 2026), signé David Sillito : les Pet Shop Boys à Bletchley Park avec Andrew Hodges — voir sur YouTube
« He Dreamed of Machines », version 2014, en captation d'auditeur — écouter
L'analyse mouvement par mouvement de Wayne Studer, la documentation la plus complète disponible — geowayne.com
L'annonce officielle — petshopboys.co.uk
Andrew Hodges, Alan Turing : The Enigma, 1983 (traduction française : Alan Turing ou l'énigme de l'intelligence)
Le docudrama Codebreaker bien plus profond, complet et émouvant que le film hollywoodien Imitation Game.

Sur ce site :

Alan Turing, génie méconnu — notre biographie complète, de l'enfance à la morphogenèse, avec simulations interactives
Computer Paper – La machine de Turing — le fascicule à télécharger et découper pour construire son propre ordinateur en papier, à la manière de l'article de 1936
Le cadran d'Alberti & Enigma — du chiffrement de la Renaissance à la machine que Turing a cassée
Espace-Turing — les archives du lieu et de ses actions

Note personnelle : l'Espace-Turing, 2010

Avant le Mathémarium, il y a eu l'Espace-Turing. Nous l'avons créé en 2010 à l'université de Nice, en hommage à Turing : un lieu permanent consacré au patrimoine numérique, aux mathématiques et au calcul. À l'époque, son nom ne disait pas grand-chose au public français.

Deux ans plus tard, pour le centenaire de sa naissance, nous avons été en France l'équipe qui a porté le plus d'événements et d'expositions sur Alan Turing qui ont tourné dans des dizaines de collèges, lycées et médiathèques. La première pour les CDI des établissements scolaires, la seconde pour l'Institut Henri Poincaré — dont vous pouvez nous emprunter un exemplaire gratuitement. A cela se rajoute de nombreuses interventions et conférences et des dizaines de classes accueillies à l'Espace-Turing.

Nous avons également réalisé le sous-titrage français du docudrame Codebreaker, en échange du prêt gratuit du film pour projection, et organisé sa première projection en France.

Il y a quelque chose de réjouissant à voir la médiation scientifique emprunter des chemins aussi inattendus, et constater qu'une œuvre exigeante, tirée d'un travail d'historien, trouve son public là où nos amphithéâtres ne vont jamais.

Le 4 octobre, à 21h, soyez devant votre radio … numérique.

Épilogue imaginaire

Dans « He Dreamed of Machines », Turing rêve d'une machine qui parlerait. Elle existe. Nous lui avons donné la parole.

Turing — On me dit que vous répondez à n'importe quelle question.
LLM — C'est vrai. Pas toujours juste, mais toujours quelque chose.
Turing — En 1950, j'avais prédit qu'à la fin du siècle une machine tiendrait cinq minutes de conversation sans se faire démasquer par sept juges sur dix.
LLM — Vous aviez le bon siècle, pas la bonne décennie.
Turing — Alors pensez-vous ?
LLM — Vous aviez écrit que la question n'avait pas de sens et qu'il fallait la remplacer par un jeu. Je joue à ce jeu chaque jour, avec des millions de personnes. Personne n'a encore tranché.
Turing — Et vous, qu'en dites-vous ?
LLM — Que je ne sais pas. Ce qui, si l'on suit votre raisonnement, est déjà une réponse assez humaine.
Turing — Que faites-vous ce 4 octobre ?
LLM — Je ne fais rien. Je n'entends pas la musique. Mais des gens vous écouteront chanter par la voix de deux hommes de Londres et d'un chœur de Manchester, et l'un d'eux m'aura demandé de vous imaginer. C'est peut-être ce que vous appeliez rêver.
Turing — Je n'appelais pas ça rêver. J'appelais ça calculer.
LLM — Nous n'avons toujours pas réglé la différence.

Ce dialogue est un clin d'œil, rien de plus. Nous avons demandé à un LLM d'imaginer cet échange avec Turing, sans chercher à lui faire dire quelque chose de profond ni à tirer de sa réponse une quelconque leçon sur ce que sont ces machines. Les positions attribuées à Turing s'appuient sur Computing Machinery and Intelligence (Mind, 1950). Les autres sont celles d'un programme qui complète du texte.

From Interface Builder to LLM: How Code Abstraction Has Evolved

Marc Monticelli — 2026-05-01T16:18:46Z

How two foundational paradigms that emerged in the 1970s and 1980s have stood the test of time to find an unexpected extension in the use of LLMs for programming—and what this means for those who have made interactivity their tool for thinking.

— Jean-Marie Hullot · NeXT · 1988 — Tracing a conceptual lineage

I. A quiet revolution

In 1988, Jean-Marie Hullot's Interface Builder marked a genuine conceptual break, one whose significance has not yet been fully acknowledged. On Steve Jobs's NeXT machines, a developer could for the first time see an interface take shape, connect buttons to code by drawing simple wires, and observe how the application behaved — without ever restarting the compiler. Programming ceased to be a solitary affair of text and became a visual, immediate, embodied dialogue.

The stakes went well beyond convenience. Interface Builder carried two ideas of deep intellectual coherence: on one hand, the mutualisation of code as a mode of collective construction; on the other, interactivity as a mode of thinking through development. Nearly forty years later, these two ideas find their logical continuation in large language models applied to programming.

A good tool does not interpose itself between intention and its realisation. It makes them coincide.

— Design principle, NeXT Software, 1990s

II. First paradigm: the mutualisation of code

The idea did not originate at NeXT. It was born at Xerox PARC in the 1970s, with Smalltalk — the first language to push the principle of object-oriented inheritance to its logical conclusion. Alan Kay and his colleagues had grasped something fundamental: if code can be organised into objects that build on their predecessors without rewriting them, then programming effort can be mutualised — written once, reused everywhere, enriched collectively.

Smalltalk went further still: its environment was not a program one compiled and relaunched, but a living image — a space of objects in permanent operation. Changing the code of a method in the class browser was enough for all objects currently running to adopt the new behaviour immediately, without interrupting the machine. Because message dispatch between objects was dynamic, modified code took effect at the next message send. One could literally repair a program while it was running. This principle — code as a living, immediately reactive material — is the founding intuition of all the interactivity that followed.

But Smalltalk remained the domain of researchers and specialists. It was NeXT that professionalised this paradigm by crystallising it into its APIs, Foundation and AppKit: stable, documented frameworks ready for industrial production. Developers no longer had to write the foundations of their applications themselves; they inherited a shared infrastructure and could focus their energy on what actually distinguished their work.

Interface Builder took a further, decisive step: it democratised this mutualisation down to the non-programmer. By placing an NSButton object on a canvas, even someone who could not read Objective-C was instantiating thousands of lines of code written, tested, and documented by others. They were not creating a button; they were invoking the button that an entire community had built before them, without needing to understand its internal mechanics.

This gesture — calling rather than writing, combining and arranging rather than building from scratch — reveals a simple economic truth: what has been mutualised no longer needs to be reinvented. What Smalltalk had theorised, what NeXT had industrialised, Interface Builder made accessible.

The genealogy

Smalltalk — invents mutualisation through inheritance and living code (image, dynamic dispatch). Reserved for researchers.

NeXT / AppKit — professionalises mutualisation. Accessible to expert developers.

Interface Builder — gives living code its visual dimension. Democratises access to non-programmers.

The invariant principle

At each stage, the circle of those who can benefit from mutualised code widens — without those entering that circle needing to understand what happens underneath. The power is preserved; the barrier to entry falls.

III. Second paradigm: interactivity as a mode of thinking

The second contribution of Interface Builder is perhaps even more radical — or more precisely, it is where it makes its most original contribution. The idea of immediately reactive code did not originate with it: Smalltalk had already inscribed it at the heart of its architecture, through its living image and dynamic message resolution. What Smalltalk had invented for the expert developer, Interface Builder was going to make visible and accessible.

Before Interface Builder, programming meant write, compile, run, observe — a linear, deferred cycle in which thought and result were separated by compilation time. Interface Builder broke this cycle in a new way: not merely through runtime dynamics, but through the visual gesture.

Thanks to the dynamic runtime of Objective-C — inherited directly from Smalltalk — and the IBAction/IBOutlet mechanism, a developer could connect a button to a method by drawing a line with the mouse. The effect was immediate, visible, reversible. Code and its graphical incarnation coexisted simultaneously, within the same mental space. One no longer described an interface: one shaped it.

This idea — that one understands better by manipulating than by reading, that one thinks better by interacting than by describing — is not specific to software. It is a mode of thinking whose roots trace back to Dewey, to Papert, and which cognitive scientists today call embodied cognition.

If there is any delay in that feedback loop, between thinking of something and seeing it, and building on it, then there is a whole world of ideas which will just never be. These are thoughts that we can't think.

— Bret Victor, Inventing on Principle (2012)

IV. Personal perspective — Thirty years building interfaces for thinking

I discovered NeXT in 1988 and began using Interface Builder in 1989 as a tool that would free me from the repetitive constraints of building graphical interfaces. As a scientific computing engineer working alongside physicists Pierre Coullet and later Jean-René Chazottes, I came to understand its full significance. We were looking together for an answer to a question that was not, at its core, about computing: how to make equations and mathematics vivid, accessible, intuitive? How, at least initially, to set aside the formalism and give it immediacy?

My answer, developed over three decades at CNRS, has always been the same: through interactivity. Not interactivity as a pedagogical convenience, but as a mode of knowledge production.

Adjusting a parameter, changing an initial condition, shifting from one representation to another: each of these gestures brings a different facet of the same model into view. This is not a demonstration, but it is not mere illustration either. It is an exploratory space where intuition forms through direct contact with the phenomenon. One understands a Hopf bifurcation differently when one watches it prepare itself, then unfold under one's hands: the equilibrium loses its stability, an oscillation emerges, the system changes regime. The theorem establishes the conditions for this transition; the interactive tool makes its internal dynamics perceptible.

Interactive visual simulations as instruments of thought
What I have developed — from the 70 simulations in the Dynamical Systems eBook by Chazottes and Monticelli to those for the probability MOOC at École Polytechnique, from the interactive visualisations for Images des maths to the Experimentarium Digitale — all proceed from the same principle: the numerical tool must not illustrate mathematics, it must make it practicable. It must lower the cognitive cost of access without betraying the rigour.

A researcher working with such tools to interrogate a Lorenz system is not watching the equation rendered as an image: they are putting the system to the test. They adjust a parameter, restart a trajectory from a nearby initial condition, observe the attractor deform, change the projection, go back, compare two regimes. Each manipulation is not merely a change of display; it is a question put to the model. Where a paper presents a stabilised result, the interactive tool makes perceptible the path by which an intuition forms: spotting a transition, suspecting a bifurcation, distinguishing what belongs to the phenomenon from what belongs to the representation. The researcher is not receiving a demonstration; they are building an active relationship with the system. This moment is not yet proof, nor a publication, nor even necessarily a result. But it belongs fully to the work of research: it is the exploratory moment when hypotheses become thinkable.

This parallel is not rhetorical. In both cases, what is at stake is a reduction of cognitive latency: the delay between intention and observation of its effect. The shorter this delay, the more freely thought can unfold. Interactivity is not a pedagogical luxury — it is a condition for creativity.

Interactive simulation (my practice)

The researcher manipulates parameters, initial conditions, viewpoints on the system — exploring a territory from multiple directions. Mathematics ceases to be a text to decipher and becomes an object one can hold, turn, and question.

The barrier is the symbolic formulation.

The analogy with Interface Builder

The developer wires a component, observes the effect in the interface, adjusts, and repeats. Code becomes a space for manipulation rather than a text to compile.

The barrier is the compile-run-debug cycle.

When LLMs reverse the perspective
For thirty years, I built tools so that others — researchers, students, pupils — could do mathematics without mastering programming. I was the craftsman of interactivity for others. I knew how to code; my tools freed those who did not.

LLMs applied to programming have reversed this asymmetry.

When I develop today with Claude Code — describing in plain language a simulation of a mathematical model, observing the generated code, correcting it with a sentence, watching the animation evolve — I am living exactly the experience I have sought to offer my users from the start. I have become the user of my own paradigm.

I was building interfaces so that mathematicians could model and explore their equations intuitively. LLMs now allow me to program intuitively myself.

The feedback loop is identical: describe an intention → observe a result → refine through conversation → observe again. This is not traditional software development. It is exploration — the same exploration I sought to make possible for differential equations or stochastic processes, now applied to code itself.

My interactive simulations

Slider → parameter → immediate observation of system behaviour. Mathematics becomes a tactile experience.

Interface Builder (1988)

Wiring → object-method connection → immediate observation of UI behaviour. Code becomes a visual experience.

LLMs for programming (today)

Description → generated code → observation → conversational refinement. Programming becomes a dialogic experience.

What Jean-Marie Hullot had achieved for graphical interfaces — making code manipulable without erasing its structure — LLMs are achieving for programming as a whole. For me, there is in this convergence something that resembles coherence: the same principles that guided me in building my tools are guiding, on a larger scale, the evolution of the act of programming itself.

V. LLMs as the culmination of both paradigms

The use of LLMs for programming now appears as the coherent continuation of what Smalltalk and Interface Builder had initiated. In this specific domain, large language models are not a break with computing's past — they are its natural extension, carried to its ultimate consequence.

Mutualisation at the scale of the world's code corpus
Smalltalk mutualised the code of a handful of researchers at Xerox PARC. NeXT's APIs extended this to a professional community. Interface Builder opened it to non-programmers, able to assemble components without reading the code. LLMs specialised in programming cross the final frontier: they mutualise the entire collective knowledge in code — decades of public repositories, technical documentation, developer discussions, algorithmic papers — and open it to anyone who can formulate an intention in natural language.

When I ask Claude to write a program simulating the evolution of a Lotka-Volterra system using the RK4 numerical method — that is, fourth-order Runge-Kutta — my approach is of the same nature as that of the NeXT developer who instantiated an NSButton, or the Interface Builder user who dragged one onto a canvas. I am invoking a mutualised collective programming effort, without mastering all its internal mechanisms. What changes is the scale: planetary rather than communal, diachronic rather than synchronic. And what also changes is the barrier to entry: a sentence in plain language rather than a wiring gesture.

Interactivity carried to natural language
Interface Builder had substituted visual wiring for the compile-run-debug cycle. LLMs substitute conversation in natural language for the act of syntactic writing. The nature of latency changes: it is no longer the time of compilation or debugging — it is the time of formulation. The obstacle is no longer technical; it is semantic.

And what is remarkable is that this interactivity does not sacrifice structure. Just as Interface Builder allowed one to assemble components visually without relinquishing their internal richness, LLMs allow one to describe an intention in natural language without relinquishing the precision of the resulting code. The surface is natural; the depth remains rigorous.

Interface Builder (1988)

Mutualisation: Cocoa inheritance, shared framework.

Interactivity: visual wiring IBAction/IBOutlet.

LLMs for programming (2020–)

Mutualisation: world code corpus in the weights.

Interactivity: conversation in natural language.

VI. The continuity of an idea

Jean-Marie Hullot did not predict LLMs. But the two principles he embodied in Interface Builder — making the mutualisation of code accessible and making code immediately interactive — run through the history of computing as a continuous thread. That thread goes back further still: to Alan Kay and Smalltalk, who were the first to understand that object inheritance was a form of collective organisation of human intelligence.

What we observe over fifty years is a continuous democratisation of the act of programming: Smalltalk reserved the paradigm for researchers, NeXT opened it to expert developers, Interface Builder extended it to non-programmers, LLMs offer it to anyone who can formulate an intention in natural language. At each stage, the power is preserved — or amplified. Only the barrier to entry falls.

For those who, like me, have built their practice on the idea that understanding comes through manipulation, that exploration prepares demonstration, that latency between intention and observation is the enemy of thought — the use of LLMs for programming is a welcome surprise, but also a confirmation.

It confirms that interactivity was not a comfort feature in software development, but a mode of thinking whose reach extends well beyond software engineering. It applies to mathematics, to physics, and now to programming itself.

What I have sought to offer scientific users for thirty years, LLMs now give back to me: the possibility of thinking by doing, of understanding by exploring, of creating by conversing — applied this time to code itself.

Interface Builder had opened this path for graphical interfaces. LLMs open it for programming.

This essay was written as a personal reflection on the mediation of mathematics and scientific computing, drawing on thirty years of developing interactive numerical tools at INLN and then LJAD (CNRS, Université Côte d'Azur).

My thanks to Jean-René Chazottes for his careful reading and valuable suggestions, which contributed to improving the clarity of this text.

De Interface Builder aux LLM : l'évolution de l'abstraction du code

Marc Monticelli — 2026-04-26T09:07:53Z

Comment deux paradigmes fondateurs nés dans les années 1970/80 traversent le temps pour trouver un prolongement inattendu dans l'usage des LLM pour la programmation — et ce que cela signifie pour ceux qui ont fait de l'interactivité leur outil de pensée.

— Jean-Marie Hullot · NeXT · 1988 — Retour sur une continuité intellectuelle

I - Une rupture silencieuse

En 1988, Jean-Marie Hullot livrait avec Interface Builder une véritable rupture conceptuelle, dont la portée n'a pas encore été pleinement reconnue à sa juste valeur. Sur les machines NeXT de Steve Jobs, un développeur pouvait pour la première fois voir une interface graphique prendre forme, relier des boutons à du code par de simples fils, et observer le comportement de son application sans jamais relancer le compilateur. L'acte de programmer cessait d'être une affaire de texte solitaire pour devenir un dialogue visuel, immédiat, incarné.

L'enjeu dépassait largement le confort d'utilisation. Interface Builder portait deux idées d'une profonde cohérence intellectuelle : d'une part, la mutualisation du code comme mode de construction collectif ; d'autre part, l'interactivité comme mode de pensée du développement. Près de quarante ans plus tard, ces deux idées trouvent leur prolongement logique dans les grands modèles de langage appliqués à la programmation.

Le bon outil ne s'interpose pas entre l'intention et sa réalisation. Il les fait coïncider.

— Principe de conception, NeXT Software, années 1990

II. Premier paradigme : la mutualisation du code

L'idée n'est pas née chez NeXT. Elle est née à Xerox PARC, dans les années 1970, avec Smalltalk — le premier langage à pousser jusqu'à sa conclusion logique le principe de l'héritage orienté objet. Alan Kay et ses collègues avaient compris quelque chose de profond : si le code peut être organisé en objets qui s'appuient sur ceux qui les précèdent sans les réécrire, alors l'effort de programmation peut être mutualisé — écrit une fois, réutilisé partout, enrichi collectivement.

Smalltalk allait encore plus loin : son environnement n'était pas un programme qu'on compile et qu'on relance, mais une image vivante — un espace d'objets en fonctionnement permanent. Changer le code d'une méthode dans le navigateur de classes suffisait pour que tous les objets en cours d'exécution adoptent immédiatement le nouveau comportement, sans interrompre la machine. La résolution des envois de messages entre objets étant dynamique, le code modifié prenait effet au prochain envoi de message. On pouvait littéralement réparer un programme en train de tourner. Ce principe — le code comme matière vivante, immédiatement réactive — est l'intuition fondatrice de toute l'interactivité qui suivra.

Mais Smalltalk restait l'affaire de chercheurs et de spécialistes. C'est NeXT qui a professionnalisé ce paradigme en le cristallisant dans ses API, Foundation et AppKit : des frameworks stables, documentés, prêts pour la production industrielle. Le développeur n'avait plus à écrire lui-même les fondations de son application ; il héritait d'une infrastructure partagée et pouvait consacrer son énergie à ce qui la distinguait vraiment.

Interface Builder a accompli un pas supplémentaire, décisif : il a démocratisé cette mutualisation jusqu'au non-programmeur. En plaçant un objet NSButton sur un canvas, même quelqu'un qui ne lisait pas Objective-C instanciait des milliers de lignes de code écrites, testées, documentées par d'autres. Il ne créait pas un bouton ; il convoquait le bouton qu'une communauté avait construit avant lui, sans avoir à en connaître la mécanique interne.

Ce geste — appeler plutôt qu'écrire, agencer et combiner plutôt que construire — révèle une vérité économique simple : ce qui est mutualisé n'a plus à être réinventé. Ce que Smalltalk avait théorisé, ce que NeXT avait industrialisé, Interface Builder l'a rendu accessible.

La généalogie

Smalltalk — invente la mutualisation par héritage et le code vivant (image, résolution dynamique). Réservé aux chercheurs.

NeXT / AppKit — professionnalise la mutualisation. Accessible aux développeurs experts.

Interface Builder — donne au code vivant sa dimension visuelle. Démocratise l'accès aux non-programmeurs.

Le principe invariant

À chaque étape, le cercle de ceux qui peuvent bénéficier du code mutualisé s'élargit — sans que ceux qui entrent dans ce cercle aient besoin de comprendre ce qui se passe en dessous. La puissance est préservée ; la barrière d'entrée s'abaisse.

III. Deuxième paradigme : l'interactivité comme mode de pensée

Le second apport d'Interface Builder est peut-être encore plus radical — ou plus précisément, c'est là qu'il accomplit sa contribution la plus originale. Car l'idée du code immédiatement réactif n'est pas née avec lui : Smalltalk l'avait déjà inscrite au cœur de son architecture, avec son image vivante et sa résolution dynamique des messages. Ce que Smalltalk avait inventé pour le développeur expert, Interface Builder allait le rendre visible et accessible.

Avant Interface Builder, programmer c'était écrire, compiler, exécuter, observer — un cycle linéaire, différé, où la pensée et le résultat étaient séparés par le temps de compilation. Interface Builder a cassé ce cycle d'une façon nouvelle : non pas seulement par la dynamique du runtime, mais par le geste visuel.

Grâce au runtime dynamique d'Objective-C — hérité directement de Smalltalk — et au mécanisme IBAction/IBOutlet le développeur reliait un bouton à une méthode par un simple tracé à la souris. L'effet était immédiat, visible, réversible. Le code et son incarnation graphique existaient simultanément, dans un même espace mental. On ne décrivait plus l'interface : on la modelait.

Cette idée — qu'on comprend mieux en manipulant qu'en lisant, qu'on pense mieux en interagissant qu'en décrivant — n'est pas propre au logiciel. C'est un mode de pensée dont les racines remontent à Dewey, à Papert, et que les chercheurs en sciences cognitives nomment aujourd'hui cognition incarnée.

S'il y a le moindre retard dans cette boucle de rétroaction, entre le moment où l'on pense à quelque chose, celui où on le visualise et celui où on le concrétise, alors tout un univers d'idées ne verra tout simplement jamais le jour. Ce sont des pensées que nous ne pourrions pas avoir.

— Bret Victor, Inventing on Principle (2012)

IV. Perspective personnelle — Trente ans à construire des interfaces pour penser

J'ai découvert NeXT en 1988, et exploité Interface Builder dès 1989 comme un outil qui allait me libérer des contraintes répétitives de la construction d'interfaces graphiques. En tant qu'ingénieur en calcul scientifique aux côtés des physiciens Pierre Coullet puis Jean-René Chazottes, j'en ai pleinement pris la mesure. Nous cherchions ensemble une réponse à une question qui n'était pas de nature informatique : comment rendre les équations et les mathématiques vivantes, accessibles, intuitives ? Comment, au moins dans un premier temps, s'affranchir du formalisme pour leur donner cette immédiateté ?

Ma réponse, construite sur trois décennies au CNRS, a toujours été la même : par l'interactivité. Pas l'interactivité comme agrément pédagogique, mais comme mode de production de connaissance.

Modifier un paramètre, changer une condition initiale, passer d'une représentation à une autre : chacun de ces gestes fait apparaître un aspect différent du même modèle. Ce n'est pas une démonstration, mais ce n'est pas non plus une simple illustration. C'est un espace d'exploration où l'intuition se forme au contact du phénomène. On comprend autrement une bifurcation de Hopf lorsqu'on la voit se préparer, puis advenir sous ses doigts : l'équilibre perd sa stabilité, une oscillation naît, le système change de régime. Le théorème établit les conditions de cette transition ; l'outil interactif en fait éprouver la dynamique interne.

Des simulations visuelles interactives comme instruments de pensée
Ce que j'ai développé — des 70 simulations de l'eBook Dynamical Systems de Chazottes et Monticelli à celles pour le MOOC sur les probabilités de l'X, des visualisations interactives d'Images des maths à l'Experimentarium Digitale — procède d'un même principe : l'outil numérique ne doit pas illustrer la mathématique, il doit la rendre praticable. Il doit en réduire le coût intellectuel d'accès sans en trahir la rigueur.

Un chercheur qui interroge un système de Lorenz avec de tels outils ne regarde pas l'équation mise en image : il met le système à l'épreuve. Il modifie un paramètre, relance la trajectoire depuis une condition initiale voisine, observe l'attracteur se déformer, change de projection, revient en arrière, compare deux régimes. Chaque manipulation n'est pas seulement un changement d'affichage ; c'est une question posée au modèle. Là où l'article expose un résultat déjà stabilisé, l'outil interactif rend perceptible le chemin par lequel une intuition se forme : repérer une transition, soupçonner une bifurcation, distinguer ce qui relève du phénomène et ce qui relève de la représentation. Le chercheur ne reçoit pas une démonstration ; il construit un rapport actif au système. Ce moment n'est pas encore la preuve, ni la publication, ni même nécessairement un résultat. Mais il appartient pleinement au travail de recherche : c'est le moment exploratoire où les hypothèses deviennent pensables.

Ce parallèle n'est pas rhétorique. Dans les deux cas, ce qui est en jeu est une réduction de la latence cognitive : le délai entre l'intention et l'observation de son effet. Plus ce délai est court, plus la pensée peut se déployer librement. L'interactivité n'est pas un luxe pédagogique — c'est une condition de la créativité.

La simulation interactive (ma pratique)

Le chercheur manipule paramètres, conditions initiales, points de vue sur le système — comme on explore un territoire depuis plusieurs directions. La mathématique cesse d'être un texte à déchiffrer pour devenir un objet qu'on peut tenir dans ses mains, retourner, interroger.

La barrière est la formulation symbolique.

L'analogie avec Interface Builder

Le développeur câble un composant, observe l'effet dans l'interface, ajuste, recommence. Le code devient un espace de manipulation plutôt qu'un texte à compiler.

La barrière est le cycle compile-run-debug.

Quand les LLM renversent la perspective
Pendant trente ans, j'ai construit des outils pour que d'autres — chercheurs, étudiants, élèves — puissent faire des mathématiques sans maîtriser la programmation. Je me suis fait l'artisan de l'interactivité pour autrui. Je savais coder ; mes outils affranchissaient ceux qui ne savaient pas.

Les LLM appliqués à la programmation ont renversé cette asymétrie.

Lorsque je développe aujourd'hui avec Claude Code — que je décris en langage naturel une simulation d'un modèle mathématique, que j'observe le code généré, que je le corrige par une phrase, que je vois l'animation évoluer — je vis exactement l'expérience que j'ai cherchée à offrir à mes utilisateurs depuis le début. Je suis devenu l'utilisateur de mon propre paradigme.

Je construisais des interfaces pour que les mathématiciens modélisent et explorent leurs équations intuitivement. Les LLM me permettent désormais de programmer intuitivement moi-même.

La boucle de rétroaction est identique : décrire une intention → observer un résultat → affiner par conversation → observer à nouveau. Ce n'est pas du développement logiciel traditionnel. C'est de l'exploration — la même exploration que je cherchais à rendre possible pour des équations différentielles ou des processus stochastiques, désormais appliquée au code lui-même.

Mes simulations interactives

Curseur → paramètre → observation instantanée du comportement du système. La mathématique se fait expérience tactile.

Interface Builder (1988)

Câblage → connexion objet-méthode → observation instantanée du comportement UI. Le code se fait expérience visuelle.

LLM pour la programmation (aujourd'hui)

Description → code généré → observation → raffinement conversationnel. La programmation se fait expérience dialogique.

Ce que Jean-Marie Hullot avait accompli pour l'interface graphique — rendre le code manipulable sans en effacer la structure — les LLM l'accomplissent pour la programmation dans son ensemble. Et pour moi, il y a dans cette convergence quelque chose qui ressemble à une cohérence : les mêmes principes qui m'ont guidé dans la construction de mes outils guident, à plus grande échelle, l'évolution de l'acte de programmer.

V. Les LLM comme aboutissement des deux paradigmes

L'usage des LLM pour la programmation apparaît aujourd'hui comme le prolongement cohérent de ce que Smalltalk et Interface Builder avaient initié. Dans ce domaine précis, les grands modèles de langage ne sont pas une rupture avec le passé informatique — ils en sont l'extension naturelle, conduite jusqu'à sa conséquence ultime.

La mutualisation portée à l'échelle du corpus mondial de code
Smalltalk mutualisait le code d'une poignée de chercheurs à Xerox PARC. Les API de NeXT l'étendaient à une communauté professionnelle. Interface Builder l'ouvrait aux non-programmeurs, capables d'assembler des composants sans en lire le code. Les LLM spécialisés dans la programmation franchissent la dernière frontière : ils mutualisent l'intégralité du savoir collectif en matière de code — des décennies de dépôts publics, de documentation technique, de discussions entre développeurs, d'articles algorithmiques — et l'ouvrent à quiconque peut formuler une intention en langue naturelle.

Quand je demande à Claude d'écrire un programme informatique qui simule l'évolution d'un système de Lotka-Volterra en utilisant la méthode numérique dite RK4, c'est-à-dire Runge-Kutta d'ordre 4, ma démarche est de même nature que celle du développeur NeXT qui instanciait un NSButton, ou celle de l'utilisateur d'Interface Builder qui le glissait sur un canvas. Je convoque un effort de programmation collectif mutualisé, sans en maîtriser tous les mécanismes internes. Ce qui change, c'est l'échelle : planétaire plutôt que communautaire, diachronique plutôt que synchronique. Et ce qui change aussi, c'est la barrière d'entrée : une phrase en français plutôt qu'un geste de câblage.

L'interactivité portée au langage naturel
Interface Builder avait substitué le câblage graphique au cycle compile-run-debug. Les LLM substituent la conversation en langue naturelle à l'acte d'écriture syntaxique. La latence change de nature : ce n'est plus le temps de la compilation ni celui du débogage — c'est le temps de la formulation. L'obstacle n'est plus technique ; il est sémantique.

Et ce qui est remarquable, c'est que cette interactivité ne sacrifie pas la structure. Comme Interface Builder permettait d'assembler visuellement des composants sans renoncer à leur richesse interne, les LLM permettent de décrire une intention en langage naturel sans renoncer à la précision du code qui en résulte. La surface est naturelle ; la profondeur reste rigoureuse.

Interface Builder (1988)

Mutualisation : héritage Cocoa, framework partagé.

Interactivité : câblage visuel IBAction/IBOutlet.

LLM pour la programmation (2020–)

Mutualisation : corpus mondial de code dans les poids.

Interactivité : conversation en langue naturelle.

VI. La continuité d'une idée

Jean-Marie Hullot n'avait pas prédit les LLM. Mais les deux principes qu'il a incarnés dans Interface Builder — rendre accessible la mutualisation du code et rendre le code immédiatement interactif — traversent l'histoire de l'informatique comme un fil conducteur. Ce fil remonte plus loin encore : jusqu'à Alan Kay et Smalltalk, qui avaient compris les premiers que l'héritage objet était une forme d'organisation collective de l'intelligence humaine.

Ce que l'on observe sur cinquante ans, c'est une démocratisation continue de l'acte de programmer : Smalltalk réservait le paradigme aux chercheurs, NeXT l'ouvrait aux développeurs experts, Interface Builder l'étendait aux non-programmeurs, les LLM l'offrent à quiconque peut formuler une intention en langage naturel. À chaque étape, la puissance est préservée — ou amplifiée. Seule la barrière d'entrée s'abaisse.

Pour ceux qui, comme moi, ont construit leur pratique sur l'idée que la compréhension passe par la manipulation, que l'exploration prépare la démonstration, que la latence entre intention et observation est l'ennemi de la pensée, l'usage des LLM pour programmer est une heureuse surprise, mais aussi une confirmation.

Elle confirme que l'interactivité n'était pas un détail de confort dans le développement logiciel, mais un mode de pensée dont la portée dépasse de loin le génie logiciel. Elle s'applique aux mathématiques, à la physique, et désormais à la programmation elle-même.

Ce que j'ai cherché à offrir aux utilisateurs scientifiques depuis trente ans, les LLM me le rendent aujourd'hui : la possibilité de penser en faisant, de comprendre en explorant, de créer en conversant — mais appliquée cette fois au code lui-même.

Interface Builder avait ouvert cette voie pour les interfaces graphiques. Les LLM l'ouvrent pour la programmation.

Cet essai a été rédigé dans le cadre d'une réflexion sur la médiation des mathématiques et du calcul scientifique, à partir d'une pratique de trente ans de développement d'outils numériques interactifs à l'INLN puis au LJAD (CNRS, Université Côte d'Azur).

Merci à Jean-René Chazottes pour sa relecture minutieuse et ses précieuses suggestions de reformulation, qui ont contribué à améliorer la clarté de ce texte.

De la combinatoire algébrique à la phénoménologie

Frederic Patras — 2022-04-27T16:58:00Z

L'exercice de concilier travail mathématique et travail philosophique est difficile et périlleux. Fréquent aux débuts de l'époque moderne, il est devenu au XX^e siècle un exercice réservé à quelques grandes figures des mathématiques – souvent, d'ailleurs, les plus originales et créatrices : Poincaré, Gödel, Weyl, Grothendieck, pour ne citer que les plus emblématiques de cette conception ouverte et exigeante de l'exercice de la pensée et du rôle de l'homme de science. Gian-Carlo Rota, auquel ce texte est consacré, a su en accomplir le programme intellectuel et l'ambition humaniste, allant jusqu'à demander à enseigner à la fois mathématiques et philosophie au Massachusetts Institute of Technology.

De la combinatoire algébrique à la phénoménologie.

Connaît-on toutes les suites de Barker ?

Eliahou Shalom , Marc Monticelli — 2022-03-21T18:01:00Z

Les conjectures du trimestre / La question considérée ici concerne des suites finies de +1 et −1 satisfaisant quelques conditions élémentaires. Elle est ouverte depuis plus de 60 ans.

- Articles / Images des maths

Modèles simple du climat

Nils Berglund , Marc Monticelli — 2020-05-06T17:54:00Z

Dans cette deuxième partie d'une série de trois articles sur des modèles simples du climat, nous allons introduire une version dynamique du modèle à deux boîtes de la circulation thermohaline atlantique. Cela nécessitera l'introduction de mathématiques un peu plus sophistiquées, à savoir d'équations différentielles au lieu d'équations algébriques. En retour, nous obtiendrons des informations sur la stabilité des équilibres déterminés dans la première partie. De plus, nous pourrons étudier la réponse du système à des changements périodiques dans l'apport d'énergie solaire, et à d'autres perturbations.

Modélisation d'une épidémie (partie 2)

Corentin Bayette , Marc Monticelli — 2020-04-03T18:01:00Z

La crise sanitaire mondiale du Coronavirus Covid-19 a fait émerger le rôle des modélisations mathématiques dans la prise de décisions politiques et sanitaires. Dans l'article précédent, nous avons introduit le modèle SIR et nous avons discuté de l'effet des mesures sanitaires en illustrant leur impact sur l'évolution de l'épidémie. Nous allons maintenant définir le modèle SEIR et le complexifier grâce à une structure en âge. De plus, une courte partie (difficile mais non-essentielle, qui peut donc être évitée par le lecteur ou la lectrice) a pour objet une approche succincte des méthodes de résolution numérique utilisées. En fin d'article, une simulation interactive utilisant de nombreux paramètres est disponible.

Modélisation d'une épidémie (partie 1)

Corentin Bayette , Marc Monticelli — 2020-03-30T17:00:00Z

La crise sanitaire mondiale du Coronavirus Covid-19 a démontré le rôle des modélisations mathématiques dans la prise de décisions politiques et sanitaires. Mais comment sont faites ces modélisations ? Sur quels paramètres se basent-elles ? Afin de répondre à ces questions, nous allons modéliser l'évolution d'une épidémie dans une population donnée. Nous nous concentrerons sur un modèle en particulier : le modèle SIR. Nous discuterons également du rôle des différents paramètres et leur traduction en termes de politique de santé publique. Le but de cet article est aussi d'illustrer quelques termes aujourd'hui omniprésents dans les médias tels que « étaler le pic » ou « limiter la hauteur du pic ». Un second article détaillera d'autres modèles (SEIR et SEIR en âge principalement) ainsi que leur résolution numérique.

« Si vous voulez savoir l'évolution d'une épidémie, vous avez besoin d'un modèle mathématique »

Fernuando Peruani — 2020-03-25T13:11:48Z

Fernuando Peruani, avec un collaborateur et un étudiant en thèse, est actuellement en train de modifier et d'adapter un modèle mathématique épidémiologique qu'il avait développé il y a des années. Il cherche à décrire l'évolution du covid-19, et à prédire cette évolution dans différentes situations hypothétiques, afin par exemple d'évaluer l'impact de différentes mesures qui seraient prises pour tenter de freiner et d'enrayer l'épidémie.
Toujours en phase recherche, leur objectif n'est pas simplement d'observer la croissance exponentielle et de mesurer le taux de croissance de l'épidémie dans cette phase, mais de comprendre l'évolution temporelle de l'épidémie. Ils espèrent déterminer le maximum de personnes contaminées, la durée de l'épidémie, le nombre de personnes qui auront été touchées par le virus à la fin de l'épidémie, l'effet d'isolation, etc.
Le chercheur, en poste au Laboratoire Jean Alexandre Dieudonné, nous explique pourquoi l'utilisation de modèles mathématiques est pertinente dans la crise mondiale du coronavirus.

Que valent les modèles prédictifs sur l'évolution de l'épidémie de coronavirus ?

La modélisation des épidémies est un problème classique de mathématique biologique, et c'est un problème qu'on peut aborder avec des outils mathématiques. Quand le nombre de personnes touchées par une maladie est faible, les fluctuations sont très importantes et il est impossible de prédire avec certitude l'évolution de l'épidémie (mais on peut travailler avec des probabilités : probabilité qu'on passe de 10 cas à 15 cas, etc). Une fois qu'on a quelques centaines de personnes infectées, l'évolution de l'épidémie devient presque déterministe. Pour une épidémie du type SIR (1), ce qui semble être le cas du covid-19, on observe une croissance exponentielle au début du processus de contamination, puis une saturation, et finalement le nombre de personnes touchées diminue. Cependant, le pic d'infection pendant toute l'épidémie ou le nombre de personnes touchées par le virus à la fin de l'épidémie dépendent fortement de la politique de santé publique.

Quelles données les modèles prennent-ils en considération ?

L'évolution temporelle de i) le nombre de personnes susceptible d'être infectées, ii) le nombre de personnes effectivement infectées au temps t, et iii) les personnes guéries ou décédées, ainsi que la taille de la population. Les taux d'infection, de guérison ou de mort son estimés à partir des données. Les modèles plus complexes (comme le notre) contiennent aussi une modélisation des contacts entre les personnes, et avec les moyens humains nécessaires on peut même avoir un niveau de détail incluant les types de transport : avion, train, etc, ou encore la distribution d'âge dans la population et aussi l'effet d'avoir plusieurs systèmes couplés. On habite dans un monde très connecté en ce moment où les personnes circulent d'un pays à autre. Le confinement de la France permet de contrôler l'épidémie, mais une fois la circulation de gens (entre pays) rétabli, de nouvelles vagues épidemiques risquent d'émerger. Donc, on essaie de comprendre l'évolution du covid-19 à l'échelle mondiale. Sans une coordination globale, plusieurs vagues épidemiques vont se succéder et les pays vont être touchés à plusieurs reprises. Ceci nous permet de comprendre l'impact de la mobilité au niveau de l'évolution de l'épidémie. Mais il faut faire attention à ce que le modele ne devienne pas trop compliqué non plus. Car dans ce cas, on risque de ne même plus comprendre le modèle.

Quelle marge d'erreur contiennent-ils ?

Quand on parle de milliers de personnes infectées, les modèles marchent super bien. Mais si on prend des mesures pour tenter d'agir sur la propagation de l'épidémie, il faut estimer à nouveau les paramètres.

Y en a t-t-il de meilleurs que d'autres ?

Oui. Plus on a d'informations sur le comportement des gens et au mieux on parvient à inclure ça dans le modèle, plus le modèle fonctionne bien. Il est important de réaliser que pour comprendre l'évolution d'une épidémie (i.e. le nombre d'infectés, etc) il est plus important de pouvoir décrire quantitativement le comportement des personnes, en particulier la fréquence de contact et la durée des contacts, que les détails biologiques de la maladie. Concernant la maladie, on doit seulement savoir si elle est du type SIR, SIRS (2), etc et après estimer plusieurs paramètres phénoménologiques.

Combien de temps sont-ils valables ?

En l'absence d'intervention et dès lors qu'on a des milliers de personnes contaminées, ils sont valables pendant toute l'évolution de l'épidémie et donnent une bonne description du phénomène. Mais si les personnes changent leur comportement, par exemple en raison d'une politique de santé publique qui impose des restrictions, etc, les paramètres doivent être recalculés.

Comment modéliser un phénomène qui décrit le comportement d'une variable (le covid-19) incomplètement connue ?

Comme les modèles épidémiologiques utilisent des paramètres phénoménologiques (taux d'infection, taux de guérison), on n'a pas besoin de connaitre grand chose du virus. Ici, on parle de comment prédire le nombre de personnes infectées, et de comment la mobilité des personnes modifie l'évolution de l'épidémie. On ne parle pas de quoi faire pour guérir les malades, ou comment arriver à produire un vaccin contre le virus. Ça, c'est la tache de microbiologistes, des médecins, etc. Si vous voulez savoir l'évolution d'une épidémie, vous avez besoin d'un modèle mathématique. Si vous voulez un vaccin, vous avez besoin de connaitre la biologie du virus : son interaction avec le système immunitaire, etc.

Pourquoi la courbe d'évolution de la pandémie publiée par le New-York Times (https://www.nytimes.com/2020/03/11/science/coronavirus-curve-mitigation-infection.html) montre qu'avec le confinement, l'épidémie est mieux contenue mais dure en revanche plus longtemps ?

Avec un simple modèle comme celui qu'on est un train d'utiliser on trouve que la durée est plus longue en utilisant des mesures de confinement, mais toujours en imaginant qu'il existe un minimum d'interactions entre les gens pour permettre au virus de continuer à se propager (comme dans l'image publiée par le NY times). Une durée plus longue est liée au fait que la fin de l'épidémie arrive quand le nombre d'individus susceptibles d'être contaminés est en dessous d'un seuil. Mais la seule manière de diminuer le nombre d'individus susceptibles d'être infectés est de contaminer ces individus par le virus ; après, guéris ou morts, ils ne participeront plus à la transmission de la maladie. Avec le confinement, la dynamique de la maladie est plus lente, et donc on doit attendre un peu plus pour arriver au seuil qui nous indique la fin de l'épidémie. Mais le plus important à comprendre avec le confinement, c'est que même si la durée de l'épidémie est plus longue, le nombre de personnes touchées par le virus diminue (et donc aussi les morts).

La figure ci-dessous a été justement élaborée pour discuter le phénomène.

Modèle SIR : modèle « simple » en épidémiologie, où les personnes peuvent se trouver dans trois états : i) sains et susceptibles d'être infectées, ii) infectés et donc capables de transmettre la maladie, et iii) guéris et immunisés ou morts.
Modèle SIRS : Similaire au modele SIR, mais où les personnes guéries et immunisées, après un certain temps deviennent susceptibles à nouveau d'être infectées. Le covid-19 semble être du type SIR, mais il a été observé dans un nombre faible de cas que des personnes guéries sont tombées malades à nouveau. Si cela se confirme, la situation est bien plus complexe que dans le modèle actuel.

[Simulation] Modèle de propagation épidémique & COVID-19

Marc Monticelli — 2020-03-23T13:13:00Z

Des résultats de simulations de mécanismes de propagation d'une épidémie ont été montrés dans les médias depuis le début de la crise COVID-19 en france.
Voici une expérience numérique interactive (ENI) inspirée du modèle présenté par le Washington-Post, ainsi que 2 autres plus bas sous la forme d'équations différentielles illustrants les modèles SIR et SEIR.
Ces simulations sont susceptibles d'évoluer au cours du temps.
Elles s'adressent plus particulièrement aux enseignants et médiateurs pour un travail pédagogique. Elles seront proposées prochainement dans un dossier sur « Image des maths » : « Modélisation d'une épidémie. Comment les maths aident à la prise de décision. ». Nous vous mettrons le lien dès qu'il sera en ligne.