Nous avons utilisé Elixir pour rendre visibles plusieurs idées d’informatique. Le projet d’AP9 vous propose d’en approfondir une, en construisant un programme et en expliquant ce que ses essais permettent d’affirmer. Cette page relie les sujets du catalogue aux idées des séances ; elle n’ajoute aucune consigne.
Un programme peut devenir une donnée
En AP2, nous avons représenté les expressions par des arbres, puis parcouru ces arbres pour les interpréter. En AP3, les mêmes expressions ont produit des instructions pour une machine à pile. Le typeur pose une autre question sur cet arbre : que pouvons-nous savoir avant l’exécution ?
À chaque étape, la représentation décide de ce qui est facile à exprimer. Un arbre conserve les sous-expressions ; une suite d’octets oblige à retrouver les limites des instructions et les destinations des sauts. Le projet de compilation vers CHIP-8 prolonge cette idée avec une autre machine cible, dont les registres et la pile de retours imposent leurs propres contraintes.
Un modèle s’évalue par des expériences
En AP4–AP5, nous avons préparé des données, manipulé des tenseurs, puis ajusté des paramètres. Retenez bien qu’une perte qui baisse sur les données d’apprentissage ne suffit pas à montrer que le modèle fonctionne sur de nouvelles données.
Une expérience utile conserve le partage des données, les paramètres de l’entraînement, les mesures et quelques erreurs. Si vous modifiez la taille du modèle et le taux d’apprentissage en même temps, pourrez-vous expliquer ce qui a amélioré le résultat ? Les projets IA reprennent cette discipline : un seul changement à la fois, une hypothèse annoncée avant l’essai, et une conclusion proportionnée à la taille des données mesurées.
L’état d’un processus et l’état répliqué posent deux problèmes
En AP6–AP7, un processus conserve un état et répond à des messages. Un GenServer traite ses messages un à un ; cela ne rend pas automatiquement atomique une suite de plusieurs appels. Lire un compteur puis écrire son successeur dans un autre appel peut perdre une contribution. Demander une seule opération « incrémenter » donne au serveur la responsabilité de cette transition. Les réservations concurrentes reprennent exactement ce souci ; la ferme de rendu fait, elle, coopérer plusieurs processus qui calculent vraiment.
En AP8, plusieurs processus ont chacun une copie. Il faut alors définir ce qu’une fusion conserve et ce qui permet de converger après les échanges. Pour notre G-Counter, le maximum par auteur absorbe les doublons et les anciens snapshots. La convergence suppose que les mises à jour finissent par circuler. La supervision relance un processus ; elle ne restaure pas sa mémoire perdue. Les deux éditeurs concurrents posent la même question sur un texte, où l’ordre des caractères rend la fusion plus délicate qu’une somme.
Une trace permet d’expliquer une garantie
Pour chaque projet, choisissez un exemple assez petit pour le calculer à la main. Prévoyez son résultat, exécutez votre code, puis modifiez un détail qui met votre raisonnement à l’épreuve. Un test qui passe sur un seul exemple n’établit pas une garantie générale, mais un contre-exemple précis peut invalider très vite une hypothèse.
Conservez aussi ce qui reste hors du périmètre : un langage sans fonctions récursives, un modèle entraîné sur un petit corpus, un éditeur sans stockage sur disque. Ces limites aident à comprendre ce que vous avez effectivement construit. Votre projet continue à la maison après AP9 ; la fin de séance sert à expliquer votre avancement et votre prochaine étape.
Pour toute question, vous pouvez me contacter par email : aurelien.noce@minesparis.psl.eu.