Blog

Qu’exiger d’un helpdesk qui détient vos clés API de marketplace ?

Une clé API Mirakl lit chaque commande et émet chaque remboursement ; une clé Sendcloud imprime des étiquettes sur votre compte. Les confier à un outil de SAV engage. Dix questions, et les réponses à exiger.

· 5 min de lecture · L’équipe Miross

Pour bien répondre à un client de marketplace, un outil de SAV a besoin d’accès : aux commandes et aux messages de la marketplace, à votre plateforme d’expédition, à votre boîte mail, parfois à votre facturation. Chacun de ces accès est une clé API ou un identifiant de compte, et chacun donne beaucoup de pouvoir. Une clé API Mirakl n’est pas en lecture seule. Elle peut accepter des commandes, les expédier et les rembourser. Une clé de plateforme d’expédition peut créer des étiquettes qui vous seront facturées.

La question n’est donc pas de savoir si un helpdesk peut faire le travail. C’est de savoir si on peut lui confier les clés qui rendent ce travail possible. Voici les dix questions que nous poserions à n’importe quel outil, le nôtre compris, et les réponses qui nous semblent être le minimum.

1. Où sont stockées les clés, et comment ?

La seule réponse acceptable : chiffrées au repos, avec une clé de chiffrement que l’application conserve à part de la base de données, de sorte qu’une copie de la base seule ne sert à rien. Demandez si cette clé de chiffrement peut être renouvelée sans interruption de service, et si cela a déjà été fait.

Un outil qui stocke votre clé API en clair dans une colonne de configuration, c’est une fuite qui n’attend plus qu’une sauvegarde égarée.

2. Pourrai-je revoir la clé un jour ?

Non. Une fois saisi, un secret ne doit plus jamais être affiché, ni dans l’interface ni dans une réponse d’API. L’outil peut vous dire qu’une clé existe, quand elle a été enregistrée et si elle fonctionne. Si un produit vous réaffiche votre clé Mirakl dans un écran de paramètres, c’est qu’elle est stockée d’une manière qui permet de la montrer à quelqu’un d’autre.

3. Que se passe-t-il si mon espace et celui d’un autre client partagent une base de données ?

C’est probablement le cas : c’est ainsi que fonctionne le SaaS. La question est de savoir si le cloisonnement est testé. Chaque point d’accès qui touche à un dossier, une connexion, un réglage ou un export doit refuser (idéalement avec une 404 plutôt qu’une 403, pour ne pas confirmer que la ressource existe) quand l’appelant n’est pas membre de cet espace de travail. Demandez s’il existe un test automatisé de ce refus pour chaque point d’accès, et si un nouveau point d’accès peut être mis en production sans le sien.

4. Où est-il hébergé, et qui peut y accéder ?

Pour des vendeurs européens qui traitent les messages de clients européens, les données doivent se trouver dans l’UE, et l’éditeur doit pouvoir dire précisément où, et ce qui y tourne. Demandez si la base de données est joignable depuis Internet (elle ne devrait pas l’être), et si l’accès d’administration se fait par clé, avec journalisation, ou par mot de passe.

5. Qu’est-ce qui sort du système, et vers qui ?

Traduction, résumés, rédaction : dès qu’une IA intervient, le texte du client part chez un fournisseur de modèles. Demandez quels fournisseurs, s’ils conservent les requêtes, et si vous pouvez couper la fonction et tout garder en interne. Posez la même question pour l’envoi d’e-mails, le suivi des erreurs et la mesure d’audience. La réponse honnête est une liste, pas « nous prenons la confidentialité très au sérieux ».

6. Qui a fait quoi ?

Chaque action qui compte (un remboursement, un changement de réglage, un nouveau membre, un export, la suppression d’un espace de travail) doit figurer dans un journal d’audit, avec l’auteur, l’heure et l’objet concerné. Pas pour jouer la comédie de la conformité : pour le jour où l’opérateur demandera qui a remboursé la commande 4471, et pourquoi.

7. Puis-je récupérer mes données, et puis-je les faire disparaître ?

Un export dans un format lisible par une machine, à la demande, sans ticket à ouvrir auprès de l’assistance. Une suppression qui supprime vraiment : un délai de grâce est raisonnable, une « suppression logique » permanente qui garde tout pour toujours ne l’est pas. Les deux doivent se trouver dans le produit, pas dans un e-mail à l’éditeur.

8. Qu’est-ce qui casse si l’outil tombe en panne, et comment le saurait-on ?

Un outil de SAV se trouve entre vous et un délai de 24 heures. Si la synchronisation s’arrête, les messages s’accumulent en silence sur la marketplace pendant que la file a l’air calme. Demandez s’il existe un contrôle de santé qui échoue bruyamment quand le traitement en arrière-plan s’arrête, quand une connexion échoue de façon répétée ou quand les e-mails sortants restent bloqués, et qui le surveille.

9. Les sauvegardes : une restauration a-t-elle déjà été faite ?

Des sauvegardes chaque nuit, c’est le minimum. La question qui distingue une vraie réponse d’une diapositive : quand avez-vous restauré une sauvegarde pour la dernière fois, et combien de temps cela a-t-il pris ? Une sauvegarde jamais restaurée n’est qu’un espoir.

10. Quel est l’accès minimal dont l’outil a réellement besoin ?

Un bon outil demande la clé la plus restreinte qui suffit au travail, et vous dit ce qu’il en fait. Lecture seule là où lire suffit (une clé de plateforme d’expédition utilisée uniquement pour le suivi ne devrait pas avoir besoin de créer des étiquettes). Là où l’écriture est inévitable, comme pour les remboursements Mirakl, l’outil doit exiger une confirmation humaine pour chaque écriture qui déplace de l’argent, revérifier l’état juste avant d’agir et consigner le résultat. « Nous ne l’utilisons que pour… » est une affirmation ; une étape de confirmation et un journal sont des preuves.

Deux choses à faire de votre côté

Donnez à chaque outil sa propre clé. Les marketplaces vous laissent créer plusieurs clés API, ou plusieurs utilisateurs API. Avec une clé par outil, vous pouvez en révoquer une sans casser les autres, et les journaux de la marketplace vous disent quel outil a fait quoi.

Renouvelez les clés quand quelqu’un s’en va. Si un collègue sur le départ a vu une clé un jour, changez-la. Avec un outil qui stocke les clés correctement, c’est l’affaire de deux minutes : collez la nouvelle clé, testez, c’est fait.

Le résumé qui dérange

Un helpdesk qui détient vos clés de marketplace peut rembourser toutes vos commandes. La plupart des éditeurs ne toucheront jamais à ce pouvoir, mais « jamais » est une promesse, et les questions ci-dessus sont des vérifications. Préférez l’éditeur capable de répondre aux dix sans rien avoir à chercher : c’est celui qui a pensé au jour où les choses tourneront mal.

Nous publions nos propres réponses sur la page sécurité. Prenez-nous au mot.