Pourquoi un prompt ne peut jamais être testé comme un programme. Démonstration avec 15 lignes de Python, 200 graines aléatoires, et un verrou logique invisible à la lecture.
Le mythe du « prompt bien écrit vaut un programme »
On répète depuis deux ans qu'un prompt bien écrit vaut un programme. Pourtant il existe une propriété que le code possède et que le prompt n'aura jamais : la capacité de vous donner tort.
Voici une démonstration concrète, avec 15 lignes de Python et une simulation de population d'agents.
L'expérience : 15 lignes de code, une population d'agents
Le scénario est simple : chaque agent gagne un peu d'énergie à chaque cycle, devient mature au-delà d'un certain seuil, et se reproduit tant qu'il n'est pas mature et qu'il dispose d'assez d'énergie.
Une description exacte, fidèle au code — et pourtant totalement muette sur ce qui va réellement se produire.
Les résultats sur 200 graines aléatoires
L'exécution du programme sur 200 graines aléatoires donne trois issues, et rien entre les deux :
- Population finale = 1 → 22 % des graines
- Population finale = 2 à 5 → 8,5 % des graines
- Population finale = 5000 (plafond) → 69,5 % des graines
Aucune valeur intermédiaire sur deux cents essais. Le programme n'a pas de comportement moyen. Il a deux issues, et le sort se joue dès le premier cycle.
Pourquoi ce résultat est impossible à prédire à la lecture
Les paramètres initiaux sont les suivants :
- Énergie de départ : 0,50
- Seuil de maturité : 0,55
- Incrément par cycle : tiré aléatoirement dans [−0,05 ; +0,08]
Si le tout premier tirage dépasse +0,05, l'agent devient mature avant même d'avoir pu se reproduire — or la reproduction exige justement de ne pas être mature. Résultat : cet agent ne se reproduira jamais.
Le calcul qui confirme l'intuition
La probabilité théorique de ce verrou logique se calcule ainsi :
(0,08 − 0,05) / 0,13 = 23,08 %
La fraction réellement mesurée sur les 200 graines : 22,0 %.
Deux seuils écrits à trois lignes d'écart, qui semblent indépendants, et dont l'un annule silencieusement l'autre pour près d'un quart des cas. Ce n'est pas un bug exotique : c'est un simple ordre d'exécution.
Personne ne prédit ce comportement en lisant le code — pas même son auteur. Le premier essai a produit une explosion mémoire, obligeant à recalibrer les paramètres. Le code a refusé de coopérer deux fois avant de livrer un résultat exploitable.
La différence fondamentale entre code et prompt
Un programme possède :
- une valeur de retour
- un état final mesurable
- une assertion qui peut échouer
Autant d'endroits où le monde peut répondre autre chose que ce qui était prévu.
Un prompt, lui, n'a rien de tout cela. Sa sortie est du texte, jugé par un humain — le même humain qui a écrit l'intention de départ. La boucle d'évaluation est fermée sur elle-même.
L'asymétrie que personne ne mentionne
Voici le point central : on évalue un prompt en écrivant du code.
Benchmarks, jeux d'évaluation, tests A/B — tout l'appareil qui permet d'affirmer qu'un prompt « fonctionne » est lui-même construit à partir de programmes.
L'inverse n'existe pas. On n'a jamais validé un programme en écrivant un prompt.
Architecture ou simple intention bien formulée ?
Beaucoup de systèmes présentés aujourd'hui comme des architectures d'intelligence artificielle sont en réalité des intentions bien formulées, auxquelles personne n'a encore donné l'occasion de dire non. Ils produisent des sorties plausibles — ce qui n'est pas la même chose que de pouvoir démontrer qu'ils fonctionnent réellement.
Le test en une seule question
Qu'est-ce qui, dans ce que vous avez construit, aurait pu vous donner tort ?
Si la réponse est « rien », vous n'avez pas encore d'ingénierie. Vous avez une description.
Testez-le vous-même
Le code source des 15 lignes est disponible en commentaire du post original. Copiez-le, exécutez-le, et vérifiez si vous obtenez les mêmes proportions.
Alain Valette-Clary — ΩiA-Group