Pour une application critique, le cloud privé est le plus souvent le bon point de départ : un ERP, un AS400 ou un logiciel métier dont l’arrêt bloque la facturation a besoin de ressources dédiées, d’une latence maîtrisée et d’un plan de reprise testé. Le cloud public mutualisé garde sa place pour les charges variables et les services standard. La décision se prend sur quatre critères : la plateforme technique, l’emplacement des données et le droit qui s’y applique, les objectifs de reprise après incident, et la réversibilité du contrat.
Quel modèle retenir pour une application critique ?
Une application est critique quand son arrêt bloque l’activité : saisie des commandes, production, paie, comptabilité. Pour ces charges, la décision ne porte pas sur le prix horaire d’une machine virtuelle. Elle porte sur ce que coûte une journée d’interruption et sur la maîtrise que vous gardez sur vos données.
Ce que le cloud public mutualisé fait bien
Les hyperscalers louent des ressources à la demande, facturées à l’usage, sur une infrastructure partagée entre de nombreux clients. Ce modèle convient aux charges qui varient fortement : un site marchand en période de soldes, un environnement de test monté pour quelques semaines.
Il convient moins à un ERP dont la charge bouge peu d’un mois à l’autre. Vous payez alors une souplesse dont vous ne vous servez pas, et les performances dépendent d’une infrastructure partagée dont vous ne fixez ni les fenêtres de maintenance ni l’emplacement exact.
Ce qu’un environnement dédié change pour un ERP ou un AS400
Dans un cloud privé, les serveurs, le stockage et le réseau sont réservés à une seule entreprise. Vous connaissez le datacenter qui héberge vos applications, vous fixez avec le prestataire les fenêtres d’intervention, et les performances de votre ERP ne dépendent pas de la charge des autres clients.
Pour un ERP ou un AS400 qui ne doit pas s’arrêter, ce cadre est souvent le plus simple à défendre devant une direction générale. Une solution de cloud privé pour les entreprises comme celle d’UltraNova repose sur ce principe : des ressources matérielles et logicielles allouées exclusivement à votre entreprise, hébergées dans des datacenters situés en France.
Le prestataire y ajoute la redondance, les sauvegardes automatisées, le PRA et le PCA, ainsi qu’une supervision continue, avec des équipes de support francophones basées en France. Ses architectures hybrides relient aussi des applications restées en local ou dans un autre cloud (ERP, AS400, logiciels métier) à l’environnement privé, et la migration se prépare pour éviter toute rupture de service.
Pourquoi l’AS400 complique-t-il le passage au cloud public ?
Déplacer un AS400 demande de comprendre sur quoi il tourne.
IBM i tourne sur des serveurs IBM Power
Le système d’exploitation des AS400 s’appelle aujourd’hui IBM i, et il s’exécute sur les serveurs IBM Power. Ces machines n’utilisent pas l’architecture x86 des serveurs qui font tourner les machines virtuelles Windows et Linux : une application IBM i ne se déplace donc pas sur une machine virtuelle standard.
IBM décrit trois façons de faire tourner IBM i : dans vos locaux, dans un cloud privé installé sur site, ou sur des serveurs Power virtualisés en cloud public. Dans tous les cas, l’hébergeur doit disposer de matériel Power et d’équipes qui connaissent ce système. Externaliser l’AS400 tel quel dans un environnement dédié évite souvent de réécrire des applications métier qui fonctionnent.
La latence entre l’ERP et ses outils satellites
Un ERP échange en permanence avec d’autres logiciels : gestion d’entrepôt, paie, pilotage de la production, échanges de données informatisés avec vos clients. Si l’ERP part dans un cloud et que ses satellites restent dans vos locaux, chaque échange traverse un réseau plus long. Un délai minime par requête, répété sur des milliers de requêtes lors d’un traitement de nuit, allonge la durée totale du traitement.
Avant de déplacer une application, cartographiez ses flux : quels logiciels l’appellent, à quelle fréquence, avec quel volume de données. Cette cartographie indique quelles briques doivent rester proches les unes des autres.
Où sont vos données, et quel droit s’y applique ?
La souveraineté des données tient à deux éléments : l’endroit où elles sont stockées et le droit auquel est soumis le prestataire qui les gère. Un datacenter en France règle le premier point, pas toujours le second.
Le Cloud Act et l’article 48 du RGPD
Le Cloud Act, loi américaine de 2018, permet aux autorités des États-Unis d’exiger d’un fournisseur américain les données qu’il détient, y compris quand elles sont stockées sur des serveurs situés hors des États-Unis.
Le RGPD encadre ce cas dans son chapitre consacré aux transferts de données hors de l’Union européenne.
Article 48 du RGPD : la décision d'un tribunal ou d'une autorité d'un pays tiers exigeant la communication de données personnelles n'est reconnue que si elle repose sur un accord international, par exemple un traité d'entraide judiciaire.
Pour une PME, ce conflit de textes se résume à une demande simple à adresser à chaque hébergeur : à quel droit sa société mère est-elle soumise, et qui peut accéder à vos données en cas de réquisition ?
Les référentiels à demander à votre hébergeur
Plusieurs référentiels permettent de vérifier les engagements d’un prestataire, quel qu’il soit. Demandez les attestations à jour avec leur périmètre exact, car une certification peut ne couvrir qu’une partie des services ou des sites :
- SecNumCloud : qualification délivrée par l’ANSSI à des offres cloud de confiance, qui visent à protéger les données sensibles face à la menace cybercriminelle et à l’application de lois extraterritoriales.
- HDS : certification exigée pour héberger des données de santé à caractère personnel pour le compte de tiers.
- ISO/IEC 27001 : norme internationale de management de la sécurité de l’information ; vérifiez quels sites et quelles activités le certificat couvre.
Les recommandations de l’ANSSI pour l’hébergement des systèmes d’information sensibles dans le cloud, publiées en juillet 2024 dans la lignée de la doctrine Cloud au centre de l’État, précisent les cas où une solution qualifiée SecNumCloud est préconisée. Une PME privée n’y est pas tenue, mais cette grille vous aide à classer vos propres données par niveau de sensibilité.
Comment dimensionner votre PRA et votre PCA ?
Le plan de reprise d’activité (PRA) décrit comment redémarrer après un sinistre. Le plan de continuité d’activité (PCA) vise à ce que l’activité ne s’interrompe pas, grâce à une infrastructure doublée qui prend le relais. Les deux se chiffrent à partir de deux objectifs que la direction doit fixer, et pas l’équipe technique seule.
RPO et RTO, deux chiffres à fixer avant de comparer les hébergeurs
Le RPO (Recovery Point Objective) est la quantité de données que vous acceptez de perdre, exprimée en durée : avec une seule sauvegarde par nuit, un incident en fin de journée efface tout ce qui a été saisi depuis la veille. Le RTO (Recovery Time Objective) est la durée d’interruption acceptable avant que l’application soit de nouveau utilisable.
Plus ces deux valeurs sont courtes, plus l’architecture coûte cher. Un RPO proche de zéro impose une réplication en continu vers un second site, un RTO de quelques minutes impose des serveurs de secours déjà démarrés. Fixez-les application par application : la paie tolère souvent plus d’attente que la prise de commandes.
Sauvegarde, test de reprise et réversibilité
Une sauvegarde ne suffit pas à faire un PRA. Faites inscrire trois points dans le contrat :
- une copie conservée sur un site distinct de la production ;
- des tests de restauration planifiés, avec leur fréquence ;
- le compte rendu écrit de chaque test, avec la durée de reprise mesurée.
Une sauvegarde qui n'a jamais été restaurée ne prouve rien : seul un test de reprise mesure le RTO réel de votre ERP.
La réversibilité demande la même rigueur : le contrat doit préciser dans quel format vos données vous sont rendues, dans quel délai et à quel coût si vous changez de prestataire. Consignez RPO, RTO, flux applicatifs et conditions de sortie dans un cahier des charges fonctionnel avant de consulter les hébergeurs : leurs réponses deviennent comparables point par point.
Faut-il tout héberger au même endroit ?
Rarement. L’architecture hybride répartit les applications selon leur profil : les briques critiques et stables dans un environnement dédié, les services standard ou très variables dans un cloud public mutualisé. Voici une répartition possible pour une PME :
| Application | Hébergement possible |
|---|---|
| ERP et bases de données de production | Environnement dédié |
| AS400 (IBM i) | Environnement dédié sur serveurs Power |
| Logiciels métier développés en interne | Environnement dédié, près de l’ERP |
| Messagerie et outils collaboratifs | Cloud public mutualisé |
| Site web et environnements de test | Cloud public mutualisé |
Entre les deux, un lien réseau sécurisé et des flux documentés permettent à l’ERP de continuer à échanger avec ses satellites.
Revoyez cette répartition à chaque renouvellement de contrat. Partez du coût d’une journée d’arrêt pour chaque application, puis retenez l’hébergement qui ramène ce risque à un niveau que votre direction accepte.