Le cloud ou sur site, ce qui compte en termes de gestion d’entreprise

Voici la traduction française du contenu HTML, respectant toutes les règles spécifiées :

« `html

7 Min. de lecture

Le débat Cloud-On-Prem dure depuis quinze ans sur deux niveaux. Au niveau supérieur, les architectes discutent latence, scalabilité et microservices. Au niveau inférieur, la direction financière calcule discrètement pourquoi la facture AWS dépasse de 30 % le business case après trois ans. En 2026, le niveau supérieur disparaîtra de la plupart des décisions des PME. Il ne restera qu’une question de TCO avec trois ou quatre variables honnêtement calculées.

Associé :Les fusions-acquisitions échouent rarement à cause du prix  /  Migration S/4HANA : avant la décision

La question Cloud-On-Prem est une question de TCO, pas une question d’architecture

Les dirigeants de PME qui ont décidé d’une migration vers le Cloud au cours des douze derniers mois connaissent le schéma. Le business case initial prévoit des économies à deux chiffres sur 24 mois. Au bout de 36 mois, il ne reste souvent qu’un chiffre à un seul digit, parfois avec un signe inversé. Les remises des hyperscalers fondent, les frais de sortie deviennent visibles, la pile d’outils se multiplie.

L’hypothèse erronée la plus fréquente dans ces calculs est que la variable Cloud inclut également la variable Personnel. Ce n’est pas le cas. Une configuration Cloud moderne nécessite des ingénieurs Cloud, des responsables FinOps et des spécialistes de la sécurité, qui coûtent entre 95 000 et 140 000 euros brut par an en DACH en 2026. Une entreprise qui disposait historiquement de deux administrateurs système pour des configurations On-Prem a rarement besoin de moins de quatre personnes dans un modèle Cloud.

Les quatre courbes de coûts que personne ne calcule honnêtement

Un calcul TCO fiable distingue quatre courbes que les business cases standards ont tendance à fusionner en une seule. Ce mélange est la principale raison pour laquelle les décisions de migration se révèlent a posteriori être des erreurs de calcul.

1. Coûts d’acquisition. En on-premise, ils apparaissent en bloc, tandis que le cloud les étale sur la durée. Quiconque est soumis à des contraintes Capex (covenants bancaires, pression sur le budget d’investissement) privilégie structurellement le cloud, indépendamment de la stack.
2. Coûts de personnel. Le cloud ne réduit pas les charges des administrateurs système, il les transfère vers des rôles spécialisés avec un prix de marché plus élevé. Une équipe on-premise de trois personnes coûte moins cher qu’un ingénieur cloud, un ingénieur cloud backup et un responsable FinOps réunis.
3. Coûts de croissance. En cas de charge très imprévisible (saisonnalité, lancements de produits, pics de charge), le cloud est structurellement supérieur. En revanche, pour une charge stable et prévisible, la solution on-premise devient moins chère chaque année, car l’amortissement du matériel l’emporte sur les dépenses OpEx du cloud.
4. Coûts de sortie. La courbe la plus sous-estimée. Une migration vers le cloud est moins coûteuse qu’une sortie du cloud. Frais d’egress, efforts de refactoring pour les services propriétaires, nouvelles négociations de licences : une sortie d’un environnement AWS de 18 mois coûte 1,5 à 3 fois le coût de la migration. Cela n’est jamais intégré dans le business case.

Le temps : pourquoi l’expression « durée de migration de 18 mois » ne veut rien dire

Les délais de migration sont le chiffre le plus souvent détourné dans les discussions cloud vs on-premise. Une durée de migration de 18 mois peut signifier : 18 mois de mise en œuvre technique avec un environnement opérationnel à la fin, ou 18 mois d’exploitation parallèle avec des coûts de double licence qui explosent, suivis de 12 mois supplémentaires de stabilisation.

Dans les projets de migration que j’ai observés chez les PME du DACH, l’écart était rarement d’ordre technique. Il tenait presque toujours au portefeuille applicatif. Une entreprise qui migre 40 à 80 applications SaaS plus 15 applications custom historiques a un calendrier radicalement différent de celui d’une entreprise avec trois applications clés et un ERP.

Le chiffre honnête n’est pas la durée de migration, mais l’horizon de stabilisation. À partir de quand le nouvel environnement fonctionne-t-il sans intervention quotidienne des ingénieurs, sans nouveaux tickets, sans mauvaises surprises de performance ? Celui qui n’intègre pas ce chiffre dans sa matrice de décision compare des pommes avec des pommes plus chères.

Réglementation 2026 : NIS2 et DORA déplacent les lignes

Les arguments des hyperscalers ces dernières années reposaient sur la sécurité, la conformité et l’auditabilité. Dans trois secteurs, ce raisonnement sera fragilisé en 2026 : la banque, les infrastructures critiques et la santé.

NIS2 exige un contrôle vérifiable des chaînes d’approvisionnement et des audits d’accès. DORA impose aux institutions financières des tests d’intrusion pilotés par les menaces et des tests de reprise reproductibles. Les deux sont plus difficiles à mettre en œuvre dans le modèle des hyperscalers que dans des environnements on-premise avec une chaîne de propriété clairement documentée. Non pas parce que le cloud serait moins sûr, mais parce que la charge d’audit est répartie différemment.

Les tests de résistance DORA que les banques allemandes échouent actuellement sont un indicateur précoce. Celui qui répertorie un fournisseur cloud comme prestataire tiers critique doit satisfaire aux exigences ICT-TPRM, et celles-ci se sont durcies en 2026. Pour de nombreuses banques de taille moyenne, le retour à l’on-premise n’est pas un réflexe anti-cloud, mais une rationalité dictée par la conformité.

Trois questions que les dirigeants doivent se poser avant de trancher

Quiconque aborde honnêtement la question du cloud *on-prem* en 2026 ne peut faire l’impasse sur ces trois interrogations. Elles sont inconfortables, car elles sollicitent davantage la direction financière que la DSI.

1. À quel point ma charge est-elle prévisible pour les 36 prochains mois ? Avec 80 % de prévisibilité, il faut sérieusement envisager l’*on-prem* ou le *colocation*. Avec 50 % ou moins, le cloud reste structurellement plus adapté, car la vitesse d’adaptation justifie le surcoût.
2. Quelles obligations réglementaires m’attendent en 2027 et 2028 ? Ceux qui sont concernés par le CRA, NIS2, DORA ou des réglementations sectorielles doivent calculer explicitement les coûts de conformité dans les deux modèles. Dans les secteurs régulés, la prime cloud en 2026 n’est plus finançable pour beaucoup de PME, car l’auditabilité devient plus coûteuse que l’avantage des hyperscalers en matière de scalabilité.
3. Combien me coûtera une sortie après 24 mois si le modèle choisi échoue ? Ne pas pouvoir répondre à cette question signifie que la décision n’a pas été menée à son terme. Qu’il s’agisse d’une sortie du cloud ou d’un retour *on-prem*, les deux sont coûteux. Celui qui intègre la clause de sortie dans son business case prend une décision différente de celui qui ne calcule que le coût d’entrée.

Dans les comités de direction où ces trois questions ont été abordées avec franchise, le postulat *cloud-first* a souvent été remis en cause. Non pas pour des décisions anti-cloud, mais pour des architectures hybrides plus nuancées, avec des profils de charge clairement distincts.

Foire aux questions

Lire la suite

• Migration S/4HANA : les PME face à un choix décisif en 2026
• IA en comptabilité : 78 % d’écritures occultes dans les PME
• Les tests de résistance DORA que les banques allemandes échouent actuellement

Plus d’articles du réseau MBF Media

Source image à la une : Pexels