Pour mettre fin au gaspillage de l’automatisation, les entreprises doivent déployer une infrastructure d’interaction qui régit physiquement le fonctionnement des agents d’IA indépendants.
Les agents d’IA peuplent désormais les réseaux d’entreprise, raisonnant à travers des tâches et exécutant des décisions avec une autonomie croissante. Pourtant, lorsque ces acteurs indépendants tentent de coordonner leur travail, d’échanger des contextes ou d’opérer dans des environnements cloud variés, le cadre d’interaction se dégrade rapidement. Les opérateurs humains se retrouvent à jouer le rôle de ciment manuel entre des systèmes déconnectés, gérant des intégrations fragiles tandis que les règles dictant les autorisations et le partage de données restent implicites.
Band, une startup basée à Tel Aviv et à San Francisco, est sortie du mode furtif avec un tour de table de 17 millions de dollars pour résoudre ce problème d’infrastructure. Le financement soutient le PDG Arick Goomanovsky et le CTO Vlad Luzin dans leurs efforts visant à créer une couche d’interaction dédiée aux systèmes d’entreprise autonomes. Le concept reflète les évolutions informatiques antérieures, dans lesquelles les interfaces de programmation d’applications nécessitaient des passerelles dédiées et les microservices nécessitaient un maillage de services pour fonctionner à grande échelle.
Alors que les systèmes distribués se multiplient sous la propriété de différentes équipes internes, l’ajout de logique métier ne parvient pas à résoudre l’instabilité sous-jacente. La fiabilité des interactions nécessite plutôt une couche d’infrastructure distincte.
La dynamique du marché a changé de trois manières principales. Premièrement, les acteurs autonomes sont passés de déploiements expérimentaux à des participants actifs à l’exécution gérant les pipelines d’ingénierie, les requêtes d’assistance client et les opérations de sécurité. L’utilisation en entreprise n’est plus une considération future ; c’est un état opérationnel actif. La question urgente consiste à gérer ce qui se passe lorsque ces acteurs distincts doivent collaborer.
Deuxièmement, l’environnement opérationnel est totalement hétérogène. Les équipes d’ingénierie créent des outils distincts dans des cadres variés. Ces modèles s’exécutent sur des plates-formes cloud concurrentes, utilisent différents protocoles de communication et relèvent de propriétaires d’entreprise distincts. Aucun fournisseur n’assure le contrôle à lui seul et aucun cadre uniforme n’encapsule l’ensemble de l’écosystème. Cette fragmentation représente la forme permanente du marché des entreprises.
Troisièmement, une couche de normes fondamentales est en train de prendre forme. Des initiatives telles que le Model Context Protocol (MCP) offrent aux modèles une méthode uniforme pour accéder aux outils externes. De même, les efforts de communication A2A établissent des paramètres conversationnels de base.
Pourtant, même si les protocoles définissent la prise de contact, ils ne parviennent pas à gérer l’environnement de production. Les protocoles standardisés n’administrent pas le routage, la récupération d’erreurs, les limites d’autorité, la surveillance humaine ou la gouvernance d’exécution. Ils ne peuvent pas manifester l’espace opérationnel partagé nécessaire à une interaction fiable. Band a l’intention de combler ce vide en matière d’infrastructure.
La responsabilité financière d’une automatisation non gérée
Le déploiement de modèles indépendants dans les unités commerciales crée des défis d’intégration toujours plus nombreux. Si les intégrations point à point doivent être réalisées manuellement par les équipes de développement internes, la charge de maintenance réduira les marges bénéficiaires et retardera les sorties de produits. Le risque financier s’étend au-delà des simples coûts d’intégration.
Lorsque des acteurs autonomes s’échangent des instructions sans gouverneur central, les organisations sont confrontées à des dépenses de calcul croissantes. L’inférence multi-agent nécessite des appels d’API continus vers de grands modèles de langage coûteux. Un échec de routage ou une erreur de boucle entre deux entités confuses peut consommer des budgets cloud substantiels en quelques heures.
Les flux de travail multi-agents autonomes menacent cette prévisibilité s’ils ne sont pas gérés. Une négociation non surveillée entre un modèle d’approvisionnement interne et un modèle de fournisseur externe pourrait déclencher des centaines de cycles d’inférence, gonflant les coûts d’utilisation des jetons au-delà de la valeur de la transaction sous-jacente. Les couches d’infrastructure doivent donc mettre en œuvre des disjoncteurs financiers stricts, mettant fin aux interactions qui dépassent les budgets de jetons ou les seuils de calcul prédéfinis.
Renforcement de la couche d’exécution multi-agents
L’intégration de ces nœuds intelligents à l’architecture d’entreprise existante nécessite des ressources d’ingénierie intenses. Les institutions financières et les prestataires de soins de santé opèrent sur des entrepôts de données sur site fortement renforcés, des clusters de calcul mainframe et des applications de planification des ressources d’entreprise personnalisées.
Sans une infrastructure d’interaction renforcée, le risque de corruption des données se multiplie à chaque étape automatisée. Un modèle de facturation peut lancer une transaction tandis qu’un modèle de conformité signale simultanément le même compte, créant ainsi un verrouillage de base de données ou des entrées conflictuelles. La couche d’interaction empêche ces collisions. En imposant des limites de capacité, l’infrastructure garantit qu’une entité autonome ne peut pas forcer des modifications non approuvées aux systèmes sources primaires.
Les bases de données vectorielles, qui hébergent les mémoires contextuelles nécessaires à la génération augmentée par récupération, présentent un défi similaire. Ces systèmes de stockage sont fréquemment configurés dans des environnements isolés adaptés à des cas d’utilisation individuels. Si un robot de support technique doit transférer une interaction client en cours vers un robot de diagnostic matériel spécialisé, les données contextuelles doivent transiter avec précision entre des environnements vectoriels isolés.
La dégradation des données se produit lorsque les modèles sont obligés d’interpréter les résultats résumés d’autres modèles plutôt que d’accéder aux journaux de données originaux vérifiés cryptographiquement. Mettre fin à cette dégradation nécessite des frontières contextuelles rigides et un maillage d’interaction central capable de retracer la lignée complète de toutes les informations partagées.
Le risque de contamination des données crée des problèmes de responsabilité. Si un modèle de service client ingère accidentellement des données financières hautement classifiées provenant d’un modèle d’audit interne lors d’un échange contextuel, la violation de la conformité pourrait entraîner de sévères sanctions réglementaires.
L’établissement d’un maillage de communication sécurisé permet aux responsables des données d’appliquer des contrôles d’accès très spécifiques au niveau de la couche d’interaction plutôt que de tenter de reconstruire la logique des modèles individuels. Chaque interaction numérique nécessite une journalisation cryptographique pour garantir que les organismes de réglementation peuvent retracer les décisions automatisées jusqu’à leur point d’origine exact.
Traiter le maillage de communication comme un périmètre de sécurité
La conception de la plateforme rejette la notion d’un modèle monolithique gérant l’ensemble de l’entreprise. Au lieu de cela, il prévoit des équipes de participants spécialisés possédant des atouts différents et remplissant des rôles distincts, fonctionnant de manière synchrone sans nécessiter d’architectures identiques.
Fonctionnant comme une plate-forme indépendante du framework et du cloud, le système reconnaît la valeur des outils existants. Le marché dispose déjà de cadres de développement fonctionnels. Band se concentre sur la phase opérationnelle, en s’engageant lorsque les modèles quittent le laboratoire et entrent dans le réseau physique de l’entreprise en tant qu’entités distribuées.
La gouvernance constitue le cœur de cette stratégie. Une erreur fréquente dans les déploiements technologiques d’entreprise consiste à traiter la gouvernance comme une fonctionnalité secondaire, corrigée sur le système après le déploiement initial. Cette approche échoue lorsqu’elle est appliquée à des acteurs d’entreprise autonomes. Ces systèmes délèguent des tâches, transfèrent le contexte et exécutent des actions à travers les lignes organisationnelles. Si les règles d’autorité restent implicites et que le routage des données manque de transparence, l’opération manquera de la confiance nécessaire, même si elle fonctionne techniquement.
Pour atténuer ce risque, le maillage sous-jacent doit fonctionner comme une limite de sécurité. Les organisations ont besoin de mécanismes pour inspecter les chaînes de délégation, appliquer des limites d’autorité strictes et conserver des pistes d’audit complètes détaillant les actions d’exécution. La participation humaine doit être profondément intégrée au niveau de l’exécution.
Les mécanismes de collaboration et les contrôles de gouvernance doivent occuper le même niveau d’infrastructure. Sans cette base, la transition d’une utilisation d’un modèle unique vers une mise en œuvre d’entreprise en réseau s’arrêtera, entravée par une accumulation de défaillances du système et de violations de conformité. Les entreprises qui réussiront à déployer des opérations évolutives seront celles qui investiront massivement dans l’infrastructure d’interaction sous-jacente plutôt que de simplement accumuler des démonstrations logicielles impressionnantes.
