Le 24 avril 2019, la direction générale des finances publiques a ouvert et mis en ligne donnees qu’elle détient sur les ventes de biens immobiliers et de biens fonciers non bâtis réalisées au cours des cinq dernières années. Pour que cette base de données DVF ( « Demande de valeur foncière ») puisse être visualisée sur une carte sans qu’il soit nécessaire de les télécharger, ou de les manipuler, la mission Etalab a développé une application web : app.dvf.etalab.gouv.fr.
Etalab pensait ainsi atteindre un public plus large que la communauté de l’open data.
« Contre toute attente », explique la mission Etalab sur son blog, « notre application web a reçu plus d’un million de visites en moins de deux semaines … La couverture presse a amené un public plus large sur l’application ; un public venu chercher des informations sur ses propres transactions, dans le cadre d’un projet immobilier, ou simplement curieux des prix pratiqués dans certains quartiers. Et les avis d’utilisateurs se sont multipliés, nous amenant à apporter encore de nombreuses modifications à l’application ».La Mission etalab tire, sur son blog, une série d’enseignements de cette réalisation et succès qu’elle a rencontrée.
- Les visualisations touchent plus de monde que les données brutes: « Alors que app.dvf.etalab.gouv.fr a été développé comme un complément à la base des demandes de valeurs foncières, l’application a vite attiré plus de visiteurs que les données DVF elles-mêmes — publiées quant à elles sur data.gouv.fr. Le site qui devait introduire les données brutes s’y est donc rapidement substitué. Parallèlement, ce qui n’était qu’une petite application développée en peu de temps et avec peu de moyens au sein d’Etalab, a souvent été présenté dans la presse comme le produit principal de cette opération ».
- Bien configurer un serveur n’est jamais une mauvaise idée: « Il est possible de gérer un afflux conséquent de visiteurs sans se ruiner. Nous avons ainsi pu accueillir plus de 180 000 personnes sur l’application lors de la seule journée du vendredi 4 mai, sur un serveur relativement modeste, et en limitant les rejets grâce à des choix technologiques prudents ».
- Documenter n’est pas une perte de temps: « Pour donner un peu de contexte aux visiteurs, et répondre aux questions qui revenaient souvent à nos oreilles, nous avons mis en ligne une FAQ (Foire Aux Questions) quelques heures après la publication de l’application ».
- Recueillir des avis permet d’améliorer l’expérience utilisateur: « En plus des problèmes de compatibilité de l’application avec certains navigateurs, la mise en place du questionnaire « Votre avis nous intéresse » nous a permis d’identifier d’autres problèmes : nous nous sommes ainsi rendu compte que plusieurs utilisateurs ne comprenaient pas vraiment comment marchait l’application. (…) Nous en avons retenu que nous ne sommes pas nos utilisateurs et que rien ne remplace les avis de personnes venues de l’extérieur ».
- Rendre le code public le rend meilleur: « Mettre le code d’une application en cours de développement sur GitHub, dans un dépôt public, revient à exposer un travail inachevé, encore loin d’être parfait. Mais la publication du code nous a aussi permis d’obtenir des avis très utiles ».
- Les critiques font partie du jeu: « Si nous avons reçu des félicitations, nous avons aussi reçu quelques critiques. Certaines critiques étaient constructives, d’autres l’étaient un peu moins. De notre côté, nous savions que notre application étaient loin d’être parfaite. Nous avons donc capitalisé sur les critiques utiles, celles qui nous tiraient vers le haut, sans nous attarder sur les autres ».
Référence :
