Architecture de référenceVersion 1.025 septembre 2026
Architecture de référence de la couche d’exploitation de l’IA
Une couche d’exploitation de l’IA est le logiciel et la discipline d’exploitation qui s’interposent entre les modèles d’IA et les systèmes d’une entreprise, construits avec la rigueur qu’exigent les secteurs régulés. Ce document en spécifie les plans, les 4 contrôles testables, le modèle de preuve et un protocole de due diligence en 1 journée. Il s’adresse aux architectes, RSSI, directions des risques et auditeurs qui en évaluent ou en construisent une.
Sur cette page
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 une couche d’exploitation de l’IA selon les mêmes critères. Elle prolonge la définition canonique publiée sur la page Qu’est-ce qu’une couche d’exploitation de l’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 une couche d’exploitation de l’IA 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.
Ce qu’est la couche, qui agit dessus, et ce qu’elle n’est pas.
La couche d’exploitation de l’IA est le logiciel et la discipline d’exploitation entre les modèles d’IA et les systèmes de l’entreprise. Elle décide quel modèle traite quelle tâche, sous quelle politique, avec quelle résidence des données, enregistre chaque action et porte un chemin d’arrêt conçu pour arrêter 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.
4 plans, chacun avec une responsabilité et un artefact.
La couche se décompose en 4 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.
Une opération gouvernée sur les 4 plans.
Lecture de haut en bas : le plan de contrôle porte l’identité et le chemin d’arrêt (C4), la politique et la gouvernance appliquent la règle en vigueur (C3), le routage et l’exécution envoient la tâche vers un modèle (C1), et la preuve et l’audit enregistrent l’action (C2). Chaque plan produit l’artefact nommé plus bas.
Chaque action s’ajoute à la piste d’audit ; rien n’est écrasé.Une personne nommée approuve le paiement avant sa libération.La version de modèle en vigueur est figée ; elle ne change que sur décision.La requête traverse chaque plan dans l’ordre ; aucun contrôle n’est contourné.4 plans, 4 contrôles : identité et arrêt, règle, modèle, enregistrement.L’arrêt, sur le plan de contrôle, coupe la requête là où elle se trouve.
- Systèmes de l’entreprise
- Fournisseur d’identité de l’entreprise
- ERP · demande de paiement
C4Contrôle- Registre des agents
ap-pay-02 - Matrice des permissions : libération du paiement, ERP
- Procédure d’arrêt d’urgence
C3Politiques et gouvernance- Jeu de règles
P-04 v3 - Validation humaine requise au-delà du seuil
C1Routage et exécution- Table de routage : fournisseur A, version figée
- Modèle de repli, déclaré
- Validation humaine
- A. Moreau, opératrice de trésorerie
C2Preuve et audit- Enregistrement #4126
- Enregistrement #4127, chaîné par hachage
- Supervision
- Export pour le régulateur
- Rapport au conseil
- ERP · libération du paiement
- Systèmes de l’entrepriseFournisseur d’identité de l’entreprise · ERP · demande de paiement
C4ContrôleRegistre des agentsap-pay-02· Matrice des permissions : libération du paiement, ERP · Procédure d’arrêt d’urgenceC3Politiques et gouvernanceJeu de règlesP-04 v3· Validation humaine requise au-delà du seuilC1Routage et exécutionTable de routage : fournisseur A, version figée · Modèle de repli, déclaré- Validation humaineA. Moreau, opératrice de trésorerie
C2Preuve et auditEnregistrement #4126 · Enregistrement #4127, chaîné par hachage- SupervisionExport pour le régulateur · Rapport au conseil · ERP · libération du paiement
Version texte
- Une demande de paiement arrive de l’ERP ; l’agent ap-pay-02 agit sous une identité émise par le fournisseur d’identité de l’entreprise.
- Le contrôle (C4) vérifie le registre des agents et la matrice des permissions, et porte la procédure d’arrêt d’urgence et le chemin d’arrêt.
- Politiques et gouvernance (C3) applique le jeu de règles P-04 v3 : une validation humaine est requise au-delà du seuil.
- Routage et exécution (C1) confie la tâche au fournisseur A sur une version figée, avec un modèle de repli déclaré.
- A. Moreau, opératrice de trésorerie, valide au point de validation humaine.
- Preuve et audit (C2) ajoute l’enregistrement #4127, chaîné par hachage à #4126.
- La supervision reçoit l’export pour le régulateur et le rapport au conseil ; l’ERP libère le paiement.
- 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.
- 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.
- 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.
- 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 sont conçus par workflow, par modèle et par utilisateur.
Artefact : le registre des agents, la matrice des permissions et les procédures d’exploitation 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 en ajout seul 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.
Chaque propriété prévient une défaillance et passe un test.
La page de définition nomme 4 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 conçu pour agir en secondes, chronométré pendant l’engagement.
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 d’acculturation datés et déclinés par rôle
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 9 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 processus métier. |
| 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. |
4 enregistrements, chaînés par empreinte.
Le plan de preuve, dessiné : chaque enregistrement porte l’empreinte du précédent, si bien qu’une modification ou une suppression rompt visiblement la chaîne, et le rapport au conseil comme l’export réglementaire sont lus dans les mêmes enregistrements.
- Plan de preuve et d’auditC2 dans l’architecture de référence v1.0 : un enregistrement par action.
- Enregistrements #4124 à #4127Ajout seul, 9 champs chacun ; #4127 est l’action de cet exemple.
- Liens de hachageChaque enregistrement porte le hachage du précédent : une modification ou une suppression rompt la chaîne de façon visible.
- Export pour le régulateurUn extrait ciblé pour un système et une période, livré avec les hachages de la chaîne (sceau).
- Rapport au conseilConstruit à partir de la piste ; chaque chiffre renvoie à ses enregistrements.
Version texte
Le plan de preuve et d’audit porte 4 enregistrements, #4124 à #4127, chacun relié au précédent par son hachage. En dessous, la zone de supervision reçoit un export pour le régulateur portant les hachages de la chaîne sous sceau, et un rapport au conseil construit à partir des mêmes enregistrements.
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, 12 mois au minimum, comme publié dans le Trust Center. L’article 26 de l’EU AI Act fixe un plancher d’au moins 6 mois pour les journaux conservés par les déployeurs, sauf disposition contraire d’un autre texte.
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 6 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 associé désigné cartographie les agents, les obligations et l’écart de preuve. | La carte des risques et l’architecture cible pour un processus métier. |
| 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. |
| Construction | 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 premières procédures d’exploitation. |
| Gouvernance | 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. |
| Exploitation | L’équipe du client, avec un support run en option contractuelle. | La couche complète : code, procédures d’exploitation, preuve, historique des exercices. |
Ce que le client détient à la sortie.
Le transfert de propriété, dessiné : le code sur mesure, les modèles, les bibliothèques de prompts et les procédures d’exploitation se trouvent côté client, et les composants réutilisables conservés par Hikari Blue sont listés dans le MSA.
- Composants conservésComposants réutilisables conservés par Hikari Blue, listés de façon exhaustive dans le MSA.
- Associé désignéL’un des 5 associés signe la mission de la première semaine à la sortie.
- Transfert de propriété à la sortieInscrit au contrat dès le premier jour.
- Modèle sur mesure ou ajustementPropriété du client à la sortie.
- Code sur mesureDans les dépôts du client, propriété du client.
- Bibliothèques de promptsLes prompts de chaque processus métier, propriété du client.
- Procédures d’exploitation et documentationRemises à des responsables formés de l’équipe du client.
- Opérateurs du clientL’équipe du client exploite la couche après le transfert.
Version texte
2 plans. Sur le plan Hikari Blue : les composants réutilisables conservés, listés dans le MSA, et l’associé désigné qui signe la mission. Une flèche marque le transfert de propriété à la sortie. Sur le plan du client : le code sur mesure dans ses dépôts, le modèle sur mesure ou l’ajustement, les bibliothèques de prompts, les procédures d’exploitation et la documentation, et les opérateurs du client qui exploitent la couche après le transfert.
Transfert de propriété
Le code sur mesure, les modèles sur mesure, les fine-tunes, les bibliothèques de prompts, les procédures d’exploitation 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.
La couche de preuve et de contrôle, en option
C’est la couche sur laquelle nous opérons nos propres missions, et celle que nous concevons et exploitons pour nos clients. Un client peut le conserver après la sortie sous son propre contrôle, ou le remplacer par tout composant qui passe les 4 contrôles.
Responsabilité nommée
L’un des 5 associés, 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 AI Governance Operations sont des options que le client contracte, pas des dépendances dont il hérite. Les 6 phases en détail
6 tests qu’un acheteur peut mener en 1 journée de travail.
Menez ces tests sur une copie de préproduction d’un processus métier réel, avec l’opérateur du prestataire au clavier et votre propre auditeur qui consigne. Le protocole s’applique à toute couche d’exploitation de l’IA, y compris la nôtre.
- 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.
- 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 9 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.
- 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.
- 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.
- 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.
- 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 des seules procédures d’exploitation.
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.
Dans notre architecture de référence, changer de modèle est un changement de routage, pas une reconstruction, et le comportement du kill switch est documenté et testé dans les procédures d’exploitation de la 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
5 conceptions qui ressemblent à une couche d’exploitation de l’IA 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 d’environnement technique 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 d’environnement technique
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, 4 plans, 4 contrôles C1 à C4, enregistrement de preuve à 9 champs, modèle d’exploitation par phase, protocole de due diligence en 6 tests, 5 anti-patterns.
Correction éditoriale · 25 octobre 2026 : phrase de licence alignée, périmètre et réserves précisés.
Licence. Publié sous licence CC BY 4.0 : citation, reprise et réutilisation libres, avec attribution à Hikari Blue et lien vers cette page. La licence couvre les textes, tableaux et schémas de Hikari Blue sur cette page ; elle ne couvre ni les données, citations et textes juridiques de tiers, qui gardent leurs propres conditions, ni le nom et le logo Hikari Blue, marques de UNITED4 LLC.
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.
Étape suivante : qui décide, qui répond et quelle preuve voit le conseil, en 15 contrôles. Cadre de gouvernance de l’IA d’entreprise v1.0
Appliquez le protocole à votre propre processus métier.
30 minutes avec un associé désigné. Nous projetons les 4 plans sur un processus métier que vous opérez déjà et montrons où les 6 tests passeraient ou échoueraient aujourd’hui. Vous repartez avec le schéma, que nous travaillions ensemble ou non.
- Votre processus métier projeté sur les 4 plans
- Les tests qui passeraient ou échoueraient aujourd’hui
- Le schéma, que nous travaillions ensemble ou non