Préambule

La question du vibe-coding pose d'emblée plusieurs problèmes éthiques qu'il n'est plus nécessaires de répéter en détails ; rappelons simplement de manière très superficielle que les impacts écologiques, sociaux et épistémiques sont tous et chacun suffisant pour indépendamment mériter un moratoire quant au développement de nouveaux modèles, à la construction de centre de données, et à l'utilisation des LLMs dans plusieurs contextes. La présente proposition cherche à diminuer les risques épistémiques liés au VC, tant d'un point de vue pédagogique que de celui associé à la perte de contrôle sur le code généré par des grands modèles de langue. D'un point de vue pratique, si vous êtes en mesure d'utiliser des petits modèles qui tournent en local, je vous encourage fortement à le faire. C'est une solution imparfaite (leur entraînement reste coûteux et polluants), mais c'est un bon moyen pour mitiger plusieurs autres aspects problématiques des LLMs.

À la recherche de la valeur symbolique

Dans son billet de blog du 15 avril 2026, Marcello Vitali-Rosati posait la question du rapport entre le travail que l’on attribue aux humains, et celui que l’on attribue aux machines. Il mentionne que pour commencer, la distinction humain-machine est “très mal posée” et “qu’elle représente un faux problème et qu’elle devrait être analysée autrement. Toutes nos pratiques sont technologiques […] la pensée est toujours déjà technique” (voir Vibecoding? Quelques réflexions préliminaires). Ce constat l'amène à poser une question centrale des humanités numériques : à quelles tâches donnons-nous, implicitement ou explicitement, de la valeur symbolique en l'attribuant à ceux et celles dont le temps "vaut" le plus? En programmation en particulier, plusieurs tâches perdent de leur valeur simplement parce qu'elles ont déjà été accomplie¹, et parce qu'elles sont de bas niveau, donc faisables par n'importe qui.

Dans la conception d'un objet numérique ; un site web, une application, une expérience computationnelle, où trouve-t-on cette valeur symbolique? Silicone Valley nous dit que c'est l'idée qui importe le plus, une vision de la programmation qui est facilitée par les pratiques de vibecoding : on demande presque systématiquement au modèle de créer un code qui mènera à un certain résultat. "Crée un site web statique pour mon blog rétro." "Une fonction qui prend en entrant deux strings et retourne le nombre de mot en commun divisé par la longueur moyenne." "Trouve l'erreur dans mon code." Ces pratiques font de l'utilisateur·rice---du videcodeur·euse---un·e directeur·rice qui assume que l'organisation qu'iel dirige saura transformer une vision (aussi floue soit-elle) en résultat. La posture n'en est pas une de recherche, mais de production : tant que ça fonctionne et me donne ce que je veux, tout va bien.

Toutefois, je ne crois pas que le locus de la programmation soit l'idée, et bien que les affordances des LLMs puissent servir cette vision, elles permettent aussi une autre approche qui met de l'avant ce que je considère comme ayant le plus de valeur symbolique en programmation¹, soit la modélisation.

Modélisation en syntaxe

Je vois l'acte de programmation comme la combinaison de deux activités, la modélisation et la syntaxe. La syntaxe permet de faire le pont entre la modélisation et l'ordinateur alors que la modélisation est elle-même un pont entre les langages naturels et formels. La syntaxe varie grandement d'un langage de programmation à l'autre avec différents degrés d'abstraction et de contrôle, mais à partir d'un certain point, les langages de haut niveau (ceux que je connais du moins) ont des affordances similaires, c'est-à-dire qu'il est possible d'écrire une même fonction dans plusieurs syntaxes différentes sans la dénaturer.

Par exemple, dans le cadre de mon cours d’astrophysique stellaire, je modélisais des étoiles en utilisant Maple—un logiciel canadien concurrent à Matlab—alors que certains de mes collègues codaient en R en python et même en fortran! Si chacun de ces langages offre des possibilités (et des limites) différentes qui modifient grandement le travail nécessaire à modéliser une étoile—Maple n’est pas recommandé pour les simulations de polytropes, mais permet de résoudre des équations différentielles très facilement—nous avons quand même tou·tes réussi à accomplir la tâche! Une même logique pouvait être implémentée dans différentes syntaxes, et même si d’autres étudiant·es avaient eu l'idée (peu judicieuse) d'utiliser Maple, nos solutions auraient été différentes les unes des autres. Il existe donc une certaine déconnection entre les modèles et la syntaxe, quoique, comme dans le cas du langage, certaines idées soient plus faciles à dire ou à penser dans un langage plutôt qu’un autre².

Ne m'éviscérez pas ami·es programmeur·euses ; je sais bien que la connaissance de la syntaxe est nécessaire au bon travail en informatique. Quand je décris l'acte de programmation comme la rencontre entre la modélisation et la syntaxe pour établir une hiérarchie, je le fais en tant que physicien de formation ou en tant qu'humaniste. Je sais bien que la magie s'opère quand la syntaxe et la modélisation sont en parfait accord après de longues nuits de conflit. Mon point je l'avance dans le contexte du vibecoding qui semble promouvoir des pratiques dans lesquelles l'utilisateur·rice ne se soucie ni des modèles, ni du langage de programmation. C'est dans le cadre de cette discussion qu'il me semble important de placer la valeur symbolique dans la conceptualisation : d'abord parce qu'elle est centrale dans la recherche ; et ensuite parce qu'elle est plus difficile à acquérir que la syntaxe (du moins, avec les langages de programmation les plus utilisés). En d'autres mots, mon argument est situé, et (relativement) informé par mes expériences (limitées) d'enseignement des langages de programmation : les étudiant·es en littérature sont tout à fait capables d'apprendre la syntaxe par eu·lles-mêmes. Iels n'ont besoin que de bases syntaxiques très simples et d'un peu d'aide quant à l'utilisation de la documentation et à la lecture d'erreurs ; le reste se fait en autodidacte, et ce bien mieux que la modélisation.

Ma relation à la programmation

Une part importante de mon parcours de programmeur s'est centrée autour de la joie d'apprendre la syntaxe des langages de programmation, ce qui signifie chercher, échouer, lutter pour enfin (parfois) réussir. Ainsi, j'ai eu le plaisir de reproduire ce que nous connaissons aujourd'hui comme le T-rex Game de Google dans Pygame, d'inventer des algorithmes de tri peu efficaces, et de modéliser des systèmes planétaires. Il y a la programmation pour s'amuser, la programmation pour apprendre, et puis il y a le travail, et le travail est toujours trop important pour être laissé aux LLMs, mais trop urgent pour ne pas les utiliser. Le fait est que ma faiblesse de programmeur, c'est la syntaxe, et que ce que je considère le moins important dans la programmation, c'est aussi la syntaxe. Lorsque le temps manque et que je n'ai aucun plaisir à échouer trente fois à quelque chose que je comprends parfaitement conceptuellement, mais dont la syntaxe m'échappe. Dans ce genre de cas, presque systématiquement, je suis devant un programme dont la logique est bonne. Puisque c'est dans l'acte de modélisation que je place la valeur symbolique, ce travail a déjà été fait, parfois sous la forme de schéma, parfois sous la forme de pseudocode. Alors comment régler un problème de syntaxe tout en gardant ma logique intacte? Comment vibecoder sans perdre le contrôle? Sans crainte qu'un plus petit modèle (celui-là même dont l'entraînement a grandement pollué, mais qui peut maintenant rouler en local) n'hallucine³ ou ne se perde?

La solution se trouve dans le titre : lorsque la syntaxe m'échappe, je convertis du pseudocode.

Ma pratique de vibecodeur : un exemple

Dans l'exemple suivant, je souhaite récupérer tous les fichiers avec une extension .txt dans un dossier base_path = "novel", puis séparer le texte du YAML et passer ce dernier dans une fonction create_metadata que j'ai déjà déclarée. Ces métadonnées, ainsi que le texte et un modèle spacy devront être donnés à une boucle qui créera un objet Paragraph par paragraphe. L'exemple suivant ressemble au type de pseudocode que j'écris aujourd'hui (remarquez que j'utilise déjà la syntaxe de python et que je demande d'utiliser certaines bibliothèque avec lesquelles je suis déjà familier) :

import os
import spacy
if spacy_english_model not downloaded:
    download spacy_english_model
model = spacy.load(spacy_english_model)
base_path = "novels"
paths = os.find_all_files(base_path, extension = ".txt")
list_of_paragraphs = []
for path in paths:
    open and read file 
    metadata = file[first instance of "---" : second instance of "---"]
    text = file - metadata
    metadata_json = create_metadate(metadata)
    paragraphs = split file per paragraph
    for paragraph in paragraphs:
        list_of_paragraphs.append(Paragraph(paragraph, metadata_json, model))

Le prompt utilisé dans ce cas est "Translate the following pseudocode in python. Keep the syntax as simple as possible, follow my naming convention, and avoid adding anything." Voici le résultat (avec Claude Opus 3) :

import os
import spacy

if not spacy.util.is_package("en_core_web_sm"):
    spacy.cli.download("en_core_web_sm")

model = spacy.load("en_core_web_sm")
base_path = "novels"
paths = [os.path.join(base_path, file) for file in os.listdir(base_path) if file.endswith(".txt")]
list_of_paragraphs = []

for path in paths:
    with open(path, "r") as file:
        content = file.read()
        start_meta = content.find("---")
        end_meta = content.find("---", start_meta + 1)
        metadata = content[start_meta:end_meta]
        text = content[:start_meta] + content[end_meta:]
        metadata_json = create_metadata(metadata)
        paragraphs = text.split("\n\n")
        for paragraph in paragraphs:
            list_of_paragraphs.append(Paragraph(paragraph, metadata_json, model))

Le résultat final avec Opus 3 a une erreur que les modèles plus récents évitent : la seconde instance de --- qui indique la fin des métadonnées est considérée comme faisant partie du texte, il suffit de modifier la ligne text = content[:start_meta] + content[end_meta:] en y ajoutant +3 : text = content[:start_meta] + content[end_meta+3:]. Opus 3 a été utilisé parce qu'il est facilement accessible, mais il reste plus gourmand qu'une instance de Qwen en local.

Un autre exemple

Le cas suivant est plus proche de ce qu'un débutant serait à même de faire en pseudocode :

• Pour chaque sous dossier dans le dossier "novels", trouve tous les fichiers terminant en .txt et crée une liste de tous ces fichiers.
• Pour chacun de ces fichiers, trouve la section de métadonnées qui commence à la première ligne par "---" et termine à la prochaine ligne qui commence à "---". Les métadonnées vont dans une première variable, le texte (tout ce qui est après le YAML) va dans une seconde variable.
• Sépare les textes à chaque instance d'un ou plusieurs sauts à la ligne pour en faire des paragraphes. Enregistre chaque paragraphe à part dans un objet qui a le texte du paragraphe et les métadonnées.
• Place chaque objet paragraphe dans une liste de tous les objets paragraphes.

Le résultat (toujours avec Claude Opus 3) :

import os

liste_objets_paragraphes = []

for sous_dossier in os.listdir("novels"):
    chemin_sous_dossier = os.path.join("novels", sous_dossier)
    liste_fichiers_txt = [f for f in os.listdir(chemin_sous_dossier) if f.endswith(".txt")]
    
    for fichier_txt in liste_fichiers_txt:
        chemin_fichier = os.path.join(chemin_sous_dossier, fichier_txt)
        
        with open(chemin_fichier, "r") as f:
            contenu = f.read()
        
        sections = contenu.split("---")
        metadonnees = sections[1].strip()
        texte = "---".join(sections[2:]).strip()
        
        paragraphes = texte.split("\n\n")
        
        for paragraphe in paragraphes:
            objet_paragraphe = {
                "texte": paragraphe,
                "metadonnees": metadonnees
            }
            liste_objets_paragraphes.append(objet_paragraphe)

Cette approche en langage naturel est la base de la modélisation, et exactement ce que j'encourageais les étudiant·es de mon atelier de programmation à faire. Ce code invoque la notion d'objet alors qu'il utilise des dictionnaires (un type de données dont la syntaxe est compatible avec JSON), mais outre ce point il est tout à fait utilisable et suit la logique du pseudocode à la lettre.

En guise de conclusion

La syntaxe viendra, mais la logique et la modélisation sont primordiales.

La traduction de pseudocode me semble être l'approche la moins problématique au vibecoding (en tenant compte du cours préambule de ce texte, toute utilisation des LLMs est problématique, mais bon... il n'y a pas de consommation éthique sous le capitalisme). Si la syntaxe est importante (et elle l'est), commencer par l'apprentissage du pseudocode l'est sans doute plus, et est maintenant suffisante pour commencer à interagir avec la machine. Toutefois, cette méthode appliquée sans volonté d'apprendre et sans curiosité ne saurait être qu'une perte de temps, mais alors tout n'est que perte de temps sans curiosité. Cela étant dit, la pratique décrite dans la dernière section offre des avantages importants lorsqu'elle est comparée à l'utilisation des LLMs pour effectuer un projet à partir de l'énonciation d'un but. La conversion de pseudocode place l'acte de modélisation entre les mains des chercheur·euses et des étudiant·es : c'est à la fois une avenue qui est plus saine d'un point de vue épistémique et plus pertinente dans un cadre pédagogique.