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 plus d'un client/équipe/marque dans les 3-5 prochaines années ?

• Oui (même hypothétiquement) → prêt pour le multi-tenant dès le jour 1
• Pas sûr → architecture prête pour le multi-tenant, 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, image de marque personnalisée par tenant
• Non → single-tenant ok

1. Exigence de conformité en matière d'isolation des données entre clients ?

• Oui (santé RGPD Art. 9, finance) → schéma par tenant ou base de données par tenant
• Business standard → la sécurité au niveau des lignes dans PostgreSQL suffit

Défaut DV : chaque application web a une architecture prête pour le multi-tenant (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 la mise à l'échelle, mais les goulots d'étranglement apparaissent à des seuils précis :

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

1 000-10 000 utilisateurs : réplique PostgreSQL en lecture seule en option pour les rapports (décharge du 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 : mise à l'échelle horizontale (répartiteur de charge + 2-4 serveurs d'application), répliques de lecture PostgreSQL, traitement de files d'attente (BullMQ + Redis), mise en cache en périphérie (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 d'architecture des modules clés (sharding, microservices où cela a du sens, équipe infrastructure dédiée). DV aide dans les décisions, mais en réalité, une application à 100k+ utilisateurs, c'est souvent une autre société opératrice qu'à 10k.

La base de données (PostgreSQL) évolue jusqu'à 1M+ utilisateurs sans refonte d'architecture, si les requêtes sont bien indexées et les schémas 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 contre la dépendance à un fournisseur :

Frameworks open source :

• Next.js (licence MIT) — utilisé par Netflix, TikTok, Twitch — zéro risque de « mainteneur qui abandonne »
• Payload CMS (licence MIT) — propriété de la plateforme CMS, vous pouvez l'héberger où vous voulez
• PostgreSQL (licence PostgreSQL) — base de données relationnelle la plus utilisée en production, vous trouverez des développeurs PostgreSQL partout

Pas de bibliothèques propriétaires 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 « console cloud DV »

Le code dans votre dépôt :

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

Cas réel de notre pratique : 2 clients sont passés à une équipe interne 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é).

La seule « dépendance » réside dans le choix d'architecture — si l'application est construite sur Next.js, migrer vers Vue/Angular nécessite de réécrire le frontend. Ce n'est pas propre à DV — chaque agence crée ce type de « dépendance ». DV vs la concurrence : nous choisissons des frameworks avec 5+ ans de track record, pas suivant la mode (Stack stable — Bloc 7 du hub /tworzenie-oprogramowania).

RGPD Art. 9 (données sensibles — santé, données biométriques) : Oui. La base DV (chiffrement au repos, journal d'audit, RBAC, authentification multi-facteurs) couvre les exigences principales. Le Discovery (étape 02) inclut une analyse d'écart RGPD — ce dont l'application a besoin en plus (par ex. politiques de conservation spécifiques, gestion du consentement, support DPIA). En pratique, 4-6 projets RGPD Art. 9 réalisés, principalement santé et RH.

Réglementation financière : Partiellement. La base d'application web DV couvre la sécurité et l'audit, mais la conformité réglementaire financière spécifique nécessite souvent un consultant en conformité externe. DV travaille en mode collaboration — nous construisons l'application, le client + une société de conformité 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 d'entreprise (monitoring continu, procédures de réponse aux incidents, formation des employés, sécurité physique du centre de données) — pas seulement une application web. DV construit l'application avec des contrôles techniques prêts pour SOC2 (journal d'audit, chiffrement, contrôle d'accès), mais la certification est du ressort du client ou d'une société d'audit SOC2 externe.

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

Oui, mais de manière sélective. La migration d'un système existant représente souvent 60-80 % du budget d'une nouvelle application, et n'a de sens que si le système existant bloque réellement le business.

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 qui communique avec le backend existant via une API. Durée : 8-12 semaines. Risque : faible. ROI : rapide (le client voit une interface moderne en 2-3 mois).

2. Migration progressive (pattern strangler) : 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é, moins de perturbation pour le business.

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 des données, formation des utilisateurs, stratégie de retour arrière). ROI : à long terme, mais nécessite un business case 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 » dans du code legacy existant (périmètre freelance)
• Reconstruction sans business case clair (sur mesure pour du 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 le même backend sans réécrire la logique business.

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

• Logique business (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 nécessaire)
• Déploiement App Store / Play Store

Calendrier typique pour ajouter le mobile :

• 6-10 semaines pour une app compagnon (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 : dès 20 000 CHF (compagnon) à 75 000+ CHF (sur mesure complet)

Natif (Swift/Kotlin) : Uniquement pour des exigences précises (graphisme avancé, fonctions 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 ateliers mobiles spécialisés.

Vous pouvez héberger où vous voulez. DV n'exige 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 pour la maintenance technique séparément (225-750 CHF/mois). Vous avez l'accès root.

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

• Images Docker de l'application
• Runbook de déploiement (étape par étape comment déployer)
• 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 les clients entreprise ou les sociétés 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 :

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