Nextcloud Native débarque en alpha — les 4 signaux qui me font revoir nos choix d’outils internes

Une nouvelle application cliente pour une suite auto-hébergée, en version alpha, développée hors de l’éditeur : sur le papier, c’est le genre d’annonce qui ne mérite pas qu’on s’y arrête. J’ai failli passer à côté. Puis j’ai regardé le choix d’architecture, et il touche un sujet dont nous parlons chaque semaine avec les équipes que nous accompagnons.

Ce client ne fait pas ce que font la plupart des applications de bureau modernes. Il n’embarque pas un moteur de rendu web pour afficher l’interface du serveur. Il parle aux API, récupère des données, et les affiche avec les composants natifs du système. C’est un choix coûteux, presque à contre-courant, et c’est précisément pour ça qu’il est intéressant.

Voici les faits, puis les quatre signaux que j’en retire — dont un qui n’a rien à voir avec Nextcloud et beaucoup à voir avec la manière dont on choisit ses outils internes.

Ce qui a été annoncé, exactement

Le projet s’appelle Nextcloud Native. Il rassemble dans une seule interface les services habituellement dispersés d’un serveur Nextcloud : Fichiers, Photos, Talk, Agenda, Mail, Notes, Deck et d’autres. L’objectif affiché est la cohérence — une seule application au lieu d’un client de synchronisation d’un côté et d’un navigateur de l’autre.

Trois précisions importantes, parce qu’elles conditionnent tout jugement. D’abord, le projet est développé indépendamment et indique explicitement qu’il n’est ni affilié, ni sponsorisé, ni approuvé par Nextcloud GmbH. Ensuite, il est en alpha : des versions exécutables existent pour Linux — la cible principale du développement — ainsi que pour Android et Windows ; une version macOS existe mais ne gère pas encore la connexion, et les versions iPhone et iPad sont annoncées comme prévues. Enfin, l’approche technique consiste à communiquer avec le serveur via les API et contrats vérifiés de Nextcloud, puis à représenter les données renvoyées avec des composants d’interface natifs.

Rien là-dedans ne justifie de déployer quoi que ce soit demain matin. Ce qui mérite l’attention, c’est ce que ce choix révèle.

Signal 1 — Le coût des interfaces web déguisées est enfin discuté

Depuis dix ans, la réponse par défaut à « il nous faut une application de bureau » est : on emballe l’interface web existante. C’est rationnel du point de vue de l’éditeur — une base de code, toutes les plateformes, aucun décalage de fonctionnalités.

Le coût de ce choix ne se voit pas dans le budget de développement. Il se voit sur les postes des utilisateurs : plusieurs centaines de mégaoctets de mémoire pour afficher une liste de fichiers, une intégration approximative avec le gestionnaire de fichiers, des notifications qui ne se comportent pas comme celles du système. Sur un poste récent, personne ne s’en plaint. Sur un parc de machines de cinq ans — la réalité de beaucoup de PME et de collectivités — l’effet cumulé est net.

Qu’un projet indépendant accepte de payer le prix fort du développement natif pour éviter cela est un signal de marché. Il indique qu’une partie des utilisateurs considère ce coût comme réel, et suffisamment gênant pour justifier un effort.

Signal 2 — Les API publiques sont devenues le vrai contrat

Le point d’architecture le plus intéressant est celui-ci : le client ne réutilise pas l’interface du serveur, il consomme ses API. Cela n’est possible que parce que ces API sont documentées, stables et considérées comme un engagement plutôt que comme un détail d’implémentation.

C’est un critère de choix largement sous-estimé quand on sélectionne une brique auto-hébergée. Deux produits peuvent se ressembler et ne pas offrir du tout la même liberté : celui dont les API sont un contrat public permet à un tiers — ou à vous — d’écrire un client, un script de migration, un connecteur métier. Celui dont l’interface web est la seule porte d’entrée vous enferme, même s’il est sous licence libre.

Autrement dit, la licence ne suffit pas à garantir la réversibilité. La qualité et la stabilité des interfaces programmatiques comptent au moins autant. C’est exactement le raisonnement que nous appliquons aux dépendances fournisseur côté IA : nos confrères de Plug-Tech mesurent la dépendance en « nombre de jours pour changer », pas en type de licence. Le critère se transpose tel quel.

Signal 3 — L’alpha multi-plateforme dit la vérité sur l’effort

L’état des versions est instructif : Linux comme cible principale, Android et Windows disponibles, macOS présent mais sans gestion de la connexion, iPhone et iPad annoncés. Ce n’est pas un défaut du projet, c’est la réalité du natif — chaque plateforme demande un travail spécifique, et l’authentification est presque toujours la partie qui traîne.

Cette asymétrie est exactement ce que masque une application à interface web embarquée : elle sort partout en même temps parce qu’elle ne fait presque rien de spécifique à chaque système. Voir la différence exposée aussi clairement rappelle pourquoi l’industrie a choisi la facilité, et pourquoi il ne faut pas reprocher à un projet jeune de progresser plateforme par plateforme.

Pour une équipe qui évalue l’outil, la conséquence est simple : le parc détermine la faisabilité du test. Un parc majoritairement Linux peut expérimenter dès maintenant sur quelques postes volontaires. Un parc majoritairement macOS n’a rien à tester tant que la connexion n’est pas gérée.

Signal 4 — La dépendance à un mainteneur se mesure avant de s’installer

C’est le signal le plus général, et le seul qui compte vraiment pour la plupart des lecteurs. Un projet indépendant, jeune, en alpha, qui vise à devenir le point d’accès unique à vos fichiers, vos échanges et votre agenda — c’est un profil de risque à évaluer explicitement, pas à trancher au feeling.

Trois questions suffisent. Combien de personnes ont contribué ces six derniers mois ? Les données restent-elles au format du serveur, ou le client introduit-il un format qui lui est propre ? Existe-t-il un chemin de repli documenté et déjà testé vers le client officiel ?

Dans le cas présent, la deuxième réponse est plutôt rassurante : tout vit côté serveur, le client n’est qu’une vue. C’est ce qui rend l’expérimentation raisonnable malgré le statut alpha. Si le projet s’arrête, on perd du confort, pas des données.

Ce que je ferais concrètement cette semaine

Rien de spectaculaire, et surtout pas un déploiement. Voici l’usage utile de cette annonce.

Mesurer. Ouvrez le moniteur système sur trois postes et relevez ce que consomment vos applications internes au repos. Le chiffre surprend souvent, et il transforme une discussion d’opinion en arbitrage chiffré. C’est vrai pour la suite collaborative comme pour la messagerie d’équipe.

Vérifier le contrat d’API. Pour chaque brique auto-hébergée en place, demandez-vous si un tiers pourrait écrire un client ou un connecteur. Si la réponse est non, vous avez une dépendance plus forte que ce que la licence laisse croire.

Écrire le plan de repli. Une page, pas plus : comment on revient au client officiel, en combien de temps, avec quelles données à re-synchroniser. Cette page vaut pour n’importe quel outil communautaire, et elle est bien plus utile que le débat sur la maturité du projet.

Sur la partie durcissement des postes et gestion des accès associés à ces outils, les équipes de WebGuard Agency rappellent une règle qui s’applique parfaitement ici : un client tiers qui demande un jeton d’accès complet à votre compte mérite le même examen qu’une application externe, même s’il est libre et même s’il tourne sur votre poste.

Faut-il s’y intéresser, alors ?

Oui, mais pas pour les raisons qu’on croit. Pas pour l’installer, pas pour remplacer quoi que ce soit. Pour ce que ce projet met en évidence : nous avons collectivement accepté que « application de bureau » signifie « page web dans une fenêtre », et nous ne mesurons presque jamais ce que ce raccourci coûte à l’usage.

Un projet alpha, indépendant, qui choisit délibérément la voie difficile ne va pas renverser cette tendance. Mais il fournit un point de comparaison concret, et c’est suffisant pour rouvrir une discussion qui mérite de l’être — surtout dans les structures dont le parc n’est pas renouvelé tous les trois ans.

Si vous cherchez à approfondir la question de la réversibilité des outils internes, notre guide sur la reprise en main d’une facture cloud traite le même réflexe sous l’angle des coûts d’infrastructure.

Questions fréquentes

Nextcloud Native est-il un produit officiel de Nextcloud GmbH ?

Non, et c’est un point à retenir avant toute décision. Le projet est développé de manière indépendante et se présente explicitement comme n’étant ni affilié, ni sponsorisé, ni approuvé par Nextcloud GmbH. Il s’appuie sur les API publiques du serveur Nextcloud, mais il ne bénéficie d’aucun engagement de support de l’éditeur. Concrètement, cela veut dire qu’aucun contrat ne garantit sa continuité, et qu’une évolution d’API côté serveur peut le casser sans que personne ne soit tenu de le corriger.

Peut-on déjà l’utiliser en production ?

Non. Le projet est annoncé comme un logiciel en phase alpha, avec des versions exécutables disponibles pour Linux, Android et Windows. Une version macOS existe mais ne gère pas encore la connexion, et les versions iPhone et iPad restent à l’état de projet. Un logiciel alpha destiné à manipuler des fichiers d’entreprise n’a pas sa place sur les postes de production. En revanche, il a tout à fait sa place sur quelques postes volontaires, à condition que la synchronisation reste doublée par un client officiel.

Quelle différence concrète avec un client qui embarque des pages web ?

Un client qui embarque des pages web transporte un moteur de rendu complet et affiche l’interface du serveur telle quelle. Il est rapide à produire et suit automatiquement les évolutions du serveur, mais il consomme beaucoup de mémoire, s’intègre mal au système et vieillit avec le moteur embarqué. Une approche native appelle les API du serveur et reconstruit l’affichage avec les composants du système d’exploitation : consommation plus faible, intégration correcte avec les notifications, le presse-papiers et le gestionnaire de fichiers, mais un coût de développement bien supérieur et un décalage à chaque nouvelle fonctionnalité du serveur.

Comment évaluer le risque d’un outil communautaire pour un usage interne ?

Trois questions suffisent à trancher la plupart des cas. D’abord, combien de personnes ont contribué au cours des six derniers mois — un projet à contributeur unique est un risque de continuité, quelle que soit sa qualité. Ensuite, le format des données est-il propriétaire au client ou reste-t-il celui du serveur : si tout vit côté serveur, l’abandon du client n’a qu’un coût de confort. Enfin, existe-t-il un chemin de repli documenté et testé, c’est-à-dire un client officiel installable en une heure sur tout le parc. Si ces trois réponses sont bonnes, le risque est acceptable.

Note de transparence : cet article s’appuie sur la présentation publique du projet datée du 16 août 2026 et sur la documentation qu’il publie. Nous n’avons pas déployé ce client en production et ne recommandons pas de le faire à ce stade.