Sécurité

Authentification

Les comptes sont gérés par Supabase Auth avec e-mail et mot de passe, Google OAuth ou GitHub OAuth. Après connexion, votre navigateur conserve un jeton de session (un JWT) que le middleware de la plateforme renouvelle automatiquement, si bien qu'une session active n'expire jamais silencieusement en plein travail.

L'API accepte ce jeton de session sous deux formes : comme cookie de session que le dashboard envoie de toute façon, ou comme en-tête Authorization Bearer. L'accès programmatique sans connexion navigateur utilise plutôt des clés API, décrites ci-dessous. Les endpoints rejettent les requêtes sans identifiant valide ; seules les routes explicitement publiques, comme le contrôle de santé et le formulaire de contact, fonctionnent sans authentification.

Rôles et permissions

Chaque compte possède exactement un rôle : CLIENT, OPERATOR ou ADMIN. Les clients possèdent des robots et paient pour les sessions, les opérateurs contrôlent des robots et tirent des gains des sessions, et les admins font tourner la plateforme. Vous choisissez entre client et opérateur lors de l'onboarding ; le rôle admin est attribué par les administrateurs de la plateforme et ne peut pas être choisi soi-même.

Les vérifications de rôle se font côté serveur à chaque requête, pas dans l'interface. Sous l'API, l'accès à la base de données est de plus restreint par des règles de row-level security, si bien qu'un bug dans un endpoint ne se transforme jamais en accès libre aux lignes d'autres comptes.

Clés API

Les clés API donnent accès aux scripts et serveurs sans connexion navigateur. Vous les créez et les révoquez dans /dashboard/settings ; les clés portent le préfixe ayr_live_ et sont envoyées comme en-tête Authorization Bearer. Une clé agit avec le rôle et les permissions du compte qui l'a créée, donc une clé qui fuite est exactement aussi grave qu'un mot de passe qui fuite.

• Gardez les clés côté serveur. Elles n'ont pas leur place dans du JavaScript côté client, des applications mobiles ou des dépôts publics.
• Utilisez une clé par intégration. En cas de fuite, vous voulez pouvoir révoquer un seul consommateur, pas tous.
• Effectuez une rotation sans interruption : créez d'abord la clé de remplacement, déployez-la, puis révoquez l'ancienne clé dans /dashboard/settings.
• Révoquez immédiatement en cas de doute. Créer une nouvelle clé prend quelques secondes ; un attaquant en possession d'une clé valide peut faire tout ce que votre compte peut faire.

Garde-fous pendant le contrôle en direct

Le contrôle en direct est lié à un bail de session. Un robot n'accepte des commandes que pendant qu'il se trouve dans exactement une session ACTIVE, et uniquement de la part de l'opérateur qui détient cette session ; le robot lui-même est marqué IN_SESSION pour tous les autres. Un opérateur ne peut détenir qu'une seule session ACTIVE ou PAUSED à la fois, ce qui exclut qu'une même personne contrôle nominalement deux bras en même temps.

Le cockpit fournit un arrêt d'urgence qui immobilise le bras instantanément, et mettre la session en pause ou y mettre fin interrompt entièrement le flux de commandes. En plus de cela, la plateforme surveille l'activité de l'opérateur : après une période sans entrée, un avertissement d'inactivité est envoyé, et si l'opérateur reste inactif, la session est arrêtée automatiquement. Cela protège les deux parties, le client contre le paiement de temps mort et le robot contre le fait de rester dans un état non contrôlé avec un bail actif.

Journal d'audit

Chaque session conserve un journal d'événements : début et fin, pauses et reprises, vérifications d'activité, avertissements d'inactivité, changements d'opérateur, demandes de prolongation et erreurs, chacun avec un horodatage. Lorsqu'un litige est examiné, ce journal d'événements constitue la preuve principale, ce qui est une raison de plus pour laquelle la plateforme l'écrit automatiquement plutôt que de se fier à la mémoire de quiconque.

Au-delà des sessions, les actions significatives sur la plateforme sont enregistrées dans un journal d'audit avec l'identifiant de l'utilisateur à l'origine de l'action, l'action elle-même, la ressource concernée et des métadonnées. Les changements de profil, les transactions liées au paiement et les actions d'administration laissent tous une trace. Les entrées d'audit sont écrites par la plateforme et ne sont modifiables par aucune interface utilisateur.

Chiffrement et protection des données

Tout le trafic à destination et en provenance de la plateforme est chiffré en transit avec TLS, y compris les flux vidéo et les signaux de contrôle. Au niveau des données, des règles de row-level security restreignent l'accès à la base de données par compte. Les données de paiement constituent la frontière la plus nette de toutes : les cartes et les coordonnées bancaires sont traitées exclusivement par Stripe et ne touchent jamais les serveurs d'AY-Robots.

Signaler une vulnérabilité

Si vous découvrez un problème de sécurité, signalez-le de façon responsable via la page /security ou le formulaire /contact en utilisant la catégorie Bug Report. Indiquez ce que vous avez trouvé, où, et comment le reproduire ; n'accédez pas aux données d'autres utilisateurs au-delà du minimum nécessaire pour démontrer le problème, et ne publiez pas les détails avant que nous ayons eu une chance raisonnable de le corriger. Nous lisons chaque signalement.

Questions fréquentes