Blog

Comment configurer des tests d'API automatisés nocturnes dans GitHub Actions, GitLab et Jenkins

Mettez en place un build nocturne pour vos API : programmez des tests de régression automatisés en CI avec l'Apidog CLI. Copiez-collez les configurations cron de GitHub Actions, GitLab et Jenkins pour détecter les échecs avant le matin.

Ashley Innocent

Ashley Innocent

15 June 2026

Comment configurer des tests d'API automatisés nocturnes dans GitHub Actions, GitLab et Jenkins

Apidog pour les entreprises

Déploiement sur site

SSO & RBAC

Conforme SOC 2

Découvrir Apidog Enterprise

Vos tests d'API passent à chaque pull request. Le build est vert. Vous déployez. Puis, à 9 heures du matin, quelqu'un d'un autre fuseau horaire signale que le processus de paiement (checkout) renvoie une erreur 500, et personne n'a modifié le code de paiement. Ce qui a changé était un environnement de test (sandbox) de paiement tiers, une migration de base de données qui a eu lieu pendant la nuit, ou un jeton qui a expiré discrètement. Vos tests par commit ne l'ont jamais détecté car rien n'a bougé dans votre dépôt.

C'est cette lacune qu'une construction nocturne (nightly build) comble. Une construction nocturne est une exécution de tests complète et planifiée qui se déclenche une fois par jour, généralement aux petites heures, sur vos services et environnements réels au lieu de se limiter aux changements de code. Elle détecte les échecs qui se produisent entre les commits : dérive des données, intégrations instables, identifiants expirés, fuites de performance lentes et ruptures de contrat introduites par des services que vous ne contrôlez pas. Pour les API spécifiquement, une exécution de régression nocturne est le système d'alerte précoce le moins cher que vous puissiez mettre en place.

Ce guide vous expliquera comment construire ce système de bout en bout avec Apidog. Vous concevrez une suite de régression, générerez une exécution en ligne de commande avec l'interface CLI d'Apidog, l'intégrerez à un job CI planifié sur GitHub Actions, GitLab et Jenkins, et obtiendrez un rapport qui vous attendra avant le stand-up. Si vous avez déjà débogué une panne qu'une exécution nocturne aurait signalée des heures plus tôt, c'est le workflow qui vous fera gagner ces heures.

bouton

Pourquoi les tests par commit ne suffisent pas

L'intégration continue nous a appris à tester à chaque push. C'est bien, et vous devriez continuer à le faire. Mais les tests par commit répondent à une question étroite : « cette modification a-t-elle cassé quelque chose ? » Ils s'exécutent rapidement, fréquemment et sont conçus pour ne pas bloquer les développeurs. C'est précisément cette portée qui leur fait manquer toute une catégorie de problèmes.

Une construction nocturne répond à une question plus large : « le système est-il toujours sain actuellement, indépendamment de toute modification ? » La différence est importante car la production comporte des éléments mobiles que vos commits ne voient jamais.

Le modèle est donc à deux niveaux, et non l'un ou l'autre. Des tests rapides de non-régression (smoke tests) protègent chaque commit. Une suite de régression plus approfondie s'exécute selon un calendrier. Le niveau nocturne est l'endroit où vous placez tout ce qui est trop lent, trop large ou trop dépendant du monde réel pour appartenir à la boucle interne.

Que contient une suite de tests de régression API nocturne ?

Avant de planifier quoi que ce soit, décidez ce que l'exécution nocturne vérifie réellement. Une suite nocturne est plus large que vos tests de non-régression de validation de commit et plus approfondie qu'un simple ping de santé. Visez une couverture qui vous embarrasserait si elle tombait en panne silencieusement.

Une suite API nocturne solide couvre :

Si vous n'avez jamais écrit de cas structurés comme ceux-ci, le modèle et l'exemple de cas de test API sont un bon point de départ, et les assertions API expliquent comment valider précisément le corps de la réponse, le statut, les en-têtes et le temps.

Étape 1 : Construire la suite de régression dans Apidog

Apidog traite les tests comme une partie de première classe du cycle de vie des API, et non comme un ajout. Vous concevez des points d'accès, puis les enchaînez en scénarios de test qui reflètent les workflows réels. Un scénario est une liste ordonnée d'étapes où chaque étape est une requête API avec des assertions, et où les données circulent d'une étape à l'autre.

Voici la forme d'un scénario de régression de paiement :

  1. POST /auth/login : envoyer les identifiants, affirmer 200, extraire l'accessToken de la réponse dans une variable.
  2. POST /carts : créer un panier à l'aide du jeton, affirmer 201, extraire l'cartId.
  3. POST /carts/{cartId}/items : ajouter un produit, affirmer 200, affirmer que le total du corps de la réponse est égal au prix attendu.
  4. POST /checkout : soumettre le panier, affirmer 200, affirmer que le order.status est "confirmed".
  5. GET /orders/{orderId} : relire la commande, affirmer qu'elle a persisté avec les bons articles.

Dans Apidog, vous construisez cela visuellement. Chaque étape reçoit des assertions sans écrire de code passe-partout : une assertion visuelle comme « le statut de la réponse est 200 » ou « JSONPath $.order.status est égal à confirmed ». Pour la conformité du schéma, Apidog peut valider automatiquement la réponse par rapport à la définition OpenAPI enregistrée du point d'accès, de sorte que vous n'avez pas à écrire manuellement une vérification pour chaque champ.

Quelques règles de conception permettent de maintenir une suite nocturne :

Si vous venez d'un autre outil, cela correspond parfaitement aux concepts que vous connaissez. L'image plus large de l'enchaînement des scénarios se trouve dans le guide d'orchestration des tests API, et si vous n'avez jamais exécuté de test structuré dans Apidog auparavant, comment tester une API avec Apidog est le point de départ étape par étape. Téléchargez Apidog et construisez un scénario avant de poursuivre la lecture ; le reste de ce guide suppose que vous avez une suite à exécuter.

Étape 2 : Exécuter la suite depuis la ligne de commande

Une construction nocturne s'exécute sans surveillance, elle a donc besoin d'un exécuteur headless. C'est l'interface CLI d'Apidog, un package npm qui exécute vos scénarios de test enregistrés depuis n'importe quel terminal, sans interface graphique requise. Il est conçu précisément pour cela : les exécutions automatisées au sein d'un pipeline CI/CD.

Installez-le globalement. La CLI nécessite Node.js v16 ou une version ultérieure.

npm install -g apidog-cli

Pour exécuter un scénario en ligne (qui réside dans votre projet Apidog), vous avez besoin de deux choses : un jeton d'accès et l'ID du scénario ou de la suite. Générez le jeton dans Apidog sous les paramètres CI/CD, où se trouve un bouton "Add access token". Traitez ce jeton comme un mot de passe ; il doit être placé dans un secret, jamais dans votre dépôt.

La commande pour exécuter un seul scénario de test ressemble à ceci :

apidog run \
  --access-token $APIDOG_ACCESS_TOKEN \
  -t 123456 \
  -e 789 \
  -r cli,html \
  --out-dir ./apidog-reports

Option par option, en utilisant les vraies options de la CLI Apidog :

D'autres options méritent leur place dans une exécution nocturne. -n, --iteration-count <n> répète l'exécution pour détecter l'instabilité. -d, --iteration-data <path> alimente un fichier CSV ou JSON afin qu'un scénario s'exécute sur de nombreuses lignes de données ; parfait pour les tests aux limites. --env-var "key=value" et --global-var "key=value" injectent des valeurs à l'exécution, ce qui permet de garder les identifiants hors du scénario enregistré.

Vous n'avez pas besoin de mémoriser cela. Apidog génère la commande exacte pour vous : ouvrez le panneau CI/CD dans le client, choisissez votre scénario ou votre suite, et copiez la ligne apidog run prête à l'emploi directement dans la configuration de votre pipeline. Exécutez-la d'abord localement pour confirmer qu'elle est verte avant de la planifier.

Étape 3 : Planifier la construction nocturne

Une construction nocturne est cette commande à un moment précis. Chaque plateforme CI prend en charge les tâches planifiées via la syntaxe cron. Le modèle est identique pour toutes : un déclencheur quotidien, le jeton d'accès provenant d'un secret, l'exécution CLI, et le rapport archivé en tant qu'artefact.

GitHub Actions

GitHub Actions prend en charge un déclencheur schedule avec un cron standard. Ce workflow s'exécute tous les jours à 02:00 UTC et expose également un bouton manuel via workflow_dispatch.

name: Nightly API Regression

on:
  schedule:
    - cron: '0 2 * * *'   # 02:00 UTC daily
  workflow_dispatch:        # allow manual runs

jobs:
  regression:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run nightly regression suite
        run: |
          apidog run \
            --access-token $APIDOG_ACCESS_TOKEN \
            --test-suite ${{ vars.APIDOG_SUITE_ID }} \
            -e ${{ vars.APIDOG_ENV_ID }} \
            -r cli,html \
            --out-dir ./apidog-reports
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}

      - name: Upload HTML report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-nightly-report
          path: ./apidog-reports

Le if: always() sur l'étape de téléchargement est important : vous voulez que le rapport soit archivé même lorsque l'exécution échoue, car un échec est précisément le moment où vous avez besoin de le lire. Notez que les tâches planifiées de GitHub s'exécutent en UTC et peuvent être retardées pendant les pics de charge, ne planifiez donc rien qui doive se déclencher à une seconde exacte.

GitLab CI/CD

GitLab planifie les pipelines via l'interface utilisateur (CI/CD > Planifications) plutôt que dans le YAML, puis votre tâche dépend d'une condition de règles afin qu'elle ne s'exécute que selon la planification, et non à chaque push.

nightly-regression:
  image: node:20
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  before_script:
    - npm install -g apidog-cli
  script:
    - apidog run
        --access-token "$APIDOG_ACCESS_TOKEN"
        --test-suite "$APIDOG_SUITE_ID"
        -e "$APIDOG_ENV_ID"
        -r cli,html
        --out-dir ./apidog-reports
  artifacts:
    when: always
    paths:
      - apidog-reports/
    expire_in: 30 days

Définissez APIDOG_ACCESS_TOKEN comme variable CI/CD masquée et protégée, puis créez une planification de pipeline avec une expression cron comme 0 2 * * *. Le bloc rules empêche cette tâche de s'exécuter sur les commits ordinaires.

Jenkins

Dans Jenkins, un pipeline avec un déclencheur cron fait le même travail. Stockez le jeton comme une identifiant et récupérez-le avec withCredentials.

pipeline {
    agent any
    triggers {
        cron('H 2 * * *')   // around 02:00, H spreads load
    }
    stages {
        stage('Install CLI') {
            steps { sh 'npm install -g apidog-cli' }
        }
        stage('Nightly regression') {
            steps {
                withCredentials([string(credentialsId: 'apidog-token',
                                        variable: 'APIDOG_ACCESS_TOKEN')]) {
                    sh '''
                        apidog run \
                          --access-token $APIDOG_ACCESS_TOKEN \
                          --test-suite $APIDOG_SUITE_ID \
                          -e $APIDOG_ENV_ID \
                          -r cli,html \
                          --out-dir ./apidog-reports
                    '''
                }
            }
        }
    }
    post {
        always {
            archiveArtifacts artifacts: 'apidog-reports/**', allowEmptyArchive: true
        }
    }
}

Le H dans H 2 * * * est une fonctionnalité agréable de Jenkins : il choisit une minute stable dans l'heure afin que toutes vos tâches nocturnes ne se déclenchent pas exactement à 02:00.

Ce champ cron est le même sur les trois plateformes. 0 2 * * * signifie minute 0, heure 2, tous les jours. Vous voulez le faire deux fois par nuit pour détecter les problèmes plus tôt ? 0 2,14 * * *. Uniquement les jours de semaine ? 0 2 * * 1-5. Choisissez un moment où votre environnement de staging est calme et où les sandboxes externes sont actives.

Étape 4 : Rendre les échecs impossibles à ignorer

Une exécution nocturne qui échoue dans un journal que personne ne lit est pire qu'aucune exécution nocturne ; elle engendre une fausse confiance. Le but est l'alerte. Connectez le résultat à l'endroit où votre équipe consulte déjà les informations.

Le code de sortie de la CLI est votre déclencheur. apidog run se termine avec un code non nul lorsqu'un scénario échoue, de sorte que la CI met automatiquement le job en rouge. À partir de là :

Une discipline permet de rendre les constructions nocturnes fiables : traitez un échec comme un véritable bug jusqu'à preuve du contraire. Le moyen le plus rapide de tuer une suite nocturne est de laisser les tests instables habituer tout le monde à ignorer le rouge. Si un scénario échoue par intermittence, corrigez le test ou l'environnement ; ne le minimisez pas. L'exécution avec -n pour répéter un scénario, ou la stabilisation des données dont dépend votre scénario, révèle généralement la véritable instabilité.

Pourquoi Apidog s'adapte au modèle de construction nocturne

Vous pouvez assembler un pipeline API nocturne à partir de plusieurs parties : un outil pour la conception, un autre pour l'écriture des tests, un troisième pour les exécuter sans interface graphique, et un validateur de schéma boulonné. De nombreuses équipes fonctionnent ainsi, et cela marche jusqu'à ce que les pièces se désynchronisent. La friction apparaît à 2 heures du matin lorsque le test exécuté par l'exécuteur ne correspond plus à l'API que vous avez réellement déployée.

Apidog regroupe tout cela en un seul workflow. Le point d'accès que vous concevez, le scénario que vous testez, le schéma par rapport auquel vous validez et la commande que vous planifiez font tous référence à la même source de vérité. Lorsque vous modifiez un point d'accès, le scénario et la vérification du schéma suivent. Il n'y a pas d'étape d'exportation, pas de collection qui devient silencieusement obsolète, pas de deuxième copie du contrat à synchroniser. Si vous avez ressenti la douleur des collections Postman qui ne sont pas une véritable source de vérité, cette conception à source unique fait toute la différence.

La CLI est le même moteur que l'interface graphique, de sorte qu'un scénario que vous déboguez visuellement à votre bureau s'exécute de manière identique en CI à 2 heures du matin. Vous construisez et corrigez les tests avec une visibilité totale, puis les exécutez sans interface graphique avec une seule commande. Cette symétrie fait d'une construction nocturne quelque chose en quoi vous avez confiance au lieu de quelque chose que vous devez surveiller.

Foire aux questions

Quelle est la différence entre une construction nocturne (nightly build) et l'intégration continue ?

L'intégration continue exécute des tests à chaque modification de code pour détecter les régressions dans les nouveaux commits. Une construction nocturne s'exécute selon un calendrier fixe, généralement pendant la nuit, indépendamment de toute modification. La CI détecte ce que votre équipe casse ; l'exécution nocturne détecte ce que le monde extérieur casse : jetons expirés, dépendances dérivées, modifications de données et lente dérive des performances. Les pipelines matures exécutent les deux. Des tests rapides de non-régression valident chaque commit, et une suite de régression plus large s'exécute toutes les nuits.

À quelle heure une construction nocturne devrait-elle être exécutée ?

Choisissez une fenêtre où votre environnement de test est inactif et où les services externes dont vous dépendez sont accessibles. Pour de nombreuses équipes, c'est de 1h à 4h du matin heure locale. Si vos API appellent des sandboxes tierces, vérifiez qu'elles sont actives à cette heure ; certains fournisseurs limitent ou suspendent le service pendant la nuit. Évitez de planifier l'exécution exactement à l'heure sur une CI partagée, où des milliers de tâches se déclenchent simultanément ; un décalage de quelques minutes (ou l'utilisation de la syntaxe H de Jenkins) répartit la charge.

Puis-je exécuter une suite nocturne contre la production ?

Exécutez des vérifications en lecture seule sur la production en toute sécurité. Pour tout ce qui écrit des données, dirigez la suite nocturne vers un environnement de staging ou de pré-production dédié avec des données réalistes, ou utilisez des opérations idempotentes et une étape de nettoyage. Un modèle courant consiste à effectuer une exécution de régression complète en lecture-écriture sur l'environnement de staging, plus une petite exécution de non-régression en lecture seule sur la production pour confirmer que le système en direct est accessible et répond correctement.

En quoi cela diffère-t-il de la surveillance ?

La surveillance de la disponibilité répond à la question « l'API est-elle active ? » Une suite de régression nocturne répond à la question « l'API est-elle correcte ? » La surveillance ping un point de terminaison et vérifie un statut 200. Une exécution de régression exerce des workflows complets, valide les corps de réponse par rapport à votre schéma, vérifie les limites d'authentification et affirme les règles métier. Ils sont complémentaires ; la surveillance est continue et superficielle, les tests nocturnes sont périodiques et approfondis.

Dois-je écrire du code pour planifier des tests API ?

Non. Vous construisez des scénarios visuellement dans Apidog sans script, puis copiez la commande apidog run générée à partir du panneau CI/CD. Le seul « code » est constitué des quelques lignes de YAML ou de configuration de pipeline qui indiquent à votre plateforme CI quand exécuter, et ce sont les modèles ci-dessus. Si vous souhaitez voir comment les exécuteurs en ligne de commande se comparent en général, Postman CLI vs Newman et exécuter des collections en CI sans Newman couvrent les alternatives.

Configurez votre première exécution nocturne

Commencez petit. Choisissez un workflow critique, votre flux de connexion ou votre chemin de paiement, et construisez-le comme un scénario Apidog unique avec de véritables assertions. Exécutez-le localement avec la CLI jusqu'à ce qu'il soit vert. Insérez la commande générée dans une tâche planifiée à l'aide de l'un des modèles ci-dessus. Connectez l'échec à votre chat d'équipe. C'est une construction nocturne fonctionnelle en un après-midi.

À partir de là, développez la suite. Ajoutez des scénarios pour les parcours les plus importants suivants, activez la validation de schéma dans l'ensemble du système et définissez des budgets de performance sur vos points d'accès les plus sollicités. En une semaine, vous disposerez d'un filet de régression qui détectera les échecs que vos tests par commit n'étaient pas conçus pour voir, et vous en serez informé par un message de chat à 2 heures du matin au lieu d'un client à 9 heures.

bouton

Pratiquez le Design-first d'API dans Apidog

Découvrez une manière plus simple de créer et utiliser des API

S'inscrire gratuitementTélécharger