Formation Vibe Coding : créer des applications avec l’IA

Jour 1

1. Ce que change un assistant de développement

• Complétion, dialogue, agent dans le terminal : trois niveaux d’assistance.
• Ce que ces outils font bien, et les catégories d’erreurs qu’ils reproduisent.
• Pourquoi le code produit compile souvent et répond parfois à côté.
• Ce qui reste entièrement à votre charge : la responsabilité de ce qui part en production.
• Pratique : même fonctionnalité produite de trois façons, comparaison du résultat.

2. Cadrer avant de produire

• Décrire l’application : périmètre, données, utilisateurs, contraintes.
• Imposer sa pile technique et ses conventions plutôt que subir celles du modèle.
• Écrire les règles du projet une fois pour toutes.
• Découper en incréments dont chacun se vérifie.
• Pratique : cadrage écrit de son projet et découpage en étapes.

3. Produire par itérations

• Une demande, un incrément, une vérification.
• Garder le contrôle de l’arborescence et des fichiers touchés.
• Valider souvent avec Git, pour pouvoir revenir en arrière sans regret.
• Reprendre la main quand l’assistant s’enferre.
• Pratique : première version fonctionnelle de l’application.

4. Relire

• Une grille de relecture du code généré, et l’ordre dans lequel l’appliquer.
• Les signaux d’alerte : duplication, abstractions inutiles, gestion d’erreur absente.
• Le code qui passe les tests sans faire ce qu’on croit.
• Faire expliquer le code par l’assistant, et pourquoi cela ne suffit jamais.
• Pratique : revue complète du code produit, corrections.

Jour 2

5. Tester pour éprouver

• Faire produire des tests qui cherchent la faille plutôt que la confirmation.
• Cas limites, entrées invalides, données manquantes.
• Ce que la couverture ne dit pas.
• Automatiser l’exécution des tests dès le début du projet.
• Pratique : suite de tests sur l’application, et corrections des échecs.

6. Sécurité du code produit

• Les défauts les plus fréquents : validation d’entrées, gestion des secrets, contrôle d’accès.
• Les secrets qui finissent dans le dépôt, et comment ne pas en arriver là.
• Faire auditer son propre code, puis vérifier l’audit.
• Ce qui nécessite un regard humain quoi qu’il arrive.
• Pratique : revue de sécurité guidée sur l’application.

7. Dépendances et licences

• Pourquoi un assistant ajoute des bibliothèques sans qu’on le lui demande.
• Vérifier l’existence, la maintenance et la réputation d’une dépendance.
• Licences : ce qui vous engage sans que vous l’ayez lu.
• Réduire la surface avant la mise en service.

8. Livrer un projet reprenable

• Documentation minimale, journal des décisions, instructions d’installation.
• Ce qu’il faut expliquer à celui qui reprendra le projet dans un an.
• Dette technique : la reconnaître tôt plutôt que la découvrir tard.
• Droit d’auteur et confidentialité du code soumis à un assistant.
• Questions ouvertes et échanges avec le formateur.