Workbench développeur

Le Workbench est la surface développeur intégrée au dashboard marchand. Il réunit les outils nécessaires pour diagnostiquer une intégration, tester les ressources API, inspecter les événements, consulter les logs HTTP, gérer les webhooks et piloter le shell ikw depuis une expérience encadrée.

Positionnement produit

Le Workbench sert trois objectifs :

• aider un marchand ou un intégrateur à comprendre l’état réel de son intégration ;
• fournir des outils de test sûrs avant le passage en live ;
• rapprocher l’expérience dashboard et l’expérience CLI, sans exposer des actions sensibles hors contrôle.

La surface est pensée comme une console opérationnelle. Elle ne remplace pas les pages métier du dashboard, mais elle donne un point d’entrée rapide pour investiguer, vérifier et débloquer une intégration.

Onglets

Onglet	Usage
Aperçu	Readiness métier, politique d’exécution, outils de test et blockers go-live
Console	Messages de diagnostic et retours applicatifs du Workbench
Events	Liste et détail des événements marchand, avec recherche et inspection JSON
Webhooks	Endpoints webhook, statuts de livraison, secret et actions de test
Logs	Logs HTTP filtrables par URL, corrélation, statut, méthode et latence
Insights	Indicateurs d’intégration et signaux utiles au diagnostic
Automations	Automatisations et simulations liées aux workflows marchand
Shell	Interface de commande ikw intégrée au dashboard
API Explorer	Exécution guidée de requêtes API autorisées

Shell intégré

Le Shell Workbench expose une expérience proche du CLI public ikw, mais avec des garde-fous supplémentaires :

• la saisie se fait dans la barre de commande dédiée, pas directement dans la zone terminal ;
• l’historique reste local au contexte Workbench ;
• les commandes browser-safe sont exécutées directement dans le dashboard ;
• les commandes mutantes passent par le broker backend lorsqu’elles sont allowlistées ;
• les commandes sensibles exigent une preuve step-up workbench.command.execute.

Le terminal affiche une bannière de démarrage Ikawaari, les sorties de commandes et les erreurs caviardées. Les tokens de couleur sont adaptés aux thèmes clair, sombre et aligné sur le thème global.

Test local des webhooks

L’onglet Webhooks permet de créer une session de relais locale compatible avec le CLI public :

ikw listen --forward-to http://localhost:4242/webhooks

La session est limitée au mode test/sandbox, possède un secret de signature court terme et peut être révoquée depuis le Workbench. Les événements générés avec ikw trigger <event_type> ou depuis les outils de test du dashboard sont livrés au CLI, puis transférés vers votre serveur local avec les mêmes headers de signature qu’un webhook standard.

Ce flux remplace le besoin d’un tunnel externe pour les scénarios de test simples. Pour des webhooks live ou des intégrations exposées publiquement, utilisez toujours un endpoint HTTPS configuré dans la page Webhooks.

Politique d’exécution

La politique d’exécution sépare les commandes en deux familles :

• Read-only navigator : commandes de lecture exécutables depuis le navigateur, par exemple liste de clients, payouts, webhooks ou événements.
• Mutating broker : commandes qui changent l’état et doivent passer par le backend, avec allowlist, audit et step-up.

Les commandes non allowlistées doivent rester bloquées, même si elles existent dans le CLI public. Le Workbench affiche la politique active pour éviter toute ambiguïté entre “commande connue” et “commande exécutable ici”.

Audit et sécurité

Chaque exécution broker doit produire des traces d’audit :

• accepted lorsque la commande est acceptée par la politique ;
• succeeded lorsque l’exécution se termine correctement ;
• failed lorsque le broker ou le provider retourne une erreur.

Les payloads sensibles sont caviardés côté serveur avant journalisation. Les clés API, secrets webhook, tokens bearer, headers d’autorisation et valeurs similaires ne doivent jamais apparaître en clair dans les logs, l’audit ou les erreurs UI.

Mode test et live mode

Le mode test doit être visuellement explicite sur toute la surface dashboard, y compris dans le Workbench ouvert ou en plein écran. Les actions suivantes doivent rester protégées par des garde-fous live-mode :

• API Explorer ;
• Shell ;
• replay d’événements ;
• test events ;
• broker execution.

Le mode live ne doit pas être activé implicitement depuis une commande. Les actions mutantes live exigent une intention utilisateur claire et une confirmation adaptée au risque.

Readiness métier

L’onglet Aperçu doit synthétiser une readiness exploitable pour le go-live :

• présence de clés API valides ;
• configuration webhook et santé des livraisons ;
• erreurs API récentes ;
• santé événements ;
• posture de version des SDK/CLI ;
• blockers go-live restants.

Cette readiness complète la checklist Préparation au go-live en reliant les signaux techniques aux décisions métier.

Dépannage

Si une commande échoue dans le Shell Workbench :

1. vérifiez si elle existe dans ikw --help ;
2. vérifiez si elle est allowlistée dans la politique Workbench ;
3. vérifiez si elle exige un broker backend ;
4. vérifiez si une preuve step-up récente est requise ;
5. consultez les onglets Logs, Events et Console pour retrouver la corrélation.

Pour les commandes publiques hors dashboard, utilisez le CLI installé localement :

npx @ikawaari/ikw --help