Designer de données : comment co-construire des outils utiles aux communautés

Le designer de données est souvent associé aux tableaux de bord, aux cartes et aux graphiques. Pourtant, son travail commence bien avant le choix d’une visualisation. Lorsqu’il intervient auprès d’une communauté, son rôle consiste d’abord à aider des personnes aux expériences et aux intérêts parfois très différents à formuler une question commune, puis à construire un outil qui leur permette d’agir. Cette approche place les données au service d’un besoin concret, plutôt que l’inverse.

En décembre 2024, l’enjeu est particulièrement important : les organisations produisent et diffusent toujours plus d’informations, mais leur abondance ne garantit ni leur compréhension ni leur utilité. Des données mal documentées, difficiles à consulter ou présentées sans contexte risquent même de renforcer les écarts entre celles et ceux qui savent les exploiter et les autres. Le design de données engagé cherche précisément à réduire cette distance.

Le designer de données, un traducteur entre informations et décisions

Le métier de designer de données ne se résume pas à « embellir » des chiffres. Il se situe à l’intersection de plusieurs compétences : comprendre une information, organiser sa circulation, concevoir une interface claire et tenir compte de la manière dont elle sera réellement utilisée. Dans une démarche sociale, s’y ajoute une exigence décisive : faire une place aux personnes directement concernées.

Cela change la question de départ. Au lieu de demander uniquement « quelles données avons-nous ? », une équipe peut commencer par demander : « quel problème les habitants, les associations, les agents ou les usagers cherchent-ils à résoudre ? ». Une base de données, une carte ou un tableau de suivi n’ont de valeur que s’ils aident à répondre à cette question.

Cette position exige de reconnaître qu’une donnée n’est jamais entièrement détachée de son contexte. Il faut choisir ce qui sera observé, la manière de le classer, les personnes qui le renseigneront et celles qui pourront y accéder. Ces choix peuvent sembler techniques, mais ils déterminent ce qui devient visible, et ce qui reste absent d’un outil.

Pourquoi associer les communautés dès le début ?

Consulter les utilisateurs à la toute fin d’un projet permet parfois de corriger une interface. Les associer dès le départ permet de mieux définir le problème lui-même. Cette différence est essentielle. Une solution conçue sans les personnes qui l’utiliseront peut reposer sur des catégories inadaptées, des indicateurs peu parlants ou des modalités d’accès irréalistes.

La participation peut prendre plusieurs formes, selon le temps disponible et la nature du projet :

• des entretiens pour comprendre les usages, les obstacles et le vocabulaire employé localement ;
• des ateliers pour hiérarchiser les besoins et discuter des indicateurs à retenir ;
• une collecte participative, lorsque les personnes concernées peuvent contribuer à documenter une situation ;
• des tests réguliers d’une carte, d’un formulaire ou d’un tableau de bord avant sa diffusion ;
• des temps de restitution pour interpréter les résultats collectivement et les corriger si nécessaire.

L’objectif n’est pas de faire participer les habitants de manière symbolique. Une démarche crédible suppose de dire clairement ce qui peut être décidé avec eux, ce qui ne le peut pas, et ce qui sera fait de leurs contributions. Il faut aussi reconnaître que « la communauté » n’est pas un bloc homogène. Des intérêts, des compétences, des disponibilités et des rapports de pouvoir différents peuvent s’y exprimer.

La confiance se construit donc dans la durée. Elle passe par une écoute active, des règles compréhensibles, des réponses aux désaccords et un retour vers les participants une fois les décisions prises. Sans cela, la consultation peut donner l’impression que des informations ont été demandées sans produire d’effet concret.

Construire une architecture de données commune

L’expression « architecture de données » peut évoquer une infrastructure complexe réservée aux spécialistes. Dans un projet collectif, elle désigne plus simplement l’ensemble des règles qui permettent de savoir quelles informations sont recueillies, comment elles sont organisées, qui les gère et à quelles fins elles servent.

Une architecture partagée évite plusieurs écueils fréquents : accumuler des données sans savoir quoi en faire, confondre des informations de qualité inégale, ou créer un outil que personne ne peut maintenir. Elle rend aussi les responsabilités plus visibles. La discussion technique devient alors une discussion sur les usages, les droits et les priorités.

La documentation est souvent moins visible qu’une interface, mais elle est déterminante. Elle doit notamment préciser l’origine des données, leur date, leur mode de collecte et leurs éventuelles lacunes. Sans ces éléments, un chiffre ou une carte peut sembler précis tout en étant difficile à interpréter correctement.

Adapter le projet aux réalités culturelles et sociales

Un dispositif pertinent dans un lieu ne l’est pas nécessairement dans un autre. Les habitudes numériques, la maîtrise de l’écrit, les langues parlées, les conditions d’accès à internet, les rythmes de travail et les relations avec les institutions influencent directement l’utilisation d’un outil.

C’est pourquoi les méthodes qualitatives ont une place importante dans le design de données. Observer des situations d’usage, mener des entretiens ou animer des ateliers ne remplace pas l’analyse de données. Ces démarches lui donnent un sens. Elles permettent, par exemple, de vérifier qu’un indicateur correspond à une réalité vécue, qu’une catégorie n’exclut pas involontairement une partie des personnes, ou qu’un formulaire peut être rempli dans les conditions réelles du terrain.

L’adaptation ne doit pas se réduire à changer une langue ou une mise en page. Elle consiste à comprendre quelles informations sont jugées utiles, qui est légitime pour les produire et quelles formes de restitution inspirent confiance. Dans certains cas, une présentation orale, un support imprimé ou une médiation humaine peut être plus approprié qu’un portail numérique sophistiqué.

Les technologies ouvertes : une opportunité, pas une garantie

Les technologies ouvertes peuvent faciliter le travail collectif. Des formats réutilisables, des outils partagés ou des ressources documentées permettent à plusieurs acteurs de contribuer, de vérifier et d’améliorer un projet. Une infrastructure de données accessible peut aussi limiter la dépendance à un prestataire unique et donner davantage de continuité à une initiative locale.

L’ouverture ne doit toutefois pas être confondue avec l’absence de règles. Rendre une donnée disponible ne signifie pas qu’elle est compréhensible, à jour ou sans risque. Certaines informations peuvent révéler des éléments sensibles sur des personnes ou des groupes. D’autres peuvent être mal interprétées hors de leur contexte. Un projet responsable doit donc définir des niveaux d’accès, protéger les données personnelles lorsque cela est nécessaire et expliquer les conditions de réutilisation.

L’accès réel dépend également de facteurs très concrets : un équipement disponible, une connexion, du temps, des compétences et un accompagnement. Un fichier publié dans un format théoriquement ouvert reste peu utile s’il est impossible à lire sans connaissances spécialisées. L’ouverture est donc une condition favorable à la participation, mais elle doit être accompagnée d’efforts de médiation et de formation.

Les limites des données disponibles et le risque d’inégalités

Les groupes citoyens et les petites organisations ne partent pas tous avec les mêmes ressources. Certains disposent déjà d’informations structurées et de personnes capables de les analyser. D’autres doivent consacrer beaucoup de temps à retrouver des documents, vérifier des chiffres, numériser des archives ou combler des données manquantes. Ce travail de base est essentiel, mais il est souvent sous-estimé.

Les structures institutionnelles peuvent aussi limiter l’accès à des informations utiles, qu’il s’agisse de procédures complexes, de formats peu pratiques ou de données incomplètes. Le designer de données ne peut pas résoudre seul ces obstacles. En revanche, il peut les rendre visibles et organiser le projet autour de contraintes clairement identifiées, plutôt que de les masquer derrière une représentation trop lisse.

Cela implique de ne pas promettre une objectivité absolue. Une carte ou un indicateur montre ce qui a été mesuré. Il ne raconte pas automatiquement tout ce qui compte. Présenter les zones d’incertitude, les absences de données et les choix méthodologiques est une marque de rigueur, pas un aveu d’échec.

Agences, équipes internes et étudiants : élargir les compétences

La collaboration avec une agence de design peut apporter des compétences complémentaires : recherche auprès des usagers, conception d’interface, visualisation, facilitation d’ateliers ou mise en forme d’une identité claire. Pour être féconde, cette relation doit toutefois conserver le lien avec les utilisateurs finaux. Une agence ne peut pas se substituer durablement à la connaissance vécue d’un territoire ou d’un groupe.

Les responsables de projet ont donc intérêt à définir, dès le départ, le rôle de chacun : qui décide des priorités, qui détient les données, qui valide les restitutions et qui assurera la maintenance. Cette clarification évite qu’un outil innovant en apparence soit abandonné faute de responsable, de budget ou de compétences après sa mise en ligne.

Les établissements d’enseignement ont également un rôle à jouer. Encourager les étudiants à travailler sur les effets sociaux des données les conduit à dépasser la seule performance technique. Ils peuvent apprendre à formuler un problème avec les personnes concernées, à expliquer leurs choix et à considérer les conséquences d’un outil sur différents publics. Cette culture de la coopération est aussi importante que la maîtrise d’un logiciel ou d’une méthode statistique.

Mesurer l’utilité sans réduire l’impact à un chiffre

Évaluer un projet de design de données demande de fixer des repères dès son lancement. Il peut s’agir de vérifier si les utilisateurs trouvent l’information recherchée, s’ils comprennent les indicateurs, s’ils participent au processus, ou si l’outil nourrit effectivement une décision, une action ou un débat.

Les retours d’expérience ont ici autant de valeur que les mesures d’audience. Un outil très consulté mais mal compris peut avoir un impact limité. À l’inverse, un dispositif utilisé par un groupe restreint peut être utile s’il répond précisément à son besoin. L’évaluation doit donc combiner des éléments quantitatifs et qualitatifs, en demandant aux participants ce qui a changé, ce qui reste difficile et ce qui devrait être amélioré.

Ce qu’il faut surveiller pour un design de données plus équitable

La promesse du design de données engagé tient moins à la technologie elle-même qu’à la qualité de la relation construite autour d’elle. Les projets les plus solides sont ceux qui prévoient du temps pour écouter, expliquer, tester, corriger et maintenir. Ils ne supposent pas que la publication d’une plateforme suffira à créer de la participation.

Trois points méritent une vigilance particulière : la protection des personnes lorsque des données sensibles sont en jeu, la capacité concrète des utilisateurs à comprendre et employer l’outil, et la continuité du projet après sa phase de conception. Associer les communautés n’est pas seulement un moyen d’améliorer un produit. C’est une manière de partager la capacité à définir les problèmes et à participer aux décisions qui en découlent.

Dans cette perspective, le designer de données devient un facilitateur. Il ne parle pas à la place des groupes concernés et ne prétend pas que les données tranchent seules les débats. Il crée les conditions pour que des informations mieux comprises, mieux documentées et mieux partagées deviennent un appui pour l’action collective.