Projet d'Appui Conjoint à la Bonne Gouvernance dans les ...

PROJET D’APPUI CONJOINT À LA BONNE GOUVERNANCE DANS LES DOMAINES
DES FINANCES PUBLIQUES ET DE LA STATISTIQUE (PAC)
ADE - ATC Consultants
Une documentation à jour permet le transfert de compétences d’une façon générale. Ne
pas disposer de documentation fait courir le risque de voir une partie de la mémoire
technique et fonctionnelle, c'est-à-dire la compétence informatique du ministère,
disparaitre.
4.1.5 Des logiciels « qui ne marchent pas »
Il est fréquent d’entendre des utilisateurs de toutes organisations dire que « les logiciels ne
fonctionnent pas ». Il est fréquent également qu’il y ait des insatisfactions dans le
fonctionnement d’un service et que la raison invoquée soit le logiciel. Ce sentiment est
tellement partagé par les utilisateurs du monde entier, qu’il est donc vrai que « les logiciels
ne marchent pas ».
Afin de traiter correctement cette question, il faut détailler les causes possibles des
dysfonctionnements des logiciels, puis chercher à catégoriser les problèmes soulevés par les
utilisateurs pour savoir quelle réponse apporter. Les sources potentielles de
dysfonctionnement des logiciels que nous avons identifié sont les suivantes :
1. Dysfonctionnement technique (Bug) : il s’agit d’une erreur manifeste du logiciel qui
« plante »
2. Dysfonctionnement fonctionnel : le logiciel produit une erreur de calcul ou de
traitement d’une procédure.
3. Dysfonctionnement conceptuel : le logiciel fonctionne conformément au cahier des
charges, mais c’est le cahier des charges qui n’est pas conforme au processus métier
(le logiciel n’est pas ou n’est plus adapté, ce qui est par exemple le cas suite à une
réforme qui modifie le fonctionnement d’une procédure)
4. Dysfonctionnement lié à une mauvaise utilisation du logiciel
5. Dysfonctionnement lié à une mauvaise compréhension du logiciel
Il faut savoir qu’en général dans toutes les organisations, une grande majorité des
dysfonctionnements rapportés par les utilisateurs sur les logiciels éprouvés (nous ne parlons
pas ici des logiciels nouveaux qui sont souvent encore très « bugués ») sont de type 4 et 5,
c'est-à-dire que ce n’est pas le logiciel en soi qui doit être remis en cause, mais la formation
au logiciel et l’organisation mise en place pour l’utiliser. A titre d’exemples :
nous avons vu au chapitre « 4.1.3. Absence de contrôle des données et de fiabilité des
chiffres fournis » que le rapprochement bancaire n’était pas fait dans ASTER. Rien ne
permet donc de garantir qu’ASTER contient tous les paiements. Pourtant la
fonctionnalité de rapprochement existe dans ASTER, mais elle n’est pas utilisée. Ce
n’est pas un dysfonctionnement intrinsèque du logiciel ASTER mais une mauvaise
utilisation (dysfonctionnement de type 4).
dans SIGFiP il est possible de produire un état d’exécution budgétaire d’un ministère
par exemple. Lors de la production de cet état, il est possible de ne sélectionner qu’une
partie des lignes budgétaires. S’affiche alors un « Taux d’exécution total » qui est la
moyenne pondérée du taux des lignes budgétaires sélectionnées. Si on produit à
nouveau cet état, mais en sélectionnant d’autres lignes budgétaires, alors ce taux va bien
entendu varier. Cette variation de taux est interprétée par certain comme un manque de
fiabilité des données de SIGFiP puisque le taux d’exécution « varie tout le temps ». Le
problème vient simplement du libellé de l’état, il faudrait que soit affiché « Taux
d’exécution total pour les lignes sélectionnées : » puis une autre ligne avec « Taux
Version provisoire – 10 juin 2011 Page 45