LLM et mathématiques : ce que GPT-5.4 Pro nous apprend sur l'automatisation de la preuve formelle

Un LLM résout un problème de mathématiques ouvert en 80 minutes

Mi-avril 2026, un fait marquant a circulé dans la communauté scientifique : le modèle GPT-5.4 Pro d'OpenAI aurait résolu le problème ouvert n°1196 de la liste d'Erdős — un problème resté sans réponse pendant des décennies — en environ 80 minutes, puis rédigé la solution sous forme de papier LaTeX en 30 minutes supplémentaires. La vérification formelle est en cours.

Le mathématicien Terence Tao, l'une des figures les plus reconnues des mathématiques contemporaines, a commenté dans le forum dédié aux problèmes d'Erdős que le modèle avait mis en lumière une connexion inédite entre l'anatomie des entiers et la théorie des processus de Markov. Kevin Barreto, qui rejoindra prochainement l'équipe AI for Science d'OpenAI, a souligné que la technique des chaînes de Markov utilisée constituait un saut créatif que les mathématiciens humains avaient manqué malgré des années de travail.

Ce cas relance le débat : les LLMs peuvent-ils découvrir de nouvelles connaissances, ou se contentent-ils de recomposer ce qu'ils ont ingéré ? La réponse semble être que de nouvelles connexions peuvent être cachées dans des données déjà connues. Pour les développeurs, cela ouvre une question très concrète : comment exploiter ce type de raisonnement dans un workflow reproductible ?

Mini-playbook : structurer un pipeline LLM → preuve formelle

1. Capturer les prompts et les paramètres

La reproductibilité commence avant l'appel API. Chaque expérience doit être traitée comme un test unitaire : versionnée, documentée, rejouable.

{
  "model": "gpt-5.4-pro",
  "temperature": 0.2,
  "max_tokens": 4096,
  "prompt_version": "v1.3",
  "timestamp": "2026-04-15T10:32:00Z",
  "problem_id": "erdos-1196"
}

• Stockez vos prompts dans un dépôt Git (un fichier .txt ou .md par prompt).
• Utilisez des températures basses (0.0–0.3) pour les tâches de raisonnement logique.
• Loggez systématiquement le hash du prompt, la version du modèle et les paramètres d'inférence.
• En n8n ou tout orchestrateur, ajoutez un nœud de journalisation avant et après chaque appel LLM.

2. Exporter les sorties en LaTeX et les valider syntaxiquement

GPT-5.4 Pro a produit un papier LaTeX directement. C'est un format idéal : structuré, diffable, vérifiable. Dans votre POC :

# Vérification syntaxique basique
pdflatex --interaction=nonstopmode output.tex

# Ou avec un linter dédié
chktex output.tex

• Demandez explicitement au modèle de produire du LaTeX balisé (\begin{proof}, \begin{theorem}, etc.).
• Parsez la réponse pour extraire les blocs LaTeX et validez-les avant de les stocker.
• Un script Python avec subprocess + pdflatex suffit pour un pipeline CI simple.

3. Enchaîner avec la vérification formelle (Coq / Lean) ou des tests automatisés

C'est l'étape clé pour dépasser le stade du "ça a l'air juste". Deux approches selon votre contexte :

Pour les preuves mathématiques : Lean 4 est aujourd'hui le standard émergent pour la vérification formelle assistée par LLM. Des projets comme LeanDojo permettent d'interfacer directement un LLM avec un proof assistant.

-- Exemple de structure cible dans Lean 4
theorem my_result (n : ℕ) : P n := by
  -- L'output du LLM vient alimenter ce bloc
  sorry -- à remplacer par la preuve générée

Pour les algorithmes et le code applicatif : traitez la sortie comme vous traiteriez du code généré — avec une suite de tests automatisés.

// PHPUnit : valider le résultat d'un algorithme généré par LLM
public function testGeneratedAlgorithm(): void
{
    $result = $this->generatedSolver->solve($inputFixture);
    $this->assertEquals($expectedOutput, $result);
    $this->assertLessThan(1.0, $result->computationTime);
}

Les pièges à éviter absolument

Hallucinations mathématiques

Les LLMs peuvent produire des preuves syntaxiquement correctes mais logiquement fausses. Ne faites jamais confiance à un résultat sans vérification indépendante. Dans le cas Erdős, la communauté attend la vérification formelle avant de valider — adoptez le même réflexe.

Contre-mesure : demandez au modèle de générer plusieurs chemins de preuve distincts (n=3 variations) et comparez-les. Une divergence entre les variantes est un signal d'alerte.

Le problème de reproductibilité

Même avec temperature=0, les LLMs hébergés ne sont pas déterministes à 100% (batching, mises à jour silencieuses du modèle). Pour un POC sérieux :

• Fixez la version exacte du modèle (pas juste gpt-5.4-pro, mais son snapshot daté si l'API le permet).
• Sauvegardez l'intégralité de la réponse brute, pas seulement votre interprétation.
• Rejouez le même prompt 3 fois et vérifiez la stabilité des conclusions.

L'effet "impressive demo"

Un LLM peut sembler résoudre un problème tout en paraphrasant une solution existante présente dans ses données d'entraînement. Dans le cas présent, la nouveauté alléguée (la connexion via les chaînes de Markov) est précisément ce que la vérification formelle doit confirmer.

Monter un POC en un sprint : checklist

Voici une séquence réaliste sur 5 jours pour un développeur solo ou une petite équipe :

L'objectif n'est pas d'avoir un produit fini, mais de délimiter honnêtement le périmètre de fiabilité du LLM sur votre cas d'usage.

Conclusion

La résolution alléguée du problème d'Erdős #1196 par GPT-5.4 Pro est un signal fort, mais ce qui importe pour un développeur n'est pas l'exploit en lui-même — c'est la méthode. Capturer rigoureusement les paramètres, produire des sorties vérifiables (LaTeX, JSON, code), et systématiquement enchaîner avec une couche de validation : voilà ce qui transforme une démonstration impressionnante en un outil de travail crédible.

Les LLMs ne remplacent pas la rigueur d'ingénierie. Ils l'amplifient — à condition que vous l'appliquiez en amont.

Source originale : The Decoder, 15 avril 2026