Le piège de l’IA multi-cloud auquel font face les DSI

Google News a fait ressortir un avertissement clair pour les DSI : l’IA multi-cloud peut promettre de la flexibilité tout en créant un coûteux piège d’intégration. Le rapport d’InformationWeek remet en cause une stratégie familière consistant à combiner des services de Google Cloud, Amazon Web Services, Microsoft Azure et de fournisseurs d’IA spécialisés.

L’attrait est facile à comprendre. Un fournisseur peut proposer le modèle privilégié, tandis qu’un autre héberge des données critiques ou offre une meilleure couverture régionale. Une troisième plateforme peut déjà prendre en charge les systèmes d’identité, d’analyse ou le parc applicatif de l’entreprise.

Le conflit commence lorsque ces choix dépassent le stade des pilotes isolés. Chaque cloud supplémentaire introduit un autre système d’identité, modèle de politiques, chemin de données, couche de supervision et structure de facturation. Les DSI doivent alors arbitrer entre un accès étendu aux services d’IA et une architecture que leurs équipes peuvent gouverner.

Il ne s’agit pas simplement d’un nouvel avertissement sur les dépenses cloud. Les applications d’IA combinent en continu des modèles, des prompts, des données privées, des index vectoriels, des outils et des actions automatisées. Leurs dépendances franchissent bien plus souvent les frontières entre systèmes que celles d’une application web classique.

Google Cloud, AWS et Microsoft promeuvent tous des services conçus pour faciliter le déploiement de l’IA en entreprise. Leurs plateformes diffèrent toutefois encore par leurs interfaces de modèles, leurs autorisations, leur observabilité, leur réseau et leurs services de données managés. Ces différences transforment la portabilité, d’une promesse d’achat, en projet d’ingénierie.

L’enjeu central est donc clair. Le choix multi-cloud best-of-breed se heurte à la réalité opérationnelle d’une infrastructure fragmentée. Plus une entreprise répartit de composants d’IA, plus il devient difficile de comprendre comment l’information circule et qui contrôle chaque décision.

Google News révèle le passage du choix du cloud à la dépendance à l’IA

Le changement important n’est pas que les entreprises utilisent plusieurs clouds. C’est que l’IA relie désormais ces clouds par des dépendances persistantes de données et d’exploitation.

Pendant des années, les entreprises ont considéré l’adoption du multi-cloud comme un moyen de conserver leur pouvoir de négociation et de sélectionner les services adaptés. Les charges de travail pouvaient rester relativement autonomes. Une équipe pouvait héberger une application sur AWS tandis qu’une autre utilisait Microsoft Azure pour un système métier distinct.

L’IA d’entreprise affaiblit cette séparation. Une même application peut récupérer des documents dans un environnement, appeler un modèle dans un autre, puis envoyer les résultats vers un workflow tiers. Elle peut aussi utiliser une plateforme d’évaluation externe et un service de sécurité distinct.

Chaque interaction devient une partie du chemin de production de l’application. Une défaillance de la fédération d’identité, de la synchronisation des données, du réseau ou de l’accès aux modèles peut affecter la réponse finale. La supervision classique de disponibilité ne révèle pas toujours quel composant a provoqué une réponse médiocre ou dangereuse.

Les recherches de Google Cloud sur l’infrastructure illustrent l’ampleur de cette transition. L’entreprise a interrogé 1 402 responsables IT dans le monde pour son rapport 2026. Elle a constaté que 52 % des organisations répondantes utilisent une architecture multicloud hybride.

Le rapport indique également que 83 % ont besoin de mises à niveau d’infrastructure pour prendre en charge des systèmes autonomes de niveau production. Quatre répondants sur cinq ont identifié la sécurité, la gouvernance ou le MLOps comme un défi majeur. Le MLOps couvre les processus utilisés pour déployer, superviser et gérer les systèmes d’apprentissage automatique.

Ces résultats proviennent d’un fournisseur de cloud ayant intérêt aux dépenses d’infrastructure. Ils ne doivent pas être considérés comme une preuve neutre que chaque entreprise a besoin d’une refonte majeure. Ils montrent toutefois comment les fournisseurs d’infrastructure présentent le frein au passage en production.

Cet obstacle devient plus déterminant avec les agents d’IA. Un agent est un logiciel qui utilise un modèle pour choisir et exécuter des actions afin d’atteindre un objectif. Il peut lire des dossiers, appeler des applications métier, générer des documents ou mettre à jour des systèmes opérationnels.

Un chatbot peut échouer en produisant une réponse inutile. Un agent peut échouer en exécutant la mauvaise action à travers des systèmes connectés. Cela renforce l’importance d’autorisations cohérentes, de traces d’audit et de l’application des politiques dans chaque cloud participant.

La promesse initiale du multi-cloud visait largement à éviter la dépendance envers un seul fournisseur. L’IA modifie l’unité de dépendance. Une organisation peut éviter de dépendre exclusivement d’un cloud tout en devenant dépendante d’un maillage sur mesure de services incompatibles.

Ce maillage est plus difficile à remplacer qu’un seul produit managé. Son comportement repose sur des connecteurs, des transformations, des politiques d’accès, des règles de routage et les connaissances des équipes. L’indépendance vis-à-vis des fournisseurs peut donc produire une dépendance à l’architecture.

La couverture de Google News importe, car cet avertissement intervient alors que les entreprises passent des démonstrations aux workflows opérationnels. Les pilotes tolèrent les interventions manuelles et les jeux de données restreints. Les systèmes de production doivent gérer l’évolution des autorisations, des versions de modèles, les interruptions de service, les règles de conformité et les comportements imprévus des utilisateurs.

La question n’est plus de savoir si plusieurs modèles peuvent produire des réponses utiles. Les DSI doivent déterminer si toute la chaîne reste compréhensible après que des centaines d’équipes ont commencé à connecter leurs propres données et outils.

La pression de l’IA oblige les DSI à intégrer avant de standardiser

Les DSI sont poussés à produire des résultats visibles avec l’IA alors que les normes architecturales nécessaires à une montée en charge sûre restent incertaines.

Les conseils d’administration et les dirigeants métiers attendent de plus en plus des responsables technologiques qu’ils transforment les investissements en IA en améliorations opérationnelles mesurables. Les unités métier ne veulent pas attendre un programme pluriannuel de modernisation des données. Elles peuvent déjà acheter directement des outils d’accès aux modèles et d’automatisation.

Cette pression encourage l’optimisation locale. Une équipe produit sélectionne le modèle le plus performant pour son cas d’usage. Un groupe régional choisit un fournisseur qui répond aux exigences locales d’hébergement. Une entreprise acquise conserve la pile cloud qu’elle exploite déjà.

Chaque décision peut être raisonnable isolément. L’architecture combinée peut néanmoins devenir ingérable.

Les analyses des DSI sur la stratégie cloud décrivent le problème en termes similaires. Les responsables technologiques doivent désormais concilier la préparation à l’IA avec la cybersécurité, la gouvernance des données, la souveraineté, l’edge computing, l’architecture d’intégration et la résilience opérationnelle. Ces préoccupations affectent les mêmes charges de travail plutôt que de constituer des exercices de planification distincts.

L’IA augmente également le nombre de parties prenantes impliquées dans les décisions cloud. Les équipes de sécurité ont besoin de contrôles clairs sur l’accès aux données. Les équipes juridiques doivent savoir quelles informations atteignent un modèle et où le traitement a lieu.

Les équipes financières ont besoin de coûts de consommation et de transfert prévisibles. Les responsables des données doivent préserver la qualité, la traçabilité et les règles de conservation. Les propriétaires d’applications attendent toujours une latence et une fiabilité acceptables.

Une conception multi-cloud répartit ces responsabilités entre différents plans de contrôle. Un plan de contrôle est le système utilisé pour configurer les ressources, les autorisations, les politiques et les opérations. Chaque fournisseur expose une terminologie et des points d’application différents.

Le même employé peut donc recevoir des accès via plusieurs mappages d’identité. Une politique qui bloque les données sensibles dans un environnement peut ne pas couvrir un endpoint de modèle ailleurs. Les journaux peuvent enregistrer des identifiants différents pour le même utilisateur ou la même charge de travail.

Google a précédemment indiqué que 81 % des organisations interrogées rencontraient des difficultés de portabilité des applications et des données entre le cloud, les centres de données et les environnements edge. Son enquête multicloud a également révélé que 39 % citaient les charges de travail d’IA comme raison majeure d’utiliser des fournisseurs alternatifs.

Le lien est révélateur. L’IA pousse les organisations vers des clouds supplémentaires, tandis que la portabilité demeure l’une des difficultés les plus courantes de l’architecture. Le service qui attire une entreprise vers un deuxième fournisseur peut approfondir le travail d’intégration requis pour l’utiliser.

Les unités métier ne voient peut-être que l’endpoint de modèle. Les équipes de plateforme doivent gérer les routes réseau, les identifiants, les clés de chiffrement, les formats de données, les limites d’utilisation, la supervision et la réponse aux incidents. Elles ont aussi besoin d’un processus pour les mises à jour de modèles et les abandons de services.

Ce déséquilibre place les DSI sous pression dans les deux sens. Un contrôle centralisé peut ralentir l’expérimentation et encourager l’utilisation d’outils non autorisés. Une expérimentation sans restriction peut générer des plateformes dupliquées et des flux de données cachés.

La réponse imposée ne consiste pas simplement à dépenser davantage. Les DSI doivent définir où la diversité crée de la valeur métier et où la standardisation réduit le risque. Cela exige des décisions concernant les modèles approuvés, les couches de données partagées, les schémas d’identité, les méthodes d’évaluation et la responsabilité.

Ces choix sont difficiles parce que le marché évolue sans cesse. Un modèle sélectionné aujourd’hui pour ses performances peut perdre son avantage après la prochaine version. Une fonctionnalité managée qui fait gagner du temps de développement peut créer une dépendance plus profonde envers son fournisseur.

L’incertitude qui en résulte encourage des couches d’abstraction promettant de rendre les fournisseurs interchangeables. Ces couches peuvent aider, mais elles introduisent aussi un service supplémentaire que les équipes doivent exploiter. L’abstraction n’élimine pas la complexité lorsque les capacités sous-jacentes restent matériellement différentes.

La pression est immédiate, tandis que les effets sont durables. Une intégration pilote peut devenir une dépendance de production en quelques mois. Une fois que les employés ont construit des workflows autour d’elle, son remplacement affecte les processus, la formation et les données historiques.

Les DSI ne choisissent donc pas seulement entre des clouds. Ils choisissent les différences que leurs organisations devront assumer comme obligations opérationnelles continues.

L’IA best-of-breed devient une taxe d’intégration

L’IA multi-cloud ne crée de la valeur que lorsque le bénéfice de chaque service spécialisé dépasse le coût permanent de sa connexion et de sa gouvernance.

L’approvisionnement best-of-breed suppose que les entreprises peuvent sélectionner le composant le plus performant pour chaque besoin. Un cloud peut fournir des accélérateurs adaptés. Un autre peut proposer un modèle de fondation privilégié, c’est-à-dire un modèle général adapté à de nombreuses tâches en aval.

Un troisième fournisseur peut héberger les bases de données de l’organisation. Des fournisseurs indépendants peuvent proposer la récupération d’informations, le routage de modèles, l’évaluation, l’observabilité et la sécurité. Sur le papier, cela crée une pile flexible avec moins de compromis liés à un fournisseur unique.

En pratique, chaque frontière génère une taxe d’intégration. Cette taxe comprend le temps d’ingénierie, le déplacement des données, les contrôles dupliqués, les tests, la coordination des incidents et l’expertise spécialisée. Elle perdure après le premier déploiement.

Les données offrent l’exemple le plus clair. Un modèle a besoin d’un contexte métier pertinent pour produire des résultats utiles. Ce contexte peut résider dans des documents, des bases de données, des messages, des tickets, des systèmes clients et des dossiers opérationnels.

Déplacer toutes ces informations vers un seul cloud crée des problèmes de gouvernance et d’actualisation. Les laisser distribuées exige des systèmes de récupération capables de s’authentifier entre les sources et de préserver les règles d’accès. Chaque choix entraîne des conséquences opérationnelles.

La génération augmentée par récupération, couramment appelée RAG, fournit à un modèle des informations sélectionnées avant qu’il ne réponde. Un pipeline RAG peut paraître simple dans une démonstration. Son utilisation en production exige l’analyse des documents, l’indexation, les autorisations, les mises à jour, la gestion des suppressions, le classement, l’évaluation et la supervision.

Répartir ces composants entre fournisseurs rend l’analyse des causes profondes plus difficile. Une mauvaise réponse peut provenir du modèle, d’un index obsolète, d’un connecteur défaillant, d’autorisations manquantes ou d’un changement de classement. Chaque équipe peut ne posséder qu’un seul segment.

Les organisations peinent déjà à gérer cette fragmentation en dehors de l’IA. Gartner a indiqué que 85 % des organisations interrogées déployaient des applications de données et d’analytique sur plusieurs clouds. Seules 30 % de ce groupe ont fait état de capacités avancées en matière de données et d’analytique intercloud.

Les conclusions de Gartner proviennent d’une enquête menée avant la vague actuelle d’agents d’IA en production. Elles suggèrent que de nombreuses entreprises ont abordé l’expansion de l’IA avec des empreintes multicloud qui dépassaient déjà leur maturité d’intégration.

L’IA augmente les enjeux, car le comportement des applications dépend à la fois de la qualité des données et des résultats du modèle. Une intégration conventionnelle associe généralement des champs connus entre des systèmes. Un pipeline d’IA introduit des réponses probabilistes, ce qui signifie qu’une même requête peut produire des résultats variables.

Les équipes doivent évaluer à la fois l’infrastructure et la qualité des résultats. Elles doivent savoir si une requête a atteint le modèle prévu, utilisé les bonnes données, respecté les politiques et produit une réponse acceptable. Ces éléments de preuve doivent être conservés au-delà des frontières entre fournisseurs.

Le routage des modèles ajoute une autre difficulté. Un routeur peut envoyer les requêtes vers différents modèles selon le coût, la vitesse, la disponibilité ou le type de tâche. Cette approche réduit la dépendance à un seul modèle, mais complique les tests et l’attribution des responsabilités.

Les différents modèles interprètent les prompts différemment. Ils proposent des formats distincts d’appel d’outils, des limites de contexte, des contrôles de sécurité et une disponibilité régionale variables. Un modèle de secours peut maintenir une application en ligne tout en modifiant les caractéristiques de qualité ou de conformité de ses réponses.

La véritable portabilité exige donc davantage qu’un changement d’adresse d’API. Les équipes doivent normaliser les prompts, les outils, les évaluations, les contrôles de contenu, la journalisation et la gestion des erreurs. Elles doivent refaire ce travail chaque fois qu’un fournisseur modifie son interface ou le comportement de ses modèles.

L’architecture de transfert des données compte également. Déplacer de grands jeux de données ou un contexte d’inférence répété entre clouds peut ajouter de la latence et des frais de consommation. Même lorsque ces coûts paraissent acceptables lors des tests, l’usage peut augmenter rapidement après une adoption généralisée par les employés.

Une décision ciblée en faveur des meilleurs outils spécialisés peut néanmoins rester pertinente. Un modèle spécialisé peut offrir un avantage significatif pour le codage, l’analyse de documents ou les travaux scientifiques. Les services régionaux peuvent également répondre à des exigences de résidence des données ou de latence qu’un seul fournisseur ne peut satisfaire.

Le piège apparaît lorsque les organisations confondent optionalité et interopérabilité gratuite. L’accès à plusieurs clouds ne signifie pas qu’il est possible de déplacer les charges de travail en toute sécurité entre eux. Chaque voie supplémentaire doit avoir un responsable et des preuves de sa valeur.

Les CIO devraient considérer la diversité des fournisseurs comme une ressource limitée. Un nouveau service doit justifier non seulement sa capacité immédiate, mais aussi la surface d’intégration qu’il crée. Cette surface demeure une fois que la nouveauté du service s’est estompée.

Les équipes ont également besoin de traces durables de leurs décisions architecturales. Une base de connaissances technique consultable peut préserver les responsabilités, les dépendances et le contexte opérationnel. La documentation seule ne peut pas résoudre la fragmentation, mais l’absence de contexte ralentit chaque incident.

Les plateformes partagées réduisent la complexité, mais n’effacent pas les différences entre clouds

Une couche d’exploitation commune peut contrôler la diversité des infrastructures, sans pour autant rendre les services d’IA propriétaires réellement interchangeables.

L’ingénierie de plateforme offre une réponse à l’IA multicloud. Une équipe centrale crée des parcours approuvés pour les équipes applicatives, y compris des modèles de déploiement, des schémas d’identité, de la supervision et des contrôles de politique. Les développeurs utilisent ces parcours au lieu d’assembler chaque connexion de manière indépendante.

Kubernetes soutient souvent cette stratégie. Il orchestre les applications conteneurisées dans différents environnements d’infrastructure. La Cloud Native Computing Foundation a indiqué que 82 % des utilisateurs de conteneurs exécutaient Kubernetes en production dans son enquête 2026.

L’enquête de la CNCF décrit Kubernetes comme une couche d’exploitation commune pour les systèmes cloud-native et d’IA. Ce positionnement reflète un réel avantage. Les conteneurs peuvent rendre certaines parties d’une application plus cohérentes entre les clouds et les infrastructures privées.

Cependant, Kubernetes ne standardise pas toutes les capacités d’IA gérées. Un service de modèles propriétaire, une base de données vectorielle, un produit d’identité ou un entrepôt de données continuent d’exposer des comportements propres à chaque fournisseur. Déplacer le code d’une application ne déplace pas automatiquement ses données ni ses contrôles opérationnels.

Les interfaces de modèles ouvertes peuvent réduire certaines frictions. Des API standardisées permettent aux applications d’adresser plusieurs modèles selon un schéma de requête commun. Les logiciels d’inférence open source peuvent également exécuter les mêmes poids de modèles sur différentes infrastructures.

Ces approches créent des choix, mais elles transfèrent la responsabilité vers l’entreprise. Les équipes doivent gérer la capacité, les mises à niveau, les correctifs de sécurité, l’optimisation des performances et la gouvernance des modèles. La portabilité devient une capacité interne plutôt qu’une fonctionnalité achetée.

Une couche de données partagée constitue une autre option. Les entreprises peuvent maintenir un accès gouverné à l’information indépendamment des fournisseurs de modèles individuels. Les applications connectent alors des modèles approuvés aux mêmes services de données tenant compte des politiques.

Cette architecture limite les réplications incontrôlées. Elle concentre aussi les risques dans la couche partagée. Des métadonnées médiocres, des droits manquants ou une passerelle indisponible peuvent affecter chaque application d’IA qui en dépend.

L’identité centralisée et l’application des politiques sont tout aussi importantes. SANS a constaté que 55 % des répondants à son enquête multicloud de 2023 utilisaient plusieurs solutions d’authentification unique. Seuls 14 % ont déclaré travailler à l’adoption d’une solution unique.

L’analyse de SANS a également relevé une prolifération importante des comptes. Seize pour cent des répondants utilisaient plus de 100 comptes AWS, tandis que 12 % utilisaient plus de 100 abonnements Azure et comptes Google Cloud.

Les services d’IA superposés à cette empreinte peuvent hériter d’autorisations incohérentes. Un modèle peut recevoir un accès étendu parce que son identité de service ne correspond pas clairement aux droits existants des utilisateurs. Un connecteur peut également conserver son accès après qu’un employé a changé de rôle.

La gouvernance centralisée devrait donc suivre l’utilisateur, les données, le modèle et l’action, plutôt que le seul compte cloud. Les équipes ont besoin d’un inventaire reliant chaque cas d’usage de l’IA à un responsable, aux données approuvées, aux modèles déployés, aux résultats d’évaluation et aux contrôles opérationnels.

Cet inventaire ne peut pas rester une feuille de calcul statique. Les configurations d’IA changent trop fréquemment, et les ressources d’infrastructure apparaissent par automatisation. La gouvernance a besoin de politiques lisibles par machine et de preuves recueillies en continu.

L’observabilité doit également traverser les clouds. Les équipes devraient relier les traces applicatives, les requêtes de modèles, les événements de récupération, les appels d’outils, les décisions de politique et les résultats métier. Une trace est un enregistrement lié montrant comment une requête a circulé dans un système distribué.

Sans cette connexion, les tableaux de bord d’infrastructure ne fournissent que des réponses partielles. Un fournisseur peut afficher une requête de modèle réussie alors que le flux de travail global a renvoyé des informations obsolètes. Un autre peut enregistrer un appel d’outil bloqué sans expliquer le prompt en amont.

Les plateformes communes réduisent le nombre de schémas que les équipes doivent prendre en charge. Elles réussissent lorsqu’elles rendent les actions approuvées plus simples que les solutions improvisées. Une plateforme qui ajoute des formulaires et des délais sans automatisation utile poussera les développeurs vers un accès direct aux fournisseurs.

L’objectif n’est pas d’avoir une infrastructure identique partout. Il s’agit de maintenir un nombre contrôlé de différences, avec des responsables explicitement désignés. Les CIO ne devraient conserver des services propres à un fournisseur que lorsque ces services créent un avantage mesurable.

Cette approche accepte une certaine dépendance. C’est souvent plus honnête que d’affirmer que chaque charge de travail d’IA reste portable. La question pertinente est de savoir si cette dépendance est intentionnelle, visible et réversible à un coût acceptable.

L’écart de sécurité et de gouvernance est le plus difficile à tester

Le principal risque de l’IA multicloud n’est pas une panne spectaculaire. C’est la perte de la capacité à expliquer quelles données, quel modèle, quelle identité et quelle politique ont façonné une action.

Les équipes de sécurité gèrent depuis longtemps les différences entre les autorisations cloud, les réseaux et les journaux. L’IA introduit les prompts, le contexte récupéré, le contenu généré par le modèle et les appels autonomes d’outils. Chaque élément peut transporter des informations sensibles au-delà des frontières entre systèmes.

Un prompt peut inclure des dossiers clients ou une stratégie interne. Un service de récupération peut assembler des passages issus de plusieurs référentiels. Un fournisseur de modèles peut traiter ce contexte dans une autre région ou selon des conditions de conservation distinctes.

L’application peut ensuite envoyer sa réponse vers la messagerie électronique, le contrôle de source, un logiciel financier ou un système client. Une seule requête peut traverser plusieurs domaines administratifs avant que quiconque ne voie le résultat final.

Le contrôle d’accès traditionnel vérifie si une identité peut appeler une ressource. La gouvernance de l’IA doit également déterminer si un cas d’usage devrait combiner certaines données avec un modèle. Elle doit évaluer les actions que le modèle peut recommander ou exécuter.

Cette distinction rend la traduction des politiques difficile. Google Cloud, AWS, Azure et les environnements privés exposent des moteurs de politique distincts. Une restriction écrite pour une plateforme ne couvre pas automatiquement un service équivalent ailleurs.

La même incohérence affecte les preuves d’audit. Les régulateurs et les examinateurs internes peuvent demander quelle version de modèle a traité un enregistrement, quel contexte elle a reçu et pourquoi un outil s’est exécuté. Produire cet historique exige des journaux coordonnés, avec des identifiants et des périodes de conservation compatibles.

L’évaluation des modèles introduit une autre lacune. Les équipes testent si un modèle est précis, sûr et fiable pour une tâche définie. Un résultat satisfaisant s’applique à une configuration précise, incluant les prompts, les paramètres de récupération, les outils et la version du modèle.

Changer de fournisseur ou de modèle de secours peut invalider ces preuves. Même une mise à jour de modèle côté fournisseur peut modifier le comportement sans changer l’application environnante. Le routage multicloud multiplie les configurations à évaluer.

Les CIO devraient également interroger les affirmations des fournisseurs concernant un contrôle unifié. Un tableau de bord peut agréger des ressources sans appliquer des politiques identiques. Un connecteur peut afficher une activité tout en omettant un contexte important sur le modèle ou les données.

Une vérification indépendante reste essentielle. Les équipes devraient tester si les contrôles bloquent effectivement les chemins de données et les actions interdits. Elles devraient également simuler des défaillances impliquant des identifiants expirés, des modèles indisponibles, des index corrompus et des journaux incomplets.

La complexité de la sécurité augmente avec la complexité organisationnelle. Les fusions apportent des comptes cloud, des systèmes d’identité et des classifications de données hérités. SANS a identifié les fusions et acquisitions comme une raison majeure pour laquelle les organisations adoptaient des fournisseurs cloud supplémentaires.

Cet historique est important, car les projets d’IA cherchent souvent des données dans l’ensemble de l’entreprise réunie. Un nouvel assistant peut révéler des incohérences restées cachées tant que les systèmes desservaient des départements distincts. La récupération peut relier les référentiels plus vite que les équipes de gouvernance ne peuvent concilier leurs politiques.

La souveraineté des données crée une tension similaire. Une entreprise peut utiliser des clouds régionaux pour conserver les données dans les juridictions requises. Pourtant, un flux de travail d’IA peut router les prompts, la télémétrie ou les échantillons d’évaluation via des services situés en dehors de la limite prévue.

Les contrats et l’architecture doivent être cohérents. Un document de politique ne peut pas compenser un chemin réseau non documenté. De même, un déploiement techniquement régional ne résout pas toutes les questions juridiques concernant les modèles, l’accès au support ou les sous-traitants ultérieurs.

La conclusion sceptique est qu’aucune plateforme actuelle n’élimine ce travail. Les fournisseurs peuvent proposer des contrôles, des journaux et des produits d’intégration. Les entreprises restent responsables d’assembler ces éléments en preuves correspondant à leurs processus métier et à leurs obligations.

La standardisation a aussi ses limites. Une entreprise peut imposer une passerelle unique pour l’accès aux modèles, mais les utilisateurs peuvent coller des informations dans des outils externes. Elle peut approuver plusieurs modèles, mais les équipes produit peuvent découvrir des capacités indisponibles via l’interface approuvée.

La gouvernance doit donc combiner contrôles techniques, achats, formation et responsabilisation. Bloquer chaque expérimentation est irréaliste. Laisser chaque expérimentation devenir une infrastructure de production est tout aussi risqué.

Les DSI ont besoin de critères de sortie mesurables pour les projets pilotes. Avant toute extension, un système doit avoir un responsable désigné, un périmètre de données approuvé, des dépendances documentées, des résultats d’évaluation, des procédures de gestion des incidents et un suivi de l’utilisation. Il doit également disposer d’une procédure d’arrêt définie.

Ces exigences ralentiront certains déploiements. Ce délai coûte moins cher que de découvrir plus tard qu’aucune équipe ne peut reconstituer la façon dont une décision à fort impact a été prise.

Ce que les DSI devraient surveiller après l’avertissement de Google News

La prochaine phase montrera si l’IA multicloud devient une architecture gouvernée ou une nouvelle couche de prolifération non maîtrisée dans l’entreprise.

Le premier signal sera l’essor d’interfaces standardisées pour les modèles et les agents. La compatibilité technique doit couvrir davantage que la génération de texte. Elle doit inclure les appels d’outils, le contexte d’identité, les décisions de politique, les traces, les évaluations et le comportement en cas d’erreur.

Si les fournisseurs et les projets open source convergent vers des standards utiles, les entreprises pourront réduire les adaptateurs sur mesure. Cela renforcerait l’argument en faveur d’une IA multicloud délibérément conçue. Une compatibilité superficielle des API laisserait inchangé le problème central d’intégration.

Les DSI devraient surveiller les mouvements réels des charges de travail plutôt que les annonces des fournisseurs sur l’interopérabilité. Un test de portabilité crédible consiste à déplacer une application proche de la production entre fournisseurs tout en préservant les autorisations, les seuils de qualité, les journaux et les procédures de reprise.

Le deuxième signal sera de savoir si les entreprises consolident leurs couches de contrôle de l’IA. Les éléments pertinents incluent un nombre réduit de passerelles de modèles, des services d’évaluation partagés, des inventaires unifiés et une application cohérente des politiques entre les unités opérationnelles.

Cette consolidation indiquerait que les organisations transforment des expérimentations en plateformes gérées. La poursuite de la croissance des passerelles, bases vectorielles et produits d’observabilité qui se chevauchent conforterait la thèse de l’enfer de l’intégration.

La métrique ne devrait pas être le seul nombre d’outils. Une grande organisation peut raisonnablement avoir besoin de plusieurs produits. Les dirigeants devraient mesurer les fonctions dupliquées, les connexions non prises en charge, les exceptions de politique et le temps nécessaire pour retracer une transaction d’IA.

Le troisième signal concernera la fiabilité en production et le reporting des coûts liés aux déploiements d’agents. Les fournisseurs continueront de publier des enquêtes sur l’adoption, mais les DSI ont besoin de mesures opérationnelles. Elles incluent la fréquence des incidents, la qualité des réponses, la latence, les taux d’intervention, l’utilisation du transfert de données et le coût par tâche métier achevée.

Si ces mesures s’améliorent tandis que la diversité des fournisseurs augmente, les plateformes partagées contiennent la complexité. Si les coûts et les incidents progressent plus vite que l’adoption, le choix multicloud crée davantage de contraintes que de valeur.

Google News continuera de faire remonter des affirmations sur de nouveaux modèles, des partenariats cloud et des fonctionnalités d’interopérabilité. Les DSI devraient considérer chaque annonce comme une décision concernant un composant, et non comme une stratégie d’architecture complète.

Un modèle affichant de meilleures performances aux benchmarks peut tout de même constituer un mauvais ajout s’il exige un pont d’identité et un processus d’évaluation supplémentaires. Un endpoint moins coûteux peut revenir plus cher une fois pris en compte les transferts de données, l’ingénierie, la supervision et les travaux de conformité.

Les entreprises devraient également distinguer la résilience de la duplication. Exécuter des charges de travail équivalentes chez plusieurs fournisseurs peut réduire l’exposition à une panne unique. Cela n’améliore la résilience que si les équipes testent régulièrement le basculement et vérifient que le chemin secondaire se comporte de manière acceptable.

Une solution de repli inutilisée n’est pas de la résilience. C’est une dépendance non testée. La même règle s’applique aux routeurs de modèles, aux index de sauvegarde et aux pipelines de données répliqués.

Les achats devraient exiger un budget d’intégration en parallèle de l’approbation du service. Ce budget comprend les effectifs, les tests, l’examen de sécurité, l’observabilité, la documentation et la migration éventuelle. Il rend le coût récurrent visible avant que l’adoption ne crée une pression interne en faveur du maintien d’un service.

Les revues d’architecture devraient également se demander ce qui se produit lorsqu’un fournisseur modifie un modèle ou abandonne une fonctionnalité. Les équipes doivent identifier quels prompts, évaluations, workflows et utilisateurs seraient affectés. Cette cartographie des dépendances transforme le verrouillage abstrait en risque exploitable.

La bonne stratégie différera selon la charge de travail. Les tâches de recherche ou d’ingénierie à forte valeur peuvent justifier l’accès à plusieurs modèles spécialisés. L’assistance courante aux employés peut davantage bénéficier d’une plateforme restreinte et standardisée, avec des contrôles cohérents.

Les DSI n’ont pas besoin de rejeter l’IA multicloud. Ils doivent cesser de la considérer comme une protection automatique contre les dépendances. La diversité n’aide que lorsque l’organisation peut exploiter, sécuriser et expliquer le système qui en résulte.

L’avertissement d’InformationWeek mis en avant via Google News renvoie à une décision concrète. Les entreprises peuvent continuer à ajouter des services d’IA partout où ils semblent les plus performants, ou elles peuvent définir les frontières d’intégration qui protègent leurs opérations futures.

Avant d’approuver un fournisseur supplémentaire, les dirigeants devraient poser une question directe : ce service crée-t-il suffisamment de valeur mesurable pour justifier une nouvelle surface de contrôle permanente ? Si la réponse demeure incertaine, la prochaine intégration devrait attendre.