# Origines SDK

> Demander et faire approuver les origines de navigateur avant que les appels du SDK web n'atteignent les routes de l'API Thalovant.

Source: https://docs.thalovant.com/fr/developers/sdk-origins/

---
{/* Last Edit: Claude Opus 5.5 - 2026-09-28 - Motive: Canadian French translation of developers/sdk-origins.mdx; terms per docs/french-glossary.md (AMF, serveur), and review fixes. */}

**SDK origins** est la liste d'autorisation des applications de navigateur qui appellent Thalovant à partir d'un site qui vous appartient.

Servez-vous-en seulement quand un environnement de navigateur doit faire des requêtes SDK ou API d'une origine à une autre. Pour les services, les agents, les outils en ligne de commande et les tâches, continuez d'utiliser un serveur ou un environnement protégé doté d'un magasin de secrets.

Les espaces de travail gratuits n'ont pas besoin de SDK origins pour le parcours vocal de départ. Commencez par **Public hubs** et **Connections**; SDK origins apparaît quand le forfait de l'espace de travail permet la revue des origines de navigateur.

## Comment ça fonctionne

1. **Ouvrez SDK origins** dans le tableau de bord.
2. **Choisissez l'espace de travail** à qui appartient l'application de navigateur.
3. **Demandez une origine exacte**, comme `https://app.example.com`.
4. **Attendez la revue.** Une personne chargée de la revue dans l'espace de travail reçoit une notification et un courriel.
5. **Utilisez l'origine approuvée.** Les requêtes de navigateur venant de cette origine peuvent utiliser CORS sans identifiants.

Une origine contient `https://`, l'hôte et, au besoin, le port. Rien d'autre : pas de chemin, de paramètres de requête, de fragment, de caractère générique, de `http://` ni de `null`.

## Ce que l'approbation permet

| Permet | Ne permet pas |
| --- | --- |
| Les appels d'API d'une origine à une autre à partir de l'origine exacte approuvée. | Les témoins du tableau de bord ni les flux de rafraîchissement de session à partir de sites clients. |
| Les en-têtes de requête `Authorization` et `Idempotency-Key`. | Les en-têtes CSRF ni les en-têtes de rafraîchissement propres au tableau de bord. |
| Les requêtes du SDK de navigateur venant d'un domaine de production connu. | Les domaines génériques, les fichiers locaux ni les origines avec chemin et paramètres de requête. |

  L'approbation ne sert qu'à la vérification de l'origine par le navigateur. Elle ne rend pas sûrs les identités de hub, les jetons d'API, les liens de configuration ni les mots de passe du courtier placés dans du JavaScript servi aux utilisateurs.

## Un modèle sûr pour le navigateur

Passez par un serveur quand le navigateur a besoin de secrets.

  
    Une application web appelle une petite surface d'API approuvée avec une authentification d'utilisateur de courte durée, sans identité de hub de longue durée dans le paquet.
  
  
    La création et le stockage des identités, le matériel de configuration, les mots de passe du courtier, les sessions de rafraîchissement et les paiements restent côté serveur.
  
  
    Demandez séparément les domaines de production, de préproduction et d'aperçu. Désactivez les origines qui ne servent plus l'application.
  

## SDK locaux et serveurs

SDK origins n'est pas la frontière de sécurité du code qui tourne sur un portable, un service côté serveur, une tâche d'intégration continue, un appareil de pièce ou un serveur privé.

| Environnement | SDK origins? | Modèle plus sûr |
| --- | --- | --- |
| Script ou outil en ligne de commande sur un portable | Non | Rangez le fichier d'identité hors du dépôt et limitez-le à l'utilisateur courant. |
| Service côté serveur ou tâche | Non | Gardez les jetons, le matériel de configuration et l'identité du hub dans un magasin de secrets côté serveur. |
| Appareil Thalovant Voice | Non | Utilisez le lien de configuration privé ou la commande d'installation générée dans **Connections**. |
| Application de navigateur d'un client | Oui | Demandez séparément les origines exactes de production, de préproduction et d'aperçu. |

Si une application de navigateur a besoin d'une opération secrète, placez cette opération derrière votre serveur et appelez ce serveur à partir du navigateur.

## Notifications

Quand une origine est demandée, la personne qui la demande et celle qui fait la revue voient une notification de sécurité. Un courriel est aussi envoyé pour que la personne chargée de la revue ouvre le tableau de bord et tranche.

Une fois la revue terminée, la personne qui a fait la demande reçoit une notification d'état et un courriel. Les origines approuvées fonctionnent dès que le cache CORS se rafraîchit.

## Si le navigateur est refusé

| Symptôme | Vérification |
| --- | --- |
| La requête préliminaire du navigateur renvoie `400` | Confirmez que l'origine exacte est approuvée et qu'elle utilise `https://`. |
| Ça marche en préproduction, pas en production | Demandez l'origine de production séparément. |
| Les requêtes avec identifiants échouent | Réservez au tableau de bord les flux à base de témoins; les origines clientes sont sans identifiants. |
| `X-CSRF-Token` est refusé | Retirez des requêtes SDK origins les en-têtes propres au tableau de bord. |
| L'application a déménagé sur un nouveau domaine | Demandez la nouvelle origine, attendez la revue, puis désactivez l'ancienne. |

## Prêt quand

L'origine SDK est prête quand :

- l'origine est exacte et approuvée;
- le navigateur n'envoie que des en-têtes pris en charge;
- les secrets de longue durée restent hors du paquet du navigateur;
- les origines de préproduction et de production sont suivies séparément;
- les origines anciennes ou inutilisées sont désactivées.