Sortir la configuration de la console

Toutes les consoles d'administration racontent le même mensonge : que la modification qu'on vient de faire est maîtrisée, puisqu'on l'a faite soi-même. Six mois plus tard, personne ne sait plus pourquoi cet en-tête est réécrit sur cette API, la recette ne ressemble plus à la production, et le seul historique disponible est la mémoire de celui qui a cliqué.

Le remède est connu : la configuration dans un dépôt Git, déployée par une chaîne, comme du code. Ce qui manque n'est pas la conviction, c'est le chemin. « On fera de l'APIOps » reste dans les backlogs pendant des années parce que le chantier paraît devoir tout geler.

Il ne le demande pas. Voici l'ordre qui fonctionne.

Étape 1 : exporter, sans rien changer

Avant d'automatiser quoi que ce soit, faites exporter chaque nuit la configuration complète de la plateforme vers un dépôt Git. Toutes les gateways sérieuses le permettent, par API ou par CLI.

Ce cron d'une journée de travail change déjà la situation : vous avez un historique, un diff quotidien, et la capacité de répondre à « qu'est-ce qui a changé cette semaine ? ». Le jour où un comportement dérive, le diff pointe la modification. C'est de l'archéologie, pas encore de l'ingénierie, mais c'est la fin de l'amnésie.

Étape 2 : faire diverger les environnements dans un fichier, pas dans les têtes

Comparez les exports de recette et de production. La liste des écarts est toujours plus longue que ce que l'équipe imagine. Classez chaque écart : légitime (URL de backend, secrets) ou accidentel (cette policy de cache activée en recette « pour un test » en 2024).

Les écarts légitimes deviennent des variables dans les fichiers de configuration. Les accidentels se corrigent. À la fin de cette étape, la phrase « la recette prouve quelque chose » redevient vraie.

Étape 3 : déployer une API, une seule, par la chaîne

Choisissez une API vivante, modifiée régulièrement, portée par une équipe volontaire. Son contrat et sa configuration vivent dans un dépôt, une pipeline pousse vers la recette à chaque merge, vers la production sur tag. Le retour arrière est un revert.

Une seule API suffit pour affronter les vrais problèmes : les secrets, les identifiants d'objets qui diffèrent entre environnements, les policies qui référencent des ressources partagées. Les résoudre sur un cas concret produit l'outillage que les suivantes réutiliseront.

Étape 4 : fermer la console, périmètre par périmètre

C'est l'étape que tout le monde repousse, et sans elle les trois autres finissent par mourir : tant que la console reste ouverte en écriture, elle regagne du terrain à chaque urgence.

On ne la ferme pas d'un coup. On la ferme périmètre par périmètre : les API migrées passent en lecture seule pour tout le monde, avec une procédure de bris de glace tracée pour les incidents. L'accès d'urgence existe, il est journalisé, et chaque utilisation déclenche une remise en conformité du dépôt.

Les règles viennent ensuite, gratuitement

Une fois la configuration dans Git, la gouvernance change de nature : les règles ne sont plus un document, ce sont des vérifications dans la pipeline. Nommage, sécurité obligatoire, compatibilité de contrat avec la version précédente : tout se vérifie au build, avant que la plateforme soit touchée.

C'est l'ordre correct des choses. Les organisations qui commencent par écrire la norme finissent avec un document. Celles qui commencent par la chaîne finissent avec une norme appliquée.

Combien de temps

Sur une plateforme de taille moyenne, une centaine d'API : l'étape 1 se compte en jours, l'étape 2 en semaines, l'étape 3 en un ou deux mois avec l'équipe pilote. L'étape 4 prend le temps qu'il faut pour couvrir le parc, et c'est le rythme auquel votre plateforme cesse de dépendre de la mémoire des gens. Le détail de la cible est décrit dans Industrialiser.