Aller au contenu

· la fractale

Une fractale de gestion, et des clients qui gèrent eux-mêmes en fractale

Une boutique, un client, un , une flotte entière : la même forme à chaque échelle. C’est ce qui permet de faire naître, d’entretenir et de réparer beaucoup d’univers avec les mêmes gestes, et de donner à chaque client la même maîtrise sur les siens.

Une boutique, un univers

En développement · conçu

Les modèles de boutique ne sont pas encore construits ; le socle commun, lui, est mesuré en labo.

Chaque boutique vit dans son propre univers : un qui porte tout ce dont elle a besoin, et rien pour les autres. Ses secrets, sa base de données, ses preuves et son sont à elle seule.

Pas d’effet domino

Si une boutique tombe, les autres continuent : elles ne partagent ni secrets, ni base, ni .

Une restauration propre

Une boutique se reconstruit à partir de sa description et de la sauvegarde de ses données, sans toucher aux voisines.

Un qui ne voit qu’elle

L’ de la boutique ne connaît qu’elle : il n’est jamais pollué par le reste.

Le même socle partout

Entre une boutique WordPress et une boutique PrestaShop, seule la brique métier change.

Le client pilote sa fractale avec Helm

En développement · conçu

Le client a son propre univers Helm. Cet univers pilote un univers « shop manager », relié à ses boutiques, jusqu’à cinq dans l’offre imaginée. Toute l’équipe parle à Helm, à l’écrit depuis son espace de travail ou à la voix depuis son standard, chacun selon son niveau.

Sa juridiction

Plein pouvoir sur ses univers, jusqu’à leurs moindres composants.

Hors de sa juridiction

Les machines, les organes qui fabriquent, les images de référence, les autres clients.

Des niveaux prouvés, pas déclarés

Chaque personne progresse par missions guidées, sans piège : ce que Helm exécute directement dépend du niveau qu’elle a démontré ; au-delà, Helm prépare et fait valider.

La fractale du client

Il fait avec ses boutiques ce que nous faisons avec nos machines : décider, observer, corriger, dans son périmètre.

Schéma

Qui gère qui

Qui gère quiracine maîtreorganes de fabricationflottetous les SaaSun SaaS de boutiquestient le registreun autre SaaStéléphonieun autre SaaSdémonstrationun client : sa juridictionunivers Helml’équipe du client pilote icishop managerboutiqueboutiqueboutiqueplace libreplace librejusqu’à cinq boutiques dans l’offre imaginéechaque boîte est le parent de celle qu’elle contient

Faites glisser pour voir tout le schéma

Cet emboîtement est celui de la gestion, pas celui des machines : les univers d’un même client peuvent tourner sur plusieurs machines.

On ne scie jamais la branche sur laquelle on est assis

Une règle de conception, pas une fonction à cocher.

Un univers ne modifie jamais son propre fonctionnement pendant qu’il tourne. C’est toujours le parent qui fait les modifications profondes de son enfant, de l’extérieur : le tandem humain et en charge de l’univers racine le modifie et le répare ; l’univers racine, qui porte les organes de fabrication, fait naître et répare l’univers Helm du client ; l’univers Helm modifie le shop manager ; le shop manager modifie chaque boutique ; une boutique fait son travail, et c’est tout.

Si le besoin touche le modèle commun de toutes les boutiques, il remonte à ceux qui le fabriquent : une nouvelle version est prouvée, puis chaque boutique y passe par décision, sauvegarde avant et preuve après. Un client qui exige un socle différent reçoit sa propre variante.

Schéma

Le parent modifie l’enfant

Le parent modifie l’enfantle tandem humain et agentde l’univers racinemodifie et répare, de l’extérieurl’univers racineorganes de fabricationmodifie et répare, de l’extérieurl’univers Helm du clientmodifie et répare, de l’extérieurle shop managermodifie et répare, de l’extérieurune boutiquefait son travail, et c’est toutun univers ne modifiejamais son proprefonctionnementpendant qu’il tourne

Faites glisser pour voir tout le schéma

Chaque échelon modifie et répare celui du dessous, de l’extérieur. Personne ne se modifie lui-même en marche.

Un qui fabrique et entretient

En développement · mesuré en labo

La chaîne complète, de l’inscription à la naissance d’un univers, a fonctionné de bout en bout une fois, dans un environnement de démonstration. La mise en pause et le déploiement avec PodMesh sont seulement conçus.

Chaque tient un registre de ce qui doit exister, client par client. Selon la facturation, il y inscrit les univers à créer, à détruire ou à mettre en pause. Sur chaque machine, un maker, la main de la machine, demande ce qu’il y a à faire, fait naître ou finir les univers, et rapporte ce qu’il a constaté. Les images de référence sont préparées à l’avance : un univers naît d’une image déjà prête, il ne s’installe pas.

Quand un client paie

Une ligne s’écrit ; le maker de la machine choisie la lit ; l’univers naît avec la spécialisation et la marque du client ; le maker rapporte un fait vérifié, jamais un simple « c’est fait » ; l’univers apparaît dans le Helm du client.

Deux vues du même système

Qui décide (le registre, puis les makers) et où ça tourne (des univers côte à côte sur plusieurs machines). La gestion ne suit pas l’emplacement.

Les deux formes d’univers

Un système classique, ou un univers déployé avec PodMesh, qui l’inscrit dans le plan de continuité et de reprise du cluster.

Schéma

Deux vues du même système

Deux vues du même systèmequi décideregistreun par SaaSce qui doit exister, selon la facturationcréerdétruiremettre en pausedemande / répondmakermachine 1makermachine 2makermachine 3sans port ouvertoù ça tournemachine 1machine 2machine 3les univers d’un même clientla gestion ne suit pas l’emplacement

Faites glisser pour voir tout le schéma

À gauche, qui décide : le registre dit ce qui doit exister, les makers le lui demandent et rapportent ce qu’ils ont constaté. À droite, où ça tourne : les univers d’un même client sont répartis sur plusieurs machines.

L’entretien, là où est la puissance

Des principes de conception, pas des fonctions livrées.

Une correction, toute la flotte

On corrige le modèle, on prouve la nouvelle version, et chaque univers y passe par décision.

Rien ne bouge tout seul

Un univers vivant reste sur la version qui l’a fait naître : améliorer le modèle ne casse jamais un client .

Chacun répare à son étage

À l’intérieur d’un univers on répare ses composants ; la naissance et la fin viennent du maker ; le parent vérifie l’enfant.

Le silence est un événement

Une machine qui ne donne plus de nouvelles déclenche une alerte, jamais un voyant vert.

Les sauvegardes sont tirées

Le coffre va chercher les copies, il n’écoute personne.

Grandir sans cérémonie

Ajouter une machine, c’est ajouter un maker ; ajouter un produit, c’est ajouter un modèle, sans toucher aux machines.

Plusieurs , une seule flotte

En développement · conçu

Chaque produit vendu a son propre registre : boutiques, téléphonie, démonstration, et demain d’autres. Les machines restent communes, et sur chacune un seul maker sert tous les registres. Le maker ne sait pas ce qu’il fabrique : il lit une adresse, une empreinte et une recette. Un nouveau ne demande donc aucun nouveau robot. Un même client peut piloter, dans un seul Helm, des univers venus de plusieurs .

La démonstration marche pareil : un visiteur s’inscrit, un univers de démonstration naît pour lui, et à l’échéance il est détruit, avec la preuve de son absence. On apprend le geste là où une erreur ne coûte rien.

Ce que nous promettons

La méthode, pas le chronomètre. Chaque étage suit le même ordre, sans état caché ni geste manuel ; ce qui n’est pas encore prouvé est marqué comme tel sur cette page.

Vous avez plusieurs boutiques, sites ou équipes à piloter ?

Parlons de ce que vous voulez piloter, et de ce qui est déjà prouvé aujourd’hui : chaque statut de cette page dit où en est la réalité.