Inventaire applicatif en PME : l'étape zéro que personne ne fait avant de moderniser son SI

Moderniser sans savoir ce qu'on a : ce qu'on observe sur le terrain

La décision de moderniser le SI d'une PME part presque toujours d'une douleur précise : un outil trop lent, un processus qui prend trop de temps, un rapport qu'on n'arrive pas à produire. Cette douleur pointe vers une solution évidente. On contacte un prestataire, on lui décrit le problème, et on commence à parler d'un nouvel outil.

Ce qu'on ne fait pas : lister ce qui existe déjà. Combien d'applications l'entreprise utilise vraiment ? Quels processus critiques vivent dans des fichiers Excel maintenus par une seule personne ? Quelles données sont dans des outils que personne n'a pensé à mentionner parce qu'ils semblent trop marginaux ?

Sans cet inventaire, une modernisation SI part avec une carte incomplète du territoire. Elle remplace ce qu'on voit et oublie ce qu'on ne voit pas. Les premières semaines d'utilisation du nouvel outil révèlent les oublis, et chaque oubli génère une demande d'évolution qui rallonge le projet.

Pourquoi les PME sautent l'inventaire applicatif

Trois raisons expliquent pourquoi l'inventaire applicatif est systématiquement sous-estimé ou omis.

Première raison : on pense connaître ses outils. Le dirigeant et le responsable informatique ont une liste mentale des logiciels en production. Mais cette liste couvre les outils officiels, pas les Shadow IT : les applications en ligne adoptées par tel service sans validation IT, les macros Excel qui automatisent un processus entier, les fichiers partagés sur Teams qui sont devenus de facto des bases de données opérationnelles.

Deuxième raison : l'inventaire semble ralentir le projet.Quand on a identifié un problème et qu'on veut le résoudre, passer une semaine à cartographier l'existant ressemble à un obstacle. C'est en réalité une économie : identifier en amont ce qui doit être repris dans le nouvel outil évite de le découvrir après la mise en production.

Troisième raison : les prestataires ne le demandent pas. Un prestataire qui vend une solution a intérêt à commencer vite. Demander un inventaire applicatif ralentit la signature et peut révéler que le périmètre est plus large que prévu. Un prestataire qui accompagne une transformation a intérêt à cartographier l'existant pour ne pas livrer une solution incomplète.

« Ils avaient une vision très « on a besoin de tel outil », alors qu'en fait ils avaient besoin davantage de mettre à plat et de mieux comprendre où est-ce qu'il y avait des effets de levier avec un vrai système d'information. »

Comment réaliser un inventaire applicatif en PME en moins de deux semaines

Ce que l'inventaire doit couvrir

Un inventaire applicatif utile n'est pas une liste exhaustive de tout ce qui existe. C'est une cartographie des applications qui supportent des processus métier réels, avec pour chacune quatre informations : qui l'utilise, à quelle fréquence, pour quel processus, et quelles données elle contient ou génère.

Cette cartographie couvre quatre catégories. Les applications officiellesvalidées par la direction ou le service informatique. Les outils adoptés par les équipes sans validation formelle (Shadow IT). Les fichiers opérationnels : Excel, Google Sheets, fichiers partagés qui servent de bases de données ou de tableaux de bord non formalisés. Et les processus manuelsqui ne s'appuient sur aucun outil mais génèrent ou consomment des données.

La méthode en trois étapes

La première étape est une revue avec le responsable informatique ou la direction, pour lister les outils connus et leurs périmètres déclarés. Cette revue prend une demi-journée.

La deuxième étape est une série d'entretiens avec les responsables de chaque service. L'objectif n'est pas de collecter une liste d'outils mais de comprendre comment le service fait son travail au quotidien, quelles informations il reçoit, quelles informations il produit, et avec quels supports. Ces entretiens révèlent systématiquement des outils et des processus absents de la liste initiale.

La troisième étape est la consolidation : une cartographie visuelle des outils, des flux de données entre eux, et des processus qu'ils supportent. Cette cartographie devient le document de référence pour la phase de modernisation. Elle permet de voir les redondances, les flux critiques, et les zones d'ombre. Pour comprendre comment un diagnostic SI se structure comme un livrable à part entière, l'article sur le diagnostic SI comme livrable (pas comme prestation gratuite) développe ce point.

Ce qu'un inventaire applicatif débloque concrètement

Un bureau d'étude offshore de 45 personnes en Bretagne avait intuitivement identifié qu'il lui fallait un outil particulier pour résoudre ses problèmes de coordination. L'inventaire applicatif a révélé une situation plus complexe : un ERP interne, des dizaines d'Excel personnels pour chaque service, des échanges Teams qui servaient de base de connaissance informelle, et un outil de facturation séparé. La vraie priorité n'était pas l'outil identifié initialement, mais la structuration du flux d'information entre ces systèmes existants.

Cette clarification a évité un investissement dans une solution qui n'aurait résolu qu'un symptôme. Elle a orienté le projet vers un premier chantier à impact plus immédiat : la structuration de la collaboration via Microsoft, avant d'attaquer la refonte SI plus profonde. Sur la question de quel premier chantier SI attaquer quand tout semble en tension, l'article par quel premier chantier SI commencer quand tout est en tension donne un cadre de priorisation.

Si vous êtes en train de réfléchir à une modernisation SI, la première question n'est pas « quel outil choisir ». C'est « qu'est-ce qu'on a, qui l'utilise, et pour faire quoi ». Répondre à ces trois questions en amont est ce qui transforme une modernisation en investissement rentable plutôt qu'en chantier interminable.