Foreman transforme les agents de grands modèles de langage (LLM) en ressources Kubernetes natives, permettant aux équipes d'exécuter du code généré par l'IA en production tout en gardant les coûts et la sécurité sous un contrôle strict.

Comment l'idée s'intègre dans le flux de travail de développement actuel

Les entreprises expérimentent des LLM capables d'écrire du code, mais la plupart des implémentations traitent le modèle comme une boîte noire de confiance. Un simple signal « terminé » provenant du modèle peut pousser des modifications non testées directement dans un dépôt, soulevant des préoccupations en matière de sécurité et de fiabilité. Parallèlement, l'exécution de services d'IA sur le cloud peut rapidement devenir coûteuse, surtout lorsque le même modèle est appelé de manière répétée depuis des pipelines CI.

La réponse de Foreman consiste à intégrer l'ensemble de la boucle de codage à l'intérieur d'un cluster Kubernetes. Foreman s'exécute en tant que ressources Kubernetes.

Les quatre objets fondamentaux qui permettent cela

  • Agent – Définit un travailleur. Il nomme le LLM à appeler, liste les outils que le modèle peut invoquer (par ex. file-write ou git-push) et définit un budget qui plafonne les appels au modèle. Les rôles s'y attachent ; un agent coder écrit le code, un agent verifier le vérifie.
  • Workload – L'unité de travail rédigée par l'utilisateur. Elle contient l'intention de haut niveau (par ex. « ajouter des tests unitaires pour le module X »), une référence au dépôt cible et une liste d'agents qui doivent gérer la tâche.
  • AgenticTask – La tâche concrète qu'un Workload génère. À mesure que le travail progresse, chaque AgenticTask enregistre des mises à jour de statut, permettant aux opérateurs de surveiller le pipeline en temps réel.
  • FleetNode – Un nœud Kubernetes qui exécute réellement les tâches. L'ordonnanceur intégré fait correspondre les AgenticTasks en attente aux FleetNodes possédant le rôle et les ressources requis.

La vérification remplace la confiance aveugle

Foreman ne suppose pas que la sortie du modèle est correcte. Lorsqu'un agent coder termine son travail, il envoie une requête plutôt qu'un résultat final. Un vérificateur — généralement un script déterministe, et non un autre LLM — fait passer le code à travers des linters, des tests unitaires ou des builds complets. Ce n'est que si ces vérifications réussissent que Foreman réécrit la nouvelle branche dans le dépôt.

Si le vérificateur échoue, la tâche est marquée comme rejetée et les modifications ne sont jamais appliquées. Cette séparation permet au modèle de générer de manière créative tout en maintenant le filet de sécurité sous le contrôle total de l'humain.

Installation de la pile sur un cluster

  1. Déployez le chart de base LLMKube avec Helm.
  2. Déployez le chart Foreman, également via Helm.
  3. Passez le mode agent en « native » pour que la véritable boucle requête-réponse soit active.
  4. Attribuez des rôles (coder, verifier) aux FleetNodes qui hébergeront le travail.

Deux ensembles d'identifiants sont requis : des identifiants git pour lire les issues et pousser des branches, et des identifiants de modèle pour appeler soit une API hébergée, soit un service d'inférence auto-hébergé.

Des leviers de coût et de sécurité réellement actionnables

Foreman permet aux opérateurs de limiter l'autorité d'un modèle en supprimant des outils de la définition de l'agent. Supprimer bash ou write_file empêche le modèle d'exécuter des commandes shell arbitraires ou d'écrire en dehors de l'espace de travail désigné.

Une limite de tours (turn limit) plafonne le nombre d'invocations du modèle par tâche, contrôlant ainsi directement les dépenses. L'ajustement de la fenêtre de contexte — la quantité de prompt que le modèle voit — permet de réduire davantage l'utilisation des tokens. Lorsque le modèle s'exécute localement sur du matériel sur site (on-prem), aucune donnée ne quitte l'organisation, respectant ainsi les politiques strictes de confidentialité des données.

Là où la plateforme excelle, et là où elle trébuche encore

Foreman excelle dans les tâches mécaniques et bien définies :

  • Correction d'un bug documenté.
  • Ajout de cas de tests manquants.
  • Mise à jour de la documentation pour la clarté ou le style.

Ces tâches présentent des critères de réussite clairs qu'un vérificateur peut contrôler automatiquement. Le système éprouve encore des difficultés avec les refontes architecturales de haut niveau ou les travaux sur des fonctionnalités ambiguës où la « justesse » dépend du jugement humain.

À retenir

En traitant les codeurs pilotés par LLM comme des ressources Kubernetes de premier ordre et en imposant une étape de vérification déterministe, Foreman offre une voie pragmatique vers la génération de code par IA en production, tout en gardant les dépenses visibles et la sécurité sous contrôle. Ce n'est pas une solution miracle pour tout travail de développement, mais pour les tâches répétitives et testables, il fournit un flux de travail auditable qui s'intègre naturellement dans les opérations cloud-native existantes.