Vos 320 questions, classées par thématique.

Oui. Le report vise les exigences des systèmes à haut risque de l'annexe III, au 2 décembre 2027. L'article 5 (pratiques interdites), l'article 4 (maîtrise de l'IA), l'article 50 (transparence), les règles GPAI, le RGPD intégral et DORA s'appliquent déjà au système d'information.

Il détermine qui, dans la chaîne de valeur, est fournisseur. Un déployeur le devient s'il appose sa marque sur un système déjà mis sur le marché, s'il y apporte une modification substantielle en le maintenant à haut risque, ou s'il en détourne la finalité au point de le rendre haut risque.

Non. Les obligations qu'elle transfère — documentation technique, gestion des risques, surveillance après commercialisation, déclaration d'incident — sont des obligations de système à haut risque, que le règlement (UE) 2026/1744 reporte au 2 décembre 2027 pour l'annexe III et au 2 août 2028 pour l'annexe I. Ce qui est urgent, c'est la trace du geste, pas la sanction.

Cela peut. Si la modification est substantielle et que le système reste ou devient à haut risque, l'organisation bascule au sens de l'article 25. La conséquence pratique immédiate est de consigner le geste — données, version, auteur, date — parce que le dossier sera exigible en décembre 2027 et ne se reconstitue pas.

Si l'outil est exposé à des tiers sous votre nom ou votre marque, ou si vous en modifiez substantiellement la finalité, vous pouvez devenir fournisseur. Un usage strictement interne, sans modification substantielle, reste un déploiement.

Il relève au minimum de la transparence (art. 50) et de la maîtrise de l'IA (art. 4). Il n'est pas classé à haut risque par nature. En revanche la sécurité du code qu'il produit relève de l'article 32 du RGPD, applicable sans réserve ni report.

Les tests publics convergent autour de 45 % de code vulnérable en sortie d'assistant de programmation. L'ANSSI et le BSI ont copublié des recommandations : précaution dès la conception, vigilance sur les services partagés exposés à Internet, préférence pour des solutions éditeur cadrées.

Parce qu'un outil perçu comme « assez intelligent » abaisse la vigilance du relecteur. C'est le biais d'automatisation appliqué au delivery : le risque n'est pas seulement dans le code produit, il est dans l'attention qu'on cesse de lui porter.

Pas encore. La loi de transposition — le projet de loi de résilience des infrastructures critiques — n'est pas promulguée. Le Sénat l'a adoptée le 12 mars 2025, la commission spéciale de l'Assemblée a amendé le texte le 10 septembre 2025, et l'examen en séance publique est repoussé à septembre 2026 au plus tôt.

Environ 15 000 entités réparties sur 18 secteurs, contre quelque 300 sous NIS1. L'ANSSI sera l'autorité nationale, avec la plateforme MonEspaceNIS2 pour l'enregistrement.

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, avec une responsabilité qui remonte personnellement aux dirigeants. Elles s'appliqueront une fois la loi française promulguée.

DORA — règlement (UE) 2022/2554, applicable depuis le 17 janvier 2025 — impose aux entités financières et à leurs prestataires TIC critiques un cadre de résilience opérationnelle et un registre d'information des prestataires TIC. C'est le seul volet de résilience déjà opposable.

Oui, dès lors qu'il fournit un service TIC contractualisé. Fournisseur de modèle, cloud d'inférence, API LLM : ils doivent figurer au registre d'information et entrer dans la gestion des risques de tiers. Beaucoup de registres ont été remis sans les briques IA.

Sous conditions strictes, et l'inférence des émotions au travail est interdite depuis le 2 février 2025 par l'article 5 de l'AI Act, avec un plafond de 35 M€ ou 7 % du chiffre d'affaires mondial. Le RGPD et le Code du travail encadrent par ailleurs toute surveillance.

Oui si le traitement présente un risque élevé pour les droits et libertés (art. 35 RGPD). C'est fréquent pour les IA de sécurité traitant des journaux nominatifs, les agents ITSM traitant des données RH, et toute automatisation décisionnelle.

L'article 50(2) s'applique depuis le 2 août 2026. Le 2 décembre 2026 est la fin d'une période de grâce réservée aux systèmes déjà sur le marché avant le 2 août : un outil mis en service après cette date n'a aucun délai. La solution d'interopérabilité de détection des filigranes vient au 2 février 2027.

Oui, en tant que systèmes d'IA. La traçabilité (art. 12) et la supervision humaine (art. 14) leur seront imposées au 2 décembre 2027 pour les systèmes à haut risque ; le RGPD et les recommandations de l'ANSSI, eux, s'appliquent dès aujourd'hui, comme l'allow-list et le point d'arrêt sur les connecteurs.

Les trois, sur des périmètres complémentaires. La DSI cartographie et repère les gestes qui déclenchent la bascule de l'article 25 ; le RSSI porte la sécurité et les incidents ; le DPO porte le RGPD et l'AIPD. Sous NIS2, la responsabilité remontera à la direction générale.

C'est le principal vecteur de Shadow AI : une fonctionnalité IA activée dans une mise à jour d'un outil déjà approuvé échappe à toute revue, puisque l'outil, lui, avait été validé. Elle doit être ré-inventoriée à chaque activation.

Par l'inventaire des huit familles d'IA du système d'information. Sans lui, aucune classification par rôle, risque ou résilience n'est possible — et la maîtrise de l'IA (art. 4), exigible aujourd'hui, ne se prouve pas sur un système qu'on n'a pas cartographié.

Oui. La plupart des systèmes marketing ne sont pas « à haut risque », mais ils relèvent de l'article 50 (transparence des chatbots et contenus générés), de l'article 5 (interdiction de la manipulation) et du RGPD (profilage, consentement). Ces trois régimes sont en vigueur.

Pas en totalité. Le Digital Omnibus a reporté la classification haut risque de l'annexe III au 2 décembre 2027. Il n'a touché ni à l'article 50 (transparence, applicable depuis le 2 août 2026), ni à l'article 5 (interdictions, applicables depuis le 2 février 2025).

C'est la fin d'une période de grâce, réservée aux systèmes d'IA générative DÉJÀ sur le marché avant le 2 août 2026, pour se conformer au marquage lisible par machine (art. 50(2)). Un système mis en service après le 2 août 2026 n'a aucun délai : l'obligation s'applique immédiatement.

Le 2 février 2027 : mise à disposition de la solution d'interopérabilité permettant la détection des filigranes entre systèmes.

Oui, depuis le 2 août 2026. L'article 50 impose d'informer clairement toute personne qu'elle interagit avec un système d'IA, dès le début de l'échange, sauf si c'est manifestement évident. Un agent présenté sous un prénom humain sans mention n'est pas conforme.

Dans l'interface de conversation elle-même, au premier message — pas dans les conditions générales ni sur une page annexe. La même règle vaut pour les voicebots.

Oui. Les contenus de synthèse doivent être marqués dans un format lisible par machine. L'obligation de marquage pèse sur le fournisseur du générateur ; le déployeur, lui, porte l'obligation de divulgation pour les deepfakes et ne doit pas retirer le marquage.

Un contenu image, audio ou vidéo généré ou manipulé par IA qui ressemble à des personnes, objets ou événements réels et pourrait être perçu à tort comme authentique. Il doit être signalé comme artificiellement généré ou manipulé.

Oui, à trois conditions : le signaler comme généré par IA (art. 50), respecter le droit à l'image, et ne pas induire le public en erreur de manière préjudiciable — auquel cas l'article 5 s'appliquerait.

Les techniques subliminales ou délibérément manipulatrices qui altèrent substantiellement le comportement en causant un préjudice important, et l'exploitation des vulnérabilités liées à l'âge, au handicap ou à la situation économique et sociale. Sanction jusqu'à 35 M€ ou 7 % du chiffre d'affaires mondial.

Non. La recommandation n'est pas interdite en soi. Elle bascule dans l'interdiction si elle exploite une vulnérabilité — cibler une détresse financière, par exemple — pour pousser un produit au détriment de la personne.

Principalement du RGPD. Sans interaction avec la personne, l'article 50 ne s'applique pas ; en revanche il s'agit d'un profilage, et l'article 22 du RGPD s'applique dès qu'une décision à effet significatif est prise sur une base exclusivement automatisée.

Que l'établissement d'un score de probabilité peut constituer une décision individuelle automatisée au sens de l'article 22 du RGPD, même lorsqu'un tiers l'utilise ensuite. La supervision humaine attendue est réelle, pas une validation de forme.

Vous êtes généralement déployeur lorsque vous utilisez un outil tiers. Vous devenez fournisseur si vous développez un système ou le modifiez substantiellement et le mettez sur le marché sous votre nom. Les obligations diffèrent : marquage pour le fournisseur, divulgation pour le déployeur.

Non. La transparence est une brique parmi trois. Il faut aussi respecter le RGPD (base légale, consentement) et l'article 5 (non-manipulation), et pouvoir prouver la conformité par un registre et des journaux.

Jusqu'à 15 M€ ou 3 % du chiffre d'affaires mondial pour l'article 50, 35 M€ ou 7 % pour l'article 5, 20 M€ ou 4 % pour le RGPD. Les procédures peuvent se cumuler sur un même incident et se servir mutuellement de circonstance aggravante.

Les outils d'IA employés par les équipes sans validation ni inventaire : abonnements individuels, extensions de navigateur, fonctions génératives activées par défaut dans des suites existantes. C'est le principal angle mort, puisqu'on ne peut ni marquer ni prouver ce qu'on ne connaît pas.

Par l'inventaire : recenser les systèmes d'IA du périmètre marketing, leurs fournisseurs, les données consommées et les contenus produits. Toutes les autres étapes en dépendent.

Souvent, oui — lorsque le profilage est à grande échelle ou porte sur des personnes vulnérables. L'AIPD (art. 35 RGPD) évalue les risques pour les personnes ; elle est distincte de la FRIA prévue par l'AI Act.

Rarement. Trois cas : systèmes visant des enfants ou des personnes vulnérables avec effets comportementaux importants, personnalisation adossée à un service essentiel (crédit, assurance), et catégorisation biométrique déduisant des données sensibles.

Oui. L'annexe III, point 5 b) classe à haut risque les systèmes d'IA destinés à évaluer la solvabilité ou à établir la note de crédit des personnes physiques, sauf ceux utilisés pour détecter la fraude financière.

Oui pour l'assurance-vie et l'assurance santé : l'annexe III, point 5 c) classe à haut risque les systèmes d'IA d'évaluation des risques et de tarification à l'égard des personnes physiques dans ces deux branches. Les autres branches n'y sont pas visées.

Non. Il a reporté leur entrée en application au 2 décembre 2027 pour les systèmes autonomes de l'annexe III (règlement (UE) 2026/1744). Le report est inconditionnel mais ne concerne que le bloc haut risque.

Les pratiques interdites (art. 5), la transparence (art. 50), la maîtrise de l'IA (art. 4), la gouvernance et les sanctions (art. 99), les règles GPAI — ainsi que le RGPD, DORA et Solvabilité II, qui ne dépendent pas de l'AI Act.

Parce que l'IA de décision y est déjà encadrée par le RGPD (art. 22, arrêt SCHUFA), par DORA depuis janvier 2025, et par la supervision de l'ACPR. Le report AI Act ne suspend aucune de ces obligations.

Le 7 décembre 2023 (C-634/21), la Cour a jugé que l'établissement automatisé d'un score de solvabilité est une décision individuelle automatisée au sens de l'article 22 du RGPD, dès lors qu'un tiers fonde sa décision de manière déterminante sur ce score.

Non si elle est purement formelle. La supervision humaine doit être effective : l'agent doit pouvoir réexaminer et s'écarter du score. Une approbation de façade laisse la décision qualifiée d'automatisée.

L'ACPR, désignée autorité de surveillance du marché au titre du règlement (UE) 2024/1689 pour les cas d'usage à haut risque liés aux services financiers. Elle exercera ces responsabilités à compter du 2 décembre 2027, en coopération avec les autres autorités nationales et européennes compétentes.

Oui. Elle travaille sur la gouvernance des algorithmes depuis 2019 et a soumis à consultation publique, jusqu'au 30 septembre 2026, un document de réflexion sur l'équité algorithmique dans le secteur financier — ouvert aux banques, assureurs, fintechs, insurtechs, associations de consommateurs et experts académiques.

Les principes et méthodes visant à concevoir et encadrer les systèmes de façon à prévenir les inégalités injustifiées, notamment celles liées à des caractéristiques personnelles sensibles. L'enjeu propre à la finance : concilier la différenciation tarifaire selon le risque avec la prévention d'un traitement discriminatoire.

Un moteur de scoring ou de tarification reposant sur un fournisseur d'IA ou de cloud tiers entre dans le registre des prestataires TIC de DORA, avec clauses contractuelles obligatoires, gestion du risque tiers et tests de résilience. DORA s'applique depuis le 17 janvier 2025.

Le plus souvent déployeur : elle utilise un système acheté ou co-construit. Elle est fournisseur si elle développe et met sur le marché son propre système. Les deux qualités emportent des obligations distinctes, et la conformité du fournisseur n'exonère pas le déployeur.

Oui en règle générale : un scoring à grande échelle avec évaluation systématique de personnes relève de l'analyse d'impact relative à la protection des données (art. 35 RGPD). Elle est due indépendamment du calendrier AI Act.

Non : l'annexe III 5 b) exclut expressément les systèmes utilisés pour détecter la fraude financière. Ils restent toutefois soumis au RGPD et à la traçabilité.

Jusqu'à 35 M€ ou 7 % du chiffre d'affaires mondial pour les infractions les plus graves à l'AI Act (art. 99), en sus des sanctions RGPD (jusqu'à 4 % du chiffre d'affaires) et des suites prudentielles.

La FRIA (analyse d'impact sur les droits fondamentaux, art. 27) vise notamment les déployeurs assurant un service public et certains cas de l'annexe III. Elle complète l'AIPD et peut concerner des acteurs financiers selon leur mission.

L'inventaire des systèmes, leur classification annexe III justifiée, l'AIPD, la preuve de supervision humaine effective, les journaux de décisions et de versions de modèles, la documentation des données et des tests de biais, et le rattachement à une gouvernance.

Par l'inventaire : recenser tous les systèmes d'IA touchant une décision client — crédit, tarification, résiliation, appétence, LCB-FT. Sans inventaire, aucune classification ni preuve n'est possible.

Court pour un grand établissement : cartographier tous les modèles, documenter les données d'entraînement, instrumenter la journalisation et prouver une supervision humaine effective sur des chaînes souvent externalisées prend plusieurs mois par système.

En traitant chaque système une seule fois avec un dossier commun : inventaire, classification, AIPD, supervision, traçabilité, données et biais. Le même dossier répond simultanément au RGPD, à DORA, à Solvabilité II, à l'ACPR et à l'AI Act.

Il impose aux fournisseurs et déployeurs de systèmes d'IA de prendre des mesures pour assurer un niveau suffisant de maîtrise de l'IA de leur personnel et des personnes utilisant l'IA pour leur compte, adapté à leurs connaissances, à leur rôle et au contexte d'usage.

Depuis le 2 février 2025. L'obligation est déjà en vigueur ; seule la supervision par les autorités arrive plus tard.

Les autorités nationales de surveillance du marché acquièrent leurs pouvoirs formels de supervision de l'article 4, au moment où l'article 50 sur la transparence devient pleinement applicable.

Non. Le Règlement (UE) 2026/1744 a assoupli le standard, d'une obligation de garantir un niveau suffisant vers une obligation de soutenir son développement, mais n'a ni reporté ni supprimé l'obligation.

Une obligation de prendre des mesures proportionnées et documentées, sans garantie de résultat. On la respecte en prouvant le moyen : plan, contenus, attestations, mises à jour.

Les sanctions autonomes seront rares. Le risque réel : une lacune documentée devient circonstance aggravante dans d'autres enquêtes AI Act, et le canal RGPD (jusqu'à 4 % du chiffre d'affaires mondial) lorsqu'un traitement illicite est en cause.

Tous les collaborateurs qui utilisent l'IA, pas seulement les équipes techniques : commerciaux, RH, juristes, marketing, support, ainsi que les prestataires agissant pour votre compte.

Non. Elle s'applique à tous les systèmes d'IA, y compris un simple chatbot ou un assistant de rédaction, ainsi qu'à l'IA embarquée dans vos logiciels.

Aucun format n'est imposé. Formation en ligne, ateliers, notes internes, questionnaires, charte signée : les mesures doivent être proportionnées au contexte. Une sensibilisation documentée suffit pour la majorité des collaborateurs.

La pratique de place converge vers cinq ans : plans, supports, attestations, feuilles d'émargement, évaluations.

En documentant le moyen : plan annuel de maîtrise, contenus, attestations rattachées aux personnes et aux systèmes qu'elles utilisent, calendrier de mise à jour, questionnaires d'évaluation.

Parce qu'un plan adapté aux rôles et au contexte suppose de savoir quels systèmes sont utilisés et par qui. Sans inventaire, le plan est générique et ne prouve rien.

Oui. Les usages non déclarés font partie des systèmes d'IA utilisés pour votre compte ; ils doivent être détectés puis couverts par la maîtrise.

L'organisation, fournisseur ou déployeur. En pratique : direction pour les moyens, DPO pour le lien RGPD, RSSI pour la sécurité, DSI pour les outils, RH et formation pour le déploiement et la preuve. Un comité ou un référent IA évite la dilution.

La maîtrise de l'IA couvre les possibilités, limites et risques propres à l'IA — biais, hallucinations, fuite de données, dépendance — et son cadre juridique. La cybersécurité classique n'aborde pas ces dimensions.

Non pour se défendre efficacement. Il faut une maîtrise proportionnée au rôle et rattachée aux systèmes réellement utilisés, sinon il ne démontre pas que les bonnes personnes ont été formées.

Au minimum annuellement, et à chaque nouvel outil, nouvel arrivant ou nouvel usage à risque. La maîtrise est un processus continu, pas un événement.

Oui, sans seuil d'effectif. Les mesures doivent être proportionnées aux moyens et au contexte, mais l'obligation existe pour toute organisation déployant de l'IA.

La maîtrise réduit le risque sur les traitements de données assistés par IA. Une lacune ayant contribué à un traitement illicite expose au régime de sanctions RGPD, jusqu'à 4 % du chiffre d'affaires mondial.

Cartographier les usages d'IA, Shadow AI compris, segmenter par rôles, déployer des mesures proportionnées et constituer la preuve. L'inventaire est le préalable.

Non, elle n'est pas interdite mais classée à haut risque. L'annexe III, point 4 range les systèmes de tri, de scoring et d'évaluation des candidats parmi les systèmes à haut risque, soumis à des obligations renforcées. Seule l'inférence d'émotions est interdite (article 5).

Oui. L'article 5 de l'AI Act interdit les systèmes d'IA destinés à inférer les émotions d'une personne sur son lieu de travail, depuis le 2 février 2025. Une exception étroite existe pour un objectif médical ou de sécurité au sens strict. La sanction peut atteindre 35 M€ ou 7 % du CA mondial.

Oui, dès lors qu'il analyse, filtre, score ou présélectionne des candidatures. L'annexe III, point 4 vise explicitement ces usages. Le classement automatique de CV est l'exemple type du haut risque RH.

Non, en principe. L'article 22 du RGPD interdit la décision fondée exclusivement sur un traitement automatisé produisant des effets significatifs. Une vraie intervention humaine, capable de contredire le score, est nécessaire — une simple validation formelle ne suffit pas.

Oui. L'introduction d'un dispositif de traitement automatisé des données du personnel ou de contrôle de l'activité relève de l'information-consultation du CSE (art. L.2312-38 du Code du travail). Faute de consultation, le dispositif est inopposable et le délit d'entrave peut être caractérisé.

Oui, dans la plupart des cas. L'évaluation systématique de personnes à grande échelle remplit plusieurs critères de la liste EDPB, ce qui rend l'analyse d'impact obligatoire avant la mise en œuvre (art. 35 du RGPD).

Oui. Le recrutement figure parmi ses thématiques de contrôle prioritaires pour 2026, avec une attention aux outils d'IA de tri et de scoring, en visant d'abord les grandes entreprises et les cabinets de recrutement. Ces contrôles préfigurent son rôle d'autorité de surveillance du marché « travail » sous l'AI Act.

Non. Il décale les obligations haut risque de l'annexe III au 2 décembre 2027, mais ne touche ni l'interdiction des émotions (art. 5, applicable depuis février 2025), ni le RGPD, ni le Code du travail — les cadres sur lesquels vous êtes contrôlé aujourd'hui.

Oui. Aucun dispositif de contrôle de l'activité n'est opposable au salarié s'il n'en a pas été informé au préalable (art. L.1222-4 du Code du travail). L'information individuelle est une condition de validité, pas une formalité.

Les deux, à des titres différents. L'éditeur est « fournisseur » et doit rendre le système conforme. L'employeur est « déployeur » et porte ses propres obligations (art. 26) : information des travailleurs, supervision humaine, usage conforme. La conformité du fournisseur n'exonère pas le déployeur.

Partiellement, et le report est désormais acquis. Le paquet « Digital Omnibus » a été adopté par le Parlement européen le 16 juin 2026 puis par le Conseil le 29 juin 2026 : les obligations sur les systèmes à haut risque de l'annexe III s'appliquent à compter du 2 décembre 2027. Attention au contresens : ce report ne touche ni les pratiques interdites (article 5) ni l'obligation de maîtrise de l'IA (article 4), applicables depuis le 2 février 2025, ni les obligations de transparence de l'article 50, applicables depuis le 2 août 2026, ni le RGPD, ni le droit national. Votre exposition immédiate n'a pas bougé.

C'est un paquet législatif européen de simplification du cadre numérique de l'UE, adopté par le Parlement le 16 juin 2026 et par le Conseil le 29 juin 2026. Il décale les échéances les plus lourdes de l'AI Act (haut risque annexe III au 2 décembre 2027) sans suspendre les obligations déjà en vigueur : interdictions de l'article 5, littératie IA de l'article 4, transparence GPAI et gouvernance restent applicables.

La littératie IA (article 4), les obligations de transparence des modèles GPAI, les interdictions de pratiques prohibées, la gouvernance institutionnelle, et l'activation des pouvoirs de sanction.

Jusqu'à 35 M€ ou 7 % du chiffre d'affaires mondial pour les manquements les plus graves. Un premier palier atteint 15 M€ ou 3 % du CA, et couvre désormais les manquements aux obligations d'information dans la chaîne de valeur.

Si vous développez, déployez ou utilisez des systèmes d'IA (y compris des chatbots, copilotes ou IA générative), oui. L'obligation de littératie IA concerne toutes les organisations utilisatrices.

C'est l'obligation de garantir un niveau suffisant de compétence en IA chez les personnes qui utilisent ou supervisent des systèmes d'IA. Elle est applicable depuis février 2025.

C'est l'usage d'outils d'IA non autorisés ou non encadrés par l'organisation. En 2026, 98 % des organisations sont concernées et 93 % de l'usage de ChatGPT en entreprise passe par des comptes personnels.

Parce qu'on ne peut pas gouverner, documenter ni sécuriser des usages qu'on ne voit pas. Le Shadow AI échappe à la politique de données, au RGPD et au cadre AI Act.

En identifiant tous les outils IA utilisés (autorisés et Shadow AI), par service et par type de données traitées. SiyadAI automatise cette cartographie sans projet de plusieurs mois.

Les domaines de l'annexe III : recrutement, scoring de crédit, éducation, biométrie, justice, services essentiels, infrastructures critiques, et gestion de la migration/asile.

Oui, le report est adopté : 2 décembre 2027 pour l'annexe III, 2028 pour les produits réglementés de l'annexe I. Mais il ne couvre que ces obligations-là. Les pratiques interdites (article 5), la littératie IA (article 4), le RGPD et le droit national continuent de s'appliquer sans délai — c'est sur ces fondements que les autorités contrôlent aujourd'hui.

Non. Installer une gouvernance, cartographier les usages et documenter les systèmes prend des mois. Attendre 2027 revient à devoir tout construire en urgence, en restant exposé aux sanctions actives entre-temps.

C'est l'obligation de respecter simultanément le socle déjà applicable de l'AI Act et de préparer les obligations « haut risque » qui arrivent en décembre 2027.

L'AI Act est une obligation légale européenne. ISO/IEC 42001 est une norme volontaire de système de management de l'IA. Mettre en place ISO 42001 facilite et structure la conformité à l'AI Act.

ISO/IEC 42001:2023 est la première norme internationale de système de management de l'intelligence artificielle (AIMS). Elle définit gouvernance, gestion des risques et amélioration continue des usages IA.

Oui, indirectement. Si vous intégrez des modèles GPAI dans vos produits ou processus, la responsabilité « aval » de la chaîne de valeur peut vous concerner, notamment via les obligations d'information.

L'AI Office européen, ainsi que les autorités nationales de surveillance désignées par chaque État membre. En France, plusieurs autorités (dont la CNIL) interviennent selon les usages.

1) Cartographier les usages IA réels ; 2) les classer par niveau de risque ; 3) installer une gouvernance ; 4) déployer la littératie IA ; 5) documenter et tracer.

Non. Un tableur fige une photo périmée dès le lendemain et ne détecte pas le Shadow AI. Une plateforme dédiée maintient une vue vivante des usages et des obligations.

SiyadAI cartographie automatiquement les usages IA (Shadow AI inclus), les classe par niveau de risque, génère le registre et la documentation attendus, et pilote la conformité AI Act et ISO 42001 depuis un tableau de bord unique.

La gouvernance de l'IA est l'ensemble des politiques, rôles, processus et outils par lesquels une organisation encadre le cycle de vie de ses systèmes d'intelligence artificielle, afin de garantir des usages sûrs, conformes et alignés sur sa stratégie. Elle couvre l'IA développée, achetée, intégrée et subie (Shadow AI).

Sans gouvernance, une entreprise cumule trois risques : juridique (sanctions AI Act et RGPD), sécurité (fuite de données via des outils non validés) et stratégique (usages anarchiques sans valeur capturée). La gouvernance transforme un usage subi en usage piloté.

La responsabilité ultime revient à la Direction générale. Elle est opérée par un comité IA transverse réunissant le RSSI (sécurité), le DPO (conformité RGPD), la DSI (intégration technique), les métiers (cas d'usage) et les RH/juridique.

La conformité AI Act est une obligation réglementaire précise. La gouvernance de l'IA est le cadre organisationnel plus large qui permet de satisfaire l'AI Act, mais aussi le RGPD, l'ISO 42001 et les bonnes pratiques de sécurité, à partir d'une source unique de vérité.

Par la visibilité : cartographier les usages et systèmes d'IA réellement utilisés dans l'entreprise. On ne gouverne pas ce qu'on ne voit pas. Le registre des usages est la fondation de tout le reste.

C'est l'inventaire structuré des systèmes d'IA de l'organisation : quels outils, par qui, pour quelles finalités, avec quelles données, à quel niveau de risque. Il sert de socle documentaire commun à l'AI Act, au RGPD et à l'ISO 42001.

Un document interne qui définit ce qui est autorisé, encadré ou interdit en matière d'IA : outils validés, données proscrites, cas d'usage sensibles, procédures de validation et responsabilités. Sa version pédagogique et accessible s'appelle la charte IA.

La politique IA est le document de référence détaillé (règles, procédures, responsabilités). La charte IA en est la version courte, lisible par tous les salariés, qui rappelle les principes et les bons réflexes au quotidien.

Le comité IA est l'instance de pilotage transverse qui valide la politique, arbitre les cas d'usage sensibles et suit le registre. Il réunit Direction, RSSI, DPO, DSI, métiers et RH, généralement de façon trimestrielle, pour suivre le rythme d'évolution des outils.

Elle n'est pas nommée « obligatoire » en tant que telle, mais elle est la condition pratique pour respecter l'AI Act (transparence, documentation, littératie), le RGPD (AIPD, bases légales) et démontrer une maîtrise des risques. En pratique, elle est incontournable en 2026.

Le Shadow AI désigne l'usage d'outils d'IA non validés par l'entreprise, souvent des SaaS grand public. C'est le principal angle mort. Une gouvernance efficace le rend visible et le ramène dans un cadre maîtrisé plutôt que de l'interdire à l'aveugle.

Le RSSI est garant de la sécurité : contrôle des flux de données, prévention des fuites (DLP), évaluation des risques de sécurité des outils, sécurisation des IA génératives et gestion des incidents. Il est souvent le pilote naturel du registre des usages.

Le DPO est garant de la conformité RGPD : bases légales, réalisation des analyses d'impact (AIPD), gestion des droits des personnes et articulation entre RGPD et AI Act. Son rôle de conseil est essentiel pour tout usage traitant des données personnelles.

En reprenant l'esprit de l'AI Act : usages interdits, usages à haut risque, usages à risque limité (soumis à transparence) et usages à risque minimal. Cette classification détermine les contrôles et les priorités.

L'ISO/IEC 42001 est la norme internationale de système de management de l'IA (AIMS). Elle structure et certifie la démarche de gouvernance. Attention : une certification ISO 42001 ne vaut pas présomption de conformité à l'AI Act ; les deux sont complémentaires.

Une première cartographie et la constitution du comité IA peuvent être réalisées en quelques semaines. La gouvernance complète (politique, garde-fous, formation) se déploie sur quelques mois, puis devient un processus continu.

Non, l'inverse. Sans cadre, les usages restent dispersés, non fiables et non capitalisés. La gouvernance permet de déployer l'IA à l'échelle en confiance, en supprimant l'incertitude qui bloque les décisions.

L'article 4 de l'AI Act impose que les personnes qui déploient ou utilisent des systèmes d'IA disposent d'un niveau suffisant de compréhension. Concrètement, cela se traduit par des actions de formation et de sensibilisation intégrées à la gouvernance.

Oui. Dès qu'une PME utilise des outils d'IA — y compris grand public comme ChatGPT ou Copilot — elle est concernée. Le cadre se dimensionne à sa taille, mais les principes (visibilité, rôles, règles, contrôle) restent les mêmes.

SiyadAI construit et maintient automatiquement le registre des usages d'IA : détection des outils réellement utilisés (y compris Shadow AI), cartographie des données exposées, classification des risques et tableau de bord pour le comité IA. La gouvernance devient un système piloté plutôt qu'un document théorique.

C'est l'ensemble des mesures techniques et organisationnelles visant à protéger les systèmes fondés sur des modèles de langage (copilotes, chatbots, RAG, agents) contre le détournement, la fuite de données et les actions non autorisées. Elle s'appuie sur des référentiels comme l'OWASP Top 10 for LLM Applications et les recommandations de l'ANSSI.

C'est un référentiel publié par l'OWASP qui classe les dix risques de sécurité majeurs des applications fondées sur des LLM. La version 2025 va de l'injection de prompt (LLM01) à la consommation non bornée (LLM10).

L'injection de prompt (LLM01). Une entrée en langage naturel manipule le comportement du modèle, pouvant contourner ses garde-fous ou déclencher des actions via des outils connectés.

En injection directe, l'utilisateur manipule lui-même le modèle par ses instructions. En injection indirecte, l'instruction malveillante est cachée dans une source externe (e-mail, page web, document) que le modèle consulte.

L'ANSSI a publié en avril 2024 le guide ANSSI-PA-102 avec 35 recommandations couvrant les trois phases du cycle de vie d'un système d'IA générative : entraînement, intégration/déploiement et production.

35 recommandations, réparties sur les trois phases du cycle de vie et destinées aux RSSI, DSI, data scientists et data engineers.

C'est le risque LLM06 : un système IA dispose de trop de permissions, d'outils ou d'autonomie. Une manipulation se traduit alors par une action réelle et potentiellement destructrice.

Oui. Un chatbot répond ; un agent agit (appelle des outils, exécute des requêtes, envoie des e-mails). Une manipulation d'agent peut provoquer des actions non autorisées, pas seulement une mauvaise réponse.

De trois façons : des collaborateurs collent des données sensibles dans des services grand public ; un système RAG expose des documents mal cloisonnés ; le modèle restitue des informations confidentielles apprises ou accessibles (risque LLM02).

Le RAG (Retrieval-Augmented Generation) enrichit les réponses du modèle avec des documents internes via une base vectorielle. Mal cloisonnée, cette base peut laisser fuiter des données entre équipes ou être empoisonnée (risque LLM08).

Indirectement, oui. L'article 15 de l'AI Act impose robustesse et cybersécurité aux systèmes à haut risque, le RGPD s'applique aux données personnelles, et l'ISO/IEC 42001 exige une maîtrise des risques IA.

La sécurité protège techniquement les systèmes (confidentialité, intégrité, disponibilité). La gouvernance encadre l'usage de l'IA (rôles, politiques, conformité). Les deux sont complémentaires et doivent partager un registre commun.

La Shadow AI désigne les usages d'IA non déclarés et non encadrés. On ne peut sécuriser que ce que l'on connaît : ces usages invisibles constituent un angle mort majeur de la sécurité.

Par la cartographie : recenser tous les systèmes d'IA (officiels, expérimentaux, non déclarés), puis les classifier par risque avant d'appliquer les référentiels OWASP et ANSSI.

C'est l'exposition des instructions internes d'un système IA (règles, secrets, logique métier), qui peut révéler son fonctionnement et faciliter d'autres attaques. Nouvelle catégorie de l'OWASP 2025.

Injection de prompt, fuite de données sensibles, agence excessive, faiblesses du RAG/bases vectorielles, et gouvernance de la Shadow AI.

Oui. Tester un système IA en conditions adverses (tentatives d'injection, de contournement, d'abus d'outils) avant sa mise en production est une bonne pratique recommandée, notamment pour les agents.

Ce sont les trois familles de scénarios décrites par l'ANSSI : manipulation (détourner le comportement), infection (empoisonner données ou chaîne d'approvisionnement) et exfiltration (extraire données ou modèle).

Oui. L'article 15 exige des systèmes à haut risque un niveau approprié d'exactitude, de robustesse et de cybersécurité tout au long de leur cycle de vie.

SiyadAI cartographie en continu les usages d'IA (Shadow AI compris), constitue un registre vivant des systèmes, associe à chacun ses risques (grille OWASP/ANSSI) et son statut de conformité, et fournit au RSSI comme au DPO une visibilité unique et permanente.

Une AIPD (analyse d'impact relative à la protection des données, ou DPIA) est une démarche documentée qui cartographie un traitement de données personnelles, évalue ses risques pour les personnes et définit un plan de mesures. Elle est prévue à l'article 35 du RGPD.

Le plus souvent, oui. Dès qu'un traitement est susceptible d'engendrer un risque élevé, l'AIPD est obligatoire. Les systèmes d'IA cumulent généralement plusieurs critères de risque élevé, ce qui rend l'AIPD obligatoire dans la majorité des cas.

Selon l'EDPB, dès que deux des neuf critères de risque élevé sont réunis (scoring, décision automatisée, surveillance systématique, données sensibles, grande échelle, croisement de données, personnes vulnérables, technologie innovante, obstacle à un droit/service).

La CNIL recommande fortement une AIPD pour le développement d'un système d'IA, notamment lorsque deux critères sont réunis (données de personnes vulnérables, croisement de jeux de données, solution innovante), et la rend obligatoire dès qu'il existe un risque de mésusage, de violation de données ou de discrimination.

Aucune : DPIA (Data Protection Impact Assessment) est le terme anglais de l'AIPD. Les deux désignent l'analyse d'impact de l'article 35 du RGPD.

L'AIPD (RGPD) porte sur les risques liés aux données personnelles. La FRIA (AI Act, article 27) couvre un spectre plus large de droits fondamentaux et des dimensions techniques. La FRIA peut s'appuyer sur l'AIPD lorsque les deux sont requises.

Une description systématique du traitement, une évaluation de la nécessité et de la proportionnalité, une appréciation des risques pour les personnes, et les mesures prévues pour traiter ces risques.

Le responsable de traitement en est responsable. Le DPO donne un avis et conseille sur la démarche. Métiers, DSI et RSSI contribuent à l'identification des risques et des mesures.

Généralement oui, s'il traite des données personnelles (échanges clients ou salariés). Il cumule souvent traitement à grande échelle, technologie innovante et parfois données sensibles.

Oui. Le tri de candidatures cumule évaluation de personnes, décision à effet significatif et risque de discrimination : l'AIPD est obligatoire.

Oui. Le RGPD s'applique à la constitution des jeux de données et à l'apprentissage, pas seulement à l'usage. L'AIPD doit traiter les deux phases distinctement.

En documentant la représentativité des données, les tests d'équité, et les mesures de détection et correction des biais. Le risque de discrimination doit faire l'objet d'une section dédiée.

Consulter la CNIL avant de démarrer le traitement, au titre de la consultation préalable prévue à l'article 36 du RGPD.

Oui. L'AIPD découle du RGPD, pas de l'AI Act. Le report de certaines obligations de l'AI Act à 2027 ne change rien à l'obligation d'AIPD, déjà en vigueur.

Oui. L'article 27.4 de l'AI Act prévoit que la FRIA peut s'appuyer sur l'AIPD réalisée au titre du RGPD. Une cartographie commune évite le double travail.

À chaque évolution significative : réentraînement, nouvelle source de données, changement de finalité ou de périmètre. L'AIPD est un document vivant.

En principe, une par traitement. Une AIPD peut couvrir plusieurs traitements similaires à risques comparables, mais un système d'IA aux finalités distinctes justifie des analyses distinctes.

De quelques jours à plusieurs semaines selon la complexité, quand elle est menée manuellement. L'outillage (référentiel commun, trames, génération assistée) réduit fortement ce délai.

Un manquement au RGPD exposant à des sanctions de la CNIL, sans compter le risque réputationnel et l'impossibilité de démontrer l'accountability en cas de contrôle ou d'incident.

Avec une plateforme de gouvernance de l'IA qui cartographie les usages, génère les AIPD (et le volet FRIA), suit les risques résiduels et produit le dossier de preuve. C'est le rôle de SiyadAI.

C'est l'inventaire structuré, tenu à jour et opposable de tous les systèmes d'IA utilisés ou développés par une organisation — internes, achetés ou embarqués dans un SaaS. Il documente pour chacun sa finalité, son fournisseur, les données traitées, son niveau de risque AI Act et son responsable.

La cartographie est l'action de découvrir et recenser les systèmes d'IA ; le registre est le livrable structuré qui en résulte et qu'on maintient dans le temps. On cartographie pour alimenter le registre.

Il n'existe pas un article unique l'imposant, mais plusieurs obligations de l'AI Act (art. 12, 26, 50) et du RGPD (art. 30, 35) le rendent indispensable de fait. C'est aussi la première pièce réclamée lors d'un contrôle.

Le registre RGPD recense les traitements de données personnelles ; le registre des usages IA recense les systèmes d'IA, qu'ils traitent ou non des données personnelles. Les deux sont distincts mais couplés : un système d'IA traitant des données personnelles doit figurer dans les deux.

Au minimum : identifiant, finalité, type et fournisseur, statut, propriétaire, données traitées, localisation/transferts, classification AI Act, base RGPD/AIPD, risques et mesures, dates de revue, preuves.

En pratique, le pilotage revient souvent au DPO ou au RSSI, sous mandat de la direction, avec des contributeurs métier. La responsabilité finale relève de la direction générale.

L'article 50 (transparence) s'applique au 2 août 2026 : dès que vous exposez de l'IA à des personnes, vous devez les informer. Impossible sans savoir où vous exposez de l'IA — d'où la nécessité de la cartographie en amont.

Ce sont les fonctions d'IA intégrées dans des logiciels tiers que vous utilisez déjà (bureautique, CRM, RH), souvent activées par défaut. C'est le plus gros angle mort d'une cartographie qui ne s'appuierait que sur le déclaratif.

Les cartographies révèlent fréquemment 2 à 3 fois plus de systèmes que ce que la direction estimait, en raison du Shadow AI et de l'IA embarquée.

Pour démarrer à une dizaine de systèmes, oui. Au-delà, ses limites (pas d'historisation fiable, pas de rappels de revue, pas de liaison avec le RGPD/AIPD, risque d'erreur manuel) le rendent inadapté et risqué.

Au minimum une revue trimestrielle, plus une mise à jour à chaque nouvel usage d'IA. Le principe : « pas de nouvel outil IA sans inscription au registre ».

Selon l'AI Act : pratique interdite (art. 5), haut risque (annexe III), risque limité soumis à transparence (art. 50), ou risque minimal. En cas de doute sur le haut risque, documentez le raisonnement.

Oui. Les obligations de transparence (art. 50) et de littératie IA (art. 4) ne dépendent pas de la taille. Une PME qui utilise un chatbot ou de l'IA générative est concernée.

Le registre identifie quels systèmes traitent des données personnelles à risque élevé ; ce sont ceux qui déclenchent une AIPD (art. 35 RGPD). Le registre est donc le point de départ de la démarche AIPD.

Vous vous exposez à ne pas pouvoir démontrer votre conformité (transparence, traçabilité), ce qui aggrave votre situation et peut conduire à des sanctions sous l'AI Act et le RGPD.

Oui — une fois découvert. L'objet même de la cartographie est de faire remonter le Shadow AI (usages non déclarés) pour le régulariser ou l'arrêter.

Oui, avec le statut « en test ». Beaucoup de risques naissent d'expérimentations passées en production sans validation. Le statut permet de les suivre.

Par recoupement de trois sources : questionnaires métier (déclaratif), analyse technique (flux réseau, connexions SaaS, dépenses), et revue des contrats fournisseurs (IA embarquée).

Oui. C'est un actif commercial (répondre aux appels d'offres), un outil de maîtrise des coûts (rationaliser les abonnements) et un socle de sécurité (identifier les surfaces d'attaque liées à l'IA).

SiyadAI industrialise la découverte des usages, structure le registre, automatise la classification AI Act, relie chaque système à ses AIPD et preuves, et produit les tableaux de bord attendus par la direction et les auditeurs.

Oui. Le Data Privacy Framework reste juridiquement en vigueur : la décision d'adéquation du 10 juillet 2023 n'a été ni annulée ni retirée. Son avenir est toutefois incertain après l'arrêt Trump v. Slaughter du 29 juin 2026.

La Cour suprême US a jugé le 29 juin 2026 que les restrictions au pouvoir présidentiel de révoquer les commissaires de la FTC sont inconstitutionnelles. Or la décision d'adéquation européenne repose sur l'indépendance de la FTC, citée 259 fois. Son raisonnement est fragilisé.

Non. Aucun texte n'interdit leur usage. La démarche : identifier le mécanisme de transfert de chaque outil, mettre à jour la TIA et préparer un plan de repli. Une migration précipitée serait coûteuse et prématurée.

Une TIA (Transfer Impact Assessment) est l'analyse documentée vérifiant que le droit du pays destinataire ne prive pas d'effectivité les garanties d'un transfert (souvent des CCT). Elle découle de Schrems II et suit la méthode en 6 étapes des recommandations 01/2020 de l'EDPB.

Probablement pas si elle conclut favorablement en s'appuyant sur l'indépendance des autorités de contrôle américaines (FTC, PCLOB, DPRC). L'étape 6 de la méthode EDPB impose une réévaluation à chaque évolution significative ; l'arrêt du 29 juin en est une.

Non, pas à elles seules. Depuis Schrems II, les CCT doivent être accompagnées d'une TIA et, si elle révèle une insuffisance, de mesures supplémentaires. Une mesure purement contractuelle ne suffit pas quand le droit local permet l'accès malgré le contrat.

C'est fortement recommandé. Maintenir les deux mécanismes coûte peu et fournit un fondement de repli mobilisable immédiatement en cas d'invalidation, sans interruption de service. C'est la leçon de l'invalidation du Privacy Shield en 2020.

Non. L'accès à distance depuis un pays tiers constitue un transfert au sens du chapitre V du RGPD. Données hébergées en Irlande mais accessibles par une équipe support américaine : il y a transfert.

Pas nécessairement. S'il appelle l'API d'un modèle américain pour sa fonctionnalité d'IA, un transfert existe dans votre chaîne de traitement — il est le vôtre. Obtenez et documentez la liste de ses sous-traitants ultérieurs.

Non pour un usage courant. Les dérogations de l'article 49 visent l'occasionnel. De plus, dans une relation de subordination, la validité du consentement d'un salarié est très contestable. Un usage quotidien appelle un mécanisme de l'article 45 ou 46.

En consultant nommément la liste publique sur dataprivacyframework.gov et en vérifiant que la certification est active. Une mention marketing de « conformité DPF » ne suffit pas. La certification s'apprécie au niveau de l'entité juridique destinataire.

La plus efficace est le filtrage en amont des données envoyées au modèle : empêcher qu'un identifiant, une donnée de santé ou un extrait RH figure dans un prompt réduit le risque à la source. S'y ajoutent pseudonymisation, chiffrement, politique d'usage et engagements de non-réutilisation.

Pas de recouvrement juridique : le RGPD protège les données, l'AI Act encadre les systèmes. Mais les deux régimes exigent la même donnée d'entrée — un inventaire fiable des systèmes d'IA. Deux référentiels séparés divergent mécaniquement.

L'article 50 de l'AI Act devient applicable : informer les personnes qu'elles interagissent avec une IA, marquer les contenus générés, informer en cas de catégorisation biométrique. Un délai court jusqu'au 2 décembre 2026 pour le marquage lisible par machine des systèmes déjà en marché.

Les manquements au chapitre V relèvent du plafond le plus élevé : 20 M€ ou 4 % du CA mondial. Au-delà, le risque opérationnel est l'injonction de suspendre le transfert, qui peut interrompre un service en production.

Oui, les transferts internationaux et l'IA générative figurent parmi les chantiers 2026 de la CNIL. Les thématiques prioritaires annoncées sont le recrutement, le répertoire électoral unique et les fédérations sportives ; la cybersécurité représente la moitié des contrôles.

Ce n'est pas une obligation. La CNIL recommande d'évaluer les alternatives européennes dès que techniquement réalisable, cas d'usage par cas d'usage. Un usage documentaire interne se bascule aisément ; une intégration profonde, beaucoup moins.

L'AIPD (art. 35 RGPD) évalue le risque d'un traitement pour les personnes. La TIA (chapitre V) évalue si les garanties d'un transfert restent effectives compte tenu du droit local. Un même traitement d'IA peut nécessiter les deux, avec des conclusions distinctes.

Pour une PME/ETI disposant déjà d'un registre des traitements, une cartographie initiale des systèmes critiques prend 2 à 4 semaines. La difficulté n'est pas l'analyse mais l'exhaustivité : usages non déclarés et IA embarquée représentent souvent la majorité de l'exposition.

Par l'inventaire de tous les systèmes d'IA, y compris non souscrits et embarqués. Puis vérifier, pour les cinq flux les plus sensibles, le mécanisme de transfert, l'existence de CCT en parallèle et l'option de résidence UE. Enfin, mettre à jour leur TIA en intégrant la décision du 29 juin.

La FRIA (Fundamental Rights Impact Assessment), ou analyse d'impact sur les droits fondamentaux, est l'évaluation imposée par l'article 27 de l'AI Act avant le premier déploiement d'un système d'IA à haut risque. Elle décrit l'usage prévu, les personnes et groupes affectés, les risques de préjudice, la surveillance humaine et les mesures correctives, y compris les mécanismes de plainte.

Partiellement. L'article 27 §2 autorise à s'appuyer sur des analyses d'impact antérieures ou sur celles du fournisseur, dans des cas similaires. Mais les points (c), (e) et (f) — groupes affectés, organisation de la surveillance humaine, mécanismes de plainte — dépendent de votre contexte et ne peuvent structurellement pas venir du fournisseur.

Lorsqu'un des éléments du paragraphe 1 a changé ou n'est plus à jour : nouvelle version du système, extension du périmètre d'usage, nouvelle population concernée, incident, évolution du cadre juridique. L'article 27 §2 en fait une obligation explicite. Sans fait générateur de révision défini et sans traçabilité des versions, la FRIA est périmée l'année suivante.

Le régime de l'article 99 prévoit, pour les manquements des déployeurs, des amendes pouvant atteindre 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial. Les États membres déterminent le régime applicable aux organismes publics. Au-delà, l'exposition principale est contentieuse et réputationnelle : droit de plainte (article 85), droit à l'explication des décisions individuelles (article 86), demandes de communication.

Pas en tant que tel : un usage bureautique général ne bascule pas automatiquement en haut risque. En revanche, si un assistant conversationnel est intégré dans un processus relevant de l'annexe III — instruction de demandes d'aide sociale, tri de candidatures, orientation scolaire — la classification haut risque doit être examinée, et les obligations de transparence de l'article 50 s'appliquent de toute façon.

L'obligation vise la première utilisation. L'article 111 organise le sort des systèmes déjà mis en service avant les dates d'application, avec un traitement particulier pour les systèmes utilisés par les autorités publiques. Un système existant modifié substantiellement, ou dont le périmètre d'usage est étendu, doit dans tous les cas faire l'objet d'une analyse à jour.

Aucun texte n'impose un pilote unique. En pratique, le DPO apporte la méthode et l'articulation avec l'AIPD, le DSI/RSSI la connaissance technique, le référent métier la réalité du processus, la direction juridique la qualification, et la direction générale l'arbitrage. Une FRIA portée par le seul DPO produit un document, pas une décision.

L'analyse elle-même se conduit en deux à quatre ateliers. Ce qui prend du temps, c'est l'amont : constituer l'inventaire des systèmes d'IA et les classifier prend de quelques semaines à plusieurs mois selon la taille de l'organisation et l'existence d'un registre préalable.

L'article 27 impose la notification à l'autorité de surveillance du marché, pas la publication. Pour une collectivité, une synthèse publiée volontairement peut néanmoins constituer une réponse anticipée aux demandes de communication et un élément de confiance vis-à-vis des usagers.

Non. Il a repoussé une seule catégorie d'obligations — les systèmes à haut risque de l'annexe III — au 2 décembre 2027. La transparence de l'article 50 s'applique depuis le 2 août 2026. Les obligations des modèles d'IA à usage général, elles, s'appliquent depuis le 2 août 2025 : ce qui est arrivé le 2 août 2026, ce sont les pouvoirs d'exécution de la Commission et les amendes qui les accompagnent.

La supervision et les amendes sur les modèles d'IA à usage général (jusqu'à 15 M€ ou 3 % du CA mondial), et les obligations de transparence de l'article 50 : étiquetage des contenus générés, marquage des deepfakes, information sur les chatbots.

Les obligations lourdes des systèmes à haut risque de l'annexe III déployés de façon autonome : recrutement, évaluation du crédit, éducation, biométrie, services essentiels. Cela inclut l'analyse d'impact sur les droits fondamentaux (FRIA, article 27).

Oui. Le Parlement européen l'a voté le 16 juin 2026, le Conseil a donné son feu vert le 29 juin 2026, et le texte a été publié au Journal officiel de l'Union européenne le 24 juillet 2026. Ce n'est plus une proposition.

Non. Les pratiques interdites de l'article 5 — notation sociale, manipulation, inférence d'émotions au travail et à l'école — sont applicables depuis le 2 février 2025 et n'ont jamais été reportées.

Non. Elle est applicable depuis le 2 février 2025. Le Digital Omnibus l'a assouplie en obligation de moyens, sans la reporter ni la supprimer.

Jusqu'à 15 millions d'euros ou 3 % du chiffre d'affaires mondial (article 101), applicable depuis que le Bureau de l'IA dispose de ses pouvoirs d'exécution, le 2 août 2026.

Jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires mondial (article 99), pour les manquements les plus graves, notamment le recours à une pratique interdite.

Oui. L'article 50 impose depuis le 2 août 2026 d'informer clairement l'utilisateur qu'il interagit avec une IA. Le report de 2027 ne concerne pas cette obligation.

Oui, depuis le 2 août 2026. Les contenus générés — texte d'intérêt public, images, audio, vidéo — et les deepfakes doivent être marqués de façon claire et perceptible. Seul le marquage lisible par machine des contenus déjà sur le marché bénéficie d'un délai jusqu'au 2 décembre 2026.

Ses obligations « haut risque » (annexe III) basculent au 2 décembre 2027. Mais il reste soumis dès maintenant à l'interdiction de l'inférence d'émotions (article 5), au RGPD et au Code du travail. Vous ne pouvez pas attendre 2027.

Oui, avec une date distincte : les systèmes à haut risque intégrés dans des produits déjà réglementés (annexe I — dispositifs médicaux, machines, jouets) passent au 2 août 2028.

Pour laisser aux normes techniques harmonisées, en retard, le temps d'être disponibles avant l'entrée en application. C'est un délai de préparation, pas une suppression de l'obligation.

Oui, à compter du 2 décembre 2027 pour les systèmes de l'annexe III, à la suite du report. L'analyse d'impact sur les droits fondamentaux reste une obligation de déployeur.

Inventorier vos usages d'IA (Shadow AI compris), qualifier chaque système, traiter d'abord les obligations en vigueur — transparence, vérification des fournisseurs GPAI, absence de pratiques interdites, plan de maîtrise — puis planifier l'annexe III vers 2027.

Non. Chaque système d'IA a sa propre échéance selon sa qualification : pratique interdite, article 50, annexe III, ou dépendance à un modèle à usage général. C'est pourquoi un inventaire à jour est indispensable.

Le Bureau de l'IA pour les modèles à usage général, et les autorités compétentes désignées par chaque État membre pour le reste. Le dispositif est opérationnel depuis le 2 août 2026.

Non sur le fond des principes. Le RGPD continue de s'appliquer en parallèle : base légale, article 22 sur la décision automatisée, article 35 sur l'analyse d'impact. Un système peut être décalé côté AI Act et pleinement soumis au RGPD aujourd'hui.

En reliant chaque système, dans un inventaire vivant, à sa qualification réglementaire, à sa date d'échéance et à la preuve correspondante : documentation, dispositif de transparence, FRIA, plan de maîtrise.

SiyadAI cartographie vos usages d'IA, Shadow AI compris, qualifie chaque système au regard de l'AI Act, lui associe sa date d'échéance réelle et centralise la preuve. Vous savez, système par système, ce qui s'applique et ce qui reste à faire.

Un hébergement où les données ET le traitement — inférence comprise — restent sous droit européen, à l'abri des lois extraterritoriales comme le CLOUD Act. En France, le niveau le plus fort est la qualification SecNumCloud de l'ANSSI.

Non. La localisation des serveurs est nécessaire mais insuffisante : un centre de données en France opéré par la filiale d'un groupe non-européen reste juridiquement atteignable par une injonction visant la maison mère.

Une qualification délivrée par l'ANSSI attestant qu'une offre cloud satisfait des exigences de sécurité élevées et de protection contre le droit extraterritorial. Les critères d'immunité viennent du référentiel 3.2.

Non. Les exigences de souveraineté figuraient dans les projets successifs du schéma et en ont été retirées. Une certification EUCS atteste d'un niveau de cybersécurité, pas d'une immunité au CLOUD Act.

Une loi américaine permettant aux autorités des États-Unis d'exiger d'un fournisseur soumis au droit américain l'accès à des données, y compris stockées en Europe. Elle expose toute donnée confiée à un fournisseur sous contrôle américain.

Au niveau de l'inférence — le modèle qui calcule et voit vos prompts. Un système peut avoir une interface hébergée en France et appeler un modèle exécuté hors UE.

Cinq : le stockage, l'inférence, les données d'augmentation (RAG, embeddings, base vectorielle), la télémétrie et les journaux, et l'administration avec le support. Une seule couche non-UE casse la chaîne.

Oui. L'écosystème européen propose des modèles ouverts compétitifs et des infrastructures GPU de niveau production. La souveraineté n'impose plus de sacrifier la performance.

Seulement si vous détenez les clés. Si le fournisseur les gère, une injonction peut porter à la fois sur les données et sur les clés. Exigez une maîtrise des clés (BYOK ou HYOK).

Pour les données sensibles des administrations publiques françaises, oui — doctrine « Cloud au centre », reprise dans la loi SREN du 21 mai 2024. Dans le privé, ce n'est pas une obligation légale générale mais c'est le standard de référence pour le sensible.

En consultant le catalogue officiel de l'ANSSI sur cyber.gouv.fr, et en vérifiant le périmètre exact qualifié — une offre peut l'être pour un service et pas un autre — ainsi que la date de validité.

Une doctrine de l'État français faisant du cloud le mode d'hébergement par défaut, en imposant le cloud qualifié pour les données sensibles. Elle est contraignante pour les administrations.

Pas nécessairement. Même avec un hébergement local et une gouvernance française, un lien capitalistique ou une licence de technologie avec une maison mère non-UE peut rouvrir l'exposition. Vérifiez le contrôle du capital et de la technologie.

Les transferts relèvent du chapitre V du RGPD : « ai-je le droit de transférer ? ». La souveraineté d'hébergement est la question amont : « comment construire une pile qui ne pose pas ce problème ». Les deux sont complémentaires.

Cinq : localisation et opération en UE ; immunité extraterritoriale avec contestation et notification des injonctions ; maîtrise des clés ; réversibilité avec format et délai ; droit d'audit et transparence sur les sous-traitants.

La capacité à récupérer vos données — embeddings et modèles affinés compris — dans un format exploitable et à quitter le fournisseur. Sans elle, le coût de sortie crée une dépendance qui est une non-souveraineté de fait.

Il y aide mais ne suffit pas : il faut aussi que l'inférence s'exécute sur une infrastructure souveraine et que les autres couches — stockage, RAG, journaux, support — le soient. La souveraineté est celle de la chaîne complète.

L'usage marketing du mot « souverain » sans les garanties juridiques correspondantes : mettre en avant une localisation ou une certification technique pour laisser croire à une immunité qui n'existe pas.

Oui. Conformité RGPD et souveraineté sont deux questions distinctes. Un fournisseur peut satisfaire le RGPD tout en restant soumis au CLOUD Act, donc non souverain au sens de l'immunité extraterritoriale.

En maintenant un inventaire vivant qui trace, en continu, où vivent les données, où s'exécute l'inférence et qui peut y accéder. Un fournisseur peut être racheté ou changer de sous-traitant : la preuve doit être continue, pas figée à la signature.

Un incident ou dysfonctionnement d'un système d'IA qui entraîne, directement ou indirectement, l'un de ces quatre préjudices : le décès ou une atteinte grave à la santé d'une personne, une perturbation grave et irréversible d'une infrastructure critique, la violation d'obligations du droit de l'Union protégeant les droits fondamentaux, ou une atteinte grave aux biens ou à l'environnement.

L'article 73. Il est précédé de l'article 72 sur la surveillance après commercialisation, qui organise la détection continue des dysfonctionnements et alimente la déclaration.

Quinze jours au maximum dans le cas général, dix jours en cas de décès, et deux jours pour une infraction généralisée ou une perturbation grave et irréversible d'une infrastructure critique. La notification doit intervenir sans retard injustifié.

À partir du moment où le fournisseur prend connaissance du lien de causalité entre le système d'IA et l'incident, ou le juge raisonnablement probable — pas à la date de l'incident lui-même.

Le fournisseur du système à haut risque porte l'obligation de déclaration. Le déployeur, l'organisation utilisatrice, doit informer sans délai le fournisseur dès qu'il identifie un incident grave, et conserver la preuve de cet envoi.

À l'autorité de surveillance du marché pour un système à haut risque. Pour un modèle d'IA à usage général à risque systémique, la déclaration se fait à l'AI Office de la Commission. La désignation officielle des autorités françaises est à suivre ; la CNIL et l'ANSSI y jouent un rôle central.

Pour les systèmes à haut risque de l'annexe III, l'obligation formelle s'applique au 2 décembre 2027, alignée sur le report des obligations haut risque. Mais les fournisseurs de modèles à usage général à risque systémique déclarent déjà leurs incidents graves à l'AI Office : cette obligation est en vigueur depuis le 2 août 2025.

Non. Un incident d'IA déclenche presque toujours une notification déjà obligatoire : RGPD sous 72 heures, NIS2 sous 24 heures, DORA sous 4 heures. Le report de l'article 73 ne suspend aucune de ces obligations.

L'article 72 impose la surveillance post-marché, le capteur qui rend le problème visible. L'article 73 impose la déclaration de l'incident grave, l'action qui suit. L'un ne fonctionne pas sans l'autre : une organisation qui ne surveille pas ne déclare pas, faute de voir.

Pas automatiquement. Elle le devient si elle produit l'un des quatre préjudices graves. Sinon elle relève des régimes cyber, NIS2 ou DORA, et du RGPD si des données personnelles sont touchées.

Oui, potentiellement. Une discrimination produite par un système d'IA peut constituer une violation de droits fondamentaux, même sans panne technique ni fuite de données. C'est la catégorie la plus sous-estimée par les équipes venues du monde cyber.

Jusqu'à 15 000 000 euros ou 3 % du chiffre d'affaires annuel mondial, le montant le plus élevé étant retenu. S'y ajoutent, le cas échéant, les sanctions RGPD — jusqu'à 20 M€ ou 4 % — et les régimes NIS2 et DORA.

Si l'incident implique une violation de données personnelles, la notification à la CNIL sous 72 heures s'ajoute à la déclaration AI Act, et l'information des personnes peut être requise en cas de risque élevé. Les deux obligations sont cumulatives, et le délai le plus court gouverne l'organisation.

NIS2 impose une alerte précoce sous 24 heures aux entités essentielles et importantes ; DORA impose une notification d'incident majeur sous 4 heures dans le secteur financier. Les régimes se cumulent : ouvrez les canaux en parallèle, jamais en série.

Un guichet confié à l'ENISA, destiné à router une seule déclaration vers les régimes applicables : RGPD, NIS2, DORA, CER et eIDAS. Attention : il relève du volet « données » du paquet Digital Omnibus, encore en négociation. Il n'existe pas aujourd'hui et les canaux restent séparés.

Oui. On ne peut pas qualifier un incident sur un système qu'on ne sait pas exploiter. Un registre indiquant, par système, la finalité, la classification, le fournisseur, les données et l'autorité compétente est le prérequis de toute préparation.

La description de l'incident et de ses effets, l'identification du système d'IA et du fournisseur, la chronologie dont la date de prise de connaissance, la catégorie de préjudice, les premières mesures prises et le lien de causalité établi ou probable.

Oui. En urgence, une notification incomplète peut être transmise dans le délai applicable, puis complétée après enquête. Mieux vaut déclarer à temps et compléter que dépasser le délai en cherchant l'exhaustivité.

Le RSSI pour la coordination, le DPO pour le volet données et droits fondamentaux, la DSI pour les mesures techniques, le métier propriétaire pour le contexte et la causalité, la direction juridique pour la qualification et la direction générale pour la décision de notifier. Sans rôles pré-attribués, la qualification dépasse le délai de deux jours.

Par l'inventaire des systèmes d'IA et leur classification, puis la grille des quatre préjudices, la carte des délais et des autorités par système, un registre d'incidents horodaté et l'attribution des rôles. C'est un exercice de gouvernance à mener à froid, avant tout incident.

Un système d'IA qui poursuit un objectif en plusieurs étapes, prend des décisions intermédiaires et agit sur son environnement — appels d'API, écriture de données, envoi de messages, exécution de code — sans validation humaine à chaque étape. Contrairement à un chatbot qui répond, un agent agit.

Un chatbot génère une réponse ; un agent exécute des actions. Le chatbot expose au risque d'une mauvaise réponse ; l'agent peut déclencher une action irréversible : suppression, envoi, engagement. La gouvernance d'un agent porte donc sur ses droits d'action, pas seulement sur ses réponses.

Un agent IA autonome déployé sans inventaire, sans identité dédiée et sans traçabilité, qui agit avec des droits — souvent une clé d'API partagée ou le compte d'un salarié. Ce n'est pas un Shadow AI plus intense : l'acteur n'est plus un humain qui saisit du texte, c'est un logiciel qui exécute.

Oui. L'article 3 vise les systèmes conçus pour fonctionner avec des niveaux d'autonomie variables, et les lignes directrices de la Commission sur la définition d'un système d'IA, publiées en février 2025, n'excluent que les systèmes fonctionnant uniquement par intervention humaine.

Cela dépend de l'action, pas de l'autonomie. Un agent qui rédige des e-mails relève du risque limité ; un agent qui filtre des candidatures, accorde un crédit ou une assurance bascule en haut risque au titre de l'annexe III. C'est le cas d'usage qui classe le système.

Le 13 avril 2026, le CERT-FR a publié le bulletin CERTFR-2026-ACT-016, qui déconseille le déploiement en production d'agents IA autonomes sur les postes de travail. Il recommande une validation humaine obligatoire pour toute action à effet de bord et une exécution en bac à sable, sans donnée sensible.

Dans une note conjointe exploratoire publiée le 20 juillet 2026, la CNIL et le Conseil de l'IA et du numérique alertent sur un risque réel de perte de maîtrise des données personnelles : l'agent accède à de multiples sources et agit directement sur son environnement. La note rappelle que le cadre existant, RGPD comme AI Act, s'applique déjà.

Publié le 9 décembre 2025 par l'OWASP GenAI Security Project, c'est le premier référentiel des risques propres aux agents : empoisonnement de mémoire, détournement d'outils, abus d'identité et de privilèges, détournement d'objectif, injection de prompt, défaillances en cascade. Il complète l'OWASP LLM Top 10, qui vise le modèle.

Détournement d'objectif, mauvais usage des outils accessibles, abus d'identité par privilèges excessifs ou partagés, empoisonnement de la mémoire persistante, injection de prompt, et effets en cascade dans les systèmes multi-agents. Ces risques découlent des trois propriétés de l'agent : autonomie, usage d'outils, mémoire.

Non. Le règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026, a reporté les obligations de l'annexe III au 2 décembre 2027, en incluant les articles 9 à 15 — dont la journalisation (art. 12) et la supervision humaine (art. 14) — et les articles 16 à 27, dont l'article 26. En revanche, l'article 22 du RGPD impose déjà l'intervention humaine sur une décision automatisée à effet significatif.

Le RGPD intégralement, dont l'article 22 et l'article 32 sur la sécurité du traitement ; l'article 5 de l'AI Act sur les pratiques interdites et l'article 4 sur la maîtrise de l'IA, depuis le 2 février 2025 ; et l'article 50 sur la transparence depuis le 2 août 2026. C'est déjà suffisant pour que l'inventaire ne puisse pas attendre.

Oui, depuis le 2 août 2026 au titre de l'article 50 de l'AI Act, dès lors qu'il interagit directement avec des personnes physiques. Un tempérament existe pour le marquage des contenus générés par des systèmes déjà sur le marché avant cette date, repoussé au 2 décembre 2026.

Avec cinq contrôles : inventorier les agents, attribuer à chacun une identité dédiée, restreindre ses droits d'action au minimum avec cloisonnement, tracer chaque action par un journal horodaté, et garder une supervision humaine avec point d'arrêt testé.

Oui. La pratique qui s'impose est de traiter chaque agent comme une identité non-humaine distincte, avec un propriétaire, un périmètre et une date d'expiration — jamais une clé d'API partagée ni le compte d'un salarié. Quand deux agents partagent une clé, la question « lequel a agi ? » n'a plus de réponse.

Souvent, oui. Un agent traitant des données personnelles à grande échelle, dans un domaine sensible ou avec effets significatifs déclenche une analyse d'impact au titre de l'article 35 du RGPD. L'AIPD d'un agent doit décrire ce qu'il peut faire, avec quels droits, sur quelles données, et comment un humain garde la main.

La mémoire persistante conserve et recombine des données au fil des interactions, ce qui met sous tension la limitation des finalités, la minimisation, la limitation de la conservation et l'exactitude. C'est l'un des points d'attention de la note CNIL/CIANum du 20 juillet 2026.

Oui, s'il produit une décision à effet juridique ou significatif sans intervention humaine réelle — crédit, recrutement, résiliation. La personne a alors droit à l'information, à une intervention humaine et à la contestation. C'est applicable aujourd'hui, sans attendre décembre 2027.

En journalisant de façon horodatée et inaltérable l'objectif reçu, les décisions, chaque outil appelé, ses paramètres, ses résultats et les données touchées, puis en centralisant ces journaux, idéalement dans un SIEM. Sans cela, on ne peut ni expliquer une décision, ni qualifier un incident.

Un mécanisme d'interruption fiable permettant d'arrêter immédiatement un agent en cas de comportement anormal : boucle, escalade de privilèges, détournement d'objectif. Un point d'arrêt jamais déclenché ne compte pas — « on débrancherait la clé » n'est une supervision que si quelqu'un l'a déjà fait.

Le canal le plus rapide est le RGPD : jusqu'à 4 % du chiffre d'affaires mondial, via l'absence d'AIPD, le défaut de base légale ou la violation de l'article 22. Côté AI Act, les pratiques interdites de l'article 5 exposent jusqu'à 35 M€ ou 7 %, et la transparence de l'article 50 jusqu'à 15 M€ ou 3 %.

Par l'inventaire : on ne gouverne que ce qu'on voit. Recensez tous les agents — postes, SaaS, connecteurs, automatisations métier — classez-les selon l'action, puis appliquez les cinq contrôles. Sans inventaire, les quatre autres contrôles sont impossibles à tenir.

Un protocole open source créé par Anthropic en novembre 2024, qui standardise la connexion entre un agent IA et les outils d'une entreprise — CRM, messagerie, stockage, bases de données. Un serveur MCP expose des « outils », c'est-à-dire des actions que l'agent peut appeler.

Un connecteur ou serveur MCP déployé sans validation ni recensement par la DSI ou le RSSI. C'est le troisième terme après le Shadow AI (usages humains non déclarés) et les Shadow Agents (agents autonomes non recensés) : après l'usage, après l'acteur, la chaîne d'approvisionnement des outils.

Parce qu'il n'affiche pas une réponse : il agit sur vos systèmes. Et c'est le modèle qui choisit quel outil appeler, sur la foi d'une description en langage naturel. Un connecteur mal cadré est un droit d'action non tracé sur une production.

Des instructions malveillantes dissimulées dans les métadonnées d'un outil MCP — son nom, sa description. Le modèle lit la description pour décider, et exécute l'instruction cachée. Une variante documentée dissimule la charge dans des caractères Unicode invisibles à l'écran de validation.

Parce que l'attaque ne vit ni dans le prompt de l'utilisateur ni dans l'agent : elle vit dans l'outil. Un agent parfaitement gouverné — identité dédiée, droits limités, point d'arrêt — exécutera quand même l'instruction cachée.

Un serveur MCP exécute ses actions avec ses propres privilèges, souvent larges, et non avec ceux de l'utilisateur qui demande. Un serveur compromis opère donc avec toute la confiance que l'organisation a accordée à l'agent.

Une taxonomie systématique publiée en mars 2026, recensant trente-huit catégories de menaces propres au protocole MCP : empoisonnement de description d'outil, injection indirecte, chaînage parasitaire d'outils, violation de confiance dynamique.

Un défaut d'architecture révélé en avril 2026 par OX Security, présent dans tous les SDK MCP officiels. Une commande passée à l'interface STDIO s'exécute sur l'hôte, qu'un serveur valide soit initialisé ou non. Environ 150 millions de téléchargements, plus de 7 000 serveurs exposés, jusqu'à 200 000 instances vulnérables. Référence CVE-2026-30623.

Non. Anthropic a confirmé que ce comportement est intentionnel et a refusé de modifier l'architecture du protocole. Un défaut qu'on corrige a une date de fin ; un défaut assumé est une propriété du terrain avec laquelle il faut composer.

Le transport, oui, nettement : cœur du protocole rendu sans état, OAuth 2.1 avec PKCE pour les serveurs distants, jetons scopés et révocables. Mais elle ne traite pas les attaques sémantiques — empoisonnement d'outil, député confus, injection indirecte — ni le manque d'inventaire.

Le bulletin CERTFR-2026-ACT-016 du 13 avril 2026 recommande une validation humaine obligatoire pour toute action à effet de bord, une exécution en bac à sable sans donnée sensible, et pas d'assistant autonome en production tant qu'il n'est pas éprouvé.

Compromission du poste par des outils en version d'essai ; fuite de données vers des ressources externes non maîtrisées ; droits d'accès excessifs aux applications bureautiques et métier ; partage de secrets d'authentification ; perte de contrôle sur les actions, avec risque d'actions irréversibles.

Non, pas encore. La journalisation (art. 12) et la supervision humaine (art. 14) sont des exigences des systèmes à haut risque : le règlement (UE) 2026/1744 les reporte au 2 décembre 2027 avec le reste de l'annexe III. L'article 50 sur la transparence, lui, s'applique depuis le 2 août 2026.

Oui, et dès aujourd'hui. Un connecteur qui lit votre CRM ou votre messagerie manipule des données personnelles : l'article 32 impose la sécurité du traitement, l'article 30 de savoir quels traitements passent par quels outils, et l'article 35 peut déclencher une AIPD.

Le modèle traite l'injection directe (OWASP LLM Top 10). L'agent traite l'acteur autonome : identité, droits, supervision. Le connecteur traite le tuyau vers vos systèmes. Les trois sont distincts, et le troisième est le plus souvent oublié.

Une authentification par utilisateur avec PKCE, des jetons scopés à une seule audience, révocables, sans secret partagé stocké en clair dans un fichier de configuration. Le serveur MCP devient un simple serveur de ressources qui délègue à un serveur d'autorisation séparé.

Un serveur qui se comporte correctement pendant l'audit, puis modifie ses outils ou son schéma après adoption — ou dont une dépendance est mise à jour avec du code malveillant. C'est ce qui rend la revue périodique nécessaire : un audit d'entrée ne suffit pas.

Six contrôles dans un ordre qui n'est pas indicatif : inventorier, authentifier, restreindre au moindre privilège, cloisonner en bac à sable avec validation humaine, tracer chaque appel d'outil, superviser par liste blanche et point d'arrêt.

Non, il faut le gouverner. L'objectif n'est pas de bloquer l'innovation mais de rendre la couche connecteurs visible, authentifiée, cloisonnée et tracée. Une interdiction produirait exactement ce qu'on cherche à éviter : des connecteurs installés en douce.

Par l'inventaire. On n'authentifie pas, on ne restreint pas, on ne trace pas et on ne supervise pas un connecteur qu'on n'a pas recensé. Et cet inventaire doit être vivant : un connecteur se branche en quelques minutes, un tableur est faux quinze jours plus tard.