Ceux qui recherchent une alternative européenne et auto-hébergeable aux deux leaders mondiaux des suites bureautiques, Google Workspace et Microsoft 365, connaissent très certainement Nextcloud.

Sommaire

• Qu’est-ce que Nextcloud ?
• Pourquoi une application de calendrier ?
• La création d’une première version en quelques semaines
• Un succès inattendu
• Et maintenant ?

Qu’est-ce que Nextcloud ?

Nextcloud est un dérivé d'ownCloud, lancé en 2016 par l'Allemand Frank Karlitschek, lui-même créateur d'ownCloud. D'abord centré sur la gestion de documents, l'écosystème s'est peu à peu étendu pour intégrer tous les modules bureautiques : e-mail, visioconférence, messagerie instantanée, etc.

Dix ans plus tard, Nextcloud est l'un des leaders open source des suites bureautiques, collabore avec d'autres acteurs majeurs européens comme IONOS Cloud ou OpenProject, et s'engage à investir 250 millions d'euros d'ici 2030 dans la souveraineté numérique.

Un beau parcours qui a commencé, comme beaucoup, par un simple commit.

Nextcloud doit donc fournir des alternatives crédibles à des outils comme Google Drive, Microsoft Teams, Google Meet ou SharePoint. Pour cela, il lui faut un écosystème extrêmement complet, doublé d'une expérience d'usage très qualitative, afin de faciliter et d'accélérer l'adoption auprès des publics non techniques, qui constituent en réalité la majorité du public visé.

Pourquoi une application de calendrier ?

Contrairement à Google avec Google Agenda ou à Microsoft avec Outlook et Teams, Nextcloud ne propose pas d'application mobile dédiée à son calendrier.

Vous me direz d'abord : « C'est inutile, il suffit d'utiliser la web app. » Oui, mais non.

Imaginez un commercial en déplacement : il doit consulter son agenda, créer un rendez-vous avec un prospect et envoyer une invitation, parfois avec une connexion réseau très limitée. Dans cette situation, une application mobile, accessible en un clic et capable de fonctionner hors ligne, fait la différence.

Vous me direz ensuite : « C'est inutile, il suffit de connecter son calendrier à une application existante avec un lien CalDAV. » Encore une fois, oui, mais non.

Une application générique peut synchroniser les événements, mais elle ne sait pas créer un lien de visioconférence Nextcloud Talk, ni intégrer les fonctionnalités spécifiques de la plateforme (comme la récupération des contacts par exemple). C’est exactement ce qui fait la force des applications de Google et Microsoft : chaque brique est conçue pour fonctionner avec les autres.

Et c’est ce manque que nous avons voulu combler.

La création d’une première version en quelques semaines

Sur un coup de tête et un peu au hasard, nous avons réalisé un premier prototype.

La technologie multiplateforme React Native a été choisie dans cette optique : aller vite pour tester la faisabilité. Si l'application n'avait jamais été créée auparavant, c'était peut-être qu'il existait un verrou technique que nous n'avions pas identifié.

Nous avons créé une première version fonctionnelle et très basique en quelques jours en nous appuyant sur l'API de Nextcloud, puis nous avons amélioré l'expérience et ajouté quelques fonctionnalités (afficher ou masquer un agenda, créer un nouvel événement, ajouter des participants).

Après des tests rapides en cas réel sur Android et iOS, nous avons créé les fiches App Store et Play Store, puis publié. Trois jours plus tard, les applications étaient disponibles pour le grand public.

Un succès inattendu

L'application a été publiée sur les magasins d'applications (App Store et Play Store) en avril 2026.

Trois semaines plus tard, avec un article Reddit comme seul moyen de communication, l’application avait déjà atteint 3.500 téléchargements.

Une heureuse surprise, mais qui allait demander du travail !

L'application était avant tout destinée aux besoins internes de notre entreprise et n'avait pas été pensée pour une telle adoption.

Il a fallu transformer ce prototype réalisé rapidement en un produit capable de répondre aux besoins de milliers de personnes tout en respectant les standards de l'open source :

• structurer une vision moyen-terme et créer une feuille de route publique
• récolter et répondre aux retours des utilisateurs (GitHub, App Store, Play Store)
• publier un APK à chaque version pour ceux qui n’ont pas accès au Play Store
• renforcer les performances et l’expérience utilisateur sur tous supports (notamment sur la navigation dans le calendrier et la gestion des données)

Et maintenant ?

Avec environ 15.000 téléchargements à fin juillet 2026, l'application est utilisée au quotidien par des milliers d'utilisateurs et dispose déjà des fonctionnalités principales :

• Visualisation des agendas personnels et partagés dans différentes vues (jour, semaine, mois, etc.)
• Édition des événements avec ajout d’un lien de visioconférence, d’un lieu et de participants
• Notifications configurables pour les rappels avant un événement
• Traductions en 8 langues : français, anglais, allemand, espagnol, italien, portugais, néerlandais et russe
• Support de plusieurs comptes connectés simultanément (par exemple, pour les ceux utilisant Nextcloud à titre pro et perso)
• Widgets (iOS et Android) pour visualiser rapidement les événements à venir

Nous avons pu échanger récemment avec les équipes techniques de Nextcloud afin de confronter notre produit à leur expérience de l'écosystème, aux bonnes pratiques et aux attentes des utilisateurs.

Leurs retours nous ont permis de repenser notre feuille de route, qui sera mise à jour en conséquence dans les semaines à venir.

En attendant, pour celles et ceux qui disposent d'une instance Nextcloud et qui souhaitent télécharger l'application :

• App Store : https://apps.apple.com/fr/app/nextcloud-calendar/id6766678698
• Play Store : https://play.google.com/store/apps/details?id=com.soluce.nextcloudcalendar
• F-Droid : à venir très prochainement

Et pour les plus motivés qui voudraient contribuer (ou simplement étudier le code source), voici le lien du dépôt GitHub :
https://github.com/SoluceTechnologies/nextcloud-calendar-mobile

N. D. M. : GPLv3

Portabase est un logiciel libre auto-hébergeable publié sous licence Apache 2.0, conçu pour automatiser la sauvegarde et la restauration de bases de données dans des scénarios de reprise après sinistre et de migration homogène (c’est-à-dire entre bases de données de même type).

Son architecture distribuée le rend particulièrement adapté à des environnements décentralisés, où les bases de données ne sont pas accessibles sur un même réseau. Il permet de piloter les sauvegardes depuis une interface unique, tout en laissant l’exécution effective aux agents déployés au plus près des bases de données.

Sommaire

• Un projet né d’un besoin opérationnel
• Une architecture distribuée : un serveur central et des agents
• Bases de données prises en charge
• Aperçu des fonctionnalités clés
  • Sauvegardes planifiées, déclenchement manuel et rétention
  • Restauration et migration homogène
  • Stockage local ou distant
  • Notifications lors d’évènements spécifiques
  • Organisation et contrôle d’accès
• Installation et déploiement
• Feuille de route et fonctionnalités à venir
• Conclusion

Un projet né d’un besoin opérationnel

Portabase a été créé il y a environ deux ans et demi pour répondre à un besoin interne : remplacer des scripts utilisés pour sauvegarder des bases PostgreSQL par une solution centralisée et facilement maintenable, évitant d’avoir à déployer un script avec une cron sur chaque serveur. N'ayant pas trouvé de logiciels libres répondant à ce besoin, nous avons investi pour créer cette solution et faire un premier pas dans la contribution au monde du libre, après avoir été de simples utilisateurs pendant de nombreuses années.

La construction d’une communauté autour du projet a réellement commencé depuis environ six mois, vers mi-décembre 2025, avec la publication d’une documentation plus détaillée, des articles sur Reddit et la création d’un serveur Discord.

Quelques statistiques à mi-mai 2026 :

• environ 850 étoiles, 90 issues ouvertes et 5 contributeurs sur GitHub
• plus de 10 000 pulls sur Docker Hub
• environ 2 000 visites mensuelles sur la documentation.

Une architecture distribuée : un serveur central et des agents

Le serveur central fournit l’interface graphique et joue le rôle de control-plane : il permet de déclarer les agents, configurer les sauvegardes, lancer des restaurations et connecter des systèmes tiers (stockages, notifications). Il est construit avec Next.js en TypeScript.

L’agent est déployé au plus près des bases de données : il exécute les tâches de sauvegarde et de restauration. Initialement écrit en Python, il a été réécrit en Rust afin d’obtenir un composant plus léger, plus prévisible et plus robuste à l’exécution. Les garanties apportées par le compilateur Rust contribuent à réduire drastiquement les bugs avant même la mise en production.

Le choix architectural est important : le serveur central ne contacte jamais directement les agents. Il n’est donc pas nécessaire d’ouvrir des ports entrants vers les environnements où résident les bases de données. Ce sont les agents qui contactent périodiquement le serveur central. Cette approche réduit la surface d’exposition réseau et limite les conséquences d’une compromission du serveur central.

Bases de données prises en charge

Le projet a démarré avec PostgreSQL, puis s’est étendu rapidement à d’autres moteurs, d’abord dans l’écosystème SQL.

Portabase prend aujourd’hui en charge neuf bases de données : PostgreSQL, MySQL, MariaDB, MongoDB, SQLite, Redis, Valkey, Firebird et Microsoft SQL Server. La prise en charge Microsoft SQL Server est plus récente, puisqu’elle date d’environ une semaine au moment de la rédaction, et doit donc encore être considérée comme en phase de test.

Aperçu des fonctionnalités clés

Sauvegardes planifiées, déclenchement manuel et rétention

Portabase permet de planifier des sauvegardes selon des intervalles fixes ou à l’aide d’une syntaxe cron. Il reste également possible de déclencher une sauvegarde manuellement ce qui est utile avant une opération de maintenance, une mise à jour applicative, une migration ou toute intervention susceptible de modifier fortement l’état des données.

La gestion de la rétention repose sur trois politiques configurables :

• count-based : conserve un nombre maximal de sauvegardes
• time-based : conserve les sauvegardes pendant une durée maximale
• GFS (Grandfather-Father-Son) : pour un plan plus élaboré, cf. ci-après.

Le GFS permet une granularité avec des sauvegardes journalières, hebdomadaires et mensuelles. L’objectif est de couvrir aussi bien les petites installations auto-hébergées que les besoins d’équipes qui doivent formaliser un plan de conservation.

Restauration et migration homogène

Sauvegarder est nécessaire, mais ce n’est pas suffisant ! L’objectif principal reste de pouvoir restaurer les données le moment venu, en écrasant les données existantes par celles contenues dans la sauvegarde sélectionnée.

Le cas de migration couvert est celui d’une migration homogène : même type de base de données, même version. Portabase permet ainsi de déplacer une base de données de manière contrôlée en passant par l’interface graphique, sans avoir à utiliser des commandes dans un terminal.

Attention : Portabase n’est pas un convertisseur de bases de données. Il ne sert pas à transformer une base PostgreSQL en base MySQL, ni une base MongoDB en base MariaDB.

Stockage local ou distant

Portabase peut stocker les sauvegardes localement, sur l’instance qui héberge le serveur central, ou à distance via des stockages compatibles S3, par exemple AWS S3 ou Garage. Google Drive est également pris en charge. Une même sauvegarde peut être envoyée vers plusieurs destinations simultanément, ce qui permet de créer de la redondance.

Notifications lors d’évènements spécifiques

Le système de notifications couvre les canaux couramment utilisés par les équipes techniques : email, Slack, Discord, Telegram, Ntfy, Gotify et webhooks. Les alertes peuvent être déclenchées sur les succès comme sur les échecs de sauvegarde, avec des politiques personnalisables au niveau des bases de données.

Organisation et contrôle d’accès

Portabase intègre un système d’organisation par espace de travail. Toutes les ressources (agents, canaux de notification, stockage, etc) peuvent être attribuées à des organisations spécifiques, permettant de segmenter les accès. Cette fonctionnalité est principalement utilisée par des équipes qui gèrent plusieurs clients.

Installation et déploiement

L’installation peut se faire avec le CLI, Docker ou sur Kubernetes via Helm Chart. Les images Docker sont disponibles pour les architectures linux/amd64 et linux/arm64.

Pour les personnes qui ne souhaitent pas utiliser la CLI, la documentation propose des configurations prêtes à l’emploi, aussi bien pour le serveur central que pour les agents, permettant de démarrer rapidement.

Feuille de route et fonctionnalités à venir

La feuille de route doit être mise à jour très prochainement. Les prochains développements porteront sur l’amélioration de l’expérience utilisateur, l’intégration dans des écosystèmes auto-hébergés comme Unraid, Proxmox VE Scripts, Dokploy et Coolify, ainsi que le renforcement des tests sur toutes les versions de bases de données prises en charge.

Conclusion

Portabase est né d’un besoin très concret : disposer d’un outil centralisé pour gérer les sauvegardes et restaurations de bases de données, sans maintenir une collection de scripts maison répartis sur chaque serveur.

Le projet couvre déjà plusieurs besoins courants : politiques de rétention, notifications, stockage local ou distant, authentification OIDC/OAuth2, ainsi que des modes de déploiement adaptés à Docker et Kubernetes.

Des retours d’usage, rapports de bugs et contributions sont donc les bienvenus pour continuer à durcir le projet et l’adapter aux cas réels rencontrés sur le terrain. N'hésitez pas à rejoindre le Discord !