La plupart des produits AI Suite s'installent sur la machine de l'utilisateur. Il n'y a pas de locataire. Il n'y a pas de connexion cloud qui limite l'accès au moteur d'inférence. Les applications de bureau communiquent avec un aisuite-server processus local qui, à son tour, dialogue soit avec un modèle embarqué, soit avec un AI Server contrôlé par le client et fonctionnant dans le réseau du client. Ce choix — installateur de bureau, pas SaaS — est délibéré, et les raisons méritent d'être exposées.

Raison 1 : les acheteurs régulés ne peuvent pas placer des requêtes de production dans le cloud d'un tiers

Le règlement européen sur l'IA, en vigueur depuis 2024, classe un ensemble important de flux de travail d'entreprise comme « à haut risque » et impose des obligations de tenue de registres, de supervision humaine et de gestion des données au déployeur [1]. Des cadres équivalents ou parallèles existent dans les pays membres de l'OCDE [2], et les agences fédérales américaines appliquent le cadre de gestion des risques IA du NIST lors de l'acquisition de systèmes IA [3]. Aucun de ces cadres n'interdit l'IA cloud ; ils exigent que le déployeur puisse démontrer, en temps réel et sur demande, ce qui a été envoyé où et ce qui a été retourné.

En pratique, cette exigence entre en conflit avec le fonctionnement actuel des API LLM cloud. Un responsable conformité pharma ne peut pas extraire une piste d'audit par requête d'un SaaS tiers pour un flux de travail traitant des identifiants patients, même si le SaaS est contractuellement conforme au RGPD. Il peut être nécessaire que la requête et la réponse ne quittent jamais un réseau qu'ils possèdent. La manière la plus propre de garantir ce chemin est de distribuer l'IA sous forme de binaire que le client exécute dans son propre périmètre — ce que nous faisons.

Ce n'est pas un acheteur hypothétique. La cohorte de clients à laquelle nous livrons depuis 2007 comprend six organisations du Fortune Global 500 dans les secteurs pharma, finance, gouvernement, juridique, défense et énergie [4]. Chacun de ces secteurs a au moins un flux de travail où la réponse à « où se fait l'inférence ? » détermine si la conversation d'achat commence même.

Raison 2 : un binaire installable correspond à la manière dont les entreprises achètent réellement des logiciels

Le processus d'achat d'une application de bureau est bien compris dans les grandes organisations informatiques. L'application est empaquetée, distribuée via SCCM, Intune ou Jamf, régie par les mêmes stratégies de groupe que Microsoft Office, supprimée lors de la mise hors service de l'ordinateur portable. Les achats, la revue de sécurité et l'informatique utilisateur final disposent de processus vieux de plusieurs décennies pour cela. AI Suite s'intègre directement.

Le SaaS cloud, en revanche, nécessite un processus parallèle : une revue des risques fournisseur par locataire, une négociation d'identité fédérée, des audits continus de la posture du fournisseur, et une négociation constante sur la répartition des obligations en cas de problème. Utile pour certains types de logiciels. Mauvais choix pour les types de flux IA que nos clients construisent.

En distribuant des applications installables pouvant s'authentifier auprès du fournisseur d'identité du client — Microsoft Entra ID ou Google Workspace via OpenID Connect — nous maintenons le contenu d'inférence hors du plan de contrôle de Software Tailor. Les services organisationnels traitent toujours les enregistrements nécessaires au fonctionnement du déploiement : listes et rôles, droits, politiques et état du serveur, usage agrégé, audit administratif, licences et support. Ce sont de véritables enregistrements côté fournisseur, mais ils sont séparés des requêtes, réponses et documents clients sur le chemin local ou hébergé par le client.

Raison 3 : zéro échec de projet depuis 2007 dépend de ne pas dépendre de la disponibilité d'autrui

Nous livrons des logiciels personnalisés depuis dix-neuf ans avec un bilan de zéro échec de projet depuis 2007 [4]. Ce bilan existe parce que l'équipe contrôle chaque couche de la livraison : code, compilation, test, artefact de déploiement. Dès que nous faisons dépendre le flux de production d'un client de la disponibilité du cloud d'une autre entreprise, ce bilan cesse d'être le nôtre à défendre.

Les fournisseurs d'IA cloud connaissent des pannes. Ils limitent les ressources. Ils modifient les tarifs. Ils retirent des modèles. Ils retirent des API entières. Les clients que nous servons dans la pharma et la défense ne peuvent pas voir leur dossier réglementaire d'une année bloqué parce qu'un point de terminaison de modèle qu'ils ne possèdent pas a été migré. Nous ne plaçons donc pas leur chemin de modèle local sur un tel service. Le modèle réside sur la machine du client et l'inférence s'effectue sur la machine du client. Notre infrastructure fournit les services du plan de contrôle nécessaires pour l'identité, les droits, la politique, l'état de la flotte, l'usage agrégé, l'administration et le support ; elle n'est pas le runtime d'inférence et ne reçoit pas le contenu des requêtes ou des réponses sur ce chemin.

Ce que cela signifie pour l'évaluation

Si vous êtes responsable conformité, DSI ou CTO évaluant l'IA locale pour un déploiement en entreprise, les questions pertinentes diffèrent de celles d'une évaluation SaaS cloud :

  • Où se déroule l'inférence ? Sur l'appareil de l'utilisateur, ou sur un serveur contrôlé par le client. Pas sur le nôtre.
  • Qu'est-ce qui sort du périmètre ? Sur le chemin d'inférence local ou hébergé par le client, aucune requête, réponse ou contenu de document ne transite vers Software Tailor. Les données du plan de contrôle, licence, sécurité, télémétrie (lorsqu'elle est activée) et support ont des chemins de données documentés séparés.
  • Quel est le journal d'audit ? JSONL sans contenu, stocké localement, exportable. Le modèle ne voit jamais de contenu sur lequel il n'est pas explicitement invité à agir, et la ligne d'audit ne voit jamais aucun contenu.
  • Que se passe-t-il lorsque le fournisseur disparaît ? Les binaires installés et le runtime local gratuit ne dépendent pas d'un locataire d'inférence hébergé. L'abonnement, l'organisation et les capacités Pro gérées centralement peuvent toujours dépendre de droits valides et de services du plan de contrôle, donc un plan de sortie doit en tenir compte.

Ce sont les quatre questions auxquelles nous avons construit AI Admin Console et la Local AI Suite pour répondre clairement. L'article sur la conformité au règlement européen sur l'IA et le déploiement sur site aborde plus en profondeur l'aspect réglementaire.

Références

  1. Commission européenne. « AI Act — Cadre réglementaire sur l'IA. » https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Consulté le 15-06-2026.
  2. Observatoire des politiques d'IA de l'OCDE. « Politiques nationales en matière d'IA. » https://oecd.ai/. Consulté le 15-06-2026.
  3. NIST. « Cadre de gestion des risques liés à l'IA (AI RMF 1.0). » https://www.nist.gov/itl/ai-risk-management-framework. Consulté le 15-06-2026.
  4. Software Tailor. « Clients précédents. » https://softwaretailor.com/past-clients.htm. Consulté le 15-06-2026.