Vibe coding : dicter sa rédaction, est-ce encore écrire ?

Tu as une idée d’application pour noter les livres que tu prêtes à tes amis. Au lieu d’apprendre tout de suite la programmation, tu décris l’écran voulu à un agent : « ajoute un livre, indique à qui je l’ai prêté et montre la date de retour ». Quelques échanges plus tard, quelque chose s’affiche à l’écran. Tu souris. Est-ce que tu as écrit le programme ?

Tu as bien participé à sa création. Mais comme l’élève qui dicte sa rédaction à un camarade, tu n’as pas forcément choisi chaque mot ni compris chaque phrase de code. Le terme vibe coding désigne une façon de créer un logiciel en guidant une IA avec des descriptions en langage courant, plutôt qu’en écrivant chaque ligne soi-même. L’explication de Google Cloud distingue l’expérimentation rapide où l’on fait confiance au résultat et une pratique où l’on examine, teste et comprend ce qui est produit.

Le vrai gain : passer plus vite de l’idée à l’essai

Le code, c’est une recette très stricte que l’ordinateur peut exécuter. La conversation avec l’agent ressemble à une dictée : tu dis ce que tu veux, il transforme ta description en fichiers, puis tu lui demandes des ajustements. Pour une maquette, un petit outil personnel ou un prototype, cette boucle peut aider à rendre une idée visible avant de connaître toutes les règles du langage.

Tu peux aussi apprendre en regardant la copie produite. Demande à l’agent d’expliquer un fichier, de modifier un seul élément à la fois et de dire comment vérifier le résultat. C’est différent de « construis toute l’application et surprends-moi » : dans le premier cas, tu gardes le plan et tu observes comment les pièces s’assemblent.

Attention au mot « coder sans coder ». Décrire un bouton n’explique pas nécessairement où les données sont stockées, qui peut y accéder ou ce qui se passe quand l’application reçoit une entrée inattendue. Une interface jolie ne prouve pas que le système est fiable. Les assistants peuvent produire du code incorrect, incomplet ou vulnérable ; la documentation GitHub sur l’usage responsable des agents Copilot demande de relire et tester attentivement le code généré.

La copie peut être propre et avoir zéro au problème

Imagine que tu demandes un formulaire de prêt de livres. L’écran s’affiche, mais l’application ne garde rien après fermeture. Ou bien elle affiche l’adresse électronique des emprunteurs à toute personne qui ouvre la page. Tu as demandé une fonction, mais tu n’as peut-être pas formulé les règles invisibles : stockage, confidentialité, cas d’erreur, sauvegarde.

C’est là que le « ça a l’air de marcher » devient un mauvais correcteur. Il faut préciser ce que signifie « marcher » avec des tests simples : ajouter un livre, fermer et rouvrir la page, vérifier que le livre est encore là ; essayer un champ vide ; vérifier qui peut consulter les données. Une réponse générée avec aplomb reste une copie à relire, comme on l’a vu dans l’article sur les erreurs de l’agent.

Pour un prototype sans données sensibles, tu peux accepter un peu de bricolage. Pour un vrai service utilisé par d’autres personnes, il faut penser à la sécurité, aux sauvegardes, à l’accessibilité, aux mises à jour et à la maintenance. Plus la conséquence d’un bug est lourde, moins tu peux te contenter d’une démonstration convaincante.

À toi de jouer : une mini appli sans compte ni secret

Essaie avec une petite page qui affiche une liste de trois livres prêtés, écrite dans un environnement de test ou un outil auquel tu fais confiance. N’ajoute aucun mot de passe, donnée personnelle ni vrai document. Donne cette consigne : « crée une page avec une liste fixe de trois livres, leur titre et une date de retour fictive. N’ajoute ni connexion ni stockage distant. Explique les fichiers créés et donne trois vérifications manuelles. »

Quand l’agent a fini, ne t’arrête pas à la capture d’écran. Vérifie que les trois lignes affichent bien les dates, que le contenu fonctionne sur un petit écran et que les fichiers correspondent à ce qui a été demandé. Si l’agent a créé une base de données ou un compte alors que tu avais demandé une simple liste fictive, demande-lui d’expliquer pourquoi avant d’accepter cette modification. Tu peux aussi lui demander de supprimer l’excédent, puis regarder la différence.

Enfin, demande : « qu’est-ce qui ne sera pas conservé si je ferme la page ? » Si l’agent ne sait pas répondre clairement, tu viens de trouver une question à résoudre avant de transformer la maquette en vrai carnet. L’exercice ne certifie pas la sécurité d’un produit ; il t’entraîne à exiger un comportement vérifiable.

Alors, est-ce encore écrire ?

Oui, tu as écrit une intention, des critères et des retours. Mais tu as délégué une partie de la mise en forme et de la réalisation. Si tu ne lis ni ne testes le résultat, tu signes une copie que tu n’as pas corrigée. Si tu pilotes, apprends ce qu’il faut pour vérifier, et assumes ce qui est livré, l’IA devient un outil de rédaction puissant — le stylo est partagé, la responsabilité reste à toi.

À retenir : le vibe coding facilite le premier jet et l’expérimentation. Il ne transforme pas une demande en logiciel fiable par magie. Commence avec une tâche petite, sans données sensibles, précise comment vérifier la réponse, puis augmente l’enjeu seulement quand tu sais relire la copie.