Entrepreneuriat & croissance
IaaS, PaaS et SaaS : différences et impacts sur le modèle de votre startup
Les requêtes « IaaS and PaaS and SaaS » ou « IaaS, PaaS or SaaS » cachent une question que tout fondateur tech finit par se poser : sur quelle couche du cloud bâtir son produit, et laquelle vendre ? Derrière ces trois acronymes se jouent votre structure de coûts, votre marge brute, la taille de votre équipe technique et, au bout du compte, le multiple qu'un investisseur acceptera de payer.
Ce guide compare IaaS, PaaS et SaaS sous l'angle financier : ce que chaque modèle change dans votre compte de résultat, comment le comptabiliser en normes françaises, ce que le cadre légal impose désormais aux fournisseurs cloud, et comment arbitrer à chaque étape de croissance. Un cas pratique chiffré montre comment quelques points de marge se traduisent en valeur.
Chez DIGIFEC, cabinet d'expertise comptable dédié aux startups et scale-ups, nous voyons régulièrement des business plans où la ligne « hébergement » est traitée comme un détail. C'est souvent elle qui fait la différence entre une marge brute défendable en due diligence et une marge à justifier ligne par ligne.
IaaS, PaaS et SaaS : de quoi parle-t-on exactement ?
La définition de référence reste celle du NIST (publication SP 800-145, septembre 2011), l'institut de normalisation américain. Elle décrit le cloud par cinq caractéristiques essentielles (accès en libre-service à la demande, accès réseau large, mutualisation des ressources, élasticité rapide, service mesuré) et par trois modèles de service. Ce qui distingue ces modèles, c'est la frontière entre ce que gère le fournisseur et ce que gère le client.
L'IaaS : louer l'infrastructure
Avec l'Infrastructure as a Service, vous louez de la puissance de calcul, du stockage et du réseau. Selon le NIST, le client peut y déployer et exécuter n'importe quel logiciel, y compris des systèmes d'exploitation, mais ne contrôle pas l'infrastructure sous-jacente. Concrètement, vous gérez les serveurs virtuels, les mises à jour, la sécurité applicative et la montée en charge.
Le PaaS : déployer son code sans gérer les serveurs
La Platform as a Service fournit un environnement d'exécution prêt à l'emploi : vous déployez une application créée avec les langages, bibliothèques et outils supportés par le fournisseur. Vous gardez la main sur l'application et sur certains paramètres d'hébergement, mais plus sur le réseau, les serveurs, le système d'exploitation ou le stockage. Bases de données managées, fonctions serverless et plateformes de déploiement continu relèvent de cette famille.
Le SaaS : utiliser une application hébergée
Le Software as a Service met à disposition une application accessible depuis un navigateur ou une API. Le client ne gère ni l'infrastructure ni même les fonctionnalités, à l'exception de paramétrages limités propres à l'utilisateur. Votre CRM, votre outil de paie ou votre logiciel comptable sont des SaaS ; votre propre produit l'est probablement aussi. Pour approfondir ce modèle côté éditeur, consultez notre article sur la définition du SaaS et son modèle économique.
Qui gère quoi ? La pile technique selon le modèle
Lecture de haut en bas : de l'application jusqu'au matériel.
Quelles différences entre IaaS, PaaS et SaaS pour une startup ?
Chaque couche déplace une partie du travail : plus vous montez vers le SaaS, plus vous achetez du temps et de la simplicité ; plus vous descendez vers l'IaaS, plus vous achetez du contrôle et un coût unitaire faible, au prix de compétences internes.
| Critère | IaaS | PaaS | SaaS |
|---|---|---|---|
| Ce que vous achetez | Calcul, stockage, réseau | Un environnement d'exécution pour votre code | Une application prête à l'emploi |
| Ce que vous gérez | Système d'exploitation, middleware, données, application | Application et données, configuration de l'hébergement | Paramétrage utilisateur uniquement |
| Mode de facturation | À l'usage, réservations possibles | À l'usage ou par paliers | Abonnement par utilisateur ou par volume |
| Compétences requises | DevOps, SRE, sécurité | Développeurs, peu d'exploitation | Aucune compétence technique |
| Usage typique en startup | Produit à forte volumétrie, IA, données sensibles | MVP, produit SaaS en phase d'amorçage | Outils internes : CRM, paie, comptabilité |
| Risque principal | Coûts d'exploitation cachés | Coût unitaire élevé à l'échelle | Empilement d'abonnements non suivis |
En pratique, une startup utilise presque toujours les trois. Elle consomme du SaaS pour ses fonctions support, construit son produit sur du PaaS ou de l'IaaS, et vend elle-même un service, le plus souvent en SaaS. La vraie question n'est donc pas « IaaS, PaaS or SaaS ? » mais : quelle combinaison, à quel stade, et avec quel impact sur vos indicateurs ?
Comment chaque modèle pèse-t-il sur la structure de coûts ?
Le cloud transforme des investissements en charges variables : un serveur acheté était une immobilisation amortie, une instance louée est une charge de la période. C'est un atout au démarrage, mais la facture devient sensible à chaque décision d'architecture.
Ce que l'IaaS rend moins cher… et ce qu'il rend plus cher
L'IaaS offre en général le coût unitaire le plus bas par ressource consommée, et des remises en échange d'un engagement de durée ou de volume. En contrepartie, il exige une équipe capable d'exploiter, sécuriser et faire évoluer l'infrastructure. Ces salaires sont le coût caché de l'IaaS : un ingénieur SRE à temps plein peut annuler l'économie réalisée sur la facture d'hébergement tant que vos volumes restent modestes.
Le PaaS, accélérateur au prix d'une prime
Le PaaS facture une prime sur la ressource brute, puisque le fournisseur assure l'exploitation à votre place. Pour une petite équipe qui doit sortir un MVP vite, cette prime est presque toujours rentable. Le problème apparaît à l'échelle, quand la facture croît au même rythme que l'usage, sans effet de palier.
Le SaaS interne, poison lent du burn
Pris un par un, les abonnements SaaS internes paraissent indolores ; multipliés par le nombre de salariés, ils deviennent un vrai poste de frais généraux. Un inventaire trimestriel des licences, avec un responsable par outil, fait partie des leviers simples pour allonger votre runway. Notre guide sur le pilotage du cash burn et du runway détaille cette démarche.
Point de vigilance : les frais de sortie de données
Dans les modèles IaaS et PaaS, l'extraction de données vers l'extérieur peut être facturée. Ces frais sont faibles au démarrage mais deviennent stratégiques lorsqu'un changement de fournisseur ou une architecture multi-cloud est envisagé. Lisez la grille tarifaire avant de signer un engagement pluriannuel.
Quel impact sur la marge brute ? Cas pratique chiffré
Prenons une startup fictive, éditrice d'un logiciel SaaS B2B de gestion de flottes, que nous appellerons Fleetly. Elle facture un MRR de 100 000 €, soit un ARR de 1 200 000 €. Son produit tourne aujourd'hui sur une plateforme PaaS. Son CTO propose de migrer vers de l'IaaS. Les chiffres ci-dessous sont des hypothèses construites pour l'exemple.
Étape 1 : isoler le coût des ventes
Le coût des ventes (COGS) d'un éditeur SaaS regroupe tout ce qui est nécessaire pour délivrer le service aux clients existants : hébergement, outils tiers intégrés au produit (envoi d'e-mails transactionnels, monitoring, cartographie), support et onboarding, et, le cas échéant, l'équipe d'exploitation. Les dépenses de R&D sur les nouvelles fonctionnalités, le marketing et les fonctions support n'y figurent pas.
Étape 2 : comparer les deux scénarios à MRR constant
En PaaS, Fleetly paie 14 000 € d'hébergement par mois, 3 000 € d'outils tiers et 9 000 € de support, sans équipe d'exploitation : 26 000 € de coût des ventes. La marge brute ressort à (100 000 − 26 000) / 100 000 = 74 %.
En IaaS, l'hébergement tombe à 7 500 €, mais il faut un demi-poste d'ingénieur d'exploitation, chiffré à 5 500 € chargés par mois. Le coût des ventes atteint 7 500 + 3 000 + 9 000 + 5 500 = 25 000 €, soit une marge brute de 75 %. L'économie d'hébergement de 6 500 € est presque entièrement absorbée par le coût humain : un seul point de marge gagné, pour un projet de migration qui mobilisera l'équipe plusieurs mois.
Étape 3 : projeter à MRR triplé
Dix-huit mois plus tard, Fleetly vise un MRR de 300 000 €. En PaaS, l'hébergement suit l'usage presque linéairement : 42 000 €. Les outils tiers passent à 6 000 € et le support à 21 000 €. Total : 69 000 €, marge brute de 77 %.
En IaaS, grâce aux engagements de capacité et à l'optimisation de l'architecture, l'hébergement ne monte qu'à 19 000 €, avec un ingénieur d'exploitation à plein temps (11 000 €). Total : 19 000 + 6 000 + 21 000 + 11 000 = 57 000 €, marge brute de 81 %. L'écart devient significatif : 4 points de marge, soit 12 000 € par mois.
| Poste de coût des ventes | PaaS (MRR 100 k€) | IaaS (MRR 100 k€) | PaaS (MRR 300 k€) | IaaS (MRR 300 k€) |
|---|---|---|---|---|
| Hébergement et infrastructure | 14 000 € | 7 500 € | 42 000 € | 19 000 € |
| Outils tiers intégrés au produit | 3 000 € | 3 000 € | 6 000 € | 6 000 € |
| Support et onboarding client | 9 000 € | 9 000 € | 21 000 € | 21 000 € |
| Exploitation (SRE / DevOps) | 0 € | 5 500 € | 0 € | 11 000 € |
| Total coût des ventes | 26 000 € | 25 000 € | 69 000 € | 57 000 € |
| Marge brute | 74 % | 75 % | 77 % | 81 % |
Étape 4 : traduire l'écart de marge en valeur
Un investisseur qui valorise une société SaaS raisonne souvent en multiple de revenus récurrents, corrigé par la qualité de ces revenus, dont la marge brute fait partie. Pour isoler l'effet, appliquons une hypothèse simple : un multiple de 8 sur la marge brute annuelle. Ce chiffre n'est pas une référence de marché, il sert uniquement à la démonstration. Pour bien présenter vos revenus récurrents, voyez aussi notre article ARR et MRR : comment les présenter aux investisseurs.
Cascade : de la marge brute à l'écart de valeur (MRR de 300 000 €)
Le multiple de 8 est une hypothèse pédagogique, pas une référence de marché : il sert à montrer qu'un écart de quelques points de marge brute se transforme en écart de valorisation dès qu'un investisseur raisonne en multiple.
La leçon est double. À 100 000 € de MRR, migrer vers l'IaaS n'apporte presque rien et détourne l'équipe du produit. À 300 000 € de MRR, la même décision vaut potentiellement plus d'un million d'euros de valeur théorique. Le bon choix d'hébergement dépend donc du stade de la startup, pas d'une préférence technique.
Vendre de l'IaaS, du PaaS ou du SaaS : quel modèle économique ?
Si votre startup est elle-même fournisseur, la couche choisie détermine votre intensité capitalistique et vos indicateurs de pilotage.
Le SaaS : récurrence et marge élevée
Un éditeur SaaS vend un abonnement, généralement par utilisateur, par palier de fonctionnalités ou par volume. Son coût marginal par client supplémentaire est faible, d'où une marge brute potentiellement élevée. Ses indicateurs clés sont le MRR, le churn, la rétention nette des revenus et le ratio entre valeur vie client et coût d'acquisition.
Le PaaS : revenus à l'usage et effet plateforme
Une startup PaaS (plateforme de déploiement, base de données managée, API d'IA générative) facture surtout à la consommation. Ses revenus suivent l'activité de ses clients : forte rétention nette possible, mais volatilité si un gros client optimise son usage. Sa marge brute dépend directement du coût de l'infrastructure qu'elle loue elle-même, souvent à un hyperscaler.
L'IaaS : un métier d'infrastructure
Vendre de l'IaaS suppose de détenir ou de louer du matériel à grande échelle : centres de données, serveurs, GPU. C'est un métier à forte intensité capitalistique, avec des amortissements lourds. Pour une startup, cela passe souvent par une niche : cloud souverain, calcul spécialisé pour l'IA, hébergement de données sensibles.
Pourquoi la valorisation diffère-t-elle selon le modèle ?
Deux startups au même chiffre d'affaires peuvent obtenir des valorisations très différentes selon la nature de leurs revenus. Les investisseurs regardent d'abord la prévisibilité : un revenu contractuel récurrent pèse plus qu'un revenu à l'usage, lui-même mieux valorisé qu'un revenu ponctuel de projet. Ils regardent ensuite la marge brute, qui indique combien de chaque euro de revenu reste pour financer la croissance et, à terme, le profit.
Une startup qui revend de la capacité cloud avec une faible marge sera lue comme un revendeur, pas comme un éditeur. À l'inverse, une marge brute qui s'améliore avec l'échelle prouve des économies d'échelle réelles, comme dans l'exemple de Fleetly.
Ce que vérifiera une due diligence
- La définition du coût des ventes : l'hébergement et le support y sont-ils bien affectés, ou dispersés en frais généraux pour flatter la marge ?
- La dépendance à un fournisseur : quelle part de la facture chez un seul hyperscaler, quelle portabilité de l'architecture ?
- Les engagements de consommation : montants, durée, pénalités en cas de sous-consommation.
- L'effet des crédits cloud : la marge présentée est-elle normalisée, hors crédits gratuits ?
Sur la sécurisation juridique de ces points, notre article sur la valorisation SaaS et sa protection juridique complète cette approche financière.
Comment comptabiliser vos dépenses IaaS, PaaS et SaaS ?
Le plan comptable général (version au 1er janvier 2026) consacre une section spécifique aux solutions informatiques (articles 611-1 à 611-8). Elle tranche une question fréquente en startup : qu'est-ce qui se capitalise, et qu'est-ce qui passe en charges ?
Les coûts d'accès : toujours en charges
L'article 611-5 du PCG prévoit que les coûts d'accès aux services nécessaires à l'utilisation continue d'une solution informatique sont comptabilisés en charges au fur et à mesure de la prestation. Vos abonnements SaaS et votre consommation IaaS ou PaaS sont donc des charges de la période.
Le développement de votre produit : activable sous conditions
Une solution informatique produite par l'entité est inscrite à l'actif à son coût de production dès que six critères sont réunis (article 611-3) : faisabilité technique, intention d'achever, capacité à utiliser ou commercialiser, avantages économiques futurs probables, disponibilité des ressources et capacité à mesurer de façon fiable les dépenses. Les études préliminaires restent en charges (article 611-4).
Point notable : l'article 611-2 vise expressément les solutions développées par l'entité pour ses besoins spécifiques à partir d'un contrat de services donnant accès à des ressources hébergées sur la plateforme d'un tiers, lorsque l'entité dispose d'un droit d'accès garantissant l'usage exclusif de la solution. Un développement spécifique bâti sur un PaaS peut donc, sous ces conditions, constituer une immobilisation incorporelle.
| Nature de la dépense | Traitement comptable | Référence |
|---|---|---|
| Abonnement SaaS (CRM, paie, outils) | Charge au fur et à mesure de la prestation | PCG, art. 611-5 |
| Consommation IaaS / PaaS (calcul, stockage) | Charge de la période | PCG, art. 611-5 |
| Études préliminaires d'un projet logiciel | Charge, quelle que soit leur nature | PCG, art. 611-4 |
| Développement de votre solution, une fois les critères réunis | Immobilisation incorporelle au coût de production | PCG, art. 611-3 et 611-4 |
| Développement spécifique sur une plateforme tierce avec droit d'usage exclusif | Immobilisation incorporelle possible | PCG, art. 611-2 |
| Coûts de réorganisation liés au déploiement | Charge lorsqu'ils sont encourus | PCG, art. 611-6 |
| Évolutions après mise en service | Actif si elles dépassent la performance actuelle, sinon charge | PCG, art. 611-7 |
Activer ou non n'est pas neutre : l'activation améliore le résultat et les capitaux propres à court terme, mais crée des amortissements futurs et doit être documentée. Le suivi des temps des développeurs sert aussi à justifier un éventuel crédit d'impôt recherche ou innovation ; notre article sur la comptabilisation et la sécurisation du CIR détaille l'articulation entre les deux.
Quelles règles encadrent les fournisseurs cloud en 2026 ?
Le cadre juridique a changé la donne pour les startups clientes du cloud. En France, la loi n° 2024-449 du 21 mai 2024 visant à sécuriser et à réguler l’espace numérique consacre son titre III à la confiance et à la concurrence dans l'économie de la donnée, avec plusieurs chapitres dédiés à l'informatique en nuage.
Crédits cloud, frais de transfert et interopérabilité
- Avoirs cloud (article 26) : ils ne peuvent être accordés que pour une durée limitée, fixée par décret, qui ne peut excéder un an, y compris en cas de renouvellement, et ne peuvent être assortis d'aucune condition d'exclusivité.
- Frais de transfert et de changement de fournisseur (article 27) : lors d'un changement de fournisseur, ils ne peuvent être supérieurs aux coûts supportés par le fournisseur et directement liés à ce changement. Leur nature et leur montant doivent être portés à la connaissance du client avant la signature.
- Interopérabilité et portabilité (article 28) : les fournisseurs doivent assurer l'interopérabilité de leurs services et la portabilité des données exportables, et mettre gratuitement à disposition les interfaces de programmation nécessaires.
Au niveau européen, le règlement sur les données (Data Act), entré en application le 12 septembre 2025, organise lui aussi la possibilité pour les clients de basculer efficacement entre fournisseurs de services de traitement de données.
Durée de validité maximale d'un avoir cloud, renouvellement compris (loi du 21 mai 2024, art. 26).
Les frais de transfert lors d'un changement de fournisseur ne peuvent excéder les coûts directement liés (art. 27).
Date d'entrée en application du Data Act européen, qui organise le changement de fournisseur cloud.
À réunir pour activer une solution informatique produite en interne (PCG, art. 611-3).
Ce que cela change pour votre modèle financier
La limitation des avoirs à un an a une conséquence directe : les programmes de crédits cloud pour startups ne peuvent plus masquer durablement le vrai coût de l'infrastructure. Si vos crédits financent aujourd'hui votre hébergement, votre business plan doit prévoir la date à laquelle ils s'éteignent et la marge brute normalisée qui en résulte.
Reprenons Fleetly en IaaS, à 100 000 € de MRR. Si les 7 500 € d'hébergement mensuel sont couverts par des crédits, le coût des ventes décaissé tombe à 17 500 € et la marge apparente grimpe à 82,5 %. À l'extinction des crédits, elle revient à 75 %. Présenter 82,5 % à un investisseur sans retraitement, c'est s'exposer à une renégociation au premier audit.
Méthode : choisir et piloter votre combinaison IaaS, PaaS et SaaS
Le choix d'une couche cloud n'est jamais définitif : réexaminez-le à chaque palier de croissance, avec des critères financiers partagés entre le CTO et la direction financière.
Arbre de décision : quelle couche cloud pour quel besoin ?
Checklist trimestrielle du pilotage cloud
- Ventilez la facture cloud entre production (coût des ventes), développement (R&D) et outils internes (frais généraux), avec des étiquettes par environnement.
- Calculez le coût d'hébergement par client ou par unité d'usage, et suivez son évolution quand le volume augmente.
- Normalisez la marge brute en neutralisant les crédits cloud et les remises ponctuelles.
- Recensez les engagements de consommation : montant, échéance, taux d'utilisation réel.
- Mesurez la dépendance : part de la facture chez le premier fournisseur, services propriétaires difficilement remplaçables.
- Documentez les développements activés au regard des critères de l'article 611-3 du PCG.
Quelles erreurs éviter dans le choix entre IaaS, PaaS ou SaaS ?
- Migrer trop tôt vers l'IaaS : comme le montre le cas Fleetly, l'économie d'hébergement est absorbée par le coût d'exploitation tant que les volumes restent faibles.
- Classer l'hébergement en frais généraux pour afficher une meilleure marge brute : un retraitement en due diligence fera apparaître l'écart, au détriment de votre crédibilité.
- Oublier l'échéance des crédits cloud dans le prévisionnel de trésorerie : la hausse brutale de la facture survient souvent au pire moment, entre deux levées.
- Signer un engagement pluriannuel sans scénario bas : en cas de croissance plus lente, vous payez une capacité inutilisée.
- Activer des dépenses non éligibles, comme des études préliminaires ou des coûts de réorganisation, que le PCG impose de passer en charges.
En résumé : faire de l'arbitrage IaaS, PaaS et SaaS une décision financière
IaaS, PaaS et SaaS ne sont pas seulement des choix d'architecture. Ils déterminent ce qui entre dans votre coût des ventes, la vitesse à laquelle votre marge brute progresse avec l'échelle, la façon dont vous comptabilisez vos développements et la lecture que les investisseurs feront de vos revenus. Le PaaS accélère le démarrage, l'IaaS récompense la maturité, et le SaaS interne doit être tenu sous contrôle pour préserver le runway.
Vous voulez modéliser l'impact de votre stack cloud sur votre marge brute et votre valorisation avant une levée ? Découvrez notre accompagnement en pilotage financier et indicateurs de performance pour startups : l'équipe DIGIFEC construit avec vous des KPI fiables et défendables en due diligence.
À lire aussi
Foire aux questions
La différence tient à la répartition des responsabilités. En IaaS, vous louez l'infrastructure (calcul, stockage, réseau) et gérez le système d'exploitation, le middleware et l'application. En PaaS, le fournisseur gère aussi l'environnement d'exécution : vous ne déployez que votre code. En SaaS, vous utilisez une application prête à l'emploi, sans rien gérer d'autre que vos paramètres utilisateur. Plus on monte vers le SaaS, plus on gagne en simplicité et moins on garde de contrôle.
Non, une startup combine presque toujours les trois. Elle utilise du SaaS pour ses outils internes, héberge son produit sur du PaaS ou de l'IaaS, et vend souvent elle-même un SaaS. L'arbitrage porte surtout sur l'hébergement du produit : PaaS en phase d'amorçage pour aller vite avec une petite équipe, migration progressive vers l'IaaS lorsque la facture d'hébergement devient un poste significatif du coût des ventes.
L'hébergement du produit fait partie du coût des ventes. Le PaaS coûte plus cher par ressource mais évite une équipe d'exploitation ; l'IaaS coûte moins cher par ressource mais exige des compétences internes. À faible volume, les deux options donnent des marges proches. À fort volume, l'IaaS bien optimisé peut faire gagner plusieurs points de marge brute, ce qui pèse sur la valorisation.
Non. Selon l'article 611-5 du plan comptable général, les coûts d'accès aux services nécessaires à l'utilisation continue d'une solution informatique sont comptabilisés en charges au fur et à mesure de la prestation. En revanche, le développement de votre propre solution peut être activé lorsque les six critères de l'article 611-3 sont réunis, y compris pour un développement spécifique réalisé sur la plateforme d'un tiers.
