Le 10 mars 2021 à 00h47, un incendie se déclare dans le datacentre SBG2 d'OVHcloud à Strasbourg. Le bâtiment de cinq étages est entièrement détruit (Datacenter Dynamics). Parmi les entreprises touchées, certaines découvrent ce matin-là que leur sauvegarde était stockée dans le même bâtiment que leur production. Deux ans plus tard, un tribunal français condamnait OVHcloud à indemniser des clients ayant perdu ces données (Blocks & Files). Aucun de ces dirigeants n'avait fait une erreur de dimensionnement serveur. Ils avaient tous coché la case sauvegarde.
En bref. L'hébergement d'un logiciel métier se décide sur trois critères contractuels avant d'être une question technique : à quel nom est ouvert le compte d'hébergement, où sont stockées les sauvegardes et comment se prouve leur restauration, et selon quelles modalités vous récupérez vos données si vous changez de prestataire. Le choix cloud ou serveur dédié vient après.
La question technique n'est presque jamais celle qui vous coûtera cher
Je vais être directe, parce que c'est le point où je diverge de tout ce que vous lirez ailleurs sur le sujet. Les guides d'hébergement de logiciel métier vous parlent de cœurs CPU, de RAM, de RAID et de niveaux de disponibilité. Ces paramètres comptent, mais ils sont réversibles. Un serveur sous-dimensionné se change en une nuit de maintenance.
Ce qui ne se rattrape pas, c'est un compte d'hébergement ouvert au nom de votre prestataire, une sauvegarde que personne n'a jamais restaurée pour de vrai, ou un contrat muet sur ce qui se passe le jour où vous partez. Ces trois points ne se voient pas sur une fiche technique. Ils se voient le jour de la panne, du litige ou du changement d'agence, c'est-à-dire au pire moment possible.
C'est le fil rouge de cet article. Je traite la partie infrastructure, parce qu'il faut la comprendre, mais je passe plus de temps sur ce que votre contrat doit dire.
Où héberger un logiciel métier : les quatre options réelles
Il existe quatre modes d'hébergement réellement praticables pour une PME, et le choix se fait moins sur la technique que sur qui porte la responsabilité opérationnelle au quotidien.
| Mode | Qui administre | Adapté quand | Le vrai risque |
|---|---|---|---|
| Serveur dans vos locaux | Vous, ou votre infogéreur | Contrainte forte de localisation, application sans besoin d'accès externe | Panne matérielle, incendie, vol, absence de redondance électrique |
| Serveur dédié en datacentre | Vous ou votre prestataire | Charge stable et prévisible sur plusieurs années | Vous restez responsable des mises à jour système |
| Cloud public (VPS, instances) | Votre prestataire | Application web, charge variable, croissance incertaine | Dépendance au fournisseur, facture qui dérive |
| Plateforme managée | Le fournisseur | Application moderne, équipe technique réduite | Moins de contrôle fin, réversibilité à vérifier |
Pour une application métier développée sur mesure, accessible par navigateur, l'arbitrage réel se joue entre cloud public et plateforme managée. Le serveur dans vos locaux ne se justifie plus que par une contrainte réglementaire ou métier précise, rarement par le budget.
Faut-il encore un serveur physique dans ses locaux ?
Dans la plupart des dossiers que je vois, non. Un serveur en local vous expose à l'incendie, au dégât des eaux, à la coupure électrique et au vol, quatre risques qu'un datacentre professionnel traite par métier. Il vous oblige aussi à assurer vous-même les correctifs de sécurité et la supervision, deux tâches qui glissent toujours en bas de la pile quand personne n'a le temps.
Le cas où il garde du sens : un atelier ou un site de production où l'application doit fonctionner même sans connexion internet, ou une contrainte contractuelle qui impose la localisation physique des données. Dans ces situations, la bonne architecture est souvent hybride, avec un fonctionnement local et une réplication hors site.
À quel nom est ouvert le compte d'hébergement ?
C'est la question que personne ne pose avant de signer, et celle qui crée le plus de dégâts ensuite. Trois configurations existent, et elles ne se valent pas du tout.
Votre prestataire ouvre le compte à son nom et vous refacture. C'est confortable pour vous et pour lui, jusqu'au jour où la relation s'arrête. Vous n'avez alors ni accès au serveur, ni au nom de domaine, ni aux sauvegardes, et vous négociez en position de faiblesse la restitution de ce que vous croyiez posséder.
Vous ouvrez le compte à votre nom et donnez un accès technique à votre prestataire. C'est la configuration saine. Vous payez l'hébergeur directement, vous voyez la facture réelle, vous pouvez révoquer un accès en trois clics, et vous restez maître de votre nom de domaine.
Configuration intermédiaire, le prestataire administre mais le contrat prévoit explicitement le transfert du compte à première demande. Acceptable si c'est écrit noir sur blanc, avec un délai. Le même raisonnement vaut pour le code lui-même, et je le détaille dans l'article sur la propriété du code d'un logiciel sur mesure.
Vos sauvegardes existent-elles vraiment ou sont-elles seulement cochées ?
L'incendie de Strasbourg a servi de leçon collective sur un point précis : une sauvegarde stockée dans le même bâtiment que la production n'est pas une sauvegarde, c'est une copie. La règle de prudence courante consiste à conserver au moins trois copies de vos données, sur deux supports différents, dont une copie hors site.
Mais le vrai test est ailleurs. Une sauvegarde qui n'a jamais été restaurée est une hypothèse. Tant que personne n'a remonté la base sur un environnement vierge et vérifié que l'application démarre avec les bonnes données, vous ne savez pas si votre filet existe.
Ce que je recommande d'écrire au contrat : la fréquence des sauvegardes, leur durée de rétention, leur localisation physique distincte de la production, et un test de restauration documenté au moins une fois par an. Cette dernière ligne est celle qui fait la différence, et c'est aussi la seule que presque personne n'exige.
Pourquoi la sauvegarde est devenue un sujet de survie et non de confort
Parce que la cible a changé. Dans son Panorama de la cybermenace 2025, publié le 11 mars 2026, l'ANSSI indique que 48 % des victimes d'attaque par rançongiciel en France sont des TPE, PME ou ETI, contre 37 % l'année précédente (ANSSI, analyse reprise par Le Monde Informatique).
Face à un rançongiciel, la seule chose qui vous rend votre activité, c'est une sauvegarde saine, isolée du réseau, et restaurable rapidement. Pas votre assurance, pas votre pare-feu, pas la négociation. Une sauvegarde accessible depuis le même compte administrateur que la production sera chiffrée avec elle.
Ce que le RGPD vous impose réellement quand vous externalisez
Point de clarification, parce que la confusion est fréquente. Le RGPD n'impose pas d'héberger en France. Il encadre les transferts hors Union européenne et, surtout, il vous laisse la responsabilité du traitement même quand vous confiez l'infrastructure à un tiers.
Concrètement, votre hébergeur et votre prestataire de développement sont des sous-traitants au sens de l'article 28. La CNIL rappelle que la relation doit être encadrée par un contrat écrit précisant l'objet, la durée, la nature du traitement, les obligations de sécurité et le sort des données en fin de contrat (CNIL, travailler avec un sous-traitant). L'absence de ce document est en elle-même un manquement.
Cette dernière clause, le sort des données en fin de contrat, mérite votre attention. Elle est à la fois une obligation réglementaire et votre meilleure protection commerciale. Elle dit ce que vous récupérez, dans quel format, et sous quel délai. C'est exactement le sujet que je traite sous un autre angle dans l'article sur la reprise de données lors d'un changement de logiciel.
Hébergeur français, européen, ou peu importe ?
La réponse honnête dépend de la nature de vos données. Pour un logiciel de gestion interne sans données sensibles, un hébergeur établi dans l'Union européenne suffit à traiter la question réglementaire.
Deux cas changent la donne. Les données de santé imposent un hébergeur certifié HDS, sans discussion possible. Et si vous traitez des données dont la confidentialité est stratégique, sachez qu'un fournisseur soumis au droit américain peut se voir contraint de communiquer des données même stockées en Europe, ce qui pousse plusieurs organisations vers des hébergeurs de droit européen.
Mon avis pratique pour une PME française : un hébergeur français simplifie le support, la langue du contrat et la relation en cas d'incident. Ce n'est pas une obligation, c'est un confort qui a de la valeur le jour où quelque chose casse un vendredi soir.
Ce que j'ai appris en hébergeant mes propres logiciels
Pictogramaweb n'est pas seulement une agence qui livre des applications à des clients, j'édite mes propres logiciels métier. Simply Spa et Simply Resa pour la réservation, Geko pour la gestion de stock et de commandes, Postwa pour la publication, plus un outil de planification pour l'ophtalmologie que j'ai cédé. Cela veut dire que je porte moi-même, tous les jours, les conséquences de mes choix d'hébergement.
Deux enseignements, dont un qui ne me flatte pas. Le premier : la supervision compte plus que la puissance. Un incident détecté par un client est toujours plus coûteux qu'un incident détecté par une alerte, même quand la panne est identique. Le second, moins agréable à écrire : sur un de mes produits, j'ai laissé passer plusieurs mois sans tester de restauration complète, en me disant que les sauvegardes automatiques tournaient. Elles tournaient. Mais je ne le savais pas vraiment, je le supposais. Depuis, la restauration est un rituel planifié et non une bonne intention.
C'est aussi ce qui structure ma façon de travailler quand je conçois une application pour une entreprise, et c'est détaillé sur la page consacrée au développement de SaaS sur mesure.
Les questions à poser avant de signer
Si vous ne retenez qu'une chose de cet article, retenez cette liste. Elle tient en une page et elle vous évitera la majorité des mauvaises surprises.
- À quel nom sera ouvert le compte d'hébergement, et à quel nom le nom de domaine ?
- Où sont stockées les sauvegardes, à quelle fréquence, pendant combien de temps, et à quelle date a eu lieu la dernière restauration testée ?
- Quel est le délai d'intervention engagé en cas d'indisponibilité, et sur quelle plage horaire ?
- Que se passe-t-il si je change de prestataire : dans quel format et sous quel délai je récupère mon code, ma base de données et mes fichiers ?
- Qui applique les mises à jour de sécurité du serveur, et selon quelle fréquence ?
Ces questions relèvent du même contrat que l'évolution du logiciel dans le temps, sujet que je traite dans l'article sur la maintenance d'une application métier sur mesure.
Mon verdict
Pour la grande majorité des PME, l'hébergement d'un logiciel métier se joue sur un cloud européen managé, avec un compte ouvert au nom de l'entreprise cliente, des sauvegardes hors site dont la restauration est testée et datée, et une clause de réversibilité écrite. Le débat serveur dédié contre cloud public arrive loin derrière, et il se tranche par la stabilité de la charge, pas par principe.
Si vous cherchez un critère unique pour évaluer une proposition d'hébergement, prenez celui-ci : demandez la date de la dernière restauration testée. Une réponse précise vous dit tout de la rigueur de votre interlocuteur. Une réponse évasive aussi.
Si vous avez un projet de logiciel métier en cours ou une application existante dont l'hébergement vous inquiète, parlons-en. Un échange d'une demi-heure suffit généralement à identifier les deux ou trois points réellement fragiles de votre configuration actuelle.
Questions fréquentes
Mon prestataire peut-il héberger mon logiciel métier chez lui ?
Oui, et c'est fréquent. La question n'est pas de savoir si c'est possible mais ce que dit le contrat. Exigez que le transfert du compte à votre nom soit prévu à première demande, avec un délai chiffré, et que la restitution des données et du code soit décrite dans un format exploitable. Sans ces clauses, vous dépendez de la bonne volonté de votre prestataire le jour où vous voulez partir.
Le cloud est-il vraiment plus sûr qu'un serveur dans mes locaux ?
Sur la sécurité physique et la redondance, oui, sans comparaison possible. Un datacentre professionnel traite l'alimentation, la climatisation, l'accès physique et la connectivité comme son métier. En revanche, le cloud ne vous protège ni d'une mauvaise configuration, ni d'un accès administrateur compromis, ni d'une sauvegarde mal isolée. Le niveau de sécurité dépend davantage de la configuration que du lieu.
Que signifie une disponibilité garantie à 99,9 % ?
Un engagement à 99,9 % autorise environ 8 heures 45 minutes d'indisponibilité cumulée par an. À 99,99 %, la tolérance tombe sous l'heure. Vérifiez surtout ce que couvre l'engagement, car il porte généralement sur l'infrastructure de l'hébergeur et non sur votre application. Une panne applicative n'est presque jamais couverte par le SLA de l'hébergeur.
Combien de temps faut-il pour migrer un logiciel métier vers un nouvel hébergement ?
Cela dépend du volume de données et du nombre d'intégrations à reconnecter. Pour une application bien documentée, la migration technique se prépare en quelques jours et se bascule sur une plage creuse. Le point qui allonge toujours les délais, c'est l'inventaire des flux externes, connecteurs, API, envois de mails, que personne n'a listés depuis la mise en production.
Photo : Kevin Ache sur Unsplash
