Résumé

  • Inmarsoft LLC doit être analysée comme un détenteur et opérateur visible de ressources réseau liées à Sendsay, non comme le vendeur public principal de la plateforme. Les registres RIPE rattachent ORG-MSL27-RIPE, AS202629, le statut LIR, l’OGRN 1147847104877 et une adresse de Saint-Pétersbourg à Inmarsoft. Les documents commerciaux de Sendsay, eux, désignent Internet Projects JSC comme partie contractante, titulaire ou contrôleur des droits logiciels et fournisseur de l’accès distant au service. Cette séparation déplace le centre de gravité économique : Inmarsoft peut porter une infrastructure importante sans que son chiffre d’affaires public prouve une thèse de logiciel à forte marge.
  • Le dossier soutient une lecture prudente. Les preuves réseau sont réelles : trois blocs IPv4 en /22, une allocation IPv6 en /29, environ 3 072 adresses IPv4 selon des sources de renseignement réseau, des routes observées via plusieurs fournisseurs, et des enregistrements SPF de Sendsay qui autorisent des blocs Inmarsoft. Mais le revenu 2024 déclaré à 516 000 roubles, avec une perte nette de 354 000 roubles, contredit toute lecture autonome de forte croissance. La valeur possible dépend donc d’un point non résolu : la manière dont le groupe autour de Sendsay répartit les revenus récurrents, les coûts de livraison, les services d’adresses dédiées, le support, la modération et le risque de réputation entre Internet Projects et Inmarsoft.

Le vrai périmètre économique

Le réflexe le plus dangereux serait de ranger Inmarsoft dans une catégorie simple de fournisseur d’hébergement local, puis d’extrapoler une histoire de substitution au cloud étranger. Les faits ne soutiennent pas une telle facilité. Inmarsoft existe dans les registres d’entreprise russes, elle est active, incorporée en 2014, identifiée par son OGRN et son INN, et associée à des codes d’activité qui couvrent le développement logiciel ainsi que l’hébergement ou le traitement de données.

Elle existe aussi dans la couche réseau internationale : RIPE relie l’organisation ORG-MSL27-RIPE à Inmarsoft LLC, à son statut de LIR, à AS202629 et à une adresse de Saint-Pétersbourg. Ce n’est pas une coquille sans empreinte opérationnelle.

Mais cette empreinte n’est pas une preuve de propriété économique de l’ensemble Sendsay. Le domaine Inmarsoft renvoie commercialement vers le site public de Sendsay. Les documents de Sendsay qui comptent pour le client payant nomment Internet Projects JSC. La page de coordonnées, la page d’accréditation informatique, l’offre publique et le contrat de licence placent le service Sendsay, l’accès distant, les droits logiciels et le paiement du côté d’Internet Projects.

Inmarsoft apparaît alors comme une frontière d’infrastructure : un détenteur de ressources, un opérateur technique possible, peut-être un prestataire interne, mais pas le visage contractuel de l’abonnement.

Cette distinction change tout. Un revenu logiciel se valorise si la société qui porte le risque porte aussi le contrat client, le droit d’usage, la capacité de prix et la relation de renouvellement. Une société d’infrastructure interne peut être essentielle tout en ayant des comptes publics minces. Elle peut aussi être un simple centre de coût. La lecture juste commence donc par l’allocation : qui encaisse le forfait mensuel, qui paie les serveurs, qui supporte les plaintes, qui maintient les routes, qui absorbe les heures de support, qui finance les développements et qui conserve l’actif le plus fragile, la réputation des adresses d’envoi.

Pourquoi un petit ASN peut avoir du poids

AS202629 n’a pas la taille d’un réseau de cloud généraliste. Les données RIPEstat examinées montrent quatre ressources annoncées : trois blocs IPv4 en /22 et une allocation IPv6 en /29. IPinfo et d’autres sources secondaires parlent d’environ 3 072 adresses IPv4 et d’une grande allocation IPv6. Dans le calcul pur, ce n’est pas un parc massif. Pour de la messagerie transactionnelle et marketing, la taille brute est pourtant la mauvaise mesure. Une adresse qui envoie des emails n’est pas seulement une ligne dans une table d’allocation ; c’est un actif de réputation, et parfois une responsabilité.

La preuve la plus parlante est le lien entre Sendsay et ces blocs. Les résolutions DNS publiques montrent que l’inclusion SPF de Sendsay autorise des blocs IPv4 et IPv6 contrôlés par Inmarsoft. Le SPF racine de Sendsay inclut ensuite cette couche. Le nom transactionnel de l’API Sendsay résout en partie vers de l’espace Inmarsoft et en partie vers de l’espace Internet Projects. Cette architecture est plus compatible avec une infrastructure de livraison, d’API et de messagerie qu’avec une offre publique d’hébergement générique.

Le client ne vient pas acheter une machine virtuelle indistincte ; il achète la capacité d’atteindre une boîte de réception, un webhook, un flux d’événements ou un canal marketing avec une performance acceptable et un risque réduit de blocage.

Dans l’email, l’économie est asymétrique. Le revenu arrive par abonnement, par volume, par taille de base de contacts, par fonctionnalités et parfois par options comme des adresses dédiées. Le coût arrive dès qu’un client dégrade la réputation commune, déclenche une modération manuelle, provoque des plaintes, demande des ajustements de délivrabilité, réclame une intégration SMTP ou API, ou exige une conservation des journaux.

L’adresse IP devient une forme de capital opérationnel : sa propreté passée et son contrôle présent peuvent soutenir la marge ; sa détérioration transforme vite un service apparemment logiciel en centre de tri, d’assistance et de conformité.

La séparation Sendsay-Inmarsoft

La marque commerciale observable est Sendsay. Elle présente une plateforme d’automatisation marketing et de données client couvrant email, web push, mobile push, SMS, Telegram, VK, API, SMTP, statistiques, segmentation et stockage CDP. La promesse est celle d’un produit logiciel : organiser la base de contacts, déclencher des messages, mesurer les ouvertures et clics, gérer les désabonnements, connecter des événements, sécuriser les comptes et industrialiser les communications d’une entreprise. Sur le papier, cette structure ressemble à un modèle de revenus récurrents.

Le détenteur visible du contrat, cependant, est Internet Projects JSC. Les documents commerciaux de Sendsay le nomment comme cocontractant. L’offre publique décrit l’accès à un service logiciel et matériel vendu à distance. Le contrat de licence parle d’une licence non exclusive par interface ou API. La page d’accréditation relie également le service à Internet Projects. Ces éléments ne sont pas décoratifs. Ils définissent qui facture, qui porte la relation client et qui peut revendiquer la propriété économique directe du logiciel.

Inmarsoft se trouve alors dans une position ambivalente. Si elle facture seulement une fonction réseau au sein de l’ensemble, son chiffre d’affaires public ne peut pas être lu comme celui d’un éditeur SaaS. S’il existe des contrats internes ou des services d’infrastructure qui lui reversent une partie significative des revenus de livraison, sa contribution peut être beaucoup plus importante que ses pages publiques ne le laissent entendre. Le dossier disponible ne permet pas de trancher.

Il permet de poser la bonne question : Inmarsoft est-elle un actif de contrôle, un prestataire de réseau, un centre de coût, ou un véhicule où une partie des revenus de livraison est logée ?

Le modèle de revenus visible

Sendsay vend une gamme dont la logique tarifaire est principalement indexée sur la taille de la base de contacts et le niveau de produit. Les pages de prix et de tarifs montrent des familles de produits, des paliers de contacts, des rabais en cas de prépaiement plus long, des notes de TVA et des modalités de paiement. Les petites bases peuvent entrer à un prix mensuel faible, puis les offres marketing et CDP montent sensiblement à mesure que la base, les fonctions et les besoins augmentent.

Cette structure est classique : elle rend le premier achat accessible, puis fait progresser le revenu par compte quand le client charge davantage de données, de campagnes et de canaux.

Sendsay Transport ajoute une lecture plus infrastructurelle. Le produit est présenté pour l’envoi massif et transactionnel par API ou SMTP. Les documents parlent de Stream API, de passerelle SMTP, de journaux, de statistiques, de webhooks, de stockage public ou privé et de comportements de bascule ou de limitation. Une telle offre ressemble moins à une simple interface marketing qu’à une brique d’envoi que des systèmes clients peuvent intégrer. L’intérêt économique est évident : quand un client branche ses opérations transactionnelles, il crée une dépendance plus forte que dans une newsletter ponctuelle.

L’intégration, les journaux, les webhooks et les règles de sécurité augmentent les coûts de changement.

Mais le même modèle attire des coûts. Plus l’envoi est proche du système opérationnel du client, plus les exigences montent. Une campagne commerciale peut être reprogrammée. Un message transactionnel attendu par un utilisateur final tolère moins la panne. Un grand compte veut des journaux, des garanties, de l’aide, parfois une adresse dédiée, parfois une configuration particulière. Le revenu devient plus durable, mais le service cesse d’être un pur logiciel auto-servi.

La marge dépend alors de la discipline d’automatisation, du nombre de clients servis par la même base technique et de la capacité à empêcher les exceptions de manger le forfait.

Qui paie, qui bénéficie, qui porte le risque

Le client de Sendsay paie pour atteindre ses propres clients. Il paie pour une base de contacts utilisable, des campagnes, des scénarios, une API, des statistiques, un stockage et une conformité locale. Il bénéficie d’un produit intégré en russe, de prix en roubles, de serveurs présentés comme russes, et d’une offre qui reste disponible dans un marché où plusieurs fournisseurs étrangers sont moins pratiques ou moins désirables pour des raisons de paiement, de données ou de géopolitique.

Pour certains clients russes, la substitution locale n’est pas seulement patriotique ou réglementaire ; elle réduit des risques de continuité et de facturation.

Le fournisseur visible bénéficie d’un revenu récurrent si le client conserve sa base, ses modèles, ses intégrations, ses historiques et ses habitudes. Une fois les déclencheurs et segments configurés, sortir n’est pas gratuit. Il faut migrer des données, recréer des modèles, revalider les consentements, rebrancher les API, réapprendre une interface et parfois reconstruire une réputation d’envoi. Cette inertie est le cœur du modèle. Elle explique pourquoi un produit d’email marketing peut avoir une meilleure économie qu’un hébergeur de machines indistinctes.

Inmarsoft, si elle porte l’infrastructure d’envoi, bénéficie d’une position rare mais supporte la mauvaise partie du risque. Les adresses et routes qui rendent possible la livraison peuvent être abîmées par des clients que l’opérateur ne choisit pas toujours directement. Les plaintes, les listes mal nettoyées, les sujets interdits et les campagnes douteuses ne détruisent pas seulement une facture ; ils consomment du temps de modération et peuvent affecter les autres clients.

Les sources non officielles ne prouvent pas un problème massif, mais elles montrent pourquoi l’assurance qualité, le filtrage et la réaction aux abus sont des dépenses structurelles, non des détails.

Unité économique : le capital des adresses

Dans un service de messagerie, la marge brute ne se calcule pas comme dans un hébergement simple. Il y a bien des serveurs, de la connectivité, du stockage, de la sécurité et du personnel technique. Mais l’actif différenciant est l’historique d’envoi. Une adresse ou un bloc utilisé proprement, authentifié correctement et surveillé activement peut soutenir des flux de messages sur plusieurs clients. Le même bloc, s’il est associé à trop de plaintes, peut imposer des limites, des quarantaines, une enquête, une migration ou une séparation de flux.

Cette logique donne une valeur économique à la petite taille contrôlée. Un réseau modeste peut être suffisant si le produit n’essaie pas de concurrencer tout le cloud, mais de servir des flux précis, authentifiés et surveillés. Les preuves SPF reliant Sendsay à des blocs Inmarsoft sont importantes parce qu’elles montrent que l’infrastructure n’est pas abstraite. Elle est dans le chemin d’autorisation de l’envoi. Si ces blocs servent des flux à marge récurrente, leur valeur dépasse le prix de location d’une adresse IP.

Le problème est que la comptabilité publique d’Inmarsoft ne montre pas cette valeur. RBC Companies rapporte pour 2024 un revenu de 516 000 roubles et une perte nette de 354 000 roubles. B2B House affiche le même ordre de grandeur et signale des revenus supérieurs à 60 millions de roubles en 2019 et 2020. Une chute aussi forte interdit de vendre une histoire simple de croissance. Elle peut refléter un transfert d’activité, une réallocation interne, un changement de facturation, une contraction réelle ou une société devenue essentiellement patrimoniale et technique.

Sans les contrats entre parties liées, on ne sait pas si Inmarsoft capture la rente de livraison ou seulement les coûts qui la rendent possible.

Fournisseurs, routes et dépendance amont

Les sources de routage citent plusieurs relations ou vues de voisinage : RETN, Severen-Telecom, EdgeCenter, Internet Projects et RetnNet selon les pages et les objets examinés. Cette diversité apparente ne doit pas être surinterprétée. Un petit AS peut afficher plusieurs liens et rester dépendant d’un nombre limité de chemins réellement utilisés, de conditions commerciales spécifiques et de la qualité opérationnelle de quelques partenaires. Pour une plateforme d’envoi, la disponibilité réseau et la réputation IP comptent ensemble.

Une route peut être techniquement ouverte mais économiquement fragile si le fournisseur augmente ses prix, change sa politique, limite certains flux ou devient plus difficile dans un contexte de sanctions et de restrictions.

L’infrastructure russe donne à Sendsay une promesse locale : serveurs en Russie, conformité aux exigences de données, prix en roubles, documents locaux, options de sécurité adaptées au marché. Cette promesse a une valeur depuis que les entreprises russes doivent gérer l’incertitude autour des fournisseurs étrangers, des paiements internationaux, des restrictions de données et de la disponibilité de services occidentaux. Mais la localisation concentre aussi les dépendances. Le fournisseur qui se vend comme local doit continuer à acheter, opérer ou remplacer des composants techniques dans un environnement plus fermé.

Les coûts de matériel, de transit, de sécurité, de talents et de maintenance peuvent monter même si le prix client reste contraint par des concurrents domestiques.

La route la plus économique n’est donc pas seulement celle qui transporte les paquets. C’est celle qui minimise le coût total de délivrabilité, de conformité et de support. Si Inmarsoft a conservé des blocs propres, une relation stable avec les amonts et une intégration opérationnelle avec Sendsay, elle possède un levier utile. Si elle doit multiplier les exceptions, changer d’amont, séparer des flux ou intervenir manuellement sur trop de comptes, l’avantage peut s’évaporer.

Les clients : signaux réels, concentration inconnue

Sendsay cite publiquement des secteurs tels que le commerce de détail, la banque, l’assurance et les services publics. Ces références sectorielles indiquent une ambition sérieuse, mais elles ne donnent pas un tableau de concentration. On ne sait pas quelle part du revenu vient de quelques grands clients, d’une longue queue de petites bases, de contrats de transport transactionnel, d’options dédiées ou de services professionnels. Cette ignorance est centrale. Une plateforme peut paraître diversifiée par le nombre de comptes et rester économiquement dépendante de quelques expéditeurs à fort volume.

Les observations SPF sur plusieurs domaines russes, qui incluent le SPF de Sendsay, donnent un signal de vraie utilisation par des tiers. Elles valent mieux qu’une page marketing isolée. Elles montrent que le service est intégré dans des configurations de domaine réelles. Mais elles ne mesurent pas le montant dépensé, la durée de relation, le volume de messages, le niveau de support ou la rentabilité. Un enregistrement SPF peut rester après une migration partielle. Il peut aussi correspondre à un compte modeste. Il confirme l’usage ; il ne quantifie pas la marge.

La concentration a un effet direct sur l’économie. Les petits clients payent peu, mais coûtent parfois cher en support s’ils manquent de compétence technique ou envoient à des listes mal qualifiées. Les grands clients payent plus, mais négocient, demandent des garanties, réclament des intégrations, et peuvent imposer un risque de réputation plus lourd si leurs volumes sont mal gérés. Le meilleur cas pour Sendsay et Inmarsoft serait une base large de clients suffisamment disciplinés, avec assez d’intégration pour rester, mais pas assez d’exceptions pour absorber l’équipe.

Le pire cas serait une poignée de clients exigeants, une longue queue peu rentable et un réseau qui porte les plaintes communes.

Alternatives et plafond de prix

Le marché russe n’est pas vide. Unisender, DashaMail, RuSender et d’autres offrent des alternatives visibles. Les pages tarifaires et comparaisons concurrentes montrent des plans gratuits, des offres Lite ou Premium, des forfaits par contacts, des produits API ou SMTP, des options d’adresse dédiée et parfois des liens avec une infrastructure cloud locale. Ces concurrents limitent la capacité de Sendsay à transformer la conformité locale et l’intégration en hausse de prix illimitée. Le client peut comparer le prix par base, par message, par fonction ou par canal.

Le plafonnement de prix ne vient pas seulement des tarifs affichés. Il vient aussi de la perception de substituabilité. Pour une petite entreprise qui envoie des campagnes simples, migrer vers une autre plateforme peut être pénible mais faisable. Pour une entreprise qui utilise CDP, segmentation avancée, Stream API, webhooks et contrôles de sécurité, la dépendance est plus profonde. Sendsay doit donc faire monter les clients dans des usages où le changement coûte réellement quelque chose. C’est là que le logiciel protège la marge mieux que le simple transport.

Inmarsoft n’est pas forcément visible dans cette bataille, mais elle en supporte une partie. Si le client paie un prix comprimé par Unisender ou RuSender, l’infrastructure sous-jacente doit rester efficace. Le coût d’une adresse dédiée, d’une configuration SMTP, d’un contrôle d’accès par IP, d’un journal détaillé ou d’une intervention de délivrabilité doit être couvert par le palier supérieur. Si le marché pousse les prix trop bas, le fournisseur risque de vendre de la complexité au prix d’un produit standard.

La pression concurrentielle rend donc l’allocation interne encore plus importante : si Internet Projects conserve le revenu et Inmarsoft supporte des coûts fixes ou des risques variables, la rentabilité de l’entité Inmarsoft peut rester faible malgré l’utilité du réseau.

Régulation et géopolitique

La réglementation russe est au centre de la proposition. Sendsay met en avant la protection des données personnelles selon la loi fédérale 152-FZ, des serveurs en Russie, une attestation de sécurité en 2024, des contrôles d’accès, des journaux, des rôles, des restrictions par IP et des options comme le VPN GOST ou les adresses dédiées. Pour une organisation russe qui manipule des données de clients, ces éléments peuvent compter davantage qu’une interface plus élégante.

La conformité locale réduit un coût de décision : le responsable peut acheter sans expliquer pourquoi les données ou les messages passent par une infrastructure étrangère difficile à contrôler.

Mais la réglementation n’est pas seulement un argument de vente. Elle impose des coûts et des risques. Les règles de données personnelles demandent des garanties techniques et documentaires. L’anti-spam impose le consentement, des seuils de plainte, des restrictions de contenu et des procédures de modération. Les canaux comme SMS, Telegram ou VK ajoutent leurs propres contraintes commerciales et politiques. Les contenus sensibles, les secteurs interdits ou les campagnes mal autorisées peuvent exiger une intervention humaine.

Plus la plateforme promet une communication omnicanale, plus elle s’expose à des règles qui ne sont pas toutes sous son contrôle.

La géopolitique coupe dans les deux sens. Elle favorise les fournisseurs russes quand les alternatives étrangères deviennent moins simples, quand les paiements transfrontaliers posent problème, ou quand les entreprises veulent une chaîne de service plus locale. Elle limite aussi l’exportation. Un produit ancré en Russie, vendu en roubles, avec une infrastructure locale, peut être plus attractif domestiquement et moins naturel pour des clients internationaux.

Pour Inmarsoft, cette double contrainte signifie que la valeur de l’infrastructure dépend surtout du marché intérieur et de la capacité de Sendsay à convaincre que la localisation compense les limites d’échelle.

Les signaux non officiels

Les avis et plaintes publiques doivent être utilisés sans paresse. G2 ne montre qu’un avis visible pour Sendsay, positif, mais l’échantillon est trop faible pour prouver une adoption large ou une satisfaction durable. Otzovik affiche des avis négatifs parlant d’interface confuse, de support lent et de plaintes liées au spam. Ces avis ne sont pas une statistique propre. Ils peuvent refléter des utilisateurs atypiques, des concurrents, des clients frustrés ou des cas anciens. Mais ils pointent les bons coûts : interface, support, spam, modération et confiance.

Les traces de Spam.org et d’AbuseIPDB sont elles aussi limitées. Un faible nombre de plaintes ou un score de confiance bas ne prouve pas un problème systémique. Dans l’autre sens, l’absence de nombreuses plaintes publiques ne prouve pas que le risque est nul. La réputation d’email est souvent gérée dans des systèmes privés, chez des fournisseurs de messagerie, sur des listes de blocage qui changent vite, ou dans des conversations entre opérateurs. L’intérêt de ces signaux non officiels est donc qualitatif. Ils rappellent qu’une infrastructure d’envoi n’a pas seulement des coûts de bande passante ; elle a des coûts de comportement client.

Pour un analyste économique, ces signaux ne renversent pas la thèse. Ils l’encadrent. Ils suggèrent que le produit peut être réel, que certains clients l’utilisent, mais que la marge dépend d’un travail peu visible. Le marketing vend l’automatisation ; l’exploitation paie les conséquences des listes sales, des messages mal ciblés, des intégrations cassées et des demandes de support. Si Sendsay transforme ces problèmes en procédures automatisées, elle protège la marge. Si elle les traite surtout par intervention humaine, la récurrence du revenu masque une récurrence des coûts.

Le fait qui dérange : les comptes publics

Le chiffre le plus important du dossier n’est pas une adresse IP. C’est le revenu 2024 d’Inmarsoft : 516 000 roubles selon RBC Companies, avec une perte nette de 354 000 roubles, et des données secondaires qui signalent un niveau comparable ainsi qu’une base de coûts presque équivalente au chiffre d’affaires. Ce montant est trop faible pour soutenir une lecture autonome d’éditeur logiciel d’infrastructure ou de fournisseur de cloud en croissance. Il est aussi trop faible pour correspondre directement à une plateforme marketing significative si cette plateforme facture réellement des clients par paliers mensuels.

La comparaison historique aggrave la question. Les revenus auraient dépassé 60 millions de roubles en 2019 et 2020. La baisse n’est pas une variation ordinaire. Elle peut indiquer un transfert de facturation vers Internet Projects, un changement d’activité, un nettoyage de périmètre, une perte de contrats, une restructuration ou un rôle désormais limité à une fonction technique. Sans états détaillés et sans contrats internes, il serait irresponsable d’en choisir une seule comme vérité.

Ce fait de renversement impose une discipline. On peut dire qu’Inmarsoft possède une empreinte réseau réelle liée à Sendsay. On ne peut pas dire que son compte public valide une rente logicielle. Le meilleur cas est celui d’une société qui détient ou opère des actifs critiques pour une plateforme plus large, mais qui ne reçoit qu’une fraction comptable du revenu. Le pire cas est celui d’une entité réseau résiduelle dont l’importance opérationnelle est plus faible que les traces DNS et RIPE ne le suggèrent. La thèse investissable, commerciale ou stratégique dépend de la preuve qui manque : la destination économique du revenu Sendsay.

Ce que la frontière contractuelle change

Quand Internet Projects est le contractant, le client achète Sendsay auprès d’Internet Projects. C’est cette société qui est visible dans les documents de paiement, de licence, d’accès et de conditions. Elle a donc le lien direct avec la capacité de prix. Inmarsoft, même si elle contrôle des ressources de livraison, peut n’être rémunérée que par des mécanismes internes. Cette séparation peut être rationnelle : isoler le réseau, la propriété logicielle, la conformité ou les risques. Elle peut aussi rendre l’analyse externe plus opaque.

Pour le client final, la distinction importe peu tant que le service fonctionne. Pour l’économie de l’entité, elle est décisive. Une entreprise qui détient un ASN et des blocs d’adresses peut être indispensable sans être riche. Une autre entreprise du groupe peut capter la marge parce qu’elle détient le contrat, la marque, le logiciel et la relation commerciale. Si les coûts d’Inmarsoft sont remboursés à prix coûtant, ses comptes resteront plats. Si elle facture une prime d’infrastructure, ses comptes devraient mieux refléter l’importance de son rôle. Les chiffres récents ne montrent pas cette prime.

Cette frontière doit aussi discipliner la lecture de la concurrence. Sendsay affronte Unisender, DashaMail, RuSender et d’autres dans l’esprit du client. Inmarsoft, elle, affronte surtout la question de savoir si l’infrastructure interne est plus efficace que des alternatives d’envoi, des fournisseurs de transit, des pools d’adresses d’autres opérateurs, ou des solutions cloud locales. La substitution n’est pas seulement externe ; elle peut arriver de l’intérieur si Sendsay déplace ses flux vers une autre base réseau ou si Internet Projects choisit une architecture différente.

Logiciel, cycle de vie et verrouillage

Le verrouillage le plus fort de Sendsay ne vient pas d’une adresse IP. Il vient du cycle de vie logiciel. Une base de contacts, des segments, des modèles, des événements, des scripts API, des webhooks, des journaux et des procédures de conformité deviennent une partie du système commercial du client. Plus l’usage touche les messages transactionnels, plus le changement devient risqué. L’entreprise ne migre pas seulement une liste ; elle migre une chaîne de communication et les preuves qu’elle respecte ses obligations.

Ce verrouillage peut soutenir de bons revenus récurrents, mais seulement si le fournisseur continue d’investir. Le blog de Sendsay indique une année 2025 avec de nombreuses sorties produit, des améliorations Transport, des journaux et des changements d’interface. Le ton est promotionnel, mais le signal est pertinent : un service de ce type ne reste pas rentable en restant immobile. Les clients attendent de nouvelles intégrations, une meilleure sécurité, des statistiques plus lisibles et une réduction des frictions. Les concurrents publient leurs propres tarifs et arguments. Le coût du logiciel est donc permanent.

Inmarsoft se trouve dans la partie moins visible de ce cycle. Si la plateforme ajoute des fonctions d’envoi, des modes de transport, des volumes plus élevés ou des options de sécurité, le réseau doit suivre. Les adresses doivent rester correctement autorisées, les routes stables, les journaux disponibles, les abus traités, les intégrations documentées et les limites maîtrisées. Le logiciel crée le revenu ; l’infrastructure protège la promesse. Si les deux couches sont dans des entités différentes, le contrat interne doit être assez bien conçu pour que chacune ait l’incitation d’investir au bon endroit.

Cette incitation est le point le plus concret de l’analyse. Une équipe commerciale peut gagner un client en promettant plus de volume, plus de canaux ou une meilleure intégration. Le coût de cette promesse tombe ensuite sur les équipes qui surveillent les flux, répondent aux incidents, ajustent les limites, vérifient les listes et protègent les blocs d’adresses. Si la rémunération interne suit seulement le coût apparent des serveurs, elle sous-paie le capital de réputation. Si elle suit la valeur du revenu récurrent rendu possible par la livraison, elle reconnaît que l’infrastructure n’est pas un simple support.

Sans cette discipline, le modèle pousse naturellement à vendre de la complexité avant d’en mesurer le coût complet.

Le scénario favorable

Le scénario favorable commence par une hypothèse simple : Inmarsoft est petite dans ses comptes publics mais importante dans l’architecture de Sendsay. Elle détient ou opère des ressources qui donnent à la plateforme une base locale de livraison, une capacité d’authentification SPF, des routes connues, une réponse plus directe aux besoins russes de données et une meilleure maîtrise de la réputation que si tout était externalisé. Dans ce scénario, les faibles revenus publiés reflètent une allocation comptable, non une absence de valeur opérationnelle.

Ce scénario devient plus convaincant si trois éléments apparaissent. D’abord, des preuves que les flux Sendsay continuent d’utiliser les blocs Inmarsoft de façon importante, pas seulement marginale. Ensuite, des signes que les clients paient pour des fonctions où l’infrastructure compte vraiment : Transport, adresses dédiées, envoi transactionnel, journaux, sécurité, API, CDP et intégrations. Enfin, une explication du partage économique avec Internet Projects, par exemple des contrats de service, des transferts internes ou une logique de coûts qui montrent pourquoi Inmarsoft ne publie pas un chiffre d’affaires proportionnel à son rôle.

Dans ce meilleur cas, Inmarsoft n’est pas une entreprise cloud au sens large ; elle est une couche de contrôle dans une chaîne de messagerie locale. Sa valeur est défensive. Elle réduit la dépendance à des fournisseurs extérieurs, améliore la maîtrise de la conformité russe, donne plus de contrôle sur les routes et les adresses, et soutient un produit dont les revenus se forment ailleurs. Le marché ne paierait pas cher pour ses serveurs seuls ; il paierait pour la continuité et la réputation que ces serveurs rendent possible.

Le scénario défavorable

Le scénario défavorable est plus direct. Inmarsoft pourrait être une entité réseau historiquement utile mais économiquement réduite, pendant que le vrai produit, le vrai contrat et la vraie relation client résident chez Internet Projects. Les traces RIPE, DNS et BGP prouveraient alors une fonction technique, pas une capacité de monétisation. Le revenu 2024 faible deviendrait le fait central, et les anciens revenus élevés deviendraient le signe d’un périmètre perdu ou déplacé.

Dans ce scénario, la petite infrastructure n’a pas de pouvoir de prix propre. Elle dépend de quelques fournisseurs amont, de décisions internes de Sendsay, de la propreté des flux clients et de la volonté d’Internet Projects de la maintenir au centre. Si Sendsay peut déplacer davantage de trafic vers des blocs Internet Projects, vers un autre opérateur russe ou vers une solution de transport concurrente, Inmarsoft n’a pas de défense commerciale directe. Elle est remplaçable dans la mesure où la réputation peut être reconstruite ailleurs et où les coûts de migration restent supportables.

Les signaux de plaintes, même faibles, pèsent davantage dans cette lecture. Ils montrent que l’actif peut devenir une charge. Une adresse IP utilisée pour l’envoi a besoin de soins continus. Si les comptes ne montrent pas de revenu, le coût de ce soin peut être difficile à justifier. La perte nette 2024, même modeste en absolu, dit que l’entité ne transforme pas publiquement son rôle en profit. Ce n’est pas une condamnation définitive, mais c’est un avertissement.

Ce qui ferait changer le jugement

Le jugement s’améliorerait si Inmarsoft ou Sendsay publiait une preuve claire de revenu d’infrastructure lié à Sendsay : services de livraison, adresses dédiées, exploitation Transport, contrats internes, facturation de support réseau ou partage des revenus d’envoi. Il s’améliorerait aussi si les données de routage, les enregistrements SPF et les hôtes transactionnels montraient une dépendance durable et croissante aux blocs Inmarsoft. Des preuves d’adoption par de grands clients, surtout dans les usages transactionnels et CDP, renforceraient également la thèse, car ces usages créent plus de dépendance que des campagnes simples.

Le jugement se dégraderait si les ressources RIPE étaient transférées, si AS202629 cessait d’annoncer les blocs observés, si Sendsay retirait les autorisations SPF liées à Inmarsoft, si les hôtes transactionnels migraient vers une autre base, ou si les plaintes publiques augmentaient au point de montrer un problème de réputation. Il se dégraderait aussi si les comptes d’Inmarsoft restaient faibles sans explication pendant que les coûts de support et de conformité montent. Dans ce cas, la société ressemblerait davantage à une dépendance technique résiduelle qu’à un actif économique stratégique.

La conclusion doit rester prudente. Inmarsoft n’est pas vide : les registres, le réseau, le DNS et l’intégration avec Sendsay montrent une fonction réelle. Elle n’est pas non plus, sur les preuves publiques, le centre contractuel du revenu Sendsay. Le bon prix analytique se situe entre ces deux erreurs. Inmarsoft est une petite couche de contrôle dans une économie de messagerie où la réputation des adresses, la conformité locale, les coûts de modération et le verrouillage logiciel comptent plus que la taille brute du réseau.

La question ouverte est de savoir si cette couche est rémunérée comme un actif critique ou seulement maintenue comme une pièce nécessaire d’un produit dont la marge est ailleurs.

Sources