Mettre en production sans être développeur : le playbook comme harness.

Dans un précédent article, je défendais une idée : quand l'IA fabrique vite, l'exigence doit se loger avant, dans le cadrage. Pendant la fabrication, on peut la laisser travailler seule, et ne juger que le résultat.

Il y a un moment où ce raisonnement cesse de tenir : la mise en production. Jusque-là, une erreur coûte une itération. À partir de là, elle touche une machine réelle, des visiteurs réels, et parfois d'autres services qui tournent sur le même serveur. Ce qui a été fait est difficile à défaire, et engage des tiers.

Mon métier, c'est le produit, pas l'administration de serveurs. Je ne lis pas une configuration de serveur web comme un développeur. Et pourtant, le site que vous lisez a été mis en ligne deux fois, sur une machine qui en servait déjà d'autres, sans rien casser. L'outil qui l'a permis n'est pas un logiciel : c'est un document, un playbook de déploiement.

Le problème : une IA qui connaît « les bonnes pratiques », pas votre machine

Demandez à un LLM de mettre un site en ligne : il vous proposera une configuration propre, conforme à ce qu'on lit partout. C'est justement le risque. Il connaît la bonne pratique, telle qu'elle est écrite dans la documentation la plus récente. Il ne connaît pas votre serveur : sa version, ce qu'il héberge déjà, ce que les autres sites y ont déclaré avant vous.

Sur mon propre déploiement, une ligne de configuration recommandée partout aurait, sur cette machine précise, empêché le serveur web de recharger sa configuration, et avec lui tous les autres services qu'il sert. Le correctif proposé ensuite aurait produit exactement le même effet, pour une autre raison. Deux pannes évitées, dans la même session, parce qu'on avait regardé la machine avant d'écrire, et posé la bonne question sur ce qu'elle servait déjà.

Rien de tout cela ne se voit en relisant un fichier. Et c'est là que le non-développeur est démuni : il ne peut pas juger la ligne. Il faut donc un cadre qui l'amène à juger autre chose.

Le playbook comme harness

Le harness, c'est tout ce qu'on construit autour du modèle pour que son comportement soit bon, et qu'il le reste d'une session à l'autre : les documents qu'il relit, les étapes, les points d'arrêt. Pour la mise en production, mon harness tient en trois couches.

• Un playbook générique, distillé d'un audit réel de mon serveur, puis nettoyé de tout ce qui lui était propre : aucune adresse, aucun nom de compte, aucun secret. Il décrit le modèle à reproduire et les protections à tenir, pour n'importe quel projet.
• Un playbook dérivé par projet, qui applique le générique à cette mise en ligne, avec les vraies valeurs. Une règle simple fixe leurs rapports : s'ils se contredisent, c'est le dérivé qui a tort.
• Un journal, tenu au fil de l'exécution : chaque étape, avec la sortie réelle de la machine. Pas un compte rendu écrit après coup, qui ne serait qu'une reconstitution plausible.

L'intérêt, pour quelqu'un qui n'est pas du métier, est que le playbook convertit un risque technique en questions auxquelles on peut répondre. Pour chaque étape, il dit ce qu'elle fait, si elle est réversible, et comment on revient en arrière. Je ne sais pas écrire la ligne ; je sais décider si j'accepte une étape irréversible, et à quelle condition.

Ce que contient le playbook

Une commande à la fois, et c'est vous qui appuyez

La règle qui compte le plus n'est pas technique, c'est un mode opératoire. L'IA propose une commande. Vous l'exécutez. Elle lit le résultat, puis propose la suivante. Pas de script déroulé d'une traite, pas de droits d'administration « le temps du déploiement », pas de mot de passe ou de clé générés par elle.

Cela ralentit, et c'est voulu. Chaque geste qui touche la production passe par une décision humaine, prise en voyant ce que la précédente a produit. Une étape qui échoue arrête la séquence : on ne continue pas « pour voir ».

Il existe une exception, et elle est étroite. Lors de la seconde mise en ligne, après avoir lu la simulation d'un transfert, j'ai demandé à l'IA de l'exécuter elle-même. Le playbook n'avait pas de mot pour ce cas ; il en a un désormais : la délégation nommée. Elle porte sur une commande précise, déjà vue en simulation, et elle ne s'étend ni à la suivante, ni à une variante. Un « enchaîne tout » n'en est pas une.

Trois règles qui ont chacune coûté quelque chose

Vérifié à un endroit n'est pas vérifié partout. Un site répond à plusieurs adresses : avec ou sans www, en https ou en http. L'IA avait vérifié que le serveur ne révélait pas sa version exacte, et l'avait déclaré réussi. C'était vrai sur l'adresse principale, faux sur les deux autres, qui ne portaient d'ailleurs aucune des protections prévues. La revue indépendante l'a mesuré. Même famille de défaut, trouvée avant la mise en ligne celle-là : sur les images et les feuilles de style, cinq protections sur six ne partaient pas, sans erreur ni message. Le playbook impose désormais un contrôle par adresse et par type de contenu, pages d'erreur comprises.

Un journal qui dit « absent » doit l'avoir mesuré. Une commande qui échoue et une chose qui n'existe pas se ressemblent beaucoup dans une sortie mal écrite. Pendant le premier déploiement, un simple refus d'accès a été traduit en « toujours absent », et a failli inverser deux conclusions. La règle : une erreur dit « la commande a échoué », jamais « la chose n'est pas là ».

Une revue lancée pendant une modification mesure un état déjà périmé. À la seconde mise en ligne, la revue de sécurité a tourné en même temps que le transfert des fichiers. Elle a signalé deux pages « toujours en ligne »… qui venaient d'être retirées. Faux rouge. Désormais, la revue se lance après la modification, jamais en même temps.

Un playbook qui n'apprend pas devient un piège

Seize jours après la première mise en ligne, le site a été entièrement redessiné et remis en ligne. C'est là que le playbook a montré sa vraie valeur, et sa limite.

Il interdisait une option de copie qui supprime, sur le serveur, les fichiers absents de la nouvelle version. L'interdiction avait une raison : le premier dossier servi contenait des pages publiées des mois plus tôt, qui n'existaient dans aucune version du projet, et qu'elle aurait effacées. Mais le nouveau dossier était dédié à ce seul site. Sans cette option, deux pages retirées du site seraient restées en ligne.

On aurait pu passer outre en silence. La règle a été réécrite à la place, avec ses conditions : le bon dossier, exactement ; rien d'autre n'y écrit ; et une simulation préalable dont les suppressions correspondent à la liste établie avant elle. La simulation en proposait deux. C'étaient les deux attendues.

En relisant tout cela, un constat moins flatteur : le playbook avait été écrit avant la première exécution, et le journal l'avait déjà contredit sur trois points, jamais reportés. Un playbook qui décrit ce qu'on comptait faire, et non ce qu'on a fait, finit par guider la prochaine session vers des erreurs déjà corrigées. Il se tient à jour comme le reste du produit.

L'utiliser avec votre LLM

Rien de tout cela ne dépend d'un modèle ou d'un hébergeur. Pour le transposer :

• demandez d'abord un playbook générique : le modèle de déploiement que vous voulez reproduire, sans aucune valeur propre à votre machine ;
• pour chaque mise en ligne, faites-en dériver un, rempli après un relevé en lecture seule de la cible, jamais avant ;
• exigez pour chaque étape sa réversibilité et le moyen de revenir en arrière ;
• imposez le mode opératoire : une commande à la fois, exécutée par vous, aucun secret écrit par l'IA ;
• n'acceptez aucune vérification sans sa sortie, et confiez la relecture finale à une conversation neuve ;
• après chaque exécution, reportez dans le playbook ce que le journal a appris.

Ce que ça change

Le playbook ne fait pas de vous un administrateur système. Il fait autre chose : il transforme une opération que vous ne savez pas juger en une suite de décisions que vous savez prendre. Est-ce réversible ? Qu'est-ce qui casse si c'est faux ? Où est la preuve ?

L'IA apporte la compétence technique. Le playbook s'assure qu'elle s'exerce sur votre machine, et que vous gardez la main sur ce qui ne se défait pas.

Vous mettez en production des projets construits avec l'IA et voulez comparer vos garde-fous, ou appliquer ce playbook à votre infrastructure ? Envoyez-moi un message privé.