Terraform ou Bicep pour Azure en entreprise

Toute mission de plateforme Azure rencontre cette question dans les quinze premiers jours, et elle est presque toujours posée sous sa forme la moins utile : quel est le meilleur langage ?

Les deux sont déclaratifs. Les deux sont lisibles. Les deux sont utilisés à grande échelle sur Azure. Si la syntaxe était le critère décisif, cet article serait court et se conclurait par un tirage au sort.

Les décisions qui comptent sont architecturales, et elles sont au nombre de quatre.

1. Où réside l’état désiré

Terraform conserve un fichier d’état explicite. Sur Azure, cela signifie généralement un compte de stockage, le verrouillage étant assuré par les baux de blob. Ce fichier est un actif à part entière : il peut contenir des secrets en clair, il exige sauvegarde et contrôle d’accès, et il constitue un point de contention entre tous ceux qui exécutent un pipeline.

Bicep n’a pas de fichier d’état. Azure Resource Manager est l’état : ce qui existe dans la souscription fait foi, et chaque déploiement est consigné dans l’historique des déploiements.

La simplification est réelle. Toute une catégorie de problèmes d’exploitation disparaît : plus de verrous obsolètes, plus d’écart entre le fichier d’état et la réalité, plus de terraform state mv exécuté fébrilement un vendredi soir.

Terraform obtient toutefois quelque chose en échange, et ce n’est pas anodin.

2. Ce qui se passe quand vous supprimez un bloc

C’est la différence qui surprend les équipes en production.

Supprimez une ressource d’une configuration Terraform, lancez apply : Terraform la détruit. Terraform sait ce qu’il a créé, puisqu’il l’a consigné.

Supprimez une ressource d’un fichier Bicep et déployez dans le mode incrémentiel par défaut : il ne se passe rien. La ressource reste exactement où elle est. Le mode incrémentiel ajoute et met à jour ; il ne supprime pas ce que vous avez cessé de décrire. Le mode complet, lui, supprime bien tout ce qui, dans le groupe de ressources, est absent du modèle — mais c’est un instrument brutal, que peu d’équipes exécutent de gaieté de cœur à grande échelle.

Les deployment stacks existent précisément pour combler cet écart : une stack suit les ressources qu’elle gère, peut les supprimer lorsqu’elles quittent le modèle, et porte des paramètres de refus qui bloquent les modifications effectuées hors du chemin de déploiement.

La conséquence pratique mérite d’être énoncée clairement. Adoptez Bicep sans deployment stacks et vos modèles décrivent ce qui devrait exister, jamais ce qui ne devrait pas. Le parc accumule silencieusement des ressources que personne ne reconnaît et que personne n’ose supprimer. Si vous choisissez Bicep, choisissez les deployment stacks en même temps : les greffer après coup sur un parc peuplé d’orphelins est nettement moins agréable.

3. Jusqu’où le langage porte

Pour la plupart des entreprises, c’est cette question qui tranche le débat.

Bicep déploie des ressources Azure, et il le fait très bien, à toutes les portées : tenant, groupe d’administration, souscription et groupe de ressources. La prise en charge des objets Microsoft Graph — groupes, inscriptions d’applications — progresse avec les travaux d’extensibilité de Bicep ; vérifiez son état d’avancement avant de bâtir un plan dessus.

La portée de Terraform est d’une autre nature. azurerm et azuread couvrent Azure et Entra ID, et derrière eux se trouvent des providers pour GitHub, Cloudflare, Datadog, Databricks, Snowflake et plusieurs centaines d’autres. Un seul plan peut créer un groupe de ressources, le groupe Entra qui en gouverne l’accès, le dépôt GitHub qui y déploie et les règles de protection de branche de ce dépôt.

Si votre plateforme s’arrête réellement à la frontière d’ARM, ce point est sans objet. Très peu de plateformes s’y arrêtent. Dès qu’une landing zone requiert un groupe Entra, un enregistrement DNS chez un registrar externe et un dépôt correctement protégé, un unique terraform apply cesse d’être une préférence pour devenir une architecture.

4. Les nouveautés Azure dès le premier jour

Bicep est généré à partir des spécifications de l’API ARM : les nouveaux types de ressources et les nouvelles versions d’API sont donc utilisables presque immédiatement.

Le provider azurerm de Terraform est écrit à la main et accuse donc un retard, parfois de plusieurs mois. L’échappatoire est le provider azapi, qui dialogue directement avec l’API REST d’ARM depuis Terraform. Les parcs Terraform matures sur Azure font cohabiter azurerm et azapi et considèrent cette combinaison comme normale. Mieux vaut le savoir avant de conclure que Terraform ne sait pas encore faire quelque chose.

Prévisualiser un changement

terraform plan reste la référence à laquelle les autres se mesurent, mais sa fiabilité dépend de la correspondance entre le fichier d’état et la réalité. En cas de dérive, le plan est affirmatif et faux.

az deployment what-if calcule l’écart côté serveur, face à la ressource réelle : un fichier d’état périmé ne peut donc pas le tromper. En contrepartie, il est plus bruyant — les resource providers qui ne renvoient pas toutes les propriétés produisent des différences qui relèvent de l’API plutôt que d’un changement réel, et les équipes apprennent à les ignorer.

Aucune des deux sorties n’est une garantie. Ce sont des éléments d’une décision humaine, et l’un comme l’autre valent bien mieux que déployer pour voir.

Refactoriser

Renommer une ressource Terraform sans bloc moved la détruit et la recrée — une leçon que la plupart des équipes n’apprennent qu’une fois. Les blocs moved et import ont rendu l’exercice bien plus gérable qu’auparavant, mais le risque est intrinsèque : le fichier d’état lie un nom présent dans votre code à un objet présent dans le cloud.

En Bicep, le nom symbolique n’est qu’un identifiant local. Le renommer ne change rien dans Azure, car c’est le nom de la ressource qui importe pour ARM. Restructurer une base de code Bicep coûte sensiblement moins cher que restructurer une base Terraform.

Ce qui compte moins qu’on ne le croit

La syntaxe. HCL et Bicep sont tous deux parfaitement corrects. Aucun programme cloud n’a jamais échoué à cause d’une boucle for.

« Natif contre tiers ». Que Bicep soit un produit Microsoft pèse dans une discussion de support. Cela ne confère aucun avantage fonctionnel.

La disponibilité des modules. Azure Verified Modules publie pour les deux langages. C’était autrefois un véritable avantage pour Terraform ; ce l’est beaucoup moins aujourd’hui.

La question d’achat à poser tôt

HashiCorp a fait passer Terraform sous licence Business Source License en 2023, ce qui a provoqué la création d’OpenTofu. Pour l’immense majorité des utilisateurs, la BSL ne change rien : elle restreint la commercialisation d’offres hébergées concurrentes, pas les travaux d’infrastructure internes. Mais votre direction juridique finira peut-être par poser la question, OpenTofu existe comme alternative open source compatible avec la plupart des configurations, et Bicep ne soulève aucune question de licence.

Tranchez ce point délibérément au démarrage, plutôt qu’au détour d’une revue achats trois mois après le début de la mission.

Comment décider concrètement

Quatre questions, dans l’ordre. La plupart des organisations s’arrêtent à la première.

1. Votre code d’infrastructure doit-il décrire quoi que ce soit en dehors d’ARM — objets Entra ID, GitHub, fournisseur DNS externe, plateformes SaaS, autre cloud ? Si oui : Terraform.
2. Le parc est-il exclusivement Azure, avec une équipe déjà installée dans l’outillage Microsoft ? Bicep, avec les deployment stacks dès le premier jour.
3. Exploitez-vous déjà Terraform ailleurs, avec un état, des pipelines et des conventions de modules établis ? Alors n’introduisez pas un second langage pour la partie Azure : la cohérence vaut davantage qu’une adéquation marginale.
4. S’agit-il d’un déploiement Azure autonome porté par une équipe produit — un cluster AKS, les ressources d’une application ? Bicep est plus léger : ni backend, ni état, ni verrou, rien à protéger.

Faire cohabiter les deux

Le schéma le plus répandu en entreprise consiste à retenir Bicep pour la plateforme et la landing zone, et Terraform pour les parcs applicatifs qui touchent à Entra ID, GitHub et au SaaS.

Cela fonctionne. Chiffrez-en d’abord honnêtement le coût : deux bibliothèques de modules, deux conventions de revue, deux jeux de tâches de pipeline, deux compétences à recruter et à entretenir, et une question de frontière à chaque nouveau composant. Faites ce choix délibérément, pour une raison énoncée. N’y glissez pas parce que deux équipes ont décidé différemment le même trimestre sans que personne ne les ait mises d’accord.

Ce qui détermine réellement l’issue

Pas le langage.

Les parcs Azure qui restent sains sont ceux où quelqu’un a tranché, tôt et explicitement :

• qui détient la bibliothèque de modules, et comment une modification y est revue
• ce que l’identité de déploiement a le droit de faire, et ce qu’elle n’a pas le droit de faire
• comment la dérive est détectée, et ce qui se passe lorsqu’elle l’est
• à quelle portée chaque pipeline déploie, et qui peut approuver à cette portée

Réglez ces quatre points et l’un ou l’autre outil vous servira bien. Laissez-les en suspens et aucun des deux ne vous sauvera — ce qui est une conclusion plus utile, même si ce n’est pas celle que la question appelait.