Rétrospective : les bonnes pratiques d’un produit data partagées auprès de la communauté de Numérique en Commun(s)
Rétrospective de Mathilde Bras, avec les contributions de Cécile Le Guen, Augustin Courtier et Quentin Leroy
Les 19 et 20 octobre 2023, la communauté du numérique d’intérêt général s’est retrouvée à Bordeaux pour sa – désormais traditionnelle – grande réunion : Numérique en Commun(s). Cette année, 5 axes thématiques ont ponctué la programmation : données & territoires, écologie & soutenabilité, éthique & émancipation, communs & souveraineté, médiation & compétences numériques.
L’occasion pour Numéricité, partenaire de l’événement, de proposer plusieurs formats de partage d’expérience et de bonnes pratiques autour de défis qui nous tiennent à coeur : l’acculturation par le produit d’équipes ou d’organisations qui souhaitent se transformer, et la mobilisation du droit, en particulier du RGPD, comme un levier d’accélération des services publics numériques.
Dans cet article rétrospective, Mathilde Bras, Strategy & Innovation Manager chez Numéricité, revient sur les principaux enseignements partagés lors de l’atelier “Meilleures pratiques pour un projet data avec et pour des utilisateurs non tech”, et consolide 5 principes d’action pour des projets et produits data.
Entreprendre un projet data, un défi pour des profils techniques et non techniques
J’accompagne et entreprends de multiples projets autour de la donnée, depuis la conception de feuilles de route data jusqu’au développement de services d’exploitation de données métiers. Très souvent, je me retrouve dans une situation où les acteurs du projet ont besoin de parler le même langage, tout en mobilisant leurs propres expertises.
Mon rôle de coach est justement de traduire “le langage” des décideurs, faire remonter les besoins des utilisateurs auprès des équipes produit, être médiatrice des besoins opérationnels, et aussi de faciliter l’identification collective de points de passage. Cela se traduit concrètement par la définition des premières orientations du produit, l’identification des parties prenantes à associer, mais aussi la manière de mobiliser les utilisateurs, le mode de communication sur le produit, les risques potentiels, les compétences à mobiliser, etc.
Pour Numérique en Communs, j’ai donc proposé un exercice ouvert d’introspection à plusieurs porteurs d’initiatives liées à la valorisation des données publiques, qu’elles soient partagées en open data ou entre administrations :
- Cécile Le Guen, responsable du pôle outils de pilotage par la donnée au sein de la Direction interministérielle du numérique, en charge du projet PILOTE
- Quentin Leroy, ingénieur au sein du Ministère de l’Intérieur, membre du programme 10%, porteur du projet ChartsGouv, l’outil open source et presque no-code de visualisation des données de l’Etat, basé sur Apache Superset
- Augustin Courtier, co-fondateur de l’association Latitudes, porteuse de l’Open Data University, un programme d’apprentissage à la réutilisation de données ouvertes, lauréat de l’Accélérateur d’initiatives citoyennes
- Mathilde Bras – moi-même – pour parler du produit Causes médicales de décès, accompagné au sein de la Fabrique numérique des ministères sociaux
En racontant nos expériences aux participants de l’atelier, nous avons pu partager des défis communs lorsqu’il s’agit de construire des produits qui se fondent sur l’exploitation de données. Leur similitude : à chaque étape, il est important de transformer des idées reçues en opportunités pour faire avancer son projet. Quelques exemples partagés pendant l’échange (nous avons partagé des exemples fictifs, mais inspirés de la réalité) :
- “J’ai besoin de 5 data-scientists pour réaliser le projet, rien d’autre” : en réalité, un projet data nécessite de s’intéresser à une pluralité de profils, tech et non tech. Une personne spécialisée en droit du numérique peut vous être utile, tout comme des compétences capables de traduire le besoin du métier en parcours (les UX designers)
- “Je sais déjà ce que je souhaite développer, pas besoin de s’adresser aux futurs utilisateurs” : en réalité, en vous adressant aux utilisateurs, vous allez pouvoir considérer l’usage des données comme un intrant pour sa structuration et sa mise en qualité. Dans le cas d’un produit data, il peut s’agir des producteurs de données, des réutilisateurs (techniques et métiers), et de décideurs (dans le cas d’un tableau de bord par exemple)
- “Le droit ne nous permet pas d’exploiter ces données, on ne peut les intégrer au prototype, il faut attendre la mise en production et l’homologation” : le fait de se poser des questions juridiques dès le démarrage du projet peut aussi être un levier pour transformer la gouvernance d’un projet, d’une politique publique ou d’une base de données
- “Commandons un logiciel sur étagère, ce sera plus simple dans la durée” : considérer la force de l’open-source est la clef. Il existe aujourd’hui des librairies très riches en matière d’exploitation et de transformation de données, tout comme d’applications de cartographie ou visualisation
- “Apprendre à des personnes non spécialisées en données à les réutiliser ne sert à rien” : bien au contraire, cela peut constituer un réel outil d’acculturation sur la manière dont les données sont produites, leur utilité pour prendre des décisions et se représenter le réel, et ainsi créer de l’engagement autour des politiques publiques qu’elles suivent
Quelques principes d’action pour développer des produits data avec et pour des utilisateurs non spécialistes de la donnée
Forts de ces témoignages et des questions posées par les participations de l’atelier NEC, nous avons consolidé quelques principes d’action pour guider des personnes travaillant actuellement ou prochainement sur des projets ou produits data, qu’elles aient des compétences “techniques” en données ou non.
Notre livrable pour la communauté Numérique en Communs – 5 principes d’action de projet data en commun(s) :
- Opérer une médiation constante entre les utilisateurs et les données (et le produit) : avoir accès à une base de données n’est pas l’objectif, c’est seulement un éventuel moyen pour répondre à des besoins “métiers” ou “usagers”. Une ou un responsable de produit data a la mission de garder en tête cette perspective, pour éviter par exemple que le service développé soit uniquement compréhensible – et donc utilisable – par les personnes qui connaissent la donnée par coeur. Concrètement, cela implique de s’intéresser autant à l’utilisation – donc la valeur de la donnée – qu’à sa qualité ;
- Travailler la gouvernance – technique et organisationnelle – tout au long du projet/produit : lors de la conception, échanger avec les personnes qui produisent, reçoivent, transmettent ou transforment la donnée, non seulement pour les inclure – et mobiliser leur expertise ! – dans les différents temps forts du projet, mais aussi pour identifier les enjeux liés à la qualité de la donnée, qui est la clef de tout projet data. Concrètement, pour le projet PILOTE, cela impliquait de se poser la question du cycle de vie des données : est-ce que je dispose de données ou le projet consiste à aller en chercher ? qui les produit ? qui est responsable des mises à jour, du stockage ? ces données doivent-elles respecter des standards de qualité ? sont-elles sensibles au sens du RGPD ?
- S’appuyer sur les forces de l’open source – et des communs – pour construire des projets data : les standards publics sont pour cela très inspirants. Tout service public numérique doit rendre son code ouvert (”public money, public code”, vivent les communs !). Au-delà du code produit, aller chercher des briques techniques dans l’état de l’art pour développer de services est souvent gage de qualité. Celles en vogue en ce moment sur les données : VueJS (développement d’applications), Apache Superset (datavisualisation), la suite ELK (import de données, requête, analyse et visualisation), Kubernetess (infrastructure de conteneurisation), Keycloack (identité et gestion des accès). Cela implique bien sûr de réaliser de la veille régulière sur ces briques, leurs mises à jour, et de s’appuyer sur la communauté de contributeurs ! Et on ne peut s’empêcher de citer Onyxia, un environnement de travail à l’état de l’art pour la data, open source et propulsé par les équipes de l’Insee, dont les cas d’usage ne font que se multiplier (voir nos travaux sur le projet DATAFID)
- Considérer le droit comme une opportunité d’innovation et d’accélération : aujourd’hui de nombreux standards doivent s’appliquer aux services numériques développés par des acteurs publics et des questions de droit (qui vont au-delà des sujets techniques) peuvent se poser tout au long du projet, et même si cela demande du travail, c’est une opportunité ! Lors d’un projet data, on peut se rendre compte que certains textes doivent être harmonisés, ou proposer une nouvelle mouture d’une disposition juridique. Et surtout, on peut aussi imaginer des facilités de prototypage même si notre produit n’a pas été homologué : un exemple concret tout récent, la génération de données “fictives”, qui respecte le schéma des données “réelles”, afin de tester une première version d’application, avant la mise en production (en savoir plus avec le projet CM2D ici)
- Dépasser les frontières de la documentation (technique) pour en faire une plateforme pour la communauté : si vous avez déjà travaillé dans des équipes produits, vous avez déjà dû entendre râler autour de vous lorsqu’il s’est agi de documenter une application ou un service. En réalité, documenter un produit peut en faciliter son adoption, inspirer des utilisateurs sur des usages possibles et permettre le déploiement à grande échelle. Concrètement, comme nous l’a raconté Quentin pour ChartsGouv, cela implique – bien sûr – de publier le code, les informations d’installation (comme un mode d’emploi) et d’aller plus loin en répertoriant des cas d’usages et en réunissant régulièrement la communauté. Dans le cas de l’Open Data University, c’est plus que de la documentation, c’est un plaidoyer sur la vertu pédagogique de l’open data enseigné au sein de multiples formations : qui engagent les étudiantes et étudiants à s’intéresser non seulement aux données publiques, mais aussi au secteur public en général !
Ces principes ne sont pas exhaustifs, nous espérons qu’ils pourront guider le plus grand nombre ! N’hésitez pas à nous faire part de vos retours d’expérience par mail : communication@numericite.eu !
Ressources associées
Un support d’atelier pour identifier des bonnes pratiques dans des projets data
