Réalisations choisies
De vraies études de cas entre architecture produit, plateformes admin/API et direction d’entreprise.
Ces entrées résument publiquement un produit en ligne, une architecture opérationnelle privée et un travail choisi de leadership d’architecture côté client.
Études de cas choisies
Trois points de preuve publiables entre produit, architecture opérationnelle 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.
Plateforme d’administration et d’API pour World of Aletheia
Une plateforme d’administration privée en SvelteKit et une couche API qui soutiennent les opérations d’adhésion aux campagnes, les workflows de gestion de comptes et les contrats de lecture publics appuyés par D1 pour World of Aletheia.
Problème
Le site public World of Aletheia avait besoin de capacités dynamiques liées aux campagnes et aux comptes, sans être couplé directement aux workflows d’administration privés ni aux détails internes de la base de données.
Contraintes
Le système devait garder les opérations administratives privées, maintenir une frontière claire entre API publiques et administratives, prendre en charge l’accès aux campagnes avec Better Auth, et éviter que le comportement du front-end diverge des contrats documentés.
Approche
Construire un service d’administration privé avec SvelteKit, des contrats OpenAPI définis en premier, des frontières explicites entre API publiques et administratives, une validation avec Zod, et des workflows ciblés pour la gestion des comptes et des campagnes.
Architecture
Runtime Cloudflare Workers/Pages, données de comptes et de campagnes dans D1, frontières de session Better Auth pour l’accès aux campagnes, Cloudflare Access pour les opérations de console administrative, et contrats OpenAPI comme source de vérité pour les consommateurs publics et internes.
Résultat
Un système opérationnel privé qui soutient le site public tout en gardant les comportements administratifs sensibles hors du dépôt public. Le travail côté public peut s’appuyer sur des contrats API documentés plutôt que sur les détails d’implémentation privés.
Notes
Le dépôt reste privé par conception, car il contient des workflows administratifs, des hypothèses de sécurité et des détails opérationnels. Les références publiques décrivent l’architecture et la discipline contractuelle sans exposer la surface administrative elle-même.
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, la plateforme 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.