Pourquoi un déploiement reproductible plutôt que manuel

Cette page n'explique pas comment déployer. Elle explique pourquoi on décrit une infrastructure sous forme de code versionné et rejouable, plutôt que de la construire à la main en tapant des commandes une à une sur un serveur. Le sujet n'est pas un outil : c'est un arbitrage entre la vitesse d'aujourd'hui et la maîtrise de demain.

Le problème : un serveur configuré à la main est un état qu'on ne connaît plus

Configurer un serveur à la main donne un résultat qui marche — dans l'instant. Mais ce résultat est un état, pas une description. Personne ne détient la liste exacte des gestes qui y ont mené : un paquet installé un soir de correctif, une valeur ajustée pour débloquer une situation, une option laissée par défaut sans qu'on l'ait décidé. La configuration réelle du système n'existe nulle part ailleurs que dans le système lui-même.

Trois conséquences en découlent, et elles s'aggravent avec le temps.

On ne sait plus ce qui a été fait

Un geste manuel ne laisse pas de trace exploitable. Un historique de commandes, quand il existe, mélange les essais ratés, les corrections et les allers-retours ; il ne dit pas quelle configuration est intentionnelle et laquelle est un résidu. La connaissance du système vit dans la mémoire de la personne qui l'a monté — une mémoire qui s'efface, et qui part avec elle.

On ne peut pas le recréer

Le vrai test d'une infrastructure n'est pas « est-ce qu'elle tourne ? », mais « saurait-on la reconstruire à l'identique si elle disparaissait ? ». Un serveur manuel échoue à ce test. Reproduire un environnement de test fidèle à la production, remonter après un incident matériel, ou simplement monter un second serveur équivalent devient une enquête : on tente de deviner l'état d'origine au lieu de le rejouer. Ce qui n'est pas reproductible n'est pas vraiment sous contrôle.

La dérive s'installe

Deux serveurs censés être identiques divergent dès la première intervention faite sur l'un et pas sur l'autre. C'est la dérive de configuration : un écart lent, invisible, qui n'apparaît qu'au pire moment — quand un comportement diffère entre environnements sans raison apparente. Chaque correctif appliqué à la main creuse l'écart, et personne ne tient le compte.

Le renversement : décrire l'infrastructure comme du code

L'infrastructure-as-code inverse le rapport entre l'intention et l'état. Au lieu d'agir sur le serveur et d'espérer que le résultat corresponde à ce qu'on voulait, on écrit ce que le système doit être, et un mécanisme se charge d'amener le système dans cet état. La description devient la source de vérité ; le serveur n'en est que le reflet.

Ce déplacement change la nature de chaque propriété du système.

• Versionnable. La description vit dans un dépôt, avec un historique. On lit qui a changé quoi, quand et — via le message de changement — pourquoi. L'infrastructure hérite de la même mémoire que le code applicatif.
• Revue. Un changement d'infrastructure devient une proposition qu'on relit avant de l'appliquer, au lieu d'une action déjà exécutée qu'on découvre après coup. On déplace la vérification avant l'impact, pas après.
• Rejouable à l'identique. La même description, appliquée deux fois, produit le même état. Reconstruire n'est plus une enquête : c'est une exécution.
• Documentée par construction. La description est la documentation, et elle ne peut pas mentir : si elle divergeait du réel, le système ne serait pas dans l'état décrit. Contrairement à une documentation manuelle, elle ne prend pas la poussière — elle est exécutée, donc vérifiée.

Idempotence : appliquer sans casser

Une propriété fonde tout l'édifice : l'idempotence. Une description bien conçue peut être appliquée un nombre quelconque de fois avec le même résultat final. Si le système est déjà dans l'état voulu, l'application ne fait rien ; s'il en a dérivé, elle l'y ramène. C'est ce qui rend l'infrastructure convergente : on ne décrit pas une suite d'étapes à jouer une fois, mais un état-cible vers lequel le système est ramené à chaque exécution. La dérive n'a plus le temps de s'installer, parce que rejouer la description l'efface.

C'est la différence de fond avec un script impératif classique, qui suppose un point de départ connu et casse si on le relance deux fois. On ne décrit plus les gestes, on décrit la destination.

Ce que cet arbitrage coûte, et pourquoi on le paie quand même

L'infrastructure-as-code n'est pas gratuite, et prétendre le contraire serait malhonnête. C'est un arbitrage, au même titre que le typage strict ou la sécurité par conception : on accepte un coût en amont pour supprimer une classe de problèmes en aval.

Le coût réel

• Une courbe d'apprentissage. Décrire un état plutôt que d'exécuter des gestes demande un autre mode de pensée. Il faut apprendre l'outillage, ses conventions, sa manière de représenter la réalité.
• Un investissement initial. Le premier serveur décrit prend plus de temps que le premier serveur monté à la main. Écrire la description est plus lent que taper la commande — la première fois.
• Une indirection. On n'agit plus directement sur le système ; on passe par une couche d'abstraction qu'il faut, à son tour, comprendre et déboguer.

Pourquoi le pari est presque toujours gagnant

Ce coût est un coût fixe, payé une fois, tôt. Le coût qu'il évite est un coût récurrent, qui croît avec le temps et le nombre de serveurs : l'enquête à chaque incident, la dérive à chaque correctif, la reconstruction impossible, la connaissance qui s'évapore. Le manuel semble moins cher parce qu'on ne voit que sa première facture ; l'IaC semble cher parce qu'on paie tout d'avance.

L'horizon de temps tranche. Qui optimise la journée tape la commande. Qui optimise l'année écrit la description. Le seuil de rentabilité est atteint dès qu'un système doit être maintenu, reproduit, ou compris par plus d'une personne — c'est-à-dire presque toujours.

Où la ligne se déplace

Cet arbitrage n'est pas absolu. Pour une machine jetable, montée pour une heure puis détruite, l'investissement de description ne se rentabilise jamais : le manuel est le bon choix, assumé. La discipline ne consiste pas à tout automatiser par principe, mais à savoir quand la reproductibilité cesse d'être un luxe pour devenir la condition de la maîtrise.

La règle pratique : dès qu'un état doit survivre à la personne qui l'a créé, être recréé ailleurs, ou rester identique dans le temps, il doit être décrit plutôt que gesticulé. Le reste est un pari sur sa propre mémoire — un pari qu'on perd toujours au moment le plus coûteux.