Le Cloud Privé d’Entreprise : Déployer et administrer son propre cluster de stockage cloud avec Nextcloud Hub et Object Storage (S3)

Pourquoi créer un cloud privé d’entreprise (plutôt que « tout mettre sur Google Drive ») ?

On a tous vécu ce moment. Au début, Google Drive ou OneDrive suffit. Deux dossiers partagés, trois fichiers Excel, ça roule. Puis l’entreprise grossit, les projets s’empilent, les fichiers deviennent lourds, sensibles, parfois carrément critiques. Et là, sans prévenir, le stockage « simple » se transforme en sujet politique, juridique et technique.

Parce que les données explosent. Contrats, plans, exportations comptables, dossiers RH, échanges clients, photos terrain, rendus vidéo. Et parce que la collaboration interne n’est plus un plaisir à avoir. On doit co-éditer, commenter, versionner, retrouver. Sans perdre le contrôle.

C’est souvent là que l’intention devient très claire : souveraineté, contrôle des accès, localisation des données, audit. Pas juste « un endroit pour mettre des fichiers ». Un système qu’on peut expliquer à un DPO, à un RSSI, ou à un auditeur. Et surtout, qu’on peut maîtriser.

Cloud public vs cloud privé : la différence concrète

Un cloud public, c’est pratique. Mais la responsabilité est partagée. Vous dépendez du fournisseur pour les évolutions, les règles, l’observabilité fine, et parfois même la façon don’t les liens de partage se comportent. Vous payez aussi pour des choses que vous n’utilisez pas, ou à l’inverse vous découvrez des coûts quand tout le monde s’y met d’un coup.

Un cloud privé, lui, vous remet au centre. Vous choisissez où sont les données, qui y accède, comment ça s’audite, comment ça se sauvegarde. Vous pouvez imposer vos règles. Et vous pouvez faire évoluer l’architecture selon votre réalité.

Cas d’usage typiques (ceux qui reviennent tout le temps)

• Partage sécurisé interne, avec règles strictes par équipe ou par projet.
• Extranet client, avec dossiers par client, expiration des liens, traçabilité.
• Dossiers RH et juridiques, avec accès très limités, et audit.
• Données R&D, parfois volumineuses, parfois confidentielles, souvent les deux.
• Remplacement d’un serveur de fichiers vieillissant, sans perdre le confort moderne (web, mobile, sync).

Et donc, la promesse de cet article, c’est simple : déployer Nextcloud Hub avec un stockage objet S3 en architecture « cluster », puis l’administrer proprement. Pas un bricolage du vendredi soir. Un truc qui peut tenir en prod.

Le piège classique : installer Nextcloud « sur un seul serveur » et le regretter plus tard

Installer Nextcloud sur une VM unique avec un disque local, ça marche. Pendant un moment. C’est même séduisant. Un docker run, un volume, et hop.

Le problème, c’est que ce modèle monolithique a des limites très réelles :

• Le disque local devient le goulot d’étranglement. I/O, latence, saturation.
• Le serveur devient un SPOF. Une panne, et tout tombe.
• Les sauvegardes deviennent lourdes. Très lourdes. Et lentes.
• Les migrations deviennent douloureuses. Déplacer des téraoctets de fichiers, refaire des droits, gérer les verrous, les indexations, les miniatures. On perd des week ends.

En production, on voit souvent les mêmes symptômes : lenteurs sur les previews, uploads qui time out, base de données qui chauffe, cron qui ne tourne pas correctement, sauvegardes impossibles à restaurer vite.

Pourquoi séparer calcul et stockage

Quand on sépare le calcul (les serveurs Nextcloud) du stockage (S3), on gagne sur plusieurs tableaux :

• Élasticité : on peut ajouter des nœuds Nextcloud si la charge monte.
• Durabilité : le stockage objet est conçu pour encaisser la perte de disques, voire de nœuds.
• Coût et opérations : le stockage devient un service à part, optimisé, monitoré, avec ses politiques.
• Simplicité cluster : plusieurs nœuds Nextcloud peuvent servir les mêmes fichiers, sans monter un gros NFS fragile.

L’architecture cible du guide, c’est donc une application Nextcloud potentiellement en plusieurs instances, une base de données solide, Redis pour éviter les ennuis de verrous, et un stockage objet S3 pour les fichiers. Le tout derrière un reverse proxy ou un load balancer si besoin.

Architecture recommandée : nextcloud hub + object storage (S3) + base de données + cache

On va poser les briques clairement, sans se perdre dans le jargon.

Les composants

• Nextcloud Hub : l’application web, les API, WebDAV, les apps (Talk, Groupware, etc.).
• Base de données : MariaDB ou PostgreSQL. Elle stocke les métadonnées, pas les fichiers eux mêmes.
• Redis : cache et surtout verrouillage des fichiers. Essentiel en cluster.
• Stockage objet S3 : les fichiers utilisateurs, les versions, les chunks d’upload.
• Reverse proxy / load balancer (optionnel mais fréquent) : terminaison TLS, routage, limites d’upload, HTTP/2.

Ce que Nextcloud stocke où (important, vraiment)

• Les fichiers vont sur S3 (si on utilise le mode primary object store).
• Les métadonnées (arborescence, partages, utilisateurs, tags, activités, etc.) vont en base.
• Les verrous et caches vont dans Redis.

Ça veut dire un truc très concret : si votre S3 est lent, l’expérience utilisateur est lente. Si votre DB est en souffrance, l’interface est lente. Si Redis est mal configuré, vous aurez des verrous bizarres, voire des corruptions logiques sur certaines opérations.

Option « cluster »

Le mode cluster, c’est plusieurs nœuds Nextcloud identiques derrière un reverse proxy ou un load balancer. Même code, même config, même accès DB, même Redis, même S3. Et on scale horizontalement.

On prem vs cloud souverain

Pour S3, deux grandes familles :

• On prem : MinIO ou Ceph, dans votre infra. Contrôle maximal.
• Fournisseur S3 compatible : cloud souverain ou provider compatible S3. Moins d’ops stockage, mais dépendance réseau et contrat.

Schéma narratif (le flux)

Un upload typique :

1. L’utilisateur envoie un fichier via web ou WebDAV vers Nextcloud.
2. Nextcloud écrit des métadonnées en base, pose des verrous via Redis.
3. Nextcloud pousse le contenu en multipart vers S3.
4. Nextcloud valide, met à jour l’index, déclenche previews et activités.

Un download :

1. L’utilisateur demande le fichier.
2. Nextcloud vérifie droits et liens.
3. Nextcloud lit sur S3 et renvoie, ou génère une preview si nécessaire.

Pré requis et décisions avant de déployer (ce qui fait gagner des semaines)

C’est la partie qu’on zappe, puis qu’on paye. Donc on ne la zappe pas.

Dimensionnement

Questions simples à se poser :

• Combien d’utilisateurs actifs, pas juste des comptes créés ?
• Volumétrie à 12 mois, à 24 mois.
• Pic d’activité : lundi matin, clôture de mois, période fiscale.
• Petits fichiers (beaucoup de métadonnées) ou gros fichiers (débit, multipart, timeouts) ?

En général, les petits fichiers font souffrir la base et les indexations. Les gros fichiers font souffrir le réseau, les timeouts, et le reverse proxy.

Réseau

• Latence entre Nextcloud et S3 : critique. Sur site, viser très bas. En cloud, tester.
• Débit interne : surtout si sync clients et uploads lourds.
• MTU, VLAN, routes, DNS. Les « petits » soucis réseau deviennent des bugs aléatoires.
• HTTPS obligatoire. Et pas juste « pour faire joli ».

Sécurité

• Modèle d’identité : LDAP/AD, SSO, ou local.
• MFA/2FA.
• Segmentation réseau : qui peut parler à la DB, à Redis, à S3.
• Moindre privilège : surtout pour les clés S3 et les comptes admin.

Gouvernance

• Politique de rétention et classification des données.
• Journaux, audit, conservation des logs.
• Règles de partage : expiration, mots de passe, domaines autorisés.

Versions à viser (exemple de cible raisonnable)

• Nextcloud Hub en version supportée (et cohérente avec vos apps).
• PHP selon pré requis Nextcloud (souvent imposé par l’image officielle).
• PostgreSQL récent ou MariaDB récent.
• Redis stable.
• MinIO ou Ceph dans une version supportée.

Le point n’est pas la version exacte ici. Le point, c’est d’éviter les mélanges hasardeux.

Déployer le stockage objet S3 (MinIO ou Ceph) : la base d’un cluster robuste

Le stockage, c’est le socle. Si vous le ratez, tout le reste devient une rustine.

MinIO vs Ceph (choix pragmatique)

• MinIO : plus simple à déployer, excellent pour beaucoup de contextes PME et ETI, très bon en performance. On peut le mettre en mode distribué pour la HA.
• Ceph : plus complexe, mais taillé pour la grande échelle, avec une vraie histoire de cluster stockage, et une intégration solide dans des environnements plus « infra ».

Si vous voulez un guide simple, MinIO est souvent le meilleur premier pas. Si vous avez déjà Ceph en place, ou une équipe stockage, Ceph est pertinent.

Bonnes pratiques buckets

• Un bucket dédié pour Nextcloud.
• Nom simple, stable, sans le changer plus tard.
• Versioning si possible, surtout pour se protéger des suppressions et ransomware.
• Lifecycle policies si vous voulez gérer l’archivage, ou purger des anciennes versions.

Réplication et durabilité

• MinIO distribué : prévoir anti affinité entre nœuds, disques distincts, et idéalement racks distincts si possible.
• Ceph : choisir réplication ou erasure coding selon objectifs. L’erasure coding optimise capacité, la réplication simplifie certains cas.

Chiffrement

• En transit : TLS entre Nextcloud et S3 si possible.
• Au repos : SSE côté S3, ou chiffrement disque côté stockage. Les deux existent, mais ça a un coût en perf et en complexité de clés.

Tests rapides avant d’installer Nextcloud

Avant même de parler Nextcloud :

• Tester upload et download avec un client S3 (mc pour MinIO, awscli, rclone).
• Tester latence.
• Tester un gros fichier en multipart.
• Vérifier taille max, timeouts, et comportement en cas de coupure réseau.

Si ces tests sont mauvais, Nextcloud ne va pas les rendre magiques.

Installer nextcloud hub : approche « prod ready » (docker/compose ou kubernetes)

Deux voies, et on reste lisible.

Option 1 : docker compose (souvent le bon compromis)

Pour beaucoup d’entreprises, Docker Compose suffit. On peut isoler les services, gérer les upgrades, et documenter.

Socle typique :

• nextcloud (web)
• cron (conteneur dédié ou cron système)
• db (PostgreSQL ou MariaDB)
• redis
• reverse proxy (nginx, traefik, caddy)

Points critiques en prod :

• Limites PHP : memory_limit, upload_max_filesize, post_max_size, max_execution_time.
• Timeouts reverse proxy : uploads WebDAV, gros fichiers, clients mobiles.
• Cron : le cron système est recommandé. Le mode AJAX est à éviter en entreprise.
• Stockage des volumes applicatifs : config, apps, thèmes. Même si les fichiers vont sur S3, ces éléments doivent être persistants et partagés si cluster.

Option 2 : kubernetes (si vous visez HA et industrialisation)

Kubernetes apporte des primitives utiles : déploiement multi réplicas, probes, secrets, ingress, rolling update. Mais il impose une discipline, et un minimum de maturité.

Dans ce cas, on vise :

• Nextcloud en plusieurs replicas
• DB managée ou opérée correctement
• Redis HA si nécessaire
• S3 externe au cluster Kubernetes, ou opéré à part

Gestion des secrets

Évitez de laisser des secrets en clair dans un compose ou dans un repo.

• Compose : fichiers .env protégés, Docker secrets si possible.
• Kubernetes : secrets chiffrés, voire un vault ou secret manager.

Mises à jour

Stratégie simple :

• Un environnement staging.
• Fenêtres de maintenance.
• Vérification compatibilité des apps Nextcloud Hub.
• Snapshot ou backup avant upgrade.

Les upgrades Nextcloud ratés, ça arrive surtout quand on met à jour « au hasard » sans vérifier apps et versions.

Connecter nextcloud au stockage objet S3 (primary storage) : configuration pas à pas

Il y a deux façons d’utiliser S3 avec Nextcloud :

• Stockage externe : vous ajoutez un stockage S3 comme un mount. Utile, mais ce n’est pas le cœur.
• Primary object store : les fichiers de Nextcloud sont stockés nativement dans S3. C’est ce qu’on veut ici.

Pourquoi ? Parce que c’est ce qui permet d’avoir des nœuds Nextcloud stateless côté fichiers. Et donc du cluster propre.

Paramètres S3 essentiels

Vous aurez besoin, selon votre S3 :

• Endpoint (URL du service S3)
• Région (parfois fictive, mais requise)
• Bucket
• Access key et secret key
• Path style vs virtual host style
• SSL : activé si vous avez TLS

Selon l’implémentation, MinIO utilise souvent le path style, surtout en on prem, parce que le DNS wildcard n’est pas toujours là.

Droits minimaux IAM (moindre privilège)

L’idée : donner à Nextcloud uniquement ce qu’il doit faire.

Typiquement, il lui faut de quoi :

• Lister le bucket et certains prefixes
• Lire, écrire, supprimer des objets
• Gérer multipart upload

La liste exacte dépend du système IAM. Mais le principe reste : pas de droits admin globaux sur tout votre S3.

Vérifications post config

Après activation du primary object store :

• Créer un fichier, le retrouver.
• Uploader un gros fichier (plusieurs Go si c’est votre réalité).
• Tester un partage externe, puis un accès via WebDAV.
• Vérifier previews et miniatures. Si ça rame, regarder la latence S3.

Pièges courants

• Horloge : NTP. Un décalage de temps peut casser des signatures S3.
• Certificats : CA non reconnue si vous utilisez un TLS interne.
• DNS : surtout en virtual host style.
• Permissions bucket : erreurs 403 masquées par des messages flous.
• Timeouts proxy : le fichier arrive à 95 % puis échoue. Classique.

Rendre l’ensemble « cluster ready » : haute disponibilité et montée en charge

C’est là que l’architecture devient vraiment intéressante.

Plusieurs nœuds nextcloud

On déploie 2 nœuds ou plus, identiques.

À gérer :

• Config identique sur tous les nœuds (config.php, apps, thèmes).
• Sessions : soit sticky sessions au niveau load balancer, soit stockage de session partagé. Le sticky est souvent plus simple, mais attention aux maintenances.
• Stockage local minimal : pas de fichiers utilisateurs en local, sinon incohérences.

Redis pour le verrouillage de fichiers

Redis n’est pas un détail. En cluster, c’est même une condition.

• Il évite des conflits sur accès concurrents.
• Il améliore les performances sur certaines opérations.
• Il réduit les risques de fichiers « bloqués » ou de comportements étranges lors des sync.

Reverse proxy / load balancer

Rôle :

• TLS termination
• HTTP/2
• Limites upload
• WebDAV friendly (certains réglages nginx sont incontournables)
• Routage vers les nœuds Nextcloud

Gardez en tête que ce composant voit passer tout le trafic. Il doit être dimensionné et monitoré.

Stockage S3 et HA

La HA du stockage, c’est côté MinIO ou Ceph, pas côté Nextcloud.

• Surveiller la santé des nœuds.
• Tester la perte d’un nœud.
• Vérifier que les opérations restent stables en mode dégradé.

Stratégie de scaling

• Vous scalez Nextcloud si vous manquez de CPU ou si vous avez beaucoup de connexions simultanées.
• Vous scalez la DB si les requêtes explosent (souvent un vrai sujet).
• Vous scalez S3 si vous manquez de débit, de capacité, ou de durabilité.

Le piège, c’est de tout scaler sauf la base, puis se demander pourquoi ça reste lent.

Sécuriser un cloud privé nextcloud : durcir sans casser l’usage

La sécurité, ce n’est pas juste cocher des cases. C’est maintenir l’utilisabilité. Si c’est trop contraignant, les gens contournent.

Contrôles d’accès

• LDAP/AD avec groupes cohérents.
• Règles de partage : expiration automatique des liens, mot de passe obligatoire selon contexte.
• Restrictions de domaines pour les partages externes, si nécessaire.
• Droits par dossier, et modèles de permissions par équipe.

Authentification forte

• 2FA pour les comptes sensibles, idéalement pour tous.
• SSO SAML ou OIDC selon votre SI.
• Politiques de mot de passe si vous avez des comptes locaux.

Journalisation et audit

• Logs d’accès, logs d’activité, traçabilité des partages.
• Alertes : connexions inhabituelles, pics de suppression, échecs répétés.

Protection réseau

• WAF ou à minima rate limiting.
• fail2ban si exposition internet.
• Segmentation : DB et Redis jamais exposés publiquement.
• Accès admin restreint (VPN, bastion, IP allowlist).

Gestion des apps

Installer moins, c’est mieux.

• Valider les apps nécessaires.
• Suivre les mises à jour.
• Désactiver ce qui n’est pas utilisé.

Certaines apps ajoutent des surfaces d’attaque, ou des dépendances qui compliquent les upgrades.

Sauvegardes et restauration : le plan qui compte vraiment le jour de la panne

On va le dire clairement : la haute dispo n’est pas une sauvegarde.

La HA vous protège de certaines pannes matérielles. Elle ne vous protège pas d’une suppression massive, d’un ransomware, ou d’une erreur humaine.

Ce qu’il faut sauvegarder

• Base de données : indispensable.
• config Nextcloud : config.php, paramètres, trusted domains.
• apps et personnalisations : selon votre mode de déploiement.
• clés et chiffrement : si vous utilisez des mécanismes de chiffrement, c’est vital.
• côté S3 : versioning, réplication, snapshots selon solution.

Le vrai danger, c’est d’avoir une super sauvegarde des fichiers mais pas de la base. Ou l’inverse. Il faut les deux.

Tests de restauration

Documentez une procédure. Puis testez la. Vraiment.

• RTO : combien de temps pour revenir.
• RPO : combien de données perdues acceptables.
• Exercice trimestriel si c’est critique.

Scénarios à prévoir

• Suppression massive (erreur ou malveillance).
• Ransomware qui chiffre via un client sync.
• Corruption DB.
• Perte d’un nœud S3.
• Perte d’un nœud Nextcloud.

Checklist de restauration « à froid »

Ordre typique :

1. Restaurer et valider S3 (ou capacité à relire les objets).
2. Restaurer la base de données.
3. Restaurer config et secrets.
4. Redémarrer Redis.
5. Redémarrer Nextcloud.
6. Lancer les commandes de maintenance nécessaires, vérifier l’intégrité, puis rouvrir aux utilisateurs.

Supervision, performance et maintenance au quotidien

Un cloud privé, ça vit. Et si vous ne le surveillez pas, il vous surprend.

Indicateurs clés

• Temps de réponse Nextcloud (p95, p99 si vous pouvez).
• Latence vers S3.
• Erreurs 5xx et 4xx (surtout 401, 403, 429).
• Saturation DB : CPU, locks, slow queries.
• Redis : mémoire, latence, connexions.
• Reverse proxy : erreurs, timeouts, taille des uploads.

Outils

• Logs Nextcloud (et logs web server).
• Metrics Prometheus et dashboards Grafana si possible.
• Alerting : pas 200 alertes, juste les bonnes.
• Santé des buckets, capacité, erreurs S3.

Hygiène ops

• Rotation des logs.
• Mises à jour planifiées.
• Revue régulière des droits et groupes.
• Rotation des clés S3.
• Nettoyage des vieux comptes, liens de partage, règles obsolètes.

Gestion de capacité

• Courbe de croissance.
• Lifecycle policies côté S3 pour l’archivage ou la purge des versions.
• Stratégie d’extension : ajouter des nœuds, des disques, ou migrer vers une classe de stockage différente.

Runbook

Écrivez un runbook simple :

• DB lente : où regarder, quoi redémarrer ou pas, quels logs.
• Verrous : comment diagnostiquer Redis, comment éviter les solutions destructrices.
• Timeouts upload : proxy, PHP, S3 multipart.
• S3 dégradé : comment basculer, comment réduire l’impact.

Le runbook sert surtout à 3 h du matin. Donc il doit être lisible.

Déploiement type en 7 étapes (résumé actionnable)

1. Valider dimensionnement, réseau, DNS, TLS. Décider du modèle d’identité (LDAP ou SSO).
2. Déployer l’object storage S3 (MinIO ou Ceph), configurer bucket, versioning, politiques. Tester avec un client S3.
3. Déployer base de données et Redis, avec persistance et sauvegardes.
4. Installer Nextcloud Hub en mode prod ready (Compose ou Kubernetes), configurer cron, proxy, limites upload.
5. Activer S3 en primary storage, puis re tester : gros fichiers, partage, WebDAV, previews.
6. Passer en cluster : 2 nœuds Nextcloud ou plus derrière reverse proxy ou load balancer. Vérifier sessions, config identique, Redis lock.
7. Ajouter sécurité, supervision, runbook, et surtout tests de restauration. Puis seulement après, ouvrir plus largement aux utilisateurs.

Oui, l’étape 5 arrive « tard ». Mais c’est volontaire. On veut un S3 solide avant de brancher l’app.

Conclusion : quand cette architecture est le bon choix (et quand elle ne l’est pas)

Cette architecture Nextcloud Hub + S3 en primary storage + DB + Redis, avec option cluster, c’est un bon choix quand vous voulez du contrôle. Conformité, souveraineté, audit, scalabilité, et des opérations plus propres. Et aussi une trajectoire. Vous pouvez commencer simple, puis ajouter des nœuds, durcir, industrialiser.

Signaux que c’est pertinent :

• Exigences RGPD, sectorielles, clients grands comptes.
• Besoin de haute disponibilité.
• Volume de données important, ou croissance rapide.
• Autonomie IT, envie de maîtriser et d’expliquer votre chaîne de responsabilité.

Signaux que ce n’est pas prioritaire :

• Petite équipe sans admin système, sans temps, sans astreinte.
• Besoins faibles, peu de sensibilité data.
• Forte tolérance au cloud public et au modèle « on paie et on oublie ».

Prochaine action recommandée : partir d’un POC. Un vrai POC, pas une VM jetable. Documenter, automatiser (IaC si possible), puis industrialiser. Et à chaque étape, garder cette idée en tête : ce n’est pas juste installer Nextcloud. C’est construire un service interne. Un service qui doit tenir, et qui doit se restaurer.

Questions fréquemment posées

Pourquoi créer un cloud privé d’entreprise plutôt que d’utiliser uniquement Google Drive ?

Au début, Google Drive suffit pour stocker quelques fichiers, mais à mesure que l’entreprise grandit, les données deviennent volumineuses, sensibles et critiques. Un cloud privé offre souveraineté, contrôle des accès, localisation des données et auditabilité, essentiels pour répondre aux exigences juridiques et techniques, contrairement à une simple solution de stockage en ligne.

Quelle est la différence concrète entre un cloud public et un cloud privé ?

Le cloud public est pratique mais la responsabilité est partagée avec le fournisseur, ce qui limite le contrôle sur les évolutions, la sécurité et les coûts. Le cloud privé remet l’entreprise au centre : elle choisit où sont stockées les données, qui y accède, comment elles sont auditées et sauvegardées, avec la possibilité d’imposer ses propres règles.

Quels sont les cas d’usage typiques pour un cloud privé avec Nextcloud Hub ?

Les usages fréquents incluent le partage sécurisé interne avec règles par équipe ou projet, un extranet client avec traçabilité et expiration des liens, la gestion sécurisée des dossiers RH et juridiques, le stockage de données R&D volumineuses et confidentielles, ainsi que le remplacement d’un serveur de fichiers vieillissant tout en conservant confort moderne (web, mobile, synchronisation).

Quels sont les pièges à éviter lors de l’installation de Nextcloud ?

Installer Nextcloud sur un seul serveur avec disque local peut fonctionner temporairement mais crée rapidement des limitations : goulot d’étranglement disque, point de défaillance unique (SPOF), sauvegardes lourdes et lentes, migrations complexes. Cela conduit souvent à des problèmes de performance et de fiabilité en production.

Pourquoi est-il important de séparer le calcul (serveurs Nextcloud) du stockage (S3) ?

Séparer calcul et stockage permet une élasticité accrue (ajout facile de nœuds Nextcloud), une meilleure durabilité grâce au stockage objet résistant aux pertes matérielles, une gestion optimisée des coûts et opérations via un service dédié au stockage, ainsi qu’une architecture cluster simplifiée évitant les systèmes NFS fragiles.

Quelle architecture est recommandée pour déployer Nextcloud en production ?

L’architecture recommandée combine plusieurs instances Nextcloud pour gérer la charge, une base de données robuste (MySQL/MariaDB/PostgreSQL), Redis pour la gestion des verrous et cache performant, un stockage objet S3 pour les fichiers volumineux et critiques, le tout derrière un reverse proxy ou load balancer afin d’assurer haute disponibilité et scalabilité.