Étape 5 · Mettre en ligne

/pulse:cicd

Mettre en place les contrôles automatiques : secrets, règles du code, tests et construction vérifiés à chaque envoi et sur chaque proposition de version parallèle, adaptés au fournisseur du dépôt distant ; puis, au choix, protéger la branche principale.

    Description

    Les contrôles automatiques, c'est un contrôle qualité qui tourne tout seul. À chaque envoi et sur chaque proposition de version parallèle, le site de votre dépôt (GitHub, GitLab…) vérifie que les secrets restent hors du code, que chaque scénario prévu a son test, que les bibliothèques n'ont pas de faille grave connue, que le code respecte les règles et que l'appli se construit.

    Une coche verte dit que tout va bien. Une croix rouge vous prévient avant que l'erreur n'arrive sur le site. Pulse écrit ces contrôles pour votre dépôt, les essaie d'abord sur votre ordinateur, puis les envoie. Il vous propose ensuite deux protections facultatives : n'accepter une version parallèle que si ses contrôles sont verts, et recevoir chaque semaine les nouvelles versions des bibliothèques.

    Contrôles à chaque envoi :
  1. Récupérer le code
  2. Installer l'environnement et les bibliothèques
  3. Secrets et scénarios     node scripts/verifier.js
  4. Failles connues          bibliothèques
  5. Règles du code
  6. Tests
  7. Construction

✅ Essayés sur votre ordinateur · prêts à envoyer

    Les étapes que /pulse:cicd met en place, dans l'ordre. Celles qui valent « aucune » dans votre projet sont sautées.

    La mise en ligne automatique à chaque envoi, elle, se règle avec /pulse:deploy. Les deux se complètent.

    Pourquoi l'utiliser

    • Une erreur est vue avant vos clients. La croix rouge apparaît sur le dépôt, pas sur le site.
    • Vos clés restent protégées. Le même contrôle des secrets s'exécute aussi avant chaque enregistrement, même fait hors de Claude Code.
    • Rien de nouveau à apprendre. Pulse utilise l'outil intégré à votre dépôt, déjà prêt et gratuit pour un petit projet.
    • Les failles connues sont corrigées plus tôt. Avec les mises à jour hebdomadaires, un robot propose les nouvelles versions, vérifiées par les contrôles avant que vous les acceptiez.

    Quand l'utiliser

    1. 1 Démarrer
    2. 2 Décrire
    3. 3 Préparer
    4. 4 Construire
    5. 5 Mettre en ligne
    6. 6 Être trouvé
    7. 7 À tout moment
    • Après le choix des outils (/pulse:tech) et une fois le projet de départ en place : les contrôles ont alors du code à vérifier.
    • Avant ou après la première mise en ligne : facultatif, mais conseillé dès que le site sert de vrais clients.
    • Quand vous publiez par versions parallèles (/pulse:pr) : chaque proposition reçoit sa coche ou sa croix.
    • Pour compléter des contrôles qui existent déjà : Pulse les lit et propose de les compléter, en gardant l'existant.

    Comment la lancer

    /pulse:cicd [proteger]

    Entre crochets [ ] : facultatif. Entre chevrons < > : à remplacer par votre valeur. La barre | sépare les choix possibles. Vide : installer ou mettre à jour les contrôles automatiques.

    • Sans argument : installe les contrôles, ou les met à jour s'ils existent. Pulse propose ensuite la protection de la version principale et les mises à jour hebdomadaires des bibliothèques.
    • proteger : seulement la protection de la version principale. Les contrôles doivent déjà exister.
    /pulse:cicd
    /pulse:cicd proteger

    Ce qu'elle produit

    FichierÀ quoi il sert
    scripts/verifier.jsLe contrôle des secrets, des scénarios sans test et des règles du projet qui portent un contrôle, lancé par les contrôles automatiques et avant chaque enregistrement.
    Le fichier des contrôles, à l'emplacement imposé par votre dépôt (par exemple .github/workflows/… ou .gitlab-ci.yml)La liste des étapes, lancées à chaque envoi sur la version principale et sur chaque proposition vers elle.
    .github/dependabot.yml (ou la configuration de Renovate)Facultatif : les propositions hebdomadaires de nouvelles versions des bibliothèques.
    docs/technical.mdLa ligne « Contrôle automatique avant mise en ligne » : l'outil, le fichier, ce qu'il vérifie.

    S'y ajoutent un enregistrement dédié aux contrôles et, si vous avez un budget de vitesse dans docs/performance.md, une vérification de vitesse facultative.

    Risques et précautions

    • Vous voyez tout avant l'écriture. Pulse montre le fichier complet, explique chaque bloc en une ligne, puis l'écrit avec votre accord.
    • L'envoi passe par votre accord. Claude Code vous demande d'autoriser l'envoi : les contrôles tournent seulement une fois le fichier sur le dépôt distant.
    • Les valeurs secrètes restent hors du fichier. Si la construction a besoin d'une variable, le fichier contient seulement son nom. Vous saisissez la valeur vous-même dans les réglages du dépôt, guidé pas à pas, jamais dans la conversation.
    • La protection se règle sur le site du dépôt, par vous. Pulse vous guide écran par écran.

    Problèmes et solutions

    Une croix rouge apparaît sur le dépôt

    Pulse lit le journal de l'étape en échec, vous l'explique simplement, corrige, enregistre et renvoie. Après deux essais sans succès, il s'arrête et propose /pulse:get-help.

    L'essai sur mon ordinateur échoue

    Une erreur ici serait une croix rouge là-bas. Corrigez-la d'abord avec /pulse:fix ou /pulse:auto-fix, puis relancez /pulse:cicd.

    « Aucun dépôt distant n'est relié »

    Les contrôles tournent chez le fournisseur du dépôt. Pulse vous guide pour relier votre projet à un dépôt en ligne, puis reprend.

    La protection est indisponible pour mon dépôt privé

    Selon l'offre du fournisseur, un dépôt privé gratuit peut ne pas y avoir droit. Les contrôles restent utiles : la croix rouge reste visible sur chaque proposition.

    J'utilise déjà un autre outil avant chaque enregistrement

    Pulse affiche un message qui indique la ligne à ajouter à votre outil existant, pour que le contrôle des secrets s'y exécute aussi.

    Exemples

    /pulse:cicd

    Votre dépôt est sur GitHub : je vous propose GitHub Actions, l'outil intégré à votre dépôt, déjà prêt et gratuit pour un petit projet. (Recommandé) · Autre outil

    pulse-aidd installer-ci · pulse-aidd installer-hook

    Voici le fichier des contrôles, bloc par bloc : récupérer le code, installer Node.js, installer les bibliothèques, contrôler les secrets, chercher les failles connues, vérifier les règles du code, tester, construire. J'essaie d'abord tout sur votre ordinateur… ✅ Claude Code va vous demander l'accord pour envoyer : c'est ce qui met le fichier sur le dépôt distant.

    ✅ Coche verte sur le carnet de réservations. Elle apparaîtra désormais à chaque envoi et sur chaque proposition de version parallèle. Accepter une version parallèle seulement si ses contrôles sont verts ? → Plus tard

    /pulse:cicd proteger

    La branche principale est celle qui part en ligne : avec cette protection, une version parallèle y est rassemblée seulement si ses contrôles automatiques sont verts. Je vous guide d'après la documentation de GitHub, un écran à la fois. Ouvrez d'abord les réglages de votre dépôt (Settings). Dites-moi quand vous y êtes.

    C'est bon, j'y suis.

    Parfait. Passons aux règles de protection de la branche main : je vous indique chaque case à cocher, puis vous enregistrez.

    Commandes liées

    • /pulse:deploy : la mise en ligne automatique, qui complète les contrôles.
    • /pulse:pr : chaque proposition de version parallèle reçoit sa coche ou sa croix.
    • /pulse:commit : enregistrer d'abord les modifications en cours.
    • /pulse:perf : ajouter une vérification de vitesse chaque semaine.
    • /pulse:fix : corriger ce qui fait échouer un contrôle.