Qu'est-ce que l'infrastructure en tant que service (IaaS) ?

IaaS est un modèle cloud qui loue des ressources de calcul fondamentales — machines virtuelles, stockage, réseau — à la demande, facturées à la consommation. La définition du NIST trace la frontière avec précision : le fournisseur contrôle l’infrastructure physique ; vous contrôlez les systèmes d’exploitation, le stockage et les applications déployées. C’est l’échelon le plus bas de l’échelle du cloud — celui qui remplace l’achat de serveurs par leur location.

Points clés

À quoi ressemble l’usage de l’IaaS

L’expérience signature est une machine en quelques minutes — suivie de tout ce dont une machine a toujours eu besoin :

# Minute un : louez la machine
$ cloud compute create --size medium --image ubuntu-24.04
   ✓ vm-7f3a running — 203.0.113.40

# À partir de la minute deux : tout reste votre travail
$ ssh [email protected]
$ apt update && apt upgrade          # les patchs : à vous
$ apt install nginx postgresql       # le stack : à vous
$ ufw allow 443 && configure-tls…    # la sécurité : à vous
$ crontab -e                         # backups, rotation, monitoring : à vous

Ce marché — le matériel en minutes, les opérations pour toujours — est tout le modèle. En contraste, voici le même objectif “avoir un backend qui tourne” tout en haut de l’échelle, là où l’infrastructure n’affleure jamais :

// JavaScript / Node.js — Back4app JS SDK
const note = new Parse.Object('Note');
note.set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched, no firewall rules

// Flutter / Dart — Back4app Flutter SDK
final note = ParseObject('Note')
  ..set('text', 'Shipped without touching a VM');
await note.save(); // no instance sized, no OS patched

// iOS / Swift — Back4app Swift SDK
var note = Note()
note.text = "Shipped without touching a VM"
note.save { result in
  if case .success = result { print("saved — zero infrastructure managed") }
}

// Android / Kotlin — Back4app Android SDK
val note = ParseObject("Note").apply {
  put("text", "Shipped without touching a VM")
}
note.saveInBackground { e ->
  if (e == null) Log.d("Note", "saved — zero infrastructure managed")
}

Qui gère quoi

Cette répartition est aussi le modèle de sécurité : le fournisseur sécurise le cloud, vous sécurisez tout ce qui est dedans. La mauvaise configuration côté client — buckets de stockage ouverts, règles de firewall permissives, systèmes non patchés — est la cause première des brèches cloud, et c’est pourquoi la case “vous opérez” mérite plus de respect qu’elle n’en reçoit d’habitude.

IaaS vs. PaaS vs. BaaS vs. on-premises

Une clarification qui revient dans chaque discussion “IaaS vs.” : les modèles serverless ne sont pas une quatrième colonne du même genre — ils abstraient l’unité de calcul (à l’invocation) plutôt que la couche de gestion, et c’est pourquoi une plateforme serverless peut elle-même tourner sur de l’IaaS en dessous.

Cas d’usage courants

• Migrations lift-and-shift. Les applications serveur existantes déménagent vers des VM louées presque sans changement — le même stack, sans plus de cycles de renouvellement de matériel.
• Stacks sur mesure et legacy. Runtimes inhabituels, logiciels sous licence ou réglages au niveau de l’OS que les plateformes gérées n’autorisent pas.
• Contrôle imposé par la conformité. Des régimes qui exigent de savoir et de configurer exactement ce qui tourne sous l’application.
• Charges de haute performance et spécialisées. Flottes de GPU, traitement de données à grande échelle et tout ce qui a des exigences en forme de matériel.
• Reprise après sinistre et capacité de débordement. Environnements de standby et marge pour les pics de trafic qu’il serait ruineux de posséder en matériel à vide.

Devriez-vous construire sur IaaS ? Matrice de décision

Le motif qui vaut d’être intériorisé : l’IaaS a rarement tort pour déplacer des systèmes existants, et a rarement raison pour démarrer des systèmes standard — un backend d’app neuf assemblé à la main sur des VM, ce sont des semaines de travail que les échelons supérieurs livrent avant le déjeuner.

Limites et trade-offs

• Les opérations restent les vôtres. Patchs, durcissement, mise à l’échelle, backups, monitoring — le runbook survit intact ; seul le matériel en dessous a changé.
• Le choc de facturation est un problème de compétences dont vous héritez. Instances à vide, VM surdimensionnées et stockage oublié facturent 24 h/24 ; la gestion des coûts devient une discipline permanente.
• L’egress est le péage de sortie. Les données entrent gratuitement et sortent contre paiement — un mécanisme qui se cumule silencieusement en vendor lock-in à mesure que les données s’accumulent.
• La mauvaise configuration de sécurité est le mode de défaillance numéro un. La moitié du fournisseur dans la responsabilité partagée est excellente ; les brèches surviennent massivement dans la moitié du client.
• La taxe de compétences. Bien opérer de l’infrastructure exige des gens qui opèrent bien de l’infrastructure — une exigence de recrutement que la page de pricing pay-as-you-go ne mentionne pas.

L’IaaS sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Face à l’IaaS, c’est l’extrémité opposée du marché : aucun accès à l’OS, aucun contrôle de l’infrastructure — et aucun runbook, parce que toute la case “vous opérez” du diagramme ci-dessus est le travail de la plateforme. Les équipes qui ont besoin d’infrastructure brute pour une charge spécialisée peuvent la faire tourner à côté d’un backend BaaS ; les équipes qui construisent des backends d’app standard peuvent sauter l’échelon du bas entièrement. Et comme le stack est open source, redescendre l’échelle plus tard — auto-héberger la plateforme sur de l’IaaS que vous contrôlez — reste une option réelle, pas une réécriture.