Pour une entreprise du CAC40 présente dans 68 pays comptant 170 000 collaborateur·rice·s, nous avons créé et développé une app centralisant l’ensemble des métiers de la finance au sein de cette entreprise multinationale : pour chacun d’entre eux sont listées les offres d’emploi, compétences et formations correspondantes. Elle présente également le parcours professionnel et les évolutions de carrière au sein du groupe.
Toutefois, cette app était figée et non-administrable par les collaborateur·rice·s IT en interne. Il a donc été rapidement nécessaire de créer une seconde app – un back-office – afin qu’ils·elles puissent gérer la base de données et modifier le contenu de la première (ajouter de nouveaux métiers, compléter les compétences et formations…).
Comment avons-nous abordé et travaillé sur ce projet ? Quels en ont été les enseignements ? Éric Bauman, développeur à la Factory chez Saegus, vous raconte.
Un défi technique
Le back-office a été pensé comme une app à part entière. La base de données est commune entre les deux applications. La première application étant internationale, le back-office devait donc être pensé en plusieurs langues – nous l’avons pour l’instant développé en français et anglais, l’objectif étant d’ajouter de nouvelles langues dans le futur. Cela entraîne un défi technique : penser différemment la base de données. Pour chaque langue, nous avons créé une table distincte pour les métiers, compétences et formations.
La maquette du back-office, designée par l’équipe de la Factory, était assez complexe à développer : il y avait beaucoup d’éléments très customisés, rendant leur intégration complexe. Par exemple, les listes déroulantes ont un style par défaut qui n’est pas modifiable ; il nous a donc fallu recréer une liste déroulante à la main, ce qui prend forcément plus de temps. Ce type de problème s’est posé sur plusieurs fonctionnalités de l’application.
Dans cette application, le menu permet de naviguer parmi tous les types de données que les administrateur·rice·s peuvent ajouter, modifier ou supprimer :
Les univers (“universes”), qui sont des sous-domaines de la finance ;
Les métiers (“jobs”) ;
Les compétences (“skills”) ;
Les formations (“trainings”) ;
Les évolutions de carrière (“career paths”).
Par exemple, pour modifier un univers, l’utilisateur·rice arrive à partir du menu sur un écran permettant de sélectionner un univers existant ou d’en ajouter un nouveau. Dans les deux cas, un formulaire contenant tous les attributs d’un univers s’affiche, permettant de le personnaliser en modifiant chaque champ. Cette fonctionnalité est la même pour tous les types de données.
Les métiers ont pour particularité d’être reliés aux formations, compétences et profils inspirants : des onglets permettent de naviguer parmi ces attributs et de les lier au métier sélectionné.
Nous avons utilisé Angular pour le front, en framework JavaScript ; Node.js et NestJS pour le backend ; et PostgreSQL pour la base de données. L’app est hébergée sur Azure.
Une app née de la collaboration
Au sein d’un projet de cette envergure, la relation avec le client est essentielle. Nous avons organisé plusieurs ateliers pour bien comprendre les besoins (parcours utilisateur, interactions) et avoir une image d’ensemble de l’interface à créer. Dans ce cadre, le client est un véritable collaborateur du projet ; les daily meetings et méthodes agiles, permettant d’avancer par itérations, sont clés pour pouvoir échanger. C’est aussi un moment au cours duquel le client peut tester les features une à une, permettant d’ajuster l’app au fur et à mesure. Sinon, le test unitaire est une bonne pratique : les lignes de test sont enregistrées et rejouées à l’ajout de chaque nouvelle fonctionnalité, automatisant les tests. Il convient de noter que cela demande du développement supplémentaire, mais fait gagner du temps à terme.
Il est essentiel que les designers et développeur·se·s travaillent en collaboration. Pour ce projet, pendant la création de la maquette, nous avons beaucoup échangé sur la faisabilité technique du front imaginé.
Après une livraison de la première version, nous avons fait des changements mineurs sur la base du retour client. Comme nous l’avons vu, l’app est pensée pour que l’on puisse y ajouter des langues supplémentaires à l’avenir, ce qui devra être fait par un·e développeur·se.
Conclusion
La gestion de projet et celle d’équipe se sont rencontrées au cours de ce projet. Une mission de cette envergure demande de la rigueur et du cadrage, ainsi qu’une collaboration régulière entre toutes les parties prenantes (client, métiers, designers). Nous sommes fier·ère·s de ce projet qui est une belle réussite.
Vous souhaitez vous aussi être accompagné·e·s par nos équipes de la Factory ? Contactez-nous !
Rédigé par Éric Bauman, Développeur à la Factory