Le problème, ce ne sont pas les outils, c'est l'ordre
La plupart des initiatives DevOps en mid-market échouent de la même manière : l'équipe installe Terraform, construit un beau dépôt IaC, et six mois plus tard découvre que les serveurs sous-jacents sont toujours configurés à la main et que personne ne connaît leur état. Le dépôt décrit une fiction.
Cet article est l'ordre que nous recommandons vraiment en 2026 pour une équipe gérant 5 à 100 serveurs en cloud et on-premise mélangés. Pas la séquence la plus ambitieuse — celle qui survit au contact du réel.
Plan
- Commencer par la gestion de configuration (Ansible) avant l'IaC (Terraform)
- Tout en gestion de versions : infra, configs, runbooks
- Une pipeline CI/CD viable minimale
- Gestion des secrets sans coffre-fort maison
- Observabilité dès le premier jour
- Pièges qui tuent le DevOps en petite équipe
- Une feuille de route 60 jours
1. Commencer par la gestion de configuration avant l'IaC
Terraform répond à « quelle infrastructure existe ? ». Ansible (ou équivalents) répond à « qu'y a-t-il sur chaque machine ? ». Pour un parc existant, c'est la deuxième question qui fait mal — et celle au plus fort retour. Marchez sur le parc avec Ansible :
- Inventorier chaque serveur avec un seul playbook.
- Appliquer un rôle baseline (users, config SSH, sync horaire, agent monitoring).
- Imposer
ansible-playbook --checksur tout changement. - Tirer ensuite seulement le provisioning vers Terraform.
Une équipe qui peut re-baseliner tout son parc en une commande est plus mature qu'une équipe avec un beau dépôt Terraform et un drift non suivi.
2. Tout en gestion de versions
Code d'infrastructure, rôles de configuration, runbooks, dashboards, définitions d'alertes, et même le modèle de planning d'astreinte. Une org Git, un CODEOWNERS, PRs obligatoires pour tout ce qui touche la production. Structure simple :
/infra # Terraform
/config # Rôles Ansible + inventaires
/runbooks # Markdown, un par classe d'incident
/observability # Dashboards-as-code, règles d'alerte
Si un changement vaut la peine d'être fait, il vaut la peine d'être revu. C'est le plan de contrôle le moins cher que vous construirez.
3. Une pipeline CI/CD viable minimale
Oubliez les pipelines à huit étapes pour la première version. Le minimum :
- Build — compilation, packaging, image conteneur avec digest.
- Test — unitaire, intégration, scan sécurité (Trivy par ex.).
- Déploiement staging — automatique sur
main. - Déploiement production — approbation manuelle, un clic.
- Rollback — un bouton, testé tous les mois.
Cette dernière étape fait la différence entre une pipeline et une intention. Si vous ne pouvez pas rollback sans réunion, vous n'avez pas de pipeline.
4. Gestion des secrets sans coffre-fort maison
Choisissez : HashiCorp Vault, Doppler, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. Branchez Ansible, Terraform et la CI. Rotation auto des credentials machine ; rotation humaine à l'offboarding. Jamais de secrets dans des fichiers env en Git, même chiffrés — l'ergonomie opérationnelle se dégrade, et tôt ou tard quelqu'un commit du clair.
5. Observabilité dès le premier jour
Trois choses, dans cet ordre :
- Métriques (Prometheus + Grafana, ou hébergé) — capacité, saturation, taux d'erreur.
- Logs (Loki, Elastic, hébergé) — forensic d'incident.
- Traces (Tempo, Jaeger, hébergé) — pour tout ce qui touche l'utilisateur.
Construisez les dashboards avant les alertes. Les alertes uniquement avec runbook. Une alerte sans runbook est un pager qui réveille sans action claire.
6. Pièges qui tuent le DevOps en petite équipe
| Piège | Pourquoi ça tue |
|---|---|
| Sur-ingénierie | Kubernetes pour trois services ; service mesh pour deux pods. |
| Serveurs snowflake | Un hôte critique que personne ne touche, plein de config manuelle. |
| Pas de test de rollback | Le premier vrai rollback se fait pendant un incident. |
| Prolifération d'outils | Trois coffres de secrets, deux IaC, deux observabilités. |
| Doc dans les têtes | Bus factor de un. |
Le remède est ennuyeux : surface réduite, déploiements répétables, drills mensuels, un outil par job, on écrit.
7. Une feuille de route 60 jours
- Sem. 1–2 — Inventaire : un playbook Ansible décrivant tout le parc.
- Sem. 3–4 — Rôle baseline appliqué partout. Rapport de drift hebdo.
- Sem. 5–6 — CI pour l'application la plus modifiée. Build + test seulement.
- Sem. 7–8 — Étape de déploiement avec approbation manuelle. Rollback testé.
- Sem. 9–10 — Secrets centralisés. Deux credentials à plus haut risque tournés.
- Sem. 11–12 — Métriques + logs au même endroit. Trois alertes actionnables avec runbooks.
Cela suffit à changer le caractère opérationnel d'une petite équipe. Au-delà de la semaine 12, c'est de l'itération.
Chaîne d'outils recommandée pour une petite équipe en 2026
- Config : Ansible
- IaC : Terraform (ou OpenTofu)
- CI/CD : GitHub Actions ou GitLab CI
- Conteneurs : Docker ; Kubernetes seulement si nécessaire
- Secrets : Vault, Doppler ou KMS du cloud
- Observabilité : pile Grafana (Prometheus + Loki + Tempo) ou hébergée
Volontairement sans paillettes. Le glamour est ce qui tue le DevOps dans les structures de moins de 200 personnes.
À retenir
- Domptez l'existant avec la gestion de configuration avant de décrire l'idéal en IaC.
- Versionnez infra, runbooks, dashboards et règles d'alerte ensemble.
- Une CI/CD viable minimale inclut un rollback testé. Sinon c'est une intention.
- Centralisez les secrets tôt ; observabilité : métriques → logs → traces, dans cet ordre.
- Six semaines de travail discipliné changent une équipe plus que six mois de shopping d'outils.
Pour un second avis sur votre feuille de route DevOps ou un kickoff à scope fixe, contactez-nous — vous parlerez à un ingénieur, pas à un commercial.