Chamath Palihapitiya avertit que les agents IA mettent en conflit les logiciels adoptés par la base et la propriété intellectuelle des entreprises

Chamath Palihapitiya remet en cause l’adoption ascendante de logiciels, avertissant que les agents IA transforment l’expérimentation informelle en un canal potentiel de fuite de propriété intellectuelle.

Une publication Google News a fait remonter cet argument via un article de Benzinga le 6 août. L’affirmation sous-jacente est plus lourde de conséquences qu’une nouvelle prédiction d’investisseur sur la demande de logiciels. Palihapitiya s’interroge sur celui qui capte les connaissances créées lorsque les employés apprennent aux agents le fonctionnement de leurs entreprises.

Traditionnellement, les logiciels adoptés par la base entrent dans une entreprise par des utilisateurs individuels, puis se diffusent au sein des équipes avant que les dirigeants ne négocient un contrat d’entreprise. Slack, Zoom, Dropbox et de nombreux outils de développement ont bénéficié de ce modèle. Les agents IA le compliquent, car ils consomment des documents, des corrections, des autorisations et du contexte opérationnel tout en exécutant des tâches.

Le conflit central n’oppose donc pas simplement les employés aux équipes de sécurité. Il oppose l’adoption ascendante à l’apprentissage institutionnel contrôlé. Les employés veulent immédiatement des outils performants, tandis que les entreprises doivent préserver les raisonnements, flux de travail et exceptions qui distinguent leurs activités.

L’article Google News transforme l’adoption de logiciels en question de propriété

L’avertissement de Palihapitiya présente l’adoption de l’IA comme une lutte pour déterminer qui possède l’apprentissage généré au sein de l’organisation d’un client.

Le rapport Google News attribue à Palihapitiya deux préoccupations liées. Premièrement, les agents IA fragilisent la stratégie ascendante établie pour vendre des logiciels. Deuxièmement, un déploiement insuffisamment contrôlé crée ce qu’il décrit comme des « fuites de PI/d’alpha ».

Dans ce contexte, « alpha » désigne l’avantage difficile à reproduire d’une entreprise, et pas seulement des fichiers confidentiels. Cela comprend le jugement en matière de prix, la connaissance des clients, les raccourcis opérationnels, les méthodes de recherche et les exceptions dissimulées derrière les procédures formelles. Une grande partie de ces connaissances n’apparaît jamais dans un document de politique interne soigné.

Un outil logiciel ordinaire reçoit généralement des entrées structurées et renvoie des résultats prévisibles. Un agent reçoit des instructions plus larges, choisit des outils, lit des documents d’appui et accomplit plusieurs étapes. Il a souvent besoin de corrections avant que ses résultats ne correspondent aux standards de l’organisation.

Ces corrections ont une valeur inhabituelle. Un employé peut expliquer pourquoi un client bénéficie d’une exception, pourquoi un fournisseur semble risqué ou pourquoi un raccourci technique a échoué auparavant. Chaque explication révèle une partie du système pratique de décision de l’organisation.

Cela ne signifie pas que chaque correction entraîne le modèle de fondation d’un fournisseur. Les grands fournisseurs distinguent le traitement des données clients de leur utilisation pour l’entraînement des modèles. La préoccupation va au-delà d’un simple paramètre d’entraînement.

Un fournisseur peut néanmoins s’intégrer profondément aux flux de travail, intégrations, méthodes d’évaluation et habitudes opérationnelles du client. Le client dépend alors d’une couche d’intelligence externe pour appliquer ses connaissances internes. Même sans entraînement de modèle, cette dépendance peut déplacer le pouvoir de négociation.

Palihapitiya a déjà soutenu que les entreprises risquent d’abandonner leur avantage tout en pensant construire une stratégie IA. Une analyse connexe a relié sa position au confinement des connaissances et à un déploiement gouverné.

Son intérêt financier compte dans l’évaluation de cette affirmation. Palihapitiya a cofondé 8090, qui développe Software Factory, une couche de gestion pour le développement logiciel assisté par IA. Son positionnement bénéficie des inquiétudes liées aux agents non contrôlés et aux outils fragmentés.

Ce conflit n’invalide pas l’argument, mais impose une attribution prudente. Palihapitiya n’est pas un auditeur neutre décrivant une fuite avérée. C’est un investisseur et fournisseur qui défend une architecture alignée sur le produit de son entreprise.

L’avertissement rapporté ne fournit pas non plus de preuve qu’une entreprise nommée ait perdu un avantage concurrentiel par l’intermédiaire d’un grand fournisseur commercial d’IA. Les « fuites de PI/d’alpha » restent un modèle de risque stratégique, et non une conséquence universelle documentée. Les lecteurs doivent distinguer le mécanisme de la version la plus forte de la prédiction.

Le mécanisme est crédible, car les agents ont besoin de contexte pour devenir utiles. La prédiction demeure incertaine, car les contrats, contrôles techniques et modèles de déploiement diffèrent considérablement. Cet écart définit le débat autour de l’IA d’entreprise.

L’adoption ascendante de l’IA crée un type d’exposition différent

Les agents IA accroissent la valeur de l’expérimentation ascendante tout en rendant leurs flux d’information plus difficiles à inventorier et à gouverner.

La croissance tirée par le produit a offert aux éditeurs de logiciels une voie pour contourner les longs cycles d’approvisionnement. Un employé pouvait essayer un outil, inviter des collègues et démontrer son utilité avant d’impliquer la direction. L’acheteur obtenait des preuves, tandis que le fournisseur gagnait des relais internes.

Cette voie fonctionnait parce que de nombreux outils opéraient dans des limites étroites. Une application de conception traitait des fichiers de conception. Un service de messagerie transportait des conversations. Un outil de suivi de projet stockait des tâches et des commentaires.

Les agents franchissent ces frontières. Un agent commercial utile peut lire les e-mails, rechercher des dossiers clients, préparer une proposition, mettre à jour un pipeline et planifier des relances. Un agent de programmation peut examiner des dépôts, tickets, notes d’architecture et journaux de déploiement.

Chaque connexion élargit l’autorité et le contexte de l’agent. Elle accroît également les conséquences d’une action erronée, d’un compte compromis ou d’une instruction malveillante. L’adoption ne peut plus être mesurée uniquement par le nombre de licences ou d’utilisateurs actifs.

Le National Institute of Standards and Technology définit les agents comme des systèmes capables de planifier et d’entreprendre des actions autonomes dans des environnements réels. Son analyse de sécurité de 2026 a relevé un large consensus selon lequel les agents introduisent des menaces distinctes et créent des obstacles à l’adoption.

L’une des menaces importantes est l’injection indirecte de prompts. Un attaquant dissimule des instructions dans un e-mail, un site web, un document ou un dépôt de code qu’un agent lira ultérieurement. L’agent peut interpréter ces instructions comme des commandes et divulguer des données ou effectuer une action indésirable.

Les travaux de red teaming du NIST ont montré que les principaux modèles différaient sensiblement dans leur résistance à ce type d’attaques. La capacité d’un modèle ne prédisait pas systématiquement sa sécurité. Un modèle général plus puissant n’était pas automatiquement l’agent d’entreprise le plus sûr.

Cela compte pour le déploiement ascendant, car les employés optimisent l’utilité immédiate. Ils peuvent accorder à un agent l’accès à plusieurs systèmes sans cartographier la manière dont les données circulent entre eux. Les équipes de sécurité peuvent ne découvrir le flux de travail qu’après qu’il est devenu opérationnellement important.

Le risque ne se limite pas aux attaques délibérées. Un agent peut placer des informations sensibles dans un e-mail généré, copier le mauvais document dans un espace de travail ou conserver un contexte confidentiel dans un journal inattendu. Les erreurs de configuration ordinaires deviennent plus lourdes de conséquences lorsqu’un logiciel peut agir.

Les contrôles traditionnels de prévention des fuites de données examinent les fichiers, messages et flux réseau. Les flux de travail agentiques ajoutent les prompts, le contexte récupéré, les appels d’outils, le raisonnement intermédiaire, la mémoire et les actions générées. Une entreprise a besoin de visibilité sur l’ensemble de cette chaîne.

Les défenseurs de l’adoption ascendante peuvent raisonnablement soutenir que l’approbation centralisée avance souvent trop lentement. Les employés comprennent leur propre travail et peuvent identifier des usages précieux avant les dirigeants. Réprimer l’expérimentation peut pousser l’adoption vers des comptes personnels et des services non approuvés.

Cela crée le premier renversement dans la thèse de Palihapitiya. Une interdiction stricte peut accroître l’exposition en poussant l’activité hors des systèmes gérés. La voie la plus sûre n’est pas nécessairement moins d’expérimentation, mais une expérimentation à l’intérieur de limites techniques claires.

Un environnement isolé gouverné peut restreindre les données accessibles, les outils autorisés et les actions externes. Il peut exiger une approbation humaine avant l’envoi de messages, la modification de dossiers ou l’exécution de code. Il peut également conserver des journaux à des fins d’enquête et d’évaluation.

Les entreprises doivent distinguer trois questions fréquemment confondues. Le fournisseur peut-il entraîner ses modèles sur le contenu client ? Combien de temps peut-il conserver ce contenu ? À quoi l’agent peut-il accéder et que peut-il faire au cours de chaque session ?

La première concerne le développement des modèles. La deuxième concerne le traitement des données. La troisième concerne l’autorité opérationnelle, qui devient l’enjeu de sécurité déterminant pour les agents.

Un fournisseur peut promettre de ne pas entraîner ses modèles sur les données de l’entreprise alors qu’un employé accorde encore des autorisations excessives à son agent. À l’inverse, un agent bien restreint peut fonctionner en toute sécurité malgré l’utilisation d’un modèle externe. L’architecture et la gouvernance déterminent l’exposition réelle.

L’adoption ascendante ne survit donc que si sa liberté devient encadrée. Les employés peuvent toujours découvrir des cas d’usage, mais les règles d’identité, d’autorisations, de conservation et d’audit doivent précéder un déploiement généralisé. L’essai logiciel spontané devient une expérimentation gérée.

Le véritable conflit oppose l’apprentissage du client à la dépendance envers le fournisseur

La version la plus solide de l’argument de Palihapitiya concerne la dépendance à une boucle d’apprentissage externe, et non le vol littéral de chaque prompt client.

Un agent devient précieux grâce à une exposition répétée au travail d’une entreprise. Il apprend quelles sources les employés jugent fiables, quelles exceptions exigent une escalade et quels résultats passent l’examen interne. Cette amélioration provient souvent du système environnant plutôt que de modifications permanentes des poids du modèle.

Le système environnant comprend les prompts, les index de récupération, les intégrations, les jeux d’évaluation, les politiques et les corrections des utilisateurs. Ensemble, ils forment une boucle d’apprentissage. Celui qui contrôle cette boucle contrôle un actif opérationnel de plus en plus important.

Un système exploité par un fournisseur offre des avantages évidents. Le fournisseur assure la maintenance des modèles, de l’infrastructure de sécurité et des intégrations produit. Les clients évitent de devoir construire eux-mêmes chaque composant.

Le compromis apparaît lorsque le changement de fournisseur devient difficile. Une entreprise peut posséder ses documents originaux tout en ne disposant pas d’un historique portable du comportement des agents, des évaluations, des corrections et des flux de travail. Passer à un autre fournisseur implique alors de reconstruire le contexte institutionnel.

Il s’agit d’une forme plus subtile de verrouillage que celle d’un format de fichier propriétaire. Les données sous-jacentes peuvent rester exportables, mais le comportement créé autour d’elles ne se transfère pas proprement. Les employés doivent enseigner au nouveau système les mêmes règles implicites.

Cette préoccupation rappelle le « paradoxe informationnel inversé » du PDG de Microsoft, Satya Nadella. La page des dirigeants de Microsoft mentionne sa discussion du 12 juillet sur ce concept parmi ses publications publiques. Nadella soutient que les acheteurs d’IA révèlent des connaissances précieuses pour rendre utile l’intelligence qu’ils achètent.

Le paradoxe informationnel historique concernait les vendeurs qui révélaient des informations avant que les acheteurs puissent les évaluer. L’IA inverse cette direction. Les acheteurs exposent des connaissances tout en évaluant et en améliorant le service qu’ils achètent.

La position rapportée de Palihapitiya étend ce raisonnement à la distribution de logiciels. La croissance ascendante incite les employés à commencer cet échange avant que la direction décide où les connaissances qui en résultent doivent résider. Au moment où les achats interviennent, le flux de travail dépend peut-être déjà d’un fournisseur.

Les fournisseurs d’IA contestent l’idée selon laquelle l’usage ordinaire en entreprise alimente automatiquement des modèles partagés avec les connaissances des clients. OpenAI indique dans ses engagements relatifs à la confidentialité des données d’entreprise que les entrées et sorties professionnelles ne sont pas utilisées pour l’entraînement par défaut.

Anthropic affirme de même qu’elle n’entraîne pas ses modèles génératifs sur les données de ses clients commerciaux. Son explication du traitement commercial précise que le client reste le responsable du traitement, tandis qu’Anthropic agit comme sous-traitant.

Ces engagements affaiblissent sensiblement les affirmations de fuite automatique vers l’entraînement des modèles. Une analyse rigoureuse ne peut pas considérer chaque prompt d’entreprise comme un futur matériau d’entraînement. Le type de contrat, la configuration du compte, les programmes facultatifs de partage de données et la surface produit comptent tous.

Cependant, les promesses de non-entraînement ne règlent pas toutes les questions de propriété. Elles ne garantissent pas automatiquement la portabilité des évaluations, des mémoires d’agents, des définitions de flux de travail ou des retours utilisateurs accumulés. Elles n’empêchent pas non plus les employés internes de saisir des informations dans le mauvais compte.

La distinction entre services grand public et services professionnels est particulièrement importante. Une organisation peut négocier de solides protections pour des comptes d’entreprise approuvés, tandis que des employés utilisent des comptes personnels hors de ces accords. La gouvernance échoue lorsque les contrôles d’identité et d’achats ne correspondent pas aux comportements réels.

La rétention diffère également de l’entraînement. Un fournisseur peut conserver temporairement des données pour la surveillance des abus, la fourniture du service ou l’état du produit, sans les utiliser pour améliorer un modèle partagé. Les équipes de sécurité ont besoin de réponses précises pour chaque point d’accès et chaque fonctionnalité.

Le même examen s’applique aux connecteurs. Un modèle peut ne pas s’entraîner sur les documents récupérés, tout en recevant du contenu sensible lors de l’exécution de son agent. Ce contenu peut apparaître dans les journaux, les sorties générées ou les outils en aval, à moins que les contrôles ne restent cohérents.

C’est pourquoi le déploiement privé n’est pas une réponse complète. Exécuter un modèle ouvert dans l’infrastructure de l’entreprise peut réduire l’exposition à des tiers. Cela transfère aussi au client la responsabilité de la sécurité, de l’évaluation, des correctifs, de l’identité et de la supervision.

Un modèle interne doté d’autorisations étendues peut toujours divulguer des données entre départements. Un système de récupération mal configuré peut renvoyer les dossiers d’un client à une autre équipe. Un composant ouvert non corrigé peut introduire un risque lié à la chaîne d’approvisionnement.

Le véritable choix n’est donc pas entre une IA externe et une IA interne parfaitement sûre. Il s’agit d’un contrôle externalisé ou d’un contrôle gouverné en interne, avec des coûts et des modes de défaillance différents. La plupart des grandes organisations combineront probablement les deux.

Elles peuvent orienter les tâches ordinaires vers des services externes gérés tout en réservant les flux de travail sensibles à des systèmes isolés. Elles peuvent également conserver les prompts, les évaluations et les définitions de flux de travail dans une couche de contrôle indépendante des modèles. Cela réduit la dépendance sans exiger que chaque modèle soit exécuté localement.

Les travailleurs du savoir utilisent déjà des systèmes personnels de connaissances pour préserver le contexte entre les outils. Une base de connaissances IA structurée applique le même principe à plus petite échelle. L’utilisateur conserve ses sources organisées au lieu de dépendre entièrement d’un seul historique de discussion.

À l’échelle de l’entreprise, l’équivalent exige des contrôles d’accès, une provenance et une récupération auditable. Il nécessite également une politique définissant quelles connaissances peuvent quitter l’organisation. Sans cette classification, « protéger l’alpha » reste seulement un slogan.

La thèse de Palihapitiya met sous pression les fournisseurs SaaS comme les laboratoires d’IA

Les agents menacent le moteur ascendant de l’industrie logicielle, mais les exigences de gouvernance peuvent renforcer les plateformes établies disposant d’une distribution de confiance.

Les fournisseurs SaaS traditionnels subissent la pression la plus nette. Leurs produits regroupent des flux de travail au sein d’interfaces, d’autorisations et de bases de données. Les agents peuvent potentiellement exécuter ces flux de travail à travers plusieurs systèmes sans obliger les utilisateurs à passer beaucoup de temps dans chaque application.

Un commercial peut demander à un agent de préparer un renouvellement plutôt que d’ouvrir séparément des outils de CRM, de messagerie, de documents et de planification. L’agent devient l’interface. Les applications existantes deviennent les systèmes d’enregistrement qui se trouvent derrière lui.

Ce changement affaiblit les indicateurs d’engagement habituels. Moins de visites de l’interface ne signifient pas nécessairement moins de valeur produit, mais elles rendent la différenciation plus difficile à démontrer. Les fournisseurs doivent prouver que leurs données, leur logique de flux de travail ou leurs autorisations restent essentielles.

L’acquisition ascendante devient également plus difficile lorsque les équipes de sécurité contrôlent centralement l’accès des agents. Un employé peut essayer une application autonome avec des données limitées. Un agent qui demande l’accès aux e-mails, au code source ou aux systèmes financiers fait l’objet d’un examen plus approfondi.

Cela favorise les fournisseurs déjà intégrés aux systèmes d’identité et de conformité des entreprises. Microsoft, Google, Salesforce, ServiceNow et d’autres fournisseurs de plateformes peuvent placer des agents à côté des autorisations et enregistrements existants. Leurs bases installées créent des avantages de distribution.

Les entreprises de modèles de pointe subissent une pression différente. Leurs meilleurs modèles attirent les employés et les développeurs, mais les acheteurs d’entreprise exigent de plus en plus des contrôles contractuels, de l’auditabilité, un traitement régional et une rétention prévisible. La seule qualité des modèles ne peut répondre à ces exigences.

L’expansion d’Anthropic via des partenaires de conseil illustre cette réponse. En juin, l’entreprise a déclaré que plus de 40 000 sociétés avaient candidaté à son programme de partenaires. Elle a également indiqué que plus de 10 000 consultants avaient obtenu une certification Claude.

L’entreprise a cité de grands déploiements ou engagements de formation chez Accenture, Cognizant, Deloitte, KPMG, Infosys et PwC. Ces chiffres proviennent d’Anthropic et décrivent son réseau de partenaires, non des résultats d’adoption audités de manière indépendante. Ils montrent néanmoins à quelle vitesse le déploiement d’agents devient une activité de services.

Cela crée une tension avec l’avertissement de Palihapitiya. Les cabinets de conseil peuvent aider les clients à mettre en œuvre une gouvernance, mais ils approfondissent aussi l’accès du fournisseur de modèles aux flux de travail d’entreprise. Le même partenaire peut réduire le risque technique tout en augmentant la dépendance stratégique.

La propre entreprise de Palihapitiya occupe une autre position sur ce marché. Software Factory se présente comme une couche de contrôle couvrant les modèles et le travail de développement logiciel. Cette architecture promet davantage de contrôle au client, mais ses avantages nécessitent des preuves indépendantes sur des déploiements en production.

Un plan de contrôle est un logiciel qui gère la manière dont d’autres systèmes sont sélectionnés, autorisés, observés et modifiés. Dans un environnement d’agents, il peut orienter les tâches entre les modèles tout en préservant les politiques et les journaux. Il n’élimine pas la dépendance envers les fournisseurs situés en dessous.

Le plan de contrôle peut lui-même devenir la nouvelle source de verrouillage. Il peut détenir les définitions de flux de travail, les données d’évaluation et l’historique opérationnel. Les clients devraient poser les mêmes questions de portabilité, que le fournisseur vende des modèles, des applications ou de l’orchestration.

Les modèles open source et à poids ouverts offrent une autre voie. Les entreprises peuvent les déployer dans une infrastructure contrôlée et personnaliser le système environnant. Cela peut limiter le traitement externe et créer un levier de négociation avec les fournisseurs commerciaux.

Pourtant, un déploiement ouvert exige des spécialistes et un travail opérationnel continu. Les équipes doivent évaluer les mises à jour de modèles, sécuriser les systèmes d’inférence, surveiller les sorties et gérer la capacité matérielle ou cloud. Les petites organisations peuvent gagner davantage en sécurité avec un service d’entreprise bien géré.

Les fournisseurs SaaS ne sont pas non plus des cibles passives. Ils peuvent exposer des actions contrôlées via des interfaces de programmation d’applications tout en conservant les autorisations et les pistes d’audit dans leurs produits. Un agent peut alors utiliser le logiciel sans contourner sa gouvernance.

Les fournisseurs peuvent également rendre les flux de travail portables et neutres vis-à-vis des modèles. Les clients peuvent préférer un fournisseur qui leur permet de changer de modèle tout en conservant les politiques, les évaluations et la logique métier. La portabilité devient une caractéristique de vente plutôt qu’une note de bas de page sur la conformité.

Le résultat probable n’est ni la disparition du SaaS ni des agents ascendants sans restriction. C’est un marché en couches où les employés choisissent les expériences, les entreprises contrôlent l’accès et les plateformes rivalisent pour posséder l’orchestration. La valeur se déplace vers celui qui préserve le contexte sans l’enfermer.

Ce résultat validerait partiellement Palihapitiya. La distribution ascendante perdrait de son autonomie, tandis que les plateformes d’agents gouvernées gagneraient en importance. Il ne prouverait pas que les fournisseurs externes s’approprient régulièrement la propriété intellectuelle des clients.

La pression pèse le plus lourdement sur les produits dont le seul avantage est une interface pratique au-dessus d’un modèle généraliste. Leurs fonctionnalités peuvent être copiées, regroupées ou appelées par un autre agent. Les produits disposant de données propriétaires, de flux de travail de confiance ou de contrôles réglementés conservent des défenses plus solides.

L’affirmation de fuite exige encore un test de preuve plus rigoureux

Palihapitiya identifie un véritable problème de gouvernance, mais les preuves publiques n’établissent pas une appropriation généralisée des connaissances d’entreprise par les fournisseurs de modèles.

L’expression « fuite de PI/alpha » combine plusieurs risques distincts. L’un est la divulgation accidentelle par les employés. Un autre est la rétention par le fournisseur. Un troisième concerne l’entraînement des modèles, tandis qu’un quatrième est la dépendance stratégique envers l’infrastructure du fournisseur.

Ces risques exigent des preuves différentes. Un document exposé peut faire l’objet d’une enquête au moyen de journaux et de registres d’accès. L’utilisation de données d’entraînement exige une analyse contractuelle et technique. La dépendance stratégique se manifeste par les coûts de changement, la concentration et les échecs de portabilité.

Traiter les quatre comme une seule forme de fuite produit un titre spectaculaire mais un plan de contrôle faible. Un responsable de la sécurité des systèmes d’information ne peut pas atténuer une métaphore. Les équipes doivent identifier les données, le point d’accès, l’utilisateur, l’autorisation et l’action en aval concernés.

Le contre-argument le plus solide provient des politiques des fournisseurs. OpenAI et Anthropic déclarent explicitement que le contenu des clients commerciaux n’est pas utilisé pour l’entraînement des modèles par défaut. Ces déclarations constituent des engagements contractuels que les clients peuvent examiner lors des achats.

Les politiques n’éliminent pas le risque de mise en œuvre. Les employés peuvent utiliser des produits grand public, activer un partage facultatif, soumettre des retours ou connecter des applications non approuvées. Les créateurs d’agents tiers peuvent également opérer selon des conditions différentes de celles du fournisseur de modèles sous-jacent.

Une autre incertitude concerne ce que les agents apprennent réellement. La plupart des systèmes de production ne mettent pas à jour de façon permanente les poids des modèles après chaque correction d’un employé. Ils peuvent plutôt stocker l’historique des conversations, les mémoires, le contenu récupéré ou les résultats d’évaluation.

Cette distinction modifie le modèle de menace. Un flux de travail conservé peut rester sensible, mais il n’équivaut pas à l’apprentissage d’un modèle de fondation partagé. Les reportages devraient éviter de suggérer un processus technique sans preuve.

Les intérêts commerciaux de Palihapitiya méritent également attention. Son entreprise bénéficie si les entreprises concluent que l’orchestration neutre vis-à-vis des modèles et le confinement des connaissances sont des priorités stratégiques. Les lecteurs devraient considérer son avertissement comme une thèse éclairée assortie d’un intérêt commercial.

Le secteur manque encore de mesures standard pour la portabilité des connaissances. Les acheteurs peuvent comparer la précision ou la latence des modèles, mais ils peinent à quantifier la part de l’apprentissage institutionnel qui reste transférable. Cette lacune rend les affirmations générales difficiles à confirmer ou à réfuter.

Une évaluation utile testerait si une entreprise peut remplacer son fournisseur de modèles sans reconstruire l’ensemble du flux de travail. Elle mesurerait les prompts, politiques, mémoires, évaluations, connecteurs et règles d’approbation transférés. Elle comparerait également la qualité des sorties après la migration.

Un autre test consisterait à vérifier si des contenus sensibles atteignent des systèmes non autorisés pendant l’exécution d’un agent. Les équipes de sécurité pourraient insérer des marqueurs synthétiques dans des documents contrôlés et suivre leur apparition. Cela révélerait des fuites opérationnelles sans exposer de véritables secrets.

Des audits indépendants devraient également examiner les engagements des fournisseurs. Les acheteurs ont besoin de preuves que les paramètres de compte, les règles de conservation et les exclusions d’entraînement fonctionnent dans chaque produit connecté. Une politique couvrant une API peut ne pas couvrir un espace de travail grand public ou un plugin tiers.

La conclusion sceptique est simple. Les agents d’IA élargissent la surface sur laquelle les connaissances d’entreprise peuvent être exposées, mais cette exposition n’est pas inévitable. L’architecture, les conditions contractuelles, le comportement des employés et les contrôles d’identité déterminent le résultat.

L’avertissement de Palihapitiya est surtout utile comme question à poser lors des achats. Il est moins convaincant comme prédiction établie selon laquelle les logiciels adoptés de manière ascendante ont déjà échoué. Les entreprises expérimentent encore des modèles de libre-service gouverné.

Cette distinction compte pour les employés. Des restrictions trop larges peuvent réduire la productivité et encourager des usages non encadrés. Une politique efficace fournit aux travailleurs des outils approuvés offrant suffisamment de capacités pour rivaliser avec les alternatives personnelles.

Elle compte aussi pour les fournisseurs. Le marketing fondé sur la peur peut attirer l’attention, mais il risque de masquer des contrôles concrets. Les acheteurs devraient exiger l’exportabilité, des autorisations restreintes, le choix du modèle, des journaux d’audit et des procédures d’incident claires.

La charge de la preuve incombe aux deux parties. Les fournisseurs de modèles devraient démontrer que les contrôles sur les données d’entreprise fonctionnent comme promis. Les fournisseurs de couches de contrôle devraient démontrer que leurs systèmes réduisent les risques sans créer une nouvelle dépendance propriétaire.

Ce que les acheteurs d’entreprise devraient surveiller ensuite

La prochaine étape de ce débat sera tranchée par des tests de portabilité, des preuves de sécurité et l’évolution des achats d’entreprise.

Le premier signal sera de savoir si les grands fournisseurs rendent l’apprentissage des agents portable. Les clients ont besoin de plus qu’une exportation de documents. Ils ont besoin de définitions de flux de travail transférables, de jeux d’évaluation, de corrections, d’autorisations et de structures de mémoire.

Si les fournisseurs adoptent des formats communs, la préoccupation de Palihapitiya concernant l’enfermement propriétaire s’affaiblit. Les entreprises pourraient conserver leur apprentissage institutionnel tout en changeant de modèles ou de plateformes d’exécution. Si la portabilité reste limitée, l’argument en faveur du contrôle gagne en force.

Le deuxième signal sera constitué de preuves indépendantes sur la sécurité des agents. Le NIST a déjà identifié l’injection indirecte de prompts, l’exfiltration de données, l’autorité excessive et la faiblesse de l’autorisation comme des préoccupations importantes. Les futurs benchmarks devraient tester des systèmes complets, et non des modèles isolés.

Une entreprise ne déploie pas un modèle seul. Elle déploie un modèle connecté à des systèmes d’identité, des bases de données, des fichiers et des outils externes. Les résultats de sécurité doivent refléter cet environnement opérationnel.

Si des tests indépendants montrent que des agents contraints résistent aux attaques et empêchent les mouvements de données non autorisés, l’expérimentation ascendante peut se poursuivre dans des limites gérées. Des échecs persistants feraient basculer l’autorité vers les équipes centralisées de sécurité et d’approvisionnement.

Le troisième signal sera le comportement d’achat des entreprises. Il faudra observer si les entreprises se standardisent sur une plateforme d’agents, adoptent des couches de contrôle indépendantes des modèles ou maintiennent plusieurs fournisseurs selon les niveaux de sensibilité. Les structures contractuelles révéleront la valeur que les acheteurs accordent au contrôle.

Les demandes d’approvisionnement deviendront également plus précises. Les acheteurs demanderont si les données entraînent les modèles, combien de temps chaque endpoint conserve le contenu et si les administrateurs peuvent désactiver les connecteurs risqués. Ils exigeront des journaux d’audit au niveau des actions et des points de contrôle d’approbation.

La distinction entre comptes personnels et comptes d’entreprise recevra davantage d’attention. Les organisations qui proposent des outils gérés et performants peuvent réduire le shadow AI. Celles qui s’appuient uniquement sur des documents de politique auront du mal à contrôler le comportement des employés.

Les résultats financiers des éditeurs SaaS fourniront un autre indice. Les fournisseurs devraient indiquer si les agents augmentent le volume des flux de travail tout en réduisant l’engagement avec l’interface. Ils devraient également expliquer si les clients paient pour les résultats, les actions, la consommation ou les abonnements traditionnels par poste.

Une baisse de la croissance du nombre de postes ne confirmerait pas automatiquement l’effondrement du logiciel. Les agents peuvent accroître la valeur des enregistrements et des autorisations sous-jacents. Le modèle économique peut évoluer avant que la catégorie de produits ne disparaisse.

Les fournisseurs de modèles subiront une pression accrue pour préciser le fonctionnement des programmes d’entraînement facultatifs. Ils devront fournir des explications cohérentes pour les API, les espaces de travail d’entreprise, les produits de programmation et les services créés par des partenaires. Des limites ambiguës renforceront les préoccupations liées aux fuites.

Les entreprises devraient dès maintenant établir un inventaire interne. Chaque agent déployé devrait avoir un responsable, des sources de données approuvées, des actions autorisées, une politique de conservation et un processus de retour arrière. Les équipes devraient consigner quel fournisseur traite chaque étape.

Elles devraient également préserver la couche d’apprentissage séparément du modèle lorsque cela est possible. Les prompts, évaluations, politiques et corrections vérifiées peuvent rester dans des référentiels contrôlés par le client. Les modèles deviennent alors des composants remplaçables plutôt que l’unique foyer de l’intelligence opérationnelle.

L’approbation humaine reste importante pour les actions aux conséquences significatives. L’envoi de paiements, la modification de systèmes de production, la divulgation d’informations client ou la prise de décisions en matière d’emploi devraient exiger une autorisation explicite. L’autonomie ne devrait s’étendre qu’après que des performances mesurées le justifient.

L’article de Google News du 6 août illustre un débat qui survivra à son titre. Palihapitiya remet en question l’hypothèse selon laquelle une adoption menée par les employés bénéficie naturellement au client. Avec les agents, chaque expérimentation réussie apprend aussi à un système comment l’entreprise fonctionne.

La question décisive n’est pas de savoir si les entreprises utiliseront des agents d’IA. Elles ont déjà de fortes incitations à automatiser la recherche, la programmation, les ventes et le travail administratif. La question est de savoir si elles peuvent conserver le contrôle des connaissances qui rendent ces agents efficaces.

Les acheteurs d’entreprise devraient poser une question pratique avant d’approuver le prochain déploiement : si le fournisseur disparaissait demain, l’organisation pourrait-elle préserver ce que ses collaborateurs ont appris au système ?

Si la réponse est non, l’entreprise a créé plus qu’un outil utile. Elle a transféré une partie de sa mémoire opérationnelle vers une dépendance. C’est l’avertissement derrière le titre, et il mérite d’être testé avant une adoption plus large.