Inventaire SI PME/ETI: les informations vraiment utiles à maintenir
Un inventaire SI exploitable ne se limite pas à une liste d'applications. Voici les informations à maintenir pour décider, auditer et cartographier.
Avoir une liste d'applications ne veut pas dire avoir un inventaire SI exploitable.
Une liste répond à la question: "qu'est-ce qui existe ?" Un inventaire exploitable répond aussi à: "qui est responsable ?", "qu'est-ce qui est critique ?", "qu'est-ce qui dépend de quoi ?" et "peut-on faire confiance à cette donnée ?"
Pour une DSI de PME/ETI avec 60 à 120 applications, cette différence change tout.
En résumé
Un bon inventaire SI ne cherche pas l'exhaustivité CMDB. Il maintient peu d'informations, mais les bonnes: couverture du parc, owners, référents IT, criticité, statut, domaine métier, responsabilités et dépendances utiles.
Une liste n'est pas une source de vérité#
Le symptôme classique: l'entreprise possède un fichier avec 90 lignes, mais personne n'ose s'en servir pour décider.
Pourquoi ?
- Certaines applications métiers ne sont pas dans la liste.
- Les owners ont changé.
- Les applications archivées apparaissent encore comme actives.
- Les criticités ne sont pas harmonisées.
- Les dépendances sont notées dans une colonne commentaire.
Dans ce cas, l'inventaire existe administrativement. Il n'est pas exploitable opérationnellement.
Tester la qualité de votre inventaire
Le Diagnostic Inventaire SI évalue votre couverture, votre mise à jour, vos ownerships et la qualité des responsabilités.
1. Couvrir le parc applicatif utile#
La première question n'est pas "combien avons-nous d'applications au total ?" mais "les applications importantes sont-elles couvertes ?"
Pour une PME/ETI, le périmètre prioritaire ressemble souvent à ceci:
Vous pouvez ignorer temporairement les outils individuels sans donnée business, les essais abandonnés et les composants techniques qui relèvent d'un inventaire infrastructure séparé.
Repère pratique
Commencez par les applications qui ont un impact métier, une facture, des données sensibles ou plus de quelques utilisateurs réguliers. Le reste peut venir ensuite.
2. Identifier owners et responsabilités#
Un inventaire sans responsabilités est difficile à utiliser.
Au minimum, chaque application importante devrait avoir:
Ces rôles ne doivent pas être de simples cases remplies pour l'audit. Ils doivent servir pendant un incident, une migration, une revue de coûts ou un changement d'outil.
3. Maintenir criticité, statut et domaine métier#
Ces trois informations sont souvent plus utiles que 30 colonnes techniques.
Une application "critique" doit signifier quelque chose pour l'entreprise. Si tout est critique, rien ne l'est.
4. Documenter les dépendances qui aident à décider#
Il ne s'agit pas de modéliser tout le SI au niveau technique. Le bon niveau est celui qui permet de répondre à une question d'impact.
Exemples:
- Sage 100 alimente la comptabilité et dépend d'un serveur local.
- Silae dépend d'un export RH mensuel.
- Une application métier interne envoie des données vers l'ERP.
- Le portail client dépend d'un SSO ou d'une base commune.
La cartographie commence ici
Une cartographie SI utile n'est pas un dessin produit à côté de l'inventaire. Elle naît des relations maintenues dans l'inventaire.
5. Organiser la mise à jour#
Un inventaire obsolète donne une fausse sécurité. La maintenance doit être légère, mais explicite.
La règle: une nouvelle application ou un changement significatif doit déclencher une mise à jour. Sinon, l'inventaire redevient un fichier historique.
6. Distribuer l'ownership sans perdre le contrôle#
Dans une petite équipe IT, tout ne peut pas reposer sur le DSI.
L'objectif est de distribuer la connaissance sans créer de désordre:
- Un owner global de l'inventaire arbitre la qualité.
- Chaque domaine métier valide ses applications.
- Les référents IT maintiennent les informations techniques utiles.
- Les changements importants suivent un processus simple.
- Les revues restent courtes et régulières.
Cela permet à l'inventaire de rester compréhensible même si le DSI, le responsable IT ou un prestataire clé est absent.
Les informations à maintenir en priorité#
Moins de champs bien maintenus valent mieux que 40 colonnes vides.
FAQ#
Questions fréquentes
L'inventaire applicatif liste les applications. L'inventaire SI exploitable relie aussi les applications aux domaines métier, infrastructures, owners, criticités et dépendances utiles.
Non. Visez d'abord les applications critiques et les domaines principaux. L'exhaustivité vient par itérations, sans bloquer la première cartographie.
Pas forcément. Une CMDB peut être utile dans une organisation mature, mais une PME/ETI a souvent besoin d'abord d'une source de vérité simple, visuelle et maintenable.
Conclusion#
Un inventaire SI exploitable n'est pas une accumulation de colonnes. C'est une base de décision.
Il doit vous dire ce qui existe, qui en répond, ce qui est critique, ce qui est à jour et quelles dépendances méritent attention.
Créer ma première cartographie
Structurez votre inventaire SI dans CLARITY et commencez par les informations qui permettent vraiment de décider.