Wiresphere Docs
Tout ce qu'il faut pour travailler avec Wiresphere — organisé par public : utilisateurs finaux (système de gestion), DevOps & architectes (plateforme, exploitation, concepts) et développeurs (SDK, CLI, API).
/images.Le système de gestion
L'interface d'administration pour le quotidien : commandes, produits, contacts et paramètres — sans connaissances techniques préalables.
Accès & Connexion
Pour vous connecter au système de gestion :
- Ouvrez votre URL d'administration dans le navigateur (p. ex.
https://ihre-domain.de/admin/login) - Saisissez le nom d'utilisateur et le mot de passe reçus dans votre e-mail de bienvenue — attention à la casse
- L'icône en forme d'œil permet d'afficher le mot de passe ; « Enregistrer la connexion » mémorise votre session
- Mot de passe oublié ? Via « Réinitialiser le mot de passe » sous le bouton de connexion, vous recevez un lien de réinitialisation
Tableau de bord
Le tableau de bord offre une vue d'ensemble de la performance de votre entreprise et vous aide à suivre les indicateurs clés. La plupart des widgets peuvent être basculés via une liste déroulante sur des périodes hebdomadaires, mensuelles ou annuelles.
| Widget | Objectif |
|---|---|
| Chiffre d'affaires journalier | Recettes moyennes — commutable en hebdomadaire/mensuel/annuel |
| Commandes par jour | Volumes de vente moyens sur la période choisie |
| Croissance des utilisateurs NFC | Tendance des achats via NFC — adoption du paiement sans contact |
| Évolution du bénéfice & du chiffre d'affaires | Garder un œil sur la rentabilité et les variations saisonnières |
| Pondération des canaux | Influence des canaux de vente sur le chiffre d'affaires — base des décisions par canal |
| Répartition des modes de paiement | Distribution des modes de paiement utilisés |
| Produits les plus vendus | Meilleures ventes par volume ou chiffre d'affaires — pour les promotions et la planification |
Vue d'ensemble des processus
La vue d'ensemble des processus affiche toutes les transactions et leur statut. Les processus peuvent être filtrés (tri, type, canal, période), analysés et gérés.
- Tableau : numéro de transaction, client, date, montant (HT), statut de paiement, canal, numéro de type et type (devis, facture, commande)
- Statut de paiement : Payé (vert) · En attente de paiement (jaune) · En cours (orange) · Échu/en retard (rouge)
- Actions : « + Ajouter une transaction », « Exporter la sélection » et « Appliquer les filtres »
Détails d'un processus
Un clic sur un processus dans la vue d'ensemble ouvre la vue détaillée avec toutes les informations sur son déroulement.
- Détails client & paiement : nom, numéro de client, e-mail ; statut de facturation et mode de paiement (p. ex. NFC Payment)
- Adresses : les adresses de facturation et de livraison sont modifiables via l'icône d'édition
- Tableau des articles : référence article, désignation, quantité, prix unitaire, TVA, poids total, prix total
- Récapitulatif des prix : sous-total, remise, frais de port, TVA, total général
- Actions : ajouter un article, annuler la sélection, imprimer le QR code, supprimer le processus, enregistrer
Gérer les produits
La vue d'ensemble des produits (menu « Gestion des marchandises » → « Vue d'ensemble des produits ») liste tous les produits avec référence article, prix HT, stock et statut.
Créer & modifier un produit
Vous créez de nouveaux produits via « + Ajouter un produit » (nom d'article, référence article, catégorie, prix, stock → Enregistrer). Vous modifiez les produits existants via l'icône crayon dans la ligne du tableau.
Prix dégressifs
Dans l'onglet « Prix par paliers » de la vue détaillée du produit, vous définissez pour chaque palier la quantité minimale et le prix ; via « + ajouter », vous complétez d'autres paliers.
Add-On-Sellings
Les ventes additionnelles (accessoires, upgrades, garanties) peuvent être associées directement à un produit principal et sont proposées automatiquement lors de la commande — cela augmente la valeur du panier et favorise le cross-selling.
Exporter / importer des produits
Exporter : toutes les données produit (nom, référence article, prix, stock, catégories) au format XLS ou CSV — pour l'analyse, le traitement externe ou la documentation.
Importer : des données produit révisées ou nouvelles au format XLS/CSV. Le système reconnaît les produits existants grâce à la référence article et met à jour les informations modifiées ; les nouveaux produits sont ajoutés sans écraser l'existant.
Catégories
Sous « Catégories », vous répartissez vos produits en groupes — cela facilite la gestion et la recherche dans l'assortiment.
- Nom : parlant et univoque
- Slug : version du nom compatible URL (minuscules, sans caractères spéciaux ni espaces) — important pour les liens et le SEO
- Propriétés de filtre & navigation : complétées automatiquement par le système après l'enregistrement
- Enregistrer / Supprimer : les suppressions font l'objet d'une confirmation supplémentaire par sécurité
CRM : contacts & organisations
Le module CRM gère de façon centralisée les interlocuteurs (personnes) et les organisations — accessible via l'onglet « CRM » de la navigation principale.
- Créer un contact : « + Ajouter un contact » → choisir personne ou organisation → saisir les données → associer éventuellement la personne à des organisations → Enregistrer
- Modifier : icône crayon à côté de l'entrée — c'est là aussi que se font l'ajout et la suppression (attention : la suppression est définitive)
- Rechercher & filtrer : via la barre de recherche, par nom, adresse e-mail et autres critères
Exporter / importer des contacts
Exporter : tous les contacts au format XLS ou CSV — pour le traitement ultérieur, l'archivage ou l'analyse.
Importer : des données de contact révisées ou nouvelles au format XLS/CSV. Les données modifiées sont détectées automatiquement et les entrées existantes mises à jour — sans doublons. Idéal pour la maintenance régulière des données et la consolidation de sources diverses.
Activer / désactiver des comptes
Sous CRM → Personnes → Modifier la personne se trouve l'interrupteur « Le compte est désactivé » — utile en cas de changement de service, d'absence ou de départ.
Si l'interrupteur est actif, la personne ne peut plus se connecter ; s'il est désactivé, elle retrouve un accès normal. Confirmez les modifications avec « Enregistrer ». La désactivation ne supprime aucune donnée — le compte peut être réactivé à tout moment.
Paramètres
L'icône d'engrenage en haut à droite donne accès aux configurations centrales — structurées à gauche en Boutique (modes de paiement, plugins, devises), Utilisateurs (rôles et autorisations), Taux de taxe et Unités.
Plateforme, concepts & exploitation
Architecture de la plateforme, options de déploiement, fonctionnement et le manuel d'administration pour l'exploitation technique.
Qu'est-ce que Wiresphere ?
Wiresphere est une runtime modulaire pour les logiciels d'entreprise. Les applications ne sont pas construites une fois puis maintenues, mais composées à l'exécution à partir de modules interchangeables. L'écosystème se compose de quatre briques : la Runtime charge, isole et orchestre les modules. Le Module SDK définit comment les modules sont construits — contract-first, type-safe, versionnés. L'Enterprise SDK l'étend avec des Private Functions sans obligation de publication, ainsi que le SSO, les policies et le raccordement à l'audit. Le Marketplace assure la découverte, la gestion des licences et les mises à jour automatiques des modules vérifiés.
Le cœur est open source et fonctionne dans le cloud UE ou sur votre propre infrastructure. Il n'y a ni licences ni commission sur le GMV — seule l'infrastructure est facturée.
Concepts clés
Module
L'unité de base de Wiresphere. Un module encapsule une capacité métier (p. ex. checkout, connexion à l'entrepôt, configurateur) dans un scope isolé avec un contract explicitement typé. Ce qui ne figure pas dans le contract n'existe pas pour les autres modules.
Scope
L'espace d'isolation d'un module. Les scopes limitent l'accès et la portée des erreurs : un module ne peut pas accéder à un état étranger, et une erreur reste confinée à son propre scope. Les scopes sont volontairement petits — assez petits pour qu'un agent de codage au contexte limité puisse les appréhender entièrement.
Contract
L'interface typée et versionnée sémantiquement d'un module. Les contracts sont imposés au niveau du Service Broker : il reçoit les requêtes des modules via HTTP et les valide avant traitement — les appels incompatibles sont rejetés, et non découverts en production.
Composition
L'état d'une application : quels modules sont actifs, dans quelle version, et comment ils sont connectés. Les compositions se modifient à l'exécution — charger, remplacer, désactiver des modules — sans redéploiement.
Glossaire
| Terme | Signification |
|---|---|
| Runtime | Couche d'exécution : charge les modules, isole les scopes, orchestre la communication |
| Module SDK | SDK TypeScript pour construire des modules contre des contracts typés |
| Enterprise SDK | Extension du Module SDK : Private Functions sans obligation de publication, SSO, policies, audit |
| Marketplace | Catalogue de modules vérifiés avec gestion des licences et canaux de mise à jour automatique |
| Canal de mise à jour | Chemin versionné (p. ex. stable/beta) par lequel les mises à jour de modules arrivent dans les applications |
| Wiresphere Cloud | La plateforme officielle d'hébergement cloud : déploiement en un clic, mises à jour gérées, hébergement UE |
| Certification | Processus de revue (vérification des types, compatibilité, qualité) avant l'entrée d'un module au catalogue |
Options de déploiement
- Wiresphere Cloud (UE) : infrastructure préconfigurée à mise à l'échelle automatique. Déploiement en 1 clic sur Wiresphere Cloud — démarrage gratuit.
- Auto-hébergement : la runtime open source fonctionne sur votre propre infrastructure — on-premise ou dans le cloud de votre choix. Fonctionnalités complètes, souveraineté totale sur les données.
- Hybride : runtime on-premise, raccordement au Marketplace pour les modules et les mises à jour via des canaux contrôlés.
Quel que soit le déploiement, le code source et les données restent entre vos mains — la plateforme est conçue pour permettre la sortie (exit-ready by design).
Composition à chaud
Les modules sont insérés, remplacés ou désactivés dans l'application en cours d'exécution — sans downtime et sans fenêtre de maintenance. Avant chaque modification, la runtime vérifie la compatibilité des contracts de la composition cible ; les modifications incompatibles sont rejetées avant de prendre effet.
Déroulement d'une modification
- La nouvelle version du module est chargée et initialisée dans le scope
- La runtime câble les contracts et redirige les appels de manière atomique vers la nouvelle version
- L'ancienne version est déchargée ; en cas d'erreur, un rollback automatique s'applique par module
Scopes isolés
Chaque module s'exécute dans son propre scope aux frontières définies. Cela limite le rayon d'impact des erreurs, empêche les couplages cachés et rend les modules développables, testables et maintenables indépendamment — y compris par des agents de codage dont le contexte ne suffirait jamais pour un monolithe.
Mises à jour & Rollback
Les modules reçoivent leurs mises à jour via des canaux versionnés depuis le Marketplace. Avant l'installation, la runtime vérifie la compatibilité sémantique par rapport à la composition active. Chaque mise à jour est réversible par module — une mise à jour défectueuse n'exige pas de restauration de l'application.
stable et validez d'abord les nouvelles versions de modules dans une composition de staging.Frontends
Les frontends sont découplés des modules et consomment les mêmes contracts — qu'il s'agisse du web, d'une app, d'un back-office B2B ou de matériel kiosque sans contexte navigateur. La pile frontend est librement choisie ; en changer n'exige aucune migration du backend.
Channels & Checkout Handler
Wiresphere fonctionne en Channels : des canaux autonomes par lesquels les commandes sont passées. Les channels disponibles sont E-Commerce, Kiosque, Caisse, Live Chat et AI Chat. Tous les channels alimentent les mêmes modules — la logique de commande n'existe qu'une seule fois.
Rôles & autorisations
Chaque channel obéit à son propre concept de rôles et d'autorisations. Les droits sont attribués par canal — un agent de chat, un caissier et un assistant IA agissent avec des autorisations différentes, sans habilitations globales.
Checkout Handler
Des Checkout Handlers flexibles déterminent le déroulement de la commande dans chaque channel. Une même commande peut ainsi suivre un parcours totalement différent selon le canal :
| Channel | Parcours de checkout typique |
|---|---|
| E-Commerce | Checkout en plusieurs étapes avec panier, adresse de facturation et de livraison |
| Kiosque | Parcours raccourci — se limite pour l'essentiel au paiement |
| Caisse | Saisie guidée par le caissier au point de vente |
| Live Chat | La commande est passée dans le chat par le conseiller |
| AI Chat | L'assistant IA passe la commande — dans les limites de ses autorisations de channel |
Console d'administration
La console d'administration est le centre d'exploitation d'une application Wiresphere. Elle affiche la composition active — tous les modules, versions, canaux de mise à jour et liaisons de contracts — et journalise chaque modification.
- Vue d'ensemble de la composition : quels modules tournent dans quelle version, depuis quand, depuis quelle source
- Journal des modifications : qui a déployé, mis à jour ou restauré quel module, et quand
- Environnements : compositions séparées pour la production, le staging et le développement
Gérer les modules
- Installer : choisir un module dans le Marketplace, confirmer la licence, choisir la composition cible — la vérification de compatibilité s'exécute automatiquement
- Mettre à jour : définir le canal de mise à jour par module (
stable/beta) ; les mises à jour arrivent automatiquement ou après validation manuelle - Restaurer : chaque version de module peut être ramenée individuellement à son état antérieur
- Désactiver : les modules peuvent être retirés de la composition sans être désinstallés
Utilisateurs & Droits
L'accès à la console d'administration est basé sur les rôles. Rôles typiques : Owner (tout, facturation incluse), Operator (modifier la composition, valider les mises à jour), Auditor (accès en lecture à la composition et aux journaux). Les modifications des compositions de production peuvent exiger une validation à quatre yeux.
Exploitation & Monitoring
- État par scope : santé, charge et erreurs sont relevées par module — les incidents sont directement imputables à leur origine
- Audit & conformité : l'état de la composition et l'historique des modifications sont exportables à tout moment (pertinent pour les justificatifs NIS2)
- Contrôle du déploiement : région UE ou on-premise ; les données ne quittent pas la juridiction choisie
SDK, CLI & API
Du premier module à la référence de l'API REST — contract-first, type-safe, versionné.
Démarrage rapide
Démarrer la runtime locale, générer un squelette de module, composer — sans inscription :
# Démarrer la runtime locale npx wiresphere dev # Générer un squelette de module (TypeScript, contract-first) npx wiresphere create module my-checkout # Composer le module dans l'application en cours d'exécution — aucun rebuild npx wiresphere compose add ./my-checkout
La runtime de développement tourne par défaut sur localhost:4200 et affiche la composition active, y compris tous les modules chargés et leurs versions de contract.
Module SDK
Les modules sont construits en TypeScript contre le SDK. Le contract en est le cœur — il définit ce que le module offre et consomme :
import { defineModule } from "@wiresphere/sdk";
import { CartContract, PaymentContract } from "./contracts";
export default defineModule({
name: "checkout",
version: "1.4.2",
contracts: { cart: CartContract, payment: PaymentContract },
scope: { isolation: "strict" },
setup({ runtime, config }) {
runtime.expose("checkout.session", createSession(config));
},
});
| Option | Type | Description |
|---|---|---|
name | string | Nom de module unique dans le catalogue |
version | semver | Version sémantique ; les sauts de version majeure signalent des ruptures de contract |
contracts | Record | Interfaces typées que le module offre/consomme |
scope | ScopeConfig | Degré d'isolation et limites de ressources du module |
setup | Fonction | Initialisation ; reçoit le handle de la runtime et la configuration |
API Runtime
| Méthode | Description |
|---|---|
runtime.expose(key, impl) | Met à disposition une implémentation sous une clé de contract |
runtime.resolve(key) | Résout un contract — typé, la version est vérifiée |
runtime.on(event, handler) | Réagit aux événements du cycle de vie (load, swap, unload) |
runtime.compose(change) | Modification programmatique de la composition (p. ex. depuis des outils d'administration) |
Contracts & Versionnement
Les contracts sont versionnés sémantiquement. La runtime accepte automatiquement les mises à jour mineures et les correctifs (rétrocompatibles) ; les mises à jour majeures exigent une modification explicite de la composition. Les incompatibilités sont interceptées au niveau du Service Broker (validation de chaque requête HTTP contre le contract versionné) et au moment de la composition — jamais seulement en production.
CLI
| Commande | Description |
|---|---|
wiresphere dev | Démarrer la runtime de développement locale avec composition à chaud |
wiresphere create module <name> | Générer un squelette de module avec modèle de contract |
wiresphere compose add|remove|swap | Modifier la composition de l'environnement cible |
wiresphere test | Tester le module de manière isolée contre ses contracts |
wiresphere publish | Soumettre le module à la certification du Marketplace |
API REST
Outre le SDK et la CLI, Wiresphere fournit une API REST multi-tenant. La référence complète des endpoints avec tous les schémas de requête/réponse est disponible sur une page dédiée :
Ouvrir la référence API complète
Authentification
L'API utilise une authentification par token (Bearer JWT). Les tokens se demandent via POST /api/v1/auth/token-auth avec username et password et sont valides 24 heures. Un token expiré ou invalide entraîne un 409 Conflict.
Authorization: Bearer <dein-token>
Concept de tenant
L'API est multi-tenant : presque chaque requête doit identifier le contexte de la boutique via l'en-tête tenant-id — sans lui, les requêtes sont rejetées. Exception : l'authentification en tant qu'utilisateur admin (l'en-tête ne doit alors pas être envoyé).
tenant-id: mein-shop-id
Pagination, filtres & tri
Tous les endpoints de liste prennent en charge des paramètres de requête uniformes :
| Paramètre | Défaut | Description |
|---|---|---|
p | 0 | Numéro de page (base 0) |
s | 10 | Entrées par page |
f | — | Expression de filtre |
o | — | Expression de tri |
# Filtre simple (recherche par sous-chaîne) f=fieldName::value # Plusieurs valeurs (liées par OU) f=fieldName::val1~~val2 # Exclure (préfixe --) f=fieldName::--ausgeschlossenValue # Filtre de période (ISO 8601) f=min_createdAt::2024-01-01T00:00:00.000Z # Tri o=createdAt::DESC,name::ASC
Groupes d'endpoints
| Domaine | Contenu | Référence |
|---|---|---|
| Authentification | Demander un token (JWT) | api.html#ep-auth |
| Inventaire | Créer, lire, mettre à jour des produits ; enregistrer des opérations | api.html#ep-inventory |
| Transactions | Listes de transactions avec paramètres doctype, de filtre et de tri | api.html#ep-transactions |
| Personnes (CRM) | Gérer les personnes, entretenir les relations | api.html#ep-persons |
| Organisations (CRM) | Gérer les organisations, entretenir les relations | api.html#ep-organisations |
| Catalogue / Slugs | Gestion des slugs pour le catalogue | api.html#ep-catalog |
| Catégories & navigation | Tri et mises à jour de la navigation | api.html#ep-categories |
| Paramètres | Lire et écrire les settings | api.html#ep-settings |
| Gestion de fichiers | Uploads (multipart), téléchargements | api.html#ep-files |
| Paiement / Stripe | Webhooks Stripe et endpoints de statut | api.html#ep-payment |
| Import / Export | Import et export de données | api.html#ep-import-export |
| Modèles de données | Schémas : PersonDTO, AddressDTO, ProductDataDTO, Slug, etc. | api.html#schemas |
Guide : composer une boutique
Une boutique headless naît de quatre modules du catalogue — sans développement propre :
checkout— panier, paiement, fulfillmentlager-interface— stocks et disponibilités issus de la gestion des marchandisessubscription-management— en option pour les abonnements et paiements récurrents- Le frontend de votre choix — web, app ou kiosque, raccordé via les mêmes contracts
Vous ajoutez vos exigences propres (p. ex. logique de prix) sous forme de module dédié — le reste de la composition reste intact.
Guide : publier un module
- Développer : construire le module contre le SDK, le valider localement avec
wiresphere devetwiresphere test - Soumettre :
wiresphere publish— la vérification des types, la revue de compatibilité et de qualité s'exécutent dans le processus de certification - Distribuer : le Marketplace prend en charge la gestion des licences et les mises à jour automatiques — avec un revenue share équitable
Détails sur le programme partenaires et la certification : Développeurs → Publier un module.