Interface de production

Dans le cadre d'une collaboration fructueuse entre mon ancienne école et une entreprise éminente dans l'horlogerie, j'ai été investi de la mission prestigieuse de mettre en place une solution centralisée, à même de cataloguer avec brio les projets de développement.

Pour faire court, cette entreprise recevait des propositions de diverses natures, émanant de multiples canaux : courrier postal, fichiers PDF, courrier électronique, pour n'en citer que quelques-uns, et ce, en provenance de deux départements distincts. Cela impliquait que les efforts et les idées de ces projets demeuraient souvent cloîtrés dans les recoins des bureaux ou perdus dans les méandres des boîtes de réception.

Il en résultait que ces projets, malheureusement, échappaient à toute quantification, identification ou traçabilité au niveau du comité de direction.

Mon dessein primordial consistait à insuffler une visibilité nouvelle à ces projets par le biais d'une interface éclairée.

Dans ce tour de force, j'ai dû m'immiscer avec agilité au sein d'une équipe pluridisciplinaire, forte de huit talents, qui se guidait par la méthodologie agile "SCRUM" pour orchestrer et superviser ces projets.

D'un point de vue fonctionnel, la solution en question devait :

• Compiler de façon exhaustive les projets en développement (en puisant dans les données fournies par SAP)

• Offrir des fonctionnalités de tri et de filtrage fluides

• Actualiser l'affichage selon des intervalles temporels prédéfinis

Pour atteindre ce but, j'ai dû me former avec diligence et maîtriser C# WPF (un outil pour créer des interfaces graphiques hautement personnalisables pour les applications .NET), apprendre à manier l'outil de gestion des versions qu'est GitHub, appréhender les subtilités de SAP et manier habilement les BAPI (interfaces de programmation applicative métier permettant d'accéder aux données de SAP) depuis ma propre solution.

Avec les résultats qui ont émergé au fil du projet, le cahier des charges initial de l'entreprise a évolué, donnant ainsi naissance à deux versions distinctes de l'application :

• La première version se concentrait sur la mise en lumière des données (objectif originel du projet)

• La seconde version a fait muter l'application en une solution de suivi de l'avancement des projets doublée d'une capacité de configuration poussée de l'affichage

L'entreprise s'est dotée d'un écran tactile spacieux pour ce projet, un choix judicieux qui s'est avéré très pratique étant donné que l'application a éventuellement évolué en un instrument de pilotage pour la progression des projets.

Dans ce cheminement, ce qui s'est avéré complexe fut le défi de développer une application sans disposer d'une vision précise des données à manipuler. Le chef de développement lançait avec assurance : "Codons selon notre intuition." Cette approche parfois casse-cou nous a contraints à parfois abandonner des fonctionnalités que nous avions peaufinées durant de longues heures... Quelle situation !

J'ai également découvert l'importance cruciale du temps de traitement des données. Alors que dans mes projets antérieurs je n'avais pas à traiter plus de cent lignes de données, dans ce projet-ci, j'ai brassé des milliers de données. La différence s'est manifestée de manière tangible une fois que j'ai mis au point mon algorithme sophistiqué, destiné à afficher les données filtrées à partir de l'application, hélas, lors de l'ouverture de l'application, lorsque celle-ci se mettait à charger les données, j'étais confronté à une attente de vingt secondes pour cinq cents données affichées, pendant ce temps l'application se figeait momentanément.

La solution salvatrice a été de déplacer l'opération de filtrage des données directement dans les BAPI, cette approche s'est avérée plus simple et a allégé considérablement la charge de code.

Malgré l'idée de mettre en place un système de threads pour afficher les données dès qu'elles étaient disponibles, le temps et l'urgence en entreprise ont orienté nos choix différemment (nota bene : je n'ai toujours pas pu mettre en place les threads dans mes applications (: ).

À la conclusion du troisième mois de développement, le projet touchait à sa fin : les fonctionnalités requises étaient incorporées. Bien que quelques ajustements fussent nécessaires, l'application était globalement prête à être soumise aux tests des utilisateurs finaux.

J'ai pris grand plaisir à œuvrer au sein de cette équipe de projet. Alors que j'avais généralement travaillé en solitaire ou en binôme auparavant, cette expérience m'a permis de sortir de ma zone de confort, une expérience tout simplement enrichissante.

Certes, j'aurais souhaité davantage m'investir dans la gestion de projet et interagir directement avec le client final, mais ma mission était résolument axée sur le développement de la solution.

En fin de compte, en moins de trois mois, mon équipe de projet et moi avons pleinement répondu aux exigences posées. Le fruit de notre travail fut présenté au comité de direction, qui à son tour a partagé ce projet avec les autres entités du groupe.