Réalisation · Plateforme et application mobile

KizzyDance — plateforme sociale dédiée à la danse

Illustration isométrique : un téléphone et un ordinateur portable affichent la plateforme KizzyDance, reliés par un flux de données entre silhouettes de danseurs

Plateforme web et application mobile dédiées à la communauté internationale de la danse, en production continue depuis 2018, sans interruption majeure.

Période d'engagement : · Page revue le

Contexte

KizzyDance fédère une communauté mondiale de danseurs autour d'événements, de cours et d'un réseau social dédié. La plateforme compte plusieurs dizaines de milliers d'utilisateurs actifs et exige une disponibilité 24/7, des cycles de mise à jour rapides et un suivi serré des coûts cloud.

Enjeu

Maintenir dans la durée une plateforme héritée (web et mobile) tout en y intégrant en continu de nouvelles fonctionnalités, sans régression, avec une équipe réduite et des contraintes de budget cloud strictes.

Approche SeedVision

SeedVision a pris en charge la totalité de la chaîne DevOps : pipeline CI/CD complet, supervision (alertes sur incident et suivi des performances), migrations PostgreSQL critiques, optimisation continue des coûts cloud et durcissement de la sécurité. Un manuel d'exploitation permet à l'équipe produit de déployer en autonomie.

Chronologie de l'engagement

  • — Mise en service. Ouverture de la plateforme web et de l'application mobile. L'engagement d'exploitation commence la même année : chaîne de déploiement et supervision sont livrées avec le produit.
  • — Exploitation continue. 8 ans de service ininterrompu. Correctifs de sécurité, migrations de base de données et montées de version du socle mobile se succèdent sans interruption majeure pour les utilisateurs.

Avant et après

Rythme de mise en production

Avant : Une livraison qui dépend d'une personne et d'une fenêtre d'arrêt plafonne la fréquence des mises à jour.

Après : Cycles de déploiement ramenés sous les 30 minutes, déclenchés depuis la chaîne d'intégration continue.

Facture cloud

Avant : Une infrastructure dimensionnée pour le pic se paie toute l'année au prix de son heure la plus chargée.

Après : Plus de 35 % de dépense cloud en moins sur 24 mois, sans réduction du périmètre servi.

Disponibilité

Avant : Sans supervision, un incident se découvre par les utilisateurs, donc trop tard pour éviter la coupure.

Après : 8 ans de production sans incident majeur prolongé, alertes déclenchées sur les signaux qui portent une conséquence utilisateur.

Autonomie de l'équipe produit

Avant : Une équipe qui ne peut pas déployer seule attend son prestataire pour la moindre correction de texte.

Après : Un manuel d'exploitation à jour permet à l'équipe produit de déployer sans SeedVision.

Résultats

  • 8 ans de production sans incident majeur prolongé
  • Cycles de déploiement ramenés sous les 30 minutes
  • Coût cloud réduit de plus de 35 % sur 24 mois
  • Socle mobile (React Native) maintenu à jour des versions du système

Voir la plateforme en production

Technologies et périmètre

  • React Native
  • Node.js
  • PostgreSQL
  • DevOps
  • En production depuis 2018

Période d'engagement :

Ce que couvre l'engagement, bloc par bloc

  • Chaîne d'intégration et de déploiement continus — Compilation, tests, publication des images et déploiement des environnements. Le même chemin sert au correctif urgent et à l'évolution planifiée : il n'existe pas de procédure de secours moins testée que la procédure normale.
  • Base de données PostgreSQL — Migrations de schéma sur une base en service, sauvegardes vérifiées par restauration réelle, suivi des requêtes lentes. Une sauvegarde jamais restaurée est une hypothèse, pas une sauvegarde.
  • Application mobile React Native — Un seul socle pour les deux magasins d'applications : montées de version du système, dépendances natives, publication et traitement des rejets de validation.
  • Supervision, sécurité et coûts — Alertes sur les erreurs, la latence et la saturation ; durcissement des accès et des dépendances ; revue régulière du dimensionnement et des ressources laissées allumées.

Ce que l'exploitation impose

  • Une migration de base de données ne se joue pas au basculement — Sur une base en service, le risque arrive dans les minutes qui suivent : verrous qui durent, plans de requête qui changent. Chaque migration critique est donc réversible et déployée séparément du code qui l'utilise.
  • Une alerte qui n'appelle aucune action doit disparaître — Le bruit se paie en délai de réaction le jour où l'incident est réel. Seuls les signaux reliés à une conséquence pour l'utilisateur restent branchés sur une astreinte.
  • Le manuel d'exploitation est un livrable vivant — Un manuel qu'on ne rejoue jamais vieillit plus vite que la plateforme. Il est corrigé à chaque changement de procédure, et c'est l'équipe produit qui l'exécute — c'est le seul test qui prouve qu'il est juste.

Choix d'architecture, et pourquoi

  • Un socle mobile unique plutôt que deux applications natives — React Native pour une équipe réduite : une base de code, deux magasins. La contrepartie est la dépendance au calendrier de la bibliothèque ; elle est budgétée dans la maintenance plutôt que subie.
  • PostgreSQL comme source de vérité unique — Une seule base relationnelle, aucun moteur spécialisé ajouté tant que le besoin n'est pas démontré : moins de composants à sauvegarder, à superviser et à faire évoluer pendant huit ans.
  • Des livraisons courtes plutôt que de grandes versions — Un petit changement se relit, se déploie et s'annule vite. C'est ce qui rend un cycle de moins de 30 minutes utile : le jour où quelque chose casse, la surface à examiner tient en quelques changements.

Millésimes techniques et réglementaires

Faits publics et datés qui contraignent le périmètre.

  • — Entrée en application du RGPD. Fait public : le règlement européen sur la protection des données s'applique depuis cette date. La plateforme, ouverte la même année, est exploitée sous ce régime depuis son premier jour de production.
  • — PostgreSQL 16. Chaque version majeure de PostgreSQL est prise en charge cinq ans par la communauté. C'est ce calendrier public, et non une préférence interne, qui commande le rythme des migrations de base de données.
  • — React Native 0.76. Cette version fait de la nouvelle architecture le mode par défaut. Une application publiée depuis 2018 traverse ces bascules : tenir le socle à jour fait partie de l'engagement.

Questions sur cet engagement

Pourquoi une plateforme ouverte en 2018 demande-t-elle encore un engagement d'exploitation ?

Parce que son environnement bouge sans elle : chaque version majeure de PostgreSQL n'est prise en charge que cinq ans par la communauté, le socle React Native a changé d'architecture par défaut, et un correctif de sécurité ne se planifie pas. L'engagement porte sur ces montées de version et sur les migrations de base de données, pas sur l'ajout de fonctionnalités.

Comment l'équipe produit déploie-t-elle sans SeedVision ?

Elle emprunte la même chaîne d'intégration continue, dont le cycle est ramené sous les 30 minutes. Le manuel d'exploitation est corrigé à chaque changement de procédure et c'est l'équipe produit qui l'exécute : un manuel jamais rejoué serait faux le jour où il servirait.

Ce fonctionnement est-il transposable à une plateforme construite par quelqu'un d'autre ?

Oui, c'est l'objet de l'offre Run et maintenance : une semaine de reprise sert à auditer le code, le manuel d'exploitation et les dépendances avant tout engagement d'astreinte. Si la dette technique est trop lourde, une remise à niveau est proposée avant l'exploitation.

Offres associées

Réalisations proches

À lire sur le blog

Parler de votre projet

Un enjeu proche de KizzyDance ? Écrivez à contact@seedvision.fr : réponse sous 24 h.