L’article 4 de l’AI Act n’a pas disparu. Il a changé de nature. Depuis le 27 juillet 2026, une entreprise qui utilise des systèmes d’IA doit prendre des mesures pour soutenir la maîtrise de l’IA de ses équipes, sans avoir à garantir un niveau donné pour chaque personne. Pour une équipe Salesforce, la question n’est donc plus « avons-nous atteint le bon niveau ? » mais « quelles mesures avons-nous prises, pour quels rôles, et pouvons-nous le montrer ? ».
Que demandait l’article 4 jusqu’en juillet 2026 ?
Dans sa version de 2024, applicable depuis le 2 février 2025, l’article 4 du règlement (UE) 2024/1689 demandait aux fournisseurs et aux déployeurs de systèmes d’IA de prendre des mesures pour garantir, dans toute la mesure du possible, un niveau suffisant de maîtrise de l’IA à leur personnel et aux personnes qui utilisent ces systèmes pour leur compte. Le texte tenait compte des connaissances techniques, de l’expérience, de la formation et du contexte d’utilisation.
« Un niveau suffisant » posait une question que personne ne savait trancher : suffisant pour qui, et mesuré comment ? La réponse la plus facile était un module en ligne identique pour tout le monde. Simple à prouver, et peu utile au commercial qui voit une fonction générative lui proposer un e-mail dans Salesforce.
Qu’est-ce qui a changé avec le règlement 2026/1744 ?
Le règlement (UE) 2026/1744, le volet IA de l’omnibus numérique, a été publié au Journal officiel le 24 juillet 2026 et s’applique depuis le 27 juillet. Il réécrit l’article 4 sur trois points.
- L’obligation reste à la charge des fournisseurs et des déployeurs : ils prennent des mesures pour soutenir le développement de la maîtrise de l’IA de leur personnel et des personnes qui agissent pour leur compte.
- Le texte précise qu’aucun niveau de maîtrise n’est à garantir pour une personne donnée. C’est une obligation de moyens, et non plus de résultat.
- La Commission et les États membres soutiennent ces efforts, en particulier ceux des PME, et la Commission publie des exemples pratiques.
La proposition de la Commission, en novembre 2025, allait plus loin et faisait porter l’effort sur les pouvoirs publics. Le texte adopté maintient une obligation pour les entreprises. Le même règlement repousse au 2 décembre 2027 les obligations des systèmes à haut risque de l’annexe III, mais il ne change pas la date d’application de l’article 4, qui reste le 2 février 2025.
Une entreprise qui active l’IA dans Salesforce est-elle concernée ?
Oui, dans la plupart des cas. Le règlement appelle déployeur l’organisation qui utilise un système d’IA sous sa propre autorité. Une entreprise qui active des fonctions génératives dans son org (une synthèse de Case, un e-mail proposé, un template Prompt Builder, un agent) les utilise sous son autorité, même si Salesforce les fournit. La mesure vise les personnes qui s’en servent et celles qui les configurent : utilisateurs, administrateurs, et les managers qui décident de ce qui en sort.
Le risque concret se trouve dans l’écart entre ce que l’org fait et ce que les équipes croient qu’elle fait. Un utilisateur qui prend une synthèse générée pour un fait vérifié, ou un admin qui élargit les données lues par un template sans regarder qui verra la sortie : ce sont les situations que la mesure doit prévenir.
Quelles mesures tiennent, et pour qui ?
Une mesure utile part des fonctions réellement activées dans l’org et des rôles qui les touchent. Un module générique ne dit rien de ce que fait votre template de synthèse, ni de qui peut le modifier.
Pour les utilisateurs, une heure sur leurs propres écrans vaut mieux qu’une journée de théorie. Ils voient la fonction dans leur org, avec leurs enregistrements, et retiennent trois gestes : relire, corriger, signaler. Côté admin, la mesure reprend la discipline de sécurité déjà enseignée dans ADX201, appliquée à l’IA : savoir avec quels droits une fonction lit ses données, et où sa sortie atterrit. Pour les managers, elle porte sur la décision : qui valide qu’un texte généré peut partir chez un client, et sur quels signaux on étend la fonction à une autre équipe.
Que garder comme trace ?
Une obligation de moyens se montre par des traces. Une page par fonction suffit, tenue par le propriétaire admin : la fonction et sa version de configuration, les rôles qui l’utilisent, la formation reçue par chaque rôle et sa date, la date de la prochaine revue.
La revue suit un calendrier que l’org connaît déjà. Salesforce publie trois releases par an, et une fonction générative peut changer de comportement d’une release à l’autre sans que personne ait touché à la configuration. Chaque release est l’occasion de vérifier que la formation décrit encore ce que fait l’org. Le modèle opérationnel qui dit qui possède chaque changement après la mise en production est le bon endroit pour inscrire ce rendez-vous.
Par où commencer ce trimestre ?
C’est la logique des deux journées « L’IA dans Salesforce » que je propose sur demande, l’une pour les commerciaux, l’autre pour les administrateurs : elles partent de l’org du client, pas d’un support générique. Si vous en êtes à la première étape, la liste des fonctions activées suffit pour une première conversation.