Organisations, applications et environnements

Une organisation contient votre équipe et votre facturation ; les applications contiennent des workflows et des clés API, et chacune est soit live, soit sandbox. Bien comprendre cette structure évite la plupart des comportements déroutants.

Rédigé par le support Didit · Mis à jour le 15 septembre 2026

Short answer

Organisation = votre équipe, votre solde de facturation, votre journal d'audit. Application = workflows, clé API, destinations de webhook, politique de rétention, et un mode live ou sandbox. La plupart des problèmes du type « mon changement n'a rien fait » viennent d'être dans la mauvaise application.

#Les deux niveaux

Organisation est votre compte. Elle possède :

  • Votre équipe et leurs rôles
  • Votre solde de facturation et vos factures
  • Votre journal d'audit
  • Toutes vos applications

Application est un espace de travail à l'intérieur de l'organisation. Elle possède :

  • Ses propres workflows
  • Sa propre clé API
  • Ses propres destinations de webhook
  • Sa propre politique de rétention des données
  • Un mode : live ou sandbox

Changez d'application depuis le menu déroulant en haut de la console.

#Pourquoi c'est plus important que ça n'en a l'air

Presque tous les signalements du type « j'ai changé ça et rien ne s'est passé » se résolvent avec cette structure :

  • Vous avez modifié un workflow dans l'application A alors que vos sessions tournent sous l'application B.
  • Vous avez ajouté une destination de webhook à une application en attendant des événements d'une autre.
  • Vous appelez avec une clé d'une application différente de celle de la ressource que vous ciblez, et vous obtenez un 404 ou un 403 pour quelque chose qui existe pourtant clairement.

Avant de déboguer quoi que ce soit d'autre, confirmez l'application. Voir erreurs API et leur signification.

#Live et sandbox sont des applications distinctes

Il n'y a pas d'interrupteur de mode test à l'intérieur d'une application live. Le mode est choisi par application, donc tester signifie créer une deuxième application en mode sandbox et utiliser sa clé.

Cette séparation est le but recherché : le trafic de test et les données de production ne se mélangent jamais, et une clé sandbox ne peut pas accidentellement dépenser de vrais crédits. Voir tester en sandbox.

Tip

Nommez vos applications pour ne jamais les confondre d'un coup d'œil - acme-live et acme-sandbox valent mieux que « Application » et « Application (2) ». Stockez les clés sous des noms correspondants dans votre gestionnaire de secrets, et ne laissez jamais une seule variable d'environnement contenir « quelle que soit la clé actuelle ».

#Combien d'applications faut-il avoir ?

Au minimum, une live et une sandbox. Au-delà, séparez selon ce qui a besoin de sa propre configuration ou de sa propre isolation :

  • Par produit, quand des produits différents ont besoin de workflows et de points de terminaison webhook différents.
  • Par environnement, si vous exécutez plusieurs environnements de préproduction.
  • Par marque, si vous proposez la vérification sous plusieurs marques avec des styles différents.
  • Par politique de rétention, puisque la rétention est configurée par application.

Ce qui ne se sépare pas par application : votre solde, qui est au niveau de l'organisation. Chaque application puise dans les mêmes crédits.

#Créer des applications supplémentaires

Les applications supplémentaires se créent dans la console. Si l'option est manquante, ou si vous devez en créer une via l'API plutôt que via la console, c'est une question de permission au niveau du compte à poser au support plutôt qu'à contourner, en particulier pour une deuxième application live, où la réponse peut dépendre de votre plan.

#Plusieurs organisations

L'e-mail d'une personne n'appartient qu'à une organisation à la fois, et il n'existe aucun moyen de créer des sous-organisations ou des sous-comptes sous la vôtre. Si vous servez plusieurs de vos propres clients, la structure prise en charge est une application par client au sein de votre unique organisation : chaque application a ses propres workflows, sa marque, ses clés d'API, ses résultats et ses rapports d'utilisation, totalement isolés des autres, tandis que la facturation reste au niveau de votre organisation.

#Revendre Didit

Si vous voulez intégrer Didit à votre propre produit et le facturer à vos clients, c'est le modèle revendeur. Voici comment il fonctionne, dans les termes que le support donne à tous ceux qui posent la question :

  • Crédit prépayé. Un achat initial minimum de 5 000 USD, prépayé, sur un accord d'un an. Le crédit n'expire jamais, il se situe au niveau de votre organisation et se consomme sur l'ensemble des clients finaux que vous intégrez, et il comporte une remise de volume qui augmente avec le montant.
  • Le tableau de bord, c'est vous qui le construisez. Vous intégrez l'API Didit dans votre propre front-end et vos clients y gèrent leurs workflows, leur marque et leurs rôles. Didit ne fournit pas de copie en marque blanche de la Business Console ; les écrans de vérification vus par vos utilisateurs finaux peuvent porter votre marque (voir marque blanche), la console non.
  • Votre marge vous appartient. Vous fixez le prix payé par vos clients. Didit vous facture par fonctionnalité terminée aux prix unitaires fixés pour la durée de l'accord.
  • Ce n'est pas un programme de partenaires locaux. Didit assure les démos, l'onboarding et le support directement avec les clients et ne recherche pas de partenaires de distribution ou d'intégration.

Si vous préférez ne pas gérer la revente, utilisez plutôt l'option parrainage : dans la barre latérale de la Business Console, ouvrez Parrainage, acceptez les conditions du programme et partagez votre lien. Vous touchez une commission de 10 % sur chaque dépôt en espèces effectué par une organisation parrainée, pendant 36 mois à compter de son premier dépôt, utilisable en crédit Didit ou versée par virement bancaire une fois mûrie, sans obligation de livraison ni de support. Vous pouvez construire et tester votre intégration sur l'offre gratuite avant de vous engager dans l'une ou l'autre voie.

#Supprimer une application

Supprimer une application retire ses workflows et sa configuration. Ses données de vérification suivent la politique de rétention et les règles de suppression propres à ces données, pas le cycle de vie de l'application - donc si votre objectif est d'effacer des données client, supprimez les données explicitement plutôt que de supposer que retirer l'application le fait. Voir supprimer des sessions et des données personnelles.

#Tout est attribuable

Chaque appel API enregistre l'application à laquelle il appartenait, dans le journal d'audit, pendant 365 jours. C'est ce qui rend une structure multi-application auditable et pas seulement bien rangée. Voir utiliser les journaux d'audit.