Prompt engineering et vibe coding : compétences de demain, ou déjà d’aujourd’hui ?

Prompt engineering, vibe coding : de quoi parle-t-on

Deux mots, deux niveaux. Le « prompt engineering » désigne l’art de formuler ses demandes à une IA pour en tirer un résultat utile et fiable : poser le contexte, donner des exemples, cadrer le format de la réponse. Le « vibe coding » va un cran plus loin : produire un logiciel ou un outil en décrivant son intention à l’IA, en langage courant, plutôt qu’en écrivant le code soi-même.

J’ai déjà défendu ici l’idée que le vibecoding est une vraie compétence — mais pas « savoir coder » : savoir cadrer, juger, arbitrer ce que la machine produit. Je voudrais cette fois prolonger ce raisonnement vers une question plus concrète, celle qui décide d’une embauche ou d’une formation : ces compétences, faut-il s’y mettre maintenant, et qu’est-ce qui, dedans, vaudra encore quelque chose dans cinq ans ?

Le paradoxe : la technique se périme en s’apprenant

Première surprise pour qui veut « apprendre à prompter » : la matière fond entre les mains. Les recettes de 2023 — ces formules magiques, ces incantations qu’on s’échangeait pour forcer un modèle à mieux répondre — sont déjà largement obsolètes. Les modèles ont progressé et ont absorbé ces astuces : ce qui demandait une technique de spécialiste s’obtient aujourd’hui en demandant simplement les choses clairement. La couche technique se banalise à vue d’œil.

Ce n’est pas nouveau. « Savoir Excel » fut un métier dans les années 90, puis une ligne de CV dans les années 2000, puis un implicite qu’on ne mentionne même plus. Le prompt engineering suit le même chemin, en bien plus rapide : ce qu’on vend aujourd’hui comme une expertise rare sera demain un savoir-faire de base, supposé acquis. Miser une carrière — ou un plan de formation — sur la seule maîtrise de l’outil du moment, c’est courir après une cible qui se dissout.

D’où une conclusion contre-intuitive : si la valeur était dans la technique, on aurait raison d’attendre que tout se stabilise. Sauf que la vraie valeur n’est pas là.

La vraie compétence : maintenir un système, pas le produire

Voici le cœur de l’affaire. Avec le vibe coding, produire est devenu trivial : n’importe qui obtient une petite application en une après-midi. Mais produire n’a jamais été le travail difficile. Le travail difficile, c’est de faire vivre ce qu’on a produit — le comprendre assez pour le faire évoluer, le réparer quand il casse, préserver sa cohérence sur des mois, savoir ce qu’on peut modifier sans tout faire s’effondrer. C’est là, exactement, que se loge la compétence durable.

Je le mesure chaque jour sur mes propres systèmes. Ma station de pilotage de robots, mon moteur d’IA documentaire AQUIFÈRE, le site que vous lisez : aucun n’est une démo. Ce sont des systèmes que j’entretiens depuis des mois. La première version de chacun a pris quelques jours ; tout le reste — des centaines d’heures — c’est de la maintenance : corriger un bug qui ne surgit qu’en conditions réelles, ajouter une fonction sans casser les autres, garder l’ensemble lisible pour qu’il reste modifiable. L’IA m’aide à chaque étape, mais c’est moi qui tiens le fil de cohérence que la machine, elle, n’a pas.

Cette distinction change tout pour le tertiaire. Celui qui vibe-code un petit outil interne — un tableau de bord, un automate de relances, un assistant de tri — n’en devient pas le producteur d’un jour : il en devient le mainteneur. Le jour où la règle métier change, où l’outil bugue avant une échéance, où un collègue demande une variante, c’est lui qu’on regarde. Savoir produire ouvre la porte ; savoir maintenir est ce qui fait qu’on reste dans la pièce.

Dans le tertiaire, la bascule a déjà commencé

Pourquoi le tertiaire en particulier ? Parce que sa matière première est exactement celle que l’IA manipule le mieux : du texte, des tableaux, des courriels, des documents. Le secrétariat, la comptabilité, la banque-assurance, le juridique, l’administration — tous ces métiers passent leurs journées à lire, trier, rédiger, recouper. C’est le terrain de jeu naturel de l’IA générative, et la bascule n’est pas une prévision : elle est en cours.

Concrètement, cela ne veut pas dire que ces métiers disparaissent. Cela veut dire que la part « production de texte ou de tableau » se délègue de plus en plus à la machine, et que la valeur de la personne se déplace vers ce que la machine ne tient pas seule : juger si le résultat est juste, l’insérer dans un processus qui dure, en assurer la fiabilité dans le temps. Autrement dit, la compétence qui monte n’est pas « produire vite », que tout le monde aura — c’est « tenir un système fiable », que peu de gens savent faire.

Alors, dès aujourd’hui ou dans cinq ans ?

Maintenant la réponse au titre. Faut-il s’y mettre dès aujourd’hui ? Oui, sans hésiter — mais pas pour « savoir prompter », puisqu’on vient de voir que cette couche-là se banalisera. Il faut s’y mettre aujourd’hui parce que l’aptitude à maintenir un système ne s’apprend qu’en pratiquant, longtemps, sur des choses réelles. Elle se construit par l’expérience accumulée : avoir vu un outil casser et compris pourquoi, avoir fait évoluer du code qu’on croyait figé, avoir reconnu la différence entre « ça marche à l’écran » et « ça tiendra en production ».

C’est précisément ce qui ne se rattrape pas. En 2031, on n’improvisera pas cinq ans de systèmes entretenus. Celui qui aura commencé aujourd’hui à construire, casser, réparer et faire durer ses petits outils aura une longueur d’avance que nulle formation accélérée ne donnera. Le « dans cinq ans » est un piège : il suppose qu’il s’agit d’apprendre une technique, qu’on pourra prendre toute faite le moment venu. Mais on n’apprend pas le jugement à la demande. On l’accumule.

C’est en cela que la fausse alternative du titre se dissout. On apprend l’outil aujourd’hui — peu importe qu’il change — parce que c’est en le pratiquant qu’on développe la seule chose qui, elle, ne se périmera pas : la capacité à tenir dans la durée ce que l’IA permet de produire en un instant.

Ce que ça change pour le dirigeant

Si vous dirigez une organisation, cette grille a trois conséquences immédiates. La première touche le recrutement : la bonne question n’est plus « sait-il se servir de l’IA ? » — bientôt tout le monde saura — mais « sait-il faire durer ce qu’il construit avec ? ». Cherchez la trace de systèmes tenus dans le temps, pas la liste des outils maîtrisés.

La deuxième touche la formation. Méfiez-vous des « formations prompt » jetables, calibrées sur l’outil du trimestre : vous payez pour un savoir qui se périmera avec la prochaine version du modèle. Formez plutôt vos équipes à cadrer un besoin, juger un résultat, et tenir un outil dans la durée — des compétences qui survivront à dix générations de modèles.

La troisième touche le risque, et c’est l’arbitrage que je pose avec mes clients à travers le RADAR IA, notamment son axe Délégation. Quand vos équipes vibe-codent vite, vous gagnez en rapidité — mais vous accumulez peut-être une dépendance que personne ne maîtrise. Qui maintiendra l’outil quand son auteur sera parti ? La vitesse de production n’est pas la maîtrise du système ; tracer la frontière entre ce qu’on délègue à la machine et ce qu’on garde comme compétence humaine durable, c’est exactement là que se joue la solidité de votre organisation.

En résumé

Faut-il apprendre le prompt engineering et le vibe coding dès aujourd’hui ? Oui — mais en sachant que la technique elle-même se banalisera, comme « savoir Excel » avant elle. Ce qui restera, et qui fera la différence dans le tertiaire, n’est pas l’aptitude à produire avec l’IA : c’est l’aptitude à maintenir, dans la durée, ce qu’on a produit. Comprendre, faire évoluer, réparer, garder cohérent.

Et cette compétence-là ne s’achète pas dans cinq ans toute faite : elle s’accumule, à partir d’aujourd’hui, en pratiquant sur du réel. L’outil est à portée de tous ; l’avantage ira à ceux qui auront appris, tôt, à faire vivre ce qu’ils bâtissent.