Un administrateur bascule sur -allow-experimental-features pour tester un truc, oublie de le retirer, et six mois plus tard un collègue copie-colle le même flag en prod sans savoir pourquoi il est là. Ça t’est peut-être déjà arrivé avec Terraform : jusqu’à la version 1.16, impossible de vérifier des policies HCL au moment du plan ou de l’apply sans ce garde-fou expérimental. Terraform 1.17, actuellement en bêta, change ça — et en profite pour poser une vraie alternative à Sentinel et OPA.
Le flag -policies quitte l’expérimental (mais pas tout le produit)
Dans la liste des changements de la 1.17.0-beta1, un point mérite qu’on s’y arrête : le flag -policies disponible sur init, plan et apply ne nécessite plus -allow-experimental-features. Concrètement, tu peux désormais écrire une policy HCL et la brancher sur ton pipeline Terraform sans activer un mode qui te prévient à chaque exécution que tu utilises quelque chose d’instable.
Attention à la nuance, parce qu’elle compte : c’est le support du flag dans le CLI Terraform qui sort de l’expérimental, pas le produit Terraform Policy lui-même. Sur la documentation officielle, HashiCorp est explicite : la fonctionnalité est en bêta publique, et la mention est sans ambiguïté — « do not use beta features in production environments ». Tu peux tester, documenter, préparer ta migration depuis Sentinel. Tu ne branches pas encore ça sur ton environnement de production critique.
Terraform Policy, concrètement : ce qu’il fait que Sentinel et OPA ne font pas
HashiCorp a annoncé ce nouveau framework le 16 juillet 2026 dans un billet intitulé « Introducing tfpolicy ». L’argument de vente tient en une phrase : écrire tes policies en HCL, le même langage que tes fichiers .tf, plutôt que d’apprendre le DSL Sentinel ou Rego pour OPA. Mais la vraie différence est ailleurs, dans ce que le moteur peut évaluer.
Sentinel et OPA tournent uniquement au moment du plan, et ni l’un ni l’autre ne peut interroger une data source pendant l’évaluation — ils travaillent sur ce que le plan leur donne, point final. Terraform Policy, lui, peut s’exécuter à trois moments distincts du cycle de vie : pendant terraform init (avant même que les providers et modules soient téléchargés — utile pour bloquer un provider non approuvé avant qu’il touche ton disque), pendant le plan, et après l’apply, pour valider des valeurs qui ne sont connues qu’une fois la ressource provisionnée (un ARN généré par le provider, par exemple). Il peut aussi interroger des données externes au moment de l’évaluation — une liste d’AMI approuvées dans une data source, typiquement.
Côté niveaux d’application, Sentinel propose advisory / soft-mandatory / hard-mandatory, OPA se limite à pass/fail sans niveau intermédiaire. Terraform Policy introduit un troisième modèle — advisory, mandatory_overridable et mandatory — qui se rapproche de Sentinel sans en reprendre le vocabulaire ni la syntaxe.
Faut-il migrer tes policies Sentinel dès maintenant ?
Non, et HashiCorp ne le demande pas. Le produit est en bêta publique sur HCP Terraform depuis juillet, le support CLI vient seulement de sortir de l’expérimental dans une version qui n’est elle-même pas encore stable. Si tu as un parc de policies Sentinel qui fonctionne, le bon réflexe est de suivre l’évolution, éventuellement de tester tfpolicy sur un projet non critique via l’agent skill GitHub mentionné dans l’annonce (conçu pour convertir des policies Sentinel existantes), mais pas de basculer ta gouvernance de prod sur un outil encore en bêta. OpenTofu, pour rappel, n’a pas d’équivalent annoncé à ce jour — un point à peser si la gouvernance par policy fait partie de tes critères de choix entre les deux outils.
Les autres nouveautés de la 1.17 à ne pas manquer
Terraform Policy capte l’attention, mais la bêta embarque trois autres changements utiles au quotidien.
Les variables et les locals sont désormais supportés dans les required_providers — tu peux enfin centraliser une contrainte de version de provider dans une variable plutôt que de la dupliquer dans chaque bloc. Une nouvelle option de planification, -minimal-refresh, rafraîchit uniquement les ressources qui ont des changements proposés au lieu de l’état entier — un gain de temps net sur les configurations avec des centaines de ressources où seule une poignée bouge réellement. Et côté tests, mock_provider prend désormais en charge les ressources éphémères, ce qui évite de devoir provisionner un vrai secret juste pour faire tourner ta suite de tests.
Un dernier détail technique : la sortie JSON de la commande version gagne un champ format_version. HashiCorp précise que ça ne devrait pas casser les intégrations existantes, mais recommande de vérifier ce champ dans les prochaines versions — un signe que d’autres changements de format sont probablement à venir.
FAQ
Terraform 1.17 est-elle disponible en version stable ?
Non, au moment de la rédaction de cet article la dernière version publiée est la 1.17.0-beta1. La 1.16 reste la version stable recommandée pour la production — on avait détaillé ses apports (import dans les modules, destroy = false) à sa sortie début octobre.
Terraform Policy remplace-t-il Sentinel ?
Pas à ce stade. Sentinel reste pris en charge sur HCP Terraform et Terraform Enterprise. Terraform Policy est une alternative construite sur une philosophie différente (HCL plutôt qu’un DSL dédié, évaluation à plusieurs étapes du cycle de vie plutôt qu’au plan uniquement), pas un remplacement annoncé.
Le flag -policies fonctionne-t-il avec OPA ou Sentinel ?
Non, ce flag sert spécifiquement à activer les policies HCL de Terraform Policy en local, via le CLI open source. Sentinel et OPA restent gérés via HCP Terraform et Terraform Enterprise, avec leurs propres mécanismes d’activation.
Passe à l’action
Si tu gères des policies Sentinel aujourd’hui, le plus utile à faire cette semaine n’est pas de migrer quoi que ce soit : c’est de lire la page de comparaison HashiCorp et de repérer les deux ou trois règles de ton catalogue qui bénéficieraient le plus d’une évaluation post-apply ou d’une data source externe — ce sont elles qui justifieront un vrai test de tfpolicy quand la 1.17 passera stable. En attendant, reste sur la 1.16 pour tout ce qui touche à la production.
Laisser un commentaire