Cloud computing

Le cloud computing (ou informatique en nuage) consiste à utiliser des serveurs, du stockage, des bases de données et d’autres services informatiques hébergés et gérés par un fournisseur externe, plutôt que de posséder et maintenir ses propres machines. On accède à ces ressources via internet, on paie en fonction de l’usage, et on ajuste la capacité en quelques clics.

Pour les startups et les éditeurs de SaaS, ce modèle a tout changé. Avant la généralisation du cloud, lancer un produit web supposait d’acheter des serveurs, de recruter un administrateur système et d’estimer la capacité des années à l’avance. Aujourd’hui, une startup démarre avec une facture de quelques dizaines d’euros par mois et augmente sa capacité au rythme de ses utilisateurs.

IaaS, PaaS, SaaS : les trois modèles du cloud computing

Le cloud se décline en trois modèles, selon le niveau de responsabilité que l’on délègue au fournisseur.

L’IaaS (Infrastructure as a Service) fournit les briques de base : serveurs virtuels, stockage, réseau. C’est l’équivalent d’un ordinateur vierge loué dans un datacenter : on installe soi-même le système d’exploitation, la base de données et l’application. AWS EC2, Google Compute Engine et Azure Virtual Machines en sont les exemples types. C’est le modèle le plus flexible, mais aussi celui qui demande le plus de compétences en administration système.

Le PaaS (Platform as a Service) va plus loin : le fournisseur gère l’infrastructure, le système d’exploitation et les outils de base, et le développeur n’a qu’à déployer son application. Heroku a popularisé ce modèle ; Railway et Render en sont les représentants les plus utilisés aujourd’hui. C’est le bon choix pour aller vite sans se soucier de l’administration serveur.

Le SaaS (Software as a Service) est le modèle que les utilisateurs finaux connaissent le mieux : tout est géré par le fournisseur, on accède au logiciel depuis son navigateur. Slack, Salesforce et Google Workspace en font partie. En tant qu’éditeur, vous utilisez de l’IaaS ou du PaaS pour héberger votre propre produit, qui est lui-même un SaaS pour vos clients.

Le serverless pousse la logique un cran plus loin : le développeur déploie des fonctions individuelles sans savoir sur quels serveurs elles s’exécutent, et la facturation se fait à l’exécution réelle. Pour des charges de travail intermittentes, c’est souvent le modèle le plus économique.

Quel fournisseur de cloud choisir ?

AWS (Amazon Web Services) est le leader du marché avec plus de 200 services. Son écosystème est le plus vaste, sa documentation la plus complète, et les profils qui le maîtrisent sont les plus nombreux. La contrepartie est une tarification et une configuration parfois difficiles à déchiffrer.

Google Cloud Platform (GCP) se distingue sur la donnée et l’intelligence artificielle, avec BigQuery et Vertex AI. Son interface est plus lisible que celle d’AWS, son catalogue moins large.

Microsoft Azure est très présent dans les entreprises déjà équipées en Microsoft (Microsoft 365, Active Directory). C’est le choix naturel quand le projet doit s’intégrer à cet univers.

Les acteurs européens comme OVHcloud et Scaleway proposent une alternative crédible pour l’hébergement de base, avec des prix souvent inférieurs et des données garanties en Europe. Leur catalogue de services managés reste toutefois bien plus restreint que celui des trois géants américains.

Pour une startup SaaS, le choix se porte le plus souvent sur AWS, par défaut et par pragmatisme. Le fournisseur n’est d’ailleurs qu’une partie de l’équation : notre guide sur les technologies à utiliser pour son SaaS en 2026 replace ce choix dans l’ensemble de la stack.

Pourquoi le cloud computing est devenu le standard

La scalabilité d’abord. Si votre application passe de 100 à 10 000 utilisateurs en une semaine, la capacité s’augmente en quelques minutes, sans acheter de serveurs ni attendre une livraison. C’est ce qui rend la montée en charge accessible même à une petite équipe.

La fiabilité ensuite. Les grands fournisseurs garantissent contractuellement une disponibilité de 99,9 % ou plus, avec des mécanismes de redondance et de sauvegarde intégrés. Atteindre ce niveau avec sa propre infrastructure coûterait beaucoup plus cher.

Le modèle économique aussi : on ne paie que ce qu’on consomme. Une startup en démarrage paie quelques dizaines d’euros par mois. Une scale-up en forte croissance paie davantage, mais en proportion de son usage réel, sans investissement initial massif.

La rapidité enfin. Créer un serveur, une base de données ou un espace de stockage prend quelques minutes, et les datacenters répartis sur tous les continents permettent de déployer l’application au plus près de ses utilisateurs, en Europe comme en Asie ou aux États-Unis, par simple configuration.

Multi-cloud, cloud hybride, cloud souverain

Le multi-cloud consiste à combiner plusieurs fournisseurs : AWS pour l’hébergement principal et GCP pour le machine learning, par exemple. Cette approche réduit la dépendance à un seul acteur, mais ajoute une vraie complexité opérationnelle. Pour la majorité des startups SaaS, un seul fournisseur suffit largement.

Le cloud hybride mélange cloud et serveurs sur site (on-premise). Certaines entreprises conservent leurs données sensibles sur leurs propres machines et utilisent le cloud pour le reste. C’est courant dans les secteurs réglementés comme la santé, la finance ou la défense, où la localisation des données est une contrainte légale.

Le cloud souverain répond à une préoccupation devenue centrale en Europe : les fournisseurs américains sont soumis au CLOUD Act, qui permet aux autorités des États-Unis d’exiger l’accès à des données qu’ils hébergent, y compris dans leurs datacenters européens. Pour les données les plus sensibles, des offres qualifiées SecNumCloud par l’ANSSI existent chez des acteurs français. Pour un SaaS B2B classique, héberger ses données dans une région européenne d’AWS, GCP ou Azure répond à l’essentiel des exigences des clients, mais la question revient de plus en plus souvent dans les appels d’offres.

Coûts, vendor lock-in, sécurité : les points de vigilance

Le coût est le piège le plus courant. Une ressource oubliée (un serveur de test resté allumé, une base de démonstration qui tourne depuis six mois) génère une facture silencieuse. Configurer des alertes de coût dès le premier jour est indispensable. C’est le point de départ du FinOps, la discipline qui consiste à piloter les dépenses cloud comme un budget à part entière.

La dépendance au fournisseur (vendor lock-in) est un risque réel. Plus on utilise de services propriétaires (fonctions serverless, files d’attente maison, services d’IA intégrés), plus la migration vers un autre fournisseur devient coûteuse. S’appuyer sur des technologies ouvertes comme Docker et Kubernetes et sur des bases de données standard limite ce risque.

La sécurité repose sur un principe souvent mal compris : la responsabilité partagée. Le fournisseur sécurise l’infrastructure physique et les services ; le client reste responsable de la configuration des accès, du chiffrement des données sensibles et du respect du RGPD. Une mauvaise configuration des permissions est l’une des premières causes de fuite de données dans le cloud.

La conformité réglementaire se vérifie en amont : dans quelles régions les données sont-elles stockées, et le fournisseur dispose-t-il des certifications attendues (ISO 27001, SOC 2, HDS pour les données de santé en France) ?

Les erreurs courantes

Ne pas surveiller les coûts. Une requête mal optimisée qui déclenche des milliers d’appels, un environnement de test laissé en marche : les surprises se découvrent sur la facture mensuelle, souvent trop tard.

Sur-dimensionner dès le départ. Provisionner une infrastructure capable de supporter un million d’utilisateurs quand on en a cent, c’est payer de la capacité inutile. Le cloud permet justement de commencer petit et de grandir progressivement.

Négliger les sauvegardes. Le cloud ne protège ni contre les erreurs humaines (une base de données supprimée par accident) ni contre les pannes régionales. Des sauvegardes régulières et un plan de reprise testé restent indispensables.

Tout configurer manuellement. À mesure que l’infrastructure grandit, la configuration à la main devient ingérable et source d’erreurs. L’infrastructure as code (Terraform, OpenTofu, CloudFormation) permet de versionner, reproduire et auditer chaque environnement.

Tout porter seul. Exploiter une infrastructure de production demande des compétences spécifiques et une astreinte. Quand l’équipe n’a pas ce profil en interne, déléguer l’exploitation est souvent plus sain que d’épuiser son CTO ; notre comparatif des sociétés d’infogérance cloud en France passe en revue les acteurs que nous recommandons.

FAQ cloud computing

Quelle différence entre cloud computing et hébergement classique ?

Un hébergement classique loue une machine fixe, avec une capacité et un prix déterminés à l’avance. Le cloud facture à l’usage des ressources qui s’ajustent à la demande, et propose en plus des services managés (bases de données, stockage, files d’attente) qu’un hébergeur traditionnel n’offre pas.

Combien coûte le cloud pour une startup ?

Quelques dizaines à quelques centaines d’euros par mois pour un SaaS en phase de lancement, selon l’architecture choisie. Les programmes de crédits comme AWS Activate ou Google for Startups peuvent couvrir les premiers mois, voire davantage. Le vrai sujet n’est pas le montant de départ mais la surveillance : c’est l’absence d’alertes qui rend les factures douloureuses.

Le cloud est-il compatible avec le RGPD ?

Oui, à condition de choisir des régions de stockage européennes et de configurer correctement les services. AWS, GCP et Azure proposent tous des régions en France ou en Europe. Pour les données les plus sensibles, les offres qualifiées SecNumCloud ou l’hébergement certifié HDS apportent des garanties supplémentaires.

Comment Polara Studio utilise le cloud

Chez Polara Studio, AWS est notre plateforme de référence. Chaque SaaS que nous développons est hébergé sur une infrastructure configurée pour la fiabilité, la performance et la maîtrise des coûts.

Nous utilisons les services managés d’AWS pour les composants critiques : RDS pour les bases de données PostgreSQL (sauvegardes automatiques, réplication), S3 pour le stockage de fichiers, CloudFront pour la distribution de contenu dans le monde entier, et ECS pour l’exécution des conteneurs Docker en production.

Notre infrastructure est définie en code, ce qui garantit que chaque environnement (développement, staging, production) est identique et reproductible. Combiné à notre pipeline de CI/CD, cela permet des déploiements fiables et rapides.

Notre approche est progressive : nous dimensionnons l’infrastructure au juste nécessaire au lancement, avec des mécanismes d’auto-scaling qui absorbent les pics de charge, et des alertes de coût et de performance configurées dès le premier jour. Nos clients ne paient jamais pour de la capacité inutile, avec la certitude que l’infrastructure suivra la croissance du produit.