L’IA ne doit pas produire des résultats « pour produire » ; elle doit structurer les décisions pour que le contexte, les validations et la responsabilité restent traçables pendant les transferts—surtout quand le travail passe d’outils à des personnes, puis à des agents. La decision architecture est le système d’exploitation qui détermine comment le contexte circule, comment les décisions sont prises, comment les approbations sont déclenchées et comment les résultats sont détenus au sein d’une entreprise. (nist.gov)Dans les PME canadiennes et les petites équipes de direction, le goulot n’est généralement pas « le modèle ne sait pas répondre ». C’est plutôt que les transferts entre agents effacent la piste d’audit : à chaque exception, l’agent suivant reformule la justification—ce qui crée des réécritures d’exceptions et réduit la réutilisation opérationnelle.> [!INSIGHT] Le contenu est bon marché. La pensée structurée (signal → logique → décision → responsable → dossier) est l’actif d’exploitation rare.
Ce qui casse quand les agents « héritent du contexte
» plutôt que d’hériter d’une décision
Dans les workflows agentiques, le transfert passe souvent par un récit (“voici ce qui s’est passé”) plutôt que par un dossier de décision (“voici le signal, la logique, la règle, et qui est responsable”). Cette lacune d’architecture se manifeste par des réécritures d’exceptions : chaque fois que le workflow échoue ou que l’incertitude augmente, l’agent suivant re-interprète la situation et génère une nouvelle justification—sans frontière décisionnelle stable et gouvernable.Les preuves primaires mises en avant par le NIST insistent sur une gestion du risque qui repose sur des contrôles de cycle de vie (évaluation, documentation, responsabilisation), et pas uniquement sur des sorties produites à la volée. (nist.gov) En pratique, dès que le transfert remplace une décision précédente par un nouveau récit, on perd la traçabilité et on augmente la probabilité de dérive de comportement entre équipes.Implication pour les opérateurs : traitez les transferts comme des transferts de décision, pas comme des transferts de conversation. Si vous ne pouvez pas rejouer la chaîne du signal à l’issue, vous ne pouvez pas la gouverner.
Concevoir un système de contexte qui conserve la chaîne de
décision à chaque transfertUne architecture d’exploitation native pour les systèmes de contexte est la couche qui rend l’IA fiable en production en structurant le contexte, l’orchestration, la mémoire, les contrôles et la revue humaine autour du travail. (nist.gov) Pour ce sujet, le levier central est d’assurer que le système de contexte transporte une capsule de décision—pas seulement un résumé. Utilisez cette chaîne explicitement dans votre design opérationnel :Signal d’entrée (faits consignés + métadonnées de sources) → logique d’interprétation (gestion de l’incertitude et des contraintes de politique) → décision ou revue (issue d’une règle) → responsable (rôle et responsabilité) → dossier de décision (artefacts prêts à l’audit).Le cadre AI RMF 1.0 du NIST vise une gestion des risques organisée et répétable (cartographier, évaluer, gérer), ce qui correspond à l’exigence de reproductibilité opérationnelle des décisions. (nist.gov) ISO/IEC 42001 place, elle, la gouvernance de l’IA dans une logique de management system qui attend des contrôles opérationnels et une traçabilité conçus pour être maintenus. (iso.org)
Exemple concret (workflow PME canadienne) :Une équipe orientée conformité documentaire (ex. RH) utilise un workflow IA pour classifier les demandes internes et rédiger une réponse.Quand le premier agent rencontre une exception—par exemple « éligibilité aux avantages incertaine »—l’agent suivant ne devrait pas régénérer une nouvelle justification. Votre système de contexte doit plutôt persister :Le signal d’origine : la section exacte du document de politique, avec version/date, et les clauses extraites pertinentes.La règle d’exception : ce que signifie “incertain” (ex. pièces manquantes ; termes de politique contradictoires).Le seuil de revue : quand escalader vers un responsable RH/juridique.Le propriétaire : qui approuve la classification finale et la réponse.Le dossier : ce qui a été vérifié, ce qui manquait et quelle règle a déclenché l’exception.C’est ainsi que vous empêchez les réécritures : vous conservez la frontière décisionnelle et vous autorisez uniquement des divergences contrôlées (ex. escalades) lorsque c’est justifié.> [!DECISION] Si votre contexte de transfert ne contient pas la règle de décision + le seuil de revue + le responsable, vous réécrirez les exceptions—parce que l’agent suivant n’aura pas de frontière stable à suivre.
Faire converger la gouvernance et l’exploitation pendant les transferts d’agents
La
gouvernance de l’IA au Canada devient actionnable quand on la mappe sur les frontières de décision du workflow, pas quand on la traite comme un document séparé. Dans le secteur public fédéral, la Directive sur la prise de décisions automatisée fonctionne avec une approche proportionnelle fondée sur l’impact, soutenue par l’outil Algorithmic Impact Assessment (AIA). (canada.ca) Même si votre PME n’est pas soumise, le pattern est transférable : l’impact de la décision doit déterminer le niveau de revue et de tenue des preuves.Côté confidentialité, le Commissariat à la protection de la vie privée du Canada souligne que la responsabilité des décisions demeure celle de l’organisation, et non de l’outil automatisé. (priv.gc.ca)
Concrètement, à chaque transfert d’agent, vous devez :Nommer les rôles dans la couche de gouvernance.Définir une trajectoire d’escalade.Écrire des déclencheurs d’escalade qui tiennent compte de l’impact et de l’évidence disponible.Critère opérationnel pour l’escalade :Escaladez immédiatement quand les preuves issues des sources primaires sont manquantes ou incohérentes.Escaladez quand la décision a un impact élevé (droits, argent, admissibilité) et que le seuil de confiance est inférieur à votre accord opérationnel.Sinon, continuez en appliquant la règle stockée et consignez ce qui a été vérifié.> [!WARNING] Un agent “utile” qui continue malgré des preuves primaires manquantes (sans règle stockée et sans seuil d’escalade) transforme les échecs de gouvernance en réécritures d’exceptions.
Arbitrages et modes de défaillance quand on rigidifie la structure décisionnelle
Renforcer la structure de décision améliore l’auditabilité, mais change les arbitrages opérationnels.Arbitrages :Plus de travail initial pour définir les capsules de décision et les règles.Plus de discipline de données (versions de documents, métadonnées, horodatage).Délais plus longs sur les exceptions à fort impact, à cause des escalades.Modes de défaillance si c’est mal fait :Si la capsule de décision est trop “légère” (uniquement un récit), vous réécrirez quand même les exceptions—avec plus d’étapes.Si les règles sont trop strictes, vous escaladerez trop souvent et vous saturerez l’équipe.Si la capture des preuves est incohérente (absence de version/date), le dossier de décision devient inutilisable.Cela correspond à l’approche de management system attendue par ISO/IEC 42001 : la gouvernance de l’IA doit être implémentée, maintenue et améliorée via des contrôles, pas “assumée” parce que le modèle est bon. (iso.org) Et cela correspond à la logique du NIST : la gestion du risque est un exercice organisationnel continu. (nist.gov)> [!EXAMPLE] Triage remboursement : si le triage passe « raison : débit en double » mais ne conserve pas les champs de preuves et l’issue de la règle, l’agent remboursement justifiera à nouveau—ce qui recrée un récit d’exception non-auditable.
Décision suivante : lancer une architecture
assessment centrée sur les
frontières de décision de transfertAvant de chercher un nouvel outil, vous devez clarifier une frontière décisionnelle. Le point de départ (question opérationnelle) : **où, exactement, le workflow a besoin d’une frontière décisionnelle stable, et quelles preuves doivent être présentes pour que l’IA puisse continuer sans revue humaine ?**Ensuite, évaluez votre architecture actuelle avec une grille simple :Dossier de transfert : à chaque handoff, avez-vous la capsule de décision (règle, seuil, responsable), et pas seulement un texte ?Ancrage “source primaire” : pouvez-vous relier l’issue à des enregistrements versionnés ?Traçabilité : pouvez-vous rejouer signal → logique → décision ?Gouvernance d’escalade : avez-vous des déclencheurs d’escalade clairs, alignés sur l’impact de la décision ?AI RMF 1.0 soutient l’idée que les évaluations et contrôles doivent être organisés et répétables dans le cadre de la gestion des risques d’une organisation. (nist.gov) ISO/IEC 42001 renforce que ces contrôles doivent vivre dans un système de management de l’IA maintenable. (iso.org)
Ligne d’autorité (quoteable) : **« Si vous ne pouvez pas rejouer une capsule de décision de handoff, vous n’avez pas un système d’IA : vous avez une conversation non gouvernée. »**Auteur : Chris June, fondateur d’IntelliSync. Éditeur : IntelliSync.CTA : Open Architecture Assessment—utilisez-le pour structurer votre réflexion autour des frontières de décision de transfert, des preuves que votre système de contexte doit conserver, et de la préparation à la gouvernance pour empêcher les réécritures d’exceptions.