Parmi les petites aventures que j’aime mener de front, il y a la création de cartes de territoires. Par exemple, durant le confinement j’ai pu expérimenter la fameuse zone des 100 kilomètres autour du domicile, lors de l’arrivée du port du masque obligatoire ce fut la même chose avec une carte de l’ensemble des villes concernées. Ou encore avec LesGrossesCartes qui permet à n’importe qui de créer une carte avec beaucoup d’informations à partir d’un back-office dédié ou via une API.

Mais tout ceci ne se résume au final qu’à une chose : avoir des choses à partager sur un support bien visuel.

C’est donc le défi que je me suis lancé avec la carte des zones à couvre-feu.

Le petit lien : https://restrictionsenfrance.fr

Mais alors, comment on fait exactement ?

Le plus simple est de repartir un peu en arrière. Un site web est composé de différentes choses : un serveur, un nom de domaine et d’un ensemble de fichiers (les informations que l’on affiche aux visiteurs).

À ceci, s’ajoutent les services annexes, des APIs par exemple. Ce qui est le cas avec l’usage de Google Maps et l’intégration par la suite de Google Analytics pour suivre le trafic du site. J’utilise la suite d’outils de chez Google par simplicité et rapidité.

Je vois déjà pointer le nez de ceux qui défendront le libre et l’open source. Je suis de tout cœur avec eux, étant également de ceux qui souhaitent que l’information circule le plus librement possible. Toutefois, la facilité technique et la rapidité d’exécution étaient pour moi indispensables : mon choix s’est tourné vers ce que je connais et ce que je peux maîtriser en peu de temps.

Cette carte, comme les autres que je crée parfois, est un MVP de ce que j’ai en tête.
MVP : Minimum Viable Product

Je ne compte pas dégager de profit de ce site, je souhaite simplement faire vite, bien et sans accrocs majeurs.

Voici à quoi ressemble l’ensemble de fichiers que j’ai déposé sur mon serveur, il s’agit d’un site statique, sans base de données, réalisé avec de vieilles technologies : HTML, CSS et JavaScript.

Ensuite, un petit détour du côté de Google Cloud Platform pour activer l’utilisation de plusieurs API nécessaires (Google Maps API, Places API, Directions API), maintenant il est temps de passer au gros du sujet.

Les données, les données, les données.

La cartographie en France est un joli sujet. Nous disposons aujourd’hui d’un tas de sources différentes pour récupérer de l’information qualifiée à moindre coût (et même gratuitement).

La plateforme OpenDataFrance fourmille de sources de données que l’on peut réutiliser comme bon nous semble. C’est ainsi que j’ai pu créer la première version du site, avec la zone de couvre-feu par métropole concernée.

Par la suite, avec les changements du 22 octobre 2020, j’ai dû adapter le site avec l’affichage des départements touchés par les restrictions. Ceci n’aurait pas été possible sans les fichiers GeoJSON trouvés sur Internet et sur GitHub.

Parfois ceux-ci nécessitaient une légère mise à jour pour être totalement fonctionnels, mais rien d’insurmontable pour ceux qui prennent le temps d’en comprendre le fonctionnement.

L’une de mes sources de données a été le site et le compte GitHub de Grégoire David :

Par la suite, j’ai pris sur moi de trouver les bonnes ressources, les mélanger puis faire en sorte que tout fonctionne correctement.

GeoJSON ?

Le format GeoJSON est une variante du format JSON qui permet de décrire des zones géographiques à placer sur une carte. Ce format permet de diffuser des informations géographiques rapidement, de façon normée et avec des informations complémentaires (il est possible d’y ajouter des noms, descriptions …).

Le code !

Il était alors temps de mettre les mains dans le concret pour proposer un système simple de représentation visuelle de notre territoire sous couvre-feu. J’ai repris la base qui m’avait servi sur 100km.space au niveau graphique puis je l’ai de nouveau adaptée aux nouveaux besoins.

La première nécessité était de positionner une adresse sur la carte et d’y apposer la couleur de la zone (rouge = couvre-feu, rien = tout va bien).

La seconde nécessité était de proposer une fonctionnalité de calcul d’itinéraire pour vérifier que nos futurs déplacements ne risquaient pas de nous propulser dans l’illégalité en nous rendant dans une zone de couvre-feu à la mauvaise heure.

J’y ai ensuite ajouté différents GeoJSON correspondants aux départements concernés et la technique fait le reste. Voici ci-dessous le code qui fait toute la magie :

Pour réagir vite concernant les zones concernées, j’ai décidé de travailler avec Google Sheets pour pouvoir générer mon code JavaScript. Ce qui fait qu’à partir d’une liste des départements de France, je peux en quelques clics avoir un code propre à déposer sur le serveur, sans manipulations fastidieuses.

J’ai également pris le temps de réunir les liens les plus demandés : le générateur de déplacements et la foire aux questions du site gouvernemental.

Ensuite ?

Par la suite, je vais analyser ce que les utilisateurs attendent du site, suivre l’évolution de la réglementation et proposer des choses utiles pour la plupart des personnes concernées.

Loin de moi l’idée d’en faire un couteau suisse perfectionné, mais d’en garder absolument le côté facile d’accès.

N’hésitez pas à proposer vos axes d’améliorations directement depuis Twitter !

U.

Un site web sans mouchards et sans (mauvaises) statistiques.

On voit apparaître une nouvelle tendance depuis plusieurs mois : affirmer que les sites proposés aux visiteurs sont sûrs et ne fournissent pas de données aux grands méchants du web.

En l’occurrence, il est fréquent de retrouver Facebook et Google sur le devant de la scène. Les données sont désormais un peu moins partagées, un peu plus protégées et un peu mieux utilisées.

Cela fait maintenant plusieurs années que je n’installe plus Google Analytics sur mes sites personnels. Lorsqu’il s’agit d’un site d’un client (et sur sa demande), je continue à installer ces bouts de codes qui permettent de tracer les activités d’une personne.

Depuis plusieurs années, je déploie des sites sans aucune donnée collectée. Y compris côté réseaux sociaux. Je tente de faire une chose simple : me demander à chaque fois si j’en ai réellement besoin.

Concernant les statistiques de visite, je n’en ai aucune utilité. Je préfère mesurer le taux d’interaction avec les visiteurs. Le nombre de fois où je reçois un email, le nombre de messages reçus sur LinkedIn ou Twitter.

D’ailleurs, c’est un peu ce que je propose à chaque nouvelle idée : quel est l’intérêt de tout connaître des utilisateurs ? Qui va réellement vérifier les informations collectées ? Quel but est caché derrière ce sentiment de toute puissance ?

Lors de mes précédentes expériences professionnelles, j’ai eu l’occasion de faire un nombre conséquent de jeux en ligne dotés d’un formulaire de contact. Ces données sensibles étaient envoyées par fichiers emails au format Excel. Un tirage au sort était effectué puis les données étaient oubliées.

Je n’ai jamais eu un client souhaitant récupérer le fichier Excel de ses participants pour les inclure dans sa démarche de connaissance client. Agrémenter son CRM avec des données sociales ? Quelle idée farfelue 😉

Typiquement, cette démarche de collecte façon Big Data sans analyse par la suite entre dans la logique du FoMO : Fear of missing out. Cette peur constante de rater possible quelque chose peut nous pousser à collecter les données “par sécurité” parce que vous comprendrez que “on ne sait jamais“.

Ce n’est pas parce que tout le fait qu’il s’agit d’une bonne pratique. Parfois oui, souvent non. Ce sentiment d’appartenance est fort, lorsqu’on tente d’en sortir, un vide peut se créer et une peur primaire arrive : pourquoi est-ce que je fais différemment des autres ? Est-ce que c’est grave ?

Mais une autre arrive assez vite au final, est-ce que l’on a besoin d’autant d’informations au quotidien ?

E.

En faire moins pour mieux en faire.

Lorsqu’il est question de développement de produit ou de service, la notion de création de valeur arrive sur le ring. Le combat peut vite devenir inégal si l’on se confronte à un marché, et pas juste à son imagination. Voici le constat que j’en ai fait à force de tuer des projets.

Il est aussi probable que l’envie de faire plus que l’autre ne soit pas toujours une priorité. C’est même ce que je défends assez souvent lorsque je rencontre d’autres entrepreneurs. Il n’est pas nécessaire d’être meilleur que son concurrent sur l’ensemble des tableaux : il faut s’astreindre à ne faire mieux que sur certains volets.

Cette innovation d’usage passe par une sélection plus drastique des fonctionnalités que l’on souhaite proposer. Il est inutile de céder à la tentation de tout faire : ce n’est ni raisonnable ni réalisable. Après tout, pour le commun des mortels, le couteau suisse est surtout un beau tire-bouchon ou un joli coupe-papier.

Ceci inclut la nécessité de proposer moins d’options, de préférences utilisateur. L’amélioration et la personnalisation de l’expérience passent par la phase d’épuration des capacités proposées. Il faut aller plus vite au cœur de ce que l’on propose.

Idem concernant les équipes, avec une taille plus réduite, mais plus impliquée, la notion d’efficacité et de rapidité d’exécution peut revenir dans les discussions d’évolution de l’offre. Le management d’équipe se fait souvent au détriment du management produit.

Il redevient possible d’imaginer avancer réellement en proposant moins de réunions, moins de rencontres entre individus, moins d’abstrait, moins de discussions sans décisions. Les freins sont plus souvent humains que technologiques.

Un peu à l’image de l’adage de la startup nation : « fake it until you make it ».

Mais ces belles envies qui ressemblent à un ensemble de portes ouvertes ne sont valables que si je me force aussi à promettre moins, promettre mieux, plus réaliste et moins idéaliste sur les projets menés de façon collaborative.

Depuis que j’adopte certains de ces beaux principes, je me suis rendu compte que les retours étaient ultra positif. Ce n’est pas vraiment ce que j’avais comme croyance avant de l’expérimenter.