Le processus de déploiement qui fonctionnait à 5 ingénieurs casse à 15
Toutes les équipes d'ingénierie font des déploiements manuels à un moment donné, et pendant un temps, ça fonctionne. Une ou deux personnes connaissent les étapes, la checklist vit dans un document Notion, et les mises en production ont lieu quand quelqu'un a un après-midi de libre. Puis l'équipe dépasse les 15 ingénieurs, la fréquence des releases passe d'hebdomadaire à quotidienne, et exactement le même processus commence à produire des incidents.
On voit ce schéma constamment : une équipe qui livrait sans problème depuis deux ans traverse soudain un mauvais mois. Pas parce que quelqu'un est devenu moins compétent — parce que le processus n'a jamais évolué au-delà de l'effectif pour lequel il avait été conçu. Les déploiements manuels sont un système à point de défaillance unique déguisé en « on a toujours fait comme ça ».
La question qu'on nous pose n'est pas « faut-il automatiser ? » Tout le monde est déjà d'accord là-dessus. La question, c'est quoi automatiser en premier, parce que les équipes qui essaient de tout corriger en un seul sprint finissent généralement par caler et ne rien livrer. Voici l'ordre qui fonctionne réellement, basé sur le schéma qu'on observe chez les équipes en phase de croissance.
Corrigez le chemin de déploiement avant de toucher à l'infrastructure
Le réflexe, quand tout semble fragile, c'est de se tourner d'abord vers l'infrastructure-as-code — tout passer sous Terraform, reprendre le contrôle des serveurs. C'est le mauvais premier geste. Si votre processus de déploiement, c'est encore « se connecter en SSH et lancer un script », mettre sous Terraform la machine sur laquelle il tourne ne corrige pas le vrai mode de défaillance : un humain qui exécute une tâche répétable à la main, sous pression temporelle, sans plan de rollback.
Le premier dollar d'automatisation doit aller au CI/CD : un pipeline qui se déclenche à chaque push, exécute les mêmes tests à chaque fois, et déploie de la même façon à chaque fois. Concrètement, cela veut dire :
- Chaque merge vers main déclenche un build et une suite de tests — sans exception, sans push manuel « juste cette fois ».
- L'étape de déploiement est un job du pipeline, pas le terminal d'une personne. GitHub Actions, GitLab CI ou CircleCI gèrent tous ça très bien ; l'outil compte moins que la discipline de l'utiliser à chaque fois.
- Le rollback est un bouton, pas une personne qui se souvient du dernier commit hash stable connu à 23h.
Les équipes qui font ça en premier voient généralement les incidents liés aux déploiements chuter nettement dès le premier mois, sans toucher un seul fichier Terraform. La raison : la plupart des incidents « d'infrastructure » à ce stade ne sont pas des problèmes d'infrastructure. Ce sont des problèmes de processus déguisés en problèmes d'infrastructure — une valeur de configuration qui n'existe que dans la tête d'un seul ingénieur, une étape de migration que quelqu'un a oublié de lancer, un déploiement qui s'est produit dans le mauvais ordre par rapport à un autre.
Ensuite, rendez les environnements reproductibles
Une fois les déploiements automatisés, le mode de défaillance suivant apparaît : « ça marche en staging mais pas en production », ou pire, « on ne se souvient plus comment le staging a été configuré ». C'est là que l'infrastructure-as-code trouve sa place — pas comme premier chantier, mais comme deuxième.
Des modules Terraform ou OpenTofu qui décrivent votre environnement AWS, GCP ou Azure sous forme de code versionné résolvent un problème précis : la dérive d'environnement (environment drift). Sans IaC, chaque environnement accumule de petites différences non documentées — une taille d'instance modifiée manuellement ici, une règle de security group ajoutée pendant un incident là — jusqu'à ce que le staging cesse d'être un prédicteur fiable du comportement en production.
L'objectif concret n'est pas « automatiser 100 % de l'infrastructure » dès le premier jour. C'est : pouvez-vous détruire et reconstruire votre environnement de staging à partir du code en moins d'une heure, sans connaissance tribale requise ? Si la réponse est non, c'est la prochaine chose à corriger — avant Kubernetes, avant le multi-région, avant tout projet plus ambitieux.
Les environnements de prévisualisation ferment la boucle ouverte par le CI/CD
Une fois les déploiements automatisés et l'infrastructure reproductible, le levier suivant consiste à donner à chaque pull request son propre environnement jetable. C'est l'étape que les équipes sautent parce qu'elle ressemble à un luxe, mais c'est généralement l'automatisation au plus fort effet de levier après les deux premières.
Sans environnements de prévisualisation, la question « est-ce que ça marche vraiment » trouve sa réponse dans le staging, qui est partagé — ce qui veut dire que les changements de chaque ingénieur entrent en collision avec ceux de tous les autres. La QA devient une file d'attente. Les bugs sont trouvés tard, après que plusieurs changements se sont empilés les uns sur les autres, ce qui les rend coûteux à isoler. Les environnements de prévisualisation — créés par PR et détruits à la fusion — transforment cette file d'attente en tests parallèles et indépendants. Les équipes qui ajoutent ça après avoir corrigé le pipeline de déploiement constatent généralement une amélioration du temps entre revue et merge, parce que les relecteurs peuvent cliquer sur un lien et voir le changement réel tourner, au lieu de lire un diff et de lui faire confiance sur parole.
Ce qu'il faut automatiser en dernier, pas en premier
Le déploiement progressif — canary releases, feature flags, rollback automatique en cas de pic du taux d'erreur — est réel et utile, mais c'est un investissement de stade plus avancé. Il résout le problème « comment livrer en toute sécurité au trafic de production », ce qui ne compte que lorsque livrer en production est déjà fiable et ennuyeux. Les équipes qui construisent une infrastructure de canary avant d'avoir un CI/CD qui fonctionne automatisent le mauvais risque ; la logique de répartition du trafic ne sert à rien si le déploiement sous-jacent dépend encore de quelqu'un qui exécute les bonnes commandes dans le bon ordre.
Kubernetes fait partie de la même catégorie tardive pour la plupart des équipes en croissance. Il résout de vrais problèmes — autoscaling, isolation des ressources, services auto-réparateurs — mais il ajoute une vraie surface opérationnelle : manifests, Helm charts, mises à niveau de cluster, RBAC. Les équipes de moins d'environ 20 ingénieurs qui font tourner une poignée de services sont généralement mieux servies par une plateforme plus simple (ECS, Cloud Run, un PaaS managé) avec un CI/CD solide devant. Passez à Kubernetes quand vous avez assez de services pour que le problème d'orchestration soit réel, pas parce que c'est l'étape suivante attendue.
Une séquence réaliste, et ce qu'elle coûte
Pour une équipe de 15-25 ingénieurs qui sort de déploiements manuels ou semi-manuels, une séquence comme celle-ci fonctionne généralement : pipeline CI/CD avec tests automatisés et rollback en un clic en premier (typiquement 2–4 semaines), infrastructure-as-code pour les environnements principaux en second (encore 3–5 semaines, selon la dérive déjà accumulée), puis environnements de prévisualisation et monitoring/alerting ajoutés par-dessus. Une mise en place de CI/CD seule démarre typiquement à partir de $8,000 ; la séquence complète — CI/CD plus infrastructure-as-code plus environnements de prévisualisation — démarre typiquement à partir de $25,000+ selon le nombre de services et d'environnements concernés — et c'est un déploiement par étapes que notre équipe cloud et DevOps planifie étape par étape plutôt que comme une refonte de plateforme à durée indéterminée.
L'erreur à éviter, c'est de traiter tout ça comme un seul gros projet d'infrastructure avec une date de lancement unique. Chaque étape doit être livrée indépendamment et commencer à rapporter immédiatement — un pipeline CI/CD qui fonctionne a de la valeur en soi, même avant que Terraform existe pour le soutenir.
En résumé
Quand les déploiements manuels commencent à craquer, la solution n'est pas « prendre plus d'outils DevOps ». C'est le séquencement : le pipeline en premier, l'infrastructure reproductible en second, les environnements de prévisualisation en troisième, le déploiement progressif et l'orchestration seulement une fois que les fondamentaux sont devenus ennuyeux. Les équipes qui automatisent dans cet ordre corrigent leurs pires incidents dès le premier mois. Les équipes qui commencent par l'outil le plus sophistiqué de la liste passent généralement un trimestre à construire une infrastructure pour un processus de déploiement qui reste, en dessous, fondamentalement manuel.
