Automation et orchestration sont confondues 90 % du temps dans les conversations DevOps. Les deux sont distinctes mais complémentaires : l’automation consiste à faire une tâche sans humain, l’orchestration consiste à enchaîner plusieurs tâches automatisées dans un ordre cohérent avec gestion des erreurs. Une troisième dimension émerge en 2026 : la choreography où plusieurs services réagissent à des événements sans orchestrateur central. Cette page distingue les trois niveaux, présente la pyramide automation → orchestration → choreography, identifie les outils 2026 par catégorie, et défend une opinion : le cloud rend possible le DevOps natif parce que tout y est API — ne pas en profiter, c’est gaspiller le principal levier d’efficacité de la décennie.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- La distinction automation, orchestration, choreography
- La pyramide de progression et ses cas d’usage
- Les outils 2026 par catégorie (Terraform, Ansible, Step Functions, GitHub Actions)
- Pourquoi le cloud impose une discipline IaC par construction
- Le défaut GitOps moderne pour l’orchestration cloud
Prérequis : avoir compris API-first et loose coupling. Si besoin, lisez d’abord Cloud API-first et Loose coupling et stateless design.
1. Les 3 niveaux de la pyramide
Section intitulée « 1. Les 3 niveaux de la pyramide »Automation — exécuter une tâche sans humain
Section intitulée « Automation — exécuter une tâche sans humain »L’automation consiste à automatiser une tâche unique qui était auparavant manuelle. Exécution sans intervention humaine, déterministe, idempotente quand possible.
Exemples :
- Un script Bash qui sauvegarde une base de données quotidiennement.
- Une commande Terraform qui crée une VM.
- Un cron qui rotate les logs.
- Un workflow GitHub Actions qui build une image Docker.
Caractéristiques :
- Une seule tâche par script ou commande.
- Pas de dépendance complexe entre tâches.
- Peut être idempotent ou non selon la conception.
- Granularité : minutes à heures.
Orchestration — enchaîner plusieurs tâches automatisées
Section intitulée « Orchestration — enchaîner plusieurs tâches automatisées »L’orchestration consiste à coordonner plusieurs tâches automatisées dans un ordre précis, avec gestion des dépendances, des erreurs, et des conditions.
Exemples :
- Terraform qui crée VPC + subnets + sécurité + instances + LB dans le bon ordre.
- Ansible playbook qui patche 50 serveurs en rolling.
- AWS Step Functions qui enchaîne « valider commande → débit → réservation stock → expédition ».
- Argo Workflows qui orchestre un pipeline ML training avec préparation données → entraînement → évaluation → déploiement.
Caractéristiques :
- Plusieurs tâches chaînées.
- Gestion des dépendances (B après A, C après B).
- Gestion des erreurs (retry, compensation, rollback).
- Orchestrateur central qui pilote.
- Granularité : minutes à jours.
Choreography — coordination par événements sans orchestrateur central
Section intitulée « Choreography — coordination par événements sans orchestrateur central »La choreography (ou event-driven choreography) supprime l’orchestrateur central. Chaque service réagit à des événements publiés par d’autres services et publie ses propres événements. Pas de coordinateur unique, la logique distribuée se construit par composition d’événements.
Exemples :
- Architecture microservices avec Kafka où chaque service consomme et émet des événements selon ses propres règles.
- Pattern Saga choreographied (cf. Synchrone vs asynchrone).
- AWS EventBridge avec rules qui déclenchent Lambda en réaction à des événements S3, DynamoDB, ou applicatifs.
Caractéristiques :
- Aucun orchestrateur central.
- Chaque service a sa logique locale de réaction.
- Flexibilité maximale, complexité de raisonnement maximale.
- Granularité : millisecondes à minutes.
Tableau comparatif
Section intitulée « Tableau comparatif »| Aspect | Automation | Orchestration | Choreography |
|---|---|---|---|
| Nombre de tâches | 1 | Plusieurs | Plusieurs services |
| Coordinateur | Inutile | Centralisé | Distribué |
| Visibilité du flux | Linéaire | Centralisée | Difficile (logique éclatée) |
| Tolérance aux pannes | Réessayer la tâche | Compensation | Eventual consistency |
| Outils types | Bash, Python, Terraform | Step Functions, Argo, Airflow | Kafka, EventBridge |
| Cas d’usage | Tâche ponctuelle | Workflow métier | Architecture event-driven |
| Difficulté de débogage | Faible | Moyenne | Élevée |
2. Pourquoi le cloud rend possible le DevOps natif
Section intitulée « 2. Pourquoi le cloud rend possible le DevOps natif »Le DevOps existe depuis 2009 (terme inventé à DevOpsDays Gent), mais il est devenu mainstream avec l’adoption massive du cloud. La raison technique est simple : tout dans le cloud est API (cf. Cloud API-first).
Sur on-premise traditionnel, automatiser le provisioning d’un serveur exige :
- Communication avec l’équipe datacenter pour réserver un slot.
- Achat ou réaffectation matérielle.
- Configuration manuelle réseau (VLAN, IPs).
- Installation OS via PXE ou ISO.
- Configuration système initiale.
Quelques étapes peuvent être automatisées (Cobbler, Foreman pour le provisioning), mais la chaîne complète reste humaine et lente.
Sur le cloud, chaque étape est un appel API :
- VM créée par
aws ec2 run-instances. - Réseau attribué automatiquement par défaut, customisable par API.
- OS pré-installé sur l’image, customisable par cloud-init.
- Configuration applicative par Ansible ou container.
Cette chaîne 100 % API rend possible l’automatisation de bout en bout. C’est ce qui rend le DevOps natif au cloud — pas une couche d’abstraction qu’on ajoute, mais une propriété structurelle.
3. Les outils 2026 par catégorie
Section intitulée « 3. Les outils 2026 par catégorie »Provisioning d’infrastructure (Infrastructure as Code)
Section intitulée « Provisioning d’infrastructure (Infrastructure as Code) »Définir l’infrastructure en code versionné, déployer de manière reproductible.
| Outil | Type | Spécificité |
|---|---|---|
| Terraform | Déclaratif | Le standard de fait, multi-cloud, écosystème massif |
| OpenTofu | Déclaratif | Fork open source de Terraform après changement de licence (2023) |
| Pulumi | Impératif | Code dans des langages (Python, TypeScript, Go) au lieu de HCL |
| AWS CDK | Impératif | Spécifique AWS, génère du CloudFormation |
| CloudFormation | Déclaratif | Natif AWS, intégration profonde avec services AWS |
| Bicep | Déclaratif | Surcouche moderne d’ARM Templates Azure |
| Deployment Manager | Déclaratif | Natif GCP |
Recommandation 2026 : Terraform ou OpenTofu pour le multi-cloud, Pulumi pour les équipes développeuses qui préfèrent le code, natifs (CloudFormation, Bicep) pour des architectures mono-cloud très intégrées.
Configuration des serveurs
Section intitulée « Configuration des serveurs »Configurer le contenu interne des VMs et serveurs.
| Outil | Style | Spécificité |
|---|---|---|
| Ansible | Push, agentless, YAML | Le plus utilisé en France, certif RHCE |
| Salt | Pull/push, agent, YAML | Performant à grande échelle |
| Chef | Pull, agent, Ruby DSL | En perte de vitesse depuis 2020 |
| Puppet | Pull, agent, DSL custom | En perte de vitesse depuis 2020 |
| Cloud-init | Bootstrap initial, YAML | Standard pour les images cloud |
Recommandation 2026 : Ansible reste dominant en France pour la configuration. Cloud-init pour le bootstrap initial des VMs cloud. Pour les workloads conteneurisés, la configuration vit dans l’image OCI elle-même — plus besoin de configuration management traditionnelle.
Orchestration de workflows
Section intitulée « Orchestration de workflows »Enchaîner des tâches automatisées avec gestion des dépendances et erreurs.
| Outil | Type | Spécificité |
|---|---|---|
| AWS Step Functions | State machine | Visual workflows, intégration AWS native |
| Azure Durable Functions | Code C#/Python | Orchestration via code, pattern stateful |
| GCP Workflows | YAML | Léger, intégration GCP |
| Argo Workflows | Kubernetes-native | YAML, parfait pour pipelines ML/data |
| Temporal | Code multi-langues | Open source, alternative cloud-agnostic |
| Apache Airflow | Python DAG | Pipelines data, le plus utilisé en data engineering |
Automatiser le build, test, déploiement du code applicatif et infrastructure.
| Outil | Type | Spécificité |
|---|---|---|
| GitHub Actions | YAML | Le plus utilisé, intégration GitHub native |
| GitLab CI | YAML | Excellent pour GitLab, on-prem possible |
| Forgejo Actions | YAML | Fork souverain de GitHub Actions |
| Jenkins | Groovy DSL | Toujours présent en entreprise, en perte de vitesse |
| CircleCI / Travis | YAML | Hosted, en perte de vitesse depuis GitHub Actions |
GitOps — l’orchestration moderne pour Kubernetes
Section intitulée « GitOps — l’orchestration moderne pour Kubernetes »Le GitOps est le pattern d’orchestration par défaut sur Kubernetes en 2026. Le principe : la source de vérité est un repo Git, des agents (Flux, ArgoCD) réconcilient continuellement l’état du cluster avec l’état décrit dans Git.
| Outil GitOps | Spécificité |
|---|---|
| Argo CD | UI riche, multi-cluster, le plus populaire |
| Flux v2 | CNCF graduated, philosophie « pull-based » pure |
| Atlantis | GitOps spécifique à Terraform (PR-driven) |
Bénéfices GitOps :
- Source de vérité unique : Git voit tout.
- Audit trail : chaque changement est une commit reviewable.
- Rollback trivial :
git revert+ l’opérateur réconcilie. - Disaster recovery : un cluster détruit se reconstruit en pointant Argo/Flux sur le repo.
4. La discipline IaC — non négociable en 2026
Section intitulée « 4. La discipline IaC — non négociable en 2026 »Pourquoi tout doit être en code
Section intitulée « Pourquoi tout doit être en code »Dans la pratique courante, toute infrastructure cloud créée à la main finit par devenir de la dette technique. Trois raisons :
Raison 1 — Pas de reproductibilité. Un environnement créé à la main ne peut pas être recréé à l’identique 6 mois plus tard. Les variables exactes, les ordres de création, les dépendances cachées disparaissent avec la mémoire de la personne qui l’a fait.
Raison 2 — Pas d’audit trail. « Qui a fait ça ? Pourquoi ? » — questions sans réponse quand l’historique est dans la console cloud, qui ne montre que les modifications récentes.
Raison 3 — Pas de revue par les pairs. Un changement infrastructure devient une PR Git, reviewable, commentable, mergée après validation. C’est la gouvernance technique que les contrôles internes attendent.
Anti-patterns IaC
Section intitulée « Anti-patterns IaC »Anti-pattern 1 — « ClickOps puis import ». On clique dans la console pour aller vite, on importe ensuite l’état dans Terraform. Le state Terraform et la réalité divergent après quelques semaines. Discipline : tout en code dès le J1.
Anti-pattern 2 — « Module Terraform géant ». Un seul module Terraform pour toute l’infrastructure. Le terraform plan prend 10 minutes, les changements sont risqués, les équipes se gênent. Discipline : modulariser par bounded context (un module par service ou domaine).
Anti-pattern 3 — « Variables hardcodées dans le code ». Les credentials, les noms d’environnements, les valeurs spécifiques à un déploiement sont dans le code Terraform. Impossible de réutiliser pour un autre environnement. Discipline : tfvars par environnement, secrets dans un gestionnaire dédié.
Anti-pattern 4 — « State sur le poste local ». Le state Terraform n’est pas centralisé. Deux développeurs travaillent en parallèle, l’un écrase le travail de l’autre. Discipline : backend remote (S3 + DynamoDB lock côté AWS, Azure Storage côté Azure, GCS côté GCP).
Anti-pattern 5 — « Pas de CI/CD pour Terraform ». Les changements Terraform sont appliqués manuellement depuis le poste d’un développeur. Discipline : Atlantis ou GitHub Actions qui exécute terraform plan sur PR et terraform apply après merge.
5. Comment doser automation, orchestration et choreography
Section intitulée « 5. Comment doser automation, orchestration et choreography »Le niveau d’automatisation approprié dépend du nombre d’étapes, de la fréquence d’exécution et de la maturité de l’équipe sur les outils. Trois critères aident à se positionner.
L’automation comme socle. Toute opération récurrente (déploiement, sauvegarde, vérification, provisionnement) gagne à être automatisée dès qu’elle se répète. Le coût d’écrire un script ou un manifeste IaC (de l’ordre de quelques heures) est largement amorti par la suppression des erreurs manuelles répétées et la traçabilité des actions. Cette automation est la base de toute pratique DevOps mature, et concerne aussi bien les opérations d’infrastructure que les workflows applicatifs.
L’orchestration sur des workflows complexes. Mettre en place un orchestrateur (Step Functions, Argo Workflows, Durable Functions, Airflow, Temporal) apporte une vraie valeur quand le workflow comporte plusieurs étapes interdépendantes, des compensations en cas d’échec partiel, et un besoin de visibilité sur l’état d’exécution. Pour des workflows simples (deux ou trois étapes, sans logique complexe), un script avec retry suffit souvent et reste plus facile à raisonner. Critère pratique : si l’on ne peut pas décrire le workflow en quelques phrases, un orchestrateur apporte généralement une lisibilité utile.
La choreography quand l’équipe a la maturité observationnelle. L’event-driven choreography (services qui réagissent à des événements sans orchestrateur central) offre un découplage très fort, mais demande une infrastructure d’observabilité solide pour tracer les flux distribués. Sans cette infrastructure, les équipes peuvent se retrouver face à des comportements émergents difficiles à diagnostiquer (qui réagit à quel événement, pourquoi cet événement n’a pas déclenché ce service ?). Une approche prudente consiste à démarrer orchestrated sur les workflows critiques, puis à introduire de la choreography progressivement au fur et à mesure que l’équipe gagne en maturité sur l’event-driven et que l’observabilité permet de suivre les flux.
Bonnes pratiques transverses : tout en code (IaC, scripts versionnés), modules par domaine, state centralisé sur un backend partagé, CI/CD systématique pour l’IaC, tests automatisés sur les modules réutilisables.
À retenir
Section intitulée « À retenir »- Automation = exécuter une tâche sans humain. Orchestration = enchaîner plusieurs tâches. Choreography = coordination par événements sans orchestrateur central.
- Le cloud rend possible le DevOps natif parce que tout est API — la chaîne complète est automatisable.
- Outils par catégorie : Terraform/Pulumi/CloudFormation pour IaC, Ansible/cloud-init pour configuration, Step Functions/Argo pour orchestration, GitHub Actions/GitLab CI pour CI/CD.
- GitOps (Argo CD, Flux) est l’orchestration par défaut sur Kubernetes en 2026.
- Discipline IaC non négociable : tout en code, modules par domaine, state centralisé, CI/CD pour Terraform.
- Le niveau d’automatisation se choisit selon le nombre d’étapes du workflow et la maturité observationnelle de l’équipe — automation systématique, orchestration sur workflows complexes, choreography quand l’observabilité distribuée est en place.