L’application douze facteurs et les principes cloud native

D’où viennent les douze facteurs

En 2011, Adam Wiggins, cofondateur de Heroku, a publié The Twelve-Factor App, un court document web qui condensait ce que l’équipe de Heroku avait appris en observant un très grand nombre d’applications construites, déployées et mises à l’échelle sur sa plateforme. La méthodologie de l’application douze facteurs (twelve-factor app) décrit des applications qui se mettent en place à partir d’étapes déclaratives et automatisées, ont un contrat clair avec la plateforme sous-jacente afin de pouvoir tourner n’importe où, gardent le développement et la production assez proches pour permettre le déploiement continu, et peuvent monter en charge horizontalement sans refonte.

Le document est antérieur à Docker (2013) et à Kubernetes (2014), et pourtant il décrit presque exactement le contrat que ces plateformes ont imposé par la suite : une application est un ensemble de processus sans état, assemblés en un artefact immuable, configurés de l’extérieur, qui écrivent leurs journaux dans un flux et communiquent avec tout le reste par le réseau. C’est pourquoi il reste le vocabulaire commun de la conception d’applications cloud native. En novembre 2024, Heroku a annoncé que la méthodologie devenait open source, maintenue par une communauté de contributeurs issus de plusieurs entreprises, dans le but de l’actualiser selon les pratiques actuelles ; ses douze facteurs d’origine restent le point de référence.

Les facteurs portent sur la relation de l’application avec sa plateforme d’exécution, pas sur son architecture interne. Un monolithe modulaire peut parfaitement respecter les douze facteurs ; un ensemble de microservices peut les enfreindre tous. Ils complètent les préoccupations de déployabilité et d’exploitabilité du chapitre 2 et les principes de mise à l’échelle et d’absence d’état du chapitre 9.

Configuration, secrets et services externes

Le facteur configuration a un test simple : la base de code pourrait-elle être rendue publique aujourd’hui sans exposer un seul identifiant ? Si ce n’est pas le cas, la configuration a fui dans le code. Séparer la configuration du code permet à un même artefact de traverser tous les environnements sans modification, ce qui est le fondement du principe build once (construire une seule fois) de la section 10.5 (CI/CD et déploiement). La configuration comprend les URL des bases de données et des services, les identifiants et les réglages propres à chaque environnement ; elle exclut le câblage interne identique partout, par exemple quelle classe traite quelle route, qui relève du code.

La recommandation d’origine d’utiliser des variables d’environnement a vieilli de façon inégale. Elles sont universelles et indépendantes du langage, et Kubernetes, les plateformes PaaS et les fonctions les prennent toutes en charge. Mais l’environnement d’un processus est visible par les processus enfants, se retrouve souvent recopié dans les rapports de plantage et les pages de débogage, et ne peut pas faire l’objet d’une rotation sans redémarrage. La pratique actuelle pour les secrets consiste à les récupérer au démarrage depuis un gestionnaire de secrets (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault ou OpenBao) ou à les monter sous forme de fichiers que la plateforme peut mettre à jour, et mieux encore à remplacer les secrets à longue durée de vie par l’identité de charge de travail, où la plateforme donne automatiquement à chaque service des identifiants de courte durée. L’intention du facteur, garder la configuration hors de l’artefact, reste inchangée.

Traiter un service externe (backing service) comme une ressource attachée signifie que le code atteint la base de données des commandes, le prestataire de paiement et le courtier de messages de la même façon : par une URL et des identifiants fournis au moment du déploiement. Cela rend les environnements composables et la reprise plus rapide. Cela ne rend pas pour autant les services externes interchangeables par magie ; remplacer un courtier de messages par un autre change la sémantique de livraison. Le style hexagonal du chapitre 5 complète le facteur : la configuration dit où se trouve la ressource, et un adaptateur derrière un port masque son comportement.

Build, release, run (assembler, publier, exécuter)

Le facteur build, release, run (assembler, publier, exécuter) sépare trois étapes souvent confondues. L’étape de build transforme un commit en artefact exécutable, aujourd’hui généralement une image de conteneur identifiée par son digest. L’étape de release combine cet artefact avec la configuration d’un environnement et donne au résultat une identité, par exemple la version v42 du service des commandes en production. L’étape de run démarre des processus à partir d’une version. Les versions sont immuables : une modification du code ou de la configuration produit une nouvelle version, jamais la modification d’une version existante.

C’est cette séparation qui rend le déploiement ennuyeux. Personne ne modifie de fichiers sur un serveur, donc les serveurs ne dérivent pas ; l’image qui a passé les tests en staging est celle qui tourne en production, donc un résultat de test a un sens ; et le retour arrière est une opération rapide et rodée plutôt qu’une reconstruction en urgence. C’est aussi une piste d’audit : pour n’importe quel moment, vous pouvez dire exactement quel code et quelle configuration tournaient. Kubernetes conserve un historique des révisions des ReplicaSets de chaque Deployment, les plateformes PaaS numérotent les versions, et GitOps (section 10.4) fait de l’historique Git du dépôt des versions la référence.

Processus, concurrence et jetabilité

Des processus sans état, qui ne partagent rien, sont la condition préalable de presque tout le reste de ce chapitre : scalabilité horizontale, déploiements progressifs, autoscaling, remplacement des nœuds défaillants et répartition sur plusieurs zones. Tout ce qu’un processus garde uniquement en mémoire ou sur son disque local (la session d’un utilisateur, un fichier envoyé, un rapport en partie construit) est perdu quand ce processus est remplacé, et reste invisible pour les autres copies. Le chapitre 9 traite en détail de la gestion des sessions (équilibrage de charge, absence d’état et sessions). L’état ne disparaît pas ; il est déplacé vers des services externes conçus pour le conserver.

Le facteur concurrence ajoute que les différents types de travail doivent s’exécuter comme des types de processus différents qui passent à l’échelle séparément. Dans la plateforme de livraison de repas, le processus web qui sert l’app client passe à l’échelle selon le débit de requêtes, tandis qu’un processus worker qui envoie les confirmations de commande passe à l’échelle selon la longueur de la file, et un consommateur des positions des livreurs selon le débit d’événements. Les mélanger dans un seul type de processus oblige à tous les mettre à l’échelle pour les besoins d’un seul.

La jetabilité (disposability) exige que les processus démarrent en quelques secondes et s’arrêtent proprement. À la réception de SIGTERM, un processus web cesse d’accepter des connexions et termine les requêtes en cours ; un worker remet son message courant dans la file ou le termine dans le délai de grâce. Comme les processus peuvent aussi mourir sans prévenir (une panne de nœud, un arrêt forcé pour mémoire insuffisante), le travail doit pouvoir être répété sans danger : traitement idempotent des messages, comme dans l’architecture pilotée par les événements, et tâches qui reprennent à partir de points de contrôle. George Candea et Armando Fox ont poussé l’idée à l’extrême en 2003 avec le crash-only software, qui n’a qu’une façon de s’arrêter (planter) et une façon de démarrer (la reprise), de sorte que le chemin de reprise est exercé en permanence au lieu d’être découvert pendant un incident.

Parité dev/prod, journaux et processus d’administration

Le texte d’origine identifie trois écarts entre le développement et la production : le temps (du code écrit des semaines avant d’être déployé), le personnel (les développeurs l’écrivent, les opérateurs le déploient) et les outils (SQLite sur un portable, PostgreSQL en production). La livraison continue comble le premier, les équipes qui exploitent ce qu’elles construisent comblent le deuxième, et les conteneurs comblent une grande partie du troisième : un développeur peut exécuter en local la même version de PostgreSQL, le même courtier de messages et le même cache, et des outils comme Testcontainers démarrent de vraies dépendances dans les tests d’intégration. Une parité parfaite n’est ni abordable ni nécessaire ; l’essentiel est d’utiliser les mêmes types et versions de services externes, car c’est là que se cachent les différences surprenantes.

Traiter les journaux comme des flux d’événements signifie que l’application écrit chaque événement sur la sortie standard et laisse à la plateforme le stockage, la rotation et l’expédition. Cela reste juste, avec deux ajouts modernes : les journaux doivent être structurés (par exemple en JSON, avec des noms de champs cohérents et un identifiant de requête ou de trace), et les journaux sont l’un des trois signaux, avec les métriques et les traces, qui rendent un système observable (observabilité). Le volume des journaux est aussi un vrai facteur de coût ; la section 10.8 y revient.

Les processus d’administration, comme les migrations de base de données, les réparations de données et les rapports ponctuels, doivent s’exécuter avec la même version (code et configuration) que l’application, sous forme de processus distincts. Dans Kubernetes, cela signifie généralement un Job exécuté par le pipeline avant le déploiement de la nouvelle version. Les migrations demandent un soin particulier : elles doivent être compatibles à la fois avec l’ancienne et la nouvelle version du code qui tournent côte à côte, ce qui correspond à la discipline d’expansion-contraction de l’évolution des schémas.

Au-delà des douze facteurs

Les douze facteurs n’ont jamais prétendu être complets, et des auteurs ultérieurs les ont étendus. Beyond the Twelve-Factor App de Kevin Hoffman (O’Reilly, 2016) a porté la liste à quinze, en ajoutant API first (concevoir le contrat avant l’implémentation), la télémétrie (intégrer métriques, santé et traçage) ainsi que l’authentification et l’autorisation (la sécurité comme préoccupation de conception dès le départ). La pratique actuelle ajoute quatre thèmes que toute application cloud native devrait respecter.

La jetabilité, prise au sérieux. Concevez pour être tué à tout moment : opérations idempotentes, délais d’expiration courts pour les requêtes, temps de démarrage borné, drainage en douceur, et aucun processus unique dont la perte compte. L’immuabilité. Ne corrigez jamais un conteneur ou un serveur en fonctionnement ; construisez une nouvelle image et remplacez-le (section 10.4 sur l’infrastructure immuable). Chaque instance en cours d’exécution devient ainsi traçable jusqu’à un commit, et la dérive disparaît. L’observabilité. Émettez des journaux structurés, des métriques et des traces via un standard comme OpenTelemetry, exposez des endpoints de santé qui reflètent l’état propre du processus, et propagez le contexte de trace d’un appel à l’autre, afin que les opérateurs puissent répondre à des questions qu’ils n’avaient pas anticipées. La sécurité. Exécutez sous un utilisateur non root, avec un système de fichiers en lecture seule quand c’est possible ; obtenez les identifiants par l’identité de charge de travail plutôt que par des clés à longue durée de vie ; appliquez le moindre privilège à chaque service externe ; et construisez à partir d’images minimales, analysées et signées (sécurité de la chaîne d’approvisionnement).