EU AI Act et architecture d'entreprise : par où commencer en cartographiant vos systèmes d'IA

Modèle opératoire du contexte souverain

Un agent IA ne vaut que le contexte qu'il peut atteindre. Pour une entreprise régulée, ce contexte — le référentiel d'architecture — est aussi l'un de ses actifs les plus sensibles.

Le modèle opératoire qui compte n'est pas « exposer le référentiel via MCP » ; c'est « gouverner quel contexte sort, vers qui, et sous quelles contraintes de résidence et d'audit ».

• Décider quels types d'objets sont interrogeables, et lesquels ne sont jamais exposés
• Garder le contexte frais : réconcilier le référentiel avec les sources vivantes, pas un snapshot annuel
• Rendre chaque réponse traçable vers une source gouvernée que l'utilisateur a le droit de voir

Commencez par la question que l'AI Act ne cesse de poser : quels systèmes d'IA exploitez-vous ?

L'EU AI Act est récent, et beaucoup d'équipes ne savent pas encore par où commencer. La réponse honnête : on ne gouverne pas ce qu'on ne sait pas lister. Presque chaque obligation du règlement — de la classification du risque à la documentation en passant par la supervision humaine — présuppose une chose : que vous savez réellement quels systèmes d'IA votre organisation déploie ou utilise, ce qu'ils font, et ce qu'ils touchent.

Pour la plupart des organisations, cet inventaire n'existe pas comme une vue unique et fiable. L'IA s'est introduite via des logiciels achetés, des solutions ponctuelles, des fonctionnalités embarquées et quelques modèles internes, détenus par des équipes différentes. La première étape pratique n'est donc pas juridique. Elle est architecturale : bâtir un inventaire à jour et traçable des systèmes d'IA. Cet article est une aide à la préparation et à la documentation, pas un conseil juridique — mais il montre où une cartographie d'architecture vous donne une longueur d'avance.

Comprendre la forme des obligations (de façon neutre)

Sans citer de numéros d'articles ni de dates dont nous ne sommes pas certains, la logique de l'AI Act est fondée sur le risque. Il distingue un petit ensemble de pratiques interdites, une catégorie à haut risque qui porte les obligations les plus lourdes, des usages soumis à des obligations de transparence (par exemple indiquer qu'une personne interagit avec une IA ou qu'un contenu a été généré par IA), et des usages à moindre risque aux exigences plus légères. Les obligations pèsent sur les développeurs de systèmes d'IA et, surtout, sur les organisations qui les déploient ou les utilisent.

Deux conséquences pratiques en découlent. D'abord, la classification se fait par usage, pas par fournisseur — le même modèle peut servir un processus à haut risque et un processus trivial. Ensuite, les déployeurs portent de vraies obligations même s'ils n'ont pas construit le modèle. C'est pourquoi une posture passive « nous ne faisons qu'acheter du logiciel » est risquée : vous devez tout de même savoir ce que ce logiciel fait avec l'IA, et pouvoir le démontrer. La classification exacte d'un système est une évaluation juridique et technique à confirmer avec un conseil ; l'architecture est l'endroit où vous en consignez le résultat.

• Paliers fondés sur le risque : interdit, haut risque, obligation de transparence, moindre risque
• Obligations sur les développeurs et sur les déployeurs / utilisateurs, pas seulement les constructeurs
• La classification se fait par cas d'usage, pas comme propriété fixe d'un outil
• Nous n'attribuons pas les classes de risque à votre place — c'est une décision juridique/technique

Votre cartographie applicative est l'hôte naturel de l'inventaire des systèmes d'IA

Un modèle d'architecture d'entreprise contient déjà l'essentiel de l'ossature nécessaire. Il liste les applications, les capacités et processus métier qu'elles supportent, et les données qui circulent entre elles. C'est précisément la structure sur laquelle un inventaire de systèmes d'IA doit reposer : un système d'IA ne flotte pas dans le vide — il vit dans une application, sert un processus, et atteint des données.

Plutôt que de démarrer un registre vierge, vous étendez l'existant. Marquez chaque application qui embarque ou appelle de l'IA. Pour chaque entrée marquée, consignez la classe de risque déterminée, le responsable redevable, la nature de la supervision humaine, et les catégories de données touchées. Comme la cartographie encode déjà les dépendances, vous voyez aussi la portée de second ordre : quels processus en aval s'appuient sur un composant piloté par l'IA, et ce qui casse ou doit être revu si ce composant change.

• Réutilisez les entités existantes : applications, processus, flux de données, responsables
• Ajoutez les attributs IA : drapeau embarque-IA, classe de risque, supervision, données touchées
• Tracez la portée via les dépendances, pas seulement l'application isolée
• Une vue interrogeable plutôt qu'un tableur statique périmé dès le lendemain

Tracer où l'IA touche processus et données — ce que les tableurs ratent

Les questions d'un auditeur ou d'un comité des risques sont relationnelles : non pas « avons-nous un chatbot » mais « quels processus en contact client utilisent l'IA, quelles données personnelles chacun atteint, et qui peut en surpasser le résultat ». Une liste plate répond à la première ; seul un modèle connecté répond au reste.

Projeter l'IA sur l'architecture permet de suivre un fil d'un processus métier jusqu'à l'application qui embarque le modèle, puis jusqu'aux données qu'il consomme — et de remonter vers les personnes redevables de la supervision. Cette traçabilité est la matière première de la documentation technique et de la tenue de registres que l'AI Act attend, et elle est bien plus simple à garder à jour comme modèle vivant que comme document ressaisi chaque trimestre. La même discipline de modèle vivant soutient vos preuves DORA et NIS2 ; plutôt que de la répéter ici, voyez notre article dédié sur la gouvernance d'architecture pour DORA et NIS2.

L'angle méta : braquer l'IA sur votre architecture est en soi un usage d'IA

Voici ce que les équipes oublient. Dès l'instant où vous utilisez des agents IA pour interroger, résumer ou raisonner sur votre modèle d'architecture, vous avez créé un autre usage d'IA — et un usage particulièrement sensible. L'architecture s'apparente à un plan complet de l'organisation : inventaire des systèmes, dépendances critiques, composants obsolètes, flux de données, parfois mesures de sécurité. Un usage d'IA de cette matière mérite la même rigueur de gouvernance que n'importe quel autre.

La même entrée d'inventaire s'applique donc à votre propre outillage : quel est le système, que touche-t-il, qui le supervise, et — surtout — où va physiquement le contexte. Si répondre à une question sur votre architecture revient à envoyer ce plan à un modèle externe hors UE, vous avez transformé un actif interne en exposition. Nous pensons que la bonne réponse est une couche de contexte souveraine : un système de contexte gouverné qui laisse les agents raisonner sur l'architecture sans que la cartographie sensible quitte votre contrôle. Pour être clair sur la discipline de revendication : cette approche souveraine et consciente de la résidence des données est la direction que nous construisons — une conviction et une feuille de route, pas un produit livré que nous vous demanderions de croire sur parole.

• Traitez « l'IA sur l'architecture » comme un usage d'IA gouverné, pas un laissez-passer
• L'architecture est une matière sensible proche d'un plan complet
• Demandez où va le contexte, pas seulement qui a le droit d'interroger
• Une couche de contexte souveraine est notre conviction et notre feuille de route, pas un MCP livré

Un point de départ pragmatique — et une frontière honnête

Si vous voulez un premier mouvement qui crée de la valeur quelle que soit la manière dont l'interprétation juridique se stabilise, bâtissez l'inventaire : prenez votre portefeuille applicatif, marquez chaque entrée qui embarque ou appelle de l'IA, et capturez classe de risque, responsable, supervision et données touchées pour chacune. Puis pilotez la traçabilité sur un seul processus à fort enjeu avant de passer à l'échelle. Vous obtiendrez une documentation dont vous auriez eu besoin de toute façon, et une image plus claire de votre propre exposition.

La frontière honnête : cela vous aide à documenter et à préparer ; cela ne vous rend pas conforme. La conformité est un résultat juridique qui dépend de vos systèmes, processus et conseils qualifiés spécifiques. La contribution d'Archilu est le modèle connecté et hébergeable en UE qui rend l'inventaire et la traçabilité réalistes à construire et à maintenir — avec un prix publié, le français et l'anglais natifs, et un hébergement que vous contrôlez. Un moyen rapide de voir où en est votre pratique aujourd'hui est l'évaluation gratuite de maturité EA : dix dimensions, un plan d'action priorisé, environ dix minutes.

KPIs du contexte IA régulé

Mesurez si votre contexte est fiable et gouverné, pas le nombre de requêtes de l'agent.

• Fraîcheur du contexte : âge médian des objets d'architecture vs réalité vivante
• Part des réponses traçables vers une source gouvernée et à périmètre de permission
• Types d'objets sensibles couverts par une politique de redaction/résidence
• Couverture d'audit : prompts et réponses loggés et revus

Common mistakes

La plupart des initiatives MCP-pour-EA échouent sur la qualité du contexte et la gouvernance bien avant d'échouer sur le protocole.

• Exposer tout le référentiel d'architecture à des LLM externes sans contrôle de résidence des données
• Traiter le MCP comme le différenciateur au lieu du contexte gouverné derrière
• Brancher un référentiel maintenu à la main vieux de 18 mois auquel l'agent ne peut pas se fier
• Aucune permission-awareness, aucun logging, aucune redaction des objets sensibles

Practical checklist

À faire avant de connecter un agent IA à votre référentiel d'architecture.

• Confirmer où vont prompts et réponses, et si la donnée reste dans votre région
• Imposer un accès permission-aware : l'agent ne voit que ce que l'utilisateur peut voir
• Classer et masquer les types d'objets sensibles (vulnérabilités, flux de données, contrôles)
• Logger prompts et réponses pour l'audit, et garder un humain dans la boucle pour tout changement