Résumé
- Kepler Technologies AB dispose de suffisamment de preuves publiques pour être considéré comme un véritable opérateur suédois de cloud et de ressources numériques: il vend des serveurs virtuels, du stockage, du réseau, des Kubernetes gérés, des bases de données gérées, de l’hébergement WordPress et des instances GPU L40S, tandis que les enregistrements RIPE montrent un statut LIR, l’AS212220 et des préfixes récemment visibles.
- Le propriétaire du risque baissier reste Kepler, et non le client ni le partenaire de centres de données en amont. La sous-utilisation, la hausse des coûts des fournisseurs, la dépendance aux installations, l’obsolescence des GPU et la substitution par les hyperscalers retombent d’abord sur le petit opérateur qui doit remplir ses capacités, maintenir la qualité de service et rendre la localisation suffisamment précieuse pour justifier de le choisir.
Le propriétaire du risque précède l’empreinte
L’empreinte visible de Kepler Technologies AB est facile à décrire: une marque cloud suédoise, une entité juridique à Helsingborg, un site web public rempli d’offres de serveurs virtuels et de stockage, une page de statut qui nomme SWE 1 à Falkenberg et SWE 2 à Stockholm, une inscription en tant que membre du RIPE NCC, un système autonome et des arguments marketing autour d’OpenStack, des instances GPU et de la localisation des données en Suède. La question plus ardue est de savoir qui supporte la perte si cette infrastructure est sous-utilisée, perturbée ou rendue obsolète par un fournisseur mieux financé.
La réponse est que Kepler porte la première couche de risque. Les clients peuvent subir des temps d’arrêt, des coûts de migration et des perturbations opérationnelles, mais ils ont généralement le choix. Ils peuvent conserver un site web chez Kepler, déplacer la charge de travail suivante vers un hyperscaler, réserver l’hébergement local uniquement pour des besoins de souveraineté des données ou utiliser le fournisseur pour WordPress et de petites machines virtuelles tout en laissant les systèmes plus exigeants ailleurs.
Glesys ou un autre fournisseur de centres de données et de connectivité en amont peut également se protéger par des conditions de gros, une tarification de colocation, des frais d’électricité, des limites contractuelles et le contrôle des installations. La partie qui tente de convertir cet ensemble en un actif commercial durable est Kepler.
Cela importe, car un fournisseur cloud peut paraître plus important que ses fondamentaux économiques. Un tableau de prix crée l’apparence d’une capacité fongible. Une page de statut crée l’apparence d’une envergure opérationnelle. Une carte de régions crée l’apparence d’une couverture géographique. Un système autonome RIPE crée l’apparence d’un contrôle réseau. Aucun de ces éléments n’est faux, mais aucun ne prouve une économie défendable.
Le test économique est l’utilisation à la marge: est-ce que suffisamment de clients paient assez, pendant assez longtemps, pour couvrir les coûts de matériel, d’électricité, de support, de logiciels, de réseau, de fournisseurs et de conformité avant que le matériel ne vieillisse ou que les clients ne choisissent une plateforme plus grande.
Les propres conditions de Kepler rendent ce risque visible. Les conditions générales distinguent les contrats gérés du cloud public en libre-service, autorisent les services complémentaires, répartissent les obligations de conformité du client, préservent le droit de Kepler de modifier les prix et incluent des clauses de sauvegarde en cas de décisions officielles, de changements législatifs ou de hausse des coûts des composants ou des licences.
Ces clauses sont normales pour un petit fournisseur cloud, mais elles montrent aussi ce contre quoi l’entreprise tente de se protéger: une base de coûts fixe ou semi-fixe confrontée à une demande incertaine et à des prix d’intrants incertains.
La question du titre n’est donc pas de savoir si Kepler dispose d’une infrastructure. C’est le cas. La question est de savoir si cette infrastructure est économiquement défendable lorsque le client peut la comparer à Amazon, Microsoft, Google, aux fournisseurs européens régionaux, à Glesys elle-même, aux fournisseurs spécialisés en GPU et aux sociétés d’hébergement gérées ordinaires. Si la localisation, le support et la simplicité sont suffisamment solides, l’actif occupe une niche.
Si le même client peut obtenir un risque plus faible, des services plus étendus ou un coût total inférieur ailleurs, Kepler porte le risque de capacités inutilisées.
Le périmètre de l’entreprise est réel mais étroit
Le périmètre opérationnel commence par l’entreprise juridique. Les informations publiques des sociétés suédoises indiquent Kepler Technologies AB avec le numéro d’organisation 556858-3131, à l’adresse Brogatan 9 à Helsingborg, et une activité dans les infrastructures de données, le traitement de données et l’hébergement.
Ratsit enregistre l’entreprise comme une société à responsabilité limitée suédoise active et fait état d’un chiffre d’affaires 2024 de 4,1 millions de couronnes suédoises, d’un résultat de 0,2 million de couronnes suédoises, d’actifs immobilisés de 2,3 millions de couronnes suédoises, de capitaux propres de 0,5 million de couronnes suédoises, d’un ratio de liquidité inférieur à 20 pour cent et d’un employé.
Le pied de page du site web de Kepler indique que Kepler Technologies AB fait partie de HDL Group AB, et sa page « À propos » précise que l’activité d’hébergement Kepler Cloud a été lancée par un groupe qui souhaitait une expérience d’hébergement différente, fondée sur la fiabilité, la rapidité et l’automatisation.
Ces chiffres ne rendent pas Kepler négligeable. Ils affinent l’analyse. Kepler n’est ni un propriétaire nordique de centres de données coté en bourse, ni une plateforme hyperscale, ni un opérateur national historique de télécommunications, ni un grand intégrateur de systèmes. C’est un petit fournisseur suédois de cloud et d’hébergement qui tente de proposer une alternative régionale sur un marché où les acheteurs sont de plus en plus sensibles à la localisation des données, à la transparence des coûts et à la qualité du support.
Les documents publics de l’entreprise doivent être lus comme l’ambition d’un petit revendeur et opérateur d’infrastructure, et non comme la preuve que les actifs bénéficient déjà d’économies d’échelle.
Le périmètre de service est plus large que celui d’un simple hébergeur web. Les menus et les pages produits de Kepler couvrent le cloud public, le cloud privé, l’hébergement WordPress, les serveurs privés virtuels, les instances GPU, les sauvegardes, le stockage par blocs, le stockage objet, le transfert réseau, l’équilibrage de charge géré, le réseau défini par logiciel, Kubernetes géré, les bases de données gérées et les démonstrations cloud.
La page d’accueil indique que Kepler utilise OpenStack comme socle principal d’infrastructure en tant que service et positionne la plateforme pour les entreprises SaaS, les agences, le commerce électronique, les services d’IA, WordPress et les besoins spécifiques des entreprises. La page de contact fait la promotion d’une API publique, d’une intégration Terraform et d’une mise à l’échelle verticale des ressources pour un centre de données virtuel.
Le périmètre reste étroit à deux égards importants. Premièrement, Kepler ne se présente pas comme propriétaire d’installations. Ses documents identifient à plusieurs reprises Glesys comme le partenaire principal de centres de données, et la page GPU précise que Kepler utilise les centres de données de Glesys pour une colocation à haute densité, durable et sécurisée. Deuxièmement, les preuves publiques ne montrent pas une large organisation commerciale entreprises, un effectif de support important, des revenus récurrents audités, une concentration de la clientèle, une utilisation, une marge brute ou une trésorerie disponible.
Un petit opérateur peut toujours créer de la valeur, mais il doit le faire avec une focalisation plus précise qu’une plateforme qui peut amortir ses outils sur des millions de clients.
La lecture la plus claire est que Kepler constitue une couche de services d’infrastructure au-dessus d’installations suédoises, d’opérations cloud de type OpenStack, de ressources numériques et de support. Elle peut contrôler les relations clients, le packaging des services, une partie de la politique réseau et certains engagements matériels ou de capacité. Elle ne contrôle pas tous les intrants économiques sous-jacents. Cette distinction est au cœur de l’analyse du risque.
La localisation suédoise est l’offre, pas un substitut à l’échelle
Le positionnement public le plus fort de Kepler est la localisation. La page de statut nomme SWE 1 - Falkenberg et SWE 2 - Stockholm. La page d’accueil répertorie Falkenberg comme SWE1, Stockholm comme SWE2, et des zones futures ou en phase de contact telles que la Finlande, Oslo, Bahreïn et Dubaï. Les documents sur les centres de données et les GPU renvoient à Glesys, tandis que le document de politique d’exploitation de Kepler indique que les services sont exécutés avec un fournisseur suédois certifié ISO 9001, ISO 14001 et ISO 27001.
Ce même document précise que Kepler utilise des centres de données géographiquement répartis en Suède, maintient des routines de sauvegarde et de reprise après sinistre, vise un délai de reprise de quatre heures après des incidents graves, un objectif de perte de données d’au plus 15 minutes et garantit une disponibilité d’au moins 99,95 % pour les services critiques hébergés sur Kepler Cloud.
La localisation peut être précieuse. Une entreprise SaaS suédoise peut vouloir un support suédois, une localisation des données en Suède, des factures prévisibles, des cycles de vente plus courts et un fournisseur qui ne la pousse pas vers une structure de compte hyperscale étendue. Une agence WordPress peut accorder plus de valeur à une aide humaine rapide qu’à un catalogue de services mondial. Une entreprise de commerce électronique peut rechercher une faible latence pour les utilisateurs suédois, une tarification transparente des ressources et une interface moins complexe.
Un acheteur soucieux de la souveraineté des données peut préférer un fournisseur européen dont les installations et la politique d’accès sont plus proches.
Mais la localisation ne constitue pas un rempart à elle seule. La Suède dispose déjà de fournisseurs d’infrastructure régionaux plus solides, d’opérateurs de colocation, de sociétés d’hébergement géré et de la présence locale de plateformes mondiales. Glesys, le partenaire désigné par Kepler, commercialise ses propres cloud public et privé, du matériel dédié, de la colocation, de l’intervention à distance, des bases de données gérées, de la reprise après sinistre, des services réseau, du stockage objet et des serveurs GPU.
Glesys affirme exploiter ses propres centres de données et son propre réseau de fibre, détenir les certifications ISO 9001, ISO 14001 et ISO 27001, réutiliser la chaleur résiduelle des centres de données suédois, fonctionner à l’électricité renouvelable et offrir une disponibilité de service allant jusqu’à 99,95 %. Cela signifie que le récit de localisation de Kepler repose en partie sur un fournisseur dont la propre offre de détail est en concurrence pour une partie de la même demande.
La valeur économique de la localisation dépend du segment de clientèle. Pour un petit acheteur de WordPress ou de VPS, la localisation assortie du support peut l’emporter. Pour un acheteur réglementé, la localisation n’a de valeur que si la documentation, l’auditabilité, les contrôles de sécurité, les règles d’accès et la transparence des sous-traitants satisfont l’équipe des risques du client. Pour les acheteurs de GPU, la localisation n’est utile que si la capacité, les pilotes, le réseau, le stockage et le prix correspondent à la charge de travail.
Pour les grandes entreprises SaaS, la localisation peut n’être qu’un paramètre parmi d’autres, derrière la fiabilité, l’outillage développeur, la qualité des bases de données gérées, la redondance géographique et la profondeur contractuelle.
Le risque pour Kepler est que les clients peuvent apprécier le récit suédois sans y consacrer un volume suffisant pour rentabiliser l’infrastructure. La localisation donne une raison d’essayer le fournisseur. Elle ne garantit pas l’utilisation qui transforme les serveurs, les GPU, le stockage et les engagements réseau en profit durable.
Les preuves RIPE montrent une ambition de contrôle, pas une immunité d’échelle
Les preuves d’infrastructure indépendantes les plus solides se trouvent dans les enregistrements RIPE. La page des membres RIPE répertorie Kepler Technologies AB comme membre en Suède. Les résultats de la base de données RIPE montrent un objet d’organisation LIR pour Kepler Technologies AB à Brogatan 9, Helsingborg, avec le numéro d’enregistrement 556858-3131. Les enregistrements RIPE montrent également AS212220, nommé KEPLER, attribué en mars 2025, avec des relations d’importation depuis AS42708 et AS48618 et des exportations annonçant AS212220 vers ces fournisseurs amont.
L’aperçu AS de RIPEstat identifie AS212220 comme « KEPLER Kepler Technologies AB » et comme annoncé, tandis que les données des préfixes annoncés de RIPEstat pour la période de fin juin à mi-juillet 2026 montrent une visibilité pour 192.176.172.0/24, 192.176.173.0/24 et 195.190.19.0/24.
Ces preuves sont tangibles. Elles montrent que Kepler n’est pas simplement un site web revendant un panneau d’hébergement mutualisé générique. Elle participe à la gouvernance des ressources numériques, dispose d’un système autonome et de préfixes annoncés. Elle possède également un mélange de ressources. Les résultats de recherche de la base de données RIPE montrent un objet hérité 192.176.172.0 à 192.176.173.255 lié à Kepler Technologies AB et une allocation 195.190.19.0 à 195.190.19.255 créée en juin 2026 sous l’organisation LIR de Kepler.
D’autres résultats de recherche RIPE montrent des plages attribuées par le fournisseur et maintenues par Glesys avec le nom de réseau KEPLER-CLOUD créées en 2024 et 2026. Le tableau opérationnel est donc un mélange de contrôle propre via le LIR et l’AS, et d’adressage fourni par le fournisseur amont ou partenaire.
La nuance est importante. Un système autonome peut améliorer le contrôle sur la politique de routage, le choix des fournisseurs amont, la portabilité des clients et la crédibilité du service. Il peut soutenir une offre cloud plus sérieuse, surtout lorsqu’elle est associée à des composants de statut public pour l’identité, le calcul, le réseau, les équilibreurs de charge, le stockage d’images, le stockage de volumes, le stockage objet, la gestion des clés, l’orchestration, le DNS et les tableaux de bord dans des régions suédoises nommées.
Mais le nombre de préfixes et la visibilité RIPE ne montrent pas une échelle comparable à celle d’un grand fournisseur cloud. Ils montrent une empreinte réseau opérationnelle qui dépend encore des fournisseurs amont et de la densité de clientèle.
Le contrôle du réseau peut également renvoyer le risque vers Kepler. Si le routage échoue, si un événement DDoS submerge les défenses, si un fournisseur amont modifie ses conditions, si la réputation des adresses est entachée par des clients abusifs ou si les coûts de trafic augmentent, le client voit le service de Kepler, et non la frontière cachée du fournisseur. Les conditions de Kepler lui permettent de suspendre les services en cas de circonstances nuisibles et de restreindre la revente sans accords séparés, ce qui est économiquement rationnel car le mauvais comportement des clients peut endommager les actifs réseau partagés.
L’opérateur qui souhaite le contrôle des ressources numériques doit également supporter la charge opérationnelle de surveillance de ces ressources.
Le marché devrait donc accorder à Kepler le mérite de disposer de véritables preuves de ressources numériques, mais ne pas considérer ces preuves comme un rempart économique. AS212220 est un signal opérationnel. Ce n’est pas une preuve d’utilisation, de marge, de fidélité de la clientèle ou d’indépendance vis-à-vis des grands fournisseurs.
La qualité des revenus dépend du remplissage des capacités, pas du catalogue de produits
Le catalogue public de Kepler est large pour une petite entreprise. La page de tarifs répertorie des instances virtuelles standard de gp1.xsmall à des plans polyvalents plus grands, des instances hautes performances à partir de hp1.xsmall, des niveaux de stockage objet et une tarification mensuelle ou horaire. La page Kubernetes géré propose des tarifs pour les options de plan de contrôle et les choix de nœuds de travail dans les zones de Falkenberg et Stockholm. La page de stockage par blocs indique que les clients ne paient que pour le stockage utilisé et peuvent ajouter ou supprimer des volumes selon les besoins.
La page de stockage objet présente le stockage objet comme un stockage cloud évolutif. Les pages bases de données gérées et Kubernetes géré rapprochent l’offre de services opérationnels, pas seulement de calcul brut.
La largeur du catalogue peut aider les ventes, mais seulement si les services partagent suffisamment d’infrastructures et de modèles de support communs. Un fournisseur cloud obtient des rendements attractifs lorsque le même personnel, les mêmes systèmes de contrôle, le même réseau, le même stockage et la même automatisation soutiennent de nombreux clients avec un faible coût supplémentaire. Il perd de l’argent lorsque chaque ligne de produits crée sa propre charge de support, son propre pool de capacités, ses cas particuliers et ses besoins de documentation.
Les conditions et les pages de Kepler montrent les deux modèles: l’utilisation de crédits cloud en libre-service pour les clients qui s’inscrivent directement, et des contrats gérés qui peuvent durer au moins douze mois et se prolonger par tacite reconduction.
Le modèle en libre-service nécessite du volume. De petits plans VPS à 110, 240 ou 470 couronnes suédoises par mois sont des points d’entrée utiles, mais ils ne paient pas beaucoup de temps d’ingénierie si les clients ont besoin d’accompagnement. Ils ne fonctionnent économiquement que lorsque l’approvisionnement, la facturation, le support et la surveillance sont hautement automatisés. Le modèle géré nécessite une qualité contractuelle.
Un cloud personnalisé ou un environnement privé peut générer un revenu mensuel plus élevé, mais il peut aussi mobiliser l’attention des cadres dirigeants, du temps d’approvisionnement, du travail de conception et du dépannage. Si un contrat géré est petit, sur mesure et exigeant en support, il peut sembler attractif en termes de revenus tout en affaiblissant la marge.
La question de la qualité des revenus est particulièrement aiguë parce que les données publiques de l’entreprise indiquent une petite échelle absolue. Le chiffre de 4,1 millions de couronnes suédoises de chiffre d’affaires en 2024 chez Ratsit, même incomplet ou en retard par rapport à la dernière poussée cloud, constitue la base de revenus d’un petit opérateur. Les logos de clients et les témoignages sur le site de Kepler suggèrent une présence sur le marché, mais il ne s’agit pas de nombres de clients audités, de valeurs de contrat ou de taux de renouvellement.
La page de statut montre plusieurs catégories de services, mais pas l’utilisation. La page de tarifs montre la disponibilité des produits, mais pas la demande.
Le test économique est de savoir si Kepler peut faire évoluer ses clients vers le haut de la courbe. Un client qui commence par de l’hébergement WordPress ou une petite machine virtuelle doit devenir acheteur de stockage, de base de données gérée, d’équilibrage de charge, de sauvegardes, de réseau privé, de Kubernetes ou de capacité GPU. Sinon, l’entreprise risque d’exploiter une plateforme étendue pour des comptes à faible ticket. Le meilleur cas est une alternative suédoise compacte où les clients valorisent suffisamment le support et la localisation pour utiliser plusieurs services.
Le cas faible est un catalogue qui attire des utilisateurs sensibles au prix, qui ont besoin d’aide, changent rapidement de fournisseur ou comparent chaque service à un niveau gratuit d’hyperscaler, à une plateforme de développement ou à un fournisseur nordique plus grand.
Le pouvoir de tarification doit compenser les coûts des fournisseurs et du support
Les informations tarifaires de Kepler montrent une entreprise qui tente d’équilibrer simplicité et recouvrement des coûts. Les plans polyvalents sont présentés avec des prix mensuels et horaires, et la page indique que les plans sont facturés sur une base de 30 jours par mois pour garantir un prix mensuel fixe, hors taxes locales applicables. Les plans de stockage objet comportent également des prix mensuels et des allocations de transfert. La page de contact indique aux grandes organisations que Kepler peut fournir des solutions sur mesure.
Les conditions permettent que les frais soient variables, fixes, uniques, liés à la facturation ou à la mise en service; elles autorisent également la facturation de services supplémentaires selon la grille tarifaire en vigueur de Kepler.
C’est la forme appropriée pour un petit fournisseur cloud, mais cela rend le pouvoir de tarification mesurable. Si Kepler est en concurrence uniquement sur des prix d’appel bas, elle est exposée à chaque choc de coût: électricité, espace en centre de données, réseau, licences logicielles, remplacement de matériel, défaillance de SSD, temps de support et hausse des prix des fournisseurs. Si elle est en concurrence sur la localisation, le support humain, une facturation prévisible et la tranquillité en matière de conformité, elle peut facturer suffisamment pour supporter la charge.
La différence n’est pas du langage marketing; c’est de savoir si les clients acceptent les modifications de prix et les conditions des contrats gérés plutôt que de traiter le fournisseur comme une commodité.
Les conditions de Kepler sont franches sur cette pression. La clause de modification des prix autorise les changements de prix avec préavis et donne aux clients un droit de résiliation si une augmentation substantielle dépasse 10 % et qu’ils ne l’acceptent pas.
La clause de sauvegarde fait référence à des changements matériels d’ordre économique, financier, juridique ou technologique, y compris les décisions officielles, les modifications législatives et les changements de prix des composants ou des licences, et stipule que le client doit indemniser Kepler pour les coûts supplémentaires qu’elle est contrainte d’accepter pour fournir le service. Ces clauses sont défensives parce que les coûts des intrants peuvent évoluer plus rapidement que les prix d’un petit fournisseur.
Les conditions répartissent également les risques quant à l’adéquation des services. Le client reste responsable de déterminer si les services répondent aux exigences techniques, commerciales ou réglementaires, tandis que Kepler coopère et peut facturer des frais supplémentaires pour le travail additionnel. La formulation de la garantie de Kepler exclut toute promesse que le fonctionnement sera sécurisé, ininterrompu ou exempt d’erreurs, les recours étant axés sur la rectification et la résiliation possible de l’abonnement concerné. Cela n’a rien d’inhabituel dans les contrats cloud.
Cela montre que le recours juridique du client en cas de défaillance est peu susceptible de couvrir la totalité de la perte d’exploitation résultant d’une panne grave.
Économiquement, la responsabilité limitée protège Kepler des réclamations catastrophiques des clients. Elle ne protège pas la marque contre l’attrition. Un petit fournisseur peut rédiger des conditions raisonnables et néanmoins perdre le renouvellement suivant si un client décide que la plateforme est trop risquée. Le pouvoir de tarification dépend donc autant de la confiance que des clauses. Le fournisseur doit faire preuve d’une fiabilité suffisante pour que les clients n’aient pas besoin de tester les recours.
La capacité GPU transforme l’obsolescence en un risque de bilan
L’offre GPU est l’exemple le plus clair du potentiel de hausse assorti d’un risque de baisse marqué. La page GPU de Kepler fait la promotion d’une instance GPU L40S pour l’IA, les graphiques, le rendu, l’entraînement de modèles, l’inférence et les applications vidéo. Elle indique que l’instance utilise un GPU NVIDIA L40S avec 48 gigaoctets de mémoire GDDR6 et 864 gigaoctets par seconde de bande passante, alimenté par huit cœurs CPU virtuels AMD EPYC 7413. Elle situe l’offre dans SWE 2 - Stockholm et annonce des remises sur les engagements de 24 et 36 mois.
Elle précise également que Kepler utilise les services de colocation haute densité de Glesys et présente le refroidissement direct sur puce et par immersion comme faisant partie du contexte des installations.
La logique commerciale est compréhensible. La demande d’IA a rendu la capacité GPU rare, coûteuse et stratégiquement importante. Synergy Research Group indique que le revenu des néoclouds a atteint 25 milliards de dollars pour l’année 2025, a progressé de 223 % en glissement annuel au quatrième trimestre et pourrait approcher 400 milliards de dollars d’ici 2031. Synergy précise également que les fournisseurs axés sur le GPU se développent parce que la demande de calcul accéléré dépasse la capacité cloud traditionnelle.
Un petit fournisseur disposant de capacité GPU locale peut attirer des acheteurs qui ont besoin d’un hébergeur suédois ou européen, d’un devis plus simple, d’un support local ou d’un engagement moindre que ce qu’un hyperscaler préférerait.
Le risque est que l’économie des GPU est impitoyable. Un processeur graphique acheté ou réservé au mauvais moment peut devenir obsolète avant d’avoir été entièrement amorti. La page L40S de NVIDIA positionne le produit comme un GPU de centre de données pour l’IA générative, l’inférence et l’entraînement de modèles de langage, les graphiques, le rendu et la vidéo, avec 48 gigaoctets de mémoire et une puissance maximale de 350 watts. C’est un équipement utile, mais le marché évolue rapidement.
De nouveaux accélérateurs, des empreintes mémoire plus grandes, de meilleures interconnexions, des puces d’inférence spécialisées et les remises des hyperscalers peuvent modifier les attentes des clients. Kepler ne peut pas supposer que la capacité L40S « économique » d’aujourd’hui restera attractive pendant un cycle contractuel de 24 ou 36 mois, à moins qu’elle ne soit tarifée pour des charges de travail spécifiques adaptées à la carte.
L’utilisation des GPU est également irrégulière. Les clients peuvent avoir besoin de nombreuses heures pendant les périodes d’entraînement, de test ou de rendu, puis de peu pendant des semaines. Si Kepler vend des contrats réservés, cela réduit le risque de capacité inutilisée mais peut sacrifier le potentiel de hausse. Si elle vend un accès à la demande, elle supporte le risque d’inutilisation. Si elle s’engage trop, elle risque de dégrader la qualité de service. Si elle s’engage trop peu, les clients vont ailleurs.
Un petit fournisseur a moins de marge de lissage statistique qu’un hyperscaler qui peut répartir la demande sur des milliers de machines et de nombreuses régions.
L’offre GPU renforce donc le récit stratégique de Kepler tout en relevant le seuil de rentabilité. Elle peut créer une niche cloud suédoise différenciée. Elle peut aussi immobiliser du capital si la demande est plus faible que prévu, si les coûts de refroidissement ou d’électricité sont plus élevés que prévu, si les clients ont besoin de systèmes de classe H100 ou plus récents, ou si les hyperscalers et les néoclouds spécialisés font baisser les prix effectifs. Le risque repose sur Kepler car le client n’a besoin de la capacité que lorsqu’elle est utile.
La dépendance aux fournisseurs est le contrat d’infrastructure caché
Le récit public de Kepler dépend fortement des fournisseurs. Glesys est cité à plusieurs reprises comme le partenaire principal de centres de données. Les enregistrements RIPE montrent des plages d’adresses attribuées par le fournisseur et maintenues par Glesys pour Kepler Cloud, et AS212220 importe des routes depuis AS42708, qui est Glesys. Les enregistrements RIPE montrent également une importation depuis AS48618, identifié par RIPEstat comme Oulun centres de données Oy, bien que cet AS n’ait pas été annoncé dans l’aperçu de RIPEstat au moment de la vérification.
La couche technologique dépend d’OpenStack, de Kubernetes, de moteurs de bases de données, de systèmes d’exploitation, d’équipements réseau, de matériel GPU, de matériel de stockage, d’outils de surveillance, ainsi que de l’alimentation électrique et du refroidissement des centres de données.
La dépendance aux fournisseurs n’est pas un défaut. Le cloud est partout assemblé à partir de fournisseurs. La question économique est de savoir si Kepler maîtrise suffisamment de valeur pour le client pour conserver une marge une fois les fournisseurs payés. Glesys contrôle des éléments importants des installations, de l’énergie, du refroidissement et du réseau dans la couche de centres de données suédoise. NVIDIA contrôle la feuille de route et la chaîne d’approvisionnement des GPU pour le matériel de classe L40S.
OpenStack réduit la dépendance à un fournisseur unique mais crée une complexité opérationnelle qui nécessite toujours du personnel. Better Stack alimente la page de statut publique. Des sous-traitants apparaissent dans le cadre de traitement des données de Kepler. Chaque fournisseur peut améliorer l’offre, mais chacun revendique également une part économique, impose des conditions et crée des frontières opérationnelles.
Le plus grand risque fournisseur est celui que les clients ne voient pas. Un client qui achète chez Kepler peut penser qu’il achète un service cloud Kepler. Si le problème sous-jacent est l’alimentation des installations, le refroidissement, le routage amont, le matériel de stockage ou un composant logiciel, le client appelle tout de même Kepler. Le contrat entre Kepler et le fournisseur peut protéger Kepler financièrement, mais la relation de service reste celle de Kepler. C’est pourquoi la sélection des fournisseurs n’est un actif économique que si Kepler peut la traduire en service fiable et en responsabilité claire.
Le propre document de sécurité de l’information de Kepler contient une nuance importante. Il indique que l’entreprise n’est actuellement pas formellement certifiée ISO 27001 mais suit les principes de la norme et dispose de procédures pour le chiffrement, le contrôle d’accès, la surveillance, le traitement des incidents, la formation des employés, la gestion des vulnérabilités, les revues de sécurité et les tests d’intrusion. Par ailleurs, le document de politique d’exploitation précise que le fournisseur suédois est certifié ISO 9001, ISO 14001 et ISO 27001. Cette distinction est importante.
La certification d’un fournisseur peut étayer les contrôles de Kepler, mais cela ne revient pas à ce que Kepler détienne sa propre certification sur l’ensemble de son exploitation de services.
L’entreprise devient plus défendable lorsque Kepler peut démontrer que la dépendance aux fournisseurs est bien orchestrée: sous-traitants documentés, basculement testé, déclarations claires sur la localisation des données, composants de service surveillés, droits d’exportation pour les clients, processus d’incident et support capable de résoudre les problèmes sans se cacher derrière le fournisseur. Elle s’affaiblit lorsque la dépendance aux fournisseurs laisse Kepler avec des obligations envers les clients mais un contrôle limité sur la cause première.
Les clients peuvent apprécier le produit tout en limitant leur risque
Le risque de concentration de la clientèle est plus important que la croissance totale du marché cloud. Le marché mondial du cloud peut croître de 25 ou 30 % tandis qu’un petit fournisseur local peine encore à remplir des capacités spécifiques. Les données de marché de Synergy en montrent la raison. Le marché mondial de l’infrastructure cloud a atteint environ 106,9 milliards de dollars au troisième trimestre 2025, et Amazon, Microsoft et Google détenaient ensemble 63 % des dépenses d’infrastructure cloud des entreprises.
En Europe, Synergy estime que les fournisseurs européens locaux détenaient environ 15 % du marché régional, tandis qu’Amazon, Microsoft et Google en détenaient 70 %. Le marché est vaste, mais les avantages d’échelle sont concentrés.
Les clients probables de Kepler ne représentent pas l’ensemble du marché cloud. Ce sont des agences, des entreprises de commerce électronique, des clients WordPress, des sociétés SaaS, des entreprises régionales, des équipes IA ayant des préférences en matière de localisation des données et des organisations qui préfèrent le support suédois. C’est une niche plausible. C’est aussi une niche où de nombreux acheteurs limiteront leur exposition.
Un client peut utiliser Kepler pour l’hébergement frontal, un environnement de développement, le stockage de sauvegarde, une copie de données en Suède ou un test GPU régional tout en gardant les systèmes centraux chez un fournisseur plus grand. Plus le client est sensible au risque, plus il est susceptible de répartir les charges de travail plutôt que de tout confier à un seul fournisseur.
Ce comportement est rationnel pour les clients et difficile pour Kepler. Les clients bénéficient de l’optionalité. Ils peuvent tirer parti de la valeur de localisation tout en évitant une dépendance totale. Kepler, en revanche, a besoin d’une utilisation dense du calcul, du stockage, du réseau et du support. Une plateforme comptant de nombreux clients à moitié engagés peut avoir des logos visibles et des fondamentaux économiques faibles.
L’activité ne s’améliore que lorsque les clients utilisent suffisamment de services pour générer une marge au niveau du compte et que le coût de départ est élevé parce que le support, la localisation et l’intégration de services de Kepler sont précieux, et non parce que des frictions contractuelles piègent le client.
Les preuves publiques de clientèle sont limitées. Le site web de Kepler affiche des logos de clients et un témoignage de Sail Racing concernant une infrastructure cloud haute performance fiable pour la croissance du commerce électronique. Il renvoie également à G2 pour les avis, mais aucune base d’avis indépendante n’était suffisamment solide pour peser dans cette analyse.
La page de statut montrait tous les services en ligne au moment de la consultation, avec des composants nommés dans SWE 1 et SWE 2, mais elle a été mise à jour pour la dernière fois le 23 mai et ne fournit pas un long historique public d’incidents dans le contenu visible de la page. Ce sont des signaux positifs, mais ils ne suffisent pas à déduire une demande large ou une fidélisation de la clientèle.
Les faits qui affineraient le jugement sont simples: nombre de clients payants par produit, chiffre d’affaires par ligne de service, revenu récurrent mensuel, attrition, part des cinq plus gros clients, utilisation du GPU, durée des contrats gérés, volume de tickets de support et marge brute après coûts des fournisseurs. Sans ces données, la position appropriée est conditionnelle. Kepler a un périmètre de produit crédible; sa densité de demande n’est pas prouvée.
Les grands fournisseurs fixent le prix de substitution
Les substituts de Kepler se répartissent en trois groupes. Le premier est le cloud hyperscale: AWS, Microsoft Azure et Google Cloud. Ils offrent de la largeur, des régions, des services gérés, des outils de conformité, des écosystèmes de développeurs, des intégrations de marketplace, des contrats d’entreprise et une capacité mondiale. Ils imposent également de la complexité, des coûts de sortie, une distance dans la gestion de compte et d’éventuelles préoccupations de souveraineté.
Le deuxième groupe est constitué des fournisseurs d’infrastructure européens et nordiques tels que Glesys, OVHcloud, Hetzner, Scaleway et les sociétés nationales d’hébergement géré. Ils peuvent offrir une localisation ou une tarification prévisible avec des bases opérationnelles plus importantes. Le troisième groupe est celui des fournisseurs spécialisés en infrastructure GPU et IA qui peuvent surpasser le cloud polyvalent en densité d’accélérateurs et en rapidité de déploiement.
Kepler n’a pas besoin de surpasser tous ces acteurs. Elle doit surpasser des alternatives réalistes pour un besoin client défini. Pour une petite entreprise suédoise qui souhaite un fournisseur réactif et des factures d’hébergement prévisibles, Kepler peut surpasser un hyperscaler. Pour une agence WordPress qui recherche du support et une facturation simple, Kepler peut être plus facile que l’auto-gestion de primitives cloud. Pour un client qui souhaite une instance GPU suédoise pour une charge de travail étroite, l’offre L40S de Kepler peut être attractive.
Pour un acheteur qui a besoin d’une disponibilité mondiale, de bases de données gérées approfondies, d’outils de sécurité d’entreprise, d’un large écosystème de partenaires ou de grands clusters GPU réservés, il est peu probable que Kepler soit le choix par défaut.
Le prix de substitution ne se limite pas au tarif mensuel affiché. Il inclut le temps d’ingénierie, le temps de migration, la tolérance aux pannes, la tranquillité réglementaire, la prévisibilité de la facturation et l’optionalité future. Un hyperscaler peut être plus cher en lignes de facturation et moins cher en risque total pour une charge de travail complexe. Un fournisseur local peut être moins cher en trésorerie et plus cher si des temps d’arrêt ou des fonctionnalités limitées imposent un travail personnalisé.
Glesys peut être à la fois un fournisseur et un substitut, ce qui signifie que Kepler doit justifier pourquoi le client devrait acheter via Kepler plutôt que directement auprès d’un opérateur d’installations et d’infrastructure plus grand.
C’est là que le contrôle opérationnel doit être distingué de la défendabilité de l’actif. Kepler peut contrôler le tableau de bord client, le bouquet de services, la relation de support, les ressources numériques et certains choix matériels. L’actif économiquement défendable est différent: une clientèle ayant de fortes raisons de rester, une utilisation qui couvre les coûts fixes, un support qui évolue, des contrôles réseau qui améliorent la fiabilité et une proposition de localisation suédoise qui justifie le paiement. Une surface de contrôle dépourvue de ces paramètres économiques est un fardeau opérationnel.
La réponse stratégique est la focalisation. Kepler ne devrait pas essayer de sonner comme un hyperscaler miniature. Le meilleur positionnement est un cloud suédois ciblé pour les clients qui valorisent le support, la transparence des coûts, la localisation, la migration de WordPress vers le cloud, l’infrastructure basée sur OpenStack, Kubernetes régional et une capacité GPU sélectionnée. Le moins bon positionnement est l’imitation large de services que les grands fournisseurs peuvent tarifer, automatiser et documenter mieux.
La réglementation favorise la localisation mais relève la barre opérationnelle
La réglementation européenne peut soutenir le récit de demande de Kepler. Le Data Act est entré en vigueur en janvier 2024 et s’applique à partir de septembre 2025. La Commission européenne indique qu’il donne aux utilisateurs un plus grand contrôle sur les données générées par les appareils connectés, améliore l’accès aux données pour les entreprises utilisant des équipements industriels et crée des règles permettant aux clients de changer de fournisseur de traitement de données.
La page NIS2 de la Commission précise que la directive élargit les obligations de cybersécurité et les exigences de déclaration dans les secteurs critiques, y compris l’infrastructure numérique et davantage de services numériques. Le RGPD reste le cadre plus large de protection des données.
Pour un fournisseur cloud suédois, cet environnement crée une opportunité. Les clients peuvent rechercher des fournisseurs capables d’indiquer où les données sont traitées, qui y a accès, comment les sous-traitants sont gérés, ce qui se passe en cas de résiliation et comment fonctionne le changement de fournisseur cloud. Le DPA de Kepler stipule que la règle principale est le traitement des données en Suède et au sein de l’UE et de l’EEE, avec des clauses contractuelles types et des garanties pour les transferts en dehors de cette zone.
Il confère aux responsables de traitement des droits d’opposition concernant les nouveaux sous-traitants et précise que Kepler doit tenir une liste à jour des sous-traitants. C’est le type de conditions que les clients demandent de plus en plus.
La réglementation augmente également les coûts de Kepler. La conformité n’est pas un slogan. Elle exige de la documentation, un traitement des incidents, une réponse aux audits, une discipline contractuelle, une diligence raisonnable vis-à-vis des fournisseurs, une gestion des vulnérabilités, des contrôles d’accès et du temps de personnel. Le document de sécurité de l’information de Kepler indique qu’elle n’est actuellement pas formellement certifiée ISO 27001, bien qu’elle suive les principes de cette norme.
Cela peut être acceptable pour de nombreux clients, surtout lorsque le fournisseur d’installations est certifié, mais les acheteurs réglementés ou les grandes entreprises peuvent exiger des preuves plus solides. Si Kepler souhaite vendre à des comptes de plus grande valeur sensibles à la conformité, la charge documentaire augmente.
Le Data Act a aussi un double tranchant. Les droits au changement de fournisseur et la standardisation des contrats cloud peuvent réduire la dépendance des clients. Un fournisseur local profite du fait que les clients veulent des alternatives aux hyperscalers, mais il doit aussi accepter que les clients veulent des droits de sortie de Kepler. Les fournisseurs les plus forts gagneront parce qu’ils sont utiles et dignes de confiance, non parce qu’il est difficile de partir.
Les conditions de Kepler ne donnent aux clients qu’une fenêtre d’accès de 24 heures pour l’exportation des données après résiliation, s’ils ont payé les sommes dues et demandé l’accès à temps. Cela peut être encadré juridiquement, mais d’un point de vue économique, les clients ayant des charges de travail critiques se préoccuperont profondément de la réversibilité pratique avant de s’engager.
La réglementation soutient donc le besoin d’alternatives locales tout en rendant les preuves plus importantes. L’opportunité de Kepler est de devenir un petit fournisseur suédois crédible sur un marché soucieux de la souveraineté. Son risque est d’être jugé selon des attentes de grande entreprise avant d’avoir atteint une échelle de grande entreprise.
Les pannes transfèrent la réputation plus vite que la responsabilité
Les temps d’arrêt du cloud sont économiquement asymétriques. Les conditions contractuelles peuvent limiter la responsabilité, mais la confiance des clients évolue plus vite que les recours juridiques. La page de statut de Kepler nomme de nombreux composants de service, notamment l’identité, le calcul, le réseau, les équilibreurs de charge, le stockage d’images, le stockage de volumes, le stockage objet, la gestion des clés, l’orchestration, le DNS et les tableaux de bord dans SWE 1 et SWE 2. Cette liste de composants est utile car elle montre la surface de service dont dépendent les clients.
Elle montre également à combien d’endroits une défaillance peut survenir.
Le document de politique d’exploitation de Kepler indique qu’elle dispose de centres de données suédois géographiquement répartis, de sauvegardes, de routines de correction, d’une planification de reprise après sinistre, d’un objectif de temps de reprise de quatre heures pour les incidents graves et d’un objectif de point de reprise de 15 minutes pour la perte de données. Ce sont des engagements significatifs s’ils sont testés et dotés en personnel. Le même document annonce une disponibilité d’au moins 99,95 % pour les services critiques hébergés sur Kepler Cloud, avec des mesures compensatoires conformément aux conditions du SLA.
La page de tarifs, ailleurs, met en avant une disponibilité de 99,9 %. La différence peut refléter l’ancienneté de la page ou la portée du produit; les clients doivent lire le SLA spécifique attaché au service acheté.
La question économique n’est pas de savoir si Kepler peut éviter toute panne. Aucun fournisseur ne le peut. Il s’agit de savoir si elle peut contenir les incidents, communiquer clairement, rétablir le service rapidement et empêcher un incident local de se transformer en événement de départ de client. Les grands fournisseurs connaissent aussi des défaillances, et la panne d’AWS en 2025 rappelle que l’échelle n’élimine pas le risque de concentration. Mais les grands fournisseurs disposent de crédits de service plus importants, de plus de régions, d’équipes d’ingénierie plus étoffées et de manuels de procédure client plus matures.
Un petit fournisseur doit être plus simple, plus clair et plus responsable.
Les pannes interagissent également avec les frontières des fournisseurs. Si la cause première est un problème d’installation Glesys, un problème de connectivité, une défaillance de cluster de stockage, une route amont, un problème d’hôte GPU, un problème d’hyperviseur ou un bug du plan de contrôle, le client subit tout de même Kepler. Le client a acheté la promesse de Kepler. Le fournisseur peut aider à réparer, mais le transfert de réputation se fait vers Kepler.
C’est pourquoi les allégations de fiabilité comptent plus que l’étendue marketing. Un petit fournisseur cloud devrait vendre les services qu’il peut exploiter excellemment, pas tous les services qui peuvent figurer sur un menu. Le risque pour Kepler en cas de panne n’est pas seulement les crédits ou les remboursements. C’est la perte d’utilisation future, ce qui est plus dommageable lorsque l’entreprise a besoin de densité.
Le jugement ne change qu’avec la preuve d’une demande dense
Le jugement actuel est conditionnel mais non définitif. Kepler Technologies AB a un véritable périmètre opérationnel, une empreinte de ressources numériques étayée par RIPE, des régions cloud suédoises nommées, une tarification publique, un large catalogue de services, un partenariat avec les installations de Glesys, un positionnement GPU, des conditions de traitement des données et des politiques de sécurité. C’est plus qu’une identité fondée uniquement sur des preuves. L’entreprise est un véritable petit fournisseur d’hébergement cloud.
La question de la qualité d’investissement est de savoir si ces ingrédients produisent un actif économiquement défendable. D’après les informations publiques, le risque est plus grand que l’empreinte visible ne le suggère. Un petit fournisseur suédois doit payer ou réserver de l’infrastructure avant de savoir si suffisamment de clients la rempliront. Il doit faire fonctionner l’économie du GPU avant que le matériel ne vieillisse. Il doit s’appuyer sur des fournisseurs tout en présentant un service unifié aux clients.
Il doit rivaliser avec les hyperscalers sur l’étendue, avec Glesys sur l’infrastructure locale adossée à des installations, avec d’autres fournisseurs européens sur la souveraineté et avec les fournisseurs spécialisés en GPU sur la capacité d’accélération. Il doit supporter des attentes en matière de support et de conformité qui augmentent plus vite que le chiffre d’affaires d’une petite entreprise.
Les faits qui modifieraient le jugement sont concrets. Premièrement, Kepler devrait démontrer une utilisation dense à Falkenberg et Stockholm, en particulier pour le calcul, le stockage et la capacité GPU. Deuxièmement, elle devrait présenter des revenus récurrents et des taux de renouvellement qui prouvent que les clients ne se contentent pas d’essayer de petites charges de travail. Troisièmement, elle devrait montrer une marge brute après les coûts de centres de données, d’électricité, de matériel, de logiciels, de réseau et de support.
Quatrièmement, elle devrait prouver que les contrats gérés sont suffisamment importants et standardisés pour éviter le frein d’un support sur mesure. Cinquièmement, elle devrait fournir des preuves de niveau entreprise pour la sécurité, la réponse aux incidents, la localisation des données et la gestion des sous-traitants si elle souhaite attirer des clients réglementés.
Le jugement s’améliorerait également si Kepler publiait des preuves clients plus claires: des études de cas nominatives avec le type de charge de travail, la région, le bouquet de services, la durée et un résultat mesurable; un historique public d’incidents qui montre une gestion transparente; et une documentation produit qui rend le changement de fournisseur, la sauvegarde, la restauration et l’exportation pratiques plutôt que simplement contractuels.
Il s’affaiblirait si l’entreprise ajoutait de nouvelles régions planifiées sans prouver la demande dans les deux premières, si la capacité GPU restait inutilisée, si les coûts des fournisseurs imposaient des hausses de prix ou si les grands fournisseurs rendaient les options locales suédoises ou européennes suffisamment bon marché pour supprimer la niche de Kepler.
La réponse fondamentale de l’article est donc simple. Lorsque l’infrastructure de Kepler est sous-utilisée, Kepler supporte le risque. Lorsqu’elle est perturbée, les clients souffrent d’abord, mais Kepler supporte la perte de réputation et de renouvellement. Lorsqu’un grand fournisseur ou concurrent rend certaines parties de l’offre obsolètes, Kepler supporte le risque de capacités inutilisées. L’actif ne devient défendable que lorsque le contrôle opérationnel s’accompagne d’une densité de clientèle, d’un pouvoir de tarification et d’une discipline vis-à-vis des fournisseurs.