Maîtrise de son SI : la condition préalable à toute évolution, sécurisation ou transformation

Vous avez peut-être déjà vécu cette situation : une demande métier arrive — migrer l’ERP, ouvrir un accès distant, changer de prestataire pour l’hébergement — et personne n’est en mesure de dire précisément ce que ça va impacter. Quels services vont être coupés ? Quelles applications dépendent de ce serveur ? Quelles données transitent par ce flux ? C’est le symptôme classique d’un SI mal cartographié.

La maîtrise du système d’information n’est pas une préoccupation réservée aux grandes entreprises avec une DSI structurée. C’est une condition préalable à toute évolution maîtrisée, à toute démarche de sécurisation, et à toute décision d’architecture éclairée — y compris dans les PME.

Pourquoi maîtriser son SI est une priorité stratégique

Un SI non documenté, c’est un SI qui se gère dans l’urgence. Les décisions se prennent sur la base de la mémoire des personnes présentes plutôt que sur une connaissance structurée et partagée. Trois enjeux concrets illustrent ce risque.

Faire évoluer sans casser

L’ajout d’un nouvel outil métier, la migration d’une application vers le cloud ou le changement de fournisseur de messagerie semblent des opérations localisées. Mais dans un SI interconnecté, chaque composant a des dépendances. Un ERP qui alimente un système de business intelligence, une messagerie qui sert d’annuaire d’authentification, un serveur fichiers qui héberge des données partagées entre plusieurs applications : sans cartographie, le risque de casser une chaîne critique est élevé.

Sécuriser ce qu’on expose réellement

On ne peut pas protéger ce qu’on ne connaît pas. Comme évoqué dans notre article sur la gestion des vulnérabilités, l’exposition d’un actif est un facteur multiplicateur du risque. Mais encore faut-il savoir ce qui est exposé : quels services sont accessibles depuis internet, quels postes ont accès à quelles données, quelles applications ne sont plus maintenues. La cartographie du SI est le point de départ de toute stratégie de sécurité.

Évaluer l’impact d’un changement avant qu’il soit trop tard

Avant de valider un changement — passage à une nouvelle version d’un progiciel, migration d’une infrastructure on-premise vers le SaaS, changement d’intégrateur — il faut être capable de répondre à : “Qu’est-ce que ça impacte sur le business ?” Cette réponse n’est possible qu’avec une vision claire des liens entre les processus métier, les applications et l’infrastructure qui les supporte.

ArchiMate : un langage pour modéliser l’architecture

ArchiMate est un standard ouvert de modélisation d’architecture d’entreprise, maintenu par The Open Group (la même organisation derrière le framework TOGAF). Il fournit un langage visuel commun pour représenter les éléments d’un SI et leurs relations, organisés en trois couches distinctes.

La couche Métier

La couche Métier décrit les processus, fonctions et acteurs de l’entreprise : vente, gestion des ressources humaines, comptabilité, production, direction. C’est le point de départ : on part des besoins business pour décrire ce que fait l’organisation, avant de s’intéresser à comment elle le fait techniquement.

La couche Application

La couche Application décrit les logiciels qui servent les processus métier : ERP, CRM, SIRH, messagerie, outils collaboratifs, logiciels métier spécifiques. Chaque application est reliée aux processus qu’elle supporte (via la relation “sert”) et à l’infrastructure qui l’héberge (via la relation “réalisé par”).

La couche Infrastructure (Technology)

La couche Infrastructure décrit les composants techniques qui font tourner les applications : serveurs physiques ou virtuels, services cloud, réseaux, stockage, équipements de sécurité. Elle distingue typiquement les éléments on-premise des services SaaS ou cloud hébergés chez des tiers.

Le SI d’une PME typique en modèle ArchiMate

Voici comment se présente, schématiquement, le SI d’une PME de 50 à 200 collaborateurs avec une activité de production ou de services. Le schéma ci-dessous représente les trois couches ArchiMate et leurs relations :

Couche Métier — Les grands processus : Vente & CRM, RH & Paie, Finance & Comptabilité, Opérations & Production, Direction & Pilotage, IT & Infrastructure.

Couche Application — Les outils qui les servent :

• Un CRM (HubSpot, Salesforce, Pipedrive) pour le commercial
• Un SIRH / outil de paie (PayFit, Silae, Sage RH) pour les RH
• Un ERP (Sage 100, SAP Business One, Cegid) central, couvrant finance, achats, stocks et facturation
• Microsoft 365 ou Google Workspace pour la messagerie, la collaboration et le stockage documentaire
• Un outil ITSM (GLPI, Jira Service Management) pour la gestion IT et l’inventaire

Couche Infrastructure — Ce qui héberge tout ça :

• En on-premise : un serveur Active Directory, un NAS pour les fichiers partagés, un firewall/VPN
• En SaaS/cloud : les applications CRM, SIRH, messagerie hébergées chez leurs éditeurs respectifs, un service Azure AD pour l’authentification, des solutions EDR/MDM pour la sécurité des postes

Les outils pour modéliser son SI

Plusieurs outils permettent de mettre en place cette démarche de modélisation, selon le niveau de maturité et les ressources disponibles.

Archi — l’open source de référence

Archi est l’implémentation open source de référence d’ArchiMate. Gratuit, multiplateforme, il permet de modéliser les 3 couches, de créer des vues filtrées par couche ou par domaine, et d’exporter en PDF ou SVG. C’est le point d’entrée recommandé pour débuter.

Les plateformes enterprise

BiZZdesign et Sparx Enterprise Architect proposent des environnements collaboratifs complets avec gestion de versions, tableaux de bord et intégrations avec d’autres référentiels (CMDB, ITSM). Adaptés aux DSI structurées avec plusieurs architectes.

Les outils de diagramme généralistes

draw.io (diagrams.net) et Lucidchart permettent de créer des schémas d’architecture sans suivre strictement la norme ArchiMate. Moins rigoureux, mais plus accessibles pour partager une vue avec des interlocuteurs non techniques.

La CMDB — le complément opérationnel

La Configuration Management Database est le référentiel opérationnel du SI : elle liste précisément les assets IT (serveurs, postes, équipements réseau, logiciels) et leurs relations. Des outils comme GLPI, ServiceNow ou Lansweeper alimentent et maintiennent cet inventaire automatiquement. La CMDB est le fondement de la couche Infrastructure en ArchiMate.

Par où commencer concrètement

La modélisation du SI ne nécessite pas de lancer un grand projet pluriannuel. Une approche pragmatique en 4 étapes permet d’obtenir rapidement une première vue utile.

1. Inventorier ses applications

Commencez par lister toutes les applications utilisées dans l’entreprise : les outils achetés, les SaaS souscrits, les logiciels développés en interne, et même les fichiers Excel critiques qui jouent un rôle de système. Pour chaque application : nom, éditeur, usage principal, nombre d’utilisateurs, mode d’hébergement (on-premise, SaaS, cloud privé).

2. Identifier les processus métier servis

Pour chaque application, identifiez quel(s) processus métier elle supporte. Cette étape force à lier le technique au business : si vous ne savez pas à quel processus correspond une application, c’est peut-être qu’elle n’est plus vraiment utilisée — ou que son usage n’est pas maîtrisé.

3. Cartographier l’infrastructure d’hébergement

Pour chaque application, identifiez où elle tourne : sur quel serveur on-premise, chez quel hébergeur cloud, dans quel datacenter tiers. Notez les interdépendances : l’application A utilise-t-elle la base de données de B ? Est-elle authentifiée via l’Active Directory ? S’appuie-t-elle sur un service partagé ?

4. Documenter les flux et intégrations

Les interfaces entre applications sont souvent les zones les plus fragiles et les moins documentées du SI. Un ERP qui exporte vers un outil BI, un CRM qui synchronise avec la messagerie, une application métier qui appelle une API externe : chaque flux est une dépendance invisible en cas de panne ou de migration.

Conclusion

Maîtriser son SI, c’est se donner les moyens d’en être le pilote plutôt que le passager. La cartographie ArchiMate n’est pas une fin en soi — c’est un outil de décision, de communication et de pilotage des risques.

Les PME qui investissent dans cette démarche constatent rapidement des bénéfices concrets : les projets d’évolution sont mieux cadrés, les incidents sont résolus plus vite, les décisions d’architecture s’appuient sur une réalité documentée plutôt que sur la mémoire collective.

La bonne nouvelle : vous n’avez pas besoin d’une équipe de 10 architectes pour commencer. Une première cartographie imparfaite mais partagée vaut mieux qu’une architecture parfaite qui n’existe que dans la tête du responsable IT.