Cloud-native, IaaS, PaaS et SaaS expliqués

Le cloud n'est pas un endroit dans le ciel. C'est la question de savoir quelle part de la machine tu fais tourner toi-même et quelle part quelqu'un d'autre fait tourner pour toi.

Je travaille à l'intersection du produit, du GTM et de l'IA comme entrepreneur software. Dès que des agents IA tournent dans ton équipe produit, cette question cesse d'être théorique. Elle décide où tes agents travaillent et à quelle vitesse.

Ce que tu retires d'ici :

• Ce que IaaS, PaaS et SaaS veulent vraiment dire, en une phrase par couche.
• Pourquoi les frontières entre eux sont floues depuis longtemps.
• Pourquoi l'architecture cloud compte quand des agents tournent chez toi.

Ma thèse : les trois modèles sont trois couches d'une même stack. Tu dois juste savoir laquelle tu opères toi-même.

🧨 Trois couches, une stack

La définition officielle vient du NIST. Au quotidien, trois phrases simples suffisent.

IaaS, Infrastructure as a Service. La couche du bas. Tu ne loues que le matériel : calcul, stockage, réseau, virtualisés dans un data center. Tu installes toi-même le système d'exploitation et tout ce qui vient au-dessus. Tu loues l'infrastructure IT et sa maintenance, rien d'autre.

PaaS, Platform as a Service. La couche du milieu. Ici, ce n'est pas l'administrateur IT qui est sollicité, mais le développeur. Le fournisseur livre l'environnement comme cadre et fixe les langages de programmation, les interfaces et le stockage des données. Tu ne contrôles que ton propre code et tes données, pas l'infrastructure en dessous.

SaaS, Software as a Service. La couche du haut, elle s'appuie sur les deux autres. Tu n'achètes pas le software et tu ne l'installes pas. Tu le loues comme un service. En général, un appareil connecté à internet et un navigateur suffisent. Du matériel bon marché chez toi, toute la puissance de calcul dans le data center.

Une image du quotidien aide. IaaS, c'est le gros oeuvre : tu loues les murs et tu aménages tout toi-même. PaaS, c'est l'atelier équipé : tu n'apportes que ton propre projet. SaaS, c'est l'appareil fini en abonnement : tu l'allumes et tu l'utilises.

🛠️ Pourquoi les frontières deviennent floues

Le gâteau à couches bien net, c'est de la théorie. En pratique, les frontières s'effacent depuis des années. Avant même qu'Azure propose des machines virtuelles en 2012, on ne savait souvent plus où finit l'IaaS et où commence le PaaS.

Les vrais projets ne demandent pas le modèle. Ils assemblent des capacités : une API ici, un composant là, un service au-dessus. Ce n'est pas IaaS ou PaaS. C'est IaaS et PaaS et SaaS, souvent dans le même projet. S'ajoute l'approche hybride, qui brouille même la frontière avec ton propre matériel on-premises.

Au début, il fallait encore expliquer et justifier le PaaS. Vite, il n'a plus été question que de vrais projets de développement. La maturité autour du cloud hybride a grandi année après année. C'est là que nous en sommes : pas un modèle, mais un mix que tu assembles volontairement.

S'ajoutent des catégories entières de produits qui vivent entre les couches. Bases de données managées, services de containers, fonctions serverless. Tous des hybrides où le fournisseur prend plus en charge qu'avec de l'infrastructure brute et impose moins qu'une plateforme complète. Le modèle en couches reste utile malgré tout. Il répond à la seule question qui compte : qui opère quoi.

🧭 La marche de décision : une boîte, trois réponses

Prends une boîte de software B2B de 30 personnes. Un produit, une petite équipe, pas de département ops. Elle fait un bon cas de test pour le choix, couche par couche.

L'infrastructure brute a du sens quand tu as vraiment besoin de contrôle. Disons que tes clients imposent par contrat où sont les données et qui y a accès. Ou que ton produit a des exigences de runtime ou de matériel que les plateformes standard ne couvrent pas. Alors tu loues des machines et tu opères le reste toi-même. Le prix : il te faut des gens qui savent et qui veulent faire ça. Dans la boîte de 30 personnes, ça veut vite dire 2 d'entre elles qui ne font que de l'infrastructure.

Une plateforme a du sens quand ton goulot est le développement, pas l'exploitation. Pour notre boîte, c'est le cas normal. L'équipe écrit du code, la plateforme s'occupe des serveurs, du scaling et des patchs en dessous. Tu cèdes du contrôle et tu récupères de la vitesse. Pour une équipe produit sans ops, c'est presque toujours le bon point de départ.

Le software fini a du sens pour tout ce qui ne te différencie pas. Mail, CRM, le système pour tes données clients, la compta, l'outil de support : loue, ne construis pas. La boîte ne gagne pas un seul client parce qu'elle opère son propre ticketing. Chaque heure passée là est une heure de moins sur le produit.

La marche de décision n'est donc pas une question de croyance. C'est une question par système : est-ce que ça nous différencie? Si non, achète le plus haut possible dans la stack. Si oui, prends autant de contrôle que nécessaire et aussi peu d'exploitation en propre que possible.

Pour la boîte de 30 personnes, le résultat ressemble souvent à ça : le produit lui-même sur une plateforme, la base de données en service managé, un morceau d'infrastructure brute pour le client aux exigences spéciales, une douzaine d'outils loués autour. Exactement le mix de la section précédente. Pas une règle de pureté, mais une série de décisions individuelles délibérées.

⚖️ Trois trade-offs, en mots simples

Derrière chaque choix de couche, les 3 mêmes trade-offs. Connais-les et tu peux situer n'importe quelle slide de vendeur en quelques minutes.

Contrôle contre responsabilité. Chaque couche que tu opères toi-même t'obéit. Et elle t'appelle quand elle tombe la nuit. Le contrôle sonne comme la liberté, ce que ça veut dire, c'est l'astreinte. La question honnête n'est pas "voulons-nous le contrôle" mais "voulons-nous la responsabilité qui vient avec".

Lock-in contre vitesse. Plus tu utilises de services finis, plus tu livres vite. Et plus tu t'enracines chez un fournisseur. Changer devient cher, pas impossible. L'erreur n'est pas le lock-in en soi. L'erreur, c'est de le prendre sans le savoir. Tout construire toi-même par peur du lock-in, et tu paies le prix maintenant au lieu de peut-être plus tard.

Coût fixe contre coût à l'usage. L'exploitation en propre coûte de l'argent, que quelqu'un utilise ton produit ou non. Les services à l'usage coûtent peu sous faible charge et grandissent avec ton succès. Pour un produit jeune, le deuxième est en général mieux. Tu ne paies beaucoup que quand tu as des clients. En échange, il faut garder un oeil sur la facture, parce que les coûts à l'usage grandissent en silence.

L'ordre compte : décide d'abord ce qui te différencie, puis pèse les trade-offs par système. Fais l'inverse et tu débattras de vendors pendant des semaines sans jamais avoir de ligne.

🤖 Pourquoi ça compte à l'ère des agents

C'est exactement là que ça devient concret pour moi. Je construis des équipes produit AI-native. J'appelle ça Get Multiplayer : comment humains et agents IA travaillent ensemble. Une équipe hyperlean, quelques pros plus des agents qui tournent 24 heures sur 24. Trois au lieu de trente.

Ces agents tournent quelque part. Sur IaaS, sur PaaS ou connectés en SaaS : ça décide de la latence, du coût et du contrôle des données. Si tu dois garder ton code, ton Jira et tes données dans l'UE, alors le choix de couche n'est pas une question technique mais une question de compliance.

Pour les boîtes DACH, ce n'est pas une note de bas de page. Beaucoup de clients B2B exigent par contrat que les données restent dans l'UE ou en Suisse. C'est le cas normal, pas l'exception. Les 3 couches existent avec des régions européennes. Il faut juste le vérifier au moment du choix au lieu de réparer après coup.

S'ajoute le contexte. Un agent ne vaut que ce que vaut sa fondation. Cette fondation, c'est le Context Engine : le contexte business et code de ta boîte. Où vit ce contexte et comment les agents y accèdent, c'est une question d'architecture cloud. Sans contexte propre, c'est garbage in, garbage out.

🧑‍💻 Qu'est-ce que ça veut dire pour une petite équipe produit?

Achète en service fini tout ce qui ne te différencie pas. Opère toi-même le moins possible. Et tranche la question des couches avant que tes agents tournent, pas après. Parce que l'architecture détermine ce que tes agents peuvent atteindre et à quelle vitesse.

Ça rejoint le point au-dessus. Dès que des assistants IA travaillent dans le produit, chaque décision de couche compte double. Elle détermine où ton code tourne. Et elle détermine si un agent peut atteindre les logs, les données et les déploiements sans qu'un humain clique entre les deux.

Une petite équipe a ici un avantage : peu de legacy. Tu peux tailler l'architecture pour que le contexte soit à un seul endroit et que les agents y travaillent. Comment un tel setup se monte en pratique, je le montre dans un produit SaaS en 90 jours et dans From Vibe Coding to Agentic Engineering.

La question des couches fait partie du product management, pas de l'IT. J'en rassemble plus dans le hub software product management.

🎢 Hauts, bas, avertissement

✅ Ce qui marche : les couches comme modèle mental. Pour chaque service, demande : quelle couche j'opère moi-même, laquelle quelqu'un d'autre opère. Ça dissipe l'essentiel de la confusion.

❌ Ce qui ne marche pas : traiter les modèles comme des boîtes rigides. La réalité est mixte, hybride et floue. Attends le gâteau bien net et tu planifies à côté de la pratique.

⚠️ Avertissement : ne laisse pas ton architecture cloud arriver par accident. Dès que des agents tournent chez toi, elle détermine la vitesse, le coût et où sont tes données.

Le cloud n'est pas un endroit dans le ciel, c'est une décision sur ce que tu opères toi-même. À l'ère des agents, cette décision devient plus importante, pas moins. Si tu veux mettre dans ton équipe produit des agents qui connaissent ton contexte, jette un oeil à teklens.ai.