Vue d’ensemble

Architecture d’entreprise, interopérabilité, gouvernance des services, sécurité, protection de la vie privée, accessibilité, marchés publics et contraintes institutionnelles de l’UE.

Statut du module

•Parcours : Socle commun TIC
•Dernière vérification : 2026-10-27
•Périmètre : Formation indépendante EPSOHQ alignée sur les fonctions décrites dans l'avis ; les sources officielles prévalent.

L’architecture avant les produits

Un administrateur AD7 doit traduire les besoins institutionnels en services qui restent exploitables, sécurisés et interopérables. Commencez par les capacités, les flux d’informations, les niveaux de service, les contraintes et les risques. Le choix des produits intervient après la définition de l’architecture cible et des critères d’évaluation. Une conception techniquement élégante, mais impossible à exploiter, à acquérir, à auditer ou à abandonner, est incomplète.

Les décisions d’architecture doivent consigner le contexte, les options, la décision retenue, les conséquences et les critères déclenchant un réexamen. La réversibilité est importante. Les interfaces et les formats de données portables réduisent le couplage. Un radar technologique distingue les technologies adoptées, testées, évaluées et mises en attente, afin que l’expérimentation ne devienne pas tacitement l’architecture de production.

Interopérabilité et contraintes du secteur public

Le règlement pour une Europe interopérable établit un cadre pour l’interopérabilité transfrontière des réseaux et des systèmes d’information du secteur public. L’interopérabilité comporte des dimensions juridique, organisationnelle, sémantique et technique. Une API ne suffit pas à résoudre les différences de bases juridiques, de responsabilités relatives aux processus ou de signification des données.

L’accessibilité doit figurer dans les critères d’acceptation. La sécurité et la protection des données doivent être intégrées dès la conception. Les marchés publics exigent des critères mesurables, une évaluation équitable et une stratégie de sortie. La gestion des documents, la transparence et l’auditabilité influent sur la journalisation, la conservation et les éléments probants étayant les décisions.

Sécurité et protection de la vie privée dès la conception

Sélectionnez les contrôles en fonction des risques. La défense en profondeur combine la gestion des identités, les terminaux, les réseaux, les applications, les données, la surveillance et la reprise. Le principe du moindre privilège limite l’accès à ce dont un sujet a besoin. La séparation des fonctions réduit le risque qu’une même identité puisse lancer, approuver et dissimuler une action sensible.

La protection de la vie privée dès la conception implique de définir, avant la mise en œuvre, la finalité, la base juridique, la minimisation, la conservation, l’accès, les transferts et les droits des personnes concernées. Le chiffrement protège la confidentialité, mais ne suffit pas à lui seul à établir la licéité du traitement. La pseudonymisation réduit la possibilité d’établir des liens, mais reste un traitement de données à caractère personnel lorsqu’une réidentification demeure possible.

Gouvernance des services

Définissez le responsable du service, le responsable du produit, le responsable technique et le responsable des données. Établissez les indicateurs de niveau de service avant les objectifs de niveau de service. Suivez les résultats pour les utilisateurs parallèlement à la disponibilité. Un service peut être techniquement disponible, mais inutilisable en raison d’un échec de l’authentification, d’une latence excessive ou de la défaillance d’une dépendance critique.

Tout service en production nécessite une supervision, une définition des rôles en cas d’incident, des preuves de sauvegarde et de restauration, des hypothèses de continuité, une procédure d’escalade auprès des fournisseurs et un plan de mise hors service. L’approbation des changements doit être proportionnelle au risque. Les changements standard à faible risque peuvent être préautorisés ; les changements d’urgence doivent néanmoins rester traçables et faire l’objet d’un examen rétrospectif.

Ensemble de sources fondamentales

•Règlement pour une Europe interopérable — Règlement (UE) 2024/903
•NIS2 — Directive (UE) 2022/2555
•RGPD — Règlement (UE) 2016/679
•Directive relative à l’accessibilité des sites internet — Directive (UE) 2016/2102
•Méthodologie PM² de la Commission européenne — Portail PM²

Politique numérique de l'UE : identifier l'acteur avant l'obligation

Complément vérifié le 27 octobre 2026. Ces distinctions étayent le jugement technique et la rédaction sur les questions européennes. Elles constituent une aide à la révision, et non une prédiction des questions EPSO ou du dossier de l'EUFTE.

Instrument	Question principale	Éléments probants à demander	Piège de périmètre
Règlement sur l’IA	Quelle est la finalité prévue du système, sa classification de risque et le rôle de l'organisation ?	Inventaire des cas d'usage, justification de la classification, registres de supervision et d'évaluation	Un label « conforme IA » d'un fournisseur ne peut pas couvrir chaque déploiement
NIS2	L'organisation est-elle une entité relevant du champ d'application de la directive et des règles nationales pertinentes ?	Gestion des risques, processus de gestion des incidents, contrôles de la chaîne d'approvisionnement et gouvernance	N'appliquez pas par défaut une directive destinée aux États membres à chaque institution de l'UE
Règlement (UE, Euratom) 2023/2841	Quelles obligations de cybersécurité concernent les institutions, organes et organismes de l'Union ?	Cadre institutionnel de gestion des risques, responsabilités et coordination des incidents	Le régime institutionnel exige sa propre analyse de périmètre
DORA	S'agit-il d'une entité financière couverte ou d'un accord pertinent avec un prestataire tiers de services TIC ?	Contrôles des risques TIC, registre des contrats, tests de résilience et modalités de sortie	DORA est sectoriel ; ce n'est pas la règle générale applicable à tout projet informatique du secteur public
Règlement sur la cyberrésilience	Un produit comportant des éléments numériques et un opérateur économique relèvent-ils du champ d'application ?	Gestion des vulnérabilités, informations d'assistance et preuves de conformité	Un contrôle de sécurité opérationnel et la conformité d'un produit répondent à des questions différentes
RGPD / Règlement (UE) 2018/1725	Quel régime de protection des données personnelles et quels rôles de responsable du traitement / sous-traitant s'appliquent ?	Finalité, base juridique, minimisation, conservation et registres d'accès	La localisation du cloud ou un paramètre de chiffrement ne suffit pas à rendre un traitement licite
Data Act	Quelle règle d'accès aux données ou de changement de service de traitement de données est pertinente ?	Formats d'export, dépendances, sortie contractuelle et tests de transition	La portabilité ne signifie pas que chaque application migre sans adaptation
Data Governance Act / directive sur les données ouvertes	S'agit-il de la réutilisation de données protégées du secteur public, d'un intermédiaire de partage ou d'informations réutilisables du secteur public ?	Conditions d'autorisation, garanties d'accès et classification des jeux de données	Ces instruments ne transforment pas toutes les données détenues en données ouvertes sans restriction
Programme d'action pour la décennie numérique	Quelle capacité ou quel résultat de service à l'horizon 2030 est visé ?	Indicateurs relatifs aux compétences, à la connectivité, aux entreprises ou aux services publics	Un objectif politique n'est pas un certificat de sécurité pour un système donné

Lisez le texte applicable et ses modifications en vigueur avant de mémoriser une date de mise en œuvre. L'entrée en vigueur, l'application générale, les obligations échelonnées et les obligations de déclaration effectives d'une entité peuvent différer. Par exemple, la Commission distingue les obligations de déclaration du CRA de ses obligations principales ultérieures. Considérez les obligations juridiques, les objectifs politiques, les normes techniques et les cadres de gouvernance volontaires comme des sources d'autorité distinctes.

Gaia-X peut fournir un contexte pour les écosystèmes cloud et de données. Il ne s'agit ni d'un règlement de l'UE ni d'une certification juridique générale. Une revendication de souveraineté doit toujours être étayée par des preuves concernant la maîtrise des clés, l'accès, les sous-traitants, la portabilité et l'exposition juridique. Le règlement européen sur les semi-conducteurs (Chips Act) porte sur les capacités de production de semi-conducteurs et la résilience des approvisionnements ; il ne certifie pas une charge de travail cloud donnée. Faites correspondre l'instrument à la décision à prendre.

Quatre décisions de périmètre originales

Infrastructure : un fabricant propose un appareil connecté portant le marquage CE. Cela ne démontre pas que la reprise du service de l'institution a été testée. Demandez séparément les preuves relatives au produit et celles relatives à la reprise locale.
Gestion de projets : un fournisseur promet « la conformité à toute la réglementation de l'UE ». Avant d'approuver l'exigence, demandez une cartographie du périmètre par acteur et par instrument, les responsables, les preuves d'acceptation et les dépendances non résolues.
Cloud et réseaux : deux fournisseurs utilisent des services d'identité et de bases de données gérées différents. Un simple export de données ne prouve pas l'existence d'un plan de sortie exécutable. Épreuveez les dépendances, le délai de reprise, les accès et l'intégrité des données.
Science des données : un indicateur de précision ne démontre ni la licéité de l'utilisation des données ni l'adéquation de la supervision. Interrogez séparément la finalité prévue, les règles applicables, la provenance des données, les performances par sous-groupe et les décisions humaines.

Gouvernance commune des TIC, sécurité et prestation de services au sein des institutions de l’UE