Terraform avant les promesses IA

Un ami, service delivery manager, me demande si l'IA peut aider à migrer des applications legacy vers quelque chose de plus moderne. Il ne parle pas d'une petite appli oubliée dans un coin. Il parle de systèmes d'entreprise, de ceux qui font tourner du métier réel, avec des batchs, des données, des interfaces, des fenêtres de maintenance, des gens qui reçoivent des mails quand ça ne passe pas, et des comités où le mot "risque" n'est pas décoratif.

Puis la conversation glisse. Il me parle de legacy, de logiciels pour modéliser l'infra, de systèmes anciens, de migration, de modernisation. Je lui réponds avec Terraform, Kubernetes, Docker, open source, infra as code. Et je réalise au milieu de la phrase que je suis en train de faire un mini-cours d'infra moderne à quelqu'un qui livre des services informatiques dans un grand contexte d'entreprise.

Ce n'est pas une critique de mon ami. C'est même l'inverse. Sa question était bonne. Le problème, c'est ce qu'elle révélait. On demande à l'IA de moderniser des systèmes que l'organisation ne sait parfois plus décrire autrement qu'avec des schémas, des tickets, et la mémoire de trois personnes très fatiguées.

L'appel qui commence mal

La question avait l'air simple: est-ce que l'IA peut aider à migrer du legacy ?

L'IA peut lire du code pénible. Elle peut résumer un module COBOL, un vieux projet Java, un script shell, un fichier de configuration, une procédure de déploiement qui sent la salle serveur. Elle peut générer une première documentation, repérer des dépendances, proposer des tests, expliquer pourquoi un batch appelle un service qui appelle une base qui déclenche un export qui finit dans un partage réseau.

Mais elle ne sait pas décider seule ce que vous voulez opérer demain.

Et c'est là que l'appel a changé de nature. La vraie question, c'était pas "est-ce que l'IA peut migrer ?" La vraie question était: vers quoi ? Avec quel inventaire ? Quelle cible d'exploitation ? Quelle stratégie de rollback ? Quelle responsabilité ? Quelle équipe va lire les logs à 2 h du matin quand le vieux flux qui passait depuis quinze ans ne passe plus ?

J'ai commencé à parler de Terraform parce que la discussion n'avait pas besoin d'un modèle. Elle avait besoin d'un artefact plus sérieux.

Legacy ne veut pas dire vieux langage

On caricature souvent le legacy avec du COBOL et un écran vert. C'est pratique. Ça permet de se moquer d'un terminal sans regarder ce qui tourne autour.

Dans la vraie vie, le legacy d'un grand compte ressemble rarement à un seul langage. C'est un empilement. Un coeur métier assurance ou banque. Des modules SAP. Une base DB2 ou Oracle qui a vu passer plusieurs générations de DSI. Des batchs de renouvellement. Des interfaces vers le back-office, les portails clients, les réseaux de distribution, les outils de reporting, les flux comptables. Des files MQ. Des jobs planifiés. Des scripts de reprise. Des certificats. Des exceptions métier que personne ne veut documenter parce qu'elles sont plus anciennes que le service qui les porte.

Le système peut être sur mainframe, sur IBM i, sur x86/Linux, sur Windows, dans un datacenter privé, dans un cloud, ou dans une zone intermédiaire avec un nom rassurant. Ce n'est pas ça qui le rend legacy. Ce qui le rend legacy, c'est que le système continue à fonctionner alors que sa compréhension opérationnelle s'est dispersée.

Un vieux système bien compris n'est pas forcément un problème. Un système récent que personne ne sait reconstruire en est déjà un. On peut mettre une application dans un container et garder exactement le même problème. On a juste changé la boîte autour du malaise. Une migration ne commence donc pas avec un outil. Elle commence avec un inventaire suffisamment honnête pour faire mal.

Le référentiel mort

Dans beaucoup d'organisations, cet inventaire existe déjà. Sur le papier. Il y a une CMDB. Un outil d'Enterprise Architecture. Des modèles applicatifs. Des diagrammes. Des cartographies. Des couches, des capacités, des applications, des flux, des responsables, des technologies, des statuts. Parfois même un outil très cher pour expliquer que tout cela est une source de vérité.

Très bien.

Bah du coup la question est simple: si je déploie une nouvelle base demain, si je change une règle réseau, si je déplace un service, si je supprime une VM, si un module SAP parle à un nouveau endpoint, est-ce que le référentiel le sait parce que le système a changé, ou parce que quelqu'un a pensé à ouvrir un ticket de mise à jour ? Si la réponse est la deuxième, ce n'est pas une source de vérité. C'est une archive avec de l'ambition.

Photo: Joshua Tree National Park / NPS, domaine public, via Wikimedia Commons.

Je ne dis pas que les référentiels d'architecture sont inutiles. Ils portent une vue que Terraform ne portera jamais seul: finalité métier, capacité, criticité, ownership, risques, liens avec les processus. Un fichier .tf ne vous dira pas pourquoi cette application traite des contrats d'assurance vie ou pourquoi tel batch ne peut pas glisser de deux heures.

Mais un référentiel déconnecté du déploiement réel vieillit très vite. Il devient un plan de métro d'une ville qui a continué à construire des stations sans prévenir le cartographe. Là où Terraform devient intéressant, ce n'est pas parce qu'il dessine mieux. C'est parce qu'il force une discipline: ce que l'on veut créer doit être décrit avant d'être créé.

Pourquoi Terraform est arrivé dans la conversation

Terraform n'est pas magique. C'est même plutôt ennuyeux quand on l'utilise correctement. Des fichiers. Des modules. Des variables. Un plan . Un state . Des reviews. Des pipelines. Des environnements. Des conventions de nommage. Des tags. Des secrets à ne pas mettre au mauvais endroit. Des ressources qui veulent parfois se recréer alors que vous vouliez juste changer une virgule.

Justement.

L'intérêt de Terraform n'est pas seulement de provisionner une VM ou un bucket. L'intérêt est de transformer une partie de l'infrastructure en texte lisible. Ce texte peut être versionné, relu, comparé, testé, automatisé, audité. On peut voir ce qui change avant de le changer. On peut discuter d'une règle réseau dans une PR au lieu de la découvrir dans une console web. On peut dériver un inventaire depuis le code, le state, les tags, les modules et les conventions.

Ce n'est pas parfait. Le state peut mentir. Le code peut être mauvais. Les modules peuvent devenir des monstres. Mais on a un artefact. Et dans une migration legacy, un artefact vivant vaut mieux qu'un schéma magnifique que personne n'ose toucher.

Il existe aussi OpenTofu , né après le changement de licence de Terraform. Je ne veux pas transformer cet article en débat de gouvernance open source, mais le point compte: dans une stratégie d'infra moderne, il faut aussi regarder la réversibilité des outils qui décrivent votre infra. L'infra as code devient vite une dépendance centrale. Choisir son moteur, son hébergement de state, ses policies, ses workflows de review et ses droits d'exécution n'est pas une décision décorative.

Dans l'appel, mon conseil n'était donc pas "utilise Terraform et tout ira bien". C'était plutôt: commence par mettre la cible dans une forme que plusieurs équipes peuvent lire sans ouvrir un outil propriétaire ou demander à Michel, qui connaît encore le VLAN de 2014.

Kubernetes et Docker ne sont pas la modernité

À un moment, Kubernetes et Docker arrivent toujours dans la conversation. C'est normal. Les containers ont changé la manière de packager et livrer les applications. Kubernetes a donné un modèle d'orchestration standard pour beaucoup de workloads. Docker a rendu l'emballage applicatif beaucoup plus concret pour une génération d'équipes.

Mais Kubernetes n'est pas une modernisation. C'est une cible d'exécution.

Une application sans tests devient une application sans tests dans un container. Une application qui ne sait pas s'arrêter proprement devient un pod qui meurt mal. Une application qui écrit dans son disque local sans le dire devient une surprise persistante. Une application sans métriques devient une boîte noire avec un restartCount . Une application avec des dépendances réseau implicites devient un ticket firewall avec un logo plus moderne.

La modernisation se joue ailleurs: contrats d'interface, health checks, secrets, logs, droits, pipelines, rollback, observabilité, limites de ressources, dépendances déclarées, runbooks, capacité à reconstruire l'environnement.

Kubernetes peut aider si ces éléments existent. Il peut aussi industrialiser le désordre. Ce n'est pas la faute de Kubernetes. Un orchestrateur orchestre ce qu'on lui donne. Si on lui donne une application legacy opaque, il l'orchestrera avec une grande rigueur. Ce qui est une autre manière de dire qu'il déplacera le problème très efficacement.

Revenons à l'IA. Oui, elle peut aider.

Elle peut lire un vieux dépôt et sortir une première carte des modules. Elle peut expliquer un batch. Elle peut comparer deux fichiers de configuration. Elle peut transformer une procédure Word en checklist. Elle peut générer des tests de non-régression. Elle peut aider à écrire un module Terraform propre à partir d'un exemple existant. Elle peut détecter des incohérences entre un schéma, un fichier de config, un runbook et un ticket.

Elle peut surtout accélérer la phase que tout le monde sous-estime: comprendre ce qui existe.

Mais elle ne doit pas devenir le prochain écran de fumée. Une IA qui décrit un système à partir de sources incomplètes produit une description incomplète avec une meilleure grammaire. Une IA qui génère une cible sans contraintes d'exploitation produit une architecture qui a l'air moderne jusqu'au premier incident. Une IA qui migre du code sans tests migre aussi les ambiguïtés, les bugs et les règles métier implicites.

Le bon usage, ici, est modeste et puissant: cartographier, expliquer, proposer, comparer, accélérer la revue. Pas signer l'architecture cible à la place des équipes.

L'IA est très utile quand elle lit des artefacts. Elle est beaucoup moins utile quand on lui demande de compenser l'absence d'artefacts.

Les questions à poser avant de migrer

Après l'appel, je me suis dit que j'aurais dû répondre avec moins de noms d'outils et plus de questions.

Par exemple :

Ces questions sont moins vendeuses que "AI-powered modernization". Elles ont un avantage: elles ressemblent à du travail.

Ce que j'aurais dû répondre plus vite

Avec le recul, ma réponse aurait dû être plus courte.

Oui, l'IA peut aider à moderniser du legacy. Mais pas avant l'inventaire. Pas avant les dépendances. Pas avant les tests. Pas avant la cible. Pas avant l'exploitation.

Et si tu veux une première marche concrète, regarde Terraform. Pas parce que Terraform migre SAP, remplace un mainframe, comprend DB2, répare les batchs ou transforme une organisation en équipe plateforme. Il ne fait rien de tout ça.

Regarde Terraform parce qu'il oblige à écrire ce que tu veux opérer.

C'est déjà énorme.

Une infra décrite en code peut être relue. Une infra relue peut être discutée. Une infra discutée peut être corrigée. Une infra corrigée peut être reproduite. Une infra reproductible peut commencer à devenir un inventaire vivant.

L'IA devient intéressante à partir de là. Elle peut lire, comparer, générer, expliquer, accélérer. Elle peut être branchée sur des dépôts, des states, des modules, des runbooks, des logs, des tickets, des référentiels. Elle peut aider à faire le pont entre le vieux monde et le nouveau.

Mais elle ne remplacera pas le pont.

Avant de demander à l'IA de moderniser le legacy, il faut arrêter de le gérer comme une collection de tickets, de schémas morts et de souvenirs de production. Il faut le rendre inspectable.

Le reste, Kubernetes compris, vient après.