Tu ne devrais pas avoir à toucher à l'infrastructure juste pour mettre en ligne une fonctionnalité

Tu as écrit la fonctionnalité. Elle fonctionne en local. Puis tu passes les deux heures suivantes sur des choses qui n’ont rien à voir avec la fonctionnalité : un plan Terraform qui veut remplacer une base de données que tu n’as pas touchée, un manifeste Kubernetes qui a besoin d’une nouvelle règle d’Ingress, une politique IAM à laquelle il manque une autorisation pour le déploiement. Rien de tout ça ne fait partie de ton boulot. Et pourtant, aujourd’hui, c’est tout ça qui fait partie de ton boulot.

Voici à quoi ressemble vraiment cette liste, et pourquoi rien de tout ça ne devrait se retrouver dans ton assiette.

Gestion de l'état Terraform

Point clé : les fichiers d’état sont censés n’être qu’un détail d’implémentation. En pratique, ils sont une source récurrente de conflits de fusion, de dérives et de sessions de débogage de plusieurs heures qui n’ont rien à voir avec le code de ton application.

Tu n’as pas écrit de bug. Tu lances « terraform plan » et tu te retrouves face à un diff qui veut remplacer ta base de données de production, pas la mettre à jour, mais la démolir et la reconstruire à partir de zéro, parce que quelqu’un a modifié un champ mardi dernier (une version de moteur, un type de stockage, un nom) que Terraform ne peut appliquer qu’en détruisant la ressource puis en la recréant. Personne ne t’a dit que ce champ était immuable. Terraform te le dit maintenant, juste avant que ça n’arrive.

Verrouillage, backends distants, stratégie d’espace de travail, détection des dérives : ce sont toutes des préoccupations légitimes en matière d’infrastructure. Ce ne sont pas des fonctionnalités à développer. Chaque heure passée à réconcilier l’état, ou à vérifier si le diff destructeur d’un plan est prévu ou s’il s’agit d’une erreur grave, est une heure pendant laquelle ce que tu construis réellement n’avance pas.

Manifestes Kubernetes et prolifération des fichiers YAML

Point clé à retenir : un déploiement Kubernetes pour un seul service peut nécessiter cinq ou six ressources distinctes avant que quoi que ce soit ne fonctionne. Gérer toute cette complexité est une discipline à part entière, et elle s’accroît avec chaque service que tu ajoutes, et non en fonction de la valeur apportée par chaque service.

Déploiement, service, Ingress ou, avec les nouvelles API Gateway, HTTPRoute, ConfigMap, Secret, voire un HPA si tu veux de l’autoscaling. Que tu les écrives à la main ou que tu les gères via des modèles Helm et des overlays Kustomize, la complexité sous-jacente ne diminue pas ; elle passe simplement de fichiers bruts à une logique de modèles qui peut échouer de différentes manières : une fonction d’indentation mal alignée qui supprime silencieusement un champ, une redéfinition de valeurs qui ne s’applique pas là où tu t’y attendais. Rien de tout ça ne décrit ce que fait ton application. Tout ça décrit simplement comment faire tourner un conteneur dans un planificateur.

C’est le rapport qui est révélateur. Un microservice comportant 200 lignes de logique métier peut nécessiter 150 lignes de configuration Kubernetes (un rapport approximatif mais courant) pour rester opérationnel. Ce n’est pas le niveau de complexité auquel tu t’attendais quand tu as écrit cette fonctionnalité.

Politiques IAM et périmètre d’accès

Point clé : donner à un pipeline de déploiement exactement les autorisations dont il a besoin, ni plus ni moins, c’est un travail de sécurité. La plupart des développeurs ont tendance soit à surdéfinir les autorisations par frustration, soit à les sous-définir et à passer un après-midi à déboguer une erreur d’accès refusé qui n’a rien à voir avec leur code.

Tu as besoin que le rôle de ton pipeline CI puisse télécharger des artefacts de build dans un compartiment S3. Si tu écris la politique en te basant uniquement sur l’ARN du compartiment, tous les appels PutObject échoueront, car les actions au niveau de l’objet nécessitent le chemin d’accès à l’objet, c’est-à-dire l’ARN suivi de /* à la fin, et pas seulement le compartiment lui-même. Si tu te trompes là-dessus, le pipeline échouera avec une simple erreur « AccessDenied » qui ne te dira pas laquelle, parmi une douzaine de causes possibles, est la véritable raison. Si tu vas trop loin dans l’autre sens et que tu accordes s3:* sur toutes les ressources du compte pour faire disparaître l’erreur, tu viens de donner à un pipeline de build la possibilité d’accéder à tous les compartiments que possède ton entreprise.

C’est ça, le vrai savoir-faire. Mais ce n’est pas le savoir-faire pour lequel un développeur de fonctionnalités a été embauché.

Règles de réseau et découverte de services

Point clé à retenir : faire en sorte que deux services communiquent entre eux de manière fiable implique le DNS, la configuration du maillage de services, les règles de pare-feu et les contrôles de santé de l’équilibreur de charge. Rien de tout cela n’apparaît dans la fonctionnalité que tu as livrée. Et tout ça peut faire planter la fonctionnalité si c’est mal configuré.

Ton service doit appeler un autre service. Sur une plateforme bien gérée, ça se résume à un nom d’hôte et un port. En pratique, c’est une règle de groupe de sécurité, un enregistrement de groupe cible, un chemin de contrôle de santé qui doit renvoyer exactement le bon code d’état, et un client quelque part qui conserve en cache une connexion vers un pod qui a déjà été remplacé, parce que la fenêtre de contrôle de santé a duré quelques secondes de plus que ce que ton script de déploiement avait prévu.

Aucune de ces compétences de débogage ne te permet d’améliorer ta fonctionnalité. C’est une discipline à part entière qui se trouve justement entre toi et la mise en production.

Rotation des secrets et parité des environnements

Point clé : maintenir à jour les secrets de chaque environnement et les faire tourner sans temps d’arrêt, c’est un travail opérationnel qui doit être effectué correctement à chaque fois. Un seul environnement oublié, c’est un incident de production qui n’attend que le bon moment.

Les identifiants de base de données sont renouvelés. Ils sont mis à jour dans le gestionnaire de secrets, et l’environnement cible récupère automatiquement sa nouvelle valeur lors de son prochain déploiement, sans que personne n’ait à copier manuellement les valeurs dans les configurations de préproduction et de production. Si cette récupération automatique échoue quelque part, tu te retrouves avec un déploiement en préproduction qui, mystérieusement, ne parvient à se connecter à rien — ce que l’on ne découvre que la prochaine fois que quelqu’un a besoin que la préproduction fonctionne réellement.

Qu’est-ce qui change réellement quand la plateforme prend en charge cette couche ?

Point clé à retenir : aucune des tâches ci-dessus ne disparaît quand une plateforme s’en charge. Elles sont simplement déplacées vers une couche où elles sont gérées une seule fois, de manière cohérente, au lieu d’être réinventées par chaque développeur sur chaque projet.

Le but n’est pas de dire que ce travail est inutile. La gestion de l’état, la délimitation des accès, la mise en réseau et la rotation des secrets sont autant d’exigences réelles pour faire tourner un logiciel en production. La question, c’est de savoir qui s’en charge et combien de fois.

Quand la plateforme gère la couche de déploiement, ce travail n’est effectué qu’une seule fois, dans le code, et s’applique automatiquement à tous les environnements. Une nouvelle branche bénéficie d’un environnement identique à celui de production sans que personne n’ait à écrire de module Terraform pour ça. Une plateforme qui gère cette couche définit les droits d’accès au déploiement dans le cadre du modèle d’environnement, plutôt que de laisser chaque développeur rédiger à la main une politique IAM à partir de zéro. Une clé secrète est mise à jour à un seul endroit, et chaque environnement la récupère lors de son prochain déploiement, plutôt qu’une personne ne la propage manuellement d’un environnement à l’autre.

C’est ça, le vrai compromis. Pas moins de rigueur. La même rigueur, appliquée une seule fois, au lieu d’être réinventée par chaque développeur qui s’occupe du déploiement.

Si tu as passé plus de temps ce mois-ci sur du YAML que sur ta fonctionnalité elle-même, ce rapport en est le signe. Ça ne reflète pas tes compétences. Ça montre simplement où se concentre le travail.

Lis le guide du développeur pour créer des applications sans te soucier de l'infrastructure

Foire aux questions (FAQ)

Est-ce qu’il ne faut pas quand même que quelqu’un configure la plateforme elle-même ?
Oui, mais une seule fois, pas pour chaque projet ni pour chaque développeur. La différence, c’est entre configurer une couche de déploiement partagée une seule fois et que chaque équipe reconstruise sa propre version à partir de zéro. Le travail existe dans les deux cas. Ce qui change, c’est de savoir s’il est dupliqué sur chaque projet ou centralisé une seule fois.

Est-ce simplement de l’« infrastructure as code » avec des étapes supplémentaires ?
Non. Les manifestes Terraform et Kubernetes sont déjà déclaratifs, ce n’est pas là la distinction. La différence réside entre des définitions de provisionnement de bas niveau, où tu déclares encore toi-même les VPC, les rôles IAM et les groupes de sécurité individuels, et une définition d’application unique de haut niveau, où tu décris ce dont ton application a besoin et où la plateforme gère le provisionnement de bas niveau en arrière-plan.

Et si mon équipe a déjà automatisé ça avec ses propres outils ? C’est le cas de
certaines équipes, et si ton équipe plateforme interne a déjà bien mis en place et entretenu cette couche, le bénéfice marginal est moindre. Ce qu’il faut vérifier, c’est si ces outils internes sont réellement gérés comme un produit, avec un responsable et une feuille de route, ou s’il s’agit d’un ensemble de scripts qu’une seule personne comprend et que tout le monde contourne.

Est-ce que ça veut dire que je perds le contrôle sur mes choix d’infrastructure ?
Non. Les services que tu utilises, le langage dans lequel tu codes et l’architecture que tu choisis restent les tiens. Ce qui change, c’est qui écrit le Terraform, les manifestes Kubernetes et les politiques IAM qui permettent à ces choix de fonctionner concrètement. Ce sont des détails de mise en œuvre, pas des décisions sur ce que tu construis.