L’IA ne devrait pas produire des sorties “pour faire des sorties”; elle devrait structurer la décision qui déclenche la revue, assigne la responsabilité et conserve une traçabilité du résultat.L’architecture décisionnelle est le système d’exploitation qui détermine comment le contexte circule, comment les décisions sont prises, quand les approbations sont déclenchées et comment les résultats sont assumés à l’intérieur d’une entreprise. (nist.gov) Dans beaucoup d’installations d’orchestration par agents que l’on observe chez des ESM canadiennes, le goulot n’est généralement pas le modèle. Le vrai problème vient de limites de décision floues, d’enregistrements de contexte manquants et d’une logique de revue qui vit “dans la tête de quelqu’un”. La réponse est un design d’approbation concret : définir les signaux et les seuils, nommer la personne responsable de la revue et de l’escalade, puis capturer un dossier décisionnel “entrée → logique → décision → résultat” réutilisable en opération. (nist.gov)> [!INSIGHT]> Si votre étape d’approbation d’IA ne peut pas être rejouée à partir de preuves, ce n’est pas un workflow d’approbation—c’est une conversation.
Ce qui casse d’abord dans les approbations d’IALa plupart des
échecs d’approbation en workflows agents ressemblent à ceci
la personne réviseuse reçoit une réponse sans les preuves nécessaires pour justifier la décision, et l’entreprise ne sait plus si l’IA a utilisé les bonnes sources, appliqué la bonne logique ou aurait dû escalader.Dans le contexte canadien des systèmes de décision automatisée, la politique attend une évaluation structurée (notamment via l’AIA) et des pratiques d’explication lorsque les systèmes automatisés assistent ou rendent des décisions administratives. (tbs-sct.canada.ca) En parallèle, NIST AI RMF présente la “fiabilité” comme quelque chose qu’on gère dans la conception, l’usage et l’évaluation, avec des considérations de risque explicites—pas comme un choix unique de modèle. (nist.gov) Pour une ESM, l’implication est directe : si vous n’intégrez pas une couche de gouvernance dans l’orchestration (seuils, chemins d’escalade, traçabilité), la revue devient lente et incohérente, et vous accumulez du “savoir tacite” plutôt que de la mémoire organisationnelle.
Concevoir des seuils de revue alignés sur l’impact réel de
la décisionL’architecture décisionnelle transforme l’approbation en contrôle acheminé. Cela exige des seuils basés sur l’impact de la décision—pas sur la commodité. Au Canada, les pratiques liées à l’AIA servent à soutenir l’évaluation des risques et des mesures d’atténuation graduées selon le niveau d’impact. (canada.ca) NIST AI RMF insiste sur l’intégration de considérations de confiance dans la façon dont l’IA est conçue, développée, utilisée et évaluée. (nist.gov) ISO/IEC 42001 traite la gouvernance de l’IA comme un système de gestion : exigences et guidance pour établir, implémenter, maintenir et améliorer continuellement un système de gestion de l’IA, incluant les considérations de risque/impact, des mécanismes d’oversight humain et la tenue de dossiers. (iso.org)
Un mouvement opérationnel simple pour une orchestration par agents chez une ESM :1) Définir une “frontière d’approbation” pour chaque action de workflow (ex. approuver une exception facture, modifier un plan client, émettre une offre, refuser une demande).2) Classer les actions par niveau d’impact (faible/moyen/élevé) avec des critères internes : exposition financière, risques juridiques/conformité, sensibilité à la vie privée, complexité du droit de recours.3) Définir des seuils de revue par niveau d’impact :
- Faible impact : approbation automatique si la confiance et la couverture des sources satisfont les exigences; conserver un dossier.
- Impact moyen : revue fonctionnelle si (a) la confiance est sous la cible, ou (b) les sources récupérées ne couvrent pas les contraintes de politique requises.
- Élevé impact : approbation obligatoire par une personne nommée lorsque l’agent propose des actions pouvant avoir un effet matériel sur des droits/avantages, des conditions contractuelles ou des obligations réglementées.
Règle de décision concrète à intégrer dans l’orchestration :
- **Escalader si les sources primaires récupérées sont incomplètes OU si l’action proposée modifie un paramètre réglementé en dehors d’une plage approuvée.**Cette règle ancre l’approbation dans les systèmes de contexte (preuves enregistrées : ce que l’agent a vu, quelles sources il a utilisées, et quelles contraintes il a respectées), plutôt que dans “ça a l’air plausible”. L’implication : vous gagnez de la vitesse sans sacrifier la responsabilité—les cas légers avancent vite, les cas élevés sont signés par l’humain responsable, et tous les cas génèrent des traces récupérables pour audit.> [!DECISION]> Votre seuil n’est pas “à quel point le modèle est intelligent”. Votre seuil, c’est “combien ça coûte d’être faux pour l’entreprise—et pour les personnes concernées”.
Donner la propriété de l’escalade à des rôles réellement responsables
Des
seuils sans responsabilité nommée créent des retards et des boucles de blame. L’architecture décisionnelle doit préciser qui révise, qui escalade et ce qui compte comme “terminé”. Dans l’environnement canadien des systèmes de décision automatisée, on attend des explications structurées et des processus coordonnés, avec l’AIA comme outil central de risque et des points de consultation, notamment pour la vie privée. (canada.ca) NIST AI RMF considère la gouvernance comme intégrée au cycle de vie (conception → usage → évaluation). (nist.gov) ISO/IEC 42001 formalise une logique de système de gestion, incluant des exigences et des dossiers de gouvernance. (iso.org)
Pour les opérateurs cross-fonctions d’ESM, transformez cela en modèle d’acheminement (style RACI) directement dans la couche d’orchestration :
- Propriétaire (responsable/“accountable”) : rôle business qui assume la catégorie de décision (ex. Opérations financières pour exceptions; Conformité RH pour décisions liées aux politiques; Juridique/Conformité pour conditions contractuelles).
- Réviseur (responsable de la revue) : personne qui valide les preuves de contexte et les contraintes de politique.
- Rôle d’escalade (approbation des exceptions) : personne/dirigeant·e nommé·e pour les cas à impact élevé.
- Exécutant technique (responsable des dossiers) : équipe qui garantit que l’orchestration produit les preuves nécessaires au réviseur.
Où le mettre concrètement dans l’orchestration par agents ?
- À l’étape d’orchestration, émettre un “dossier décisionnel” pour la personne réviseuse :
- Signaux/inputs : enregistrements récupérés + faits utilisateur + indicateurs de provenance.
- Logique d’interprétation : quelles contraintes de politique ont été appliquées.
- Demande de décision/revue : ce que l’agent propose et pourquoi ça dépasse (ou respecte) les seuils.
- Traçabilité du résultat : décision finale + horodatage + identité du réviseur + modifications éventuelles.
L’implication : l’escalade devient un transfert contrôlé basé sur des dossiers, pas un fil de messages improvisé.
Construire la traçabilité des résultats de l’input jusqu’à la décision
La
traçabilité des résultats rend les approbations auditables et réutilisables en opération. Sans elle, chaque workflow refait les mêmes questions—et re-discute les mêmes décisions. NIST AI RMF insiste sur l’intégration de considérations de confiance sur l’ensemble du cycle de vie, ce qui suppose des enregistrements permettant l’évaluation répétée et l’amélioration. (nist.gov) ISO/IEC 42001 pousse une logique de système de gestion qui soutient la tenue de dossiers et l’amélioration continue. (iso.org) Côté vie privée, les pratiques canadiennes d’évaluation (PIA) servent à identifier et atténuer les risques lorsque des renseignements personnels sont impliqués dans des décisions. (priv.gc.ca)
Une chaîne “signal → logique → décision → résultat” qui doit être rejouable par votre orchestration :
- Signal/input : “exception facturation” avec historique fournisseur + règles de politique internes + identifiants des sources primaires récupérées.
- Logique d’interprétation : l’agent vérifie si l’exception se situe dans la plage approuvée et si les contraintes de politique sont respectées.
- Décision/revue : si seuils OK, approbation; sinon, revue/re-signature par un humain.
- Traçabilité : stocker les identifiants des enregistrements récupérés, les règles de politique appliquées, le résultat du test de seuil, la décision du réviseur et le résultat final.> [!EXAMPLE]> Si une personne rédige une réponse client avec l’aide d’un agent, ne stockez pas seulement le texte final. Stockez aussi les faits utilisés, les extraits de politique récupérés, le résultat du test de seuil, et qui a autorisé les modifications. La prochaine fois, le système peut réutiliser la mémoire organisationnelle au lieu de repartir de zéro.L’implication : approbations plus rapides (dossier de preuve immédiat pour le réviseur) et gouvernance plus facile (vos artefacts d’évaluation peuvent référencer des dossiers, pas des reconstructions manuelles).
Exemple concret et modes de panne à prévoir
Prenons un exemple d’ESM canadienne qui utilise l’orchestration par agents pour trier des exceptions de facturation.Frontière de workflow (outil interne sécurisé) :
- Le système d’IA est un outil privé interne qui propose approuver/refuser et rédige la justification client.
- Il ne doit pas finaliser des changements irréversibles sans revue humaine lorsque l’exception est d’impact moyen/élevé.
Exemple opérationnel :
- Cas faible impact (écart historique limité) : orchestration approuve automatiquement si la confiance dépasse une cible et si l’ensemble de sources/politiques récupérées couvre les contraintes requises.
- Cas impact moyen (changement de paramètre politique) : orchestration route vers la personne réviseuse Finance si soit la confiance baisse, soit les contraintes récupérées sont incomplètes.
- Cas élevé impact (exposition financière importante) : escalade obligatoire vers une personne “accountable” nommée.
Modes de panne et compromis :
- Mode de panne : preuves générées mais non capturées. Si votre orchestration explique “pourquoi” à la personne réviseuse, mais ne conserve pas un dossier décisionnel durable, vous échouez sur la traçabilité en pratique—even si la revue “semblait” bonne. (nist.gov)
- Mode de panne : seuils trop grossiers. Si tout devient “élevé impact”, vous recréez le goulot. NIST AI RMF pousse à raffiner via l’évaluation des résultats, pas à régler une fois puis ignorer. (nist.gov)
- Compromis : plus de structure augmente l’effort à court terme. Vous devez définir signaux, mapping des propriétaires d’escalade et imposer une structure de dossiers. Le bénéfice : investissement transformé en mémoire organisationnelle et réutilisation opérationnelle. ISO/IEC 42001 cadre cette logique comme un cycle d’amélioration d’un système de gestion. (iso.org)Ligne d’autorité :« L’architecture décisionnelle, c’est l’OS des approbations : définissez la frontière, routez la responsabilité, et stockez les preuves pour pouvoir rejouer les décisions. »
Open Architecture Assessment
La prochaine étape consiste à structurer votre réflexion en un assessment d’architecture que vous pouvez mener avec des propriétaires cross-fonctions (opérations + finance/RH/juridique/conformité + opérations techniques).
Le Open Architecture Assessment d’IntelliSync commence par une question : quelle est votre frontière d’approbation pour les décisions assistées par IA, et pouvez-vous produire un dossier décisionnel auditables de l’entrée jusqu’au résultat aujourd’hui, de façon cohérente? Si la réponse est “pas vraiment”, alors vous savez déjà quel design viser.En choisissant un workflow où le goulot est réel, on cartographie :
- les signaux/inputs et les systèmes de contexte nécessaires- les seuils de revue et la propriété d’escalade- les exigences de traçabilité des résultats, en tenant compte des réalités de gouvernance au CanadaDémarrez l’évaluation pour transformer la sortie “bon marché” de l’IA en architecture décisionnelle réutilisable.