Feuille de route Mise à jour le 10 octobre 2026

Ce que Sarpius construit, et dans quel ordre

Il ne manque presque plus de fonctionnalités à Sarpius. Ce qui manque, c'est la preuve : une reprise après incident testée de façon démontrable plutôt que promise, et des chiffres de production que tu peux vérifier toi-même. La reprise des bases de données est en place ; la suite consiste à ouvrir ce que nous faisons déjà tourner pour nous-mêmes, puis le reste de la reprise, puis la ligne de calcul. Cette page nomme aussi les endroits où nous sommes en retard aujourd'hui.

En cours À venir Prévu

Où nous en sommes aujourd'hui

Les déploiements, le routage avec TLS automatique, les bases de données managées (avec TLS sur chaque base dédiée), le stockage d'objets avec buckets publics, les files de messages, un cache en périphérie, les tâches planifiées et la facturation à la minute tournent en production, de même qu'une page de statut publique avec disponibilité et historique des incidents par composant. Sarpius Functions tourne en bêta fermée : Node.js, Python et PHP, à chaque requête ou selon un planning, facturé par GiB-seconde et par invocation. Le cycle de vie complet d'une application est pilotable depuis la console, l'API publique et un serveur MCP pour les agents IA, et un projet peut être exporté sous forme de bundle de migration quand tu veux partir. SparxLite tourne aujourd'hui, encore sur des tailles fixes, chaque taille et son prix étant publiés. Les points de restauration que tu remets en place toi-même tournent pour PostgreSQL (partagé et dédié), ainsi que pour Redis et MariaDB dédiés ; PostgreSQL dédié en version 16 bénéficie aussi de la récupération à un instant précis.

Ce qui ne figure pas dans cette liste : les variables d'environnement et les connexions aux bases de données pour Functions, la gestion des secrets pour tes propres applications, les points de restauration pour les buckets et un second site indépendant. Ce sont les phases 1, 2, 3 et 7 ci-dessous, et tant qu'elles n'existent pas, nous indiquons pour chaque type de ressource exactement ce qui est restauré et ce qui ne l'est pas.

0 En cours ce mois-ci

Les derniers chiffres en avant

La disponibilité par composant, la période de mesure correspondante et les prix de chaque taille SparxLite sont déjà sur le site sans un clic. Trois chiffres manquent encore, ou se trouvent encore derrière un lien.

Temps de rétablissement et réussite des déploiements sur la page de statut. Temps moyen de rétablissement par composant et part des déploiements réussis, à côté de la disponibilité déjà affichée.
Le SLA là où la question se pose. Sur les tarifs, les bases de données et l'autoscaling, un court résumé de l'objectif de disponibilité et des délais de réponse, avec un lien vers le document complet. Un objectif, pas une garantie, et nous le disons.
Limites de restauration pour chaque type de ressource. Publiées aujourd'hui pour les bases de données. Les buckets, les apps et SparxLite suivent : ce qui est restauré, la quantité de données que tu peux perdre au pire, et qui déclenche l'action, y compris là où la réponse est défavorable.

Le test auquel nous nous tenons : tu peux évaluer ton propre risque et ta propre facture sans nous envoyer de mail. "Nous ne savons pas" cesse d'être la réponse factuelle partout.

1 En cours

Sarpius Functions, hors de la bêta fermée

Les fonctions tournent déjà dans ton projet, dans des microVM Firecracker, avec leur propre routage, leurs membres et leur facturation. Ce qui les maintient en bêta fermée, c'est qu'elles ne peuvent pas encore atteindre le reste de ton application.

Variables d'environnement par environnement. Définies de la même manière que pour n'importe quel autre composant.
Connexions aux bases de données. Relie une base de données à une fonction exactement comme tu la relies aujourd'hui à une app.
Ouvert à tous. Aucun accès bêta nécessaire, avec les mêmes prix par GiB-seconde et par invocation et les mêmes plafonds de dépenses.

D'ici là, Functions est marqué bêta fermée partout où nous en parlons. La même règle vaut pour tout le site : en ligne, bêta ou prévu, jamais sous-entendu.

2 En cours

SarpiVault, des secrets hors de tes variables d'environnement

SarpiVault détient déjà les propres secrets de la plateforme, avec versionnement et piste d'audit. L'étape suivante est de l'ouvrir à tes propres applications.

Historique des versions par secret. Y compris qui a lu quoi et quand.
Injection sans exposition. Dans les composants et les fonctions sans que la valeur n'apparaisse jamais dans une réponse d'API, un journal ou un diff.
Rotation sans redéploiement complet. De tout ce qui utilise la clé.

Pourquoi avant le reste de la reprise : une sauvegarde d'un système qui garde encore les secrets en variables d'environnement en clair sauvegarde aussi ces secrets. Faire d'abord tourner le coffre pour nos propres secrets, c'est ainsi que nous savons qu'il tient avant de te demander de lui confier les tiens.

3 Prévu

Sauvegarde et restauration en tant que produit

Les points de restauration que tu remets en place toi-même depuis la console, sans ticket et avec une rétention publiée, existent déjà pour PostgreSQL (partagé et dédié), ainsi que pour Redis et MariaDB dédiés ; PostgreSQL dédié en version 16 restaure aussi à n'importe quel instant des 7 derniers jours grâce à la récupération à un instant précis. Ce qui reste ici, c'est le reste : couvrir chaque type de ressource, et vérifier selon un planning que ça marche vraiment.

Points de restauration pour les buckets. Le même bouton que pour les bases de données qui l'ont déjà.
Objectifs RPO et RTO par type de ressource. En public.
Un test de restauration automatisé. Tournant selon un planning, avec un résultat que tu peux voir.

Ce dernier point n'est pas optionnel. Une sauvegarde à partir de laquelle personne n'a jamais restauré est une hypothèse. Ceci vient délibérément avant la phase de calcul : SparxLite et SparxCore s'y brancheront, plutôt que d'avoir chacun sa demi-solution.

4 Prévu

Managed Domains, ton domaine sans corvées DNS

Aujourd'hui tu achètes un domaine ailleurs et tu configures ensuite toi-même les enregistrements. Ça devient une étape à l'intérieur de ton projet.

S'enregistrer et transférer via Sarpius. Acheter un nouveau domaine, ou transférer un domaine existant avec un code de transfert, payé depuis le même solde que le reste.
DNS hébergé chez nous. Tu gères les enregistrements dans la console et via l'API, avec les mêmes permissions que le reste de ton projet.
Relié automatiquement à ton application. Choisir un domaine pour un composant suffit : nous gérons le routage et le certificat TLS, sans que tu aies à recopier un CNAME où que ce soit.
Aucun verrouillage. Tu demandes toi-même le code de transfert dans la console, sans ticket. Ton domaine t'appartient, même quand tu pars.

Pourquoi après les sauvegardes et avant le calcul : un domaine est la première chose sur laquelle une application s'appuie et la dernière que tu veux perdre. Cela nécessite d'abord une plateforme dont la propre reprise après incident est en ordre ; chaque forme de calcul qui vient ensuite en hérite dès le premier jour.

5 Prévu Nouveau produit

SparxLite reconstruit, et SparxCore à ses côtés

Toute la ligne de calcul est mise en ordre d'un coup. SparxLite passe des tailles fixes au dimensionnement libre, et SparxCore la rejoint : des VM cloud complètes avec leur propre noyau et un accès root.

Ce que c'est	SparxLite	SparxCore
Ce que c'est	Conteneurs	VM cloud complètes
Isolation	Noyau partagé	Noyau et OS propres
Accès	Managé depuis la console	Root via SSH, plus une console d'urgence
Aujourd'hui	En ligne, sur tailles fixes	Pas encore disponible

Dimensionnement libre. CPU, RAM et stockage définis indépendamment à la création et lors du redimensionnement, au lieu de choisir un palier fixe.
Un configurateur public. Tu calcules un coût mensuel concret pour tourner 24/7 sans compte, et c'est le même montant qui te sera facturé ensuite.
Les règles techniques de base publiées. Modèle de CPU, partagé ou dédié, usage raisonnable, TCP et UDP, ports par instance, bande passante incluse et ce qui se passe au-delà de cette limite.
Portée DDoS pour le trafic de jeu direct. Indiquée séparément, pas seulement pour le trafic web derrière le routeur.
SparxCore complet dès le premier jour. Créer, démarrer, arrêter, redémarrer, redimensionner, supprimer, plus l'accès console quand le réseau est coupé. Une liste d'images publiée, IPv4 et IPv6, et des règles de pare-feu depuis la console.
Instantanés et sauvegardes dès la phase 3. La même rétention et le même bouton de restauration que le reste de la plateforme, pas un second système.
Ce qui arrive à tes données en cas de panne d'hôte. Publié par type de stockage. C'est la question sur laquelle les acheteurs de VM insistent, et à juste titre.
SparxLite, SparxCore ou un projet. Une comparaison qui dit quand choisir lequel, y compris face à l'hébergement de jeu traditionnel et face à un VPS ordinaire.

Si tu es sur un palier SparxLite fixe aujourd'hui : nous indiquerons ce qui arrive à ton prix quand le dimensionnement libre sera lancé, avant qu'il soit lancé. Pas après.

6 Prévu

Cas clients avec de vrais chiffres

Pas un témoignage disant que ça marche bien, mais un environnement de production que tu peux vérifier.

Requis par cas : nombre de composants et leur rôle, requêtes par mois, taille et moteur de base de données, fréquence de déploiement et si ces déploiements ont causé une indisponibilité.
Un vrai événement de scaling. De combien à combien de répliques, et ce qui l'a déclenché.
Au moins un incident par cas. Ce qui a mal tourné et combien de temps la reprise a pris. Un cas sans panne n'est pas un cas, c'est une publicité.
Un vrai cas de restauration. Plus des images d'un déploiement, d'un rollback, de l'autoscaling en action, et d'un export montrant que tu peux repartir.

Ceci se place volontairement après la phase 3. Le cas de restauration est la partie qu'un lecteur technique vérifie le plus sévèrement, et jusque-là nous n'aurions pas pu le faire honnêtement.

7 Prévu

Une seconde zone indépendante

D'abord une seconde zone néerlandaise correctement conçue. Plusieurs pays seulement après ça. Deux sites reposant sur les mêmes dépendances sous-jacentes ne sont pas de la redondance, c'est une carte.

Deux sites séparés. Physiquement et opérationnellement, sans alimentation, réseau ou stockage partagés.
Basculement de base de données. Entre les deux.
Un routage capable de contourner entièrement un site. Y compris une panne complète du site, pas seulement un seul nœud.
Un engagement de zone explicite pour les VM SparxCore. Fixé au lancement de SparxCore plutôt qu'ajusté après coup.
Un test de basculement effectué, avec le résultat publié. Sinon c'est un plan, pas une zone.

Les régions internationales viennent après ça, et alors pour quatre raisons concrètes : la latence en dehors des Pays-Bas, un choix en matière de localisation des données, la reprise après sinistre régionale, et des clients qui n'accepteront pas de dépendre d'un seul pays.

En continu, à côté de chaque phase

Les phases numérotées sont un ordre : chacune a une raison de venir après la précédente. Ces deux chantiers ne le sont pas. Ils tournent dès maintenant, n'ont pas de date de fin, et n'attendent pas la phase 7.

Plus de frameworks, de runtimes et d'intégrations

Le travail qui rend la plateforme utilisable pour plus de monde : plus de frameworks reconnus par l'assistant dès que tu connectes ton dépôt, plus de runtimes et de versions, plus de moteurs de base de données, et plus de modèles prêts à l'emploi.

Une liste publique des frameworks, runtimes et versions pris en charge, chacun avec un statut honnête : testé, expérimental ou prévu.
La règle d'admission : quelque chose ne rejoint cette liste qu'une fois qu'un vrai dépôt de ce type a été détecté, construit et déployé, et que ce déploiement tourne. Pas quand la détection fonctionne et que le reste n'est pas éprouvé.
Configuré correctement dès l'arrivée : les variables d'environnement et les ports dont un framework a besoin, sans que tu aies à les chercher.
Des demandes via Discord. Ce que tu demandes atterrit sur cette même liste publique en tant que prévu, afin que tu puisses suivre ce qu'il advient.

Trouvabilité et transparence

Du petit travail, un effet cumulatif.

L'expérience publique complète dans chaque langue que nous proposons, aujourd'hui l'anglais, le néerlandais, l'allemand et le français, tenue complète à mesure que des pages s'ajoutent.
Chaque fonctionnalité marquée en ligne, bêta ou prévue.
Une page publique d'architecture et de sécurité.
Le DPA et la liste des sous-traitants à deux clics depuis n'importe quelle page.
Un résumé d'une revue de sécurité indépendante.
Les études de cas dans la navigation principale, à côté du journal des modifications et de cette feuille de route.

Où nous sommes en retard aujourd'hui

Ce ne sont pas des problèmes de présentation. Ils sont là pour que tu les connaisses avant de mettre un environnement de production chez nous, plutôt qu'après.

La reprise n'est pas encore complète

Les points de restauration que tu remets en place toi-même existent pour PostgreSQL (partagé et dédié), ainsi que pour Redis et MariaDB dédiés, et PostgreSQL dédié en version 16 bénéficie aussi de la récupération à un instant précis. Les points de restauration pour les buckets n'existent pas encore. Pour tout ce qui n'est pas couvert, garde ta propre exportation.

Résolu en phase 3

Tout tourne dans un seul domaine de panne

La plateforme tourne aujourd'hui sur un seul site. Une panne qui met ce site à terre emporte ton application avec elle. Nous préférons te le dire ici plutôt que te laisser le découvrir.

Résolu en phase 7

SparxLite n'a que des tailles fixes

Aujourd'hui tu choisis parmi un ensemble de tailles prédéfinies. Si ta charge de travail ne rentre pas bien dans l'une d'elles, tu payes pour un palier dont tu n'as pas besoin. Chaque taille et son prix mensuel sont publiés sur la page SparxLite, pour qu'au moins tu puisses faire le calcul.

Résolu en phase 5

Notre historique de mesure est encore court

La page de statut ne mesure que depuis peu de temps. Il y a peu à accélérer là-dessus ; ce que nous faisons à la place, c'est être honnêtes sur la fenêtre et documenter chaque incident publiquement, y compris ce qu'il nous a appris.

S'améliore avec le temps

Une année d'historique de statut honnête avec une poignée de pannes bien gérées convainc plus qu'un 100 % théorique. Cette feuille de route est le chemin vers ça, et elle est mise à jour quand l'ordre change plutôt que complétée par une seconde.

Voir la page de statut Demander un framework sur Discord