ProsperOps et l'automatisation des Savings Plans : ROI réel, pièges et cas où ça ne vaut pas le coup

Notre arbre de décision Savings Plans vs Reserved Instances répond à la question « quel mécanisme d’engagement choisir ». Celui-ci répond à une question différente, posée par plusieurs clients en mission FinOps cet été : faut-il payer un outil tiers pour piloter ces engagements à leur place ? ProsperOps est le nom qui revient le plus souvent — c’est l’acteur historique de l’« Autonomous Discount Management » sur AWS, Azure et Google Cloud. La proposition est séduisante sur le papier : zéro intervention humaine, achat continu, rien à configurer. Le prix à payer, littéralement, mérite d’être détaillé avant de signer.

Le problème réel : un engagement figé une fois par an sous-optimise presque toujours

La gestion manuelle des Savings Plans souffre d’un défaut structurel simple : elle se fait par à-coups. Une équipe FinOps ou infra regarde sa facture une à deux fois par an, calcule un engagement basé sur l’usage des 3 derniers mois, achète un Compute Savings Plan pour 1 ou 3 ans, puis n’y retouche plus jusqu’à l’échéance suivante. Entre deux revues, deux choses se passent : l’usage réel dérive (montée en charge, migration Graviton, arrêt d’un service), et une partie de la facture reste non couverte parce que personne n’a le temps de recalculer chaque mois le delta entre engagement et consommation.

Les chiffres AWS eux-mêmes montrent l’écart entre les mécanismes : un Compute Savings Plan sur 3 ans réduit la facture jusqu’à 66 %, un EC2 Instance Savings Plan jusqu’à 72 %, mais uniquement si le taux de couverture — la part de l’usage effectivement couverte par l’engagement — reste élevé en continu. Un engagement acheté en janvier et jamais réajusté voit typiquement sa couverture se dégrader de plusieurs points par trimestre sur une infra qui bouge. C’est ce delta, pas le taux de remise affiché par AWS, que les outils d’automatisation vendent en réalité.

Comment fonctionne l’automatisation ProsperOps (Autonomous Discount Management)

ProsperOps ne remplace pas les mécanismes AWS natifs — il les pilote en continu à travers trois couches, décomposées explicitement dans son contrat client :

• Inherited Savings : les économies déjà générées par les Reserved Instances et Savings Plans que le client avait achetés lui-même avant l’onboarding — ProsperOps ne les facture pas comme sa propre performance, mais les intègre au calcul de couverture globale.
• Base Savings : les Compute Savings Plans achetés en gros par ProsperOps pour le compte du client, sur la base d’un socle d’usage jugé stable.
• Smart Savings : la couche différenciante — un mécanisme de laddering adaptatif, qui achète et fait tourner des tranches de Compute Savings Plans mensuelles plutôt qu’un engagement unique figé, en recalculant chaque mois la meilleure combinaison de durées et de tailles de tranches.

Le laddering ne change pas le taux de remise unitaire négocié avec AWS — ce taux est fixé par AWS, pas par ProsperOps. Ce qu’il change, c’est la vitesse de réaction : au lieu d’un engagement décidé une fois par an sur une prévision, on a douze décisions par an sur de l’usage déjà observé, ce qui réduit le risque de sur-engagement (capacité payée mais non consommée) sans sacrifier la couverture. Le module complémentaire, Autonomous Resource Management (ARM), pousse la logique côté rightsizing des ressources elles-mêmes, mais reste pour l’instant réservé aux clients déjà sur l’offre Compute ADM.

Le modèle de prix : Savings Share, pas un abonnement

ProsperOps ne facture pas un abonnement fixe ni un pourcentage de la facture cloud totale — c’est un point qui mérite d’être vérifié en amont avec chaque prospect car la confusion est fréquente. Le modèle facturé s’appelle Savings Share : un pourcentage appliqué uniquement aux économies réellement constatées par le système de facturation AWS, avec un taux différent selon qu’il s’agit d’Inherited, Base ou Smart Savings (les couches Smart Savings, à plus forte valeur ajoutée, sont facturées au taux le plus élevé).

Le taux exact n’est pas publié — il se négocie par contrat, et varie selon le volume d’usage. À titre d’ordre de grandeur, si le contrat prévoit un taux de 25 % sur une couche donnée et que ProsperOps génère 100 000 € d’économies mensuelles sur cette couche, la facture ProsperOps correspondante est de 25 000 €, nets 75 000 € d’économie réelle pour le client. Les analyses tierces publiées en 2026 évoquent des fourchettes de 20 à 35 % selon la couche et le contrat — à vérifier au cas par cas, jamais à prendre pour acquis sur un devis. Le seuil de rentabilité couramment cité par les intégrateurs qui vendent l’outil : en-dessous d’environ 10 000 €/mois de facture compute AWS, les économies brutes générées ne justifient généralement pas la mise en place (temps d’onboarding, revue contractuelle, facturation continue à surveiller).

Le calcul qui compte réellement pour une organisation : ROI net face au Cost Optimization Hub

C’est le point le plus souvent zappé dans les argumentaires commerciaux : AWS propose depuis 2024 un outil natif et gratuit, Cost Optimization Hub, qui consolide les recommandations de Compute Optimizer, Trusted Advisor et Cost Explorer, y compris les préférences de durée (1 ou 3 ans) et de mode de paiement pour les Savings Plans et réservations. Ce n’est pas un outil d’exécution automatique — il recommande, il n’achète pas, et il ne fait pas de laddering mensuel — mais pour une organisation dont l’infra est stable et suivie par une personne dédiée, il couvre une bonne partie du problème à coût nul.

Le calcul de ROI d’un outil comme ProsperOps se résume donc à une question : combien vaut, en argent, le fait de ne pas avoir à exécuter soi-même la recommandation chaque mois ? Pour une infra AWS de 30-80 000 €/mois avec un usage qui bouge (scaling irrégulier, migrations fréquentes, plusieurs comptes), l’écart de couverture entre un engagement figé et un laddering mensuel peut représenter plusieurs points de facture — largement supérieur à la Savings Share prélevée. Pour une infra stable de moins de 15-20 000 €/mois avec un mix d’instances qui ne change quasiment jamais, l’écart est marginal, et le Cost Optimization Hub couplé à une revue trimestrielle humaine capture l’essentiel de la valeur sans reverser 20-35 % des économies à un tiers.

Le paysage concurrentiel : ProsperOps n’est pas seul sur ce terrain

ProsperOps reste la référence historique sur l’automatisation pure des engagements de calcul, mais le terrain s’est densifié. nOps revendique un delta de performance additionnel via une optimisation plus fine à l’heure plutôt que sur des engagements plus longs, avec un positionnement prix comparable en Savings Share. DoiT International (FlexSave) applique une logique proche mais l’adosse à sa position de revendeur AWS, ce qui change la structure de facturation. Les outils FinOps généralistes couverts dans notre comparatif Vantage / CloudZero / Cloudability donnent de la visibilité sur l’allocation des coûts mais n’achètent pas d’engagements à la place du client — ce sont des couches complémentaires, pas concurrentes, à celle de ProsperOps.

Recommandation pour une organisation AWS

Trois cas concrets, issus de nos audits :

• Infra stable, moins de 15-20 000 €/mois, une personne suit déjà les coûts : Cost Optimization Hub + revue trimestrielle suffit. Payer une Savings Share n’a pas de sens économique.
• Infra qui bouge (montée en charge, migrations, plusieurs comptes), 30 000 €/mois et plus, personne n’a le temps de recalculer les engagements chaque mois : l’automatisation a un vrai cas d’usage — le coût de la Savings Share reste net inférieur au delta de couverture perdu par une gestion manuelle trimestrielle.
• Entre les deux, ou avant tout engagement contractuel : un audit DevSecOps chiffre le delta réel de couverture sur votre historique de facturation avant de signer quoi que ce soit avec un tiers — c’est un chiffre vérifiable en quelques heures avec l’API Cost Explorer, pas une estimation.

La question n’est jamais « l’automatisation fonctionne-t-elle » — elle fonctionne, le mécanisme de laddering est solide et documenté. La question est « le delta qu’elle capture sur votre infra dépasse-t-il la part qu’elle en prélève ». Sur une infra stable, souvent non. Sur une infra qui bouge sans personne dédié pour la suivre, souvent oui.