Dans mon billet sur Lambs on Acid, j’ai mentionné en passant un réseau appelé Weeklynet. Je voudrais y revenir, parce que c’est la contrainte la plus intéressante que j’aie rencontrée en vingt ans, et qu’elle n’a rien à voir avec la blockchain.
Weeklynet est un réseau de test Tezos recréé de zéro toutes les semaines. Pas mis à jour. Pas migré. Recréé. Chaque semaine, l’ancien monde cesse d’exister et un nouveau démarre au bloc zéro.
Et mon travail était d’avoir un nœud dessus, synchronisé, qui publie des instantanés. En permanence. Sans y toucher.
La phrase que tout le monde dit
Posez la question à n’importe quelle équipe qui fait de l’infrastructure as code : « si on perdait tout, vous pourriez reconstruire ? »
La réponse est toujours oui. Elle est même donnée avec une certaine fierté, parce que c’est exactement ce que l’infrastructure as code est censée garantir. Le code est dans le dépôt. Le terraform apply existe. Donc oui.
Maintenant posez la deuxième question : « quand l’avez-vous fait pour la dernière fois ? »
Là, ça devient intéressant. Dans la grande majorité des cas, la réponse honnête est jamais. On a construit, il y a deux ou trois ans. Depuis, on a modifié. On n’a jamais recommencé depuis rien.
Et entre les deux il y a un fossé que personne ne mesure.
Ce qui casse, et qui ne casse que là
Un environnement qu’on reconstruit vraiment révèle une catégorie de problèmes entièrement invisible en exploitation normale. J’en ai croisé toujours les mêmes.
Ce que quelqu’un a fait à la main, une fois. L’enregistrement DNS ajouté dans une interface web un vendredi soir. La règle de pare-feu ouverte « en attendant ». Le certificat renouvelé en cliquant. Rien de tout ça n’est dans le code, personne ne s’en souvient, et tout ça marche parfaitement — jusqu’au jour où on repart de zéro et où ça manque.
L’ordre implicite. Le code décrit des objets, pas une chronologie. Sur une infrastructure qui existe déjà, l’ordre ne se voit pas : tout est là. Sur une reconstruction, on découvre que la base doit être prête avant la migration, que le certificat doit exister avant l’ingress, et que le DNS doit avoir propagé avant la validation. Ce sont des dépendances réelles que personne n’a écrites parce que personne ne les a jamais vues.
Ce qui a dérivé sans qu’on le sache. La version d’image qui n’était pas épinglée et qui a avancé toute seule. Le paramètre par défaut du fournisseur qui a changé entre-temps. Sur une infrastructure en place, ces dérives sont invisibles. À la reconstruction, on n’obtient pas l’environnement d’avant : on obtient celui que le code décrit aujourd’hui, avec les valeurs par défaut d’aujourd’hui. Ce n’est pas la même chose.
Le secret que personne ne sait régénérer. Il est dans le coffre, très bien. Mais qui sait comment il a été obtenu ? Auprès de qui ? Avec quel compte ? C’est presque toujours une personne, et cette personne est souvent partie.
Aucun de ces problèmes n’apparaît en exploitation. Tous apparaissent à la reconstruction. C’est pour ça qu’une équipe peut avoir un dépôt Terraform impeccable et être malgré tout incapable de repartir de zéro.
Ce que Weeklynet obligeait à faire
Un environnement qui doit exister à nouveau tous les sept jours, sans intervention, ne laisse le choix qu’entre deux états : automatisé, ou mort.
Il n’y avait pas de troisième option. Pas de « on le refera à la main cette fois-ci, on automatisera plus tard » : plus tard, c’était dans sept jours, puis encore sept jours après. Une tâche manuelle hebdomadaire perpétuelle n’est pas une dette, c’est une condamnation.
Ce que ça produit est assez simple à décrire et étonnamment rare à voir : une reconstruction testée cinquante-deux fois par an. Pas un plan de reprise dans un document. Pas un exercice annuel qu’on prépare trois semaines à l’avance. Le chemin normal, emprunté si souvent qu’il n’y a plus rien dessus qui puisse surprendre.
Et une conséquence secondaire à laquelle je ne m’attendais pas : ça change ce qu’on accepte d’ajouter. Quand chaque nouveauté doit survivre à une destruction hebdomadaire, on réfléchit à deux fois avant d’introduire quelque chose qui ne se décrit pas. Le coût de la bidouille manuelle n’est plus repoussé dans un avenir vague, il arrive mardi.
« Mais mon système a des données »
C’est l’objection immédiate, et elle est juste. Weeklynet n’avait rien à conserver : le réseau lui-même était neuf. Votre base de production, elle, contient des choses que personne ne peut recalculer.
Sauf qu’en pratique, la part de votre système qui doit vraiment survivre est beaucoup plus petite que ce que vous croyez. Un cluster Kubernetes n’a pas d’état digne d’être sauvegardé. Un index de recherche se reconstruit. Un cache aussi, par définition. Une image de conteneur se rebâtit. Un entrepôt analytique se recalcule depuis ses sources. Un serveur d’application ne contient rien du tout.
Le vrai périmètre irremplaçable, dans la plupart des systèmes, c’est une base de données et un espace de stockage de fichiers. Le reste est dérivé — et le dérivé n’a pas besoin d’être sauvegardé, il a besoin d’être reconstructible. Ce sont deux problèmes différents, avec deux solutions différentes, et les confondre coûte cher dans les deux sens. J’y reviens dans un autre billet, parce que c’est le sujet en soi.
Une fois ce tri fait, la question devient praticable : est-ce que la partie non-données de votre plateforme peut être détruite et refaite sans vous ? Pas en théorie. Cette semaine.
Ce que je vous propose
Vous n’allez pas détruire votre production toutes les semaines, et je ne le suggère pas.
Mais il y a une version raisonnable de l’exercice, et elle tient en une phrase : construisez un environnement complet depuis rien, à intervalle régulier, et chronométrez-le.
Un environnement de recette qu’on recrée entièrement tous les mois plutôt que de le laisser vieillir cinq ans. Un compte cloud vide, un apply, et la mesure du temps qu’il faut pour obtenir quelque chose qui répond. Ce chiffre n’a pas besoin d’être bon. Il a besoin d’exister, parce que sans lui, « on pourrait reconstruire » est une opinion.
Et il rend un service annexe : c’est le même chiffre que celui qui dit combien de temps il vous faudrait pour partir de chez votre hébergeur. J’ai écrit ailleurs que la souveraineté se déclare et que la réversibilité se mesure. C’est cette mesure-là.
Le premier essai fait toujours mal. C’est précisément pour ça qu’il vaut mieux le faire un mardi choisi qu’un jeudi subi.
Une reconstruction qu'on n'a jamais faite n'est pas un plan. C'est un espoir.