Objectif

Lorsqu’une direction générale ou une DSI souhaite structurer son organisation de manière agile, la première étape consiste à cartographier son fonctionnement. Cette approche ne repose pas sur une modélisation isolée et rigide réalisée en amont, mais sur l’itération continue, en impliquant les clients et les équipes. Elle s’inspire de méthodologies comme le Design Thinking, le Lean, le Domain-Driven Design (DDD) et l’Open Agile Architecture (O-AA). Le but est d’obtenir une vision globale permettant de guider des expérimentations courtes et concrètes.

Cette page ne cherche pas à remplacer les ouvrages de référence, mais à proposer un guide synthétique et actionnable. Pour approfondir, il est recommandé en particulier de consulter le référentiel Open Agile Architecture O-AA de l’Open Group (éditeur également du TOGAF, qui est une référence depuis longtemps en architecture d’entreprise), une lecture relativement concise qui a su, à notre sens, capter l’essentiel de chaque approche.

Identifier les domaines de l’organisation

Un domaine, qui donne son nom à l’approche Domain Driven Design, est l’ensemble des activités de l’organisation visant à répondre à un des objectifs majeurs de l’organisation, par exemple vendre et livrer un certain type de produits ou de services.

Votre objectif dans un premier temps sera d’identifier et de lister les domaines de votre organisation, car l’ensemble du travail décrit dans cette cartographie devra être refait pour chaque domaine, chaque domaine ayant ses propres spécificités et objectifs.

Dans un grand nombre de cas, une organisation n’aura qu’un seul domaine. Par exemple, un concessionnaire n’a qu’un seul objectif : vendre ses voitures à ses clients et en tirer un bénéfice. Toute son organisation est structurée autour de cet objectif. Mais d’autres organisations, en particulier les groupes qui peuvent regrouper plusieurs métiers différents et s’adresser à des clients différents, auront potentiellement plusieurs domaines. On pourrait citer par exemple un grand constructeur qui pourrait à la fois :

• Construire et vendre des voitures, en direct ou via son réseau de concessionnaires.
• Construire et vendre des camions.
• Produire des moteurs qui sont ensuite utilisés par d’autres constructeurs.
• Construire des équipements sur mesure pour des organismes publics. Chacun de ces objectifs constitue pour le groupe un domaine différent, chacun nécessitant une structuration et donc une analyse différente.

À noter que cela n’empêchera pas la mise en commun de certaines capacités, notamment sur le plan des services supports comme les RH, DSI, Financier, etc. dont le fonctionnement sera simplement dupliqué sur chaque domaine.

Cartographier la chaîne de valeur

Le Design Thinking nous incite à rechercher les propositions de valeurs en alternant les phases d’identification du Problème (recherche client) avec les phases de recherche de Solutions (découverte produit), afin de faciliter la découverte de solutions innovantes et potentiellement disruptives.

Pour ce faire, un des outils les plus utiles pour représenter l’expérience du client consiste à faire une cartographie de la chaîne de valeur (Attention, il y a plusieurs traductions ; nous parlons ici du Value Stream Mapping en anglais, issu de l’approche Lean).

Cela consiste à représenter les différentes étapes de l’expérience du client tout au long de son évolution dans le domaine. Il ne s’agit pas de représenter l’ensemble du processus, mais uniquement les étapes perceptibles par le client, en excluant les étapes internes à l’organisation.

À chacune de ces étapes, nous allons ensuite ajouter :

• Le canal représentant le point de contact avec le client.
• Le ressenti actuel du client.
• Le ressenti actuel des collaborateurs.
• Le temps nécessaire pour réaliser l’étape avec le client (Process Time, P/T).
• Le temps nécessaire pour atteindre l’étape suivante (Delay Time, D/T).
• Le pourcentage de réussite de l’étape (Percentage Complete & Accurate, %C/A), imposant le cas échéant de recommencer celle-ci.
• Les fonctionnalités existantes et utilisées à cette étape.
• Les fonctionnalités prévues à l’avenir pour améliorer l’expérience du client.

Cette schématisation permet de représenter de manière très claire pour chacun des intervenants les points problématiques actuels (ressentis négatifs, délais, taux d’échecs), afin de réfléchir aux solutions innovantes capables d’améliorer sensiblement la situation et potentiellement de faire émerger un avantage compétitif sur la concurrence.

Il peut également être intéressant de réaliser une Matrice des Étapes Produits, qui vise à identifier pour chaque famille de produits/services que vous proposez, les étapes qui peuvent potentiellement être esquivées.

Nous devrons garder en tête les problématiques et les solutions identifiées lors de cette cartographie pendant les prochaines étapes, qui seront plus centrées sur le fonctionnement de l’organisation mais qui viseront bien in fine à implémenter ces solutions.

Event Storming

L’Event Storming est un atelier spécifiquement conçu pour identifier le fonctionnement du domaine, fonctionnement qui n’est pas forcément si évident qu’on pourrait le croire. Il se pratique en réunissant les différents intervenants dans le domaine.

Cet atelier se concentre sur l’identification des “événements”, qui sont les différentes actions ayant provoqué (notez l’usage du passé) un changement dans l’état du processus. Les intervenants sont invités dans un premier temps à noter librement sur des post-its (oranges) collés sur un tableau blanc tous les événements qui leur viennent en tête, tout au long du processus.

Ils ont également à leur disposition les concepts suivants :

• Les commandes (post-its bleus), représentant une action de la part d’un acteur et qui résulte généralement sur un événement. Une commande peut échouer, alors qu’un événement a déjà eu lieu.
• Les agrégats et les entités (post-its jaunes), qui sont les objets stockant les informations. Un agrégat peut regrouper plusieurs entités qui font sens entre elles, l’une d’entre elles étant la racine de l’agrégat, c’est-à-dire son point d’entrée.
• Les réactions (post-its violets), qui déclenchent une réponse suite à un événement.
• Les points d’attention (post-its rouges) qui sont des points de vigilance globaux sur une problématique, l’objectif est d’attirer l’attention des intervenants sur un point qui n’a peut-être pas été assez étudié encore.
• Les règles, les conditions qui doivent être respectées pour déclencher une action.
• Les acteurs, persona représentant ceux qui déclenchent des commandes.
• Les requêtes de lectures (post-its verts), représentant le format des extractions et documents que nous voulons extraire du système et qui n’influent pas sur le processus.

Les post-its sont ensuite regroupés autour des agrégats, et une photo est prise en tant que résultat de l’atelier.

Les ateliers Event Storming sont utilisés dans deux situations :

• Pour capturer la vue d’ensemble du domaine, c’est l’usage que nous en avons ici pour préparer la réalisation de la carte contextuelle (la prochaine étape).
• Pour faire un focus sur une partie précise du domaine, que nous voudrons implémenter dans une application. C’est l’étape préparatoire à la réalisation des schémas des agrégats que nous évoquons dans les phases de conception.

Réalisation de la carte contextuelle

Nous allons désormais pouvoir entamer le cœur de la cartographie de notre domaine, la carte contextuelle (Context Map dans l’approche Domain Driven Design).

Elle consiste dans un premier temps à identifier l’ensemble des sous-domaines (Subdomains en anglais). Un sous-domaine est une thématique précise au sein de la problématique de votre domaine. Par exemple, vous pouvez avoir un sous-domaine lié à la gestion de la paie des collaborateurs, un sous-domaine sur la prospection des nouveaux clients, un sous-domaine sur la production du produit vendu, un sous-domaine sur la gestion de la livraison, etc. C’est le regroupement de l’ensemble des sous-domaines qui permet à votre domaine de fonctionner et d’atteindre collectivement ses objectifs.

Un certain nombre des sous-domaines vont venir naturellement (Paie, Facturation, etc.), d’autres vont apparaître en consultant la cartographie de la chaîne de valeur et les résultats de l’atelier Event Storming qui ont été faits au préalable.

Ils peuvent être regroupés en trois catégories :

• Les sous-domaines coeurs, qui sont des activités spécifiques à votre domaine et directement liées à la production de valeur pour vos clients, donc dont l’adéquation et le bon fonctionnement sont hautement critiques pour votre fonctionnement.
• Les sous-domaines génériques, qui sont les activités qu’on retrouve dans la plupart des organisations, comme la gestion de la paie, la gestion des ressources humaines, la comptabilité, etc.
• Enfin, les sous-domaines de support, qui sont également des activités spécifiques à votre organisation mais dont la criticité n’atteint pas le même niveau que les sous-domaines coeurs.

Au niveau des outils, on ira généralement chercher des outils clés en main pour les sous-domaines génériques, alors que les sous-domaines coeur et de support nécessiteront généralement des outils développés spécifiquement, avec un budget et un focus bien plus important pour les sous-domaines coeurs.

Dans un premier temps, vous devez ainsi identifier et lister l’ensemble des sous-domaines, avant de les classer chacune dans l’une de ces trois catégories.

L’étape suivante consistera à regrouper les sous-domaines dans des Contextes (Bounded Context en anglais), qui sont des regroupements de sous-domaines partageant un même langage (Ubiquitous Language en anglais, on utilisera aussi la traduction Langage Universel ici) et qui est sous la direction d’un seul et même service ayant l’autorité d’agir en toute autonomie. Par exemple, on peut imaginer le contexte “Ressources Humaines” qui s’occupe des activités “Paie” et “Formation” et qui est sous la direction de la DRH de l’organisation.

Là où les sous-domaines représentent les Problématiques auxquelles on cherche à répondre, les Contextes représentent nos Solutions, c’est-à-dire les structures qu’on met en place pour y répondre.

Rajouts des données, des outils et des niveaux de maturité

L’étape suivante consistera à ajouter un certain nombre d’informations pour chaque sous-domaine, à savoir les données, les outils en charge de chaque sous-domaine ainsi que le niveau de maturité tel que nous le définissons dans la partie réservée aux experts métiers. Celui-ci vous permettra de visualiser la progression de chaque équipe dans la mise en place de leurs outils et la mise à disposition de leurs données au reste de l’organisation.

On ne consigne que les données dont le sous-domaine est “maître”, c’est-à-dire que les données ne sont pas imposées par un autre sous-domaine. Par exemple, si le fichier des clients est géré par le sous-domaine Facturation, on ne mentionnera pas ce fichier dans le sous-domaine Comptabilisation. On peut imaginer par contre que le sous-domaine Comptabilisation peut compléter avec des informations supplémentaires, comme par exemple les comptes bancaires des clients à prélever.

Concernant les outils, il convient de noter qu’il est tout à fait possible qu’un outil soit mentionné dans plusieurs Contextes, et donc qu’il soit sous la responsabilité de plusieurs services. C’est notamment le cas quand l’organisation a mis en place un ERP. Dans ce cas, l’outil est généralement géré par la DSI, mais chaque service métier conserve la responsabilité et l’autorité d’agir sur les données et les activités qui lui sont propres, en commandant à la DSI les évolutions nécessaires.

Identification des interconnexions

La dernière étape de notre cartographie consistera à identifier les interconnexions entre les différents Contextes, en nommant chaque liaison avec la donnée créée par un service X et ensuite utilisées par un autre.

Ces interconnexions seront aussi catégorisées pour refléter la nature de la relation entre les différents contextes :

• Conforme : Il s’agit d’une relation Client-Fournisseur où un service fournit des données à un autre et où le service client ne peut que difficilement demander au fournisseur de prendre en compte ses besoins. Dans le cas d’une relation Conforme, le domaine qui consomme les données utilise directement le format des données du service fournisseur au sein de son outil. Il est ainsi vulnérable à des changements de format de la part du fournisseur, qui risque à tout moment de provoquer une interruption de service mais surtout d’influer directement sur le fonctionnement interne du service consommateur, en provoquant des changements en urgence pour conserver l’interconnexion sans que le service consommateur n’ait eu le temps de prendre le recul nécessaire pour s’assurer que les nouvelles données correspondent bien à leur besoin. La solution pour le service client consiste généralement à mettre en place une Couche Anti-Corruption.
• Couche anti-corruption : Dans ce cas où l’on est également dans une relation Client-Fournisseur, le client ne pouvant demander au fournisseur des ajustements, cette fois-ci le service consommateur met en place en amont de son contexte un traducteur qui va transcrire les données du fournisseur dans un format qui est propre au contexte consommateur. Ce qui est une manière d’éviter les problèmes cités dans la relation Conforme, où la structure de donnée du fournisseur peut venir influencer (“corrompre”) la structure de donnée du domaine client.

• Client contraignant : Relation Client-Fournisseur où le service client a un pouvoir suffisant pour imposer au service fournisseur de ne pas modifier son interface tant qu’ils ne sont pas prêts à prendre en compte les conséquences. Dans ce cas de figure, le service fournisseur est paralysé et ne peut pas faire évoluer son fonctionnement comme il le voudrait. La solution pour le service fournisseur consiste généralement à évoluer vers un modèle Hôte Ouvert.
• Hôte ouvert (Open Host) : Toujours un cas de relation Client-Fournisseur, mais cette fois-ci c’est le fournisseur qui fait un travail de mitigation de son impact auprès de ses clients. Il le fait notamment en s’assurant de gérer avec attention le versionning de son API, en faisant attention de ne pas introduire sans concertation des changements disruptifs auprès de ses clients. Nous évoquons cette relation dans le dernier niveau de maturité des services métiers, où être en capacité de mettre à disposition une API en Hôte Ouvert en est l’objectif ultime, tout en se protégeant eux-mêmes avec des couches anti-corruption.

• Partenariat : Les services ne sont ni en Couche Anti-Corruption ni en Hôte Ouvert, sont dépendants du langage de l’autre, mais échangent suffisamment pour se coordonner, voir ont des incitatifs pour aller dans la même direction et faire les efforts nécessaires pour que les données circulent dans de bonnes conditions.
• Responsabilité partagée : Un outil, une base de données, voire un sous-domaine entier contenant des règles de gestion, est partagé entre deux Contextes. Dans ce cas, les deux directions, avec parfois des intérêts contradictoires, doivent se coordonner pour assurer le bon fonctionnement de cette liaison. Ce cas doit être évité autant que possible, il demande des efforts supplémentaires, mais il peut être nécessaire dans certaines situations.
• Langage publié : Dans certains cas, le langage de communication entre deux Contextes est parfaitement défini par un standard public, largement utilisé y compris par d’autres organisations. Dans ce cas, dans la mesure où les services ont fait le choix logique d’utiliser ce standard, on le modélise d’une manière spécifique.
• Chemin séparés : Un service a régulièrement besoin des données d’un autre service, mais le service fournisseur ne met pas à disposition un système efficace pour automatiser la récupération de la donnée pour le service client. Cette liaison peut indiquer aussi la suspicion que des échanges manuels mal identifiés (via Tableur Excel par exemple) sont présents. Cette situation est problématique car impactant l’efficacité du service consommateur, l’identification de ce niveau de coopération doit être un point d’alerte demandant une intervention.

Un mot sur les différents types d’équipes

À ce stade, vous avez terminé la modélisation du domaine, félicitations !

Avant de clôturer cette page, nous voudrions évoquer une thématique qui n’était pas facile d’évoquer plus tôt car nous ne la modéliserons pas dans notre cartographie : les différents types d’équipes que vous pouvez être amené à mettre en place au sein de votre organisation.

Nous en identifions trois qui méritent d’être évoqués :

• Les équipes orientées vers la valeur (Stream-Aligned Team). Ces équipes, pluri disciplinaires, sont concentrés sur la production de valeur pour les clients de votre organisation. Il convient d’insister sur la pluridisciplinarités de ses membres, et de résister à la tentation de créer des équipes par thématiques (avec une équipe commerciale, une équipe conception etc…). A l’inverse, les architectures Agile nous incite fortement à créer des équipes autonomes regroupant toutes les disciplines et qui sont concentrés sur un profil de client précis. Par exemple, il est préférable de créer des équipes qui s’occupent chacune d’une zone géographique, d’un segment de marché différents etc…

• Les équipes de compétences (Competency Team): Dans la mesure où les différents profils de compétences sont dilués dans les équipés orientés vers la valeur, il devient difficile pour chaque spécialiste de pouvoir échanger avec ses pairs. C’est pourquoi vous devez aussi, en complément, mettre en place des équipes de compétences, transversales à votre organisation. Via des canaux de communication dédiés, les spécialistes pourrons ainsi continuer à échanger entre eux et monter en compétences, tout en restant concentré sur leur mission au sein de leur équipe principale. Des représentants seront chargés d’organiser ces équipes, et de faire remonter les besoins de leurs confrères.

• Les équipes plate-formes (Platform Team): Celles-ci sont chargés de maintenir les outils dont ont besoin les autres équipes

Conclusion

Cette cartographie, qui contient à la fois des enjeux technique (pour la DSI) et des enjeux organisationnel (pour la DG) vous donnera la vue d’ensemble nécessaire pour mieux comprendre le fonctionnement de votre organisation et d’identifier les points d’amélioration possibles. Elle doit être un support de travail important entre la DSI et la direction générale, et vous permettra également de mieux communiquer avec les autres services de votre organisation ainsi que de mieux comprendre leurs besoins. En mettant en évidence la présence des différences données et leurs bonne ou mauvaise circulation, elle est un support important pour permettre de débloquer la bonne circulation des données entre chaque service, et donc de lutter contre les silos de données qui existent dans la plupart des organisations.

Cette cartographie doit bien sûr être maintenue à jour en permanence, notamment lors de la mise en place de nouveaux outils ou de l’identification de nouveaux sous-domaines ou données au sein de votre organisation. Elle doit également être partagée avec l’ensemble des services de votre organisation, afin que chacun puisse en prendre connaissance, savoir où ils se situent et comprendre l’importance de mettre à disposition leurs propres données au reste des collaborateurs.