Je suis un peu tanné des débats où le cloud est soit l’avenir de tout, soit une irresponsabilité complète. Une architecture se juge mieux avec une charge précise, un niveau de service et un mécanisme de sortie. Je choisirais donc un petit système réversible et je mesurerais ce qui se passe réellement.

Un bon candidat serait un traitement de rapports non critique. Un utilisateur dépose un fichier, un service l’envoie dans une file, des workers produisent les rapports et les placent dans un stockage objet. Le nombre de workers peut varier sans déplacer la base transactionnelle principale.

Le test doit répondre à des questions écrites

Avant de créer la première machine, je fixerais ce protocole :

1. déployer l’environnement depuis un script ou un modèle;
2. traiter un lot connu de 10 000 lignes;
3. couper un worker pendant le traitement;
4. augmenter la charge jusqu’au double prévu;
5. restaurer un résultat supprimé;
6. exporter données et configuration vers un emplacement indépendant;
7. détruire l’environnement et rapprocher la facture.

Les mesures incluent temps total, coût par lot, taux de reprise, volume réseau et effort d’exploitation. Le résultat n’est pas « le cloud fonctionne »; c’est « cette architecture traite ce lot avec tel coût et perd au plus telle quantité de travail ».

L’état doit être explicite. Les workers restent remplaçables; la file garde les messages non confirmés; le stockage conserve les résultats; une base garde les identifiants et statuts. Si un worker meurt après avoir écrit le fichier mais avant d’acquitter le message, un autre le reprendra. Une clé d’idempotence évite deux rapports différents pour la même demande.

Les limites font partie de l’essai

Le fournisseur impose quotas, tailles de message, délais et modèles de facturation. Une reprise agressive peut multiplier les transactions payantes. Une sortie de données volumineuse peut coûter plus que l’entrée. Je provoquerais donc les erreurs de quota et la perte réseau plutôt que de les découvrir en production.

La sécurité du plan de gestion compte autant que celle de l’application : comptes séparés, authentification forte, clés courtes, réseaux fermés par défaut et journaux exportés hors du compte principal. Le fichier d’entrée doit être chiffré et supprimé selon une durée définie.

Un test devient facilement une production cachée. Si des utilisateurs réels commencent à en dépendre, il faut une décision explicite : industrialiser avec support, sauvegarde et propriétaire, ou fermer. La date d’expiration et le centre de coût sont inscrits dès le départ.

Séparer le coût fixe du coût provoqué par l’usage

La facture du pilote doit être reliée aux métriques. Je répartirais calcul par heure, stockage au gigaoctet, opérations de file et trafic sortant, puis calculerais un coût par rapport produit. Une instance minimale toujours ouverte forme le plancher; les workers et transactions varient avec le volume. Le test inclut une journée sans travail pour repérer les ressources qui facturent encore et une charge anormale pour vérifier les alertes budgétaires. Ces chiffres permettent une comparaison avec le serveur existant sans prétendre que son coût est nul. Ils révèlent aussi l’architecture bavarde qui réalise cent opérations payantes lorsqu’une seule suffirait.

Je présenterais finalement un tableau comparant cette solution à l’hébergement actuel : disponibilité, reprise, délai de déploiement, coût stable et coût variable, compétences et dépendances. Un prototype utile ne cherche pas à confirmer une opinion. Il réduit l’incertitude sur un système assez petit pour qu’on puisse encore l’éteindre proprement.