À dire : Bonjour à toutes et à tous, et bienvenue dans ce cours d'AP. Pendant neuf séances, nous allons apprendre un langage, Elixir, et surtout nous en servir pour construire : une calculatrice dès aujourd'hui, puis un petit langage, des modèles qui apprennent et des programmes qui coopèrent. Je vais d'abord vous raconter, pendant une petite demi-heure, d'où vient ce langage et ce que l'on construit avec. Nous passerons ensuite dans Livebook pour le reste de la séance : c'est là que se fait le cours. Commençons par la carte de nos neuf séances. Repères : keynote de 35 min indicatives (30 à 40), vérification de Livebook et premiers essais compris ; ensuite environ 130 min dans les cinq carnets, 10 min de pause et 5 min de bilan, le créneau officiel laissant la marge. Pas de quiz aujourd'hui. Ces notes donnent un fil oral, pas une deuxième leçon de syntaxe : la syntaxe se travaille dans les carnets projetés au tableau.
À dire : Le cours suit quatre temps, qui sont aussi les quatre parties du poly. Aujourd'hui, nous apprenons à écrire en Elixir : valeurs, fonctions, motifs, récursion, et une calculatrice pour finir. En AP2 et AP3, nous nous demanderons comment un programme devient un résultat, en écrivant un interpréteur puis un compilateur vers une petite machine. En AP4 et AP5, la question devient : comment un programme apprend-il à partir de données ? Vos six séances de NumPy et pandas vous y donneront déjà des repères. D'AP6 à AP8, nous ferons coopérer des processus, jusqu'à un compteur partagé entre plusieurs copies. AP9, enfin, lance un projet que vous choisirez dans l'un de ces thèmes. Voyons maintenant comment nous allons travailler. Repères : 2 min. Les quatre parties du poly couvrent les chapitres 1 à 4, 5 et 6, 7, puis 8 et 9 ; chaque quiz renvoie à l'un d'eux. Ne pas détailler les sujets d'AP9, présentés en janvier, ni promettre Phoenix en AP8. On ne refait pas l'introduction aux tableaux en AP4.
À dire : Concrètement, je parle peu et vous écrivez beaucoup. Je projette le même carnet que vous : nous prédisons un résultat avant de l'exécuter, puis nous reprenons ensemble ce qui a surpris. Ce que vous gardez, c'est votre code, mais aussi vos traces et vos explications : une trace juste et une erreur expliquée comptent autant que le code terminé. Le travail d'AP1 à AP3 forme un seul rendu, le 6 décembre, et rien n'est à faire entre aujourd'hui et jeudi. À partir d'AP3, chaque séance s'ouvrira par un quiz de dix minutes, préparé par la lecture d'un chapitre du poly. Reste une question : pourquoi un langage que la plupart d'entre vous n'ont jamais vu ? Pour y répondre, remontons à 1986, chez Ericsson. Repères : 2 min. Pas de quiz en AP2, deux jours après AP1 ; AP3 s'ouvre par un quiz sur AP2, chapitre 5 du poly, dix minutes puis correction ensemble. Les reprises orales contribuent à la participation. Le point d'arrêt se donne en séance : ce n'est pas une course aux bonus. Le poly sert à retrouver le pourquoi d'une forme.
À dire : Voici Joe Armstrong, photographié en 2009. Au milieu des années 1980, il travaille chez Ericsson avec Robert Virding et Mike Williams sur un problème très concret : un central téléphonique gère beaucoup de conversations en même temps, sur des machines qui peuvent tomber en panne. Imaginez que vous êtes en ligne : que doit devenir votre appel si la conversation voisine provoque une erreur, ou si une carte lâche ? Le reste doit continuer. C'est de cette exigence qu'est né Erlang, rendu open source en 1998. Voyons les principes que l'équipe en a tirés. Repères : 1 à 2 min ; la partie histoire, de cette page aux SLA, tient en 8 min environ. Le portrait date de 2009, pas des années 1980 : le style peut prêter à sourire, la contrainte reste très actuelle. Erlang est un travail collectif. Ne pas confondre la naissance du langage (1986), ses premiers essais (1987 selon le cours historique) et sa diffusion publique (décembre 1998) ; cf. prof/AP1-SOURCES.md.
À dire : De ce contexte viennent quatre principes. Chaque activité est confiée à un processus léger et isolé : s'il échoue, l'erreur reste chez lui. Les processus ne partagent pas de mémoire, ils s'envoient des messages. Plutôt que de prévoir toutes les erreurs, on laisse tomber le processus fautif et un superviseur le relance : c'est le fameux « let it crash ». Enfin, on remplace le code d'un système en marche, sans couper les appels. Notez une curiosité : le premier prototype était écrit en Prolog, et nous lui devons les atomes, les tuples et le filtrage par motifs que vous écrirez tout à l'heure. Le schéma suivant montre ces processus en action. Repères : 1 à 2 min. Le nom honore A. K. Erlang, mathématicien danois du trafic téléphonique, et se lit aussi « Ericsson language ». L'implémentation actuelle est la BEAM, une machine virtuelle écrite en C dans les années 1990. En 1998, Ericsson cesse d'employer Erlang pour ses nouveaux produits ; le langage est rendu open source en décembre. Ne pas détailler la supervision ici.
À dire : Lisons ce dessin. Les processus A et B ont chacun leur propre état et s'échangent des messages ; le processus C, lui, est tombé en panne. Son superviseur l'a remarqué et en a relancé un neuf, pendant que A et B continuaient leur travail. Attention : la relance ne restitue pas l'état perdu, c'est une politique à concevoir, pas de la magie. Nous créerons nous-mêmes ces processus en AP6, puis nous les ferons superviser en AP7. Ces idées ont-elles tenu leurs promesses à grande échelle ? Repères : 1 min. Dessin conceptuel, pas un schéma du réseau de WhatsApp ou d'Ericsson. Un processus BEAM n'est pas un processus du système d'exploitation : il est bien plus léger, et la machine virtuelle en fait tourner des milliers. Les animations laissent tous les labels visibles et se désactivent avec la préférence de réduction des mouvements.
À dire : L'exemple le plus célèbre est un commutateur d'Ericsson, l'AXD301. En 2004, son logiciel central comptait environ 2,1 millions de lignes d'Erlang : ce n'est pas un prototype de laboratoire. Joe Armstrong rapporte, pour un système client, une disponibilité de 99,9999999 %, les « neuf neuf ». Sur une année, ce taux laisserait environ 31 millisecondes d'interruption ! C'est une conversion du taux, pas la durée d'une panne observée. Retenez surtout que la redondance, la supervision et les mises à jour en service travaillent ensemble. Mais que représentent ces pourcentages, concrètement ? Repères : 1 min. Cronqvist compte environ 2,1 millions de lignes pour le logiciel des processeurs centraux en 2004, et plus de 1 000 AXD301 déployés. Armstrong rapporte neuf neuf pour un système client de onze nœuds, d'après une présentation dont la méthode et la fenêtre de mesure ne sont pas documentées (British Telecom selon le résumé FFG 2003). Le matériel, le logiciel et l'exploitation concourent au résultat.
À dire : Faisons le calcul ensemble. Selon vous, que laisse 99,9 % de disponibilité sur une année : quelques secondes, quelques minutes ou plusieurs heures ? Une année compte 31 536 000 secondes ; un millième de ce temps fait 31 536 secondes, soit 8 h 45 min 36 s. Ensuite, chaque neuf ajouté divise ce temps par dix : avec cinq neuf, il reste environ cinq minutes par an. Ces ordres de grandeur, vous les retrouverez dans les contrats des services en ligne. Repères : 1 à 2 min. Faire estimer avant de montrer le calcul. Pour neuf neuf, la fraction indisponible vaut 10^-9, soit 0,031536 s/an. De 99,5 % à 99,9 %, le facteur est cinq, pas dix. On additionne les interruptions, on ne prédit pas une panne unique ; le mois de 30 jours et l'année de 365 jours sont deux conventions distinctes.
À dire : Un SLA, c'est un engagement de niveau de service : le fournisseur promet une disponibilité, sur un périmètre et une période définis. Chez Amazon, une machine virtuelle seule est garantie à 99,5 % par mois ; répartie sur plusieurs zones, l'offre monte à 99,99 %. Pourquoi cet écart ? Parce qu'une machine peut tomber pendant que le service continue sur les autres : c'est l'idée d'Erlang, isoler une panne et relancer ce qui doit l'être. Erlang a donc fait ses preuves ; pourtant, ce n'est pas lui que nous allons écrire. Pourquoi Elixir ? Repères : 1 min. Ces engagements ne sont pas une norme universelle. Une zone de disponibilité est un ensemble d'infrastructures isolé des autres zones ; le SLA EC2 multizone a un périmètre régional précis et porte sur la connectivité. S3 mesure des taux d'erreur de requêtes par intervalles ; ses onze neuf de durabilité concernent la conservation des données, un autre sujet. La table précédente convertit un taux temporel idéal ; chaque contrat fixe sa mesure et ses conditions.
À dire : En 2011, José Valim, qui vient de l'écosystème Ruby, commence un nouveau langage. Son idée : garder la machine virtuelle d'Erlang, la BEAM, avec ses processus et sa robustesse, et lui offrir une autre syntaxe et des outils modernes. La version 1.0 paraît en septembre 2014. Ce que nous écrirons aujourd'hui, l'immuabilité et les motifs, vient donc tout droit d'Erlang. Qu'est-ce qu'Elixir ajoute, alors ? Repères : 1 min ; la partie Elixir tient en 3 min avec les deux pages suivantes. Elixir n'est pas un interpréteur Ruby sur Erlang. Le développement commence en 2011 ; l'annonce publique de la version 0.5 date de mai 2012. Un programme Elixir appelle directement les fonctions Erlang.
À dire : Trois choses, surtout. Le langage est extensible : des formes qui semblent primitives, comme defmodule, if ou le pipe, sont des macros écrites en Elixir, et c'est pour cela que tout y est une expression qui vaut quelque chose. Il apporte un outillage unifié : Mix crée et compile un projet, Hex partage les bibliothèques, ExUnit écrit les tests ; nous nous en servirons à partir d'AP6. Ses chaînes sont en UTF-8, et nous les découperons par motifs dans le carnet 4. Les processus et la supervision, eux, restent ceux d'Erlang/OTP. Autour du langage s'est construit tout un écosystème. Repères : 1 min. Nous n'écrirons pas de macros : il suffit de dire que if se réécrit en case et le pipe en un appel, ce qui explique « tout est expression ». Sources : annonce de Valim en 2012, documentation de Kernel.if/2.
À dire : Voici les briques que vous croiserez. Erlang/OTP et la BEAM exécutent les processus, les messages et la supervision ; Elixir est le langage que nous écrivons. Phoenix et LiveView servent aux applications web interactives, Nx, Axon et Livebook au calcul numérique et aux expériences. Livebook ressemble aux notebooks Jupyter de vos séances de PE : c'est lui que nous ouvrirons tout à l'heure. Nous introduirons chaque outil au moment où un exercice en aura besoin. Voyons maintenant ce que des équipes construisent avec ces briques. Repères : 1 min. Aucun catalogue d'API. Livebook rappelle Jupyter, mais Elixir et ses bibliothèques forment un autre environnement. Phoenix reste un exemple d'écosystème, pas une promesse de programme détaillé pour AP8.
À dire : Vous utilisez peut-être certains de ces services. Pensez à une action de tous les jours, rejoindre un salon ou recevoir une notification : quels échanges déclenche-t-elle ? Chez Discord, des processus Elixir diffusent les messages et les présences de chaque communauté. Chez Pinterest, un système appelé Guardian détecte le spam grâce à un langage de règles proche de SQL : c'est un petit langage métier, et nous en construirons un, à notre échelle, en AP2 et AP3. WhatsApp, enfin, fait circuler ses messages avec Erlang, sur la même plateforme. Ce sont de très grands systèmes ; regardons aussi une entreprise qui a construit tout son produit en Elixir. Repères : 2 min ; les exemples de produits tiennent en 5 min jusqu'au langage de niche. Les dates sont celles des retours d'expérience (WhatsApp 2014, Discord 2017, Pinterest 2021), pas un état actuel des systèmes. WhatsApp illustre Erlang, Discord Elixir : deux langages, une plateforme. Guardian n'est pas le langage jouet d'AP2.
À dire : Remote aide des entreprises à embaucher, gérer et payer des équipes partout dans le monde : contrats, paie, facturation. Elixir est sa technologie principale depuis sa création, en 2019, et en janvier 2025 environ 180 ingénieurs travaillaient dans une même base de code. Ce qui m'intéresse ici, c'est que l'équipe recrute des ingénieurs qui n'ont jamais écrit d'Elixir et les forme en quelques semaines : apprendre un nouveau langage fait partie du métier. Un dernier exemple relie le cours à l'apprentissage automatique. Repères : 1 min. Le serveur principal est un monolithe Elixir, l'interface est en React. Les quelque 180 ingénieurs de la même base ne sont pas les quelque 300 personnes de toute l'organisation engineering. La formation interne dure deux à quatre semaines. Les nombres décrivent janvier 2025.
À dire : Amplified aide à retrouver les brevets proches d'une invention que vous décrivez : le produit classe les documents selon les idées qu'ils expriment, pas seulement selon leurs mots-clés. Son équipe utilise Nx, Axon, Bumblebee et Livebook en production. Nous retrouverons Nx, Axon et Livebook en AP4 et AP5 : représenter des données par des nombres, apprendre un modèle, évaluer ses réponses. Revenons alors à la question du début : pourquoi apprendre un langage de niche ? Repères : 1 min. La keynote de Christopher Grainger à ElixirConf EU 2024 atteste l'usage de cette pile en production ; la date est confirmée par son billet du 9 mai 2024. Notre grille de points (AP4) et Fashion-MNIST en prolongement (AP5) sont des terrains d'apprentissage : ils ne reproduisent pas leur moteur de recherche. Bumblebee fournit des modèles préentraînés construits avec Axon, hors du socle des TP. Reprendre ce cas au bilan d'AP5.
À dire : Elixir reste un langage de niche, comme OCaml, que certains d'entre vous ont pratiqué en prépa ; qui en a fait ? Ces langages ont deux intérêts. Ils font travailler des idées qui se réutilisent partout : l'immuabilité, les motifs, la récursion, et avec Elixir la concurrence. Ils servent aussi à de vrais produits : OCaml chez Jane Street, Elixir chez Discord, Pinterest ou Remote. Ce que je cherche, c'est à élargir vos façons de concevoir un programme, puis à les mettre en pratique. Justement, regardons la petite machine que nous allons construire aujourd'hui. Repères : 1 min. OCaml n'est pas un prérequis, et les choix de typage et d'exécution diffèrent entre les deux langages. Jane Street décrit OCaml comme sa plateforme principale, notamment pour ses systèmes de trading. L'offre Apple de septembre 2026 (profil senior) et le cours de KTH attestent un usage et un enseignement documentés, sans prouver une adoption générale.
À dire : Voici ce que votre programme saura calculer à la fin de la séance. L'écriture paraît curieuse : chaque opération vient après ses deux nombres. Que vaut cette ligne, selon vous ? … Elle vaut 10 : huit moins trois font cinq, puis cinq fois deux. Pour y arriver, nous écrirons d'abord les fonctions qui lisent le texte, puis celles qui font évoluer une pile. Au prochain cours, nous voudrons lire l'écriture habituelle, (8 - 3) * 2, avec ses priorités et ses parenthèses. Mais d'où vient cette notation sans parenthèses ? Repères : 1 min ; de cette page à « Cinq carnets », compter 4 min. Recueillir deux ou trois prédictions avant de donner 10. Ne pas expliquer l'algorithme : il devient l'objectif des carnets 4 et 5. Les priorités et les parenthèses font le lien avec AP2, dont le parser reste guidé.
À dire : Elle a presque un siècle. En 1924, le logicien Jan Łukasiewicz écrit l'opérateur avant ses opérandes : sans parenthèses, l'ordre des symboles suffit à fixer le groupement. En 1957, Charles Hamblin la retourne, l'opérateur après ses opérandes, et montre qu'une machine peut alors calculer en lisant de gauche à droite avec une simple pile. L'idée a fait du chemin : les calculatrices HP dès 1972, Forth, PostScript, puis la machine virtuelle Java. En AP3, cette pile deviendra notre propre machine. Regardons-la fonctionner sur le début de notre exemple. Repères : 1 min. Chaque opérateur prend ses opérandes au sommet de la pile : c'est exactement l'algorithme du carnet 5. Les machines à pile (B5000, P-code, JVM) seront le fil d'AP3 ; ne pas les détailler maintenant.
À dire : Nous lisons 8 et nous l'empilons. Nous lisons 3 : il passe au sommet, que j'écris à gauche. Nous lisons le signe moins : nous retirons 3, puis 8, et nous empilons leur différence, 5. Attention à l'ordre : on retire d'abord 3, mais on calcule bien 8 moins 3. À chaque étape, le prochain symbole et la pile suffisent à décider quoi faire : c'est tout l'état de notre calcul. Pour écrire cela en Elixir, nous avancerons en cinq étapes. Repères : 1 min. Le sommet est à gauche. Faire verbaliser l'ordre des opérandes ; le carnet 5 reprend cette question au moment d'écrire la soustraction, qu'une addition ne permettrait pas de vérifier.
À dire : La séance se découpe en cinq carnets Livebook, un par étape, chacun ouvert par une question. Le premier nous apprend ce que renvoie une cellule et ce que garde un nom ; le deuxième, comment une fonction choisit son cas grâce aux motifs ; le troisième, comment parcourir une liste en sachant où nous en sommes. Après la pause, le quatrième lit un texte sans accepter n'importe quoi, et le cinquième assemble la pile et la calculatrice. Aucun carnet n'a besoin des cellules d'un autre : si vous avez pris du retard, vous ouvrez quand même le suivant avec nous. Avant cela, vérifions que Livebook fonctionne chez tout le monde. Repères : 1 min. Durées indicatives : 20, 25 et 25 min, la pause de 10 min, puis 25 et 35 min, et 5 min de bilan. Revenir à cette page à chaque passage de carnet pour annoncer la question suivante. Le carnet 5 fournit au besoin le Token.read/1 du carnet 4. Les transitions de pile sont le socle ; la boucle complète peut être construite ensemble. Le carnet 6 est facultatif et les six petits carnets de réserve servent à reprendre une notion : ce n'est pas une seconde liste à finir.
À dire : Vous avez installé Livebook avant la séance ; lancez-le maintenant. Sur la page AP1 du site, chaque carnet a un bouton « Run in Livebook » : ouvrez seulement le premier, ap1-01-expressions, et enregistrez-le tout de suite dans votre dossier AP1. Si le bouton ne trouve pas l'application, téléchargez le fichier .livemd et ouvrez-le depuis l'accueil de Livebook. Si une étape échoue, notez le message exact et levez la main ; en attendant, suivez avec votre voisin. Ajoutez enfin une cellule de code tout en haut du carnet : nous allons y faire nos premiers essais ensemble. Repères : 4 min indicatives de vérification ; l'installation était demandée avant le cours via /avant-ap1/. Livebook Desktop fournit son propre Elixir : inutile d'installer Mix pour AP1. Montrer l'import depuis le site et l'ouverture d'un fichier local. Les carnets 2 à 5 s'ouvriront au début de chaque étape, pas maintenant. Une installation bloquée se traite pendant une phase autonome, en binôme ; les boutons Essayer du diaporama permettent déjà les premiers essais.
À dire : Recopiez ces deux lignes dans votre cellule, mais avant d'évaluer, dites-moi ce qui va s'afficher. … Une cellule renvoie la valeur de sa dernière expression : ici, une chaîne où chaque #{…} a été remplacé par la valeur de l'expression qu'il contient. Remplacez le prénom et réévaluez. Ajoutez ensuite, juste dessous, une cellule de texte qui dit ce que vous avez changé : c'est le geste que nous répéterons toute la séance. Passons à une ligne plus surprenante. Repères : 2 min. Résultat : "Bonjour Ada, 2 + 3 vaut 5". Montrer Evaluate (Ctrl ou Cmd + Entrée), puis l'ajout d'une cellule de texte. Les boutons du diaporama permettent un essai immédiat, mais le travail à garder est dans Livebook. Dire seulement que #{…} insère la valeur d'une expression dans le texte : les carnets n'en dépendent pas.
À dire : Voici une ligne qui ne ressemble à rien de ce que vous avez écrit en Python. Que vaut la cellule ? … Elle vaut 43 : la valeur 42 a été extraite et reliée au nom value. Remplacez maintenant seulement :ok, à droite, par :error, et réévaluez. Vous obtenez une erreur, MatchError : les deux côtés n'ont plus la même forme. Pour comprendre ce qui s'est passé, il nous faut trois mots de vocabulaire. Repères : 2 min. L'erreur est provoquée volontairement pour susciter la question, pas comme un piège à retenir ; remettre :ok ensuite pour garder un carnet relançable. Ne pas affirmer que = est une comparaison : il lie aussi value. Les carnets 1 et 2 reprennent les tuples, puis les motifs, avant de les faire écrire.
À dire : Premier mot : :ok est un atome, une constante qui n'est rien d'autre que son nom, un peu comme une étiquette. Deuxième mot : les accolades construisent un tuple, quelques valeurs regroupées dans un ordre fixe ; les crochets, eux, feraient une liste. Troisième mot : le signe égal ne range pas une valeur dans une case, il fait correspondre deux formes, et relie value à 42 quand elles coïncident. Avec :error à droite, l'étiquette ne correspondait plus, d'où MatchError. Retenez enfin qu'une valeur ne change jamais ; un nom, lui, peut être relié plus loin à une autre valeur. Vous avez tout ce qu'il faut pour vous lancer dans le carnet 1. Repères : 1 à 2 min. Ces trois mots viennent de Prolog, par Erlang. Le = de Prolog est l'unification ; celui d'Elixir est plus simple, car la droite est déjà une valeur. Les carnets 1 et 2 reprennent ces notions en les faisant écrire : ne pas aller plus loin ici.
À dire : Vous êtes maintenant dans le carnet 1 ; il vous reste à le parcourir de haut en bas. À chaque cellule, écrivez d'abord ce que vous attendez, puis évaluez : c'est l'écart entre les deux qui nous intéresse. Vous verrez qu'un nom réassocié ne modifie pas la valeur précédente, puis vous fabriquerez votre premier résultat étiqueté. Quand vous rouvrez un carnet, réévaluez-le depuis le haut, et sauvegardez souvent. Je projette le même carnet, et nous reprendrons ensemble les surprises dans une vingtaine de minutes. À vous ! Repères : 1 à 2 min avec la mise en route, puis 20 min de carnet. Valeurs du carnet : le tuple de départ vaut {14, 3.5, 3, 1}, le prix réassocié donne {5, 7, 15}, puis E1 attend 21 et {:ok, 21}. Chaque carnet se sauvegarde dans AP1/, un fichier par étape ; on recopie sa brique du carnet précédent quand elle est nécessaire. Les fiches s'ouvrent quand une forme manque, elles ne sont pas à lire avant. Si la keynote a duré 40 min, raccourcir les premiers calculs du carnet 1, pas le carnet 5.
À dire : Toutes les sources de cette introduction sont réunies ici ; vous pourrez y revenir après la séance. Repères : référence finale à consulter, pas une page à lire collectivement. Vérifier les faits datés avant une nouvelle édition (prof/AP1-SOURCES.md).