Un service identifie un besoin informatique urgent qui, à première vue, semble être une « petite évolution » ou une « amélioration évidente ». Ce besoin pourrait simplifier une tâche répétitive, améliorer la qualité d’une donnée, ou offrir un accès plus rapide à une information cruciale.
Cependant, sous prétexte que :
- Le service informatique est déjà surchargé.
- Le besoin semble mineur et peut être reporté.
- On pense pouvoir « bricoler » une solution temporaire.
La demande est souvent mise de côté, repoussée à « plus tard », ou priorisée derrière des projets jugés plus complexes ou stratégiques.
Les conséquences de ce report
Le problème survient lorsque cette « petite évolution évidente » n’est pas traitée immédiatement. Ce qui était perçu comme mineur peut rapidement :
- Prendre de l’ampleur : Le besoin initial se révèle être la pointe de l’iceberg, masquant des problèmes plus profonds ou interconnectés.
- Générer des inefficacités cumulées : Chaque jour où la solution n’est pas en place, l’entreprise perd du temps, de l’argent, ou subit des erreurs. Ces petites pertes s’additionnent et peuvent devenir significatives.
- Créer des « shadow IT » : Les utilisateurs, face à l’urgence et au manque de réactivité du service informatique, peuvent tenter de développer leurs propres solutions parallèles (souvent des tableurs complexes, des macros non sécurisées, etc.), ce qui engendre des risques de sécurité, de cohérence des données, et complique encore plus la maintenance future.
- Provoquer de la frustration : Le personnel se sent moins efficace, non écouté, et la confiance envers le service informatique peut s’éroder.
L’envie d’arranger et de mettre en œuvre
C’est là qu’intervient le désir, souvent bien intentionné, « d’arranger la chose et de mettre en œuvre ». Face aux conséquences négatives du report, il y a une prise de conscience (parfois tardive) que même une « petite » amélioration peut avoir un impact majeur sur l’efficacité opérationnelle et la satisfaction des employés.
Cette prise de conscience peut pousser à :
- Re-prioriser la demande : La « petite évolution » initialement reléguée est finalement considérée comme urgente.
- Rechercher des solutions rapides : On cherche à implémenter la solution avec les ressources disponibles, même si ce n’est pas la plus optimale à long terme.
- Mettre en place des processus plus agiles : Certaines entreprises adoptent des méthodologies qui permettent de traiter plus rapidement les petites demandes, reconnaissant leur valeur cumulative.
En somme, le constat est celui d’une sous-estimation des « petits » besoins informatiques urgents, menant à des complications et une perte d’efficacité, ce qui finit par générer une volonté (parfois tardive) de les adresser rapidement.