Le problème de la concurrence

Depuis les années 1970, les développeurs de logiciels modifient les mêmes fichiers simultanément. Lorsque deux personnes modifient la même fonction, l’une d’elles effectue sa validation en premier, tandis que l’autre se retrouve confrontée à un conflit de fusion. Le contrôle de version a résolu ce problème de manière si efficace que tous les développeurs l’utilisent désormais sans même y penser : ils enregistrent leurs modifications, les valident lorsqu’elles sont prêtes et résolvent tout conflit avant la mise en production.

Les données de terrain présentent la même structure. Deux équipes modifient des éléments dans la même zone. L'une travaille sous terre sans connexion, l'autre à l'autre bout de la ville avec un signal instable. Elles se reconnectent toutes les deux et envoient leurs modifications. Le système doit conserver le travail des deux équipes et indiquer les zones de chevauchement.

Les besoins en matière d'édition sur le terrain

La révision sur le terrain nécessite trois éléments à la fois.

Travailler sans réseau. Une équipe effectue des modifications sous terre ou hors de portée du réseau, et ces modifications sont conservées sur l'appareil jusqu'au rétablissement de la connexion.

Toutes les modifications sont conservées. Lorsque deux équipes modifient la même zone, chacune conserve son travail, et les chevauchements apparaissent avant que les modifications ne soient validées.

Les espaces partagés restent partagés. Les équipes interviennent là où le travail doit être effectué, et les carrefours, les axes et les infrastructures partagées restent modifiables par tous ceux qui en ont besoin.

Le modèle de contrôle de version

Aptli s'inspire du mode de fonctionnement des équipes de développement logiciel, et les concepts correspondent parfaitement les uns aux autres.

L'enregistrement s'effectue localement. Les modifications apportées par un intervenant sur le terrain (déplacement d'un point, modification du tracé d'une ligne, mise à jour des propriétés) sont enregistrées dans une version de travail sur l'appareil, comme si vous modifiiez une branche locale. Les fonctions « Annuler » et « Rétablir » s'appliquent à l'ensemble de la session, et un compteur indique le nombre de modifications en attente.

Le téléchargement correspond à une opération de « push ». Lorsque le collaborateur est prêt, la fonction « Upload » envoie la version de travail au serveur sous la forme d'un ensemble de modifications, accompagnée d'un horodatage et du nom du collaborateur.

L'approbation correspond à la révision du code. La commande « Soumettre » envoie la version et demande une approbation. Une personne chargée de l'approbation examine les modifications apportées et leur emplacement, puis valide la version ou la renvoie accompagnée d'une remarque. La carte partagée est mise à jour lorsque la personne chargée de l'approbation valide la version.

Les vérifications de conflits sont des vérifications de fusion. Avant qu'une version ne soit intégrée, Aptli vérifie si quelqu'un d'autre a modifié les mêmes fonctionnalités. Tout chevauchement est signalé, les deux séries de modifications s'affichent, et l'équipe le résout explicitement.

L'historique des versions correspond au journal des validations. Chaque version validée indique qui l'a soumise, à quelle date, quelles modifications elle comporte et qui l'a approuvée. Une version validée peut être restaurée, et cette restauration fait l'objet d'une procédure d'approbation comme toute autre modification.

Concrètement, cela se traduit comme suit

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.

L'équipe A termine son travail, rétablit les connexions et soumet sa version. Personne d'autre n'a modifié ces éléments. Le responsable de la validation examine les modifications apportées au tracé des câbles et les valide.

L'équipe B se reconnecte une heure plus tard et valide ses modifications. Deux de ses modifications au niveau des points de raccordement chevauchent des éléments déjà modifiés par l'équipe A, et Aptli signale le conflit. L'équipe B prend connaissance des deux séries de modifications, adapte ses points de raccordement aux tracés de câbles de l'équipe A et valide à nouveau. Le responsable de la validation valide la version corrigée.

Les deux équipes poursuivent leur travail. La synchronisation ne prend que quelques minutes, et chaque chevauchement a été détecté avant qu'il ne se produise.

Conçu pour fonctionner hors ligne

La connectivité sur le terrain est intermittente : sous-sols, tunnels, routes de campagne, chantiers. Un système utilisé sur le terrain passe la majeure partie de la journée hors ligne.

Le système de versions fait de cela l'état par défaut. Chaque modification reste sur l'appareil jusqu'à ce que l'utilisateur la transmette. Le réseau est nécessaire à deux reprises : pour envoyer les modifications et pour récupérer les dernières mises à jour des autres utilisateurs. Entre ces deux moments, l'utilisateur dispose d'un accès complet en mode édition, et lorsque la connexion est rétablie, la synchronisation s'effectue.

Ce modèle s'inspire du fonctionnement du travail sur le terrain : principalement hors ligne, avec une connexion occasionnelle.

Résumé

Les données de terrain sont confrontées au problème de concurrence que le développement logiciel a résolu il y a plusieurs décennies : plusieurs personnes modifient le même contenu, souvent sans connexion.
La modification sur le terrain doit pouvoir s’effectuer sans signal ; chaque modification doit être conservée et l’historique doit rester partagé.
Le modèle de gestion des versions (enregistrements locaux, téléchargements, validation, vérification des conflits, historique permanent) s’applique directement du développement logiciel aux opérations sur le terrain.
Les modifications sont enregistrées sur l’appareil jusqu’à ce que l’intervenant les télécharge. La soumission fait l’objet d’une demande de validation ; un validateur valide alors la version ou la renvoie accompagnée d’une note. Les conflits sont signalés pour être résolus de manière explicite.
Chaque version validée enregistre l'identité de son auteur, l'heure et celle du validateur ; une version validée peut être restaurée après validation.
Ce modèle s'inspire du fonctionnement du travail de terrain : principalement hors ligne, avec une connexion occasionnelle.