3 « Autonome » s’est invité cette année dans les listes de fonctionnalités de nombreux éditeurs technologiques, et le stockage n’y a pas échappé. On comprend pourquoi. L’IA a poussé les équipes d’infrastructure sur un terrain pour lequel leurs outils n’ont jamais été conçus : plus de données, plus de charges de travail, plus d’urgence, et bien trop peu de personnes pour tout gérer à la main. « Autonome » est devenu un raccourci pour dire « nous avons résolu ce problème ». Mais le mot véhicule un mythe qu’il vaut la peine de démonter d’emblée, celui qui donne son titre à cet article : l’idée que garder un humain « dans la boucle » signifie qu’une personne approuve chaque action en temps réel. Mettez ces deux idées côte à côte, autonome et pourtant validé en tout point par un humain, et elles s’annulent. Soit le système attend une personne et n’est pas autonome, soit il agit seul et l’humain n’a pas vraiment le contrôle. C’est cette contradiction apparente qui fait que l’« humain dans la boucle » est souvent balayé comme un argument marketing. La solution consiste à voir le modèle comme deux couches, et non comme une séquence. La première est une politique permanente : les humains définissent à l’avance les limites d’autorisation et en sont responsables. La seconde est la boucle d’exécution, et elle va vite : une information émerge, la plateforme la confronte à cette politique permanente et exécute automatiquement lorsque l’action se situe dans les limites, en faisant remonter la décision à une personne lorsque ce n’est pas le cas ou lorsque les enjeux sont tels qu’un humain doit encore trancher sur le moment. Le contrôle reste entre les mains des personnes. Ce qui change, c’est le moment où elles l’exercent : elles passent à la couche de politique, là où se prennent les vraies décisions. Cette distinction compte, car « autonome » ne veut pas dire la même chose d’un éditeur à l’autre. L’un signale un problème et attend une personne ; un autre agit simplement, sans aucune approbation. Les acheteurs en sont réduits à deviner ce qu’ils achètent réellement, et ces suppositions coûtent cher lorsque les données se comptent en exaoctets et qu’une erreur ne reste pas petite. Voici la définition d’« autonome » que vous devriez exiger de votre fournisseur : les humains fixent la politique en amont ; un agent IA formule une recommandation ; la plateforme la vérifie au regard de cette politique et n’exécute, à la vitesse de la machine, que ce qui est déjà autorisé, en journalisant chaque étape et en sollicitant une personne pour tout ce que la politique ne couvre pas. L’autonomie ne supprime pas l’humain ; elle le fait intervenir plus tôt Personne de responsable d’un exaoctet de données de production ne veut d’un système qui agit en dehors des limites fixées, et personne ne veut signer une constatation d’audit indiquant « la plateforme a décidé ». Alors, lorsque le discours d’un éditeur laisse entendre que vos opérateurs sont désormais facultatifs, posez la question directement : que fait cette plateforme de nos données quand personne ne regarde, et peut-elle le prouver après coup ? C’est là que le mythe fait des dégâts. Parce que l’« humain dans la boucle » est assimilé à une approbation en temps réel, les équipes en concluent qu’elles doivent choisir entre garder le contrôle et aller à la vitesse de la machine, et les éditeurs qui vendent une automatisation sans limites se gardent bien de les détromper. Mais le vrai rôle de l’humain est autre : décider à l’avance quelles actions sont autorisées et dans quelles conditions, et assumer cette politique. L’humain rédige la politique ; la plateforme exécute à l’intérieur de celle-ci. Une grande partie de ce qui est vendu comme stockage autonome n’est que de l’automatisation ordinaire, ou de l’automatisation sans limites, habillée d’un vocabulaire de pilotage automatique. Des termes comme auto-réparation, auto-optimisation, zéro intervention ou « l’IA s’en occupe » éludent les seules questions qui comptent : quelles actions le système peut-il entreprendre seul, qui en a décidé, et qu’advient-il de tout ce que la politique ne couvre pas ? Supprimer l’humain n’a jamais été l’objectif. L’objectif était de supprimer le tri des alertes, l’archéologie dans les tableaux de bord et les suppositions à 3 heures du matin, et rien de tout cela ne devrait se terminer par l’obligation d’expliquer à un régulateur pourquoi votre plateforme de stockage a supprimé quelque chose de sa propre initiative. Un humain dans la boucle ne recrée-t-il pas simplement le goulot d’étranglement ? Regardez le chronomètre de l’adversaire. Le temps moyen de propagation (breakout time), de l’accès initial à l’activité malveillante, est tombé à 29 minutes en 2025, soit 65 % plus rapide que l’année précédente, le record le plus rapide étant de 27 secondes (CrowdStrike 2026 Global Threat Report). À 27 secondes, aucun processus qui attend une décision humaine sur le moment ne gagne cette course. C’est précisément pourquoi la décision doit être prise avant le départ de la course. Tout modèle autonome dont la réponse à l’urgence est « alerter quelqu’un et espérer qu’il soit réveillé » n’est pas une conception sérieuse. Cela ne signifie pas que le stockage doive tenter de détecter les attaques à la vitesse de l’adversaire. Ce n’est pas le rôle d’une plateforme de stockage, et tout éditeur qui vous le promet retombe dans l’« autonomous-washing ». Dans un workflow agentique, la vraie question est de savoir si l’action a déjà été autorisée par la politique avant le moment de l’urgence. Alors, un humain dans la boucle crée-t-il un nouveau goulot d’étranglement ? Seulement si l’on suppose que l’humain doit approuver en temps réel. La pré-autorisation change cette hypothèse : vous décidez à l’avance quelles actions sont déjà autorisées, en commençant par les opérations réversibles, tandis que tout ce qui détruit des données ou de la capacité exige encore une décision humaine sur le moment, au moins jusqu’à ce que le retour arrière lui-même ait été testé et prouvé sûr. Et lorsque aucune politique ne couvre la situation, le workflow se rabat sur la sollicitation d’une personne. Ce repli est délibéré ; à l’échelle de l’exaoctet, c’est le seul comportement par défaut sûr. Où se situe la limite d’autorisation : Scality ADI (Autonomous Data Infrastructure) prend en charge les deux modèles. Guardian, sa fonction d’opérations IA intégrée, fonctionne en lecture seule : il recommande des actions, et toute action initiée via Guardian requiert une approbation humaine. Les clients qui pilotent ADI depuis leur propre environnement agentique via MCP peuvent à la place définir des politiques d’autorisation dans cet environnement, ce qui permet aux actions déjà autorisées par ces politiques de s’exécuter sans nouvelle décision humaine sur le moment. Dans le modèle piloté par le client, cette séparation des tâches se déplace hors de Guardian : l’environnement agentique détient la limite d’autorisation, et la pile IA peut invoquer les actions opérationnelles exposées via MCP selon les autorisations qui lui sont attribuées. Ce n’est pas un point à minimiser : l’identifiant que vous confiez à votre pile IA est un accès à privilèges, et il doit être traité comme tel, avec une politique écrite, un périmètre défini et un enregistrement. Il faut aussi être précis sur ce qu’est une « recommandation », car la traiter comme une alerte améliorée est une erreur : Une alerte demande votre attention. Une recommandation demande votre décision. Une décision engage la responsabilité. C’est le piège de l’autonomie encadrée : une longue liste de recommandations en attente d’approbation en temps réel engendre une lassitude d’approbation, et les validations deviennent un simple tampon au lieu d’un contrôle. Décider à l’avance quelles actions votre politique autorise, et lesquelles elle n’autorisera jamais, est ce qui rend l’autonomie sûre à activer. Le vrai produit, c’est la limite, pas l’intelligence Les bonnes recommandations deviennent faciles à obtenir : ce n’est plus là que se trouve l’ingénierie intéressante. Le plus difficile, c’est la limite : une couche de politique détenue par le client, appliquée par la plateforme, avec un enregistrement de ce qui a été proposé, de qui l’a autorisé, de ce qui a été exécuté et de ce qui a changé. Dans Scality ADI, les politiques sont définies et approuvées par les opérateurs, et non par une automatisation opaque, et le client conserve la piste d’audit. Cette maîtrise compte, car à l’échelle de l’exaoctet, une mauvaise décision ne reste pas petite. ADI présente quatre niveaux sur un seul espace de noms S3 : GPU-Direct (flash TLC, S3 sur RDMA) Chaud (QLC et NL-SSD) Tiède (NL-SSD et HDD) Froid (bande et cloud) À l’échelle de l’exaoctet, une opération autorisée à tort peut toucher une quantité énorme de données avant qu’un humain ait le temps d’intervenir. C’est pourquoi, ici plus qu’ailleurs, la limite et l’enregistrement doivent tenir. L’environnement de menace explique précisément pourquoi l’enregistrement compte autant que la limite. Lors d’incidents de ransomware, 34 % des référentiels de sauvegarde ont été modifiés ou supprimés (Veeam 2025 Ransomware Trends). Si vous ne pouvez pas établir qu’une action était autorisée, vous avez créé un problème d’enquête au pire moment possible. Les équipes doivent reconstituer ce qui s’est passé, déterminer si l’activité était légitime et reconstruire une chaîne de responsabilité auditable. Tant que vous ne pouvez pas l’écarter, vous traitez un incident. Le versioning des objets vous dit ce qui a changé ; seul l’enregistrement vous dit qui l’a autorisé. Dans Scality ADI, les actions des opérateurs dans le Supervisor et son API sont écrites dans des journaux que vous pouvez transmettre à votre propre SIEM. Et un enregistrement ne vaut que par la responsabilité qui le sous-tend : demandez donc ce sur quoi tout éditeur s’engage contractuellement, et pas seulement ce que son architecture permet. Une check-list pour quiconque vous vend de l’« autonome » Une autonomie que l’on ne peut pas auditer est une responsabilité illimitée avec un meilleur marketing. Ne lui faites pas confiance. Ces questions sont conçues pour mettre au jour les limites, les contrôles et la responsabilité derrière toute promesse d’autonomie. À poser dès le premier rendez-vous : Que peut-il faire sans me demander ? Si l’éditeur ne peut pas énumérer ces actions, il n’y a pas de limite. Pouvez-vous produire le journal, et puis-je prouver qu’il n’a pas été modifié ? Interrogez-le sur la preuve d’intégrité, la conservation, l’export vers vos propres outils et ce dont l’éditeur est contractuellement responsable si l’enregistrement est faux. Un enregistrement que seul l’éditeur peut produire, c’est sa parole sur son papier à en-tête. Quelle politique le gouverne, et avec quelle finesse peut-on la délimiter ? Si la réponse est « nos paramètres par défaut », la politique n’est pas la vôtre, et le risque non plus. Délimitez-la par action, niveau, bucket, débit, part de capacité. Un périmètre grossier, c’est simplement un rayon d’impact plus large. À soumettre à la revue d’architecture : Comment empêche-t-on le moteur de recommandation d’exécuter ? Si le même composant peut proposer et agir, l’éditeur doit le dire. Sinon, demandez si la lecture seule est imposée par un identifiant et une surface d’API distincts, ou simplement affirmée dans la configuration. Une intention de conception n’est pas un contrôle. Puis-je l’observer avant de lui faire confiance ? Demandez une exécution à blanc ou une vue des changements proposés. Une autonomie que l’on ne peut pas répéter est une autonomie que l’on teste en production. Une action approuvée peut-elle être annulée ? Demandez quel retour arrière existe, à quelle granularité et dans quel délai. « Restaurer depuis la sauvegarde » n’est pas une annulation. Que se passe-t-il quand la boucle se rompt ? Si la pile d’approbation est injoignable ou que l’évaluation de la politique échoue, la plateforme s’arrête-t-elle, met-elle en file d’attente ou poursuit-elle sur sa dernière instruction ? Le fonctionnement en mode ouvert en cas d’échec (fail-open) est une décision que quelqu’un a prise pour vous. Et comment l’arrêter en pleine action : arrêt immédiat ou révocation de l’identifiant, et qui a le droit de le déclencher ? Qui est responsable lorsque la politique était mauvaise ? La réponse doit désigner un responsable clairement identifié, et non se terminer par « le système a décidé ». Soumettez cette liste de questions à votre fournisseur actuel et à chaque concurrent que vous évaluez, et comparez les réponses côte à côte. Posez les mêmes questions à Scality. Si nous ne pouvons pas y répondre, nous n’avons pas mérité le mot « autonome » non plus. Certaines de nos réponses sont déjà publiques. Lors de l’AI Field Day 8 (en anglais), nous avons fait la démonstration de Guardian et du plan opérationnel MCP devant des délégués indépendants venus précisément pour contester et poser les questions difficiles. La politique d’abord. Ensuite l’information, la vérification, l’exécution. « Autonome » continuera d’apparaître dans le marketing du stockage. Le mot en lui-même ne prouve rien ; ce qui compte, c’est qu’un éditeur puisse vous montrer une politique rédigée par des humains et fixée à l’avance, puis l’information, la vérification au regard de la politique et l’exécution, avec un enregistrement pour le prouver. Tout le reste n’est qu’une supposition déguisée en fonctionnalité. Voici à quoi ressemble une autonomie méritée : le stockage autonome vous implique toujours, plus tôt que vous ne le pensez. Vous fixez les limites dans une politique en amont ; un agent fait remonter ce qui se passe ; et la plateforme exécute, à la vitesse de la machine, uniquement ce que ces règles autorisent déjà, en journalisant chaque étape et en sollicitant une personne chaque fois que les règles ne couvrent pas la décision.
