Ce que vous gardez,
et comment vous nous sortez
Les accès, les secrets et la réversibilité, écrits noir sur blanc. Chez nous, reprendre la main ne se négocie pas : cela se fait en retirant une clé.
Sommaire
1. Vous gardez la main, entièrement
Vous conservez un accès root complet sur vos machines. Nous ne verrouillons rien. Ce n'est pas un oubli, c'est la conséquence directe de notre modèle : vous achetez l'infrastructure en direct chez l'hébergeur, nous ne facturons que l'exploitation. La machine est à vous, le compte chez l'hébergeur est à vous, et les accès le sont aussi.
| Ce à quoi vous avez accès | Niveau |
|---|---|
| Vos serveurs | root, en permanence |
| Proxmox VE | interface et API, si l'hyperviseur vous est dédié |
| Vos machines virtuelles | console et export |
| Vos sauvegardes | consultation et restauration |
| Votre espace membre | console, démarrage et arrêt, insertion d'ISO, sauvegardes |
| Votre compte hébergeur | il n'a jamais cessé d'être le vôtre, dès lors que vous l'avez souscrit en direct |
Chez beaucoup d'infogéreurs, « comment je récupère mes billes ? » ouvre un chantier de plusieurs mois et une facture de réversibilité. Ici, la question a une réponse d'une ligne — et elle est plus bas sur cette page.
2. Ce que nous préconisons, sans l'imposer
La distinction compte, alors autant l'écrire : ce qui suit sont des recommandations. Nous les défendons, nous les argumentons, et nous nous y tenons de notre côté. Mais la politique d'accès de vos serveurs vous appartient.
Des clés SSH, pas des mots de passe Unix
C'est notre préconisation la plus ferme. Un mot de passe se devine, se rejoue, se note sur un carnet et se partage sans laisser de trace. Une clé se révoque unitairement : retirer une ligne d'un fichier retire un accès, et un seul.
Des comptes individuels
Un compte par personne, pour qu'on sache qui a fait quoi. Des comptes par groupe restent possibles si vous le demandez — certaines organisations les préfèrent, et c'est votre décision. Nous vous dirons simplement ce que vous y perdez en traçabilité.
Ce que nous n'imposons pas
Ni bastion, ni double facteur sur vos machines, ni revue d'accès obligatoire. Nous pourrions en faire une liste de contrôles et la présenter comme un gage de sérieux : ce serait surtout un moyen de nous rendre indispensables. Un prestataire qui tient seul les clés de votre infrastructure est un prestataire dont vous ne partez pas facilement. Nous avons fait le choix inverse, et cette page existe pour que ce soit vérifiable.
Ce n'est pas un plafond, c'est un réglage par défaut. Si votre politique de sécurité exige un bastion, un VPN d'administration, du double facteur, des privilèges temporaires ou la journalisation des sessions, nous le mettons en place et nous nous y conformons — c'est votre infrastructure et vos contraintes. La différence est que cela vient de vous, pas de nous.
Et c'est souvent le bon réflexe : au-delà d'un certain niveau de criticité, ou dès qu'un cadre réglementaire s'applique, ces mesures ont leur place — dans le contrat, pas seulement dans les usages.
3. Les secrets : qui détient quoi
Les identifiants, clés et mots de passe créés à la mise en service vous sont transmis à ce moment-là. Chacun les conserve ensuite de son côté. Il n'existe donc pas de coffre unique dont nous serions le seul détenteur, et vous n'avez jamais à nous demander l'accès à votre propre infrastructure.
Pour les clients en astreinte ou en infogérance d'infrastructure complète, l'inverse est également possible : un accès à notre propre coffre, pour que votre équipe ne soit pas bloquée si nous ne répondons pas. La dépendance doit couper dans les deux sens, sinon ce n'est pas de la redondance.
4. La restauration trimestrielle, et son rapport
Une sauvegarde dont personne n'a jamais restauré le contenu n'est pas une sauvegarde, c'est une hypothèse. Alors nous la vérifions, et surtout nous vous en donnons la preuve.
Deux preuves de nature différente
Prises isolément, chacune a l'air mince. Ensemble, elles couvrent la question — et la distinction est réelle : une empreinte valide ne dit pas qu'une machine redémarre.
| Preuve | Ce qu'elle atteste | Portée |
|---|---|---|
| Intégrité | L'archive n'a pas pourri et correspond à ce qui a été écrit. Chaque bloc porte une empreinte, et la bonne pratique documentée par Proxmox est un travail récurrent sur les sauvegardes récentes, doublé d'un travail périodique qui « revérifie tout ». | Automatique, permanente, exhaustive |
| Restauration | La chaîne complète fonctionne, et voici combien de temps elle prend. C'est la seule des deux qui produit une durée. | Manuelle, périodique, échantillonnée |
Notre engagement, avec sa condition
Pour les infrastructures en Proxmox dont les sauvegardes sont sur notre plateforme Nimbus, nous restaurons une machine virtuelle tirée au hasard, à une cadence qui suit la taille du parc :
| Taille du parc | Restauration testée |
|---|---|
| Jusqu'à 5 machines | une VM au hasard par semestre |
| Au-delà de 5 machines | une VM au hasard par trimestre |
Au hasard, et c'est le point important : si nous choisissions la machine, nous ne testerions que celles dont nous savons déjà qu'elles remontent.
Ce que ce test prouve, et ce qu'il ne prouve pas. Un tirage aléatoire vérifie que la chaîne de restauration fonctionne, pas que chacune de vos machines a été restaurée récemment — plus le parc est grand, plus le passage d'une machine donnée s'espace. C'est la vérification d'intégrité, elle, qui couvre l'ensemble du parc en permanence. Les deux ensemble répondent à la question ; l'une sans l'autre n'y répond pas.
Le rapport qui vous est remis porte :
- • la date du test ;
- • la machine tirée et restaurée ;
- • la volumétrie remontée ;
- • la durée de restauration mesurée ;
- • le résultat.
La condition n'est pas une réserve commerciale : elle délimite ce que nous pouvons réellement tenir. Nous ne testons pas les restaurations d'une sauvegarde que nous n'exploitons pas, ni d'une charge qui n'est pas virtualisée chez nous.
Pourquoi ce chiffre vaut mieux qu'une garantie
La durée de restauration mesurée est la seule donnée qui permette d'estimer un temps de rétablissement réaliste. Personne ne vous la donne. C'est aussi ce qui rend notre position tenable sur les délais : nous ne garantissons pas un temps de rétablissement, nous mesurons le vôtre et nous vous le communiquons.
Un prestataire qui vous vend une GTR de 4 heures sans avoir jamais chronométré une restauration sur votre volumétrie vous vend un nombre, pas un délai.
Le mécanisme — comment les sauvegardes sont faites, la rétention, l'immuabilité, la façon dont le test est mené — est décrit sur Nimbus, notre plateforme de sauvegarde. Ce que vous lisez ici est l'autre moitié : l'engagement d'exploitation, c'est-à-dire le fait que quelqu'un s'en serve régulièrement et vous le prouve.
5. Comment vous nous sortez
C'est la question que tout le monde pose en fin de contrat, et rarement au début. Voici la réponse complète, dans les trois cas de figure.
Dans tous les cas : vous retirez notre clé
Notre accès est une clé publique dans un fichier authorized_keys.
Vous la supprimez, et l'accès cesse d'exister — immédiatement, sans nous prévenir, sans
notre concours. Il n'y a pas de compte de service dissimulé ni d'agent propriétaire à
désinstaller.
Votre infrastructure est chez un hébergeur
OVHcloud, Scaleway, Hetzner, IONOS : il n'y a rien à migrer. Le matériel, le contrat et le compte sont à votre nom depuis le premier jour. Couper nos accès suffit, et vous êtes sorti.
Votre machine virtuelle est hébergée chez nous
Vous récupérez son export au format .vma.zst,
le format natif de Proxmox, et vous la réinstallez où vous le souhaitez. C'est la seule
opération qui demande un peu de travail — et elle est de votre côté, pas du nôtre.
Pas de délai de réversibilité à négocier, pas de facture de sortie, pas de format propriétaire. Nous préférons être gardés parce que le service convient, pas parce que partir coûte cher.
6. Ce qui reste chez nous
Deux exceptions, et il vaut mieux les dire clairement.
Le serveur de sauvegarde physique
Lorsque vos sauvegardes sont hébergées sur notre plateforme Nimbus. C'est un service managé — vous n'avez pas la main sur cette machine, et c'est précisément ce que vous achetez.
Un hyperviseur mutualisé
L'accès à l'interface et à l'API Proxmox VE suppose que l'hyperviseur vous soit dédié. S'il héberge aussi d'autres clients, nous ne pouvons pas vous en ouvrir la console d'administration sans leur donner accès à vos machines, et réciproquement.
Vous n'êtes pas démuni pour autant. Vous gardez le root sur vos machines, et votre espace membre vous donne la main sur ce qui compte au quotidien, sans passer par nous :
- • la console de vos machines ;
- • le démarrage et l'arrêt ;
- • l'insertion d'un CD, depuis les images ISO préchargées ;
- • la navigation dans vos sauvegardes ;
- • la restauration d'une sauvegarde.
Ce qui reste de notre côté, c'est l'administration de l'hôte lui-même — celle qui touche aussi aux autres. Sur un hyperviseur qui vous appartient ou qui vous est réservé, la question ne se pose pas.
Ce que cela ne change pas : vos sauvegardes restent consultables et restaurables par vous, à tout moment. C'est le matériel et son exploitation qui sont à nous, pas vos données.
Nous sommes établis à Pontoise, dans le Val-d'Oise, et l'essentiel de nos interventions se fait à distance.
Questions fréquentes
Gardez-vous un accès à nos serveurs après la fin du contrat ?
Non, et vous n'avez rien à nous demander pour cela. Notre accès est une clé SSH dans votre fichier authorized_keys : vous la retirez, l'accès cesse d'exister. Il n'y a pas de compte de service caché, pas de porte dérobée d'exploitation, pas de délai de désactivation à négocier.
Imposez-vous un bastion, du MFA ou une politique d'accès ?
Pas par défaut. Nous préconisons fortement les clés SSH plutôt que les mots de passe Unix, et les comptes individuels plutôt que les comptes partagés, mais la politique d'accès reste la vôtre : c'est votre serveur et vous en gardez le root. En revanche, si vous exigez un bastion, un VPN d'administration, du double facteur ou la journalisation des sessions, nous le mettons en place et nous nous adaptons à vos contraintes de sécurité. Ce que nous refusons, c'est d'en faire une condition du service : un prestataire qui verrouille l'accès de son client se rend indispensable.
Que se passe-t-il si je veux migrer une VM hébergée chez vous ?
Vous récupérez son export au format .vma.zst et vous la réinstallez où vous voulez. Si votre infrastructure est déjà chez un hébergeur — OVHcloud, Scaleway, Hetzner, IONOS — il n'y a même pas de migration : le matériel et le compte sont à vous, il suffit de couper nos accès.
Qui détient les mots de passe et les secrets ?
Nous vous les transmettons au moment de la mise en service, et chacun les conserve ensuite de son côté. Il n'existe pas de coffre unique dont nous serions le seul détenteur. Les clients en astreinte ou en infogérance d'infrastructure complète peuvent en plus obtenir un accès à notre propre coffre.
Testez-vous réellement les restaurations ?
Oui, pour les infrastructures en Proxmox dont les sauvegardes sont sur notre plateforme Nimbus : nous restaurons une machine virtuelle tirée au hasard — une par semestre jusqu'à cinq machines, une par trimestre au-delà — et nous vous remettons le rapport : date, machine, volumétrie, durée de restauration et résultat. La durée mesurée est la seule donnée qui permette d'estimer un temps de rétablissement réaliste.
Une question sur le contrat plutôt que sur la technique ?
Périmètre, accès, sortie : nous répondons par écrit, avant la signature.
Demander un devis