_0389.jpg){kind=link}
Solution
Infrastructure versionnée
Une configuration modifiée uniquement à la main devient difficile à reproduire et à expliquer. Je décris la partie automatisable de l’infrastructure dans des fichiers, avec Terraform par exemple, dans un dépôt qui conserve qui a proposé et approuvé chaque changement, et je reconstruis un environnement pour prouver que la description est complète.
Les résultats d’une configuration versionnée
La reconstruction devient testable
Le code, les artefacts et une procédure permettent d’exécuter puis de comparer une reconstruction. La dépendance à une seule personne diminue, et l’exercice montre de combien.
Certaines erreurs apparaissent avant la mise en production
L’outil affiche le détail prévu avant l’application. Vous repérez à la relecture un port ouvert par erreur, au lieu de le découvrir plus tard dans un journal.
L’historique conserve l’auteur et la raison
Qui a changé quoi, quand et pourquoi : la question revient à chaque incident et à chaque questionnaire. Un dépôt tenu fournit la trace sans dépendre de la mémoire.
Concrètement
- La partie automatisable de l’infrastructure décrite avec un outil adapté, par exemple Terraform, dans un dépôt qui conserve l’historique et le nom des auteurs
- Une relecture avant chaque changement couvert, avec le détail des modifications affiché avant leur application et les urgences documentées après coup
- Des environnements reconstruits à partir des fichiers et logiciels contrôlés, puis comparés à des critères observables ; les données, mots de passe et services externes restent traités séparément
- Une comparaison régulière qui révèle les modifications manuelles absentes des fichiers versionnés
- Les réglages attendus pour les sauvegardes et leur conservation versionnés avec l’infrastructure, puis comparés à la configuration réelle
- La reprise progressive d’une infrastructure existante : je décris d’abord les systèmes déjà en fonctionnement, puis je les traite un par un sans reconstruction générale imposée
Les systèmes concernés
- Azure et Google Cloud, y compris leurs régions suisses
- Proxmox et les hyperviseurs en place
- Terraform, Ansible, Git et GitHub Actions ou l’outil d’intégration continue en place
- Les systèmes de sauvegarde dont la configuration est versionnée
Ligne de serviceCloud Azure et Google Cloud →
Les environnements à décrire
Le même travail, avec les contraintes du secteur. Chaque carte ouvre le secteur complet.
Déroulement
Relevé
Je recense les systèmes réellement utilisés avant toute automatisation. Cet inventaire évite de concevoir une architecture qui oublierait une machine ou une dépendance.
Description
J’importe ou je décris la configuration existante sans appliquer immédiatement de modification. Je compare ensuite les fichiers avec la réalité et j’examine les risques propres à chaque outil.
Revue
Les changements courants passent par une proposition écrite et relue au lieu d’une modification directe dans la console. L’application intervient seulement après cette validation.
Test de reconstruction
Un environnement représentatif est reconstruit dans un périmètre isolé, puis comparé aux critères convenus. Les écarts, dépendances manuelles et temps observés sont consignés.
Pour approfondir
Les accès cloud sur Google Cloud, Azure, AWS et Infomaniak
Les mêmes quatre décisions sur quatre plateformes, et l’écart dit sans détour : Infomaniak vous donne la résidence suisse des données et la portabilité OpenStack, et ne vous donne ni héritage des droits, ni règle de connexion selon l’appareil, ni rôle d’administrateur qui expire.
Sauvegardes : le test de restauration que personne ne fait
Rolle, 2021 : les données de 5 393 habitants sur le darknet. Une stratégie de sauvegarde devient crédible le jour où la restauration est testée contre les RTO, les RPO et l’impact métier.
Vérifier l’adéquation : Infrastructure versionnée
Décrivez le contexte, les contraintes et la décision attendue. Le premier échange sert à qualifier le périmètre, les limites et la prochaine étape utile.
Décrire la situation