L’automatisation des preuves Lean vient de passer de la recherche aux logiciels réels

L’automatisation des preuves Lean a franchi un seuil pratique le 26 juillet, lorsque l’ingénieur en sécurité Adam Langley a décrit un décodeur Zstandard formellement vérifié et assisté par IA. Plusieurs grands modèles de langage ont généré des preuves substantielles en environ 20 minutes, selon Langley. Lean a ensuite vérifié ces preuves sans accepter de marqueurs indiquant qu’elles étaient inachevées. L’expérience était modeste, mais elle remet en question une hypothèse tenace sur les logiciels vérifiés : la preuve ne coûte peut-être plus beaucoup plus cher que le programme.

Cela ne signifie pas qu’un modèle d’IA a prouvé que le décodeur était correct au sens large ou philosophique du terme. Langley a choisi les propriétés, écrit une grande partie de l’implémentation et confirmé que Lean acceptait les termes de preuve obtenus. Son décodeur était également environ dix fois plus lent que la commande standard zstd. L’avancée réelle est plus limitée et plus utile. L’IA peut désormais effectuer suffisamment de travail de preuve formelle pour modifier les projets d’ingénierie qui paraissent économiquement raisonnables.

Cela place les tests ordinaires et la vérification formelle dans une nouvelle compétition. Les tests échantillonnent des exécutions sélectionnées, tandis qu’une preuve formelle peut couvrir chaque entrée représentée par un théorème. Historiquement, cette garantie plus forte entraînait des coûts de main-d’œuvre exceptionnels. Le célèbre projet de système d’exploitation seL4 a fait état d’efforts de preuve très supérieurs à son travail d’implémentation. Si l’IA réduit ce travail sans entrer dans la chaîne de vérification de confiance, les logiciels appuyés par des preuves cessent d’apparaître comme une spécialité réservée aux noyaux et à la cryptographie.

Ce que l’expérience Lean Zstandard a réellement changé

Le résultat important n’était pas qu’une IA ait écrit du code. C’était que le travail de preuve généré par l’IA ait résisté à un vérificateur mécanique indépendant.

Langley a construit un décompresseur Zstandard dans Lean, un langage de programmation fonctionnelle et démonstrateur de théorèmes interactif. Zstandard, généralement abrégé en Zstd, est un format de compression conçu pour une compression sans perte rapide. Son décodeur doit interpréter correctement des en-têtes compacts, des symboles codés par entropie, des longueurs, des décalages et des séquences répétées.

Ces détails créent précisément les bogues que les systèmes de types classiques peinent à exclure. Une longueur décodée peut ne pas correspondre aux données d’entrée disponibles. Un index de tableau peut franchir une limite. Une table malformée peut produire un état qui ne devrait pas exister. Les développeurs gèrent généralement ces possibilités au moyen de validations, de contrôles à l’exécution, de tests, de fuzzing et de revues attentives.

Lean ajoute une autre possibilité. Son système de types dépendants permet à un type d’intégrer des faits sur une valeur. Une fonction peut renvoyer à la fois un tableau d’octets et une garantie vérifiée par machine que ce tableau possède la longueur demandée. Le code ultérieur peut utiliser cette garantie lors de l’accès à un élément.

Langley a montré ce schéma dans une branche de décodeur pour l’encodage par longueur d’exécution. Cette branche devait lire un octet dans un bloc. Lean exigeait une preuve que le bloc contenait cet octet. L’implémentation reliait la longueur de lecture demandée à un théorème montrant que ce type de bloc possède toujours une taille de contenu égale à un.

Cette preuve locale était courte. L’exemple le plus conséquent concernait l’entropie à états finis, ou FSE, que Zstandard utilise pour représenter efficacement les symboles. Langley a implémenté l’algorithme de construction de table décrit par le format, puis a demandé à des systèmes d’IA de prouver des propriétés universelles sur sa sortie.

Les propriétés demandées allaient au-delà de tests fondés sur des exemples. Elles couvraient la taille de la table, le nombre d’entrées attribuées à chaque symbole et les transitions valides au sein de la table. Autrement dit, la preuve décrivait des règles structurelles censées s’appliquer à toutes les distributions acceptées, et non seulement aux trois vecteurs de test fournis par la spécification.

Langley indique que plusieurs LLM ont achevé ces preuves en environ 20 minutes. Il affirme également que le travail n’a consommé qu’une fraction d’un quota d’abonnement mensuel standard. Les modèles ont modifié une partie de son implémentation, car sa structure impérative résistait aux mécanismes de preuve de Lean. Il a ensuite confirmé que les preuves finales étaient correctement typées et ne contenaient aucun sorry, le marqueur explicite de Lean pour une preuve inachevée.

Son compte rendu complet, avec les extraits de code et les limites, figure dans l’article original sur l’automatisation des preuves. Il n’a pas publié le dépôt du décodeur ; les développeurs externes ne peuvent donc pas encore reproduire chacune de ses affirmations. Il s’agit d’un retour d’expérience, et non d’un résultat évalué de manière indépendante.

L’expérience établit néanmoins un flux de travail crédible. Un humain énonce l’invariant. Une IA cherche une preuve et remanie le code lorsque nécessaire. Lean vérifie le terme de preuve produit. Le modèle fournit le travail, mais le vérificateur décide de l’acceptation.

C’est cette répartition qui distingue ce résultat d’une simple démonstration de programmation par IA.

Pourquoi l’automatisation des preuves Lean intéresse les travailleurs du savoir

L’automatisation des preuves importe parce qu’elle peut transformer des hypothèses importantes, exprimées en prose, en produits de travail vérifiés et réutilisables.

La plupart des travailleurs du savoir n’écrivent pas de décodeurs de compression. Ils évoluent toutefois dans des systèmes construits sur des hypothèses non documentées. Un modèle financier suppose qu’une colonne contient des identifiants uniques. Un flux de travail de politique interne suppose que chaque approbation possède un responsable clairement identifié. Un pipeline de recherche suppose que chaque citation conserve sa source.

Les équipes expriment souvent ces règles dans de la documentation, des commentaires, des supports d’intégration ou des notes de réunion. Ces règles s’affaiblissent à mesure que le travail traverse les outils et les services. Un champ renommé, un enregistrement inhabituel ou un processus modifié peut les invalider sans générer d’alerte immédiate.

Les méthodes formelles traitent un problème similaire dans les logiciels. Elles transforment certaines hypothèses en énoncés suffisamment précis pour qu’une machine les vérifie. Lean utilise des types dépendants, ce qui signifie que les types peuvent dépendre de valeurs et ainsi encoder des relations détaillées entre les entrées et les sorties.

Le langage ne se contente pas d’exécuter un script de preuve généré par IA et de faire confiance à sa conclusion. Les tactiques Lean construisent des termes de preuve, qui sont des représentations de l’argument vérifiables indépendamment. Un petit noyau vérifie ensuite que chaque terme découle des règles logiques du système. La documentation officielle du noyau Lean décrit cette séparation entre l’automatisation pratique et la vérification de confiance.

Cette architecture modifie le calcul du risque autour de l’IA. Un modèle de langage peut halluciner des tactiques, mal comprendre une définition ou poursuivre un objectif erroné. La plupart de ces échecs produisent du code rejeté plutôt qu’un théorème accepté silencieusement. Le modèle peut être peu fiable tandis que le contrôle final d’acceptation reste strict.

Cela ne rend pas l’ensemble du flux de travail exempt d’erreurs. Une preuve valide peut établir l’énoncé erroné. Des définitions peuvent omettre le comportement réel. Des bibliothèques importées peuvent introduire des hypothèses. Une fonction vérifiée au niveau du code source peut encore dépendre d’un compilateur, d’un système d’exploitation ou d’un processeur non vérifiés.

Les propres recommandations de Lean sur la validation des preuves soulignent ces limites. L’acceptation par le noyau montre qu’un théorème découle de ses définitions et dépendances. Elle ne montre pas que le théorème correspond à ce qu’une personne avait l’intention d’exprimer.

Pour les travailleurs du savoir, cette distinction ressemble à une feuille de calcul aux formules irréprochables mais fondée sur une mauvaise définition métier. Les calculs peuvent être cohérents en interne tout en répondant à la mauvaise question. La formalisation déplace la revue la plus difficile vers la spécification.

Ce déplacement est précieux. Les humains ont tendance à mieux examiner l’intention et le contexte que des milliers d’étapes mécaniques de preuve. L’IA peut absorber davantage de recherche répétitive tandis que les personnes examinent avec attention ce qui doit réellement être vrai.

Le même schéma apparaît déjà dans le travail pratique sur l’information. L’IA rédige des résumés, des classifications, des requêtes et des transformations. Un flux de travail responsable vérifie ensuite le résultat par rapport à des sources primaires, des schémas, des contraintes ou des calculs déterministes. L’automatisation des preuves applique ce schéma à un niveau bien plus strict.

Elle clarifie également pourquoi le contexte personnel reste important. Un modèle ne peut pas protéger un invariant qu’il ne voit jamais. Les équipes ont besoin d’accéder aux registres de décision, spécifications, exemples et exceptions qui définissent le comportement correct. Une base de connaissances personnelle bien entretenue devient une partie de la discipline des données d’entrée, même lorsque la preuve formelle demeure une activité spécialisée.

L’opportunité immédiate n’est pas de formaliser chaque mémo. Elle consiste à identifier les hypothèses coûteuses qui se comportent déjà comme des spécifications cachées. Ces hypothèses se situent souvent à la frontière entre systèmes, équipes ou obligations réglementaires.

La nouvelle compétition oppose le coût de la preuve à la valeur de la vérification

L’IA ne change la vérification formelle que si elle réduit le travail de preuve plus rapidement qu’elle n’accroît le travail de spécification et de maintenance.

La vérification formelle n’a jamais manqué de résultats convaincants. Le micronoyau seL4 en fournit un exemple marquant. Ses preuves vérifiées par machine relient les implémentations à des spécifications formelles et couvrent des propriétés que les seuls tests ne peuvent établir.

La documentation officielle sur la vérification seL4 explique que les configurations prises en charge disposent de preuves de correction fonctionnelle au niveau du code. Certaines configurations étendent ces garanties au code binaire. Le projet montre ce que les méthodes formelles peuvent apporter lorsque les enjeux justifient un effort spécialisé soutenu.

Il illustre aussi pourquoi l’adoption est restée limitée. Langley cite une rétrospective de seL4 selon laquelle les ingénieurs ont consacré environ dix fois plus d’efforts à la preuve qu’à la conception et à l’implémentation. Il note également que le code de preuve dépassait l’implémentation C de plus de vingt fois.

Ces ratios ne doivent pas être considérés comme une taxe universelle. seL4 visait un niveau d’assurance exceptionnellement élevé sur un noyau de système d’exploitation complexe. Des propriétés, langages et chaînes d’outils différents entraînent des coûts différents. Ces chiffres illustrent néanmoins le problème historique : l’effort de preuve peut dominer la livraison.

L’automatisation traditionnelle des preuves réduit une partie de cette charge. Les simplificateurs, procédures de décision, solveurs SAT et solveurs SMT peuvent résoudre de nombreux objectifs. Les développeurs doivent toutefois souvent structurer le code et les lemmes en fonction de ce que chaque solveur traite efficacement.

Langley décrit cela comme le développement d’un sixième sens pour satisfaire le solveur. Un objectif en dehors d’un fragment favorable peut engager une recherche automatisée dans une voie improductive. Les ingénieurs passent alors du temps à traduire le problème dans une forme que l’outil peut résoudre.

Les LLM apportent une capacité différente. Ils peuvent lire les définitions environnantes, examiner les messages d’erreur, essayer des tactiques, introduire des lemmes intermédiaires et réviser l’implémentation. Ils n’exigent pas que chaque problème entre dans une procédure de décision fixe.

Cette flexibilité rend l’IA utile comme couche d’orchestration au-dessus des outils de preuve existants. Un modèle peut appeler des tactiques déterministes lorsqu’elles sont adaptées, écrire un argument explicite ailleurs et utiliser les retours de Lean pour corriger les échecs. Le modèle explore des stratégies de preuve tandis que le noyau fournit un test d’acceptation strict.

L’expérience de Langley révèle également un coût important. Ses assistants IA ont modifié le code de construction de table parce qu’il avait trop utilisé Id.run, une manière d’exprimer un calcul impératif dans Lean. Le code d’origine était peut-être lisible et exécutable, mais il était moins favorable à la preuve.

C’est de l’ingénierie de la preuve : le travail consistant à structurer programmes et lemmes afin que les preuves restent possibles et maintenables. L’IA peut en réduire le coût, mais elle ne supprime pas la tension sous-jacente. Le code optimisé pour la familiarité humaine, les performances à l’exécution et la simplicité de la preuve n’aura pas toujours une forme unique.

La question économique change donc. Les équipes ne demandent plus seulement : « Pouvons-nous prouver cela ? » Elles demandent : « Une IA peut-elle maintenir la preuve et la structure qui la soutient aussi rapidement que les développeurs font évoluer le produit ? »

Cela favorise les logiciels aux frontières stables et explicites. Les analyseurs syntaxiques, politiques d’autorisation, machines à états de protocole, calculs financiers et transformations de données exposent souvent des propriétés claires. Leurs modes de défaillance justifient également un niveau d’assurance plus élevé.

AWS propose une comparaison utile en production avec Cedar, son langage de politiques d’autorisation. AWS maintient des modèles Lean exécutables aux côtés de son implémentation Rust et utilise des preuves avec des tests différentiels. Le compte rendu publié sur le développement vérifié indique que les versions de Cedar exigent des modèles, des preuves et des tests à jour.

Cedar ne prouve pas que chaque application devrait passer à Lean. Il montre toutefois que des artefacts formels peuvent s’intégrer à un véritable processus de livraison. La recherche de preuves assistée par IA pourrait élargir le nombre d’équipes capables de maintenir un tel processus.

Le modèle le plus solide à court terme restera probablement hybride. Les ingénieurs implémentent le code de production dans un langage généraliste. Ils formalisent les comportements à forte valeur dans Lean. Les tests comparent les deux implémentations, tandis que les preuves établissent les propriétés du modèle.

Langley a suivi une voie plus directe en implémentant le décodeur directement dans Lean. Cela a créé des liens forts entre le code et le théorème, mais au prix d’une pénalité majeure de performance. Le choix entre modèles vérifiés et code de production vérifié reste central.

Ce que la preuve ne prouve pas

Une preuve vérifiée par le noyau peut éliminer une catégorie d’incertitude tout en laissant ouvertes la spécification, la frontière d’implémentation et l’environnement d’exploitation.

Le titre « Nous disposons désormais de l’automatisation des preuves » est volontairement provocateur. L’expérience l’étaye dans un sens pratique, mais seulement dans les limites énoncées. Elle n’établit pas qu’un LLM puisse vérifier de manière autonome n’importe quel logiciel de production.

Premièrement, le code source n’est pas disponible. Langley affirme avoir vérifié que les preuves passent la vérification de types et ne contiennent aucun espace réservé inachevé. Les lecteurs peuvent évaluer son raisonnement et ses exemples, mais ils ne peuvent pas reproduire l’intégralité de la compilation.

Deuxièmement, le travail portait sur un décodeur jouet. Zstandard est un format sérieux, et la construction de tables FSE n’est pas triviale. Pourtant, le projet n’a pas dû gérer des années d’évolutions fonctionnelles, plusieurs équipes, la rétrocompatibilité, des environnements d’intégration hostiles ou la pression des incidents en production.

Troisièmement, le décodeur était environ dix fois plus lent que l’implémentation standard en ligne de commande. Cet écart compte. Un logiciel ne peut pas sacrifier ses exigences opérationnelles fondamentales simplement parce que ses preuves sont élégantes.

Langley a étudié la possibilité d’utiliser de l’assembleur vérifié pour résoudre le problème de performance. Il a envisagé d’utiliser le framework LNSym d’AWS afin de prouver que de l’assembleur AArch64 optimisé correspondait à des fonctions Lean. De petits exemples ont fonctionné, mais l’approche n’a pas passé à l’échelle dans ses tests. Un petit exemple utilisant bv_decide, une tactique pour les propositions finies sur les vecteurs de bits, exigeait plus de mémoire que sa machine n’en possédait.

C’est un rappel que la vérification n’est pas gratuite. Un terme de preuve peut devenir coûteux à traiter pour le noyau. Les recherches automatisées peuvent épuiser la mémoire ou le temps disponible. Un flux de travail théoriquement valide peut tout de même dépasser son budget de compilation.

Quatrièmement, les modèles ont dû modifier l’implémentation. Ce n’est pas intrinsèquement mauvais. Une preuve peut révéler que la structure d’un programme masque les relations dont il dépend. Refactoriser vers des invariants explicites peut améliorer la maintenabilité.

Cependant, un refactoring généré par IA peut également modifier le comportement ou dégrader les performances. Le théorème final ne protège que les propriétés qu’il énonce. Les ingénieurs ont toujours besoin de tests, de benchmarks, de revues de code et de modélisation des menaces pour tout ce qui se situe hors de ces propriétés.

Cinquièmement, la spécification humaine reste le point le plus sensible. Si un théorème sur un décodeur prouve la bonne formation des tables mais omet un dépassement d’entier ailleurs, la propriété vérifiée reste vraie mais incomplète. Si le comportement Zstandard formalisé diffère du format réel, Lean peut vérifier fidèlement le mauvais modèle.

Le format de compression concerné est documenté dans la RFC 8878, mais transformer une norme rédigée en prose en définitions implique une interprétation. L’ambiguïté ne disparaît pas lorsqu’elle entre dans un démonstrateur de théorèmes. Elle devient une décision de modélisation.

Ce risque s’accroît lorsque des non-spécialistes s’appuient sur l’IA pour générer à la fois l’énoncé et la preuve. Un modèle peut rendre une affirmation facile à prouver en l’affaiblissant. Il peut choisir une définition commode qui exclut les entrées problématiques. Il peut satisfaire le vérificateur tout en manquant l’intention du relecteur.

Cela signifie que la revue de preuves nécessitera une interface différente. Les relecteurs devraient voir des explications en langage clair pour chaque théorème, ses hypothèses, les axiomes importés, les chemins de code couverts et les comportements exclus. Une simple coche verte ne suffit pas.

Les organisations auront également besoin d’une traçabilité entre les décisions métier et les définitions formelles. Lorsqu’une politique change, quelqu’un doit savoir quel théorème l’encode. Lorsqu’une implémentation change, le système doit identifier quelles garanties doivent être réexaminées.

C’est là que l’assistance IA peut aider au-delà de l’écriture de tactiques. Un agent peut retrouver la spécification pertinente, relier une modification de code aux invariants affectés et résumer les obligations non satisfaites. Une base de connaissances consultable peut relier le contexte de conception aux artefacts formels.

Aucune de ces limites n’annule le résultat. Elles définissent le travail nécessaire pour faire passer cette expérience intrigante à une pratique d’ingénierie fiable.

L’automatisation des preuves Lean met les outils de codage IA sous pression

Lorsqu’un modèle peut générer du code et une preuve vérifiable, « les tests sont passés » commence à ressembler à une affirmation de qualité incomplète.

Les produits de codage IA rivalisent aujourd’hui sur l’exécution des tâches, la compréhension des dépôts, l’utilisation d’outils, les scores de benchmark et l’expérience développeur. Leurs garde-fous de qualité ressemblent encore au développement conventionnel. Les agents exécutent des tests, linters, vérificateurs de types, scanners de sécurité et flux de revue humaine.

Ces contrôles sont importants, mais la plupart n’établissent pas un comportement universel. Un test unitaire prouve qu’une entrée sélectionnée a produit un résultat attendu lors d’une exécution donnée. Le fuzzing étend la couverture au moyen d’entrées générées, mais il continue d’échantillonner des exécutions. L’analyse statique peut couvrir des catégories plus larges, mais chaque analyseur travaille selon des approximations définies.

Un théorème peut affirmer que chaque entrée acceptée satisfait une propriété choisie. Si Lean vérifie la preuve, la garantie ne dépend pas de la confiance accordée au modèle qui l’a générée. C’est une distinction produit convaincante pour les systèmes de codage agentiques.

La pression apparaîtra d’abord sur des tâches étroites. Un agent IA pourrait générer un analyseur syntaxique accompagné d’une preuve que les analyses réussies ne dépassent jamais une limite d’entrée. Il pourrait implémenter une règle de contrôle d’accès avec un théorème excluant les transitions non autorisées. Il pourrait créer une migration de base de données et prouver la préservation d’un invariant de schéma dans un modèle formel.

Les outils grand public n’ont pas besoin d’exposer la syntaxe Lean à chaque utilisateur. Ils peuvent proposer la vérification formelle comme mode de validation supplémentaire. L’interface pourrait demander aux développeurs d’approuver des propriétés en langage clair, montrer leurs traductions formelles et renvoyer soit des preuves vérifiées, soit des contre-exemples concrets.

La fonctionnalité décisive ne sera pas les scores bruts de démonstration de théorèmes. Ce sera l’intégration. L’automatisation des preuves doit fonctionner avec le contexte du dépôt, les systèmes de compilation, les spécifications, les tests de performance et la revue de code.

L’expérience de Langley fournit une leçon produit utile. Les modèles ont travaillé de façon interactive. Ils ont rencontré du code résistant à la preuve, en ont modifié la structure et ont continué jusqu’à ce que le vérificateur accepte le résultat. Cela ressemble davantage à un agent d’ingénierie qu’à un système d’autocomplétion.

Elle suggère également une nouvelle forme de responsabilité. La génération de code par IA produit souvent une asymétrie : le modèle peut créer du code plus vite qu’un humain ne peut le relire. Les agents produisant des preuves peuvent joindre des éléments de preuve vérifiables par machine à des affirmations ciblées.

Ces éléments de preuve ne rendent pas la revue facultative. Ils permettent aux relecteurs de passer moins de temps à simuler un comportement mécanique et davantage à examiner l’affirmation. La question centrale devient : « Est-ce la propriété dont nous avons besoin ? », plutôt que : « Le modèle a-t-il négligé quelque part un cas d’indice ? »

Les concurrents peuvent répondre par plusieurs voies. Ils peuvent intégrer Lean directement, connecter des modèles à d’autres assistants de preuve, produire des certificats pour des solveurs spécialisés ou combiner des modèles formels avec du code conventionnel. L’approche gagnante peut varier selon le domaine.

Lean dispose d’un avantage, car il réunit programmation, démonstration de théorèmes, métaprogrammation et automatisation étendue dans un même environnement. Son noyau fournit également une frontière de confiance claire. Pourtant, Lean n’est pas automatiquement le bon langage de déploiement pour les logiciels sensibles aux performances.

L’IA produisant des preuves sera donc en concurrence avec des pipelines de développement vérifiant les preuves, et non seulement avec d’autres LLM. L’unité fiable est le système complet : modèle, énoncé formel, outils de preuve, noyau, hypothèses sur le compilateur, tests et relecteurs.

Pour les travailleurs du savoir qui achètent des produits IA, cela crée une meilleure question que celle de savoir si le modèle d’un fournisseur est précis. Demandez quelles sorties reçoivent une validation déterministe, quelles affirmations disposent d’éléments de preuve vérifiables et lesquelles dépendent encore d’un jugement probabiliste.

L’automatisation des preuves fournit la version la plus forte de ce modèle. Elle ne s’appliquera pas à chaque tâche, mais elle relève les attentes pour toute sortie pouvant être spécifiée formellement.

Trois signaux indiqueront si cela devient une pratique d’ingénierie normale

La prochaine étape dépend de la reproductibilité, de la maintenance face au changement et de fonctionnalités appuyées par des preuves dans les outils de développement du quotidien.

Le premier signal sera un dépôt logiciel public et reproductible comparable à l’expérience de Langley. Les développeurs doivent pouvoir examiner les définitions, les prompts ou traces d’agent, les termes de preuve, les axiomes, les temps de compilation et les exigences matérielles. Des équipes indépendantes devraient pouvoir réexécuter le processus et tester des modèles alternatifs.

La reproductibilité renforcerait l’affirmation selon laquelle les LLM actuels peuvent gérer un travail de preuve substantiel. L’impossibilité de la reproduire limiterait le résultat à la configuration et au jugement d’un ingénieur compétent. Les deux issues amélioreraient les éléments de preuve disponibles.

Le deuxième signal sera la performance face à l’évolution du code. Une preuve ponctuelle peut masquer une aide humaine importante. Le test plus exigeant consiste à savoir si un agent peut réparer des preuves après des modifications réalistes de l’implémentation sans affaiblir le théorème ni déformer le programme.

Les équipes devraient mesurer le temps de réparation des preuves, les interventions humaines, le coût computationnel, les changements de théorèmes et les régressions de performance. Elles devraient également suivre la fréquence à laquelle une preuve échouée révèle un véritable bug plutôt qu’un changement structurel sans gravité.

Si la réparation reste rapide sur plusieurs mois de développement, l’IA aura réduit la charge de maintenance de l’ingénierie des preuves. Si chaque changement déclenche une restructuration importante, la vérification formelle restera limitée à des composants stables et à forte valeur.

Le troisième signal sera l’intégration produit. Surveillez les agents de codage qui proposent des propriétés vérifiées par le noyau comme sortie standard, notamment pour les analyseurs syntaxiques, moteurs de politiques, implémentations de protocoles et code de traitement de données.

Un produit crédible devrait séparer la génération du théorème de la vérification du théorème. Il devrait afficher les hypothèses, rejeter les preuves inachevées, conserver les journaux de vérification et avertir lorsqu’une modification de code invalide une garantie. Il devrait également maintenir les tests et les benchmarks dans le flux de travail.

Si ces fonctionnalités apparaissent dans les outils grand public, l’automatisation des preuves Lean aura dépassé les démonstrations de démonstration de théorèmes. Si elles restent confinées aux dépôts de recherche, le gain de productivité n’aura pas encore compensé les coûts d’intégration.

Pour les travailleurs du savoir, la réponse pratique consiste à préparer de meilleures spécifications. Consignez les décisions qui définissent le comportement attendu. Préservez les sources. Identifiez les invariants dont une mauvaise compréhension entraîne des défaillances coûteuses. Rendez les exceptions explicites.

Posez ensuite une question plus précise à chaque workflow d’IA : quels résultats peuvent faire l’objet d’une vérification indépendante et fiable ?

Le décodeur de Langley ne prouve pas que tous les logiciels peuvent être formellement vérifiés. Il montre que l’IA a commencé à s’attaquer à la barrière des coûts, tandis que Lean préserve une porte de contrôle finale stricte. Cela suffit à modifier la feuille de route.

L’avenir proche ne sera pas fait de logiciels écrits par des modèles infaillibles. Ce seront des logiciels proposés par des modèles faillibles, encadrés par de meilleures spécifications et vérifiés par des systèmes qui se moquent de l’assurance avec laquelle le modèle s’exprime.