Collaborer sur des données dynamiques

Cette page fait partie d’une série portant sur les bonnes pratiques collaboratives dans le monde numérique.

Nous allons:

• expliquer pourquoi nous rédigeons cette page 😉;
• lister ce que nous entendons 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 cette page sur les données dynamiques ?

Une grande majorité des personnes a encore tendance à travailler par défaut avec des fichiers statiques. Comme on l’explique sur cette page: il est plus simple de rapidement créer un document que l’on envoie par email que de “nourrir” un espace d’information avec des données dynamiques…

Sans le faire exprès, ces personnes se compliquent la vie, non pas forcément sur le court terme, mais clairement sur le moyen et long terme. Et surtout, la collaboration devient très compliquée et fastidieuse.

Pour donner une idée plus concrète, sur l’exemple d’une structure de production de films, on peut dire 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, nous aimerions 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, en évoluant de manière souple avec le temps, selon les besoins.

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). Voir notre page sur comment créer une base de données relationnelle.
• 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.
• 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 construire une base de données relationnelle avec du no-code

Pour en savoir plus sur comment créer les conditions pour ces données dynamiques:

Construire une base de données avec du no-code

Il y a trois challenges lorsque l’on veut construire une base de données:

memoways.com

En résumé, pour mieux collaborer sur des données dynamiques

Comme vous l’avez sans doute remarqué en parcourant notre site, pour ce qui est d’un logiciel no-code permettant de créer des bases de données relationnelles, nous penchons bien plus vers Notion que vers Airtable. Par exemple, ce site est réalisé avec le tandem Notion + Super.so.

Cependant, dès qu’il s’agit de construire une base de données relationnelle plus ambitieuse, nous avons encore tendance à aller d’abord vers Airtable. En utilisant l’outil Miniextensions, nous pouvons nous 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ù une vingtaine d’étudiant.e.s ont collaboré sur une base de données Airtable).

Voici un schéma d’architecture de données que nous avons 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, ou une application no-code), et une multitude de connecteurs entre ces bases.

Voici pour terminer une liste non exhaustive d’outils qui permettent de créer des bases de données (mises à jour continuelles: