Une plateforme ecommerce contre laquelle vous n'avez pas à vous battre

Choisissez l'une des 10 principales plateformes commerce SaaS et regardez leur documentation API. Puis regardez leur UI admin. Les fonctionnalités ne correspondent pas. L'admin peut faire des choses que l'API ne peut pas. Pire, l'éditeur de la plateforme le sait — et il considère ça comme une feature, pas un bug. Verrouiller des capacités derrière l'admin est ce qui vous maintient sur leur plateforme. Au moment où vous pouvez tout faire via API, vous pouvez aussi partir.

C'est la tension fondamentale. Les grandes plateformes SaaS (Shopify, BigCommerce, Wix Commerce) optimisent pour des marchands non techniques parce que c'est la majeure partie de leur TAM. Quand les développeurs demandent un webhook sur un événement précis, un moyen d'enregistrer une étape de checkout custom, ou un accès en écriture à une ressource jusque-là en lecture seule, la réponse est généralement « passez au tier enterprise » ou « utilisez Zapier ».

Axnify est construit différemment parce que son backend est structuré pour. Chaque domaine est un microservice (product, order, cart, theme, billing, asset, customer, payment, shipping, etc.) avec son propre schéma de base de données et sa propre API HTTP. L'UI admin est un frontend qui parle à ces APIs — exactement de la même façon que votre code. Il n'y a pas de capacité admin-only. Il n'y a pas d'« endpoint interne » que vous ne pouvez pas appeler. La surface API EST la plateforme.

Ce choix de conception a des conséquences. Cela signifie qu'Axnify est plus honnête sur ce qu'elle supporte et ce qu'elle ne supporte pas : si ce n'est pas dans l'API, ça n'existe pas. Cela signifie que les breaking changes sont détectés plus vite — vous ne pouvez pas livrer une feature admin sans livrer l'API en même temps. Et cela signifie que vous, en tant que développeur intégrant la plateforme, n'êtes jamais dans la position d'écrire un screen-scraper parce que l'admin peut faire quelque chose que votre code ne peut pas.

L'architecture classique d'une plateforme ecommerce — Shopify, Magento, WooCommerce — est une seule codebase monolithique qui tourne contre une seule base de données. Ça rend la plateforme rapide à construire au début et facile à raisonner pour les petites boutiques. Ça veut aussi dire que chaque feature partage le même runtime, le même connection pool de base de données et le même cycle de release. Quand l'équipe plateforme livre une nouvelle feature, chaque marchand l'obtient (ou le bug qui va avec) le même jour.

Axnify prend l'approche inverse. Chaque domaine commerce vit dans son propre microservice Go. Le service product possède les produits, variantes, options et stocks. Le service order possède les commandes, lignes et exécutions. Le service cart possède les paniers actifs. Le service asset possède le stockage de fichiers. Le service theme possède les thèmes, pages, sections et blocs. Il y a 20+ services au total, chacun avec son propre schéma PostgreSQL, son propre répertoire de migrations, ses propres tests, chacun déployable indépendamment.

Les services communiquent via HTTP en utilisant l'authentification par clé interne pour les appels service-à-service et JWT/X-Tenant-ID pour les appels initiés par utilisateur final. Les préoccupations partagées (auth, résolution tenant, rate limiting, logging, métriques, error tracking) vivent dans un package middleware partagé que chaque service importe. PostgreSQL est partagé mais les schémas sont isolés ; un service peut JOIN contre les tables d'un autre via des vues, mais les écritures passent par l'API du service propriétaire.

Pour vous en tant que développeur intégrant la plateforme, cette architecture a des implications pratiques. Les APIs sont stables par service : l'API product évolue à son propre rythme, l'API order au sien. Les webhooks viennent du service qui possède l'événement, avec des métadonnées riches sur qui a émis quoi. Les performances sont bornées par domaine : une requête de rapport lente dans le service analytics ne peut pas bloquer votre appel order-create. Et le debug est plus simple parce que chaque requête porte un request ID loggé à travers chaque service qu'elle touche.