Slides | Mapper.fr

3D géospatiale, jumeaux numériques et outils open source pour l'archéologie : Avancées du projet Junarka

Wed, 19 Nov 2025 00:00:00 +0000

Git, Gitlab, Github... Qu'ès aco?

Tue, 12 Dec 2023 00:00:00 +0000

Git, Gitlab, Github… Qu’es aquò?

Introduction à la journée “Explorer le potentiel de Git et Gitlab”
12 décembre 2023
MMSH

Git, Gitlab, Github… Qu’es aquò?

Historique et usages de Git

Ligne de commande et interfaces graphiques

Interfaces web (partiellement commerciales): les forges

J’ai été invité à ouvrir la journée en tentant de répondre à une première question: de quoi parle-t-on? Git, Github, Gitlab, voire Gitea ou encore Codeberg – qu’es aquò? Comme on dit ici. Pour tenter d’y répondre en une petite demi-heure, je tracerai un rapide historique de Git, cet outil décentralisé de gestion de version et je présenterai ensuite ses différentes interfaces qui sont comme autant de portes d’accès - que ce soit “en local” sur ma machine avec la ligne de commande ou un “client graphique”, c’est à dire un logiciel disposant d’une interface graphique, mais aussi des interfaces disponibles sur le web, comme Github et Gitlab, qui en plus des fonctionnalités du logiciel Git, proposent des fonctionnalités de partage de code (dépôts publics), de réseau social (avec des abonnés et des abonnements), de wikis, d’outils de gestion de projet, etc.

Git, Un logiciel libre de gestion de version décentralisé

Libre et gratuit, créé en 2005 par Linus Torvalds

Permet de stocker un ensemble de fichiers en conservant la chronologie des modifications effectuées dessus

Décentralisé: système de connexion pair à pair

Pour du code, mais pas seulement! Livres, articles…

Un outil d’abord disponible en ligne de commande

Git est un logiciel libre de gestion de version décentralisé.

Logiciel libre, librement reproductible, distribuable, etc. créé en avril 2005 par Linus Torvalds, développeur finlandais (maintenant américain), et dont le développement est mené, depuis, par le Japonais Junio Hamano et l’américain Jeff King. Git a été créé à l’origine pour remplacer un programme propriétaire, BitKeeper.

Ce dernier - qui était alors gratuit mais pas libre ni ouvert - était utilisé pour le développement du noyau Linux. Lorsqu’Andrew Tridgell, développeur à l’ODSL (future Fondation Linux), tente la rétro-ingénierie de certains protocoles de BitKeeper (= comprendre le fonctionnement d’un système fermé en le devinant), ce statut gratuit est révoqué, ce qui pousse Linus Torvalds à créer Git pour se défaire de BitKeeper.

Logiciel de gestion de version: il permet de stocker un ensemble de fichiers en conservant la chronologie des modifications effectuées dessus, et de retrouver au besoin un état précédent d’un fichier.
Il est décentralisé: il ne repose pas sur un serveur central mais utilise un système de connexion pair à pair.

Il est principalement utilisé en développement logiciel, lorsque les fichiers concernés contiennent du code informatique, mais peut être utilisé avec d’autres types de projets. Des rédactions collaboratives d’ouvrages ou d’articles on été menées en utilisant Git.

Git est d’abord un outil disponible via une interface en ligne de commande. La ligne de commande, c’est cette interface textuelle accessible en général à l’aide d’un terminal qui permet de donner des instructions à l’ordinateur, qui va les éxécuter, avant d’afficher un retour - réussite ou échec de la commande, texte d’aide, description du contenu d’un dossier, etc.

Pour utiliser Git, on se déplace dans le dossier où l’on veut travailler, puis on tape la commande git suivie d’un ou plusieurs autres termes. Ces commandes permettent d’assurer un certain nombre de fonctionnalités.

Fonctionnalités

Créer un nouveau dépôt et surveiller les fichiers présents dans un dossier: git init
Ajouter les fichiers récemment modifiés à la liste des fichiers surveillés: git add
Valider cet ajout: git commit
créer ou gérer différentes branches dans le code: git branch
fusionner des branches: git merge

Fonctionnalités

Clone (=copier) en local un dépôt distant: git clone
Récupérer le code le plus à jour sur un dépôt distant: git pull
Publier des révisions ou contributions sur un dépôt distant: git push
Défaire les modifications d’un commit précédent: git revert
Etc.

De nombreuses interfaces graphiques disponibles

git-gui, gitk, TortoiseGit, Git Extensions, Magit, MeGit, GitUp, gitg, ungit, Fugitive, Guitar, git-cola, GitGUI, giggle, RepoZ, Gitgui, Gittyup, Git Klient, gitonic, Gitnuro, Pragma-git…

En plus de l’interface de base en ligne de commande, le projet de base propose deux interfaces graphiques, git-gui (pour effectuer des commit) et gitk (pour parcourir le code et les commits qui l’ont affecté). De nombreuses interfaces graphiques tierces ont été créées au fil des années. Le site internet de Git en propose une liste, dont je reprends ici uniquement les exemples sous licence libre - il y en a au moins autant sous licence propriétaire, et pour les trois principales plateformes, Windows, Mac ou Linux. On a donc l’embarras du choix pour travailler avec Git en local.

De nombreuses interfaces disponibles

https://git-scm.com/downloads/guis

L’apparition des forges logicielles en ligne

De la gestion de version à la forge: des interfaces web enrichies

2008: Github

2011: Gitlab

Git rencontre très vite un grand succès et de nouvelles interfaces enrichies apparaissent sous la forme de forges logicielles. Présentée sous la forme d’un site internet, une forge peut proposer, en plus des fonctions de gestion de versions du code:

des gestionnaire de listes de diffusion;
des outils de suivi de bugs;
des gestionnaires de documentation de type wiki;
des outils de gestion des tâches;
des outils de traduction en ligne;
La possibilité de présenter son projet avec une page d’accueil;
la publication régulière d’actualités relatives à son projet.

Tout ceci dans une interface intégrée, enrichie de fonctionnalités proches de celles des réseaux sociaux (compte utilisateur public, abonnés et abonnements, mise en favori de projets).

Les forges facilitent le travail collaboratif autour d’un dépôt commun de code, et intègrent des outils de plus en plus spécifiques.

La forge la plus célèbre, Github.com, est lancée en 2008. En 2012, elle compte près de 3 millions d’utilisateurs et près de 5 millions de dépôts. En 2018, Github est rachetée par Microsoft, ce qui provoque une certaine inquiétude quant à son positionnement et son avenir (et une fuite toute relative des projets - dans la journée, 50 000 projets migrent vers Gitlab, c’est beaucoup, ce n’est pas tant). En 2023, Github continue d’être la forge la plus active, de loin, et compte plus de 100 millions d’utilisateurs.

Gitlab, de son côté, est créé en 2011. Si les fonctionnalités proposées par Gitlab sont proches de celles de Github, son fonctionnement est un peu différent: en plus de la forge proposée à l’adresse Gitlab.com, Gitlab propose deux version (CE et EE – la forge disponible sur Gitlab.com est basée sur l’EE) que l’on peut installer sur le serveur de son choix. C’est le modèle économique de l’open core, avec une version de base proposée en open source et des versions complémentaires enrichies de fonctionnalités.

Gitlab

Intégration continue + déploiement et/ou livraison continue (CI/CD), DevOps

Plusieurs instances existantes, et possibilité de déployer sa propre instance

Gitlab est donc une forge logicielle en ligne, basée sur Git, et qui propose les fonctionnalités complémentaires que je viens de décrire. Elle se spécialise également sur des outils dits d’intégration continue et de livraison ou de déploiement continu (CI/CD):

CI: Chaque modification (commit) est testée automatiquement pour éviter de casser l’existant
CD: Livraisons ou déploiement du code rapides et automatisées. (Livraison = le code est partagé dans le dépôt principal de la forge. Déploiement = le code est mis en production, qu’il s’agisse d’un site web ou d’un logiciel).

Gitlab se présente souvent comme une plateforme de “DevOps”. Le DevOps est une approche qui propose d’unifier le développement logiciel et l’administration des infrastructures informatiques. Je le cite pour info car c’est un élément souvent mis en avant concernant Gitlab mais ce n’est pas d’une importance capitale ici.

La particularité de Gitlab, comme je vous le disais plus tôt, c’est de proposer la possibilité d’installer une instance du logiciel sur un serveur de son choix. C’est ce qu’a fait Huma-Num, qui propose une instance à https://gitlab.huma-num.fr.

Gitlab

https://gitlab.com
https://gitlab.huma-num.fr
https://gitlab.gnome.org
https://gitlab-forge.din.developpement-durable.gouv.fr
https://gitlab.depp.education.fr

etc!

Git et Gitlab pour OrAG

Suivi des versions du code en local
Dépôt pour l’instant privé
https://gitlab.huma-num.fr

On explore!

Merci pour votre attention!

Jérémy Garniaux
jeremy@mapper.fr

DocSoc2022

Thu, 23 Jun 2022 00:00:00 +0000

Données et métadonnées dans l’hybridation et le bricolage des pratiques des chercheurs en contexte de science ouverte

Un retour d’expérience du GDR SILEX

Bonjour à toutes et à tous. Merci aux organisatrices et aux organisateurs pour l'invitation, pour nous donner cette occasion de revenir sur le travail mené au sein du GDR Silex dans la mise en oeuvre d'une plateforme scientifique de cartographie participative, merci enfin pour avoir bien voulu nous accueillir à distance malgré les consignes, suite à des contraintes de dernière minute de notre côté.

Équipe

Christophe TUFFERY (Inrap, TEMPS)
Vincent DELVIGNE (U. de Liège, TEMPS)
Paul FERNANDES (Paléotime, TEMPS)
Jérémy GARNIAUX (AMU, LAMPEA/MMSH) Stéphane RENAULT (AMU, LAMPEA)

Bref historique des recherchesvoudrais qu’elle

Des travaux menés depuis le XIXe siècle

Constats

Diversité des approches

Hétérogénéité dans les descriptions

Partage difficile

Géolocalisation approximative

Cartes statiques, print mais pas web

Travaux locaux isolés

Quels schémas explicatifs à petite échelle?

Une série de constats peut-être faite sur ces premiers travaux:

D’abord, la diversité des approches, méthodes, domaines d’études, etc. crée une grande hétérogénéité dans les descriptions et les caractérisations des matériaux siliceux, d’où découle un certain nombre de difficultés pour partager les données entre chercheurs.

Ensuite, la géolocalisation de nombreuses données récoltées sur le terrain pose problème car pas toujours bien enregistrée. Les cartes réalisées sont jusqu’ici statiques, peu partageables, plus adaptée à des supports “print”, papier ou pdf, qu’à une circulation sur le web.

Les travaux restent isolés, très localisés, et ne donnent pas lieu à des synthèses multirégionales, ce qui participe à l’impossibilité de proposer des schémas explicatifs valables sur de grands espaces (à petite échelle).

Mise en place du GDR

Organiser et animer la production de connaissances harmonisées

Mise en place de 4 PCR “Réseau de lithothèques” (2006)

Mise en place du Groupement de Recherche SILEX (2019-2023)

Éléments de méthode

Inventaire et description harmonisée

Méthode harmonisée de caractérisation

Pétroarchéologie (interface géologie/archéologie)

Paléo-territoires -> Litho-espaces

En termes méthodologiques, il s’agit de mener un inventaire des formations à silicite pour la France et d’en établir une description harmonisée, puis de définir une méthode harmonisée de caractérisation des échantillons présents dans les lithothèques ou prélevés lors de prospection. Ce sont les outils de la pétroarchéologie, discipline à l’interface entre géologie et archéologie, qui sont mobilisés ici.

L’objectif des études est de caractériser le milieu minéral, et de contribuer à la définition des systèmes techno-économiques. Les méthodes d’observation sont complémentaires, et les techniques d’exploration sont multiples.

La finalité scientifique de ces divers outils réside dans la possibilité de reconsidérer la notion de « territoire » en Préhistoire, aujourd’hui marquée par une conception sédentaire et moderne diamétralement opposée à celles des collectifs non-modernes mobiles. La notion de paléo-territoires est actuellement révisée pour la notion de litho-espaces, qui se limite à la description des espaces d’approvisionnement en ressources lithiques.

Données géologiques

Des sources hétérogènes

Plateforme cartographique

ArcGis Online

Formations à silicite

Points de collecte et inventaires de lithothèques

Migration vers une infra open source

Affichage des données QGIS Server dans QWC2

Nouvelle infra carto: En 2020, l’équipe du projet a décidé de s’engager dans la migration des solutions actuellement mises en œuvre, vers des solutions open source. En parallèle de cette décision, les autres décisions suivantes ont été prises:
- la publication des données sous licence Etalab 2.0;
- le dépôt régulier de versions consolidées des données sur la plateforme ArcaDIIS;
- la mise en ligne de documents iconographiques sur la plateforme Nakala d’HumaNum
- l’établissement de liens entre les données et ces ressources documentaires.

Ces choix s’inscrivent dans le cadre des orientations des deux plans nationaux pour la science ouverte (2018-2021 et 2021-2024) du MESRI. Une première phase de migration de la solution développée sur les solutions ESRI, a consisté à déployer un serveur cartographique utilisant la solution QGIS Server et une applicative de consultation cartographique s’appuyant sur QWC2, un client Web pour QGIS Server.

Pour l’instant, le projet QGIS utilise les services de données Web WFS actuellement hébergés sur la plateforme AGOL. Ils seront ensuite importés dans une base PostGIS lorsque nous basculerons complètement sur QGIS et que nous pourrons “débrancher” la solution ESRI. ESRI.

Migration vers une infra open source

Briques de la plateforme à venir

Dépôts semi-automatisés dans ArcaDIIS

Dépôts iconographiques dans Nakala

En plus de ces solutions cartographiques open source, d’autres “briques” complètent la plateforme.

Des exportations régulières des données seront déposées de façon semi-automatisée sur la plateforme ArcaDIIS (arcadiis.science), qui permettra leur FAIRisation en enrichissant les métadonnées et en leur attribuant un identifiant pérenne. Les données seront accessibles via un moteur de recherche à facettes en interrogeant leurs métadonnées normalisées (Dublin Core ISO 15836, complétée par d’autres normes comme INSPIRE ou le Darwin Core). ArcaDIIS proposera également la pré-génération de trames de data papers depuis les métadonnées des jeux de données, et - sous la forme d’un Linked Open Vocabulary - l’accès aux mots-clés issus du thésaurus PACTOLS (été 2022).

-Ensuite, les documents iconographiques contiueront à être déposés sur Nakala. Des liens seront établis entre les données et ces ressources documentaires.

De la science ouverte en archéologie

Hybridation des pratiques

Depuis 2006, date du début de nos premiers projets, les notions de science ouverte ont progressivement émergé et se sont de plus en plus diffusées dans nombre de domaines scientifiques. L’archéologie fait partie des disciplines où la traduction dans les faits des principes de l’ouverture des données et des outils n’est pas aussi développée que dans d’autres disciplines, pour différentes raisons - notamment les questions de propriétés des savoirs et des savoir-faire, ou les craintes de pillage des sites archéologiques existant.

On a pu constater qu’une forme de stratégie d’hybridation des pratiques a été mise en oeuvre par les chercheurs face au mouvement de la science ouverte. Hybridation au sens donné par Latour lorsqu’il décrit les formes d’adhésion et de résistance, de fluidité et de tension dans les relations entre individus et objets matériels - qu’il décrit sous le vocable commun “d’actants”. Ici, l’hybridation des pratiques est la dynamique qui amène l’activité scientifique (ou l’enquête de terrain, par exemple) à ne pas se dérouler exactement comme prévu.

Concrètement, la question des métadonnées est un bon exemple: si l’on sait en théorie que des métadonnées bien renseignées participent au premier plan à une bonne qualité des données et donc au bon respect des principes FAIR, les contributeurs n’en font pas toujours une priorité. Il y a la difficulté à distinguer données et métadonnées, ou bien l’idée que les métadonnées pourront être renseignées “plus tard” parce que ça prend beaucoup de temps pour un intérêt en apparence moindre.

De la science ouverte en archéologie

Bricolage cognitif

Cette hybridation produit du “bricolage” cognitif, au sens de la possibilité de s’adapter à un contexte contraint par le caractère limité des moyens dont on dispose. Dans notre cadre de pratiques numériques, les chercheurs s’adpaptent avec leurs compétences et leurs savoir-faire. L’appropriation n’est possible que si ces pratiques peuvent s’intégrer dans des pratiques préexistantes, aussi bien à titre individuel que dans le ou les gorupes dans lesquels ils interviennent et interagissent.

Pour faire référence à une notion proposée par Marcel Mauss, et en l’adaptant aux dispositifs numériques, la mise en œuvre de ceux-ci ne peut donner lieu à des « actes traditionnels efficaces » qu’à la condition qu’ils s’inscrivent dans une continuité et non pas dans une recherche de rupture avec les pratiques traditionnelles préexistantes. Pour citer Mauss: « Il n’y a pas de technique et pas de transmission, s’il n’y a pas de tradition ».

En ce sens, on peut considérer que les principes de publication qui soutendent la science ouverte doivent contribuer d’abord à des pratiques de partage, de transmission des savoirs et des savoir-faire dans une éthique de la recherche animée par le respect des autres et donc de la diversité des pratiques de recherche.

De la science ouverte en archéologie

Braconnage culturel

Au sein du GDR Silex, les chercheurs se sont appropriés les pratiques que nous avons mises en place par des processus de « braconnage culturel »: l’expression est de Michel De Certeau et désigne les ruses dont font preuve certains acteurs par des tactiques de résistance, voire de subversion des groupes auxquels ils appartiennent.

En adoptant lentement les nouvelles pratiques numériques qui leur étaient proposées, et en y résistant « en douceur », de façon presque invisible, certains des membres ont réussi, de l’intérieur même des collectifs de travail, à ne pas se faire imposer ces nouvelles pratiques, comme nous avons pu le constater notamment lors de sessions de formation sur le terrain.

(On voit ici, par exemple, un cas de braconnage: la coexistence de l’utilisation de l’appli mobile et du formulaire papier pour l’enregistrement des données de terrain lors d’une session de formation)

Plusieurs outils et méthodes existent pour accompagner les changements des pratiques: expression des besoins non seulement des changements attendus mais aussi des maintiens nécessaires de l’existant, rédaction collaborative de documents référençant des pratiques « vertueuses », actions de formation, recueil des retours d’expérience, adaptations des protocoles et des dispositifs numériques à la diversité des capacités et des intentions des individus de se les approprier.

La coexistence au sein d’un même projet de recherche comme le nôtre, de formes d’expression et d’action aussi variées que le changement et la continuité, le souhait de rupture avec le passé des uns, l’envie de conservation de l’existant des autres, permet de souligner certains des paradoxes de la science ouverte et de soulever des questions de nature éthique.

De la science ouverte en archéologie

Pour clore ce retour d’expérience, nous souhaitions évoquer certaines questions éthiques apparues lors de la mise en œuvre de l’application mobile, en particulier en regard de la publication sous licence ouverte des données produites par les chercheurs sur le terrain.

Parmi les données recueillies, celles concernant les prospections de terrain et les inventaires de lithothèques intègrent des données à caractère personnel dont la géolocalisation des chercheurs ayant saisi les données sur terrain. Or, les acteurs concernés n’ont que rarement conscience des conditions de stockage ou des modalités de diffusion de ces données.

Il nous a semblé que les risques de pillage de lieux patrimoniaux (sites archéologiques ou gîtes de matériaux siliceux), liés à la diffusion des données enregistrées, posait davantage de problèmes que la diffusion des données personnelles des enquêteurs.

En effet, il est possible de restituer les pratiques de travail d’un chercheur jour par jour (et même heure par heure) à partir des métadonnées non-anonymisées qu’il a produites avec l’application mobile. On peut ainsi visualiser les déplacements par dates et par heures, dans l’ordre où ces données ont été renseignées. Les données et métadonnées sur les relevés de terrain renseignent par conséquent sur les pratiques de travail des chercheurs sur leurs terrains respectifs.

Le fait de voir ces données diffusées sur l’application cartographique n’a soulevé, pour l’instant, aucune question ni refus, alors que dans le même temps, des craintes claires ont été exprimées sur la diffusion des données de localisation des points de collecte - eu égard aux risques de pillage des sites.

Pour la communauté scientifique concernée, la valeur patrimoniale des gîtes semble davantage problématique que la valeur des données à caractère personnel et les risques de leur diffusion.

On peut émettre aussi l’hypothèse que les inconvénients à voir les données à caractère personnel diffusées sont moindres en comparaison des bénéfices tirés de l’usage de l’application mobile. Celle-ci permet enfin aux chercheurs de participer à une œuvre collective de production de données selon un même modèle et un même cadre d’acquisition, ce qui a longtemps été un point majeur de difficultés à la collaboration.

Ces questions sont abordées dans le cadre de la thèse de Christophe Tufféry en cours depuis 2019 à CY Cergy Paris Université en relation avec l’Institut National du Patrimoine (Inp), portant sur les effets du numérique sur l’archéologie et les archéologues.

Merci pour votre attention!

jeremy.garniaux@univ-amu.fr