Clés API

Tout ce qui se connecte à MoneyLights depuis l’extérieur de l’application — un script, une intégration, un assistant IA — s’authentifie avec une clé API. Un type de credential, un endroit pour le gérer, un bouton de révocation.

Création d’une clé

Va dans Paramètres → Clés API en tant que Propriétaire ou Admin de ton organisation. Un Membre peut éditer des données dans l’application mais ne peut pas émettre une clé : une clé agit sans surveillance, ce qui est une autre sorte de responsabilité.

Lorsque tu crées une clé, tu choisis :

• Un nom — nomme-la d’après le système qui l’utilisera, pas la personne.
• Des scopes — exactement ce que la clé peut faire (voir ci-dessous).
• Une expiration — 30, 90, 180 ou 365 jours. Il n’y a pas d’option “n’expire jamais” intentionnellement : un credential auquel personne ne pense jamais est un credential que personne ne remarque s’il a été compromis.
• Une liste d’IP autorisées (optionnel) — restreins la clé à ton propre infrastructure, donc une clé compromise est une clé qui ne fonctionne nulle part ailleurs.

Le secret (ml_sk_…) est affiché une seule fois, à la création. MoneyLights ne stocke qu’un hash, donc personne — y compris le support — ne peut le récupérer plus tard. Si tu le perds, fais tourner la clé.

Donne à chaque intégration sa propre clé. Tu peux alors couper l’une sans affecter les autres, et les chiffres d’utilisation te diront quel système fait quoi.

Scopes

Les scopes sont des paires ressource:action — par exemple transactions:read ou documents:write. Une clé ne contient que les scopes que tu lui as accordés, et :

• Écrire implique lire, jamais l’inverse. vendors:write peut aussi lire les vendeurs ; vendors:read ne peut jamais écrire.
• Les scopes ne peuvent pas être modifiés après création. Avoir besoin d’un nouveau scope signifie créer une nouvelle clé — élargir un credential en place serait un changement que personne ne voit.

Ce qu’une clé peut réellement faire est recalculé à chaque requête :

permissions effectives = les scopes de la clé ∩ ce que son créateur peut faire maintenant ∩ ton plan

Donc si la personne qui a créé une clé est rétrogradée, la clé se restreint à l’appel suivant. Si elle quitte l’organisation, ses clés cessent de fonctionner immédiatement. Émet des clés sous un compte qui va rester.

Rotation

Faire tourner émet un nouveau secret pour la même clé et te permet de choisir combien de temps l’ancienne continue de fonctionner : immédiatement, 24 heures ou 7 jours. La fenêtre existe pour que tu puisses déployer le nouveau secret sans temps d’arrêt. La clé conserve son nom, ses scopes, ses restrictions IP et son expiration.

Fais tourner lorsque quelqu’un ayant accès au secret part, lorsqu’il a pu être exposé, et selon le calendrier que ta propre politique définit.

Avertissements d’expiration

Le créateur de la clé est notifié 14, 7 et 1 jour avant qu’une clé expire, et une fois qu’elle a expiré. Ces notifications ne peuvent pas être désactivées. N’attends pas la dernière : faire tourner à 14 jours coûte un déploiement ; découvrir une clé expirée à zéro coûte une panne.

Stockage du secret

• Utilise des variables d’environnement ou un gestionnaire de secrets — jamais de contrôle de source, jamais de fichier de configuration qui est expédié avec ton application.
• Ne mets jamais la clé dans une URL, une ligne de log ou un événement d’analyse. Les requêtes portant une clé dans la chaîne de requête sont refusées immédiatement.
• N’utilise jamais une clé dans du code côté client. Une clé dans un navigateur ou une application mobile a été donnée à tous ceux qui l’utilisent.

Suspecte une fuite ? Révoque d’abord, enquête ensuite. La révocation se fait dans Paramètres → Clés API, prend effet immédiatement, et est toujours disponible — même si ton abonnement est en retard.

Prochaines étapes

Avec une clé en main, tu peux appeler le REST API ou connecter un assistant IA via MCP — c’est le même credential pour les deux.