IA et système d'information : ce que l'AI Act, le RGPD et la résilience imposent à la DSI en 2026

Votre DSI a déployé un copilote de code, un agent qui trie les tickets, quelques automatisations dopées à l'IA et, côté sécurité, des outils de détection « augmentés ». Personne n'a ouvert de dossier de conformité, parce que « le haut risque, c'est reporté à décembre 2027 ».

Cette phrase est vraie. Elle est aussi la plus mauvaise raison de ne rien faire, et pour une raison qui ne concerne que l'IT : la DSI est le seul métier qui ne se contente pas d'utiliser l'IA — elle la modifie. Or modifier un système d'IA change qui, juridiquement, en répond.

Ce guide dit exactement ce qui est exigible aujourd'hui, ce qui vient au 2 décembre 2027, et pourquoi la partie qui ne peut pas attendre est la moins juridique de toutes.

1. Ce qui est reporté, et ce qui ne l'est pas

Le Digital Omnibus — règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026 — a repoussé les obligations des systèmes à haut risque de l'annexe III du 2 août 2026 au 2 décembre 2027, et celles de l'annexe I au 2 août 2028.

Le report est réel et large : il emporte les exigences des articles 9 à 15 et 16 à 27. La documentation technique, la gestion des risques, la journalisation, la supervision humaine, les obligations du déployeur — tout ce bloc devient exigible en décembre 2027, pas avant.

Ce qui n'a pas bougé, et qui s'applique à votre SI aujourd'hui :

• L'article 5 (pratiques interdites), depuis le 2 février 2025. Une IA de surveillance des salariés qui déduit leur état émotionnel relève de l'inférence d'émotions au travail, interdite, plafond 35 M€ ou 7 % du chiffre d'affaires mondial.
• L'article 4 (maîtrise de l'IA), depuis le 2 février 2025, sous supervision depuis le 2 août 2026. Il faut pouvoir prouver que les équipes maîtrisent les outils déployés — ce qui suppose de savoir lesquels le sont.
• L'article 50 (transparence), depuis le 2 août 2026. Dès que le SI produit et diffuse des contenus générés, le marquage lisible par machine s'applique. Le 2 décembre 2026 n'est pas la date d'entrée en vigueur : c'est la fin d'une période de grâce, réservée aux systèmes déjà sur le marché le 2 août 2026.
• Les modèles à usage général (GPAI), depuis le 2 août 2025 pour les obligations, depuis le 2 août 2026 pour les pouvoirs d'exécution de la Commission.
• Le RGPD, intégralement : registre (art. 30), sécurité (art. 32), AIPD (art. 35), décision automatisée (art. 22).
• DORA, applicable depuis le 17 janvier 2025 pour les entités financières.

Le calendrier complet le montre ligne par ligne.

2. Le piège propre à la DSI : l'article 25

Le marketing, les RH, la finance sont presque toujours déployeurs : ils utilisent un système acheté. La DSI, elle, intervient dessus. Et l'article 25 prévoit qu'un déployeur — ou tout autre acteur de la chaîne — devient juridiquement fournisseur d'un système à haut risque dans trois cas :

• il appose son nom ou sa marque sur un système déjà mis sur le marché ;
• il apporte une modification substantielle à un système à haut risque qui le reste ;
• il détourne la finalité d'un système au point de le rendre haut risque.

Concrètement : fine-tuner un modèle open-weight sur vos données, exposer une API LLM sous votre marque à des tiers, ré-entraîner un moteur de détection, brancher un module de décision automatique sur un outil ITSM.

Où passe la ligne du « substantiel »

Le mot n'a rien d'intuitif pour une équipe technique, et c'est là que se joue la plupart des désaccords. Une mise à jour de dépendance, un correctif de performance, un changement d'infrastructure : non. Un ré-entraînement qui modifie le comportement du modèle, l'ajout d'un module qui décide seul, un changement de finalité : oui, probablement.

Le critère n'est pas l'ampleur du diff, c'est l'effet sur la conformité, la sécurité ou la finalité du système tel qu'il avait été évalué. Un fine-tuning de trois cents lignes peut être substantiel ; une refonte complète de l'infrastructure d'inférence peut ne pas l'être.

Deux conséquences pratiques. La première : la question se tranche avant le geste, pas pendant l'audit — une équipe qui se la pose au moment de la revue de conception y répond en cinq minutes, une équipe qui se la pose dix-huit mois plus tard n'y répond plus du tout. La seconde : le doute se règle par la documentation, pas par l'optimisme. Consigner un geste dont on décidera plus tard qu'il n'était pas substantiel coûte deux minutes ; l'inverse coûte le dossier.

Ce que cela change, et quand

Soyons précis, parce que c'est là que la plupart des contenus dérapent. La bascule ne crée pas d'obligation exigible aujourd'hui : les obligations du fournisseur d'un système à haut risque — documentation technique, système de gestion des risques, surveillance après commercialisation, déclaration d'incident grave — sont précisément celles que l'Omnibus a reportées au 2 décembre 2027.

Ce qui rend le sujet urgent n'est donc pas la sanction. C'est la chronologie :

> Le geste qui vous fait basculer a lieu aujourd'hui. Le dossier qu'il crée sera exigible en décembre 2027. Et on ne reconstitue pas rétroactivement la traçabilité d'un ré-entraînement qu'on n'a pas consigné au moment où il a eu lieu.

Une DSI qui commence en 2027 devra documenter dix-huit mois de modifications dont plus personne ne se souvient — les données d'entraînement, les versions, les décisions, les personnes. C'est le coût réel, et il se paie une seule fois : maintenant, à quelques minutes par geste, ou plus tard, en archéologie.

3. Les huit familles d'IA du système d'information

Avant de gouverner, nommer. Huit familles couvrent l'essentiel :

1. Copilotes de code — assistants de programmation, complétion, génération de tests.

2. Agents ITSM et support — tri de tickets, chatbots internes, base de connaissances augmentée.

3. Observabilité et AIOps — détection d'anomalies, corrélation d'alertes, prévision de capacité.

4. IA de sécurité et SOC — détection augmentée, triage SIEM, réponse assistée.

5. RPA et hyperautomatisation — workflows décisionnels, extraction documentaire, orchestration.

6. Agents et connecteurs MCP — le SI comme substrat d'exécution d'agents autonomes.

7. IA d'infrastructure — FinOps, placement de charges, autoscaling prédictif.

8. IA embarquée dans les SaaS déjà validés — le vecteur d'entrée le plus fréquent du Shadow AI.

Pour chacune, trois questions plutôt qu'une : quel rôle (déployeur ou fournisseur) ? quel risque (transparence, ou haut risque si la finalité le déclenche) ? quelle résilience (prestataire TIC à inventorier) ?

Ce que chaque famille déclenche, en une ligne :

Une remarque qui vaut pour les huit : ce n'est jamais la technologie qui déclenche le haut risque, c'est la finalité. Le même classifieur de documents est hors champ quand il range des factures, et relève de l'annexe III quand il présélectionne des candidatures. C'est pourquoi la colonne « finalité » du registre compte plus que la colonne « modèle ».

4. La brique que seul l'IT porte : la résilience opérationnelle

C'est ce qui distingue ce volet des trois précédents. Ni le marketing ni les RH ne portent DORA ou NIS2 ; la DSI, si.

DORA — règlement (UE) 2022/2554, applicable depuis le 17 janvier 2025. Les entités financières tiennent un registre d'information de leurs prestataires TIC. Un moteur d'IA ou un cloud d'inférence externalisé est un prestataire TIC à ce titre. Beaucoup de registres ont été remis sans les briques IA — c'est un écart constatable dès aujourd'hui, sans attendre 2027. Voir aussi le volet banque-assurance et la question des transferts hors UE pour le cloud d'inférence.

NIS2 — directive (UE) 2022/2555. En France, elle n'est pas encore transposée. Le projet de loi de résilience des infrastructures critiques a été adopté au Sénat le 12 mars 2025, amendé en commission spéciale de l'Assemblée nationale le 10 septembre 2025, et son examen en séance publique est repoussé à septembre 2026 au plus tôt. Aucune promulgation à ce jour.

Ce qui est connu du texte : environ 15 000 entités concernées sur 18 secteurs, contre quelque 300 sous NIS1 ; l'ANSSI comme autorité nationale ; des sanctions jusqu'à 10 M€ ou 2 % du chiffre d'affaires mondial pour les entités essentielles, 7 M€ ou 1,4 % pour les entités importantes ; et une responsabilité qui remonte aux dirigeants.

Écrire « NIS2 s'applique » aujourd'hui serait faux. Écrire qu'on a le temps le serait aussi : le délai de mise en conformité court à partir de la promulgation, et l'inventaire des systèmes est la partie la plus lente.

5. Le cas dur : la sécurité du code généré

C'est le risque le plus mesurable du volet IT, et il ne dépend d'aucune échéance.

Les tests publics convergent autour de 45 % de code vulnérable en sortie d'assistant de programmation. Un copilote de code n'est pas un gadget de productivité hors périmètre : c'est un composant du SI, et la sécurité de ce qu'il produit relève de l'article 32 du RGPD, applicable sans réserve, ainsi que des exigences de résilience.

L'ANSSI et son homologue allemand le BSI ont copublié des recommandations sur les assistants de programmation fondés sur l'IA : précaution dès la conception, vigilance sur les services partagés exposés à Internet, préférence pour des solutions éditeur cadrées plutôt que des frameworks auto-hébergés non maîtrisés.

S'y ajoute un effet documenté et rarement anticipé : un outil perçu comme « assez intelligent » abaisse la vigilance en revue de code. Le biais d'automatisation appliqué au delivery. Le risque n'est donc pas seulement dans ce que l'outil produit — il est dans l'attention qu'on cesse de lui porter, et cette part-là ne se corrige par aucun réglage de l'outil.

Trois contrôles suffisent à tenir le sujet, et aucun n'attend une échéance :

• La revue reste systématique, y compris — surtout — sur le code que l'outil a écrit d'un trait. C'est le contrôle qui compense le biais, et le seul qui le fasse.
• L'analyse statique tourne sur le code généré comme sur le reste. Une chaîne d'intégration qui exempte les fichiers issus d'un copilote au motif qu'ils sont « propres » retire le filet là où il sert le plus.
• Le copilote est inventorié comme un composant, avec un propriétaire, une version et un périmètre — pas comme une préférence d'éditeur de texte.

Le comparatif des trois couches de sécurité IA et le guide sécurité des IA génératives détaillent le reste.

6. La méthode en 7 étapes

1. Inventorier. Recenser les huit familles, y compris l'IA embarquée dans les SaaS validés et les copilotes installés en Shadow. Prérequis absolu : le registre des usages IA.

2. Classer par rôle. Déployeur ou fournisseur ? Et surtout : consigner, au moment où il a lieu, tout geste susceptible de déclencher la bascule — fine-tuning, wrapping sous marque, ré-entraînement, ajout d'un module de décision.

3. Classer par risque. Transparence par défaut ; haut risque si la finalité le déclenche ; marquage des contenus générés diffusés.

4. Qualifier au RGPD. Brancher le registre IA sur le registre des traitements (art. 30), AIPD si le traitement est à risque élevé (art. 35), sécurité du code et des connecteurs (art. 32).

5. Résilience. Inscrire les fournisseurs de modèles et de cloud d'inférence au registre des prestataires TIC, et intégrer l'IA à la gestion des risques et à la chaîne de notification d'incident.

6. Préparer la traçabilité et la supervision. La journalisation (art. 12) et la supervision humaine (art. 14) s'imposeront au 2 décembre 2027 pour les systèmes à haut risque. Le RGPD et l'ANSSI, eux, les recommandent déjà — et pour les agents autonomes et leurs connecteurs, allow-list et point d'arrêt relèvent de la sécurité courante, pas d'une échéance.

7. Gouverner et prouver. Un propriétaire par système, un registre vivant, des journaux. La preuve, pas la promesse.

L'ordre n'est pas négociable : tout dépend de la première étape.

7. Les quatre choses à consigner dès cette semaine

Tout ce qui précède se résume à une poignée de gestes, et aucun n'est juridique.

Un. La liste des copilotes de code réellement installés. Pas ceux qui figurent au contrat cadre : ceux qui tournent, y compris arrivés par abonnement individuel ou par extension. C'est la famille la plus répandue en Shadow AI et la plus facile à recenser — elle laisse des traces dans les journaux d'accès et les dépenses.

Deux. Un journal des modifications substantielles. Une ligne par geste : quel système, quelle date, quel auteur, quelles données, quelle version. C'est le seul artefact de tout ce dossier qui ne se reconstitue pas après coup, et il coûte deux minutes au moment où le geste a lieu.

Trois. Le raccordement du registre TIC. Ouvrir le registre DORA existant et vérifier, ligne par ligne, si les fournisseurs de modèles et les clouds d'inférence y figurent. Dans la plupart des entités financières, la réponse est non — et c'est constatable aujourd'hui, sans attendre 2027.

Quatre. La qualification du périmètre NIS2. Entité essentielle, entité importante, ou hors champ ? La question se tranche sur le secteur et la taille, pas sur la technologie, et elle ne demande pas que la loi soit promulguée pour être posée.

Aucun de ces quatre points n'exige un budget, un cabinet ou un comité. Ils exigent de savoir ce qui tourne — ce qui est précisément l'étape que le report de décembre 2027 n'a pas décalée.

8. Qui fait quoi

La DSI ne gouverne pas seule. Le RSSI porte la sécurité du code, le SOC et les incidents. Le DPO porte le RGPD, le registre et l'AIPD. Les achats portent les clauses fournisseurs et le registre TIC. Les directions métier portent les finalités, qui sont ce qui déclenche le haut risque. La direction générale portera la responsabilité NIS2.

Le rôle propre de la DSI est plus étroit et plus décisif : elle est la seule fonction qui sait qu'un geste technique vient de changer le statut réglementaire de l'organisation. Personne d'autre ne peut le voir — cela se passe dans un dépôt de code, pas dans un contrat, et aucune revue juridique ne lit les commits.

Deux directions sont systématiquement oubliées de cette table. Les achats, parce que les clauses fournisseurs et le registre TIC se négocient au moment de la signature, pas au moment du contrôle. Et les directions métier, parce que ce sont elles qui décident des finalités — donc elles qui, sans le savoir, font basculer un outil dans l'annexe III en lui demandant un nouvel usage.

Le cadre de gouvernance et la répartition des rôles posent le reste.

9. Les sanctions, et le vrai risque

AI Act : 35 M€ ou 7 % (art. 5), 15 M€ ou 3 % (autres obligations, dont l'art. 50). RGPD : 20 M€ ou 4 %. NIS2, une fois transposée : 10 M€ ou 2 %, avec responsabilité personnelle des dirigeants. DORA : sanctions sectorielles.

Le risque réel n'est pas le plafond, c'est le cumul : un même incident peut ouvrir plusieurs procédures, et chacune peut retenir l'autre comme circonstance aggravante.

Et pour une DSI, le risque le plus probable n'est ni l'amende ni le contrôle. C'est le questionnaire sécurité d'un grand compte, qui demande la liste des systèmes d'IA, leur hébergement et le rôle de l'entreprise dans la chaîne de valeur — et qui arrive, lui, sans préavis et sans échéance réglementaire. Une réponse vide ne se sanctionne pas : elle fait perdre l'affaire.

Ce qui ne peut pas attendre 2027

La DSI qui attend décembre 2027 n'accumule pas une dette de conformité — elle accumule une dette de mémoire. Les obligations arriveront à date connue ; ce qui ne se rattrape pas, c'est la trace des gestes posés entre-temps.

La sortie n'est pas un catalogue de formations. C'est un inventaire vivant qui sait, pour chaque système d'IA du SI : quel rôle, quel risque, quelle résilience, quelle preuve. C'est exactement ce que SiyadAI rend automatique.

Pour aller plus loin

• Comparatif — DSI : rôle, risque, résilience
• Checklist — L'IA du système d'information (24 points)
• Trame — Registre de l'IA du SI et des prestataires TIC
• Une DSI peut-elle devenir fournisseur au sens de l'AI Act ?
• Le report du haut risque dispense-t-il la DSI de tout ?
• NIS2 est-elle applicable en France ?