Richard DEMONGEOT Blog
Personnel

2026, je relance RDEM Systems : piloter mon rebond, pas le subir

Fin 2025, une page s'est tournée : un cycle salarié s'est achevé. J'aurais pu attendre, déposer des CV et regarder le calendrier. J'ai choisi l'inverse - reprendre la main, relancer RDEM Systems et transformer un savoir-faire en produit. Voici pourquoi, et surtout comment j'organise ce rebond pour le piloter plutôt que de le subir.

Un tournant, et une règle simple

Tout le monde traverse, un jour, un moment où le sol bouge un peu sous les pieds. Le mien est arrivé fin 2025. Plutôt que de raconter ce qui s'est terminé, je préfère parler de ce qui commence - c'est la seule partie sur laquelle j'ai vraiment la main.

Ma règle : un rebond, ça se pilote. On ne contrôle pas l'événement de départ, mais on contrôle ce qu'on en fait : la première brique qu'on pose, le premier client qu'on sert, le premier outil qu'on livre. Le reste suit.

Concrètement, piloter veut dire produire des preuves de résilience tangibles, pas des intentions : du code qui tourne, des clients réels, des factures émises. J'ai organisé ce rebond autour de deux axes très différents et volontairement complémentaires - la sauvegarde d'un côté, la boutique de jeux de l'autre.

Une continuité de plus de dix ans, pas un départ de zéro

RDEM Systems n'est pas une création ex nihilo : la SASU existe depuis 2016, avec une antériorité bien plus ancienne en entreprise individuelle. C'est donc le successeur naturel de cette activité - derrière le changement de structure, il y a une histoire continue, et surtout des clients qui me font confiance depuis plus de dix ans. Ils se reconnaîtront - et je les en remercie sincèrement : cette fidélité, c'est le socle sur lequel tout le reste s'appuie.

Même pendant les périodes où l'activité tournait en sommeil, en parallèle d'autres engagements, elle n'a jamais cessé : les missions ont continué, avec un chiffre d'affaires tout à fait acceptable pour une structure comme la mienne. C'est précisément ce qui rend la relance de 2026 crédible : je ne rallume pas une machine froide, je remets les gaz sur quelque chose qui n'a jamais vraiment calé.

Axe 1 - Nimbus Backup : transformer un savoir-faire en produit

Le projet central s'appelle Nimbus Backup : du Proxmox Backup Server as a service. L'idée est de prendre une techno de sauvegarde que je maîtrise et de la rendre accessible « clé en main » - sans demander au client de devenir administrateur système.

À la base, l'offre est du PBS pur : on sauvegarde des environnements Proxmox VE, proprement, avec stockage redondé en France. C'est le cœur du service - celui qui répond à un vrai besoin et qui trouve déjà ses clients, comme ce client australien dont je reparle plus bas.

Le détour Windows : un pari sur moi-même

Le déclic est venu d'un ami. Il avait commandé du Nimbus - du PBS, donc - et une fois la commande passée, il lâche, l'air de rien : « …et pour mettre du Windows ? ». Là, deux options. Soit je lui réponds gentiment qu'il est mal barré. Soit je cherche à lui sauver la mise, à en rigoler un peu, et surtout à comprendre la brique Windows. J'ai choisi la deuxième - et tant qu'à faire, je me suis posé la question qui change tout : pourquoi ne pas en faire un outil capable de générer du P2V ?

Le défi technique, lui, est apparu tout de suite : comment fiabiliser Proxmox Backup Server sur du Windows ? L'écosystème PBS est pensé pour Linux ; côté poste Windows, il fallait un client propre, robuste, qui ne casse pas au premier antivirus venu.

J'aurais pu rester sur le terrain confortable du PBS pur, sous Linux. J'ai fait le choix inverse : aller chercher le Windows précisément parce que c'est plus dur. Le temps que j'y ai passé est énorme - et soyons honnêtes, ça ne rapporte rien financièrement pour l'instant. C'est avant tout un pari sur moi-même : me prouver que je sais fiabiliser PBS là où on ne l'attend pas. Mais c'est exactement le genre de défi qui me fait avancer.

C'est exactement ce que je construis avec NimbusBackupClient, le client de sauvegarde Windows du projet. Un exemple concret de ce travail de fiabilisation : la gestion des faux positifs antivirus, un grand classique pour tout exécutable qui lit le disque et chiffre des données. La prochaine étape sur ce front sera sans doute de signer l'exécutable avec un certificat, pour couper court aux alertes des antivirus.

Crédit à l'upstream : NimbusBackupClient ne part pas de rien. C'est un fork de proxmoxbackupclient_go, l'excellent client Go de Tiziano Bacocco (tizbac), sous licence GPLv3. Sans son travail amont, il n'y aurait pas de base sur laquelle bâtir l'expérience Windows. Merci à lui - et, comme le veut la GPL, le code reste ouvert.

Le kiff technique : viser le P2V

Au-delà du besoin immédiat, il y a une cible qui me fait vraiment vibrer : arriver à terme à un outil de P2V (Physical-to-Virtual). L'idée : sauvegarder une machine physique, puis pouvoir la restaurer directement en machine virtuelle sur un nœud Proxmox VE. La sauvegarde ne sert plus seulement à se rassurer - elle devient un chemin de migration et de reprise d'activité. C'est ce genre d'objectif qui rend les soirées de dev faciles.

Les retours qui valident

Ce qui me conforte, ce sont les signaux venus de l'extérieur, et de plus loin que prévu :

Clin d'œil : les règles de résilience type Bâle III imposent - si je ne m'abuse - une quarantaine de kilomètres de séparation entre deux datacenters. Là, mon client fait littéralement l'inverse : l'autre bout de la Terre. Au fond, la vraie question philosophique : si sa donnée et son backup disparaissaient en même temps… serait-il encore vraiment à risque ?
Ce qu'il me reste à construire : la preuve publique. Le code existe, les clients existent, mais il me manque encore des sources d'autorité autour du dépôt GitHub - documentation, guides, signaux de confiance. C'est le prochain chantier assumé : transformer un outil qui marche - pas encore à 100 %, soyons honnêtes 🙂 - en projet qu'on trouve, qu'on comprend et auquel on fait confiance. Et, très honnêtement, j'espère que le logiciel tiendra ses promesses et qu'il finira par m'amener des clients. 🙂

Axe 2 - un coup de main local, pas que de la tech

Piloter son rebond, ce n'est pas s'enfermer derrière un terminal. En parallèle de Nimbus, j'ai donné un coup de main à un collègue commerçant pontoisien, comme moi : j'ai monté le site Dynamite Games Pontoise, une boutique de jeux rétro à deux pas de chez moi - un vrai trésor pour qui a grandi manette en main (j'en parle aussi côté souvenirs dans cet article).

Et parce qu'un site sans vie ne sert à rien, on a enchaîné sur l'organisation d'un jeu concours pour l'été. Les coulisses sont racontées ici :

Ça peut sembler éloigné de la sauvegarde Proxmox, mais c'est la même logique : rendre service, livrer du concret, et tisser un réseau local sur lequel on peut s'appuyer.

Piloter, pas subir

Voilà l'état d'esprit de cette relance de 2026. Un tournant n'est pas une fin : c'est une bifurcation, et le volant reste entre mes mains. Nimbus Backup grandit retour client après retour client, RDEM Systems reprend de l'élan, et le réseau local s'étoffe. Rien de tout ça n'était écrit fin 2025 - tout ça s'est décidé.

La suite ? Continuer à documenter Nimbus au grand jour, avancer vers le P2V, et écrire ici les prochaines étapes. Si le sujet sauvegarde vous parle - ou si vous tournez sous Windows et que vos backups vous inquiètent - le dépôt NimbusBackupClient est ouvert, et je suis toujours preneur d'un edge case de plus.