Comment planifier les tests API automatisés dans Apidog (Cloud, Runner et CLI)

Une suite de tests réussie n’est utile que si elle le reste. Une dépendance peut introduire un changement incompatible à 2 h du matin, un certificat peut expirer pendant le week-end, ou une dérive de configuration peut désactiver un endpoint de paiement. Si vos tests ne s’exécutent que manuellement, vous découvrirez le problème via un client — pas via une alerte. La solution : planifier vos tests d’API, les exécuter sans intervention humaine et recevoir une notification dès qu’un scénario échoue.

Essayez Apidog dès aujourd’hui

Apidog inclut des tâches planifiées (Scheduled Tasks) pour exécuter des scénarios de test existants selon une cadence définie. Vous sélectionnez les scénarios, l’environnement, le Runner qui les exécute et les canaux de notification. Pour le contexte général, consultez cette introduction à la surveillance d’API, ainsi que la documentation des tâches planifiées d’Apidog.

Les tâches planifiées sont actuellement en bêta. Le nombre d’exécutions disponibles dépend de votre forfait.

Ce que font les tâches planifiées

Une tâche planifiée exécute un ou plusieurs scénarios de test sauvegardés à intervalle régulier. Cas d’usage typiques :

• une régression nocturne sur l’API de production ;
• un test de fumée de staging toutes les 6 heures ;
• une vérification de santé pendant le week-end ;
• une validation après un déploiement.

Une tâche mémorise :

• les scénarios à exécuter ;
• l’environnement cible ;
• la cadence ;
• le Runner chargé de l’exécution ;
• les destinataires des alertes.

Cette fonctionnalité ne correspond pas à des tâches de scraping ou de collecte de données. Elle exécute des scénarios de test d’API : requêtes chaînées, assertions, extraction de variables et rapports de réussite ou d’échec.

Prérequis : configurer un Runner auto-hébergé

Avant de créer une tâche planifiée, configurez un Runner auto-hébergé.

Le Runner est la machine qui exécute réellement votre suite. Lorsqu’une tâche démarre, les requêtes ne partent pas de votre client Apidog local : elles sont envoyées depuis le Runner sélectionné.

Vous pouvez utiliser :

• un serveur CI ;
• une VM dédiée ;
• un serveur toujours actif ;
• une machine présente dans votre réseau interne.

Choisissez un Runner qui reste joignable aux horaires prévus.

Vérifiez le réseau du Runner

Le réseau du Runner influence directement les résultats :

• VPN d’entreprise ;
• VPC privé ;
• région géographique ;
• proxy ;
• pare-feu ;
• DNS interne.

Un test exécuté depuis le Runner peut donc produire un résultat différent d’un test lancé depuis votre ordinateur portable. C’est souvent souhaitable : le Runner doit idéalement voir votre API dans des conditions proches de celles de vos utilisateurs ou de votre infrastructure.

La cible Apidog Cloud est indiquée comme « bientôt disponible ». Pour le moment, utilisez un Runner auto-hébergé.

Créer une tâche planifiée, étape par étape

L’exemple suivant concerne une suite de régression nocturne pour une API e-commerce couvrant l’inscription, le catalogue, le panier et le paiement via Stripe.

1. Ouvrez les tâches planifiées

Dans le client Apidog :

1. Ouvrez le module Tests.
2. Dans l’arborescence, sélectionnez Tâches planifiées (Scheduled Tasks).
3. Consultez les tâches existantes et leur état.

Cette vue centralise les tâches actives, désactivées et leur historique d’exécution.

2. Créez une tâche

Cliquez sur + Nouveau pour créer une tâche planifiée.

Ajoutez un nom et une description explicites, par exemple :

Régression nocturne — Production
Vérifie inscription, catalogue, panier et paiement chaque nuit.

Vous pouvez aussi créer des dossiers pour organiser les tâches :

Tâches planifiées/
├── Production/
│   ├── Régression nocturne
│   └── Health check horaire
└── Staging/
    ├── Smoke test après déploiement
    └── Régression quotidienne

Chaque tâche peut être activée ou désactivée sans être supprimée.

3. Sélectionnez les scénarios de test

Dans Scénario de test, ajoutez un ou plusieurs scénarios existants.

Pour une API e-commerce, vous pourriez sélectionner :

• Inscription et connexion
• Parcourir et ajouter au panier
• Payer avec la carte de test Stripe

Chaque scénario peut définir ses propres paramètres :

• environnement ;
• données de test ;
• nombre d’itérations ;
• délai d’expiration ;
• enregistrement des requêtes et réponses.

Si tous les scénarios doivent utiliser la même configuration, activez Utiliser la même configuration d’exécution.

4. Choisissez l’environnement

L’environnement est généralement le paramètre le plus important.

Exemple de séparation recommandée :

Tâche	Environnement	Cadence
Smoke test	Staging	Toutes les 6 heures
Régression complète	Production	Chaque nuit
Health check	Production	Selon votre besoin

Même si une tâche peut cibler plusieurs environnements, gardez de préférence un environnement par tâche. Les alertes, l’historique et le diagnostic seront plus faciles à lire.

5. Définissez la cadence d’exécution

Configurez le champ Cycle d’exécution ou Mode d’exécution selon l’intitulé affiché dans votre interface.

Exemples de cadence :

• chaque dimanche à 23 h ;
• toutes les 6 heures ;
• toutes les 8 heures ;
• chaque nuit.

Recommandations pratiques :

• utilisez une exécution nocturne pour une régression complète ;
• utilisez une cadence plus fréquente pour un smoke test léger ;
• évitez de surcharger staging ou production avec des suites coûteuses trop fréquentes.

6. Sélectionnez le Runner

Dans le champ Exécuter sur ou S’exécute sur, choisissez votre Runner auto-hébergé.

Si plusieurs Runners sont disponibles, sélectionnez celui dont le réseau correspond au contexte à valider :

• Runner dans le même VPC que l’API ;
• Runner interne pour les endpoints privés ;
• Runner dans une région spécifique ;
• Runner CI pour des vérifications liées au pipeline.

Toutes les requêtes du scénario partent de cette machine.

7. Configurez les notifications

Activez les notifications pour recevoir les résultats sans surveiller manuellement l’interface.

Apidog propose notamment :

• Slack ;
• Teams ;
• Webhook ;
• Jenkins ;
• E-mail.

Pour l’e-mail, vous pouvez utiliser les membres du projet ou saisir d’autres adresses, par exemple une boîte partagée ou une rotation d’astreinte.

Choisissez ensuite la condition de notification :

• Après chaque exécution : utile pendant la mise en place ou après un déploiement à risque ;
• Uniquement en cas d’échec : recommandé pour les régressions régulières.

Pour une tâche nocturne stable, privilégiez les alertes uniquement en cas d’échec. Le silence devient alors un signal de bon fonctionnement.

8. Activez la tâche et consultez l’historique

Activez l’interrupteur de la tâche pour démarrer les exécutions planifiées.

Après chaque exécution, les résultats du Runner sont envoyés au serveur. Ouvrez Tâches planifiées → Historique des exécutions pour consulter :

• la date et l’heure de l’exécution ;
• le statut global ;
• le scénario en échec ;
• l’assertion concernée ;
• les détails nécessaires au diagnostic.

Lorsqu’une alerte Slack ou e-mail arrive, l’historique d’exécution est le premier endroit à consulter.

Paramètres avancés

Limitez la portée des variables

Apidog permet de partager des variables à plusieurs niveaux :

1. Uniquement dans le scénario actuel
   
   La variable reste isolée dans ce scénario.

2. Entre les scénarios de la tâche planifiée actuelle
   
   Les scénarios d’une même tâche peuvent lire les valeurs produites par les autres.

3. Entre les tâches planifiées du dossier actuel
   
   Les tâches d’un même dossier peuvent partager des valeurs.

Utilisez la portée la plus limitée possible. Par exemple, ne partagez pas un jeton d’authentification avec des scénarios qui n’en ont pas besoin.

Conservez les variables entre deux exécutions

Les variables ne persistent entre plusieurs exécutions que si l’option Conserver les valeurs des variables est activée dans la page de conception du scénario.

Activez cette option si votre tâche dépend d’une valeur récupérée précédemment, par exemple :

• un ID de commande ;
• un jeton renouvelé ;
• une valeur de session ;
• une donnée créée lors d’une exécution antérieure.

Sans cette option, chaque exécution planifiée repart de zéro.

Organisez les tâches par dossier

Utilisez des dossiers pour séparer les usages :

Production/
├── Vérification de santé
├── Régression nocturne
└── Validation paiement

Staging/
├── Smoke test
├── Régression après déploiement
└── Tests de contrat

Cette organisation devient particulièrement utile lorsque vous utilisez le partage de variables au niveau du dossier.

Vérifiez les limites de votre forfait

Le nombre d’exécutions planifiées dépend de votre abonnement. Vérifiez cette limite avant de programmer une suite complète toutes les heures.

Pour aller plus loin, consultez :

• les tâches planifiées avancées ;
• la logique conditionnelle dans les scénarios de test d’API ;
• les exécutions nocturnes de tests d’API dans la CI.

Alternative : planifier vos tests avec Apidog CLI

L’interface des tâches planifiées est une solution. Une autre approche consiste à exécuter un scénario avec le CLI d’Apidog, puis à laisser cron ou votre plateforme CI gérer la planification.

Le CLI ne fournit pas de commande de planification native : la cadence est définie par votre outil externe.

Installez le CLI, authentifiez-vous, puis exécutez un scénario :

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <SCENARIO_ID> -e <ENV_ID> -r cli,junit

Paramètres principaux :

• -t : ID du scénario de test ;
• -e : ID de l’environnement ;
• -r : rapporteur, par exemple cli, html ou junit.

Le guide d’installation de l’Apidog CLI détaille la configuration du jeton.

Exemple avec cron

Pour lancer un scénario chaque nuit à 2 h :

0 2 * * * cd /srv/api-tests && apidog run --access-token $APIDOG_ACCESS_TOKEN -t 4471 -e 88 -r junit >> run.log 2>&1

Le rapport JUnit peut ensuite être exploité dans vos tableaux de bord ou outils de CI existants.

Vous pouvez aussi déclencher le CLI depuis GitHub Actions via un workflow planifié. Consultez le guide Apidog CLI dans votre pipeline CI/CD, ainsi que la documentation des déclencheurs planifiés GitHub Actions.

FAQ

Puis-je exécuter des tests planifiés sur Apidog Cloud aujourd’hui ?

Pas encore. Apidog Cloud est indiqué comme « bientôt disponible ». Utilisez actuellement un Runner auto-hébergé.

À quelle fréquence une tâche peut-elle s’exécuter ?

La cadence est flexible, avec des exemples comme toutes les 6 heures ou chaque dimanche à 23 h. Le nombre total d’exécutions reste toutefois limité par votre forfait.

Comment recevoir une alerte uniquement en cas d’échec ?

Dans les paramètres de notification, choisissez uniquement en cas d’échec, puis ajoutez un canal comme Slack, Teams, Webhook, Jenkins ou E-mail.

Associez cette configuration à une vérification de santé d’API légère pour détecter rapidement les indisponibilités, en complément d’une régression plus complète.

Pourquoi les résultats planifiés diffèrent-ils de mes tests locaux ?

Les requêtes sont envoyées depuis le Runner, pas depuis votre ordinateur. Sa région, son VPN, son proxy, ses règles de pare-feu et son accès réseau peuvent modifier les réponses obtenues.

Pourquoi mes variables sont-elles réinitialisées après chaque exécution ?

Activez Conserver les valeurs des variables dans la page de conception du scénario. Sans cette option, chaque exécution démarre avec un état vierge.

En résumé

Les tests planifiés transforment « nous pensons que l’API fonctionne » en « nous savons qu’elle fonctionne — et nous serons alertés si ce n’est plus le cas ».

Mettez en place ce flux :

1. créez vos scénarios de test ;
2. enregistrez un Runner auto-hébergé ;
3. sélectionnez l’environnement cible ;
4. définissez la cadence ;
5. configurez une notification en cas d’échec ;
6. consultez l’historique dès qu’une alerte arrive.

Pour intégrer les mêmes contrôles dans votre pipeline, utilisez aussi le CLI avec cron ou GitHub Actions. Téléchargez Apidog pour configurer votre première suite de régression planifiée.