Après plus d’un an chez Taleo, dans le logiciel livré en ligne, je regarde les serveurs autrement. Le client n’achète pas notre diagramme d’infrastructure. Il ouvre une session, lance une recherche et attend une réponse. Si cette recherche prend quinze secondes le lundi matin, toutes les machines peuvent répondre au ping et le service reste mauvais.

Le mot cloud devient concret quand on décrit ce trajet. Le navigateur résout un nom DNS, établit une connexion chiffrée, rejoint un répartiteur de charge, puis une instance de l’application. Celle-ci vérifie l’identité, lit ou modifie des données et appelle parfois d’autres services avant de retourner la page. La disponibilité ressentie dépend de toute cette chaîne, pas seulement de l’état du serveur web.

SaaS, hébergement et élasticité ne sont pas synonymes

Un produit SaaS est un logiciel exploité comme un service continu : une version gérée par le fournisseur, des clients servis à distance, un abonnement ou une entente d’usage et des opérations communes. Il peut rouler dans le centre de données privé du fournisseur. À l’inverse, une vieille application copiée sur une machine virtuelle louée reste une vieille application, avec ses sessions locales, son stockage attaché et ses fenêtres de maintenance.

Pour pouvoir ajouter une instance lorsqu’arrive une pointe, l’état de l’utilisateur ne doit pas rester prisonnier de la mémoire d’un serveur. Je séparerais donc :

• les requêtes web, qui peuvent aller vers n’importe quelle instance;
• la session, conservée dans un dépôt partagé ou encodée dans un jeton;
• les fichiers, placés dans un stockage commun;
• les travaux longs, envoyés dans une file;
• les données transactionnelles, protégées par la base et ses mécanismes de reprise.

Prenons une importation de 50 000 candidatures. Si la requête HTTP traite tout, elle peut dépasser le délai du proxy et être relancée par l’utilisateur, créant des doublons. Une meilleure séquence accepte le fichier, lui attribue un identifiant, écrit un message dans une file et répond immédiatement. Un worker traite ensuite le lot de façon idempotente : revoir le même identifiant ne doit pas importer deux fois les mêmes lignes.

Mesurer le service comme le vit le client

Je définirais un indicateur simple : 99,9 % des recherches doivent réussir en moins de deux secondes sur un mois. Ce n’est pas seulement une moyenne. Cent recherches à 200 ms et une à 60 secondes donnent une moyenne trompeuse; le 95e ou le 99e percentile montre mieux la longue traîne.

Les logs doivent relier les étapes avec un identifiant de corrélation : requête reçue, appel à la base, service externe, résultat et durée. Sans ce lien, on sait que plusieurs erreurs sont arrivées, pas si elles appartiennent à la même opération. Une sonde externe qui ouvre réellement une session complète le monitoring interne.

Les pannes ne disparaissent pas chez un fournisseur. Une zone peut devenir indisponible, le DNS peut être mal configuré, une limite d’API peut être atteinte ou une facture grimper parce qu’un traitement boucle. Il faut des timeouts, quelques reprises avec attente croissante, un disjoncteur pour cesser d’appeler une dépendance malade et une procédure testée pour restaurer les données. Réessayer une écriture sans clé d’idempotence est particulièrement dangereux.

Le contrat cloud doit enfin préciser la localisation des données, les responsabilités, les objectifs de service et la sortie : format d’export, délai, clés de chiffrement et suppression des copies. Une application fragile ne devient pas solide parce qu’elle roule ailleurs. Sur un vrai projet, je dessinerais le trajet d’une requête, lui associerais une mesure et forcerais au moins une panne contrôlée avant de parler d’élasticité.