Pourquoi les administrateurs système ne font-ils toujours pas confiance à l’IA pour les systèmes de production

Deux années de promesses des fournisseurs sur l’auto-correction des infrastructures se heurtent à une réalité bien moins enthousiasmante : ceux qui gèrent les systèmes de production refusent toujours de laisser l’IA prendre le contrôle. Une nouvelle enquête menée auprès d’administrateurs IT montre que l’automatisation annoncée pour 2026—avec l’IA gérant la gestion des correctifs, la priorisation des vulnérabilités, la surveillance des systèmes et la gestion des incidents—n’a tout simplement pas vu le jour dans la plupart des environnements. L’écart entre ce que les administrateurs système attendaient en 2024 et ce qu’ils sont réellement prêts à autoriser aujourd’hui est révélateur : la question porte sur la confiance, la responsabilité et la gouvernance, bien plus que sur les capacités de l’IA.

Le rapport « 2026 Survey Report: AI Impact on Sysadmins » d’Action1 a interrogé les professionnels les plus proches de l’infrastructure de production sur l’utilisation réelle de l’IA, et les réponses vont à l’encontre du discours d’automatisation qui domine le marketing IT depuis 2024. Moins d’un administrateur système sur cinq utilise aujourd’hui l’IA pour la gestion des correctifs ou la priorisation des vulnérabilités. Près d’un quart n’a jamais utilisé l’IA dans un cadre professionnel. Et lorsqu’on leur demande s’ils laisseraient l’IA déployer des correctifs sur les systèmes de production sans supervision humaine, la majorité répond non.

Cette réticence n’a rien de technophobe. Elle répond de façon rationnelle à un problème non résolu : lorsqu’un système autonome intervient sur l’infrastructure de production, des fichiers sensibles ou des identités, et qu’un incident survient, qui est responsable des dégâts ? L’enquête montre que la question reste largement sans réponse, et c’est le même sujet qui anime aujourd’hui toutes les discussions sur la gouvernance de l’IA en entreprise, que l’IA serve à corriger un serveur ou à interroger une base clients.

Résumé des points clés

1. Les prévisions d’automatisation pour 2024 ne se sont pas réalisées. Moins d’un administrateur système sur cinq utilise aujourd’hui l’IA pour la gestion des correctifs ou la priorisation des vulnérabilités, et 23 % n’ont jamais utilisé l’IA dans un contexte professionnel, selon l’enquête 2026 d’Action1.
2. La supervision, pas l’autonomie, reste la norme acceptée par les administrateurs système. Seuls 14 % accepteraient que l’IA déploie des correctifs en production sans supervision humaine, tandis que 53 % exigent une supervision, et une minorité refuse toute intervention de l’IA sur les correctifs.
3. La confiance s’effondre dès qu’il s’agit d’outrepasser les règles. Seuls 11 % des administrateurs système accepteraient que l’IA outrepasse la politique de correctifs existante, et 40 % s’y opposent catégoriquement, illustrant une résistance profonde à l’idée que l’IA puisse agir hors du cadre défini.
4. La question de la responsabilité reste ouverte. Plus de la moitié des répondants craignent de perdre la visibilité ou le contrôle sur les actions menées par l’IA, et l’enquête note que lorsqu’une erreur survient lors de la gestion de fichiers ou d’identités par l’IA, la responsabilité des conséquences reste floue.
5. La solution passe par un accès gouverné, pas par la confiance aveugle ou l’interdiction totale. Imposer des contrôles d’accès à la demande et maintenir une traçabilité unifiée pour chaque action humaine ou IA permet aux organisations de disposer du registre de responsabilité qui fait défaut selon l’enquête, même si la gouvernance des accès et l’automatisation des opérations IT répondent à des problématiques différentes.

L’écart entre les prévisions 2024 et la réalité 2026

En 2024, alors que les fournisseurs présentaient l’IA générative comme la prochaine révolution des opérations IT, les administrateurs système prévoyaient des gains d’automatisation notables à l’horizon 2026 : l’IA gérant les tâches de correctifs courants, classant les vulnérabilités selon leur risque réel, surveillant les systèmes en continu et accélérant la réponse aux incidents. L’enquête de suivi d’Action1 mesure ce qui s’est réellement produit, et les résultats décrivent un marché qui a adopté l’IA de manière inégale et prudente, loin de l’automatisation généralisée attendue.

Moins d’un administrateur système sur cinq déclare utiliser l’IA pour la gestion des correctifs ou la priorisation des vulnérabilités aujourd’hui. C’est un taux d’adoption particulièrement bas pour deux tâches souvent citées comme idéales pour l’automatisation par l’IA—elles sont répétitives, riches en données et semblent parfaitement adaptées à la reconnaissance de schémas et à la priorisation. Autre point marquant : 23 % des répondants déclarent n’avoir jamais utilisé l’IA professionnellement, ce qui signifie que près d’un quart de la population des administrateurs système n’a pas intégré d’outils IA à son quotidien, deux ans après les prévisions initiales.

L’IA ne faillit pas à ces tests. Les administrateurs système choisissent simplement de ne pas lui confier les clés, ce qui en dit plus sur la confiance et la gouvernance que sur les capacités. Ce constat rejoint ce que Kiteworks observe sur la gouvernance des données IA : l’adoption tarde car les organisations manquent de contrôles pour rendre les actions de l’IA visibles, réversibles et traçables, non parce que les modèles ne sont pas à la hauteur.

Pourquoi les administrateurs système refusent-ils de laisser l’IA déployer des correctifs sans supervision ?

Le signal le plus clair dans les données d’Action1 concerne la question directe posée aux administrateurs système : accepteriez-vous que l’IA déploie des correctifs sur les systèmes de production sans supervision humaine ? Cinquante-trois pour cent répondent non—ils exigent une supervision humaine pour tout déploiement de correctif initié par l’IA. Seuls 14 % accepteraient un déploiement sans supervision. L’écart est donc important entre la tolérance à l’IA comme assistante et la tolérance à l’IA comme opérateur autonome, et cela reste vrai même chez ceux qui utilisent déjà des outils IA dans d’autres aspects de leur travail.

Le déploiement de correctifs est un cas d’usage pertinent car les enjeux sont concrets et immédiats. Un mauvais correctif appliqué en production peut interrompre des services, casser des dépendances ou ouvrir de nouvelles failles—des conséquences visibles en quelques heures, loin des risques abstraits d’un rapport de conformité. Les administrateurs système, qui gèrent ce risque au quotidien, savent qu’une décision de correctif implique souvent des arbitrages qu’un système automatisé ne peut pas faire : est-ce la bonne fenêtre de maintenance, ce système a-t-il une dépendance non documentée, y a-t-il une raison métier de reporter. Les répondants n’écartent pas l’aide de l’IA pour identifier et préparer les correctifs ; ils refusent simplement que l’IA prenne la décision finale et l’exécute sans validation humaine.

La résistance s’accentue encore lorsque la question porte sur l’« outrepassage de politique ». Seuls 11 % des administrateurs système accepteraient que l’IA outrepasse la politique de correctifs existante, et 40 % refuseraient dans tous les cas. La ligne est donc encore plus dure que pour la supervision, ce qui révèle un point important : les administrateurs système préfèrent que l’IA agisse dans un cadre qu’ils ont défini, plutôt que de lui donner le pouvoir de décider que ce cadre ne s’applique pas. Des règles qu’un système automatisé peut contourner sans bruit ne sont pas de vraies règles, mais de simples suggestions.

Les équipes IT semblent avoir bien compris cette nuance, mieux que ne le laissent entendre les argumentaires marketing qu’on leur propose.

Le vide de responsabilité quand l’IA agit sur des systèmes sensibles

Plus de la moitié des administrateurs système interrogés déclarent craindre de perdre le contrôle ou la visibilité sur les actions menées par l’IA. Cette inquiétude relie les questions sur les correctifs à un enjeu plus large mis en avant par le rapport d’Action1 : lorsqu’une erreur survient lors de la gestion de fichiers ou d’identités par l’IA, la question de la responsabilité reste sans réponse claire.

On retrouve ce même vide de responsabilité dans toutes les fonctions où les systèmes IA disposent d’un accès permanent aux données de production, aux identifiants ou à l’infrastructure, et pas seulement dans les opérations IT. Si un agent IA doté d’autorisations de gestion de fichiers supprime, déplace ou expose le mauvais document, l’analyse post-incident doit répondre à une question de base : à quoi l’agent avait-il accès, pourquoi, et qui l’a validé ? Si un système IA doté d’autorisations de gestion d’identités provisionne ou modifie un compte de façon incorrecte, les mêmes questions se posent. Sans registre de ce que l’IA était autorisée à manipuler et de ce qu’elle a réellement fait, « l’IA a fait une erreur » n’est pas une réponse exploitable.

C’est une impasse.

C’est exactement ce vide de confiance et de responsabilité qui est au cœur des travaux de Kiteworks sur la Shadow AI et la gouvernance de l’IA. Lorsque les systèmes IA opèrent avec des accès larges, mal définis et sans traçabilité cohérente, les organisations perdent la capacité de reconstituer les événements après un incident, rendant l’analyse des causes et la responsabilité quasiment impossibles. Les administrateurs système décrivent ce problème côté opérations ; les équipes sécurité et conformité le vivent côté accès aux données. C’est le même écart.

Shadow AI et la problématique plus large de gouvernance

Les résultats d’Action1 s’inscrivent dans une tendance plus large à laquelle les entreprises sont confrontées : les outils IA se multiplient dans les services plus vite que les cadres de gouvernance ne peuvent les suivre. Les opérations IT constituent un environnement relativement visible et contrôlé—les administrateurs système sont, par définition, plus sensibles aux risques de production que l’utilisateur métier moyen. Si cette population, avec ce niveau de vigilance sur l’infrastructure, refuse toujours d’accorder à l’IA une autorité sans supervision, cela donne une idée du manque de contrôle dans les services où l’IA s’installe de façon informelle, hors du champ de vision de l’IT et sans aucune revue des accès.

C’est tout l’enjeu de la Shadow AI : des collaborateurs et, de plus en plus, des agents autonomes se connectent à des systèmes, fichiers et bases de données via des outils IA jamais évalués, ni cadrés, ni tracés par l’organisation. Un administrateur système qui refuse de laisser un outil IA validé accéder à la production sans supervision a, au minimum, engagé une discussion de politique sur cet outil. Beaucoup d’usages de l’IA en entreprise n’ont même pas ce débat. La gouvernance des données que les équipes IT appliquent visiblement à la gestion des correctifs doit s’étendre à tous les systèmes où l’IA peut lire, déplacer ou agir sur du contenu sensible—dépôts de fichiers, messagerie électronique, transfert sécurisé de fichiers, systèmes d’identités, etc.

À quoi ressemble un accès IA gouverné dans le Control Plane Kiteworks

L’enquête Action1 identifie clairement le problème : les administrateurs système veulent l’aide de l’IA sans renoncer au contrôle, à la visibilité ou à la capacité de désigner un responsable en cas de problème. Pour cela, il faut appliquer la même discipline de gouvernance que pour les utilisateurs humains, de façon cohérente à tout acteur accédant à des systèmes sensibles, qu’il soit humain ou piloté par l’IA.

Kiteworks répond à ce besoin via un Control Plane Kiteworks qui régit l’accès, l’utilisation et l’échange des données pour chaque identité qui en fait la demande—qu’il s’agisse d’une personne connectée ou d’un agent IA effectuant un appel API. Chaque requête d’un système IA pour lire, récupérer ou agir sur du contenu est évaluée comme le serait une demande humaine : selon la politique RBAC et ABAC définie, au moment de la requête, et non comme une autorisation ponctuelle oubliée par la suite. Cette évaluation à la demande fait toute la différence entre « nous faisons confiance à cet outil IA en général » et « nous pouvons vérifier exactement ce que cet outil IA a consulté, à telle date, selon telle politique, dans le cadre de tel workflow ».

Deux fonctions répondent directement à l’écart de confiance mis en lumière par l’enquête. Kiteworks Compliant AI impose une gouvernance au niveau du contenu lors de la demande d’accès par un système IA, filtrant et limitant ce qu’un modèle ou agent IA peut récupérer selon la politique définie, et non selon le jugement du modèle. Le Secure MCP Server applique ce même contrôle aux agents IA connectés via le Model Context Protocol, de sorte que la requête d’un agent est soumise aux mêmes contrôles d’accès et intégrée dans les mêmes journaux d’audit unifiés qu’une demande utilisateur, et non sur une piste séparée dédiée à l’IA. Ces deux fonctions produisent l’élément que les administrateurs système jugent manquant selon Action1 : une trace vérifiable de ce qu’un système IA était autorisé à faire et de ce qu’il a effectivement fait, consultable par un humain, rattachée à une politique et à une identité précises.

Les limites de la gouvernance des accès : ce qu’elle résout et ce qu’elle ne résout pas

L’enquête Action1 mesure un sujet connexe, mais distinct de ce que la gouvernance des accès au contenu permet de résoudre. Les administrateurs système ont été interrogés sur le déploiement de correctifs, la priorisation des vulnérabilités et l’exécution de tâches IT par l’IA—des actions qui relèvent de la gestion des correctifs et de la configuration de l’infrastructure, et non de la couche d’accès au contenu et aux identifiants que gère une plateforme comme Kiteworks.

Un moteur de politique de données appliquant RBAC et ABAC aux requêtes d’un agent IA détermine si cet agent peut lire un fichier, récupérer un enregistrement ou agir sur un identifiant—et consigne cette action. Il ne décide pas si un correctif donné est sûr à déployer sur un serveur de production, et ne remplace pas les outils de gestion des correctifs, de contrôle des changements et de supervision évoqués par les administrateurs système. Les deux problèmes partagent une cause racine—la responsabilité ambiguë quand l’IA agit de façon autonome—mais nécessitent des contrôles différents. Les entreprises qui veulent combler ce déficit de confiance côté opérations IT ont besoin de plateformes de gestion des correctifs intégrant des workflows d’approbation et des mécanismes de retour arrière ; celles qui veulent sécuriser l’accès au contenu, aux fichiers et aux identités doivent imposer une gouvernance des accès et une traçabilité sur tous les systèmes touchés par l’IA. La plupart des organisations ont besoin des deux, et l’un ne remplace pas l’autre.

La gouvernance des accès n’est aussi efficace que la politique définie par l’organisation. Les contrôles RBAC et ABAC appliquent les règles définies par l’équipe sécurité ; ils ne déterminent pas de façon autonome ce qu’est un périmètre « sûr » pour l’accès IA selon un rôle ou un workflow. La responsabilité attendue par les répondants d’Action1 dépend du travail de définition des politiques en amont—déterminer qui et quoi doit accéder à quel contenu, dans quelles conditions—puis de la capacité de la plateforme à appliquer et tracer ces règles de façon cohérente.

Construire une adoption de l’IA dans les opérations IT fondée sur la gouvernance

Les administrateurs système interrogés décrivent des conditions raisonnables pour élargir le rôle de l’IA—visibilité, réversibilité, chaîne de responsabilité claire—et non un échec de l’adoption de l’IA. Les entreprises qui cherchent à combler le même écart pour l’accès de l’IA au contenu et aux systèmes sensibles doivent partir de ces trois conditions, plutôt que d’une autorisation ou d’un refus global.

Cela implique de considérer chaque agent IA et chaque workflow connecté à l’IA comme une identité soumise à la même politique d’accès, analyse de risque et exigences d’audit qu’un utilisateur humain—et non comme une exception parce que le demandeur est un modèle et non une personne. Cela implique de tracer les actions de l’IA avec une granularité suffisante pour répondre à « qu’a-t-elle consulté, quand, et avec quelle autorisation » sans devoir lancer une enquête forensique après coup. Et cela implique de bâtir des contrôles d’accès et une infrastructure d’audit assez précis pour que la confiance devienne secondaire, puisque chaque action est vérifiable, quel que soit l’acteur.

Les organisations qui réussiront sur ce point pourront élargir le rôle de l’IA dans les opérations IT et les workflows de contenu de façon réfléchie, sur la base de preuves, plutôt que de rester coincées entre interdiction totale et autonomie sans supervision—ce qui est précisément le dilemme décrit par la majorité des répondants d’Action1.

Pour en savoir plus sur la gouvernance de l’accès des agents IA au contenu sensible via un Control Plane unifié, réservez votre démo sans attendre.

Ressources complémentaires

• Article de blog
  Stratégies Zero-Trust pour une protection abordable de la confidentialité IA
• Article de blog
  Comment 77 % des organisations échouent à sécuriser les données IA
• eBook
  AI Governance Gap : pourquoi 91 % des petites entreprises jouent à la roulette russe avec la sécurité des données en 2025
• Article de blog
  Il n’existe pas de « –dangerously-skip-permissions » pour vos données
• Article de blog
  Les régulateurs ne se contentent plus de vous demander si vous avez une politique IA. Ils veulent des preuves de son efficacité.