| Revision History | |
|---|---|
| Revision 1 | 2/5/20212 |
Ajout de la section Kolab. | |
| Revision 2 | 5/5/2012 |
Ajout de la section Solutions écartées | |
Abstract
Partager ses données personnelles (contacts, agenda) entre Kontact et un smartphone sous Android est désormais possible, en Open Source et gratuitement. Le protocole SyncML et le serveur Funambol Community le permettent, sans passer par la case Google.
Le développement des PDA puis des smartphones soulevait déjà la question de la synchronisation des données entre l'ordi et le terminal mobile. Avec le développement des services en lignes (type Gmail), le besoin de synchronisation touchait ne nouveux horizons. Avec l'externalisation généralisée des données (ce que le marketing appelle le Cloud) le problème gagne en ampleur.
Comme parfois (souvent ?) en informatique, la multiplication des besoins n'entraîne pas nécessairement une complexité croissante. Trop de cas spécifiques oblige à trouver une solution générale applicable à un maximum de situations particulières. Ainsi, le problème initial de synchronisation entre Kontact et Android trouve une solution générale dans la synchronisation de Kontact avec presque n'importe quoi.
On oublie souvent que la possibilité de synchroniser ses données n'est pas synonyme de qualité de synchronisation. Ainsi de nombreuses solutions "clés en main" se présentent sous leur meilleur jour en omettant ou dissimulant le fait qu'elle perdent des informations. Rien de moins ! En matière de données personnelles ce sont souvent des champs qui disparaissent. Par exemple, que deviendra le numéro de fax professionnel de votre correspondant si vou le synchroniser avec un service qui n'a pas prévu cette information. Il peut en aller de même de l'adresse professionnelle, du nom du chef de service… Bref tout ce qui sort du répertoire d'adresses minimal est en danger.
Enfin, la question de la synchronisation des données personnelles avec un terminal Android est souvent réduite à la synchronisation avec les services de Google, répertoire Gmail et agenda en tête. Ici, le parti pris est précisément de se passer de Google. Autrement dit, nous souhaitons gérer et synchroniser nos données personnelles sans les confier à aucun moment à Google !
Une autre erreur commune est d'associer la question du mail à la gestion des données personnelles. Là encore, il s'agit d'un effet de formattage intellectuel produit par le marketing. La problèmatique du mail est différente. L'accès distant à son mail à travers un logiciel dédié (client lourd) est déjà parfaitement réglé. Son intégration au client mail standard d'Android en est l'exemple. Les nouvelles problématiques du mail sont d'un autre ordre : d'une part la centralisation d'accès à plusieurs comptes et/ou services de mail et d'autre part, dans ce contexte, l'alerte de réception (mail-push). Il existe des solutions Open Source robustes traitant ces objectifs et des professionnels sachant les mettre en œuvre.
Afin de synchroniser nos données personnelles gérées par Kontact avec notre terminal Android, nous allons donc retenir une solution générale. Au lieu de chercher à synchroniser directement deux terminaux (un ordi et smartphone/tablette) nous introduisons un intermédaire neutre :
Kontact <-> Android devient Kontact <-> intermédiaire <-> Android. Le premier avantage est que l'on pourra ainsi synchroniser n'importe quel service et/ou terminal sanchant dialoguer avec notre intermédiaire. Le second avantage est qu'en choississant le bon intermédiaire, on disposera d'un double intégral de nos informations ; en effet, le schéma direct limite la duplication à ce que sait gérer chaque partenaire de l'échange.
Le choix de l'intermédaire est capital. Il doit être aussi neutre que possible, c'est-à-dire qu'il doit être capable de s'adapter à tout interloccuteur.
D'un côté, si un service/logiciel permet de mémoriser le nom de l'adjointe de la chef de service d'un contact, l'intermédiaire doit également mémoriser cette information et permettre sa synchronisation. D'un autre côté, l'intermédiaire doit être capable d'entrer en communication avec le maximum d'interlocuteurs, dans de bonnes conditions.
Répondre à ces deux contraintes nous conduit à choisir un protocole de synchronisation et un serveur adapté à ce protocole. Le protocole retenu est SyncML (parfois appelé OMA), en raison de ses qualités intrinsèques, de sa pérénité probable et du grand nombre de logiciels-clients, connecteurs, passerelles exploitant ce protocole. Pour l'intermédiaire, notre choix s'est porté sur le serveur Funambol en raison de sa relative neutralité et sa probable pérénité.
Une fois le serveur mis en place, il devient possible de synchroniser tout équipement "sachant parler" SyncML. Dans le cas qui nous intéresse, il va s'agir de doter KDE-Kontact et Adroid-Contacts-Agenda de clients SyncML.
L'installation d'un serveur Funambol local et dédié est simple - pour qui a déjà installé une application Web "clés en main". Les deux mots important sont ici, "local" et "dédié". Un serveur local n'étant pas exposé à Internet on esquive la principale complexité qui est sa protection. Par "dédié" on entend qu'on ne lui demandera que de faire tourner le serveur Funambol. On esquive ainsi tout problème d'interférence avec d'autres services. Autrement dit, on peut installer un serveur local dédié Funambol sans savoir configurer un vrai serveur multi-services internet.
Notre choix est d'installer un serveur Debian 6 (Squeeze). Si vous disposez d'un bonne connexion Internet, la méthode d'installation appelée "netinst" est la plus rapide.
Sur ce serveur, nous allons installer la version Community "clés en main" (bundle) de Funambol. Cette version a deux caractérisituqes majeures. D'une part elle est la version Open Source, gratuite, de Funambol. Elle ne dispose pas de toutes les fonctionnalités accessibles à travers la version commerciale (OneMediaHub) mais répond à notre cahier des charges. D'autre part, elle installe et configure tout ce dont Funambol peut avoir besoin pour fonctionner.
La configuration du serveur Funambol se limite à la création d'un compte-utilisateur.
Funambol ne propose pas d'interface Web d'administration mais un client Java. S'il ne propose pas non plus d'interface Web de consultation, il propose néanmoins deux outils permettant de tester le fonctionnement avant d'avoir configuré un client SyncML : une interface Web et un client Java rudimentaires.
Tout en se limitant à un serveur local, il est tout à fait possible de mutualiser un serveur existant. L'installation de Funambol Community est alors plus complexe. Une certaine pratique des application Web Java et des serveurs d'application ou conteneurs de servlets est alors nécessaire.
Installer Funambol sur un serveur accessible par Internet demande une réelle compétence en matière de sécurisation. Sans même parler de confidentialité des données ni de risque d'intrusion dans vos systèmes informatiques la simple disponibilité du serveur (donc la possibilité de synchroniser) devient un enjeu de taille.
Louer un serveur mutualisé pour un faire tourner Funambol ne sera pas chose aisée. En effet, la quasi-totalité de l'offer d'hébergement mutualisé est conçue pour des clients souhaitant héberger des application PHP. Funambol étant une application Java, vous ne pourrez la faire fonctionner sur leurs serveurs.
Si vous optez pour la location, vous êtes obligé⋅e⋅ de vous tourner vers les serveurs dits "dédiés", c'est-à-dire une machine réelle que vous louez chez un hébergeur. La variante d'un serveur virtuel (vhost) est envisageable mais risque de ne pas être intressante pour des application Java. L'hébergement en cloud est évidemment possible mais là encore, l'intérêt économique reste à prouver et la complexité de mise en œuvre dépasse de loin l'installation d'un serveur Funambol.
Pour toute utilisation professionnelle d'ampleur nécessitant la synchronisation via internet et une disponibilité garantie du serveur, contactez des professionnel⋅les. Nous par exemple ;)
Qu'il s'agisse de tester cette solution ou d'un choix pérenne, vous pouvez vous tourner vers des sociétés commercialisant la synchronisation SyncML avec un serveur Funambol comme un service (principe du SaaS). L'avantage est que vous disposez d'une solution de syncrhonisation via Internet sans avoir à configurer de serveur. L'inconvénient est que vous externalisez des données critiques en les confiant à des sociétés dont vous ne savez rien. À quoi bon éviter de confier vos informations vitales à Google si c'est pour les laisser des inconnus les scruter ?
L'installation du client SyncML sur Android se fait simplement depuis la place de marché de Google : Play Store.
En l'occurence nous vous suggérons d'installer le client gratuit FunV10.
La configuration dépend du serveur/service utilisé. Si vous avec installé un serveur local dédié Funambol, les données de configuration seront les suivantes :
login : l'identifiant choisi password : le mot de passe l'url : xxx.xxx.xxx.xxx:8080/funambol/ds, où xxx.xxx.xxx.xxx désigne l'adresse locale de votre serveur (ou son nom de domaine local) calendar : cal contacts : card
Nous ferons l'hypothèse raisonnable que si vous utilisez Kontact, vous travaillez problablement dans une session KDE, sous Linux.
Dans un soucis d'allègement de cet article nous ferons l'hypothèse plus harsardeuse que vous utilisez un système Linux utilisant apt comme gestionnaire de paquetages. Ceci nous permet de vous renvoyer sur la documentation disponible sur le site d'Unbuntu-fr.org.
La disponibilité d'un client SyncML libre capable de mettre à jour les données gérées par Kontact est extrêmement récente (mai 2012). Nous mettrons à jour ce chapître en fonction des développements qui devraient avoir lieu, nous l'espérons, dans les semaines ou les mois qui viennent. Des progrès en matiière d'intégration à KDE (Kwallet pour les mots de passe, exploitation automatique des données Kontact, …) sont vivement souhaités. La mise à disposition dans les dépôt des principales distributions de paquetages binaires.
L'un[1] des atouts de Funambol tient à sa vocation à œuvrer en tant une plate-forme d'intégration-centralisée de [comptes de] mail, avec alertes (mail-push). L'intérêt majeur de cette fonctionnalité se retrouve dans des situation d'itinérance (push) puisque que la configuration d'un terminal pour la seule connexion avec le serveur Funambol donne accès à l'intégralité de son mail.
À partir du moment où l'on opte pour une solution externalisant les données PIM sur un serveur, d'autres options que SyncML/Funambol viennent à l'esprit. Parmi celles-ci, le serveur Kolab présente la particularité de préconiser la suite KDE-PIM comme client de référence. Une aubaine puisqu'on veut précisément synchroniser Kontact avec les reste du monde !
L'un des avantages notables est que l'on n'aura rien à installer, ni sur l'ordi sur lequel on utilise Kontact, ni sur le terminal Android. L'un comme l'autre savent déjà communiquer avec Kolab.
Les concepteurs de Kolab recommandent vivement son installation sur un système dédié[2]. L'installation de Kolab sur un serveur local dédié n'est cependant pas aussi évidente qu'on pourrait l'imaginer. En effet, Kolab utilise un système de gestion des paquetages indépendant[3] du système hôte. Si l'on utilise Debian ou Ubuntu-Server comme système hôte, on remarque que Kolab existe sous forme de paquetages dans les dépôts officiels de ces deux distributions. Si de tels paquetages existent dans votre distribution, les developpeurs de Kolab déconseillent fortement leur utilisation et qualifient d'expérimentale[4] ce type de distribution de Kolab.
En revanche, l'installation depuis le code source s'avère relativement simple[5] et débouche sur un serveur parfaitement opérationnel.
L'utilisation d'un serveur dédié permet d'éviter les interférences entre les services qui ne manqueraient de se produire so l'on avait opté pour un serveur assurant déjà plusieurs services.
La configuration minimale de Kolab est plus complexe que celle de Funambol car Kolab est conçu pour effectuer la gestion du courrier (réception, envoi, filtrage des spams, redirections, etc.) parallèlement à la gestion des données PIM. Lors de l'étape de configuration post-installation (bootstrap) on définit les paramètres généraux de fonctionnement. Dans un second temps, on se connecte au serveur Kolab en tant qu'admin pour créer un compte-utilisateur.
Un terminal Android dispose d'origine de tous les composants logiciels nécessaires pour communiquer avec un serveur Kolab. En effet, le serveur Kolab propose une interface ActiveSync ce qui signifie que le terminal Android peut s'y connecter comme s'il s'agissait d'un serveur Exchange (Entrepise). Il suffit donc de créer un tel compte, en indiquant les coordonnées du serveur et les identifiants du compte-utilisateur créé sur le serveur.
Kontact est le client privilégié de Kolab. Akonadi étant la partie de KDE-PIM en charge de l'accès aux ressources, il suffit de créer une ressource Kolab, en suivant les indications de l'assistant de création du même nom !
De par sa finalité première, Kolab apporte automatiquement des fonctionnalités supplémentaires : le traitement du mail, des annuaires partagés, les boîtes mail partagées, un web-mail. Les boîtes partagés sont accessibles à travers un mécanisme d'adressage. On notera cependant que la prise en charge du mail par le client Android d'origine est très aléatoire.
Ces fonctionnalités sont tout à fait adaptées à l'accès itinérant ("mail-push")de personnes impliquées dans un envrionnement organisationnel (partage de données). Le prix à payer pour en bénéficier est l'accèssibilité du serveur par internet avec ce que cela implique en matière de sécurité-disponibilité.
OnwCloud s'inscrit dans une démarche de "cloud personnel". Offrant une interface CardDAV et CalDAV, Kontact peut s'y connecter directement pour synchroniser les données PIM. Il permet également de syncrhoniser des fichiers ordinaires (multimedia, etc.). Enfin, il propose une interface Web.
Son principal atout est probablement de s'installer comme une application PHP/MySQL quelconque[6]. Contrairement à Funambol (par commodité) et à Kolab (par recommandation), il n'est pas nécessaire de lui dédier la totalité d'un système (serveur).
La limite rédhibitoire de ce serveur est la perte d'informations PIM. En effet, OwnCloud ne mémorise qu'une toute petite partie des données de carnet d'adresses, par exemple. Il sera impossible de restaurer les données de Kontact à partir du serveur !
De plus, il n'existe pas (encore) de client Open Source et gratuit CalDAV pour Android.
Seul le ciblage sur Kontact justifie que nous ayons écarté SOGo. Si vous envisagez de vous affranchir de KDE-Kontact (plus généralement de tout logiciel PIM lié à un environnement de bureau) SOGo est une piste à étudier sérieusement. Son client PIM de référence n'est autre que Thunderbird, enrichit de l'incontournable Lightning et d'un plug-in spécifique, au nom explicite : SOGo Integrator.
SOGo est très bien fourni en interfaces : CalDAV, CardDAV, SyncML (via Funambol), Web, OutLook (via OpenChange).
La synchronisation des données personnelles gérées par des logiciles comme Kontact (PIM) est à l'intersection d'autres préoccupations grandissantes :
la synchronisation plus large de documents personnels (personnal cloud)
le partage d'agendas et la synchronisation d'agendas partagés
l'interconnexion de serveurs d'accès et de syncrhonisation (notamment du monde Window$, Exchange, etc.)
la collecte/consultation centralisée de plusieurs compte/boîtes/services de mail et l'alerte
le partage et la synchronisation de documents entre différents systèmes et personnes
la sécurisation des échanges et l'identification des intervenant⋅e⋅s
Dans toutes ces situations, on retrouve deux caractéristiques de la synchronisation des données PIM à travers un serveur: la confidentialité et le besoin de disponibilité en plusieurs points. Chaque cas d'espèce combine les différents ingrédients de manière singulière. S'il n'existe pas de réponse standardisée, nous disposons aujourd'hui d'outil Open Source permettant à chacun⋅e d'ajuster le niveau d'indépendance/aliénation à ses besoins et ses contraintes. Entre le tout-Google[7] (Gmail, Contacts, Agenda, Google Docs, Google Cloud,…) et l'utilisation de ressources intégralement contrôlées, du serveur au terminal mobile, il existe une large palette de solutions. Reste à chacune, personne ou organisation à identifier ses contraintes à définir ses objectifs. Une seule chose est aurjourd'hui avérée : la pseudo-gratuité des services commerciaux est hors de prix, en termes d'indépendance et de libertés publiques.
[1] Dans la version commerciale de Funambol, la synchronisation est étendue à des répertoires banalisés pouvant contenir tous types de fichiers. On obtient alors un accès multi-localisé au mail, aux données PIM (granularisées) ainsi qu'à des données quelconques, c'est-à-dire l'ensemble des fonctionnalités visées dans de cadre de SyncML.
[2] Un serveur entièrement consacré à Kolab, n'effectuant aucune autre tâche telle que l'hébergement de sites Web, gestion de courrier électronique, listes de diffusion, partage de fichiers, etc.
[3] OpenPKG qui permet de diffuser Kolab sous une forme unique, indépendante de la distribution Linux du système hôte. En vérité, vous serez toujours plus ennuyé⋅e si vous utilisez un Linux basé sur Debian qu'une Linux basé sur Red Hat.
[4] Dans le cas de Debian 6, notre installation à partir des paquettages Debian a débouché sur un seveur Kolab inopérant.
[5] Dans la mesure ou les sources de la pile (stack) Kolab contiennent toutes les applications nécessaires. En suivant pas à pas les indications fournies on obtient un système fonctionnel sans trop [devoir] savoir comment…
[6] Comme un site Web utilisant un CMS.
[7] Ou tout autre réponse enfermante (tout-Apple, tout-Micro$oft, tout-FaceBook,…).