Pourquoi 9 produits phares, pas 30 SKU
Manera Intelligence est bâti à partir de 30+ sous-applications Python. Chacune roule comme son propre processus PM2, a son propre port, sa propre base de données, son propre cerveau. À l'interne, nous les appelons « pétales » — elles entourent le hub mesh central.
Mais sur la surface d'achat, vous voyez **9 produits phares**, pas 30. Voici pourquoi.
La taxe de confusion de l'acheteur
En 2024, quand j'avais 30 sous-applications chacune avec sa propre page /pricing, je perdais des affaires. L'objection était toujours la même : *« Comment savoir lesquelles me faut-il ? Je ne veux pas évaluer 30 SKU. »*
Le coût d'un SKU additionnel n'est pas zéro. Chaque décision d'achat additionnelle est une chute de conversion d'environ 10 %. Si vous avez 30 SKU chacun avec un taux de conclusion de 50 %, votre taux de conclusion effectif sur une affaire multi-SKU est `0,5^N` — qui s'évanouit rapidement.
Notre solution : effondrer les 30 sous-applications en 9 « unités d'achat » phares.
| Produit phare | Sous-applications à l'intérieur | |---|---| | Cyber OS | IdentityPulse, EndpointPulse, CloudPulse, PhishingPulse, AdversarialAI, ResiliencePulse, ThreatPulse | | Treasury | FXWatch, EarningsIntel, SentimentDNA, NEIP, CommodityWatch | | Strategy | MAScope, NexusAI (mode salle de guerre), PatentPulse, GeopolRisk | | Legal | LexiWorld, RegulatoryRadar, moteur de contrats | | Real Estate | RealEstatePulse, WeatherPulse (surcouche risque climatique) | | NexusAI | Orchestrateur de requêtes mesh-croisées | | Talent Intel | Talent Intel (autonome), DrManera (surcouche d'assistant) | | Trading | SATORI (admin uniquement, dormant) | | Billing | MANERAbilling (SKU instantané, dev-facing) |
L'acheteur ne se soucie pas que « PatentPulse » soit une sous-application séparée de « MAScope » — il se soucie de *Strategy*. Donc nous mettons les deux sous Strategy et laissons l'utilisateur décider quels sous-modules exécuter dans son produit phare Strategy.
Pourquoi nous avons gardé les 30 sous-applications comme modules
Si 9 produits phares est la surface d'achat, pourquoi ne pas effondrer le code aussi ?
Trois raisons :
1. Isolation des défaillances Si le flux de données de FXWatch casse à 03 h 00 UTC, cela ne fait pas tomber EarningsIntel. Chaque sous-application est son propre processus PM2. Treasury « fonctionne » même si 1 sous-application sur 5 est dégradée. Le redémarrage PM2 est un événement de 200 ms, pas un déploiement.
2. Déploiements indépendants Une correction LexiWorld ne nécessite pas un redéploiement CloudPulse. Chaque sous-application a son propre `app.py`, ses propres tests, sa propre cadence de version. Nous pouvons livrer 5x/jour sans frais généraux d'orchestration.
3. L'effet mesh Les sous-applications s'interrogent. FXWatch interroge SentimentDNA interroge NEIP. NexusAI interroge tout le monde. Si elles étaient un monolithe, ce serait des appels de fonction in-process — rapides mais couplés. En tant que 30 processus séparés communiquant via Redis + Postgres, ils sont à mise à l'échelle indépendante, à test indépendant et (de façon critique) remplaçables : nous pouvons changer le moteur sous-jacent de FXWatch sans toucher à SentimentDNA.
Ce que les acheteurs voient réellement
La vue à 9 produits phares à [/pricing](/pricing). Cliquez Treasury, vous voyez 5 sous-modules — mais ils sont tous inclus; vous ne payez pas par module. Cliquez Cyber OS, vous voyez 7 sous-modules — pareil.
C'est l'équivalent expérience-d'achat d'un Mac vs une distribution Linux : un Mac a des centaines de services qui roulent, mais vous voyez « Réglages système → Batterie ». Vous ne voyez pas launchd. Vous ne le voulez pas.
Où ça devient flou
Deux produits phares étaient presque des non-produits-phares :
- **Trading** : J'ai bâti SATORI comme mon assistant de négociation personnel au début de 2026. J'ai brièvement envisagé de le produire. J'ai décidé de ne pas le faire — conseils financiers + responsabilité d'exécution de marché est une ligne de produit séparée. Trading reste dormant sur /pricing comme espace réservé. La plupart des acheteurs l'ignorent. Les 1-2 % qui demandent sont dirigés vers la [liste d'attente](/trading). - **Billing** : Manera Billing n'est pas vraiment un produit phare côté « achat »; c'est de l'infrastructure pour développeurs. Nous le présentons sur /pricing parce que certains acheteurs (surtout des fintechs qui bâtissent sur Manera) veulent l'utiliser comme leur couche de tarification. C'est l'« étrange » du catalogue.
La leçon
Si votre produit a 30 SKU, vos calculs de conversion sont brisés. Si votre produit a 1 SKU, vous cachez de l'optionalité. Quelque part entre les deux est le bon nombre — pour nous, c'est 9, et il a fallu 18 mois pour y arriver.
Les 30 sous-applications sont toujours là. Elles roulent, elles répondent, elles s'interrogent. Mais l'acheteur n'a pas à y penser. C'est le design.
Contre-argument que j'ai entendu
> « Mais Bloomberg a un seul SKU et ça fonctionne. »
C'est vrai. Bloomberg a aussi 40 ans d'avance sur la marque. Pas nous. Les nouveaux entrants doivent être plus lisibles que l'acteur historique. 9 produits phares organisés par douleur-de-rôle-d'acheteur (CFO / RSSI / GC / CSO / DRH) est plus lisible pour un acheteur de 2026 que « Manera ». Nous gagnerons le droit de nous effondrer à 1 SKU plus tard, après avoir une marque.
Ce que cela signifie pour vous
- **En tant qu'acheteur** : n'essayez pas de cartographier nos 30 sous-applications. Choisissez juste le produit phare qui correspond à votre rôle et commencez. - **En tant que partenaire / intégrateur** : chaque sous-application expose sa propre spec OpenAPI 3.1 à `/api/openapi.json`. La spec fusionnée vit à [/api/openapi.merged.json](/api/openapi.merged.json) pour l'outillage. - **En tant que concurrent qui lit ceci** : oui, c'est un fossé d'expérience-d'achat délibéré. Ce n'est pas techniquement difficile. C'est psychologiquement difficile, parce que chaque PM veut livrer un SKU de plus.
— Kao