Intégrations IA – chemin des données et souveraineté

En vigueur : 2026-05-24 - intégrations IA de fremforge, phase 1

L’essentiel en une phrase #

Sur le chemin par défaut, fremforge ne fait jamais traiter le code client par un fournisseur d’IA américain en tant que sous-traitant ultérieur. Le client apporte sa propre clé de fournisseur d’IA (BYOK) et choisit lui-même son fournisseur. Ce fournisseur est le sous-traitant du client, sous le contrat du client, et non un sous-traitant ultérieur de fremverk au titre de l’accord de traitement des données (DPA).

C’est inscrit à l’annexe B §B.8 du DPA.

Ce que couvrent les « intégrations IA » #

fremforge propose quatre fonctionnalités IA côté serveur qui utilisent le fournisseur d’IA configuré par le client. Chacune reste désactivée tant que le client n’a pas ajouté de clé de fournisseur :

1. Revue de PR par IA – à l’ouverture ou à la synchronisation d’une pull request, fremforge envoie le diff + les métadonnées de la PR au fournisseur configuré et publie un commentaire de revue structuré, avec un statut de commit pending → success / warning.
2. Explications des mises à jour de dépendances Renovate – les PR créées par Renovate reçoivent un prompt plus ciblé, centré sur la correction des CVE et le risque de changements incompatibles.
3. Passerelle appelable par le client – POST /api/v1/orgs/<slug>/ai/complete avec un PAT portant le scope ai:invoke. Les workflows et scripts du client appellent ce point de terminaison au lieu d’embarquer les SDK des fournisseurs.
4. Correction IA des résultats SAST – désactivée par défaut, même lorsqu’une clé est configurée ; c’est un propriétaire de l’organisation qui l’active. Lorsqu’une personne clique sur AI fix sur un résultat relevant d’une courte liste de règles SAST, fremforge envoie au fournisseur configuré la description de la règle et au plus 60 lignes du fichier concerné, vérifie le diff renvoyé, l’analyse à nouveau et ouvre une pull request qui n’est jamais fusionnée automatiquement. Le prompt, le code et le diff ne sont pas conservés par fremforge. Voir AutoFix.

Il existe un chemin distinct pour l’outillage IA côté développeur (Claude Code, Cursor, Continue, JetBrains AI qui dialoguent avec fremforge via l’API REST standard + un PAT). Ce chemin ne fait transiter aucun fournisseur d’IA par l’infrastructure de fremverk ; voir docs.frem.sh/get-started/ai-in-your-ide/.

Fournisseurs pris en charge (phase 1, BYOK) #

fremforge prend en charge trois types d’adaptateurs qui couvrent tous les grands fournisseurs actuels :

Le client colle une clé d’API de fournisseur dans l’interface d’administration, sur /<org>/_admin/ai-integrations. La clé est chiffrée au repos en AES-256-GCM avec T Cloud Public DEW KMS et une liaison AAD par ligne (ainsi, une clé extraite d’une sauvegarde de base de données ne peut pas être déchiffrée sans extraire aussi l’identifiant de la ligne correspondante).

Le chemin des données #

Pour chaque appel IA (revue de PR, explication Renovate ou /ai/complete appelé depuis un workflow) :

1. La requête provient du dépôt du client, d’une charge utile de webhook ou d’une étape de workflow.
2. Le pod api de fremforge assemble le prompt : texte du diff + métadonnées de la PR + prompt système + messages fournis par le client.
3. Le pod api de fremforge envoie une requête HTTPS à l’URL du fournisseur configuré par le client, avec la clé configurée par le client.
4. La réponse du fournisseur est enregistrée : nombre de tokens, latence, nom du modèle, texte de la réponse.
5. fremforge publie un commentaire Forgejo (revue de PR) OU renvoie la réponse au workflow (/ai/complete).
6. Une ligne ai_usage_events enregistre l’appel : locataire, fournisseur, modèle, tokens en entrée, tokens en sortie, latence. Le prompt et le corps de la réponse ne sont pas conservés au-delà de la durée de vie de la requête.

Le prompt et la réponse transitent une seule fois par le pod api de fremforge. Ils ne passent par aucun agrégateur de journaux tiers, aucun service d’observabilité et aucune sauvegarde. L’audit de chaque appel enregistre les métadonnées (quelle fonctionnalité, quel fournisseur, nombre de tokens), mais pas le contenu.

Pourquoi ce n’est « pas un sous-traitant ultérieur » #

Selon l’article 28 du RGPD, une entité devient sous-traitant ultérieur lorsque le responsable du traitement la désigne, contracte avec elle et lui donne instruction de traiter les données pour son compte. Aucune de ces conditions n’est remplie ici :

• Le client choisit le fournisseur d’IA. fremverk n’en désigne ni n’en recommande aucun. La liste déroulante de l’interface d’administration présente des types d’adaptateurs, pas des recommandations.
• Le client contracte directement avec le fournisseur d’IA. fremverk n’a aucune relation commerciale avec le fournisseur d’IA à cette fin. Le client paie le fournisseur ; fremverk n’applique aucune marge sur le coût des tokens.
• Le client peut retirer le fournisseur d’IA à tout moment sans en informer fremverk. Ce n’est pas ainsi que fonctionne une relation de sous-traitance ultérieure avec fremverk.
• L’engagement de fremverk à n’avoir aucun sous-traitant ultérieur à société mère américaine, au §11.3 du DPA, est inchangé. Un client qui choisit un fournisseur d’IA constitué aux États-Unis (OpenAI, Anthropic, Google Vertex) s’expose à la juridiction de ce fournisseur – pas à celle de fremverk.

C’est la même position juridique que pour les fournisseurs d’identité choisis par le client (Microsoft Entra, Okta, Google Workspace, JumpCloud, Authentik) et fédérés avec fremforge via OIDC. Ils figurent dans la note d’en-tête de l’annexe B pour la même raison.

La trajectoire « clés en main » de la phase 2 #

Lorsque AIFS (T-Cloud AI Foundation Services) proposera un modèle spécialisé code suffisamment bon pour la revue de PR – attendu à ce jour dans 6 à 18 mois –, fremverk prévoit de proposer une offre IA clés en main : fremverk détiendrait un compte AIFS en Allemagne et facturerait les tokens par siège. Cette option constituerait un nouveau sous-traitant ultérieur de fremverk et serait ajoutée au registre de l’annexe B, sous réserve du préavis de 30 jours du §10.2.

Le chemin BYOK reste disponible même après l’arrivée de l’offre clés en main – les clients peuvent toujours apporter leur propre clé de fournisseur.

Visibilité dans l’audit #

Chaque appel IA émet un événement d’audit :

• tenant.ai_integration.provider_added / _disabled / _tested – modifications de la configuration des fournisseurs
• tenant.ai_integration.feature_default_changed – quel fournisseur gère quelle fonctionnalité
• tenant.ai_integration.repo_override_changed / _removed – surcharges par dépôt
• ai.complete.ok / ai.complete.failed – chaque requête /ai/complete appelée par le client

Les clients voient dans l’interface d’administration leur consommation de tokens par mois et les scores de satisfaction 👍/👎 par couple (fournisseur, modèle) ; les tables ai_usage_events et ai_review_comments alimentent les deux. Les journaux d’audit du client (§9 du DPA, conservation de 13 mois) incluent tous les événements tenant.ai_integration.*.

Dégradation en douceur #

Les fonctionnalités IA ne bloquent jamais une PR. Si le fournisseur configuré renvoie une erreur, atteint une limite de débit, dépasse le plafond de dépenses du client ou que la clé n’est pas valide, le commentaire de revue de la PR est omis et un statut de commit warning s’affiche (« AI review unavailable: retry on next push or fix the key »). La CI du client n’est pas affectée ; seul le commentaire généré par l’IA manque.

Questions, demandes d’audit #

Pour les responsables conformité : cette page est le document de confiance vers lequel vous pouvez renvoyer directement. Le support contractuel est l’annexe B §B.8 du DPA. Questions à compliance@frem.sh.