Cinquante pour cent de réduction sur votre moteur de base de données. Le chiffre atterrit en réunion de planification comme un cadeau providentiel. Quelqu'un fait le calcul de tête, multiplie par douze mois, et la salle décide collectivement qu'il s'agit de l'optimisation la plus simple qu'elle aura jamais à réaliser. Le bon de commande est signé. Et lentement, silencieusement, le véritable coût de cette décision commence à se révéler — non pas en euros économisés, mais en performances dégradées, en architecture compromise et en flexibilité sacrifiée.

Les Reserved Instances sont le plus ancien levier de rate optimization du cloud. Elles en sont aussi le plus mal compris.

L'anatomie d'une bonne affaire

Les fournisseurs cloud proposent des commitment-based discounts à travers différents mécanismes — Reserved Instances chez AWS et Azure, Committed Use Discounts chez GCP. La proposition est limpide : engagez-vous sur un type de ressource précis pour un à trois ans, et bénéficiez d'une remise substantielle sur le coût de calcul. Trente pour cent sur un an. Cinquante pour cent ou davantage sur trois ans.

Sur un tableur, cela ressemble à de l'argent gratuit. En production, c'est rarement le cas.

La première chose à comprendre est ce que la remise couvre réellement. Une remise Reserved Instance s'applique au moteur de calcul — et uniquement au moteur de calcul. Elle ne couvre pas le stockage. Elle ne couvre pas les opérations d'entrée-sortie. Elle ne couvre pas le transfert réseau. Elle ne couvre ni les sauvegardes ni les snapshots. Pour une charge de travail de base de données, ces composants représentent couramment quarante à soixante pour cent du coût total.

Cette remise de cinquante pour cent sur votre moteur de base de données ? Appliquez-la au coût réel d'exploitation de cette base — calcul, stockage, réseau, sauvegardes — et la remise effective tombe quelque part entre vingt et trente pour cent. Toujours significatif, mais une proposition fondamentalement différente de celle qui a suscité l'enthousiasme en réunion.

Le réflexe du sur-provisionnement

C'est ici que l'équation économique se détériore davantage. Lorsque vous vous engagez sur une taille d'instance spécifique pour un à trois ans, l'instinct naturel est de provisionner pour l'avenir. Personne ne souhaite se retrouver verrouillé sur une instance sous-dimensionnée, sans aucune possibilité de changement pendant trente-six mois. Alors on provisionne plus large. On ajoute de la marge. On achète l'instance dont on pense avoir besoin dans dix-huit mois, pas celle dont on a besoin aujourd'hui.

Ce sur-provisionnement n'est pas irrationnel. C'est une réponse logique à un engagement inflexible. Mais cela signifie que vous payez un tarif réduit sur de la capacité que vous n'utilisez pas. La remise se réduit. Le gaspillage augmente. Et le tableur qui a justifié l'achat devient progressivement fictif.

La cascade de consolidation

Les instances réservées sur-provisionnées créent leur propre force gravitationnelle. Vous avez payé pour un moteur de base de données surdimensionné. Il est là, sous-utilisé. L'étape logique suivante ? Consolider. Migrer d'autres bases de données sur le même moteur pour maximiser l'utilisation de la capacité déjà engagée.

C'est là que les véritables dégâts commencent.

Des bases de données spécifiques à un domaine se retrouvent fusionnées sur des instances partagées. La base d'authentification partage un moteur avec le pipeline analytique. Le registre transactionnel cohabite avec le système de reporting. Chaque migration semble sensée prise isolément — pourquoi payer des moteurs séparés quand on dispose de capacité inutilisée ?

Mais les bases de données ne sont pas des charges de travail interchangeables. Elles ont des profils d'accès, des besoins en mémoire et des caractéristiques CPU fondamentalement différents. Lorsque vous consolidez des charges de travail hétérogènes sur un même moteur, vous créez de la contention. Les cycles CPU qui devraient servir des requêtes transactionnelles sont consommés par des analyses de masse. La mémoire qui devrait contenir les index chauds d'un domaine est vidée par les chargements de données d'un autre. Les entrées-sorties de stockage deviennent un goulot d'étranglement tandis que des charges de travail concurrentes se disputent le débit.

Le résultat est prévisible : des performances dégradées sur l'ensemble des charges hébergées par cette instance partagée. Les temps de réponse augmentent. Des délais d'expiration apparaissent. Les équipes applicatives commencent à construire des contournements — couches de cache, optimisations de requêtes, logiques de relance — pour compenser une décision d'infrastructure dictée par la comptabilité analytique, pas par l'architecture.

L'impôt sur la performance que vous n'avez jamais budgété

L'ironie est chirurgicale. Vous avez réservé une instance pour économiser. La réservation a conduit au sur-provisionnement. Le sur-provisionnement a conduit à la consolidation. La consolidation a conduit à la dégradation des performances. Et la dégradation des performances a conduit à du temps d'ingénierie consacré à éteindre des incendies — un temps qui a un coût réel, même s'il n'apparaît jamais sur la facture cloud.

L'économie de la réservation est devenue un impôt sur la performance. Et contrairement à la facture cloud, cet impôt est invisible pour quiconque n'est pas au plus près des systèmes de production. La direction financière voit la remise. L'ingénierie subit la douleur. Et personne ne fait le lien parce que les deux sont mesurés sur des tableaux de bord différents.

L'alternative : le dimensionnement juste et la spécialisation

Il existe un chemin plus efficace vers l'optimisation des coûts de bases de données, et il n'exige pas de s'enfermer dans un engagement pluriannuel.

Le dimensionnement juste (right-sizing) consiste à ajuster en permanence la capacité de vos instances à votre charge de travail réelle. Pas celle que vous imaginez avoir dans deux ans — celle que vous avez aujourd'hui, avec une marge raisonnable pour la croissance organique. Les environnements cloud modernes rendent cet ajustement simple. Vous pouvez monter en charge verticalement ou horizontalement, changer de famille d'instances et vous adapter à des schémas d'utilisation changeants sans la rigidité d'une réservation.

Les bases de données spécialisées signifient choisir le bon moteur pour la bonne charge de travail. Une base relationnelle pour l'intégrité transactionnelle. Un magasin de documents pour les schémas flexibles. Une base de séries temporelles pour les métriques et la télémétrie. Un stockage en colonnes pour l'analytique. Chaque moteur optimisé pour son profil d'accès spécifique, dimensionné à sa juste taille, coûtant exactement ce que la charge de travail exige.

Cette approche demande davantage de rigueur architecturale que la consolidation de l'ensemble sur un unique moteur réservé. Elle produit aussi de meilleures performances, un coût total inférieur et une flexibilité incomparablement supérieure.

Quand les réservations ont réellement du sens

Rien de tout cela ne signifie que les réservations sont intrinsèquement mauvaises. Elles constituent un outil légitime de rate optimization — lorsqu'elles sont appliquées aux bonnes circonstances.

Les réservations ont du sens lorsque vous disposez d'une visibilité réelle sur vos profils d'utilisation. Pas des projections. Pas des estimations. Une utilisation réelle, observée sur une période étendue. Si vous exploitez une charge de travail depuis deux ans et que vous connaissez son profil de consommation et son taux de croissance avec confiance, une réservation sur cette base stable est une décision financière pertinente. C'est, en fait, précisément le cas d'usage que les fournisseurs cloud décrivent dans leur propre documentation. Des charges de travail stables, prévisibles, bien comprises.

Le problème est que la plupart des organisations appliquent les réservations bien trop tôt dans leur parcours cloud — avant de disposer des données d'utilisation nécessaires à des engagements éclairés. Elles achètent des contrats à terme sur des charges de travail qu'elles comprennent à peine.

Un mot sur les AWS Compute Savings Plans

AWS a introduit les Savings Plans comme alternative plus flexible aux Reserved Instances traditionnelles, et ils méritent une attention particulière. Contrairement aux RI, qui vous verrouillent sur un type d'instance, une taille et une région spécifiques, les Compute Savings Plans s'appliquent à travers les familles d'instances, les tailles, les régions, et même entre EC2, Fargate et Lambda. La remise porte sur l'ensemble de vos dépenses de calcul, pas sur une ressource précise.

Cette flexibilité inter-ressources répond à bon nombre des problèmes de rigidité qui rendent les réservations traditionnelles risquées. Vous pouvez changer de type d'instance, migrer entre régions et déplacer des charges de travail entre services — tout en conservant votre remise engagée. C'est un instrument significativement plus adapté aux organisations dont les architectures évoluent dans le temps, c'est-à-dire la quasi-totalité d'entre elles.

Si votre organisation envisage des commitment-based discounts, les Compute Savings Plans devraient être le point de départ de cette conversation, pas l'après-coup.

La discipline de savoir ce que l'on dépense

Le piège de la réservation est en définitive le symptôme d'un problème plus profond : prendre des engagements financiers sur des ressources cloud sans comprendre suffisamment la manière dont ces ressources sont réellement consommées. C'est une décision de rate optimization prise en l'absence d'usage optimization — et la rate optimization sans l'usage optimization n'est que de la conjecture avec une remise.

Avant de vous engager, dimensionnez juste. Avant de consolider, comprenez vos profils de charge. Avant de signer un accord sur trois ans, demandez-vous si vous parieriez votre architecture sur les mêmes choix technologiques pendant toute cette durée.

La meilleure remise est celle qui s'applique à une charge de travail que vous comprenez véritablement. Tout le reste est une bonne affaire que vous ne pouvez pas vous permettre.

manneken think accompagne les organisations pour distinguer les véritables opportunités d'optimisation des illusions coûteuses — car la remise la plus dangereuse est celle qui semble trop belle pour être questionnée.