Organiser une archive de photos de piège photographique : dossiers, métadonnées et étiquettes d'espèces

Voici la vérité inconfortable dont personne ne vous avertit lorsque vous achetez votre première douzaine de caméras : le plus difficile, avec les pièges photographiques, ce n'est pas le piégeage. C'est tout ce qui se passe une fois les cartes SD rentrées à la maison. Un seul projet accumule couramment de plusieurs milliers d'images par carte jusqu'à des centaines de milliers, voire des millions, de fichiers. Et à l'instant même où cette montagne existe, un compte à rebours démarre — car une archive que vous ne pouvez pas fouiller, à laquelle vous ne pouvez pas vous fier et que vous ne pouvez transmettre à personne n'est, à des fins de recherche, quasiment pas une archive.

Les gens qui étudient cela pour vivre le formulent sans détour. À travers toute la littérature, le constat récurrent est que c'est la gestion des données, plutôt que leur collecte, qui constitue le facteur limitant l'achèvement des études par piège photographique. Les caméras sont devenues bon marché et fiables ; le mur du stockage et de l'étiquetage, lui, n'a pas bougé d'un pouce. Le catalogage prend du retard sur l'acquisition, et « une grande quantité de données reste inutilisée et finit par être perdue pour la science et la gestion de la conservation ». Une synthèse a constaté que les comparaisons inter-sites et les méta-analyses sont presque entièrement absentes de la littérature — non pas parce que les données n'existent pas, mais parce que chacun les a organisées différemment, à sa manière bien à soi, et que personne ne peut les combiner.

Cet article porte sur l'étape avant l'analyse : comment agencer, nommer, étiqueter, sauvegarder et, à terme, partager une archive de photos de piège photographique pour qu'elle survive au projet, survive au renouvellement du personnel et reste utile à vous-même comme à toute personne avec qui vous collaborez. Il ne s'agit pas de savoir où placer vos caméras, ni de transformer des horodatages en courbes d'activité — ce sont là d'autres tâches à part entière. Voyez ce qui suit comme la plomberie. C'est ingrat, c'est l'endroit où la plupart des projets perdent discrètement de la valeur, et bien le faire tient presque entièrement à des décisions que vous prenez dans la première heure, pas dans la dernière.

Pourquoi c'est le goulot d'étranglement, et pourquoi « je trierai plus tard » échoue

Il est utile de comprendre pourquoi cette étape engloutit les projets, car les raisons vous disent contre quoi vous prémunir.

La première raison, c'est le volume brut qui se heurte au travail manuel. Récupérer, stocker, organiser et — le plus pénible — identifier le contenu de chaque image se fait encore en grande partie à la main, et la classification des images est régulièrement désignée comme le plus grand défi du piégeage photographique. Le travail est « laborieux, chronophage, source d'erreurs et coûteux ». Quand la main-d'œuvre ne peut pas suivre, l'arriéré grossit, et un arriéré d'images non cataloguées est, de fait, un arriéré de données perdues.

La deuxième raison, c'est que la manipulation manuelle engendre des erreurs, et que les erreurs dans une archive sont corrosives d'une manière qu'elles ne le sont pas dans un simple tableur. Il existe pour cela un chiffre concret et éloquent, tiré d'une étude comportementale menée en Namibie qui a géré environ 1,2 million de photographies issues de 26 caméras sur trois ans : avant que l'équipe automatise la gestion de ses fichiers, les erreurs humaines — dossiers mal étiquetés, copies envoyées au mauvais endroit — représentaient 15,5 % de leurs pertes de données ; après avoir laissé un logiciel gérer les transferts, ce chiffre est tombé à 6,2 %. Mêmes personnes, mêmes caméras. La différence, c'était la structure.

La troisième raison est celle qui coûte le plus cher au domaine : la fragmentation. Parce que la plupart des projets ne se sont jamais souciés que de leur propre espèce cible et ont bâti leur système bricolé, le résultat est ce qu'un article très cité appelle les « données dormantes » — des données indisponibles pour les autres chercheurs ou le public, verrouillées dans un format propre à un logiciel et stockées sur le disque local de quelqu'un. Les pièges photographiques sont indiscriminés ; ils photographient tout ce qui déclenche le capteur. Si vous ne cataloguez que les cerfs et jetez le reste, vous avez mis au rebut des données qu'une autre équipe — celle qui étudie les renards, ou les humains, ou les interactions entre eux — aurait donné cher pour avoir. La solution est de tout cataloguer, de façon cohérente, du premier coup.

Alors « je trierai plus tard » échoue pour une raison simple : plus tard, c'est quand le volume est le plus grand, quand le souvenir de quelle caméra était où est le plus flou, et quand le coût de chaque erreur est multiplié à l'échelle de toute la collection. La rigueur doit être placée en amont. La bonne nouvelle, c'est que la version en amont ne demande pas beaucoup de travail — ce sont surtout une poignée de conventions, appliquées dès le premier jour. Les caméras sont devenues bon marché et fiables ; le mur du stockage et de l'étiquetage, lui, n'a pas bougé, et la seule façon de le franchir est de construire les habitudes avant que la montagne n'existe.

Les caméras sont devenues bon marché et fiables ; le mur du stockage et de l'étiquetage, lui, n'a pas bougé.

Arborescence de dossiers : organisez par déploiement, copiez la carte telle quelle

Commencez par les dossiers, car tout le reste en découle.

Il y a un accord frappant dans le domaine sur le principe fondamental, même si les outils diffèrent : organisez les médias en un répertoire par déploiement — un déploiement étant une seule mise en place d'une caméra à un endroit pour une période donnée — et ne renommez pas les fichiers à leur sortie de la carte. Le guide de bonnes pratiques du GBIF l'énonce presque comme un commandement : « Évitez de renommer les fichiers médias. Organisez plutôt les fichiers médias dans un répertoire par déploiement ».

Pourquoi une telle fermeté à ne pas renommer ? À cause de la manière dont l'unicité des noms de fichiers fonctionne réellement. La plupart des caméras nomment les fichiers avec un court compteur séquentiel (`IMG_0001.JPG`, `PICT0001.JPG`), et ces noms ne sont garantis uniques qu'au sein d'une seule carte. Regroupez les images de trois caméras dans un même dossier et vous obtiendrez aussitôt une collision de trois fichiers `IMG_0001.JPG`. Garder chaque déploiement dans son propre répertoire contourne tout le problème, et cela signifie que vous pouvez copier le contenu d'une carte exactement tel qu'il est — sans transformation, sans occasion d'introduire une erreur. Les auteurs d'Aardwolf ont bâti tout leur schéma à trois niveaux (projet → caméra → dossier d'opération de transfert) autour de cette idée : « cette structure physique garantit aussi que la copie des répertoires depuis une carte de stockage de piège photographique peut se faire telle quelle ».

La boîte à outils R camtrapR formalise une disposition très proche. Pour un relevé avec une caméra par station, vous obtenez `rawImages/stationA`, `rawImages/stationB`, et ainsi de suite ; avec plus d'une caméra par station, vous ajoutez un niveau : `rawImages/stationA/camera1`, `rawImages/stationA/camera2`. Et elle est livrée avec un avertissement qui mérite d'être tatoué quelque part de bien visible : « Si vous avez plus d'une caméra par station mais que vous ne séparez pas les images des différentes caméras à ce stade, vous ne pourrez plus le faire par la suite ». Fusionnez-les maintenant et la provenance est perdue à jamais. C'est le fil rouge de tout le sujet — certaines informations ne peuvent être préservées qu'au moment de l'ingestion, jamais reconstituées.

Deux autres habitudes complètent le tableau. D'abord, conservez vos images brutes comme une sauvegarde intacte et travaillez sur une copie — la fonction de renommage de camtrapR copie délibérément les images vers un nouvel emplacement afin que les originaux ne soient jamais mis en danger. Ensuite, ne stockez rien d'autre que des images dans vos répertoires d'images ; des fichiers parasites peuvent perturber les outils qui parcourent ces dossiers.

Jusqu'à quelle profondeur la hiérarchie doit-elle descendre ? Empruntez la règle empirique au monde de la gestion des données de recherche, qui y réfléchit depuis plus longtemps que les adeptes du piège photographique : limitez les dossiers à trois ou quatre niveaux de profondeur, et essayez de ne pas avoir plus d'une dizaine d'éléments dans une même liste, en gardant données et documentation dans des branches séparées. Un projet de piège photographique s'y range naturellement — projet, puis site ou déploiement, puis carte — sans que personne ait à le forcer.

Certaines informations ne peuvent être préservées qu'au moment de l'ingestion, jamais reconstituées.

Conventions de nommage : commencez par la date, jamais par l'espèce

Si vous renommez vos fichiers — et il y a des raisons légitimes de le faire, principalement pour qu'ils soient auto-descriptifs une fois sortis de l'abri de leur dossier — il y a une bonne façon et plusieurs mauvaises.

La règle la plus importante de toutes est de faire coïncider l'ordre alphabétique avec l'ordre chronologique. L'astuce propre consiste à commencer le nom par la date, `AAAAMMJJ`, ou la date et l'heure, `AAAAMMJJ_HHMMSS`. Le guide du GBIF donne les exemples concrets directement : `20200709_093352.JPG` est bon, parce qu'il se trie correctement ; `09072020_093352.JPG` est mauvais, parce que le nommage jour-en-premier brouille l'ordre chronologique dès que vous avez plus d'un mois de données. Ce n'est pas du pédantisme — la moitié des outils que vous utiliserez un jour supposent que l'ordre des fichiers reflète l'ordre du temps, et une caméra qui nomme les fichiers `1.jpg, 2.jpg … 10.jpg` sera lue par votre ordinateur comme `1, 10, 2 …`, brisant discrètement cette supposition.

Les guides génériques d'archivage de données abondent dans le même sens et ajoutent les détails d'intendance : utilisez des dates au format ISO `AAAA-MM-JJ`, séparez les éléments par des tirets ou des tirets bas, évitez les espaces et les caractères spéciaux comme `&`, `?` ou `!`, gardez des noms parlants mais brefs, réservez l'extension à trois lettres au format du fichier, et incluez un indicateur de version là où cela compte. Le schéma de nommage propre à camtrapR en est une illustration concrète : il renomme en `StationID__Date__Time(X).JPG`, où le `(X)` désambiguïse les images prises dans la même minute, et il réserve les doubles tirets bas comme délimiteurs de champs — vos identifiants de station et de caméra ne doivent donc pas contenir eux-mêmes de tirets bas.

Il y a ici une règle que les adeptes du piège photographique enfreignent constamment, et elle mérite sa propre ligne : ne stockez pas d'information de classification dans le nom de fichier. Il est tentant de renommer une photo `..._Ardea_alba_1_Anas_platyrhynchos_male_female.jpg` pour pouvoir la retrouver plus tard. Ne le faites pas. Le guide du GBIF signale précisément cela comme une mauvaise pratique. La raison en est qu'une identification n'est pas un fait à propos du fichier ; c'est une interprétation, et les interprétations se révisent. Gravez « renard roux » dans un millier de noms de fichiers, puis découvrez que la moitié étaient des renards gris, et vous voilà avec un millier d'opérations de renommage et une piste de vérification rompue. Les étiquettes ont leur place dans les métadonnées, où elles peuvent être corrigées sans toucher à l'identité du fichier — ce qui est exactement là où nous allons ensuite. (camtrapR peut ajouter un nom d'espèce à un nom de fichier par commodité pour la consultation, mais notez qu'il lit d'abord cet identifiant d'espèce dans votre arborescence de dossiers ou dans vos étiquettes de métadonnées ; l'identification vit ailleurs, et le nom de fichier n'en est qu'une copie.)

Quand vous avez vraiment besoin de renommer en masse, vous ne le faites pas à la main. Des outils dédiés de renommage par lot existent pour chaque plateforme, et l'utilitaire de métadonnées ExifTool peut renommer des fichiers à partir de leurs propres métadonnées — en tirant la date de capture directement de chaque image pour construire le nouveau nom — en plus des modifications de métadonnées par lot, du géoréférencement et de la correction de date et d'heure.

Étiquetage et annotation : convenez du schéma avant de toucher à une image

Voici maintenant la partie que tout le monde envisage comme « le travail » : passer en revue les images et consigner ce qu'elles contiennent. Cette étape s'appelle l'étiquetage — examiner chaque image et encoder ses attributs d'intérêt sous forme de données — et c'est là que se produisent les erreurs les plus grandes, les plus coûteuses et les plus évitables.

La leçon la plus profonde ici provient d'un article distillant huit années de conception de l'outil d'analyse d'images Timelapse, et ce n'est pas un conseil sur un logiciel. C'est une décision que vous prenez avant le logiciel : spécifiez et déployez un schéma de données commun. Avant que quiconque étiquette quoi que ce soit, le responsable du projet devrait décider exactement quelles données seront relevées à partir des images, les définir comme un schéma standardisé et lisible par machine — les champs, leurs noms, leurs types de données, leurs valeurs autorisées — puis faire en sorte que le logiciel l'impose. La raison, c'est le problème des multiples personnes chargées de l'étiquetage. Un vrai projet compte plusieurs personnes (souvent des bénévoles) qui traitent chacune une part des images, et « sans cohérence des données — si chaque analyste spécifiait de manière idiosyncrasique quelles données encoder à partir des images, dans quel format et sous quel nom — il serait extrêmement difficile de donner du sens aux données d'un analyste à l'autre ». Convenez du schéma d'abord, ou passez le reste du projet à réconcilier dix dialectes du même jeu de données.

Un gabarit concret et citable pour ce schéma est la disposition en quatre tables vers laquelle convergent les projets bien organisés, joliment saisie dans un exemple pédagogique bâti autour d'un jeu de données canadien : une table de projet (objectifs, conception, qui est responsable), une table d'images/observations (espèce, effectif, âge/sexe, comportement, horodatage, par image), une table de déploiement (localisation, début et fin, caméra, hauteur, orientation) et un inventaire des caméras (marque, modèle, numéro de série). Chaque emplacement de caméra unique reçoit son propre enregistrement de déploiement. C'est le même squelette qu'emploient les standards formels — nous y viendrons sous peu — et même si vous ne publiez jamais, disposer vos données ainsi dès le départ signifie que vous gardez les bonnes choses aux bons endroits.

Au-delà du schéma, l'article des huit années de Timelapse est un catalogue de motifs d'efficacité durement acquis, et ils valent la peine d'être connus car ils séparent un flux de travail qui prend une saison d'un qui prend une année. La même équipe a mesuré des gains de temps d'environ 200 % par rapport à des analystes utilisant un simple tableur. Quelques-uns des motifs qui comptent le plus :

• Réduisez la saisie au clavier. Taper est lent et source d'erreurs ; remplacez-le par la sélection partout où c'est possible — menus déroulants pour les espèces, cases à cocher pour les indicateurs, autocomplétion qui propose vos saisies précédentes.
• Comptez en cliquant, et marquez ce que vous avez compté. Quand une image renferme un troupeau, il est facile de mal compter — perdre le fil, compter deux fois, en oublier un. Laisser la personne cliquer sur chaque animal pour incrémenter un compteur et déposer un marqueur visible corrige les trois modes d'erreur d'un coup et permet à une seconde personne de vérifier le comptage plus tard.
• Auto-remplissez tout ce que l'ordinateur sait déjà. Le nom de fichier, le dossier et la date/heure de capture devraient être renseignés automatiquement, jamais re-tapés. Beaucoup de caméras intègrent aussi des extras — température ambiante, parfois GPS — qui peuvent être tirés directement des métadonnées de l'image vers vos champs de données.
• Regroupez les rafales en épisodes. Un déclenchement par mouvement produit souvent une rafale, et un seul animal qui s'attarde génère de nombreuses images quasi identiques. Regrouper en un unique « épisode » les images prises dans un court intervalle permet de consigner l'événement une seule fois au lieu de gonfler les effectifs — l'outil peut signaler la première image de chaque épisode et numéroter les autres.
• Propagez les valeurs répétitives. Sur une série d'images semblables, les données sont souvent identiques ; les commandes de recopie vers l'avant, de report vers l'arrière et de copie-à-tous transforment cent saisies identiques en une seule.

Ce ne sont pas des luxes. De mauvais choix d'outils entraînent « une saisie de données fastidieuse… sujette aux erreurs (ce qui affecte la validité des données collectées)… et — à long terme — très coûteuse en temps d'analyste ». À propos, c'est la façon la plus honnête d'envisager le logiciel en général pour cette tâche : le propre panorama du domaine sur les programmes disponibles a constaté qu'aucun outil unique ne s'est imposé comme favori évident, et un rapport majeur de bonnes pratiques a conclu à peu près la même chose — de nombreux grands projets « ont fini par concevoir leurs propres systèmes de A à Z », et il vous faudra peut-être en tester plusieurs avant qu'un ne convienne à votre flux de travail. Il n'y a pas de bonne réponse universelle ; il y a la rigueur du schéma, et il y a l'adéquation de l'outil à la façon dont vos gens travaillent réellement.

Convenez du schéma d'abord, ou passez le reste du projet à réconcilier dix dialectes du même jeu de données.

Où vivent les étiquettes : EXIF, IPTC, XMP et fichiers annexes

Vous avez donc étiqueté une espèce sur une image. Où cette étiquette va-t-elle physiquement — et sera-t-elle encore là quand vous copierez le dossier sur la machine d'un collègue dans un an ?

C'est ici qu'il est payant de comprendre les trois standards de métadonnées qui vivent dans (et à côté de) un fichier image, car ils font des travaux différents :

• EXIF est ce que la caméra écrit au moment de la capture — la date et l'heure, plus des réglages comme la vitesse d'obturation, l'exposition, la sensibilité ISO et l'état du flash. En général vous ne l'éditez pas ; vous le lisez. Le champ de date et d'heure (`DateTimeOriginal`) est le joyau de la couronne, et nous verrons pourquoi.
• IPTC est destiné au texte que vous ajoutez après la capture — auteur, droits d'auteur, légendes, et surtout des mots-clés. Son écueil, c'est que ses champs de texte sont limités en longueur.
• XMP est l'évolution moderne d'IPTC. Il « supprime les limites de taille de texte » et prend en charge plusieurs langues, ce qui explique pourquoi les outils recommandent généralement de donner la priorité au XMP pour les étiquettes et les légendes.

Le point qui rend ces trois-là importants pour une archive : les mots-clés et les étiquettes peuvent être écrits directement dans les propres métadonnées de l'image, via les champs IPTC et XMP. Cela signifie qu'une étiquette d'espèce — « renard roux », ou tout un sujet hiérarchique comme Mammalia > Carnivora > Vulpes > Vulpes vulpes — peut être stockée à l'intérieur de la photo, pour qu'elle voyage avec le fichier. Comme le dit sans détour la documentation d'un outil de métadonnées : « Stocker les métadonnées directement dans les fichiers image permet de préserver cette information lors du déplacement ou de l'envoi des fichiers vers d'autres systèmes ». C'est tout l'enjeu. Une étiquette dans une base de données séparée, laissée derrière lors d'une copie, est une étiquette que vous avez perdue ; une étiquette intégrée au fichier est une étiquette qui survit au voyage.

Il y a une subtilité à connaître, surtout si vous photographiez en RAW ou faites de la vidéo. Vous ne pouvez pas toujours réécrire des métadonnées dans le fichier d'origine — les formats RAW sont souvent en lecture seule, et l'étiquetage de la vidéo est mal standardisé. La réponse est un fichier annexe (« sidecar ») : un petit fichier compagnon (nommé `nomdefichier.ext.xmp`) qui contient les métadonnées à côté de l'image, utilisé seul ou en plus de l'écriture dans le fichier. Le choix pratique est donc configurable — écrire les étiquettes dans l'image, dans un fichier annexe, ou les deux — et le bon réglage dépend de vos types de fichiers.

Un hybride pragmatique et très employé consiste à stocker les étiquettes à deux endroits à la fois : intégrées dans l'image (ou son fichier annexe) pour la portabilité, et aussi dans une base de données externe pour une recherche rapide — en traitant la base comme un cache et les fichiers comme « l'unique source de vérité ». Ainsi vous obtenez la vitesse quand vous interrogez et la durabilité quand vous déplacez.

Sous presque tout cela se trouve un petit outil, ingrat et indispensable : ExifTool, l'utilitaire gratuit et multiplateforme de Phil Harvey pour lire, écrire et éditer des métadonnées dans des centaines de formats, dont EXIF, IPTC et XMP. C'est le moteur sur lequel s'appuient les boîtes à outils de recherche — camtrapR, par exemple, en dépend pour chaque opération de métadonnées et ne fait pas grand-chose sans lui. Vous l'appelez peut-être rarement directement, mais il fait presque certainement le travail derrière quoi que vous utilisiez.

Une note honnête sur la façon dont le flux « espèce-en-métadonnée » se câble réellement en pratique, car les outils se répartissent la tâche d'une manière qui surprend. C'est en général une application généraliste de gestion de photos qui écrit d'abord le mot-clé d'espèce dans les métadonnées de l'image (via ses champs de mots-clés/sujets), et la boîte à outils R relit ensuite ces étiquettes intégrées — camtrapR peut tirer un identifiant d'espèce de l'étiquette de métadonnée `HierarchicalSubject` qu'une application d'étiquetage a écrite — pour assembler ses tables d'enregistrements. L'identification naît dans l'outil d'étiquetage ; le champ de métadonnée est la façon dont elle est stockée et transmise plus loin.

Une étiquette dans une base de données laissée derrière lors d'une copie est une étiquette que vous avez perdue ; une étiquette intégrée au fichier est une étiquette qui survit au voyage.

L'horodatage mérite une paranoïa particulière

Parmi toutes les données rattachées à une image, un champ est unique par son caractère irrécupérable, et il vaut la peine de l'extraire de la discussion sur les métadonnées pour insister dessus à part.

Le guide du GBIF est sans ambiguïté : la date et l'heure de prise d'une photo « sont l'aspect le plus important de ses métadonnées… et ne peuvent pas être dérivées après coup » — contrairement, par exemple, à la localisation de la caméra, que vous pouvez toujours retrouver ultérieurement. Ratez l'horodatage et il n'existe aucune seconde source pour le corriger. L'équipe de Timelapse, après huit années à voir cela mal tourner, a catalogué les quatre modes d'échec classiques : une caméra dont l'horloge n'a tout simplement jamais été réglée correctement (tout est décalé d'une valeur fixe) ; une caméra qui ne gère pas le changement d'heure d'été (un paquet d'images décalées d'une heure) ; une horloge qui dérive lentement, en avance ou en retard, au cours d'un déploiement ; et une caméra qui enregistre les dates de façon ambiguë, comme `02/10/2019`, qui peut être février ou octobre selon la convention.

Deux habitudes en amont préviennent l'essentiel de cela, et toutes deux sont, par conception, neutres vis-à-vis du lieu. D'abord, réglez l'horloge de la caméra sur le temps universel coordonné (UTC) ou sur l'heure d'hiver locale, et désactivez le passage automatique à l'heure d'été — puis consignez séparément le fuseau horaire du déploiement. La raison pour laquelle cela l'emporte sur « réglez-la à l'heure locale » est que le passage à l'heure d'été est le saboteur silencieux : il place une couture cachée d'une heure au travers de la moitié de vos enregistrements, et une horloge fixée sur l'UTC ou l'heure d'hiver n'a tout simplement aucune couture sur laquelle trébucher. Ensuite, quand vous exportez ou nommez des fichiers, écrivez les heures dans un ordre non ambigu — date d'abord, `AAAA-MM-JJ` ou l'horodatage ISO complet — pour que personne en aval n'ait à deviner si `02/10` est février ou octobre.

Si vous découvrez après coup que l'horloge d'un déploiement était fausse d'une valeur connue, c'est récupérable en masse — l'outillage peut décaler les horodatages de toutes les images d'un dossier d'un même écart fixe, ce qui est la bonne façon de traiter, par exemple, le bogue de micrologiciel qu'un grand fabricant a livré et qui a brouillé l'année sur ses caméras au passage 2015/2016. Sauvegardez d'abord les images, puis corrigez. Le point de fond demeure : une erreur d'horloge détectée à l'ingestion est un tracas de cinq minutes ; la même erreur détectée jamais est une fiction permanente dans votre jeu de données.

Faire le tri dans les vides : le pré-filtrage par IA

Voici la partie du flux de travail où le problème du volume et l'outillage moderne finissent par se rencontrer à votre avantage.

Les pièges photographiques se déclenchent sur la chaleur et le mouvement, ce qui veut dire qu'ils se déclenchent sur les branches secouées par le vent, l'herbe qui ondule, la pluie, le soleil qui bouge et l'air chaud aussi facilement que sur les animaux. Résultat : une large majorité des images d'un déploiement typique ne contient aucun animal — ce sont des vides. (Vous verrez circuler dans le domaine un chiffre précis de « 70 à 95 % de vides » ; traitez-le comme du folklore à moins que vos propres données ne disent le contraire, car il n'est adossé à aucune source solide unique. Ce qui est bien établi, c'est la réalité qualitative : les images vides écrasent d'ordinaire les utiles, et les passer en revue à la main est le grand gouffre de temps de toute l'entreprise.) Se frayer un chemin à travers elles manuellement est exactement le travail « ennuyeux » qui engloutit les heures d'analyste.

L'outil standard pour trancher dans le lot est un modèle de détection — le plus notoire étant MegaDetector, le modèle open source du laboratoire AI for Good de Microsoft. Il fait une seule chose et la fait largement : il « détecte les animaux, les personnes et les véhicules dans l'imagerie de piège photographique et écarte les images vides, réduisant la revue manuelle sur de grands jeux de données ». Entraîné sur plusieurs millions d'images provenant de nombreux écosystèmes, il a été adopté par bien plus d'une centaine d'organisations à travers le monde, des agences nationales de la faune aux laboratoires universitaires sur plusieurs continents. Point crucial, vous en comprenez la portée : MegaDetector trouve les animaux ; il ne les identifie pas à l'espèce. C'est une première passe grossière mais impitoyable — animal / personne / véhicule / rien — qui vous permet de mettre les images vides de côté et de dépenser votre véritable attention sur celles qui contiennent réellement quelque chose. Les coordonnées et l'indice de confiance du détecteur alimentent ensuite un outil d'étiquetage, qui trace un cadre autour de chaque détection et vous laisse l'accepter, la rejeter ou l'étiqueter à l'espèce.

Une note sur ce que cela vous apporte et ce que cela ne vous apporte pas. Un détecteur fait le tri dans les vides ; il ne fait pas votre identification à l'espèce, et même couplé à un classificateur d'espèces, la précision de la vision par ordinateur reste en retrait de celle d'un expert humain — de sorte que la recommandation durable dans tout le domaine est le pré-filtrage assisté par IA plus la vérification humaine, pas l'automatisation aveugle. Utilisé ainsi, cela change l'arithmétique d'un projet : au lieu qu'une personne ouvre chacune de quelques centaines de milliers d'images, elle ouvre la fraction qu'un détecteur signale comme non vide, et vérifie à partir de là.

Un détecteur fait le tri dans les vides ; il ne fait pas votre identification à l'espèce — couplez-le à un humain, pas à une foi aveugle.

Sauvegarde et stockage : partez du principe qu'un disque va lâcher, parce qu'un disque lâchera

Une archive n'est aussi durable que son pire point de défaillance unique, et en piégeage photographique ce point est en général un disque dur posé sur un seul bureau.

Le volume qui rend tout le reste difficile rend aussi la sauvegarde non triviale : il n'est « pas trivial de stocker, sauvegarder et gérer en toute sécurité les fichiers médias » à cette échelle. La recommandation standard est d'utiliser des services cloud ou un stockage institutionnel bien géré, en acceptant que cela ait un coût réel, et — quand vous le pouvez — d'utiliser un système de stockage capable de servir les fichiers via des adresses web stables, afin qu'un jeu de données publié puisse référencer les images directement plutôt que d'expédier des copies de tout. Les guides génériques de gestion des données renforcent la discipline évidente que les adeptes du piège photographique négligent à leurs dépens : une sauvegarde délibérée, pas juste « c'est sur mon portable ».

Deux choix de conception issus de l'outillage valent la peine d'être empruntés même si vous ne touchez jamais aux outils eux-mêmes. Le premier est le modèle des fichiers-comme-source-de-vérité déjà mentionné : gardez les données faisant autorité dans les fichiers image (et leurs fichiers annexes), et traitez toute base de données comme un cache reconstructible. Si la base se corrompt, vous la régénérez à partir des fichiers ; vous ne perdez jamais les observations réelles. Le second est de séparer l'organisation logique de l'emplacement physique — en laissant les données d'un projet s'étaler sur plusieurs disques ou un partage réseau tout en se présentant comme une seule hiérarchie propre — ce qui est précisément la façon dont un système minimaliste a passé le cap du million de photos sur du matériel courant.

Le fil conducteur est de cesser de faire confiance à un quelconque appareil unique. Les disques lâchent, les cartes se corrompent, et le décompte sans fard des défaillances physiques de l'étude namibienne — dégâts des eaux de pluie, batteries mortes, cartes défectueuses, destruction par la faune — rappelle que le terrain est hostile à vos données bien avant qu'elles n'atteignent un ordinateur. La redondance n'est pas optionnelle ; c'est le prix pour maintenir en vie une archive de plusieurs années.

Standards de données : parler une langue que les autres peuvent lire

Tout ce qui précède rend votre archive utilisable pour vous. Les standards, c'est ce qui la rend utilisable pour tout le monde — et, de plus en plus, pour votre propre futur vous-même et pour les modèles d'apprentissage automatique que vous entraînerez peut-être plus tard.

Deux standards dominent, et ils s'emboîtent parfaitement.

Camtrap DP (le Camera Trap Data Package) est celui conçu sur mesure. C'est un format d'échange développé par la communauté, géré sous l'égide de l'organisme des standards d'information sur la biodiversité (TDWG), qui structure tout un projet en trois tables liées — Déploiements, Médias et Observations — plus un fichier de métadonnées décrivant le paquet. Il a été conçu précisément parce que, alors que le traitement des « Big Data » des pièges photographiques était devenu abordable, « l'harmonisation et l'échange des données restent limités, entravant leur plein potentiel ». Il prend en charge tout l'éventail des façons dont les gens travaillent réellement — classification humaine et par IA, par image et par événement — et il s'appuie sur une spécification ouverte existante d'empaquetage de données afin qu'un logiciel standard puisse le valider automatiquement. Il est, de fait, le successeur moderne d'un standard antérieur de métadonnées de pièges photographiques qui a le premier défini la hiérarchie désormais omniprésente à quatre niveaux Projet → Déploiement → Séquence d'images → Image et la convention de regrouper en une seule séquence les images prises dans un intervalle de 60 secondes.

Darwin Core est le standard de biodiversité plus large dans lequel les données de pièges photographiques peuvent aussi s'écouler. C'est « un ensemble de termes aux sémantiques clairement définies, compréhensibles par les personnes ou interprétables par les machines », ratifié comme standard en 2009 et utilisé pour partager des centaines de millions d'enregistrements de biodiversité à travers des centaines d'organisations et des dizaines de pays. Ses termes sont organisés en classes couvrant des choses comme l'événement, la localisation, l'occurrence et le taxon ; une observation de piège photographique se rattache à la classe Occurrence. Parce qu'il est délibérément simple et indépendant de la technologie, les mêmes données peuvent être exprimées en CSV, XML, JSON ou d'autres encodages.

Comment choisir ? La recommandation pratique est claire : pour les données de piège photographique en particulier, Camtrap DP est à privilégier parce qu'« il est spécifiquement conçu pour ce type de données et peut conserver plus d'informations qu'une archive Darwin Core », tandis qu'une archive Darwin Core est la voie à suivre quand vous voulez vous insérer dans le monde plus large des données de biodiversité. Et les deux ne sont pas rivaux — il existe un paquet R dont le rôle entier est de lire un Camtrap DP et de le convertir en Darwin Core (et en EML), ce qui est exactement le pont qu'un dépôt public utilise pour ingérer les paquets de pièges photographiques. Vous pouvez travailler dans le format natif au piège photographique et publier tout de même dans le format général.

Un cadrage que toute cette discussion sur les standards rend neutre vis-à-vis du lieu et qui vaut la peine d'être intériorisé : stockez le nom scientifique, même si vous ne montrez jamais aux gens que le nom courant. Les noms courants dérivent selon les régions et les langues et désignent parfois des animaux entièrement différents — « elk » désigne une espèce en Amérique du Nord et une autre en Europe — alors que le nom scientifique est globalement cohérent et sans ambiguïté. Gardez une unique table de référence des espèces que vous attendez, issue d'une taxonomie faisant autorité, et stockez le nom scientifique comme point d'ancrage. C'est une petite habitude qui épargne à une collaboration internationale une catégorie de confusion réellement difficile à démêler après coup.

Partage et archivage : transformer un dossier privé en ressource publique

La dernière étape — et celle qui distingue une archive de recherche d'une boîte à chaussures personnelle — est de publier les données quelque part où d'autres peuvent les trouver et les réutiliser.

La destination, dans le monde de la recherche, est en général un dépôt public de biodiversité atteint via une chaîne de publication standard ; le Système mondial d'information sur la biodiversité (GBIF) est le principal, et vous y publiez en standardisant d'abord vos données en Camtrap DP ou en Darwin Core. L'objectif directeur porte un nom — les données FAIR : faciles à trouver, accessibles, interopérables, réutilisables — et la recette est concrète : déposez les données dans un dépôt qui leur attribue un identifiant unique stable, joignez de riches métadonnées pour que d'autres puissent juger si elles répondent à leurs besoins, ajoutez une licence ouverte pour qu'ils aient le droit de les utiliser, et standardisez le format pour qu'il se combine réellement avec d'autres jeux de données. La recommandation forte est de publier un jeu de données par projet, ce qui garde la portée, les méthodes et les contributeurs descriptibles en un même lieu cohérent.

Avant que quoi que ce soit ne devienne public, deux étapes de préparation comptent. D'abord, des identifiants uniques et stables pour vos enregistrements — idéalement ceux que votre système de gestion a déjà attribués, utilisés tels quels plutôt que bidouillés, puisque ajouter des morceaux à un identifiant ne fait que le fragiliser. Ensuite, traitez les informations sensibles en les généralisant, pas en les supprimant. Les données de piège photographique portent trois sortes de sensibilité : les localisations d'espèces rares ou menacées (qui peuvent attirer les braconniers), les localisations de vos propres caméras (vol et vandalisme), et les données personnelles — les noms des participants, et toute image de personnes identifiables, qui relèvent de réglementations sur la vie privée comme le RGPD. L'approche recommandée est de flouter les coordonnées d'une espèce sensible plutôt que de retenir entièrement l'enregistrement, de garder privées les images de personnes, et de documenter toute généralisation appliquée pour que les utilisateurs sachent ce qu'ils regardent. Le monde de la science participative pratique depuis longtemps des versions de cela : masquer la localisation des espèces menacées et en danger pour que les points de données publics ne se résolvent qu'au centre d'un projet, et offrir des embargos sur les données pour qu'une équipe ait la primeur de la publication avant que les données ne s'ouvrent.

Il vaut la peine de dire clairement pourquoi vous vous donneriez la peine de partager, car il est facile de traiter la publication comme une paperasse bureaucratique. Toute la raison pour laquelle le problème des « données dormantes » importe, c'est que des données de piège photographique partagées dans un format cohérent sont réutilisables bien au-delà de leur objectif d'origine — pour la modélisation de la répartition des espèces, pour le suivi de la biodiversité, et même comme données d'entraînement pour la prochaine génération de modèles de détection. Les données que vous avez collectées pour répondre à une question peuvent, correctement archivées et partagées, aider à en répondre à une douzaine que vous n'aviez jamais pensé à poser. C'est là tout l'argument pour faire tout cela avec soin : une archive organisée, standardisée et publiée ouvertement ne se contente pas de survivre à votre projet — elle le dépasse.

Les données que vous avez collectées pour répondre à une question peuvent, correctement archivées, aider à en répondre à une douzaine que vous n'aviez jamais pensé à poser.

Un flux de travail minimal, du début à la fin

Si vous voulez le tout comme une seule séquence, voici la colonne vertébrale que les sources décrivent collectivement — adaptez les outils, gardez l'ordre :

1. Ingérez par déploiement. Copiez chaque carte dans son propre dossier par déploiement, sans renommer ; gardez la copie brute intacte comme sauvegarde.
2. Corrigez l'horloge d'abord. Vérifiez les horodatages ; si l'horloge d'un déploiement était fausse d'une valeur connue, décalez-la en masse maintenant, avant que quoi que ce soit d'autre ne lise ces heures.
3. Décidez du schéma. Définissez vos champs de données et leurs valeurs autorisées en amont et faites-les imposer par votre logiciel à toutes les personnes chargées de l'étiquetage.
4. Pré-filtrez les vides. Passez un détecteur pour mettre de côté les images vides, afin que l'attention humaine n'aille qu'aux images contenant quelque chose.
5. Étiquetez efficacement, dans les métadonnées. Identifiez et annotez en privilégiant la sélection sur la saisie et le regroupement par épisodes sur l'image par image, et stockez les étiquettes dans les propres EXIF/IPTC/XMP de l'image (ou un fichier annexe) pour qu'elles voyagent.
6. Sauvegardez de façon redondante. Stockage cloud ou institutionnel, plus la discipline que ce sont les fichiers — et non une quelconque base de données — la source de vérité.
7. Standardisez et partagez. Exportez en Camtrap DP (ou Darwin Core), généralisez tout ce qui est sensible, et publiez un jeu de données par projet dans un dépôt public.

Aucune de ces étapes n'est difficile. Plusieurs d'entre elles sont impossibles à faire plus tard. Cette asymétrie est la raison entière de prendre l'étape ingrate au sérieux : l'archive que vous pourrez transmettre à un inconnu dans cinq ans se construit, ou se perd, dans la première heure après le retour des cartes à la maison.

Questions fréquentes