États-Unis : victoire cruciale pour la neutralité du Net

Les cinq commissaires qui dirigent la FCC ont considéré par trois voix contre deux que l’Internet américain devait désormais être considéré comme un « bien public » au même titre que le réseau téléphonique, ce qui donne à la Commission le pouvoir de faire appliquer la neutralité d’Internet sur le territoire américain.

[…] La Commission peut désormais interdire aux fournisseurs d’accès à Internet de bloquer arbitrairement des contenus légaux, de ralentir ou d’accélérer les flux de données sans justification ou de prioriser certains contenus transitant par leur réseau moyennant paiement.

C’est encore plein de détail, le combat est loin d’être fini, et n’a même qu’à peine commencé en Europe, mais c’est la bonne nouvelle de la semaine. Très importante pour l’avenir.

Trois choses sur lesquelles vous devriez copier Google

  • Takeout : Pouvoir télécharger toutes vos données dans un format standard via un gros fichier zip.
  • Validation en deux étapes : La possibilité d’imposer un aller-retour par SMS ou l’utilisation d’une application smartphone en plus du mot de passe, pour sécuriser correctement votre compte.
  • Gestionnaire de compte inactif : Un système pour donner accès à vos données à une personne désignée à l’avance si jamais votre compte devient inactif trop longtemps (avec une alerte pour vous permettre d’annuler l’opération juste avant qu’elle intervienne).

Parce que pouvoir critiquer ce qui ne va pas implique aussi de pouvoir montrer ce qui est bien fait.

Informations personnelles pour les sites e-commerce

J’aimerai tant un site e-commerce qui ne me demanderait pas de créer un compte pour faire un achat. Qu’il me soit obligatoire de décliner nom et adresse pour par exemple acheter un livre en ligne… est plus que gênant

Je regarde la super lampe déco, je clique sur « acheter », je saisis une éventuellement adresse de livraison, puis mon numéro de carte bancaire, je valide, et voilà !

Je n’ai pas besoin de plus pour acheter mon pain à la boulangerie, un lit ou une armoire dans mon magasin de meuble, ou un livre à ma librairie. Tout ce qui vient en plus avant la finalisation de la commande me fera fuir.

Parce qu’il y a parfois un besoin d’une relation après vente, je peux comprendre qu’on me demande aussi un numéro de téléphone ou un email, même si ce n’est pas strictement nécessaire. On pourra m’y envoyer un jeton d’accès pour me relier à mes commandes ou m’authentifier si besoin.

Je ne vois aucune raison incontournable d’imposer la saisie de plus d’informations [en fait si, voir commentaires]. Je n’ai ni besoin d’un compte ou d’un mot de passe, ni besoin de décliner mon identité.

Rien n’empêche de proposer la saisie de bien plus d’informations, mais après la commande, et de façon totalement optionnelle.

Pagination sans limit ni offset

TL;DR: La pagination c’est bien™, le faire avec des paramètres limit/offset c’est mal™.

C’est très simple à expliquer : Si les données sont mises à jour entre deux requêtes d’une même pagination, au mieux vous manquez des données et en visualisez d’autres en double, au pire vous corrompez tous vos calculs.

Hypermedia

La solution magique c’est que vos API retournent un nombre limité de résultats avec des liens dans les entêtes, probablement un rel=next pour les données suivantes et/ou un rel=prev pour les données précédentes. Le client n’a qu’à suivre les liens.

En pratique

OK, je triche parce que je n’explique rien, alors je vais prendre un exemple : Un hypothétique client Twitter sur une hypothétique API Twitter (je m’autorise donc à ne pas préciser ce qui se fait sur les API actuelles).

Lorsque Twitter vous retourne les 100 derniers tweets de votre timeline avec les identifiants 3245 à 3566, il peut vous renvoyer deux liens dans les entêtes :

  • Un rel=last qui mène en fait vers l’exacte requête que vous avez faite mais avec en plus un paramètre since_id=3566. Quand vous voudrez rafraichir votre timeline, il vous suffira de suivre le lien. Il vous retournera les nouveaux messages jusqu’au 3566 non compris, mais jamais ceux que vous avez déjà reçu.
  • Un rel=prev qui mène vers l’exacte même requête que vous avez faite, mais avec en plus un paramètre max_id=3245. Quand vous voudrez aller chercher les messages plus anciens, il vous suffira de suivre le lien.

Si vous suivez un rel=prev après avoir suivi un rel=last vous finirez avec un lien qui contient et un since_id et un max_id, vous assurant de combler les trous que vous avez dans votre timeline, sans jamais renvoyer un message en double ni en oublier.

Si vous souhaitez faire une synchronisation complète, il suffit de stocker tous les liens rel=prev que vous recevez dans une liste, et d’aller les suivre un à un à la fréquence que vous souhaitez. Vous pouvez avoir un autre fil d’exécution en parallèle qui suit le rel=last de temps en temps (il n’y en aura qu’un seul à la fois, vous en aurez un nouveau à chaque fois que vous suivez le précédent).

Bon, dans la vraie vie vous aurez généralement un rel=next (messages juste suivants) plutôt qu’un rel=last (derniers messages), mais Twitter est particuliers : Ça va si vite qu’en général la priorité est d’avoir les derniers messages à date, quitte à générer des trous dans la timeline qui seront comblés plus tard.

Twitter est aussi facile parce qu’on trie toujours pas date, et que l’identifiant unique de chaque message est toujours ordonné lui aussi. Ailleurs on utilisera peut être la date de dernière modification comme pivot pour gérer la pagination. L’important est que le critère de tri soit cohérent avec la donnée utilisée comme pivot