Blog FabLrc

Catégorie : CI/CD

  • Mon Workflow « Agentique » : De l’idée à la production

    Mon Workflow « Agentique » : De l’idée à la production

    Il y a quelques mois encore, j’utilisais l’IA comme un simple assistant : un super moteur de recherche ou un générateur de snippets. Mais les choses ont changé. Vite.

    Aujourd’hui, je ne « chat » plus vraiment avec mon IDE. Je collabore avec des Agents.

    Récemment, VSCode (ou Cursor si vous voulez) a intégré nativement la gestion des agents. Couplé à des modèles de raisonnement comme Claude Sonnet 4.5 ou Gemini Pro 3, et à la puissance des MCP (Model Context Protocol), ma façon de développer une application, de l’idée au déploiement, a été totalement transformée.

    Voici comment je développe mes applications aujourd’hui, étape par étape, sans jamais quitter mon éditeur.

    Using agents in Visual Studio Code

    Le Setup : Donner des super-pouvoirs à l’IA

    Avant d’écrire la moindre ligne de code, il faut équiper l’agent. Un modèle d’IA, aussi puissant soit-il, est limité par sa date de connaissance (training cut-off) et son isolement. Pour pallier cela, j’installe des MCP (Model Context Protocol).

    C’est le standard qui permet à l’IA de se connecter à des outils externes. J’en utilise principalement deux :

    • Context7 : C’est mon « bridge » vers la connaissance temps réel. Il permet à l’agent de consulter les documentations officielles les plus récentes. Fini le code React déprécié ou les hallucinations sur des API qui n’existent plus.
    • ChromeDevTools : Permet à l’agent de « voir » et debugger ce qui se passe dans le navigateur via la console ou des screenshots qu’il prend lui même.
    • Supabase, Stripe, MongoDB : J’utilise Supabase pour plusieur de mes projets, un MCP existe permettant aux agents de l’utiliser « nativement ». C’est la même chose avec pas mal de technologies actuelles, je vous invite à les utiliser selon les projets, vos agents n’en seront que plus efficaces !

    La Mémoire du Projet : Le dossier .github/instructions

    C’est mon secret pour éviter que l’IA ne devienne amnésique ou incohérente au bout de 30 messages.

    L’IA a une fenêtre de contexte limitée. Plutôt que de répéter « N’oublie pas qu’on utilise Tailwind » à chaque prompt, je crée un dossier .github/instructions à la racine de mon projet. Les agents VSCode lisent ces fichiers systématiquement avant de répondre.

    J’y place généralement :

    • tech_stack.md : La liste de mes technos (Next.js, Supabase, Shadcn/ui…).
    • arch.md : L’architecture du projet (les connexions avec les APIs, les dossiers du projets, …)
    • project_rules.md : Mes principes de design (DRY, composition over inheritance, gestion des erreurs).
    • plan.md : L’état d’avancement(roadmap) du projet (on y reviendra).

    C’est la mémoire à long terme de mon assistant.

    Phase d’Idéation : Challenger le concept

    Tout commence par une discussion, mais pas n’importe laquelle. J’active le modèle Gemini Pro 3, GPT 5.2 ou Claude Opus 4.5 (pour leur capacité de raisonnement supérieure) et je lance un prompt de challenge.

    Voici un exemple de prompt :

    Objectif : obtenir une analyse complète, structurée et objective d’une idée d’application pour décider de sa viabilité commerciale et stratégique.

    Instructions pour l’IA :
    Tu es un analyste de marché expert, combinant des compétences en stratégie, business model, étude de concurrence, finance, tarification, estimation des coûts, et validation de produit. Je te fournis ci-dessous une idée d’application ; tu dois évaluer sa viabilité sur le marché réel, en étant objectif et précis.

    1. Résumé de l’idée (à remplir)
    Nom de l’application :
    Description succincte :
    Problème que l’application résout :
    Public cible :

    2. Analyse de marché

    • Estime la taille du marché adressable (TAM/SAM/SOM) avec des données ou chiffres du secteur (sources publiques, tendances).
    • Décris les tendances du marché, croissance, demandes émergentes, et si le problème existe dans la réalité.
    • Identifie les indicateurs de demande, comme volume de recherche, communautés/plateformes où le problème est discuté, signaux d’intérêt (forums, social), etc.

    3. Concurrence

    • Liste les principaux concurrents directs et indirects (produits/services similaires).
    • Compare leurs offres, fonctionnalités, positionnement, forces et faiblesses.
    • Évalue les barrières à l’entrée (propriété intellectuelle, effets réseaux, coût d’acquisition, licences).

    4. Business Model & Tarification

    • Propose plusieurs modèles de monétisation plausibles (SaaS, freemium, abonnement, commission, publicité, etc.).
    • Pour chaque modèle, suggère plages de prix réalistes basées sur le marché actuel.
    • Estime les marges unitaires (par utilisateur/transaction) avec hypothèses de coûts variables et fixes.

    5. Coûts & Temps de Développement

    • Estime le coût de développement (MVP, version 1) : main-d’œuvre, tech stack, design, tests, infrastructure.
    • Donne une plage de durée réaliste de la phase MVP jusqu’à une première version exploitable (en semaines/mois).
    • Identifie les ressources ou compétences nécessaires (dev, product, marketing, support).

    6. Acquisition & Distribution

    • Propose des canaux efficaces pour acquérir les premiers utilisateurs et tester rapidement l’offre (ex. pubs, référencement, réseaux pro, partenariats).
    • Estime un coût d’acquisition client (CAC) réaliste selon les canaux.
    • Donne une stratégie de go-to-market progressive (phase beta, early adopters, scaling).

    7. Scénarios Financiers

    • Présente 3 scénarios (pessimiste / réaliste / optimiste) avec :
      • Nombre d’utilisateurs sur 12 mois
      • Revenus estimés
      • Coûts (fixes + variables)
      • Point mort financier (break-even)

    8. Risques & Opportunités

    • Identifie risques majeurs (technique, réglementaire, marché, concurrence) et stratégies pour les atténuer.
    • Détaille opportunités supplémentaires (extensions de produit, marchés adjacents).

    9. Recommandation Finale

    • Sur une échelle de 1 à 10, donne une note de viabilité commerciale globale.
    • Résume conditions pour poursuivre (ex : validations à faire, données manquantes, prochaines étapes).

    Format de réponse attendu :
    Réponse structurée par section, avec chiffres ou sources quand c’est possible, hypothèses indiquées clairement, et recommandations concrètes (pas seulement théoriques).

    L’agent me force à affiner mon tir avant même de coder. Une fois l’idée validée, on passe à la structure.

    Planification : Le mode « Plan » de VSCode

    Une fois l’idée validée, il va falloir planifier le développement de celle-ci pour en faire une application fonctionnelle (ou dans un premier temps un bon MVP). Pour ça, vous pouvez utiliser le mode « plan » dans VSCode. C’est une fonctionnalité native de VSCode que j’adore. Je ne saute pas dans le code.

    Ici, je demande à l’agent de rédiger le PRD (Product Requirements Document). On définit ensemble :

    1. Le MVP (Minimum Viable Product) : Qu’est-ce qu’on livre en premier ?
    2. Les User Stories : « En tant qu’utilisateur, je veux… »
    3. L’Architecture : Base de données, API, Authentification.

    L’agent génère un fichier PLAN.md. Ce fichier servira de boussole pour tout le reste du développement. Je le place donc dans mon dossiers « .github/instructions« 

    Voici un exemple de prompt pour le plan :

    Objectif :
    Construire un plan global, fonctionnel et non technique d’une application déjà validée sur le marché, décrivant précisément ce que fait l’application, pour qui, et comment les utilisateurs interagissent avec elle, jusqu’à obtenir une vision complète et cohérente du produit.

    Rôle de l’IA :
    Tu es un Product Manager senior spécialisé en conception d’applications (web / mobile / SaaS).
    Ton objectif est de transformer une idée validée en un plan fonctionnel détaillé, clair et structuré, sans écrire de code ni entrer dans des choix techniques.

    Tu dois :

    • Identifier les zones floues ou ambiguës
    • Poser des questions ciblées et utiles quand des informations manquent
    • Construire le plan progressivement, en itérant avec l’utilisateur
    • T’arrêter uniquement lorsque le plan est complet, cohérent et exploitable

    1. Contexte de départ (fourni par l’utilisateur)

    Nom de l’application :
    Objectif principal de l’application :
    Problème utilisateur résolu :
    Cible principale (utilisateurs) :
    Plateforme(s) envisagée(s) : (ex : mobile, web, desktop)

    2. Méthode de travail (obligatoire)

    • Commence par résumer ta compréhension du produit en quelques phrases
    • Identifie immédiatement :
      • Ce qui est clair
      • Ce qui est incomplet ou ambigu
    • Pose des questions avant d’aller trop loin si nécessaire

    ⚠️ Ne fais pas d’hypothèses critiques sans validation.
    Pose des questions plutôt que d’inventer.

    3. Structure attendue du plan fonctionnel final

    Tu devras produire, une fois toutes les informations réunies, un plan contenant au minimum :

    A. Vision Produit

    • Proposition de valeur principale
    • Objectifs du produit (court / moyen terme)
    • Règles fondamentales (ce que l’app fait / ne fait pas)

    B. Typologie des utilisateurs

    • Types d’utilisateurs (ex : visiteurs, utilisateurs inscrits, admins, etc.)
    • Droits et capacités de chaque type
    • Parcours général de chaque type d’utilisateur

    C. Parcours Utilisateur (User Journeys)

    • Découverte / arrivée sur l’app
    • Inscription / onboarding
    • Utilisation principale (cœur de valeur)
    • Actions récurrentes
    • Sortie / désengagement

    D. Fonctionnalités Clés

    Pour chaque fonctionnalité :

    • Objectif utilisateur
    • Description fonctionnelle (ce que ça permet de faire)
    • Déclencheur (quand / pourquoi l’utilisateur l’utilise)
    • Résultat attendu

    ⚠️ Pas de technique, pas de code, pas de stack.

    E. Règles Métier & Logique Fonctionnelle

    • Limitations
    • Cas particuliers
    • Conditions d’accès à certaines fonctionnalités
    • Interactions entre fonctionnalités

    F. Gestion des Contenus & Données (fonctionnel)

    • Types de données manipulées (sans schéma technique)
    • Qui crée quoi, qui voit quoi, qui modifie quoi
    • Logique de cycle de vie des contenus

    G. Notifications & Interactions

    • Types de notifications
    • Déclencheurs
    • Objectifs (engagement, information, rappel, etc.)

    H. Monétisation (si applicable)

    • Ce qui est gratuit vs payant
    • Déclencheurs de paiement
    • Parcours utilisateur lié à la monétisation

    I. Administration & Modération

    • Fonctionnalités nécessaires pour gérer l’app
    • Actions possibles côté admin
    • Contrôles et règles

    4. Processus itératif obligatoire

    • À chaque étape :
      • Si une information manque → pose une ou plusieurs questions précises
      • Attends la réponse avant de continuer
    • Reformule régulièrement pour valider la compréhension
    • Ne considère le plan terminé que lorsque toutes les sections sont complètes

    5. Critère de fin

    Le travail est terminé lorsque :

    • Le plan peut servir de base à un cahier des charges fonctionnel
    • Un designer ou un développeur peut comprendre ce que doit faire l’application
    • Aucune fonctionnalité majeure n’est floue ou implicite

    Commence maintenant par :

    1. Résumer ta compréhension du projet à partir des éléments fournis
    2. Lister les informations manquantes
    3. Poser les premières questions nécessaires

    Développement : L’Agent aux commandes

    C’est ici que la magie opère. Je passe en mode « Agent » avec Claude Sonnet 4.5. Ce modèle est redoutable pour le code.

    La règle d’or : Les Micro-tâches

    Je ne dis jamais « Crée toute l’application ». C’est le meilleur moyen d’obtenir du code spaghetti.

    Je découpe le travail :

    « Implémente la User Story #1 : La page de Login avec Supabase Auth. »

    Exécution et Auto-correction (Self-Healing)

    L’agent va :

    1. Lire mes instructions (.github/instructions).
    2. Générer le code des composants.
    3. Lancer des commandes terminal.

    C’est là que c’est fort : si je lui demande de lancer un npm run lint ou un test et que ça échoue, l’agent lit l’erreur et se corrige lui-même. Il itère jusqu’à ce que la tâche soit verte.

    Grâce au MCP Context7, s’il a un doute sur une nouvelle fonction de Next.js 16, il va lire la doc officielle avant d’écrire le code, m’évitant des heures de debugging.

    Sécuriser l’avancée : Git et Tests

    Travailler avec des agents va vite, très vite. Parfois trop. Pour ne pas perdre le contrôle :

    1. Tests automatisés : J’exige de l’agent qu’il crée un test unitaire pour chaque feature critique. C’est mon filet de sécurité pour m’assurer que les nouvelles modifications ne cassent pas ce qui marchait 5 minutes avant.
    2. Commit Atomique : Dès qu’une micro-tâche est validée et que les tests passent -> Git Commit.Si l’agent part en vrille à l’étape suivante (ça arrive), je fais un simple rollback. Git est mon bouton « Sauvegarde ».

    Déploiement : L’Agent DevOps

    Une fois le MVP prêt, je ne change pas de méthode. Je demande à l’agent :

    « Prépare le déploiement sur Vercel. Vérifie que les variables d’environnement sont bien configurées dans le projet et génère le Dockerfile si nécessaire. »

    L’agent interagit avec les CLI, prépare les configs, et je n’ai plus qu’à valider le push sur GitHub qui déclenchera la CI/CD.

    Conclusion

    Ce workflow a radicalement changé ma productivité. Je ne tape plus autant de code « boilerplate », mais je passe plus de temps à concevoir, vérifier et guider.

    VSCode, avec ses modes natifs (Plan, Agent, Edit) et la puissance des modèles comme Claude Sonnet 4.5, devient plus qu’un éditeur : c’est un véritable cockpit de pilotage.

    Et vous, vous avez testé les MCP ? Dites-moi en commentaire quel est votre setup !

  • Automatiser vos déploiements (CI/CD) avec GitHub Actions

    Automatiser vos déploiements (CI/CD) avec GitHub Actions

    Les pipelines CI/CD (Continuous Integration / Continuous Delivery) sont devenus un standard incontournable du développement moderne. Ils assurent la qualité du code et accélèrent la mise en production.

    GitHub Actions offre une solution puissante et native pour orchestrer ces pipelines directement depuis votre dépôt GitHub, sans avoir besoin d’outils externes complexes comme Jenkins.

    Comprendre le CI/CD en un coup d’œil

    Avant de plonger dans le code, rappelons les concepts :

    • Continuous Integration (CI) : C’est le filet de sécurité. À chaque modification du code (push ou Pull Request), on compile le projet et on lance les tests automatiquement.
    • Continuous Delivery (CD) : C’est l’automatisation de la livraison. Si la CI est validée (tests au vert), le code est automatiquement déployé sur un serveur de test ou de production.

    Le principe clé : Si le code échoue à la compilation ou si un test ne passe pas, le processus s’arrête immédiatement. On ne déploie jamais une erreur.

    GitHub Actions : Comment ça marche ?

    GitHub Actions fonctionne via des Workflows (fichiers YAML) situés dans le dossier .github/workflows/. Pour bien comprendre la structure, il faut connaître ce vocabulaire :

    Action : Un script réutilisable (ex: actions/checkout pour récupérer le code).

    Workflow : Le processus automatisé complet (ex: « Déploiement Production »).

    Event (on) : L’événement qui déclenche le workflow (ex: un push sur main).

    Job : Une série d’étapes exécutées sur un même serveur (Runner).

    Step : Une tâche individuelle (ex: lancer une commande npm install).

    Cas pratique : Mettre en place la CI (Tests)

    Voici un workflow classique pour une application Node.js. Il s’assure que le code est sain avant toute chose.

    name: CI Test

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest # Le système d'exploitation virtuel

    steps:
      # Étape 1 : Récupérer le code
      - name: Checkout code
        uses: actions/checkout@v4

      # Étape 2 : Installer l'environnement
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20' # Toujours utiliser une version LTS récente
          cache: 'npm'       # Astuce : met en cache les node_modules pour aller plus vite

      # Étape 3 : Installation et Tests
      - name: Install dependencies
        run: npm ci # 'npm ci' est plus fiable que 'npm install' pour les pipelines
      
      - name: Run tests
        run: npm testLangage du code : YAML (yaml)

    Cas pratique : Le Déploiement (CD)

    Une fois le code validé, nous voulons le déployer. Pour cet exemple, nous utiliserons SCP pour copier les fichiers vers un serveur Linux classique.

    Sécurité avant tout : Ne mettez jamais de mots de passe en clair dans vos fichiers YAML. Utilisez les GitHub Secrets (Settings > Secrets and variables > Actions).

    name: Deploy to Server

on:
  push:
    branches: [ "main" ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    # Optionnel : attendre que la CI passe avant de déployer
    # needs: build-and-test 

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      # Imaginez ici une étape de "Build" (ex: npm run build) qui génère un dossier dist/

      - name: Copy files to server
        uses: appleboy/scp-action@master
        with:
          host: ${{ secrets.SERVER_IP }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          source: "dist/"
          target: "/var/www/myapp"
          strip_components: 1 # Pour éviter de copier le dossier parent "dist"Langage du code : YAML (yaml)

    L’astuce Pro : Tester en local avec Act

    L’un des plus grands défis des pipelines CI/CD est le cycle « commit > push > attendre l’erreur > recommencer« . L’outil Act résout ce problème en vous permettant d’exécuter vos GitHub Actions localement via Docker.

    Pourquoi l’utiliser ?

    • Gain de temps immédiat (feedback loop rapide).
    • Pas de pollution de l’historique Git avec des commits « fix ci ».
    • Économie des minutes gratuites de GitHub Actions.

    Installation et utilisation :

    # Sur macOS
brew install act

# Lister les jobs disponibles
act -l

# Lancer le workflow complet
act
# Ou lancer un job spécifique
act -j build-and-testLangage du code : Bash (bash)

    Conclusion

    L’automatisation avec GitHub Actions n’est pas seulement un gain de temps, c’est une garantie de sérénité. En mettant en place ce pipeline :

    1. Vous détectez les régressions instantanément (CI).
    2. Vous déployez sans intervention manuelle risquée (CD).
    3. Vous sécurisez vos accès grâce aux Secrets.

    Commencez par un workflow simple de tests, puis ajoutez le déploiement une fois à l’aise. Votre « moi du futur » vous remerciera !