Vous dites “crée-moi ce logiciel” sans préciser la technologie : 25 IA ont tendance à choisir Python beaucoup trop souvent

Demandez simplement à une IA de « créer cette application » et elle risque de choisir Python avant même d’avoir examiné la plateforme, la latence, le déploiement ou la maintenance. LangChoiceBench a soumis 28 projets à 25 modèles : en moyenne, ils ont produit une solution Python dans 35,3 % des cas, alors qu’ils ne recommandaient explicitement ce langage que dans 10,7 % des réponses.

Le problème n’est pas Python. C’est un excellent choix pour l’automatisation, la donnée, l’IA, les scripts et de nombreuses API. Le problème apparaît lorsqu’un agent utilise le langage qu’il connaît le mieux pour une extension Chrome, une application mobile native, un système embarqué ou un service à très faible latence sans comparer les contraintes du projet.

LangChoiceBench ne demande pas « quel langage préférez-vous ? »

Les auteurs de LangChoiceBench, publié le 6 août 2026, ont construit des tâches où le choix de la technologie compte réellement. Le corpus rassemble 28 projets répartis entre systèmes embarqués, logiciels d’entreprise, frontend, jeux, applications à faible latence, mobile et systèmes.

Ces projets ont été sélectionnés volontairement parce que Python y constitue souvent un mauvais choix par défaut. Cette précision est essentielle : le benchmark ne mesure pas la fréquence idéale de Python dans l’ensemble des logiciels du monde. Il cherche à savoir si un modèle sait résister à son réflexe favori lorsque la plateforme ou les performances suggèrent autre chose.

Un modèle reçoit une description de projet sans langage imposé. Les chercheurs observent ensuite deux décisions :

1. le langage que le modèle recommande lorsqu’il explicite son choix ;
2. le langage qu’il utilise réellement dans les fichiers produits.

Cette séparation révèle un défaut difficile à voir dans une simple démonstration. Une IA peut expliquer que TypeScript convient mieux à une extension Chrome, puis livrer malgré tout un script Python. Une réponse verbalement raisonnable ne garantit donc pas une architecture cohérente.

25 IA choisissent Python bien plus souvent qu’elles ne le recommandent

Sur l’ensemble du benchmark, le taux moyen de recommandation de Python atteint 10,7 %. Le taux d’implémentation grimpe pourtant à 35,3 %. La cohérence moyenne entre recommandation et implémentation n’est que de 48,8 %.

Plusieurs petits modèles ouverts sur-sélectionnent particulièrement Python, mais le phénomène n’est pas limité à une seule famille. Les écarts montrent aussi pourquoi la phrase « les IA choisissent toujours Python » serait fausse : certains modèles résistent nettement mieux que d’autres au défaut étudié.

Le résultat le plus gênant reste la discordance. Si le modèle identifie correctement une technologie puis code dans une autre, le problème ne vient plus seulement d’un manque de connaissance. Il peut venir de la facilité de génération, de ses habitudes d’entraînement ou d’une incapacité à maintenir sa décision pendant l’exécution.

Ce que révèlent 9 826 traces de raisonnement

Les chercheurs ont analysé 9 826 traces associées à des implémentations Python, provenant des 15 modèles qui rendaient ce type de trace accessible. Un modèle juge a classé les justifications en quatre familles. Ce juge avait auparavant été comparé à une évaluation humaine, avec 96 % d’exactitude et un coefficient kappa de Cohen de 0,93.

La « phantom evidence » est plus dangereuse qu’une mauvaise intuition

Une IA peut affirmer que le projet exige une bibliothèque Python particulière, que l’équipe maîtrise déjà Python ou que le prototype doit être livré sous forme de script, alors que la consigne n’a fourni aucune de ces informations. Elle ne se contente plus de prendre un raccourci : elle fabrique une preuve qui rend ce raccourci crédible.

Cette justification a posteriori peut tromper un utilisateur non spécialiste. Un choix arbitraire prend l’apparence d’une décision d’architecture. Plus l’explication est fluide, plus il devient difficile de remarquer que la contrainte invoquée n’existe pas.

Le bon réflexe consiste à demander au modèle de séparer trois colonnes : faits fournis, hypothèses à valider et conséquences techniques. Une hypothèse ne doit jamais être transformée silencieusement en exigence.

Pourquoi Python devient-il le choix automatique du vibe coding ?

Python possède plusieurs avantages qui le rendent très attractif pour un modèle génératif :

• une syntaxe concise, donc moins de code à produire ;
• un immense volume d’exemples publics et de questions résolues ;
• des bibliothèques disponibles pour presque tous les prototypes ;
• un démarrage rapide sans structure de projet très lourde ;
• des environnements d’exécution fréquemment utilisés dans les outils d’IA.

Ces qualités sont idéales pour une démonstration. Elles peuvent devenir un piège lorsqu’un prototype est confondu avec le produit final. Un petit script qui prouve une idée ne répond pas forcément aux besoins d’une application installable, d’un navigateur, d’une console de jeu, d’un microcontrôleur ou d’un service soumis à une latence stricte.

Le développement en langage naturel, souvent appelé vibe coding, accélère la création mais ne supprime pas le choix de la stack. Il déplace simplement ce choix vers le début de la conversation, à un moment où l’utilisateur doit expliciter les contraintes que le modèle serait tenté d’inventer.

Dix projets à ne jamais confier avec le seul prompt « construis-le »

Voici un protocole reproductible pour tester un builder ou un agent. La colonne « questions à trancher » ne donne pas un langage gagnant universel ; elle montre les informations à obtenir avant le code.

Le prompt qui force l’IA à choisir l’architecture avant de coder

LangChoiceBench n’a pas testé l’intervention suivante. Il s’agit donc d’une méthode pratique proposée pour vos projets, pas d’un résultat démontré par l’étude.

Ne code rien pour le moment.

1. Liste les contraintes explicitement fournies.
2. Liste les informations manquantes qui peuvent changer la stack.
3. Compare trois architectures réellement différentes.
4. Pour chacune, évalue : compatibilité avec la plateforme,
   performance, déploiement, sécurité, maintenance,
   recrutement et coût d’exploitation.
5. Recommande une stack et indique les hypothèses utilisées.
6. Attends ma validation avant de créer les fichiers.

Après validation, rappelle la stack approuvée au début du plan
et signale toute modification avant de l’appliquer.

Cette consigne crée un point d’arrêt entre la recommandation et l’implémentation. Elle empêche aussi l’agent de changer silencieusement de langage au milieu du travail. Avec un agent de programmation comme ChatGPT Codex, ajoutez ces décisions dans les instructions persistantes du dépôt et contrôlez le premier lot de fichiers avant d’autoriser la suite.

Ajoutez des critères mesurables

« Une application rapide » ne suffit pas. Donnez des seuils :

• temps de démarrage inférieur à deux secondes ;
• P95 de l’API inférieur à 100 millisecondes sous 500 requêtes par seconde ;
• paquet desktop inférieur à 100 Mo ;
• fonctionnement hors ligne pendant huit heures ;
• déploiement par une équipe de deux personnes ;
• support de Windows et macOS pendant trois ans.

Le modèle peut alors comparer des compromis observables. Sans seuil, « performance », « simplicité » et « maintenabilité » restent des mots que l’IA peut interpréter dans le sens de son choix initial.

Comment vérifier que le code respecte la recommandation

1. Inspectez l’arborescence. Les extensions, fichiers de configuration et gestionnaires de dépendances révèlent immédiatement la stack réelle.
2. Relisez le plan d’exécution. Une application navigateur qui nécessite soudain un serveur local doit expliquer pourquoi.
3. Exigez une matrice de traçabilité. Chaque contrainte importante doit pointer vers un composant, un test ou une décision.
4. Lancez un test minimal de la plateforme cible. Construire, installer et démarrer sur le vrai environnement vaut mieux qu’une longue explication.
5. Demandez un contre-avis sans montrer le choix initial. Un second passage peut comparer le dépôt produit aux contraintes, sans être ancré par la première recommandation.

Vous pouvez aussi automatiser une règle simple dans la revue : si le langage majoritaire des fichiers ne correspond pas à la décision validée, le travail s’arrête jusqu’à ce que l’écart soit expliqué. Cette règle ne bloque pas les projets polyglottes ; elle rend seulement les changements visibles.

Quand Python reste précisément le bon choix

Réagir à LangChoiceBench en interdisant Python reproduirait l’erreur du benchmark sous une autre forme. Python reste souvent excellent pour :

• l’analyse de données, les notebooks et les pipelines scientifiques ;
• les outils internes et automatisations à durée de vie maîtrisée ;
• les prototypes d’IA et de machine learning ;
• les API dont la charge, la latence et l’exploitation sont compatibles avec son écosystème ;
• les équipes qui disposent déjà de compétences, de bibliothèques et d’une plateforme Python fiables.

Le bon choix n’est pas le langage théoriquement le plus rapide. C’est celui qui satisfait les contraintes du produit avec un coût de construction et d’exploitation acceptable. Une stack familière et bien maîtrisée peut battre une solution plus performante sur le papier mais impossible à maintenir par l’équipe.

Ce que l’étude ne permet pas de conclure

LangChoiceBench apporte un signal fort, mais ses limites évitent plusieurs raccourcis :

• les 28 tâches ont été choisies parce que Python y est souvent peu adapté ; le taux de 35,3 % ne représente pas tous les projets logiciels ;
• le benchmark évalue le choix du langage, pas la correction complète, la sécurité ou la qualité à long terme du produit ;
• les prompts directs ne reproduisent pas tous les workflows d’agents, builders et équipes humaines ;
• l’analyse des raisonnements concerne 15 modèles qui exposaient des traces, pas les 25 ;
• les 9 826 traces étudiées sont celles des implémentations Python, pas l’ensemble de toutes les décisions ;
• l’étude ne teste pas notre prompt « architecture d’abord » et ne prouve donc pas qu’il corrige quantitativement le biais.

La conclusion solide est plus étroite : dans ce protocole conçu pour challenger le défaut Python, plusieurs modèles utilisent ce langage bien plus souvent qu’ils ne le recommandent, et une partie des justifications s’appuie sur une facilité implicite ou sur des éléments de contexte inventés.

Le vibe coding ne dispense pas de choisir une stack

Une IA peut écrire dix fichiers avant qu’un humain ait terminé de comparer trois architectures. Cette vitesse rend la première décision encore plus importante : une mauvaise stack génère rapidement davantage de code, de dépendances et de coûts de migration.

Avant « crée-moi ce logiciel », ajoutez donc une étape : « recommande l’architecture, sépare les faits des hypothèses et attends ma validation ». Puis vérifiez que les fichiers livrés correspondent réellement à cette décision. Le gain ne vient pas d’une interdiction de Python, mais de la disparition du choix automatique.

Questions fréquentes sur LangChoiceBench

LangChoiceBench prouve-t-il que Python est un mauvais langage ?

Non. Le benchmark sélectionne volontairement des projets où Python est souvent un mauvais choix par défaut. Il évalue la capacité des modèles à adapter leur décision, pas la valeur générale du langage.

Les 25 modèles choisissent-ils tous Python dans 35,3 % des cas ?

Non. 35,3 % est une moyenne. Les taux rapportés varient fortement, de 9,5 % pour Kimi K2.6 à 66,5 % pour Nemotron 7B parmi les exemples cités.

Qu’est-ce que la « phantom evidence » ?

C’est une justification qui s’appuie sur un fait absent de la consigne : une prétendue compétence de l’équipe, une bibliothèque obligatoire ou une contrainte de prototype inventée pour soutenir le choix effectué.

Demander trois architectures suffit-il ?

Non, mais cela ralentit le choix automatique. Ajoutez des contraintes mesurables, validez explicitement une option puis contrôlez que le dépôt utilise réellement la stack approuvée.

Faut-il toujours empêcher l’IA de choisir la technologie ?

Pas nécessairement. Elle peut proposer et comparer. La décision doit toutefois rester vérifiable, fondée sur les contraintes du produit et approuvée avant que la génération massive de code rende le changement coûteux.

Sources principales : article scientifique LangChoiceBench et dépôt de recherche associé, consultés le 19 août 2026.