Toute démarche de rationalisation commence par la même phrase : il nous faut une cartographie. Six semaines plus tard, on livre un tableau. Deux cents lignes, une application par ligne, des colonnes pour l’éditeur, la version, le nombre d’utilisateurs, le coût annuel.
Ce tableau est un inventaire. Il a sa valeur — on n’arbitre pas sur ce qu’on ignore. Mais il ne permet aucune décision, parce qu’il ne dit rien de ce qui compte : ce qui se casse si l’on retire une ligne.
Ce qu’un inventaire ne dit pas
Une application n’a pas de coût isolé. Elle a un coût, des dépendances et une place dans une chaîne. L’inventaire ne capte que le premier terme :
- quels processus métier s’arrêtent si elle tombe, et pendant combien de temps
- quelles autres applications l’interrogent, et par quel moyen
- quelles données elle détient en propre, et lesquelles elle recopie d’ailleurs
- qui sait la faire fonctionner — et ce qui se passe le jour où cette personne s’en va
Ce sont ces quatre réponses qui séparent une liste d’une carte. Elles ne se trouvent dans aucun référentiel : elles se recueillent auprès de ceux qui utilisent l’outil tous les jours.
La dépendance qu’on ne voit qu’en la coupant
Dans la plupart des systèmes constitués par sédimentation, il existe au moins un maillon dont personne n’a la description complète : un export nocturne, un fichier déposé sur un partage, une macro héritée d’un poste qui n’existe plus. Il fonctionne, donc il est invisible.
Le premier mérite d’une cartographie sérieuse est de rendre ces maillons visibles avant qu’un projet ne les rompe. C’est aussi le moment le moins coûteux pour les traiter.
Un inventaire dit ce que vous possédez. Une cartographie dit ce que vous risquez en y touchant.
Le niveau de détail utile
L’erreur symétrique consiste à vouloir tout modéliser. Une cartographie exhaustive coûte cher, vieillit en quelques mois et cesse d’être tenue à jour dès que le prestataire qui l’a produite est parti.
Le bon niveau est celui qui permet de trancher : assez de détail pour décider de conserver, remplacer ou retirer une application, pas davantage. Ce qui suppose de savoir, avant de commencer, quelles décisions on cherche à préparer.
Ce qu’on en fait ensuite
Une cartographie n’est pas un livrable, c’est un instrument. Elle alimente le schéma directeur, elle donne sa base au plan de reprise, elle sert d’argumentaire le jour où un éditeur annonce une fin de support. Produite sans ces usages en tête, elle finit dans un dossier partagé que plus personne n’ouvre.