Construction d'un Data Warehouse

Un Data Warehouse est une base de données et un ensemble d’outils d’analyse permettant un accès simple et sécurisé aux données. Au sein de SNT2, je suis responsable de la mise en œuvre de différents flux de données. Construit autour du connecteur e-commerce, notre Data Warehouse est un outil de suivi des performances en temps réel, où les équipes peuvent créer leurs propres tableaux de bord. La solution offre un référentiel unique pour différents flux de l’entreprise, pour les fonctions e-commerce ou pour le CRM HubSpot. L’entrepôt de données est construit en suivant les méthodes ETL pour le nettoyage de la data et sa normalisation et ELT pour son exploitation.

Conception d'un connecteur e-commerce

Dans le cadre de son développement, le groupe SNT2 s’est diversifié en lançant différents sites e-commerce. J’ai donc entrepris en 2020 la conception et le développement d’un connecteur PrestaShop. En production après quelques semaines de développement, j’ai poursuivi l’amélioration de l’outil en ajoutant de nouvelles fonctionnalités et en améliorant ses performances pour accompagner la montée en charge de la solution et pour répondre aux besoins de tout les utilisateurs, clients finaux et collaborateurs. Ce connecteur est actuellement en production et synchronise en temps-réel 6 sites e-commerce et traite une centaine de commandes par jour. Fonctionnalités Prise en charge de plusieurs PrestaShop (toutes versions confondues) et de plusieurs ERP Prise en charge de l’API standard PrestaShop Synchronisation en temps-réel : des clients des commandes et de leurs workflows de statut des règlements des numéros de tracking des documents PDF provenant des ERP (les factures par exemple) Intégre des workflows standard et permet la création de workflows spécifiques, répondant à tous les cas d’usage

Déploiement ERP

En tant que Chef de Projet chez SNT2, j’ai mené à bien une mission de modernisation et de ré-internalisation du système informatique de gestion. Mes interventions ont couvert divers aspects du projet, notamment : Définition du projet : j’ai participé à la définition des périmètres fonctionnels, des budgets et des délais du projet. Préparation des spécifications : j’ai rédigé les cahiers des charges et identifié les utilisateurs pilotes. Sélection des solutions : j’ai sélectionné les différentes solutions en short-list et participé au choix final de SAP Business One et de PrestaShop. Sélection des partenaires : j’ai interviewé et participé à la sélection des partenaires intégrateurs, validé les budgets avec eux, et planifié les ateliers métiers, les prestations de paramétrages ou de développement et les formations. Paramétrage et développement : j’ai participé au paramétrage et au développement de SAP Business One sur les aspects comptables, logistiques, de chaîne d’achat et divers fonctionnels. J’étais responsable du paramétrage d’un middleware en charge de la synchronisation e-commerce. Pour les travaux délégués aux intégrateurs, je validais les recettes ou délèguais celles-ci aux utilisateurs finaux. Reprise de données : j’ai encadré et participé à la reprise de données pour les tiers clients et fournisseurs (~500 000 tiers), l’historique comptable (3 ans pour ~3 000 000 lignes d’écritures ainsi que les à-nouveaux), les articles (~20 000 références de diverses typologies). Formation et accompagnement : j’ai rédigé les supports de formation avec les key-users et accompagné les utilisateurs lors des transitions vers les nouveaux systèmes en assurant le support de proximité, en faisant le lien avec les intégrateurs, en adaptant les supports de formation et en améliorant l’ERP ou les processus. Durant la mise en œuvre de l’ERP, nous maintenions les différents ERP du groupe et avons mis en œuvre différents flux de synchronisation pour permettre une migration fluide des fonctions de l’entreprise. D’abord les processus comptables puis les processus achats et stocks. Une partie des e-commerce étaient synchronisés avec cet ERP. Le secteur du e-commerce demande beaucoup d’agilité : nous devions donc faire vivre les ERP historiques et l’ERP SAP en parallèle, un nouveau besoin devant être reporté sur l’ensemble des ERP. En 2021, nous avons décidé d’arrêter la mise en œuvre de SAP. Cela a été motivé par la lourdeur du développement dans SAP, qui peinait face à l’agilité des ERP spécifiques e-commerces que nous utilisions. J’ai donc entrepris la migration des différents processus migrés vers leurs ERP d’origine, jusqu’à l’arrêt définitif de la solution.

Mise à jour de l'infrastructure

Au sein de l’entreprise Synchronic, j’étais responsable du maintien en conditions opérationnelles de l’infrastructure serveur du groupe. Dans ce cadre, j’étais en charge de la mise à niveau de l’infrastructure, incluant la mise à niveau des versions Active Directory, Exchange, Remote Desktop, vSphere et Kaspersky. Ce projet s’est déroulé durant plus de 2 ans et a abouti à une infrastructure à jour. Actions menées Exploitation, entretien et renouvellement : d’une forêt Active Directory 2003 vers 2008 R2 d’un serveur Exchange 2010 d’un cluster Remote Desktop Services d’un cluster VMware vSphere des applicatifs de supervision et de sauvegardes des antivirus d’entreprise Mise en œuvre d’un stockage VMware vSAN Mise à jour des référentiels et documentations : inventaire cartographie procédures techniques à destination du service informatique et des procédures métiers à destination des usagers PCA PRA PSSI Support tout niveau

Mon utilisation de GitLab

Historique J’ai débuté ce projet en 2017 dans le but de standardiser mes déploiements Docker sur mon serveur hébergé chez Scaleway. Je l’ai utilisé pendant 7 ans, effectuant les montées de versions majeures jusqu’à son arrêt en 2024, faute de temps pour pouvoir entretenir mon infrastructure correctement. Utilisations Fork de projet public, pour archivage ou pour modification Déploiement de services, pour mon usage personnel ou pour ceux d’usagers tiers. Organisation J’y exploitais les fonctionnalités d’intégration continue (CI/CD) de Gitlab et la création de template Docker pour créer des déploiements reproductibles et réutilisables à souhait. Une application web gérée par la plateforme pouvait donc être déployée autant de fois souhaité, où chaque client disposait de ses environnements propres. Gestion des Docker Stack Un projet pour la gestion des Docker Stack : Chaque service pris en charge est un sous-projet Toujours construit de la même manière : Un sous-dossier docker-stack, contenant deux fichiers : dev.docker-stack.yaml : permet de définir des surcharges lors des déploiements prod.docker-stack.yaml : idem, spécifique à la production L’ensemble des fichiers nécessaires au fonctionnement et à la conduite du projet Gestion des clients / usagers Un projet par usager : Chaque service déployé est un sous-projet Ces sous-projet intègrent les Stack en tant que submodule git dans un dossier “docker-stack” Ils contiennent deux fichiers : dev.docker-stack.yaml : permet de définir des surcharges demandées par le client prod.docker-stack.yaml : idem, spécifique à la production Les variables d’environnements sont définies à ce niveau : URL du service, feature flag à activer, etc. les configurations spécifiques via Docker Config et les Docker Secret Chaque branche déclenche un pipeline de déploiement, permettant de tester rapidement et facilement Les pipelines de déploiement exécutent les 2 fichiers : dev.docker-stack.yaml docker-stack/dev.docker-stack.yaml Le pipeline de production exécute les 2 fichiers : prod.docker-stack.yaml docker-stack/prod.docker-stack.yaml Les branches sont construites en suivant GitLab Flow, permettant la gestion des environnements et leurs historiques L’utilisation de git submodule permet de déployer les nouvelles versions des Stack au moment opportun et s’intègre dans GitLab Flow Cette organisation permet l’industrialisation des Stack tout en offrant une grande flexibilité et la possibilité de personnaliser le service déployé pour chaque client.

Hébergement de solutions Open Source

J’auto-héberge différentes solutions Open Source depuis 2012. J’ai commencé ce projet en hébergeant des serveurs de jeux sous Linux, puis en hébergeant mon NextCloud en cloud privé Scaleway. Je me suis intéressé à Docker et Docker Compose dès les 1ʳᵉ versions, en construisant les images et les Stacks en fonction de mes besoins. Au fil des évolutions et des migrations, j’ai entrepris l’auto-hébergement de Gitlab, afin de standardiser mes déploiements. J’y versionne mes Stacks Docker, construits et organisés de façon à permettre la reproductibilité et la personnalisation des déploiements. Autant d’environnement que nécessaire sont livrés, de multiples dev, une staging et une production en suivant le Gitlab Flow. Traefik est utilisé pour sécuriser l’accès aux services. Les configurations sont pensées pour être les plus dynamiques possibles, notamment en se basant sur les variables d’environnement des projets GitLab. En ajoutant au fur et à mesure de nouvelles solutions, j’ai constitué une bibliothèque d’une dizaine d’applications Open Source : NextCloud Minio n8n WordPress ERPNext Odoo PrestaShop AppSmith BudiBase Metabase Apache Superset MySQL, Postgres, MongoDB Ollama, Llama 3 Open WebUI L’ensemble de ces outils me permettent de créer des workflows de travail spécifiques et intégrés. A titre d’exemple, mon processus de veille est articulé autour de NextCloud News pour l’agrégation de flux RSS, où je sélectionne les articles intéressants à l’aide de la fonction de favoris. Ces articles favoris sont ensuite importés dans NextCloud Bookmarks et enrichis avec une IA auto-hébergée pour l’ajout de tags et de résumés. Ces automatisations sont traitées par n8n et les différentes API de NextCloud. Ce process me permet rapidement de retrouver du contenu quand j’en ai le besoin, offrant la possibilité d’utiliser les tags avec l’ensemble de l’écosystème de NextCloud.