SaaS, IaaS, PaaS : quel modèle d'hébergement choisir

Quatre modèles d’hébergement se partagent le marché du logiciel d’entreprise : SaaS, IaaS, PaaS et installation sur site. Ils déplacent tous le même curseur, celui de l’administration que vous confiez à un tiers, du rack physique jusqu’au simple compte utilisateur. Le choix se joue sur quatre conséquences : coût, compétences internes, sécurité et sortie de contrat.

SaaS, IaaS, PaaS et serveur interne : le même curseur

La différence entre ces quatre formules ne tient ni à la technologie employée ni au montant facturé. Elle tient à la frontière que le contrat trace entre ce que le prestataire administre et ce qui reste à votre charge. Poussez cette frontière vers le haut de la pile technique, et les quatre modèles apparaissent dans l’ordre.

• Hébergement sur site, ou on-premise : machine, système et logiciel vivent chez vous, sous votre responsabilité entière.
• Infrastructure as a Service : vous louez puissance de calcul, stockage et réseau, puis installez tout le reste.
• Platform as a Service : vous louez un environnement prêt à exécuter votre application, sans toucher au système.
• Software as a Service : vous louez un logiciel terminé, accessible par navigateur, paramétrable mais non modifiable.

Ce que le mot cloud recouvre vraiment

Le terme sert d’étiquette commerciale à des réalités très différentes. Un éditeur qui annonce une bascule vers le cloud a parfois simplement déplacé son installation classique chez un hébergeur, avec une instance dédiée par client et une facturation annuelle. Vu du navigateur, le résultat ressemble à un service cloud, mais les mises à jour, la disponibilité et les sauvegardes suivent encore les règles d’un contrat d’hébergement traditionnel.

Cette confusion se dissipe en lisant les mots du contrat plutôt que ceux de la plaquette. Niveau de service, réversibilité, tenant, hébergement mutualisé ou dédié : chacun désigne un engagement précis, et un terme mal compris se paie à la signature. Le média numeora.fr, qui couvre l’intelligence artificielle, la cybersécurité, le cloud et la facturation électronique pour les TPE et PME, publie un Lexique du numérique professionnel où ces définitions sont reprises une à une. Vérifier un terme prend quelques minutes, un contrat mal calibré vous engage pour trois ans.

L’axe d’abstraction, du rack au navigateur

Le National Institute of Standards and Technology, dans sa publication SP 800-145 de septembre 2011, décrit l’informatique en nuage par cinq caractéristiques essentielles, trois modèles de service et quatre modèles de déploiement. Ce texte reste la base commune des définitions employées par les fournisseurs. Ces cinq caractéristiques se lisent comme une grille de vérification :

• le libre-service à la demande, sans intervention humaine du fournisseur ;
• l’accès large par le réseau, depuis des terminaux variés ;
• la mutualisation des ressources entre plusieurs clients ;
• l’élasticité rapide, à la hausse comme à la baisse ;
• la mesure du service consommé, facturée à l’usage.

Une offre qui ne coche que deux de ces cinq points reste un hébergement classique repeint. La mutualisation repose sur des mécanismes déjà présents en interne : un hyperviseur découpe un serveur physique en machines virtuelles, un conteneur isole une application sans dupliquer le système. Ces techniques structurent autant une salle serveurs d’entreprise qu’un centre de données, comme le détaille notre article sur la virtualisation de serveurs en PME.

Qui administre quoi, couche par couche

Une application d’entreprise empile six couches, du béton de la salle machine jusqu’aux comptes utilisateurs. Le modèle retenu décide de l’étage auquel la responsabilité change de main.

Lue de haut en bas, cette grille explique presque tous les arbitrages entre modèles d’hébergement. Chaque ligne déléguée retire une compétence à recruter et une astreinte à organiser, contre une marge de manœuvre en moins.

La couche que personne ne délègue jamais

La dernière ligne ne change jamais de colonne. Quatre responsabilités vous suivent quel que soit le contrat signé :

• l’exactitude et la pertinence des données saisies ;
• l’attribution des droits d’accès et leur revue régulière ;
• le paramétrage fonctionnel, qui porte souvent l’essentiel de votre métier ;
• la décision de ce qui est stocké, et surtout de ce qui ne devrait pas l’être.

Un compte administrateur laissé actif après un départ produit le même incident, que le logiciel tourne sur un serveur de votre couloir ou dans un centre de données à huit cents kilomètres.

Ce que chaque modèle exige de votre équipe

Le vrai coût se mesure en compétences disponibles. Un contrat qui suppose un administrateur système, dans une entreprise qui n’en a pas, produit un système à l’abandon.

IaaS : louer la machine, garder les mains dans le système

Une offre IaaS livre des ressources brutes : machines virtuelles, volumes de stockage, réseau privé, pare-feu. Tout ce qui tourne dessus vous appartient, avec les charges qui vont avec.

• l’installation et la mise à jour du système d’exploitation ;
• l’application des correctifs de sécurité, dans des délais tenables ;
• la sauvegarde, sa restauration testée, sa durée de rétention ;
• la supervision de la charge et le dimensionnement des ressources.

Ce modèle se justifie quand une application ancienne refuse de bouger, quand un pic saisonnier rend l’achat de matériel absurde, ou quand un environnement de test doit vivre trois semaines. La facturation à l’heure récompense la discipline : une machine oubliée six mois coûte plus cher qu’un serveur acheté.

PaaS : livrer une application sans administrer de serveur

Un cran plus haut, le PaaS absorbe la couche que l’IaaS vous laissait. Le fournisseur maintient le système, l’environnement d’exécution, la base de données managée, parfois la chaîne de déploiement. Votre équipe dépose du code et une configuration, rien de plus.

• gain immédiat sur les délais de mise en production ;
• disparition de l’astreinte système et des fenêtres de maintenance ;
• versions de langage et de bibliothèques imposées par la plateforme ;
• architecture qui finit par épouser des services propriétaires.

Ce modèle concerne les entreprises qui font développer un outil, rarement celles qui achètent des logiciels du commerce.

SaaS : payer un service, administrer un compte

Dans les faits, le SaaS domine les usages, au point que beaucoup de dirigeants en consomment sans avoir jamais tranché la question. Messagerie, suite bureautique, stockage de fichiers, facturation, gestion commerciale, paie, signature électronique : la liste couvre la quasi-totalité des fonctions support d’une PME.

D’après Eurostat, 52,7 % des entreprises de l’Union européenne utilisaient des services cloud payants en 2025, contre 17,8 % en 2014. La messagerie arrive en tête avec 85,2 % des entreprises concernées, devant les suites bureautiques à 71,7 % et le stockage de fichiers à 71,5 %. La France signe l’une des plus fortes progressions du continent entre 2023 et 2025, avec 13,7 points gagnés selon la même source.

Trois charges subsistent malgré l’apparente simplicité :

• les comptes et leurs droits, revus au fil des départs ;
• les connexions avec vos autres outils, qui cassent à chaque évolution ;
• les changements d’interface décidés par l’éditeur.

Le serveur interne, quand garder la machine se défend encore

Loin d’avoir disparu, l’hébergement sur site s’est spécialisé. Quatre situations le justifient toujours.

• Une machine-outil ou un instrument de mesure exigeant une latence locale.
• Un volume de données lourd et peu mobile, dont le transfert récurrent coûterait davantage que le stockage.
• Une contrainte de localisation imposée par un client, un donneur d’ordre ou un assureur.
• Un logiciel métier ancien, sans version en ligne, dont la migration dépasse le budget.

L’addition dépasse largement le prix du serveur : onduleur, refroidissement, second exemplaire pour la reprise, licences système, temps d’administration, et la nuit où quelqu’un devra se déplacer. Le suivi rejoint la discipline de l’inventaire des licences logicielles, obligatoire quel que soit le lieu d’exécution.

Abonnement ou licence perpétuelle : où part l’argent

Deux logiques s’opposent, et la comparaison n’a de sens que sur une durée identique. Une licence perpétuelle s’achète une fois, s’immobilise à l’actif, puis se paie chaque année en maintenance pour recevoir correctifs et versions. L’abonnement supprime l’investissement initial et transforme la dépense en charge courante, tant que le contrat vit.

Sur cinq ans, le modèle SaaS revient souvent plus cher qu’une licence achetée, sans que ce surcoût soit injustifié : il finance les mises à jour, l’hébergement, la sauvegarde et le support qu’un serveur interne facturerait ailleurs. Le calcul se fait contrat par contrat, sur la durée d’usage anticipée.

Quatre variables font dériver un budget d’abonnement plus sûrement que le tarif affiché :

• la tarification à l’utilisateur, qui suit la croissance des effectifs et jamais leur baisse ;
• les modules facturés à part, découverts après la signature ;
• les volumes de stockage ou d’appels d’interface au-delà du seuil inclus ;
• les journées de conseil consommées chaque année pour suivre les évolutions.

Aucun ordre de grandeur universel ne tient ici, tant l’écart se creuse entre un outil de facturation pour trois personnes et un progiciel pour cinquante. La méthode de chiffrage figure dans notre article sur le budget informatique d’une PME.

Sécurité : une responsabilité partagée, jamais transférée

Le contrat repose sur un partage explicite : le fournisseur sécurise ce qu’il administre, vous sécurisez le reste. Le tableau des couches se relit comme une carte de risques.

La surface qui vous incombe en IaaS reste large : durcissement du système, correctifs, règles de pare-feu, chiffrement des volumes, journalisation. Le fournisseur ne répond que de l’infrastructure sous-jacente. En SaaS, cette surface se réduit aux identités, aux droits, aux options de sécurité proposées et à la conduite des utilisateurs.

Trois obligations ne se délèguent jamais :

• l’authentification renforcée sur les comptes sensibles, à commencer par les administrateurs ;
• la revue périodique des accès, aux départs comme aux changements de poste ;
• la vérification des garanties exigées par l’article 28 du règlement général sur la protection des données, qui impose un contrat écrit détaillant objet, durée, finalité, mesures de sécurité et sort des données en fin de prestation.

Un logiciel hébergé chez un fournisseur sérieux résiste souvent mieux qu’un serveur interne mal entretenu. Le raisonnement s’inverse dès que plus personne ne surveille les comptes, et notre dossier sur la cybersécurité en PME en donne la trame.

Souveraineté, mutualisation et localisation des données

Trois questions distinctes se cachent derrière le mot souveraineté, et les confondre mène à des réponses fausses :

• le lieu physique de stockage et de traitement des données ;
• le droit applicable au fournisseur et à ses maisons mères ;
• la capacité technique du prestataire à lire vos données en clair.

L’Agence nationale de la sécurité des systèmes d’information traite les trois dans le référentiel SecNumCloud, dont la version 3.2 publiée en mars 2022 ajoute des critères d’immunité aux législations extraterritoriales. La circulaire n° 6404/SG du 31 mai 2023, qui actualise la doctrine dite « cloud au centre », impose cette qualification à l’État pour les données d’une sensibilité particulière. Une PME n’y est pas soumise, mais l’exigence donne un repère face à un donneur d’ordre public.

La mutualisation mérite une question directe. Sur une offre standard, un hébergement mutualisé place plusieurs clients sur la même infrastructure, avec une isolation logique appelée cloisonnement par tenant ; un hébergement dédié réserve la machine à un seul client. Le premier coûte moins cher, le second se justifie quand un client final l’exige noir sur blanc. Demandez laquelle des deux couvre l’offre proposée, et faites écrire la réponse.

Sortir d’un modèle coûte ce que l’entrée n’a pas facturé

L’effort de sortie grimpe à mesure que vous déléguez, et chaque cran ajoute une dépendance :

• serveur interne : déplacer des fichiers dont vous détenez déjà tout ;
• IaaS : recréer machines et réseau chez un autre fournisseur ;
• PaaS : réécrire les appels aux services propriétaires de la plateforme ;
• SaaS : reprendre données, paramétrages et historique aux formats de l’éditeur.

Quitter un SaaS demande le travail le plus lourd, alors que l’entrée y était la plus simple.

Le règlement européen 2023/2854, dit Data Act, a changé le rapport de force. Son chapitre VI, applicable depuis le 12 septembre 2025, encadre le changement de fournisseur de services de traitement de données et vise explicitement l’IaaS, le PaaS et le SaaS. Il impose la suppression des obstacles contractuels, commerciaux et techniques au départ, et organise une période de transition.

Cette protection ne dispense d’aucune précaution. Un export testé pendant la recette, relu puis rangé chez vous vaut mieux qu’une clause jamais éprouvée : la méthode figure dans notre article sur la réversibilité et le changement de logiciel.

Décoder une offre et calibrer selon la taille de l’équipe

Quatre questions qui révèlent le vrai modèle

Une proposition commerciale décrit rarement son architecture. Quatre questions suffisent à la classer sans ambiguïté.

• Qui applique les correctifs du système d’exploitation, et sous quel délai après publication ?
• Mon instance est-elle partagée avec d’autres clients ou réservée à mon entreprise ?
• Une version différente de la mienne peut-elle exister chez un autre client, et qui décide des montées de version ?
• Sous quel format et dans quel délai récupérerai-je mes données si je pars ?

Un fournisseur qui laisse chaque client sur une version différente vend un hébergement dédié, quel que soit le vocabulaire employé. Le pilotage qui suit relève de la même discipline que le choix d’un prestataire informatique.

Un curseur qui bouge avec l’effectif

La taille de l’équipe informatique interne tranche plus sûrement que le chiffre d’affaires.

• Sans compétence système interne, le SaaS s’impose partout, avec un éditeur exigeant sur l’export.
• Avec une personne polyvalente, le SaaS reste la règle, complété d’un stockage local pour les fichiers lourds.
• Avec une application développée pour vous, le PaaS évite l’astreinte que l’IaaS impliquerait.
• Avec une équipe constituée et une contrainte de latence, l’IaaS et le serveur interne redeviennent défendables.

Une entreprise mélange presque toujours plusieurs modèles d’hébergement : le progiciel en ligne, l’outil métier sur un serveur du local technique, un environnement loué pour les tests. Cette coexistence ne pose aucun problème tant que chaque brique porte un responsable nommé et une sauvegarde vérifiée.

Prochaine étape : listez vos dix logiciels les plus utilisés et notez pour chacun le modèle réel, le format d’export et la date du dernier test de restauration. Comptez une demi-journée. Les lignes restées vides désignent les dépendances à traiter en premier.