Environnements · Saphere

Saphere fonctionne sur deux environnements. Ils sont complètement séparés : comptes séparés, clés d’API séparées, données séparées. Une mesure faite sur le Test n’apparaît jamais en Production, et une clé délivrée 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, recette, et validation de ce qui vient. Parfois légèrement en avance sur la Production.	`https://cdn.test.saphere.ai`	`https://api.test.saphere.ai`

Choisir un environnement, c’est choisir une adresse

Il n’y a aucun réglage à changer. On atteint un environnement par l’adresse que l’on appelle, et le widget la 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 du service de mesure du CDN d’où il a été chargé. Un code 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 toute seule

Votre propre point d’entrée à jetons. Si le widget se charge depuis le CDN de Test, votre serveur doit appeler l’api de Test pour délivrer le jeton d’accès. Un jeton de Production présenté au service de Test est refusé, et la mesure ne démarre jamais.

Lisez l’environnement dans votre propre configuration. N’écrivez jamais une adresse en dur dans le code.

Ce qui diffère, et ce qui ne diffère pas

	Test	Production
Clés d’API	Délivrées pour le Test seulement	Délivrées pour la Production seulement
Comptes, mesures, jetons	Données séparées	Données séparées
Version servie	Parfois en avance	La version livrée
Routes, noms d’événements, options	Le contrat livré, parfois augmenté de ce qui est en validation	Le contrat livré

Le Test est aussi l’environnement où les nouveaux développements sont validés avant leur livraison. Il est donc parfois légèrement en avance sur la Production : un écran, une option ou un événement peut y exister avant d’exister en Production. L’écart est faible et se referme à la livraison suivante, mais il est réel, et il va dans le sens que l’on attend — le Test d’abord, la Production ensuite.

Deux conséquences pratiques.

Construisez sur ce qui est documenté, non sur ce que vous observez sur le Test. Ce que vous y trouvez et que cette documentation ne décrit pas est peut-être en cours de validation. Ce n’est pas encore un contrat.

Un comportement qui fonctionne sur le Test et pas en Production mérite une question plutôt qu’un contournement. Il s’agit en général d’une fonctionnalité pas encore livrée, et la réponse est une date plutôt qu’une modification de votre code.

Passer une intégration en Production

Changez l’adresse du CDN dans votre page ou dans votre application.
Pointez votre point d’entrée à jetons vers l’api de Production, et donnez-lui la clé d’API de Production.
Vérifiez que la clé n’atteint jamais le navigateur. Les jetons d’accès expliquent comment.

Rien d’autre ne change de votre côté : aucune option à renommer, aucun événement à rebrancher, aucune forme de réponse à adapter.

N'envoyez jamais une clé d'API de Production dans une page

Une clé d’API de Production n’expire pas et ouvre toutes les routes de votre compte. Placée dans une page, n’importe qui ouvrant les outils de développement du navigateur peut la lire. La révoquer veut dire la remplacer, ce qui coupe toutes vos intégrations au même instant.

C’est pourquoi la stratégie unsafe-api-key porte ce nom, et pourquoi elle est réservée aux essais sur le Test.