Une copie en retard n’écrase rien

Le service garde les scénarios des postes. Chaque texte différent devient une version, cinq versions sont conservées par fichier, et un dépôt qui n’apporte rien n’écrit rien puisque c’est l’empreinte qui tranche.

Reste la question qui se pose dès le deuxième poste : que fait-on quand deux copies ont divergé ?

Le dépôt annonce d’où il part

Chaque envoi porte baseRevision, c’est-à-dire la version distante dont part la copie locale. Le service la compare à la sienne et refuse en 409 si ce n’est plus la dernière.

Côté poste, la marque vit dans la fiche du scénario et porte l’organisation où elle a été posée. Un numéro de version ne veut rien dire ailleurs : changer d’atelier remet la copie au rang de « jamais synchronisée », ce qu’elle est effectivement. La marque ne se pose que sur un dépôt abouti. Et dupliquer un scénario ne l’emporte pas, puisque la copie a un identifiant neuf et donc aucune histoire côté service.

Quatre règles, et pourquoi chacune

Zéro veut dire « je n’ai jamais synchronisé », pas « pas de garde ». C’est la plus contre-intuitive, et c’est celle qui compte. Deux postes qui portent le même dossier copié à la main sur une clé USB doivent se faire arrêter, justement parce qu’aucun des deux ne sait ce que l’autre a déposé. Prendre zéro pour un laissez-passer rendrait le garde inopérant pile dans le cas qu’il existe pour couvrir.

C’est l’absence du champ qui lève le garde, pas sa valeur. Elle est réservée aux clients qui ne suivent pas la synchronisation, comme la console ou un script.

Un texte identique passe toujours, même venu d’une copie en retard. Il n’écrase rien, et refuser là ferait échouer la redéposition de précaution. C’est le geste qu’on veut encourager, pas celui qu’on veut punir.

Une base plus haute que la version courante est refusée aussi. Ce n’est pas une avance, c’est une marque venue d’ailleurs : un autre serveur, une base restaurée depuis une sauvegarde. Un poste qui dit partir de la version 12 quand le service en est à la 7 ne se trompe pas de version, il se trompe de service.

C’est un refus et non une fusion. Deux YAML qui ont divergé ne se réconcilient pas tout seuls, et personne ne veut d’un scénario de préparation issu d’un merge automatique. Il existe un passage en force, l’historique gardant de toute façon ce qu’on remplace, mais c’est un geste délibéré et pas un comportement par défaut.

La veille regarde, elle ne synchronise pas

En face, un tour d’horloge lit la liste du service et la compare aux marques locales. Il ne télécharge rien tout seul.

Télécharger, ça veut dire remplacer un fichier. Un scénario remplacé sous les doigts de quelqu’un qui est en train de l’éditer, c’est exactement la mauvaise surprise qu’un « toujours à jour » automatique finit par produire. Et elle arriverait le jour où ça compte, pas le jour où on l’aurait remarquée.

La proposition a donc trois réponses et non deux : prendre, laisser passer cette version-là, ou ne rien décider. « Ignorer » retient un numéro et pas un drapeau, parce que refuser la version 7 ne doit rien dire de la 8, qui n’est pas encore écrite. Et ignorer ne touche pas à la marque de base : c’est l’affichage qu’on fait taire, pas le garde-fou.

Dernier point, rien n’est signalé quand il n’y a rien à signaler. Une veille qui annonce « tout va bien » toutes les heures finit par ne plus être lue, et le jour où elle annonce autre chose, personne ne regarde non plus.