Alsacreations.com - Actualités - Archives (aout 2025)

Le « vibe coding » est une expression inventée par Andrej Karpathy en début d'année, elle désigne une nouvelle façon de programmer, en déléguant entièrement l'écriture du code à l'intelligence artificielle d'un agent. Mais un agent de programmation IA reste un outil, apprendre à le manier demande un peu de temps et quelques efforts.

À qui s'adresse ce tutoriel ? À un développeur, utilisant Visual Studio Code, avec un abonnement GitHub Copilot payant, sur un projet existant.

Le plan gratuit ne suffira pas car nous aurons besoin des derniers modèles d'Anthropic. Ce tutoriel fait de plus l'hypothèse d'une base de code existante avec de préférence un système de gestion de versions (comme Git).

Sommaire

• Configurer Visual Studio Code
• L'agent IA est un perpétuel nouveau venu
• Documenter le projet
• Surveiller la consommation des requêtes premium
• « Vibe coder » une fonctionnalité
• Conseils & réflexions

Configurer Visual Studio Code

Votre VS Code et les plugins de Copilot doivent être à jour. Dans les préférences utilisateur, utilisez la configuration suivante :

  "chat.agent.enabled": true,
  "chat.agent.maxRequests": 1000,
  "chat.tools.autoApprove": true,

Attention : cela fait passer l'agent IA de VS Code dans un mode « YOLO » efficace, mais aussi risqué. Vous devrez désormais le surveiller durant son travail et systématiquement utiliser votre système de gestion de versions afin de pouvoir revenir à une version antérieure en cas de problème.

Si ce n'est pas déjà fait, ouvrez la barre latérale de chat en cliquant sur son icône en haut à droite du champ de recherche. En bas de cette barre latérale, passez en mode Agent et choisissez le modèle Claude Sonnet 4.

L'agent IA est un perpétuel nouveau venu

Un agent de programmation IA doit être traité comme un nouveau venu. À chaque nouvelle session de travail, il redécouvre en effet le projet depuis zéro. Et une session de travail ne dure que quelques minutes ou dizaines de minutes, alors on se lasse de se répéter. La bonne nouvelle est qu'il est dévoué et motivé : il fera à chaque fois l'effort de lire les guides d'utilisation que nous lui fournirons. Tout commence donc par un effort de documentation.

Documenter le projet

Dans cette section, nous allons mettre en place un embryon de documentation à l'intérieur de votre projet. Voici la structure visée :

_docs/
├── Code Style Guidelines.md
├── How to Write a TIP.md
├── Onboarding.md
└── Refactoring & Programming Principles.md
_plans/
.github/
└── copilot-instructions.md
CLAUDE.md

Assurez-vous que votre projet est sauvegardé dans le système de gestion de versions et que l'état du répertoire de travail est propre.

À partir d'ici, nous « vibe coderons » ce que nous pourrons. Parce que, eh !, c'est l'esprit ! Donnez ce prompt à votre agent :

Create two directories `_docs` and `_plans` at the root of the repository. If a `.gitignore` file exists, add `_plans` to it.

Le fichier Onboarding.md

Le premier jet du guide d'intégration (« onboarding guide ») de votre projet sera généré grâce à une commande fournie par VS Code :

1. Dans VS Code, appuyez sur Ctrl+Shift+P (ou Cmd+Shift+P sur Mac) et recherchez « Chat: Generate Workspace Instructions File ». Cette commande vous fournit un prompt qui génèrera un nouveau fichier .github/copilot-instructions.md.
2. … Mais nous allons déplacer le contenu de ce fichier. Voici le prompt :

Empty the `.github/copilot-instructions.md` file, move its content into a new file `_docs/Onboarding.md`. Leave the `copilot-instructions.md` file empty. Also, change the title to `# Onboarding Guide`.

Le fichier Code Style Guidelines.md

Il nous faut des conventions de codage. Envoyez la sauce :

You are tasked to write a new file `_docs/Code Style Guidelines.md` that will contain the code style rules of this repository. If there is any information about code style in `_docs/Onboarding.md`, extract it. Also explore the codebase to deduce existing code style rules. Do not invent any rule that is not observed in the codebase. The rules must be short, in the form of bullet list(s).

Le fichier Refactoring & Programming Principles.md

Vous aurez l'occasion de le découvrir : les agents de programmation sont têtus pour certaines choses, comme les commentaires qui répètent inutilement le code. Ils préfèrent aussi paresseusement dupliquer et complexifier le code plutôt que de refactoriser, quand bien même ils en seraient parfaitement capables ! C'est pourquoi nous avons besoin d'un document pour inciter à la refactorisation. Nous commencerons par le faire générer, mais vous aurez bien entendu l'occasion de le réécrire dans le but de limiter les défauts de l'agent qui vous embêteront le plus. Surfons sur la vibe avec :

Write a new file `_docs/Refactoring & Programming Principles.md`. This will be a prompt that an AI agent will read when it is asked to refactor. It should contain the principles of refactoring and programming, such as SRP (Single Responsibility Principle), DRY (Don't Repeat Yourself), and YAGNI (You Aren't Gonna Need It). Be concise and clear. Do not use bullets on this one. Just a title level 2 and a short paragraph for each principle should be fine. The SRP principle is the most important, emphasis it and explain that big functions with inline comments should be rewritten into small well-named functions.

Le fichier How to Write a TIP.md

Nous allons récupérer ce document-ci depuis un projet open-source qui occupe mon temps libre. Il s'agit d'une procédure qui détaille comment rédiger un plan d'implémentation approfondi que l'on désignera par « TIP ». Même si on veut reprendre le fichier tel quel, ce n'est pas une raison pour le faire nous-même :

Create a new file `_docs/How to Write a TIP.md`. Fetch its content from here: https://gitlab.com/paroi/opensource/paroicms/-/raw/main/_docs/How%20to%20Write%20a%20TIP.md

Une remarque : j'utilise l'acronyme « TIP » pour « Thorough Implementation Plan », afin de distinguer ce type de plan d'implémentation particulier. En effet, l'agent IA a également ses propres règles de rédaction de plans d'implémentation, il faut pouvoir faire la différence.

Le fichier CLAUDE.md

Désolé, je vais vous mettre à contribution sur celui-là. Créez un fichier CLAUDE.md (attention à la casse), à la racine de votre dépôt, avec le contenu suivant (remplacez « YourProjectName » par le nom de votre projet) :

# YourProjectName Development Instructions

Always read `_docs/Onboarding.md` before anything else. Then, you MUST select the relevant internal documentation files and read them ENTIRELY.

## Internal documentation

Most frequently consulted procedures:

- `_docs/Code Style Guidelines.md` - ALWAYS READ BEFORE CODING

Additional procedures (read as needed):

- `_docs/How to Write a TIP.md` - A TIP (for _Thorough Implementation Plan_) is a special kind of implementation plan

Architecture and design documents:

- `_docs/Refactoring & Programming Principles.md` - How to apply SRP, DRY, YAGNI

Au fur et à mesure que vous apprendrez à travailler avec l'agent IA, vous rédigerez ou ferez rédiger des documentations pour un nombre croissant de procédures, sous la forme de documents « How to XXX.md ». Ensuite, référencez ces fichiers ici dans le fichier CLAUDE.md en ajoutant des entrées dans la liste des procédures.

Pourquoi ce fichier CLAUDE.md ? C'est le fichier de documentation de Claude Code. L'agent IA d'Anthropic a été un précurseur, il est toujours le grand champion de sa catégorie. Alors honneur aux anciens ! Dans ce tutoriel, j'ai voulu montrer comment rendre disponible une même documentation pour plusieurs agents IA. Et je propose le fichier CLAUDE.md comme point d'entrée commun de la documentation des agents IA.

Le fichier copilot-instructions.md

Dans le fichier .github/copilot-instructions.md, laissez un simple message :

[Read these instructions](../CLAUDE.md)

---
alwaysApply: true
---

ALWAYS read the instructions in `CLAUDE.md` ENTIRELY.

Surveiller la consommation des requêtes premium

Nous utilisons Claude Sonnet 4 qui est un modèle premium. Aussi, il faut commencer à surveiller le niveau de consommation des requêtes premium car il y a une limite mensuelle. Cliquez sur l'icône du chat située en bas dans la barre latérale. Repérez le pourcentage de requêtes premium restantes pour le mois en cours.

Astuce : même s'il ne s'agit pas de vibe coding à proprement parler, n'hésitez pas à débloquer toute l'assistance à la programmation en cochant les cases de ce dialogue.

« Vibe coder » une fonctionnalité

Implémenter une fonctionnalité, cela commence par la rédaction de spécifications. Lorsque cela est fait, n'oublions pas qu'un agent de programmation IA est, à chaque nouvelle session, un nouveau venu. Même après qu'il ait lu la documentation, on ne lâche pas un nouveau venu sur une base de code existante en lui disant de faire comme il le sent. On lui demande comment il envisage de traiter le problème (c'est le plan d'implémentation), on en discute avec lui. Ensuite on le laisse travailler. À la fin, on vérifie le travail.

Les étapes sont alors les suivantes :

1. Écrire des spécifications techniques ;
2. Faire générer un plan d'implémentation ;
3. Relire le plan et demander à l'agent de le corriger si nécessaire ;
4. Faire appliquer le plan ;
5. Revue de code et demandes de corrections à l'agent IA.

1. Écrire des spécifications techniques

Cette première étape est essentielle et, si elle est bien faite, alors elle est celle qui demande le plus de temps et d'effort de votre part. Rédiger un bon prompt prend de quelques minutes à plusieurs heures. Afin d'historiser les décisions, le bon endroit pour rédiger est d'ordinaire un logiciel de gestion de tickets.

Détaillez comme vous le feriez s'il s'agissait de donner des indications à un développeur sans expérience sur le projet (mais ayant lu la documentation). Ces sections se retrouvent souvent dans mes prompts :

• Une description du comportement qui est implémenté actuellement ;
• La description du comportement attendu après la modification ;
• Les parties du code à lire et à modifier, avec des chemins vers des fichiers sources ou bien une chaîne de caractères de recherche ou une autre manière de les trouver.

Si des consignes identiques doivent être mentionnées systématiquement, amendez les conventions de codage (Code Style Guidelines.md) ou le fichier How to Write a TIP.md plutôt que de les répéter à chaque nouvelle spécification.

Vous trouverez des exemples de prompts de spécifications techniques dans ces tickets.

2. Faire générer un plan d'implémentation

Ici, il faut prendre conscience de l'importance de la « zone de contexte ». Vous ne souhaitez pas que l'agent IA mélange les informations de votre prompt avec celles qu'il a déjà lues sur les tâches précédentes. Vous devez donc repartir d'une session neuve, en cliquant sur le bouton « ＋ » (Nouveau chat).

Initialisez un nouveau chat (« ＋ ») puis écrivez simplement :

Write a TIP. Here are the specs:


[collez vos spec. ici]

Cela aura pour effet de générer un plan d'implémentation dans le dossier _plans.

3. Relire le plan d'implémentation

Relisez attentivement le plan d'implémentation. Discutez des solutions techniques possibles avec votre agent, demandez-lui de le corriger ou de le compléter si nécessaire. En dernier recours, vous corrigerez le plan vous-même à la main, ça arrive.

Je demande parfois de l'aide à un autre agent, et notamment Claude Code, pour m'aider à relire et compléter un plan. Mais plus un plan est complexe et plus il importe de faire l'effort de le comprendre. Sous peine de passer ensuite plus de temps à (faire) corriger qu'à implémenter vous-même. N'espérez jamais qu'un problème complexe puisse se résoudre comme par magie sans que vous n'ayez à comprendre comment !

4. Faire appliquer le plan

Pensez toujours à enregistrer dans le système de contrôle de version (git commit) tous vos éventuels changements en cours avant de demander à l'agent IA d'appliquer un plan d'implémentation. Cela permet de revenir en arrière en cas de problème. Cela permettra aussi de regarder le diff entre le code avant et après l'application du plan.

Initialisez un nouveau chat (« ＋ »), glissez-déplacez le fichier du plan d'implémentation dans le chat, ou bien ouvrez-le et assurez-vous que le fichier ouvert est bien visible par l'agent, puis écrivez :

Apply this implementation plan

Le cas échéant, n'hésitez pas à interrompre l'agent dès que vous vous apercevez qu'il va dans une mauvaise direction. Expliquez-lui ce qui ne va pas, il continuera sa session en prenant en compte votre message.

Avant d'exécuter un plan, relancez toujours une nouvelle session de l'agent. D'abord pour éviter la contamination des informations entre tâches, car cela vous empêcherait d'obtenir un résultat cohérent si vous deviez relancer un plan amendé après un échec. Ensuite parce que l'agent IA devient parfois moins fiable et plus confus lorsque sa fenêtre de contexte se remplit. De plus, en fin de contexte, l'agent se résume automatiquement la situation à lui-même puis relance une session neuve en lui passant le résumé, ce qui augmente l'incertitude sur le résultat ; mieux vaut éviter d'atteindre trop vite cette limite.

Une astuce : le travail de l'agent IA sur votre base de code peut parfois être bloquant puisque votre projet est en train d'être édité et ne compile ou ne s'exécute plus. Si vous vous demandez quoi faire pendant que l'agent fait son travail, mettez ce temps à profit pour rédiger les spécifications techniques des prochaines fonctionnalités. Toutefois, gardez un œil sur ce que fait votre agent.

5. Revue de code et demandes de corrections à l'agent IA

Il arrive que la fonctionnalité implémentée marche du premier coup, et c'est fun ! Mais sur le plan de la qualité du code, ne laissez rien passer. N'acceptez pas du code qui serait moins bon que ce que vous auriez écrit vous-même. Ne faites pas non plus l'impasse sur du code que vous ne comprenez pas : au besoin, si vous vous êtes aventuré loin de votre zone de confort, c'est éventuellement le moment d'apprendre. Quoi qu'il en soit, vous restez responsable du code que vous commitez de la même manière que le conducteur doit garder le contrôle de son véhicule : en cas d'accident, le comportement de la voiture n'est pas une bonne excuse, celui qui utilise l'outil est toujours responsable.

Lorsque vous demandez à l'agent IA de corriger des choses, vous pouvez ensuite lui faire amender la documentation du projet avec ce qu'il a appris. Par exemple :

Update the Code Style Guidelines file with what you've learned.

Il faut parfois terminer le travail à l'ancienne, c'est-à-dire à la main. Sur les tickets difficiles, dans une base de code complexe, l'agent passe à côté de beaucoup de choses. Avec l'expérience vous pourrez anticiper la situation mais non l'éviter. L'agent peut toutefois dégrossir le travail. Et surtout, au fil des mises à jour, sa performance s'améliore à pas de géant.

Conseils & réflexions

Ce que vous risquez si vous ne surveillez pas l'agent IA pendant son travail ?

• Rappelez-vous que dans l'étape de configuration, nous avons désactivé les protections, donc l'agent pourrait lancer des outils dangereux en ligne de commande ;
• Il peut aussi se retrouver bloqué dans une boucle infinie en cherchant une solution à un problème sans la trouver, et consommer ainsi une large part, voire la totalité de vos requêtes premium.

Faites attention aux prompts malintentionnés. Ne lancez pas aveuglément votre agent sur un projet inconnu. Et soyez vigilant à chaque fois que vous lui demandez de rechercher des informations sur Internet.

Le système de gestion de versions est une garantie de sécurité, mais gardez à l'esprit que votre agent sait aussi l'utiliser.

La fenêtre de contexte d'un agent IA est limitée. Nous avons donc intérêt à minimiser la quantité de contexte injectée automatiquement. C'est-à-dire que le temps que vous passerez à rendre plus synthétiques les instructions les plus lues (CLAUDE.md, Onboarding.md) ne sera pas du temps perdu : il faut être à la fois concis et complet. Pour la même raison, mieux vaut séparer les documentations spécifiques dans des fichiers différents en demandant à l'agent de n'ouvrir que ce dont il a besoin.

Évitez ou limitez les ordres désagréables en majuscules dans la documentation. Gageons que les techniques pour forcer une IA à obéir seront de moins en moins pertinentes au fur et à mesure que les modèles de langage s'amélioreront. Votre documentation est là pour durer. Considérez que le contenu du dossier de documentation sera utile à tous les nouveaux-venus sur le projet, IA comme humains. Expliquez donc les choses normalement.

Il sera facile de garder la documentation à jour, vous demanderez à l'agent IA de le faire pour vous.

Le choix de nommer les répertoires _docs et _plans, ou encore l'acronyme « TIP », n'est pas une convention reconnue. Ce sont simplement le résultat de mon expérience et mes choix d'organisation. Il n'existe pas encore de bonnes pratiques en la matière. Je vous ai donné les miennes, adaptez librement.

Si vous vous demandez pourquoi j'insiste sur Claude Sonnet 4, essayez avec un modèle moins premium et vous aurez vite la réponse.

Pour ma part, j'écris mes prompts et la documentation, tout comme le code, en anglais. Mais le français marchera très bien également.

En guise de conclusion, je souhaite ouvrir sur le TDD, dont la version vibe coding est voisine du plan d'implémentation. C'est très efficace pour implémenter un algorithme dans une fonction. Les tests unitaires remplacent alors le plan d'implémentation. Le processus est similaire : 1. Écrire des spécifications. 2. Faire générer des tests unitaires, en précisant à l'agent de ne pas tenter de les exécuter. 3. Vérifier les tests, les faire compléter et modifier. 4. Faire générer une implémentation à partir des spécifications, l'agent doit faire en sorte que les tests passent. 5. Revue de code et demandes de refactorisations car l'agent, en luttant pour faire passer certains tests, aura peut-être dupliqué des parties de code.

Happy Vibe Coding!

Retrouvez l'intégralité de ce tutoriel en ligne sur Alsacreations.com

Flux (rss): http://www.alsacreations.com/rss/actualites.xml