Entreprise Publié le 2026-06-15 · 5 min de lecture

Pourquoi nous livrons l'IA sous forme de binaires installables, et non en SaaS cloud

Inférence locale, audit maîtrisé par le client et un parcours d'achats déjà en place. Trois raisons structurelles pour lesquelles les produits IA de Software Tailor sont des installateurs de bureau, et non un tenant dans notre cloud.

La majeure partie de la gamme AI Suite s'installe sur la machine de l'utilisateur. Il n'y a pas de tenant. Il n'y a pas d'authentification cloud qui conditionne l'accès au moteur d'inférence. Les applications de bureau dialoguent avec un processus aisuite-server local qui, à son tour, dialogue soit avec un modèle on-device, soit avec un AI Server maîtrisé par le client et fonctionnant à l'intérieur du réseau du client. Ce choix — installateur de bureau, et non SaaS — est délibéré, et les raisons méritent d'être consignées.

Raison 1 : les acheteurs réglementés ne peuvent pas placer des prompts de production dans le cloud d'autrui

L'EU AI Act, en vigueur depuis 2024, classifie un ensemble substantiel de workflows d'entreprise comme « à haut risque » et impose au déployeur des obligations de tenue de registres, de supervision humaine et de gestion des données ^[1]. Des cadres équivalents ou parallèles existent dans les États membres de l'OECD ^[2], et les agences fédérales américaines opèrent au regard du NIST AI Risk Management Framework lorsqu'elles acquièrent des systèmes d'IA ^[3]. Aucun de ces cadres n'interdit l'IA cloud ; ils exigent que le déployeur puisse démontrer, de manière contemporaine et par requête, ce qui a été envoyé où et ce qui est revenu.

Dans les faits, cette exigence entre en collision avec le fonctionnement actuel des API LLM cloud. Un responsable conformité pharmaceutique ne peut pas tirer une piste d'audit par prompt depuis un SaaS tiers pour un workflow qui traite des identifiants patients, même lorsque ce SaaS est contractuellement aligné RGPD. Il a besoin que le prompt et la réponse ne quittent jamais un réseau qu'il maîtrise. La façon la plus propre de le lui offrir est de livrer l'IA comme un binaire que le client exécute à l'intérieur de son propre périmètre — c'est ce que nous faisons.

Il ne s'agit pas d'un acheteur hypothétique. La cohorte de clients à qui nous livrons depuis 2007 inclut six organisations du Fortune Global 500 dans la pharmacie, la finance, le gouvernement, le juridique, la défense et l'énergie ^[4]. Chacun de ces secteurs comporte au moins un workflow où la réponse à la question « où l'inférence se produit-elle ? » détermine si la conversation d'achats peut seulement débuter.

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

Le parcours d'achat d'une application de bureau est bien rodé dans les grandes DSI. L'application est packagée, distribuée via SCCM, Intune ou Jamf, régie par les mêmes stratégies de groupe que Microsoft Office, supprimée lorsque le poste est mis hors service. Les achats, la revue sécurité et l'end-user computing disposent de processus éprouvés depuis des décennies pour cela. AI Suite s'y insère directement.

Le SaaS cloud, à l'inverse, requiert un parcours parallèle : une revue de risque fournisseur par tenant, une discussion sur la fédération d'identité, des audits continus de la posture du fournisseur et une négociation permanente sur les obligations de chacun en cas de défaillance. Utile pour certains types de logiciels. Mauvais ajustement pour le type de workflows IA que nos clients construisent.

En livrant des applications installables qui s'authentifient auprès du fournisseur d'identité du client — Microsoft Entra ID ou Google Workspace via OpenID Connect — et qui ne stockent rien sur nos serveurs au-delà du registre organisationnel et du journal d'audit des actions administratives, nous plaçons la conversation d'achats dans la case que celle-ci sait déjà traiter.

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

Nous livrons du logiciel sur mesure depuis dix-neuf ans, avec un bilan de zéro échec de projet depuis 2007 ^[4]. Ce bilan tient parce que l'équipe maîtrise chaque couche de la livraison : code, build, test, artefact de déploiement. À l'instant où nous faisons dépendre le workflow de production d'un client de la disponibilité continue du cloud d'une autre société, ce bilan cesse d'être le nôtre à défendre.

Les fournisseurs d'IA cloud connaissent des pannes. Ils appliquent du throttling. Ils modifient leurs tarifs. Ils retirent des modèles. Ils retirent des API entières. Les clients que nous servons dans la pharmacie et la défense ne peuvent pas voir leur dossier réglementaire d'un an s'enliser parce qu'un endpoint de modèle qu'ils ne possèdent pas a été migré. Nous ne les y plaçons donc pas. Le modèle vit sur la machine du client, l'inférence se produit sur la machine du client, et la seule chose qui réside sur notre infrastructure est la surface d'administration légère qu'ils utilisent pour gérer leur propre déploiement.

Ce que cela implique pour l'évaluation

Si vous êtes responsable conformité, DSI ou CTO et que vous évaluez l'IA locale pour un déploiement d'entreprise, les questions pertinentes ne ressemblent pas à celles d'une évaluation de SaaS cloud :

Où l'inférence se produit-elle ? Sur l'appareil de l'utilisateur, ou sur un serveur que le client maîtrise. Pas sur les nôtres.
Qu'est-ce qui quitte le périmètre ? Le registre organisationnel et les actions d'administration uniquement. Aucun prompt, aucune réponse, aucun contenu de document.
Quelle est la piste d'audit ? JSONL sans contenu, stocké localement, exportable. Le modèle ne voit jamais de contenu sur lequel on ne lui a pas demandé d'agir, et la ligne d'audit ne voit jamais de contenu du tout.
Que se passe-t-il si le fournisseur disparaît ? Les binaires que le client a installés continuent de fonctionner. L'AI Server local qu'il a enrôlé continue de servir. Aucune re-platformisation nécessaire.

Ce sont les quatre questions auxquelles AI Admin Console et la Local AI Suite ont été conçues pour répondre proprement. L'article sur la conformité à l'EU AI Act et le déploiement on-prem couvre le volet réglementaire de manière plus approfondie.

Références

Commission européenne. « AI Act — Regulatory framework on AI. » digital-strategy.ec.europa.eu. Consulté le 2026-06-15.
OECD AI Policy Observatory. « National AI policies. » oecd.ai. Consulté le 2026-06-15.
NIST. « AI Risk Management Framework (AI RMF 1.0). » nist.gov/itl/ai-risk-management-framework. Consulté le 2026-06-15.
Software Tailor. « Past clients. » softwaretailor.com/past-clients.htm. Consulté le 2026-06-15.

Évaluez la même approche sur une charge de travail réelle.

Un pilote gratuit d'une semaine déroule un véritable travail client — inférence locale, identité maîtrisée par le client, audit maîtrisé par le client.

Démarrer un pilote gratuit d'une semaine