Atlas relie les fonctions métier, les applications qui les outillent et les données qu'elles échangent. Il en tire une vue urbanisée façon Plan d'Occupation des Sols, déduit le graphe des dépendances par la donnée, et contrôle la cohérence de l'ensemble en continu. Le tout dans un seul fichier qu'on ouvre : aucune dépendance, aucun serveur, vos données restent locales.
Pourquoi cartographier
Un système d'information ne se conçoit pas une fois pour toutes : il grossit par accumulation, au fil des projets et des outils. L'urbanisation du SI est la discipline qui le garde lisible et évolutif, en l'organisant comme un territoire. Et tout commence par une carte : sans elle, on pilote à l'aveugle.
Applications qui se recouvrent, données dupliquées à plusieurs endroits, dépendances invisibles entre services. Personne n'a la vue d'ensemble, et chaque décision (acheter, intégrer, arrêter) se prend sans savoir ce qu'elle touche en aval.
Urbaniser, c'est découper le SI comme une ville : des zones (les grands domaines métier), des quartiers (les sous-domaines), des parcelles (les fonctions). Le POS dit qui occupe quoi, quelles applications outillent chaque fonction et quelles données y circulent.
Une cartographie partagée fait passer du descriptif au décisionnel : rationaliser le parc, décommissionner les doublons, sécuriser les données sensibles, aligner le SI sur la stratégie. C'est le socle de toute trajectoire de transformation.
Le parti pris
La cartographie applicative est le Saint Graal des DSI, et rarement bien faite. Atlas s'en tient à une règle d'urbaniste : trois objets, et aucun lien direct entre applications. Tout le reste se déduit.
On dit quelle fonction métier utilise quel logiciel, et quelles données elle consomme ou produit. Les flux entre fonctions sont déduits de la donnée, jamais saisis deux fois.
Atlas distingue les données de valeur : les données de référence (golden data), avec leur source faisant autorité, et les indicateurs de pilotage. La criticité descend de la donnée vers le SI.
Pas de build, pas de serveur, pas de base : un seul fichier HTML. On l'ouvre, ça marche, même hors-ligne. Le modèle s'édite en ligne et se transporte d'un client à l'autre.
Le catalogue
Atlas est livré avec un large catalogue, du métier au support : CAO et conception, calcul et simulation, gestion des données techniques (PLM), calcul HPC, ERP et finance, IAM et sécurité, bureautique, stockage et sauvegarde, bases de données, supervision. On coche ce qui est utilisé, c'est terminé.
Le parcours
Atlas suit l'ordre d'une mission d'urbanisation : on construit le modèle, on le visualise, on le contrôle. Chaque vue est dérivée des mêmes données, donc toujours cohérente.
Construire
On pose les fonctions clés et support, par sous-domaine, comme les zones d'un plan d'urbanisme.
Construire
Le dictionnaire des données que les fonctions consomment ou produisent.
Construire
Un catalogue de ~300 applis : on coche en un clic ce qui tourne dans la maison.
Construire
On glisse les applications et les données dans les fonctions.
Visualiser
Le POS cliquable : chaque fonction, ses applications, ses données, ses flux dérivés.
Visualiser
Le parcours d'une donnée, amont et aval, multi-sauts : l'analyse d'impact.
Contrôler
Données orphelines, fonctions non outillées, applis candidates au décommissionnement.
Communiquer
Une affiche d'urbanisation type Longépé, en une page, imprimable en PDF pour le COMEX.
Aperçu de l'outil
Une seule saisie, plusieurs lectures. La même matrice fonction / application / donnée se rend en planche d'ensemble, en graphe de flux ou en carte cliquable : voici de vraies sorties d'Atlas, sur l'exemple livré.
En pratique
Rattacher un logiciel ou une donnée à une fonction, c'est un glissé : on prend dans le parc, on dépose dans la fonction. (Animation.)
Gouvernance de la donnée
Atlas dérive automatiquement le parcours de chaque donnée et met en évidence les référentiels : leur source faisant autorité, les cas de sources multiples à arbitrer, et la criticité qui en découle pour le SI.
Parcours d'un référentiel