Lire un langage de programmation sans savoir l’écrire. Entre ignorance et maîtrise : une compétence intermédiaire encore difficile à nommer.
Le vibe coding tient en une boucle assez simple : décrire en langage naturel ce qu’on veut, laisser une IA produire
le code, regarder ce qui sort, corriger la trajectoire, recommencer jusqu’à ce que ça tienne.
La caricature s’écrit toute seule. Quelqu’un demande un « bouton plus joli », clique sur Run, obtient un écran rouge et
négocie avec la machine jusqu’à ce que quelque chose fonctionne.
Cette caricature existe. Elle occupe même suffisamment le terrain pour masquer le phénomène plus intéressant.
À force de faire écrire, corriger et expliquer du code par une machine, certains utilisateurs finissent par comprendre une
langue qu’ils ne savent toujours pas parler.
Une compétence sans case
L’informatique reposait jusqu’ici sur une frontière relativement nette : ceux qui programment et ceux qui utilisent ce qu’ils ont
programmé.
Les modèles génératifs installent progressivement un troisième terme.
Le vibecodeur n’écrit pas nécessairement une fonction Python, ne sait pas concevoir seul une architecture TypeScript et peut très
bien se perdre dans un rebase. Quelques mois de pratique, pourtant, et il commence à reconnaître des formes.
Il voit qu’un patch de deux cents lignes pour corriger un problème d’affichage est probablement un aveu plutôt qu’une solution. Il
apprend à isoler une fonctionnalité avant d’y toucher. Il distingue une erreur de syntaxe d’un conflit de dépendances ou d’un
comportement simplement mal spécifié.
Il apprend ce que sont un test, une branche, un log, un environnement, une API.
Surtout, il apprend à formuler le problème de manière exploitable.
Ce savoir est troué. Il devient dangereux exactement au moment où il se prend pour de la maîtrise. Mais il n’est pas nul.
C’est une forme de littératie technique assistée.
Comprendre n’est pas produire
Le phénomène n’a rien d’exotique hors de l’informatique.
On peut comprendre une langue étrangère beaucoup mieux qu’on ne la parle. Reconnaître des mots, des tournures, des intentions. Sentir
qu’une traduction sonne faux tout en étant incapable d’en écrire immédiatement une meilleure.
Compréhension et production ne sont pas la même compétence.
L’IA introduit cette dissociation dans le code.
Un utilisateur lit quarante lignes générées. Il serait incapable de les produire seul. Pourtant, il en identifie la fonction
générale, repère la variable importante, comprend quel module est appelé et commence parfois à deviner où se situe l’erreur.
Il ne devient pas développeur par osmose.
Il devient autre chose : quelqu’un capable de naviguer dans un système dont une partie importante de l’exécution lui échappe.
Le prompt n’est pas l’outil
Les premiers discours autour des IA génératives ont beaucoup surinvesti le prompt engineering, parfois jusqu’à lui prêter
les propriétés d’une petite discipline occulte : trouver la formulation parfaite, l’incantation qui ferait enfin obéir la machine.
La pratique quotidienne est moins spectaculaire et beaucoup plus utile.
La compétence déterminante n’est pas verbale. Elle est méthodologique.
Décomposer.
Demander une chose.
Regarder ce qui a changé.
Faire tester.
Lire l’erreur.
Limiter la correction.
Comparer avec l’état précédent.
Revenir en arrière lorsque la solution empire le problème.
Puis recommencer.
Le vibecoding sérieux ressemble finalement assez peu à une conversation avec un oracle. Il ressemble davantage à de la
direction technique assistée.
L’utilisateur n’exécute plus nécessairement chaque opération. Il organise leur production et contrôle leur succession.
Ce qu’on ne sait pas qu’on ignore
Le principal piège est inscrit dans le dispositif.
Une IA peut produire en trente secondes quelque chose d’extrêmement convaincant. L’interface répond, les boutons fonctionnent, la
démonstration passe.
Puis viennent la sécurité, les performances, les dépendances, les cas limites, la maintenance, la dette technique et tout ce qu’une
démonstration de cinq minutes avait élégamment laissé hors champ.
Le risque n’est donc pas simplement de produire du mauvais code.
C’est de ne pas connaître l’étendue de ce qu’on ignore.
Plus un projet grossit, plus la capacité à vérifier la machine devient le facteur limitant.
Et c’est là qu’apparaît un effet intéressant : le vibecodeur sérieux est progressivement contraint d’apprendre.
Pas nécessairement à programmer selon le parcours classique, mais à comprendre les architectures, les tests, le versioning, les
dépendances, la documentation, les permissions, les environnements et ce qui sépare un prototype séduisant d’un système réellement
robuste.
Il devient moins ignorant précisément parce que la délégation lui révèle les endroits où son ignorance devient coûteuse.
Le déplacement de la compétence
Le phénomène dépasse largement la programmation.
Pendant longtemps, créer quelque chose de complexe exigeait d’abord de maîtriser le geste technique permettant de le produire.
L’intelligence artificielle commence à dissocier ces deux capacités.
L’humain peut définir l’intention, poser les contraintes, comparer plusieurs solutions, détecter une incohérence, arbitrer et décider
tandis que la machine prend en charge une partie croissante de l’exécution.
La compétence ne disparaît pas.
Elle change d’endroit.
Une part de sa valeur se déplace du geste vers le jugement, de l’exécution vers la direction, de la
production immédiate vers la capacité à contrôler un processus.
Le code rend cette mutation particulièrement visible parce qu’il constitue un langage extrêmement formalisé. Quelques phrases
ordinaires peuvent désormais provoquer la production de centaines ou de milliers de lignes dans une langue que leur commanditaire
déchiffre parfois à peine.
D’où cette situation singulière :
on peut commencer à bâtir avec une langue qu’on ne sait pas encore parler.
L’ordre inversé
Opposer le « vrai développeur » au vibecodeur est tentant, mais assez peu intéressant.
Quelques semaines passées avec une IA ne remplacent évidemment pas des années de métier. Elles n’en ont d’ailleurs pas besoin pour
que le phénomène mérite d’être observé.
La question est ailleurs : que devient l’apprentissage lorsqu’il n’est plus nécessaire de maîtriser une technique avant de
commencer à produire avec elle ?
Le parcours classique suivait approximativement cet ordre :
apprendre → maîtriser → produire
Un autre parcours devient possible :
produire → observer → comprendre → apprendre
La production cesse d’être seulement la récompense située au terme de l’apprentissage. Elle devient elle-même un moyen
d’apprendre.
C’est là que le vibecoding devient véritablement intéressant.
Non comme remplacement du développement, mais comme premier exemple particulièrement visible d’un rapport plus général aux
intelligences artificielles : des individus capables d’opérer dans des domaines qu’ils ne maîtrisent pas entièrement, à condition d’en
comprendre progressivement assez la structure pour diriger, vérifier et corriger les machines qui exécutent à leur place.
Ce n’est pas encore savoir faire seul.
Ce n’est certainement plus ne rien savoir.
C’est apprendre à gouverner ce qu’on ne sait pas entièrement exécuter.
Pour une pratique encore récente, le déplacement mérite probablement davantage d’attention que la qualité des boutons qu’elle permet
de générer.
Laisser un commentaire