Context Systems : délivrer le bon contexte au bon moment
Les organisations AI-Native ne rivalisent pas pour stocker la connaissance. Elles rivalisent pour délivrer le bon contexte exactement quand c'est nécessaire, à la personne ou à l'agent qui en a besoin, de manière cohérente et gouvernable.
Le problème non dit
Une CTO d’une entreprise de 5 000 personnes prépare la prochaine version de son architecture de paiement. Elle souhaite adopter une approche orientée événements. La proposition a du sens dans son contexte actuel.
Sur Slack, quelqu’un demande : « N’avons-nous pas essayé cela il y a trois ans ? Que s’est-il passé ? »
La CTO répond : « Oui, mais je ne retrouve pas le contexte de pourquoi nous avons choisi l’autre option. »
Quelques jours plus tard, en reconstituant l’historique, elle découvre ceci : il y a trois ans, ils ont tenté cette même approche, ont eu de sérieux problèmes de cohérence à l’échelle et l’ont abandonnée.
Ils ont redécidé la même chose. Avec le même résultat prévisible.
L’investissement précédent dans la mémoire organisationnelle est resté sous-utilisé.
Ce n’est pas un cas isolé. C’est un modèle organisationnel.
Les entreprises investissent des fortunes pour capturer et organiser la connaissance. Elles ont des wikis. Elles ont des référentiels de décisions d’architecture. Elles ont des politiques documentées. Elles ont des bases de données de leçons apprises.
Mais quand quelqu’un doit décider, la connaissance n’apparaît pas là où elle est nécessaire. Elle n’est pas devant la personne qui décide. Elle n’atteint pas l’agent pendant l’exécution. Elle n’accompagne pas le moment où la décision est prise.
Le problème est la déconnexion entre ce qui est connu et ce qui parvient à qui en a besoin quand il en a besoin.
Le diagnostic incorrect
Les organisations interprètent souvent mal ce problème. Le diagnostic typique est : « Nous manquons de documentation. »
Résultat : elles lancent des initiatives de « plus de documentation », « meilleur wiki » et « partage de connaissances ».
Cela ne fonctionne pas.
Plus de documentation génère généralement plus de bruit. Les organisations se noient dans l’information. La documentation précieuse coexiste avec une documentation non pertinente. Les décisions critiques sont mêlées à des décisions mineures. Chercher le contexte revient à plonger dans le chaos.
Le bon diagnostic est autre.
Les organisations qui disposent déjà d’une mémoire organisationnelle et ont ordonné cette mémoire continuent de faire face au même problème : elles ne disposent pas d’un système fiable pour mettre un contexte utile entre les mains de celui qui décide, au moment même où il décide.
C’est un problème de distribution, pas de stockage. C’est un problème de délivrance au moment de la décision, pas d’existence de la connaissance.
Et cela nécessite un système explicite.
Trois couches : Mémoire, Architecture, Délivrance
Avant de définir ce système, il convient d’organiser la conversation.
Dans une organisation AI-Native, il existe trois capacités complémentaires :
Organizational Memory
Répond à la question : « Que savons-nous ? »
C’est le stock. Il capture les décisions, les politiques, les leçons apprises, les résultats d’expériences et le contexte métier. C’est une capacité relativement stable. Dans la plupart des entreprises, elle existe déjà.
Elle est nécessaire. Mais elle ne suffit pas à elle seule.
Memory Architecture
Répond à la question : « Comment organisons-nous ce que nous savons ? »
C’est la structure. Elle définit comment classer, relier et maintenir cette connaissance pour qu’elle puisse être réutilisée. Ce n’est pas « mieux documenter ». C’est concevoir une logique commune pour que différents domaines parlent le même langage.
Elle permet la recherche. Elle réduit le chaos. Mais elle ne résout toujours pas le problème central.
Même si la mémoire est bien ordonnée, la question opérationnelle demeure : quand quelqu’un va décider maintenant, comment reçoit-il ce dont il a besoin sans perdre de temps ni commettre d’erreurs ?
Context Systems
Répond à la question : « Comment faisons-nous parvenir cette connaissance à ceux qui en ont besoin au moment exact ? »
C’est la capacité de délivrance. Elle est dynamique. Elle fonctionne avec des événements réels d’exploitation : une décision qui va être prise, un incident en cours, une revue de conformité, une exécution d’agent.
Sa fonction est simple à expliquer et difficile à bien faire : apporter un contexte pertinent, à jour et gouvernable à la bonne personne ou au bon agent, à l’instant où il en a besoin.
Elle fait que la mémoire et l’architecture se transforment en décisions de meilleure qualité.
Sans ces trois capacités, il y a toujours de la friction :
- Sans mémoire, tout est redécouvert.
- Sans architecture, la connaissance existe mais devient chaotique.
- Sans Context Systems, l’organisation sait beaucoup mais décide comme si elle savait peu.
Context Debt : Le coût de ne pas pouvoir délivrer
Lorsqu’une organisation a de la connaissance, mais ne peut pas l’activer à temps, elle accumule ce que nous appelons chez Archwise la Context Debt.
La Context Debt est la distance entre deux réalités :
- ce que l’organisation sait déjà,
- et ce qu’elle utilise réellement lorsqu’elle prend des décisions.
Une organisation peut avoir peu de dette technique et peu de dette de connaissance, et accumuler quand même une énorme dette de contexte. Savoir quelque chose ne garantit pas que cette connaissance parvienne à celui qui doit décider. C’est là le point critique : ce qui échoue n’est pas ce que l’organisation sait, c’est la façon dont elle l’active en opération.
Ce n’est pas une métaphore élégante. C’est un problème opérationnel réel, visible et mesurable.
Elle se manifeste ainsi :
Redécisions récurrentes. Une équipe décide quelque chose. Deux ans plus tard, une autre équipe redécide la même chose. La première décision était documentée mais n’est pas parvenue à la seconde.
Non-conformités évitables. Une politique exige deux approbations. Une équipe approuve avec une seule. La règle existait ; elle n’est pas apparue au moment de décider.
Agents d’IA opérant à l’aveugle. L’agent prend une décision sous-optimale. L’analyse postérieure révèle la même conclusion : il y avait un contexte qui aurait évité l’erreur, mais il n’est pas parvenu.
Onboarding lent. Un nouveau profil met des mois à comprendre pourquoi le système est conçu comme il l’est. La connaissance existe, mais elle est dispersée ou inaccessible.
Incidents répétés. Un bon post-mortem est réalisé, la leçon est documentée, et des mois plus tard la même panne se reproduit dans une autre équipe.
La Context Debt a également un coût cumulatif :
- Coût de décision. On décide moins bien et plus lentement.
- Coût opérationnel. On répète des erreurs déjà connues.
- Coût de coordination. Trop de temps passé à demander « qui sait cela ? ».
- Coût de conformité. On enfreint des règles déjà définies.
- Coût de confiance. Les personnes et les agents cessent d’être prédictibles.
Si la Technical Debt est le prix des compromis techniques à court terme, la Context Debt est le prix de ne pas connecter la connaissance à la décision.
Si la Knowledge Debt, c’est ne pas capturer ce qui a été appris, la Context Debt, c’est le capturer mais ne pas le mettre en circulation quand cela compte.
Et comme toute dette organisationnelle sérieuse, elle croît de façon composée : plus d’équipes, plus de décisions et plus d’agents, plus grand est l’impact.
C’est pourquoi la Context Debt doit devenir une métrique de direction, pas une note de bas de page.
Context Routing : Le cœur
Si les Context Systems sont la capacité de délivrance, le Context Routing en est le noyau décisionnel.
La question centrale est celle-ci : comment une organisation décide-t-elle quel contexte va à qui, quand et pour quoi faire ?
Ce n’est pas une question technique mineure. C’est une décision de conception organisationnelle.
Le Context Routing répond à cinq dimensions :
QUI : Qui a besoin du contexte ?
Tout le monde n’a pas besoin de la même chose.
Une CTO a besoin de contexte sur les décisions d’architecture, les contraintes techniques, les précédents et les critères de gouvernance. Elle n’a pas besoin d’un détail complet du marketing pour décider des paiements.
Une personne de conformité a besoin des politiques applicables, des changements récents, des exceptions actives et de la traçabilité. Elle n’a pas besoin de toutes les alternatives de conception d’infrastructure.
Un profil technique qui intègre a besoin de comprendre pourquoi un composant est comme il est, quelles erreurs ont été commises avant et quelles dépendances sont critiques.
Une organisation mature définit des profils de contexte par rôle : direction technologique, architecture, conformité, opérations et agents.
QUOI : Quel contexte exactement ?
Tout livrer est aussi mauvais que ne rien livrer.
La clé est de spécifier le minimum de contexte suffisant pour bien décider.
Pour une décision d’architecture :
- décisions antérieures sur ce composant,
- raisons de ces décisions,
- règles en vigueur,
- tentatives échouées et pourquoi elles ont échoué,
- impact sur d’autres domaines.
Ne pas inclure : contexte non pertinent, historique obsolète ou détails qui ne changent pas le cours de la décision.
Pour une revue de conformité :
- politique en vigueur,
- derniers changements,
- exceptions actives,
- décisions similaires antérieures,
- critères de risque applicables.
Ne pas inclure : détails techniques sans lien avec la conformité ni informations confidentielles sans nécessité.
QUAND : Quand exactement ?
Le moment change tout. Un contexte excellent qui arrive trop tard ne sert à rien.
Il existe des catégories de timing :
Avant de décider. La direction technologique doit recevoir le contexte avant la réunion. La conformité doit le voir avant d’approuver.
Pendant l’opération. Un agent ou une personne d’astreinte a besoin de contexte en temps réel pour agir.
À la demande. Quelqu’un demande et a besoin d’une réponse rapide, concrète et utilisable.
Après avoir décidé. Le contexte reste disponible pour l’apprentissage et l’audit.
Le principe est simple : chaque type de décision exige une cadence de délivrance différente.
POURQUOI : Pourquoi est-ce nécessaire ?
Parce que cela change les résultats.
La direction technologique évite les redécisions et maintient la cohérence.
La conformité réduit les non-conformités et augmente la traçabilité.
Les agents passent de l’improvisation à une exécution plus prédictible et explicable.
Dans les organisations enterprise, les Context Systems cessent d’être une amélioration optionnelle et deviennent une condition pour décider avec cohérence à l’échelle.
COMMENT : Comment met-on en œuvre ?
En termes organisationnels, le flux est le suivant :
Lorsque survient [type de décision] initiée par [acteur] :
- Identifier qui décide et ce qu’il est en train de décider.
- Définir de quel contexte ce rôle a besoin pour ce type de décision.
- Récupérer ce contexte depuis la mémoire organisée.
- Filtrer par pertinence, actualité et permissions.
- Valider qu’il n’y a pas de contradictions ni d’informations périmées.
- Le livrer avec le format adapté à la personne ou à l’agent.
- Enregistrer l’utilisation et le résultat pour améliorer la livraison suivante.
Voilà le Context Routing : transformer le contexte en une capacité de décision reproductible.
Scénario réel : Une CTO propose un changement d’architecture
Une CTO conçoit la prochaine itération de sa plateforme de paiement. Elle propose de passer d’un schéma orienté requêtes à un schéma orienté événements.
Sans Context Systems, la CTO pense que c’est nouveau. Elle propose un changement à partir de zéro. C’est une redécision.
Avec Context Systems :
Le système identifie qu’il s’agit d’une décision d’architecture critique.
Il récupère les décisions antérieures dans le domaine des paiements des dernières années.
Il retourne :
- 2021 : tentative similaire dans les paiements ; problèmes de cohérence et de rollback.
- 2018 : succès dans l’inventaire ; cas non critique avec tolérance à la latence.
- 2024 : critère en vigueur : événements pour les routes non critiques, approche synchrone pour les routes critiques.
Le contexte est validé :
- S’agit-il d’une source fiable ?
- Est-il à jour ?
- Existe-t-il une contradiction entre les décisions ?
Il est livré en format exécutif pour la réunion de conception.
Il est livré avant la réunion, pas après.
Résultat : la CTO ne répète pas une décision. Elle propose une option plus précise : appliquer les événements sur un sous-ensemble où cela fonctionne réellement. La Context Debt diminue parce que la connaissance historique s’est transformée en action.
Scénario réel : Un agent de conformité évalue un changement
Une équipe demande de modifier la conservation des données de 90 jours à 30 jours.
Sans Context Systems, la revue est manuelle, lente et incohérente.
Avec Context Systems :
Le système reconnaît une décision de conformité.
Il consulte les politiques en vigueur, les changements récents et les exceptions actives.
Il retourne :
- Politique générale : minimum réglementaire de 30 jours.
- Changement récent : certaines données de santé passent à 45 jours.
- Exception contractuelle active pour un client spécifique.
- Critères de risque applicables à ce type de changement.
Validé :
- validité,
- sources,
- exceptions,
- traçabilité.
L’agent reçoit ce contexte en format opérationnel et agit.
Résultat : il approuve le changement pour la plupart des cas et oriente le cas avec exception vers le circuit correct. La conformité cesse de dépendre de la mémoire individuelle et devient un processus reproductible.
Dans ce cas, la Context Debt en matière de conformité est clairement réduite.
Les quatre ennemis du contexte
Lorsqu’une organisation ne conçoit pas bien la distribution du contexte, quatre ennemis apparaissent toujours.
Fragment du contexte. La connaissance est répartie dans des silos. Une partie vit dans les documents, une autre dans les chats, une autre dans la tête de personnes clés. Résultat : personne n’a l’image complète au moment de décider.
Contexte désactualisé. Ce qui arrive était correct, mais ne s’applique plus. Résultat : des décisions « correctes » sur des hypothèses obsolètes.
Incohérence. Le même concept signifie des choses différentes selon les équipes. Résultat : des décisions incompatibles entre elles.
Surcharge. Trop de contexte arrive et devient inutile. Les personnes et les agents cessent de l’utiliser.
Ces quatre sont des problèmes de conception organisationnelle, pas des fatalités. C’est pourquoi le Context Routing est si important : il réduit la fragmentation, contrôle la validité, aligne les significations et filtre le bruit.
L’architecture : Structure opérationnelle
L’architecture est importante, mais ici elle doit servir de support à la thèse.
Un Context System solide couvre généralement six fonctions :
Identifier ce que chaque rôle a besoin de savoir pour chaque type de décision.
Récupérer ce contexte depuis les sources disponibles.
Filtrer le pertinent et éliminer le bruit.
Valider la validité, la cohérence et les permissions.
Délivrer dans le format adapté à la personne ou à l’agent et au bon moment.
Apprendre de l’utilisation réelle pour améliorer les décisions futures.
Ce n’est pas une finalité technique en soi. C’est une façon de transformer la connaissance en de meilleurs résultats opérationnels.
Scalabilité : Trois organisations différentes
Les principes sont les mêmes dans les petites organisations, les grandes ou celles avec une forte présence d’agents. Ce qui change, c’est l’échelle de l’effort.
Petite organisation (<200 personnes).
La Context Debt semble souvent « tolérable » parce que beaucoup de choses se résolvent en parlant. Pourtant, il y a déjà des coûts : onboarding lent, redécisions et dépendance à des personnes clés.
Avec une capacité minimale de Context Systems, on peut beaucoup s’améliorer :
- profils de base par rôle,
- critères simples de validité,
- circuit clair pour les décisions récurrentes.
Organisation enterprise (1 000+ personnes).
Ici, la Context Debt cesse d’être une friction et devient un risque structurel. Il y a trop de décisions, trop de dépendances et trop de domaines opérant à des rythmes différents.
La priorité devient organisationnelle :
- définir des responsabilités claires sur le contexte,
- standardiser les critères de décision,
- assurer la traçabilité de ce qui est utilisé pour décider,
- aligner gouvernance et opérations.
Le retour est tangible : moins de redécision, plus de vitesse, meilleure conformité et moindre variabilité opérationnelle.
Organisation AI-Native avec de nombreux agents.
Lorsque les agents participent de manière intensive, l’exigence augmente : le contexte doit arriver plus rapidement et avec plus de précision. Une erreur de contexte se transforme en erreur d’exécution à l’échelle.
Ici, le Context Routing est décisif : il délimite ce que chaque agent peut utiliser, dans quelles conditions et avec quelle supervision.
À toutes les échelles, la règle est la même : bon contexte, pour le bon acteur, au bon moment.
Et dans les grands environnements, il convient d’opérer avec un modèle fédéré : chaque domaine gère son contexte, mais avec des critères communs pour que l’organisation décide avec cohérence.
La transition : Du stockage aux décisions
Revenons à notre point de départ.
Les organisations AI-Native ne passent pas à l’échelle en accumulant plus d’informations. Elles passent à l’échelle en distribuant un contexte utile au moment de décider.
La transition complète est la suivante :
Organizational Memory : conserve ce que l’organisation apprend.
Memory Architecture : organise cette connaissance pour qu’elle puisse être réutilisée.
Context Systems : la transforme en décisions meilleures et plus cohérentes.
Les trois capacités sont complémentaires. Aucune ne remplace l’autre.
Sans mémoire, pas d’apprentissage. Sans architecture, l’apprentissage se disperse. Sans Context Systems, tout cet effort n’arrive pas au point où il génère de la valeur : la décision.
Les organisations qui conçoivent explicitement des Context Systems :
- prennent de meilleures décisions,
- réduisent les temps de coordination,
- augmentent la cohérence entre les équipes,
- améliorent la conformité,
- et permettent des agents plus fiables.
Celles qui ne le font pas accumulent de la Context Debt :
- redécisions,
- non-conformités évitables,
- agents moins fiables,
- apprentissage lent,
- incidents répétés.
Et cette dette s’accumule. Chaque décision mal contextualisée aggrave la suivante.
Commencer
Si vous voulez commencer, commencez par mesurer.
Combien de redécisions par an ? Combien de temps faut-il à une nouvelle personne pour opérer en autonomie ? Combien d’incidents répétez-vous avec une leçon déjà documentée ? Combien de non-conformités étaient évitables ?
Voilà la Context Debt en chiffres.
Ensuite, choisissez un front concret : architecture, conformité ou opérations.
Construisez un premier petit cycle :
- un type de décision,
- un rôle principal,
- un flux de contexte clair avant de décider,
- une façon de mesurer l’amélioration.
La question n’est pas « si le système existe ». La question est : la dette de contexte a-t-elle diminué ?
Si elle diminue, élargissez progressivement le périmètre.
Et n’oubliez pas la gouvernance : décider, c’est aussi respecter des règles.
Conclusion : La mémoire comme action
La mémoire organisationnelle sans architecture finit en accumulation.
L’architecture de mémoire sans délivrance finit en ordre sans impact.
Les Context Systems transforment les deux en capacité de décision.
Il ne s’agit pas d’avoir plus de pages, plus de référentiels ou plus de tableaux de bord. Il s’agit de décider mieux, de manière cohérente et à l’échelle.
C’est pourquoi la séquence est importante :
Organizational Memory
→ Memory Architecture
→ Context Systems
Trois capacités complémentaires d’une organisation AI-Native.
La première conserve la connaissance.
La seconde l’organise.
La troisième la transforme en décisions.
Et cette troisième capacité définit la différence entre une organisation qui sait beaucoup et une organisation qui apprend, décide et exécute mieux.
À ce stade, la Context Debt cesse de croître.
Et la connaissance, enfin, commence à travailler pour l’organisation.