Mohamed Aziz BEN REJEB

Deux front-ends, un back-office et un extranet client, partagent la même plateforme.

Un ERP doit répondre vite à ses utilisateurs, alors qu'une partie du travail est longue : produire des PDF, envoyer des e-mails, lire des documents. Ces traitements ne doivent pas bloquer l'API.

• Les traitements longs passent par RabbitMQ : l'API publie une tâche, un orchestrateur de workflows la distribue aux workers.
• Les schémas, DTO et contrats vivent dans des bibliothèques partagées du monorepo (Turborepo), utilisées par tous les services.
• Les données sont dans MongoDB (Mongoose, migrations), avec Redis et un stockage de fichiers.
• Tests Jest, conteneurs Docker, intégration continue GitLab CI.
• Ingénierie assistée par IA : agents Claude Code, revue et spécification automatisées.

• Les microservices ont été consolidés dans un monorepo, pour deux raisons : la gestion des versions et la simplicité des rollbacks.
• Des microservices détaillés, découpés en plusieurs composants.
• Pas de Kubernetes pour l'instant : ce serait du sur-dimensionnement tant que le besoin n'existe pas. La stack est déjà prête, le passage sera donc simple le jour venu.
• L'infrastructure, d'abord provisionnée sur AWS avec Terraform, a été migrée vers des serveurs dédiés pour son coût.
• Un système de migration de données simple.

• L'authentification est confiée à Keycloak, sur lequel s'appuie la gateway.
• Une tâche en échec est isolée dans une dead-letter queue.
• Le monorepo garde les rollbacks simples.

• J'ai co-conçu l'architecture microservices initiale (API, authentification, orchestrateur, mailer, services PDF et notification), puis co-piloté sa consolidation en monorepo.
• Je porte le socle de la plateforme et je prends les fonctionnalités les plus difficiles de bout en bout.
• Je prends les décisions d'architecture, et je cadre les demandes avec les Product Owners : faisabilité, chiffrage, spécification.
• J'arbitre les urgences de production face à la roadmap, et je coordonne les prestataires externes : cadrage, revue de code, qualité de livraison.
• Je suis le premier contributeur du code : 58 % des commits hors fusions (1 266 sur 2 174, novembre 2026).

Je livre d'abord le MVP, et je ne cherche pas à couvrir 100 % des cas métier.

Offrir aux pentesters et aux RSSI un test d'intrusion prêt à l'emploi : un boîtier qu'on branche, piloté depuis une interface web, avec des moteurs d'attaque qui peuvent aussi tourner à distance, sur d'autres machines. Ces moteurs doivent être authentifiés un par un.

• L'architecture est proche de celle de l'ERP, mais les workers sont des agents, qui peuvent tourner à distance sur d'autres machines.
• Les agents communiquent en MQTT.
• Redis sert de cache et gère les sessions au niveau des moteurs d'attaque ; les données sont dans MongoDB et PostgreSQL.

• Tout le système est géré par certificats : chaque agent a son propre certificat.
• Les bonnes pratiques de sécurité sont appliquées dans le code : requêtes préparées, encodage des données, validation des entrées, contrôle des accès, journalisation.

• J'ai pensé tout le système : l'infrastructure, dont j'ai dirigé la mise en place, et les workflows.
• J'ai développé le noyau de l'application en Flask, front-end et back-end, et les moteurs d'attaque.
• J'ai développé le back-office de gestion des clients et des licences.
• J'ai mis en place les environnements de production, de test et de développement, avec la CI/CD GitLab et Harbor sur serveurs bare metal.
• J'ai supervisé la migration sous-traitée vers une nouvelle version : cahier des charges, recette et suivi qualité des livraisons.
• J'ai coordonné l'équipe : découpage, affectation des tâches, revue de code.

Calculer une réputation par intelligence artificielle demande de collecter des données avec des crawlers, puis de les analyser : un travail réparti entre plusieurs workers, qu'il faut coordonner et suivre.

• Une architecture de type agents dès 2020, dans sa forme de l'époque : un orchestrateur délègue à chaque worker ses tâches, à travers RabbitMQ.
• L'authentification repose sur Keycloak, fournisseur OpenID, configuré avec l'API gateway Kong.
• L'API ajoute une couche sur Express, organisée en clean architecture.
• Les statistiques des crawlers ont leur propre microservice.
• Les données sont dans MongoDB et PostgreSQL ; la supervision passe par Grafana et Prometheus.

• J'ai rédigé le document de spécification des exigences (SRS) et conçu la solution en UML : analyse fonctionnelle, architecture technique, composants à développer.
• J'ai conçu et mis en œuvre l'architecture globale : microservices, broker de messages, workers et workflows.
• J'ai développé l'API, une couche sur Express (Node.js) en clean architecture, et une librairie Python pour la connexion à RabbitMQ et la gestion des queues.
• J'ai développé l'orchestrateur qui délègue à chaque worker ses tâches, et un microservice qui suit, calcule et stocke les statistiques des crawlers.
• J'ai posé le socle de l'interface React : authentification Keycloak, menu, pages, routes, principaux formulaires et workflows.
• J'ai mis en place le cluster Kubernetes sur serveurs bare metal, le registre Harbor pour les images Docker et les manifests de chaque mise en production.

Le backend qui distribue et collecte les données des véhicules connectés est réparti sur plusieurs clusters et serveurs.

Pour le surveiller, il fallait une interface de monitoring, une API pour l'alimenter, et des échanges authentifiés entre serveurs.

• Toute l'API est en microservices GraphQL, avec Apollo sur Express et Node.js.
• Les microservices sont répartis sur plusieurs clusters Kubernetes.
• La partie rétro-ingénierée a été réécrite en Go.
• Les données sont dans MongoDB ; l'infrastructure passe par Terraform et Ansible.

• Les serveurs s'authentifient entre eux avec ZeroMQ.
• Les clusters Kubernetes sont sécurisés selon les bonnes pratiques.

• J'ai apporté le front qui sert à monitorer la partie backend : c'est le « GUI » du nom.
• J'ai fait la conception globale de l'application, et mis en œuvre l'architecture microservices, avec la place de chaque élément sur les différents clusters et serveurs.
• J'ai développé toute l'API en microservices GraphQL (Apollo, Express, Node.js), et le socle React : menu, datatables, pages principales.
• J'ai développé l'authentification serveur à serveur avec ZeroMQ, et appliqué les bonnes pratiques de sécurisation des clusters Kubernetes.
• J'ai rétro-ingénieré une partie de l'application et je l'ai réécrite en Go.
• Revue de code, refactorisation et correction de bugs ; coordination de l'équipe, découpage et affectation des tâches.