Ingénieur logiciel senior avec plus de 18 ans d’expérience, j’ai construit mon parcours autour de l’architecture applicative, du leadership technique Java, de la structuration de processus Agile et de l’intégration de la sécurité dans les projets d’ingénierie logicielle.
Mes rôles successifs — architecte solution, responsable technique Java, scrum master, chef de projet technique — ont façonné une expertise transverse centrée sur la conception de solutions, la coordination multi‑équipes et la sécurisation des architectures et des applications.

En 2025, j’ai entrepris une mise à jour stratégique de mon socle technologique pour intégrer pleinement les pratiques modernes du marché : Spring Boot 3, CI/CD GitHub Actions, Docker, Kubernetes (kind puis EKS), sécurité applicative, supply chain security et DevSecOps.
Cette démarche s’est concrétisée par la réalisation du projet CoreService, un démonstrateur complet d’ingénierie logicielle illustrant :

• la construction d’une architecture moderne et sécurisée,
• la structuration d’un SDLC complet (fonctionnel → technique → code),
• une CI/CD sécurisée (analyse statique, SBOM, Trivy, VEX),
• un déploiement Kubernetes local et cloud,
• une démarche Secure by Design intégrée à chaque étape,
• une collaboration humain–IA maîtrisée et documentée.

Aujourd’hui, je me positionne sur un rôle situé à la croisée naturelle de ces compétences :
Architecte Solution, Responsable Technique Java ou Ingénieur Backend Senior Java/Spring Boot, avec une forte orientation Secure by Design et sécurisation des architectures et des applications.

La démarche repose sur l’intégration de la sécurité dans les phases que je maîtrise réellement :

Architecture → Sécurité applicative → CI/CD → Sécurité d’exécution → Sécurité infrastructure

Elle vise à industrialiser la sécurité dans les projets en s’appuyant sur des pratiques concrètes, reproductibles et alignées avec les exigences du marché.
Les futures releases prévoient d’articuler ces exigences applicatives avec les exigences issues de la GRC (NIS2, analyses de risques) et de la gouvernance.

• Conception d’une architecture moderne (Spring Boot 3, Docker, Kubernetes),
• Définition des patterns de sécurité applicative,
• Structuration des flux, zones de confiance et responsabilités.

La sécurité applicative est intégrée via un processus structuré :

1. Fiches sécurité

   • Identification des exigences sécurité par composant,
   • Définition des contrôles applicatifs (authN, authZ, validation, journalisation, secrets, etc.).

2. Spécifications techniques

   • Déclinaison des exigences sécurité en mécanismes concrets,
   • Patterns d’implémentation, contraintes d’architecture, contrôles à intégrer dans le code.

3. Spécifications fonctionnelles

   • Référence aux exigences sécurité comme contraintes transverses,
   • Spécifications centrées sur le métier, sans implémentation sécurité.

• Pipeline GitHub Actions sécurisé,
• Analyse statique, SBOM, Trivy, VEX,
• Durcissement des images et gestion des dépendances.

• Déploiement Kubernetes local (kind) puis cloud (EKS),
• NetworkPolicy, RBAC, secrets, observabilité.

• Durcissement des environnements,
• Gestion des identités cloud,
• Séparation des rôles et privilèges.

La démarche s’appuie sur un modèle de collaboration humain–IA structuré :

• une IA de génération (code, architectures, documents),
• une IA de contrôle (sécurité, cohérence, conformité, qualité),
• un arbitrage humain systématique pour garantir la maîtrise des livrables.

Ce principe de contrôle croisé IA → IA, supervisé par l’humain, renforce la robustesse de la démarche Secure by Design.

Le projet est structuré en releases successives, chacune documentée par :

• une spécification d’architecture versionnée,
• une spécification technique,
• une fiche sécurité,
• une release note,
• un schéma d’architecture (logique, applicative, déploiement).

Ce processus reproduit les pratiques d’une DSI moderne et démontre une capacité à industrialiser la sécurité dans les projets.

Le projet n’est pas publié intégralement.

Pour des raisons de confidentialité et de protection des artefacts :

• les fiches sécurité,
• les spécifications techniques,
• les schémas complets,
• les release notes détaillées,

ne sont pas rendus publics.

Le dépôt public présente uniquement :

• la démarche,
• les objectifs,
• les principes Secure by Design,
• un schéma d’architecture non sensible,
• la structure générale du projet.

Les artefacts internes sont présentés uniquement en entretien.

• Présentation professionnelle complète
  → presentation.md

• CV intermédiaire (détaillé)
  → cv/CV_intermediaire.md

• CV court
  → cv/CV_court.md

• Versions PDF
  → cv/CV_intermediaire.pdf