Environnements
Deux environnements, Test et Production. Celui que vous atteignez tient à une seule URL — celle depuis laquelle le widget est chargé.
Saphere tourne sur deux environnements. Ils sont entièrement séparés : comptes distincts, clés d’API distinctes, données distinctes. Une mesure faite en Test n’apparaît jamais en Production, et une clé émise pour l’un est refusée par l’autre.
| Environnement | À quoi il sert | CDN | API |
|---|---|---|---|
| Production | Les mesures réelles, le quota réel. Ce que vos utilisateurs atteignent. | https://cdn.saphere.ai | https://api.saphere.ai |
| Test | Intégration et recette. Comptes distincts, données distinctes, clés d'API distinctes. | https://cdn.test.saphere.ai | https://api.test.saphere.ai |
Choisir un environnement, c’est choisir une URL
Vous ne configurez pas d’environnement. Vous l’atteignez par l’adresse que vous appelez, et le widget suit :
<!-- Test -->
<script type="module">
import SaphereScan from "https://cdn.test.saphere.ai/saphere-scan/v2/main.js"
</script>
<!-- Production -->
<script type="module">
import SaphereScan from "https://cdn.saphere.ai/saphere-scan/v2/main.js"
</script>
Cette seule ligne règle tout le reste. Le widget déduit l’adresse de l’api de mesure du CDN depuis lequel il a été chargé : un paquet servi par cdn.test.saphere.ai parle à api-measure.test.saphere.ai, et jamais à la Production. Il n’y a rien d’autre à basculer, donc rien qui puisse rester à moitié basculé.
Une chose ne suit pas d'elle-même
Votre propre point d’accès à jetons. Si le widget est chargé depuis le CDN de Test, votre serveur doit appeler l’api de Test pour émettre le jeton d’accès — un jeton de Production présenté au service de mesure de Test est refusé, et la session ne s’ouvre pas.
Lisez l’environnement depuis votre configuration, n’écrivez jamais un hôte en dur.
Ce qui diffère, et ce qui ne diffère pas
| Test | Production | |
|---|---|---|
| Clés d’API | Émises pour le Test seul | Émises pour la Production seule |
| Clients, mesures, jetons | Données distinctes | Données distinctes |
| Version du widget servie | La même livraison | La même livraison |
| Surface de l’api, noms d’événements, options | Identiques | Identiques |
Les deux dernières lignes sont la raison d’être d’un environnement de Test : ce que vous y validez est ce qui tournera en Production. Un comportement qui différerait entre les deux est un défaut à signaler, non une différence à contourner.
Passer une intégration en Production
- Remplacez l’URL du CDN dans la page ou la coquille applicative.
- Faites viser l’api de Production à votre point d’accès à jetons, avec la clé d’API de Production.
- Vérifiez que la clé n’atteint jamais le navigateur — voir Jetons d’accès.
Rien d’autre ne change : aucune option, aucun nom d’événement, aucune forme de charge utile.
Ne livrez jamais une clé d'API de Production dans la page
Une clé d’API de Production n’a ni expiration ni portée. Placée dans une page, elle est lisible par quiconque ouvre les outils de développement, et la révoquer revient à la changer — ce qui coupe d’un coup toutes les intégrations de ce compte.
C’est la raison du nom de la stratégie unsafe-api-key, et de ce qu’elle est réservée aux essais sur le Test.