IA
L'IA révisable
Pourquoi la conversation sur l'IA en infrastructure doit passer de « faire confiance au modèle » à « réviser le travail ».
IA
Pourquoi la conversation sur l'IA en infrastructure doit passer de « faire confiance au modèle » à « réviser le travail ».
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 », ce qu'il veut habituellement dire, c'est : « j'ai vu des sorties assurées qui se sont révélées fausses, et je n'ai aucun moyen de l'attraper avant que ça ne touche la production. » La préoccupation n'est pas que l'IA puisse être imparfaite — tout système qui touche la production finit par être imparfait — c'est que l'imperfection puisse 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 bâtis pour qu'on leur fasse confiance comme à des réponses finales. D'autres sont bâtis pour être révisés comme des propositions. Le premier modèle place le fardeau de l'exactitude sur l'IA elle-même, ce qui est exactement le fardeau que les systèmes actuels ne sont pas en mesure de porter au niveau qu'exige l'infrastructure d'entreprise. Le second modèle place le fardeau sur un processus de révision auquel l'équipe du client fait déjà confiance. Presque tout usage productif de l'IA agentique dans des environnements de production dépend de la justesse de ce choix.
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 la sortie du modèle comme une proposition, pas comme un verdict. Le système agentique fait le gros du travail analytique : corréler le coût, l'utilisation, les politiques d'affaires et le contexte d'infrastructure à travers des milliers de ressources, générer le changement requis pour agir sur ce qu'il trouve, et l'acheminer à travers le processus de révision existant du client. Ce qui se présente devant un ingénieur humain est un pull request, pas une recommandation opaque. L'ingénieur le révise de la même façon qu'il révise tout autre changement d'infrastructure — lire le diff, vérifier le raisonnement, approuver ou rejeter.
C'est le modèle autour duquel JetScale est bâti. Chaque recommandation atterrit sous forme de Terraform lisible à l'intérieur d'un flux de travail Git standard, la trace de raisonnement voyageant à ses côtés : quels signaux ont été pris en compte, quelles politiques d'affaires ont été vérifiées, quel est l'impact projeté, quelles solutions de rechange ont été écartées. Avant qu'une recommandation n'atteigne un pull request, elle passe à travers un palier de vérification programmatique conçu pour attraper les erreurs de l'agent à la source — violations de politiques, IaC malformé, transitions de ressources non prises en charge — de sorte que la révision de code du client ne soit pas l'unique ligne de défense. Si l'IA se trompe, l'ingénieur l'attrape de la même façon que n'importe quel mauvais PR se fait attraper : en révision. L'IA accélère le travail analytique; le jugement de l'ingénieur gouverne ce qui est livré.
La raison pour laquelle cette conception désamorce la préoccupation d'hallucination, c'est que l'hallucination est une propriété des systèmes où la sortie est une réponse finale. Quand la sortie est une proposition révisable à l'intérieur du pipeline de gestion du changement existant du client, la question de savoir si le modèle génère à l'occasion quelque chose de faux devient beaucoup moins intéressante. Les mauvaises propositions sont rejetées à la révision de code, de la même façon que le sont les mauvaises propositions rédigées par des humains. L'infrastructure ne les voit jamais.
Le choix de conception plus profond porte sur ce dans 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 à l'environnement, fenêtres 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 ne font tout simplement jamais surface. L'espace des sorties possibles est façonné par la réalité du client avant que le modèle ne produise quoi que ce soit à réviser.
La transparence intégrée à ce flux de travail comporte un bénéfice de second ordre qui devient évident après six mois : chaque décision est auditable. Quand un régulateur, un dirigeant ou un auditeur interne demande pourquoi un changement particulier a été fait — ou ce que la plateforme a recommandé à 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é du côté du fournisseur à naviguer, pas de reconstruction de la prise de décision du fournisseur après coup.
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 une trace de ce qui a été livré et pourquoi? Quand la réponse à la seconde question est oui, la première question perd l'essentiel de son poids. C'est la conception dont JetScale part — et la raison pour laquelle la confiance, dans cette catégorie, n'a pas à être un acte de foi.