Lasm permet de créer des applications web formellement vérifiées avec Lean

Présentation

Lasm est un projet open‑source qui propose d’écrire des applications web en utilisant le langage de preuve Lean, puis de les déployer sur des environnements Node.js, serverless ou edge. Le principe repose sur la capacité de Lean à produire des preuves de correction formelles, ce qui permet d’attester, avant l’exécution, que le code respecte les spécifications déclarées. Le dépôt GitHub indique explicitement que l’objectif est de « write formally verified webapps in Lean for Node/serverless/edge », ce qui place le projet à l’intersection de la vérification formelle et du développement web moderne.

Architecture et compilation

Le flux de travail de Lasm s’articule autour de trois étapes. D’abord, le développeur écrit le comportement de l’application en Lean 4, en profitant du système de types dépendants pour exprimer des invariants de sécurité ou de logique métier. Ensuite, le code Lean est transformé en une représentation intermédiaire qui peut être traduite en JavaScript compatible avec le runtime Node. Cette étape de compilation repose sur le backend de Lean qui génère du code bas‑niveau, puis sur un passeur spécifique à Lasm qui mappe les constructions Lean (par exemple les fonctions purement fonctionnelles ou les monades) vers des fonctions JavaScript ou TypeScript. Enfin, le produit final est un bundle JavaScript qui peut être exécuté directement sur un serveur Node, ou empaqueté pour des plateformes serverless comme AWS Lambda ou des environnements edge tels que Cloudflare Workers. Chaque cible impose des contraintes différentes : les fonctions serverless doivent être stateless et respecter des limites de temps d’exécution, tandis que les workers edge sont soumis à des quotas de mémoire et à un modèle d’isolation basé sur V8.

Implications pour la vérification et les déploiements serverless

En conservant les preuves de Lean jusqu’à la phase de compilation, Lasm garantit que les propriétés vérifiées ne sont pas perdues lors de la génération du code JavaScript. Concrètement, une fonction qui a été prouvée « pure » dans Lean restera pure dans le bundle final, ce qui simplifie l’analyse de la surface d’attaque et la prévisibilité du comportement à l’exécution. Sur des plateformes serverless, où le code est souvent chargé et déchargé à la volée, cette certitude réduit le besoin de tests dynamiques supplémentaires. De plus, les environnements edge, qui exécutent le code au plus près de l’utilisateur, bénéficient d’une latence réduite grâce à l’absence de logique conditionnelle non vérifiée. Les développeurs peuvent ainsi déclarer, par exemple, que chaque requête HTTP renvoie un statut 200 uniquement si une condition de validation de données est satisfaite, et la preuve associée empêche toute dérivation vers un statut d’erreur non prévu.

Limites et perspectives

Le principal frein identifié provient du gap entre le modèle de preuve de Lean et les API JavaScript courantes. Certaines bibliothèques Node, notamment celles qui manipulent des flux d’E/S ou des sockets, ne sont pas encore modélisées dans le système de types de Lean, ce qui oblige les développeurs à recourir à des wrappers non vérifiés. De plus, la taille du bundle JavaScript généré par Lasm peut dépasser les limites imposées par certaines plateformes edge, nécessitant une optimisation manuelle. Enfin, la communauté autour de Lasm reste petite, ce qui se traduit par une documentation limitée et peu d’exemples concrets. Malgré ces contraintes, le projet ouvre une voie claire vers des applications web dont le comportement est mathématiquement certifié, un axe qui pourrait gagner en importance à mesure que les exigences de sécurité et de fiabilité augmentent dans les architectures serverless.