L’automatisation des preuves Lean vient de passer un véritable test logiciel, mais la preuve n’est pas prête pour la production

L’automatisation des preuves Lean a franchi un cap important le 26 juillet, tout en restant très loin d’une sortie logicielle en production. L’ingénieur sécurité Adam Langley a créé un décompresseur Zstandard fonctionnel en Lean, puis a utilisé plusieurs grands modèles de langage pour générer des preuves vérifiées par machine autour de sa logique la plus difficile.

L’expérience n’a produit ni décompresseur plus rapide, ni bibliothèque publiée, ni preuve que l’IA peut vérifier n’importe quelle grande application. Langley indique que sa version s’exécute environ dix fois plus lentement que la commande standard zstd. Il décrit également l’implémentation comme un projet d’apprentissage et a refusé d’en publier le code.

Le changement est plus limité, mais plus conséquent. Un système d’IA a produit des preuves pour un logiciel non trivial, tandis que Lean vérifiait indépendamment leur validité. Cela fait passer la vérification assistée par IA au-delà des explications fluides et du code plausible, vers un flux de travail doté d’un critère d’acceptation inhabituellement strict.

La confrontation principale n’oppose plus le code généré par l’IA au code écrit par des humains. Elle oppose une génération probabiliste à une vérification déterministe. Le modèle peut deviner, réviser et échouer à répétition, tandis qu’un petit vérificateur de confiance décide de ce qui entre dans le programme final.

Pour les développeurs, ce modèle offre une réponse possible au manque de fiabilité des agents de programmation. Pour les travailleurs du savoir, il suggère un modèle plus large d’automatisation : laisser l’IA produire une première tentative imparfaite, mais faire dépendre l’acceptation de conditions explicites et vérifiables par machine.

L’expérience Zstandard a concrétisé l’automatisation des preuves

Le test de Langley compte parce qu’il a appliqué des preuves générées par IA à un logiciel système ordinaire, et non à un nouveau benchmark mathématique isolé.

Lean est à la fois un langage de programmation et un assistant de preuve interactif. Ses types dépendants permettent aux types d’un programme d’inclure des faits sur les valeurs, comme la longueur exacte d’un tableau ou une relation entre plusieurs sorties.

Cette capacité modifie ce qu’une signature de fonction peut garantir. Une fonction normale de lecture de fichier peut renvoyer un tableau d’octets. Une fonction Lean peut renvoyer un tableau accompagné d’une preuve que sa longueur correspond au nombre d’octets demandé.

La référence officielle de Lean explique pourquoi cette architecture présente une valeur inhabituelle pour le travail généré par IA. Les tactiques Lean peuvent être complexes et automatisées, mais chaque terme de preuve qu’elles produisent passe par un noyau comparativement petit.

Une tactique défaillante peut faire perdre du temps ou générer un candidat invalide. Elle ne peut pas rendre valide une preuve invalide, à moins que la fondation de confiance ne contienne elle aussi un défaut. Le vérificateur, plutôt que le générateur, demeure l’autorité finale.

Langley a choisi Zstandard parce qu’il représentait un défi d’implémentation significatif. Zstandard, généralement appelé zstd, est un format de compression sans perte fondé sur l’appariement de type LZ77 et deux systèmes de codage entropique.

Sa spécification de format attribue le codage de Huffman aux données littérales, et l’entropie à états finis, ou FSE, aux autres symboles et aux en-têtes Huffman. FSE utilise un état transmis entre les symboles, ce qui impose de décoder ses flux de bits dans l’ordre inverse de leur écriture.

Ce mécanisme est bien plus exigeant que de prouver l’égalité de deux courtes expressions arithmétiques. Un décompresseur doit analyser des structures binaires compactes, maintenir un état, rejeter les entrées invalides et reconstruire correctement les octets d’origine.

L’expérience Lean de Langley s’est particulièrement concentrée sur la construction des tables FSE. La table détermine comment les états compressés sont remappés vers des symboles et combien de bits le décodeur consomme.

Plusieurs LLM auraient généré une preuve d’une propriété importante de ce code de construction de table en environ 20 minutes. Langley a vérifié que les preuves résultantes passaient le vérificateur de types de Lean et ne contenaient aucune déclaration sorry, le mécanisme de Lean permettant d’admettre temporairement une affirmation non prouvée.

Les modèles ont dû modifier certains choix d’implémentation. Langley avait utilisé Id.run pour exprimer certaines parties de l’algorithme dans un style plus impératif, ce qui rendait les mécanismes de preuve plus difficiles à employer.

Ce détail empêche une lecture simpliste du résultat. L’IA ne s’est pas contentée d’inspecter un code figé et d’y attacher un certificat. Elle a contribué à remodeler l’implémentation afin de la rendre propice à la construction de preuves.

Le résultat a néanmoins créé une boucle complète : écrire un logiciel significatif, énoncer un invariant fort, générer une preuve, puis demander à un noyau indépendant de l’accepter ou de la rejeter. C’est cette boucle qui constitue le véritable événement.

L’automatisation des preuves Lean s’attaque au problème du coût de la vérification

La vérification formelle a déjà offert des garanties exceptionnelles, mais le travail de preuve l’a maintenue hors de la plupart des projets logiciels courants.

L’exemple historique le plus clair est seL4, un petit noyau de système d’exploitation étayé par des preuves vérifiées par machine. Ses propriétés vérifiées couvrent bien davantage que la réussite de tests sur un ensemble d’entrées sélectionnées.

La vérification initiale a nécessité environ 20 années-personnes sur quatre ans et a produit plus de 200 000 lignes de script de preuve Isabelle. Une rétrospective décrite dans les recherches sur seL4 montre pourquoi ces chiffres ne peuvent être écartés comme un simple excès académique.

Les équipes de vérification doivent définir les bonnes propriétés, relier différentes couches d’abstraction, construire des preuves et maintenir leur alignement avec l’évolution du code. Chaque tâche exige des connaissances spécialisées et une ingénierie rigoureuse.

Le bénéfice peut être considérable. Le projet seL4 ne signale aucun défaut de correction fonctionnelle dans le code vérifié depuis l’achèvement de sa preuve principale en 2009. Toutefois, la plupart des équipes logicielles ne peuvent pas investir des années de travail spécialisé avant de livrer un seul composant.

L’automatisation traditionnelle des preuves réduit une partie de cette charge. Les tactiques peuvent résoudre des schémas familiers, tandis que les solveurs de satisfiabilité modulo théories, appelés solveurs SMT, déchargent les conditions logiques dans les domaines pris en charge.

Ces systèmes influencent également la manière dont les programmeurs écrivent du code vérifié. Les utilisateurs expérimentés apprennent quelles formulations un solveur peut traiter et quelles structures apparemment inoffensives font exploser la recherche de manière incontrôlable.

Langley soutient que les LLM modifient cette équation économique parce qu’ils sont des générateurs de preuves flexibles. Ils peuvent lire les définitions environnantes, examiner les messages d’erreur, réécrire du code local, proposer des lemmes intermédiaires et tenter une autre voie après un rejet.

L’irrélevance des preuves renforce cet argument. Dans Lean, les propositions vivent dans un univers où les preuves sont irrélevantes, ce qui signifie que le système se préoccupe généralement de l’existence d’une preuve valide, et non de celle qui a été fournie.

Un ingénieur en preuves humain valorise souvent l’élégance, car une preuve claire peut mieux survivre aux modifications ultérieures. Si un LLM peut régénérer rapidement une preuve vérifiée, une partie de ce calcul de maintenance change.

Cela n’élimine pas l’ingénierie des preuves. Il faut toujours énoncer le bon théorème, définir la frontière de confiance et décider si la régénération après chaque modification reste abordable.

Cela affaiblit néanmoins une objection majeure. Un code généré laid est dangereux lorsque les développeurs ne peuvent pas évaluer son comportement avec confiance. Une preuve générée laide est moins préoccupante lorsqu’un noyau de confiance rejette chaque version invalide.

Le flux de travail émergent ressemble davantage à la compilation qu’au raisonnement collaboratif. Les développeurs spécifient la propriété, un agent cherche un artefact acceptable, et le vérificateur détermine si la compilation réussit.

Cette différence compte pour les responsables qui décident de la place de l’IA. Un assistant de programmation qui affirme qu’une fonction est sûre fournit une opinion. Un assistant producteur de preuves qui renvoie un artefact vérifié par le noyau fournit des éléments probants dans le cadre d’hypothèses déclarées.

Cette distinction révèle également le nouveau goulot d’étranglement. Si la génération de preuves devient bon marché, rédiger la bonne spécification devient la compétence rare.

Les équipes auront besoin de personnes capables de traduire les exigences en invariants précis. « Ce parseur devrait être sécurisé » n’est pas vérifiable. « Chaque analyse réussie reste dans le tampon d’entrée fourni » se rapproche d’une propriété qu’un système formel peut évaluer.

Pour les travailleurs du savoir, la tâche équivalente consiste à définir des conditions d’acceptation avant le début de l’automatisation. L’IA peut rédiger une prévision, rapprocher une politique ou fusionner des notes de réunion, mais une automatisation digne de confiance exige une description claire de ce qui doit rester vrai.

Le nouvel adversaire est la génération sans vérification

La leçon la plus forte n’est pas que les LLM sont devenus fiables, mais qu’une génération peu fiable peut devenir utile au sein d’une boucle de vérification fiable.

La plupart des produits d’IA générative demandent aux utilisateurs de juger directement les résultats. Un modèle rédige un e-mail, résume une réunion, modifie une feuille de calcul ou propose du code. L’humain recherche ensuite les erreurs subtiles avec un temps et une attention limités.

Ce modèle rend l’automatisation attrayante pour les tâches à faible risque, mais difficile à faire confiance pour la sécurité, la finance, la conformité, l’infrastructure et les changements opérationnels irréversibles. La confiance du modèle offre peu de protection, car un langage fluide n’établit pas la correction.

L’automatisation des preuves Lean sépare deux tâches. Le LLM explore un vaste espace de preuves possibles, tandis que l’assistant de preuve effectue une tâche de vérification restreinte selon des règles exactes.

Le générateur peut halluciner le nom d’un théorème, appliquer une transformation invalide ou mal comprendre une définition. Ces échecs deviennent des candidats rejetés plutôt que des conclusions acceptées, à condition que la propriété revendiquée et la frontière de confiance soient saines.

Des recherches récentes indiquent l’émergence de systèmes construits autour de cette séparation. OpenProver, publié en juillet 2026, combine planification, agents exécutants et vérification Lean dans un système open source de démonstration de théorèmes.

Son architecture attribue différentes responsabilités à des agents spécialisés tout en conservant une vérification formelle automatique. Elle prend également en charge le pilotage humain, reconnaissant que la recherche de preuves bénéficie encore d’une orientation experte.

Il s’agit d’un modèle de produit différent d’un chatbot doté d’une fenêtre de code. La sortie précieuse n’est pas l’explication du modèle sur les raisons pour lesquelles une preuve devrait fonctionner. C’est l’objet de preuve qui survit à une vérification indépendante.

Un modèle similaire peut améliorer le travail ordinaire de connaissance, même lorsqu’une démonstration de théorème complète n’est pas nécessaire. Prenons le cas d’un chef de produit qui prépare une mise à jour hebdomadaire à partir d’entretiens, de tickets, de métriques et de décisions.

Un LLM peut rédiger rapidement cette mise à jour. Cependant, chaque affirmation factuelle doit rester traçable jusqu’à une source, chaque métrique doit conserver sa date et sa définition, et les contradictions non résolues doivent rester visibles.

Un système personnel de gestion des connaissances peut aider à préserver ces connexions. Par exemple, le knowledge blending peut réunir du contenu local connexe dans un même contexte de travail, plutôt que d’obliger l’utilisateur à le reconstituer à partir de fichiers dispersés.

Ce n’est pas la même chose qu’une preuve mathématique. Le vérificateur peut se composer de citations de sources, de validation de schéma, de contrôles d’accès, de tests arithmétiques ou d’une étape d’approbation humaine.

Le principe architectural reste similaire. La liberté générative intervient avant le portail. Des règles déterministes, des preuves documentées ou un examen responsable décident de ce qui le franchit.

Cela modifie aussi la manière dont les équipes devraient évaluer la productivité de l’IA. Le temps gagné lors de la rédaction n’est qu’une métrique. Le temps de revue, la fréquence des corrections, le taux d’échappement des défauts et la qualité des éléments probants sont tout aussi importants.

Un agent qui rédige dix fois plus vite mais double l’effort de revue n’a pas automatisé la tâche. Il a déplacé le travail vers une étape moins visible.

En revanche, un agent qui produit un premier résultat plus lent, avec une provenance complète et une validation automatique, peut offrir des gains de productivité plus utiles. Les éléments de preuve réduisent l’incertitude pour chaque lecteur en aval.

Lean rend ce principe particulièrement visible, car la condition d’acceptation est binaire. La preuve est vérifiée ou elle ne l’est pas. La plupart des automatisations de bureau ne disposent pas d’une limite aussi nette, mais les équipes peuvent créer des garde-fous plus petits et adaptés à chaque tâche.

Un récapitulatif financier peut exiger que chaque total soit rapproché des cellules sources. Une comparaison de contrats peut exiger que chaque différence signalée renvoie aux clauses exactes. Une note de recherche peut empêcher les citations non étayées d’intégrer le document final.

Ces garde-fous ne rendent pas le modèle sous-jacent honnête ou déterministe. Ils facilitent le confinement de ses faiblesses.

Ce que le test Zstandard ne prouve pas

L’expérience valide un mécanisme prometteur, mais elle n’établit pas que l’IA peut vérifier des systèmes de production de grande taille à faible coût ou de manière exhaustive.

La limite la plus évidente concerne le périmètre. Langley qualifie le décompresseur de jouet, indique que le code n’est pas publié et ne le présente pas comme un modèle pour d’autres programmeurs Lean.

Cela empêche les évaluateurs indépendants de reproduire le résultat, d’examiner les énoncés précis des théorèmes ou d’identifier les composants non vérifiés. Nous savons que des preuves sélectionnées ont passé la vérification de type, d’après le rapport de l’auteur.

Nous ne savons pas si ces énoncés couvrent toutes les propriétés qu’exige un décompresseur de production. Une preuve parfaitement valide d’une spécification incomplète peut coexister avec de graves défauts en dehors de cette spécification.

On appelle souvent cela le problème de la spécification. Le vérificateur peut établir qu’un code satisfait un énoncé formel, mais il ne peut pas décider si les humains ont choisi le bon énoncé.

Un décompresseur pourrait prouver que les entrées valides effectuent correctement un aller-retour, tout en laissant hors du théorème l’épuisement de la mémoire, les comportements de déni de service, les limites de ressources ou l’analyse des archives. Chaque limite omise crée une possibilité de défaillance.

La base de calcul de confiance compte également. Le petit noyau de Lean réduit fortement le composant auquel il faut faire confiance, mais les programmes réels interagissent avec des compilateurs, des systèmes d’exploitation, des fonctions étrangères, du matériel et des bibliothèques externes.

Langley a exploré l’appel d’assembleur optimisé via le mécanisme extern de Lean. De petits exemples d’équivalence ont fonctionné, mais les tentatives visant à étendre cette approche se seraient heurtées à des besoins mémoire considérables ou n’auraient pas progressé.

Ce résultat met en évidence un compromis central. Du code vérifié de haut niveau peut apporter de solides garanties logiques, tandis que les performances en production dépendent souvent d’implémentations et d’outils de bas niveau dépassant le cadre de la preuve immédiate.

L’implémentation Zstandard elle-même illustre cet écart. Langley indique que son décodeur Lean fonctionne environ dix fois moins vite que l’implémentation standard en ligne de commande.

Les performances ne sont pas une préoccupation mineure pour les logiciels de compression. La décompression se trouve souvent sur un chemin sensible à la latence impliquant le stockage, la distribution de paquets, les bases de données ou le transfert réseau.

La maintenance des preuves demeure également incertaine. Langley suggère qu’une régénération rapide pourrait réduire la nécessité de concevoir soigneusement les preuves pour les évolutions futures.

C’est plausible pour un projet limité. Une grande base de code peut créer des milliers d’obligations interdépendantes, où un petit changement de type se propage à travers les modules et dépasse le contexte ou le budget de recherche d’un agent.

Les benchmarks de recherche ne devraient pas, à eux seuls, trancher cette question. Les collections de théorèmes mathématiques fournissent généralement des objectifs explicites et des environnements contrôlés. Le code de production comporte des spécifications partielles, des interfaces héritées, des dépendances changeantes et des hypothèses non documentées.

Il existe également un risque lié au facteur humain. La génération facile de preuves peut inciter à considérer toute coche verte comme une assurance complète.

Un théorème vérifié dit exactement ce que dit son énoncé formel. Il n’offre aucune garantie concernant la sécurité, la confidentialité, la fiabilité ou la justesse métier, sauf si ces propriétés figurent dans le modèle.

Les équipes doivent donc examiner les spécifications avec le même sérieux que celui aujourd’hui réservé aux revues de code. Sinon, l’IA accélérera la production de réponses convaincantes à des questions incomplètes.

L’automatisation des preuves par l’IA déplace le goulot d’étranglement vers les spécifications

Si les modèles deviennent des générateurs de preuves compétents, le travail intellectuel à forte valeur se déplace de la construction d’artefacts vers la définition des affirmations et des limites.

Les équipes logicielles ont déjà connu une version de cette transition. Les agents de programmation réduisent le coût de production des fonctions, tests, migrations et documentations.

À mesure que la production devient moins coûteuse, décider de ce qui doit être construit devient plus important. Les exigences, interfaces, contraintes, modèles de menace et tests d’acceptation déterminent si une génération rapide crée de la valeur ou seulement davantage de matière à inspecter.

Lean étend ce déplacement aux affirmations de correction. Un programmeur peut encoder un invariant dans un type, demander à un LLM de construire la preuve et laisser le noyau en vérifier le résultat.

La contribution humaine ayant le plus d’impact se situe souvent en amont. Quelqu’un doit reconnaître quel invariant compte, l’exprimer sans échappatoire et le relier à l’environnement d’exploitation réel.

Les travailleurs du savoir rencontrent la même structure avec des outils moins formels. Un analyste doit décider quelles preuves sont admissibles pour étayer une affirmation de marché. Un recruteur doit définir quels critères de candidat sont légaux et pertinents.

Un responsable du support doit préciser quand une réponse automatisée peut être envoyée et quand un dossier exige une escalade. Un chercheur doit distinguer une source directe, un résumé secondaire et une inférence non étayée.

Ce sont des tâches de spécification, même lorsque personne ne les rédige dans Lean. Elles transforment des attentes vagues en conditions observables.

Les organisations peuvent s’y préparer en consignant les règles de décision à côté des documents qu’elles régissent. Une note indiquant « utiliser le nombre de clients le plus récent » est ambiguë. Une règle qui nomme le tableau de bord de référence, l’heure d’actualisation, la région et la période de reporting est vérifiable.

La provenance devient tout aussi importante. Un modèle ne peut pas réconcilier de manière fiable les connaissances d’une équipe si le matériau source a perdu sa date, son propriétaire, sa version ou son lien avec les décisions antérieures.

C’est pourquoi le passage des interfaces de chat aux systèmes d’agents exige une meilleure architecture de l’information. Les agents ont besoin d’un contexte structuré, d’autorisations, de règles de validation et d’archives durables des modifications qu’ils ont apportées.

La revue humaine doit également se concentrer sur les exceptions. Si chaque affirmation générée par l’IA exige une inspection ligne par ligne, le système demeure un assistant plutôt qu’une couche d’automatisation.

Des garde-fous utiles peuvent approuver automatiquement les cas courants qui remplissent des conditions explicites. Les humains se concentrent alors sur les preuves manquantes, les sources contradictoires, les valeurs inhabituelles, les actions sensibles pour la sécurité et les changements hors des schémas connus.

Les assistants de preuve formelle offrent la version la plus robuste de ce flux de travail, mais ils ne conviennent pas à toutes les tâches. De nombreuses décisions dépendent du jugement, de définitions contestées ou d’informations incomplètes.

L’objectif n’est pas de formaliser chaque e-mail. Il consiste à identifier les affirmations dont l’échec entraîne un coût réel et à construire autour d’elles des contrôles proportionnés.

Pour les logiciels, cela peut signifier prouver la sûreté des limites dans un analyseur tout en testant l’interface utilisateur de manière conventionnelle. Pour une équipe opérationnelle, cela peut signifier rapprocher automatiquement les totaux de paiement tout en exigeant une approbation humaine pour les virements.

Pour les chercheurs, cela peut signifier valider chaque citation et chaque passage cité tout en laissant l’interprétation ouverte au débat. La vérification doit protéger la limite qui compte le plus.

L’expérience de Langley rend cette stratégie de conception plus facile à imaginer. Le LLM n’avait pas besoin de devenir un mathématicien infaillible. Il devait générer un artefact qu’un système plus strict pouvait évaluer.

C’est une voie plus réaliste pour l’IA d’entreprise que d’attendre que les modèles cessent de commettre des erreurs.

Trois signaux montreront si ce changement est réel

La prochaine étape dépendra de la reproductibilité, de l’échelle et d’un coût de maintenance mesurable, plutôt que d’une nouvelle preuve ponctuelle impressionnante.

Le premier signal est un corpus publié et reproductible de logiciels vérifiés ordinaires. Le décompresseur de Langley ne peut pas jouer ce rôle, car le code source et les preuves ne sont pas disponibles.

Des projets comme lean-zip fournissent une référence plus inspectable. Leonardo de Moura, co-créateur de Lean, l’a récemment mis en avant comme un projet de compression vérifié qui implémente à la fois la compression et la décompression.

Les futurs projets devront inclure des énoncés de théorèmes précis, des hypothèses documentées, des mesures de performance et des tests par rapport à des implémentations établies. Des équipes indépendantes devraient pouvoir reconstruire chaque preuve et identifier quels modules restent en dehors de la limite vérifiée.

Si plusieurs projets reproduisent ce modèle pour des analyseurs, du code réseau, des formats de stockage et des composants cryptographiques, les arguments en faveur de l’automatisation des preuves avec Lean se renforceront. Si les résultats restent concentrés dans de petites démonstrations, l’affirmation plus large s’affaiblira.

Le deuxième signal concerne le comportement de la génération de preuves après de véritables modifications du code. La construction initiale des preuves attire l’attention, mais c’est la maintenance qui détermine si l’économie du modèle fonctionne.

Les équipes devraient mesurer le temps de régénération après des refactorisations, des mises à niveau de dépendances, des modifications de spécifications et des optimisations de performance. Elles devraient également enregistrer la fréquence à laquelle un expert humain doit restructurer le code ou inventer des lemmes intermédiaires.

Une réussite rapide sur un théorème stable fournit des preuves limitées concernant une application vivante. Un système utile doit survivre à des mois de développement ordinaire sans transformer chaque pull request en projet imprévisible de recherche de preuves.

Si les coûts des preuves restent maîtrisés et que les échecs produisent des diagnostics exploitables, la vérification générée par l’IA peut intégrer l’intégration continue. Si de petits changements déclenchent des heures de recherche opaque, l’adoption restera limitée.

Le troisième signal est l’intégration dans les agents de programmation grand public. La génération de preuves se situe actuellement près des flux de travail de recherche et des environnements Lean spécialisés.

Le point d’inflexion pratique arrivera lorsqu’un agent pourra proposer un invariant, expliquer son périmètre, générer la preuve, lancer le vérificateur et montrer exactement quelles hypothèses restent non vérifiées.

Cette interface doit résister à une confiance excessive. Elle doit distinguer le comportement testé du comportement prouvé, ainsi que les modules vérifiés des enveloppes non vérifiées.

Elle doit aussi rendre les modifications de théorèmes très visibles. Un agent ne doit jamais « corriger » une preuve en échec en affaiblissant silencieusement la propriété que les utilisateurs s’attendaient à voir préservée.

Pour les travailleurs du savoir, ces signaux se traduisent par un test simple lors des achats. Demandez si un produit d’IA génère des réponses ou produit des réponses assorties de conditions d’acceptation applicables.

Recherchez une provenance au niveau des sources, des contrôles d’autorisation, une validation structurée, des transformations reproductibles et des voies d’escalade claires. Une réponse soignée dépourvue de ces contrôles reste un brouillon, quelle que soit l’assurance avec laquelle elle est formulée.

L’automatisation des preuves avec Lean ne prouve pas que l’IA peut désormais être digne de confiance seule. Elle montre que la confiance peut être conçue autour de l’IA lorsque les affirmations sont explicites et que la vérification reste indépendante.

La question pour le prochain projet est pratique : quelle décision récurrente crée suffisamment de risques pour justifier un véritable garde-fou d’acceptation ? Commencez par là, définissez ce qui doit rester vrai et faites en sorte que l’automatisation mérite chaque coche verte.