Ce semestre, étudiants en M1 avons inscrit notre projet dans la continuité des travaux précédents, en reprenant les données regroupées lors des années précédentes sur le programme Sunoikisis DC.
Ce projet, créé en 2015 à l’initiative de membres des universités d’Harvard, de Londres et de Leipzig, a pour objectif de favoriser les échanges à travers des séminaires portant sur toute discipline ayant trait aux Humanités Classiques entre les pays du monde entier. Ces séminaires se déroulent en visio-conférence, mais sont ensuite disponibles de manière asynchrone sur YouTube et GitHub. Les disciplines présentées sont nombreuses, et ne portent pas que sur la culture gréco-romaine : on y trouve des séances sur l’Égypte, la Mésopotamie, ou encore la Chine. Lors de la fondation du projet à Leipzig, le premier séminaire comptait 12 universités participantes ; de nos jours, on compte 135 institutions différentes qui ont participé au projet. En 10 ans, le programme s’est significativement développé, et on espère qu’il continuera à s’étendre et susciter l’intérêt du grand public pour le domaine des Humanités Classiques.

Carte recensant les différentes institutions ayant participé au projet dans le monde, disponible via ce lien.
En regroupant les métadonnées de ces séminaires, notre objectif a été d’harmoniser et de mettre à jour les données des années passées, et ainsi créer des conditions d’analyse adéquates, de sorte que les années qui suivent, nos données soient complétées suivant le modèle fourni par notre fichier.
A la fois élèves en présentiel et en EAD nous sommes répartis diverses tâches visant à améliorer un fichier CSV créé par les précédents étudiants, qui se présente sous la forme d’un tableau regroupant ces données. L’essentiel de notre travail a été de le mettre à jour en ajoutant les données sur les séances récentes, mais également d’uniformiser les données. Pour cela, nous avons eu recours à divers outils.
GitHub
Il s’agit d’un service d’hébergement basé sur le protocole Git, un outil de versionnage qui permet de conserver toutes les versions d’un fichier. Il facilite la collaboration entre les développeurs du monde entier, qui, par exemple dans le cadre de projets “open source”, y partagent des lignes de codes entières, ainsi accessibles à n’importe quel individu qui peut à son tour contribuer à l’élaboration du code. On peut y partager un fichier, que d’autres peuvent importer pour le modifier, puis l’exporter sur GitHub à leur tour pour partager leur version, sans pour autant créer de conflits, puisque le service permet d’enregistrer les versions de chaque machine.
Le projet Sunoikisis DC regroupe les données sur les séminaires sur GitHub, de sorte que le monde entier puisse y avoir accès de manière asynchrone. Nous avons ainsi facilement pu regrouper ces données dans un fichier CSV.
Nous disposons également d’un entrepôt GitHub exclusif, qui a facilité les échanges au sujet de l’élaboration du fichier CSV, notamment grâce à l’outil ‘Issues’ qui nous a permis de partager et de discuter de différents problèmes contenus dans notre fichier, et même d’assigner des personnes à une tâche donnée : par exemple, nous avons discuté de la mise en forme des conférences qui avaient été annulées.
OpenRefine
Il s’agit d’un logiciel de nettoyage de données, parfait pour un fichier Excel ou CSV. Sous forme de tableau, il permet d’harmoniser nos données, en repérant rapidement des fautes de frappe ou des hétérogénéités dans notre fichier, mais également en filtrant les données, leur attribuer un type (date, heure, pays…) à des fins analytiques. Le logiciel consiste à effectuer des transformations sur un tableau, en utilisant le langage GREL. Grâce à celui-ci, nous avons rapidement pu traiter les données en utilisant diverses expressions, des commandes. Nous avons également pu enrichir le fichier en ajoutant des données à partir de Wikidata, comme les identifiants des différentes universités qui ont participé aux séminaires. Enfin, OpenRefine nous a aidé à visualiser et explorer les données du tableau, pour nous aider à la correction.
Visual Studio Code
Il s’agit d’un éditeur de code source, outil de développement indispensable destiné à l’écriture de différents langages de code. C’est avec ce logiciel que nous avons modifié notre fichier CSV, dont le format (Comma-Separated Values) consiste à regrouper sous la forme d’un tableau les données en les séparant par des virgules. Nous avons combiné ce format à une extension, Rainbow CSV, qui attribue une couleur différente à chaque colonne, de sorte que la lecture et la correction des données soit facilitée.
Notre carnet de recherche
En visualisant les articles comprenant l’étiquette “Sunoikisis DC”, nous avons pu lire et analyser les travaux effectués par les classes précédentes, ce qui nous a permis de comprendre leurs réflexions et d’effectuer la synthèse des billets ci-dessous.
Fichier CSV
Github est un service web d’hébergement et de gestion de développement de logiciels, utilisant le logiciel de gestion de versions Git. Par conséquent, dans un fichier réalisé en commun (projet collaboratif) ce service web avec la commande « Git » garde en mémoire chaque modification des données. Chaque fois qu’un caractère est modifié, faisant partie du logiciel, cela permet de savoir l’état du fichier avant la modification et après la modification apportée par chaque contributeur/contributrice inscrit dans un projet collaboratif. Dans un terme technique, Github pratique ce qu’on appelle le « versionnage ».
On peut en dire que Github est une sorte d’entrepôt/dépôt qui permet de sauvegarder ce qui est partagé. Cela se réalise grâce à plusieurs fonctionnalités de Github qu’on étudiera. Par le biais de « commits », de « pull requests » et d’« issues ».
Qu’est qu’un fichier CSV ?
Un fichier CSV (Comma-Separated Values) est un type de fichier qui organise les données sous forme de tableau séparées par des virgules et parfois des points virgules. C’est le cas de notre fichier quand on consulte la section «preview» (prévisualisation de la version finale du fichier) et juste à côté la section «code» (cela permet de visualiser le fichier à l’état brut).
Qu’est qu’un commit ?
Un commit, terme emprunté de l’anglais dans son sens informatique, représente une ou plusieurs modifications d’un ou d’une contributrice apportées à un dépôt/entrepôt chronologiquement (repository : espace de stockage). GitHub enregistre un commit qui est composé d’un titre et d’un message explicatif indiquant ce qu’un ou une contributrice a apporté comme modification à un fichier.
Sur Github, on peut avoir accès à l’historique des commits d’un fichier et on peut savoir à quel moment un commit a été réalisé. Pour trouver le lien pour accéder à l’historique des commits, c’est indiqué en haut à droite d’un fichier qu’on a sélectionné sur le site (History). On peut le voir dans l’image ci-dessous à en haut à droite.

Dans le cas du fichier Sunoikisis, voici le lien de l’historique des commits.
Combien y a-t-il de commits pour ce fichier CSV?
Ce fichier du projet collaboratif compte 132 commits. Si l’on compte par sessions académiques :
- 34 commits durant l’année 2020-2021 ;
- 20 commits durant l’année 2021-2022 ;
- 29 commits durant l’année 2022-2023 ;
- 21 commits durant l’année 2023-2024 ;
- 28 commits durant l’année 2024-2025.
Lorsque l’on accède à l’historique de ce fichier CSV, on apprend que ces commits ont été réalisés sur une période allant du 1er mars 2021 au 14 avril 2025.
Combien y a-t-il de contributeurs/contributrices ?
Au total, on compte 32 contributeurs/contributrices à ce projet collaboratif, les anciens laissant leurs places aux nouveaux contributeurs/contributrices chaque année depuis 2021 pour participer à la continuité de l’état du fichier CSV par des commits.
A titre d’exemple, durant l’année académique 2024-2025, on compte plus de 7 contributeurs/contributrices s’étant ajoutés à ce projet collaboratif.
Quels sont les types de commits du fichier CSV ?
On en trouve de diverses sortes, qui permettent de contribuer à l’état du fichier CSV final :
Le commit initial est réalisé par le contributeur propriétaire qui a permis d’ajouter les données du fichier CSV. Voici une image ci-dessous qui l’illustre:

Les commits de correction : par exemple via ce lien on peut voir des citations ont été modifiées.
Les commits d’amélioration : harmonisation des institutions et des noms dans le fichier CSV, ou encore modification des noms de colonnes en anglais comme on peut le voir ci-dessous :

Comment savoir qu’un commit a été réalisé ?
Via Github, des notifications sont indiquées avec le titre du commit. De plus, lorsqu’on clique sur le commit, chaque contributeur/contributrice indique en description ce qu’il a réalisé. On peut ajouter que Github donne des indications visuelles à chaque personne lisant le commit : en rouge la version avant le changement et en vert l’état après le changement d’un élément du fichier opéré par un contributeur/contributrice.
En voici un exemple:

On peut savoir lorsqu’un commit a été réalisé avec d’autres éléments à travers l’image ci-dessous :

- L’identifiant du commit du contributeur ici est « cd3079c ».
- On peut voir la date de la contribution: « committed 3 weeks ago ». Dans certains commits on peut aussi voir en anglais : « authored + date».
- Le titre et la description du commit que le contributeur a réalisés. Dans cet exemple, le titre et la description du commit sont identiques : « Harmonise institutions and names ».
- Lorsque l’on clique sur le commit, on peut voir le message « 1 file changed », ainsi que les lignes de ces modifications: “+68 – 68”.
- Tout en bas de l’image on trouve le bouton de notification. Sur Github, on peut être averti d’un commit réalisé via l’historique des commits, mais aussi en s’étant abonné à une discussion spécifique ou d’un fil lié à un certain commit ou sujet, mais pas pour l’ensemble des commits d’un fichier.
Les commits sont non seulement visibles via le site de Github si le dépôt est public, mais aussi en local via le logiciel GitHub Desktop.
Voici l’interface de l’historique des commits du fichier CSV du projet Sunoikisis DC de GitHub Desktop ci-dessous :

A gauche de l’écran, on peut voir l’historique des commits avec les informations associées à ceux-ci comme sur le site de GitHub.
GitHub Desktop est un logiciel associé au site de Github permettant de travailler en local sur des fichiers (ajouts, modifications ou suppressions) depuis son ordinateur sans passer directement par le site web. Cependant, pour que les modifications locales soient synchronisées avec le site GitHub, il est indispensable d’effectuer la commande « push ». Sans cette étape, les modifications restent uniquement sur l’ordinateur local, même si le dépôt est public.
Par exemple, dans le projet collaboratif, il y a des exemples montrant que GitHub Desktop a été pris en compte mais qui n’a pas été synchronisé avec le site de GitHub en sélectionnant la commande « push ». Cela peut être volontaire, puisque l’on peut travailler sur un fichier via son ordinateur sans qu’il soit synchronisé avec le site de GitHub, ou involontaire. On peut le voir avec l’image ci-dessous :

Dans l’image ci-dessus, ces 8 commits réalisés par ces contributrices apparaissent entre le commit « harmonise institutions and names » et le dernier commit « update csv and archive » dans GitHub Desktop.
Mais ils n’apparaissent pas dans l’historique du fichier CSV sur le site de GitHub comme on peut le constater ci-dessous :

De plus, lorsqu’on se connecte régulièrement sur Github, on peut apercevoir en haut à droite (« Fetch origin ») une notification indiquant qu’un commit a été réalisé par un contributeur ou une contributrice. C’est un moyen efficace si on veut récupérer les changements des autres contributions. Cette commande permet aussi de rafraîchir la page comme on peut le constater ci-dessous :

Comment peut-on modifier le fichier CSV et réaliser un commit ?
Il y a plusieurs moyens de réaliser un commit.
Il est important de savoir que l’on peut directement modifier un fichier sur le site de GitHub pour ensuite effectuer un commit.
Tout d’abord, on sélectionne le fichier qu’on souhaite modifier. Dans notre cas, il s’agit du fichier CSV sur le projet Sunoikisis DC qui se trouve dans l’accueil du site de GitHub du contributeur/contributrice ou d’une personne externe au projet collaboratif consultant le fichier.
On peut le voir via l’image ci-dessous :

Ensuite, en haut à droite, il y a l’icône en forme de crayon que l’on sélectionne. Voici l’image ci-dessous :

En appuyant sur cet icône, on a la possibilité de modifier le fichier. Une fois cette étape réalisée, on sélectionne “commit changes” pour ainsi mettre en titre et en description, ce que le ou la contributrice a modifié. On peut le voir en haut à droit dans l’image ci-dessous :

Pour s’assurer que le commit soit vu par les autres, il suffit de cliquer sur la commande « push”, et les modifications réalisées se synchronisent avec le site de GitHub, et seront enregistrées dans l’historique du fichier CSV et sur GitHub Desktop.
On peut annuler une modification avant d’avoir appuyer sur « commit changes », en sélectionnant « cancel changes » qui se trouve juste à côté.
Cependant bien que cela reste une possibilité, cela peut entraîner des conflits avec le travail des autres contributeurs/contributrices. En effet, si plusieurs personnes effectuent des modifications dans un même fichier sans coordination, cela peut engendrer des conflits de fusion ou l’écrasement involontaire de modifications importantes.
Par conséquent, pour éviter ces éventuels conflits, il est possible de modifier le fichier et de réaliser des commits localement via Github Desktop avant de synchroniser ou non.

Dans l’image ci-dessus, on sélectionne le fichier sur le projet Sunoikisis qui est encadré en bleu. Puis on fait clic-droit et on sélectionne un logiciel d’éditeur de texte comme Visual Studio Code.
Via ce logiciel, on peut modifier directement le fichier comme on peut le voir dans l’image. Ensuite, dans la section « file » en haut à gauche, on sélectionne la commande « save » pour sauvegarder les modifications réalisées. L’extension CSV lint téléchargeable sur cet éditeur de texte permet de détecter les erreurs de formatage et renforcer les différents types de données avec des couleurs, en plus des virgules. Voici un image qui permet de l’illustrer ci-dessous :

GitHub Desktop affiche automatiquement les fichiers modifiés dans l’interface que l’on peut voir ci-dessous :

On peut effectuer ensuite un commit (en incluant un titre et une description) associé à la ou les modifications que l’on a réalisées via Visual Studio Code. Voici une image ci-dessous :

La réalisation du commit s’effectue en bas à gauche. Lorsque l’on insère le titre et la description du commit, on sélectionne « commit to main ». Ainsi, le commit est affiché dans l’historique du fichier CSV sur Github Desktop, et s’il a été synchronisé avec le site GitHub, cela apparaît dans l’historique du fichier avec la commande « push ».
Attention, mettre un titre et une description du commit est nécessaire, car GitHub et GitHub Desktop enregistrent la ou les modifications. Néanmoins, le ou les commits vont s’afficher automatiquement en titre « update + le nom du fichier ». Cela indique qu’une mise à jour a été réalisée sur un fichier spécifique. Cela est observable via ces images ci-dessous :

Ci-dessus, ce sont des commits automatiques sur l’historique du fichier CSV sur le site de GitHub.
Ci-dessous, ce sont des commits automatiques sur l’historique du fichier CSV sur le logiciel GitHub Desktop :

Y a-t-il une autre façon de modifier un fichier?
Pour modifier un fichier, on peut également se détacher de « la branche principale du code » c’est-à-dire de la version officielle (sous le nom de « main » ou « master ») du fichier via GitHub Desktop, en créant une nouvelle branche qu’on peut voir ci-dessous :

Après avoir sélectionné le fichier, on va dans la section « branch » puis « new branch » pour ainsi faire les modifications nécessaires via Visual Studio Code par exemple et effectuer un commit comme dans la branche principale. Ensuite, on peut proposer les modifications qu’on a réalisées aux autres contributeurs/contributrices avec des « pull requests » dans GitHub Desktop (surligné en bleu).
Mais aussi sur le site de GitHub. Voici des images ci-dessus qui l’illustrent :


On peut constater via l’image ci-dessus, qu’aucun pull request n’a été ouvert car tous les autres ont été fermés lorsqu’ils ont été acceptés ou non. Dans le projet collaboratif, 22 pull requests ont été clos.
Ainsi, en cliquant dessus on peut accéder à l’historique des pull requests du fichier CSV que l’on peut voir ci-dessous et disponible ici :

Ainsi le ou la contributrice dans une conversation (section « conversation ») propose sa modification avec son commit (section « commit »), et les autres contributeurs/contributrices peuvent en discuter. Si le fichier est accepté, ses modifications sont attachées à la branche principale du fichier, devenant la version officielle, dans la section « files changed ». Dans le cas du « pull request » de cette contributrice (voir ci-dessous), la proposition de modification a été acceptée et fermée (« Pull request successfully merged and closed »).

Il est important de noter que le commit lié à ce « pull request » de cette contributrice n’apparaît pas dans l’historique du fichier CSV sur le site de Github. Cependant, il est bien considéré comme un commit mais dans un historique de « pull requests » bien spécifique et sur Github Desktop, sans être directement rattaché à l’historique des « commits » du fichier CSV.
Cette contributrice a effectué des modifications en changeant les valeurs des colonnes du fichier CSV via un autre logiciel, en dehors de Visual Studio Code, qui s’intitule OpenRefine.
OpenRefine, est un logiciel libre de mise en forme et de nettoyage des données. Ainsi OpenRefine sous la forme d’un tableur va réorganiser les données. On a la possibilité d’ajouter des colonnes et de modifier des colonnes pour un format en CSV. Dans notre cas, le fichier collaboratif était déjà en CSV.

Voici la version finale du fichier CSV, sous la forme d’un tableur via OpenRefine. Cependant, pour faire une simulation, on appuie sur l’icône du copier-coller (« Raw this file ») surlignée en jaune pour télécharger le fichier afin de l’ouvrir dans OpenRefine.
Ensuite, on peut sélectionner des paramètres de OpenRefine concernant le fichier, comme on peut le voir ci-dessous :

Quand on a réalisé les modifications nécessaires, on peut appuyer tout en haut à droite sur « Create projet » et exporter le fichier final avec plusieurs formats, dont le format CSV.
Qu’est qu’une issue ?
Une « issue » sur GitHub est une fonctionnalité qui permet de signaler un problème, de demander une amélioration ou encore de discuter d’une idée dans un projet collaboratif.
L’historique des issues du fichier CSV est consultable à ce lien.
On peut déléguer des tâches spécifiques à certains des contributeurs/contributrices.
Tout comme le « pull request », on peut ouvrir une issue et la fermer quand les contributeurs et les contributrices estiment que l’issue en question est résolue.
Dans les « issues », on a également la possibilité d’activer la fonctionnalité d’un ou de plusieurs « milestones ». D’une part, cela permet de regrouper les « issues » pour un projet bien précis. D’autre part, de pouvoir renforcer l’organisation et de fixer des dates limites pour la réalisation de tâches spécifiques d’un projet.
Dans le cas du fichier CSV, il n’ y a pas de « milestone » ouvert ou fermé, mais c’est une fonctionnalité qui reste utile.
Le « milestone » peut s’appliquer pour les issues, mais aussi pour les « pull requests ». A l’instar des issues, dans le cas du fichier CSV, il n’y a pas de « milestone » ouvert ou fermé dans les « pull requests ».
NOTRE FICHIER CSV
L’entrepôt GitHub offre une fenêtre sur l’histoire du projet et du fichier.
Consiste en transformation de données brutes, en l’espèce à la création d’un fichier à partir des métadonnées pour pouvoir créer des conditions d’analyse.
Ces données sont mises en forme pour rendre le projet dont elles sont issues lisible et intelligible.
Pour cela, les participants se sont appuyés sur la documentation produite par les membres du projet Sunoikisis DC, mise à disposition sur le wiki, lui-même créé pour l’occasion; il répertorie les différentes sessions à mesure qu’elles ont lieu, leurs programmes et intervenants.
Le projet s’est articulé pour les étudiants autour de la création d’un fichier au format .csv, format fondamental de logiciels de tableur comme Excel. Ce format permet d’offrir sous forme de tableau les métadonnées classées.
L’entrepôt lui-même a été ordonné de manière à ce que les travaux accomplis chaque année apparaissent de façon accessible et lisible pour les visiteurs-participants ; nous avons donc accès aux archives. Nous nous sommes principalement fondés sur le fichier résultant des travaux des années précédentes et mis au propre par notre enseignant.
Récapitulatif de l’histoire du fichier :
- 2021: première année, 9 contributeurs (Zacharie, Maria, Olivier, Penda, Thierry, Chloé, Jérôme, Aurélia, Shubert), 189 lignes, 7 colonnes; les données prises en compte étaient l’étudiant.e contributeur.ice, le décompte total de sessions, l’année académique, la saison, la numérotation par session, le date, le titre, les contributeur-institution et thèmes.
- 2022: à partir du travail réalisé par les étudiants de l’année précédente, ceux de cette année ont pu aborder les données de manière quantitative-analytique, notamment fréquence (institutions, contributeurs, mots-clés, thèmes associés) et représentation sous forme de pourcentages.
Le fichier csv a été divisé par blocs téléversés dans l’entrepôt pour ensuite produire un fichier final unifié comprenant les séances 189 à 220. Certaines parties du fichier précédent ont été reprises pour être corrigées et la catégorie des thèmes des séances, auxquels on dédie une colonne par thème, a été approfondie. Les contributeurs sont séparés de leur institution et cette catégorie a été étendue. Les fichiers préparatoires permettent d’avoir un aperçu des méthodes de travail (colonne suggestion-correction, réflexion autour des catégories, en vue, toujours, d’offrir un fichier de données lisible et synthétique).
- 2023: Cette année-là, les données ont été abordées sous un angle géographique, à l’aide du format .kml, lisible dans Google Earth et Geojson, en vue de produire une représentation visuelle des pays d’origine des institutions concernées par les contributions (données géo-spatiales). Une colonne dédiée au lien menant vers la documentation de chaque session a été créée. Le fichier final semble ne pas apparaître ou alors celui disponible n’inclut pas la mention des pays.
- 2024: Ajout jusqu’à la session 238/240; recours à Gephi, outil de visualisation graphique de données. Distinction host-guest, qui manifestement n’a pas été conservée cette année; focalisation sur les contributeurs, en vue de produire une représentation graphique de leurs liens et apparitions.
- 2025: Le fichier tel que nous l’avons trouvé était dans un état proche de final. La numérotation a été interrogée et révisée, tant pour corriger d’éventuelles erreurs ou incohérences que pour œuvrer à l’harmonisation du fichier. Nous avons, notoirement, ajouté une catégorie intitulée status (sous forme de colonne, donc) . A l’occasion de cet apport, nous avons dans un premier temps envisagé un intitulé répondant à la question « la séance a-t-elle eu lieu ? ». OpenRefine nous aurait permis, dans une certaine mesure, d’automatiser le remplissage de cette colonne. Or il se trouve que la complétion de certaines séances n’était ni effective, ni annulée, mais reportée. Nous avons alors délaissé la forme interrogative « Occurred?» au profit du terme status. Nous avons également révisé la colonne des liens vers la documentation de chaque séance; nous avons ajouté et complété les séances manquantes (239 à 269); nous nous sommes également interrogés sur la pertinence du maintien d’une catégorie, face à un cas de concurrence en matière d’informations.
Nous travaillons à partir d’un fichier créé par les étudiants des années précédentes, avec pour objectifs de:
- compléter-mettre à jour le fichier ;
- harmoniser/raffiner le fichier ;
- extraire informations pertinentes pour une analyse plus générale du projet ;
- interroger un environnement de travail, en tentant de répondre à la question « que faire de ces données? Pourquoi?».
Méthode: comme pour les années précédentes, nous nous sommes réparti le travail en divisant le fichier par blocs de lignes. Ainsi avons-nous pu opérer, sur un champ plus réduit, des travaux d’inspection, vérification et modifications (ajouts comme suppressions, visibles dans l’historique des commits, donc).
Quand on compare les deux fichiers, on peut relever une première différence portant sur le décompte des séances par saison. Au départ, l’année 2019-2020 était en effet comptée comme un seul bloc, ce qui fait que les séances étaient numérotées de 1 à 32; dans ce cas-là, année académique et saison se confondent. Nous avons, dans un souci d’harmonisation, procédé à un re-découpage suivant les critères observés pour les années précédentes, figurant plus haut dans le fichier, donc, en limitant le décompte à chaque saison proprement dite au sein d’une année, à savoir Spring, Summer, Fall. A noter par ailleurs que chaque année débute en septembre et s’achève en juillet. Ce cas nous a invité à réfléchir sur le sens des catégories préexistantes, puisqu’alors ce « rangement » mettait en concurrence ou du moins affaiblissait celui adopté ailleurs.

De même, pour l’année suivante, les saisons (ou semestres) d’automne et de printemps allaient chacun de 1 à 9, mais celui d’été semblait reprendre le calcul à l’échelle de l’année, puisqu’il partait de la séance 19 (9+9+1, donc) et ce jusqu’à 32.

Pareil pour 2021-2022, qui proposait un décompte mutualisé des séances des semestres d’automne et de printemps (1 à 18) et dont le semestre d’été semblait chevaucher le début de l’année suivante.

L’année 2023-2024 était lacunaire quant à la numérotation générale et, pour la saison d’été, manquaient visiblement les séances 2, 4, 6, 8 et 10.

Elle présentait une étrangeté, dans le sens où pas moins de 4 séances successives numérotées comme étant la cinquième.

Quant aux séances n’ayant pas eu lieu, soit elles ont été annulées, soit reportées: dans le fichier initial, lorsque ce cas se présentait, soit une mention en styles changeants « cancelled », soit, a priori, des lacunes.
Le fichier présentait une erreur, il n’était pas mis en forme de manière « cherchable », comme nous l’indique l’encart de GitHub.

Les données apparaissaient donc sous forme brute, séparées par des virgules.

Pour autant, par une simple fonction cmd+F/ctrl+F, nous avons pu opérer une recherche positive des occurrences sur la page.
OpenRefine, en tant que « powerful tool to work with messy data » nous a permis de rendre la tâche plus aisée, logiciel fort utile pour opérer des remplacements lexicaux et autres corrections.
Ainsi avons-nous pu, par exemple, créer une nouvelle colonne, à l’endroit souhaité, dévolue à la question du statut des séances.



Le remplissage des cellules était donc automatisable, au moyen de la fonction « transform» pour les séances ayant eu lieu; restait à remplir manuellement celles ayant été annulées ou reportées.



Dans la mesure du possible, certaines séances n’en offrant pas, tous les liens vers la documentation utile ont été ajoutés.
Ainsi avons-nous pu compléter le fichier avec les séances les plus récentes et celles qui manquaient éventuellement, corriger certaines erreurs de syntaxe et œuvré à l’harmonisation du fichier, dans la continuité du travail de nos prédécesseurs.
Billets précédents
Les thèmes qui n’apparaissent que dans un billet
Les billets rédigés les années précédentes abordent plusieurs sujets. Nous allons donc nous attarder sur les sujets n’apparaissant que dans un seul billet.
Dans le billet de 2023, le groupe a choisi d’utiliser le logiciel UMap pour créer une carte afin de visualiser leur recherche. Le but a été de mettre en évidence les pays des institutions et des centres de recherche qui participent au projet Sunoikisis DC. Les membres du groupe ont tout d’abord ajouté une colonne sur Github afin de classer les séances par pays. Pour certaines séances, ils ont rencontré des difficultés puisqu’il s’agissait d’une collaboration entre plusieurs universités du programme. Une fois cette étape terminée, ils ont pu transformer le fichier en fichier KML pour le transformer en carte grâce à UMap. Enfin, des observations ont pu mener à des explications ou des questionnements : l’absence des États-Unis malgré l’existence de nombreuses universités investies dans ce domaine ou la présence de l’Egypte du fait de ses importantes ressources paléographiques. La plupart des pays participant au projet Sunoikisis DC sont donc européens.
Le travail autour des différents thèmes abordés dans le projet Sunoikisis DC est un thème récurrent dans les trois billets. Cependant, le point de vue utilisé pour travailler sur les thèmes abordés varie dans les billets. C’est donc dans cette optique que nous allons nous intéresser aux thèmes dans cette partie.
Dans le billet de 2023, le travail s’est axé autour de trois thèmes uniquement. Cette décision a été prise afin de faciliter le travail, mais des problèmes se sont posés : une partie des thèmes abordés se retrouve manquante, savoir quel thème regrouper sous quel nom. Dans le billet de 2022, c’est un travail sur la répartition des différents thèmes abordés durant le programme. Un graphique a donc été fait pour permettre de visualiser la répartition des différents thèmes par année. Cependant, le graphique qui est présenté n’est pas très lisible. Nous ne pouvons pas correctement nous rendre compte de la réelle répartition. De plus, dans ce billet, le logiciel TaDiRah est utilisé pour les annotations des thèmes. Ce logiciel n’est pas présent dans les autres billets.
En essayant de comprendre le travail mené sur l’analyse des données du Projet Sunoikisis DC jusqu’ici, on a procédé à une analyse des billets déjà publiés sur Hypotheses. On a trouvé quatre billets, dont un datant de 2016, qui ne concerne pas notre analyse vu qu’il présente une analyse des données liée à un corpus différent. Alors, notre synthèse concerne les billets des années 2022, 2023 et 2024 qui travaillent sur le corpus des séances du projet Sunoikisis DC. Dans ce corpus, on a observé l’existence des certains thèmes récurrents chaque année et certains thèmes apparus une seule fois.
Thèmes récurrents
CSV
Le format CSV apparaît de manière récurrente dans les billets de 2022 à 2024 comme un outil central dans le traitement des données liées au projet Sunoikisis DC. En 2022, son maniement est cité parmi les compétences pratiques acquises par les étudiants. Le billet de 2023 approfondit cette mention en définissant le format CSV (Comma Separated Values) et en soulignant son utilité pour organiser les données sous forme tabulaire. Ce fichier, contenant l’ensemble des séances du projet Sunoikisis DC depuis 2014-2015, sert de base pour l’annotation thématique, l’analyse des séances, et la cartographie des institutions participantes. Les étudiants créent même un nouveau fichier CSV à partir des données initiales, afin d’isoler les informations géographiques utiles au projet de cartographie. En 2024, l’utilisation du même fichier CSV est de nouveau un thème central, avec une attention particulière portée aux métadonnées (comme les noms des contributeurs), extraites puis transférées dans un fichier distinct pour faciliter leur traitement. Certaines modifications ont également été apportées dans le fichier original afin d’assurer une compatibilité avec les outils de visualisation comme Gephi. Ainsi, le CSV a été utilisé comme un outil fondamental de structuration, de transformation et d’exportation des données dans l’ensemble du processus analytique.
Détail du fichier CSV.
GitHub
GitHub est régulièrement mentionné dans les billets de 2022 à 2024 comme un outil fondamental pour le travail collaboratif des étudiants autour du projet Sunoikisis DC. En 2022, il est évoqué comme un simple entrepôt de données, servant à centraliser les fichiers partagés du groupe. En 2023, son rôle s’élargit : les étudiants ont pour objectif de s’initier à son usage et de contribuer à l’enrichissement de cet espace commun. Le billet de 2024 consacre une attention particulière à GitHub, présenté non seulement comme un service web de stockage, mais surtout comme une plateforme de collaboration qui permet de centraliser les données initiales, de regrouper les productions individuelles et de gérer différentes versions d’un même fichier. Cette capacité à retracer les modifications facilite l’identification des erreurs éventuelles. Le lien entre GitHub et l’usage du format CSV est également souligné, montrant comment l’intégration des deux outils soutient efficacement le travail d’équipe et la gestion des données au fil du projet.
OpenRefine
OpenRefine est mentionné de façon constante dans les billets de 2022 à 2024 comme un outil clé dans le traitement des données du projet Sunoikisis DC. En 2022, il est cité pour ses fonctions de nettoyage, de traitement automatique et d’analyse interactive des données, mettant en valeur sa capacité à structurer efficacement les données brutes. En 2023, le logiciel est décrit comme un outil libre dédié au nettoyage et à la mise en forme, confirmant son rôle dans la préparation des données pour l’analyse. En 2024, OpenRefine est mis en avant comme l’un des trois logiciels principaux utilisés par les étudiants, aux côtés de GitHub et Gephi.
Son usage est donc pleinement intégré au processus de travail, soulignant sa pertinence pour assurer la qualité, la cohérence et la structuration des données tout au long du projet.
Traitement et analyse des données
L’analyse et le traitement des données sont au cœur des trois billets consacrés au projet Sunoikisis DC, constituant le fil conducteur des travaux menés par les étudiants.
En 2022, le traitement automatique des données est brièvement mentionné, soulignant une première approche technique de la manipulation des informations. En 2023, le traitement prend une place plus structurée avec l’usage du format CSV pour organiser les données tabulaires, accompagné d’une description des étapes du processus. Le billet de 2024 approfondit cette dynamique en insistant sur la nécessité d’assurer une cohérence dans le traitement, impliquant des choix méthodologiques de la part des étudiants. Ce dernier texte met également en lumière l’usage de plusieurs outils logiciels, tels que Visual Studio Code (déjà présent en 2023) et Gephi, pour affiner le traitement et faire face à des problématiques spécifiques liées à certaines données. Finalement, il montre comment l’articulation de ces outils a permis une analyse plus fine et structurée des données du projet.
Au fil du temps, le traitement des données devient donc un processus de plus en plus réfléchi, rigoureux et intégré à une chaîne d’outils complémentaires.
Annotation
L’annotation des données apparaît comme une pratique stable, collaborative et essentielle à la structuration thématique des séances du projet Sunoikisis DC.
Dès 2022, le billet souligne le travail collectif d’annotation thématique réalisé par les étudiants, en insistant sur son caractère manuel, donc potentiellement subjectif. Cette annotation sert à identifier et organiser les thèmes abordés dans chaque séance, et le terme lui-même est également utilisé comme mot-clé pour décrire le contenu des certaines séances.
Visualisation du traitement des donnés concernant l’annotation des thèmes des séances du Projet Sunoikisis comme publié au billet du 20.05.2022
En 2023, cette pratique est intégrée explicitement aux objectifs pédagogiques du groupe : l’annotation collaborative y est à nouveau valorisée comme un moyen structurant de catégoriser les thèmes du projet. Le texte réitère aussi l’usage du mot annotation comme mot-clé dans la description des séances, montrant ainsi la continuité de cette démarche dans la construction d’une base de données thématique cohérente et partagée.
Thèmes
Les trois billets présentent les travaux d’analyse des étudiants liés aux thèmes des séances du Projet Sunoikisis..
Question des données concernant les organisateurs (hosts)
Les billets de 2022 et de 2024 analysent la problématique créée par la présence des noms des organisateurs (hosts) dans le tableau CSV qui participent très souvent aux séances, mais la majorité de fois ils prennent la parole pour introduire et présenter les différents participants. La non-distinction entre eux et les invités participants (guests) crée un « bruit », posant question sur la fiabilité des résultats des analyses des données.
Visualisation des thèmes des séances du Projet Sunoikisis comme publié au billet du 23.04.2023.
Le groupe d’étudiants qui a travaillé sur le billet de 2022 a signalé ce problème et le groupe de 2024 a fait la distinction dans le fichier CSV du projet Sunoikisis entre les hosts et les guests, et a corrigé les discontinuités existantes liées à ce sujet.
Capture d’écran concernant le travail mené en 2024 sur la distinction entre hosts et guests comme publié au billet du 03.05.2024.
Visualisation des données avec des graphes
Les billets de 2022 et de 2023 mentionnent le mot “visualisation” en faisant référence au mot-clé pour le thème de la visualisation que certaines séances du projet Sunoikisis portent.
Le billet de 2024 met en avant le processus de visualisation des données à partir du fichier CSV du projet Sunoikisis avec l’utilisation des logiciels comme Gephi.
Visualisation des données du Projet Sunoikisis avec le logiciel Gephi comme publié au billet du 03.05.2024.
On observe une montée en complexité et en réflexivité au fil des années : les outils ne sont plus seulement utilisés, ils sont analysés, articulés entre eux, et les étudiants développent des méthodologies critiques, en particulier sur la fiabilité et qualité des données (notamment sur les hosts).
Conclusion
Dans le cadre du projet collaboratif du Master 1 d’Humanités Classiques et Numériques, nous avons effectué des recherches sur les métadonnées des séances du projet Sunoikisis DC. Ayant accès au travail des trois dernières années, regroupé dans un fichier CSV et ainsi qu’aux billets correspondants, nous avons jugé pertinent de mener une approche analytique sur le travail mené, les outils traités, les aspects considérés, afin de proposer de nouveaux axes de recherche pour les années à venir.
Une constante en ce qui concerne les outils a été l’emploi du fichier CSV, des logiciels de traitement de texte VSCode et OpenRefine, ainsi que Github. En second plan et selon les besoins et les différentes cibles du groupe, Gephi, TaDiRaH et UMap ont été utilisés pour visualiser les données. Les outils offrent un large éventail de fonctionnalités requises pour le traitement des données, et cette année, ils se sont avérés utiles et indispensables. L’analyse des différents emplois de Github a mis en évidence les énormes possibilités offertes par cette plateforme aux projets collaboratifs, qu’il est possible d’explorer davantage.
Après avoir été regroupées dans le fichier, les données ont été nettoyées et mises à jour, puis examinées et interprétées. On y trouve des métadonnées importantes telles que le titre de la séance, les organisateurs, l’institution, le pays, les mots clés et les liens. Trois recherches très intéressantes ont déjà été réalisées : l’analyse des sujets abordés et de leur fréquence; l’identification des organisateurs, et la fréquence de leur activité ; la cartographie des institutions impliquées au projet. En se basant sur ces études, dans le cadre d’une requête plus complexe, il serait envisageable d’effectuer une analyse comparative de ces deux variantes, à savoir les institutions et les sujets traités. De plus, les caractéristiques académiques et sociales des hôtes, qui certes a été un sujet traité en 2022, pourrait être repris et enrichi en considérant différentes catégories telles que l’âge, le sexe et la capacité. Mais le fichier pourrait aussi être enrichi avec les ressources proposées à chaque séance, puisque l’on peut noter des séances plus riches qui comprennent exercices et listes bibliographiques, en parallèle de séances plus simples.