Outil · Diagnostic
Votre parc décisionnel mérite-t-il une migration ?
Six paramètres que vous connaissez déjà, quatre axes de lecture, un verdict argumenté à porter en comité. La grille ne décide pas à votre place : elle rend visible ce que votre parc dit déjà.
La grille situe l'arbitrage entre refonte, migration et statu quo assumé à partir de six paramètres qu'un responsable BI peut relever en une demi-journée. Elle ne décide pas à votre place : elle rend visible ce que le parc dit déjà, avec des pondérations affichées et discutables.
L’essentiel
- Un score élevé ne signifie pas migrer vite, il signifie que l'écart entre coût de maintien et service rendu est devenu mesurable.
- En dessous de quarante, le sujet n'est pas le parc mais une date de fin de support à relever.
- Entre quarante et soixante-dix, l'arbitrage se joue sur le taux d'usage, jamais sur le volume seul.
- Le taux d'usage est le paramètre que personne ne connaît de tête, et celui qui pèse le plus lourd.
Périmètre Pour un responsable BI ou un DSI d'ETI disposant de l'inventaire de ses rapports et, idéalement, des logs du serveur. L'outil ne chiffre ni la charge du chantier, traitée par le calculateur de charge, ni le coût de licence de la cible ; il ne convient pas à un parc dont les rapports alimentent des flux applicatifs plutôt que des lecteurs.
Grille d'audit
Décrivez le parc, la grille situe l'arbitrage
Les six champs correspondent à ce qu'un responsable BI peut sortir de son serveur en une demi-journée. Si vous ne connaissez pas encore votre taux d'usage réel, laissez la valeur par défaut et lisez la réponse comme une hypothèse : c'est justement le chiffre qui déplacera le plus le verdict.
Les pondérations ci-dessous sont une convention de lecture posée par ce site, pas un barème sectoriel relevé sur une source publique. Elles sont écrites pour être contestées en comité : si votre contexte impose une autre répartition, le calcul se refait à la main en trois minutes.
| Axe | Poids | Ce qu'il mesure |
|---|---|---|
| Usage réel | 25 | La part du parc qui n'est plus consultée. C'est l'axe qui fait basculer le verdict de « migrer » vers « refondre ». |
| Volume | 25 | Rapports et univers cumulés. Le volume ne dit rien de la valeur, il dit le coût de la reprise à l'identique. |
| Criticité et dépendances | 25 | Ce qui casse en aval si la bascule dérape : clôture, liasses, flux vers d'autres applications. |
| Âge du socle | 25 | Proxy grossier de la dette accumulée. Il ne remplace pas la date de fin de support de votre version exacte. |
Lecture du résultat
Ce que le score dit, et ce qu'il ne dit pas
Un score élevé ne veut pas dire qu'il faut migrer vite. Il dit que l'écart entre ce que le parc coûte à maintenir et ce qu'il rend est devenu mesurable. Trois lectures se distinguent nettement.
En dessous de 40, le parc n'est pas le sujet. Ce qui vous mettra sous contrainte, c'est une date de fin de support, pas l'état de vos rapports. Le travail utile consiste alors à relever cette date sur la note de maintenance de l'éditeur, à la dater, et à la remettre au planning une fois par trimestre.
Entre 40 et 70, l'arbitrage se joue sur l'usage. Un parc de trois cents rapports dont quatre-vingts servent encore ne se migre pas : il se trie, puis se reconstruit sur le périmètre trié. La reprise à l'identique est la décision par défaut, c'est-à-dire celle que personne n'a arbitrée, et c'est presque toujours la plus chère.
Au-dessus de 70, la question n'est plus de savoir s'il faut bouger mais dans quel ordre. Le découpage en lots, chacun avec sa fenêtre de double run et son valideur métier nommé, coûte plus cher en coordination qu'une bascule unique. Il coûte infiniment moins cher qu'une clôture ratée.
Objection assumée
Cette grille ne convient pas à un parc dont les rapports sont majoritairement générés par une application tierce plutôt que consultés par des humains. Le taux d'usage y perd son sens : un rapport ouvert deux fois par an peut alimenter un flux quotidien. Dans ce cas, remplacez l'axe usage par une mesure de dépendance applicative, et lisez le score sans cet axe.
Méthode
Comment obtenir un taux d'usage qui tienne devant un comité
Le taux d'usage est le seul paramètre de cette grille que personne ne connaît de tête, et c'est celui qui pèse le plus. Il se relève sur les logs d'audit du serveur, sur une fenêtre de douze mois glissants, et la première chose à vérifier n'est pas le nombre de consultations : c'est la durée de rétention de ces logs.
Une rétention à quatre-vingt-dix jours transforme tout rapport trimestriel en rapport fantôme. Le tri qui en découle est faux, et il est faux dans le sens le plus coûteux : on décide d'abandonner des rapports que quelqu'un attend, et on ne s'en aperçoit qu'après la bascule, au moment où le rapport aurait dû sortir.
Le relevé utile comporte trois colonnes : identifiant du rapport, nombre d'ouvertures distinctes sur la période, et dernier utilisateur identifié. La troisième colonne est celle qui fait avancer le dossier, parce qu'elle donne un nom à qui poser la question. Un rapport sans propriétaire identifiable après relance n'est pas un rapport critique, quelle que soit son intitulé.
Ce périmètre exclut délibérément les rapports planifiés qui s'exécutent sans être ouverts. Ils apparaissent dans les logs d'exécution, pas dans les logs de consultation, et ils doivent être comptés à part sous peine de conclure à un abandon massif qui n'existe pas.
Périmètre
Pour qui cette grille est faite, et ce qu'elle ne couvre pas
Elle s'adresse à un responsable BI, un DSI d'ETI ou un chef de projet décisionnel qui pilote un socle exploité en interne et doit défendre un arbitrage devant un comité. Elle suppose que vous ayez accès à l'inventaire de vos rapports et, idéalement, aux logs du serveur.
Elle ne traite ni le coût de licence de la cible, qui dépend d'une grille tarifaire à relever et à dater, ni la charge du chantier en jours-homme. Ces deux questions ont leurs propres outils sur ce site, et les mélanger produit un chiffre que personne ne peut défendre : une charge et un coût de licence ne se cumulent pas dans la même unité.
Elle ne remplace pas non plus la lecture de la note de maintenance de votre éditeur. L'âge du socle saisi ici est un indicateur de dette, pas une échéance. La seule échéance qui engage un calendrier est celle qui figure noir sur blanc dans la documentation officielle, avec sa date de consultation.
Questions fréquentes
Ce qu'on nous demande sur cette grille
D'où viennent les pondérations ?
D'une convention de lecture posée par ce site, affichée en clair sous le résultat. Aucun barème sectoriel public ne pondère ces quatre axes : prétendre le contraire reviendrait à donner une source à un chiffre qui n'en a pas. Les poids sont volontairement égaux pour que la discussion porte sur vos valeurs, pas sur la formule.
Le score peut-il conclure qu'il ne faut rien faire ?
Oui, et c'est un résultat aussi valable qu'un autre. Un socle récent, largement consulté et peu couplé ne justifie pas un chantier au seul motif qu'une migration est à la mode. Le verdict « statu quo assumé » reste conditionné à une chose : connaître la date de fin de support de votre version exacte et l'avoir mise au planning de réexamen.
Mes données sont-elles enregistrées ?
Non. Le calcul se fait à la soumission du formulaire, à partir des seules valeurs présentes dans l'URL, et rien n'est écrit sur le serveur. Vous pouvez copier l'adresse de la page de résultat pour la retrouver ou la partager : elle contient vos paramètres, et elle recalcule le même verdict.
Pourquoi la grille ne demande-t-elle pas mon outil source ?
Parce que l'arbitrage refonte contre migration se joue sur la structure du parc, pas sur le nom du produit. Ce qui change d'un socle à l'autre, ce sont les mécanismes de reprise et les échéances de support — deux sujets traités séparément, l'un par le calculateur de charge, l'autre par les fiches d'échéances éditeurs.
Puis-je l'utiliser tel quel dans un dossier interne ?
Oui, à condition de reprendre aussi le tableau des pondérations. Un score sorti de son barème est un chiffre orphelin, et c'est exactement le type d'argument qu'un comité renvoie en séance suivante. Le tableau tient en quatre lignes, il coûte moins cher que la question qu'il évite.
Suite
L'étape d'après dépend de votre verdict
Si la grille conclut à une migration, la question suivante est celle de la charge : combien de jours-homme, avec quels ratios, et ce que l'estimation exclut. Le calculateur de charge de migration reprend le volume que vous venez de saisir et affiche ses hypothèses.
Si elle conclut à un statu quo, la seule chose à surveiller est l'échéance. Les échéances éditeurs expliquent comment lire une date de fin de support sans la confondre avec un ordre de migration.
Dans les deux cas, la bascule ne se signe pas à l'intuition : la checklist de recette avant/après fixe ce qui doit être identique, ce qui peut différer, et qui a le droit de valider.
Journal de mise à jour
- — Mise en ligne de l'outil et de sa convention de pondération.