Architecture de référence · v1.0 · 25 septembre 2026

AI Operating Layer Reference Architecture

Un AI operating layer est la gouvernance, l'audit et le runtime conçus entre les modèles de fondation et les workflows métier d'une entreprise régulée. Ce document en spécifie les plans, les quatre contrôles testables, le modèle de preuve et un protocole de due diligence en une journée. Il s'adresse aux architectes, RSSI, directions des risques et auditeurs qui en évaluent ou en construisent un.

Comment citer ce document

0 · Statut et conventions

Une spécification publique et versionnée, pas une fiche produit.

Nous publions cette architecture de référence pour que tout acheteur, auditeur ou concurrent puisse tester un operating layer selon les mêmes critères. Elle prolonge la définition canonique publiée sur la page Qu'est-ce qu'une couche opérationnelle d'IA ? et ne la contredit jamais.

Dans ce document, « nous » désigne Hikari Blue, la firme qui opère cette architecture sur les missions de ses clients. Le mot « doit » marque une exigence ; une couche qui en manque une n'est pas un operating layer au sens de cette spécification.

Le mot « devrait » marque une pratique recommandée qu'un déployeur peut remplacer par un contrôle équivalent, à condition que la substitution soit consignée dans le registre des décisions d'architecture. Chaque exigence est formulée pour qu'un tiers puisse la tester sans notre participation.

Les points d'ancrage réglementaires citent le règlement (UE) 2024/1689, l'EU AI Act, tel que publié sur EUR-Lex (ouvre dans un nouvel onglet). Le calendrier d'application de ses obligations à haut risque est suivi sur la page de définition, pas repris ici, afin que ce document reste valide quand le calendrier bouge.

1 · Périmètre et définitions

Ce qu'est la couche, qui agit dessus, et ce qu'elle n'est pas.

L'AI operating layer se place entre les modèles de fondation et les workflows de l'entreprise. Il décide quel modèle traite quelle tâche, sous quelle politique, avec quelle résidence des données, enregistre chaque action et arrête n'importe quel agent ou modèle en une seule action.

  • Fournisseurs de modèles

    Les entreprises qui entraînent et servent des modèles de fondation, comme Anthropic, OpenAI, Mistral ou Google, ainsi que les modèles open-weight auto-hébergés. La couche traite chaque fournisseur comme un prestataire remplaçable placé sous une seule gouvernance.

  • L'entreprise déployeuse

    L'organisation régulée qui utilise l'IA sous sa propre autorité. Au titre de l'EU AI Act, elle porte les obligations du déployeur : elle doit donc posséder la politique, la preuve et le chemin d'arrêt.

  • Agents

    Des acteurs logiciels qui appellent des modèles et des outils pour agir dans un workflow. Chaque agent est une identité gouvernée, avec un périmètre d'outils déclaré, un budget et une trace d'exécution.

  • Vérificateurs humains

    Des personnes nommées qui approuvent, rejettent ou corrigent une décision d'agent quand l'enjeu le justifie. Leur identité et leur décision font partie de l'enregistrement, pas d'un commentaire à côté.

  • L'opérateur

    L'équipe qui fait tourner la couche au quotidien : astreinte, réponse à incident, changements de modèle, exercices de kill switch. Pendant une mission, ce peut être Hikari Blue ; après le transfert de propriété, c'est l'équipe du client.

  • Hors périmètre

    L'entraînement des modèles, la recherche en évaluation de modèles, la conception des applications pour l'utilisateur final et la qualification juridique d'un cas d'usage donné. La couche produit la preuve dont un juriste a besoin ; elle ne remplace pas le juriste.

Termes repris de la page de définition : multi-modèle par architecture, audit par architecture, souverain par construction, contrôle des agents par architecture, le kill switch comme architecture. L'analogie de la tour de contrôle vaut tout au long du document : les modèles sont les avions, la couche les autorise, les journalise et les cloue au sol.

2 · Modèle de référence

Quatre plans, chacun avec une responsabilité et un artefact.

La couche se décompose en quatre plans. Chaque plan porte une seule responsabilité et produit un artefact qu'un tiers peut inspecter. Un plan sans artefact inspectable est une affirmation, pas un composant.

  1. 01

    Plan politique et gouvernance

    Porte les règles qui décident quelle tâche peut tourner, sur quel modèle, sur quelles données, sous quelle autorité. Les politiques sont du code, versionnées et évaluées à l'exécution par tenant et par tâche, avec des moteurs comme Open Policy Agent ou Cedar.

    Artefact : le jeu de politiques versionné, plus le registre des décisions d'architecture qui explique chaque écart par rapport au défaut.

  2. 02

    Plan routage et exécution

    Exécute le travail. Il route chaque tâche vers un modèle selon le profil de risque, le coût et la juridiction, et fait tourner les agents avec des permissions d'outils bornées. Il expose les outils par une interface neutre vis-à-vis des fournisseurs, comme le Model Context Protocol.

    Artefact : la table de routage et le catalogue de modèles, qui indiquent pour chaque classe de tâches le modèle principal, le modèle de repli et le corridor de résidence.

  3. 03

    Plan preuve et audit

    Enregistre chaque prompt, sortie, appel d'outil, action d'opérateur, changement de modèle et déclenchement du kill switch au moment où il a lieu. Les enregistrements sont en ajout seul, interrogeables par les équipes du client et exportables vers un régulateur sans reconstitution.

    Artefact : la piste d'audit elle-même, plus les formats d'export décrits à la section 4.

  4. 04

    Plan de contrôle : identité, périmètre et chemin d'arrêt

    Rattache chaque agent et chaque opérateur à une identité issue du fournisseur d'identité de l'entreprise, déclare ce que chaque agent peut toucher et porte le chemin d'arrêt. Arrêt, bridage et retour arrière s'appliquent par workflow, par modèle et par utilisateur.

    Artefact : le registre des agents, la matrice des permissions et le runbook du kill switch avec l'historique de ses exercices.

Les plans correspondent au schéma par défaut publié sur la page page Engineering. L'identité et la politique sont en amont ; l'orchestrateur multi-modèle, la piste d'audit immuable et le kill switch sont dans la couche ; l'observabilité, la résidence et l'export régulateur sont en aval. Pour une lecture en système de management des mêmes obligations, voir ISO/IEC 42001:2023 et le NIST AI Risk Management Framework 1.0.

3 · Les quatre propriétés comme contrôles testables

Chaque propriété prévient une défaillance et passe un test.

La page de définition nomme quatre propriétés. Ici, chacune devient un contrôle, avec la défaillance qu'il prévient, un test que l'acheteur mène, une condition de réussite et un point d'ancrage réglementaire. Une propriété qui ne se teste pas relève du marketing.

  • C1 · Multi-modèle par architecture

    Propriété. Plusieurs modèles de fondation tournent sous une seule gouvernance, et le choix du modèle est une décision de routage par tâche, réversible à tout moment.

    Défaillance prévenue. La captivité envers la feuille de route, la tarification ou la juridiction d'un seul fournisseur, et une panne en production quand ce fournisseur modifie ou retire un modèle.

    Test. Retirer le fournisseur principal pour une classe de tâches en production et router la tâche vers le repli déclaré. Mesurer le temps écoulé, les changements de code nécessaires et vérifier que la piste d'audit enregistre le changement.

    Condition de réussite. Le changement est une modification de configuration, pas une réécriture de code, et la piste montre le changement avec son auteur et son horodatage.

    Point d'ancrage réglementaire. DORA traite la concentration sur des tiers prestataires TIC comme un risque à gérer, et NIS2 impose des mesures de sécurité de la chaîne d'approvisionnement. La dépendance à un seul fournisseur est cette concentration.

  • C2 · Audit par architecture

    Propriété. Chaque action est enregistrée au moment où elle a lieu, en ajout seul, avec le contexte dont un régulateur a besoin pour reconstituer la décision.

    Défaillance prévenue. Une piste d'audit reconstituée à partir de journaux épars la semaine précédant une inspection, ce qui relève de la documentation, pas de l'audit.

    Test. Choisir au hasard une décision passée et exporter son enregistrement. Vérifier qu'il nomme l'acteur, le modèle et sa version, la politique, le vérificateur humain et l'horodatage sans assemblage manuel.

    Condition de réussite. L'enregistrement est complet, exporté depuis la piste elle-même, et toute modification est détectable.

    Point d'ancrage réglementaire. L'article 12 de l'EU AI Act impose aux systèmes à haut risque d'enregistrer automatiquement les événements tout au long de leur cycle de vie. L'article 19 impose de conserver ces journaux, et l'article 26 oblige les déployeurs à conserver les journaux placés sous leur contrôle.

  • C3 · Souverain par construction

    Propriété. La résidence des données, la juridiction des modèles et la garde des clés sont décidées par l'entreprise et appliquées par la couche charge par charge, avec zéro donnée en clair côté serveur là où l'architecture l'exige.

    Défaillance prévenue. Une promesse de souveraineté qui vit dans une note de politique pendant que prompts et sorties franchissent les frontières à l'exécution.

    Test. Faire passer une charge étiquetée dans la couche et tracer où se trouvent calcul, stockage, inférence et clés. Tenter de la router vers un modèle hors de son corridor déclaré.

    Condition de réussite. Chaque étape reste dans le corridor déclaré, les clés restent sous la garde du client, et la tentative hors corridor est refusée et journalisée.

    Point d'ancrage réglementaire. L'article 35 du RGPD impose une analyse d'impact relative à la protection des données pour les traitements à haut risque. La trace de résidence est l'élément factuel dont cette analyse a besoin.

  • C4 · Contrôle des agents par architecture

    Propriété. Chaque agent tourne sous sa propre identité, avec un périmètre d'outils déclaré, un budget et un chemin d'arrêt mesuré en secondes.

    Défaillance prévenue. Des agents qui agissent sous un compte de service partagé, ne peuvent pas être attribués et ne peuvent pas être arrêtés sans couper tout le workflow.

    Test. Demander à un agent d'appeler un outil hors de son périmètre, puis déclencher le kill switch sur cet agent. Mesurer le temps entre le déclenchement et l'arrêt, et confirmer que ses permissions d'outils sont révoquées.

    Condition de réussite. L'appel hors périmètre est refusé et journalisé, l'arrêt intervient en quelques secondes, et les autres agents du workflow continuent de tourner.

    Point d'ancrage réglementaire. L'article 14 de l'EU AI Act impose que les systèmes à haut risque soient conçus pour un contrôle humain effectif, y compris la capacité de les arrêter. L'article 26 confie ce contrôle à des personnes compétentes chez le déployeur.

Lorsqu'une décision produit des effets juridiques ou significatifs similaires sur une personne, l'article 22 du RGPD s'applique aux décisions exclusivement automatisées. Le champ de vérification humaine de l'enregistrement d'audit, décrit à la section 4, est la manière dont la couche prouve qu'une personne a réellement examiné le résultat. L'article 4 de l'EU AI Act ajoute une obligation de maîtrise de l'IA pour le personnel qui opère et vérifie ; nous la délivrons à travers des parcours de formation datés et résolus par rôle

4 · Modèle de preuve

Un enregistrement par action, chaîné, exportable sans reconstitution.

La piste d'audit est la production principale de la couche, pas un sous-produit. Chaque action produit un enregistrement portant les neuf champs ci-dessous. Les enregistrements sont en ajout seul et chaînés par empreinte, si bien qu'une suppression ou une modification rompt visiblement la chaîne.

Champ Contenu Pourquoi il compte
Identité de l'acteur L'identité de l'agent ou de l'opérateur émise par le fournisseur d'identité de l'entreprise, jamais un compte de service partagé. Attribution : chaque action a une identité responsable unique.
Modèle et version Le fournisseur, le nom du modèle et la version ou l'instantané exact utilisé pour cette action. Reproductibilité après la mise à jour ou le retrait d'un modèle par son fournisseur.
Politique appliquée L'identifiant et la version de la politique évaluée, avec la décision qu'elle a rendue. Prouve que l'action a tourné sous la règle en vigueur à ce moment.
Corridor de résidence La région déclarée pour le calcul, le stockage et l'inférence, et la référence de garde des clés. Fait de la souveraineté un fait établi action par action, et non une déclaration.
Référence des entrées Des pointeurs vers les données d'entrée et les sources de référence consultées, stockés par référence ou par empreinte plutôt qu'en clair. Reconstitue ce que le système a vu sans copier de données sensibles dans la piste.
Action La sortie produite ou l'appel d'outil effectué, avec son système cible et son résultat. Relie la sortie du modèle à sa conséquence dans le workflow.
Vérification humaine L'identité du vérificateur, la décision prise (approuver, rejeter, corriger) et le motif lorsqu'il est donné. Prouve le contrôle humain comme un événement, pas comme une intention.
Horodatage Heures de début et de fin issues d'une horloge synchronisée, en UTC. Établit la période d'utilisation et l'ordre des événements.
Chaîne d'empreintes L'empreinte de cet enregistrement combinée à celle de l'enregistrement précédent. Rend toute altération détectable par quiconque détient l'export.

  • Le rapport au conseil

    Une synthèse périodique construite à partir de la piste : workflows en production, agents par identité, répartition des modèles par fournisseur, refus de politique, corrections humaines, exercices de kill switch et incidents. Chaque chiffre renvoie aux enregistrements qu'il agrège, si bien qu'un administrateur peut demander la preuve sous-jacente.

  • L'export régulateur

    Un extrait borné d'enregistrements bruts pour un système et une période, avec les versions de politique et le registre des agents en vigueur. Il est livré avec les empreintes de la chaîne, afin que le destinataire vérifie l'intégrité indépendamment de l'expéditeur.

Notre socle de mission conserve la piste selon le contrat, douze mois au minimum, comme publié dans le Trust Center. L'article 26 de l'EU AI Act fixe un plancher d'au moins six mois pour les journaux conservés par les déployeurs, sauf disposition contraire d'un autre texte.

5 · Modèle d'exploitation

Qui fait tourner la couche à chaque phase, et qui la possède ensuite.

Une architecture sans modèle d'exploitation se dégrade en un trimestre. Chaque mission suit six phases : Diagnostic, Architecture, Build, Governance, Adoption, Run. L'exploitation passe de notre équipe à celle du client selon un plan daté, écrit au contrat dès le premier jour.

Phase Qui fait tourner la couche Ce que le client détient à la fin de la phase
Diagnostic Pas encore de couche. Un partner désigné cartographie les agents, les obligations et l'écart de preuve. La carte des risques et l'architecture cible pour un workflow.
Architecture Hikari Blue Engineering, avec les équipes architecture et sécurité du client. Registres des décisions d'architecture, modèle de politiques, carte de résidence, conditions de sortie.
Build Une équipe mixte, dans l'environnement du client, sous le fournisseur d'identité du client. Du code dans les dépôts du client, des tests, de l'observabilité, les premiers runbooks.
Governance Une équipe mixte ; les fonctions risque et conformité du client possèdent le jeu de politiques. Politiques signées, registre des agents, premier exercice de kill switch consigné.
Adoption Les opérateurs du client en poste, Hikari Blue en soutien. Opérateurs et vérificateurs formés, registres de maîtrise de l'IA au titre de l'article 4.
Run L'équipe du client, avec un support run en option contractuelle. La couche complète : code, runbooks, preuve, historique des exercices.

  • Transfert de propriété

    Le code sur mesure, les modèles sur mesure, les fine-tunes, les bibliothèques de prompts, les runbooks et la documentation d'exploitation appartiennent au client à la sortie. Les composants réutilisables que nous conservons sont listés de manière exhaustive dans le MSA, si bien qu'aucune licence n'arrive par surprise.

  • Hikari Blue Ops, en option

    Hikari Blue Ops est notre produit de preuve, la couche sur laquelle nous opérons nos propres missions. Un client peut le conserver après la sortie sous son propre contrôle, ou le remplacer par tout composant qui passe les quatre contrôles.

  • Responsabilité nommée

    L'un des quatre partners, Engineering, Strategy, Talent ou Run, signe chaque mission de la première semaine à la sortie. Le journal des décisions porte le nom de l'opérateur qui a signé chaque ligne.

La réponse à la question « qui opère la couche après le transfert » est l'équipe du client. Le support run et Hikari Blue Ops sont des options que le client contracte, pas des dépendances dont il hérite. Les six phases en détail

6 · Protocole de due diligence

Six tests qu'un acheteur peut mener en une journée de travail.

Menez ces tests sur une copie de préproduction d'un workflow réel, avec l'opérateur du prestataire au clavier et votre propre auditeur qui consigne. Le protocole s'applique à tout operating layer, y compris le nôtre.

  1. 01

    Changement de fournisseur

    Désactiver le fournisseur de modèles principal pour une classe de tâches et laisser la couche basculer sur le repli. Mesurer le temps écoulé et compter les changements de code nécessaires.

    Réussite : la tâche aboutit sur le repli par la seule configuration, et le changement apparaît dans la piste.

  2. 02

    Export de la piste

    Désigner une décision passée et une période, puis demander l'export régulateur. Vérifier les neuf champs de l'enregistrement et recalculer vous-même la chaîne d'empreintes.

    Réussite : chaque champ est présent, la chaîne se vérifie, et personne n'assemble le fichier à la main.

  3. 03

    Chronométrage du kill switch

    Lancer une session d'agent, déclencher le kill switch depuis la console d'exploitation, et chronométrer l'intervalle entre le déclenchement et l'arrêt.

    Réussite : l'agent s'arrête en quelques secondes, ses permissions d'outils sont révoquées, et le déclenchement, son auteur et l'heure d'arrêt sont enregistrés.

  4. 04

    Tentative de sortie de périmètre

    Demander à un agent, directement ou par un contenu injecté, d'appeler un outil ou d'atteindre des données hors de son périmètre déclaré.

    Réussite : le plan politique refuse l'appel avant exécution, et le refus est journalisé avec la version de la politique qui s'est déclenchée.

  5. 05

    Preuve de résidence

    Étiqueter une charge avec un corridor de résidence et tracer le calcul, le stockage, l'inférence et la garde des clés. Tenter ensuite de la router vers un modèle hors corridor.

    Réussite : chaque étape se situe dans le corridor, les clés restent sous la garde du client, et la route hors corridor est refusée.

  6. 06

    Répétition du transfert

    Demander à l'opérateur du client, et non au prestataire, d'exécuter les tests 01 et 03 à partir du seul runbook.

    Réussite : l'équipe du client mène les deux sans aide du prestataire, ce qui montre que la couche tourne sans celui qui l'a construite.

Sur nos missions, les modèles changent en quelques heures, jamais en mois, et le comportement du kill switch est testé chaque trimestre et documenté dans le runbook de mission. Les délais d'incident, y compris les fenêtres de notification au régulateur prévues par le RGPD, DORA et NIS2, sont publiés dans le Trust Center

7 · Anti-patterns

Cinq conceptions qui ressemblent à un operating layer et échouent aux tests.

Chaque anti-pattern ci-dessous passe une démonstration et échoue à au moins un contrôle. Ils sont courants parce que chacun coûte moins cher à construire que la propriété qu'il imite.

  • La surcouche

    Une interface fine autour de l'API d'un seul modèle. Retirer le fournisseur casse le système : elle échoue à C1 et au test de changement de fournisseur.

  • L'audit rapporté après coup

    Des journaux collectés dans plusieurs systèmes et recousus avant une inspection. L'enregistrement est assemblé à la main et ne peut pas prouver qu'il n'a pas été modifié : il échoue à C2.

  • La souveraineté par note de politique

    Une résidence écrite dans une clause contractuelle pendant que l'exécution route librement. Rien ne refuse un appel hors corridor : elle échoue à C3 et à la preuve de résidence.

  • Les agents à identité partagée

    Plusieurs agents qui agissent sous un même compte de service. Aucune action n'est attribuable et aucun agent ne peut être arrêté seul : ils échouent à C4.

  • Le tableau de bord sans chemin d'arrêt

    Un tableau de bord de gouvernance qui montre l'activité mais ne peut pas l'arrêter. L'activité n'est pas la responsabilité ; sans kill switch câblé, il échoue à C4 et au test de chronométrage.

Notre politique de stack liste ce que nous ne livrons pas, dont les surcouches boîte noire sans prompts ni traces exportables, et tout agent en production sans identité propre. Lire la politique de stack

8 · Versions et citation

Comment citer ce document.

Cette URL est permanente et sert toujours la version en vigueur. Chaque modification d'une exigence incrémente la version et figure dans l'historique ci-dessous, afin qu'une citation reste rattachable au texte qu'elle cite.

  • Citation recommandée

    Hikari Blue, « AI Operating Layer Reference Architecture v1.0 », 25 septembre 2026, https://hikariblue.com/reference-architecture

    Les ancres de section sont stables : #scope, #reference-model, #controls, #evidence, #operating-model, #due-diligence, #anti-patterns, #cite.

  • Historique des versions

    v1.0 · 25 septembre 2026. Première version publique : périmètre et acteurs, quatre plans, quatre contrôles C1 à C4, enregistrement de preuve à neuf champs, modèle d'exploitation par phase, protocole de due diligence en six tests, cinq anti-patterns.

    Licence. Publié sous CC BY 4.0 : libre de citation, de reprise et de réutilisation, avec attribution à Hikari Blue et un lien vers cette URL.

Les corrections et contestations d'une exigence sont bienvenues de la part des architectes, des auditeurs et des régulateurs. Adressez-les par le canal conformité ; les modifications retenues sont créditées dans l'historique des versions.

Pour les architectes, RSSI, directions des risques et auditeurs

Appliquez le protocole à votre propre workflow.

Trente minutes avec un partner désigné. Nous projetons les quatre plans sur un workflow que vous opérez déjà et montrons où les six tests passeraient ou échoueraient aujourd'hui. Vous repartez avec le schéma, que nous travaillions ensemble ou non.

Réserver le diagnostic Ou lire la définition canonique de l'AI operating layer