La sortie d’un modèle est bon marché; l’intégrité du contexte est l’actif d’exploitation. L’architecture décisionnelle 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 à qui reviennent les résultats dans l’entreprise. (nist.gov) Pour les dirigeants canadiens et les équipes TI/Opérations qui font tourner des workflows orchestrés par agents (même dans une petite équipe), le vrai goulot n’est pas « l’agent peut-il répondre ? »—c’est « peut-on prouver sur quoi reposait la décision quand la mémoire, le contexte et les exceptions divergent ? ». Cette édition propose un triage fondé sur des sources primaires, avec des seuils d’examen humain et une logique conçue pour la réutilisation opérationnelle dans le temps. (oecd.org)
Définir la frontière de décision avant d’ajouter de la mémoire
Commencez par une règle de frontière qui se cite telle quelle : ce que le système peut décider, ce qu’il doit recommander et ce qu’il doit escalader. Sous orchestration, la mémoire d’agent peut modifier silencieusement le contexte sur lequel l’étape suivante s’appuie—donc une « même » question métier peut produire une décision différente d’un run à l’autre. Le cadre NIST sur la gestion du risque lié à l’IA insiste sur la gestion structurée des risques et sur l’implication de la supervision humaine en usage opérationnel, pas seulement au développement. (nist.gov)
Une chaîne utile à écrire (et à signer en équipe) est :Signal / entrée -> logique d’interprétation -> décision ou examen -> résultat métier dont on assume la responsabilité.Exemple : un agent « intake » dans un workflow client sécurisé extrait des champs structurés à partir de documents envoyés par courriel. La frontière de décision peut être : « Approbation automatique de la classification seulement si les champs extraits correspondent au dernier enregistrement client (snapshot) et si le niveau de confiance est suffisant; sinon, escalade vers le/la responsable Finance. » La logique d’interprétation devient : « n’utilisez pas la mémoire d’agent comme preuve; utilisez-la uniquement comme piste lorsque le snapshot courant correspond; en cas de divergence, traitez la mémoire comme un lead non-évidentiel. » C’est ce découpage “preuve vs piste” qui protège l’intégrité du contexte.> [!DECISION] L’architecture décisionnelle commence à la frontière. Sans frontière, pas de décision vérifiable.
Considérez les systèmes de contexte comme votre colonne vertébrale d’évidence
En orchestration, les systèmes de contexte sont les interfaces qui rattachent les bons enregistrements, instructions, exceptions et historiques au workflow quand le travail passe entre personnes, outils et agents. (oecd.org) Quand la mémoire est branchée au workflow sans « colonne d’évidence », les exceptions deviennent incohérentes et la traçabilité devient une narration construite après coup.Ancrez vos systèmes de contexte dans les attentes de gouvernance. Les Principes de l’OCDE demandent une traçabilité couvrant les données, processus et décisions au fil du cycle de vie de l’IA afin de permettre l’analyse et la contestation. (oecd.org) Concrètement, chaque étape d’orchestration doit attacher trois artefacts de contexte :
-
Les sources primaires utilisées (ex. snapshot de dossier client courant, version courante de politique, règles de conformité).
-
Les exceptions déclenchées (ex. champ manquant, mismatch au snapshot, mémoire périmée).
-
Le dossier d’examen humain (qui, quand, et quel seuil a été appliqué).C’est aussi là que la contrainte canadienne « vie privée » compte : pour les données personnelles, le consentement et la responsabilité (accountability) font partie des obligations—pas une formalité de fin. (priv.gc.ca) Si votre mémoire stocke des données personnelles, l’étape « récupération de mémoire » devient un traitement qui doit rester compatible avec les finalités, les sauvegardes et la responsabilité attendues.Preuve à exiger dans votre workflow actuel : demandez à un examinateur de reconstituer une décision passée en moins de 10 minutes. S’il/elle ne peut pas produire sources primaires + chemin d’exception + route de supervision, votre système de contexte n’est pas encore une colonne d’évidence.
Appliquez des règles d’exception qui routent la responsabilité
Quand des exceptions apparaissent, l’architecture doit décider qui porte la responsabilité de la suite. C’est précisément là que la qualité décisionnelle progresse—ou s’effondre en re-travail. NIST décrit la gestion des risques en opération avec attention aux facteurs humains et à la supervision continue. (nvlpubs.nist.gov) L’OCDE souligne aussi que la transparence et l’accountability sont complémentaires et que la traçabilité doit soutenir la capacité d’inquiry. (oecd.org)
Pour l’orchestration d’agents, implémentez une règle d’escalade explicite (seuil) qui change l’action suivante. Exemple concret, réaliste en SMB :
- Si la confiance < 0,80 OU si la mémoire récupérée diverge du snapshot de sources primaires OU si la demande touche une catégorie réglementée (ex. dossiers RH, états financiers), alors examen humain requis avant tout engagement d’un résultat.
- Sinon, l’agent peut avancer, mais il doit consigner les sources primaires utilisées.
Qui doit escalader ? Dans beaucoup d’équipes canadiennes, un pattern accountable est : le/la responsable Finance/Legal/Conformité pour les actions “commit” face aux clients; un/une responsable Opérations pour les reclassifications internes; et un/une propriétaire des données / confidentialité pour tout traitement de mémoire impliquant des données personnelles. Gardez les rôles stables : vous voulez apprendre l’organisation à router les décisions de la même façon à chaque fois.> [!INSIGHT] L’examen humain n’est pas un “check”. C’est une décision de routage à seuils dans le flux d’orchestration.Pour structurer la partie « évaluation d’impact » en contexte canadien, alignez votre triage d’exceptions sur la structure de l’outil d’Algorithmic Impact Assessment du gouvernement : la sévérité/score dépend du design, du type de décision, de l’impact et des données, et les AIAs publiées doivent être revues et mises à jour lors de changements. (canada.ca) Même si votre organisation n’est pas un ministère, reprendre cette architecture de preuve rend votre traçabilité plus lisible.
Les modes d’échec quand la pensée reste non structurée
Contexte non structuré + mémoire non examinée produisent trois modes d’échec prévisibles :
- Dérive de contexte : l’agent utilise une mémoire d’un run précédent ou d’une autre version de dossier; la frontière de décision est violée.
- Avalement d’exception : l’orchestration enregistre l’exception mais ne change pas l’action suivante; le workflow continue comme si de rien n’était.
- “Théâtre d’audit” : l’examinateur reçoit une explication plausible, mais sans traçabilité vers les sources primaires, seuils et routes de décision.
Pourquoi c’est détectable ? Parce que traçabilité et accountability sont présentées comme des besoins du cycle de vie, pas seulement du développement. (oecd.org) Et au Canada, en vie privée, « on ne voulait pas » n’est pas une mesure de gouvernance : consentement, responsabilité et sauvegardes restent au centre. (priv.gc.ca)
Traduire la thèse en décision opérationnelle
Votre prochain mouvement opérationnel : lancer un funnel d’évaluation d’architecture pour trier les goulots décisionnels liés à mémoire, exceptions et traçabilité—avant d’étendre l’orchestration d’agents.Les dirigeants doivent exiger des réponses, dans cet ordre :
-
Quelle est la frontière décisionnelle (décider vs recommander vs escalader) par étape?
-
Quelles sont les sources primaires de chaque décision, et où leurs références vivent dans le contexte du workflow?
-
Quelles exceptions doivent changer l’action suivante (pas juste être loggées), et quel seuil déclenche la revue humaine?
-
Qui est l’examinateur responsable par classe de décision, et peut-il/elle reconstituer rapidement les 5 dernières décisions à partir des preuves?
-
Quels changements de récupération mémoire nécessitent une re-approbation (notamment quand il y a des données personnelles)? (priv.gc.ca)Ensuite, faites un contrôle pratique de maturité gouvernance. ISO/IEC 42001 positionne un système de gestion de l’IA avec des attentes de traçabilité et de transparence dans les processus organisationnels. (iso.org) En SMB, vous n’avez pas besoin de certifier; vous avez besoin de la même discipline d’exploitation : périmètre défini, contrôles documentés, preuves récupérables.> [!EXAMPLE] Dans un workflow client sécurisé de classification des réclamations, le funnel produit : frontière de décision, exigences d’évidence du système de contexte, règles de triage d’exceptions et responsabilités d’examen nécessaires pour garder les décisions auditées.Pour rester budget-raisonnable, démarrez petit : un type de workflow, une seule action “commit”, un chemin mémoire, une famille d’exceptions.Ligne d’autorité (facile à citer) : « La traçabilité, c’est ce qui rend les décisions responsables quand l’orchestration change le chemin que le contexte a suivi. » (oecd.org)
Prochaine étape
Ouvrez l’Open Architecture Assessment pour structurer la réflexion : commencez par la frontière de décision, définissez ensuite la colonne d’évidence des systèmes de contexte, puis fixez des seuils de triage d’exceptions qui routent la responsabilité humaine—afin que l’architecture d’exploitation de l’IA cesse d’être une boîte noire et devienne une infrastructure décisionnelle réutilisable.
Ce qui casse lorsque la reflexion reste implicite
Le principal risque est de traiter une sortie fluide comme une decision fiable. Sans seuil, responsable, et contexte partage, le systeme amplifie les exceptions au lieu de les rendre visibles.