Comment j’ai construit une plateforme BI from Scratch sans me suicider.
--
Qui suis-je d’abord ?
Avant tout, Salut l’astronaute !
Moi c’est Orbit Turner (Mohamed GUEYE de mon vrai nom) je suis un jeune passionné de la technologie, de l’automobile et de design.
J’ai commencé à toucher à mes premières lignes de code quand j’avais 11 ou 12 ans et depuis lors j’ai suivi pas mal de Roadmap en autodidacte mais aussi à travers mes différentes formations avant de finir par devenir un développeur Fullstack en fin 2020 puis DevOps actuellement.
CONTEXTE
Tout a commencé en début 2021 où j’ai été contacté par une entreprise Française basée au Sénégal qui cherchait un développeur Fullstack qui pourrait répondre à leurs besoins internes.
Après un long processus habituel ainsi que des tests bizarres j’ai pu rejoindre le vaisseau qui a plus de 17 ans d’existence et près de 600 employés ainsi qu’une infrastructure informatique énorme et complexe.
Ma mission initiale était de proposer un outil capable de suivre et de gérer le workflow du département chargé d’un des clients de la boîte.
Il faut comprendre que l’entreprise est un centre d’appels émetteur c’est à dire un centre de contact clients Télévente, Enquêtes et Prise de rendez-vous B2B. Ce qui fait que les clients sont souvent de grandes boîtes télécoms françaises ou autres qui nécessitent des métriques (Statistiques d’appels (DMC, nombre de contacts argumentés, contacts positifs, taux de concrétisation, ventes/fiches livrées, taux de pénétration, attente moyenne, first call résolution, …): en temps réel, par heure, jour, semaine, mois et par téléconseiller / équipe, Tris partiels, suivi des KPI et quotas en cours de terrain, Edition et envoi du suivi terrain — Reporting automatisé quotidien) et un workflow très spécifique et intensif.
Du moment où j’ai pris connaissance des besoins et une fois mon intégration terminée, le syndrome de l’imposteur s’est installé et je me suis dit : “bah, frère, là, tu es dans la merde jusqu’au cou !”.
LES PROBLEMES
Ah bah là ils étaient nombreux 😨!
- L’entreprise pour la plupart de ses outils, est sur du Python 2.
- L’entreprise a une pléthore de Serveurs de Base de données avec une cinquantaine de bases dans chaque serveur ainsi que des millions d’enregistrements tout aussi sensibles.
- L’entreprise veut, en plus d’automatiser certains traitements manuels, avoir une visibilité totale et en temps réel de ce qui se passe. Ventes, temps d’appels, heures badgées, rentabilités, prévisions etc. Ce qui veut dire extraire, transformer et visualiser des rapports très épurés des millions de lignes d’informations éparpillées en moins d’une seconde.
- L’entreprise appelle çà un “OUTIL”. 😭😫
- POUR COURONNER LE TOUT, J‘ETAIS LE SEUL DEV 👨🏾🦯
FACE A L’UNIVERS
J’avais une semaine pour proposer un plan d’action et le “Thinking’” d’une solution.
Mon syndrome de l’imposteur me disait de faire comme tout ceux qui sont passé avant moi c’est-à-dire : ME CASSER !
Mais la part sadique en moi celle que j’appelle “Shadow” s’est pointé avec un sourire narcissique en me disant : “Tu sais très bien que t’aimes ce genre de truc. On ne vit qu’une fois ! Alors ne réfléchis même pas. Fonce et casse-toi la gueule avec fierté”. 😫
Oui, comme un idiot, j’ai sauté la tête en première !
Les deux premiers jours comme tout le monde j’étais déjà dans mon bureau à penser aux entités, à comment gérer plusieurs BDD sans tout faire péter, à la Tech Stack, au déploiement, à Docker, aux microservices, au Big O Notation etc.
Mais, comme à chaque fois que je suis face à un nouveau défi de taille, j’ai pris le temps de me retirer et de penser en dehors des limites.
THINKING OUT OF THE BOX !
Depuis toujours j’ai été quelqu’un qui aime aller vite en prenant des raccourcis ou en utilisant ce qui existe déjà. Je refusais toujours de faire une chose deux fois car j’automatisais tout ce qui pouvait l’être.
‘C’est simple non ?’
NON ! Ce n’est pas aussi simple car au fil du temps, des projets et personnes rencontrées on finit par détecter rapidement ceux qui sont faits pour résoudre des problèmes et ceux qui sont faits pour coder. Pour ma part voici comment j’ai pu faire face à mon problème.
REDEFINIR LES BESOINS !
Un projet est toujours la définition du besoin de quelqu’un et quand une personne vous fait part de ce qu’il veut c’est évident qu’il dira tout ce qui lui passe par la tête.
Ce qui différencie un projet de dev pour une entreprise et un projet de dev pour un client lambda, c’est que bien souvent l’entreprise veut, comme elle le surnomme, “un outil à tout faire” qui leur permet de travailler et de gérer leurs différentes opérations mais la différence réside dans le fait que cet outil n’a souvent pas de date de livraison ou de version finale. Aussi bien que l’entreprise vivra l’outil grandira.
Donc l’étape cruciale a été de dire à notre DSI: “Ok cool ! Je vois ce que vous attendez de moi. Maintenant, on commence par quoi ?”.
Cela paraît banal mais redéfinir les besoins c’est tout d’abord redécouper le besoin en plusieurs petits blocs puis les organiser par priorité. Oui, çà a un nom, c’est être : AGILE!
Ensuite l’étape suivante était de revoir, avec un grand recul, l’évolution sur le long terme et d’en déduire la nature même de ce qui sera réalisé.
Il faut savoir qu’en fonction des premières demandes j’ai cru qu’il s’agissait d’un ERP. Alors il fallait même si je savais c’était quoi un ERP, le redéfinir clairement et le comparer aux besoins.
Selon Oracle un ERP est :
Un type de logiciel que les entreprises utilisent pour gérer leurs activités quotidiennes telles que la comptabilité, les achats, la gestion de projets, la gestion des risques et la conformité, ainsi que les opérations de supply chain. Une suite ERP complète comprend également un logiciel de gestion de la performance (EPM) qui aide à planifier, budgétiser, prévoir et générer un rapport sur les résultats financiers d’une entreprise.
Cependant même si plusieurs modules du projet se rapprochaient de çà, ce n’était pas autant un full ERP. La partie analyse, métriques et suivi était beaucoup plus importante. Sachant aussi que la boîte avait déjà un ERP gérant tous les départements et que ses données à lui aussi seront intégrés dans la nouvelle plateforme.
Alors en faisant le dossier technique qui étudie en profondeur certains aspects des besoins et des départements pour lesquels l’outil allait être mis en place on se rapprochait de plus en plus d’une plateforme, et pas n’importe laquelle !
Une Plateforme de Business Intelligence !😫
Mais c’est Quoi réellement le BI ?
Alors, Selon encore Oracle 😅:
La Business Intelligence (BI) est un processus technologique d’analyse des données et de présentation d’informations pour aider les dirigeants, managers et autres utilisateurs finaux de l’entreprise à prendre des décisions business éclairées. La Business Intelligence englobe une grande variété d’outils, d’applications et de méthodologies qui permettent aux organisations de collecter des données à partir de systèmes internes et de sources externes. Ces données sont ensuite préparées pour l’analyse afin de créer des rapports, tableaux de bord et autres outils de Data Viz pour rendre les résultats analytiques disponibles aux décideurs et aux opérations.
I GOT IT 🔥 C’est de çà qu’ils ont besoin !
Oui c’est vrai Aujourd’hui, les entreprises s’appuient sur les logiciels de Business Intelligence pour identifier et extraire des informations précieuses des grands volumes de données qu’elles stockent. Ces outils permettent d’en tirer des informations tels que des veilles concurrentielles et les tendances du marché, ainsi que des informations internes telles que trouver les raisons des opportunités perdues, etc.
Cette étape est ce qui a permis de bien comprendre la direction à suivre ainsi que l’état d’esprit à avoir.
Bien que cela fait plusieurs années maintenant que je suis dans le développement, je n’ai jamais eu à faire ce genre de truc ni eu ce genre de responsabilité d’être celui qui allait jeter les bases d’un si grand projet. Mais je me sentais capable de le faire au fond alors j’ai pris mes boules à deux mains et j’ai commencé les travaux.
LE JEU DU LEGO
Il y a une loi que j’affectionne particulièrement. Celle de Gall.
La loi de Gall explique pourquoi le prototype et l’itération sont des méthodes de création de valeurs qui fonctionne bien. Au lieu de créer un système complexe en partant de zéro, il est beaucoup plus facile de construire un prototype.
La raison principale en est qu’un système complexe est constitué d’une quantité importante de paramètres et de dépendances. C’est la logique du mouvement Lean-Startup avec la création puis l’amélioration d’un MVP.
Je ne me suis pas dès le départ dit que j’allais construire une plateforme BI. Je ne me suis pas dit que j’allais créer un système hyper performant avec du load balancing, du caching, et des optimisations sur tout etc.
J’ai commencé par la construction d’un squelette rigide qui me permettrait en avançant de placer mes blocs sans fragiliser la structure. Les décisions du départ ont été les clés de la suite.
L’ARCHITECTURE
Au départ j’étais là à me faire toutes les architectures possibles du monde BFF, Microservices, Micro-Frontend, etc.
Mais vous comprendrez bien que Rome n’a pas été fait en un jour. À cause de notre passion nous sommes bien souvent sous la “hype” de vouloir utiliser ou tester tout ce qui sort. Mais ces solutions s’appliquent à des problèmes spécifiques. Si les FAANG ou GAFAM sortent tout le temps de nouvelles architectures, frameworks, etc.; ce n’est pas par volonté mais par nécessité. Les noms viennent souvent bien après. Au cours de ce projet j’ai eu à faire certains choix, certains tweaks et résoudre certains problèmes avant de me rendre compte qu’il y avait un nom pour çà.
J’ai commencé le projet avec une architecture distribuée pour, en progressant et au fil des besoins pouvoir tendre vers de l’extrême ‘Segregation of Principle’ en faisant du MICRO MICRO 😂
FRONT-END FIRST
“C’est une Blague 😨?!”
Non ! Le premier défi et le plus grand bien sûr était côté backend.
‘Comment me connecter à toutes ses bases et réunir toutes ces données ?’
C’était une question à laquelle je n’avais pas encore de réponse mais je suis quelqu’un qui aime bien, comme je vous l’ai dit plutôt, aller vite. Vu que tous les yeux étaient rivés sur moi il fallait que je me montre à la hauteur et quoi de mieux que du bluff 😏.
Que ce soit en entreprise ou dehors ce que voit les utilisateurs et les demandeurs c’est le front. Alors je ne pouvais pas passer une semaine de plus à dire que je faisais des recherches. Vu que je suis très à l’aise avec le design, j’ai commencé à directement faire l’intégration de ce que j’avais faits comme mockup et proto avec ANGULAR afin que mon DSI ait au moins quelques choses à se mettre sous la dent entre-temps.
J’ai dû dès le départ déployer dans l’un de nos serveurs en interne une version de l’application et mettre en place un pipeline de CI/CD afin que chaque 02 ou 03 jours, ils puissent suivre les évolutions avec fierté.😂
Oui j’ai choisi Angular en front et les raisons étaient nombreuses. À mon avis quand on parle de projet d’entreprise, de plateforme ou d’outils de gestion c’est le meilleur choix en matière de technos JS. Son architecture orientée scalabilité, sa maturité, sa structuration et sa stabilité font qu’il facilite l’uniformisation et l’évolution de la solution construite.
J’ai l’habitude de dire que Angular est dans les technos JS ce que JAVA est face aux autres langages. Il est strict et puissant et très orienté scalabilité.
Cependant ce n’est pas à cause d’Angular que la plateforme est devenue ce qu’elle est. Angular, React, Svelte, Vue, Laravel ce sont tous des outils !
Comme ce qu’est un crayon dans la main d’un architecte. C’est à cette main d’en faire un excellent usage et d’en créer un joyau.
En une semaine j’avais déjà le login, l’accueil ainsi que plusieurs composants UI qui rendait le projet très facile à assembler.
Dès le départ j’ai voulu trouver des raccourcis très efficaces et évolutifs. Après la redéfinition des besoins j’ai su qu’on aura beaucoup de ‘Data Visualisation’ sur la plateforme ainsi je me suis orienté vers les Suites ou bibliothèques de composants UI tels que Syncfusion, KendoUI, PrimeNG, etc.
En général un seul suffit. Une fois le choix effectué, c’était autour du UI crafting. Je passais plusieurs jours à créer des composants réutilisables permettant à la demande de créer une interface, page ou module rien qu’en les appelants et les paramétrant.
FRONT ARCHITECTURE & CODING CONVENTION
En commençant le projet j’ai su que j’aurais tôt ou tard besoin de prendre plus de gens avec moi pour aller plus vite. Mais il fallait que ces gens en arrivant comprennent facilement et rapidement comment est structuré le projet et comment y contribuer.
Ainsi j’ai fait un document définissant les conventions de codage par rapport à Angular au niveau de la boîte. C’est un document d’environ 15 pages mis à la disposition de tous les gens de l’IT et les nouveaux dev tel que l’incroyable Ababacar Diene Ndiaye qui à su prendre la relève avec succès.🔥
En voici un p’tit aperçu.
ARBORESCENCE DES DOSSIERS
Nous appliquons l’arborescence de base d’un projet Angular. Cependant le dossier src qui contient toutes les fonctionnalités de l’application nous l’avons organisé comme suit :
Comme vous pouvez le voir on a créé certains dossiers afin de faciliter la lisibilité du projet.
LE DOSSIER COMPONENTS
Le dossier component contiendra toutes les vues et composants UI du projet. Nos applications la plupart du temps utiliserons un système de Module Séparation (Voir ici) alors ce dossier sera organisé
comme suit :
Ui-elements
On y mettra tous les composants unitaires qui pourront être utilisés un peu partout indépendamment du module. Par exemple : un DataGrid, Un Graphique, Chart Generator, Les Exporters, un bouton, une Card, un Modal, etc.
Layout
On y mettra tous les composants qui constituent notre “Theme Styling” et les différents Modules de l’application. Par exemple : Module Admin et son theme, Navbar, Module Générale, etc.
View
Dans ce dossier on trouve toutes les pages/vues du site organisées en sous-dossier en fonction des modules auxquels elles appartiennent. Ces vues seront rattachées aux ChildRoutes prévu afin qu’elles passent par leurs modules respectifs lorsqu’elles sont appelées.
LE DOSSIER CONFIG
Dans ce dossier on trouve tous les fichiers de configuration globale de l’application en cours. On y mettra par exemple : les liens vers le backend, la langue par défaut, l’état de l’appli en debug ou en prod, etc.
LE DOSSIER HELPER
En plus de l’architecture orientée Composant d’Angular j’applique ce que j’appelle une ‘Micro-Architecture orientée Helpers’. On peut considérer les helpers comme des providers qui permettent à plusieurs modules de partager ou d’utiliser un moteur de traitements afin d’éviter la duplicité de code.
Pour ne pas surcharger le fichier “components.ts” d’un composant quand celle-ci nécessite de faire certains traitements, on lui crée un Helper ce qui permet même dans le futur si un autre module a besoin de ce traitement ou de ces données il n’appellera que l’helper.
LE DOSSIER MODELS
Comme son nom l’indique il contiendra toutes les interfaces (types) de notre système si besoin en est.
LE DOSSIER MODULES
Ce dossier contient tous les composants complexes formant à eux seuls un mini-système isolé. Exemple : le module de notification, le Logger du système, l’encoder (afin de compresser ou de crypter certains payloads parfois), etc.
Euh…😑 dès que j’ai pas de nom pour un package ou un utilitaire que je crée, je le préfixe par ‘Orbit’ c’est pas par narcissisme 😂😂😂.
LE DOSSIER ERROR
Dans ce dossier on trouve les pages d’erreurs ainsi que le module de gestion d’erreur. Ce dernier permet d’intercepter, d’étudier et de gérer toutes les erreurs de notre application. À la fin de chaque journée les logs sont regroupés puis envoyés en Base afin de nous permettre de les étudier.
Exemple de logs en base :
LA SECURITE & LE MONITORING
La sécurité est l’un des aspects les plus importants de l’application. Voilà pourquoi nous disposons d’un “encoder / decoder” en front et Back car aucune des informations qui transite entre nos applications n’est mis en clair (Oui même le token 😂).
Surtout les quelques infos sauvegardées dans le LocalStorage bien qu’il ne soit pas sensible nous les encryptons puis les compressons afin de les rendre illisibles pour les humains 😅 ou hors de l’appli.
En plus notre Encoder nous permet de pouvoir avoir plus d’infos dans les paramètres de certaines de nos requêtes GET tout en gardant celle-ci très courte.
___
Nous avons aussi différents helpers de monitoring et de suivi qui nous permettent d’avoir toutes les infos sur les utilisateurs ainsi que leurs actions afin de mieux suivre l’appli ou d’éviter certaines fraudes ou réclamations mensongères😂. Exemple ci-dessous les utilisateurs peuvent avoir des infos plus poussées sur leurs IP privé dans notre réseau (différent de l’ip publique) ainsi que d’autres infos qui peuvent aider l’équipe SI à intervenir rapidement en cas de nécessité:
Pour l’authentification nous utilisons aussi notre propre Package NPM basée sur Auth0 qui s’appelle : Orbit-JWT. 😏 Il nous permet en quelques lignes de gérer l’Auth & d’attacher le token sur les headers, sans avoir à faire d’intercepteur et beaucoup d’autres choses...
Tout ceci fait que le frontend est très évolutif, claire et facile à manager ! 🥳
Par exemple pour une interface complexe comme celle-ci :
Où nous avons principalement :
- Un Composant de filtre Global (paramétrable avec plus de 05 filtres [date range, typeahead select, switch, etc).
- Une DataGrid avec des filtres sur toutes les colonnes, la possibilité de trie, ainsi que la ligne des agrégations en bas.
- Un composant d’Export permettant d’avoir les données sous n’importe quel format.
- etc …
Aussi complexe qu’elle soit nous le construisons facilement dans l’application en moins de 50 lignes(je sais ! 😫 le nombre de lignes ne définit pas la qualité du code). Comme ici dans le fichier x.component.html :
Exemple des viz dans notre Front (Pleins de gribouillage car certaines données peuvent être sensibles):
Tout ce qui est DataViz And So Much More !!!! :
…
Lors des premiers mois le front faisait 70% du traitement à travers différents helpers car je voulais aussi voir jusqu’où je pouvais pousser Angular et aussi parce que les demandes étaient nombreuses et qu’il fallait les faire vite. Et pourtant les perfs étaient très acceptables. D’où l’importance de se concentrer sur l’architecture plus que sur les technos. Car aussi cool qu’une tech soit, c’est celui qui l’utilise qui déterminera ce qu’il en fera.
Cependant, vous vous doutez bien que les données que manipule le front viennent du back. Alors je vais vous parler de comment j’ai pu résoudre l’un de mes plus grands défi en 2021 avec une facilité incroyable !
READ PART 2 :
🥳 Or Check out My Web Site : https://orbitturner.com
