Au cours des quatre années que j'ai passées chez Antidot (2010-2014), j'ai assisté à des changements profonds dans la manière de penser la monétisation des données. Un constat s'est peu à peu imposé : la donnée elle-même perd de sa valeur marchande et toutes les organisations dont le modèle économique repose peu ou prou sur la vente de données prennent peu à peu conscience de l'obligation d'inventer de nouveaux modes de rémunération. C'est un changement long et complexe auquel les producteurs de contenus dans leur ensemble doivent faire face et il suffit pour s'en convaincre de voir les déboires que vit la presse. Chacun est à la recherche du ou des services, la seule source actuelle de monétisation acceptée par le consommateur, qui lui permettront de survivre à ces bouleversements, mais, dans la plupart des cas, force est de constater que le chiffre d'affaires qu'ils génèrent ne compense pas la baisse des revenus constatée par ailleurs.
Attention, loin de moi l'idée de me plaindre et de regretter le temps passé, d'autant qu'il faut bien le dire : certains producteurs de contenus s'étaient constitué de véritables rentes qu'ils exploitaient pour un service limité et évoluant peu voire pas. Après tout, cela donne l'occasion de redistribuer les cartes. Pourtant, il existe un point crucial qu'il ne faut pas mettre de côté : même si la donnée n'a plus de valeur marchande en soi, sa création représente toujours un coût. Or, la tentation est grande à l'heure des économies pour un manager dont les yeux seraient uniquement rivés sur le chiffre d'effectuer une coupe drastique dans cette activité si consommatrice de ressources.
Cette décision aurait des conséquences terribles. Au niveau de l'organisation elle-même, elle marque le début de sa lente descente aux enfers, car elle constitue une rupture dans la vocation même de l'organisation. Et de manière plus générale, cela déstabilise l'ensemble de l'écosystème de services qui s'est construit autour des données produites par cette organisation. Et c'est finalement là que réside le paradoxe : alors que nous sommes dans une situation où nous avons de plus en plus besoin de données de qualité pour construire de nouveaux services, nous allons faire face à une pénurie car nous n'aurons plus les moyens de les produire.
Puisque la donnée est la richesse de l'organisation, la base sur laquelle de futurs services peuvent être construits, c'est elle qui doit faire l'objet de toutes les attentions. Ainsi, plutôt que de réduire l'activité de production elle-même, il est nécessaire d'investir pour revoir les processus de production et d'exploitation.
Comment alors réduire les coûts pour s'assurer d'une donnée de qualité et créer de nouveaux usages ?
1- Libérer et lier toutes les données internes
Est-il nécessaire de revenir sur la valeur que constitue la mise en relation de toutes les données d'une organisation ? Ceux d'entre vous qui me suivent depuis plusieurs années m'ont certainement maintes fois lu, vu ou entendu discourir sur cette question (et pour les autres, quelques présentations pour rattraper le retard : Linked Enterprise Data : disposer d'une vue consolidée des données, Wikidata, quand Wikipedia s'intéresse aux données, Relier, réutiliser, partager : l'apport du Web de données avec Emmanuelle Bermès). Il me semble que c'est la base même de toute réflexion sur la production et l'exploitation des données car cette démarche permet de mettre en cohérence, de rationaliser et de casser les silos de données existants et ce faisant permet la mise en place d'une gouvernance des données et d'indicateurs à même de piloter les activités autour des données (donc y compris maîtriser les coûts liés à cette activité).
Par honnêteté, je me dois de faire mention d'un point important : je ne suis plus aussi sûr de la place centrale des technologies du Web sémantique dans cette démarche, du moins pas dans les proportions où je pouvais l'exposer. Et j'avoue être assez d'accord avec la position que Phil Archer a exposée à SemWeb.pro 2014, rappelée par Manue dans ce billet : attribuer des URIs, penser en graphe et faire du JSON-LD.
De plus, en liant les données issues des différents silos, elles sont libérées de leurs usages initiaux. En effet, en séparant les données de leurs usages applicatifs d'origine, les conditions (c'est à dire la métastabilité) sont réunies pour l'innovation et donc l'émergence de nouveaux usages. Et, une fois mis en place ce processus de libération en interne, il est assez simple techniquement d'en faire profiter l'extérieur par le déploiement d'une stratégie d'open data et d'open API dont les éléments dépendront autant de la nature des données que des objectifs que l'organisation souhaite atteindre par cette ouverture.
Par ailleurs, il existe tout un pan de données dont l'utilité a été démontrée ces dernières années. En effet, s'il y a une chose à retenir des premières années du Big Data (<teasing>qui fera l'objet du prochain billet</teasing>) au niveau des usages, c'est l'énorme potentiel et valeur des traces des utilisateurs. Les logs et les traces laissés par les utilisateurs et/ou produits automatiquement par leur comportement sur un site Web sont autant d'indicateurs qui peuvent enrichir les données "historiques" : systèmes de recommandations, de mise en avant, de similarité, prédiction du comportement, palmarès, liste, hit-parade.... Autant de possibilités ouvertes par l'exploitation de cette masse d'informations.
Dès 2010, Christian Fauré avait expliqué l'importance de ces deux points dans le billet les enjeux d'une bibliothèque sur le Web démontrant leur apport dans l'appréhension des ressources de l'organisation par l'internaute. Il parlait alors "d'orages sémantiques" construits à partir du Web analytic, du text mining, du data mining, des technologies d'indexation et des données structurées en RDF... J'avoue qu'il m'aura fallu quatre ans pour percevoir les enjeux exposés dans ce billet et appréhender les moyens techniques d'y parvenir <teasing>mais j'y reviendrai dans le prochain billet</teasing>.
2- Optimiser les processus de production eux-mêmes
Lorsqu'on aborde les processus de production, la révision des IHM vient évidemment à l'esprit en premier. En effet, la complexité des interfaces est bien souvent proportionnelle à la complexité/richesse des données produites. De plus, ces IHM sont bien souvent anciennes, leur modification étant redoutée car elle pourrait induire une baisse de la productivité et demande aussi un accompagnement au changement qui peut être long et difficile. Peut-être est-il alors possible de penser à un juste milieu et de les modifier par petites touches. Dans cette perspective, les modes d'organisation dits agiles ou itératifs comme la méthode Scrum constituent une bonne solution. Non seulement, ils rapprochent étroitement le métier et les forces de développement au sein d'une task force mais en plus ils impliquent des changements réguliers et en nombre limité ce qui simplifie l'acceptation du changement. Ainsi, les IHM peuvent évoluer par petites touches : système d'auto-suggestion, aide à la saisie, révision des petits défauts ergonmiques...
La révision des IHM constitue aussi un bon moyen pour identifier les tâches manuelles qui pourraient être automatisées. En effet, au fur et à mesure des années, les utilisateurs ont développé des stratégies (parfois très complexes) pour contourner une limitation de l'application ou exécuter des tâches récurrentes. Ils n'ont parfois pas conscience que ces tâches pourraient facilement et rapidement être automatisées. Inversement, la DSI a parfois tendance à railler les solutions mises au point par les utilisateurs et n'a pas conscience que l'ajout de telle ou telle fonctionnalité demandée depuis des années et toujours remise à l'année suivante constituerait une économie substantielle en raison de la répétition de la tâche. Le dialogue, l'écoute doivent donc être de rigueur au même niveau qu'un calcul de ROI pour ces petites tâches.
Dans le même ordre d'idée, la DSI a bien souvent tendance à présenter les systèmes automatiques comme la réponse miracle pour baisser les coûts ce qui a bien entendu pour conséquence de crisper les producteurs de données qui voient leur légitimité et leur compétence remises en cause par des robots. Au-delà des positions caricaturales des uns et des autres, les systèmes automatiques peuvent aider à fluidifier et à simplifier le travail, en le rendant plus efficace et/ou en le déplaçant vers des tâches finalement plus intéressantes (les systèmes automatiques pour fonctionner correctement doivent reposer sur des données de qualité dont la mise au point doit être l'objet de toutes les attentions). Il ne faut donc pas hésiter à proposer des systèmes d'extraction automatique, de classifications, de rapprochements ou des systèmes de règles... dans la mesure où ils sont présentés comme des assistants et non comme des remplaçants.
Enfin, dans certains cas, le crowdsourcing peut représenter un moyen de démultiplier les forces de production. Pour autant, une communauté ne se décrète pas, elle se construit et s'entretient par une animation régulière issue de l'organisation. Il existe plus d'échecs que de réussites en la matière et aucune recette miracle. Le recours au crowdsourcing doit donc être évalué au regard de la communauté potentielle, de l'intérêt que cela représente et des moyens d'animer et de modérer la communauté. Enfin, comme pour les systèmes automatiques, il ne faut éviter de présenter le crowdsourcing comme un moyen de remplacer les ressources et compétences internes mais plutôt le considérer comme une solution permettant de compléter ou de produire des données impossibles à produire en interne.
3- Récupérer et agréger des données externes
Les organisations ont dans de nombreux cas centralisé en interne la production de toutes les données. Or, force est de constater que d'autres organisations ont pour vocation de produire et maintenir certaines de ces données. Il existe ainsi des référentiels "universels" (liste des communes/régions/départements, codes postaux/INSEE, référentiels de personnes, référentiels d'organisations, statistiques diverses et variées, liste d'adresses...) dont la maintenance n'a peut-être que peu de sens au sein d'une organisation. La récupération automatique de ces données permettrait non seulement de supprimer le coût de maintenance interne mais aussi d'offrir peut-être des données plus complètes et à jour.
C'est dans ce domaine, à mon avis, que l'Open Data est le plus intéressant. En effet, s'il n'est pas impossible de contractualiser la récupération de données entre différentes organisations, la libération des données permet non seulement de simplifier de manière incomparable le processus de réutilisation (après tout il n'y a qu'à se servir) mais la présence des jeux de données libérés dans un annuaire permet d'en faire connaître l'existence auprès de tous.
Ainsi, l'Open Data peut certes concourir dans une certaine mesure à l'innovation des usages par les données, mais il est, à mes yeux, surtout un moyen de permettre des économies d'échelle substantielles par le fait qu'il permet de mettre en place un écosystème de données réutilisables et ainsi d'éviter aux organisations de maintenir certains données qui ne sont pas leur cœur de métier. C'est dans cette perspective que les notions d'interopérabilité et de confiance sont cruciales dans le processus de libération des données.
Last but not least, la récupération de données externes peut aussi enrichir les données de l'organisation. Cela ouvre la voie à l'émergence de nouveaux usages (géolocalisation grâce aux coordonnées géographiques, renseignements complémentaires sur une personne....) et à la création automatique de liens hypertextes entre les sites Web pour proposer des parcours thématiques inter-organisations (la logique institutionnelle n'a pas cours sur le Web, espace commun et unique de navigation...).