FORMA·IA
module 02 / 06

Vibe coding — bases

Passer du chat à l'agent : piloter un assistant de code sur de vraies tâches, avec un workflow qui garde le contrôle. On code toute la session.

2.0Objectifs de la session

2.1Les outils en pratique

Trois familles d'outils, trois façons de travailler. La démo de session couvre les trois modes : chat (discuter, explorer), agent (lire, modifier, exécuter dans le repo) et autocomplétion (compléter pendant la frappe).

OutilForcesLimites
Claude CodeAgent complet : multi-fichiers, exécute tests et commandes, CLI ou IDEDemande du cadrage — un agent mal briefé part loin
CursorIDE intégré, agent + complétion au même endroit, contexte visuelVerrouillé sur l'éditeur, contexte parfois implicite
CopilotAutocomplétion rapide, boilerplate, zéro frictionVision locale : ne comprend pas l'architecture du projet

Permissions et sandbox

Un agent exécute des commandes sur votre machine. Les outils sérieux demandent permission avant chaque action sensible (écrire un fichier, lancer une commande) ou travaillent en sandbox. Réflexe : comprendre ce que l'agent s'apprête à faire avantd'approuver — jamais de mode « tout accepter » sur un repo de prod.

2.2Le workflow spec → plan → code → review

Le cœur de la session. Quatre étapes, aucune ne se saute :

  1. Spec— dire quoi et pourquoi : périmètre, contraintes, critères d'acceptation. Deux phrases floues = code flou.
  2. Plan — faire écrire le plan avant le code : fichiers touchés, approche, étapes. On corrige un plan en 30 secondes, un mauvais code en 30 minutes.
  3. Code— laisser l'agent implémenter par petites étapes, tests inclus. Itération courte : une étape, on vérifie, on continue.
  4. Review— lire le diff comme celui d'un collègue. Lancer les tests. C'est vous qui signez le commit.

Une session type

vous  > Je veux ajouter un endpoint GET /users/:id/orders à cette API
        Fastify. Pagination par cursor, réponse typée. Propose-moi un plan
        AVANT d'écrire du code.

agent > Plan : 1. schéma de réponse dans src/schemas/orders.ts
               2. route dans src/routes/users.ts, réutilise le plugin auth
               3. requête paginée dans src/db/orders.ts
               4. tests vitest : cas nominal, cursor invalide, user inconnu

vous  > OK mais la pagination existe déjà dans src/db/pagination.ts,
        réutilise-la. Vas-y étape par étape.

agent > [implémente l'étape 1, montre le diff]
vous  > [lit, valide, l'agent enchaîne — tests verts à la fin]
La règle d'or : le plan d'abord« Propose un plan avant d'écrire du code » est la phrase la plus rentable du vibe coding. Elle expose les mauvaises hypothèses de l'agent (fichier inventé, lib absente, périmètre trop large) quand elles ne coûtent encore rien.

2.3Confiance et vérification

La confiance dans le code généré n'est pas binaire — elle se calibre selon la nature du code :

Type de codeConfianceVérification
BoilerplateHaute — config, DTO, mappings, scaffoldingLecture rapide du diff, compile
Logique métierMoyenne — le modèle ne connaît pas vos règlesLecture attentive + tests sur les cas limites
Sécurité / crypto / paiementBasse — zone à hallucinations plausiblesReview humaine systématique, jamais en autonomie
Le danger n°1 : le code plausible non luLe code généré a l'airjuste — c'est sa spécialité. Copier sans lire, c'est introduire des bugs qu'on ne saura pas déboguer, dans du code qu'on ne comprend pas. Si vous ne pouvez pas expliquer une ligne, vous ne pouvez pas la merger.

2.4Bonnes pratiques de session

Savoir repartir de zéroQuand une session dérive — l'agent tourne en rond, empile les rustines, réécrit ce qui marchait — n'insistez pas. git checkout sur le dernier commit sain, nouvelle session, meilleur brief. Trois échanges de correction infructueux = signal de reset.

2.5TP de la session

Dossier exercices/session-2/ du repo. Au programme :

2.6Checklist de fin de session

2.7Quiz de validation

Q1L'ordre correct du workflow de base est…

Q2L'agent génère une fonction de vérification de signature de webhook (paiement). Vous…

Q3Pourquoi exiger un plan avant le code ?

Q4Après trois tentatives, l'agent empile des correctifs et re-casse ce qu'il répare. Le bon réflexe :

2.8Défi inter-session

D'ici la prochaine sessionLivrer une petite feature réelle de votre backlog avec le workflow complet spec → plan → code → review. Garder une trace du plan produit par l'agent (copie brute) : on comparera plans et résultats en ouverture de session 3.