LA REMONTÉE D'INDICATEURS À LA HIÉRARCHIE : UN EFFORT LÉGITIME, MAIS FASTIDIEUX, POUR DONNER DES CHIFFRES DE L'ACTIVITÉ DU TERRAIN SOUVENT PEU FIABLES
Les éléments observés sur le terrain
Les processus de remontée des indicateurs demandés par la hiérarchie sont en général reconnus par tous comme peu performants.
Un processus de demande d'information complexe
Les sollicitations en matière d'indicateurs sont de deux types : organisées et récurrentes d'un côté et ponctuelles et différentes de l'autre. Dans le cas des demandes ponctuelles, l'administration centrale envoie habituellement une note indiquant les éléments qui devront figurer dans un tableau à renvoyer au service central demandeur.
Exemple : un directeur départemental de la Sécurité Publique a expliqué qu'il reçoit régulièrement ce type de demande. Il s'étonne qu'aucun tableau de recueil de l'information ne lui soit transmis avec la note. Il en crée donc un et demande à ses commissaires de le remplir pour leurs districts. Il exige un cheminement électronique. Il effectue ensuite la consolidation avant de renvoyer l'information pour son département à l'administration centrale. Néanmoins, l'administration centrale va recevoir autant de tableaux, dans des formats différents (Excel, Word, papier, autre...) et devra ensuite effectuer une seconde consolidation pour l'ensemble des départements de France - avec les sources d'erreurs inhérentes à une ressaisie.
Exemple : la Préfecture de Police demande également des informations. Dans un commissariat central parisien visité, le processus de renseignement est entièrement manuel. Et le commissariat envoie ensuite un document sous format papier.
Les différents acteurs hiérarchiques de la gendarmerie exigent régulièrement que différentes informations leur soient remontées par les unités de terrain. Pourtant, bien que régulières et formalisées dans une note, ces requêtes font doublon avec d'autres indicateurs existants et multiplient la quantité de travail fournie par les brigades :
Exemple : les brigades du ressort d'une des compagnies visitées, doivent régulièrement envoyer des comptes rendus périodiques dont la grande majorité des informations figure déjà sur les modules BB 2000 transmis quotidiennement :
§ nombre de gardes à vue prises en police de la route,
§ kilométrage transfèrement,
§ comptabilité carburant,
§ violences conjugales,
§ état des dépistages urinaires des stupéfiants sur les conducteurs impliqués dans les accidents mortels de la circulation routière.
Dans le cadre des demandes récurrentes, le processus de remontée n'est pas non plus toujours standardisé. Les raisons sont multiples et proviennent, la plupart du temps, de la faiblesse du parc informatique et de l'absence de réseau.
Exemple : dans un commissariat central, les unités saisissent leur activité dans la Main Courante Informatique (MCI) sur un poste unique. Ensuite, une édition papier est transmise au Bureau d'Ordre et d'Emploi (BOE) qui ressaisit l'information sur son propre poste - le commissariat n'est pas en réseau et la MCI ne permet pas de transmission par disquette.
La gendarmerie compte sur BB 2000 pour obtenir une connaissance précise et fiable de l'activité des unités de terrain, car cette information est saisie directement par des opérationnels puis consolidée après vérification par les échelons hiérarchiques. Mais cet idéal statistique cache un décalage de perception de cet outil entre l'encadrement et les gendarmes de terrain. La réalité en effet est différente.
La fiabilité des données ressaisies n'est pas garantie et accapare les agents
La qualité des informations saisies dans BB 2000 est inégale : le regroupement de l'ensemble des activités par thème n'empêche pas les gendarmes dans leur majorité de méconnaître la nomenclature exacte. Par conséquent, le risque d'erreur apparaît dès l'origine : le doute est permis lorsque la saisie d'une activité donne lieu à différentes appréciations.
Exemple : dans un Peloton de Surveillance et d'Intervention de la Gendarmerie (PSIG), la question s'est posée de savoir comment qualifier la journée de sélection passée par de jeunes Gendarmes Adjoints Volontaires (GAV) afin de devenir militaires de carrière. Le choix finalement retenu pour le service sera « concours commandement », dont l'adéquation avec la véritable nature de l'activité laisse un doute.
Une information aussi simple et essentielle que le nombre d'heures de travail réalisées par une brigade peut également faire l'objet d'un doute quant à sa fiabilité dans les périodes estivales où l'activité de certaines brigades observées peut augmenter considérablement. Le renfort de gendarmes mobiles, voire de réservistes, n'est pas toujours pris en compte dans les données de certaines brigades. L'intégration de ces effectifs, souvent changeants, dans les statistiques nécessite en effet différents paramétrages (BB 2000, registre des procès-verbaux, registre du courrier, etc...) qui augmentent le risque d'erreurs de saisie mais aussi de pertes de données.
Dans la police, cette absence de fiabilité provient également de l'utilisation de la Main Courante Informatique (MCI) qui demeure très imparfaite : les agents n'arrivent pas à rapporter correctement leur travail dans les 166 catégories. A Paris, la Main Courante Informatique (MCI) n'est même pas installée ; tout se fait sur des registres papiers.
En tout état de cause, quel que soit le mode de saisie, le renseignement de l'activité d'une brigade ou d'une patrouille à l'issue de son service produit, très souvent, une forte déperdition de renseignements. Le chef de brigade ne pourra légitimement pas se souvenir, en fin de service de l'ensemble de l'activité de son unité à la demi heure près.
Un commissaire central interrogé a estimé que toute utilisation du Test d'Emploi des Policiers (TEP) - issu de la Main Courante Informatique (MCI) - est donc toujours sujet à caution.
Exemple : on peut noter d'ailleurs une certaine absence de fiabilité du Test d'Emploi des Policiers (TEP) dans l'un des commissariats visités. Les données enregistrées dans la Main Courante Informatique (MCI) ne correspondent pas à l'activité réelle de l'unité. Il s'agit de celles demandées dans la feuille de service qui apparaît lors de l'ouverture de l'application au moment de la prise de service, en début d'activité de l'unité. Le Test d'Emploi des Policiers qui en résulte est dès lors nécessairement fortement erroné dans la mesure où il est rare que la brigade puisse suivre parfaitement la feuille d'emploi : durant son activité, elle sera nécessairement intervenue en renfort des unités de roulement par exemple ou bien pour un transfèrement programmé en dernière minute.
Par ailleurs et dans la mesure où ces informations sont issues de systèmes différents, non interfacés entre eux et non connectés en réseau, de nombreuses doubles et triples saisies sont observées. Ces multiples saisies entraînent inévitablement des erreurs de saisie et faussent les données finales, telles que celles de l'état 4001.
La fiabilité de l'indicateur 4001 peut être en effet questionnée
L'état 4001 n'est pas non plus très fiable. Il est renseigné dans l'application STIC par un service la plupart du temps composé d'agents administratifs. Leur travail consiste à prendre les procédures saisies dans LRP pour leur donner un code dans la nomenclature 4001. Ces agents ne connaissent la plupart du temps pas l'affaire et n'ont aucune formation juridique. Leur saisie n'est donc pas toujours fiable. Cet état, alimenté également par les données issues de la gendarmerie, souffre aussi de la perte d'information observée soit au cours de la transmission des statistiques par les brigades, soit au moment même de leur consolidation.
La diversité des tableaux d'activité est rarement une garantie de fiabilité, ni même celle d'une vision complète et efficace de l'activité des unités. La première explication tient dans la perte en ligne observée à chaque fois qu'il y a fractionnement d'une information.
Exemple : le Bureau d'Ordre et d'Emploi (BOE) d'un des commissariats visités traite de façon répétée un certain nombre de données identiques : les heures supplémentaires des agents sont d'abord mentionnées sur une feuille d'emploi qui remonte chaque jour au BOE, à partir des informations saisies par ces derniers sur la Main Courante Informatique (MCI). Elles sont par la suite saisies sur le registre P4 mensuel (registre obligatoire du service) puis une nouvelle fois dans GEOPOL avant d'être reprises dans un état mensuel qui sera contrôlé en fin de mois par les différents chefs d'unité du commissariat.
Des états obligatoires renseignés dans des outils informatiques différents
Les commissariats de police doivent tenir un certain nombre d'états obligatoires relatifs à l'activité de l'unité. Ces états portent aussi bien sur l'activité de chaque fonctionnaire que sur ses périodes d'absence ou sur le nombre de faits élucidés par exemple.
Dans la police, une même information peut avoir à être saisie plusieurs fois dans la mesure où les principales applications existantes (MCI, LRP, GEOPOL et STIC) ne sont pas interfacées.
Exemple : quand un fonctionnaire de police est absent, cette absence est saisie dans la Main Courante Informatique (MCI) ainsi que dans GEOPOL. Lorsqu'une patrouille interpelle un individu, elle doit le mentionner dans la Main Courante Informatique (MCI) puisqu'il s'agit d'une intervention. Elle saisira ensuite la procédure dans LRP. Un service prendra ensuite la procédure sous format papier pour intégrer le fait dans le STIC qui alimente l'état 4001.