Sécurité et confidentialité

Rock API traite vos identifiants API et le contenu des requêtes pour authentifier, acheminer et facturer les appels aux modèles. La passerelle transmet le contenu à un service en amont pour l’inférence. Avant d’envoyer des données sensibles, examinez le traitement par la passerelle et les conditions applicables au circuit réellement utilisé en amont. Cette page décrit les comportements vérifiés dans l’implémentation et les mesures que vous pouvez prendre. La configuration de production, les durées de conservation opérationnelles et les contrats des prestataires doivent être confirmés séparément ; le code ne suffit pas à établir ces politiques.

​

Parcours des données

1. Votre application envoie sa clé API et sa requête à l’adresse HTTPS https://rockapi.ai/v1. Effectuez cet appel côté serveur ; consultez Authentification.
2. La passerelle vérifie la clé et le compte, applique les restrictions configurées et sélectionne un canal en amont. Selon l’interface et le canal, elle peut remapper le nom du modèle, convertir le format, remplacer des paramètres ou transmettre directement le corps de la requête.
3. Le service en amont reçoit les éléments nécessaires à l’inférence : messages, entrées des outils, médias fournis ou références à ces médias. La passerelle traite la réponse et les informations d’utilisation, puis renvoie le résultat au client.
4. Les journaux d’utilisation et d’erreur servent à la facturation et au diagnostic. Les tâches multimédias asynchrones peuvent aussi conserver des entrées, un état, des données du prestataire et des URL de résultat. Leurs enregistrements diffèrent des journaux des requêtes textuelles.

La transmission directe du corps n’anonymise pas les données. Les adaptateurs standards utilisent les identifiants configurés pour le canal. La transmission d’en-têtes par joker ou expression régulière exclut les cookies et les en-têtes d’authentification courants, mais des remplacements explicites peuvent modifier ce comportement. Ne placez pas de secrets ou d’identifiants personnels dans des en-têtes personnalisés.

​

Protéger et révoquer les clés API

Créez des clés API distinctes par application et environnement. Lorsque l’éditeur le permet, définissez une expiration, un quota limité, les modèles autorisés et une liste d’adresses IP autorisées. Avant le transfert vers un modèle, l’implémentation contrôle l’état de la clé, son expiration, son quota disponible et les restrictions IP configurées ; les restrictions de modèles limitent le routage. Testez la liste depuis l’adresse IP de sortie réelle de votre application. Conservez les clés dans un gestionnaire de secrets côté serveur ou une configuration d’exécution protégée. Excluez-les des fichiers JavaScript distribués au navigateur, applications mobiles, dépôts, URL, captures d’écran et traces partagées. Préférez l’en-tête d’authentification documenté aux paramètres d’URL. Les réponses de liste et de détail masquent la clé, tandis qu’une opération authentifiée distincte permet d’obtenir sa valeur complète. Ce masquage concerne l’affichage ; il ne prouve ni un hachage irréversible ni un chiffrement au repos. Pour une rotation courante, créez une clé de remplacement, mettez l’application à jour, vérifiez un appel, puis désactivez ou supprimez l’ancienne clé. En cas de fuite, révoquez d’abord la clé exposée, remplacez-la et cherchez les appels inhabituels dans les journaux d’utilisation. Vérifiez que l’ancienne clé est refusée et contactez l’assistance si elle fonctionne encore. La révocation n’efface pas les enregistrements historiques.

​

Contenu possible des journaux

La journalisation de la consommation et l’agrégation des usages sont configurables. Les vues destinées aux utilisateurs retirent certains détails administratifs ; elles ne recensent donc pas tous les champs stockés. Désactiver une catégorie ou la préférence IP ne désactive pas tous les journaux d’accès, de sécurité, de tâches ou d’infrastructure. Consultez Tarification et facturation pour rapprocher les consommations.

​

Réduire les données transmises

Envoyez uniquement les échanges, extraits de documents, résultats d’outils et médias nécessaires. Retirez mots de passe, jetons d’accès, données de paiement et informations personnelles sans rapport avec la tâche. Remplacez l’identité des clients par des pseudonymes internes et gardez la correspondance dans votre système. Vérifiez aussi les noms de fichiers, métadonnées multimédias, en-têtes personnalisés et URL signées. Validez toute nouvelle intégration avec des données fictives. Pour demander de l’aide, commencez par l’identifiant de requête ou de tâche, la date avec fuseau horaire, l’identifiant du modèle, le chemin de l’interface, le statut HTTP et le libellé de la clé. Ajoutez au besoin une courte erreur expurgée ou un exemple minimal. N’envoyez ni clé complète, ni en-tête d’authentification, ni conversation privée, ni URL multimédia signée non expurgée.

​

Conservation, entraînement et conformité

L’implémentation établit les fonctions de traitement et de journalisation. Elle ne prouve aucune politique générale de conservation nulle, aucun engagement de non-utilisation pour l’entraînement ni aucun délai fixe de suppression pour Rock API et tous ses prestataires. Avant d’utiliser des données sensibles, contactez l’assistance via la page À propos du site principal pour confirmer :

• Conservation et accès : quels corps de requête, sorties, fichiers de tâches, journaux d’utilisation, journaux d’accès et sauvegardes sont conservés ? Pendant combien de temps, avec quels droits d’accès et quelles exceptions ?
• Entraînement et autres usages : Rock API ou le prestataire effectivement utilisé exploitent-ils les entrées et sorties pour l’entraînement, l’évaluation, l’examen d’abus ou d’autres usages ? Quelles exclusions ou possibilités de refus couvrent votre compte et votre routage ?
• Prestataires et localisation : quels intervenants et régions traitent le modèle choisi, y compris lors de nouvelles tentatives ou de routages de secours ? Peut-on imposer des restrictions géographiques à votre traitement ?
• Justificatifs contractuels : un accord de traitement des données (DPA) est-il disponible ? Quelles garanties de transfert, certifications de sécurité et attestations d’audit couvrent le service souscrit et son périmètre ?

Obtenez une confirmation pour le modèle, le circuit, le compte et la catégorie de données concernés avant de poursuivre. Le nom d’un modèle ne suffit pas à déterminer ces conditions.

​

Demander la suppression d’un compte ou de données

Arrêtez l’intégration concernée et révoquez ses clés lorsque l’accès doit prendre fin. L’opération de suppression du compte utilise une suppression logique ; elle ne démontre pas l’effacement des journaux, sauvegardes, résultats de tâches ou copies détenues en amont. Utilisez le canal d’assistance indiqué sur la page À propos pour demander une suppression ou un examen de confidentialité. Fournissez l’identifiant du compte, les catégories de données, la période, les identifiants de requête ou de tâche pertinents, et précisez si la demande couvre les copies en amont. Demandez confirmation de la procédure de vérification, du périmètre, du délai, du traitement des sauvegardes et des obligations légales de conservation. Transmettez toute preuve d’identité complémentaire uniquement par le canal indiqué par l’assistance.