Copilote IA pour l'infrastructure : ce qu'il peut, ce qu'il ne peut pas

Le gain réel est un gain de rappel. Un opérateur compétent connaît une dizaine d'outils en profondeur et les vingt autres de loin. Le modèle restitue sans effort l'invocation exacte de journalctl, la directive nginx qui correspond au comportement décrit, le champ qu'il faut lire dans la sortie de systemctl show. Sur un diagnostic, il compresse le temps passé à chercher la bonne formulation, pas le temps passé à réfléchir. C'est modeste, et c'est déjà beaucoup quand on ouvre une machine qu'on n'a pas administrée depuis six mois.

Le manque est toujours le même : l'état invisible. Un cron qui réécrit un fichier de configuration, un collègue qui a modifié une unité systemd sans la versionner, une dépendance implicite entre deux services. Rien de tout cela n'apparaît dans la sortie d'une commande, donc rien de tout cela n'existe pour le modèle. Et une même commande n'a pas la même gravité selon la machine : systemctl restart postgresql se lit exactement pareil sur un VPS de test et sur le primaire d'une réplication. La bonne question n'est donc pas de savoir si le modèle est bon, mais ce que coûte son erreur.

Le mode de défaillance propre aux agents est l'enchaînement. Chaque sortie devient l'entrée du tour suivant : si la troisième commande produit un résultat inattendu, le modèle ne conclut pas qu'il s'est trompé, il rationalise et continue. Sur un serveur, les effets de bord ne se rejouent pas à l'envers. Un fichier tronqué reste tronqué, une table iptables vidée coupe la session en cours, un service arrêté sous charge laisse derrière lui une file d'attente qui ne se rattrape pas.

Il faut y ajouter un risque structurel largement sous-estimé : la sortie d'une commande est du texte que le modèle lit, donc un canal d'entrée. Une ligne de log, une bannière de connexion, un nom de fichier fabriqué par un attaquant deviennent des instructions candidates. Personne ne sait aujourd'hui neutraliser complètement ce vecteur. C'est une raison suffisante pour que la décision d'exécuter reste un acte humain plutôt qu'un réglage.

Trois régimes couvrent l'essentiel des situations. L'observation, d'abord : le modèle inspecte, tout ce qui n'est pas classé sûr est refusé sans même proposer la validation, et l'échange sert à comprendre. La validation systématique ensuite : l'opérateur voit la commande exacte, dans sa formulation finale, avant qu'elle parte, et donne son accord commande par commande. L'autonomie surveillée enfin : les opérations de routine passent, seules les commandes destructrices arrêtent le flux. Dans Servor, ces trois régimes s'appellent Ask, Plan et Auto ; Plan est le mode par défaut, et le mode se change en cours de session.

Un point mérite d'être dit franchement parce qu'il est souvent survendu ailleurs : l'approbation porte sur une commande, pas sur un plan. Il n'existe pas d'objet plan figé qu'on approuverait en bloc avant exécution ; l'agent avance, propose, s'arrête. C'est moins confortable à raconter, mais la décision reste au niveau où l'effet se produit. Le vrai piège est ailleurs : la fatigue de validation. Quarante approbations d'affilée et la quarante et unième est cliquée sans lecture. Le nombre d'arrêts doit rester proportionnel au risque réel, ce qui suppose de classer chaque commande et pas seulement de choisir un mode de session.

Les deux ne se concurrencent pas, ils couvrent des zones différentes. Un playbook est déterministe, idempotent, relisible en revue, versionné avec le reste du code. Tout ce que vous savez faire deux fois par mois doit y finir : le codifier est plus sûr et moins cher que le redemander à un modèle. Ce qui reste en dehors, c'est la première heure d'un incident, la machine héritée dont personne n'a la documentation, l'opération rare qu'on refait une fois par an, le format de log jamais vu. C'est là que le copilote remplace six onglets de navigateur, pas le playbook.

Le ChatOps posait déjà la bonne structure : faire passer les opérations par un canal partagé, où la commande est visible, discutée, validée, et où la trace se construit d'elle-même. Un copilote change la source de la proposition, il ne change pas le modèle de responsabilité. Quant à l'AIOps, il a surtout traité la corrélation de signaux pour détecter plus tôt ; agir est resté une décision humaine. Traiter un copilote comme un opérateur junior très rapide, qu'on relit systématiquement, décrit la réalité mieux que n'importe quelle promesse d'autonomie.

Une liste de commandes interdites n'a de valeur que si elle est appliquée au-delà de l'interface : un filtre présent uniquement dans le navigateur tombe avec le premier contournement. Dans Servor, elle est appliquée côté serveur et côté agent, depuis la même base partagée : suppression récursive de la racine, écriture disque brute, fork bomb, écriture sur /etc/passwd, /etc/shadow ou /etc/sudoers. S'y ajoutent une analyse syntaxique de la commande, une classification de son risque, une limite de débit et la journalisation de chaque exécution. Un serveur peut aussi être installé en supervision seule : le plan de contrôle refuse alors toute exécution, quel que soit le mode choisi dans la console.

La traçabilité est le garde-fou qu'on néglige jusqu'au premier post-mortem. Toute commande, quelle que soit son origine, manuelle, IA, runbook ou terminal, est enregistrée avec sa sortie, son code de retour et sa durée, et le journal d'audit est chaîné par empreintes et protégé en écriture seule au niveau de la base, de sorte qu'une entrée ne puisse être ni modifiée ni supprimée. Rien de tout cela ne rend l'erreur impossible. Ces mécanismes réduisent la probabilité et la portée d'un incident, ils ne les ramènent pas à zéro, et la responsabilité de l'opération reste celle de la personne qui a validé.

Le mécanisme se décrit en trois phrases. Un seul outil est exposé au modèle : exécuter une commande. L'appel d'outil revient au navigateur, qui classe le risque, applique la politique du mode, affiche la demande d'approbation, puis relaie l'exécution. La commande est signée dans le navigateur avec une clé Ed25519 dérivée de la clé de coffre, et cette signature est vérifiée sur la machine cible, pas sur le serveur qui a transporté la requête ; une option par serveur rend cette signature obligatoire. La clé de coffre vient elle-même d'une phrase secrète jamais transmise : elle est dérivée dans le navigateur par Argon2id, une fonction volontairement lente et gourmande en mémoire, et sert à déballer une clé privée X25519 qui ne quitte pas la page.

La propriété obtenue se formule sans emphase : un plan de contrôle compromis ne peut pas forger une exécution, faute de posséder la clé qui la signe. Ce n'est pas de l'invulnérabilité, c'est une réduction du rayon d'impact ; une attaque réussie sur la plateforme ne donne pas mécaniquement un shell sur votre parc. Le même raisonnement gouverne l'agent installé sur la machine : il ouvre une connexion sortante, sans port entrant à exposer, ne reçoit jamais d'identifiant, et s'exécute sous l'utilisateur système que vous avez configuré.

En pratique, la console tient un historique unifié : une commande lancée par le copilote, par un runbook, par le formulaire d'exécution ou depuis le terminal web finit au même endroit, avec sa sortie, son code de retour et sa durée. Vingt-sept runbooks officiels couvrent les installations et durcissements courants, de nginx et PostgreSQL à Docker, fail2ban, UFW, WireGuard ou Prometheus et node_exporter. Ce qui est déjà écrit et relu n'a pas à être redemandé à un modèle.

Le copilote est inclus dans le plan AI, à 29 € HT par mois, avec 3 000 crédits mensuels. Un crédit correspond au coût réel des jetons traités : une question courte en consomme peu, une session de diagnostic longue davantage. Les plans Free et Operations n'incluent pas l'IA, et l'exploitation quotidienne reste utilisable sans copilote.