Entrazure
Ce que nous construisons
De l’infrastructure en code, sur le parc réel. Terraform ou Bicep couvrant ce que vous exploitez vraiment : réseau, identité, services de données, calcul, supervision. Les ressources créées à la main sont importées dans l’état plutôt que reconstruites, donc la production continue pendant que le code la rattrape.
Des modules qui sont les vôtres. Une couche de modules dimensionnée sur vos motifs, avec des entrées nommées dans votre vocabulaire et une documentation écrite pour l’ingénieur qui arrivera dans dix-huit mois. Nous ne livrons pas un registre privé que nous seuls pouvons mettre à jour.
Des pipelines qui planifient en pull request et appliquent à la fusion. GitHub Actions ou Azure DevOps. Chaque modification proposée produit un plan visible dans la pull request : le réviseur voit ce qui va se passer avant que ça se passe. L’application ne part que de la branche principale, avec approbations d’environnement quand le rayon d’impact le justifie.
Une authentification sans secrets. Identifiants fédérés OIDC entre le pipeline et les identités de charge de travail Entra ID. Rien à faire tourner, rien à stocker, rien à retrouver dans un journal. À lui seul, ce changement ferme la constatation la plus fréquente d’une revue de sécurité d’infrastructure.
Politiques et dérive dans le pipeline. Azure Policy appliquée au niveau des groupes d’administration, plus des contrôles dans le pipeline qui attrapent un changement non conforme avant le déploiement. La dérive est détectée sur horaire et rapportée, parce que quelqu’un finira par corriger quelque chose dans le portail à 2 h du matin, et c’est acceptable tant que le code l’apprend.
La livraison applicative. Build, tests, image de conteneur, déploiement vers App Service, Container Apps ou Azure Kubernetes Service, avec promotion d’environnement et un retour arrière qui tient en une commande. Nous dimensionnons la plateforme à l’équipe : cinq ingénieurs qui exploitent un maillage de services, c’est une taxe opérationnelle permanente.
Secrets et configuration. Identités gérées partout où le service les accepte, un coffre pour le reste, et une configuration séparée du code pour qu’une promotion entre environnements n’implique pas une reconstruction.
Terraform ou Bicep
Cette question consomme plus de temps de réunion qu’elle n’en mérite, alors voici notre position. Bicep convient à un parc uniquement Azure, avec une équipe orientée Microsoft qui ne veut pas exploiter d’état distant. Terraform convient quand vous gérez autre chose qu’Azure, quand vous voulez l’écosystème de modules, ou quand vos ingénieurs le connaissent déjà.
Ce qui compte bien davantage que le choix, c’est de savoir qui l’entretiendra. Nous construisons avec l’outil que votre équipe utilisera encore dans trois ans, et nous le disons franchement si ce n’est pas celui qu’une direction a déjà annoncé.
Comment le mandat se déroule
Semaine 1, évaluation et décisions. Ce qui existe, ce qui est déployé à la main, la structure de dépôt, l’outil, la plateforme de pipelines, le modèle d’environnements et d’approbations. Livrable : un registre de décisions avec les raisons attachées.
Semaines 2 et 3, fondation et import. Dépôt, structure de modules, configuration de l’état, identifiants OIDC, et les premiers pipelines qui tournent de bout en bout hors production. L’import de l’existant démarre.
Semaines 4 et 5, production et pipelines applicatifs. Promotion du même code en production, protection de branches, approbations d’environnement, et les pipelines de build et de livraison d’un ou deux services réels. Vos ingénieurs ouvrent leurs propres pull requests à partir d’ici.
Semaine 6, dérive, documentation et transfert. Détection de dérive planifiée, contrôles de politiques câblés dans le pipeline, documentation des modules, et une séance de travail sur les cas d’échec : application ratée, verrou d’état bloqué, retour arrière sous pression.
Ce que vous gardez
- Un dépôt Terraform ou Bicep dans votre organisation Git, avec la documentation des modules.
- Des pipelines fonctionnels, en OIDC fédéré, sans aucun secret stocké.
- Le registre de décisions de la première semaine, options écartées comprises.
- La configuration des environnements et des approbations, déjà éprouvée sur un vrai changement.
- La détection de dérive, avec un propriétaire désigné pour le rapport qu’elle produit.
- Les procédures des trois pannes qui arrivent vraiment : application ratée, verrou d’état, retour arrière d’urgence.
- Un backlog priorisé de ce qui reste hors du code, avec une estimation par élément.
Pour qui c’est
Des équipes d’infrastructure ou de développement de trois à trente personnes, déjà en exploitation sur Azure, qui passent trop de temps sur du déploiement manuel, sur des écarts entre environnements qu’elles n’expliquent pas, ou sur une mise en production qu’une seule personne sait exécuter. Le mandat se combine naturellement avec une landing zone Azure, elle-même livrée en code, et avec une migration vers Azure, parce qu’une migration est le seul moment où tout le parc vous passe entre les mains.
Pour qui ce n’est pas
Si vous avez trois machines virtuelles et aucun projet de les changer, le code coûtera plus cher à écrire que les clics qu’il remplace.
Si votre équipe n’a ni la capacité de réviser des pull requests ni l’intention de l’acquérir, vous obtiendrez un dépôt d’infrastructure qui divergera de la réalité en deux trimestres. C’est pire que pas de dépôt, parce que les gens lui font confiance. Dites-le au départ et nous cadrerons plutôt Azure infogéré.
Et si un outil a déjà été imposé pour des raisons que personne ne sait formuler, et que la décision n’est pas rouvrable, nous pouvons livrer, mais la semaine d’évaluation fera remonter le désaccord au lieu de le masquer.
Pages liées
- Landing zone Azure, la fondation que ces pipelines déploient.
- Migration vers Azure et sortie de VMware, là où l’infrastructure en code se rentabilise le plus vite.
- Architecture de conformité, comment la preuve produite par le pipeline satisfait un auditeur.
- Tous les services Azure, le catalogue complet des mandats.
Questions fréquentes
Terraform ou Bicep ?
Bicep si vous êtes uniquement sur Azure, que l’équipe est déjà orientée Microsoft et que personne ne veut exploiter un état distant. Terraform si vous gérez plus d’un fournisseur, infonuagique ou SaaS, ou si vous voulez l’écosystème de modules. Les deux se défendent. La vraie question est de savoir lequel votre équipe entretiendra encore dans trois ans.
Nous avons des ressources créées à la main. Faut-il tout refaire ?
Non. Nous importons le parc existant dans l’état plutôt que de le redéployer : la production continue de tourner pendant que le code la rattrape. L’import est plus lent qu’une construction neuve et nous le chiffrons honnêtement, quelques centaines de ressources représentent typiquement deux à trois semaines du mandat.
Comment les pipelines s’authentifient-ils à Azure ?
Par identifiants fédérés OIDC entre votre plateforme Git et des identités de charge de travail Entra ID. Aucun secret client stocké dans une variable de pipeline, rien à faire tourner, rien à retrouver dans un vieux journal de build. Si vous vivez aujourd’hui avec des secrets de principal de service à longue durée, les remplacer est généralement le premier gain de sécurité livré.
Avons-nous besoin de Kubernetes ?
Probablement pas, et le dire nous coûte du revenu. App Service ou Container Apps couvre la majorité des charges avec une fraction de la charge d’exploitation. Nous recommandons Azure Kubernetes Service quand il y a une vraie orchestration multiservices, une exigence de portabilité ou un profil de montée en charge qui le justifie, et nous concevons alors les pools de nœuds et les limites de coût.
Qui révise les pull requests une fois que vous partez ?
Vos ingénieurs, et c’est pour cette raison qu’ils en ouvrent et en révisent dès la troisième semaine au lieu de nous regarder faire. Si personne chez vous ne peut réviser un changement d’infrastructure, nous le disons au cadrage et nous formons, ou nous proposons plutôt une prise en charge infogérée.
GitHub Actions ou Azure DevOps ?
Celui sur lequel vous êtes déjà. Les deux font correctement le travail. Migrer votre plateforme de gestion de code au milieu d’un projet d’infrastructure en code ajoute du risque sur deux fronts à la fois.
Une question sur ce mandat ?
Trois champs. Un architecte le lit et répond en un jour ouvrable.