Fichier des Personnes Recherchées (FPR)

Logo FPR

Constat

Deux Fichiers des Personnes Recherchées (FPR) existaient, l’un en Gendarmerie et l’autre en Police. Pour un certain nombre de raisons leur maintien en condition opérationnelle était fortement compromis, à tel point qu’il devenait urgent d’en développer un autre, unique.

Problématique

Les langages utilisés par les deux SI existants m’étaient inconnus et les délais étaient très contraints au vu de leur imminente obsolescence.

Le nombre de parties prenantes était indéterminé mais semblait assez élevé et de nature très variée.

Solution

La solution consistait en la conception depuis une page blanche d’une application unique, trans-institutionnelle, à l’état de l’art technologique pour ne plus dépendre de personne et que des équipes successives puissent prendre le relais pour la faire évoluer l’application au fil des années.

Mise en oeuvre

Il a fallu jeter un dispositif sommaire de début de projet, pour consolider rapidement le processus en composant une équipe élargie et ayant à disposition une plateforme d’intégration continue en mesure de déployer régulièrement des versions incrémentales de l’application.

Mon rôle

Désigné chef de projet, j’ai conçu l’architecture et fait des choix de langages et de technologies, composé l’équipe et distribué les rôles.

Même si ce n’est pas le cas d’usage habitude puisque j’étais plutôt Product Owner (bien qu’également développeur pour certains chantiers…), en plus de ma casquette de chef de projet j’ai été Scrum Master, puisqu’il s’agissait rapidement de guider l’équipe et que le format s’y prêtait.

J’ai animé des réunions avec les fonctionnels afin de disposer non seulement d’entrées permettant de construire un carnet de produit suffisamment précis pour alimenter les développeurs, mais également de faire valider ce qui avait été produit et de déterminer avec eux les orientations qui permettaient aux utilisateurs finaux de disposer de l’ensemble fonctionnalités nécessaires à l’opérationnalité de l’ensemble des institutions.

Je me suis approprié le chantier de la reprise de données, dans la mesure où elles étaient ultra sensibles et que je voulais assurer la confidentialité de l’ensemble des données personnelles contenues dans le fichier.

Difficultés

La rétro-ingénierie sur des langages comme le COBOL ou le GCOS-7 était particulièrement complexe, puisque je ne disposais de quasiment aucune ressource, hormis pour la partie GCOS-7 pour laquelle mon interlocuteur Police Nationale était particulièrement compétent en plus d’être sympathique, ce qui n’enlevait rien au plaisir de travailler avec lui.

Enrichissements

C’est un des projets les plus enrichissants sur lesquels il m’a été donné de travailler, puisque la variété des sujets et des problématiques abordés était tellement vaste qu’elles m’ont donné les armes pour affronter bien d’autres défis par la suite.

Je suis devenu à l’aise sur le sujet des migrations que ce soit de langage ou de données. J’ai d’ailleurs rédigé un retour d’expérience sur la reprise des données du FPR ici.

J’estime avoir eu beaucoup de chance d’avoir été bien entouré, que ce soit par la qualité des développeurs, celle des fonctionnels avec qui j’ai pu travailler, que ce soit en interne Gendarmerie mais également en externe où les collègues policiers étaient d’un grand professionalisme, compétents et motivés dans une construction collective. Je garde d’ailleurs un excellent souvenir de certaines soirées!

Le travail en hybridité était un défi, que ce soit dans le développement, où des gendarmes côtoyaient des prestataires externes, mais également dans le fonctionnel, où j’ai pu collaborer avec de nombreuses institutions et ministères bien éloignés de la Gendarmerie. Je n’oublie pas non plus le sérieux de l’AMOA qui était d’un confort certain.

Un autre enrichissement est le pouvoir de conviction que j’ai dû acquérir afin de faire adopter bon nombre de décisions, à commencer dès le début du projet par mes choix techniques, lorsqu’il a fallu convaincre les chefs du bien fondé du choix de l’open source.

Je n’oublie pas non plus ma rencontre avec celui qui m’a enseigné le Scrum, Étienne Rossignon. Étienne était en avance sur un grand nombre de sujets, et quand je regarde son travail aujourd’hui je mesure la chance que j’ai eu de le rencontrer, tant c’est un puits de savoir, doté d’une pédagogie impressionnante. J’ai compris que dès lors qu’on maîtrise la technique et qu’on dispose d’une équipe solide, le domaine technique n’est pas sur le chemin critique.

Certains étaient étonnés du fait que nous ayons réussi à livrer un système d’information critique, avec une reprise de données intégrale sans erreur, et ce dans des délais respectés. C’est la dernière leçon que j’ai tirée: si le projet est celui d’une équipe et non pas d’une personne, l’intelligence collective permet d’aboutir rapidement à une solution qui convient. Je suis désormais convaincu que l’amélioration continue n’est possible qu’avec un partage des connaissances.