Les équipes de sécurité Databricks et Google face à un nouveau compromis pour la défense par IA

Databricks a publié un nouveau guide de sécurité articulé autour d’un conflit : l’IA peut accélérer la défense, mais seulement lorsque les équipes font confiance aux données et à l’automatisation qui la sous-tendent. Pour les organisations qui évaluent des déploiements databricks google, la proposition va au-delà de l’analytique. Databricks veut faire du lakehouse une couche opérationnelle pour les données de sécurité, les investigations, l’ingénierie de détection et la réponse assistée par IA.

Ce guide arrive alors que les équipes de sécurité réévaluent le système de gestion des informations et événements de sécurité, ou SIEM, qui centralise traditionnellement les journaux et les alertes. Databricks estime que la télémétrie fragmentée, la rétention coûteuse et les workflows déconnectés empêchent les défenseurs d’utiliser efficacement l’IA. Sa réponse proposée place les données d’entreprise gouvernées au centre, puis permet aux analystes et aux agents IA de travailler dans ce contexte partagé.

Cette position place Databricks face à davantage que les fournisseurs SIEM établis. Elle remet en cause l’idée selon laquelle les données de sécurité doivent rester dans une plateforme de sécurité spécialisée. Google Security Operations, Microsoft Sentinel, Splunk, CrowdStrike et d’autres fournisseurs ajoutent eux aussi des fonctions d’investigation et de réponse pilotées par IA. La concurrence devient un choix entre une suite de sécurité intégrée et une plateforme de données plus large adaptée à la défense.

Ce que Databricks a réellement mis sur la table

Cette annonce constitue un plan stratégique pour les opérations de sécurité, et non une référence produit validée de manière indépendante.

Databricks a publié son ebook destiné aux responsables de la sécurité le 2 septembre 2026. Le guide présente une architecture de données unifiée comme fondement de la cyberdéfense moderne. Son argument central est que les organisations ne peuvent pas déployer des agents de sécurité fiables tant que leurs journaux, identités, alertes et contexte métier restent séparés.

L’entreprise décrit trois évolutions liées. Les équipes de sécurité devraient consolider davantage de télémétrie, rendre l’analytique accessible au-delà des groupes d’ingénierie spécialisés et introduire des agents IA dans des workflows gouvernés. Cette approche fait du lakehouse plus qu’un espace de stockage à long terme. Il devient un lieu de détection, d’investigation, d’enrichissement et d’activités de réponse ciblées.

Le guide destiné aux responsables de la sécurité met en avant plusieurs chiffres clients et sectoriels. Databricks affirme que 72 % des dirigeants de la sécurité interrogés peinent à gérer des données cloisonnées. L’entreprise cite également Arctic Wolf, qui traite huit mille milliards d’événements de sécurité chaque semaine.

Le guide indique que Rivian a réduit de 60 % les coûts liés au SIEM après avoir modernisé son architecture de données de sécurité. Un autre exemple affirme que des équipes ont déployé des règles de détection cinq à six fois plus rapidement. Ces chiffres illustrent l’argument de l’entreprise, mais exigent une interprétation prudente.

Databricks ne présente pas chaque chiffre comme une comparaison contrôlée entre des environnements de sécurité équivalents. Le mix de charges de travail, les politiques de rétention, les effectifs, le volume de données et les contrats existants peuvent influer considérablement sur le résultat. Une mise en œuvre réussie chez un client n’établit pas un taux d’économies universel.

Le signal utile réside dans la tendance derrière ces exemples. Les équipes de sécurité souhaitent une rétention plus longue, une télémétrie plus étendue et un accès plus rapide aux données contextuelles. L’économie des SIEM traditionnels peut les inciter à filtrer les informations avant leur ingestion ou à déplacer les journaux plus anciens vers un stockage distinct.

Cette séparation crée des frictions opérationnelles. Un analyste enquêtant sur un accès suspect peut avoir besoin d’alertes endpoint, de l’historique des identités, de journaux d’audit cloud, de l’attribution des actifs et de l’activité applicative. Si ces enregistrements sont répartis entre plusieurs systèmes, une investigation automatisée hérite des mêmes lacunes.

Un lakehouse modifie la frontière entre stockage et analyse. Il peut conserver des enregistrements structurés aux côtés d’informations moins standardisées, tout en prenant en charge SQL, Python, le machine learning et le partage de données gouverné. Databricks qualifie cette architecture de plateforme unifiée pour les données, l’analytique et l’IA.

L’entreprise promeut également Agent Bricks, son environnement destiné à créer des agents IA spécialisés par domaine. Dans les opérations de sécurité, un agent pourrait résumer des alertes associées, récupérer des activités historiques ou aider à rédiger une logique de détection. L’agent reste toutefois tributaire des autorisations, d’un contexte fiable et d’un circuit d’approbation défini.

Cette distinction est importante. Le guide ne démontre pas que les agents IA peuvent remplacer en toute sécurité les analystes de sécurité. Il montre comment Databricks veut que les organisations préparent leurs données et leur gouvernance à une automatisation accrue.

C’est une affirmation plus limitée, mais aussi plus lourde de conséquences. Si les entreprises acceptent cette prémisse, les décisions d’architecture de sécurité se rapprochent de l’équipe responsable de la plateforme de données. L’achat d’un SIEM devient en partie une question de formats de stockage, de catalogues, d’accès aux modèles et de contexte d’entreprise réutilisable.

Pourquoi les déploiements Databricks Google comptent maintenant

L’histoire databricks google importe parce que la défense par IA couvre désormais la plateforme de données, les contrôles cloud, les systèmes d’identité et les fournisseurs de modèles externes.

Databricks opère sur Google Cloud depuis l’annonce du partenariat entre les entreprises en 2021. Le partenariat cloud initial mettait l’accent sur l’analytique intégrée, le machine learning, la facturation unifiée, la prise en charge des identités Google et un accès plus simple aux données.

Les implications en matière de sécurité se sont élargies depuis. Un espace de travail Databricks peut utiliser le stockage, le réseau, l’identité, le chiffrement et les services d’audit de Google Cloud. Les équipes de sécurité peuvent également analyser la télémétrie dans Databricks sans considérer la plateforme elle-même comme l’unique source de protection.

Les recommandations actuelles de Google Cloud décrivent la sécurité comme une responsabilité partagée entre Databricks, le client et le fournisseur cloud. Cette frontière est essentielle lorsqu’une organisation transfère davantage de données de sécurité vers le lakehouse.

Google Cloud protège son infrastructure sous-jacente et fournit des contrôles pour les identités, les réseaux, le stockage et le chiffrement. Databricks sécurise sa plateforme gérée et propose des capacités au niveau de l’espace de travail. Les clients restent responsables des autorisations, de la classification des données, de l’isolation des charges de travail, du comportement des applications et de nombreux choix de configuration.

Un jeu de données de sécurité unifié n’élimine pas ces frontières. Il les rend plus visibles. Les investigations peuvent corréler les actions entre les systèmes, mais les administrateurs doivent toujours comprendre quel contrôle relève de quel opérateur.

Par exemple, Databricks sur Google Cloud prend en charge la fédération d’identités, l’authentification unique, la connectivité privée, les clés gérées par le client et la journalisation d’audit cloud. Ces contrôles peuvent réduire l’exposition lorsqu’ils sont correctement configurés. Ils peuvent également créer des angles morts lorsque les équipes supposent qu’une autre partie a couvert l’exigence.

L’expression databricks google peut donc désigner plusieurs décisions d’achat différentes. Une organisation peut utiliser Databricks pour l’analytique tout en conservant Google Security Operations comme SIEM principal. Une autre peut déporter la télémétrie historique vers Databricks. Une troisième peut construire des détections directement sur les données du lakehouse.

Ces conceptions entraînent des risques différents. Un magasin analytique secondaire n’a pas besoin de tous les workflows présents dans une console de sécurité principale. Un système qui gère le triage en direct, le confinement automatisé et les preuves réglementaires exige des garanties opérationnelles plus strictes.

Google fait également progresser sa propre pile de sécurité et de contrôle des agents. Son cadre d’identité des agents de 2026 comprend l’identité, la gestion des accès, des passerelles, des garde-fous et la défense à l’exécution pour les logiciels autonomes. Cela recoupe le problème de gouvernance que Databricks aborde depuis la couche de données.

Ce chevauchement crée à la fois coopération et concurrence. Databricks bénéficie de l’infrastructure Google Cloud et peut servir des clients déjà investis dans les identités et le stockage Google. Pourtant, Google commercialise également une plateforme d’opérations de sécurité qui concurrence Databricks pour la télémétrie, l’attention des analystes et les charges de travail d’automatisation.

Cette tension n’est pas inhabituelle dans les logiciels cloud. Les plateformes s’intègrent fréquemment au niveau de l’infrastructure tout en se concurrençant plus haut dans la pile applicative. Les acheteurs devraient évaluer quel système devient la référence pour les détections, les dossiers, les approbations de réponse et la conservation des preuves.

L’architecture affecte également la portabilité. Databricks met l’accent sur les formats de données ouverts et l’exploitation multicloud. Google Cloud met l’accent sur les services intégrés et les contrôles natifs du cloud. Les entreprises peuvent valoriser les deux, mais ces objectifs ne conduisent pas toujours à la même conception.

Un format de stockage ouvert peut faciliter la réutilisation des enregistrements de sécurité. Il ne rend pas automatiquement portables les règles de détection, les workflows d’incident ou les playbooks d’automatisation. Ces actifs de niveau supérieur dépendent souvent de schémas et d’API propriétaires.

Les responsables de la sécurité se retrouvent donc face à une question plus précise. Ils ne choisissent pas entre ouverture et intégration dans l’abstrait. Ils décident où accepter la spécialisation, où exiger la portabilité et où la gouvernance doit rester cohérente.

La véritable compétition oppose la couche de données à la suite SIEM

Databricks parie que le contrôle des données de sécurité comptera davantage que la propriété de la console d’analyste traditionnelle.

Un SIEM conventionnel combine ingestion, normalisation, recherche, détection, alertes, investigation et reporting. Sa valeur provient de l’intégration de ces fonctions dans un workflow centré sur la sécurité. Sa faiblesse apparaît lorsque le volume de données augmente plus vite que les budgets ou la capacité opérationnelle.

Databricks aborde le problème dans la direction opposée. L’entreprise commence par un stockage de données évolutif, des outils de traitement ouverts, une gouvernance centralisée et le machine learning. Les fonctions de sécurité sont ensuite construites sur cette base.

Ce modèle peut aider les équipes à conserver la télémétrie brute pour des investigations ultérieures. Il permet également de joindre les enregistrements de sécurité au contexte métier. Une connexion inhabituelle devient plus utile lorsque les analystes peuvent la relier au rôle d’un employé, à un appareil géré, au propriétaire d’une application et aux récents changements d’accès.

La défense pilotée par IA bénéficie de ce contexte. Un modèle qui ne reçoit qu’un titre d’alerte et quelques champs d’événement dispose d’éléments limités. Un agent gouverné capable de récupérer un historique autorisé a davantage de chances de produire un résumé utile.

Davantage de données ne garantit pas une meilleure réponse. Une normalisation médiocre peut créer des identités contradictoires, des événements dupliqués et des chronologies trompeuses. Les équipes de sécurité doivent toujours maintenir les schémas, les contrôles de qualité, la traçabilité et la logique de détection.

C’est là que les fournisseurs SIEM conservent un avantage. Ils proposent du contenu spécifique à la sécurité, des interfaces d’investigation établies, des connecteurs, une gestion des dossiers et des intégrations de réponse. De nombreux clients préfèrent ces capacités packagées à l’assemblage d’une plateforme de données généraliste.

Google Security Operations propose de l’analytique de sécurité à l’échelle du cloud et du renseignement sur les menaces dans un environnement opérationnel dédié. Microsoft relie Sentinel à ses produits d’identité, d’endpoint, de productivité et de cloud. CrowdStrike étend les données endpoint et de menaces vers une plateforme de sécurité agentique.

Splunk dispose d’une large base installée, d’intégrations étendues et de plusieurs années de contenu de détection. Palo Alto Networks et d’autres fournisseurs de sécurité consolident également les données et l’automatisation. Databricks entre sur un marché où les acheteurs font déjà face à des promesses de plateformes qui se chevauchent.

La position la plus forte de Databricks n’est pas le remplacement immédiat. C’est le levier architectural. Les organisations peuvent utiliser le lakehouse pour réduire la duplication de télémétrie, conserver davantage d’historique, enrichir les enquêtes et tester des workflows assistés par l’IA sans déplacer d’un coup tous les processus opérationnels.

Une approche progressive facilite également la mesure des performances. Les équipes peuvent commencer par l’optimisation des coûts liés aux journaux ou la chasse aux menaces historiques. Elles peuvent comparer la vitesse des requêtes, la couverture de détection, l’effort d’ingénierie et les dépenses opérationnelles totales avec le système existant.

L’étape suivante pourrait consister à déplacer certaines détections vers Databricks. Les ingénieurs sécurité peuvent gérer la logique au moyen de pratiques de développement familières, notamment le contrôle de version et les tests. Les alertes peuvent continuer d’être transmises vers un système établi de gestion des cas.

Un remplacement complet exige davantage de preuves. Un SIEM principal doit prendre en charge une ingestion fiable, une détection à faible latence, la continuité des enquêtes, les exigences d’audit et la coordination des réponses. Il doit aussi rester utilisable lors d’incidents qui affectent d’autres systèmes de l’entreprise.

Databricks présente Lakewatch comme un SIEM ouvert et agentique, construit sur la plateforme de l’entreprise. Cette orientation produit clarifie l’intention concurrentielle. Databricks souhaite passer du soutien à l’analytique de sécurité à la maîtrise d’une plus grande part du workflow opérationnel.

Ce changement exerce une pression sur les fournisseurs traditionnels en matière d’économie de rétention et d’accès aux données. Il impose aussi à Databricks de répondre à des attentes propres à la sécurité. La fiabilité d’une plateforme de données est nécessaire, mais un système de défense opérationnelle porte des responsabilités supplémentaires.

Le levier des acheteurs consiste à séparer les affirmations en couches vérifiables. L’économie du stockage peut être évaluée indépendamment de la qualité de détection. La productivité des agents peut être évaluée séparément de la sûreté des réponses. La portabilité peut être testée aux niveaux des données, des requêtes, des règles et des workflows.

Les responsables de la sécurité doivent également suivre le travail caché. Une plateforme peut réduire la pression liée aux licences tout en augmentant le travail d’ingénierie. La maintenance des schémas, le développement de connecteurs, l’ajustement des détections, les autorisations et le support d’astreinte doivent tous entrer dans la comparaison.

C’est pourquoi la proposition de Databricks est plus significative qu’une simple annonce de fonctionnalité IA. Elle redéfinit la frontière entre l’infrastructure de données d’entreprise et le centre des opérations de sécurité. Cette frontière façonne depuis des années les budgets et les workflows de sécurité.

La défense pilotée par l’IA hérite d’un problème de gouvernance de l’IA

Les mêmes agents qui accélèrent les enquêtes peuvent aussi accélérer les erreurs, les accès non autorisés et les réponses insuffisamment supervisées.

Databricks présente la gouvernance comme une composante de l’architecture plutôt que comme une étape de conformité distincte. Unity Catalog contrôle l’accès aux données et aux actifs IA. Unity AI Gateway gère le trafic vers les modèles et les services d’outils.

Le guide de gouvernance de l’IA de l’entreprise indique que la passerelle peut acheminer les requêtes vers les modèles et le Model Context Protocol. Elle peut aussi appliquer des limites, mettre en œuvre des politiques et enregistrer l’utilisation entre plusieurs fournisseurs.

Model Context Protocol, ou MCP, est une norme qui permet aux applications IA de se connecter à des outils et à des sources de données. Dans un environnement de sécurité, un service MCP peut exposer du renseignement sur les menaces, des fonctions de gestion de tickets, des enregistrements d’actifs ou des outils de réponse approuvés.

Le contrôle centralisé offre un avantage concret. Une organisation peut gouverner un modèle externe, un agent de programmation ou un service MCP via la même couche d’accès que celle utilisée pour les autres actifs de données. Databricks affirme que cela peut inclure des modèles de Google, Anthropic et OpenAI.

Certaines capacités restent en bêta. Databricks décrit des politiques de service capables d’autoriser, de refuser ou d’exiger une approbation pour les requêtes selon leur contenu. Le statut d’aperçu est important lorsque ces politiques sont censées empêcher l’exposition de données sensibles ou l’utilisation dangereuse d’outils.

Aucun responsable de la sécurité ne devrait considérer une protection bêta comme l’unique barrière protégeant une action de réponse en production. La défense exige des contrôles superposés. Les restrictions d’identité, les outils à périmètre limité, les étapes d’approbation, la journalisation, les limites de débit et les actions réversibles doivent se renforcer mutuellement.

La revue humaine doit également être définie avec précision. Exiger qu’un analyste approuve chaque suggestion peut préserver le contrôle, mais cela risque de recréer la file d’attente que l’automatisation devait réduire. Autoriser une large autonomie peut améliorer la vitesse tout en augmentant l’impact d’une mauvaise décision.

Une conception pragmatique répartit les actions selon leurs conséquences. La récupération en lecture seule comporte moins de risques que la désactivation d’un compte. Rédiger une règle de détection diffère de son déploiement. Mettre en quarantaine un seul endpoint diffère de la modification d’une politique à l’échelle du réseau.

Chaque catégorie nécessite sa propre limite d’autorisation. Les actions réversibles et à forte confiance peuvent recevoir davantage d’automatisation. Les actions ambiguës ou à fort impact doivent exiger des éléments supplémentaires et une approbation explicite.

L’exposition des données soulève une autre préoccupation. Un agent d’enquête a souvent besoin des activités des utilisateurs, des détails sur les appareils, des journaux d’applications et du contexte organisationnel. Cette combinaison peut révéler des informations personnelles ou professionnelles sensibles, même lorsque chaque source semble inoffensive prise isolément.

Databricks indique dans sa documentation sur la confiance dans l’IA que les fournisseurs partenaires de modèles ne stockent ni les prompts ni les réponses. L’entreprise indique également que les autorisations Unity Catalog régissent les données que ses fonctionnalités IA peuvent envoyer.

La documentation reconnaît que les modèles peuvent halluciner ou produire des réponses incorrectes. Cet avertissement est particulièrement important en sécurité, où un résumé fluide mais inexact peut détourner une enquête ou impliquer à tort un utilisateur.

La récupération tenant compte des autorisations réduit les accès non autorisés. Elle ne prouve pas l’exactitude factuelle. Les équipes ont besoin d’évaluations fondées sur des schémas d’incidents réels, des entrées adverses, une télémétrie incomplète et des preuves contradictoires.

L’injection de prompt ajoute un autre risque. Un attaquant pourrait placer un texte malveillant dans un ticket, un champ de journal, un dépôt ou un document qu’un agent récupère ensuite. Si le système traite ce contenu comme une instruction, le workflow d’enquête peut être manipulé.

Les politiques de gouvernance peuvent filtrer certaines attaques, mais une défense fiable dépend également d’une séparation architecturale. Les données récupérées doivent rester non fiables. Les outils doivent imposer l’autorisation en dehors du modèle. Les actions sensibles ne doivent pas dépendre uniquement d’une décision générée.

L’auditabilité devient le test final. Les équipes ont besoin de traces indiquant quelles données un agent a consultées, quel modèle les a traitées, quels outils ont été appelés et qui a approuvé le résultat. Sans cette chaîne, l’examen des incidents et les preuves réglementaires deviennent difficiles.

Cela est aussi pertinent pour le travail de connaissance en dehors du centre des opérations de sécurité. Les équipes qui utilisent une base de connaissances IA font face à des questions similaires concernant les autorisations, la qualité des sources et la traçabilité. La sécurité en augmente les conséquences, mais le principe de gouvernance reste le même.

Databricks a réuni des composants crédibles pour ce problème. L’entreprise n’a pas établi que chaque client puisse les combiner pour assurer une défense autonome sûre. Ce résultat dépend de la rigueur de mise en œuvre, de la mesure et de la responsabilité opérationnelle.

Trois signaux montreront si la stratégie fonctionne

Le prochain test n’est pas une nouvelle démonstration d’IA ; c’est la preuve que Databricks peut améliorer la défense sans déplacer les coûts et les risques ailleurs.

Le premier signal est une performance client compréhensible de manière indépendante. Databricks a besoin de davantage d’études de cas définissant la référence, la charge de travail, le périmètre de déploiement et la période de mesure. Un pourcentage sans ces précisions attire l’attention, mais apporte peu d’indications.

Les responsables de la sécurité doivent examiner la couverture de détection, le délai moyen d’enquête, les taux de faux positifs, la profondeur de rétention et l’effort total d’ingénierie. Les affirmations sur les coûts doivent inclure le travail de migration, la maintenance des connecteurs, l’infrastructure et les effectifs.

Si les clients conservent une télémétrie plus large tout en réduisant à la fois le temps d’enquête et les dépenses d’exploitation, Databricks renforce son argument. Si les économies dépendent d’un important travail d’ingénierie personnalisé, l’argument devient moins convaincant pour les petites équipes.

Le deuxième signal est la maturité des opérations d’agents gouvernés. Les politiques de service, les contrôles d’approbation, les restrictions sur les outils et les traces d’audit doivent dépasser le stade des démonstrations. Les acheteurs ont besoin d’un comportement documenté en cas de défaillance, d’attaque et de preuves ambiguës.

Une validation utile montrerait un agent rencontrant un contenu récupéré malveillant sans le suivre. Une autre montrerait qu’une action de réponse est bloquée parce que l’identité demandeuse ne disposait pas de l’autorisation nécessaire. Les équipes ont également besoin de procédures claires de retour arrière et d’examen des incidents.

Si ces contrôles deviennent généralement disponibles et résistent à des tests adverses, la thèse de la défense pilotée par l’IA se renforce. Si les protections critiques restent en aperçu ou exigent un travail personnalisé considérable, l’autonomie doit rester strictement limitée.

Le troisième signal est la réponse concurrentielle. Google, Microsoft, Splunk, CrowdStrike et Palo Alto Networks contrôlent déjà d’importants workflows de sécurité. Ils peuvent ajuster les modèles de rétention, ouvrir l’accès aux données, étendre la gouvernance des agents ou approfondir les intégrations cloud.

Google mérite une attention particulière, car il est à la fois partenaire d’infrastructure et concurrent sur les plateformes de sécurité. Un client databricks google peut combiner leurs services, mais le chevauchement des plans de contrôle peut créer une responsabilité peu claire.

Une interopérabilité plus étroite soutiendrait Databricks. Les données de sécurité pourraient rester portables, tandis que les alertes, les cas, le renseignement sur les menaces et les actions de réponse passeraient par des interfaces définies. Les acheteurs gagneraient en choix architectural sans reconstruire chaque workflow.

Un regroupement de plateformes plus étroit pourrait affaiblir l’argument. Si les fournisseurs établis associent une économie de stockage acceptable à des agents de sécurité matures, les clients pourraient préférer une suite opérationnelle unique. Lors d’incidents, la commodité et la responsabilité comptent souvent davantage que l’élégance architecturale.

Les responsables de la sécurité n’ont pas besoin de choisir immédiatement une architecture finale. Ils peuvent tester le modèle Databricks sur une charge de travail coûteuse ou fragmentée. La chasse aux menaces historiques, l’analyse des audits cloud et le développement de détections offrent des points de départ circonscrits.

Le pilote doit préserver le workflow existant tout en produisant des mesures comparables. Les équipes doivent définir le succès avant de déplacer des données. Elles doivent également consigner le travail nécessaire pour normaliser la télémétrie et maintenir la fiabilité des détections.

Un examen utile pose cinq questions. Le nouveau système a-t-il conservé davantage de données pertinentes ? Les analystes ont-ils enquêté plus rapidement ? Les détections se sont-elles améliorées ? L’effort opérationnel total a-t-il diminué ? La gouvernance est-elle restée compréhensible ?

Les réponses montreront si le lakehouse devient une couche opérationnelle de sécurité ou simplement une autre destination pour les journaux. Elles distingueront également la valeur de l’IA de celle du stockage, que les fournisseurs présentent souvent ensemble.

Databricks a identifié une contrainte réelle. Les agents ne peuvent pas compenser des données de sécurité fragmentées, inaccessibles ou mal gouvernées. Son guide donne aux responsables de la sécurité une raison de réexaminer où ces données résident et qui les contrôle.

La question non résolue est la confiance opérationnelle. Une entreprise de plateforme de données peut-elle fournir la fiabilité, le contenu de sécurité, les contrôles de réponse et la responsabilité attendus d’un système de défense de première ligne ?

Pour les équipes évaluant une architecture databricks google, la prochaine étape est une comparaison mesurée, non un remplacement immédiat. Choisissez un workflow d’enquête, définissez ses autorisations et capturez les résultats de référence. Testez ensuite si un contexte unifié améliore les décisions sans élargir les accès ni augmenter le travail caché. Ces preuves compteront davantage que le nombre d’agents dans une démonstration produit.