Cette mission menée chez Doctolib s’inscrit dans une problématique que l’on retrouve fréquemment dans des organisations en forte croissance : comment reprendre le contrôle sur une infrastructure existante, sans la remettre en cause, tout en améliorant sa traçabilité, sa gouvernance et son auditabilité.
L’enjeu n’était pas la performance ou la vitesse de déploiement. Le besoin principal était ailleurs : rendre l’infrastructure plus lisible, plus maîtrisable et plus reproductible, dans un contexte exigeant et structuré.
Un constat initial clair : manque de gouvernance et de visibilité
Avant l’introduction de Terraform et de l’IaC, plusieurs difficultés avaient été identifiées. La visibilité sur ce qui était réellement déployé restait partielle, les standards de déploiement variaient, et la documentation existante ne permettait pas toujours de répondre facilement à des enjeux d’auditabilité.
Dans un environnement pourtant relativement contenu sur Azure, ce manque de cadre représentait un risque à moyen terme, notamment en matière de contrôle et de conformité.
Un objectif prioritaire : auditabilité et reproductibilité
La motivation principale de la mission était donc de poser des fondations solides. Il s’agissait avant tout de garantir que chaque évolution d’infrastructure puisse être tracée, revue et reproduite, indépendamment des personnes.
L’idée n’était pas de tout transformer immédiatement, mais de créer un socle robuste sur lequel l’équipe pourrait s’appuyer dans la durée.
Positionnement de la mission
L’intervention s’est concentrée sur la plateforme Terraform elle-même, les workflows, les pratiques et la gouvernance technique. Elle ne portait pas sur l’architecture applicative complète ni sur les déploiements métiers spécifiques.
Ce positionnement a permis de travailler en profondeur sur les mécanismes transverses, sans interférer avec les responsabilités applicatives des équipes en place.
Mise en place de Terraform Cloud (HCP) comme socle
Le cœur de la mission a consisté à mettre en place Terraform Cloud (HCP) comme plateforme centrale. Cette brique est devenue le point d’entrée unique pour l’exécution, la traçabilité et la gouvernance des déploiements IaC.
L’approche retenue a volontairement privilégié la connexion à l’existant plutôt qu’une refonte complète.
Intégration avec l’écosystème existant
Un dépôt GitHub existait déjà. L’objectif a été de l’industrialiser : connexion VCS, déclenchement automatique des runs, gestion des workspaces et structuration des variables, y compris les variables sensibles, via les processus internes.
Cette continuité a permis une adoption plus fluide et une meilleure acceptation par les équipes.
Gouvernance et sécurité : un cadre assumé
La gouvernance reposait sur une équipe “owner” des repositories, chargée de contrôler les changements, de vérifier les informations et de garantir une gestion rigoureuse des secrets.
Un principe fort a été posé : les plans et exécutions Terraform doivent passer par la CI. Les actions ad hoc ou non traçables ont été volontairement limitées afin de renforcer le contrôle centralisé.
Organisation des workspaces et des états
L’infrastructure Terraform a été organisée autour d’un monorepo, avec un state par workspace. Les environnements (production, préproduction, test) disposaient de plusieurs workspaces dédiés.
Une organisation en “arbre” a été mise en place : un workspace parent capable de générer des workspaces enfants, chacun responsable de son environnement.
Déploiement progressif par couches
Afin de maîtriser les risques, une approche par couches a été retenue : bootstrap minimal, puis fondations, réseaux, et enfin ressources. Cette progression permettait d’introduire l’IaC de manière incrémentale, tout en conservant un contrôle fin sur chaque étape.
Modules Terraform : une approche exploratoire
Des modules internes de base (notamment pour les machines virtuelles) ont été initiés, sans être finalisés. Ce choix était assumé : les standards et besoins n’étaient pas encore suffisamment stabilisés pour figer des abstractions durables.
Cette phase exploratoire a néanmoins permis de poser les bases pour des travaux ultérieurs.
Adoption et communication
L’équipe était déjà convaincue de la valeur de Terraform. Le principal frein restait le manque de temps pour structurer correctement la solution.
Une restitution courte, en anglais, a été réalisée lors de réunions d’équipe afin de présenter ce qui avait été mis en place et la valeur apportée : traçabilité, reproductibilité et auditabilité.
Difficultés rencontrées et apprentissages
La première difficulté a été l’apprentissage du paradigme déclaratif et de l’Infrastructure as Code. La seconde, plus structurante, a concerné la conception d’une architecture de workspaces cohérente et pérenne.
Ces réflexions ont été centrales dans la réussite du projet.
Documentation : un livrable clé
Une part importante du travail a porté sur la documentation. Documentation mainteneurs, documentation utilisateurs, checklists, repères clairs sur la localisation et la responsabilité des ressources.
L’objectif était explicite : réduire l’implicite, renforcer l’autonomie et améliorer l’auditabilité globale.
État du projet à la fin de la mission
À la fin de l’intervention, la plateforme Terraform Cloud était en place et opérationnelle. Le projet était lancé, avec une trajectoire claire : la migration progressive des ressources existantes vers une gestion complète en IaC.
Ce que nous retenons
Cette mission chez Doctolib illustre l’importance d’un cadre technique clair, surtout dans des organisations en forte croissance. Elle confirme qu’une approche méthodique, progressive et documentée est souvent la clé pour faire évoluer durablement une infrastructure.
C’est ce type de mission, centrée sur la structuration et la transmission, qui donne tout son sens à notre approche chez Quill Pro.