FinOps, c'est quoi ? Définition 2026, méthode et par où commencer

La facture cloud d'une scale-up peut grossir plus vite que la capacité de quiconque à l'expliquer. La direction financière voit une ligne qui augmente chaque trimestre sans savoir quel produit la porte ; la direction technique sait quelles équipes consomment, mais pas ce que cela coûte par client ; chaque reprise en main risque de finir en campagne d'économies que le trimestre suivant efface. Le FinOps répond à ce problème, à condition de le prendre pour ce qu'il est : une pratique de pilotage partagée, pas un outil ni une chasse ponctuelle aux économies.

Cet article donne la définition en vigueur, la structure du cadre, puis une méthode pour les 30 premiers jours (allocation, rapport par produit, engagements, coût unitaire) et les indicateurs à suivre dès le départ. Cette lecture est établie sur le FinOps Framework dans sa mise à jour de mars 2026 et sur la spécification FOCUS 1.4 ; les pages officielles citées ont été vérifiées le 28 septembre 2026.

Ce qu'est le FinOps en 2026, et ce qu'il n'est pas

La définition officielle, et le mot qui a changé

La FinOps Foundation, qui maintient le cadre de référence, publie cette définition :

« FinOps is an operational framework and cultural practice which maximizes the business value of technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams. »

En traduction libre : le FinOps est un cadre opérationnel et une pratique culturelle qui maximise la valeur métier de la technologie, permet une prise de décision rapide fondée sur les données et crée une responsabilité financière grâce à la collaboration entre ingénierie, finance et métiers.

Début 2026, la FinOps Foundation a remplacé un mot dans sa mission : « cloud » est devenu « technologie ». Pour une scale-up, le changement est pratique : abonnements SaaS (observabilité, intégration continue), plateforme de données facturée à la consommation ou services d'IA facturés au jeton relèvent du même exercice que la facture AWS, Azure ou Google Cloud. Le cadre les range en cinq catégories technologiques : cloud public, SaaS, data center, plateformes de données cloud et IA.

La mise à jour du cadre présentée en mars 2026 ajoute une capacité, Executive Strategy Alignment, qui relie la dépense technologique à la stratégie de l'entreprise pour aider la direction à comparer les options et à arbitrer. Elle renomme plusieurs capacités, dont Workload Optimization devenue Usage Optimization et Policy & Governance devenue Governance, Policy & Risk. Elle approfondit la notion de périmètre (scope), un segment de la dépense technologique auquel on applique la démarche, et décrit la coordination avec les disciplines voisines : gestion des actifs informatiques (ITAM), gestion financière de l'informatique (ITFM), gestion des services informatiques (ITSM), durabilité, sécurité et architecture d'entreprise.

Ce que le FinOps n'est pas

• Pas un outil. L'outillage est une capacité parmi plus d'une vingtaine ; sans propriétaires désignés, un tableau de bord n'est piloté par personne.
• Pas une campagne d'économies. Un principe du cadre pose que la valeur métier guide les décisions technologiques et que les métriques unitaires montrent mieux l'impact qu'une dépense agrégée. Une facture qui croît avec le chiffre d'affaires peut être saine ; un coût par client qui dérive ne l'est pas.
• Pas une fonction qui dit non. Le cadre pose que chacun est responsable de son usage de la technologie ; la fonction centrale facilite.

La structure du cadre

Phases et maturité : deux axes distincts

Beaucoup de résumés présentent Crawl, Walk, Run comme les phases du FinOps. Ce n'est pas ce que dit le cadre. Les phases situent une décision dans la boucle : Inform examine l'état actuel de l'usage et des coûts ; Optimize identifie et documente les améliorations possibles ; Operate donne aux équipes les moyens d'appliquer les changements, puis on revient à Inform. La maturité mesure la qualité d'exécution d'une capacité : une organisation au niveau Crawl réagit surtout aux problèmes après coup, une pratique au niveau Run intègre le coût dès ses choix d'architecture et ses processus d'ingénierie. Le cadre précise que l'objectif n'est jamais d'atteindre Run dans chaque capacité, mais le niveau adapté à son contexte. Une organisation peut ainsi être en phase Optimize sur ses engagements AWS et en phase Inform sur ses dépenses d'IA, au niveau Crawl en allocation et Walk ailleurs.

FOCUS, le format commun des données de coût

La FinOps Foundation porte aussi FOCUS (FinOps Open Cost and Usage Specification), un schéma commun pour les données de facturation. À la date du 28 septembre 2026, la version publiée est la 1.4, ratifiée le 4 juin 2026 ; elle ajoute les jeux de données Invoice Detail (les charges telles qu'elles figurent sur les factures) et Billing Period (les périodes de facturation et leur statut), et le périmètre publié de la version 1.5 prévoit d'exposer l'identité des modèles d'IA et la consommation de jetons. Deux colonnes intéressent d'abord la direction financière : BilledCost, la base de facturation, dont la somme sur une période doit correspondre aux factures reçues, et EffectiveCost, le coût amorti qui intègre la part des achats prépayés. Attention au décalage de versions : AWS Data Exports propose à la même date des tables FOCUS 1.0 et FOCUS 1.2. La lecture des coûts AWS et leur rapprochement avec la facture sont traités dans « Coût facturé, coût amorti, crédits : réconcilier des montants AWS qui ne tombent jamais juste ».

Qui fait quoi : ingénierie, finance, direction

Les six personas principaux du cadre (praticien FinOps, ingénierie, finance, produit, achats, direction) existent rarement comme postes distincts dans une scale-up de 20 à 200 personnes. Les achats peuvent être portés par la direction administrative et financière (DAF) ou un fondateur, et le rôle de praticien FinOps n'est pas forcément un temps plein. Ce qui compte est l'existence d'un référent FinOps nommé, avec un mandat écrit de la direction : responsable plateforme, directeur technique (CTO) ou contrôleur de gestion à l'aise avec les données techniques. Sans ce nom, le principe d'une pratique facilitée par une fonction centrale reste théorique.

La répartition ci-dessous, recommandation de méthode, évite deux échecs : la finance qui découvre les engagements sur la facture, et l'ingénierie qui reçoit des objectifs d'économies sans les données.

Le rituel central est une revue mensuelle courte, tenue après l'émission de la facture du mois précédent, où chaque propriétaire explique ses principales variations. La FinOps Foundation propose des certifications, dont FinOps Certified Practitioner ; elles aident le référent mais ne remplacent ni l'accès aux données ni le mandat de la direction.

Les 30 premiers jours : quatre livrables, dans cet ordre

Le découpage est indicatif : quatre semaines, un livrable par semaine. L'ordre compte plus que le rythme : un coût unitaire calculé avant l'allocation divise un chiffre faux par un chiffre juste, et un engagement acheté avant d'avoir mesuré l'usage fige une hypothèse pour un ou trois ans. Prérequis : un accès en lecture seule à la facturation (sur AWS, la politique gérée AWSBillingReadOnlyAccess) et un export actif, Cost and Usage Report 2.0 (CUR 2.0) ou FOCUS.

Semaine 1 : allocation et étiquetage

Le cadre définit l'allocation comme la répartition des coûts vers ceux qui sont responsables de chaque composante, directement ou comme élément partagé. La structure d'abord, les étiquettes ensuite : un compte ou un abonnement par produit et par environnement attribue la dépense sans dépendre de la discipline de chaque équipe. Une taxonomie de départ tient en quatre clés sans accents, à casse figée : produit, environnement, equipe, centre-de-cout. Trois comportements de plateforme fixent le calendrier :

• AWS : une clé d'étiquette met jusqu'à 24 heures pour apparaître dans la console des étiquettes de répartition des coûts, puis jusqu'à 24 heures pour s'activer. Le compte de gestion peut demander un rattrapage sur douze mois au plus, une fois par 24 heures, pour des étiquettes réellement présentes sur les ressources pendant la période.
• Azure : pour les contrats Enterprise Agreement et Microsoft Customer Agreement, l'héritage d'étiquettes de Cost Management applique les étiquettes de facturation, d'abonnement et de groupe de ressources (et, en Microsoft Customer Agreement, de profil de facturation et de section de facture) aux enregistrements d'usage des ressources enfants, sans modifier les ressources elles-mêmes, sous 24 heures, pour le mois en cours.
• Google Cloud : dans l'export de facturation BigQuery, un libellé ne porte les coûts qu'à partir de sa date de pose sur la ressource (à partir du jour suivant si le libellé est posé en cours de journée).

Les tag policies d'AWS Organizations standardisent les clés, mais n'évaluent pas les ressources sans étiquette ; pour exiger une étiquette à la création, la documentation fournit un exemple de politique de contrôle des services (SCP) qui refuse ec2:RunInstances sans aws:RequestTag/Project, à tester avant déploiement. Pour les coûts qu'aucune étiquette ne porte (support, réseau, clusters mutualisés), AWS Cost Categories regroupe par règles, avec une date d'effet fixée par défaut au mois en cours. Les règles de répartition des charges partagées n'apparaissent que sur la page de détail de la catégorie, ni dans Cost Explorer ni dans les rapports de coûts : la règle doit donc être publiée avec le rapport.

Livrable : la carte d'allocation (compte ou étiquette vers produit, équipe, centre de coût), la liste des coûts partagés avec leur règle, et un premier taux de coût alloué.

Semaine 2 : un premier rapport de coûts par produit

Le rapport se construit en lecture amortie (EffectiveCost en FOCUS, AmortizedCost dans Cost Explorer) : en lecture non combinée, le paiement initial d'une réservation All Upfront ou Partial Upfront apparaît en une seule ligne, le mois de l'achat. Pour chaque produit : coût du mois, variation, explication signée par le propriétaire ; plus deux lignes souvent cachées à tort, les coûts partagés et le non alloué.

Activez le même mois un moniteur d'anomalies, qui est un filet et non un rapport : AWS Cost Anomaly Detection analyse le coût net non combiné environ trois fois par jour, avec jusqu'à 24 heures de délai, et demande dix jours d'historique pour un service nouvellement utilisé. Pour l'observabilité facturée hors du fournisseur cloud, par exemple la facturation d'un outil d'observabilité SaaS sur Kubernetes, la même logique d'allocation et d'explication s'applique.

Livrable : le rapport du mois, publié à date fixe, avec la liste des ressources non allouées adressée à leurs équipes probables.

Semaine 3 : la couverture des engagements existants

L'inventaire recense chaque Savings Plan et chaque réservation : type, durée, mode de paiement, échéance. Deux mesures AWS se lisent ensemble : la couverture, part des dépenses éligibles couverte par des Savings Plans, et l'utilisation, part de l'engagement acheté réellement consommée. Couverture haute et utilisation basse : engagement surdimensionné. Couverture basse et utilisation pleine : marge d'engagement à instruire.

La FinOps Foundation souligne l'interdépendance entre optimisation des tarifs et optimisation de l'usage : un engagement pris sur des ressources ensuite réduites peut être payé sans être consommé jusqu'à son terme, et les deux chantiers peuvent compter deux fois la même économie. D'où la règle : stabiliser l'usage avant d'engager, et n'engager que sur la consommation présente dans tous les scénarios.

Ajoutez les coûts qui apparaissent sans changement d'usage : une version Kubernetes sur Amazon Elastic Kubernetes Service (EKS) reste 14 mois en support standard, puis 12 mois en support étendu facturé en supplément par heure de cluster ; le support étendu d'Amazon Relational Database Service (RDS) est facturé à partir du lendemain de la fin du support standard. Ces échéances se suivent comme des engagements, avec leur date et leur propriétaire.

Livrable : un tableau des engagements (échéances, couverture, utilisation) et une recommandation argumentée, sans achat pendant ces 30 jours.

Semaine 4 : un seul coût unitaire

Le cadre décrit des métriques unitaires techniques (coût par Go, par processeur virtuel, par jeton) et métier (coût par client ou par locataire), et indique qu'au niveau Crawl elles sont surtout techniques.

Choisissez-en une seule avec la finance et le produit, sur un dénominateur déjà suivi (clients actifs, transactions) dont la définition ne changera pas. Le numérateur est le coût amorti alloué au produit, coûts partagés compris ; les exclusions sont écrites. La formule tient en une ligne : coût amorti alloué au produit sur le mois, divisé par le nombre de clients actifs du même mois. C'est la tendance, rapprochée du prix de vente, qui dit si la croissance de la facture est saine.

Livrable : une fiche de définition (numérateur, dénominateur, sources, exclusions, propriétaire) et la première valeur.

Mesurer : les indicateurs utiles au début, et ceux à éviter

Au démarrage, peu d'indicateurs, chacun avec un propriétaire. Ces cinq indicateurs clés de performance (KPI) couvrent l'essentiel d'une première année.

Le modèle de maturité de la FinOps Foundation publie aussi des exemples d'indicateurs par niveau : ce sont des repères à situer dans votre contexte, pas des objectifs à recopier. À éviter au début :

• Les « économies réalisées » comme indicateur principal : une économie est l'écart avec un scénario qui n'a pas eu lieu, et tarifs et usage revendiquent souvent la même somme.
• La baisse de la facture totale comme objectif : la facture doit suivre l'activité ; le coût unitaire dit si elle la suit bien.
• Le nombre de recommandations traitées : il récompense le volume et pousse aux changements risqués.
• Un coût non combiné comparé mois à mois dès que des engagements existent, et tout indicateur sans propriétaire nommé.

Optimiser sans casser : right-sizing prudent et livrables d'une analyse externe

Une recommandation de réduction de taille (right-sizing) coûte peu à produire et cher à mal appliquer ; six garde-fous de méthode l'encadrent. Ils s'appuient ici sur AWS Compute Optimizer et Amazon Elastic Compute Cloud (EC2), mais leur logique vaut pour les autres fournisseurs.

1. Une fenêtre qui couvre un cycle complet. AWS Compute Optimizer exige au moins 30 heures de métriques sur les 14 derniers jours pour une instance EC2 : un minimum technique, pas une base de décision. Il propose des fenêtres d'observation de 14 jours (par défaut), 32 jours et 93 jours (payante), et sa documentation indique que 32 jours capturent les cycles mensuels.
2. Des percentiles hauts, jamais la moyenne. Compute Optimizer propose les seuils P90, P95 et P99.5 pour le processeur (CPU), avec P99.5 par défaut, et ajoute par défaut une marge de 20 % sur le processeur et sur la mémoire. Une moyenne basse masque les pointes qui font tomber un service.
3. La mémoire mesurée, ou la recommandation écartée. Compute Optimizer n'analyse la mémoire d'une instance EC2 que si l'agent CloudWatch est installé.
4. Les crédits CPU des instances T. Elles acquièrent des crédits à un rythme fixé par leur taille. En mode standard, crédits épuisés, l'instance redescend progressivement à son niveau de référence ; en mode illimité, si l'usage moyen sur 24 heures dépasse ce niveau, le surplus est facturé. Réduire ou basculer vers une instance T suppose de lire le solde de crédits.
5. L'engagement vérifié après changement. Réduire une ressource couverte peut faire baisser l'utilisation de l'engagement sans baisser la facture : couverture et utilisation se relèvent avant et après chaque lot.
6. Des économies exprimées en fourchettes, avec leurs hypothèses (tarif, part couverte, durée d'observation) et leur risque. Un montant unique donne une fausse précision.

Un accès en lecture seule, qui expire

Une analyse externe n'a besoin d'aucun droit d'écriture. Sur AWS, elle passe par un rôle entre comptes dont la politique de confiance exige un identifiant externe (sts:ExternalId), unique pour chaque client du tiers, mécanisme documenté contre le problème du « député confus ». La clé de condition globale aws:CurrentTime borne l'accès dans le temps.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "identifiant-fourni-par-le-tiers" },
        "DateLessThan": { "aws:CurrentTime": "2026-11-30T23:59:59Z" }
      }
    }
  ]
}

Le compte 111122223333 est celui des exemples de la documentation AWS et la date est illustrative. Les permissions restent en lecture, par exemple AWSBillingReadOnlyAccess et ComputeOptimizerReadOnlyAccess. La condition de date joue à la prise de rôle : des identifiants temporaires déjà émis restent valides jusqu'à leur expiration, bornée par la durée maximale de session du rôle (1 à 12 heures, 1 heure par défaut). En fin d'analyse, le rôle se supprime ; la date n'est qu'un filet.

Quand faire appel à une analyse externe, et ce qu'elle doit livrer

La méthode est faisable en interne. Un regard extérieur se justifie surtout face à une facture qui dérive sans explication, un engagement important à renouveler, une levée de fonds où la structure de coûts sera examinée, une migration ou une fin de support, ou l'absence de référent disponible. Une analyse utile laisse des livrables que l'équipe maintient seule :

• l'inventaire des comptes, exports et accès, et la carte d'allocation avec sa règle de coûts partagés ;
• un rapport par produit rapproché de la facture, écart résiduel publié ;
• l'analyse des engagements et une recommandation argumentée ;
• une liste priorisée de changements d'usage, chacun avec fourchette, hypothèses, risque et propriétaire ;
• un coût unitaire défini, les indicateurs de suivi, et la preuve que l'accès en lecture seule a été retiré.

Pour appliquer cette méthode à votre compte payeur, voir la page Audit FinOps : expliquer la facture.

Sources officielles et limites de lecture

Délais, fenêtres, seuils par défaut et versions d'export sont des faits datés, à revérifier avant toute décision ; les 30 jours décrivent un ordre de travail, pas une durée garantie. La comptabilisation des engagements et la refacturation interne relèvent de vos fonctions financières.

Sources

1. FinOps Framework Overview, FinOps Foundation, https://www.finops.org/framework/, consulté le 28/09/2026.
2. FinOps Framework 2026: Executive Strategy, Technology Categories, and Converging Disciplines, FinOps Foundation, https://www.finops.org/insights/2026-finops-framework/, consulté le 28/09/2026.
3. A One Word Change: How the FinOps Community Made Our Mission Evolution Inevitable, FinOps Foundation, https://www.finops.org/insights/mission-update/, consulté le 28/09/2026.
4. FinOps Principles, FinOps Foundation, https://www.finops.org/framework/principles/, consulté le 28/09/2026.
5. FinOps Domains, FinOps Foundation, https://www.finops.org/framework/domains/, consulté le 28/09/2026.
6. FinOps Capabilities, FinOps Foundation, https://www.finops.org/framework/capabilities/, consulté le 28/09/2026.
7. FinOps Phases, FinOps Foundation, https://www.finops.org/framework/phases/, consulté le 28/09/2026.
8. FinOps Maturity Model, FinOps Foundation, https://www.finops.org/framework/maturity-model/, consulté le 28/09/2026.
9. FinOps Personas, FinOps Foundation, https://www.finops.org/framework/personas/, consulté le 28/09/2026.
10. FinOps Technology Categories, FinOps Foundation, https://www.finops.org/framework/technology-categories/, consulté le 28/09/2026.
11. FinOps Scopes, FinOps Foundation, https://www.finops.org/framework/scopes/, consulté le 28/09/2026.
12. Allocation (capability), FinOps Foundation, https://www.finops.org/framework/capabilities/allocation/, consulté le 28/09/2026.
13. Unit Economics (capability), FinOps Foundation, https://www.finops.org/framework/capabilities/unit-economics/, consulté le 28/09/2026.
14. Rate Optimization (capability), FinOps Foundation, https://www.finops.org/framework/capabilities/rate-optimization/, consulté le 28/09/2026.
15. FinOps Practitioner Training & Certification, FinOps Foundation, https://www.finops.org/training-certification/recommended/practitioner/, consulté le 28/09/2026.
16. FOCUS Specification 1.4, FinOps Foundation, https://focus.finops.org/focus-specification/, consulté le 28/09/2026.
17. Introducing FOCUS 1.4: Invoice Reconciliation, Commitment Details, and Specification Maturity, FinOps Foundation, https://www.finops.org/insights/introducing-focus-1-4/, consulté le 28/09/2026.
18. Invoice Detail (dataset), FOCUS Specification 1.4, https://focus.finops.org/docs/specification/v1-4/datasets/invoice-detail, consulté le 28/09/2026.
19. Billed Cost (column), FOCUS Specification 1.4, https://focus.finops.org/docs/specification/v1-4/columns/cost-and-usage/billed-cost, consulté le 28/09/2026.
20. Effective Cost (column), FOCUS Specification 1.4, https://focus.finops.org/docs/specification/v1-4/columns/cost-and-usage/effective-cost, consulté le 28/09/2026.
21. FOCUS 1.5 Release Scope: Confirmed and Stretch Features, FinOps Foundation, https://focus.finops.org/focus-1-5-release-scope/, consulté le 28/09/2026.
22. What is AWS Data Exports?, Amazon Web Services, https://docs.aws.amazon.com/cur/latest/userguide/what-is-data-exports.html, consulté le 28/09/2026.
23. AWSBillingReadOnlyAccess (managed policy), Amazon Web Services, https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSBillingReadOnlyAccess.html, consulté le 28/09/2026.
24. Activating user-defined cost allocation tags, Amazon Web Services, https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html, consulté le 28/09/2026.
25. Backfill cost allocation tags, Amazon Web Services, https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-allocation-backfill.html, consulté le 28/09/2026.
26. Group and allocate costs using tag inheritance, Microsoft Learn, https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/enable-tag-inheritance, consulté le 28/09/2026.
27. Understand the Cloud Billing data tables in BigQuery, Google Cloud, https://docs.cloud.google.com/billing/docs/how-to/export-data-bigquery-tables, consulté le 28/09/2026.
28. Tag policies, AWS Organizations, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html, consulté le 28/09/2026.
29. Example SCPs for tagging resources, AWS Organizations, Amazon Web Services, https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html, consulté le 28/09/2026.
30. Creating cost categories, Amazon Web Services, https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html, consulté le 28/09/2026.
31. Splitting charges within cost categories, Amazon Web Services, https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/splitcharge-cost-categories.html, consulté le 28/09/2026.
32. Detecting unusual spend with AWS Cost Anomaly Detection, Amazon Web Services, https://docs.aws.amazon.com/cost-management/latest/userguide/manage-ad.html, consulté le 28/09/2026.
33. Using the Savings Plans coverage report, Amazon Web Services, https://docs.aws.amazon.com/savingsplans/latest/userguide/ce-sp-usingCR.html, consulté le 28/09/2026.
34. Using the Savings Plans utilization report, Amazon Web Services, https://docs.aws.amazon.com/savingsplans/latest/userguide/ce-sp-usingPR.html, consulté le 28/09/2026.
35. What are Savings Plans?, Amazon Web Services, https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html, consulté le 28/09/2026.
36. Understanding your reservation line items, AWS Data Exports, Amazon Web Services, https://docs.aws.amazon.com/cur/latest/userguide/regular-reserved-instances.html, consulté le 28/09/2026.
37. Understand the Kubernetes version lifecycle on EKS, Amazon Web Services, https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html, consulté le 28/09/2026.
38. Amazon RDS Extended Support charges, Amazon Web Services, https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/extended-support-charges.html, consulté le 28/09/2026.
39. Resource requirements, AWS Compute Optimizer, Amazon Web Services, https://docs.aws.amazon.com/compute-optimizer/latest/ug/requirements.html, consulté le 28/09/2026.
40. Rightsizing recommendation preferences, AWS Compute Optimizer, Amazon Web Services, https://docs.aws.amazon.com/compute-optimizer/latest/ug/rightsizing-preferences.html, consulté le 28/09/2026.
41. EC2 instance metrics, AWS Compute Optimizer, Amazon Web Services, https://docs.aws.amazon.com/compute-optimizer/latest/ug/ec2-metrics-analyzed.html, consulté le 28/09/2026.
42. Key concepts for burstable performance instances, Amazon EC2, Amazon Web Services, https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html, consulté le 28/09/2026.
43. The confused deputy problem, AWS IAM, Amazon Web Services, https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html, consulté le 28/09/2026.
44. AWS: Allows access based on date and time, AWS IAM, Amazon Web Services, https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws-dates.html, consulté le 28/09/2026.
45. Update settings for a role (maximum session duration), AWS IAM, Amazon Web Services, https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-settings.html, consulté le 28/09/2026.
46. Revoke IAM role temporary security credentials, AWS IAM, Amazon Web Services, https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html, consulté le 28/09/2026.
47. ComputeOptimizerReadOnlyAccess (managed policy), Amazon Web Services, https://docs.aws.amazon.com/aws-managed-policy/latest/reference/ComputeOptimizerReadOnlyAccess.html, consulté le 28/09/2026.