Pas d’IA fiable sans fondation data : par où commencer, du siège aux filiales.

Le scénario est connu. Une direction lance un projet d’IA sur un cas d’usage prometteur. Le prototype fonctionne sur un échantillon soigneusement préparé. Puis vient la mise à l’échelle, et avec elle les données réelles : des référentiels clients en doublon entre le siège et les filiales, des articles codés différemment d’un pays à l’autre, des hiérarchies analytiques qui ont changé trois fois sans que personne ne documente pourquoi. Le modèle ne se trompe pas ; il apprend fidèlement le désordre qu’on lui donne. Et le projet s’arrête là où s’arrêtait déjà la confiance dans les chiffres.

La fondation data, ce que le mot recouvre.

Le terme est devenu si courant qu’il finit par ne plus rien désigner. Pour nous, une fondation data tient en trois couches, indissociables.

Le modèle de données. Une définition partagée des objets qui comptent : le client, le produit, le fournisseur, le site, le centre de coût. Non pas leur structure technique, mais leur signification métier : qu’est-ce qu’un client actif, à partir de quand une commande est-elle une vente, quelle hiérarchie de produits fait foi pour le reporting du groupe. Tant que ces questions ont plusieurs réponses selon qui les pose, aucun outil ne les réconciliera.

La gouvernance. Des propriétaires nommés pour chaque référentiel, des règles de création et de modification, des contrôles de qualité qui remontent aux responsables et non à une boîte aux lettres anonyme. La gouvernance n’est pas un comité de plus ; c’est la réponse à une question simple : quand une donnée est fausse, qui la corrige, et qui décide de ce qui est juste ?

La plateforme. Seulement ensuite vient l’outillage : là où la donnée est consolidée, historisée, exposée à l’analyse et aux modèles. C’est la couche la plus visible et, paradoxalement, la moins décisive. Une bonne plateforme sur un mauvais modèle produit de beaux tableaux de bord faux.

Business Data Cloud, Datasphere, SAC : une architecture, pas un catalogue.

L’écosystème SAP offre aujourd’hui une chaîne cohérente pour cette fondation. SAP Datasphere joue le rôle de couche sémantique et d’intégration : c’est là que le modèle de données prend forme, que les sources SAP et non SAP se réconcilient, et que les définitions métier deviennent des objets réutilisables. SAP Analytics Cloud porte l’analyse, la planification et la restitution. Business Data Cloud, plus récent, vise à réunir ces briques autour de produits de données préparés et à ouvrir la voie aux cas d’usage d’IA sur des données gouvernées.

Notre position est nuancée. Ces outils sont bons, et leur intégration au cœur S/4HANA est un avantage réel : la sémantique des données de gestion arrive avec elles, au lieu d’être reconstruite à la main. Mais aucun outil ne remplace le travail de définition. Nous avons vu des plateformes déployées en quelques mois qui restaient vides de sens parce que personne n’avait tranché ce qu’était un client. Et nous avons vu des groupes dont l’essentiel de la valeur venait d’un travail de modèle et de gouvernance mené avant même de choisir la plateforme. Le bon ordre est celui-là : définir, gouverner, puis outiller. L’inverse coûte cher et déçoit.

Une plateforme data se choisit en dernier. Ce qui la remplit, le modèle et la gouvernance, se décide en premier, et se décide au niveau de la direction.

Le tableau de bord est la dernière étape.

C’est la conviction la plus contre-intuitive, et celle que nous défendons le plus fermement. Les projets data commencent presque toujours par la restitution : une direction veut « son » tableau de bord, et le projet se construit à rebours pour le remplir. Le résultat est un tableau de bord qui affiche des chiffres que personne ne peut expliquer, contesté dès la première réunion où deux directions apportent deux versions du même indicateur.

Un tableau de bord n’est pas un projet ; c’est le résultat visible d’une fondation invisible. Quand le modèle est partagé, quand la gouvernance est en place, quand la plateforme expose des données réconciliées, le tableau de bord devient presque trivial à produire, et, surtout, il est cru. La même règle s’applique à l’IA : un agent qui recommande un réapprovisionnement à partir d’un stock que trois systèmes évaluent différemment ne recommande rien. Il propage une incohérence avec assurance.

Cela ne signifie pas qu’il faille attendre des années avant de montrer quoi que ce soit. Cela signifie que le premier livrable visible d’un programme data doit être un périmètre étroit, entièrement fiable, plutôt qu’un périmètre large et approximatif. Un indicateur juste, expliqué, dont la direction se sert vraiment, vaut plus qu’un mur d’écrans.

Du siège aux filiales : le vrai terrain de la gouvernance.

Pour les groupes marocains et africains, la question de la fondation data prend une forme particulière. Le siège veut une vision consolidée ; chaque filiale a ses systèmes, ses codifications, ses obligations locales, parfois sa monnaie et sa langue de travail. La tentation est de tout uniformiser par décret, ou de renoncer et de consolider à la main dans des tableurs. Les deux échouent.

• Un modèle commun, avec des extensions locales explicites. Le groupe définit le noyau, les objets et les hiérarchies qui doivent être comparables partout. Chaque filiale conserve ce qui lui est propre, dans des attributs identifiés comme tels, et non dans des détournements de champs.
• Une gouvernance fédérée. Des propriétaires de données au siège pour le noyau, dans les filiales pour le local, et une instance d’arbitrage qui tranche les conflits de définition. Sans arbitre, les définitions divergent à nouveau en quelques mois.
• Un déploiement par vagues, filiale après filiale, en commençant par celle où la donnée est la plus mûre et la direction la plus engagée. Le premier succès sert de modèle et de preuve aux suivantes.
• Le respect du droit local sur les données personnelles, pays par pays, intégré au modèle dès le départ : quelles données peuvent être consolidées, sous quelle forme, et lesquelles doivent rester dans leur pays.

C’est un travail qui se mène depuis la région, avec des équipes qui connaissent les systèmes des filiales et les contraintes de chaque pays. C’est aussi celui qui rend possible tout ce qui vient ensuite : la consolidation fiable, la planification, et les cas d’usage d’IA que nous décrivons dans notre point de vue sur l’IA d’entreprise dans l’écosystème SAP. Le Centre d’excellence IA de Casablanca commence d’ailleurs presque toujours par là : quand la donnée n’est pas prête, nous le disons, et nous commençons par elle.

Ce qu’il faut retenir

Une IA nourrie de données incohérentes produit des résultats convaincants et faux. La fondation data précède tout cas d’usage.

L’ordre

Définir le modèle de données, mettre en place la gouvernance, puis outiller avec Datasphere, SAP Analytics Cloud et Business Data Cloud. Jamais l’inverse.

Le tableau de bord

Dernière étape, pas point de départ. Un périmètre étroit et entièrement fiable vaut plus qu’un mur d’écrans approximatifs.

Les filiales

Noyau commun et extensions locales explicites, gouvernance fédérée avec un arbitre, déploiement par vagues, droit local respecté pays par pays.

Pour aller plus loin : notre offre Data & Analytics, le Centre d’excellence IA qui s’appuie sur cette fondation, et notre approche, du cadrage à la réalisation.