La question qui me donne le plus confiance dans un projet cloud n’est pas « combien économise-t-on? », mais « que fait l’application lorsque l’instance ou le fournisseur ne répond plus? ». Le scepticisme devient utile lorsqu’il produit un test.

En 2009, il faut distinguer infrastructure louée et logiciel livré comme service. Avec une infrastructure comme EC2, nous choisissons l’image, configurons le système et déployons l’application. Le fournisseur opère le centre de données et l’hyperviseur. Avec un SaaS, le fournisseur opère aussi l’application et son cycle de versions. Dans les deux cas, notre responsabilité sur l’identité, les données et le plan de sortie ne disparaît pas.

IaaS : nous -> application -> système invité -> fournisseur -> matériel
SaaS : nous -> configuration et données -> fournisseur -> application + plateforme

Pour un pilote, je choisirais un traitement de rapports non critique. Les demandes entrent dans une file conservée hors de l’instance. Un worker loué prend une tâche, lit les données, produit le rapport dans un stockage durable, puis confirme la tâche. Si l’instance tombe avant la confirmation, le message redevient disponible.

demande -> file -> instance de calcul -> objet résultat
             ^          | panne
             `----------' reprise

L’opération porte un identifiant unique afin qu’une reprise ne facture ou ne publie pas deux fois le même rapport. Le worker localise ses entrées à partir de l’identifiant; il ne dépend pas d’un fichier laissé sur son disque éphémère.

Mesurer coût, perte et retour

Je noterais trois objectifs avant l’essai :

1. RTO : le traitement doit reprendre en moins de deux heures;
2. RPO : aucune demande confirmée ne peut être perdue;
3. sortie : toutes les données et résultats doivent être exportables en une journée.

On arrête ensuite l’instance au milieu d’une tâche, coupe temporairement l’accès réseau et restaure un résultat supprimé. Ces scénarios révèlent la file réellement durable, les timeouts trop longs et les clés d’accès présentes seulement sur une machine.

La facture doit inclure calcul, stockage, requêtes et transfert sortant. Une heure à bas prix est séduisante, mais un gros export régulier ou dix instances oubliées peut dominer le coût. J’ajouterais un propriétaire, une limite et une alerte de consommation avant de parler d’économie.

La sécurité demande des clés distinctes par service, des droits minimaux et un journal des opérations administratives. Une clé intégrée dans l’image se retrouve dans toutes ses copies. Le stockage doit être privé par défaut, et le pilote doit tenter un accès anonyme pour vérifier qu’une politique n’a pas ouvert les résultats.

Enfin, la disponibilité du fournisseur n’est pas notre disponibilité. Si le réseau du bureau tombe, un service sain demeure inaccessible. Si une région a un problème, une copie dans le même domaine de panne n’est pas une reprise. Je veux connaître le périmètre exact avant de promettre quoi que ce soit.

Je commencerais petit, puis je provoquerais les pannes et exporterais tout avant de décider. Les bonnes questions ne ralentissent pas le cloud : elles transforment un serveur loué en architecture qu’une équipe sait exploiter et quitter.