Après une prise de connaissance du contexte du projet, nous avons ****proposé trois scénarios d’accompagnement :

• 1er scénario : un développement de l’application par Numéricité, avant transfert des codes sources à la DGI pour que cette dernière se charge de la maintenance et des évolutions du produit en autonomie.
• 2ème scénario : un développement de l’application par Numéricité, suivi de formations et d’une montée en compétences des agents de la DGI afin qu’ils soient capable de prendre en main l’application dans son entièreté.
• 3ème scénario : l’utilisation du développement de l’application mobile comme “prétexte à la transformation”. Elle servirait de cas d’usage pour former les équipes de la DGI à la programmation et à l’algorithmie. Ainsi, l’application serait in fine développée par les agents, avec l’appui de Numéricité. Cette méthode est la plus efficace pour assurer une montée en compétence et favoriser l’adoption d’une culture numérique au sein de l’organisation, mais nécessite une très forte implication de part et d’autre.

Du fait du contexte haïtien, en proie à des tensions internes et une crise sécuritaire, c’est finalement le 2ème scénario qui a été retenu. Nous avons procédé en plusieurs étapes :

• L’application demandée par la DGI est-elle la meilleure solution pour répondre aux besoins des agents ?

Chez Numéricité, il est de coutume de réinterroger le besoin exprimé par nos clients. Il arrive régulièrement que ce besoin nous soit partagé sous forme de solution : “il nous faut une plateforme / un portail / une application”. Une solution n’est jamais un besoin. Dans le cas haïtien, la problématique réelle était que les agents avaient du mal à consulter, ranger et rechercher des dispositions fiscales. L’entrée en vigueur du nouveau Code fiscal a apporté un premier élément de résolution en centralisant la législation en une source unique.

Mais pour répondre à l’irritant, une application mobile était-elle vraiment adaptée ? Si oui, fallait-il plutôt opter pour une application web ou native ? Après avoir pesé le pour et le contre, l’idée de développer une application web progressive, aussi connue sous le nom PWA **(**Progressive Web App), a semblé constituer la meilleure option. La particularité d’une PWA est qu’il s’agit d’une application comme on l’entend au sens courant, mais exécutée sur un environnement web, donc depuis n’importe quel navigateur ordinateur, mobile ou tablette.  Ce “site web” peut par ailleurs, comme n’importe quelle application, être installé sur tout appareil, offrant ainsi un accès hors-ligne nécessaire dans le contexte d’Haïti (multiples coupures Internet quotidiennes).

• Comment transformer le Code fiscal, compréhensible par un humain, en une donnée exploitable par un système informatique ?

Nous disposions d’une version PDF du Code fiscal, soit un format textuel, adapté et lisible pour les humains mais totalement inadapté pour un traitement informatique. La première étape a été de convertir ce PDF peu exploitable en un document Word. S’agissant d’un texte juridique, le Code doit respecter un certain formalisme, notamment quant à la hiérarchisation des contenus : ce formaliste devant se retrouver dans l’application, il convenait de faire en sorte que l’ordinateur puisse reconnaitre tous les découpages du texte, divisé en livres, parties, sections, chapitres ou autres subdivisions inférieures, jusqu’à en arriver aux articles et aux alinéas.

À l’aide du langage Python, parfaitement adapté aux tâches de scripting, nous avons pu structurer les données provenant du fichier Word, préalablement converti en HTML et analysé en amont, de façon plus logique. Sur cette base, nous avons défini des “schémas” pour détecter le début et la fin de chaque type de subdivision dans le contenu : un chapitre, par exemple, commençait toujours par l’expression “Chapitre X : ” dans une balise HTML “<b>”, ce que nous détections via une regex (expression régulière) et s’achevait soit au début du chapitre suivant, soit au début du titre suivant (pour le dernier chapitre d’un titre). Cette étape a nécessité un étude approfondie du document initial mais s’est avérée nécessaire et très utile pour l’avenir : en cas de modification du Code fiscal, il suffira d’exécuter le script sur la nouvelle version du texte pour mettre à jour le contenu de l’application en un clin d’oeil.

• Comment rendre l’application utilisable et utilisée ? Design et fonctionnalités

Nous avons fait appel à notre UX/UI designer afin de créer les maquettes des différents écrans de l’application à l’aide de Figma, sur la base des entretiens utilisateurs menés avec plusieurs agents métiers de la DGI. Les maquettes s’appuient sur les fonctionnalités attendues par le Directeur général des Impôts et les agents, à savoir la recherche, l’enregistrement de favoris, le partage de résultats et le réglage des modes d’accessibilité.

La phase de réinterrogation du besoin a permis d’éclaircir certaines fonctionnalités, et d’en mettre d’autres de côté. Ainsi de l’authentification, par exemple. L’application étant conçue comme un outil métier, la DGI souhaitait n’en permettre l’accès qu’à ses agents. Cette solution aurait nécessité la création et le maintien à jour d’une base de données d’utilisateurs, et l’ajout et la suppression réguliers de droits pour les nouveaux agents ou ceux ayant quitté l’organisation. Or, le Code fiscal étant un texte de loi, public, accessible à tout citoyen. Après discussions avec l’équipe projet, l’exigence d’authentification a finalement été mise de côté, dans la mesure où elle ne répondait à aucun besoin spécifique et ne présentait pas non plus d’intérêt technique à réaliser.

• Comment formater les données pour les intégrer à la PWA ?

Une fois les données mises en forme (JSON), nos développeurs ont implémenté les éléments issus de ce “scraping” sur le site web, en construisant une interface utilisateur sous Next.js. L’application en elle-même n’est qu’une mise en forme, dans des écrans intuitifs et compréhensibles par des humains, du JSON créé à l’étape précédente, fourni en intrant à l’interface Next.js que nous avons développée. Une première version de l’application mobile a ainsi pu être présentée à la DGI, sur laquelle nous avons itéré pour la rendre aussi simple d’utilisation que possible. Une fois le contenu correctement formaté, entre les livres, chapitres, titres et autres, il a été possible de développer l’affichage sur la base des maquettes établies par notre UX/UI designer.

Après 2 mois de développement, nous avons enfin pu déployer l’application sur un domaine .ht créé pour l’occasion, procédé à la formation de 10 agents de la DGI (eux-mêmes chargés de former 10 agents, eux-mêmes chargés de former 10 agents…) pour garantir la prise en main de l’application, fourni un guide d’utilisation et d’installation destiné à favoriser l’autonomisation des équipes.