Nous avons passé les six premiers mois de VenduSys à tout modéliser. Au bout de quatre mois, nous avions dix-sept entités, huit tables de jointure, trois objets « de contexte » que personne ne parvenait vraiment à définir, et un modèle d’autorisations qui prenait vingt minutes à expliquer. Du grand classique.
Nous avons alors tout mis de côté et sommes partis d'une question : quel est le plus petit ensemble d'entités capable de modéliser toutes les formes de commerce qui nous intéressent ?
La réponse s'est avérée être quatre.
Fête
Une personne, une organisation ou un agent. Acheteurs, vendeurs, opérateurs, partenaires : autant de facettes d'un même enregistrement. La différence entre « acheteur » et « vendeur » ne réside pas dans le type, mais dans le rôle joué dans une transaction. Un acheteur dans une opération peut être un vendeur dans la suivante.
Une fois que l'on accepte cela, l'identité devient un problème de graphe plutôt qu'un problème de typage. KYB, KYC, rôles, audit, configuration des paiements… tout cela dépend du même nœud.
Chose
Tout ce qui est proposé ou détenu. Produits, licences, services, abonnements, actifs, temps. Les variantes et les offres groupées constituent des projections supplémentaires : une référence (SKU) est une « chose » sous une forme particulière, un forfait d’abonnement est une « chose » dotée d’une dimension temporelle, une heure de service est une « chose » dotée d’une dimension de capacité.
La plupart des stacks e-commerce les modélisent comme des entités distinctes (produit, forfait, service, actif), puis passent des années à combler les lacunes. Le fait de les considérer comme une seule et même entité dotée d'attributs — à durée indéterminée ou limitée, physique ou numérique, transférable ou non — permet de réduire considérablement la complexité.
Déplacer
Un événement qui entraîne un transfert de valeur ou de droits entre des parties. Commandes, retours, renouvellements, transferts, remboursements, litiges : tous ces événements constituent des « mouvements ». Un mouvement comporte un payeur, un bénéficiaire, un élément (ou un ensemble d'éléments), un montant et un état.
Le fait de modéliser les « commandes » et les « remboursements » comme des objets de même type — avec des signes différents — permet d'éliminer toute une catégorie de bogues.
Entrée
Une ligne du grand livre en partie double. Chaque opération génère des écritures ; les rapports et les soldes en découlent de manière déterministe. Il s'agit de l'entité la plus importante du système, et celle que la plupart des plateformes commerciales masquent.
Si votre plateforme sert de système d'enregistrement des transactions financières mais que votre registre n'est qu'un élément secondaire, votre plateforme est un système permettant de nier de manière plausible.
Pourquoi cela fonctionne-t-il ?
Le problème, ce ne sont pas ces quatre entités. Le problème, c'est ce qu'elles vous empêchent d’avoir :
- Il n'existe pas de types distincts d'« ordre au marché » et d'« ordre direct »
- Il n'y a pas de distinction entre « abonnement » et « achat ponctuel » : les deux correspondent à des enchaînements d'actions.
- Il n'y a pas de « portefeuille » distinct : le solde correspond à la somme des écritures passées sur un compte
- Il n'y a pas de « moteur de remboursement » distinct : un remboursement correspond à une opération de contre-passation avec des écritures de contre-passation.
- Il n'y a pas de « grand livre des associés » distinct : les versements aux associés ne sont que des écritures comptables passées sur les comptes des associés.
La forme dans le code
En gros, en TypeScript :
type Party = { id; kind: 'person' | 'org' | 'machine'; profile; trust };
type Thing = { id; kind; attrs; rights?; meter? };
type Move = { id; kind; from: PartyId; to: PartyId; thing: ThingId[];
at; state; reverses?: MoveId };
type Entry = { id; account; move: MoveId;
side: 'debit' | 'credit'; amount; ccy };Tout le reste — commandes, factures, abonnements, programmes partenaires, places de marché — relève d'un flux de travail qui les regroupe. La bibliothèque de flux de travail fera l'objet d'un autre article.
Ce à quoi nous avons renoncé
Il faut tout de même un minimum de clarté, franchement. « Commande » et « Abonnement » sont des termes utiles dans les échanges avec des non-ingénieurs. Nous les conservons comme projections dans l'interface de l'API — mais en réalité, ce ne sont que des enchaînements d'opérations. C'est cet écart qui représente un coût.
En contrepartie, nous disposons d'un système qui ne tombe pas en panne lorsqu'une nouvelle forme fait son apparition. Nous saurons que notre modèle est le bon si nous n'avons jamais à ajouter une cinquième entité. Reposez-nous la question dans trois ans.
Edwin Korver is the founder and systems architect behind VenduSys and RoundMap®. His work focuses on regenerative business, value orchestration, and the systems that help organizations move from extraction toward shared value and healthier ecosystems.