L'IA que vous utilisez vous engage : qui répond de quoi ? L'AI Act ne concerne pas que les juristes | Les signaux du changement

Description

Depuis le 2 août 2026, l'AI Act est entré en vigueur : les autorités peuvent enquêter et sanctionner. Cet épisode pose une grille de lecture pour les directions générales, juridiques et opérationnelles : la responsabilité suit l'usage que vous faites d'un système d'IA, pas l'outil que vous avez acheté. On y sépare le fournisseur du déployeur, on démonte le piège de l'article 25, et on chiffre l'enjeu. À la fin, un geste concret : cartographier ses usages pour savoir, pour chacun, de quoi l'on répond.

Nos derniers articles : https://www.spentia.com/?utm_source=podcast&utm_medium=show-notes&utm_campaign=signaux&utm_content=ep10

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Speaker #0
Bienvenue dans ce nouvel épisode des Signes du Changement. Une loi est, d'ordinaire, un sujet que l'on confie à la direction juridique. Celle dont on parle aujourd'hui fait exception, et c'est tout l'objet de cet épisode. Car l'EI Acte Européen attache une responsabilité aux décisions que prennent les métiers, chaque jour. Choisir un outil pour trier des candidatures, résumer un dossier ou automatiser une opération. Ces gestes ordinaires engagent désormais l'entreprise. C'est ce qui rend le sujet utile bien au-delà des juristes, même s'il a l'air technique. Alors posons les bases. L'EI Act, c'est le premier cadre européen qui encadre l'intelligence artificielle en tant que telle dans tous les secteurs confondus. Sa logique tient en une idée simple. Il ne juge pas la technologie dans l'absolu, il regarde ce qu'on en fait. Il classe les usages selon leur niveau de risque, puis répartit les responsabilités entre celui qui conçoit un système et celui qui l'emploie. Depuis le 2 août 2026, ce cadre est passé en exécution. Les obligations de transparence et la supervision des modèles généraux s'appliquent et les autorités peuvent sanctionner. Le volet « au risque » , celui qui porte les obligations les plus exigeantes, a été repoussé par le Digital Omnibus à décembre 2027. Ce report laisse du temps pour se préparer. La date de décembre 2027 est probablement ferme. Une dernière raison de tendre l'oreille, quelle que soit votre fonction. Une direction juridique ne cadre que les usages qu'on lui signale. Si les métiers avancent sans le dire, l'exposition grandit sans que personne ne la voit. Partager ce sujet dans toute l'entreprise, c'est se donner les moyens de regarder le risque en face. Aujourd'hui, une question qui vaut déjà pour toute l'entreprise. Pour l'intelligence artificielle que vous utilisez, qui répond de quoi ?
Speaker #1
Posons un cadre de réflexion pour commencer. Imaginons une scène qui en ce moment même se déroule probablement dans une multitude de grandes organisations. Un collaborateur, disons au sein d'une direction financière, a besoin de synthétiser un rapport d'audit particulièrement complexe.
Speaker #2
Oui, un cas d'usage très classique.
Speaker #1
Voilà. Et pour gagner du temps, il copie l'intégralité du document et le colle dans l'interface d'un outil d'intelligence artificielle générative standard disponible en ligne. La synthèse produite est impeccable. Sauf que peu de temps après... La direction juridique réalise que des données stratégiques ont été ingérées par le modèle de cet outil pour son propre apprentissage.
Speaker #0
Et là, c'est la panique ?
Speaker #1
Exactement, c'est la panique. Le premier réflexe de l'entreprise, c'est de se tourner vers l'éditeur de l'outil pour exiger les comptes. Et là, surprise. Les conditions d'utilisation stipulent clairement que l'éditeur fournit un simple moteur algorithmique et que la responsabilité de la nature des données injectées ainsi que l'usage final incombe entièrement au client.
Speaker #2
Ce qui laisse l'entreprise complètement seule.
Speaker #1
C'est ça. Soudainement seul, pleinement imputable d'une faille de sécurité majeure et sans aucun recours. Si la machine capte déjà ce que les outils classiques ne mesurent pas, la vraie question qui se pose à voix haute, c'est qui est comptable de ce qu'elle produit ?
Speaker #2
Et ce scénario, en fait, il illustre parfaitement la fracture abyssale entre la perception de la technologie par les directions opérationnelles et la réalité de l'encadrement légal. Il y a un biais, un biais vraiment persistant, qui consiste à penser que l'acquisition d'une solution auprès d'un acteur reconnu du marché ça transfère automatiquement la charge de la conformité.
Speaker #1
On achète un outil réputé conforme, donc on se croit couvert sur le plan légal.
Speaker #2
C'est exactement cette illusion. Or, la législation qui se met en place actuellement renverse complètement cette logique.
Speaker #1
Et c'est précisément l'objet de notre exploration d'aujourd'hui. Pour déconstruire ce mécanisme, on a croisé plusieurs sources de référence. Le texte définitif du règlement européen sur l'intelligence artificielle, l'EA Act, Les premières lignes directrices d'exécution de la Commission européenne, ainsi que des notes d'analyse produites par de grands cabinets d'avocats. L'objectif, pour les directions générales, juridiques et opérationnelles qui s'informent sur le sujet, c'est de fournir une grille de lecture claire.
Speaker #2
Une grille indispensable, oui.
Speaker #1
Car la thèse centrale, on va la filer tout du long, la responsabilité juridique suit strictement l'usage final qui est fait du système et non la simple acquisition technique.
Speaker #2
Tout à fait. Et le passage de la théorie à la pratique, disons que ce n'est plus une perspective lointaine. La période de transition, d'observation en quelque sorte, touche à sa fin.
Speaker #1
Avant de comprendre qui est responsable de quoi, il faut comprendre pourquoi cette question quitte le domaine de la théorie pour devenir un risque d'exposition immédiat.
Speaker #2
Parce que le calendrier réglementaire impose une bascule opérationnelle stricte. C'est le 2 août 2026 qui marque ce pivot pour l'ensemble des acteurs.
Speaker #1
D'accord, décortiquons un peu cela. Pourquoi le 2 août... 2026 change la donne de manière si abrupte. L'écosystème a l'habitude des réglementations européennes, il y a toujours des phases d'adaptation.
Speaker #2
C'est vrai, et le marché se trouvait justement dans une phase de mise en conformité préparatoire. Certaines obligations existaient déjà, mais elles ciblaient principalement les concepteurs de modèles généraux. La bascule, c'est qu'à partir de cette date, l'arsenal coercitif global entre en action.
Speaker #1
C'est-à-dire ?
Speaker #2
C'est-à-dire que les autorités de contrôle nationales et européennes activent leur plein pouvoir d'enquête, les perquisitions numériques, l'exécution et in fine les sanctions. L'AI Act n'est plus un sujet de veille juridique, c'est un cadre exécutoire.
Speaker #1
Donc le droit souple devient un droit dur ?
Speaker #2
Absolument ! Et parallèlement, c'est l'entrée en vigueur des obligations de transparence applicables à toutes les entreprises. C'est l'obligation légale de signaler qu'on interagit avec une machine, par exemple face à un agent conversationnel.
Speaker #1
Pour bien matérialiser ce basculement, c'est comme le code de la route. Les panneaux de limitation de vitesse étaient déjà posés l'année dernière, on pouvait lire le code. Mais depuis ce fameux mois d'août, les radars sont allumés et les amendes partent.
Speaker #2
C'est une bonne analogie.
Speaker #1
Sauf que, et c'est là que la comparaison atteint ses limites, un algorithme n'a pas de plaque d'immatriculation. Comment une autorité de contrôle procède-t-elle pour identifier Dix. qui sanctionner sur cette nouvelle route usine ?
Speaker #2
En première intention, le régulateur ne cherche pas à inspecter la complexité du code source. Il s'accue plutôt sur une méthode de classification structurelle. Toute l'approche européenne repose sur une gradation des risques.
Speaker #1
C'est l'approche par les risques dont on entend souvent parler ?
Speaker #2
Voilà. Il y a les pratiques inacceptables, les usages à haut risque, ceux à risque limité et le risque minimal. Mais pour déterminer la cible, le droit impose une distinction fondamentale, presque philosophique, entre ce qu'il nomme un modèle et ce qu'il qualifie de système.
Speaker #1
Un modèle contre un système. Ça semble être une simple nuance sémantique au premier abord. En quoi cela fait-il voler en éclats l'illusion de l'outil clé en main ?
Speaker #2
Parce que c'est ce qui définit la qualification juridique. Un modèle d'intelligence artificielle, c'est une brique algorithmique générale. Il n'a aucune finalité prédéfinie.
Speaker #1
C'est juste un moteur, en somme.
Speaker #2
C'est ça, un moteur avec des capacités statistiques. Un système d'intelligence artificielle, en revanche, c'est l'assemblage de ce modèle avec une interface, des règles métiers et, élément central, une destination d'usage prévue.
Speaker #1
Ce qui retient l'attention ici, c'est que la qualification juridique est dictée par la finalité, pas par le moteur technologique lui-même.
Speaker #2
Exactement. Concrètement, si on utilise un même modèle génératif pour synthétiser des comptes rendus internes de réunion, ça relève du risque minimal.
Speaker #1
D'accord.
Speaker #2
Mais si on intègre cette... exacte même technologie dans un processus RH pour trier les candidatures, l'ensemble bascule dans la catégorie à haut risque, le domaine de l'emploi étant sensible.
Speaker #1
C'est une bascule majeure. Ça signifie qu'un éditeur logiciel peut fournir une technologie parfaite et conforme, mais la classification de risque finale lui échappe totalement dès lors que l'entreprise cliente décide de l'appliquer à un domaine critique.
Speaker #0
Faisons une pause pour poser les idées. La première, c'est la distinction entre un modèle et un système. Un modèle, c'est le moteur, la capacité générale sans destination. Un système, c'est ce moteur une fois installé dans un usage précis, avec une interface et une finalité. Et c'est cette finalité qui détermine le risque. Le même modèle qui résume vos comptes rendus reste anodin. Branché sur une décision qui touche des personnes, comme un recrutement, Il change de catégorie. Pourquoi cela vous concerne, quel que soit votre métier ? La conformité ne se juge pas à l'achat. Elle se joue au moment où vous décidez à quoi servira l'outil. Ce moment-là relève de vous, quel que soit le fournisseur. Reste alors une question, celle de la suite. Une fois le système en service, qui porte quelle responsabilité ? Celui qui l'a conçu ou celui qui l'a mis en œuvre ? Le droit sépare ces deux rôles. Et le second pèse plus lourd qu'on ne l'imagine.
Speaker #2
C'est toute la subtilité. Et c'est pour ça que le droit européen, de manière très logique, scinde les obligations entre celui qui conçoit la technologie et celui qui décide de son application en entreprise.
Speaker #1
Donc on passe au partage des responsabilités. Puisque c'est l'usage qui définit le risque, comment le texte sépartit lui ses rôles ?
Speaker #2
Il institue deux rôles majeurs, le fournisseur et le déployeur.
Speaker #1
Commençons par le fournisseur. Quelle est sa part de responsabilité ?
Speaker #2
Le fournisseur, c'est l'entité qui développe et met sur le marché. Il porte la charge de la conformité de conception.
Speaker #1
C'est-à-dire la gouvernance des données d'entraînement ?
Speaker #2
Oui, la gouvernance des données, la rédaction de la documentation technique et bien sûr, l'obtention du marquage de conformité européen. Mais une fois l'outil commercialisé, le rôle principal bascule vers le déployeur.
Speaker #1
Ce terme est intéressant parce que dans le langage courant de l'entreprise, On dit plutôt le client ou l'utilisateur.
Speaker #2
Oui, mais le terme juridique de déployeur est lourd de sens. Le déployeur désigne l'organisation qui utilise le système dans le cadre de son activité. Et le fardeau légal qu'il porte est bien plus lourd qu'il ne l'imagine.
Speaker #1
Concrètement, qu'est-ce que cela signifie pour une direction des achats ou une direction informatique ? On n'est plus de simples acheteurs de licences logicielles.
Speaker #2
Loin de là. En tant que déployeur, l'entreprise a des devoirs de surveillance active. Ce rôle implique par exemple d'attribuer la supervision humaine à du personnel spécifiquement formé.
Speaker #1
Arrêtons-nous là-dessus un instant, parce que cette supervision humaine soulève une question opérationnelle. Si on déploie un algorithme pour traiter un grand volume d'opérations logistiques, un humain ne peut matériellement pas repasser derrière chaque décision.
Speaker #2
Bien sûr ! Et le législateur ne demande pas de dupliquer le travail de la machine. Ce sera absurde !
Speaker #1
Alors, que signifie réellement superviser AIA ?
Speaker #2
La supervision implique une conception organisationnelle. Il faut que les personnes chargées de cette supervision aient la compétence de détecter les anomalies et surtout l'autorité hiérarchique pour ignorer ou renverser une décision proposée par l'algorithme.
Speaker #1
Ce n'est donc pas une vérification à la tâche, c'est la mise en place d'un filet de sécurité, un vrai droit de veto institutionnel ?
Speaker #2
C'est l'esprit de la loi. Et le déployeur doit aussi s'assurer de l'alphabétisation en IAD de ses collaborateurs.
Speaker #1
TA
Speaker #2
Par la documentation, il faut pouvoir prouver l'existence de formations spécifiques et l'intégration de ses compétences dans les processus. De plus, le déployeur doit contrôler la pertinence des données réelles injectées, les inputs, et conserver les journaux d'événements, les fameux logs.
Speaker #1
C'est un changement de paradigme complet. L'entreprise devient un superviseur d'opérations algorithmiques. Mais si ce rôle de déployeur est déjà contraignant, il existe un mécanisme juridique redoutable, une sorte de piège. C'est l'article 25.
Speaker #2
Ah oui, l'article 25 de l'AI Act. C'est le principe de requalification automatique.
Speaker #1
C'est ici que l'analyse devient particulièrement intéressante. Comment une entreprise peut-elle perdre son statut de déployeur pour devenir concepteur, responsable de tout
Speaker #2
TA ? Ce mécanisme s'active si l'entreprise modifie substantiellement un système tiers ou si elle décide de l'exploiter sous sa propre marque pour un usage classé à haut risque. Du jour au lendemain, elle perd son statut de simple déployeur.
Speaker #1
Et elle devient légalement le fournisseur.
Speaker #2
Exactement ! Elle hérite soudainement de toutes les obligations initiales de conception. Les évaluations de conformité complexes, l'enregistrement européen, les systèmes de gestion des risques.
Speaker #1
Pour faire une comparaison, c'est l'équivalent d'acheter un véhicule utilitaire standard, on est d'accord, et de modifier soi-même le moteur et le châssis dans ses ateliers pour transporter des matières dangereuses.
Speaker #2
C'est une excellente image.
Speaker #1
Osier de la loi, on n'est plus seulement le conducteur du véhicule, on est devenu le constructeur automobile. Et on doit fournir toutes les certifications de sécurité.
Speaker #2
C'est tout à fait ça. Par la force de ses propres choix d'adaptation technique, l'entreprise cliente devient le fabricant devant la loi.
Speaker #1
Mais qu'appelle-t-on une modification substantielle ? Si un collaborateur rédige une instruction complexe dans l'interface de l'outil à un prompt très élaboré, est-ce que ça déclenche ce piège de l'article 25 ?
Speaker #2
Non, l'utilisation courante via l'interface, même poussée, ne modifie pas l'architecture profonde. Mais si une équipe technique prend un modèle ouvert... et procède à un réentraînement spécifique de l'algorithme avec des bases des données internes pour l'intégrer dans un processus de décision critique, là, la ligne est franchie.
Speaker #1
L'outil a été structurellement altéré.
Speaker #2
Et le fardeau documentaire qui s'abat alors sur l'organisation est colossal.
Speaker #0
Reprenons le fil. Car ce qui vient d'être dit dépresse les responsabilités. Par défaut, lorsque vous utilisez un système d'IA, vous êtes le déployeur. Vous en êtes responsable. Le fournisseur, lui, répond de sa conception. Mais si vous transformez le système en profondeur, en réentraînant par exemple un modèle sur vos propres données, ou si vous le diffusez sous votre marque pour un usage sensible, la loi vous considère alors comme son concepteur. C'est l'article 25. Et vous héritez, d'un coup, des obligations les plus lourdes. Évaluation de conformité, documentation technique, enregistrement. Ce qu'il faut en retenir en comité de direction. Ce basculement ne n'est pas d'une décision juridique. Il naît de choix techniques ordinaires, pris parfois sans en mesurer la portée. D'où l'intérêt de savoir, pour chaque projet, de quel côté de la ligne on se trouve avant de la franchir. Et si l'enjeu semble encore abstrait, la suite va le rendre concret. Car ce risque a désormais un prix, et il ne se compte plus dans le budget informatique.
Speaker #1
Ce basculement des responsabilités prend toute sa dimension quand on observe le levier coercitif. Le risque n'est pas seulement théorique, il y a une interdiction financière derrière.
Speaker #2
Une réalité très dissuasive. Le régulateur a mis en place une grille de sanctions très stricte.
Speaker #1
Comment se structurent ces pénalités ?
Speaker #2
Elles obéissent à la grille de 7%, 3%, 1%. Ce sont des plafonds basés sur le chiffre d'affaires annuel mondial de l'entreprise.
Speaker #1
Des pourcentages du chiffre d'affaires mondial, ce n'est pas anodin.
Speaker #2
Pas du tout, et le plafond maximal est réservé aux pratiques formellement interdites, comme le scoring social à grande échelle ou la reconnaissance des émotions sur le lieu de travail.
Speaker #1
Et à combien s'élève ce plafond maximal ?
Speaker #2
Pour ces interdictions absolues, l'amende peut atteindre jusqu'à 7% du CA mondial ou 35 M&E. L'autorité retenant systématiquement le montant le plus élevé des deux.
Speaker #1
C'est un recadrage stratégique majeur. Ces montantes déplacent le sujet de la sphère purement technologique vers la sphère de la gouvernance d'entreprise. Une non-conformité n'impacte pas le budget informatique. C'est un risque existentiel qui relève de la responsabilité du conseil d'administration.
Speaker #2
Et des directions financières, absolument.
Speaker #1
Face à des risques de cette envergure, le constat est posé. Quelle est la démarche immédiate pour les directions opérationnelles ? Le premier réflexe serait peut-être de bloquer techniquement l'accès à ces outils.
Speaker #2
Le verrouillage, on le sait, mène souvent à l'informatique de l'ombre, ce qui aggrave les failles. La première action n'est pas de rédiger un mode d'emploi technique, restrictif, c'est d'établir une cartographie juridique et fonctionnelle rigoureuse.
Speaker #1
Cartographie ses usages. Mais c'est plus qu'un simple inventaire logiciel.
Speaker #2
Bien plus. L'entreprise doit lister chaque système déployé, bien sûr. Mais surtout, documenter sa destination d'usage précise, déterminer son statut exact. Pour chaque cas, agit-on en tant que déployeur ou ont-on franchi la ligne vers une requalification en fournisseur ?
Speaker #1
Le centre de gravité se déplace vraiment. Pour être en règle, l'organisation ne doit plus seulement auditer le code informatique qu'elle achète. Elle doit auditer les tâches confiées à la machine par ses propres collaborateurs.
Speaker #2
C'est l'objectif. Cette rigueur permet ensuite de réviser les contrats d'achat. On s'assure d'interdire contractuellement les usages non autorisés en interne et on garantit que l'éditeur fournira bien les documentations techniques nécessaires.
Speaker #1
Mais si l'on relie cela au contexte global, établir cette cartographie, c'est une posture purement interne.
Speaker #2
Oui, mais c'est le socle de toute la défense de l'entreprise. Parce que l'EIAI Acte n'opère pas en vase clos. Il interagit de manière complexe avec d'autres textes fondamentaux, comme le RGPD ou la nouvelle directive sur la responsabilité des produits défectueux.
Speaker #1
C'est vrai, la directive a été mise à jour pour inclure les logiciels.
Speaker #2
Et c'est là que le piège se referme aux civils. Si une entreprise est incapable de prouver qu'elle a respecté ses obligations de déployeur, par exemple en négligeant de conserver les journaux d'événements, cette faille dans les high-act devient une preuve automatique de négligence devant un juge.
Speaker #1
C'est une présomption de défaut. La boucle est bouclée. La ligne de démarcation entre la conception technologique et l'application opérationnelle est claire. On sait désormais de quoi on répond le long de cette chaîne. Reste à le prouver quand l'autorité viendra frapper à la porte.
Speaker #0
Une dernière idée pour refermer. Cartographier vos usages, c'est transformer une échéance réglementaire en une décision qui vous appartient. Merci pour votre écoute sur ce sujet technique et rendez-vous sur spencia.com pour nos derniers articles.

About Les signaux du changement

Découvrez Les Signaux du Changement, un tout nouveau podcast qui explore les stratégies de transformation des entreprises et leur impact critique sur le capital humain.

Dans un monde où 50 % des cadres préfèrent désormais se confier à un algorithme plutôt qu'à leur manager, comment réinventer le lien au travail ? De la fracture des compétences aux frictions opérationnelles invisibles, nous décodons les signaux faibles qui redessinent les organisations.

Une expérience inédite : Pour incarner cette mutation, ce podcast est lui-même une exploration technologique, entièrement réalisé avec l'intelligence artificielle. Une plongée immersive pour comprendre comment naviguer entre automatisation et authenticité humaine à l'horizon 2026.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

About Les signaux du changement

Découvrez Les Signaux du Changement, un tout nouveau podcast qui explore les stratégies de transformation des entreprises et leur impact critique sur le capital humain.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Description

Nos derniers articles : https://www.spentia.com/?utm_source=podcast&utm_medium=show-notes&utm_campaign=signaux&utm_content=ep10

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Speaker #0
Bienvenue dans ce nouvel épisode des Signes du Changement. Une loi est, d'ordinaire, un sujet que l'on confie à la direction juridique. Celle dont on parle aujourd'hui fait exception, et c'est tout l'objet de cet épisode. Car l'EI Acte Européen attache une responsabilité aux décisions que prennent les métiers, chaque jour. Choisir un outil pour trier des candidatures, résumer un dossier ou automatiser une opération. Ces gestes ordinaires engagent désormais l'entreprise. C'est ce qui rend le sujet utile bien au-delà des juristes, même s'il a l'air technique. Alors posons les bases. L'EI Act, c'est le premier cadre européen qui encadre l'intelligence artificielle en tant que telle dans tous les secteurs confondus. Sa logique tient en une idée simple. Il ne juge pas la technologie dans l'absolu, il regarde ce qu'on en fait. Il classe les usages selon leur niveau de risque, puis répartit les responsabilités entre celui qui conçoit un système et celui qui l'emploie. Depuis le 2 août 2026, ce cadre est passé en exécution. Les obligations de transparence et la supervision des modèles généraux s'appliquent et les autorités peuvent sanctionner. Le volet « au risque » , celui qui porte les obligations les plus exigeantes, a été repoussé par le Digital Omnibus à décembre 2027. Ce report laisse du temps pour se préparer. La date de décembre 2027 est probablement ferme. Une dernière raison de tendre l'oreille, quelle que soit votre fonction. Une direction juridique ne cadre que les usages qu'on lui signale. Si les métiers avancent sans le dire, l'exposition grandit sans que personne ne la voit. Partager ce sujet dans toute l'entreprise, c'est se donner les moyens de regarder le risque en face. Aujourd'hui, une question qui vaut déjà pour toute l'entreprise. Pour l'intelligence artificielle que vous utilisez, qui répond de quoi ?
Speaker #1
Posons un cadre de réflexion pour commencer. Imaginons une scène qui en ce moment même se déroule probablement dans une multitude de grandes organisations. Un collaborateur, disons au sein d'une direction financière, a besoin de synthétiser un rapport d'audit particulièrement complexe.
Speaker #2
Oui, un cas d'usage très classique.
Speaker #1
Voilà. Et pour gagner du temps, il copie l'intégralité du document et le colle dans l'interface d'un outil d'intelligence artificielle générative standard disponible en ligne. La synthèse produite est impeccable. Sauf que peu de temps après... La direction juridique réalise que des données stratégiques ont été ingérées par le modèle de cet outil pour son propre apprentissage.
Speaker #0
Et là, c'est la panique ?
Speaker #1
Exactement, c'est la panique. Le premier réflexe de l'entreprise, c'est de se tourner vers l'éditeur de l'outil pour exiger les comptes. Et là, surprise. Les conditions d'utilisation stipulent clairement que l'éditeur fournit un simple moteur algorithmique et que la responsabilité de la nature des données injectées ainsi que l'usage final incombe entièrement au client.
Speaker #2
Ce qui laisse l'entreprise complètement seule.
Speaker #1
C'est ça. Soudainement seul, pleinement imputable d'une faille de sécurité majeure et sans aucun recours. Si la machine capte déjà ce que les outils classiques ne mesurent pas, la vraie question qui se pose à voix haute, c'est qui est comptable de ce qu'elle produit ?
Speaker #2
Et ce scénario, en fait, il illustre parfaitement la fracture abyssale entre la perception de la technologie par les directions opérationnelles et la réalité de l'encadrement légal. Il y a un biais, un biais vraiment persistant, qui consiste à penser que l'acquisition d'une solution auprès d'un acteur reconnu du marché ça transfère automatiquement la charge de la conformité.
Speaker #1
On achète un outil réputé conforme, donc on se croit couvert sur le plan légal.
Speaker #2
C'est exactement cette illusion. Or, la législation qui se met en place actuellement renverse complètement cette logique.
Speaker #1
Et c'est précisément l'objet de notre exploration d'aujourd'hui. Pour déconstruire ce mécanisme, on a croisé plusieurs sources de référence. Le texte définitif du règlement européen sur l'intelligence artificielle, l'EA Act, Les premières lignes directrices d'exécution de la Commission européenne, ainsi que des notes d'analyse produites par de grands cabinets d'avocats. L'objectif, pour les directions générales, juridiques et opérationnelles qui s'informent sur le sujet, c'est de fournir une grille de lecture claire.
Speaker #2
Une grille indispensable, oui.
Speaker #1
Car la thèse centrale, on va la filer tout du long, la responsabilité juridique suit strictement l'usage final qui est fait du système et non la simple acquisition technique.
Speaker #2
Tout à fait. Et le passage de la théorie à la pratique, disons que ce n'est plus une perspective lointaine. La période de transition, d'observation en quelque sorte, touche à sa fin.
Speaker #1
Avant de comprendre qui est responsable de quoi, il faut comprendre pourquoi cette question quitte le domaine de la théorie pour devenir un risque d'exposition immédiat.
Speaker #2
Parce que le calendrier réglementaire impose une bascule opérationnelle stricte. C'est le 2 août 2026 qui marque ce pivot pour l'ensemble des acteurs.
Speaker #1
D'accord, décortiquons un peu cela. Pourquoi le 2 août... 2026 change la donne de manière si abrupte. L'écosystème a l'habitude des réglementations européennes, il y a toujours des phases d'adaptation.
Speaker #2
C'est vrai, et le marché se trouvait justement dans une phase de mise en conformité préparatoire. Certaines obligations existaient déjà, mais elles ciblaient principalement les concepteurs de modèles généraux. La bascule, c'est qu'à partir de cette date, l'arsenal coercitif global entre en action.
Speaker #1
C'est-à-dire ?
Speaker #2
C'est-à-dire que les autorités de contrôle nationales et européennes activent leur plein pouvoir d'enquête, les perquisitions numériques, l'exécution et in fine les sanctions. L'AI Act n'est plus un sujet de veille juridique, c'est un cadre exécutoire.
Speaker #1
Donc le droit souple devient un droit dur ?
Speaker #2
Absolument ! Et parallèlement, c'est l'entrée en vigueur des obligations de transparence applicables à toutes les entreprises. C'est l'obligation légale de signaler qu'on interagit avec une machine, par exemple face à un agent conversationnel.
Speaker #1
Pour bien matérialiser ce basculement, c'est comme le code de la route. Les panneaux de limitation de vitesse étaient déjà posés l'année dernière, on pouvait lire le code. Mais depuis ce fameux mois d'août, les radars sont allumés et les amendes partent.
Speaker #2
C'est une bonne analogie.
Speaker #1
Sauf que, et c'est là que la comparaison atteint ses limites, un algorithme n'a pas de plaque d'immatriculation. Comment une autorité de contrôle procède-t-elle pour identifier Dix. qui sanctionner sur cette nouvelle route usine ?
Speaker #2
En première intention, le régulateur ne cherche pas à inspecter la complexité du code source. Il s'accue plutôt sur une méthode de classification structurelle. Toute l'approche européenne repose sur une gradation des risques.
Speaker #1
C'est l'approche par les risques dont on entend souvent parler ?
Speaker #2
Voilà. Il y a les pratiques inacceptables, les usages à haut risque, ceux à risque limité et le risque minimal. Mais pour déterminer la cible, le droit impose une distinction fondamentale, presque philosophique, entre ce qu'il nomme un modèle et ce qu'il qualifie de système.
Speaker #1
Un modèle contre un système. Ça semble être une simple nuance sémantique au premier abord. En quoi cela fait-il voler en éclats l'illusion de l'outil clé en main ?
Speaker #2
Parce que c'est ce qui définit la qualification juridique. Un modèle d'intelligence artificielle, c'est une brique algorithmique générale. Il n'a aucune finalité prédéfinie.
Speaker #1
C'est juste un moteur, en somme.
Speaker #2
C'est ça, un moteur avec des capacités statistiques. Un système d'intelligence artificielle, en revanche, c'est l'assemblage de ce modèle avec une interface, des règles métiers et, élément central, une destination d'usage prévue.
Speaker #1
Ce qui retient l'attention ici, c'est que la qualification juridique est dictée par la finalité, pas par le moteur technologique lui-même.
Speaker #2
Exactement. Concrètement, si on utilise un même modèle génératif pour synthétiser des comptes rendus internes de réunion, ça relève du risque minimal.
Speaker #1
D'accord.
Speaker #2
Mais si on intègre cette... exacte même technologie dans un processus RH pour trier les candidatures, l'ensemble bascule dans la catégorie à haut risque, le domaine de l'emploi étant sensible.
Speaker #1
C'est une bascule majeure. Ça signifie qu'un éditeur logiciel peut fournir une technologie parfaite et conforme, mais la classification de risque finale lui échappe totalement dès lors que l'entreprise cliente décide de l'appliquer à un domaine critique.
Speaker #0
Faisons une pause pour poser les idées. La première, c'est la distinction entre un modèle et un système. Un modèle, c'est le moteur, la capacité générale sans destination. Un système, c'est ce moteur une fois installé dans un usage précis, avec une interface et une finalité. Et c'est cette finalité qui détermine le risque. Le même modèle qui résume vos comptes rendus reste anodin. Branché sur une décision qui touche des personnes, comme un recrutement, Il change de catégorie. Pourquoi cela vous concerne, quel que soit votre métier ? La conformité ne se juge pas à l'achat. Elle se joue au moment où vous décidez à quoi servira l'outil. Ce moment-là relève de vous, quel que soit le fournisseur. Reste alors une question, celle de la suite. Une fois le système en service, qui porte quelle responsabilité ? Celui qui l'a conçu ou celui qui l'a mis en œuvre ? Le droit sépare ces deux rôles. Et le second pèse plus lourd qu'on ne l'imagine.
Speaker #2
C'est toute la subtilité. Et c'est pour ça que le droit européen, de manière très logique, scinde les obligations entre celui qui conçoit la technologie et celui qui décide de son application en entreprise.
Speaker #1
Donc on passe au partage des responsabilités. Puisque c'est l'usage qui définit le risque, comment le texte sépartit lui ses rôles ?
Speaker #2
Il institue deux rôles majeurs, le fournisseur et le déployeur.
Speaker #1
Commençons par le fournisseur. Quelle est sa part de responsabilité ?
Speaker #2
Le fournisseur, c'est l'entité qui développe et met sur le marché. Il porte la charge de la conformité de conception.
Speaker #1
C'est-à-dire la gouvernance des données d'entraînement ?
Speaker #2
Oui, la gouvernance des données, la rédaction de la documentation technique et bien sûr, l'obtention du marquage de conformité européen. Mais une fois l'outil commercialisé, le rôle principal bascule vers le déployeur.
Speaker #1
Ce terme est intéressant parce que dans le langage courant de l'entreprise, On dit plutôt le client ou l'utilisateur.
Speaker #2
Oui, mais le terme juridique de déployeur est lourd de sens. Le déployeur désigne l'organisation qui utilise le système dans le cadre de son activité. Et le fardeau légal qu'il porte est bien plus lourd qu'il ne l'imagine.
Speaker #1
Concrètement, qu'est-ce que cela signifie pour une direction des achats ou une direction informatique ? On n'est plus de simples acheteurs de licences logicielles.
Speaker #2
Loin de là. En tant que déployeur, l'entreprise a des devoirs de surveillance active. Ce rôle implique par exemple d'attribuer la supervision humaine à du personnel spécifiquement formé.
Speaker #1
Arrêtons-nous là-dessus un instant, parce que cette supervision humaine soulève une question opérationnelle. Si on déploie un algorithme pour traiter un grand volume d'opérations logistiques, un humain ne peut matériellement pas repasser derrière chaque décision.
Speaker #2
Bien sûr ! Et le législateur ne demande pas de dupliquer le travail de la machine. Ce sera absurde !
Speaker #1
Alors, que signifie réellement superviser AIA ?
Speaker #2
La supervision implique une conception organisationnelle. Il faut que les personnes chargées de cette supervision aient la compétence de détecter les anomalies et surtout l'autorité hiérarchique pour ignorer ou renverser une décision proposée par l'algorithme.
Speaker #1
Ce n'est donc pas une vérification à la tâche, c'est la mise en place d'un filet de sécurité, un vrai droit de veto institutionnel ?
Speaker #2
C'est l'esprit de la loi. Et le déployeur doit aussi s'assurer de l'alphabétisation en IAD de ses collaborateurs.
Speaker #1
TA
Speaker #2
Par la documentation, il faut pouvoir prouver l'existence de formations spécifiques et l'intégration de ses compétences dans les processus. De plus, le déployeur doit contrôler la pertinence des données réelles injectées, les inputs, et conserver les journaux d'événements, les fameux logs.
Speaker #1
C'est un changement de paradigme complet. L'entreprise devient un superviseur d'opérations algorithmiques. Mais si ce rôle de déployeur est déjà contraignant, il existe un mécanisme juridique redoutable, une sorte de piège. C'est l'article 25.
Speaker #2
Ah oui, l'article 25 de l'AI Act. C'est le principe de requalification automatique.
Speaker #1
C'est ici que l'analyse devient particulièrement intéressante. Comment une entreprise peut-elle perdre son statut de déployeur pour devenir concepteur, responsable de tout
Speaker #2
TA ? Ce mécanisme s'active si l'entreprise modifie substantiellement un système tiers ou si elle décide de l'exploiter sous sa propre marque pour un usage classé à haut risque. Du jour au lendemain, elle perd son statut de simple déployeur.
Speaker #1
Et elle devient légalement le fournisseur.
Speaker #2
Exactement ! Elle hérite soudainement de toutes les obligations initiales de conception. Les évaluations de conformité complexes, l'enregistrement européen, les systèmes de gestion des risques.
Speaker #1
Pour faire une comparaison, c'est l'équivalent d'acheter un véhicule utilitaire standard, on est d'accord, et de modifier soi-même le moteur et le châssis dans ses ateliers pour transporter des matières dangereuses.
Speaker #2
C'est une excellente image.
Speaker #1
Osier de la loi, on n'est plus seulement le conducteur du véhicule, on est devenu le constructeur automobile. Et on doit fournir toutes les certifications de sécurité.
Speaker #2
C'est tout à fait ça. Par la force de ses propres choix d'adaptation technique, l'entreprise cliente devient le fabricant devant la loi.
Speaker #1
Mais qu'appelle-t-on une modification substantielle ? Si un collaborateur rédige une instruction complexe dans l'interface de l'outil à un prompt très élaboré, est-ce que ça déclenche ce piège de l'article 25 ?
Speaker #2
Non, l'utilisation courante via l'interface, même poussée, ne modifie pas l'architecture profonde. Mais si une équipe technique prend un modèle ouvert... et procède à un réentraînement spécifique de l'algorithme avec des bases des données internes pour l'intégrer dans un processus de décision critique, là, la ligne est franchie.
Speaker #1
L'outil a été structurellement altéré.
Speaker #2
Et le fardeau documentaire qui s'abat alors sur l'organisation est colossal.
Speaker #0
Reprenons le fil. Car ce qui vient d'être dit dépresse les responsabilités. Par défaut, lorsque vous utilisez un système d'IA, vous êtes le déployeur. Vous en êtes responsable. Le fournisseur, lui, répond de sa conception. Mais si vous transformez le système en profondeur, en réentraînant par exemple un modèle sur vos propres données, ou si vous le diffusez sous votre marque pour un usage sensible, la loi vous considère alors comme son concepteur. C'est l'article 25. Et vous héritez, d'un coup, des obligations les plus lourdes. Évaluation de conformité, documentation technique, enregistrement. Ce qu'il faut en retenir en comité de direction. Ce basculement ne n'est pas d'une décision juridique. Il naît de choix techniques ordinaires, pris parfois sans en mesurer la portée. D'où l'intérêt de savoir, pour chaque projet, de quel côté de la ligne on se trouve avant de la franchir. Et si l'enjeu semble encore abstrait, la suite va le rendre concret. Car ce risque a désormais un prix, et il ne se compte plus dans le budget informatique.
Speaker #1
Ce basculement des responsabilités prend toute sa dimension quand on observe le levier coercitif. Le risque n'est pas seulement théorique, il y a une interdiction financière derrière.
Speaker #2
Une réalité très dissuasive. Le régulateur a mis en place une grille de sanctions très stricte.
Speaker #1
Comment se structurent ces pénalités ?
Speaker #2
Elles obéissent à la grille de 7%, 3%, 1%. Ce sont des plafonds basés sur le chiffre d'affaires annuel mondial de l'entreprise.
Speaker #1
Des pourcentages du chiffre d'affaires mondial, ce n'est pas anodin.
Speaker #2
Pas du tout, et le plafond maximal est réservé aux pratiques formellement interdites, comme le scoring social à grande échelle ou la reconnaissance des émotions sur le lieu de travail.
Speaker #1
Et à combien s'élève ce plafond maximal ?
Speaker #2
Pour ces interdictions absolues, l'amende peut atteindre jusqu'à 7% du CA mondial ou 35 M&E. L'autorité retenant systématiquement le montant le plus élevé des deux.
Speaker #1
C'est un recadrage stratégique majeur. Ces montantes déplacent le sujet de la sphère purement technologique vers la sphère de la gouvernance d'entreprise. Une non-conformité n'impacte pas le budget informatique. C'est un risque existentiel qui relève de la responsabilité du conseil d'administration.
Speaker #2
Et des directions financières, absolument.
Speaker #1
Face à des risques de cette envergure, le constat est posé. Quelle est la démarche immédiate pour les directions opérationnelles ? Le premier réflexe serait peut-être de bloquer techniquement l'accès à ces outils.
Speaker #2
Le verrouillage, on le sait, mène souvent à l'informatique de l'ombre, ce qui aggrave les failles. La première action n'est pas de rédiger un mode d'emploi technique, restrictif, c'est d'établir une cartographie juridique et fonctionnelle rigoureuse.
Speaker #1
Cartographie ses usages. Mais c'est plus qu'un simple inventaire logiciel.
Speaker #2
Bien plus. L'entreprise doit lister chaque système déployé, bien sûr. Mais surtout, documenter sa destination d'usage précise, déterminer son statut exact. Pour chaque cas, agit-on en tant que déployeur ou ont-on franchi la ligne vers une requalification en fournisseur ?
Speaker #1
Le centre de gravité se déplace vraiment. Pour être en règle, l'organisation ne doit plus seulement auditer le code informatique qu'elle achète. Elle doit auditer les tâches confiées à la machine par ses propres collaborateurs.
Speaker #2
C'est l'objectif. Cette rigueur permet ensuite de réviser les contrats d'achat. On s'assure d'interdire contractuellement les usages non autorisés en interne et on garantit que l'éditeur fournira bien les documentations techniques nécessaires.
Speaker #1
Mais si l'on relie cela au contexte global, établir cette cartographie, c'est une posture purement interne.
Speaker #2
Oui, mais c'est le socle de toute la défense de l'entreprise. Parce que l'EIAI Acte n'opère pas en vase clos. Il interagit de manière complexe avec d'autres textes fondamentaux, comme le RGPD ou la nouvelle directive sur la responsabilité des produits défectueux.
Speaker #1
C'est vrai, la directive a été mise à jour pour inclure les logiciels.
Speaker #2
Et c'est là que le piège se referme aux civils. Si une entreprise est incapable de prouver qu'elle a respecté ses obligations de déployeur, par exemple en négligeant de conserver les journaux d'événements, cette faille dans les high-act devient une preuve automatique de négligence devant un juge.
Speaker #1
C'est une présomption de défaut. La boucle est bouclée. La ligne de démarcation entre la conception technologique et l'application opérationnelle est claire. On sait désormais de quoi on répond le long de cette chaîne. Reste à le prouver quand l'autorité viendra frapper à la porte.
Speaker #0
Une dernière idée pour refermer. Cartographier vos usages, c'est transformer une échéance réglementaire en une décision qui vous appartient. Merci pour votre écoute sur ce sujet technique et rendez-vous sur spencia.com pour nos derniers articles.

About Les signaux du changement

Découvrez Les Signaux du Changement, un tout nouveau podcast qui explore les stratégies de transformation des entreprises et leur impact critique sur le capital humain.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

About Les signaux du changement

Découvrez Les Signaux du Changement, un tout nouveau podcast qui explore les stratégies de transformation des entreprises et leur impact critique sur le capital humain.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Embed

You may also like

Description

Nos derniers articles : https://www.spentia.com/?utm_source=podcast&utm_medium=show-notes&utm_campaign=signaux&utm_content=ep10

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Speaker #0
Bienvenue dans ce nouvel épisode des Signes du Changement. Une loi est, d'ordinaire, un sujet que l'on confie à la direction juridique. Celle dont on parle aujourd'hui fait exception, et c'est tout l'objet de cet épisode. Car l'EI Acte Européen attache une responsabilité aux décisions que prennent les métiers, chaque jour. Choisir un outil pour trier des candidatures, résumer un dossier ou automatiser une opération. Ces gestes ordinaires engagent désormais l'entreprise. C'est ce qui rend le sujet utile bien au-delà des juristes, même s'il a l'air technique. Alors posons les bases. L'EI Act, c'est le premier cadre européen qui encadre l'intelligence artificielle en tant que telle dans tous les secteurs confondus. Sa logique tient en une idée simple. Il ne juge pas la technologie dans l'absolu, il regarde ce qu'on en fait. Il classe les usages selon leur niveau de risque, puis répartit les responsabilités entre celui qui conçoit un système et celui qui l'emploie. Depuis le 2 août 2026, ce cadre est passé en exécution. Les obligations de transparence et la supervision des modèles généraux s'appliquent et les autorités peuvent sanctionner. Le volet « au risque » , celui qui porte les obligations les plus exigeantes, a été repoussé par le Digital Omnibus à décembre 2027. Ce report laisse du temps pour se préparer. La date de décembre 2027 est probablement ferme. Une dernière raison de tendre l'oreille, quelle que soit votre fonction. Une direction juridique ne cadre que les usages qu'on lui signale. Si les métiers avancent sans le dire, l'exposition grandit sans que personne ne la voit. Partager ce sujet dans toute l'entreprise, c'est se donner les moyens de regarder le risque en face. Aujourd'hui, une question qui vaut déjà pour toute l'entreprise. Pour l'intelligence artificielle que vous utilisez, qui répond de quoi ?
Speaker #1
Posons un cadre de réflexion pour commencer. Imaginons une scène qui en ce moment même se déroule probablement dans une multitude de grandes organisations. Un collaborateur, disons au sein d'une direction financière, a besoin de synthétiser un rapport d'audit particulièrement complexe.
Speaker #2
Oui, un cas d'usage très classique.
Speaker #1
Voilà. Et pour gagner du temps, il copie l'intégralité du document et le colle dans l'interface d'un outil d'intelligence artificielle générative standard disponible en ligne. La synthèse produite est impeccable. Sauf que peu de temps après... La direction juridique réalise que des données stratégiques ont été ingérées par le modèle de cet outil pour son propre apprentissage.
Speaker #0
Et là, c'est la panique ?
Speaker #1
Exactement, c'est la panique. Le premier réflexe de l'entreprise, c'est de se tourner vers l'éditeur de l'outil pour exiger les comptes. Et là, surprise. Les conditions d'utilisation stipulent clairement que l'éditeur fournit un simple moteur algorithmique et que la responsabilité de la nature des données injectées ainsi que l'usage final incombe entièrement au client.
Speaker #2
Ce qui laisse l'entreprise complètement seule.
Speaker #1
C'est ça. Soudainement seul, pleinement imputable d'une faille de sécurité majeure et sans aucun recours. Si la machine capte déjà ce que les outils classiques ne mesurent pas, la vraie question qui se pose à voix haute, c'est qui est comptable de ce qu'elle produit ?
Speaker #2
Et ce scénario, en fait, il illustre parfaitement la fracture abyssale entre la perception de la technologie par les directions opérationnelles et la réalité de l'encadrement légal. Il y a un biais, un biais vraiment persistant, qui consiste à penser que l'acquisition d'une solution auprès d'un acteur reconnu du marché ça transfère automatiquement la charge de la conformité.
Speaker #1
On achète un outil réputé conforme, donc on se croit couvert sur le plan légal.
Speaker #2
C'est exactement cette illusion. Or, la législation qui se met en place actuellement renverse complètement cette logique.
Speaker #1
Et c'est précisément l'objet de notre exploration d'aujourd'hui. Pour déconstruire ce mécanisme, on a croisé plusieurs sources de référence. Le texte définitif du règlement européen sur l'intelligence artificielle, l'EA Act, Les premières lignes directrices d'exécution de la Commission européenne, ainsi que des notes d'analyse produites par de grands cabinets d'avocats. L'objectif, pour les directions générales, juridiques et opérationnelles qui s'informent sur le sujet, c'est de fournir une grille de lecture claire.
Speaker #2
Une grille indispensable, oui.
Speaker #1
Car la thèse centrale, on va la filer tout du long, la responsabilité juridique suit strictement l'usage final qui est fait du système et non la simple acquisition technique.
Speaker #2
Tout à fait. Et le passage de la théorie à la pratique, disons que ce n'est plus une perspective lointaine. La période de transition, d'observation en quelque sorte, touche à sa fin.
Speaker #1
Avant de comprendre qui est responsable de quoi, il faut comprendre pourquoi cette question quitte le domaine de la théorie pour devenir un risque d'exposition immédiat.
Speaker #2
Parce que le calendrier réglementaire impose une bascule opérationnelle stricte. C'est le 2 août 2026 qui marque ce pivot pour l'ensemble des acteurs.
Speaker #1
D'accord, décortiquons un peu cela. Pourquoi le 2 août... 2026 change la donne de manière si abrupte. L'écosystème a l'habitude des réglementations européennes, il y a toujours des phases d'adaptation.
Speaker #2
C'est vrai, et le marché se trouvait justement dans une phase de mise en conformité préparatoire. Certaines obligations existaient déjà, mais elles ciblaient principalement les concepteurs de modèles généraux. La bascule, c'est qu'à partir de cette date, l'arsenal coercitif global entre en action.
Speaker #1
C'est-à-dire ?
Speaker #2
C'est-à-dire que les autorités de contrôle nationales et européennes activent leur plein pouvoir d'enquête, les perquisitions numériques, l'exécution et in fine les sanctions. L'AI Act n'est plus un sujet de veille juridique, c'est un cadre exécutoire.
Speaker #1
Donc le droit souple devient un droit dur ?
Speaker #2
Absolument ! Et parallèlement, c'est l'entrée en vigueur des obligations de transparence applicables à toutes les entreprises. C'est l'obligation légale de signaler qu'on interagit avec une machine, par exemple face à un agent conversationnel.
Speaker #1
Pour bien matérialiser ce basculement, c'est comme le code de la route. Les panneaux de limitation de vitesse étaient déjà posés l'année dernière, on pouvait lire le code. Mais depuis ce fameux mois d'août, les radars sont allumés et les amendes partent.
Speaker #2
C'est une bonne analogie.
Speaker #1
Sauf que, et c'est là que la comparaison atteint ses limites, un algorithme n'a pas de plaque d'immatriculation. Comment une autorité de contrôle procède-t-elle pour identifier Dix. qui sanctionner sur cette nouvelle route usine ?
Speaker #2
En première intention, le régulateur ne cherche pas à inspecter la complexité du code source. Il s'accue plutôt sur une méthode de classification structurelle. Toute l'approche européenne repose sur une gradation des risques.
Speaker #1
C'est l'approche par les risques dont on entend souvent parler ?
Speaker #2
Voilà. Il y a les pratiques inacceptables, les usages à haut risque, ceux à risque limité et le risque minimal. Mais pour déterminer la cible, le droit impose une distinction fondamentale, presque philosophique, entre ce qu'il nomme un modèle et ce qu'il qualifie de système.
Speaker #1
Un modèle contre un système. Ça semble être une simple nuance sémantique au premier abord. En quoi cela fait-il voler en éclats l'illusion de l'outil clé en main ?
Speaker #2
Parce que c'est ce qui définit la qualification juridique. Un modèle d'intelligence artificielle, c'est une brique algorithmique générale. Il n'a aucune finalité prédéfinie.
Speaker #1
C'est juste un moteur, en somme.
Speaker #2
C'est ça, un moteur avec des capacités statistiques. Un système d'intelligence artificielle, en revanche, c'est l'assemblage de ce modèle avec une interface, des règles métiers et, élément central, une destination d'usage prévue.
Speaker #1
Ce qui retient l'attention ici, c'est que la qualification juridique est dictée par la finalité, pas par le moteur technologique lui-même.
Speaker #2
Exactement. Concrètement, si on utilise un même modèle génératif pour synthétiser des comptes rendus internes de réunion, ça relève du risque minimal.
Speaker #1
D'accord.
Speaker #2
Mais si on intègre cette... exacte même technologie dans un processus RH pour trier les candidatures, l'ensemble bascule dans la catégorie à haut risque, le domaine de l'emploi étant sensible.
Speaker #1
C'est une bascule majeure. Ça signifie qu'un éditeur logiciel peut fournir une technologie parfaite et conforme, mais la classification de risque finale lui échappe totalement dès lors que l'entreprise cliente décide de l'appliquer à un domaine critique.
Speaker #0
Faisons une pause pour poser les idées. La première, c'est la distinction entre un modèle et un système. Un modèle, c'est le moteur, la capacité générale sans destination. Un système, c'est ce moteur une fois installé dans un usage précis, avec une interface et une finalité. Et c'est cette finalité qui détermine le risque. Le même modèle qui résume vos comptes rendus reste anodin. Branché sur une décision qui touche des personnes, comme un recrutement, Il change de catégorie. Pourquoi cela vous concerne, quel que soit votre métier ? La conformité ne se juge pas à l'achat. Elle se joue au moment où vous décidez à quoi servira l'outil. Ce moment-là relève de vous, quel que soit le fournisseur. Reste alors une question, celle de la suite. Une fois le système en service, qui porte quelle responsabilité ? Celui qui l'a conçu ou celui qui l'a mis en œuvre ? Le droit sépare ces deux rôles. Et le second pèse plus lourd qu'on ne l'imagine.
Speaker #2
C'est toute la subtilité. Et c'est pour ça que le droit européen, de manière très logique, scinde les obligations entre celui qui conçoit la technologie et celui qui décide de son application en entreprise.
Speaker #1
Donc on passe au partage des responsabilités. Puisque c'est l'usage qui définit le risque, comment le texte sépartit lui ses rôles ?
Speaker #2
Il institue deux rôles majeurs, le fournisseur et le déployeur.
Speaker #1
Commençons par le fournisseur. Quelle est sa part de responsabilité ?
Speaker #2
Le fournisseur, c'est l'entité qui développe et met sur le marché. Il porte la charge de la conformité de conception.
Speaker #1
C'est-à-dire la gouvernance des données d'entraînement ?
Speaker #2
Oui, la gouvernance des données, la rédaction de la documentation technique et bien sûr, l'obtention du marquage de conformité européen. Mais une fois l'outil commercialisé, le rôle principal bascule vers le déployeur.
Speaker #1
Ce terme est intéressant parce que dans le langage courant de l'entreprise, On dit plutôt le client ou l'utilisateur.
Speaker #2
Oui, mais le terme juridique de déployeur est lourd de sens. Le déployeur désigne l'organisation qui utilise le système dans le cadre de son activité. Et le fardeau légal qu'il porte est bien plus lourd qu'il ne l'imagine.
Speaker #1
Concrètement, qu'est-ce que cela signifie pour une direction des achats ou une direction informatique ? On n'est plus de simples acheteurs de licences logicielles.
Speaker #2
Loin de là. En tant que déployeur, l'entreprise a des devoirs de surveillance active. Ce rôle implique par exemple d'attribuer la supervision humaine à du personnel spécifiquement formé.
Speaker #1
Arrêtons-nous là-dessus un instant, parce que cette supervision humaine soulève une question opérationnelle. Si on déploie un algorithme pour traiter un grand volume d'opérations logistiques, un humain ne peut matériellement pas repasser derrière chaque décision.
Speaker #2
Bien sûr ! Et le législateur ne demande pas de dupliquer le travail de la machine. Ce sera absurde !
Speaker #1
Alors, que signifie réellement superviser AIA ?
Speaker #2
La supervision implique une conception organisationnelle. Il faut que les personnes chargées de cette supervision aient la compétence de détecter les anomalies et surtout l'autorité hiérarchique pour ignorer ou renverser une décision proposée par l'algorithme.
Speaker #1
Ce n'est donc pas une vérification à la tâche, c'est la mise en place d'un filet de sécurité, un vrai droit de veto institutionnel ?
Speaker #2
C'est l'esprit de la loi. Et le déployeur doit aussi s'assurer de l'alphabétisation en IAD de ses collaborateurs.
Speaker #1
TA
Speaker #2
Par la documentation, il faut pouvoir prouver l'existence de formations spécifiques et l'intégration de ses compétences dans les processus. De plus, le déployeur doit contrôler la pertinence des données réelles injectées, les inputs, et conserver les journaux d'événements, les fameux logs.
Speaker #1
C'est un changement de paradigme complet. L'entreprise devient un superviseur d'opérations algorithmiques. Mais si ce rôle de déployeur est déjà contraignant, il existe un mécanisme juridique redoutable, une sorte de piège. C'est l'article 25.
Speaker #2
Ah oui, l'article 25 de l'AI Act. C'est le principe de requalification automatique.
Speaker #1
C'est ici que l'analyse devient particulièrement intéressante. Comment une entreprise peut-elle perdre son statut de déployeur pour devenir concepteur, responsable de tout
Speaker #2
TA ? Ce mécanisme s'active si l'entreprise modifie substantiellement un système tiers ou si elle décide de l'exploiter sous sa propre marque pour un usage classé à haut risque. Du jour au lendemain, elle perd son statut de simple déployeur.
Speaker #1
Et elle devient légalement le fournisseur.
Speaker #2
Exactement ! Elle hérite soudainement de toutes les obligations initiales de conception. Les évaluations de conformité complexes, l'enregistrement européen, les systèmes de gestion des risques.
Speaker #1
Pour faire une comparaison, c'est l'équivalent d'acheter un véhicule utilitaire standard, on est d'accord, et de modifier soi-même le moteur et le châssis dans ses ateliers pour transporter des matières dangereuses.
Speaker #2
C'est une excellente image.
Speaker #1
Osier de la loi, on n'est plus seulement le conducteur du véhicule, on est devenu le constructeur automobile. Et on doit fournir toutes les certifications de sécurité.
Speaker #2
C'est tout à fait ça. Par la force de ses propres choix d'adaptation technique, l'entreprise cliente devient le fabricant devant la loi.
Speaker #1
Mais qu'appelle-t-on une modification substantielle ? Si un collaborateur rédige une instruction complexe dans l'interface de l'outil à un prompt très élaboré, est-ce que ça déclenche ce piège de l'article 25 ?
Speaker #2
Non, l'utilisation courante via l'interface, même poussée, ne modifie pas l'architecture profonde. Mais si une équipe technique prend un modèle ouvert... et procède à un réentraînement spécifique de l'algorithme avec des bases des données internes pour l'intégrer dans un processus de décision critique, là, la ligne est franchie.
Speaker #1
L'outil a été structurellement altéré.
Speaker #2
Et le fardeau documentaire qui s'abat alors sur l'organisation est colossal.
Speaker #0
Reprenons le fil. Car ce qui vient d'être dit dépresse les responsabilités. Par défaut, lorsque vous utilisez un système d'IA, vous êtes le déployeur. Vous en êtes responsable. Le fournisseur, lui, répond de sa conception. Mais si vous transformez le système en profondeur, en réentraînant par exemple un modèle sur vos propres données, ou si vous le diffusez sous votre marque pour un usage sensible, la loi vous considère alors comme son concepteur. C'est l'article 25. Et vous héritez, d'un coup, des obligations les plus lourdes. Évaluation de conformité, documentation technique, enregistrement. Ce qu'il faut en retenir en comité de direction. Ce basculement ne n'est pas d'une décision juridique. Il naît de choix techniques ordinaires, pris parfois sans en mesurer la portée. D'où l'intérêt de savoir, pour chaque projet, de quel côté de la ligne on se trouve avant de la franchir. Et si l'enjeu semble encore abstrait, la suite va le rendre concret. Car ce risque a désormais un prix, et il ne se compte plus dans le budget informatique.
Speaker #1
Ce basculement des responsabilités prend toute sa dimension quand on observe le levier coercitif. Le risque n'est pas seulement théorique, il y a une interdiction financière derrière.
Speaker #2
Une réalité très dissuasive. Le régulateur a mis en place une grille de sanctions très stricte.
Speaker #1
Comment se structurent ces pénalités ?
Speaker #2
Elles obéissent à la grille de 7%, 3%, 1%. Ce sont des plafonds basés sur le chiffre d'affaires annuel mondial de l'entreprise.
Speaker #1
Des pourcentages du chiffre d'affaires mondial, ce n'est pas anodin.
Speaker #2
Pas du tout, et le plafond maximal est réservé aux pratiques formellement interdites, comme le scoring social à grande échelle ou la reconnaissance des émotions sur le lieu de travail.
Speaker #1
Et à combien s'élève ce plafond maximal ?
Speaker #2
Pour ces interdictions absolues, l'amende peut atteindre jusqu'à 7% du CA mondial ou 35 M&E. L'autorité retenant systématiquement le montant le plus élevé des deux.
Speaker #1
C'est un recadrage stratégique majeur. Ces montantes déplacent le sujet de la sphère purement technologique vers la sphère de la gouvernance d'entreprise. Une non-conformité n'impacte pas le budget informatique. C'est un risque existentiel qui relève de la responsabilité du conseil d'administration.
Speaker #2
Et des directions financières, absolument.
Speaker #1
Face à des risques de cette envergure, le constat est posé. Quelle est la démarche immédiate pour les directions opérationnelles ? Le premier réflexe serait peut-être de bloquer techniquement l'accès à ces outils.
Speaker #2
Le verrouillage, on le sait, mène souvent à l'informatique de l'ombre, ce qui aggrave les failles. La première action n'est pas de rédiger un mode d'emploi technique, restrictif, c'est d'établir une cartographie juridique et fonctionnelle rigoureuse.
Speaker #1
Cartographie ses usages. Mais c'est plus qu'un simple inventaire logiciel.
Speaker #2
Bien plus. L'entreprise doit lister chaque système déployé, bien sûr. Mais surtout, documenter sa destination d'usage précise, déterminer son statut exact. Pour chaque cas, agit-on en tant que déployeur ou ont-on franchi la ligne vers une requalification en fournisseur ?
Speaker #1
Le centre de gravité se déplace vraiment. Pour être en règle, l'organisation ne doit plus seulement auditer le code informatique qu'elle achète. Elle doit auditer les tâches confiées à la machine par ses propres collaborateurs.
Speaker #2
C'est l'objectif. Cette rigueur permet ensuite de réviser les contrats d'achat. On s'assure d'interdire contractuellement les usages non autorisés en interne et on garantit que l'éditeur fournira bien les documentations techniques nécessaires.
Speaker #1
Mais si l'on relie cela au contexte global, établir cette cartographie, c'est une posture purement interne.
Speaker #2
Oui, mais c'est le socle de toute la défense de l'entreprise. Parce que l'EIAI Acte n'opère pas en vase clos. Il interagit de manière complexe avec d'autres textes fondamentaux, comme le RGPD ou la nouvelle directive sur la responsabilité des produits défectueux.
Speaker #1
C'est vrai, la directive a été mise à jour pour inclure les logiciels.
Speaker #2
Et c'est là que le piège se referme aux civils. Si une entreprise est incapable de prouver qu'elle a respecté ses obligations de déployeur, par exemple en négligeant de conserver les journaux d'événements, cette faille dans les high-act devient une preuve automatique de négligence devant un juge.
Speaker #1
C'est une présomption de défaut. La boucle est bouclée. La ligne de démarcation entre la conception technologique et l'application opérationnelle est claire. On sait désormais de quoi on répond le long de cette chaîne. Reste à le prouver quand l'autorité viendra frapper à la porte.
Speaker #0
Une dernière idée pour refermer. Cartographier vos usages, c'est transformer une échéance réglementaire en une décision qui vous appartient. Merci pour votre écoute sur ce sujet technique et rendez-vous sur spencia.com pour nos derniers articles.

About Les signaux du changement

Découvrez Les Signaux du Changement, un tout nouveau podcast qui explore les stratégies de transformation des entreprises et leur impact critique sur le capital humain.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

About Les signaux du changement

Découvrez Les Signaux du Changement, un tout nouveau podcast qui explore les stratégies de transformation des entreprises et leur impact critique sur le capital humain.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Description

Nos derniers articles : https://www.spentia.com/?utm_source=podcast&utm_medium=show-notes&utm_campaign=signaux&utm_content=ep10

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Transcription

Speaker #0
Bienvenue dans ce nouvel épisode des Signes du Changement. Une loi est, d'ordinaire, un sujet que l'on confie à la direction juridique. Celle dont on parle aujourd'hui fait exception, et c'est tout l'objet de cet épisode. Car l'EI Acte Européen attache une responsabilité aux décisions que prennent les métiers, chaque jour. Choisir un outil pour trier des candidatures, résumer un dossier ou automatiser une opération. Ces gestes ordinaires engagent désormais l'entreprise. C'est ce qui rend le sujet utile bien au-delà des juristes, même s'il a l'air technique. Alors posons les bases. L'EI Act, c'est le premier cadre européen qui encadre l'intelligence artificielle en tant que telle dans tous les secteurs confondus. Sa logique tient en une idée simple. Il ne juge pas la technologie dans l'absolu, il regarde ce qu'on en fait. Il classe les usages selon leur niveau de risque, puis répartit les responsabilités entre celui qui conçoit un système et celui qui l'emploie. Depuis le 2 août 2026, ce cadre est passé en exécution. Les obligations de transparence et la supervision des modèles généraux s'appliquent et les autorités peuvent sanctionner. Le volet « au risque » , celui qui porte les obligations les plus exigeantes, a été repoussé par le Digital Omnibus à décembre 2027. Ce report laisse du temps pour se préparer. La date de décembre 2027 est probablement ferme. Une dernière raison de tendre l'oreille, quelle que soit votre fonction. Une direction juridique ne cadre que les usages qu'on lui signale. Si les métiers avancent sans le dire, l'exposition grandit sans que personne ne la voit. Partager ce sujet dans toute l'entreprise, c'est se donner les moyens de regarder le risque en face. Aujourd'hui, une question qui vaut déjà pour toute l'entreprise. Pour l'intelligence artificielle que vous utilisez, qui répond de quoi ?
Speaker #1
Posons un cadre de réflexion pour commencer. Imaginons une scène qui en ce moment même se déroule probablement dans une multitude de grandes organisations. Un collaborateur, disons au sein d'une direction financière, a besoin de synthétiser un rapport d'audit particulièrement complexe.
Speaker #2
Oui, un cas d'usage très classique.
Speaker #1
Voilà. Et pour gagner du temps, il copie l'intégralité du document et le colle dans l'interface d'un outil d'intelligence artificielle générative standard disponible en ligne. La synthèse produite est impeccable. Sauf que peu de temps après... La direction juridique réalise que des données stratégiques ont été ingérées par le modèle de cet outil pour son propre apprentissage.
Speaker #0
Et là, c'est la panique ?
Speaker #1
Exactement, c'est la panique. Le premier réflexe de l'entreprise, c'est de se tourner vers l'éditeur de l'outil pour exiger les comptes. Et là, surprise. Les conditions d'utilisation stipulent clairement que l'éditeur fournit un simple moteur algorithmique et que la responsabilité de la nature des données injectées ainsi que l'usage final incombe entièrement au client.
Speaker #2
Ce qui laisse l'entreprise complètement seule.
Speaker #1
C'est ça. Soudainement seul, pleinement imputable d'une faille de sécurité majeure et sans aucun recours. Si la machine capte déjà ce que les outils classiques ne mesurent pas, la vraie question qui se pose à voix haute, c'est qui est comptable de ce qu'elle produit ?
Speaker #2
Et ce scénario, en fait, il illustre parfaitement la fracture abyssale entre la perception de la technologie par les directions opérationnelles et la réalité de l'encadrement légal. Il y a un biais, un biais vraiment persistant, qui consiste à penser que l'acquisition d'une solution auprès d'un acteur reconnu du marché ça transfère automatiquement la charge de la conformité.
Speaker #1
On achète un outil réputé conforme, donc on se croit couvert sur le plan légal.
Speaker #2
C'est exactement cette illusion. Or, la législation qui se met en place actuellement renverse complètement cette logique.
Speaker #1
Et c'est précisément l'objet de notre exploration d'aujourd'hui. Pour déconstruire ce mécanisme, on a croisé plusieurs sources de référence. Le texte définitif du règlement européen sur l'intelligence artificielle, l'EA Act, Les premières lignes directrices d'exécution de la Commission européenne, ainsi que des notes d'analyse produites par de grands cabinets d'avocats. L'objectif, pour les directions générales, juridiques et opérationnelles qui s'informent sur le sujet, c'est de fournir une grille de lecture claire.
Speaker #2
Une grille indispensable, oui.
Speaker #1
Car la thèse centrale, on va la filer tout du long, la responsabilité juridique suit strictement l'usage final qui est fait du système et non la simple acquisition technique.
Speaker #2
Tout à fait. Et le passage de la théorie à la pratique, disons que ce n'est plus une perspective lointaine. La période de transition, d'observation en quelque sorte, touche à sa fin.
Speaker #1
Avant de comprendre qui est responsable de quoi, il faut comprendre pourquoi cette question quitte le domaine de la théorie pour devenir un risque d'exposition immédiat.
Speaker #2
Parce que le calendrier réglementaire impose une bascule opérationnelle stricte. C'est le 2 août 2026 qui marque ce pivot pour l'ensemble des acteurs.
Speaker #1
D'accord, décortiquons un peu cela. Pourquoi le 2 août... 2026 change la donne de manière si abrupte. L'écosystème a l'habitude des réglementations européennes, il y a toujours des phases d'adaptation.
Speaker #2
C'est vrai, et le marché se trouvait justement dans une phase de mise en conformité préparatoire. Certaines obligations existaient déjà, mais elles ciblaient principalement les concepteurs de modèles généraux. La bascule, c'est qu'à partir de cette date, l'arsenal coercitif global entre en action.
Speaker #1
C'est-à-dire ?
Speaker #2
C'est-à-dire que les autorités de contrôle nationales et européennes activent leur plein pouvoir d'enquête, les perquisitions numériques, l'exécution et in fine les sanctions. L'AI Act n'est plus un sujet de veille juridique, c'est un cadre exécutoire.
Speaker #1
Donc le droit souple devient un droit dur ?
Speaker #2
Absolument ! Et parallèlement, c'est l'entrée en vigueur des obligations de transparence applicables à toutes les entreprises. C'est l'obligation légale de signaler qu'on interagit avec une machine, par exemple face à un agent conversationnel.
Speaker #1
Pour bien matérialiser ce basculement, c'est comme le code de la route. Les panneaux de limitation de vitesse étaient déjà posés l'année dernière, on pouvait lire le code. Mais depuis ce fameux mois d'août, les radars sont allumés et les amendes partent.
Speaker #2
C'est une bonne analogie.
Speaker #1
Sauf que, et c'est là que la comparaison atteint ses limites, un algorithme n'a pas de plaque d'immatriculation. Comment une autorité de contrôle procède-t-elle pour identifier Dix. qui sanctionner sur cette nouvelle route usine ?
Speaker #2
En première intention, le régulateur ne cherche pas à inspecter la complexité du code source. Il s'accue plutôt sur une méthode de classification structurelle. Toute l'approche européenne repose sur une gradation des risques.
Speaker #1
C'est l'approche par les risques dont on entend souvent parler ?
Speaker #2
Voilà. Il y a les pratiques inacceptables, les usages à haut risque, ceux à risque limité et le risque minimal. Mais pour déterminer la cible, le droit impose une distinction fondamentale, presque philosophique, entre ce qu'il nomme un modèle et ce qu'il qualifie de système.
Speaker #1
Un modèle contre un système. Ça semble être une simple nuance sémantique au premier abord. En quoi cela fait-il voler en éclats l'illusion de l'outil clé en main ?
Speaker #2
Parce que c'est ce qui définit la qualification juridique. Un modèle d'intelligence artificielle, c'est une brique algorithmique générale. Il n'a aucune finalité prédéfinie.
Speaker #1
C'est juste un moteur, en somme.
Speaker #2
C'est ça, un moteur avec des capacités statistiques. Un système d'intelligence artificielle, en revanche, c'est l'assemblage de ce modèle avec une interface, des règles métiers et, élément central, une destination d'usage prévue.
Speaker #1
Ce qui retient l'attention ici, c'est que la qualification juridique est dictée par la finalité, pas par le moteur technologique lui-même.
Speaker #2
Exactement. Concrètement, si on utilise un même modèle génératif pour synthétiser des comptes rendus internes de réunion, ça relève du risque minimal.
Speaker #1
D'accord.
Speaker #2
Mais si on intègre cette... exacte même technologie dans un processus RH pour trier les candidatures, l'ensemble bascule dans la catégorie à haut risque, le domaine de l'emploi étant sensible.
Speaker #1
C'est une bascule majeure. Ça signifie qu'un éditeur logiciel peut fournir une technologie parfaite et conforme, mais la classification de risque finale lui échappe totalement dès lors que l'entreprise cliente décide de l'appliquer à un domaine critique.
Speaker #0
Faisons une pause pour poser les idées. La première, c'est la distinction entre un modèle et un système. Un modèle, c'est le moteur, la capacité générale sans destination. Un système, c'est ce moteur une fois installé dans un usage précis, avec une interface et une finalité. Et c'est cette finalité qui détermine le risque. Le même modèle qui résume vos comptes rendus reste anodin. Branché sur une décision qui touche des personnes, comme un recrutement, Il change de catégorie. Pourquoi cela vous concerne, quel que soit votre métier ? La conformité ne se juge pas à l'achat. Elle se joue au moment où vous décidez à quoi servira l'outil. Ce moment-là relève de vous, quel que soit le fournisseur. Reste alors une question, celle de la suite. Une fois le système en service, qui porte quelle responsabilité ? Celui qui l'a conçu ou celui qui l'a mis en œuvre ? Le droit sépare ces deux rôles. Et le second pèse plus lourd qu'on ne l'imagine.
Speaker #2
C'est toute la subtilité. Et c'est pour ça que le droit européen, de manière très logique, scinde les obligations entre celui qui conçoit la technologie et celui qui décide de son application en entreprise.
Speaker #1
Donc on passe au partage des responsabilités. Puisque c'est l'usage qui définit le risque, comment le texte sépartit lui ses rôles ?
Speaker #2
Il institue deux rôles majeurs, le fournisseur et le déployeur.
Speaker #1
Commençons par le fournisseur. Quelle est sa part de responsabilité ?
Speaker #2
Le fournisseur, c'est l'entité qui développe et met sur le marché. Il porte la charge de la conformité de conception.
Speaker #1
C'est-à-dire la gouvernance des données d'entraînement ?
Speaker #2
Oui, la gouvernance des données, la rédaction de la documentation technique et bien sûr, l'obtention du marquage de conformité européen. Mais une fois l'outil commercialisé, le rôle principal bascule vers le déployeur.
Speaker #1
Ce terme est intéressant parce que dans le langage courant de l'entreprise, On dit plutôt le client ou l'utilisateur.
Speaker #2
Oui, mais le terme juridique de déployeur est lourd de sens. Le déployeur désigne l'organisation qui utilise le système dans le cadre de son activité. Et le fardeau légal qu'il porte est bien plus lourd qu'il ne l'imagine.
Speaker #1
Concrètement, qu'est-ce que cela signifie pour une direction des achats ou une direction informatique ? On n'est plus de simples acheteurs de licences logicielles.
Speaker #2
Loin de là. En tant que déployeur, l'entreprise a des devoirs de surveillance active. Ce rôle implique par exemple d'attribuer la supervision humaine à du personnel spécifiquement formé.
Speaker #1
Arrêtons-nous là-dessus un instant, parce que cette supervision humaine soulève une question opérationnelle. Si on déploie un algorithme pour traiter un grand volume d'opérations logistiques, un humain ne peut matériellement pas repasser derrière chaque décision.
Speaker #2
Bien sûr ! Et le législateur ne demande pas de dupliquer le travail de la machine. Ce sera absurde !
Speaker #1
Alors, que signifie réellement superviser AIA ?
Speaker #2
La supervision implique une conception organisationnelle. Il faut que les personnes chargées de cette supervision aient la compétence de détecter les anomalies et surtout l'autorité hiérarchique pour ignorer ou renverser une décision proposée par l'algorithme.
Speaker #1
Ce n'est donc pas une vérification à la tâche, c'est la mise en place d'un filet de sécurité, un vrai droit de veto institutionnel ?
Speaker #2
C'est l'esprit de la loi. Et le déployeur doit aussi s'assurer de l'alphabétisation en IAD de ses collaborateurs.
Speaker #1
TA
Speaker #2
Par la documentation, il faut pouvoir prouver l'existence de formations spécifiques et l'intégration de ses compétences dans les processus. De plus, le déployeur doit contrôler la pertinence des données réelles injectées, les inputs, et conserver les journaux d'événements, les fameux logs.
Speaker #1
C'est un changement de paradigme complet. L'entreprise devient un superviseur d'opérations algorithmiques. Mais si ce rôle de déployeur est déjà contraignant, il existe un mécanisme juridique redoutable, une sorte de piège. C'est l'article 25.
Speaker #2
Ah oui, l'article 25 de l'AI Act. C'est le principe de requalification automatique.
Speaker #1
C'est ici que l'analyse devient particulièrement intéressante. Comment une entreprise peut-elle perdre son statut de déployeur pour devenir concepteur, responsable de tout
Speaker #2
TA ? Ce mécanisme s'active si l'entreprise modifie substantiellement un système tiers ou si elle décide de l'exploiter sous sa propre marque pour un usage classé à haut risque. Du jour au lendemain, elle perd son statut de simple déployeur.
Speaker #1
Et elle devient légalement le fournisseur.
Speaker #2
Exactement ! Elle hérite soudainement de toutes les obligations initiales de conception. Les évaluations de conformité complexes, l'enregistrement européen, les systèmes de gestion des risques.
Speaker #1
Pour faire une comparaison, c'est l'équivalent d'acheter un véhicule utilitaire standard, on est d'accord, et de modifier soi-même le moteur et le châssis dans ses ateliers pour transporter des matières dangereuses.
Speaker #2
C'est une excellente image.
Speaker #1
Osier de la loi, on n'est plus seulement le conducteur du véhicule, on est devenu le constructeur automobile. Et on doit fournir toutes les certifications de sécurité.
Speaker #2
C'est tout à fait ça. Par la force de ses propres choix d'adaptation technique, l'entreprise cliente devient le fabricant devant la loi.
Speaker #1
Mais qu'appelle-t-on une modification substantielle ? Si un collaborateur rédige une instruction complexe dans l'interface de l'outil à un prompt très élaboré, est-ce que ça déclenche ce piège de l'article 25 ?
Speaker #2
Non, l'utilisation courante via l'interface, même poussée, ne modifie pas l'architecture profonde. Mais si une équipe technique prend un modèle ouvert... et procède à un réentraînement spécifique de l'algorithme avec des bases des données internes pour l'intégrer dans un processus de décision critique, là, la ligne est franchie.
Speaker #1
L'outil a été structurellement altéré.
Speaker #2
Et le fardeau documentaire qui s'abat alors sur l'organisation est colossal.
Speaker #0
Reprenons le fil. Car ce qui vient d'être dit dépresse les responsabilités. Par défaut, lorsque vous utilisez un système d'IA, vous êtes le déployeur. Vous en êtes responsable. Le fournisseur, lui, répond de sa conception. Mais si vous transformez le système en profondeur, en réentraînant par exemple un modèle sur vos propres données, ou si vous le diffusez sous votre marque pour un usage sensible, la loi vous considère alors comme son concepteur. C'est l'article 25. Et vous héritez, d'un coup, des obligations les plus lourdes. Évaluation de conformité, documentation technique, enregistrement. Ce qu'il faut en retenir en comité de direction. Ce basculement ne n'est pas d'une décision juridique. Il naît de choix techniques ordinaires, pris parfois sans en mesurer la portée. D'où l'intérêt de savoir, pour chaque projet, de quel côté de la ligne on se trouve avant de la franchir. Et si l'enjeu semble encore abstrait, la suite va le rendre concret. Car ce risque a désormais un prix, et il ne se compte plus dans le budget informatique.
Speaker #1
Ce basculement des responsabilités prend toute sa dimension quand on observe le levier coercitif. Le risque n'est pas seulement théorique, il y a une interdiction financière derrière.
Speaker #2
Une réalité très dissuasive. Le régulateur a mis en place une grille de sanctions très stricte.
Speaker #1
Comment se structurent ces pénalités ?
Speaker #2
Elles obéissent à la grille de 7%, 3%, 1%. Ce sont des plafonds basés sur le chiffre d'affaires annuel mondial de l'entreprise.
Speaker #1
Des pourcentages du chiffre d'affaires mondial, ce n'est pas anodin.
Speaker #2
Pas du tout, et le plafond maximal est réservé aux pratiques formellement interdites, comme le scoring social à grande échelle ou la reconnaissance des émotions sur le lieu de travail.
Speaker #1
Et à combien s'élève ce plafond maximal ?
Speaker #2
Pour ces interdictions absolues, l'amende peut atteindre jusqu'à 7% du CA mondial ou 35 M&E. L'autorité retenant systématiquement le montant le plus élevé des deux.
Speaker #1
C'est un recadrage stratégique majeur. Ces montantes déplacent le sujet de la sphère purement technologique vers la sphère de la gouvernance d'entreprise. Une non-conformité n'impacte pas le budget informatique. C'est un risque existentiel qui relève de la responsabilité du conseil d'administration.
Speaker #2
Et des directions financières, absolument.
Speaker #1
Face à des risques de cette envergure, le constat est posé. Quelle est la démarche immédiate pour les directions opérationnelles ? Le premier réflexe serait peut-être de bloquer techniquement l'accès à ces outils.
Speaker #2
Le verrouillage, on le sait, mène souvent à l'informatique de l'ombre, ce qui aggrave les failles. La première action n'est pas de rédiger un mode d'emploi technique, restrictif, c'est d'établir une cartographie juridique et fonctionnelle rigoureuse.
Speaker #1
Cartographie ses usages. Mais c'est plus qu'un simple inventaire logiciel.
Speaker #2
Bien plus. L'entreprise doit lister chaque système déployé, bien sûr. Mais surtout, documenter sa destination d'usage précise, déterminer son statut exact. Pour chaque cas, agit-on en tant que déployeur ou ont-on franchi la ligne vers une requalification en fournisseur ?
Speaker #1
Le centre de gravité se déplace vraiment. Pour être en règle, l'organisation ne doit plus seulement auditer le code informatique qu'elle achète. Elle doit auditer les tâches confiées à la machine par ses propres collaborateurs.
Speaker #2
C'est l'objectif. Cette rigueur permet ensuite de réviser les contrats d'achat. On s'assure d'interdire contractuellement les usages non autorisés en interne et on garantit que l'éditeur fournira bien les documentations techniques nécessaires.
Speaker #1
Mais si l'on relie cela au contexte global, établir cette cartographie, c'est une posture purement interne.
Speaker #2
Oui, mais c'est le socle de toute la défense de l'entreprise. Parce que l'EIAI Acte n'opère pas en vase clos. Il interagit de manière complexe avec d'autres textes fondamentaux, comme le RGPD ou la nouvelle directive sur la responsabilité des produits défectueux.
Speaker #1
C'est vrai, la directive a été mise à jour pour inclure les logiciels.
Speaker #2
Et c'est là que le piège se referme aux civils. Si une entreprise est incapable de prouver qu'elle a respecté ses obligations de déployeur, par exemple en négligeant de conserver les journaux d'événements, cette faille dans les high-act devient une preuve automatique de négligence devant un juge.
Speaker #1
C'est une présomption de défaut. La boucle est bouclée. La ligne de démarcation entre la conception technologique et l'application opérationnelle est claire. On sait désormais de quoi on répond le long de cette chaîne. Reste à le prouver quand l'autorité viendra frapper à la porte.
Speaker #0
Une dernière idée pour refermer. Cartographier vos usages, c'est transformer une échéance réglementaire en une décision qui vous appartient. Merci pour votre écoute sur ce sujet technique et rendez-vous sur spencia.com pour nos derniers articles.

About Les signaux du changement

Découvrez Les Signaux du Changement, un tout nouveau podcast qui explore les stratégies de transformation des entreprises et leur impact critique sur le capital humain.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

About Les signaux du changement

Découvrez Les Signaux du Changement, un tout nouveau podcast qui explore les stratégies de transformation des entreprises et leur impact critique sur le capital humain.

Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Embed