Maturité cloud : les fondations à vérifier avant l’IA

Adopter le cloud ne signifie pas encore savoir l’utiliser à grande échelle. Une entreprise peut avoir déplacé ses applications vers un fournisseur cloud tout en conservant des données cloisonnées, des systèmes anciens, des coûts mal suivis et des responsabilités de sécurité floues. L’intelligence artificielle rend ces écarts plus visibles, car elle dépend de la qualité des données, de la capacité de calcul et de la solidité des opérations.

La maturité cloud désigne donc moins le nombre de services utilisés que la capacité d’une organisation à relier son infrastructure, ses données, ses équipes et ses objectifs métier. Une entreprise mature sait pourquoi elle utilise le cloud, où exécuter chaque charge de travail, comment contrôler les risques et quels résultats elle attend.

L’adoption du cloud ne mesure pas la maturité

Le passage au cloud est souvent suivi avec des indicateurs de migration comme le nombre d’applications déplacées, la réduction des serveurs sur site ou l’ouverture de nouveaux environnements. Ces données décrivent une étape technique, pas la valeur créée. Une application transférée sans modification peut fonctionner dans le cloud sans profiter de l’automatisation, de l’élasticité ou des outils d’observabilité disponibles.

Un modèle de maturité peut distinguer trois situations. Au stade initial, l’entreprise commence à consommer des services cloud et cherche encore ses méthodes, ses compétences et ses règles. À un niveau intermédiaire, plusieurs charges de travail fonctionnent dans le cloud, les équipes ont acquis de l’expérience et les premiers processus de gouvernance apparaissent. À un niveau avancé, le cloud est intégré au fonctionnement global de l’entreprise : les architectures, les données, la sécurité et les décisions d’investissement sont suivies dans un même cadre.

Ces catégories ne constituent pas un classement universel. Une entreprise peut être avancée sur l’automatisation et rester fragile sur la qualité des données. Elle peut aussi disposer d’une sécurité bien organisée tout en conservant des applications difficiles à faire évoluer. L’évaluation doit donc examiner plusieurs capacités au lieu de produire une note unique.

Pourquoi l’IA révèle les faiblesses du système d’information

Une IA générative ou un agent logiciel ne demande pas seulement davantage de puissance de calcul. Il lui faut des données accessibles, correctement décrites et suffisamment fiables. Lorsque les informations sont réparties entre un ERP ancien, des fichiers locaux et des interfaces conçues au cas par cas, le problème ne se règle pas avec un meilleur modèle ou une consigne plus précise.

Le rapport de NTT DATA intitulé Cloud-led innovation in the era of AI: The new rules for driving value with cloud s’appuie sur une enquête menée auprès de plus de 2 300 décideurs dans 33 pays et 13 secteurs. Il estime que 14 % des organisations interrogées ont atteint le niveau de maturité cloud le plus élevé étudié. Ce résultat repose sur les déclarations de décideurs et ne remplace pas un audit indépendant des systèmes.

La même enquête indique qu’environ la moitié des organisations interrogées considèrent leurs applications ou leurs plateformes de données anciennes comme un frein à l’innovation. Elle relève aussi des difficultés de contrôle des coûts. Ces problèmes se renforcent : une architecture vieillissante complique la modernisation, tandis que des usages d’IA variables rendent la facture cloud plus difficile à anticiper.

Les quatre questions à poser avant de déployer une IA

Quel résultat métier est recherché?

La première question ne concerne ni le fournisseur cloud ni le modèle d’IA. Elle porte sur le résultat attendu : réduire le délai de traitement d’un dossier, détecter plus tôt une anomalie, améliorer une prévision ou automatiser une tâche répétitive. Ce point permet de mesurer la valeur du projet et d’éviter de confondre une démonstration technique avec un usage utile.

Les données sont-elles utilisables?

Cartographiez les données nécessaires au cas d’usage. Cette étape vérifie leur localisation, leur format, leur qualité, leur fraîcheur et les liens entre les différents systèmes. Une donnée disponible dans le cloud mais impossible à relier à une autre source reste peu exploitable pour une IA qui doit produire une réponse contextualisée.

L’architecture peut-elle absorber la charge?

Les charges d’IA peuvent être intensives, variables et sensibles au temps de réponse. Le choix des services et leur répartition entre infrastructure sur site, cloud public, cloud privé ou plusieurs fournisseurs dépendent de la performance, de la résilience, de la conformité, du contrôle des données et du coût total. L’objectif est de déterminer où chaque charge de travail peut fonctionner avec un niveau de contrôle acceptable.

Qui contrôle les accès et les résultats?

Une IA connectée à plusieurs applications introduit de nouveaux chemins d’accès aux données et aux processus. Définissez les rôles avant la mise en production : équipe responsable du modèle, propriétaire des données, responsable de la sécurité et personne habilitée à interrompre un traitement. Cette organisation devient plus importante lorsqu’un agent peut agir automatiquement dans plusieurs outils.

Moderniser ne consiste pas à tout reconstruire

Le transfert direct, souvent appelé lift and shiftpeut convenir à une application stable dont les contraintes sont connues. Il permet de changer l’emplacement de l’infrastructure sans réécrire immédiatement le logiciel. En revanche, cette méthode ne suffit pas lorsqu’une application doit exploiter des données en temps réel, s’intégrer à plusieurs services ou ajuster automatiquement ses ressources.

La modernisation doit donc être sélective. Une organisation peut conserver certaines applications dans leur forme actuelle, réécrire les composants qui bloquent les nouveaux usages et remplacer les interfaces les plus fragiles. La bonne séquence dépend de la criticité de l’application, de la qualité de ses données, du coût de sa maintenance et de sa contribution au cas d’usage d’IA.

Cette logique évite deux erreurs : croire qu’une migration rapide suffit à créer de la valeur, ou lancer une refonte générale avant d’avoir défini un besoin précis. Un projet pilote peut tester une architecture, mais il doit aussi révéler les travaux nécessaires sur les données, la sécurité et l’exploitation.

Le cloud devient une décision d’architecture et de gouvernance

Le choix de l’emplacement d’une charge de travail ne relève plus uniquement de l’équipe infrastructure. Il concerne aussi la direction métier, la sécurité, le juridique et les responsables des données. Les questions de résilience, de localisation, de conformité et de dépendance à un fournisseur peuvent modifier le choix technique initial.

La souveraineté du cloud ajoute une contrainte lorsque certaines données ou certains traitements doivent rester sous un contrôle renforcé. Une architecture hybride ou l’utilisation de plusieurs fournisseurs peut répondre à des exigences précises, mais ne résout pas automatiquement les problèmes de gouvernance.

La maturité consiste alors à documenter les arbitrages. Pour chaque charge de travail, l’entreprise doit savoir pourquoi elle a choisi un environnement, quelles données y circulent, quelles dépendances existent et comment elle réagirait à une panne ou à une évolution réglementaire.

Automatiser l’exploitation sans perdre la visibilité

À mesure que les environnements se multiplient, la gestion manuelle devient difficile. Une plateforme peut standardiser les déploiements, intégrer les règles de sécurité, suivre la consommation et automatiser certaines décisions. Elle n’a d’intérêt que si les règles sont explicites et si les équipes peuvent comprendre les actions déclenchées.

Le suivi des coûts doit être relié aux usages. Une facture globale ne permet pas de savoir quelle équipe, quelle application ou quel projet consomme les ressources. Des budgets par service, des alertes et des indicateurs de performance aident à repérer les dérives sans interrompre une charge de travail utile.

La sécurité repose également sur une responsabilité partagée. Le fournisseur protège l’infrastructure qu’il opère, tandis que le client reste responsable de la configuration de ses services, de ses identités, de ses données et de ses applications. Une certification du fournisseur ne dispense donc pas de vérifier les droits, les journaux, les sauvegardes et les règles d’accès.

Une évaluation utile doit rester régulière

La maturité cloud n’est pas un statut définitif. Une nouvelle application, un changement de fournisseur, une réglementation ou l’arrivée d’agents plus autonomes peuvent modifier les risques et les besoins. Une évaluation régulière permet de revoir les priorités au lieu de poursuivre une feuille de route devenue inadaptée.

Cette évaluation peut couvrir trois volets : la capacité générale de l’organisation à utiliser le cloud, le niveau d’automatisation et de contrôle de la sécurité, puis l’aptitude à concevoir des applications réellement adaptées au cloud. Une entreprise n’a pas besoin d’atteindre le niveau maximal sur chaque axe. Elle doit atteindre le niveau nécessaire pour ses données, ses contraintes et ses objectifs.

Le point de départ le plus concret consiste à choisir un cas d’usage d’IA, à cartographier ses dépendances et à comparer l’état actuel au niveau requis. Si les données sont cloisonnées, si les coûts sont invisibles ou si les responsabilités sont incertaines, le prochain investissement doit porter sur ces fondations. L’IA pourra ensuite être déployée dans un environnement capable de l’exploiter, de la surveiller et de l’arrêter lorsque ses résultats ne sont pas fiables.