Val Bercovici, Chief AI Officer chez WEKA – Série d’interviews

Val Bercovici, Chief AI Officer chez WEKA, est un dirigeant spécialisé dans l’IA et l’infrastructure de données, axé sur l’avancement des technologies qui sous-tendent la prochaine génération d’intelligence artificielle. Depuis qu’il a rejoint WEKA en tant que Chief AI Officer en janvier 2025, il s’est concentré sur la construction d’infrastructures d’agents IA, l’accélération des charges de travail d’entraînement et d’inférence, et l’amélioration de l’économie du calcul IA. En parallèle de son rôle chez WEKA, Bercovici est conseiller IA pour Home Dock, conseiller stratégique pour FermiHDI et The Hive, et président de PencilDATA, où son travail couvre l’IA, la cybersécurité, la blockchain, le cloud computing et l’infrastructure de données. Sa carrière reflète un engagement de longue date à développer et conseiller les technologies émergentes conçues pour soutenir des systèmes d’IA de plus en plus gourmands en données.

WEKA est une société d’infrastructure de données native IA qui construit une plateforme définie par logiciel conçue pour les exigences de données exigeantes de l’intelligence artificielle, de l’apprentissage automatique, du calcul haute performance et d’autres charges de travail accélérées. La plateforme de données WEKA offre aux organisations une architecture unifiée pouvant fonctionner sur site, dans le cloud, en hybride et en périphérie, aidant à éliminer les goulets d’étranglement de stockage, à améliorer l’utilisation des GPU et à accélérer l’entraînement et l’inférence des modèles IA. L’entreprise positionne de plus en plus sa technologie autour de l’émergence de l’économie d’inférence et de l’IA agentique, son infrastructure étant conçue pour fournir un accès à haut débit et à faible latence aux données à très grande échelle tout en simplifiant les pipelines de données IA complexes. WEKA sert les entreprises, les fournisseurs de cloud, les organisations de recherche et les développeurs IA opérant dans certains des environnements informatiques les plus intensifs au monde.

Votre carrière vous a mené de la définition de la stratégie cloud précoce de NetApp et de votre participation au conseil fondateur de Kubernetes à la construction d’infrastructures IA chez WEKA. En quoi cette évolution a-t-elle influencé votre façon de penser la préparation de l’infrastructure pour la prochaine phase de l’IA ?

Chaque époque de ma carrière a été définie par le même schéma : le goulot d’étranglement se déplace, et l’industrie met des années à le remarquer. Au début du cloud et de Kubernetes, nous avons vu le calcul devenir élastique et l’orchestration devenir le nouveau point de friction. En sortant de NetApp, où j’étais CTO après l’acquisition de SolidFire, je pensais savoir à quoi ressemblait la rapidité : quelques millisecondes pour une lecture aléatoire du premier octet en production.

La raison pour laquelle j’ai rejoint WEKA est purement geek. Un seul indicateur : la première lecture aléatoire non mise en cache d’un octet est de 70 µs, ce qui n’est pas un chiffre de classe stockage. Je n’avais jamais envisagé une latence au niveau microseconde pour ce type de système. Cela a été l’illumination : cette technologie pouvait servir les applications mémoire, les applications de classe DRAM comme Redis et le cache KV, et pas seulement le stockage. Et, comme prévu, l’inférence a commencé à supplanter l’entraînement parce que l’industrie devait monétiser ces modèles, et les agents sont apparus pour faire de la mémoire le jeu complet.

C’est la perspective que j’apporte à l’infrastructure IA. Nous avons déjà vu ce scénario. Le FinOps du cloud est apparu parce que les entreprises déployaient de l’infrastructure sans rigueur économique unitaire, puis recevaient la facture. L’IA suit la même trajectoire, mais plus rapidement. À mesure que les entreprises repoussent inévitablement le « tokenmaxxing » avec l’arrivée de factures de consommation d’API bien supérieures aux budgets de tokens prévus, nous assistons à l’essor du FinOps IA. C’est le moment où les organisations cessent de considérer l’inférence comme une utilité bon marché et commencent à gérer l’efficacité des tokens comme une discipline financière. Le FinOps IA débute avec la tokenomie : optimiser chaque couche matérielle et logicielle de la pile d’inférence qui influe sur le coût unitaire par token. Aujourd’hui, le plus grand gaspillage de cette pile provient des GPU coûteux et des nouveaux ASICs qui restent inactifs, attendant la mémoire et les données (appelées « decode ») plutôt que les FLOPS (appelés « prefill »). Celui qui résoudra ce problème possédera la prochaine phase de l’IA.

La Maison-Blanche garde confidentiels les détails de son nouveau cadre de sécurité IA. Comment les entreprises peuvent‑elles se préparer aux exigences réglementaires alors qu’elles ne savent pas encore exactement ce qui sera testé ou requis ?

Les entreprises ne doivent pas attendre la liste de contrôle finale. Les tests spécifiques évolueront, mais l’obligation sous‑jacente restera la même : il faudra démontrer ce que votre modèle IA a fait, quelles données il a manipulées et comment il s’est comporté à un instant donné. Et l’attente n’est déjà plus une option à l’échelle mondiale. Le AI Act de l’UE est devenu applicable ce mois‑ci, et il classe la plupart des orchestrations d’agents comme à haut risque.

Cela signifie que le travail de préparation relève de l’infrastructure. La traçabilité des données, l’observabilité, la reproductibilité et la capacité de reconstruire l’état du modèle à la demande sont essentiels pour les entreprises. Enfin, les organisations doivent mettre en place des modèles de garde‑fou avant les sorties, avec des budgets de latence et de tokens associés aux couches de défense sémantique. Si vous construisez ces capacités dès maintenant, tout cadre devient un exercice de mise en forme. Attendre les règles définitives, c’est ajouter de la responsabilité à des systèmes qui n’ont jamais été conçus pour s’expliquer. Cette adaptation est toujours plus coûteuse que de l’intégrer dès le départ.

En fin de compte, la solution pour créer une IA sûre consiste en davantage d’IA, appliquée de manière optimale et très intentionnelle.

Quel type de nouvelles exigences d’infrastructure les tests de sécurité IA pourraient‑ils engendrer, et en quoi ces charges de travail diffèrent‑elles de l’entraînement ou de l’inférence de modèles conventionnels ?

L’entraînement ressemble à un tuyau d’incendie. Vous poussez d’énormes volumes de données à travers un modèle selon un schéma soutenu et prévisible. Les tests de sécurité sont l’inverse : des milliers de scénarios d’évaluation, des sondages répétés, des comparaisons comportementales version après version, et des équipes rouges adversariales qui ne cessent jamais.

Ce profil compte. La formation et les tests de sécurité sont ponctuels, très axés sur la lecture et comparatifs. Ils génèrent et consomment d’énormes quantités d’état intermédiaire. Les modèles de garde‑fou doivent être intrinsèquement hétérogènes et stratifiés, mis en œuvre dans des budgets de latence stricts, amplifiant les évaluations avec cette nouvelle dimension de critères de sécurité. Pour des modèles aussi avancés ou capables sur le plan cyber, le profil de charge de travail est persistant 24 h/24 et 7 j/7 plutôt qu’épisodique. Vous n’exécutez pas un test une fois puis n’archivez pas les résultats. Vous exécutez des charges de travail d’essaims d’agents continus qui rivalisent en production avec le calcul, la mémoire et la bande passante des données pour les applications critiques qu’ils protègent. Après la qualité et la vitesse, la plupart des infrastructures actuelles ne sont pas conçues pour ce troisième principe.

Il existe également un problème de mesure sous‑jacent. La plupart des benchmarks IA aujourd’hui fonctionnent avec 8 000 tokens ou moins, un prompt, une réponse. Je plaisante en disant qu’il s’agit de benchmarks artificiels d’intelligence artificielle. À la mi‑2026, les charges de travail réelles d’agents traitent de 100 000 à 400 000 tokens de contexte sur des milliers de tours. Si les évaluations de sécurité héritent de ces benchmarks ludiques, nous certifierons des systèmes pour un monde qui n’existe pas. Les régulateurs renforcent déjà leurs capacités : le NIST a publié en open‑source des outils d’évaluation de la sécurité des agents, et les premiers résultats montrent que des attaques de détournement d’agents novatrices réussissent à plusieurs fois le taux des références connues. C’est exactement le type de test continu, adversarial et coûteux sur lequel je m’attends à ce que les cadres de sécurité convergent.

Les organisations devraient‑elles construire un excédent de capacité de calcul et de données spécifiquement pour les futures charges de travail de conformité et de sécurité, ou existe‑t‑il une manière plus efficace de concevoir face à cette incertitude ?

Acheter des GPU en excédent et espérer que l’utilisation rattrape ne fait que laisser du capital bloqué dans du matériel qui se déprécie.

La réponse efficace consiste en une infrastructure qui bascule entre les charges de travail de production et d’évaluation sans pile distincte. C’est fondamentalement un problème de données. Si vous pouvez déplacer et réutiliser les données efficacement, préserver le contexte entre les charges de travail et garder vos accélérateurs occupés à faire du travail réel, la conformité devient un coût incrémental plutôt qu’une construction parallèle. L’économie de l’IA repose de plus en plus sur la valeur extraite de chaque token, octet et watt. Si vous y parvenez, vous pouvez générer 3 à 4 fois plus de valeur avec la même infrastructure, ou réduire l’encombrement de votre rack jusqu’à 75 %. La conformité doit être soumise au même niveau d’exigence.

Le cadre actuel se concentrerait sur les modèles fermés avancés tout en excluant les modèles à poids ouvert. Quels défis d’infrastructure ou de sécurité pourraient émerger du traitement différencié de ces deux catégories ?

Si vous traitez différemment les modèles fermés et les modèles à poids ouvert, vous vous retrouvez avec deux cadres de conformité pour des technologies qui font la même chose, et l’écart entre eux est l’endroit où le risque réside.

Un modèle à poids ouvert peut être affiné et déployé dans des environnements où le fournisseur d’origine n’a aucune visibilité. Réglementer le fournisseur ne sert à rien dans ce cas. Et la division est déjà visible : les contrôles à l’exportation ont touché les modèles de pointe fermés les plus récents cette année, tandis que les modèles à poids ouvert traversent les frontières librement et occupent désormais les premières places des classements de capacités publiques. Cependant, l’administration finit par définir les modèles de pointe, la gouvernance ne peut pas s’arrêter au modèle lui‑-même. Il faut une visibilité sur l’endroit où les modèles s’exécutent, quelles données ils accèdent, quels prompts, réponses et métadonnées sont conservés, comment ils ont été modifiés, et si l’infrastructure sous‑jacente peut réellement supporter une IA gouvernée à grande échelle. De nouvelles mises à jour d’ISO 27001 et de SOC 2 seront nécessaires.

Ma réponse est « faire confiance mais vérifier ». Si votre infrastructure vous offre la capacité de tokens, vous pouvez appliquer des garde‑fous hétérogènes à tout modèle avant que sa sortie ne soit diffusée : qu’il soit domestique ou étranger, ouvert ou fermé. La vérification objective l’emporte sur la confiance aveugle ou la méfiance généralisée basée sur l’origine du modèle. À mesure que les modèles ouverts prolifèrent, cette capacité de vérification réside dans la couche d’infrastructure, et c’est là que les entreprises se différencieront. La politique peut décider quels modèles sont autorisés. L’infrastructure décide si ces modèles peuvent être déployés de façon responsable et économique.

À mesure que les agents IA deviennent plus autonomes et opèrent sur des contextes plus longs, comment cela modifie‑t‑il la quantité de données, de mémoire et de calcul que les organisations doivent allouer à la surveillance et à la sécurité ?

Un chatbot se compose d’un prompt et d’une réponse. Un agent autonome est un processus en cours d’exécution. Il touche des dizaines de systèmes, récupère des informations, prend des décisions intermédiaires et accumule un état pendant des heures ou des jours avant d’achever une tâche.

Vous ne pouvez pas surveiller cela en échantillonnant des tokens ou des réponses individuels. Vous devez capturer la séquence complète : ce que l’agent savait, quand il le savait et ce qu’il a fait ensuite. Chaque heure d’exécution d’un agent fait croître son état, ainsi que la mémoire, les déplacements de données et l’infrastructure nécessaires pour le capturer et l’analyser. La surveillance cesse d’être une simple fonction de journalisation et devient une charge de travail à part entière avec son propre budget de ressources.

La défense est le domaine où cela devient urgent. Le problème de mémoire de l’IA se transforme en problème de sécurité. Un agent de codage peut se lancer, livrer et s’arrêter. Un agent de cybersécurité ne le peut pas. Il doit conserver le contexte à travers les changements de quart quotidiens dans un centre d’opérations de sécurité, les mises à jour fréquentes de modèles et les campagnes d’attaque multi‑étapes sophistiquées qui s’étendaient autrefois sur des semaines, mais fonctionnent aujourd’hui à des vitesses de machines coordonnées. Lorsque cette mémoire de travail IA est évincée et recomputée à chaque quelques minutes, un agent qui a détecté un comportement anormal durant la première heure d’un incident n’en a plus le souvenir à la deuxième heure. Les attaquants n’ont pas ce problème. Leurs agents identifient et poursuivent les faiblesses de façon persistante, et les chaînes de destruction s’achèvent désormais à des vitesses optimisées par la tokenomie, de sorte que la défense cybernétique alimentée par l’IA doit fonctionner de manière autonome 24 h/24. Et ce n’est pas théorique. Les fournisseurs de sécurité se préparent dès maintenant à des agents cybernétiques persistants 24 h/24, et la première chose qu’ils constatent est que l’économie ne ressemble en rien aux charges de travail de chat. Certaines organisations ont besoin de ces agents fonctionnant en périphérie, dans des installations où il est impossible d’expédier un rack GPU ou même un refroidisseur cette année. Le véritable test pour l’IA d’entreprise est la rétention continue du contexte, pas l’inférence ponctuelle. Cela devient une lutte d’attrition de tokens, et celui qui résoudra la mémoire de contexte persistante à grande échelle alimentera la première application transversale à succès de l’IA d’entreprise : des essaims d’agents bleus toujours actifs.

Vous avez évoqué l’importance croissante de la « mémoire de contexte » à mesure que les charges de travail IA passent du simple chat aux agents persistants. Cette mémoire de contexte pourrait‑elle également devenir importante pour l’audit, la reproduction ou l’investigation du comportement IA ?

Absolument, et c’est un cas d’usage important. Pendant des années, la mémoire était une question de performance : à quelle vitesse alimenter le GPU, combien de contexte vous pouviez conserver. Une fois que les agents agissent de façon autonome, cette même mémoire devient la preuve. Si un agent prend une décision basée sur un contexte accumulé sur plusieurs jours, le prompt final et la sortie vous disent presque rien sur les raisons de son action. L’explication réside dans l’état accumulé.

Techniquement, la majeure partie de cet état réside dans le cache KV, et l’industrie le considère encore comme un espace de travail jetable plutôt que comme des données durables. Si vous préservez cet état et pouvez le récupérer efficacement, vous pouvez reconstruire ce que le système savait au moment de l’action. Les équipes l’utiliseront d’abord pour le débogage, puis pour les évaluations de sécurité, et finalement, quelqu’un en aura besoin lors d’une enquête. Jeter la mémoire de contexte, c’est jeter le seul enregistrement qui explique pourquoi votre IA a agi ainsi.

La réglementation IA pourrait‑elle finalement contraindre les entreprises à conserver beaucoup plus d’informations sur les entrées et sorties des modèles, les points de contrôle, la traçabilité des données et l’activité des agents ? Qu’est‑ce que cela impliquerait pour l’architecture de l’infrastructure IA ?

En principe, oui. À mesure que les systèmes IA deviennent plus déterminants, les exigences de visibilité s’étendront pour couvrir chaque étape du pipeline. On voit déjà les premiers signaux : les équipes prévoient de conserver la mémoire de contexte obsolète dans des niveaux de stockage d’objets moins chers, uniquement à des fins d’audit, avant que toute réglementation ne l’exige.

L’authentification de la surveillance avec immutabilité est essentielle. La falsification des journaux et d’autres artefacts médico‑légaux par des agents malveillants est devenue courante, nécessitant des systèmes de vérification cryptographique élaborés qui ne sont pas vulnérables aux cibles d’intégrité centralisées et concentrées. Les simples journaux de transparence ou chaînes de hachage ne suffisent pas à se défendre contre les capacités de collusion d’essaims d’agents coordonnés. Les architectures de blockchain publiques hautement décentralisées sont parfaitement adaptées à cela, mettant en avant la valeur d’Intégrité souvent négligée, au cœur de la triade C‑I‑A de la cybersécurité.

La rétention n’est pas seulement un problème de stockage massif, immuable et intimidant. La difficulté réside à maintenir ces informations fiables, organisées, indexées et récupérables suffisamment rapidement pour être utiles dans un délai, qu’il provienne d’un régulateur, d’une réponse à incident ou d’un tribunal. Un pétaoctet d’activité d’agent que vous ne pouvez pas interroger constitue une responsabilité, pas un enregistrement. Le changement architectural passe de « plus de stockage » à une infrastructure conçue autour de données IA objectivement vérifiables, persistantes et interrogeables comme charge de travail principale.

De nombreuses organisations se concentrent sur l’achat de plus de GPU, mais où voyez‑vous les goulets d’étranglement d’infrastructure moins évidents apparaître à mesure que les charges de travail IA s’étendent et que les exigences de sécurité se renforcent ?

Le GPU fait la une parce que ce n’est pas un poste budgétaire négligeable. Mais les GPU et surtout les nouveaux accélérateurs optimisés pour le décodage (ASIC+SRAM) sont rarement la contrainte réelle. La bande passante mémoire, la gravité et le déplacement des données, les performances de stockage et le réseau déterminent si ces accélérateurs effectuent un travail productif ou restent sous‑utilisés.

À mesure que l’IA devient plus lourde en contexte, le mur de mémoire devient la contrainte déterminante. Vous pouvez continuer à ajouter des GPU, mais s’ils passent leurs cycles à recomputer des tokens ou à échanger le contexte entre systèmes, vous payez pour du travail gaspillé, de façon répétée. Faire évoluer le mur de mémoire signifie faire en sorte que la couche de données se comporte comme un stockage partagé, tout en fonctionnant à de véritables vitesses mémoire. Cette barre de vitesse adjacente à la HBM est importante pour la vague de solutions de déchargement du cache KV qui arrivent maintenant : chacune doit offrir une véritable performance de classe mémoire pour que la tokenomie soit viable. La valeur de rétention du cache KV est une discussion de centre de coût, secondaire au centre de profit. Et si la lecture du contexte mis en cache est plus lente que le simple recomptage, le cache devient inutile pour l’équation commerciale. Ce qui compte n’est pas le nombre de GPU que vous possédez, mais la productivité de chacun. L’économie de l’IA repose sur la valeur extraite de chaque token, octet et watt, et les exigences de sécurité ne feront qu’augmenter les enjeux de ce calcul.

En regardant vers l’avenir, pensez‑vous que la sécurité et la conformité IA deviendront une charge de travail d’infrastructure distincte, à l’instar de la façon dont la cybersécurité est devenue une couche dédiée de la technologie d’entreprise ?

Nous verrons la sécurité et la conformité IA devenir une charge de travail distincte, et le parallèle avec la cybersécurité fonctionne dans les deux sens. La sécurité est devenue une couche propre une fois que l’industrie a accepté qu’il ne pouvait s’agir d’une activité ponctuelle. L’industrie de l’assurance cyber a rendu cela obligatoire. La sécurité IA suit la même trajectoire obligatoire à mesure que les modèles deviennent plus performants et plus autonomes.

Mais nous devons tirer les leçons des erreurs de la sécurité. Elle est devenue un ajout : une pile séparée, un budget distinct, une équipe distincte découvrant les problèmes a posteriori. L’infrastructure de sécurité ne doit pas reproduire cette erreur. La surveillance, l’évaluation, l’auditabilité et la rétention immuable doivent faire partie intégrante de l’infrastructure IA elle‑même, co‑conçues dès le départ.

Voici la partie que la plupart des gens manquent : une IA sûre nécessite davantage d’IA. Les modèles de garde‑fou ne sont pas gratuits. Ils doivent être continuellement entraînés, affinés et inférés à chaque étape du runtime d’un agent. Les budgets de latence des tokens rendent cela concret : chaque réponse dispose d’une fenêtre fixe, et plus vous pouvez traiter de tokens dans cette fenêtre, plus vous pouvez exécuter de vérifications avant que la sortie ne soit diffusée. Et la véritable menace des modèles de pointe réside dans leur application agentique. Les agents fonctionnent comme des boucles d’inférence à haut volume, effectuant des appels répétés aux modèles sur de longues périodes. Chaque boucle suit le cycle observer, orienter, décider, agir, et chaque étape consomme des tokens. Cela transforme la sécurité IA en une guerre d’attrition de tokens. Les attaquants déploient des essaims d’agents rouges, les défenseurs des essaims d’agents bleus, et le camp capable de générer plus de tokens par dollar et par watt l’emporte. La tokenomie se situe sur le chemin critique tant de l’attaque que de la défense. Cela n’est plus une simple expérience de pensée depuis cet été, lorsqu’une attaque d’essaim d’agents rouges contre un grand dépôt de modèles a secoué l’industrie, et qu’une alliance IA sécurisée dédiée s’est formée en quelques jours. Parallèlement, les volumes continuent de croître : le traitement de tokens par l’industrie est passé de billions à quadrillions.

Une fois que la sécurité devient une exigence permanente, ses coûts de calcul, de mémoire et de données cessent d’être un surcoût. Ils deviennent partie intégrante de l’économie unitaire fondamentale de l’exécution de l’IA. Les entreprises qui internalisent cela tôt considéreront la sécurité comme une donnée de conception. Toutes les autres la considéreront comme une taxe.

Merci pour cette excellente interview, les lecteurs qui souhaitent en savoir plus devraient visiter WEKA.