L'IA révisable

La mauvaise question sur l'IA

L'objection la plus courante à l'IA agentique en infrastructure ne porte pas vraiment sur l'IA. Elle porte sur la vérifiabilité. Quand un acheteur dit « les modèles hallucinent », il veut généralement dire j'ai vu des résultats présentés avec assurance qui se sont révélés faux, et je n'ai aucun moyen de le détecter avant que ça touche la production. La préoccupation n'est pas que l'IA puisse être imparfaite (tout système qui touche à la production finit par l'être), c'est que cette imperfection pourrait rester invisible jusqu'à ce qu'elle ait causé un problème.

C'est une préoccupation raisonnable, et elle pointe vers un véritable choix de conception. Certains systèmes d'IA sont conçus pour qu'on leur fasse confiance comme réponses finales. D'autres sont conçus pour être révisés comme des propositions. Le premier modèle place le fardeau de l'exactitude sur l'IA elle-même, un fardeau que les systèmes actuels ne peuvent tout simplement pas porter au niveau qu'exige l'infrastructure d'entreprise. Le second modèle place ce fardeau sur un processus de révision auquel l'équipe du client fait déjà confiance. Presque tout usage productif de l'IA agentique en environnement de production dépend de la justesse de ce choix.

Ce que « agentique » devrait vraiment signifier en infrastructure

L'architecture qui résout le problème de confiance n'est pas un meilleur modèle. C'est un flux de travail qui traite le résultat du modèle comme une proposition, pas comme un verdict. Le système agentique effectue le gros du travail analytique : corréler le coût, l'utilisation, les politiques d'affaires et le contexte d'infrastructure sur des milliers de ressources, générer la modification requise pour agir sur ce qu'il découvre, et l'acheminer à travers le processus de révision déjà en place chez le client. Ce qui arrive devant un ingénieur humain est une demande de tirage (pull request), pas une recommandation opaque. L'ingénieur la révise de la même façon qu'il réviserait toute autre modification d'infrastructure : lire le différentiel, vérifier le raisonnement, approuver ou rejeter.

C'est le modèle autour duquel Jetscale est bâti. Chaque recommandation arrive sous forme de code Terraform lisible, à l'intérieur d'un flux Git standard, accompagnée de sa trace de raisonnement : quels signaux ont été considérés, quelles politiques d'affaires ont été vérifiées, quel est l'impact projeté, quelles alternatives ont été écartées. Avant qu'une recommandation n'atteigne une demande de tirage, elle passe par une couche de vérification programmatique conçue pour intercepter à la source les erreurs de l'agent (violations de politique, IaC mal formé, transitions de ressources non prises en charge), afin que la révision de code du client ne soit pas la seule ligne de défense. Si l'IA se trompe, l'ingénieur l'attrape de la même façon que toute mauvaise demande de tirage est attrapée : en révision. L'IA accélère le travail analytique; le jugement de l'ingénieur détermine ce qui est déployé.

L'hallucination est le mauvais cadre d'analyse

Si cette conception désamorce la préoccupation liée à l'hallucination, c'est parce que l'hallucination est une propriété des systèmes où le résultat constitue une réponse finale. Quand le résultat est une proposition révisable à l'intérieur du pipeline de gestion du changement déjà en place chez le client, la question de savoir si le modèle génère parfois quelque chose d'erroné devient beaucoup moins préoccupante. Les propositions erronées sont rejetées en révision de code, exactement comme le seraient des propositions erronées rédigées par un humain. L'infrastructure ne les voit jamais.

Le choix de conception plus profond concerne ce sur quoi l'IA est ancrée. Les recommandations de Jetscale ne sont pas générées à partir de données d'entraînement génériques; elles sont ancrées dans l'état réel de l'infrastructure du client et dans ses politiques d'affaires. Contraintes de conformité, seuils d'approbation, garde-fous propres à chaque environnement, périodes de gel des changements : tout cela est ingéré comme contexte de premier ordre. Les recommandations qui les enfreignent ne sont pas filtrées après coup; elles n'émergent tout simplement jamais. L'espace des résultats possibles est façonné par la réalité du client avant même que le modèle ne produise quoi que ce soit à réviser.

La vérifiabilité est le fondement, pas la finition

La transparence intégrée à ce flux de travail comporte un avantage de second ordre qui devient évident après six mois : chaque décision est vérifiable (auditable). Quand un régulateur, un dirigeant ou un auditeur interne demande pourquoi un changement précis a été effectué, ou ce que la plateforme a recommandé au cours d'un trimestre passé, la réponse se trouve dans le même système Git que l'équipe d'ingénierie utilise pour gérer tout autre changement d'infrastructure. Il n'y a pas de journal d'audit distinct à maintenir, pas d'opacité côté fournisseur à contourner, pas de reconstitution après coup d'une prise de décision opaque chez le fournisseur.

La bonne question à poser au sujet de l'IA agentique en infrastructure n'est pas puis-je faire confiance à ce modèle? C'est puis-je réviser ce qu'il produit, et ai-je un registre de ce qui a été déployé et pourquoi? Quand la réponse à la seconde question est oui, la première perd la majeure partie de son poids. C'est le point de départ de la conception de Jetscale, et la raison pour laquelle la confiance dans cette catégorie n'a pas à être un acte de foi.