Cette page fait partie d’une série portant sur les bonnes pratiques collaboratives numériques.
Je vais:
- expliquer pourquoi je m’amuse à rédiger cette page 😉
- lister ce que j’entends par données dynamiques;
- énumérer quelques applications web qui permettent de produire des données dynamiques;
- présenter deux solutions pour créer des bases de données relationnelles;
- résumer les points les plus importants à retenir.
Pourquoi je m’amuse à rédiger cette page ?
Je vois quotidiennement que la majorité des personnes avec qui je collabore a tendance à travailler par défaut avec des fichiers statiques. Pour le meilleur, parfois, mais souvent pour le pire. Sans faire exprès, ces personnes se compliquent la vie, non pas forcément sur le court terme, mais clairement sur le long terme.
Pour le court terme, il est souvent plus facile de vite créer un nouveau document statique que de construire puis d’alimenter une base de données. Alors que sur la durée, il est bien plus efficace, intéressant et financièrement rentable de travailler à partir d’une base de données.
Pas pour tout bien sûr, mais pour une bonne partie des opérations et des livrables à poser dans le monde.
Pour donner une idée plus concrète, sur l’exemple d’une structure de production de films, je dirais qu’il y a plus de 60% des informations importantes qui devraient résider dans une base de données, et non pas dans une multitude de fichiers statiques. Qui très vraisemblablement contiennent plusieurs fois les mêmes informations, qui sont rarement vraiment à jour… donc avec un fort risque d’erreur, avec le stress lié à la gestion de ces informations.
Même un scénario pourrait être stocké dans une base de données… (ce qui est le cas si on utilise une application dédiée comme Yamdu par exemple).
Pour sortir de cette pensée du jetable (dans le sens du « après moi le déluge ») et du non pérenne, j’aimerais contribuer avec cette page dans la compréhension de l’intérêt d’une base de données, qui va nous permettre de produire des données dynamiques.
Que sont les données dynamiques ?
Il s’agit de “morceaux” d’informations stockées dans une base de données, qui fonctionne comme “l’unique source de vérité”. Il n’y a (à priori) plus d’informations redondantes qui existent dans plusieurs fichiers différents, qu’il faut mettre à jour en parallèle. Chaque donnée existe une fois, et fait sens à partir du moment qu’elle est liée à d’autres données.
Contrairement aux fichiers statiques, les données dynamiques peuvent être exploitées facilement pour des multiples usages différents, évolutifs dans le temps.
Il y a quatre choses importantes à saisir à ce stade:
- Toutes les données qui doivent rester à jour et qui sont potentiellement utilisées pour des usages variés et évolutifs devraient se trouver dans une base de données.
Exemple: lorsque vous créez un document Word qui contient toutes les informations sur un projet (équipe technique, synopsis etc), le moindre changement dans le document demande de mettre à jour toutes les autres occurrences (les PDF exportés, le site web etc). C’est une source d’erreur importante, sans parler du surcroît de travail que cela occasionne. La bonne pratique consiste à stocker dans une base de donnée relationnelle toutes les données qui vont dynamiquement évoluer en phase avec le développement du projet. - Les données sont structurées avec une granularité aussi précise et fine que possible.
Exemple: dans une base de données de contacts, on va séparer le nom de famille du prénom d’une personne, pour pouvoir traiter ces deux données de manière séparée. Il est possible de créer autant de tables spécifiques (par exemple une table contacts, une table projet etc) avec autant de champs que nécessaire – pour que chaque morceau d’information puisse être traité spécifiquement (d’où la granularité fine). - Les tables contenant les données sont liées les unes aux autres, pour former une base de données relationnelle.
Exemple: la table contact est liée à la table projet, de manière à pouvoir identifier les rôles pour les personnes travaillant sur les projets, tout en ayant toujours sous la main (de manière relationnelle) les informations de contact, si on veut appeler la personne. L’enjeu est de pouvoir construire une base de données relationnelle au service des flux de travail des collaboratrices et collaborateurs, tout en étant évolutive pour des nouveaux usages. Voir des exemples plus bas. - Les données peuvent être “servies” simultanément pour plusieurs applications et services différents.
Exemple: pour son site web, pour un formulaire de contact, pour un questionnaire, pour une application mobile… C’est ici que l’on peut mieux comprendre le concept de “source de vérité”: les données n’existent qu’une seule fois, et partout où elles sont affichées, c’est ces informations à jour qui sont affichées. Plus de multiples version de synopsis ou d’équipe technique pas à jour…
En fait, ce qui est dynamique n’est pas tant la donnée en tant que telle (un nom de famille ne va pas changer, en principe), que la capacité du système informatique de générer à la volée une nouvelle visualisation, un nouvel usage, une statistique, etc. C’est donc l’exploitation des données qui est dynamique, pas la donnée en tant que telle.
Comment créer et faire vivre une base de données relationnelle ?
Il y a trois challenges lorsque l’on veut construire une base de données:
- Séparer les données par tables spécifiques (par exemple: personnes; sociétés; projets; médias…);
- Définir les formats de données, par colonne (par exemple: format date, format nombre, format texte…);
- Créer des relations entre les tables (par exemple: une personne fait partie d’une société, collabore sur 3 projets…).
Et rapidement, il y a les enjeux suivants:
- Comment alimenter et mettre à jour les données ?
Avec un set de données qui grandit (les contacts sont un bon exemple), il faut pouvoir maintenir les données à jour et pouvoir facilement en ajouter. L’enjeu est donc de pouvoir automatiser un maximum, à partir des logiciels qui font partie des systèmes d’exploitation (OSX, Windows, …) et des solutions Cloud (Google, Microsoft, …). La difficulté va être de regrouper tous ces contacts éparpillés et de pouvoir les segmenter selon besoin.
Pour y arriver, il va falloir utiliser un ensemble de solutions logicielles indépendantes et de scripts (d’automations selon des règles). Je vais aborder cette question dans un prochain billet. - Comment intégrer les données dans ses propres workflows ?
Dans la même idée de ce qui précède, il s’agit de pouvoir utiliser les données pour la gestion de ses projets, dans les tâches attribuées entre les collaboratrices et collaborateurs, pour la communication et le marketing avec le monde extérieur. Pour y arriver, il faut utiliser là aussi d’autres solutions logicielles et des scripts. - Comment collaborer sur la dimension éditoriale des données ?
Il y a des données objectives sur lesquelles il n’y a à priori pas de discussion (le nom de famille d’une personne par exemple), mais il y a aussi beaucoup de données subjectives, comme l’affiliation d’une vidéo à une thématique. Pour coordonner les subjectivités de l’équipe, il faut pouvoir suivre des principes et rester ouvert à discuter au cas par cas, idéalement dans le contexte de la donnée. Le logiciel de la base de données devrait permettre de collaborer directement sur cet aspect éditorial.
Toutes ces challenges et enjeux devraient être adressés par l’application que l’on va choisir, que ce soit sous forme de fonctionnalités intégrées, d’un connecteur permettant d’exploiter les données à l’extérieur (une API) et d’une intégration native avec d’autres logiciels.
Quelle solution logicielle utiliser alors pour pouvoir travailler de manière dynamique ?
Comme je ne suis pas développeur, je vais parler ici que de solutions simples à mettre en place, sur base de ce que l’on appelle le no code. Il s’agit d’applications web qui permettent de créer et de gérer des bases de données sans écrire une seule ligne de code. C’est à priori aussi simple que de jouer aux Legos…
Voici une liste non exhaustive d’outils qui permettent de créer des bases de données, que je met continuellement à jour:
Deux solutions que je recommande pour créer des bases de données
Personnellement, j’utilise intensivement Airtable depuis 2015 et Notion depuis 2019 (voir mon billet “Ces applications qui changent votre vie”), autant pour des projets de plateforme vidéo interactive que pour générer des sites web adossés à une plateforme collaborative.
Voici ce que je peux dire aujourd’hui sur ces deux applications.
Airtable
On peut décrire Airtable comme étant une sorte de tableur en ligne permettant de lier des tables entre elles, pour ainsi créer une base de données relationnelle. La solution est spécifiquement prévue pour traiter efficacement des données à la granularité fine.
- Pour: solution solide et éprouvée (leader du marché), beaucoup de fonctionnalités, simplicité et efficacité dans l’usage, API’s solides…
- Contre: le modèle d’abonnement est bien trop cher dès que l’on veut travailler sérieusement avec une équipe (plusieurs miliers de francs par année); les fonctionnalités d’intégration et de partage sont trop bridées (voir les alternatives).
Exemple d’une base de données Airtable pour gérer la production de vidéos:
Notion
Notion est un mélange entre un tableur et un traitement de texte, avec la capacité d’intégrer d’autres applications web au sein d’une page et d’exposer facilement des pages web publiques ou privées.
- Pour: la flexibilité et la modularité couplée avec une simplicité d’usage hors pair; le prix imbattable; la capacité de personnaliser les vues des tables en fonction de multiples critères.
- Contre: limitations dans le fonctionnement de la base de données (pas aussi puissant qu’Airtable); sa flexibité et modularité sont aussi son danger (on peut vite se perdre dans la personnalisation); toujours pas d’embed possible (voir ci-dessous). Voir les alternatives.
D’après des tests que j’ai pu faire avec des développeurs, il semble que les API’s de Notion fournissent les mêmes types de fonctionnalités que les API’s de Airtable, ce qui permet d’utiliser Notion comme “source de vérité” centralisée, puis d’utiliser certaines données choisies pour son site web et toutes les autres présences web publiques.
Comme je ne peux pas intégrer une page Notion ici, comme démonstration de la solution je vous met une vidéo qui présente Notion:
En résumé, pour mieux collaborer sur des données dynamiques
Comme vous l’avez sans doute remarqué, je penche bien plus vers Notion que vers Airtable pour ce qui est de mon usage personnel. Par exemple, ce billet j’ai commencé à le rédiger dans Notion, qui est bien mieux pour la rédaction que l’interface capricieuse de mon CMS (WordPress, que j’aime de moins en moins je dois dire).
J’utilise Notion pour quasiment tout maintenant: la gestion de projets avec les tâches, la facturation, la gestion du temps, une partie de la compta et de la gestion financière, des mini sites pour collaborer sur des projets…
L’outil est vraiment incroyablement puissant et versatile, pour seulement 48$ par année (ils viennent de doubler le prix pour les nouveaux abonnés – ce qui reste tout de même très bon marché).
Cependant, dès qu’il s’agit de construire une base de données relationnelle plus ambitieuse, j’ai encore tendance à aller d’abord vers Airtable. En utilisant l’outil Miniextensions, je peux m’affranchir des limitations de l’abonnement en externalisant le login et la manipulation de données à des interfaces conçues dans Miniextension (voir ce projet comme exemple, où j’ai invité une vingtaine d’étudiant.e.s à collaborer sur une base de données Airtable).
Voici un schéma d’architecture de données que j’ai conçu pour une structure de production de films, pour donner un exemple de l’intégration de divers outils et bases de données entre elles, pour fournir un flux de données utile pour les diverses exploitations prévues:
Il y a une base de données centrale (Airtable), une base de donnée pour la gestion des projets (Notion), une base de donnée spécifique pour le site web (développement custom), et une multitude de connecteurs entre ces bases.
Mes autres tutoriels et documentations méthodologiques: