Étude de cas · side project personnel

Sonomundi : construire progressivement un produit abouti

Side project personnel non salarié démarré en décembre 2025, Sonomundi prolonge une découverte du secteur de l’événementiel commencée avec une formation de Chef de projet événementiel chez Studi en juillet 2024. Je construis d’abord un produit stable dont l’exploitation courante pourra être largement automatisée, sans m’imposer de date de sortie. Voici précisément où j’en suis aujourd’hui.

Pour accéder à une interface plus complète, créez un compte dans la démo. Sans connexion, la démo reste limitée aux fonctionnalités publiques.

Où en est Sonomundi aujourd’hui ?

Ce qui fonctionne aujourd’hui

La démo permet de parcourir des événements, des artistes et des morceaux. L’application gère plusieurs rôles, expose une API documentée et dispose de tests back-end et UI.

Ce que je consolide avant une sortie

Je resserre le périmètre utile et je renforce la préproduction, l’observabilité et l’automatisation du delivery. La publication sera progressive, quand l’ensemble sera suffisamment fiable.

Ce qui reste en laboratoire

Neo4j, k3s local et certains services satellites restent des explorations techniques. Ils ne conditionnent pas la sortie du cœur Laravel/Vue.

Ce que je ne revendique pas encore

Sonomundi n’est pas encore ouvert au public ni exploité à l’échelle commerciale. Je ne présente donc pas de trafic réel, de disponibilité mesurée ou de paiement exploité en conditions réelles.

1. Contexte du projet

Sonomundi est un monorepo Laravel/Vue conçu comme un side project personnel de long terme autour de l’événementiel et de la musique. Je veux prendre le temps de le terminer correctement et le publier progressivement lorsqu’il sera suffisamment abouti, sans imposer de calendrier de lancement pressant.

J’ai commencé en juillet 2024 chez Studi une formation de Responsable de projets événementiels. Mon attestation comptabilise 1 000 heures ; j’estime que le travail personnel et l’approfondissement ont porté l’investissement réel au-delà, mais je ne présente comme vérifiable que le volume attesté. La fiche publique liée correspond au programme en vigueur en juillet 2026 et affiche désormais une durée indicative de 500 heures ; mon attestation reste la source relative au parcours commencé en 2024.

Le parcours n’a pas débouché sur la certification parce que je n’ai pas trouvé le stage nécessaire. Je vis dans un territoire rural isolé où les opportunités événementielles sont rares, éloignées géographiquement et souvent difficiles à identifier ou à rejoindre sans réseau professionnel local. Après cette recherche infructueuse, j’ai choisi d’investir mon énergie dans la construction de Sonomundi plutôt que de prolonger indéfiniment l’attente d’un stage.

Le programme couvrait la stratégie et l’étude de faisabilité, le marché et le positionnement, le besoin client, la conception du projet, le budget et les risques, les KPI, le reporting, le feedback, la création d’une équipe projet, la délégation et la communication interne. Cette reprise de formation visait à dépasser une lecture uniquement technique du produit et à apprendre à conduire un projet avec d’autres.

J’ai ensuite appliqué une partie de ces concepts à Sonomundi : cadrage du MVP, spécifications et planning, priorisation des risques, rôles et responsabilités, indicateurs de readiness, reporting, boucles de feedback et amélioration continue. Cela ne remplace ni le stage absent ni une expérience de management humain, mais fournit une mise en pratique concrète et démontrable.

Son développement reste hors temps de travail et peut être mis en pause. Il est organisé pour ne pas empiéter sur ma disponibilité complète pour un employeur.

2. Problème traité

Le cœur du produit organise la découverte d’événements et la navigation entre événements, artistes et morceaux. Le travail sert aussi à démontrer la capacité à transformer un besoin riche en architecture, contrats, règles d’accès et parcours vérifiables.

3. Fonctionnalités principales

  • Hub d’événements et sélection d’une région.
  • Ouverture d’un événement, d’un artiste puis d’un morceau.
  • Surfaces publiques, authentifiées et administratives.
  • Ressources API, jobs et documentation OpenAPI/Scramble.

4. Architecture

Le noyau associe une API Laravel/PHP et une SPA Vue 3/TypeScript. MySQL porte les données principales ; Redis sert au cache, aux files et à la coordination locale. Des services Python/FastAPI existent pour des besoins ciblés. Les frontières sont documentées par migrations, resources, middlewares, jobs, tests et contrats API.

Au 21 juillet 2026, le VPS exécute 37 conteneurs rattachés à Sonomundi. Ce total décrit deux environnements applicatifs et leur plateforme d’exploitation ; il ne signifie pas que le produit est composé de 37 microservices ni qu’il supporte une charge de production démontrée.

  • 11 conteneurs pour la démonstration et 11 pour la préproduction : interface web, API, proxy HTTP, worker, scheduler, temps réel, transcodage audio, MySQL, deux usages Redis et Neo4j.
  • 15 conteneurs partagés : forge et CI/CD, orchestration d’agents et recherche sémantique du code, observabilité et logs, suivi d’erreurs, tableaux d’exploitation, bases techniques et passerelles d’accès.

5. Stack

  • PHP 8.2, Laravel 12, Vue 3 et TypeScript.
  • MySQL, Redis et Neo4j en exploration graphe/recommandation.
  • Python/FastAPI pour des services satellites ciblés.
  • Docker, k3s local, OpenAPI/Scramble, PHPUnit et Playwright.

6. Authentification et rôles

Le périmètre couvre l’authentification multi-rôles et des accès différenciés pour les visiteurs non connectés, le public authentifié, les artistes, les labels et l’administration. Les middlewares et matrices de tests servent à vérifier ces frontières.

7. Ontologie et traçabilité fonctionnelle

Sonomundi possède une ontologie versionnée et lisible par machine. Elle formalise les entités du domaine — comptes, rôles, artistes, labels, sorties, morceaux, événements, lieux, ressources audio, demandes de contenu et preuves — ainsi que leurs relations, invariants, politiques de provenance et règles de visibilité.

La référence revue du 24 juillet 2026 relie les capacités visibles aux surfaces de l’application, aux six espaces de rôles et aux preuves de test. Elle recense 511 capacités, 113 surfaces de routage et 3 066 cellules capacité-rôle. Les preuves manquantes ou contradictoires restent explicitement à décider ; elles ne sont jamais déduites par similarité ou par un LLM.

Cette ontologie sert de contrat de connaissance et de gouvernance : elle rend les frontières métier, les droits et les lacunes de couverture auditables par les humains comme par les outils agentiques. Neo4j constitue une exploration distincte pour le graphe et la recommandation ; il n’est pas la source de vérité de l’ontologie.

8. Données et performances

MySQL reste la base applicative principale. Redis est utilisé pour le cache, les queues et la coordination locale. Neo4j relève encore de l’expérimentation. Aucune latence de production réelle ni capacité de charge commerciale n’est publiée : ces mesures n’existent pas dans les preuves disponibles.

9. Tests

L’inventaire statique de gitea/main au 16 juillet 2026 recense 2 189 tests PHPUnit répartis dans 401 fichiers PHP. Il décrit le volume de tests présents dans le dépôt, pas le résultat d’une exécution complète ni un taux de couverture.

Une matrice Playwright complète cette preuve avec 683 scénarios validés sur cinq profils d’accès. Ces chiffres documentent l’étendue du dispositif de validation, sans prétendre à une couverture universelle ni à une validation en production.

10. CI/CD

Les changements sont isolés par branches et worktrees, puis validés avec Docker, Make, tests ciblés et contrôles élargis lorsque les contrats partagés sont touchés. La démo recruteur est figée sur une version dédiée. Le projet conserve une préproduction distincte en amélioration continue.

11. Observabilité

Grafana/Loki et GlitchTip/Sentry font partie des rails techniques explorés. Une observabilité de production mature, des SLO, un historique d’incidents et des mesures de disponibilité réelles ne sont pas démontrés ; ils restent des travaux d’industrialisation.

12. Utilisation des outils IA

J’ai adapté Paperclip comme plan de contrôle du delivery agentique : les spécifications alimentent des lots attribués à des agents spécialisés, avec contexte ciblé, tâches bornées, mémoire documentaire, branches et worktrees isolés, validations Docker/CI et pré-revue des pull requests. Codex, MCP et LangChain/LangGraph complètent ce dispositif pour l’analyse, l’implémentation, les tests, la documentation et les audits.

L’ontologie et les contrats versionnés fournissent aux agents un vocabulaire métier et des frontières vérifiables, sans leur déléguer la vérité fonctionnelle. Aucun auto-merge ; le LLM n’est jamais la source de vérité et la responsabilité d’intégration reste la mienne.

À terme, l’objectif est d’automatiser au maximum les validations, revues de PR, mises à jour documentaires, déploiements et alertes de suivi afin de réduire la maintenance courante et d’éviter les interruptions inutiles.

Infographie reliant huit étapes du workflow IA et delivery à huit dimensions du produit Sonomundi.
Le workflow IA n’est pas présenté comme une fin en soi : chaque étape est reliée à une capacité produit, de l’ownership à la livraison reproductible.
Lire la version textuelle de l’infographie

La colonne « Stack IA / delivery » est mise en regard de la colonne « Produit Sonomundi » selon huit correspondances :

  • Agent IA de code → ownership produit.
  • Context engineering → back-end senior.
  • Orchestration d’agents → front-end applicatif.
  • Debug dans un navigateur réel → qualité logicielle.
  • Validation automatisée → architecture modulaire.
  • Auto-review et gates → media et discovery.
  • CI/CD et publication contrôlée → API et documentation.
  • Reporting et observabilité → organisation remote-ready et delivery reproductible.

13. Limites actuelles

  • Dépôt privé et démonstration conduite par le candidat.
  • Aucune date de sortie imposée : la qualité et la pérennité priment sur la vitesse.
  • Billing, wallet, settlement, monétisation et audio réel : chantiers séparés ou partiels.
  • Observabilité, sauvegardes, secrets et infrastructure à renforcer pour une industrialisation.
  • Certaines surfaces avancées restent gelées ou incomplètes.

14. Enseignements

Le principal enseignement est de réduire plus tôt le MVP et de distinguer la preuve technique du volume produit. Les tests, contrats, frontières de modules, migrations et décisions documentées sont plus utiles que les lignes de code ou le nombre de commits. L’IA accélère la production ; elle ne remplace ni le cadrage ni la responsabilité.

Le pilotage des agents m’oblige à expliciter l’objectif, distribuer des responsabilités, fournir le bon contexte, contrôler les dépendances, donner du feedback et arbitrer les résultats. Ce n’est pas une expérience de management humain, mais un terrain concret pour consolider des pratiques de coordination que je souhaite mettre à profit dans un rôle de contributeur senior ou de lead au service d’une équipe.

15. Démonstration et captures

Le parcours recruteur montre le hub d’événements, une région, un événement, un artiste et un morceau. Les captures ci-dessous complètent la démo et l’architecture anonymisée. Aucun accès au dépôt ni installation locale n’est demandé au lecteur.

Pour accéder à une interface plus complète, créez un compte dans la démo. Sans connexion, la démo reste limitée aux fonctionnalités publiques.