Réalisations choisies
De vraies études de cas entre architecture produit, outillage utilitaire et direction d’entreprise.
Ces entrées résument publiquement un produit en ligne, un utilitaire public et un travail choisi de leadership d’architecture côté client.
Études de cas choisies
Trois points de preuve publiables entre produit, outillage et transformation
Chaque entrée reste concrète sur le périmètre, l’architecture et le résultat. Là où la confidentialité client s’applique, le résumé reste au niveau déjà public dans l’historique de rôle.
World of Aletheia
Une plateforme Astro en production pour worldbuilding et campagnes JDR, conçue pour gérer découverte publique, accès campagne protégé et workflow de publication orienté Obsidian.
Problème
Le site devait servir à la fois de référence publique pour l’univers et d’espace campagne protégé sans séparer l’écriture, la découverte et le contrôle d’accès runtime en systèmes disjoints.
Contraintes
Le volume de contenu augmentait, les zones campagne devaient rester fail-closed, et le workflow de publication devait rester léger pour l’auteur au lieu de devenir une lourdeur de CMS.
Approche
Adopter une architecture Astro-first avec domaines produit explicites, collections validées par schéma et un chemin de synchronisation Obsidian-first qui sépare clairement l’écriture de la surface de déploiement.
Architecture
Runtime Cloudflare Workers/Pages, métadonnées de découverte dans D1, stockage objet dans R2, frontières de campagne via Better Auth, et vérifications runtime uniquement là où le contenu protégé l’exige.
Résultat
Un produit en ligne avec routes de référence publiques, espaces campagne protégés et posture static-first qui supporte quand même des frontières authentifiées et des opérations de contenu adossées au cloud.
Notes
Le site live comme le dépôt public sont consultables, ce qui permet de montrer de vraies décisions d’architecture plutôt qu’un simple résumé rétrospectif.
Hexinater
Un petit CLI Python ciblé qui ajoute des grilles hexagonales configurables sur des cartes JPG et PNG pour le jeu de rôle, pensé comme un vrai utilitaire et non comme un simple échantillon portfolio.
Problème
La préparation de campagne butait toujours sur la même friction : trouver de bonnes cartes vues du dessus était facile, mais y poser une grille hexagonale propre restait péniblement manuel.
Contraintes
L’outil devait rester rapide, local et explicite : taille de grille configurable, style de ligne, orientation et offsets, sans obliger à passer par des workflows d’éditeur d’image.
Approche
Concevoir un CLI étroitement ciblé, avec une surface de commande claire, des défauts prévisibles et assez de contrôle pour résoudre le vrai problème d’alignement sans construire une boîte à outils graphique générale.
Architecture
Flux Python en ligne de commande avec validation d’entrée, génération de grille configurable, gestion du format de sortie et résumés d’exécution concis pour itérer rapidement.
Résultat
Un outil public qui pose une grille hexagonale en une seule commande, sert à une vraie préparation de campagne et rend visible un exemple petit mais concret de jugement d’architecture et d’implémentation.
Notes
Le dépôt documente ouvertement le workflow de build assisté par IA tout en gardant exigences, décisions d’interface et jugement d’acceptation clairement sous responsabilité humaine.
Architecture de plateforme cloud et gouvernance technique pour une organisation nationale de services au Royaume-Uni
Un résumé publiable d’un travail d’architecture digitale pour une organisation nationale de services au Royaume-Uni, avec un axe direction de plateforme AWS, intégration avec l’existant, alignement fournisseur et mise en place initiale d’une Technical Design Authority.
Problème
Une organisation nationale de services avait besoin d’une direction de plateforme cloud capable de soutenir la modernisation tout en restant compatible avec les systèmes existants et les contraintes de livraison déjà en place.
Contraintes
Le travail devait équilibrer les objectifs d’une plateforme cloud-native avec les systèmes existants, l’implication de fournisseurs, la pression de livraison et le besoin d’une gouvernance technique plus claire avant les phases ultérieures de delivery.
Approche
Définir une direction pragmatique de plateforme AWS, clarifier les besoins d’intégration, soutenir l’évaluation des solutions et des fournisseurs, et contribuer à la mise en place d’une fonction Technical Design Authority pour améliorer la cohérence des décisions techniques.
Architecture
Accent mis sur l’architecture de plateforme AWS, les patterns d’intégration avec les systèmes existants, les enjeux de scalabilité et de résilience, l’alignement fournisseur et les pratiques de gouvernance reliant la conception initiale à la direction plateforme plus large.
Résultat
Production d’une direction initiale d’architecture et de conception pour une initiative de plateforme cloud-native, soutien à l’intégration technique et à la sélection fournisseur, et contribution aux fondations initiales d’une fonction Technical Design Authority avant les phases ultérieures de livraison et de mise en production.
Notes
Ce résumé est volontairement anonymisé et limité au travail d’architecture et de conception initiale. Il évite les détails de programme confidentiels, les spécificités d’architecture interne, les affirmations de mise en production et toute métrique inventée.
Réalisations choisies
Besoin d’aide face à une pression similaire sur le produit, l’outillage ou la transformation ?
La page services montre comment ces motifs se traduisent en mission de conseil. La page contact est l’étape directe quand l’une de ces situations ressemble déjà à la vôtre.