QED et la vérification formelle : et si on prouvait que le code fonctionnait vraiment ?

Tu as déjà eu la certitude absolue que ton code frontend ne planterait jamais en production ? Genre, une certitude mathématique, pas juste "j'ai testé deux fois et ça a l'air de marcher". Pour 99% des devs, la réponse c'est non. On code, on teste, on prie, on déploie les doigts croisés.

Et si je te disais qu'il existe un projet qui pourrait changer ça ?

Lean 4, c'est quoi ce truc ?

Avant de parler de qed, il faut qu'on pose les bases. Lean 4, c'est un langage de programmation développé chez Microsoft Research (aujourd'hui open source) qui combine plusieurs choses sacrément puissantes :

• Les types dépendants — tes types peuvent contenir des valeurs, pas juste des catégories
• La vérification formelle — tu peux prouver mathématiquement que ton code est correct
• La métaprogrammation native — le langage peut générer du code lui-même
• Des perfs dignes du C — ouais, ça compile en natif

Le système de types de Lean, c'est là que ça devient intéressant. Quand tu peux transformer des propriétés en types et ensuite prouver qu'elles sont vraies, tu ne corriges plus des bugs — tu les empêches d'exister.

QED : le concept

qed (pour "quod erat demonstrandum", le classique latin qu'on met à la fin d'une démonstration) utilise exactement ces super-pouvoirs pour construire des interfaces web. Concrètement, ça veut dire quoi ?

Les frameworks habituels — React, Vue, Svelte — fonctionnent sur un modèle simple : tu codes, tu espères que ça marche. Tu ajoutes des tests, tu check les erreurs, tu pousses en prod.

Le problème ? Les tests ne prouvent rien. Les erreurs runtime passent quand même. Les cas limites explosent plus vite que ta couverture de tests.

Avec une approche formellement vérifiée, tu ne writes pas juste du code — tu écris des théorèmes sur ce code, et tu les prouver. Le compilateur devient assistant de preuve.

Pourquoi ça devrait t'intéresser ?

La vérification formelle, c'est traditionnellement réservé aux domaines critiques : aviation, nucléaire, cryptographie. Le développeur web lambda ? Jamais touché.

Mais qed représente un pont intéressant :

1. La sécurité intégrée dès le départ — plutôt que d'ajouter des vérifications après coup, tu prouver que les propriétés de sécurité tiennent.

2. Refactorer sans stress — si ta logique core est vérifiée, les gros refactos deviennent moins terrifiantes. La preuve te dit si t'as cassé quelque chose.

3. La doc qui s'exécute — les propriétés vérifiées servent de spécifications. Ton code ET tes preuves, c'est ta documentation.

4. Ready for production — Lean 4 a muri, et des projets comme qed montrent qu'on peut expérimenter pour de vrai.

Le vrai changement : la philosophie de la confiance

Ce qui me frappe avec qed, c'est le shift philosophique.

La plupart du développement logiciel repose sur "trust but verify" : on fait confiance à notre code, puis on vérifie. La vérification formelle inverse tout — on part de fondations prouvées et on construit dessus. La confiance est mathématique, pas basée sur l'espoir.

Pour des applications où la correctness compte vraiment — dashboards financiers, portails santé, systèmes d'auth — cette approche peut être transformative.

Ce qu'il faut garder en tête

Soyons honnêtes : le dev web formellement vérifié ne va pas remplacer React demain. La courbe d'apprentissage est raide, l'écosystème est embryonnaire.

Mais qed prouve que le concept tient la route.

On voit déjà ces idées percoler dans le mainstream — le système de types de TypeScript qui devient de plus en plus sophistiqué, le borrow checker de Rust, et maintenant des projets comme qed qui montrent ce qui est possible.

La vraie question n'est pas si les méthodes formelles vont influencer le dev quotidien, mais à quelle vitesse.

En attendant, qed mérite le détour si tu veux explorer ce qui se fait de plus avance en matière de code vérifié. Ça neiera peut-être pas ton prochain MVP, mais ça pourrait changer ta façon de penser la correction du code.

Après tout, ce serait pas nice de pouvoir prouver que ton code fonctionne, plutôt que de juste espérer ?

Tu en penses quoi de la vérification formelle dans le web ? C'est l'avenir, ou de la surcouche pour la plupart des cas d'usage ? Raconte-moi.