AlphaProof Code vs AesCode 32B : l’un prouve que le code est correct, l’autre le dessine

Mettez AlphaProof Code et AesCode 32B dans la même phrase, et le seul point commun est le mot « code ». AlphaProof Code est un framework agentique de Google DeepMind annoncé le 10 novembre 2026, qui a produit environ 6,5 millions de lignes de Lean vérifiées par machine prouvant que le binaire libsignal compilé se comporte comme spécifié. AesCode 32B est un modèle vision-langage de 33 milliards de paramètres que Microsoft a mis en ligne sur Hugging Face début octobre 2026 sans annonce, et qui écrit un prompt dans un unique document HTML autonome — une diapositive, une affiche, un tableau de bord — qu’un humain regarde ensuite. Aucun des deux n’est un service que l’on peut appeler. L’un des deux n’est même pas un modèle. Si vous êtes arrivé ici en quête d’une décision de remplacement direct, la réponse honnête est qu’une telle décision n’existe pas, et le reste de cet article explique pourquoi la comparaison vaut quand même la peine.

L’erreur de catégorie, énoncée correctement

AesCode 32B est un générateur. Vous lui donnez une description ; il renvoie un artefact dont la qualité est jugée sur le plan esthétique et selon que les chiffres figurant sur la page correspondent ou non à ceux que vous avez demandés. La fiche modèle présente elle-même les choses ainsi : les générateurs d'images composent une belle page et rendent mal les chiffres qui s'y trouvent, tandis que les modèles de code obtiennent des chiffres corrects mais ne peuvent pas voir à quoi ressemble la page — AesCode associe votre prompt à une image générée à partir de ce même prompt et utilise l'image comme référence esthétique tout en suivant le texte pour le contenu.

AlphaProof Code est un vérificateur. Vous lui fournissez une spécification — l'énoncé de ce qui doit être vrai — et il renvoie une preuve, vérifiée par le noyau de Lean, qu'un binaire compilé particulier satisfait cette spécification. Il n'y a aucun jugement esthétique à aucun moment du processus. Une preuve est soit acceptée, soit elle ne l'est pas, et le critère d'acceptation est constitué de quelques milliers de lignes de code du noyau plutôt que du goût d'un relecteur.

Cette distinction détermine à quoi sert chacun. AesCode 32B répond à « fais-moi une chose ». AlphaProof Code répond à « cette chose est-elle bien ce qu’elle prétend être ». Vous utiliseriez le premier un mardi après-midi pour une présentation, et le second, si vous étiez Signal, sur quatre semaines avec cinq chercheurs et des équipes de 40 à 80 agents.

Ce que chacun livre réellement

• Paramètres — AesCode 32B : environ 33,4 milliards en BF16 répartis sur quatorze shards safetensors totalisant 66 714 912 704 octets. AlphaProof Code : aucun. Il s’agit d’un framework accompagné d’un dépôt d’artefacts, et il n’y a aucun poids à télécharger.

• Base — AesCode 32B : un fine-tune de Qwen3-VL-32B-Instruct, architecture déclarée comme Qwen3VLForConditionalGeneration, il se charge donc avec transformers 4.57 et versions ultérieures. AlphaProof Code : indépendant du modèle par construction ; l’article DeepMind nomme Gemini 4 Carbon pour les agents de preuve et indique que Claude Opus 5.5 a été utilisé parmi les modèles rédigeant et révisant les spécifications.

• Licence — AesCode 32B : Apache 2.0, disponible dès aujourd’hui sur Hugging Face. AlphaProof Code : le développement Lean, la sémantique AArch64 et le binding libsignal sont publiés sur github.com/google-deepmind/code-verification, et la page d’accueil n’indique aucune licence, ce qu’il convient de clarifier avant de construire quoi que ce soit dessus.

• Disponibilité — AesCode 32B : auto-hébergement uniquement. Environ 65 Go de mémoire d'accélérateur pour les poids, une commande vLLM sur quatre rangs de parallélisme tensoriel, aucun point de terminaison hébergé et aucun mapping de fournisseur d'inférence derrière la page du dépôt. AlphaProof Code : artefact de recherche, aucun point de terminaison, aucune liste d'attente, aucun tarif.

• Sortie — AesCode 32B : un document HTML, vérifiable en l’ouvrant. AlphaProof Code : un terme de preuve Lean, vérifiable par Lean.

• Ce que signifie « correct » — AesCode 32B : la page semble correcte et les chiffres correspondent au prompt, jugé par une personne. AlphaProof Code : le théorème tient pour toutes les entrées du modèle, jugé par un noyau.

Le seul chevauchement vraiment intéressant : les deux sorties sont des artefacts.

Voici la comparaison qui vaut la peine. Les deux systèmes produisent un fichier qui survit au modèle qui l’a créé. Le HTML d’AesCode 32B est un document fini ; vous pouvez le livrer, le modifier, le comparer, et personne n’a plus besoin du modèle. La preuve Lean d’AlphaProof Code est une dérivation finie ; vous pouvez la revérifier sur un ordinateur portable en quelques minutes de calcul, et si la spécification n’a pas changé, le résultat tient toujours cinq ans plus tard.

C’est une propriété plus rare qu’il n’y paraît sur un marché plein de points de terminaison de chat. La plupart des sorties de modèles sont du texte jetable dont la valeur dépend de la disponibilité continue du modèle. Ces deux approches produisent quelque chose que vous pouvez conserver. La différence tient à ce que « conserver » vous apporte : avec AesCode, vous conservez un deck ; avec AlphaProof Code, vous conservez une garantie.

Là où l'analogie échoue, c'est sur l'auditabilité. N'importe qui peut ouvrir le HTML et voir si le titre est erroné. Presque personne ne peut ouvrir 6,5 millions de lignes de Lean et voir si le théorème dit ce que le communiqué de presse dit qu'il dit — c'est précisément pourquoi l'article de DeepMind consacre des pages à énumérer sa base de confiance, ses 37 primitives sous contrat et les propriétés qu'il ne prouve pas. L'artefact est vérifiable ; sa lecture, elle, n'est pas gratuite.

Ce que valent les nombres de chaque côté

Le chiffre phare d’AesCode 32B est un score global de 85,89, contre 81,28 pour GPT-5.5 — une mesure par Microsoft du modèle d’un concurrent, sur une grille d’évaluation rédigée par Microsoft, sur un banc d’essai conçu par Microsoft. Boundary se situe à 97,27 avec un débordement sévère sur 4,3 % des échantillons, et style à 55,99, une ligne où aucun modèle du tableau ne dépasse 60. D’après les propres compteurs du dépôt, personne en dehors de Microsoft n’avait publié de chiffre pour le modèle. Tous les chiffres ci-dessus sont déclarés par le fournisseur et non reproduits.

AlphaProof Code ne dispose d’aucun tableau de benchmarks, et ce n’est pas une lacune du rapport : c’est un autre type d’affirmation. Le résultat, c’est qu’un binaire spécifique satisfait dix théorèmes symboliques et une piste computationnelle avec une borne concrète. Vous pouvez ne pas être d’accord avec la spécification, mais vous ne pouvez pas contester le verdict du noyau sur la preuve. Les réserves comparables sont structurelles plutôt que statistiques : aucune garantie post-quantique pour le rétablissement SPQR, aucune confidentialité de la charge utile, aucune authentification du répondant sur les premiers messages non promus, une session par promotion, des longueurs de message fixes, aucun état multi-appareil. Et une borne de falsification MAC qui devient vide autour de 25 000 messages dans une seule session.

Un chiffre se transpose effectivement de manière utile. La vérification d’AlphaProof Code a pris quatre semaines là où des travaux comparables ont historiquement pris des années à des équipes d’experts, face aux références citées dans l’article lui-même, d’environ 20 années-personnes pour seL4 et d’environ 6 pour CompCert. C’est ce ratio qu’il faut retenir, et il concerne le flux de travail, non la qualité du modèle.

Lequel pouvez-vous réellement exécuter cette semaine ?

AesCode 32B : oui, si vous avez le matériel. Téléchargez les shards, servez avec vLLM sur quatre rangs, gardez les prompts sous le plafond de 24,576 jetons de la carte, et acceptez que votre étape de relecture soit un humain qui plisse les yeux devant du HTML rendu. Il ne vous dira pas si la page est correcte ; il vous dira si la page a l'air correcte.

{{1}}AlphaProof Code{{/1}} : non. Les artefacts publiés constituent un développement Lean, pas un pipeline que l’on invoque. Même les modèles qu’il contient ne sont pas le livrable — le cadre est une construction de recherche, et selon la propre formulation de DeepMind, son passage à l’échelle « nécessite des recherches continues ». CodeMender est le projet frère dédié à la réparation automatisée ; la vérification et la remédiation sont deux produits différents dans la feuille de route de ce laboratoire.

Si ce que vous voulez, c'est un modèle pour rédiger les spécifications — l'étape où des experts humains ont traduit les objectifs de sécurité de Signal en Lean et les ont examinés un par un — c'est du travail de modèle ordinaire, et Claude Opus 5.5 figure au catalogue d'OrcaRouter à 4 $ par million de tokens d'entrée et 20 $ par million de tokens de sortie, avec le prix catalogue du fournisseur répercuté à 0 % de marge. Faire tourner une boucle de rédaction de spécifications sur deux ou trois modèles et comparer leur sortie Lean est un appel de DSL de routage, pas un projet de recherche. Rien de tout cela ne vous donne une preuve ; c'est à l'étape de preuve que les six millions de lignes ont été produites.

Pourquoi l’association mérite quand même d’être publiée

Parce que « modèle de code » est devenu une catégorie sans seuil minimal. Un modèle qui rédige des diapositives et un framework qui prouve un protocole de messagerie y sont tous deux classés, et les acheteurs qui les comparent sur un classement n’apprennent rien. La question utile n’est pas de savoir lequel est meilleur — c’est de savoir quelles preuves vous obtenez pour la sortie. AesCode 32B vous fournit une page rendue et une grille d’évaluation du fournisseur. AlphaProof Code vous fournit une dérivation vérifiée par le noyau et une liste inhabituellement explicite de ce qu’il suppose. L’un des deux passe à l’échelle pour du code sur lequel vous préféreriez ne pas vous tromper, et ce n’est pas celui qui a le plus grand nombre de paramètres.

Si vous évaluez AesCode 32B pour un pipeline de conception, ce qu’il faut tester n’est pas son score global, mais son comportement aux limites — c’est dans le taux de débordement grave de 4,3 % qu’un deck devient silencieusement erroné plutôt que laid. Si vous évaluez AlphaProof Code, ce qu’il faut lire, c’est le catalogue des écarts par rapport aux spécifications dans le dépôt d’artefacts : plus de 200 entrées computationnelles et environ 35 symboliques, dont quinze sont des lacunes ou des bugs dans l’analyse Double Ratchet. Ce catalogue est le document le plus honnête de la version, car il liste tout ce que les preuves n’ont pas clos.