L’IA déplace les arbitrages d’infrastructure
Les premiers usages de l’intelligence artificielle générative ont souvent été abordés par le haut : gains possibles, métiers concernés et vitesse d’adoption.
Mais à mesure que les projets sortent du registre de l’expérimentation, une autre question s’impose. Où ces usages doivent-ils tourner ? Sur quelles données ? Dans quel environnement ? Avec quelles garanties de confidentialité, de traçabilité et de performance ?
L’IA vient se brancher au système d’information, le traverser, parfois l’aspirer, en mobilisant messageries, documents internes, bases clients, référentiels métiers ou environnements de développement.
Cette capillarité change radicalement la nature des arbitrages, puisqu’un projet d’IA générative oblige à examiner les flux, les droits, les dépendances techniques, les journaux d’activité, la conservation des données et les conditions de réversibilité.
Le sujet rejoint aussi les exigences de protection des données. Le développement des systèmes d’IA doit notamment être pensé au regard du RGPD, dès la constitution des bases de données et la définition des finalités de traitement. Un cadre qui n’interdit pas l’innovation, mais qui invite néanmoins les organisations à clarifier ce qui est traité, pourquoi, par qui, et dans quelles conditions.
Pour les DSI, cette clarification devient une condition d’industrialisation.
Or cette clarification ne se joue pas seulement dans les règles de gouvernance ou les politiques de sécurité. Elle oblige aussi à regarder de plus près les lieux où l’IA est intégrée. C’est là que le débat sur le cloud, que l’on croyait derrière nous, revient dans les discussions.
Le cloud public ne répond pas à tous les cas d’usage
Oui, le cloud public reste incontournable. Il offre une capacité de calcul difficile à égaler, un accès rapide aux modèles les plus avancés, des services managés et une élasticité qui a largement contribué à accélérer les expérimentations IA. Il serait illusoire, pour la plupart des entreprises, de vouloir s’en passer par principe.
Mais l’IA rend plus visible ce que les architectures hybrides avaient déjà fait apparaître. Tous les usages ne présentent pas le même niveau de sensibilité. Un assistant généraliste utilisé pour reformuler un texte ne soulève pas les mêmes enjeux qu’un agent connecté à des données RH, à une base contractuelle, à des informations de santé, à des secrets industriels ou à des référentiels financiers. Dans ces cas, c’est la maîtrise de l’environnement dans lequel les données circulent qui est en jeu.
C’est d’ailleurs ici que la notion « "d’infrastructure souveraine » reprend de l’épaisseur. On ne parle pas nécessairement d’un retour massif à l’on-premise, ni d'un refus du cloud. Elle peut prendre la forme d’un cloud privé, d’un cloud de confiance, d’environnements dédiés, d’une segmentation plus stricte des traitements, ou encore d’une combinaison entre services publics et infrastructures maîtrisées.
L’objectif est bien de savoir jusqu’où l’entreprise garde la main sur ses choix d’architecture, ses conditions d’exploitation et ses marges de manœuvre futures.
Vincent Barthez, Responsable Digital Foundation au sein de la société de conseil et de services numériques Inside précise « Avec l’IA, la souveraineté ne se limite plus à la localisation des données. Elle concerne la capacité d’une entreprise à choisir son architecture, à maîtriser ses briques technologiques et à garantir à ses utilisateurs un environnement performant, sécurisé et évolutif. L’enjeu n’est pas d’opposer cloud public et on-premise, mais de construire une trajectoire cohérente avec les usages, les contraintes métiers et le niveau d’indépendance recherché. »
Cette manière de poser le sujet a une conséquence directe pour les DSI. La souveraineté devient une capacité d’arbitrage, et donc un sujet d’architecture.
Un sujet qui devient architectural avant d’être technologique
Cette dimension architecturale apparaît rarement au premier jour d’un projet. Elle surgit souvent plus tard, lorsque le prototype a convaincu, que les métiers souhaitent l’étendre et que la DSI doit transformer un essai local en service exploitable. Le risque est alors de confondre réussite fonctionnelle et capacité à passer en production. Or c’est souvent à ce moment que les difficultés apparaissent.
Industrialiser un usage IA suppose en effet de répondre à des interrogations moins visibles que celles du modèle ou de l’interface. Comment l’outil s’authentifie-t-il ? Quels droits hérite-t-il des utilisateurs ? Ou encore, comment éviter qu’un service expérimental devienne, par glissement, une brique critique non gouvernée ?
Ces questions relèvent de l’architecture, car elles obligent les DSI à cartographier les flux, à distinguer les environnements, à segmenter les usages, à définir des zones de confiance et à articuler les choix d’infrastructure avec la gouvernance des données.
L’IA vient ainsi rappeler que l’innovation n’est robuste que si les fondations le sont.
Cette dimension architecturale est aussi renforcée par l’évolution réglementaire. La directive NIS 2, qui vise à renforcer la cybersécurité des réseaux et systèmes d’information, conduit un plus grand nombre d’organisations à structurer leur démarche de sécurisation. Ainsi, les infrastructures deviennent des objets de gouvernance, de conformité et de résilience.
Cette évolution change aussi la place de la cybersécurité. Longtemps pensée comme un ensemble de contrôles appliqués aux environnements existants, elle tend à devenir une composante des choix d’infrastructure eux-mêmes. Plus les usages IA se rapprochent des données et des processus critiques, moins la sécurité peut être traitée comme une couche ajoutée après coup.
La sécurité doit être intégrée dès la conception
L’IA rend les fondamentaux de la cybersécurité plus exigeants. Ils prennent en effet une nouvelle dimension lorsque les usages IA accèdent à des données internes, produisent des contenus, assistent des décisions ou s’intègrent à des processus critiques.
Dans cette perspective, la sécurité participe à la continuité de service, à la qualité d’exploitation et, de plus en plus, à la capacité de l’entreprise à démontrer sa conformité.
Alexandre Brianceau, CEO de l'éditeur de la plateforme d'automatisation de la sécurité Rudder, explique ainsi qu'à l'heure actuelle, aucune entreprise ne peut se permettre, d’avoir une panne de mails pendant plusieurs heures, un service « down » sur leur site, voire un piratage massif d’informations, sans que cela ait des conséquences, parfois dramatiques, sur son activité et son image. L’automatisation de la sécurité de l'infrastructure SI est devenue en quelques années un véritable outil de qualité, de conformité et de productivité. Dans un système d’information hybride, où cohabitent infrastructures internes, cloud public, services SaaS et environnements spécialisés, le contrôle manuel atteint vite ses limites. Automatiser les politiques de configuration, vérifier les écarts, documenter les états réels, appliquer plus rapidement les correctifs et harmoniser les règles devient une condition de fiabilité.
Pour les projets IA, cette logique doit intervenir dès la conception.
Aussi, avant même de chercher à multiplier les agents ou les assistants, les entreprises doivent s’assurer que leur socle technique peut être piloté, observé et corrigé avec le même niveau d’exigence que les services IA qu’il accueillera.
Industrialiser les fondations avant les usages IA
L’IA générative agit finalement comme un révélateur. Les entreprises dont les infrastructures sont lisibles, documentées, gouvernées et sécurisées disposent d’un avantage évident pour passer de l’expérimentation à l’usage maîtrisé. Les autres découvrent que les limites ne viennent pas toujours de l’algorithme, mais de la difficulté à savoir où sont les données, qui y accède, quelles dépendances existent et comment sécuriser l’ensemble.
Pour les DSI, la priorité est donc d’abord d’industrialiser le pilotage de l’infrastructure. Cela suppose évidemment une vision claire des environnements, des niveaux de criticité, des coûts, des contraintes réglementaires, mais également des scénarios de réversibilité.
Cela suppose aussi de ne pas opposer mécaniquement cloud public, cloud souverain et on-premise, mais de les articuler selon les usages.
Contenu proposé par Cloudlist, le carrefour de l’information sur le secteur IT