Idée

Un contexte métier traverse les applications au lieu de les remplacer

Idée principale

Organiser l'information autour de contextes — un contexte produit, un contexte support, un contexte client, un contexte code source, un contexte norme — ne suppose pas de démanteler l'existant. Le CRM garde ses comptes, l'outil de ticketing ses tickets, le dépôt son code : ce sont des objets métier, et ils sont à leur place.

Ce qu'un contexte ajoute est d'un autre ordre. Il rassemble, autour d'un but, ses sources, ses règles, ses décisions, ses notes, ses objectifs, ses limites et ses liens — et ces éléments viennent de plusieurs outils à la fois. Un contexte client relie des tickets, un historique commercial, des usages produit, des engagements contractuels et des risques identifiés ; aucune des applications qui détiennent ces éléments ne pouvait porter cet ensemble, parce que chacune n'en détient qu'une part.

Le contexte est donc une couche transversale, pas un outil de plus dans la liste. Il ne concurrence pas les applications sur ce qu'elles font bien ; il occupe ce qu'aucune ne pouvait occuper, faute de voir au-delà de son périmètre.

Pourquoi c'est important

Cela change la nature du projet quand une organisation veut capitaliser sa connaissance. Le réflexe est de choisir un outil central et d'y faire converger les autres — migration, doublons, arbitrage sans fin sur l'outil maître. Traiter le contexte comme une couche qui traverse retire cette question : rien n'est à migrer, il faut décider ce qu'on écrit en plus, et où.

Cela explique aussi pourquoi le découpage des contextes ne suit pas le découpage des outils. Un contexte se définit par un but, donc par une équipe et un travail — et il puise dans autant d'applications qu'il le faut.

Nuances et limites

Traverser suppose de pouvoir lire chez les autres. Un outil fermé, sans interface d'accès, met hors de portée la part de matière qu'il détient, et le contexte se construit alors sur des recopies qui vieillissent.

Et la couche transversale a un coût propre : elle ne se remplit pas toute seule, et personne n'en est responsable par défaut, puisqu'elle n'appartient à aucun outil.

Questions ouvertes

  • Qui porte la responsabilité d'un contexte qui traverse plusieurs équipes, quand aucune d'elles n'en détient la totalité ?