Penser son application

Le prompt est le nouveau style :
Pourquoi les littéraires reprennent le pouvoir

La matière première du vibe coding n'est pas du code. C'est du langage.

Jean-Philippe Sportich
Auteur · Mai 2026
TL;DR — EN 30 SECONDES

Cet article répond à la question : “Pourquoi les littéraires reprennent-ils le pouvoir avec le vibe coding ?”

  • Le nouveau profil type : en 2026, les meilleurs créateurs d'applications ne sont plus des ingénieurs, mais des profils littéraires (écrivains, juristes, philosophes, scénaristes).
  • La force du langage : la matière première du vibe coding est le langage naturel, pas le code. Manier le verbe avec précision et structurer une pensée complexe sont des forces d'écrivain.
  • Formuler vs résoudre : l'habitude de formuler avec rigueur (comme une juriste rédigeant des contrats) produit des prompts bien plus efficaces qu'une approche purement technique.
  • Ce que vous apprendrez ici : pourquoi cette bascule historique s'opère, les 4 compétences clés à maîtriser, 6 conseils opérationnels, et les réponses à vos questions.
I.

Les meilleurs vibe codeurs sont d’anciens écrivains, pas des ingénieurs

Il y a quelques années, dire qu’un diplômé de lettres allait créer la prochaine app à succès, c’était le genre de blague qu’on sortait lors des repas de famille pour détendre l’atmosphère — juste après la question sur le chômage.

Aujourd’hui, c’est une thèse sérieuse. Et elle fait mal à beaucoup de monde.

Parce qu’elle sous-entend une chose que personne ne veut admettre : pendant 50 ans, on a mis les mauvaises personnes aux commandes de l’économie numérique. On a sacré les ingénieurs rois du logiciel, relégué les littéraires au rang de fossiles sympathiques — bons pour enseigner Flaubert ou rédiger des newsletters que personne ne lit.

Illustration éditoriale : un écrivain à son bureau dont la plume se transforme en flux de code lumineux

La plume qui devient curseur. L’écrivain qui devient vibe codeur.

“Sauf que Flaubert, il paraît, était un excellent prompteur.”

Le monde du vibe coding est en train de corriger cette erreur historique. Discrètement. Sans conférence de presse. Et les premiers concernés — les écrivains, les philosophes, les scénaristes — ne le savent même pas encore.

C’est le moment de le leur dire.

II.

La vieille équation est morte

J’ai formé pas mal de monde au prompting durant ces trois dernières années. Des profils très différents. Principalement des professionnels en reconversion.

Et j’ai observé quelque chose d’étrange, de répétable, et franchement d’un peu gênant à dire dans une salle pleine d’ingénieurs.

Les meilleurs élèves ne sont presque jamais les plus techniques.

Pas une fois. Pas deux fois. Systématiquement.

La personne qui produit le prompt le plus efficace au bout de deux heures de formation, c’est la juriste qui rédige des contrats depuis dix ans. C’est le journaliste reconverti qui a passé sa carrière à reformuler des idées complexes pour des lecteurs pressés. C’est la chargée de com’ que tout le monde regardait avec condescendance au début de la session.

Pendant ce temps, le développeur senior — celui qui connaît Python, qui a des opinions tranchées sur les design patterns, qui a demandé trois fois si on allait parler de l’API — produit des prompts qui ressemblent à des tickets Jira. Secs, fonctionnels, et totalement inefficaces.

Constat terrain — 2 ans de formations

Profil littéraire
Développeur senior
Formule une intention
Décrit une fonction
Structure une narration
Liste des contraintes
Choisit le ton
Ignore le ton
Anticipe l'interprétation
Suppose la précision
Itère sur le sens
Itère sur la syntaxe

Observations issues de 200+ sessions de formation au prompting · 2024–2026

Pourquoi ?

Parce qu’il a passé quinze ans à apprendre à parler à une machine. Syntaxe stricte, logique binaire, zéro ambiguïté. C’est une discipline formidable. Et c’est exactement ce qui le trahit face à un LLM.

Compilateur vs LLM — deux langages radicalement différents

Compilateur
  • Syntaxe stricte
  • Zéro ambiguïté tolérée
  • Résultat binaire : compile ou plante
  • Le contexte ne compte pas
  • Le ton est invisible
LLM
  • Langage naturel
  • Sensible au contexte et au ton
  • Résultat graduel : meilleur ou moins bon
  • Le cadrage change tout
  • La structure narrative guide la réponse

Parce qu’un LLM, ce n’est pas un compilateur.

C’est un interlocuteur. Il réagit au ton, au contexte, à la structure narrative de votre demande. Il est sensible à la façon dont vous posez les choses, pas seulement à ce que vous demandez. Lui donner un prompt sec et technique, c’est comme envoyer un SMS sans ponctuation à quelqu’un que vous voulez convaincre de quelque chose d’important.

“Ça marche. Mais pas bien.”

L’ancienne équation était simple et rassurante : créer du logiciel = maîtriser la logique et les maths. Elle a tenu cinquante ans. Elle a produit des fortunes, des carrières, une aristocratie technique qui a restructuré l’économie mondiale.

L’équation qui meurt — 50 ans de règne

1970sNaissance du logiciel
1990sInternet / Web
2010sApogée des devs
2025Vibe coding
2026+Ère littéraire

Ancienne équation : créer du logiciel = maîtriser la logique et les maths

Nouvelle équation : créer du logiciel = formuler une intention avec précision

Elle est morte. Pas brutalement — doucement, comme meurent les évidences. Sans faire de bruit.

La matière première du vibe coding, ce n’est pas du code. Ce n’est pas un algorithme. Ce n’est pas une fonction récursive élégante dont vous êtes fier depuis 2019.

C’est une phrase bien construite.

Et ça, croyez-moi, ça change absolument tout.

III.

Formuler vaut mieux que résoudre

Voici ce que j’observe en formation, en vrai, sans filtre.

Je donne le même exercice à tout le monde : créer une app simple de gestion de tâches en vibe coding, from scratch, sans toucher à une ligne de code. Une heure. Chrono.

Le même exercice. Deux approches. Deux résultats.

Le développeur
Prompt :“Crée une app React avec une liste de tâches, un champ input, un bouton d’ajout et une fonction de suppression.”
Résultat correct. Fonctionnel. Ennuyeux comme la pluie.
La scénariste
Prompt :“Je veux une app de gestion de tâches pour quelqu’un de débordé qui a besoin de clarté mentale immédiate. L’interface doit être apaisante, les actions doivent sembler légères, et l’utilisateur doit avoir l’impression de reprendre le contrôle dès la première seconde.”
Résultat 3× supérieur. Sans exagérer.

Elle n’a pas décrit une fonctionnalité. Elle a décrit une intention. Un LLM nourri d’intentions claires produit quelque chose de fondamentalement différent d’un LLM nourri de spécifications techniques.

C’est le premier basculement à intégrer.

Syntaxe vs style

Le développeur optimise sa requête comme il optimise son code : il traque la redondance, il veut de la précision technique, il évite le superflu. C’est une excellente discipline pour écrire du Python. C’est une discipline médiocre pour écrire un prompt.

Parce qu’un prompt n’est pas une commande. C’est un texte. Et un texte a un style. Le style porte de l’information que les mots seuls ne portent pas — le niveau de langue signale le registre attendu en retour, le rythme signale l’urgence ou la profondeur, le choix entre “supprimer” et “faire disparaître” oriente subtilement le résultat.

Conseil opérationnel n°1

Avant d’écrire votre prompt, posez-vous cette question : quel registre je veux en retour ? Formel, conversationnel, technique, narratif ? Puis écrivez votre prompt dans ce registre. L’IA s’aligne sur votre ton. Utilisez-le.

Algorithme vs intention

Un ingénieur décompose un problème en étapes logiques. C’est puissant. Mais un romancier décompose une intention en sous-intentions — il sait que pour écrire une scène de rupture convaincante, il faut d’abord construire l’attachement, puis installer le doute, puis laisser le silence faire le travail.

C’est exactement la structure d’un bon prompt complexe.

Anatomie d’un prompt en couches

01ContexteQui je suis, ce que je construis
02ObjectifCe que je veux obtenir
03ContraintesCe que je ne veux pas
04TonComment je veux que ça sonne
Conseil opérationnel n°2

Arrêtez d’écrire des prompts monolithiques. Décomposez votre intention en couches. D’abord le contexte, puis l’objectif, puis les contraintes, puis le ton. Quatre paragraphes courts valent dix fois mieux qu’une liste à puces exhaustive.

Donner des ordres vs écrire

C’est l’erreur la plus répandue que je vois en formation, et la plus coûteuse.

Les gens traitent un LLM comme un moteur de recherche amélioré. Ils tapent des mots-clés. Ils font des listes. Ils abrègent. Ils pensent que la brièveté est une qualité.

Prompt comme moteur de recherche

app tâches react
suppression items
localStorage
mobile responsive
Résultat générique

Prompt comme texte

Contexte précis.
Intention formulée.
Exemple concret fourni.
Ton voulu signalé.
Résultat singulier

Elle ne l’est pas. Pas ici. Prompter, c’est écrire. Avec tout ce que ça implique : un début qui pose le contexte, un développement qui précise l’intention, une fin qui cadre le livrable attendu. Le non-dit compte. L’exemple compte. La métaphore, parfois, vaut mieux que la définition.

Conseil opérationnel n°3

Donnez un exemple dans votre prompt. Pas une description de ce que vous voulez — un exemple réel, même imparfait, de ce à quoi ça doit ressembler. “Dans le style de cet extrait...”, “avec la structure de cet email...”, “aussi concis que cette phrase...” Un exemple vaut mille adjectifs.

Performance vs élégance

Le dernier point, et probablement le plus contre-intuitif pour un profil technique.

Un bon vibe codeur évalue son output comme un éditeur évalue un manuscrit : est-ce que c’est clair ? Est-ce que chaque élément est là pour une raison ? Est-ce que ça respire ? Est-ce que l’intention de départ est encore lisible dans le résultat final ?

L’ingénieur se demande…

Le vibe codeur se demande…

Est-ce que ça tourne ?
Est-ce que c'est clair ?
Est-ce que c'est optimisé ?
Est-ce que ça respire ?
Quel est le temps de réponse ?
L'intention est-elle lisible ?
Y a-t-il des erreurs ?
Chaque élément a-t-il une raison d'être ?
Conseil opérationnel n°4

Relisez votre output comme un texte, pas comme un code. Demandez-vous si un utilisateur qui ne sait rien de votre intention de départ comprendrait ce que cette app veutlui faire ressentir. Si la réponse est non, le problème n’est pas dans le code généré. Il est dans le prompt que vous avez écrit.

Formuler, en 2026, c’est la compétence la plus sous-estimée de l’économie numérique.

Et le plus beau, c’est qu’elle s’apprend. Vite. Par ceux qui ont déjà passé des années à choisir leurs mots.

IV.

La bascule qui arrive

Permettez-moi de vous poser une question sérieuse.

Quand vous pensez à une “école qui forme les créateurs de demain”, quelle image vous vient spontanément ?

L’image mentale collective en 2026

Un campus avec des tableaux blancs couverts d'équations

Des étudiants sous Red Bull devant des terminaux, trois heures de sommeil

Une hiérarchie où coder le plus bas niveau = être le plus respecté

?

Est-ce que cette image décrit encore quelque chose de réel en 2026 — ou un mythe qui a pris du retard sur la réalité ?

Référence philosophique

Platon avait une théorie là-dessus. Il appelait ça la caverne. Des gens enchaînés qui prennent des ombres pour des vérités, parce que les ombres, au moins, ils les connaissent depuis longtemps.

Je ne dis pas que les ingénieurs sont enchaînés dans une caverne. Je dis juste que peut-être, la lumière vient d’une direction que personne ne regardait.

Est-ce que le pouvoir économique du logiciel s’est déjà déplacé — et on ne l’a pas encore officiellement remarqué ?

Où est la valeur dans une app — avant et après

Valeur perçue avant

Valeur réelle en 2026

Tourner sans bug
Commoditisé — prérequis, pas avantage
Performance technique
Générée par n'importe quel LLM en 30s
Architecture élégante
Invisible pour l'utilisateur final
Maîtrise du stack
Commoditisée — accessible à tous

Ce qui crée vraiment la valeur

La clarté de l’intention derrière le produit

Compétence requise

Formuler un problème humain avec précision

Est-ce que ça ressemble à une compétence d’ingénieur ? Ou est-ce que ça ressemble, bizarrement, à ce qu’on apprend en atelier d’écriture ?

Voilà la vraie question qui devrait déranger tout le monde : et si on avait mal lu, depuis cinquante ans, ce qui fait la valeur d’un créateur de logiciel ?

Pas mal codé. Mal lu. Mal interprété. Comme on lit mal parfois un roman en ne voyant que l’intrigue, en ratant complètement ce que l’auteur faisait avec la langue. L’économie numérique a peut-être passé cinq décennies à optimiser le mauvais paramètre.

Questions ouvertes

  • ?Les filières littéraires vont-elles 'sauver la tech' ?
  • ?Les écoles d'ingénieurs vont-elles perdre leur monopole d'ici 2030 ?
  • ?Est-ce une révolution ou un rééquilibrage ?
  • ?Est-ce de la justice, de l'ironie, ou un accident ?

Honnêtement ? Je ne sais pas.

Toute personne qui répond avec certitude mérite un scepticisme poli mais ferme.

Ce que je sais avec certitude

  • Quelque chose bouge — je le vois en formation, semaine après semaine
  • Des profils littéraires rejoignent la tech par la porte du langage
  • Ils ont exactement les bons réflexes pour la prochaine étape
  • Ce n'était pas prévu. Et pourtant c'est là.

Conclusion

Le prompt est le nouveau style.

“Le style, c’est l’homme même.”

— Buffon, 1753. Qui n’avait pas prévu les LLM — mais qui aurait probablement adoré les prompter.
V.

Ce que ça change pour vous

Bon. On arrive au moment où il faut atterrir.

Parce que la philosophie, c’est bien. Buffon, Platon, la caverne, les ombres — c’est stimulant intellectuellement. Mais vous êtes là pour savoir ce que vous faites concrètement avec tout ça, lundi matin, devant votre écran.

Alors voici la vraie question : vous êtes qui, vous ?

A

Si vous venez des lettres, de la philo, du droit, du journalisme, de la com’, du scénario

Première chose : arrêtez de vous excuser.

Vous avez passé des années à intérioriser l’idée que votre formation était un luxe sympathique mais économiquement fragile. Que vous étiez, dans le grand théâtre de l’économie numérique, un personnage secondaire — utile pour les brochures, décoratif pour les équipes créatives, mais fondamentalement dépendant de ceux qui vraiment construisaient les choses.

Cette histoire est terminée. Pas dans dix ans. Maintenant.

Vos réflexes — que vous n’aviez pas identifiés comme compétences techniques

Décomposer une intention
Structure un prompt en couches sans effort
Choisir ses mots avec soin
Guide le registre et le ton du LLM
Sentir quand une formulation rate sa cible
Permet d'itérer sur le sens, pas la syntaxe
Vivre avec l'ambiguïté du langage
Anticipe les interprétations multiples du modèle

Est-ce que vous savez vous en servir ?

Probablement pas encore. Parce que personne ne vous a dit que c’était une compétence technique. On vous a laissé croire que c’était juste... vous. Votre façon d’être. Un trait de caractère un peu flou, difficilement monnayable.

Conseil opérationnel n°5

Prenez n’importe quel projet que vous avez envie de créer et passez deux heures à le décrire par écrit avant de toucher à quoi que ce soit. Pas les fonctionnalités. L’intention.

  • L'émotion que vous voulez provoquer
  • Le problème humain que vous résolvez
  • Le personnage qui l'utilise à 23h un mardi soir quand il est épuisé

Puis donnez ce texte à un LLM. Regardez ce qu’il produit. Et demandez-vous si un ticket Jira aurait fait la même chose.

B

Si vous venez de l’ingénierie, du développement, des maths

Votre atout technique est réel. Ne le bradez pas — il reste précieux, et il le restera. La compréhension fine de ce qui se passe sous le capot n’est pas obsolète. Elle est juste insuffisante, seule, pour capturer la valeur maximale de ce moment technologique.

Ce qui vous manque — et ce que ce n’est pas

Une nouvelle librairie
Un nouveau framework
Une meilleure connaissance des LLM
Un rapport différent à la langueC’est ça

Et ça, contrairement à ce qu’on vous a peut-être laissé croire dans votre parcours très orienté STEM, ça s’apprend. Ça se travaille. Ça se muscle, exactement comme on muscle une compétence technique — par la pratique délibérée, par l’exposition répétée, par l’inconfort consenti de faire quelque chose qu’on ne maîtrise pas encore.

Conseil opérationnel n°6

Imposez-vous une contrainte simple pendant trente jours. Avant chaque prompt, écrivez une phrase qui commence par :

“Ce que je veux vraiment obtenir, c’est...”

Pas la fonctionnalité. L’intention derrière la fonctionnalité. L’intention derrière l’intention.

C’est agaçant au début. C’est lent. Ça ressemble à une perte de temps pour quelqu’un d’habitué à aller droit au but. Et puis un jour, vous regardez votre output et vous comprenez que quelque chose a changé.

Dans les deux cas — sans nuance

La compétence clé de 2026 — ce que ce n’est pas

Un nouveau langage de programmation
La maîtrise d'un outil en particulier
La connaissance des LLM les plus récents (ils changent tous les 3 mois)
La précision stylistique

La capacité à formuler une intention complexe en termes assez clairs, assez riches, assez justes pour que la machine produise quelque chose qui dépasse ce que vous auriez pu faire seul.

C'est une compétence d'écrivain.

Pas d'ingénieur.

Pas de mathématicien.

D'écrivain.

Et la bonne nouvelle — la vraie —

c’est que tout le monde peut le devenir.

Foire aux questions

Les questions que vous vous posez
(et celles que vous n’osez pas poser)

Est-ce que le vibe coding va vraiment remplacer les développeurs ?+

Non. Et quiconque vous dit le contraire essaie probablement de vous vendre quelque chose.

Le vibe coding ne remplace pas les développeurs. Il déplace la valeur. Ce qui change, c’est l’endroit où se crée l’avantage concurrentiel dans la chaîne de création logicielle. Construire une app fonctionnelle n’est plus un exploit — c’est un point de départ. La vraie question devient : qu’est-ce que vous construisez, pour qui, et pourquoi ? Et ça, c’est une question de formulation, pas de compilation.

Je ne sais pas coder. Est-ce que je peux vraiment créer une app avec le vibe coding ?+

Oui. Avec des nuances sérieuses.

Vous pouvez créer un prototype convaincant, un MVP fonctionnel, un outil personnel utile — sans toucher à une ligne de code. Des centaines de personnes le font chaque semaine. Certaines en font des business rentables.

Ce que vous ne pouvez probablement pas faire seul, pour l’instant : déployer une infrastructure complexe, sécuriser une app qui gère des données sensibles, déboguer un problème profond qui nécessite de comprendre ce qui se passe réellement sous le capot.

Le vibe coding abaisse spectaculairement la barrière d’entrée. Il ne la supprime pas entièrement. Soyez ambitieux, pas naïf.

Et si mon écriture est mauvaise ? Si je ne suis pas « littéraire » ?+

Mauvaise nouvelle : vous confondez deux choses.

Écrire avec précision n’est pas écrire avec style littéraire. Personne ne vous demande de rédiger des prompts comme Proust construisait ses phrases — ce serait d’ailleurs contre-productif et légèrement épuisant.

Ce qu’on vous demande, c’est d’être clair sur ce que vous voulez. De formuler une intention sans ambiguïté. De savoir dire ce que vous ne voulez pas autant que ce que vous voulez.

C’est une compétence de communication, pas de littérature. Et si vous avez réussi à vous faire comprendre dans un email difficile, une réunion tendue, ou un message à votre propriétaire pour lui expliquer pourquoi le loyer était en retard — vous avez les bases.

Les ingénieurs vont-ils vraiment perdre leur avantage ?+

Perdre leur avantage, non. Devoir le partager, oui.

Ce qui disparaît, c’est le monopole. L’idée qu’il fallait obligatoirementpasser par eux pour créer quelque chose de numérique. Ce monopole était structurel — il reposait sur une barrière technique réelle. Cette barrière s’effondre.

Ce qui reste précieux dans une formation d’ingénieur : la rigueur analytique, la compréhension des systèmes, la capacité à déboguer une logique complexe. Ce sont des atouts réels. Ils deviennent juste insuffisants, seuls, pour capturer toute la valeur disponible.

L’avenir appartient probablement aux profils hybrides — ceux qui pensent en systèmes et en intentions. Ceux qui codent et qui écrivent. Pas à ceux qui choisissent un camp.

Combien de temps faut-il pour devenir bon en vibe coding ?+

Moins que vous ne le pensez. Plus que ce que les influenceurs vous vendent.

En deux heures de pratique sérieuse, vous pouvez produire quelque chose qui vous aurait pris des semaines à apprendre à coder. C’est réel, ce n’est pas de la publicité mensongère.

Mais « bon » en vibe coding — c’est-à-dire capable de produire des résultats consistants, de débloquer les situations complexes, de ne pas être paralysé quand l’IA part dans une mauvaise direction — ça se construit sur quelques semaines de pratique régulière.

Comptez un mois de pratique quotidienne pour passer du statut de débutant impressionné à celui de créateur autonome. C’est honnête.

Est-ce que les écoles vont s'adapter ?+

Certaines. Pas toutes. Pas assez vite.

Les institutions bougent lentement — c’est leur nature, pas un défaut de caractère. Une école d’ingénieurs qui a construit sa réputation sur cinquante ans de formation technique ne va pas pivoter vers les humanités numériques en dix-huit mois.

Ce qui va probablement se passer : des formations hybrides vont émerger en dehors du système traditionnel. Des bootcamps, des communautés, des parcours autodidactes vont produire les praticiens les plus efficaces de la prochaine vague. Ce n’est pas une catastrophe pour l’éducation formelle. C’est simplement la façon dont les transitions technologiques se passent, historiquement, quand elles vont plus vite que les curricula.

« Le prompt est le nouveau style » — c'est une métaphore ou c'est littéral ?+

Les deux. Et c’est exactement pour ça que ça fonctionne.

C’est une métaphore parce qu’écrire un prompt n’est pas, techniquement, du style littéraire au sens où Barthes l’entendait.

C’est littéral parce que votre façon de formuler une demande à un LLM est unique, reconnaissable, et directement corrélée à la qualité de ce qu’il produit en retour. Deux personnes qui donnent le même brief à la même IA obtiennent des résultats radicalement différents — pas à cause de la chance, mais à cause de la façon dont elles écrivent.

C’est la définition du style.

Buffon avait raison. Il avait juste trois siècles d’avance.