Il est devenu fréquent que les administrations demandent aux citoyens de leur fournir une adresse e-mail pour les contacter. C’est par exemple le cas sur l’Irisbox pour les Bruxellois, sur Tax-on-web pour tous les belges et résidents (ou dans son « dossier fiscal ») et même de certaines communes. C’est souvent optionnel, et on ne sait pas toujours pourquoi ils la demandent. La récente légalisation sur le recommandé électronique en France ou en Belgique (voir moniteur) va vraisemblablement augmenter le nombre d’adresses e-mail stockées par les autorités.

L’e-mail existe depuis le milieu des années 70, et bien qu’on ait à plusieurs reprises prédit sa fin, force est de constater qu’il est toujours un média largement utilisé, et qu’il n’est probablement pas prêt de disparaître. Cependant, lors d’une étude que nous avons menée récemment à propos de la gestion des adresses e-mails dans les bases de données, nous avons fait deux constats :

1. Il est difficile de gérer correctement une grande base de données d’adresses e-mail ; de nombreux facteurs d’incertitude, des standards multiples et non respectés ainsi que des caractéristiques intrinsèquement dynamiques rendent la tâche très ardue ;
2. De plus en plus de spécialistes s’accordent pour dire qu’un nombre croissant de gens, en particulier parmi les jeunes, délaissent l’usage de leur adresse e-mail, au profit des réseaux sociaux. Je connais personnellement de nombreux adolescents qui se sont créé une adresse e-mail dans le seul but de pouvoir se créer un profil sur Facebook.

Il serait donc judicieux de se demander si, en complément à une adresse e-mail, il était aussi possible pour un citoyen d’être contacté via le réseau social de son choix. Le ministère de finances en a fait une annonce récemment, ainsi que, dans le privé, KLM ; chez Smals, on y réfléchit depuis quelques mois.
Notons que ces mécanismes peuvent aller bien au-delà de la notification administrative. On peut également imaginer le même système pour être averti en cas de crue d’un cours d’eau ou en cas d’alerte près d’un site Seveso, en supplément aux canaux déjà utilisés (presses, sms, …)

Pour qu’un réseau social puisse être candidat alternatif à l’adresse e-mail dans le contexte de l’e-governement, il doit rencontrer quelques conditions.

1. Il faut qu’il offre un mécanisme de messagerie privée, qui permet d’envoyer un message à un utilisateur qu’il sera seul à pouvoir lire. Il n’est bien évidement pas question de poster sur le mur public d’un citoyen qu’il a oublié de payer ses impôts, ou d’envoyer un tweet pour signaler qu’il a reçu un recommandé électronique.
2. Il faut que la plateforme offre une « API » (Application Programming Interface), permettant d’interagir automatiquement avec le réseau, sans qu’un fonctionnaire ait à se connecter explicitement sur le compte et doive envoyer les messages « à la main ».
3. Le réseau doit pouvoir permettre qu’un de ses utilisateurs, sur base volontaire et explicite, autorise un serveur à le contacter via son profil. Il va de soi qu’une institution ne pourra jamais se servir d’un profil Facebook pour contacter son propriétaire sans son consentement explicite. En effet, rien ne permet à une administration de s’assurer que le « Albert Durant » qu’il a trouvé sur Facebook est bien celui qui n’a pas payé ses impôts. Par ailleurs, les réseaux sociaux sont – heureusement ! – suffisamment cloisonnés pour qu’on ne puisse pas interagir avec quelqu’un qui n’a pas marqué son accord, même si la demande vient d’un ministère.
4. Le mécanisme d’autorisation doit cibler précisément ce que l’accès à un profil permet de faire. En général, pouvoir envoyer un message ou une notification est suffisant. Aucun citoyen ne sera prêt à accepter un tel mécanisme s’il savait que les autorités avaient soudainement accès à toutes ses photos ou les commentaires qu’il poste sur les statuts de ses amis.

Après avoir très brièvement présenté ce que permet le protocole « oAuth », voici une revue rapide et non exhaustive de quelques-uns des réseaux sociaux majeurs que nous avons étudiés ou testés, en développant un petit « proof-of-concept » lorsque ça s’appliquait. Nous supposons qu’un citoyen possède un accès à une « e-box », sorte de boîte au lettre électronique, sécurisée au moyen par exemple d’une carte d’identité électronique, dans laquelle les autorités peuvent déposer des documents. Cette e-box est amenée de temps à autre à lui communiquer que, par exemple, un nouveau document officiel y est disponible.

oAuth

oAuth est un protocole d’autorisation très populaire parmi les réseaux sociaux, qui permet principalement deux choses :

1. La façon classique de pouvoir se connecter sur un portail quelconque (forum, e-commerce, …) consiste en la création d’un « compte », en général avec un nom d’utilisateur et un mot de passe. L’inconvénient de cette façon de faire est qu’elle oblige les gens à se créer de multiples comptes sur un tas de services, et à en retenir les identifiants. Grâce à oAuth, pour autant qu’il soit implémenté sur le portail en question, il est également possible de s’y connecter avec, par exemple, son compte Facebook. Ceci se fait en tout sécurité, sans que le mot de passe de Facebook ne soit transmis au portail.
2. Le même protocole permet d’autoriser un portail, ou une application (c’est-à-dire une page web) indépendante du réseau social, non seulement d’accéder de façon contrôlée à certaines informations disponibles sur le réseau social (par exemple ses photos, sa liste de contacts, sa date de naissance, …), mais également d’effectuer des actions au nom de l’utilisateur, comme par exemple poster un message sur un mur, ou recevoir une notification. Chaque utilisateur de Facebook voit régulièrement un de ses amis poster un message du type « J’ai obtenu un score de XXX au jeu YYY ; seriez-vous capable de me battre ? », message qu’il n’a pas écrit lui-même, mais qui l’a été par le jeu en question.

Notons que la plupart des systèmes présentés ci-dessous et qui implémentent oAuth permettent également, quand cela s’applique et que l’autorisation a été accordée, d’accéder à l’adresse e-mail renseignée sur le réseau social. On pourrait dès lors proposer de lier son e-box à un réseau social, et de s’en servir uniquement pour récupérer l’adresse e-mail renseignée. Nous ne détaillerons pas plus cette possibilité ci-dessous.

Facebook

Nous avons trouvé deux façons de permettre ce que nous présentons plus haut, dont seulement une réellement satisfaisante. La première consiste à envoyer un e-mail classique à l’adresse associée à un compte Facebook (souvent du type prenom.nom@facebook.com). Cette solution a pour avantage sa facilité, puisqu’il n’est pas nécessaire de mettre en place un mécanisme de contact différent de celui habituellement utilisé pour les e-mails : un citoyen peut choisir, à la place de son adresse e-mail « classique » de fournir celle de Facebook. Elle a par contre un inconvénient majeur : le message en question n’apparaît pas directement dans la boîte de réception, mais dans une catégorie « Autre », peu visible, que beaucoup d’utilisateurs de Facebook n’ont même jamais remarquée.

La seconde nécessite de développement d’une application utilisant l’API de Facebook, basée sur le protocole d’autorisation oAuth décrit plus haut. Le citoyen pourra d’une part se connecter avec son compte Facebook à une application sur son e-box, prouvant ainsi qu’il a bien accès à ce compte Facebook, et d’autre part, autoriser l’e-box à interagir avec lui, au travers de « notifications » (petit icône de globe terrestre en haut à droite) ou de « requêtes » (nombre apparaissant dans la colonne de gauche, à côté de nom d’une application).

Le citoyen contrôle parfaitement ce à quoi l’e-box aura accès, et dans notre cas, seules les informations déjà publiques seront suffisantes, puisque tout ce qui nous intéresse, c’est de pouvoir recevoir des notifications. Aucun risque, donc, que l’État sache où il est parti en vacances, ni qu’il participe à une fête alors qu’un certificat médical lui interdit toute sortie … Par ailleurs, il peut décider à tout moment de désactiver l’application, et donc d’empêcher toute interaction avec son e-box, qui n’aura plus aucun moyen de le contacter via son compte Facebook, ni d’accéder à ses informations.

Une fois la connexion entre son e-box et son compte Facebook établie, l’organisme gérant cette e-box peut lui envoyer un message. Il en sera alors notifié dès qu’il se connecte sur Facebook. Notons que lorsqu’on parle d’application Facebook, il ne s’agit en rien d’un programme à installer sur son ordinateur ou son smartphone, mais simplement de fonctionnalités supplémentaires que l’on rajoute sur la page de Facebook.

[Mise à jour 26/2/2014] Ce lundi 24 février, Facebook a annoncé la fin du service pour les adresses @facebook.com. Prochainement, les e-mails envoyés à ces adresses seront transféré à l’adresse e-mail renseignée dans le profil, et n’apparaîtront plus dans les messages. La première solution présentée ci-dessus n’est donc plus d’actualité.

Twitter

Le cas de Twitter est un peu plus simple. Il existe deux types de messages sur Twitter : les « tweets », qui sont publics, et les « messages privés » (ou « direct messages »), accessibles via la petite icône d’enveloppe au-dessus de la page d’accueil. Ce sont ces derniers qui nous intéressent ; seul l’utilisateur y aura accès. Pour pouvoir envoyer un message privé à un autre utilisateur, il suffit d’être suivi par cet autre utilisateur (être donc un de ses « followers »).

On pourra donc créer un profil, disons « @eBox », et inviter chaque citoyen désirant être contacté via Twitter à devenir « follower » de ce compte. Une application peut ensuite être autorisée par ce profil « @eBox » à écrire des messages privés en son nom, et le tour est joué.
Il faut cependant lier le compte Twitter du citoyen à son compte sur l’e-box. Cela peut se faire soit en communiquant dans l’e-box son « screen name » de Twitter (nom d’utilisateur), soit, pour garantir que le citoyen en question a bien un accès à ce compte, en utilisant la fonctionnalité « Se connecter avec Twitter » de oAuth, décrite plus haut.

LinkedIn

D’après les informations dont nous disposons jusqu’ici, LinkedIn ne permet pas de mettre en place une procédure similaire à celle décrite ci-dessus. En effet, s’il est également possible de se connecter à un site web ayant implémenté les librairies de LinkedIn en se servant de son compte LinkedIn, ce dernier empêche à une application l’envoi d’un message à un utilisateur A de la part d’un utilisateur B sans qu’il n’y ait d’action manuelle effectuée par l’utilisateur B. Il ne semble donc pas possible à un serveur d’envoyer automatiquement des messages à des utilisateurs, sans l’intervention manuelle d’un fonctionnaire, ce qui n’est bien évidemment pas envisageable.

Nous continuons à investiguer la question, mais si un lecteur, expert en API LinkedIn, voit une façon élégante de procéder, nous serions ravis de lire son avis sur la question !

Google+

Le réseau social de Google offre une série d’API permettant d’écrire des applications, et de faire en sorte que plusieurs utilisateurs d’une même application puissent “chatter” entre eux (en utilisant “Hangout”), un peu comme cela se fait dans les “Google Docs” (drive.google.com). Mais rien qui, à notre connaissance, ne permette d’envoyer un message à un utilisateur qu’il verrait dès qu’il se connecte sur la page d’accueil de Google+. Il ne nous semble donc pas qu’à ce stade, ce réseau soit un candidat pour notre objectif.

À nouveau, nous serions très heureux d’entendre l’avis de quelqu’un qui en aurait un autre !

Snapchat

Snapchat est un réseau social dans lesquels les messages envoyés sont « auto-détruits » après un temps maximum de 10 secondes … et n’est donc de toute évidence pas adapté au problème décrit ci-dessus.

Instagram, Pinterest

Ces deux réseaux sociaux n’offrent, à notre connaissance, pas de messagerie privée, et ne sont donc pas candidats.

WhatsApp

Cet outil de messagerie, qui vient d’être racheté par Facebook, ne propose pas officiellement d’API permettant d’interagir avec d’autres utilisateurs. Les quelques librairies et outils que nous avons pu trouver jusqu’ici relève vraiment du « hacking », en permettant à un serveur de se faire passer pour un téléphone ; il ne serait donc pas raisonnable de les utiliser dans un contexte officiel.

Skype

Skype n’est pas à proprement parler un réseau social, mais pourrait très bien faire l’affaire pour ce qui nous concerne. Cependant, si une API était disponible par le passé pour envoyer des messages, elle a été supprimée lors du rachat par Microsoft. Il semblerait que certains outils soient cependant encore disponibles, mais étant donné qu’ils ne sont pas officiellement supportés, nous ne les avons pas étudiés plus en détails.

Netlog

Réseau social similaire à Facebook mais largement moins répandu, Netlog, développé en Belgique, propose une API principalement basé sur OpenSocial de Google. Ce réseau semble cependant en fort déclin, et la documentation de son API est très incomplète, pleine d’erreurs et de liens morts vers des exemples, raisons pour lesquelles nous ne l’avons que partiellement testé.

 

Conclusions

L’utilisation des réseaux sociaux comme alternative complémentaire à l’adresse e-mail dans le cadre d’une communication entre les autorités et les citoyens offre de nombreux avantages pour les deux parties : contact plus rapide, plus grande flexibilité, image plus moderne, contrôle d’existence aisé, … Par ailleurs, l’investissement est relativement faible : l’accès aux API est gratuit, seul un temps de formation (quelques jours tout au plus) est nécessaire avant la mise en place professionnelle d’une telle infrastructure. L’infrastructure matérielle requise n’est par ailleurs pas plus complexe que celle nécessaire à l’envoi d’e-mails classiques. Les gains, quant à eux, dépendent fortement de l’application : factures payées plus tôt, diminution des envois postaux ou des appels téléphoniques, traitement plus rapide des dossiers…

Les candidats les plus sérieux à l’heure actuelle sont pour nous Facebook et Twitter. Il faudra cependant évaluer le marché en continu, de façon à voir comment évoluent les réseaux sociaux et leurs API associées.