Aller au contenu principal

Position sur l’IA et accès natif pour les agents

fremforge est agnostique en matière d’IA par conception. Le rôle de la forge est d’être un serveur Git propre, pensé d’abord pour l’API et conforme aux standards, qui interopère avec l’outillage d’IA choisi par votre équipe, quel qu’il soit.

fremforge n’héberge pas de modèles d’IA et ne fournit pas de clés d’IA. Les fonctions d’IA proposées sont facultatives, à activer explicitement, et ne fonctionnent qu’avec la propre clé de fournisseur d’IA de votre organisation (apportez votre propre clé, BYOK). Elles sont désactivées par défaut : rien n’est envoyé à un fournisseur d’IA tant qu’un administrateur de l’organisation n’a pas ajouté une clé de fournisseur, et chaque fonction peut ensuite être désactivée pour toute l’organisation ou pour un seul dépôt. Le fournisseur que vous choisissez agit dans le cadre de votre contrat avec lui.

Ces fonctions sont la revue de PR par IA, les explications Renovate et le point de terminaison /ai/complete appelable par les clients. Voir Admin → Intégrations IA pour la liste des fournisseurs pris en charge (Anthropic, OpenAI, Azure OpenAI, Mistral, Vertex Gemini ou toute URL compatible OpenAI) et le guide de configuration.

Apportez votre propre IA

Les outils que vos développeurs utilisent aujourd’hui fonctionnent avec fremforge sans modification :

  • Claude Code fonctionne avec n’importe quel dépôt Git distant et n’importe quelle API REST documentée. Pointez-le vers un dépôt fremforge et il se comporte comme avec GitHub.
  • Cursor utilise le workflow Git standard. La configuration de l’éditeur est conservée.
  • Windsurf : idem.
  • Codex CLI : idem.
  • Aider : idem.
  • Continue, Cody, etc. : les outils d’IA côté IDE qui travaillent au niveau des fichiers prennent en charge fremforge via le dépôt Git distant standard.

Il n’y a rien à configurer côté fremforge pour aucun d’entre eux. La forge traite les opérations Git pilotées par une IA comme les opérations Git humaines : push, pull requests, commentaires de tickets, appels d’API. La relation avec le fournisseur d’IA est la vôtre, pas la nôtre.

Pourquoi ce choix

Trois raisons, que nous détaillons chacune dans l’article de lancement sur le blog de fremverk :

  1. Le découplage compte pour la souveraineté. Les clients qui rejettent le Git des hyperscalers américains pour des raisons liées au CLOUD Act ont les mêmes raisons de rejeter les fournisseurs d’IA dont l’hébergement des modèles relève de la même juridiction. Rendre la décision sur l’IA indépendante de la décision sur Git permet à chaque client de composer sa propre posture.
  2. L’IA d’entreprise converge vers un seul fournisseur par organisation. La plupart des entreprises standardisent sur une seule plateforme d’IA pour tous leurs outils. Imposer un second fournisseur d’IA via la forge est une friction que personne n’a demandée.
  3. Le développement assisté par IA avancé a quitté l’interface de la forge. Il se fait dans l’IDE (Cursor, Windsurf), en ligne de commande (Claude Code, Aider, Codex CLI) et dans les extensions d’éditeur (Continue, Cody). L’interface de la forge sert à la collaboration et à l’exploitation, pas à la boucle d’IA.

Ce que nous livrons : une API de premier plan pour les agents

L’autre moitié de l’agnosticisme en matière d’IA consiste à faire de fremforge une plateforme excellente à utiliser depuis l’outillage d’IA :

Chaque action de l’interface d’administration a un point de terminaison d’API public

L’interface d’administration de fremforge est un client de l’API REST publique, sans point de terminaison réservé à l’administration ni lacune inattendue. Les agents de développement IA qui doivent provisionner des organisations, gérer les utilisateurs, configurer des politiques, lire des résultats ou lancer des exports le font sur la même surface que les humains.

Spécification OpenAPI à une URL stable

La spécification lisible par machine se trouve à /api/openapi.yaml. L’outillage d’IA qui consomme des spécifications OpenAPI (frameworks compatibles MCP, générateurs de clients pilotés par OpenAPI, boîtes à outils pour agents) peut la charger directement.

Les agents agissent pour le compte d’une personne

fremforge n’a pas d’identités d’agent. Un agent agit toujours pour le compte d’une personne. Aujourd’hui, les agents s’authentifient avec :

  • Un jeton émis par la personne, un jeton d’accès personnel. Dans ce cas, fremforge ne peut pas distinguer l’agent de la personne, et les événements sont enregistrés comme pour tout appel effectué avec ce jeton.
  • Un échange de jetons RFC 8693 avec un actor_token : le jeton de l’IdP de la personne comme subject_token et celui de l’agent comme actor_token. Le résultat est un jeton d’une durée maximale d’une heure, limité aux scopes autorisés par l’application de votre IdP. Voir Authentification native pour les agents.
  • Une autorisation de connecteur sur le serveur MCP distant, approuvée par la personne.

Un service qui agit pour l’organisation plutôt que pour une personne utilise à la place les identifiants client OAuth ou un jeton d’API d’organisation.

Attribution dans le journal d’audit. Lorsque fremforge connaît l’agent (un échange de jetons avec un actor_token, ou un connecteur MCP), les événements d’un agent portent la personne comme actor (un identifiant Forgejo, ou oidc:idp:<sub> pour un échange avec l’IdP d’un client) et l’agent dans fields.agent : oidc:agent:<sub> pour un échange, mcp-client:<client id> pour un connecteur MCP. fields.via_token nomme le jeton utilisé pour l’appel. Le journal d’audit de l’administration signale ces événements par une pastille via un agent, et son filtre d’acteur porte sur l’acteur, on_behalf_of et fields.agent, ce qui vous permet de retrouver tout ce qui a été fait pour une personne ou tout ce qu’un agent donné a fait. Les événements écrits avant le 2026-10-23 nommaient l’agent comme acteur et la personne dans on_behalf_of ; ils conservent cette forme et s’affichent comme pour le compte de la personne.

Encore sur la feuille de route :

  • Des mandats délégués, limités en portée et dans le temps : une personne accorde à un agent quelque chose de plus restreint qu’un scope de jeton (« peut ajouter jusqu’à 3 utilisateurs, valable 24 h », « peut uniquement lire les résultats, valable 1 h »), dans la limite de son propre rôle. Un agent agissant sous le mandat d’un membre ne peut pas modifier les politiques, car un membre ne le peut pas. La personne reste l’acteur.
  • Une implémentation de référence : un exemple Claude Code (ou Cursor / Codex) qui provisionne de bout en bout une nouvelle organisation fremforge pour le compte d’un utilisateur. Entièrement documenté, entièrement exécutable. Présenté comme « le premier hébergeur Git européen que votre IA peut acheter pour vous ».

Serveur MCP

Le serveur MCP distant sur https://frem.sh/_app/mcp expose les opérations de lecture de fremforge et de Forgejo sous forme d’outils MCP pour tout environnement compatible MCP. Quelques outils d’écriture nommés peuvent agir en tant que la personne, uniquement après que celle-ci a donné son consentement pour chaque outil et lorsque les propriétaires de l’organisation autorisent les écritures par connecteur. MCP est un protocole neutre ; l’adopter signifie que nous ne choisissons pas un fournisseur d’IA en choisissant une bibliothèque cliente. C’est cohérent avec notre position agnostique.

Ce que cela signifie pour les acheteurs en 2026 et 2027

Une prédiction sur laquelle nous sommes prêts à miser le produit : l’intégration de l’IA au niveau de la forge deviendra une question d’achat, comme la résidence des données l’est devenue en 2020. Les équipes conformité et sécurité commenceront à demander où l’inférence a lieu, qui traite les embeddings, si la télémétrie d’entraînement inclut le code des clients. Les fournisseurs dont l’IA est indissociable de leur produit principal répondront d’une manière ; ceux dont l’IA est facultative et choisie par l’utilisateur répondront d’une autre.

fremforge se place du côté de la réponse qui, selon nous, vieillira le mieux : aucune IA hébergée par la forge, et des fonctions d’IA facultatives, désactivées par défaut et exécutées avec le fournisseur que vous avez choisi. Apporter sa propre IA n’est pas un compromis ; c’est la position d’architecture qui sera encore la bonne en 2028, lorsque la moitié des offres d’IA intégrée actuelles auront changé de cap, été rachetées ou seront devenues hors de prix.

Voir aussi

Obtenir de l’aide

Pour toute question sur la portée des mandats d’agent, les modèles OpenAPI pour des frameworks d’agents particuliers ou la prise en charge d’un modèle d’intégration donné : écrivez à support@frem.sh avec un objet commençant par AI -.