diff --git a/L'architecture pilotée par la donnée (Hiera-first).md b/L'architecture pilotée par la donnée (Hiera-first).md
new file mode 100644
index 0000000..b2d8e0c
--- /dev/null
+++ b/L'architecture pilotée par la donnée (Hiera-first).md	
@@ -0,0 +1,95 @@
+---
+title: "Réconcilier Puppet et Ansible : L'architecture pilotée par la donnée (Hiera-first)"
+description: 
+tags: []
+date: 2026-02-27 19:11
+lastmod: 2026-02-27 19:15
+type: 
+category: 
+status: 
+---
+
+# Réconcilier Puppet et Ansible : L'architecture pilotée par la donnée (Hiera-first)
+
+Le débat "Puppet vs Ansible" appartient au passé, enterré par la réalité des infrastructures hybrides de 2026. Opposer l'agentless à l'agent-based est un faux dilemme d'administrateur système nostalgique. La véritable question n'est plus "quel outil ?", mais "quelle stratégie de gestion d'état ?".
+
+L'idée est simple : bosser dur sur une architecture d'abstraction une seule fois pour ne plus jamais avoir à coder un seul manifeste Puppet ou un Playbook Ansible manuellement. On ne veut pas gérer des serveurs, on veut piloter un modèle de données.
+
+---
+
+## La Single Source of Truth (SSoT) : Code vs Data
+
+Le secret d'une infrastructure qui scale sans douleur réside dans la séparation hermétique entre la **logique métier** (le code) et la **déclaration d'intention** (la donnée).
+
+### L'organisation GitOps avec r10k et OpenVox
+
+Pour garantir la cohérence, nous utilisons un workflow GitOps rigoureux. L'outil **r10k** (ou sa variante haute performance **g10k**) agit comme le bras armé de notre déploiement.
+
+- **Code (Modules) :** Stocké dans des dépôts distincts, versionné, et testé par des pipelines GitLab CI.
+    
+- **Control Repo :** Le cerveau. Il contient le `Puppetfile` (qui liste les versions des modules) et surtout, l'arborescence **Hiera**.
+    
+
+Dans cet écosystème, **OpenVox** (le fork communautaire performant de Puppet) assure le respect de l'état souhaité en continu. Là où Ansible est un "tireur d'élite" (on l'appelle pour une action précise), Puppet/OpenVox est votre "garde du corps" : il surveille le **configuration drift** (dérive de configuration) toutes les 30 minutes et corrige toute modification manuelle impromptue.
+
+---
+
+## Démonstration Technique : Le Pattern Roles & Profiles
+
+Pour atteindre cette abstraction, on utilise le pattern **Roles & Profiles**. C'est la couche d'indirection indispensable.
+
+1. **Le Role :** Une simple inclusion de profils. Un nœud n'a qu'un seul rôle (ex: `role::db_server`).
+    
+2. **Le Profile :** C'est ici que la magie opère. C'est une brique technologique (ex: `profile::postgres`). Le profil ne contient **aucune valeur en dur**. Il fait appel à des fonctions de `lookup()`.
+    
+
+### Implémentation "Hiera-first"
+
+L'objectif est que 100% de la configuration d'un serveur soit pilotée par le YAML de Hiera. Voici comment nous structurons un profil pour forcer l'idempotence via la donnée :
+
+Puppet
+
+```
+# /modules/profile/manifests/database/postgres.pp
+class profile::database::postgres (
+  Boolean $manage_backup = true,
+  Hash    $databases     = {}, # On injecte tout via Hiera
+) {
+  # Abstraction : on utilise create_resources ou l'itération native
+  $databases.each |$db_name, $config| {
+    postgresql::server::db { $db_name:
+      user     => $config['user'],
+      password => postgresql::postgresql_password($config['user'], $config['password']),
+    }
+  }
+
+  if $manage_backup {
+    include profile::database::backup
+  }
+}
+```
+
+---
+
+## Deep Dive : Pourquoi Hiera est votre meilleur allié SRE
+
+### 1. Lookup Options et Deep Merging
+
+Contrairement à Ansible où la gestion des priorités de variables peut devenir un enfer de "debug", Hiera offre une hiérarchie granulaire (OS > Datacenter > Environnement > Host).
+
+Avec les **Lookup Options**, vous pouvez fusionner des Hashes de données provenant de différents niveaux de votre hiérarchie. Cela permet de définir des paramètres par défaut au niveau "Global" et de ne spécifier que les exceptions au niveau "Node".
+
+### 2. L'Idempotence et le Drift Management
+
+Ansible excelle dans l'orchestration de tâches séquentielles (rolling updates). Mais pour la conformité (Compliance-as-Code), Puppet reste imbattable.
+
+- **Idempotence :** Le code décrit un état, pas une action. Si l'état est déjà atteint, OpenVox ne fait rien.
+    
+- **Corrective Changes :** Grâce aux rapports Jenkins ou Puppetboard, vous voyez instantanément qui a modifié un fichier `/etc/sudoers` à la main, car Puppet l'a restauré immédiatement.
+    
+
+### 3. L'interopérabilité : Le meilleur des deux mondes
+
+En 2026, on ne choisit plus. On utilise **Ansible pour le "Run"** (déclencher une migration de DB, un redémarrage de service orchestré) et **Puppet pour le "State"** (s'assurer que le service est toujours configuré selon la norme de sécurité).
+
+> **Note d'expert :** Vous pouvez même utiliser un inventaire dynamique où Ansible va requêter PuppetDB pour savoir quels serveurs possèdent le `profile::database`.