Le déterminisme n'est pas qu'un argument marketing

Le principe : correction par construction, pas correction après coup

En informatique, on distingue depuis longtemps deux familles de génération de programme : celle où la correction est démontrée par la structure même du système (correction par construction), et celle où elle est estimée statistiquement sur un échantillon de sorties (génération probabiliste). Une revue comparative récente formalise cette distinction et situe les deux paradigmes sur un même axe, du plus vérifiable au plus flexible.

Un exemple concret de la première famille, appliqué à un tout autre domaine que la génération d'applications métier : Veritas (2025), un pipeline de synthèse de circuits où un LLM compact conçoit une spécification logique, qu'un traducteur déterministe transforme ensuite en code Verilog. Résultat mesuré : 100 % de réussite au premier essai, garantie par construction plutôt que par test a posteriori.

• From Provable Correctness to Probabilistic Generation: A Comparative Review of Program Synthesis Paradigms : arxiv.org/pdf/2508.00013
• Veritas — correction par construction en synthèse de circuits : emergentmind.com/topics/llm-synthesized-code

« Compiler » plutôt que « générer » : une IA qui s'arrête avant le code

Un article de 2026 décrit un paradigme baptisé « Compiled AI » : les modèles de langage produisent des artefacts de code exécutables durant une phase de compilation, après laquelle les workflows s'exécutent de façon déterministe, sans nouvel appel au modèle. C'est une reformulation académique du principe déjà en œuvre chez Blueprint Maker — une IA conçoit, un moteur déterministe construit — appliquée ici à l'automatisation de workflows plutôt qu'à des applications de gestion complètes.

• Compiled AI: Deterministic Code Generation for LLM-Based Workflow Automation (2026) : arxiv.org/html/2604.05150

Le non-déterminisme des générateurs classiques : mesuré, pas supposé

L'étude de référence sur le sujet, publiée dans ACM Transactions on Software Engineering and Methodology, a soumis ChatGPT à 829 problèmes de code, avec cinq générations indépendantes par problème, comparées sur leur similarité sémantique, syntaxique et structurelle. Résultat : une variabilité significative du code produit pour un prompt identique — et un angle mort du champ académique lui-même, puisque seulement 21,1 % des études sur la génération de code par IA prennent en compte ce risque dans leur protocole.

Ce non-déterminisme n'est pas qu'un effet de la température du modèle : des travaux plus récents identifient des sources numériques additionnelles (traitement par lots, arrondis en virgule flottante) qui subsistent même à température nulle. Réduire le hasard reste possible ; l'éliminer à l'étape où un modèle de langage écrit le code ligne à ligne ne l'est pas.

• An Empirical Study of the Non-determinism of ChatGPT in Code Generation (ACM TOSEM) : dl.acm.org/doi/10.1145/3697010
• Understanding and Mitigating Numerical Sources of Nondeterminism in LLM Inference : arxiv.org/pdf/2506.09501

Formaliser la spécification avant le code : une direction de recherche active

Plusieurs travaux récents proposent de faire précéder la génération de code d'une étape explicite de formalisation des exigences — exactement le rôle que joue l'AppSpec chez Blueprint Maker. Un protocole d'étude empirique sur la génération de code pilotée par spécification a été accepté à SANER 2026, une conférence reconnue en génie logiciel ; un autre travail propose une vision multi-agents pour développer et formaliser les exigences avant de générer.

• Understanding Specification-Driven Code Generation with LLMs (Registered Report, SANER 2026) : arxiv.org/html/2601.03878v1
• Requirements Development and Formalization for Reliable Code Generation: A Multi-Agent Vision (2025) : arxiv.org/pdf/2508.18675

Ce que Blueprint Maker en tire

Blueprint Maker applique le même principe — spécification conçue par une IA, code produit par un traducteur déterministe — à un domaine différent de ceux étudiés dans ces travaux : les applications métier complètes (base de données, API, interface, tableau de bord), plutôt que les circuits logiques ou les workflows d'automatisation. Le mécanisme est le même ; le champ d'application diffère.

Rien ici n'est présenté comme une preuve que Blueprint Maker est infaillible : la recherche cite des gains mesurés sur des tâches précises, pas une garantie universelle. Ce qu'elle établit, c'est que séparer spécification et code n'est pas un choix marketing isolé — c'est une direction de recherche prise au sérieux, avec des résultats publiés et évalués par les pairs.