Une question légitime est posée aux équipes de packaging d'applications : si vous introduisez l'IA dans le packaging, qu'advient-il de vos données ? C'est exactement la bonne question à se poser. L'erreur serait d'en conclure que le packaging assisté par IA et un véritable contrôle des données ne peuvent pas coexister.

Ils le peuvent, et pour nous il s'agit d'une décision d'architecture, pas d'un argument marketing. Nous avons conçu EtherApps Forge pour que le packaging assisté par IA s'exécute au sein de votre environnement, sur votre tenant et sous votre gouvernance, ce qui signifie que vos données restent les vôtres. Cet article explique le raisonnement derrière ce choix : pourquoi nous n'avons délibérément pas créé de plateforme de packaging SaaS, et comment fonctionne un packaging IA maîtrisé lorsque le client possède l'infrastructure.

Nous avons délibérément renoncé à construire une plateforme de packaging SaaS

Le choix commercial évident aurait été de construire un service de packaging SaaS multi-tenant : les clients nous transmettent leurs applications, notre cloud fait le travail, et les données de chacun transitent par notre pipeline. C'est un modèle courant, et c'est précisément celui qui crée le risque pour les données que l'on a raison de redouter.

Nous avons fait le choix inverse. Forge permet aux clients de construire leurs propres solutions de packaging sur leurs propres tenants. Les binaires des applications, les preuves de capture, les packages, les prompts IA et les sorties restent tous au sein de l'environnement du client. Vous possédez l'infrastructure. Vous contrôlez le périmètre. Rien n'a besoin de quitter votre tenant pour produire un package.

Cette décision nous prive du confort d'un lac de données central, et cela nous convient. Le contrôle et la sécurité pour le client comptent davantage que le confort opérationnel pour nous.

Une IA gouvernée avec Azure AI Foundry, à l'intérieur de votre périmètre

Le packaging assisté par l'IA a tout de même besoin d'un modèle. La question est de savoir où ce modèle s'exécute et qui le gouverne. Forge est conçu pour utiliser Azure AI Foundry au sein du propre tenant du client, avec les protections qui rendent l'IA d'entreprise sûre :

  • Infrastructure détenue par le client – La ressource Foundry, le déploiement du modèle et le réseau se trouvent au sein de l'abonnement Azure du client. Nous ne relayons pas vos prompts via un service partagé.
  • Réseau privé et contrôle d'accès – Les points de terminaison privés, l'isolation réseau et l'accès basé sur les rôles maintiennent le trafic d'inférence à l'intérieur de votre périmètre, soumis à votre Conditional Access et à votre journalisation.
  • Aucun entraînement sur vos prompts – Azure AI Foundry et Azure OpenAI n'utilisent pas vos prompts, vos entrées ou vos sorties pour entraîner les modèles sous-jacents. Votre contexte de packaging vous appartient.
  • Votre périmètre de conformité – La résidence des données, la rétention et la politique suivent votre tenant, pas le nôtre, de sorte que les contrôles que vous appliquez déjà à Microsoft 365 et Azure s'appliquent aussi à l'IA de packaging.

C'est le point que l'argument du « LLM public » manque. Utiliser l'IA ne signifie pas envoyer des données clients vers un modèle public. Avec Forge, le modèle est celui que le client a choisi, déployé et gouverne, s'exécutant là où ses autres charges de travail réglementées s'exécutent déjà.

Nous n'utilisons pas les données des clients, et nous ne les utilisons jamais pour entraîner nos modèles

Parce qu'il n'existe aucune plateforme de packaging SaaS, il n'y a aucun pipeline central qui ingère discrètement les applications des clients. Nous ne collectons pas vos binaires. Nous ne récupérons pas vos preuves de capture. Nous n'entraînons aucun modèle sur les applications que vous packagez.

Ce n'est pas une politique que nous avons ajoutée après coup. C'est le même principe qui parcourt l'ensemble du portefeuille. EtherAssist possède l'un des ensembles de politiques de gouvernance et de contrôle des données les plus solides du secteur, et cet engagement à préserver la sécurité des données clients est la norme à laquelle nous soumettons chaque produit. Forge hérite de cet ADN : vos données sont les vôtres, et elles ne constituent pas notre jeu d'entraînement.

Votre environnement apprend de lui-même, et cet apprentissage reste chez vous

Ne pas entraîner nos modèles sur les données des clients ne signifie pas que l'outillage reste statique. Cela signifie que l'intelligence s'accumule au bon endroit : à l'intérieur de l'environnement contrôlé du client.

Une fois l'environnement d'un client mis en place, il apprend de lui-même et s'améliore à chaque fois que vous packagez une application. Les schémas, les correctifs et les décisions de packaging qui ont fonctionné sur votre parc rendent le package suivant plus facile, et cette connaissance accumulée réside dans votre tenant, sous votre gouvernance. L'apprentissage se produit dans un environnement contrôlé, et les données restent sécurisées. Vous bénéficiez d'un système qui s'améliore à l'usage, sans que cette connaissance ne quitte votre périmètre ni ne nous revienne.

Nous construisons nos propres modèles pour qu'ils s'exécutent sur vos appareils

Les points de terminaison Foundry gouvernés constituent une voie. Nous construisons également nos propres modèles pouvant être hébergés sur les appareils des clients, pour les équipes qui souhaitent le contrôle le plus fort possible. Lorsque le modèle s'exécute localement, il n'y a aucun appel d'inférence externe : l'intelligence de packaging s'exécute sur le matériel du client, entièrement à l'intérieur de son périmètre. C'est la même philosophie de conception poussée jusqu'à sa conclusion, en gardant à la fois les données et le modèle là où le client peut les voir.

Schéma : EtherApps Forge, Azure AI Foundry, auto-apprentissage contrôlé et modèles sur l'appareil s'exécutent tous à l'intérieur de la frontière de contrôle du tenant du client et produisent des sorties MSIX, MSI, IntuneWin, App Attach et App-V, tandis qu'un réseau de LLM publics et un pipeline SaaS multi-locataire restent en dehors de la frontière et ne sont volontairement pas utilisés.

La réalité des tests : MSIX ne peut pas être validé en mode headless

Il y a une vérité pratique à propos de MSIX que toute présentation honnête du packaging doit reconnaître. Vous ne pouvez pas tester correctement un package MSIX dans un conteneur headless. L'activation MSIX, le comportement au lancement, la réparation et le montage App Attach dépendent d'une session Windows interactive, de sorte que valider un package suppose de le faire sur une véritable surface Windows.

En pratique, cela signifie l'une des deux choses suivantes :

  • Windows Sandbox pour des vérifications rapides, jetables et interactives d'un seul package.
  • Des flottes de machines virtuelles dans le cadre d'un plan de test structuré lorsque vous devez valider à grande échelle, sur différentes builds et configurations.

À l'échelle de l'entreprise, provisionner et orchestrer ces tests à la main ne suit pas le rythme. C'est là que des plateformes dédiées comme Rimo3 prennent tout leur sens : elles sont conçues pour gérer les tests applicatifs automatisés à la vitesse et au volume qu'exigent les grands parcs.

Forge est conçu pour s'adapter à cette réalité plutôt que de faire comme si elle n'existait pas. Forge capture l'application, applique des décisions de packaging guidées par l'IA, et produit des sorties MSIX, MSI, IntuneWin, App Attach et App-V prêtes au déploiement, préparant chaque package pour les tests finaux et la validation. La manière dont vous menez ces tests finaux, que ce soit avec Windows Sandbox, votre propre plan de test sur VM ou une plateforme de test d'entreprise, relève de votre choix. Forge produit le package et les preuves ; c'est vous qui décidez comment il est éprouvé et validé.

Schéma de flux de la capture à la validation : capturer une application installée sur une vraie machine Windows, packaging assisté par IA avec Azure AI Foundry dans votre tenant, générer des sorties MSIX, MSI, IntuneWin, App Attach et App-V, exécuter les tests finaux de votre choix avec Windows Sandbox, un parc de VM ou Rimo3 à grande échelle, puis valider.

La question du LLM public, répondue sans détour

Nous sommes d'accord avec le principe selon lequel les données clients ne doivent jamais rencontrer de LLM publics. Ce point n'est pas contesté, et quiconque le soulève défend une position que nous tenons déjà.

Là où nous divergeons, c'est sur la conclusion. La réponse à ce risque n'est pas de tourner le dos à l'IA ni d'envelopper la discussion dans la peur. La réponse, c'est l'architecture :

  • Aucune plateforme de packaging SaaS, donc aucun pipeline central d'où faire fuir des données.
  • Des points de terminaison Azure AI Foundry gouvernés au sein du propre tenant du client.
  • Aucun entraînement par le fournisseur sur les données clients, en cohérence avec la norme de gouvernance d'EtherAssist.
  • Un apprentissage autonome qui reste à l'intérieur de l'environnement contrôlé du client.
  • Nos propres modèles, conçus pour s'exécuter sur les appareils des clients afin d'offrir le contrôle le plus fort.

Si vous avez vu des commentaires suggérant que le packaging assisté par l'IA revient à alimenter un modèle public avec les applications des clients, cela ne décrit pas le fonctionnement de Forge. Forge a été conçu dès le départ pour que le client possède le tenant, possède le modèle et possède les données. Ce n'est pas une réserve que nous ajoutons ensuite. C'est le fondement.

Commencez avec le contrôle, pas le compromis

Vous n'avez pas à choisir entre un packaging moderne assisté par l'IA et la sécurité de vos données. Avec EtherApps Forge, vous obtenez les deux, car le contrôle est conçu dès l'origine plutôt que promis après coup.

Essayez EtherApps Forge gratuitement
Sans carte bancaire. Essai de 7 jours.

Découvrez le packaging et le déploiement MSIX ou consultez le packaging applicatif agentique pour voir comment une opération de packaging contrôlée et fondée sur les preuves se met en place sur votre propre tenant.