Bac à sable#
Un environnement de test complet, avec le même code que la production et des données fictives, servi ici même.
| URL de base | https://developer.elrm.app/sandbox/v1 |
| Clés | pk_test_…, émises par ELRM |
| Quota | 300 requêtes / minute pour la clé émise au reset (sinon la valeur choisie par ELRM à l'émission) |
| Réinitialisation | Chaque dimanche |
| Référence | /reference, sélectionnez le serveur « Bac à sable » |
Le jeu de données#
- Catalogue : copie du catalogue de production (recommandations, offres, prix, centres), rafraîchie à chaque réinitialisation.
- Sessions : les vraies sessions publiques à venir de la production (mêmes numéros, dates, centres, places restantes), copiées à chaque réinitialisation. Ce que vous choisissez ici existe en production ; seules les personnes inscrites sont fictives.
- Votre client : un client fictif double votre fiche client (
SBX-…, « Nom (bac à sable) »), avec la même remise et les mêmes droits API que votre client réel.GET /mele renvoie. - Dossiers, analyses, apprenants : rien au départ, c'est votre terrain de jeu. Créez, inscrivez.
Ce qui est neutralisé#
Le mode bac à sable est appliqué dans le code, indépendamment de la configuration :
| Action | En production | Sur le bac à sable |
|---|---|---|
| Emails (convocations, notifications) | Envoyés | Journalisés, jamais envoyés |
| Signature électronique des documents | Yousign | Non déclenchée |
| Financement CPF / Wedof | Appels réels | 503 sandbox_outbound_blocked |
| Synchronisations planifiées | Actives | Désactivées |
Une opération qui dépend d'un envoi n'échoue donc pas : le flux continue, sans l'effet de bord.
Ce que vous pouvez dérouler seul#
Tout le parcours piloté par l'API se joue de bout en bout, sans intervention d'ELRM : catalogue → analyse du besoin → dossier (accepté d'emblée) → liste des apprenants → répartition dans les sessions générées → validation finale. Les événements correspondants apparaissent dans le journal.
Ce qui ne se produit pas sur le bac à sable, faute d'organisme derrière : les étapes ultérieures (documents_envoyes, documents_signes, formation_en_cours…), donc aucun document (convocations, attestations) n'y est jamais produit. Pour tester la lecture des documents, utilisez la production sur un dossier réel.
Voir vos données de test dans votre portail#
Votre espace client (elrm.app) affiche un sélecteur Production / Test dès que votre fiche a une clé API. En mode test, les écrans Formations (dossiers, apprenants, sessions, inscription) et « Demander une formation » montrent les données du bac à sable : celles que vos clés pk_test_ ont créées. Un bandeau ambre le rappelle en permanence.
C'est le moyen le plus simple de vérifier ce que produit un appel : créez un dossier par l'API, ouvrez-le dans le portail en mode test, et poursuivez l'inscription à l'écran ou par l'API, au choix. Le règlement par carte n'est pas disponible en test.
Réinitialisation hebdomadaire#
Chaque dimanche :
- Les données métier sont vidées (dossiers, analyses, apprenants, inscriptions).
- Le catalogue et les sessions à venir sont réimportés depuis la production.
- Votre client fictif est conservé (même identifiant), ainsi que votre clé : seules ses données repartent de zéro.
Conséquences pour vos tests automatisés :
- Ne codez en dur aucun
iddu bac à sable : redécouvrez-les à chaque exécution (GET /me,GET /formations,GET /formations/sessions,GET /centres). - Un
404sur un identifiant le lundi matin est presque toujours un reste de la semaine passée : relisez le catalogue.
Limites#
- Pas de données de production, jamais : impossible d'y retrouver un vrai client ou un vrai apprenant.
- Le bac à sable suit la branche déployée en production : ce que vous y testez est ce qui tourne en production, mais pas ce qui est en préparation.
- Aucun document n'est produit (voir ci-dessus) :
GET …/documentsrenvoie une liste vide.