Les fondations doivent être posées

Les automatisations ne fonctionnent souvent que ponctuellement, les prévisions sont utilisées avec prudence et la confiance dans les décisions basées sur les données est fragile. Le problème réside rarement dans l'IA elle-même. Il est plus profond - dans l'architecture. Dans ma pratique à l'interface de l'architecture de données et de la gestion d'entreprise, j'ai appris une chose : la surface brillante des nouvelles technologies n'a aucune valeur si la salle des machines en dessous ne fonctionne pas.

Stabilité opérationnelle

Si l'on regarde de plus près les transformations S/4, on reconnaît un modèle connu. La priorité est donnée à ce qui sécurise l'exploitation : des processus stables, des versions propres, une mise en service la moins perturbée possible. L'analytique est considéré comme complexe, potentiellement risqué ou comme un sujet à traiter dans une phase ultérieure. Il faut d'abord passer à l'action, puis voir plus loin.

Après la mise en service, on constate toutefois le coût de cette décision. Les données historiques manquent ou ne sont plus utilisables que de manière limitée. Les chiffres clés ont été redéfinis, souvent sans logique de transition compréhensible. Les rapports fournissent d'autres valeurs qu'auparavant, sans que rien n'ait changé sur le plan opérationnel. C'est précisément là que commence le problème de l'IA. Les modèles ont besoin de séries temporelles stables, de logiques cohérentes et d'états de données reproductibles. L'IA ne devient alors pas une force productive, mais une expérience. L'erreur de raisonnement réside dans l'approche : l'architecture opérationnelle et l'architecture analytique sont pensées séparément. L'IA est considérée comme un ajout à un système fini. Les décisions architecturales sont prises sans tenir compte des conséquences analytiques.

L'IA naît entre les systèmes

Les applications d'IA pertinentes ne sont presque jamais créées dans un seul système. Elles naissent entre les systèmes. Les données transactionnelles de S/4 fournissent le contexte fonctionnel. Les données de capteurs et d'événements apportent une dynamique temporelle. Les données externes complètent les informations sur le marché ou la chaîne d'approvisionnement. Ces données parlent des langues différentes. La référence temporelle, la granularité et la signification diffèrent - elles ont souvent évolué au fil du temps et ne sont connues que de manière implicite. Sans un découplage clair, des dépendances fragiles apparaissent. Sur le plan technique, cela se traduit par l'absence d'interfaces ou par l'absence de versions, ce que l'on appelle les contrats de données.

Un contrat de données est plus qu'un document technique ; c'est une poignée de main numérique entre l'informatique opérationnelle et les utilisateurs de données. Il définit de manière contraignante la qualité des données et la sémantique qui seront fournies par l'ERP. Si ce „contrat“ fait défaut, la chaîne se brise à chaque petite mise à jour du système. Un projet de maintenance pratique l'illustre bien : l'objectif était de prévoir les pannes de machines. Après une version S/4, des logiques de matériel ont été modifiées dans l'ERP. Pour les métiers, tout restait identique, mais pour le modèle, les prévisions dérivaient sans qu'aucune erreur ne soit visible. La cause était banale : une rupture d'intégration parce qu'une modification importante pour le métier n'avait été ni versionnée ni communiquée.

Avec l'IA générative, ce modèle s'accentue. Les modèles basés sur le langage sont particulièrement dépendants d'un contexte cohérent et d'informations historisées. Si les données changent de signification à chaque nouvelle version, les résultats restent superficiels. Sans une sémantique stable - c'est-à-dire des significations clairement définies des indicateurs et des références temporelles - l'IA générative devient une simple assistance textuelle, mais pas un outil de décision.

Le thème du temps réel est souvent mis en avant. Mais pour l'IA apprenante, un autre élément est décisif : la persistance. Les modèles qui réagissent en premier lieu aux flux actuels perdent les modèles historiques et les effets saisonniers. Le temps réel contrôle le comportement, mais la persistance crée la compréhension nécessaire à une véritable intelligence économique.
L'organisation bat la technique : qui possède les données ? L'organisation est un facteur souvent sous-estimé. La responsabilité des données n'est souvent pas claire ou n'est répartie que par projet. L'informatique optimise le fonctionnement du système, les coûts et la disponibilité. Lorsque les chiffres ne correspondent plus, la recherche du coupable commence. La gouvernance existe souvent sur le papier, mais n'est pas appliquée au quotidien. À cela s'ajoute un paysage de compétences fragmenté : les experts BW comprennent les modèles de données, les conseillers fonctionnels connaissent les processus et les data scientists travaillent en fonction des modèles - souvent sans connaissance approfondie de la sémantique ERP. Chacun est bon dans son domaine, mais peu de choses émergent entre les deux.

Le véritable changement commence par l'appropriation technique. La responsabilité des données ne doit pas être un ticket informatique. Il faut des responsables dans les domaines spécialisés qui répondent non seulement du processus (par exemple la réception des marchandises), mais aussi de la qualité des données et de leur importance analytique. Ce n'est que lorsque le business reconnaît que les données sont une valeur patrimoniale que la modernisation technologique devient durable.

Trois leviers stratégiques pour 2026

Des opportunités concrètes peuvent être déduites de ces observations :

1. l'analytique comme critère de conception : Les exigences analytiques doivent faire partie de l'architecture dès le début, au même titre que la stabilité opérationnelle.

2. sémantique explicite : Les contrats de données et les interfaces versionnées ne sont pas une théorie, mais le mode d'emploi pour que les données conservent leur signification à travers les versions de S/4-Hana.

3. responsabilité durable : La souveraineté des données nécessite une appropriation professionnelle claire et durable.

Si l'on continue à optimiser l'architecture en premier lieu pour l'exploitation opérationnelle, on continuera à voir des démonstrations impressionnantes d'IA - mais on n'obtiendra que peu d'effets au quotidien. Celui qui nettoie maintenant les fondations gagne une entreprise qui n'est pas seulement prête pour l'IA, mais qui peut enfin contrôler sa propre réalité avec précision. (Source : Stefan Maxones)