On premise — ce que ça signifie et quand votre propre serveur gagne face au cloud

L'on-premise est le modèle où une entreprise achète ses propres serveurs, les installe sur son propre site et les exploite elle-même — au lieu de louer de la puissance de calcul et des logiciels dans le cloud. Pendant une décennie, on nous a dit que ce modèle était en train de disparaître. Pourtant, en 2026, beaucoup d'entreprises se retrouvent face à cette question à nouveau : certaines parce que le support de leur serveur se termine, d'autres parce que leur facture cloud a augmenté plus vite que prévu.

Cet article ne prend parti pour aucun des deux camps. C'est une aide à la décision : ce que coûte réellement un serveur dans vos locaux, quand l'on-premise gagne, quand il perd, et s'il existe quelque chose entre les deux. Chaque chiffre a une source, et là où un chiffre dépend de votre propre entreprise, nous montrons comment le calculer plutôt que d'en inventer un. Ce que signifient concrètement l'IaaS, le PaaS et le SaaS est expliqué séparément dans notre article sur le cloud computing — ici, nous supposons que vous connaissez déjà ces notions.

On premise — ce que ça signifie

L'expression anglaise on premises (souvent raccourcie dans l'usage courant en on premise) signifie littéralement « sur place », dans les locaux propres de l'organisation. En informatique, cela désigne une infrastructure que l'organisation possède et exploite elle-même : le serveur se trouve dans son bâtiment, lui appartient, et les personnes responsables de son fonctionnement sont ses propres employés ou une société de service qu'elle a engagée directement.

Fait intéressant : les définitions les plus citées du secteur ne définissent pas ce terme de façon directe. La définition du cloud du NIST américain (SP 800-145) et la norme ISO/IEC 17788 n'utilisent l'expression « on or off premises » qu'à l'intérieur d'une autre définition — celle du cloud privé, qui selon le NIST « may exist on or off premises » — traduction libre : « peut se trouver dans les locaux de l'organisation ou en dehors » (NIST SP 800-145).

La description la plus utile vient d'IBM, qui met en regard l'on-premise et le cloud : « L'informatique sur site traditionnelle consiste pour les entreprises à posséder et à entretenir leurs propres centres de données et serveurs physiques pour associer puissance de calcul, stockage et autres ressources. » (IBM, qu'est-ce que le cloud computing ?). Deux verbes comptent ici : posséder et entretenir.

Cette définition révèle aussi la différence essentielle avec le cloud : en on-premise, toutes les couches — de l'électricité et de la climatisation, en passant par le matériel et le système d'exploitation, jusqu'à l'application et aux données — sont de votre côté. Dans le cloud, le fournisseur en reprend une partie. Dans quelle mesure exactement dépend du modèle, ce que détaille le schéma de notre article sur le cloud computing.

Le coût complet de votre propre serveur

La plupart des comparaisons « on premise contre cloud » se trompent de la même façon : d'un côté on inscrit le prix d'achat du matériel, de l'autre une facture mensuelle complète. Or le prix d'achat n'est que le premier des postes à calculer. En voici les autres.

Amortissement : comment un serveur se répercute sur vos coûts

Un serveur est une immobilisation, donc — sauf exceptions pour les biens de faible valeur — il entre dans vos coûts par amortissement, et non par une seule écriture. L'Administration fédérale des contributions (AFC) publie des taux d'amortissement standards pour les actifs des entreprises ; nous n'en citons pas ici — confirmez celui qui s'applique au matériel informatique avec votre fiduciaire avant de budgétiser. Ce qui reste vrai indépendamment du taux exact, c'est le mécanisme sous-jacent, et il compte pour toute comparaison avec le cloud : une facture cloud est un coût dès le premier jour, le coût d'un serveur est étalé sur plusieurs années.

Licence on premise : Windows Server et SQL Server

Le deuxième poste, souvent plus élevé que le matériel lui-même, ce sont les licences. L'exemple des logiciels Microsoft — un choix courant dans les salles serveurs des entreprises — montre comment fonctionne une licence on premise et pourquoi il est difficile de l'estimer « à l'œil ».

Windows Server 2025 est vendu sous licence par cœur de processeur, avec des seuils minimaux. Les règles de licence de Microsoft exigent « a minimum of 8 core licenses per physical processor and a minimum of 16 core licenses per server » — traduction libre : « un minimum de 8 licences cœur par processeur physique et un minimum de 16 licences cœur par serveur » (Microsoft Licensing, Windows Server 2025). S'ajoutent les licences d'accès : « Each user or device that accesses licensed servers requires a Windows Server CAL » — traduction libre : « chaque utilisateur ou appareil qui accède à des serveurs sous licence nécessite une licence CAL Windows Server ».

Microsoft ne publie des prix catalogue que sur sa page américaine, en dollars ; les pages suisses (fr-ch) et les autres pages non américaines montrent le même tableau des éditions, sans aucun prix. Cela nous apprend déjà quelque chose : il n'existe pas de prix catalogue en francs pour Windows Server, et ce que vous payez dépend de votre revendeur. Ce qui ne change pas selon le marché, c'est le mécanisme de licence : la différence entre les éditions porte sur la virtualisation — Standard donne le droit d'exécuter deux environnements de système d'exploitation (physiques ou virtuels), Datacenter un nombre illimité. Si vous prévoyez plusieurs machines virtuelles sur un même serveur, cette distinction détermine le coût. Il existe aussi une option de facturation à l'usage, au cœur et par mois.

SQL Server 2022, si votre application en dépend, a ses propres règles : une licence par cœur exige « a minimum of four Licenses per Physical Processor » — traduction libre : « un minimum de quatre licences par processeur physique » (Microsoft Licensing, SQL Server), et le modèle moins coûteux « serveur + CAL » n'est disponible que pour l'édition Standard. Là encore, aucun prix catalogue en francs n'existe — seule la page américaine en affiche un.

Nous n'additionnons pas ces montants en un « serveur type », car le résultat dépend du nombre de cœurs, d'utilisateurs et de machines virtuelles prévus. Une règle à retenir : avec une licence par cœur, un processeur plus puissant acheté « par précaution » augmente aussi la facture logicielle.

Service : ce que vous achetez vraiment dans un contrat de maintenance

Un serveur tombe en panne, et la question est de savoir à quelle vitesse quelqu'un le réparera. Les fabricants vendent cela comme un service séparé. La description du service ProSupport for Infrastructure de Dell (version 17, juillet 2026) distingue deux variantes principales. Dans la variante 4 heures, « a technician typically arrives on-site within 4 hours after completion of troubleshooting and isolating the issue » — traduction libre : « un technicien arrive généralement sur site dans les 4 heures suivant la fin du diagnostic et l'identification du problème ». Dans la variante jour ouvré suivant, un technicien est envoyé pour arriver généralement le jour ouvré suivant (Dell ProSupport for Infrastructure, description du service).

Trois points de ce texte méritent une lecture attentive. D'abord, le délai de 4 heures démarre après le diagnostic, pas après votre signalement. Ensuite, le mot « généralement » (typically) n'est pas une garantie. Enfin, en Europe, le service sur site est disponible dans un rayon allant jusqu'à 150 km du site logistique Dell le plus proche, et pour les pièces non standards, Dell bascule par défaut sur le jour ouvré suivant. Si votre entreprise est éloignée d'une grande ville, vérifiez ce point avant d'acheter.

Électricité, place et personnel

Trois derniers postes n'ont pas de prix universel, mais on ne peut pas les ignorer.

• Électricité et refroidissement. Un serveur fonctionne en continu, et la pièce où il se trouve nécessite généralement une climatisation, qui consomme elle aussi de l'électricité. La puissance nominale de votre serveur, multipliée par les heures et votre tarif électrique, donne un coût annuel.
• Place et alimentation de secours. Une pièce dédiée, un onduleur (UPS) dont les batteries doivent être remplacées régulièrement, un contrôle d'accès.
• Personnel. Quelqu'un doit installer les mises à jour, surveiller les sauvegardes et réagir aux incidents — y compris le week-end. C'est soit un poste (ou une fraction de poste), soit un contrat avec une entreprise externe. Dans les deux cas, c'est un coût fixe, indépendant du fait que quelque chose se soit effectivement cassé ce mois-là.

Le cloud ne supprime pas entièrement ce travail, mais dans les modèles PaaS et SaaS, il en reprend une grande partie.

L'échéance qui va forcer la décision : Windows Server 2016

Pour beaucoup d'entreprises, « on-premise ou cloud » n'est pas une question théorique — elle a une date précise. Le support étendu de Windows Server 2016 se termine le 12 janvier 2027 (Microsoft Lifecycle, Windows Server 2016). C'est la dernière étape du cycle de vie du produit durant laquelle Microsoft publie encore des correctifs de sécurité dans le cadre de son support ordinaire. Un serveur qui continue de fonctionner avec ce système après cette date ne reçoit plus de correctifs pour les nouvelles vulnérabilités découvertes, dans le cadre de ce programme de support.

À titre de comparaison : Windows Server 2025 bénéficie d'un support standard jusqu'au 13 novembre 2029 et d'un support étendu jusqu'au 14 novembre 2034 (Microsoft Lifecycle, Windows Server 2025). Acheter aujourd'hui une licence pour le nouveau système, c'est donc acheter environ huit ans de support.

Un serveur acheté avec ce système sera alors en service depuis près de dix ans. Une entreprise a trois options : mettre à jour le système sur le matériel actuel (si le matériel et les licences le permettent), acheter un nouveau serveur avec le nouveau système, ou déplacer la charge ailleurs. Si et à quelles conditions on peut acheter des mises à jour étendues pour un système plus ancien, c'est à vérifier auprès de Microsoft ou de votre revendeur de licences — de toute façon, cela ne fait que reporter l'échéance.

Quand l'on-premise gagne

Une charge stable, importante et prévisible. Le cloud facture à l'usage, ce qui est un avantage en cas de variations de la demande et un inconvénient en cas de charge stable : vous payez la marge du fournisseur pour une flexibilité que vous n'utilisez pas. Plus l'échelle est grande et stable, plus ce coût devient visible.

Des exigences sur le lieu de stockage des données. Quand un contrat, une règle sectorielle ou une politique d'entreprise exige que les données restent physiquement à un endroit précis, votre propre serveur donne une certitude sans avoir à la négocier avec un fournisseur.

Aucune dépendance à un seul fournisseur. Votre propre matériel ne changera pas sa grille tarifaire du jour au lendemain et n'arrêtera pas un service dont dépend votre système.

L'exemple le plus cité du premier cas est 37signals, l'entreprise derrière Basecamp et le service de messagerie HEY. Voici les chiffres publiés par l'entreprise elle-même, dans des billets du cofondateur David Heinemeier Hansson :

• Février 2023 : « We spent $3.2m on cloud in 2022 » — traduction libre : « Nous avons dépensé 3,2 millions de dollars en cloud en 2022 » —, dont environ 1 million pour le stockage de fichiers S3. Le plan prévoyait l'achat de matériel « in the region of $600,000 » (environ 600 000 dollars), amorti « over a conservative five years » (sur cinq ans, de façon prudente), pour économiser 7 millions de dollars en cinq ans sans agrandir l'équipe d'exploitation (DHH, 21.02.2023) ;
• Septembre 2023 : les dépenses cloud hors S3 sont passées d'environ 180 000 à moins de 80 000 dollars par mois, et « our ops team stayed the same » — traduction libre : « notre équipe d'exploitation est restée la même » (DHH, 15.09.2023) ;
• Octobre 2024 : depuis les 3,2 millions de dollars par an initiaux jusqu'à 1,3 million en 2024, avec environ 700 000 dollars de matériel Dell ; la prévision d'économies était désormais « well over ten million dollars over five years » — traduction libre : « largement plus de dix millions de dollars sur cinq ans » (DHH, 17.10.2024) ;
• Mars 2025 : le dernier élément était S3, pour lequel l'entreprise dépensait « just shy of $1.5 million/year » (un peu moins de 1,5 million de dollars par an) ; il devait être remplacé par une baie Pure Storage de 18 Po pour environ 1,5 million de dollars, plus un peu moins d'un million pour le service sur cinq ans (DHH, 26.03.2025). La migration elle-même a été décrite en janvier 2026 par l'ingénieur de l'entreprise Jeremy Daer : les données ont été déplacées en moins de 10 jours et « there was no downtime » — traduction libre : « il n'y a eu aucune interruption de service » (37signals, 08.01.2026).

Deux réserves s'imposent ici. D'abord, ce sont des chiffres publiés par l'entreprise elle-même, qui fait publiquement la promotion de sa sortie du cloud — ce n'est pas un audit. Même le volume de données déplacées varie selon les billets : « almost 10 petabytes » en 2024, « nearly 6 PB » en 2025, « five petabytes » dans le récit de migration de 2026. Ensuite, et c'est plus important : c'est une entreprise qui dépense des millions de dollars par an en infrastructure, avec sa propre équipe d'exploitation qui existait déjà. À l'échelle d'une petite entreprise, l'économie peut être plus faible que le coût de la personne qui devrait s'occuper du matériel. L'exemple de 37signals donne une méthode — compter les deux côtés honnêtement — pas une conclusion selon laquelle tout le monde devrait quitter le cloud.

Quand l'on-premise perd

Une charge variable. Un serveur est acheté pour le pic. Si le pic dure deux semaines par an — une saison commerciale, une clôture comptable de fin d'année — le matériel reste largement inactif le reste du temps, tout en continuant de s'amortir, de consommer de l'électricité et de nécessiter un service.

Aucun administrateur. C'est la raison la plus fréquente pour laquelle un serveur on-premise dans une petite entreprise devient un risque. Un serveur sans mises à jour, avec une sauvegarde que personne n'a jamais essayé de restaurer, fonctionne bien — jusqu'à la première panne de disque ou la première attaque.

Sauvegardes et site de repli. Une sauvegarde conservée dans le même bâtiment que le serveur ne protège ni contre un incendie, ni contre une inondation, ni contre un vol. Un deuxième site est un coût supplémentaire et une chose de plus à entretenir ; de nombreux services cloud l'intègrent d'office. Comment construire un système de sauvegarde raisonnable est expliqué dans notre article sur la sauvegarde et la reprise après incident.

Les histoires très médiatisées de « sortie du cloud » suggèrent une tendance massive, mais les analystes sont plus prudents. Selon IDC, « only 8-9% of companies plan full workload repatriation » — traduction libre : « seulement 8 à 9 % des entreprises prévoient un rapatriement complet de leurs charges de travail » (blog IDC, D. Saroff, 28.10.2024, sur la base de son enquête Server and Storage Workloads Survey). C'est le résultat d'une enquête, pas un recensement, et cela porte sur des intentions, pas sur des migrations réalisées. Cela montre néanmoins qu'un retour complet dans sa propre salle serveur est l'exception — les entreprises ramènent plus souvent des systèmes ciblés et laissent le reste dans le cloud.

La troisième voie : VPS et auto-hébergement

La conversation « on premise contre cloud » laisse souvent de côté la voie intermédiaire qui, pour beaucoup de petites et moyennes entreprises, est la plus raisonnable : un serveur privé virtuel (VPS) loué chez un hébergeur, sur lequel l'entreprise fait tourner elle-même ses applications. Le matériel, l'électricité, la connectivité et la sécurité physique appartiennent au fournisseur — pas besoin d'acheter un serveur, une climatisation ou un contrat de service. Mais le système d'exploitation, les mises à jour, les sauvegardes et tout ce qui tourne dessus restent de votre côté, comme en on-premise.

Formellement, c'est de l'IaaS, l'un des modèles du cloud ; en pratique, la responsabilité ressemble à celle d'un serveur propre. Ce site fonctionne justement de cette manière. Nous avons comparé la facture pour notre propre pile technique (Next.js et Payload CMS, une équipe de trois personnes, 2 To de transfert mensuel, grilles des fournisseurs relevées le 5 octobre 2026, hors TVA) : une plateforme gérée — Vercel avec une base de données MongoDB Atlas — coûte environ 271 USD par mois, tandis qu'un VPS Hetzner CPX32 (4 vCPU, 8 Go de RAM, 160 Go NVMe) avec Coolify coûte 35,99 EUR par mois, adresse IPv4 comprise (grille Hetzner Cloud ; le CPX31 que nous comptions auparavant n'est plus proposé que dans les sites américains). La facture complète et les hypothèses qui la sous-tendent se trouvent dans notre article sur l'auto-hébergement de Next.js et Payload.

C'est un écart important, mais l'honnêteté impose de montrer l'autre côté. Après le passage à notre propre serveur, nous avons dû reprendre nous-mêmes les sauvegardes, les correctifs de sécurité et la surveillance de disponibilité. Et nous avons connu trois incidents de production qu'une plateforme gérée n'aurait pas connus :

1. Mémoire et fichiers perdus. Le traitement des images consommait tellement de mémoire que le système tuait le processus de l'application. Nous avons aussi découvert qu'une collection de fichiers n'avait pas de volume persistant configuré — 11 fichiers téléversés ont disparu après le redémarrage du conteneur.
2. Un disque plein. Le cache des pages générées est monté à 89 Go parce que des robots demandaient sans cesse des adresses inexistantes, et chaque réponse était enregistrée comme fichier.
3. Une compilation a privé la base de données de ressources. La compilation d'une nouvelle version de l'application sur le même serveur prenait les ressources dont la base de données avait besoin. La solution : compiler sur un système CI externe, plus 4 Go de mémoire d'échange (swap).

Les trois incidents viennent de la même chose : sur votre propre serveur, chaque couche au-dessus du matériel vous appartient. La conversion honnête est la suivante : deux heures de maintenance par mois, multipliées par le tarif en francs que paie réellement un employeur ici, doivent être soustraites de l'écart d'abonnement avant que ce qui reste puisse être appelé une économie. L'auto-hébergement est rentable quand ces heures sont déjà dans l'équipe de toute façon et couvrent plusieurs projets à la fois, pas un seul. Comment détecter des interruptions que personne ne remarquerait autrement est expliqué dans notre article sur le monitoring de site.

Les entreprises suisses et le cloud — ce que les données ne disent pas

L'enquête d'Eurostat sur l'usage du cloud par les entreprises (isoc_cicce_use) couvre les États membres de l'UE et ne comporte pas de ligne pour la Suisse, et nous n'avons trouvé aucune enquête suisse récente qui mesure l'usage payant du cloud de la même manière. Nous ne donnons donc pas de chiffre ici.

Ce que nous pouvons décrire, c'est le mécanisme : l'e-mail, le partage de fichiers et la suite bureautique sont les charges les plus faciles à acheter sous forme de service cloud prêt à l'emploi, alors que les bases de données et les applications sur mesure demandent plus de préparation pour migrer. Où ces charges tournent réellement — on-premise, sur un VPS ou chez un éditeur de logiciel —, aucune enquête suisse actuelle ne le dit. Plus d'informations sur les modèles de service cloud eux-mêmes dans notre article sur le cloud computing.

Comment décider : on-premise, VPS ou cloud

Commencez par les questions, puis calculez.

Les questions qui réduisent le choix

1. La charge est-elle stable ou variable ? Stable et importante favorise votre propre infrastructure ou un VPS ; variable favorise le cloud facturé à l'usage.
2. Avez-vous quelqu'un pour entretenir un serveur ? Une personne ou une entreprise avec un périmètre défini : mises à jour, sauvegardes, réaction aux incidents. Sans cela, l'on-premise et le VPS sont un risque, pas une économie.
3. Les données doivent-elles rester à un endroit précis ? Si oui, vérifiez si une région suisse ou européenne d'un fournisseur cloud satisfait l'exigence, ou si cela nécessite réellement un serveur dans vos propres locaux. Ce qui reste de votre côté dans le cloud est expliqué dans notre article sur la sécurité des données dans le cloud.
4. Combien coûte une heure d'interruption, et qui la répare ? Côté on-premise, la réponse vient de votre contrat de service et de votre administrateur ; côté cloud, du SLA du fournisseur — à lire attentivement pour comprendre ce qu'il garantit réellement. Le calculateur de coût de maintenance peut aider à estimer le coût de l'interruption elle-même.
5. Quel logiciel doit tourner ? Une application qui nécessite Windows Server et SQL Server implique des licences quel que soit l'emplacement — dans le cloud, vous les payez aussi, simplement intégrées dans l'abonnement.
6. Quelle échéance vous poursuit ? La fin du support d'un système, la fin d'un contrat fournisseur, la fin d'une garantie matérielle.

Le calcul sur cinq ans : comment le faire

Si deux ou trois options restent après ces questions, comparez-les sur un horizon de cinq ans — la durée (« conservative five years », cinq ans par prudence) sur laquelle 37signals a amorti son matériel. Les montants dépendent de votre propre entreprise, voici donc les postes à inscrire dans un tableau.

Côté on-premise :

• achat du matériel (serveur, stockage, réseau, UPS) — étalé selon votre taux d'amortissement, confirmé avec votre fiduciaire ;
• licences du système et des bases de données — en tenant compte des minimums de cœurs et d'une licence CAL par utilisateur ou appareil ;
• un contrat de service du fabricant pour toute la période (pas seulement la durée de garantie) ;
• électricité et refroidissement — puissance multipliée par les heures et par votre tarif ;
• temps de l'administrateur — heures par mois multipliées par le taux, même s'il s'agit de votre propre employé ;
• sauvegardes sur un site externe ;
• remplacement du matériel ou du système avant la fin de la période, si une échéance de support tombe à l'intérieur.

Côté cloud ou VPS :

• abonnement ou usage — avec une croissance réaliste, pas la facture d'aujourd'hui multipliée par 60 ;
• transfert et stockage de données — des postes qui tendent à croître plus vite que le reste ;
• licences, si elles ne sont pas incluses dans le service ;
• travail administratif qui reste de votre côté — comparable à l'on-premise pour un VPS, minimal pour le SaaS ;
• le coût d'une éventuelle migration en quittant le fournisseur.

Deux règles : comptez le temps des personnes des deux côtés, y compris un employé « déjà sur la fiche de paie de toute façon », et testez un scénario pessimiste — plus de trafic, une panne en année trois. Une option qui ne gagne que dans le scénario optimiste ne gagne pas.

Si ce calcul exige des connaissances sur vos systèmes que vous n'avez pas sous la main, c'est exactement le cas pour le conseil technologique : un regard extérieur sur ce que l'entreprise possède, ce que cela coûte, et ce qui vaut la peine d'être déplacé avant qu'une échéance ou une panne n'impose la décision.

Et ensuite

Ce que sont les modèles de service cloud et ce que montrent réellement les données sur le cloud computing est expliqué dans notre article sur le cloud computing. Le modèle du logiciel en tant que service lui-même est expliqué dans notre guide du SaaS, et si vous hésitez entre un logiciel prêt à l'emploi et un développement sur mesure, voyez notre article sur le logiciel sur mesure.