15 — Administration de plateforme¶
ikloze est un SaaS multi-client : au-dessus des workspaces, l'équipe ikloze dispose d'un back-office pour exploiter la plateforme. Ce chapitre décrit ce que le staff peut faire — et ce qu'il doit faire pour que le produit tourne.
Un périmètre distinct
Les fonctions de ce chapitre sont transverses aux workspaces et réservées au staff ikloze. Elles reposent sur des permissions dédiées, suffixées _admin, et sur le statut de superutilisateur. Aucun client n'y accède, quel que soit son rôle dans son workspace.
Les réglages de plateforme¶
Trois paramètres pilotent le comportement économique et commercial du produit.
| Réglage | Effet |
|---|---|
| Taux de commission plateforme | La part prélevée par ikloze sur chaque vente encaissée |
| Délai d'escrow | Le nombre d'heures entre le solde d'une vente et la libération des commissions |
| Mode d'inscription | ouvert (inscription libre) ou liste d'attente (validation préalable) |
Ce sont les leviers de pilotage du modèle : le taux détermine le revenu d'ikloze, le délai d'escrow arbitre entre protection et satisfaction des closers, le mode d'inscription contrôle le rythme d'acquisition.
Une partie de ces réglages est exposée publiquement, pour que l'interface d'inscription sache si elle doit proposer un formulaire de compte ou une demande d'accès.
La liste d'attente¶
Quand le mode d'inscription est en liste d'attente, l'inscription libre est fermée : les candidats déposent une demande.
Le staff peut alors approuver, rejeter, ou renvoyer l'invitation d'une demande. Le candidat est notifié à chaque étape — accusé de réception, puis décision.
C'est le mécanisme de lancement progressif : il permet d'ouvrir le produit par vagues, de qualifier les premiers clients, et d'absorber la charge support.
La gestion des comptes¶
Utilisateurs¶
Le staff consulte l'ensemble des comptes et peut :
- suspendre un compte — l'accès est coupé, l'utilisateur est notifié ;
- réactiver un compte suspendu ;
- forcer une réinitialisation de mot de passe — en cas de compromission suspectée.
Workspaces¶
Le staff consulte les workspaces, leur liste de membres, et peut suspendre ou réactiver un workspace entier. La suspension notifie le propriétaire.
Groupes¶
Le staff administre les groupes (rôles) et les permissions qu'ils portent. C'est ce qui permet de faire évoluer les rôles standards du produit sans intervention technique.
Les opérations financières¶
C'est la partie la plus sensible du back-office : elle touche à l'argent des clients.
KYC¶
Le staff revoit les soumissions KYC : consultation des documents, puis approbation ou rejet motivé. C'est un passage obligé — sans validation, aucun closer ne peut retirer ses commissions.
C'est donc l'opération dont la latence a l'impact le plus direct sur la satisfaction des closers.
Retraits¶
Le staff traite les demandes de retrait : approbation avec note, rejet avec motif, puis marquage comme payé une fois le virement exécuté.
Le staff est notifié à chaque nouvelle demande. Le déroulé complet est décrit en 08.
Escrow¶
Le staff consulte les allocations d'escrow et peut en forcer la libération avant l'échéance programmée.
L'action est nominative et motivée : qui a libéré, pourquoi. C'est la soupape pour les litiges tranchés et les gestes commerciaux — jamais une opération silencieuse.
Portefeuilles¶
Le staff consulte n'importe quel portefeuille, son relevé, et peut procéder à un ajustement manuel.
L'ajustement manuel est un dernier recours
Un ajustement écrit dans le grand livre au même titre qu'une commission : en partie double, typé manual_adjustment, attribué à son auteur. Il corrige un incident constaté — il ne contourne pas le parcours normal. Chaque ajustement est traçable et attribuable.
Paiements¶
Le staff consulte l'ensemble des liens de paiement et des échéances de la plateforme, tous workspaces confondus. C'est l'outil de diagnostic quand un client signale un paiement non pris en compte.
La communication¶
Emails en masse¶
Le staff peut envoyer un email en masse à partir d'un fichier CSV, avec un sujet et un corps templatés — les variables du CSV sont substituées par destinataire.
Usage : annonces produit, communication d'incident, campagnes d'activation. Un aperçu du rendu est disponible avant envoi.
Emails transactionnels¶
Tous les emails du produit — confirmation de compte, invitation, notification de commission, décision KYC — reposent sur des gabarits rendus dans la langue du destinataire, avec en-tête et pied de page communs.
Exploitation technique¶
Le produit expose ce qu'il faut pour être exploité en production :
| Capacité | Rôle |
|---|---|
| Sondes de santé | Vérifier que le service est vivant et prêt à recevoir du trafic |
| Suivi des erreurs | Remontée centralisée des incidents (Sentry) |
| Journalisation structurée | Traçabilité des opérations, en particulier financières |
| Limitation de débit | Protection contre les abus et les attaques |
| File d'attente | Traitement asynchrone des paiements, notifications et libérations d'escrow |
| Stockage de fichiers | Documents KYC et logos, en local ou sur un stockage S3-compatible |
Détail technique : Architecture › Vue d'ensemble et Modules › Transverses.
Ce que le staff doit faire pour que le produit tourne¶
Trois opérations manuelles sont structurellement nécessaires — le reste est automatique :
- Valider les KYC — sinon aucun closer ne peut être payé.
- Traiter les retraits — approbation puis exécution du virement.
- Gérer la liste d'attente — si le mode d'inscription est restreint.
Tout le reste — affectation, scoring, calcul et libération des commissions, notifications, écritures comptables — se déroule sans intervention humaine.