Emmanuel Elimbi Medi

Plateforme SaaS conçue et développée au sein de ma société EME Technologies. Elle donne aux équipes engineering, architecture et management une vue unifiée et maintenue à jour automatiquement de leur parc applicatif.

LE BESOIN
Dans une DSI de taille moyenne, personne ne sait répondre de façon fiable à : quelles applications avons-nous, qui les possède, sur quels dépôts et quelles technologies reposent-elles, où sont-elles déployées, et qu'est-ce qui casse si celle-ci tombe ? Les cartographies existent, sous forme de schémas périmés dès leur publication. Archplorer répond en construisant la carte à partir des systèmes réels, en continu.

CE QUE J'AI LIVRÉ
- Inventaire applicatif : catalogue centralisé (nom, description, équipe propriétaire, statut de cycle de vie, tags, criticité, stack, niveau de conformité), avec rattachement à un ou plusieurs dépôts et exécutables.
- Cartographie des dépôts : métadonnées, branches, activité de commits, langages, README — pour GitHub, GitLab et Azure DevOps.
- Catalogue des cibles de déploiement : environnement, région, plateforme d'hébergement, URL, runtime, règles de scaling — cloud (Azure, AWS, GCP), on-premise, Kubernetes.
- Gestion des exécutables : services, jobs, fonctions et CLI, avec extraction de l'arbre de dépendances (bibliothèques et versions) et détection des dépendances inter-applications (appels d'API, files de messages, accès base).
- Couche de visualisation : graphe interactif des applications et de leurs dépendances, topologies dépôts et déploiements, arbre de dépendances par exécutable, vues filtrées par environnement (INT / UAT / PROD).
- Modèle organisationnel : domaines, équipes, personnes, appartenances — pour répondre à « qui possède quoi » sans passer par un annuaire tiers.

CHOIX TECHNIQUES
J'ai retenu une architecture Hub & Spoke dictée par la sécurité : le Hub, la plateforme centrale, n'appelle jamais les systèmes du client. Ce sont des agents CLI légers, déployés dans l'infrastructure du client, qui scannent Git, les dépendances (NuGet, npm, Maven, pip, modules Go), les définitions de pipelines CI/CD et les ressources cloud, puis poussent leurs résultats vers une API d'ingestion. Deux modes d'exploitation : intégré au pipeline CI/CD (scan à chaque build, via GitHub Action, job GitLab CI ou tâche Azure Pipelines) ou agent planifié. Le Hub ne stocke aucun identifiant Git ou cloud — uniquement la clé d'API de l'agent. C'est ce qui rend le produit acceptable pour une DSI qui refuserait d'ouvrir ses systèmes à un SaaS externe.

Côté données, PostgreSQL est la source de vérité et Neo4j une projection graphe dérivée, synchronisée en asynchrone via Dapr pub/sub sur RabbitMQ. Le chemin d'écriture ne bloque donc jamais sur le graphe, et si Neo4j est indisponible les événements s'accumulent dans le broker et sont rejoués à la reprise. Ce découpage permet des requêtes de traversée coûteuses — plus court chemin entre deux applications, dépendants transitifs, détection de cycles — sans pénaliser le CRUD. J'ai aussi intégré un moteur d'inférence LLM exécuté localement (Ollama) pour proposer des liens de dépendance que les scanners ne détectent pas, avec un contrat de sortie strictement JSON : aucune donnée client n'est envoyée à une API externe.

Stack : .NET, C#, ASP.NET Core, Clean Architecture, CQRS, EF Core, PostgreSQL, Neo4j, Dapr (pub/sub + Workflow), RabbitMQ, Redis, YARP, Clerk, React / Vite, .NET Aspire, Serilog + Seq, OpenTelemetry, Ollama, Docker.