{"id":211,"date":"2024-01-14T00:19:45","date_gmt":"2024-01-13T23:19:45","guid":{"rendered":"https:\/\/zoominandout.fr\/?p=211"},"modified":"2024-01-14T00:19:46","modified_gmt":"2024-01-13T23:19:46","slug":"here-be-dragons-ou-la-difficile-cartographie-du-si","status":"publish","type":"post","link":"https:\/\/zoominandout.fr\/index.php\/2024\/01\/14\/here-be-dragons-ou-la-difficile-cartographie-du-si\/","title":{"rendered":"\u00ab\u00a0Here be dragons\u00a0\u00bb, ou la difficile cartographie du SI"},"content":{"rendered":"\n

Pour tout randonneur, une carte est bien utile pour savoir o\u00f9 on est et quel chemin prendre pour aller l\u00e0 o\u00f9 on veut. De m\u00eame, pour un syst\u00e8me d’information, une \u00e9quipe informatique a besoin de s’appuyer sur une cartographie pour adapter le SI aux enjeux du m\u00e9tier, sans parler de l’optimiser ou simplement de le maintenir en \u00e9tat de fonctionnement. Pourtant, la plupart des SI ne disposent pas de cartographie r\u00e9ellement <\/em>op\u00e9rationnelle, \u00e0 la fois utile, utilisable et utilis\u00e9e. Alors, comment mettre en place des cartographies qui repoussent l’inconnu, le Here be dragons <\/em>des cartes anciennes ?<\/p>\n\n\n\n

Apr\u00e8s une p\u00e9riode de d\u00e9veloppement des SI, beaucoup d’entreprise doivent aujourd’hui revoir leur c\u0153ur de SI – qui est obsol\u00e8te, ou non adapt\u00e9 \u00e0 la nouvelle configuration du march\u00e9 -, ou optimiser leur portefeuille d’application pour r\u00e9duire les co\u00fbts de possession en impactant le moins possible le service rendu au m\u00e9tier. Sans la carte du territoire<\/em>, ces chantiers d’adaptation ou de transformations sont risqu\u00e9s et compliqu\u00e9s, et finissent \u00eatre en retard et co\u00fbteux (s’ils finissent !). On construit rarement sur du green field<\/em> : le brown field <\/em>est quand m\u00eame la situation la plus rencontr\u00e9e.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Que trouve-t-on dans une cartographie de SI ?<\/h2>\n\n\n\n

Que contient une cartographie de SI ? A minima, elle contient le portefeuille applicatif, sa projection dans l’organisation, les d\u00e9pendances entre ces \u00e9l\u00e9ments. Le portefeuille applicatif est l’inventaire de l’ensemble des applications et de leurs constituants. La projection dans l’organisation est le d\u00e9coupage des p\u00e9rim\u00e8tres de responsabilit\u00e9 (et de financement) de ce m\u00eame portefeuille. Enfin, les d\u00e9pendances peuvent se comprendre comme des flux de donn\u00e9es, d\u00e9finissant des relations producteur-consommateur entre applications. Ces \u00e9l\u00e9ments sont n\u00e9cessaires pour appr\u00e9hender le SI comme un syst\u00e8me socio-technique : la combinaison d’\u00e9l\u00e9ments informatiques et de savoir-faire humains produit (ou devrait produire) une valeur sup\u00e9rieure \u00e0 la somme des valeurs unitaires. <\/p>\n\n\n\n

Ce noyau de cartographie est souvent compl\u00e9t\u00e9 par une projection du SI sur l’infrastructure, c’est-\u00e0-dire le d\u00e9ploiement des \u00e9l\u00e9ments applicatifs sur les ressources techniques. Cette information est g\u00e9n\u00e9ralement conserv\u00e9e et exploit\u00e9e dans une CMDB (qui peut avoir les m\u00eames probl\u00e8mes de fra\u00eecheur et d’exhaustivit\u00e9 !). Elle sert \u00e0 exploiter le parc technique pour atteindre les engagements de niveau de service, et potentiellement \u00e0 l’optimiser sur un plan \u00e9conomique, dans une approche de FinOps<\/em>. <\/p>\n\n\n\n

Pour les cartographies les plus avanc\u00e9es, nous avons aussi une mise en correspondance entre le SI et les processus M\u00e9tier, qui \u00e9tablit le lien entre les activit\u00e9s de processus et les \u00e9l\u00e9ments applicatifs. Cette relation fournit les d\u00e9pendances entre le mod\u00e8le op\u00e9rationnel de l’organisation et le parc applicatif et d’identifier les \u00ab\u00a0applications critiques\u00a0\u00bb, celles qui supportent les processus M\u00e9tier les plus importants. Cette compr\u00e9hension est utile pour orienter les efforts sur les enjeux m\u00e9tier. L’allocation des efforts n’est pas si \u00e9vidente que l’on pourrait le penser, car elle doit tenir compte des d\u00e9pendances entre applications. En effet, pour qu’un service m\u00e9tier soit rendu, toute la cha\u00eene applicative qui le sous-tend doit fonctionner de bout en bout<\/em>. . Par exemple, un bus de service qui n’a pas de valeur m\u00e9tier en soi, h\u00e9rite souvent de la criticit\u00e9 des applications m\u00e9tier qu’il supporte. On peut aller encore plus loin en s’appuyant sur ce lien entre SI et processus pour rechercher l’efficience du SI en fonction de la valeur m\u00e9tier induite. Cette approche offre une alternative mieux-disante \u00e0 la recherche de la r\u00e9duction du co\u00fbt absolu du SI (voir cet autre article du blog, Pour un nouveau contrat entre le m\u00e9tier et l\u2019IT<\/a>).<\/p>\n\n\n\n

\"\"
Structure de la cartographie du SI<\/figcaption><\/figure>\n\n\n\n

La difficult\u00e9 \u00e0 disposer d’une bonne cartographie<\/h2>\n\n\n\n

Pour qu’une cartographie puisse apporter de la valeur, elle doit \u00eatre suffisamment <\/em>\u00e0 jour, suffisamment <\/em>compl\u00e8te, suffisamment <\/em>manipulable et intelligible par la plupart des acteurs et suffisamment <\/em>employ\u00e9e dans la planification et la mise en \u0153uvre des changements du SI. En mati\u00e8re de cartographie, la perfection n’est pas n\u00e9cessaire. De toute fa\u00e7on, la carte n’est pas le territoire<\/em>1<\/a><\/sup> ! L’approximation est acceptable si les erreurs potentielles sont facilement d\u00e9tectables et r\u00e9parables par les acteurs, que ce soit par des proc\u00e9dures ou des contr\u00f4les automatiques. Dans ces conditions, les acteurs ont une confiance fond\u00e9e \u00e0 s’appuyer sur la cartographie pour analyser le SI et prendre des d\u00e9cisions pertinentes sur les trajectoires des projets.<\/p>\n\n\n\n

\n

Une carte\u00a0n\u2019est pas<\/em>\u00a0le territoire qu\u2019elle repr\u00e9sente, mais, si elle est juste, poss\u00e8de une\u00a0structure similaire<\/em>\u00a0\u00e0 ce territoire, ce qui justifie son utilit\u00e9<\/p>\n\u00a0A Non-Aristotelian System and its Necessity for Rigour in Mathematics and Physics<\/em>, \u00a0Alfred Korzybski<\/a>, 1931\u00a0<\/cite><\/blockquote>\n\n\n\n

Malheureusement, beaucoup de cartographies sont trop approximatives. Les acteurs doivent alors aller \u00e0 la p\u00eache aux informations <\/em>et v\u00e9rifier syst\u00e9matiquement toutes les informations pr\u00e9sent\u00e9es. Le b\u00e9n\u00e9fice de la cartographie s’\u00e9vapore compl\u00e8tement. Cette situation s’explique par la trag\u00e9die des communs<\/em>2<\/a><\/sup> : tout le monde b\u00e9n\u00e9ficierait d’une cartographie op\u00e9rationnelle, mais personne n’a le temps\/l’envie\/la comp\u00e9tence (rayez la mention inutile) pour la mettre \u00e0 jour. Ce conflit entre int\u00e9r\u00eat collectif et int\u00e9r\u00eat individuel peut \u00eatre r\u00e9solu par la gouvernance du syst\u00e8me d’information, qui promeut les comportements de bons citoyens et instruit les \u00e9carts par rapport \u00e0 cette norme. Les acteurs ont donc des incitations pour mieux coop\u00e9rer entre eux. Ne ha\u00efssez pas les joueurs, mais le jeu<\/em>3<\/a><\/sup> !<\/p>\n\n\n\n

Approche classique de mise en place de la cartographie<\/h2>\n\n\n\n

Dans une approche classique, les \u00e9quipes produisent les dossiers d’architecture des applications, en responsabilit\u00e9, et reversent les \u00e9l\u00e9ments d’information dans une base de connaissance commune, ladite cartographie. Le dossier d’architecture sp\u00e9cifie notamment l’implantation de l’application dans le SI : comment l’application interagit avec le reste du SI ? comment est-elle d\u00e9ploy\u00e9e au travers de l’ensemble de ses environnements ? comment cette implantation va se r\u00e9aliser dans le temps ? La cartographie du SI est \u00e0 la fois l’unification de ces \u00ab\u00a0cartes locales\u00a0\u00bb mais aussi la piste chronologie de la carte globale. Elle d\u00e9crit \u00e0 la fois l’\u00e9tat pr\u00e9sent du SI, mais aussi l’\u00e9tat projet\u00e9 au travers de plusieurs trajectoires (l’\u00e9tat pass\u00e9 peut aussi \u00eatre int\u00e9ressant dans le cas de r\u00e9trospective). En s’appuyant sur la cartographie, les acteurs construisent une compr\u00e9hension commune de la situation, mais aussi s’entendent sur la coh\u00e9rence de leurs plans d’action. <\/p>\n\n\n\n

\"\"
Assemblage de la cartographie globale du SI<\/figcaption><\/figure>\n\n\n\n
La cartographie du SI est parfois assimil\u00e9 comme le dossier d'architecture du SI. Cela me semble \u00eatre une erreur \ud83e\udee3.  \nLe dossier d'architecture ne se r\u00e9sume pas \u00e0 des sch\u00e9mas d'impl\u00e9mentation ! Il contient tout un raisonnement qui conduit des enjeux m\u00e9tier aux exigences non fonctionnelles, puis aux choix d'impl\u00e9mentation et \u00e0 la sp\u00e9cification des environnements. Ce raisonnement permet de comprendre l'existant et peut \u00eatre remis en cause de fa\u00e7on consciente pour s'adapter \u00e0 de nouvelles circonstances. \nDe l'autre c\u00f4t\u00e9, la cartographie doit rester \u00e0 un niveau de simplification suffisant pour rester exploitable. Bien s\u00fbr, quand on arrive sur une application dans la carte, il est int\u00e9ressant de joindre le dossier d'architecture de celle-ci pour \"creuser\". \nSi on fait une analogie dans le monde du b\u00e2timent, le plan cadastral nous donne l'organisation des parcelles tandis que le plan technique du b\u00e2timent implant\u00e9 sur la parcelle d\u00e9crit sa structure. Le plan cadastral serait s\u00fbrement lourd \u00e0 consulter s'il contenait la description d\u00e9taill\u00e9e des b\u00e2timents.  <\/pre>\n\n\n\n
Comment faire une cartographie en r\u00e9trospective ? <\/h2>\n\n\n\n

Et comment faire une cartographie si on n’a pas suivi cette approche classique ? Dans cette situation, on  constate souvent une documentation \u00e9crite incompl\u00e8te, non actualis\u00e9e, voire absente ! La connaissance est dans la t\u00eate des acteurs (enfin, c’est ce qu’ils imaginent !) et ces derniers n’ont pas l’id\u00e9e de renseigner une cartographie spontan\u00e9ment (vous vous rappelez la trag\u00e9die des communs<\/em> ?). Les produits du march\u00e9 visent la population des architectes, qui ne repr\u00e9sentent qu’une toute petite fraction de la DSI et sont parfois jug\u00e9s comme trop complexes pour les autres acteurs de la DSI. Dans ces conditions, les architectes collectent les informations et sont les seuls \u00e0 renseigner le r\u00e9f\u00e9rentiel. Certes, nous avons une cartographie utile et utilisable, mais pas utilis\u00e9e par le plus grand nombre \ud83d\ude1e. Et cela d\u00e9pend d’un effort important concentr\u00e9 sur un petit nombre d’acteurs, un effort qui se d\u00e9multiplie quand il s’agit de reprendre l’existant (le fameux Here be dragons<\/em>). Un autre frein dans cette d\u00e9marche est le processus d’achat du produit. Il est compliqu\u00e9 de faire entendre le ROI d’une cartographie pour motiver cet achat. La perte de temps de la p\u00eache aux informations ou les op\u00e9rations \u00ab\u00a0coup de poing\u00a0\u00bb d’inventaire d’existant sont difficiles \u00e0 valoriser pour alimenter le business case<\/em> de l’achat du produit de cartographie.<\/p>\n\n\n\n
Et si on doit d\u00e9marrer l\u00e9ger ?<\/h2>\n\n\n\n
L’ann\u00e9e derni\u00e8re, j’ai eu l’opportunit\u00e9 de construire une alternative plus l\u00e9g\u00e8re pour initier une cartographie sur tout ou partie du SI et commencer \u00e0 explorer le Here be dragons<\/em>.  Elle se d\u00e9roule en deux temps : une phase de collecte dans des feuilles de calcul, suivie d’une phase de contr\u00f4le bas\u00e9e sur une repr\u00e9sentation graphique dynamique, affichable avec cet excellent outil qu’est Ilograph<\/a>.  L’affichage permet de valider en s\u00e9ance les renseignements collect\u00e9s avec l’ensemble des acteurs. Cette approche permet de rassembler et de croiser le savoir des acteurs, qu’ils soient managers, d\u00e9veloppeurs ou op\u00e9rateurs.  <\/p>\n\n\n\n
La mod\u00e9lisation du SI est volontairement simple. Le portefeuille applicatif est un ensemble de ressources organis\u00e9 en une s\u00e9rie de poup\u00e9es gigognes : les organisations sont divis\u00e9es en unit\u00e9s organisationnelles\u202f; les unit\u00e9s organisationnelles sont en charges  d’applications et ces applications sont impl\u00e9ment\u00e9es par des composants. Le concept d’application est ici central, positionn\u00e9 entre l’organisation humaine et les composants d\u00e9ploy\u00e9s (voir Et pour vous, qu\u2019est-ce qu\u2019une application ?<\/a>). Un point important dans cet exercice est d’identifier tous les \u00e9l\u00e9ments (et donc de fournir un identifiant \u00e0 chacun).  Curieusement, il n’y a pas toujours d’identifiant fixe et universel de disponible (par exemple, un code applicatif pour d\u00e9signer une application). Dans ce cas, il faudra produire de fa\u00e7on arbitraire un identifiant pour poursuivre la d\u00e9marche.  Le tout premier b\u00e9n\u00e9fice de la cartographie est de pouvoir nommer sans ambigu\u00eft\u00e9 les constituants du SI \ud83d\ude42 ! <\/p>\n\n\n\n
\"\"
Proessus de r\u00e9trocartographie<\/figcaption><\/figure>\n\n\n\n
Ensuite, on formalise les flux d’informations entre les applications, les flux applicatifs<\/em>. Les flux sont des abstractions au-dessus des flux techniques qui correspondent \u00e0 des ouvertures de r\u00e9seau.  Pour reconstituer les flux applicatifs, on recherche leurs points de passage avec l’aide des op\u00e9rateurs. Un point de passage peut \u00eatre un job <\/em>dans un ordonnanceur, un label d’un transfert de fichier, une souscription sur une API… Un flux applicatif est fr\u00e9quemment compos\u00e9 de plusieurs flux techniques. De m\u00eame, que pour les ressources, les flux sont identifi\u00e9s. <\/p>\n\n\n\n
\"\"
M\u00e9ta-mod\u00e8le de cartographie<\/figcaption><\/figure>\n\n\n\n
La feuille de calcul est un bon support pour ce cas d’usage. Les acteurs sont habitu\u00e9s \u00e0 ce format documentaire. Ce format est flexible : on peut ajouter des champs suppl\u00e9mentaires qui apportent une information pertinente dans le contexte. <\/p>\n\n\n\n
L’export des donn\u00e9es de la feuille de calcul vers un diagramme Ilograph est r\u00e9alis\u00e9 par un script Python, d\u00e9velopp\u00e9 pour l’occasion. Ce script peut \u00eatre adapt\u00e9 pour prendre en compte des particularit\u00e9s. <\/p>\n\n\n\n
Le diagramme Ilograph fournit une repr\u00e9sentation graphique bien adapt\u00e9 \u00e0 des sessions de travail en groupe. On peut modifier \u00e0 la vol\u00e9e l’affichage, en choisissant un niveau dans l’organisation des ressources (d’o\u00f9 l’int\u00e9r\u00eat des poup\u00e9es gigognes plus haut) ou s\u00e9lectionnant l’\u00e9l\u00e9ment central \u00e0 repr\u00e9senter. Il est possible d’adapter l’affichage en fonction du point abord\u00e9. Un autre int\u00e9r\u00eat par rapport \u00e0 d’autres solutions de diagramming<\/em> est la meilleure tol\u00e9rance pour afficher des syst\u00e8mes avec beaucoup de flux. Comme les syst\u00e8mes d’information sont de plus en plus distribu\u00e9s, on a besoin de solutions qui nous permettent d’afficher ces graphes sans qu’ils ressemblent \u00e0 une toile d’araign\u00e9e (c’est joli, mais pas tr\u00e8s utile ! ).<\/p>\n\n\n\n
Il est aussi possible de compl\u00e9ter le mod\u00e8le pour inclure les trajectoires de transformation de SI. C’est un point que je suis en train d’exp\u00e9rimenter (et ce sera sans doute l’objet d’un prochain article \ud83d\ude09).<\/p>\n\n\n\n
TL;DR<\/h2>\n\n\n\n
Cartographier le SI est donc une activit\u00e9 essentielle de la DSI, dans le contexte actuel. Cette activit\u00e9 peut \u00eatre d\u00e9coup\u00e9e en deux volets : la cartographie des nouveaux pans du SI et celle de l’existant.<\/p>\n\n\n\n
 La cartographie des nouveaux pans implique de remettre de l’architecture intentionnelle dans la d\u00e9marche des projets ou des it\u00e9rations : instruire les dossiers d’architecture peut \u00eatre une pratique \u00e0 d\u00e9marrer ou restaurer. Certes, il ne s’agit plus maintenant de produire des corpus documentaires volumineux comme avant, mais de r\u00e9aliser une documentation efficace s’appuyant sur des pratiques modernes comme les ADR pour instruire les choix ou les DSL pour produire les sch\u00e9mas d’architecture. <\/p>\n\n\n\n
La cartographie de l’existant implique de pouvoir r\u00e9cup\u00e9rer la connaissance sur le SI qu’elle soit sur des supports \u00e9crits ou dans la t\u00eate des sachants<\/em> et de la mettre en qualit\u00e9. <\/p>\n\n\n\n
Prioriser la remise en \u00e9tat de la connaissance du SI reste une t\u00e2che difficile. Aussi, une approche l\u00e9g\u00e8re et it\u00e9rative, comme d\u00e9crite pr\u00e9c\u00e9demment, peut amorcer un cercle vertueux qui d\u00e9montre les b\u00e9n\u00e9fices de disposer d’une cartographie du SI avec un investissement minimal. Ensuite, le passage vers une approche plus industrielle peut se produire pour fournir une cartographie \u00e0 l’\u00e9chelle de l’organisation et pour supporter l’ensemble des trajectoires dans le SI.<\/p>\n\n\n\n
Cr\u00e9dits<\/h3>\n\n\n\n