Conseil en infrastructure as code

Qu’est-ce que l’infrastructure as code ?

L’infrastructure as code décrit les ressources cloud dans des fichiers texte : réseaux, clusters, bases de données, enregistrements DNS, politiques d’identité et d’accès. Un outil comme Terraform, OpenTofu, Pulumi ou CloudFormation compare ces fichiers avec ce qui existe et applique la différence. Les fichiers vivent dans Git : chaque changement a un auteur, une relecture et un historique.

L’enjeu est la reproductibilité et le contrôle. Un nouvel environnement est créé à partir du même code que le précédent, un relecteur voit exactement ce qu’un changement va faire avant son exécution, et un auditeur peut retracer qui a ouvert quel port et quand. Sans cela, les environnements divergent et chaque incident commence par la question de ce qui est réellement déployé.

Notre périmètre couvre les plateformes greenfield et les environnements existants construits à la main, qui sont le cas le plus fréquent. Nous importons l’existant, le structurons en modules, sécurisons le state et le connectons à vos pipelines. Ce travail s’inscrit dans notre expertise en conseil DevOps, aux côtés des pipelines, de l’observabilité et de l’orchestration.

Les signes qu’il vous faut de l’infrastructure as code

Certaines équipes n’ont aucun code d’infrastructure. Plus souvent, elles en ont un peu, mais il ne correspond plus à la réalité et plus personne ne lui fait confiance. Les deux situations produisent les mêmes symptômes dans l’exploitation au quotidien.

• La production a été construite en cliquant dans une console

  Si personne ne peut reconstruire la production de zéro, une région perdue ou une ressource supprimée se transforme en une reprise longue et improvisée.

• Les plans affichent des changements que personne ne reconnaît

  Des diffs inattendus signifient que quelqu’un a modifié des ressources à la main. Les équipes cessent alors d’appliquer le code de peur d’annuler un correctif urgent.

• Chaque équipe copie et modifie le même code

  Le code réseau ou base de données copié diverge vite : un correctif de sécurité doit être appliqué à de nombreux endroits, et certains sont oubliés.

• Les fichiers de state sont sur un portable ou un dossier partagé

  Un state local ou non verrouillé entraîne des applies concurrents, un state corrompu et des secrets stockés en clair, lisibles par n’importe qui.

• Un auditeur demande qui a modifié une règle de pare-feu

  Quand les changements ne passent pas par du code relu, répondre à une question de conformité impose de fouiller les logs de la console pendant des jours.

Un code d’infrastructure partiel peut être plus risqué que pas de code du tout, car il donne une fausse impression de contrôle. L’audit mesure l’écart entre le code et la réalité avant toute modification, pour que le plan parte de faits.

Ce que couvre notre mission IaC

Nous commençons par comparer ce que décrit votre code avec ce qui tourne réellement, compte par compte. Chaque ressource est classée : déjà en code, importable, à reconstruire ou à supprimer. La manière dont les équipes organisent leurs dépôts et promeuvent les changements est détaillée dans notre guide sur la scalabilité et le versioning du code d’infrastructure entre environnements.

• Inventaire et rapport de drift

  Les ressources par compte et par environnement, rapprochées du code existant, avec le drift et les ressources non gérées listés et classés par risque.

• Choix de l’outil et organisation des dépôts

  Terraform, OpenTofu, Pulumi ou CloudFormation choisi avec votre équipe, et une structure de dépôts pour les modules, les environnements et les responsabilités.

• Des modules réutilisables et versionnés

  Des modules réseau, calcul, base de données et identité avec des valeurs par défaut pertinentes, des versions sémantiques et des exemples, pour que les équipes assemblent au lieu de copier.

• State distant et applies sécurisés

  Un state distant chiffré avec verrouillage, séparé par environnement, et des applies exécutés uniquement depuis un pipeline après un plan relu.

• Policy as code et gestion des secrets

  Des contrôles automatiques sur les plans pour les ports ouverts, le chiffrement ou les tags manquants, et des secrets lus dans un coffre au lieu d’être écrits dans le code.

Les imports se font par petits lots, chacun n’étant accepté que lorsque le plan n’affiche aucun changement : la production n’est jamais modifiée pendant sa mise en code. Vos ingénieurs mènent les imports avec nous, ce qui est le moyen le plus rapide de leur faire apprendre la nouvelle structure.

Notre méthode de mise en code en quatre phases

L’ordre compte. Nous sécurisons le state et la structure avant d’importer, et nous importons avant d’imposer. Imposer trop tôt bloque les équipes qui ont encore besoin d’accéder à la console pour leur travail quotidien.

Une fois que les applies passent exclusivement par le pipeline, l’accès en écriture à la console se réduit à un rôle d’urgence journalisé. Un plan planifié s’exécute sur chaque environnement et déclenche une alerte quand la réalité s’écarte du code : le drift est détecté en quelques jours au lieu d’être découvert lors du prochain incident.

Terraform, OpenTofu, Pulumi ou CloudFormation ?

L’outil compte moins que la discipline qui l’entoure, mais le choix pèse tout de même pendant des années sur le recrutement, la réutilisation et la dépendance au fournisseur. Nous recommandons celui que votre équipe peut maintenir, et nous documentons les raisons pour que la décision puisse être revue.

Changer d’outil est rarement la première priorité. Une équipe dont le Terraform fonctionne gagne davantage avec des modules, une bonne hygiène du state et des contrôles de politiques qu’avec une réécriture. Nous ne recommandons un changement que lorsque les conditions de licence, les compétences en langage ou un projet multi-cloud font de l’outil actuel une vraie contrainte.

Les risques de la mise en code d’un environnement en production

Placer une infrastructure en fonctionnement sous code est délicat, car l’outil supprimera sans hésiter ce qu’il ne s’attend pas à trouver. Nous planifions chaque étape autour de ce risque et gardons un relecteur entre chaque plan et chaque apply.

• Un apply qui détruit une ressource

  Un mauvais import ou un bloc renommé peut planifier un remplacement. Chaque plan est relu, et la destruction d’une ressource stateful exige une approbation explicite.

• Un state corrompu ou perdu

  Le state est stocké à distance avec verrouillage, versioning et sauvegardes, et personne ne le modifie à la main en dehors d’une procédure documentée.

• Des secrets écrits dans le code ou le state

  Les identifiants proviennent d’un gestionnaire de secrets au moment de l’apply, et le stockage du state est chiffré avec un accès limité au pipeline.

• Des modules que personne n’ose mettre à jour

  Les modules sont versionnés et épinglés par environnement, avec un changelog, pour que les mises à jour passent de la préproduction à la production dans un ordre maîtrisé.

Tester le code d’infrastructure permet de détecter la plupart de ces problèmes avant qu’ils n’atteignent la production. Nos guides sur une stratégie de tests pour l’infrastructure as code et sur la gestion des secrets hors du code Terraform présentent les contrôles que nous ajoutons au pipeline.

Tarifs de l’infrastructure as code

Chaque mission commence par un diagnostic de vos comptes et du code existant, et se conclut par un devis forfaitaire. Les durées sont indicatives, pas garanties, et dépendent surtout de la part de l’environnement construite à la main.

Ce qui fait varier le prix : le nombre de comptes cloud et d’environnements, la part des ressources construites à la main, le nombre d’équipes qui utilisent les modules et les exigences de conformité.

Le devis couvre uniquement des consultants seniors, un ensemble défini de comptes et les livrables de chaque phase. Les ressources cloud, le stockage du state et toute licence commerciale pour une plateforme IaC ou un outil de politiques sont facturés par leurs fournisseurs, séparément de nos honoraires.

FAQ infrastructure as code