Guide de l’acheteurArchitectureVersion 1.025 octobre 2026
Une architecture d’IA auditable, sans verrou fournisseur
Un système d’IA bâti autour de l’interface d’un seul fournisseur, dont l’historique dort dans des journaux que personne ne sait exporter, porte 2 risques. Quand le fournisseur change un modèle, un prix ou ses conditions, l’entreprise reconstruit ; quand un auditeur interroge une décision, l’équipe la reconstitue. La réponse est architecturale : multi-modèle par architecture et audit par architecture, 2 contrôles qu’un acheteur teste en 1 jour ouvré.
Sur cette page
Le choix du modèle comme décision de routage, et un enregistrement écrit au moment de l’action.
Une architecture d’IA est auditable sans verrou fournisseur quand plusieurs modèles de fondation tournent sous une même gouvernance, que le choix du modèle est une décision de routage par tâche, réversible à tout moment, et que 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.
Ce sont les contrôles C1, multi-modèle par architecture, et C2, audit par architecture, de l’architecture de référence de la couche d’exploitation de l’IA v1.0. Dans cette page, « nous » désigne Hikari Blue, qui conçoit et exploite la couche d’exploitation de l’IA qui relie les modèles, les données et les processus métiers.
2 défaillances qui passent pour des choix techniques jusqu’au jour où elles coûtent.
Captif d’un fournisseur
La dépendance à la feuille de route, aux prix ou à la juridiction d’un seul fournisseur, et une panne de production quand il modifie ou retire un modèle. DORA traite la concentration des prestataires tiers de TIC comme un risque à gérer, et NIS2 exige des mesures de sécurité de la chaîne d’approvisionnement.
Un audit reconstitué avant l’inspection
Une piste d’audit reconstituée à partir de journaux épars la semaine qui précède une inspection est de la documentation, pas un audit. L’article 12 de l’AI Act impose aux systèmes à haut risque d’enregistrer automatiquement les événements tout au long de leur cycle de vie.
4 conditions, chacune vérifiable.
Un repli déclaré
La table de routage indique, pour chaque classe de tâches, le modèle principal, le modèle de repli et le corridor de résidence.
Une bascule testée
Retirez le fournisseur principal pour une classe de tâches. Le test est réussi quand la bascule est un changement de configuration, pas une réécriture du code, et que la piste l’enregistre avec son auteur et son horodatage.
Code, prompts et données à vous
Le code sur mesure est dans vos dépôts, les bibliothèques de prompts et les modèles sur mesure vous reviennent à la sortie, et vous décidez de la résidence des données et de la garde des clés. Ce que nous conservons est listé dans le MSA.
Les modèles que vous choisissez
Claude, Gemini, GPT et les modèles à poids ouverts tournent sous une même gouvernance : modèles de frontière par API, modèles à poids ouverts dans votre cloud ou sur site, par configuration.
Un enregistrement par action, 9 champs, exportable sans reconstitution.
La piste d’audit est la production principale de la couche, pas un sous-produit. Les enregistrements sont en ajout seul et chaînés par empreinte : une suppression ou une modification rompt la chaîne de façon visible.
- Identité de l’acteur
- Modèle et version
- Politique appliquée
- Corridor de résidence
- Référence des entrées
- Action
- Vérification humaine
- Horodatage
- Chaîne d’empreintes
L’export pour le régulateur
Un extrait circonscrit des enregistrements bruts pour un système et une période, avec les versions de politiques et le registre des agents en vigueur, livré avec les empreintes de la chaîne.
Le rapport au conseil
Une synthèse périodique tirée de la piste ; chaque chiffre renvoie à ses enregistrements.
Les articles 19 et 26 de l’AI Act imposent de conserver ces journaux sous le contrôle du déployeur, pendant au moins 6 mois sauf disposition contraire.
Une spécification n’est pas un déploiement, et un déploiement que nous décrivons n’est pas une mesure.
Les cas sont anonymisés à la demande de chaque client, et aucun chiffre de performance n’est publié.
Spécifié
C1, C2, leurs tests et l’enregistrement en 9 champs sont publiés dans l’architecture de référence v1.0, sous licence CC BY 4.0.
Déployé, selon Hikari Blue
La mission en services financiers présentée sur la page Missions exploite une orchestration multi-modèle avec une piste d’audit émise à l’exécution ; changer de modèle est un changement de routage, sans effet sur l’audit. Mesuré par le client ; valeurs non divulguées.
Démontrable sous NDA
Une présentation de la mission sous NDA réciproque, conduite par un associé désigné, sur demande.
Menez la bascule et l’export sur une copie de préproduction d’un processus réel.
Le protocole de due diligence de l’architecture de référence compte 6 tests qu’un acheteur mène en 1 jour ouvré, l’opérateur du prestataire au clavier et votre propre auditeur qui consigne. 3 d’entre eux répondent à cette page.
- 01
Bascule de fournisseur
Désactivez le fournisseur de modèle principal pour une classe de tâches et laissez la couche basculer sur le repli. Mesurez le temps écoulé et les modifications de code.
Réussite : la tâche aboutit sur le repli par simple configuration, et la bascule figure dans la piste.
- 02
Export de la piste
Désignez une décision passée et une période, puis demandez l’export pour le régulateur. Vérifiez les 9 champs de l’enregistrement et recalculez 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.
- 06
Répétition du transfert
Demandez à votre opérateur, pas au prestataire, d’exécuter la bascule de fournisseur et le chronométrage du kill switch à partir de la seule procédure.
Réussite : votre équipe mène les deux sans l’aide du prestataire, preuve que la couche tourne sans son constructeur.
Ce que demandent DSI et responsables des risques avant de signer.
Pouvons-nous changer de modèle d’IA sans reconstruire ?
Oui, si l’architecture route chaque classe de tâches vers un modèle principal avec un repli déclaré. Changer de modèle est alors un changement de configuration, enregistré dans la piste avec son auteur et son horodatage. Si le retrait d’un fournisseur casse le système, c’est une surcouche, pas une couche d’exploitation.
Quels modèles pouvons-nous exploiter ?
Claude, Gemini, GPT et les modèles à poids ouverts, sous une même gouvernance : modèles de frontière par API chez Anthropic, OpenAI, Mistral ou Google, et modèles à poids ouverts dans votre cloud ou sur site, par configuration.
À qui appartiennent les prompts, le code et les données ?
À vous. Le code sur mesure est dans vos dépôts ; les bibliothèques de prompts, les modèles sur mesure et les fine-tunes vous appartiennent à la sortie. Vous décidez de la résidence des données et de la garde des clés, et la couche les applique par charge de travail. Ce que nous conservons est listé dans le MSA.
Que reçoit un auditeur ?
Un export pour le régulateur : les enregistrements bruts d’un système sur une période, 9 champs par action, avec les versions de politiques, le registre des agents en vigueur et les empreintes de la chaîne, pour que le destinataire vérifie l’intégrité par lui-même.
Comment le tester avant de signer ?
Menez la bascule de fournisseur et l’export de la piste sur une copie de préproduction d’un processus réel, en 1 jour ouvré, votre propre auditeur consignant les résultats. Le premier échange avec un associé désigné est gratuit.
Testez la bascule et la piste sur l’un de vos processus.
30 minutes avec un associé désigné ; le premier échange est gratuit. Nous projetons un processus que vous exploitez déjà sur les 4 plans et montrons où la bascule et l’export réussiraient ou échoueraient aujourd’hui.
- Votre processus projeté sur les 4 plans
- Où la bascule et l’export réussissent ou échouent aujourd’hui
- Le schéma, que nous travaillions ensemble ou non