Vibecoding et développement agentique AI

Programme

Ouvrez un module pour en lire les leçons. Chaque module se termine par un test, et l’examen final délivre l’attestation.

1. Module 1

   Le vibecoding et le paysage des IA de code

   - Expliquer ce qu'est le vibecoding, ce qu'il permet réellement et ce qu'il ne permet pas. - Décrire en mots simples comment une IA arrive à écrire du code, et pourquoi elle se trompe. - Nommer les grandes pièces d'une application et dire à quoi chacune sert. - Distinguer les trois familles d'outils d'IA de code et reconnaître à laquelle appartient un outil donné. - Choisir un outil d'IA de code en vous appuyant sur quatre grilles : le coût, la performance, le rapport performance/prix et le type d'application à construire. - Justifier votre choix devant un client ou un employeur, avec des arguments et non des impressions. - Expliquer pourquoi cette formation a retenu Claude Code, et comment la suivre avec un autre outil si nécessaire.

   • Le vibecoding : ce que c'est, ce que ce n'est pas
   • Comment une IA « comprend » du code
   • Anatomie d'une application
   • Les trois familles d'outils d'IA de code
   • Choisir selon le coût
   • Choisir selon la performance
   • Choisir selon le rapport performance/prix
   • Choisir selon le type d'application
   • Notre choix pour cette formation : Claude Code
   • Travaux pratiques — Votre fiche de choix d'outil
   • Synthèse, lexique et ressources du module
   • Résumé du modulepdf
2. Module 2

   Choisir son langage et son framework

   - Expliquer la différence entre un langage, un framework et une bibliothèque, sans jargon. - Situer un projet sur l'un des six terrains du développement. - Dire, pour chaque grand langage, ce qu'il fait bien et le type d'application qui lui convient. - Faire de même pour les principaux frameworks. - Choisir une technologie à partir du cahier des charges, avec un arbre de décision. - Prendre en compte les critères que les débutants oublient : hébergement, maintenance, compétences disponibles localement, taille de la communauté, coût de sortie. - Refuser une technologie à la mode proposée par l'IA, et lui imposer la vôtre. - Expliquer la stack retenue pour cette formation, et l'alternative prévue.

   • Langage, framework, bibliothèque : la différence
   • Les six terrains du développement
   • Les langages et ce qu'ils font bien
   • Les frameworks et leur spécialité
   • Les briques autour du framework
   • L'arbre de décision : du cahier des charges à la stack
   • Les critères que l'on oublie
   • Refuser la technologie à la mode que l'IA propose
   • Notre choix pour cette formation
   • Travaux pratiques — Trois cahiers des charges, trois stacks
   • Synthèse, lexique et ressources du module
   • Résumé du modulepdf
3. Module 3

   Choisir son éditeur et monter son atelier

   - Expliquer à quoi sert un éditeur de code quand c'est l'IA qui écrit. - Nommer les quatre zones de la fenêtre de travail et dire ce que chacune vous apprend. - Comparer les éditeurs sur des critères qui comptent vraiment : prix, ressources exigées, tolérance à une connexion instable, intégration de l'IA. - Décider ce qui convient à votre machine et à votre connexion. - Installer de bout en bout votre atelier : éditeur, Node.js, Git, Claude Code, et le compte qui va avec. - Utiliser le terminal avec douze commandes — pas une de plus. - Organiser vos projets pour ne jamais perdre votre travail ni dérouter l'IA. - Vérifier vous-même que tout fonctionne, avec une liste de contrôle.

   • À quoi sert un éditeur quand c'est l'IA qui écrit
   • Comparer les éditeurs sur ce qui compte
   • Machine modeste et connexion capricieuse
   • Notre choix pour cette formation
   • Installation guidée, étape par étape
   • Le terminal en douze commandes
   • Organiser son poste de travail
   • La liste de contrôle : vérifier que tout marche
   • Travaux pratiques — Votre atelier, monté et validé
   • Synthèse, lexique et ressources du module
   • Résumé du modulepdf
4. Module 4

   Le contrat avec l'IA : les règles du projet

   - Expliquer, avec trois exemples concrets, ce qu'un agent sans règles fait à un projet. - Dire dans quel fichier chaque outil d'IA lit ses règles, et écrire ce fichier au bon endroit. - Distinguer les portées — organisation, vous, le projet, un sous-dossier — et savoir laquelle s'applique. - Utiliser `AGENTS.md` pour n'écrire vos règles qu'une seule fois, même en changeant d'outil. - Rédiger un fichier de règles complet : contexte, technologies imposées, conventions, commandes, périmètre. - Écrire la liste des interdits et celle des obligations, avec des formulations qui fonctionnent. - Expliquer ce que les règles ne peuvent pas faire, et ce qu'il faut utiliser à la place. - Faire évoluer vos règles à chaque dérapage, au lieu de répéter la même correction.

   • Ce qu'un agent sans règles fait à votre projet
   • Où chaque IA lit ses règles
   • La portée des règles : qui parle le plus fort
   • AGENTS.md : écrire ses règles une seule fois
   • Anatomie d'un bon fichier de règles
   • Les interdits : la liste des « ne jamais »
   • Les obligations : la liste des « toujours »
   • Ce que les règles ne peuvent pas faire
   • Faire évoluer ses règles
   • Travaux pratiques — Le fichier de règles de votre projet, mis à l'épreuve
   • Modèle à copier — Règles du projet — gestion-boutique
   • Synthèse, lexique et ressources du module
   • Résumé du modulepdf
5. Module 5

   Parler à l'IA pour coder

   - Construire une demande avec ses quatre éléments : contexte, objectif, contraintes, critère de réussite. - Découper une fonctionnalité en demandes qui réussissent du premier coup. - Donner à l'agent le contexte utile — sans gaspiller la fenêtre de contexte. - Décrire un écran que vous avez en tête, avec des mots et une capture. - Conduire le dialogue : interrompre, corriger, refuser, revenir en arrière. - Reconnaître une mauvaise réponse avant de l'accepter. - Éviter les huit demandes qui échouent toujours. - Utiliser une bibliothèque de formulations prêtes à l'emploi.

   • Les quatre éléments d'une bonne demande
   • La formule à copier, et l'effet avant/après
   • Découper : une demande = un changement vérifiable
   • Donner le contexte sans le gaspiller
   • Décrire un écran que vous avez en tête
   • Le dialogue : interrompre, corriger, refuser, revenir
   • Reconnaître une mauvaise réponse
   • Les huit demandes qui échouent toujours
   • La bibliothèque de formulations
   • Travaux pratiques — Cinq demandes à réécrire, une fonctionnalité à construire
   • Fiche mémo — Parler à l'IA pour coder
   • Synthèse, lexique et ressources du module
   • Résumé du modulepdf
6. Module 6

   Lire le code que l'IA écrit

   - Dire pourquoi il faut savoir lire du code même quand on ne sait pas en écrire. - Retrouver n'importe quel fichier dans un projet, sans chercher au hasard. - Reconnaître les cinq éléments présents dans presque tous les fichiers de code. - Lire une page entière avec la méthode des trois passes. - Lire un diff — ce qui a changé, et rien d'autre. C'est le geste central du module. - Comprendre les dix mots de vocabulaire qui suffisent à discuter avec un développeur. - Repérer un problème en trente secondes avec une grille de sept points. - Faire expliquer le code par l'IA — sans vous faire endormir par sa réponse. - Savoir ce que vous n'avez pas à lire.

   • Pourquoi lire, quand on ne sait pas écrire
   • L'arborescence : où vit quoi dans un projet
   • Les cinq éléments présents dans presque tout fichier
   • Lire une page : la méthode des trois passes
   • Lire un diff : ce qui a changé, et rien d'autre
   • Les dix mots de vocabulaire qui suffisent
   • Repérer un problème en trente secondes
   • Faire expliquer par l'IA, sans se faire endormir
   • Ce que vous n'avez pas à lire
   • Travaux pratiques — Trois fichiers à lire, trois défauts à trouver
   • Synthèse, lexique et ressources du module
   • Résumé du modulepdf
7. Module 7

   Le projet fil rouge : l'interface

   - Écrire un cahier des charges court qui tient en une page et qui sert vraiment. - Créer un projet Next.js et le lancer sur votre machine, sans rien installer au hasard. - Reconnaître l'arborescence de départ et savoir ce qui est à vous, ce qui ne l'est pas. - Faire construire votre première page et une navigation qui marche. - Comprendre ce qu'est un composant, et savoir quand en demander un. - Obtenir une mise en forme correcte sans être graphiste. - Travailler avec des données factices avant d'avoir la moindre base de données. - Rendre l'application utilisable sur téléphone. - Tenir la cohérence visuelle sur vingt écrans, pas seulement sur le premier.

   • Le cahier des charges qui tient en une page
   • Créer et lancer le projet
   • L'arborescence de départ : ce qui est à vous
   • Votre première page et la navigation
   • Les composants : arrêter de tout réécrire
   • La mise en forme sans être graphiste
   • Les données factices : construire avant d'avoir une base
   • Le responsive : l'application sur téléphone
   • Tenir la cohérence sur vingt écrans
   • Travaux pratiques — Construire trois écrans de gestion-boutique
   • Synthèse, lexique et ressources du module
   • Résumé du modulepdf
8. Module 8

   Git : le filet de sécurité

   - Expliquer le problème que Git résout, et pourquoi il est vital quand on code avec une IA. - Reconnaître les quatre états d'un fichier et savoir où il se trouve à tout moment. - Utiliser les six commandes qui couvrent 95 % du travail. - Écrire un message d'enregistrement qui vous servira dans six mois. - Revenir en arrière — sur un fichier, sur une modification, sur tout le projet. - Envoyer votre travail sur GitHub et le récupérer ailleurs. - Travailler sur une branche pour essayer quelque chose sans rien casser. - Configurer `.gitignore` pour ne jamais envoyer un secret ni un dossier inutile.

   • Le problème que Git résout
   • Les quatre états d'un fichier
   • Les six commandes qui suffisent
   • Écrire un message qui vous servira dans six mois
   • Revenir en arrière : les quatre situations
   • GitHub : la copie qui vit ailleurs
   • Les branches : essayer sans casser
   • .gitignore : ce qu'on n'envoie jamais
   • Travaux pratiques — Un dépôt, dix enregistrements, un retour en arrière
   • Synthèse, lexique et ressources du module
   • Résumé du modulepdf
9. Module 9

   Les données : base de données et back-end

   - Dire pourquoi une base de données n'est pas un fichier Excel amélioré. - Utiliser le vocabulaire juste : table, colonne, ligne, clé primaire, clé étrangère. - Dessiner les relations entre vos tables avant d'écrire la moindre ligne. - Créer un projet Supabase et ses tables, sans être administrateur de base de données. - Faire les quatre opérations depuis l'application : créer, lire, modifier, supprimer. - Brancher votre application Next.js sur la base, côté serveur. - Ranger vos clés dans des variables d'environnement, jamais dans le code. - Activer la sécurité au niveau de la ligne (RLS) et comprendre ce qu'elle protège. - Faire le même travail avec MySQL sur un hébergement mutualisé, si c'est votre contrainte.

   • Pourquoi une base de données, et pas un fichier
   • Le vocabulaire : table, colonne, ligne, clé
   • Les relations : le client et ses ventes
   • Créer son projet Supabase et ses tables
   • Les quatre opérations : créer, lire, modifier, supprimer
   • Brancher l'application sur la base
   • Les secrets : les variables d'environnement
   • RLS : la sécurité au niveau de la ligne
   • La variante MySQL sur hébergement mutualisé
   • Travaux pratiques — Trois tables, quatre opérations, une règle de sécurité
   • Synthèse, lexique et ressources du module
   • Résumé du modulepdf
10. Module 10

    Comptes utilisateurs et droits

    - Distinguer les deux questions que tout le monde confond : *qui es-tu ?* et *as-tu le droit ?* - Choisir une méthode de connexion adaptée à vos utilisateurs réels. - Mettre en place l'inscription et la connexion avec Supabase Auth. - Expliquer ce qu'est une session, où elle vit, et pourquoi `proxy.ts` existe. - Protéger une page au bon endroit — côté serveur, jamais seulement dans la page. - Définir des rôles et les stocker là où ils ne peuvent pas être falsifiés. - Écrire des règles RLS qui dépendent du rôle de l'utilisateur. - Reconnaître les six erreurs de sécurité que les agents IA commettent le plus souvent.

    • Authentification et autorisation : deux questions différentes
    • Les façons de se connecter, et laquelle choisir
    • Mettre en place l'inscription et la connexion
    • La session : où elle vit, et pourquoi `proxy.ts`
    • Protéger une page au bon endroit
    • Les rôles : où les stocker pour qu'ils tiennent
    • Les droits en base : RLS par rôle
    • Les six erreurs que les agents commettent
    • Travaux pratiques — Inscription, connexion, deux rôles, une page protégée
    • Synthèse, lexique et ressources du module
    • Résumé du modulepdf
11. Module 11

    Déboguer avec l'IA

    - Lire un message d'erreur au lieu de le copier sans le regarder. - Savoir où l'erreur s'affiche selon le symptôme : terminal, console, réseau, base. - Appliquer une méthode de diagnostic en cinq étapes, toujours la même. - Donner à l'agent exactement ce qu'il lui faut pour diagnostiquer — ni plus, ni moins. - Reconnaître les huit pannes les plus fréquentes et leur cause habituelle. - Repérer quand l'agent tourne en rond, et sortir de la boucle. - Retrouver le moment où ça marchait encore, par bissection. - Savoir quand arrêter et repartir d'un état sain plutôt que de continuer à réparer.

    • Le réflexe qui change tout : lire l'erreur
    • Anatomie d'un message d'erreur
    • Les quatre endroits où l'erreur s'affiche
    • La méthode de diagnostic en cinq étapes
    • Donner à l'agent ce qu'il faut pour diagnostiquer
    • Les huit pannes les plus fréquentes
    • Quand l'IA tourne en rond : sortir de la boucle
    • La bissection : retrouver le moment où ça marchait
    • Travaux pratiques — Trois pannes fabriquées, trois diagnostics
    • Synthèse, lexique et ressources du module
    • Résumé du modulepdf
12. Module 12

    Qualité, sécurité et données personnelles

    - Dire ce que « qualité » veut dire quand c'est une IA qui écrit le code. - Faire écrire des tests utiles — et reconnaître le test qui valide le bug. - Organiser une relecture de sécurité par une seconde session. - Gérer le cycle de vie d'un secret, de sa création à sa révocation. - Reconnaître les six failles que l'on retrouve dans presque toutes les applications de débutants. - Citer la loi burkinabè sur les données personnelles et dire ce qu'elle exige de vous. - Traduire ces obligations en décisions concrètes dans votre application. - Passer une liste de contrôle avant de livrer à un client.

    • Ce que « qualité » veut dire quand l'IA écrit
    • Les tests : ce qu'on teste, ce qu'on ne teste pas
    • Le piège du test qui valide le bug
    • La relecture de sécurité par une seconde session
    • Le cycle de vie d'un secret
    • Les six failles des applications de débutants
    • Les données personnelles : la loi burkinabè
    • Traduire la loi en décisions concrètes
    • Travaux pratiques — Audit complet de gestion-boutique
    • Synthèse, lexique et ressources du module
    • Résumé du modulepdf
13. Module 13

    Mettre en ligne

    - Dire ce que « mettre en ligne » veut dire, et ce qui change une fois que c'est fait. - Déployer une application Next.js depuis un dépôt Git, sans configuration manuelle. - Reporter correctement vos variables d'environnement chez l'hébergeur. - Choisir, acheter et brancher un nom de domaine — y compris un `.bf`. - Séparer préproduction et production, et savoir à quoi sert chacune. - Optimiser ce qui compte vraiment sur une connexion lente. - Mettre en place des sauvegardes et savoir les restaurer. - Chiffrer le coût mensuel réel d'une application, et l'annoncer à un client.

    • Ce que « mettre en ligne » veut dire vraiment
    • Le déploiement : du dépôt Git au site en ligne
    • Les variables d'environnement chez l'hébergeur
    • Le nom de domaine : choisir, acheter, brancher
    • Préproduction et production
    • La performance sur une connexion lente
    • Les sauvegardes, et la restauration
    • Ce que ça coûte réellement par mois
    • Travaux pratiques — Mettre gestion-boutique en ligne, de bout en bout
    • Synthèse, lexique et ressources du module
    • Résumé du modulepdf
14. Module 14

    Projet final, livraison et suite

    - Savoir ce qu'on attend du projet final, et comment il est noté. - Finaliser une application : la liste des choses qu'on croit finies et qui ne le sont pas. - Écrire les trois documents qui suffisent — et pas les trente qu'on n'écrira jamais. - Présenter votre travail en dix minutes, sans démonstration qui rate. - Définir le périmètre d'un projet, et le tenir. - Établir un devis qui distingue le développement, l'hébergement et la maintenance. - Annoncer à un client les limites du vibecoding, avant qu'il les découvre. - Situer votre responsabilité quand c'est une IA qui a écrit le code.

    • Ce qu'on attend du projet final
    • Finaliser : ce qu'on croit fini et qui ne l'est pas
    • La documentation : trois documents, pas trente
    • La démonstration : montrer en dix minutes
    • La grille de notation sur 100
    • Le périmètre : ce que vous vendez, et ce que vous ne vendez pas
    • Le devis et la maintenance
    • Les limites à annoncer au client
    • Éthique et responsabilité
    • Projet final — Finalisation et présentation
    • Grille de notation du projet final — Formation Vibecoding
    • Synthèse, lexique et ressources du module
    • Résumé du modulepdf