Gouvernance de l'IA dans SAP : conformité, sécurité, responsabilité

La gouvernance de l'IA dans SAP couvre chaque fonction d'IA qui tourne dans S/4HANA, SuccessFactors, Ariba, Concur ou sur SAP BTP. Pour chacune, vous devez savoir qui répond de ses décisions, quelles données elle utilise, comment elle est journalisée et quand elle est revue. Le calendrier réglementaire a bougé en 2026 : les obligations de l'AI Act européen pour les systèmes à haut risque autonomes, comme l'IA utilisée en recrutement, s'appliquent désormais à partir du 2 décembre 2027. Les obligations de transparence pour les contenus générés par l'IA s'appliquent déjà. Ce guide s'adresse aux DSI, aux responsables conformité et aux responsables de programmes SAP. Il explique où apparaissent d'abord les failles de gouvernance, ce qui a changé en 2026 et quelles règles s'appliquent, puis propose un registre que vous pouvez lancer cette semaine. Commencez par désigner un responsable par fonction d'IA.

Commencez par une question simple : quand un modèle livre un résultat, qui en répond ? Si la réponse n'est pas claire, vous avez une faille de gouvernance.

Les environnements SAP sont encombrés : S/4HANA au cœur, un CRM dans le cloud, des briques d'analytique greffées, des systèmes historiques que personne ne veut toucher. Un ingénieur peut déployer un modèle en quelques minutes. Mesurer son effet sur le recrutement, le crédit ou la planification de la chaîne d'approvisionnement peut prendre des semaines.

Les données compliquent les choses. La paie, les commandes d'achat, les stocks et les notations de fournisseurs arrivent dans des formats différents, sous la responsabilité de gestionnaires différents. Une équipe masque les identifiants personnels ; une autre les laisse exposés. Avant qu'un modèle ne tourne, décidez quelles données il peut utiliser, qui approuve les changements et combien de temps les enregistrements sont conservés. Écrivez-le, revoyez-le et faites-le appliquer.

J'ai vu un déploiement où la prévision des stocks fonctionnait presque trop bien. Les commandes étaient passées avant la demande, ce qui paraissait efficace sur le tableau de bord. Puis la finance a appelé. La trésorerie avait fléchi, et personne ne savait qui avait le dernier mot sur le comportement du modèle. La logique était enfouie. C'est là que la gouvernance devient concrète, et non une diapositive dans une présentation.

Les schémas que je retrouve sans cesse :

Finance. L'IA dans S/4HANA Finance aide au traitement des factures, à la prévision de trésorerie et à la détection d'anomalies. Elle est utile jusqu'au jour où elle ne l'est plus : un paiement légitime bloqué, un paiement douteux approuvé, une prévision construite sur des données périmées. La solution : une piste d'audit sur chaque décision influencée par l'IA et une personne nommément désignée qui la contrôle.

Achats. L'IA recommande des fournisseurs, signale des risques et examine des contrats. Si les données d'achats historiques portent un biais, par exemple des fournisseurs privilégiés pour des raisons que personne ne voit, le modèle le reproduit. Quelqu'un doit revoir les présélections plutôt que de les accepter telles quelles.

RH. L'IA dans SuccessFactors peut aider à présélectionner des candidats et à analyser l'engagement. Entraînée sur des données de recrutement déjà orientées vers certains profils, elle continue de les favoriser. Testez les biais avant le déploiement, puis après chaque réentraînement.

Production. Les modèles de maintenance prédictive et d'ordonnancement se dégradent quand une usine est reconfigurée. Suivez la précision dans le temps et planifiez le réentraînement. N'attendez pas un arrêt de ligne pour remarquer la dérive.

L'IA dans les applications cloud de SAP arrive le plus souvent en silence : rapprochement de factures dans Ariba, validations dans Concur, scoring des leads dans le CRM. Elle travaille en arrière-plan, et c'est ce qui fait son attrait. C'est aussi ce qui rend la supervision plus difficile.

Je me souviens d'un client qui utilisait l'intelligence embarquée de SAP Ariba. Le système s'est mis à signaler automatiquement des fournisseurs en double. C'était utile, mais personne n'avait compris que ces signalements étaient parfois déclenchés par des noms incohérents dans les données de base. Aucune mauvaise intention, simplement des saisies qui ne correspondaient pas. Les achats n'avaient aucun processus pour valider les alertes, ce qui a provoqué des retards et de la confusion. La solution : une étape de validation des alertes et une convention de nommage cohérente dans les données de base fournisseurs.

SAP BTP. BTP permet aux équipes de construire et de déployer leur propre IA sur l'ensemble du parc SAP. J'ai vu un modèle approuver de mauvais fournisseurs parce qu'il avait été entraîné sur des données d'achats incomplètes. Le problème de données précédait le problème d'IA, et nettoyer les données d'entrée l'a réglé plus vite que de réajuster le modèle.

SAP Concur. L'IA des notes de frais repère les doublons et les infractions à la politique. Elle déclenche aussi de fausses alertes de fraude sur des demandes légitimes, et quand les collaborateurs passent du temps à contester les rejets, le gain de productivité disparaît. Gardez une revue humaine pour les cas limites et mettez les règles à jour chaque fois que la politique de frais change.

Les dates d'application de l'AI Act pour les systèmes à haut risque ont bougé. Le Digital Omnibus sur l'IA, règlement (UE) 2026/1744, est entré en vigueur le 27 juillet 2026. Les obligations pour les systèmes à haut risque autonomes relevant de l'annexe III, qui incluent l'IA utilisée pour le recrutement et la gestion des travailleurs ainsi que pour les contrôles de solvabilité des personnes physiques, s'appliquent désormais à partir du 2 décembre 2027. L'IA à haut risque intégrée dans des produits réglementés suit le 2 août 2028. Les pratiques interdites et la maîtrise de l'IA s'appliquent depuis février 2025, et les obligations de transparence de l'article 50 pour les contenus générés par l'IA depuis le 2 août 2026. Le report est un répit, pas une dispense. L'évaluation de la conformité et la documentation technique sont un travail lent.

1. 2025Pratiques interdites et maîtrise de l'IADepuis février 2025
2. 2026Digital Omnibus en vigueur27 juillet, règlement (UE) 2026/1744
3. 2026Obligations de transparence pour les contenus générés par l'IA2 août, article 50
4. 2027Systèmes à haut risque autonomes (annexe III)2 décembre. Recrutement, gestion des travailleurs, contrôles de solvabilité des personnes physiques
5. 2028IA à haut risque intégrée dans des produits réglementés2 août

Source: Règlement (UE) 2026/1744, Digital Omnibus sur l'IA

La journalisation de Joule dépend d'un choix que vous avez peut-être déjà fait. Les journaux de conversation Joule enregistrent l'utilisateur, l'horodatage, la conversation, les prompts et les réponses. Ils n'existent que si le stockage a été activé lors de l'onboarding de Joule. La durée de conservation par défaut documentée par SAP pour ces journaux est de 365 jours, et vous pouvez demander une autre durée. Vérifiez le paramètre et si la conservation couvre votre cycle d'audit.

SAP a restreint les agents d'IA sur ses API. La politique d'API de SAP (version 4.2026a) restreint l'utilisation des API SAP avec des systèmes d'IA semi-autonomes ou génératifs qui planifient, sélectionnent ou exécutent des séquences d'appels d'API. Cet usage n'est autorisé que via des architectures et des voies approuvées par SAP. Si un agent ou un copilote tiers appelle directement S/4HANA, c'est désormais une question contractuelle autant qu'une question de sécurité. Inventoriez ces intégrations.

Les contrôles BTP existent, mais c'est à vous de les configurer. Le generative AI hub de SAP propose le masquage des données, le filtrage du contenu en entrée et en sortie, le grounding, un registre de prompts et la journalisation d'audit. Ce sont des contrôles, pas un programme de gouvernance. Une journalisation activée sans politique de conservation disparaît avant qu'une revue trimestrielle ait pu la lire.

Si un éditeur ne peut pas produire la documentation technique d'usage à haut risque d'une fonction d'IA, cette fonction ne peut pas rester dans un usage à haut risque. L'échéance a bougé. L'exigence de documentation, non.

Elles s'appliquent aux organisations qui font tourner de l'IA dans SAP, quel que soit l'endroit où SAP héberge le logiciel.

Réglementation	Ce qu'elle exige en pratique
AI Act de l'UE	Obligations fondées sur le risque. Les usages à haut risque (recrutement et gestion des travailleurs, solvabilité des personnes physiques et autres cas de l'annexe III) exigent gestion des risques, documentation, journalisation, supervision humaine et évaluation de la conformité à partir du 2 décembre 2027. Les obligations de transparence s'appliquent déjà
RGPD	Base légale et minimisation des données. Pour les décisions fondées exclusivement sur un traitement automatisé produisant des effets juridiques ou similaires, garanties de l'article 22, dont l'intervention humaine et des informations utiles sur la logique sous-jacente
ISO/IEC 42001:2023	Un système de management de l'IA auditable : rôles, processus de gestion des risques, contrôles et amélioration continue
Cadres nationaux	Les pays du Golfe, Singapour et d'autres publient des principes éthiques et des cadres de gouvernance de l'IA. Passez en revue chaque année ceux des pays où vous opérez

La classification à haut risque compte tout particulièrement pour SAP. L'IA de SuccessFactors qui influence le recrutement, la promotion ou le licenciement entre dans le champ. Les contrôles de solvabilité de clients professionnels dans S/4HANA n'y entrent en général pas, parce que la catégorie de l'annexe III couvre la solvabilité des personnes physiques. Classez chaque fonction plutôt que de le supposer.

Le point de départ pratique est un registre. Une ligne par fonction d'IA, renseignée.

Colonne	Ce qu'il faut consigner
Fonction d'IA	Par exemple, le rapprochement de candidats dans SuccessFactors ou la détection de fournisseurs en double dans Ariba
Système et responsable	L'application, et une personne responsable nommément désignée
Catégorie AI Act	Interdite, haut risque (annexe III), transparence uniquement ou minimale
Données utilisées	Sources, données personnelles, masquage appliqué
Supervision humaine	Qui revoit quelles sorties, et quand cette personne peut passer outre
Journalisation et conservation	Où les décisions sont journalisées et pour combien de temps
Cadence de revue	Trimestrielle pour les fonctions à fort impact, semestrielle pour les autres
Dernière revue	Date et résultat

1. Désignez un responsable par système d'IA avant le go-live. Une personne, pas un comité. Tous les autres jouent un rôle d'appui.
2. Tenez une piste d'audit sur les décisions influencées par l'IA. Pour l'approbation de factures, la sélection de fournisseurs ou le classement de candidats, consignez les données utilisées, le résultat et le moment où une personne l'a revu.
3. Planifiez des revues de modèles. Les modèles se dégradent à mesure que les données changent. Un rythme trimestriel est un bon début pour les systèmes critiques. N'attendez pas la plainte d'un utilisateur pour découvrir trois mois de mauvaises réponses.
4. Mettez d'abord en place la gouvernance des données, puis reliez-y la gouvernance de l'IA. Les règles d'accès, les normes de qualité et le masquage doivent exister avant que la gouvernance de l'IA puisse fonctionner. Les équipes qui construisent les deux en même temps finissent souvent sans l'une ni l'autre.
5. Ne confondez pas gouvernance et documentation. Des politiques sur SharePoint ne sont pas de la gouvernance. La gouvernance change la manière dont les décisions se prennent : qui revoit, qui escalade et qui peut suspendre un modèle.

La réglementation continue de bouger. Les changements de l'AI Act en 2026 montrent à quelle vitesse les dates se déplacent. Désignez une personne chargée de suivre les évolutions juridiques et de les traduire chaque année en exigences propres à SAP.

La confidentialité entre modules. SAP contient la paie, les transactions clients et les dossiers des salariés. La sécurité par rôles de SAP ne s'applique pas automatiquement aux données d'entrée des modèles d'IA. Vérifiez-le explicitement.

Biais dans les données d'entraînement. Si un modèle SuccessFactors a appris sur cinq ans de recrutements biaisés, il reproduira le biais. Examinez les résultats par groupe avant le déploiement, pas seulement la précision.

Systèmes historiques dans le pipeline. Quand l'IA sur BTP puise dans un ERP historique ou une plateforme tierce, la qualité des données du système le plus faible devient votre limite. Cartographiez les sources avant la mise en production du modèle. Mon cadre de gestion des risques de l'IA couvre les étapes d'évaluation, et mon guide du cadre de gouvernance de l'IA couvre le modèle opérationnel dans son ensemble.

Qu'est-ce que la gouvernance de l'IA dans les projets SAP ?

Ce sont les responsables, les politiques et les contrôles qui font fonctionner les fonctions d'IA de SAP de manière responsable, transparente et licite. Elle couvre les données que les modèles peuvent utiliser, la façon dont les fonctions sont approuvées et déployées, la manière dont les décisions sont journalisées et revues, et qui peut suspendre un modèle. Elle s'applique à S/4HANA, SuccessFactors, Ariba, Concur et à tout ce que vous construisez sur SAP BTP.

Quand les règles de l'AI Act sur le haut risque s'appliquent-elles aux systèmes SAP ?

Après le Digital Omnibus (règlement (UE) 2026/1744), les obligations pour les systèmes à haut risque autonomes de l'annexe III s'appliquent à partir du 2 décembre 2027. L'IA à haut risque intégrée dans des produits réglementés suit à partir du 2 août 2028. Les pratiques interdites et la maîtrise de l'IA s'appliquent depuis février 2025, et les obligations de transparence pour les contenus générés par l'IA depuis août 2026. Pour SAP, le domaine à haut risque le plus courant est l'IA utilisée dans le recrutement et les décisions sur les effectifs.

Qui est responsable de la gouvernance de l'IA dans les projets SAP ?

Un groupe transverse : la conformité suit la réglementation, l'IT et la sécurité gèrent les accès et la journalisation, les équipes data sont responsables de la qualité des données d'entraînement, les responsables de processus métier valident les sorties et le juridique examine la responsabilité. La décision la plus importante est de désigner un responsable unique par système d'IA. Quand quelque chose tourne mal à 2 h du matin, vous devez savoir qui reçoit l'appel.

Joule conserve-t-il une piste d'audit ?

Les journaux de conversation Joule peuvent enregistrer l'utilisateur, l'horodatage, la conversation ainsi que les prompts et les réponses, mais seulement si le stockage des journaux a été activé lors de l'onboarding. SAP documente une durée de conservation par défaut de 365 jours pour les clients qui ont activé l'option, et une autre durée peut être demandée. Les changements de configuration touchant à la sécurité dans Joule Studio sont envoyés au service SAP Audit Log sur BTP. Vérifiez le paramètre de votre tenant plutôt que de le supposer.

Comment traiter les biais des modèles d'IA dans SAP SuccessFactors ?

Examinez sur quoi le modèle a été entraîné. Si les données de recrutement historiques ont défavorisé certains groupes, le modèle le fera aussi. Testez les résultats par groupe avant le go-live, surveillez les taux de sélection après, et réentraînez à intervalles réguliers à mesure que les données sur vos effectifs évoluent. Si des candidats qualifiés issus d'un même parcours sont systématiquement écartés, voyez-y un signal, pas une coïncidence.

À quelle fréquence faut-il revoir les modèles d'IA dans SAP ?

Chaque trimestre pour les systèmes à fort impact comme les approbations financières, les décisions RH ou la sélection de fournisseurs, et chaque semestre pour les outils à enjeux plus faibles. Déclenchez une revue supplémentaire dès qu'une source de données, une intégration ou un processus métier change, car chacun de ces éléments peut modifier le comportement d'un modèle sans changement de code.