Vous avez déjà un serveur.
Il reste où il est.
Prise en charge d'une infrastructure déjà en production, chez votre hébergeur, sous votre contrat. Pas de migration, pas de transfert de compte, pas de réinstallation.
Sommaire
1. « Pouvez-vous gérer le serveur que j'ai déjà chez OVH ? »
C'est la première question qu'on nous pose, et elle est posée sur la défensive — comme si l'on demandait une faveur. La réponse est oui, et la formulation mérite d'être renversée : ce n'est pas une exception que nous consentons, c'est le cas normal. La quasi-totalité des serveurs que nous exploitons ont été souscrits par nos clients eux-mêmes, avant nous, et sont restés à leur nom.
Concrètement, une prise en charge de serveur existant ne demande ni migration, ni changement de
contrat, ni transfert de compte, ni fenêtre d'interruption. Nous ajoutons notre clé SSH à votre
authorized_keys, nous déployons la
supervision et la sauvegarde externalisée, et l'exploitation démarre. La machine ne bouge pas, les
adresses IP ne changent pas, vos DNS ne sont pas touchés.
Cela vaut chez OVHcloud, Hetzner, Scaleway, Contabo et IONOS, sur un VPS comme sur un serveur dédié, et aussi sur un serveur hébergé dans vos propres locaux dès lors qu'il est joignable et alimenté.
2. Pourquoi notre modèle le suppose
Beaucoup de prestataires acceptent un serveur existant à contrecœur, parce que leur marge est sur l'hébergement qu'ils revendent. Chez nous la question ne se pose pas dans ces termes : nous ne revendons aucune infrastructure. Vous souscrivez votre serveur en direct chez l'hébergeur de votre choix, vous le payez directement, et nous facturons l'infogérance seule.
Le contrat reste à votre nom
Vous êtes titulaire du compte chez l'hébergeur. Nous n'y figurons pas, sinon comme utilisateur délégué si vous le souhaitez. Vous gardez la facturation, les adresses IP et la propriété de la machine.
Notre accès est une clé, pas un verrou
Vous gardez le root. Notre accès est une clé SSH dans votre fichier d'autorisations : vous la retirez, il cesse d'exister. Le détail est écrit dans accès et réversibilité.
Nous n'avons pas d'intérêt à vous retenir
Si vous nous quittez, vous ne perdez ni la machine, ni le compte, ni les adresses. Il n'y a rien à récupérer parce qu'il n'y a jamais rien eu à transférer.
Ce point n'est pas un argument de vente périphérique : c'est ce qui rend la reprise triviale sur le plan administratif. La seule chose qui change entre « avant » et « après », c'est qui reçoit l'alerte à trois heures du matin.
3. Les cinq étapes d'une reprise
Le déploiement technique prend 48 à 72 heures et se fait sans interruption de service ; l'onboarding est compris dans le forfait. Ce qui détermine la durée réelle d'une reprise, ce n'est pas nous : c'est la période de recouvrement que vous négociez avec le prestataire sortant, à l'étape 4.
Accès en lecture et audit d'entrée
Vous nous donnez un accès au serveur. Nous n'appliquons aucun changement à ce stade : nous regardons. L'audit d'entrée établit ce qui tourne réellement, par opposition à ce que la documentation prétend.
- Inventaire : services actifs, versions, tâches planifiées, conteneurs, machines virtuelles
- État des correctifs, date de fin de support du système, vulnérabilités ouvertes
- Sauvegardes : existent-elles, où vont-elles, ont-elles déjà été restaurées
- Capacité : remplissage des disques, charge, marge avant saturation
- Accès : qui a le root aujourd'hui, quelles clés sont autorisées, lesquelles n'ont plus de propriétaire identifié
Restitution écrite
Vous recevez l'audit par écrit, avec les constats classés par risque : ce qui peut provoquer un arrêt à court terme, ce qui devra être traité dans l'année, ce qui est acceptable en l'état. Ce document est à vous, y compris si vous ne signez pas ensuite. C'est aussi le moment où nous vous disons si quelque chose nous paraît hors de notre périmètre.
Déploiement de la supervision et de la sauvegarde
Mise en place de la collecte de métriques, des seuils d'alerte et du routage vers PagerDuty ; configuration de la sauvegarde externalisée vers notre Proxmox Backup Server à Equinix Paris, hors de l'infrastructure de votre hébergeur. Opérations non intrusives, réalisées sans coupure. À partir de cette étape, nous voyons ce qui se passe — mais l'astreinte n'a pas encore basculé. Le cas externalisation d'une plateforme de virtualisation détaille la même séquence sur un parc entier.
Période de recouvrement
C'est l'étape que la plupart des reprises escamotent, et c'est celle qui compte. Pendant deux à quatre semaines, le prestataire sortant conserve ses accès et son contrat, pendant que nous exploitons déjà. Deux équipes se recouvrent volontairement.
L'objectif est de faire apparaître ce qui n'est écrit nulle part : le script qui tourne le premier de chaque mois, la dépendance vers un système tiers, la procédure connue d'une seule personne. Un mois de recouvrement coûte moins cher qu'une seule nuit passée à comprendre une automatisation non documentée pendant que la production est arrêtée.
Bascule de l'astreinte
Une date, une heure. À partir de cet instant, l'alerte nous réveille et la GTI court : 4h en formule Pro, 1h en formule Critique. Vous recevez vos identifiants PagerDuty pour déclencher un incident, et les accès du prestataire sortant sont retirés — ou conservés en lecture si vous préférez une transition plus douce.
Il n'y a pas de zone grise : avant l'heure convenue, c'est le sortant ; après, c'est nous. C'est écrit dans le contrat, pas convenu oralement.
4. Ce dont nous avons besoin
La liste est courte, et volontairement : plus un prestataire demande d'éléments avant de commencer, plus il est probable qu'il vous demande ensuite de tout refaire à son image.
Indispensable
- Un accès administrateur au serveur, par clé SSH de préférence
- L'accès à votre espace client chez l'hébergeur, ou un utilisateur délégué : c'est par là que passent le redémarrage forcé, le mode rescue et l'ouverture de ticket matériel
- Le nom d'une personne côté client qui peut arbitrer une fenêtre de maintenance
Utile, mais nous faisons sans
- La documentation existante, même périmée — elle indique au moins l'intention d'origine
- Le contact technique du prestataire sortant
- L'historique des incidents des douze derniers mois : c'est le meilleur prédicteur de ce qui cassera ensuite
- Les contrats d'éditeur et les licences en cours
5. Changer d'infogérant sans trou noir
Le risque d'un changement de prestataire n'est presque jamais technique. Il est contractuel et temporel : il existe une fenêtre pendant laquelle le sortant considère qu'il n'est plus responsable et l'entrant qu'il ne l'est pas encore. Les pannes qui tombent dans cette fenêtre sont celles qui durent.
Trois points suffisent à la fermer, et ils se règlent avant de signer, pas après :
Datez la bascule à l'heure près
« Courant octobre » n'est pas une date. Écrivez le jour et l'heure de bascule de l'astreinte dans les deux contrats, l'entrant et le sortant. C'est la seule ligne qui décide qui décroche.
Faites-vous restituer les secrets avant la fin du préavis
Mots de passe applicatifs, clés d'API, certificats, comptes de service, accès aux enregistrements DNS. Réclamez-les pendant que le contrat court encore : un prestataire sortant répond beaucoup plus vite avant son dernier jour facturé qu'après.
Vérifiez que les sauvegardes ne sont pas chez le sortant
C'est le point de blocage le plus fréquent. Si vos sauvegardes vivent sur l'infrastructure du prestataire que vous quittez, votre historique part avec lui. Nous constituons un nouveau jeu complet sur notre plateforme dès l'étape 3, avant toute rupture — pas au moment de la sortie.
Le symétrique vaut pour nous, et il est écrit : ce que vous récupérez en sortant de chez RDEM Systems, et sous quel délai, figure noir sur blanc dans accès et réversibilité. Un prestataire qui ne documente pas sa propre sortie ne vous fera pas de cadeau au moment de la vôtre.
6. Ce qui complique une reprise
Nous reprenons le système tel qu'il tourne, et nous ne conditionnons pas le démarrage de l'exploitation à une remise à plat. Quatre situations demandent cependant une décision de votre part avant que nous puissions nous engager sur une GTI, parce qu'elles limitent ce que nous pouvons réellement garantir.
Un système d'exploitation sorti de support
Plus aucun correctif de sécurité n'est publié : la maintenance préventive devient impossible, quel que soit le prestataire. Nous exploitons quand même, mais nous chiffrons la montée de version comme un chantier séparé et nous écrivons dans l'audit que le risque résiduel vous appartient tant qu'il n'est pas lancé.
Pas d'accès hors bande
Sans console de secours, mode rescue ou redémarrage forcé accessibles depuis l'espace client de l'hébergeur, un serveur qui ne répond plus au réseau devient injoignable. La GTI 1h n'a alors plus de sens : nous ne pourrions pas tenir un délai qui dépend d'un ticket chez un tiers. Nous le disons avant de signer, pas au moment de la panne.
Des root partagés sans traçabilité
Quand quatre personnes extérieures détiennent le même mot de passe root et que personne ne sait qui a fait quoi, aucun engagement d'exploitation ne tient : la configuration peut changer sous nos pieds entre deux interventions. Nous demandons des comptes individuels — un par intervenant — sans imposer pour autant de bastion ni de politique d'accès particulière.
Des logiciels compilés à la main, sans procédure
Un binaire compilé sur mesure il y a six ans, dont personne n'a gardé les options ni les sources, ne peut pas être mis à jour ni réinstallé à l'identique après un incident. C'est le seul cas où nous recommandons franchement de reconstruire avant de contractualiser, plutôt que de vendre une astreinte sur quelque chose que personne ne saura remonter.
Dans les quatre cas, la réponse par défaut reste l'exploitation avec un plan de remise à niveau chiffré à part, que vous déclenchez quand vous le décidez. Ce que nous refusons, ce n'est pas la reprise : c'est de signer une GTI que la situation technique rend intenable.
7. Questions fréquentes
Pouvez-vous gérer le serveur que j'ai déjà chez OVH ?
Oui, et c'est le cas normal plutôt que l'exception. Nous ne revendons aucune infrastructure : la quasi-totalité des serveurs que nous exploitons ont été souscrits par nos clients eux-mêmes, chez OVHcloud, Hetzner, Scaleway, Contabo ou IONOS. Il n'y a ni migration, ni changement de contrat, ni transfert de compte : nous ajoutons notre clé SSH, nous déployons la supervision, et l'exploitation démarre. Le serveur ne bouge pas.
Puis-je garder mon hébergeur actuel ?
Non seulement vous le pouvez, mais notre modèle le suppose. Le contrat d'hébergement reste à votre nom, vous continuez à payer votre hébergeur en direct, et nous ne facturons que l'infogérance. Cela veut dire que nous n'avons aucun intérêt financier à vous garder captif : si vous nous quittez, vous ne perdez ni votre machine, ni votre compte, ni vos adresses IP.
Comment se passe un changement d'infogérant ?
En cinq étapes : accès en lecture et audit d'entrée, restitution écrite de l'audit, déploiement de notre supervision et de la sauvegarde externalisée, période de recouvrement pendant laquelle le prestataire sortant conserve ses accès, puis bascule de l'astreinte à une date et une heure convenues. La période de recouvrement dure typiquement deux à quatre semaines et évite le trou noir classique où plus personne ne se sent responsable.
Combien de temps prend la prise en charge d'un serveur existant ?
Le déploiement technique — supervision, sauvegarde externalisée, accès — prend 48 à 72 heures, sans interruption de service, et l'onboarding est compris dans le forfait. L'audit d'entrée est restitué sous quelques jours. La durée totale d'une reprise dépend en pratique de la période de recouvrement que vous négociez avec votre prestataire sortant, pas de nous.
Faut-il migrer ou réinstaller le serveur pour passer chez vous ?
Non. Nous reprenons le système tel qu'il tourne. Si l'audit d'entrée révèle un problème structurel — système d'exploitation sorti de support, absence de sauvegarde exploitable, partitionnement qui ne permet pas de croître — nous le chiffrons comme un chantier séparé, avec sa propre fenêtre, et vous décidez de le lancer ou non. Nous ne conditionnons pas le démarrage de l'exploitation à une remise à plat.
Que se passe-t-il si mon prestataire actuel ne coopère pas ?
La reprise reste possible tant que vous détenez l'accès administrateur au serveur et le compte chez l'hébergeur — ce qui est le cas si le contrat est à votre nom. Nous reconstituons alors l'inventaire par l'audit technique plutôt que par la documentation du sortant : services actifs, tâches planifiées, certificats, dépendances externes. C'est plus long et cela laisse une zone d'incertitude sur les automatismes non documentés, que nous vous signalons explicitement plutôt que de la passer sous silence.
Reprenez-vous un serveur qui n'a jamais été supervisé ?
Oui, c'est même le motif de reprise le plus fréquent. Attendez-vous à ce que l'audit d'entrée remonte des choses : un disque proche de la saturation, des correctifs en retard, une sauvegarde configurée mais jamais restaurée. Ce n'est pas un motif de refus, c'est le point de départ. Nous les classons par risque et nous traitons d'abord ce qui peut provoquer un arrêt.
Faites auditer le serveur que vous avez déjà
Dites-nous chez quel hébergeur il tourne et ce qu'il porte. Nous vous répondons avec ce que nous regarderions en premier.
Demander un devis