[{"data":1,"prerenderedAt":167},["ShallowReactive",2],{"blog:fr:git-for-field-data":3},{"id":4,"title":5,"author":6,"body":7,"date":153,"description":154,"extension":155,"meta":156,"navigation":157,"path":158,"seo":159,"stem":160,"tags":161,"__hash__":166},"blog_fr/blog/git-for-field-data/fr.md","Git pour les données de terrain","Aptli",{"type":8,"value":9,"toc":143},"minimark",[10,15,19,22,26,29,36,42,48,52,55,61,67,73,79,85,89,92,95,98,101,104,108,111,114,117,121],[11,12,14],"h2",{"id":13},"le-problème-de-la-concurrence","Le problème de la concurrence",[16,17,18],"p",{},"Depuis les années 1970, les développeurs de logiciels modifient les mêmes fichiers simultanément. Deux personnes modifient la même fonction. L'une effectue son push en premier. L'autre se retrouve face à un conflit de fusion. Ce problème a été résolu de manière si efficace que tous les développeurs d'aujourd'hui utilisent cette solution sans même y penser : le contrôle de version. Enregistrez vos modifications en attente. Validez-les lorsque vous êtes prêt. Si quelqu'un d'autre a modifié la même chose, le système le signale et vous résolvez le conflit avant que quoi que ce soit ne soit mis en ligne.",[16,20,21],{},"Les données de terrain posent le même problème. Deux équipes modifient des entités dans la même zone. L'une se trouve sous terre, sans connexion. L'autre est à l'autre bout de la ville, avec un signal cellulaire instable. Les deux se reconnectent et soumettent leurs modifications. Si le système ne détecte pas le chevauchement, le travail d'une équipe écrase silencieusement celui de l'autre. Si le système verrouille les enregistrements pour éviter les conflits, personne ne peut travailler hors ligne. Ce sont là les mêmes compromis auxquels les équipes logicielles étaient confrontées avant le contrôle de version — et la plupart des logiciels de terrain en sont toujours là.",[11,23,25],{"id":24},"comment-la-plupart-des-logiciels-de-terrain-gèrent-cela","Comment la plupart des logiciels de terrain gèrent cela",[16,27,28],{},"Il existe trois approches courantes, et chacune a un coût.",[16,30,31,35],{},[32,33,34],"strong",{},"La dernière écriture l'emporte."," C'est la méthode la plus simple, mais aussi la plus dangereuse. Les deux utilisateurs modifient le document. Les deux l'envoient. La deuxième soumission écrase la première sans avertissement. Le travail du premier utilisateur est perdu. Cette approche est malheureusement courante dans les logiciels de terrain initialement conçus pour un utilisateur unique, auxquels la prise en charge multi-utilisateurs a été ajoutée par la suite. Elle fonctionne jusqu'à ce qu'elle ne fonctionne plus, et lorsqu'elle échoue, l'échec passe inaperçu.",[16,37,38,41],{},[32,39,40],{},"Verrouillage des enregistrements."," Le système verrouille un élément géographique lorsqu'un utilisateur l'ouvre pour le modifier. Personne d'autre ne peut le modifier tant que le verrou n'est pas levé. Cela évite les conflits en empêchant toute modification simultanée, ce qui rend également impossible tout travail hors ligne. Si un agent de terrain verrouille un élément géographique puis s'enfonce dans un tunnel de métro pendant quatre heures, cet élément reste bloqué pour toute l'équipe. Le verrouillage des enregistrements privilégie l'intégrité des données au détriment de la fluidité opérationnelle.",[16,43,44,47],{},[32,45,46],{},"Éviter les conflits grâce à la délimitation des zones."," Attribuez à chaque équipe une zone géographique et faites-lui confiance pour qu'elle y reste. Cela fonctionne si les zones ne se chevauchent jamais, si les limites sont toujours respectées et si aucun élément ne s'étend au-delà d'une limite. Dans la pratique, les zones se chevauchent à chaque intersection, à chaque limite et au niveau des couloirs d'infrastructure partagés. Cette approche fonctionne en théorie, mais échoue aux marges — là où se déroule l'essentiel du travail intéressant.",[11,49,51],{"id":50},"le-modèle-de-contrôle-de-version","Le modèle de contrôle de version",[16,53,54],{},"Notre approche s'inspire directement du mode de fonctionnement des équipes de développement logiciel. Les concepts correspondent exactement.",[16,56,57,60],{},[32,58,59],{},"La modification s'effectue en local."," Lorsqu'un intervenant sur le terrain modifie un élément — déplace un point, redessine une ligne, met à jour des propriétés —, la modification est enregistrée dans son navigateur. Elle n'est visible par personne d'autre. Cela revient à modifier un fichier sur votre branche locale. L'intervenant peut annuler, rétablir et poursuivre la modification sans affecter l'ensemble de données partagé. Un badge « Modifications non validées » indique le nombre de modifications en attente, de la même manière qu'un développeur suit les modifications non validées.",[16,62,63,66],{},[32,64,65],{},"Soumettre, c'est valider."," Lorsque le collaborateur est prêt, il clique sur « Soumettre ». Toutes les modifications en attente sont envoyées au serveur sous la forme d'une seule version — un ensemble cohérent de modifications accompagné d'un horodatage et de l'identité de l'auteur. C'est ce qu'on appelle une validation. Elle est atomique : soit toutes les modifications sont prises en compte, soit aucune ne l'est.",[16,68,69,72],{},[32,70,71],{},"La révision par l'administrateur correspond à une révision du code."," Pour les collaborateurs sur le terrain qui ne sont pas administrateurs, le bouton « Soumettre » ne publie pas directement le contenu. Il crée une version marquée pour révision. Un administrateur ouvre la file d'attente de révision, examine les différences — ce qui a changé, où, et comment cela se compare à l'état actuel — puis approuve ou rejette la modification. Il s'agit d'une demande de modification. L'ensemble de données partagé ne change pas tant qu'une personne habilitée n'en a pas donné l'autorisation.",[16,74,75,78],{},[32,76,77],{},"La détection des conflits consiste à vérifier les fusions."," Lorsqu'une version est soumise, le serveur vérifie si quelqu'un d'autre a modifié les mêmes éléments ou la même zone géographique depuis la dernière synchronisation de l'auteur de la soumission. En cas de chevauchement, le conflit est signalé. Les deux versions sont visibles — les modifications de l'auteur en bleu, celles de l'autre utilisateur en orange — et l'équipe résout le conflit de manière explicite. Pas de remplacement silencieux. Pas de perte de données.",[16,80,81,84],{},[32,82,83],{},"L'historique des versions correspond au journal des commits."," Chaque version validée est conservée : qui l'a soumise, quand, quelles modifications ont été apportées et qui l'a approuvée. Les versions sont compressées au fil du temps, mais ne sont jamais supprimées. Vous pouvez reconstituer l'état d'une fonctionnalité à n'importe quel moment de son historique. Le journal des versions fait à la fois office de piste d'audit, de mécanisme d'annulation et de mémoire institutionnelle.",[11,86,88],{"id":87},"concrètement-cela-se-traduit-comme-suit","Concrètement, cela se traduit comme suit",[16,90,91],{},"Deux équipes travaillent sur le même réseau de fibre optique. L'équipe A est sur le terrain et modifie le tracé des câbles dans la partie nord. L'équipe B travaille sous terre et modifie les points d'épissure dans la partie centrale. Les deux équipes sont hors ligne.",[16,93,94],{},"L'équipe A termine son travail et se reconnecte. Elle soumet sa version. Le serveur l'accepte — aucun conflit n'est signalé, car personne d'autre n'a modifié ces éléments depuis la dernière synchronisation de l'équipe A. L'administrateur examine les différences, vérifie que les modifications apportées au tracé des câbles sont pertinentes, puis donne son accord. Les modifications sont mises en ligne.",[16,96,97],{},"L'équipe B se connecte une heure plus tard et valide ses modifications. Le serveur détecte que deux de ses modifications de points de raccordement chevauchent des éléments déjà modifiés par l'équipe A. Un avertissement de conflit s'affiche. L'équipe B ouvre la vue des conflits et voit les deux versions : ses modifications en bleu, l'état validé de l'équipe A en orange. Elle ajuste ses points de raccordement pour tenir compte des modifications apportées au tracé des câbles par l'équipe A, valide à nouveau, et l'administrateur approuve la version corrigée.",[16,99,100],{},"Nombre total de données perdues : zéro. Temps total consacré au rapprochement manuel : quelques minutes. Nombre total de fonctionnalités écrasées sans avertissement : zéro.",[16,102,103],{},"Comparons cela aux autres solutions. Avec le principe du « dernier écrit qui l'emporte », la soumission de l'équipe B aurait discrètement écrasé les modifications apportées au tracé des câbles par l'équipe A. Avec le verrouillage des enregistrements, l'une des équipes n'aurait pas pu modifier les données pendant que l'autre travaillait sous terre. Avec l'évitement basé sur les zones, la section où les tracés se chevauchaient aurait donné lieu à un véritable cauchemar de coordination, géré à coups d'appels téléphoniques et de tableaux Excel.",[11,105,107],{"id":106},"priorité-au-mode-hors-ligne-pas-seulement-une-tolérance-du-mode-hors-ligne","Priorité au mode hors ligne, pas seulement une tolérance du mode hors ligne",[16,109,110],{},"On croit souvent à tort que la prise en charge hors ligne implique une dégradation progressive des services en cas de coupure du réseau. Cette conception part du principe que le fonctionnement en ligne est la norme et que le mode hors ligne constitue une exception à gérer. Dans le cadre des opérations sur le terrain, c'est tout le contraire. La connectivité est par défaut intermittente : sous-sols, tunnels, zones rurales, chantiers de construction sans réseau. Un système qui considère le mode hors ligne comme une exception passera la majeure partie de son temps en mode d'exception.",[16,112,113],{},"Le contrôle de version inverse ce principe. Le mode hors ligne est l'état de travail par défaut. Chaque modification reste locale jusqu'à ce que vous décidiez de la valider. Le réseau n'est nécessaire que pour deux choses : envoyer vos modifications vers le serveur et récupérer les dernières mises à jour des autres utilisateurs. Entre ces deux opérations, vous travaillez de manière autonome en disposant de toutes les fonctionnalités d'édition. Lorsque la connexion est rétablie, vous effectuez une synchronisation — et le système s'occupe du reste.",[16,115,116],{},"C'est pour cette raison que le modèle fonctionne. Il n'a pas été conçu pour traiter le mode hors ligne comme un cas particulier. Il a été conçu en partant du principe que les utilisateurs sont généralement hors ligne et ne se connectent qu'occasionnellement — ce qui correspond exactement au fonctionnement du travail sur le terrain.",[11,118,120],{"id":119},"résumé","Résumé",[122,123,124,128,131,134,137,140],"ul",{},[125,126,127],"li",{},"La gestion des données sur le terrain est confrontée au même problème de concurrence que le développement logiciel a résolu il y a plusieurs décennies : plusieurs personnes modifient le même document, souvent sans connexion, avec le risque de réécritures silencieuses.",[125,129,130],{},"Le principe du « dernier à écrire l'emporte » entraîne des pertes de données silencieuses. Le verrouillage des enregistrements empêche le travail hors ligne. L'évitement basé sur les zones échoue à chaque limite et chevauchement.",[125,132,133],{},"Le modèle de contrôle de version — brouillons locaux, validations atomiques, révision par l'administrateur, détection des conflits, historique permanent — s'applique directement du développement logiciel aux opérations sur le terrain.",[125,135,136],{},"Les modifications sur le terrain sont stockées localement jusqu'à ce que l'employé les soumette. Les soumissions non administratives passent par une file d'attente de révision. Les conflits sont détectés sur le serveur et signalés pour une résolution explicite — pas de réécritures silencieuses, pas de perte de données.",[125,138,139],{},"Chaque version validée est conservée avec le nom de l'auteur, l'horodatage et le nom de la personne ayant approuvé. L'historique des versions est compressé mais jamais supprimé. L'état de n'importe quelle fonctionnalité peut être reconstitué à tout moment.",[125,141,142],{},"Le mode hors ligne est l'état de travail par défaut, et non une exception à gérer. Le système part du principe que les utilisateurs sont généralement déconnectés et se synchronisent occasionnellement — ce qui correspond au fonctionnement réel du travail sur le terrain.",{"title":144,"searchDepth":145,"depth":145,"links":146},"",2,[147,148,149,150,151,152],{"id":13,"depth":145,"text":14},{"id":24,"depth":145,"text":25},{"id":50,"depth":145,"text":51},{"id":87,"depth":145,"text":88},{"id":106,"depth":145,"text":107},{"id":119,"depth":145,"text":120},"2026-05-07","Le développement logiciel a résolu le problème de l'édition simultanée il y a plusieurs décennies : mise en attente, validation, détection des conflits, révision du code. Les données de terrain sont confrontées aux mêmes problèmes. Nous avons appliqué la même solution.","md",{},true,"/blog/git-for-field-data/fr",{"title":5,"description":154},"blog/git-for-field-data/fr",[162,163,164,165],"version-control","offline","conflict-detection","field-operations","TXbGJFTsjmcMsG6FWjZL8puRVU1Avx3Rp145x6LDKps",1780338687076]