Une application web pour l'entreprise qui a dépassé les tableurs

Trois critères de décision :

1. L'application va-t-elle servir >1 client/équipe/marque dans les 3-5 prochaines années ?

• Oui (même hypothétiquement) → multi-tenant ready dès le jour 1
• Pas sûr → architecture multi-tenant ready, mais déploiement single-tenant (défaut DV)
• Définitivement non → single-tenant (rare en pratique)

1. L'application doit-elle un jour être en marque blanche pour des revendeurs ?

• Oui → multi-tenant requis, branding sur mesure par tenant
• Non → single-tenant ok

1. Exigence de conformité imposant l'isolation des données entre clients ?

• Oui (médecine RGPD Art. 9, finance réglementée) → schema-per-tenant ou database-per-tenant
• Business standard → row-level security dans PostgreSQL suffit

Défaut DV : chaque application web a une architecture multi-tenant ready (tenant_id dans le schéma, RLS), même si le déploiement est single-tenant. Conversion single → multi en 1-2 sprints au lieu d'une refonte de 6 mois.

L'architecture DV est conçue pour le scaling, mais des goulots d'étranglement apparaissent à des seuils précis :

100-1 000 utilisateurs : zéro changement d'infrastructure, 1 VPS (4-8 Go de RAM, 2-4 vCPU) suffit. Coût 50-150 CHF/mois.

1 000-10 000 utilisateurs : réplique PostgreSQL en lecture seule optionnelle pour les rapports (décharge la base primaire), cache Redis pour les requêtes fréquentes, CDN pour les assets statiques. Migration en 1-2 sprints. Coût d'infrastructure 250-750 CHF/mois.

10 000-100 000 utilisateurs : scaling horizontal (load balancer + 2-4 serveurs d'application), répliques PostgreSQL en lecture, traitement de files (BullMQ + Redis), edge caching (Cloudflare). L'architecture ne nécessite pas de réécriture — la structure modulaire dès le jour 1 permet de faire évoluer les éléments séparément. Coût 1 000-4 000 CHF/mois.

100 000+ utilisateurs : décision au cas par cas — nécessite généralement une refonte architecturale des modules clés (sharding, microservices là où c'est pertinent, équipe infrastructure dédiée). DV aide dans les décisions, mais dans les faits une application à 100k+ utilisateurs relève souvent d'une autre entreprise opératrice qu'une à 10k.

La base de données (PostgreSQL) monte en charge jusqu'à 1M+ utilisateurs sans refonte architecturale, si les requêtes sont bien indexées et les modèles d'accès prévisibles.

Réponse courte : non, le stack est open-source, le code est à vous.

Réponse longue — ce qui protège concrètement du lock-in :

Frameworks open-source :

• Next.js (licence MIT) — utilisé par Netflix, TikTok, Twitch — zéro risque de « maintainer qui abandonne »
• Payload CMS (licence MIT) — plateforme CMS que vous possédez, hébergeable où vous voulez
• PostgreSQL (licence PostgreSQL) — base de données relationnelle la plus utilisée en production, vous trouverez des développeurs PostgreSQL partout

Aucune bibliothèque propriétaire DV :

• Chaque dépendance dans package.json a un registre npm public
• Zéro « DV Framework » ou « DV Auth Library » absent de npm
• Configuration de déploiement dans le dépôt git, pas dans une « DV Cloud Console »

Code dans votre dépôt :

• GitHub/GitLab, votre licence
• Historique git complet disponible
• Changement de développeur/agence = pull request, pas « récupération du code depuis le cloud DV »

Cas réel de notre pratique : 2 clients sont passés à une équipe in-house après 18-24 mois. Le développeur senior s'est retrouvé dans le code en 1-2 semaines (Next.js + PostgreSQL = standard du marché).

Le seul « lock-in » réside dans le choix architectural — si l'application est construite sur Next.js, migrer vers Vue/Angular nécessite de réécrire le frontend. Ce n'est pas spécifique à DV — chaque agence crée ce type de « lock-in ». DV vs la concurrence : nous choisissons des frameworks avec 5+ ans de track record, pas guidés par le hype (Stack stable — Bloc 7 du hub /tworzenie-oprogramowania).

RGPD Art. 9 (données sensibles — médecine, données biométriques) : Oui. Le socle DV (chiffrement au repos, journal d'audit, RBAC, authentification à plusieurs facteurs) couvre les exigences essentielles. Le Discovery (Étape 02) inclut une analyse d'écart RGPD — ce dont l'application a besoin en plus (par ex. politiques de rétention spécifiques, gestion du consentement, support DPIA). Concrètement, 4-6 projets RGPD Art. 9 réalisés, principalement médecine et RH.

Réglementation financière (secteur bancaire/financier) : Partiellement. Le socle de l'application web DV couvre la sécurité et l'audit, mais la conformité réglementaire spécifique au secteur financier nécessite souvent un consultant en conformité externe. DV travaille en mode collaboration — nous construisons l'application, le client + un cabinet de conformité financière valident. 1-2 projets fintech réalisés (pas de banking complet, mais adjacent — fintech B2B, plateforme de prêt).

SOC2 / ISO 27001 : Pas par défaut. Ces audits nécessitent des processus opérationnels de l'entreprise (monitoring continu, procédures de réponse aux incidents, formation des employés, sécurité physique du data center) — pas uniquement une application web. DV construit l'application avec des contrôles techniques SOC2-ready (journal d'audit, chiffrement, contrôle d'accès), mais la certification revient au client ou à un cabinet d'audit SOC2 externe.

HIPAA / conformité GDPR US : Non. DV travaille sur les marchés Pologne / UE / Suisse. Pour la conformité santé américaine, nous recommandons des cabinets spécialisés.

Oui, mais de façon sélective. La migration d'un système legacy représente souvent 60-80% du budget d'une nouvelle application, et le résultat n'a de sens que si le système existant bloque réellement l'activité.

Trois scénarios de migration que nous réalisons :

1. Migration UI/frontend, le backend reste : Le cas le plus fréquent. L'ancien monolithe PHP/Java/.NET reste, nous ajoutons un nouveau frontend Next.js communiquant avec le backend existant via API. Durée : 8-12 semaines. Risque : faible. ROI : rapide (le client voit une interface moderne en 2-3 mois).

2. Migration progressive (strangler pattern) : L'ancien système reste en production, de nouveaux modules en Next.js + Payload remplacent les modules legacy un par un. Durée : 12-24 mois. Risque : moyen. ROI : étalé, moindre disruption métier.

3. Migration complète (reconstruction) : L'ancien système est archivé (lecture seule), le nouveau système remplace 100% des fonctionnalités. Durée : 16-32 semaines. Risque : élevé (migration de données, formation des utilisateurs, stratégie de rollback). ROI : à long terme, mais nécessite un business case avec ROI sur 3-5 ans.

Ce que nous NE faisons PAS :

• Migration d'un stack que DV n'utilise pas en production (Java legacy, Ruby on Rails legacy, mainframe sur mesure)
• « Petites corrections » sur du code legacy existant (périmètre freelance)
• Reconstruction sans business case clair (sur mesure pour le sur mesure = échec)

Oui — et nous le faisons souvent. L'application web DV est conçue API-first (Next.js API Routes ou backend dédié). L'application mobile peut utiliser ce même backend sans réécrire la logique métier.

Stack mobile : React Native (Expo) — réutilisation de code de 60-80% depuis l'application web React/Next.js. Partagé :

• Logique métier (TypeScript)
• Client API
• Schémas de validation (Zod)
• Définitions de types

Ce qui est spécifique au mobile :

• Composants UI (patterns mobiles, gestion des gestes)
• Notifications push (FCM/APNs)
• Mode hors ligne (si requis)
• Déploiement App Store / Play Store

Calendrier typique pour ajouter le mobile :

• 6-10 semaines pour une companion app (lit/modifie les mêmes données que l'app web)
• 12-16 semaines pour un mobile riche en fonctionnalités (hors ligne, push, intégration matérielle)
• Prix : à partir de 20 000 CHF (companion) jusqu'à 75 000+ CHF (sur mesure complet)

Natif (Swift/Kotlin) : Uniquement pour des exigences précises (graphisme avancé, fonctionnalités critiques en performance, intégration matérielle comme BLE/NFC). En pratique, DV fait du React Native dans 80%+ des projets mobiles. Pour du natif, nous recommandons des shops mobiles spécialisés.

Vous pouvez héberger où vous voulez. DV n'impose pas de déploiement sur sa propre infrastructure.

Trois modèles de déploiement :

1. VPS géré par DV (le plus fréquent, 70% des projets) : DV met en place le VPS sur votre compte, le configure, monitoring, sauvegardes. Vous payez le VPS directement (40-100 CHF/mois), DV facture la maintenance technique séparément (225-750 CHF/mois). L'accès root est à vous.

2. Géré par le client (votre infrastructure) : Votre équipe IT gère l'infrastructure — VPS propre, serveur on-premises, cluster Kubernetes. DV transmet :

• Images Docker de l'application
• Runbook de déploiement (étape par étape)
• Scripts de migration de base de données
• Modèle de configuration (variables d'environnement, secrets)
• 1-2 sessions de transfert de connaissances pour votre équipe

Le plus souvent pour des clients enterprise ou des entreprises avec une équipe DevOps dédiée.

3. Cloud (AWS / GCP / Azure) : Si le client a déjà un écosystème cloud. DV déploie l'application sur votre compte cloud, configuration IaC (Terraform/Pulumi) dans le dépôt git, vous contrôlez la facturation et les accès.

Points clés :

• Code dans votre dépôt git — indépendamment du modèle de déploiement
• Sauvegardes de base de données dans votre stockage cloud — zéro rétention sur l'infrastructure DV
• Secrets (clés API, mots de passe) dans votre gestionnaire de secrets — DV ne conserve pas les identifiants clients à long terme
• Chemin de migration — le passage de géré par DV → géré par le client est toujours possible (export des images Docker + dump de base de données + configuration)