Les clips tournés contre la plateforme

Ces clips-là montrent l'application en train de parler à la vraie plateforme Vigie-Chiro, et non à ses fixtures. Ils vivent à part, sur la pré-version clips-connectes, et cette page dit pourquoi et comment les lire.

Un lecteur vide dit « pas encore tourné », jamais « le produit est cassé »

La pré-version se peuple par un tournage, qui est manuel : tant qu'aucun tournage connecté n'a eu lieu depuis qu'un scénario existe, son lecteur reste vide. C'est la même règle que pour les deux autres pages, et PageDesClipsTest garde la correspondance entre les cas et les adresses, pas la présence des fichiers.

Une seconde cible : la plateforme de test

Un tournage connecté peut aussi viser la plateforme de test de l'ADR 5641, par l'entrée plateforme_de_test de tournage-recette.yml (#5793) : l'API Vigie-Chiro épinglée, montée par les tests eux-mêmes, sur un état de départ déclaré, sans jeton, sur Ubuntu seul. Le scénario est le même : le banc lit la cible que le profil déclare, et seuls ses cas qui ont un sens sur cette cible sont joués (recette-connectee & plateforme-de-test), aujourd'hui S8-01, S8-05, S8-06, S2-59, S2-60, S4-47, S4-90, S4-92 et S4-98.

S4-47 est le premier cas qui n'existe que là (#5795), S4-90 et S4-92 les suivants (#5796), puis S4-98 (#5836) : leurs scénarios portent en plus plateforme-de-test-seule, que le tournage national exclut et que son oracle n'attend pas.

Ses clips vont sur une pré-version à elle, clips-plateforme-de-test, et non sur clips-connectes. Leur état de départ étant déclaré, ils se comparent, et la condition que l'ADR 5641 posait est mesurée (#5797, puis #5870 avec l'instrument du flux) : deux tournages du même commit ne s'écartent pas de plus de 0,503 %, sur quinze paires par clip. Leurs planchers sont dans planchers-tournages.tsv, et la page de la comparaison dit comment les lire.

Cette pré-version est écrasée à chaque tournage de main, et la comparaison veut deux côtés. Le tournage d'avant est donc gardé : avant de verser, le job de publication recopie la pré-version sur clips-plateforme-de-test-precedent (#5854). La comparaison se lance de l'une à l'autre, avant = clips-plateforme-de-test-precedent, apres = clips-plateforme-de-test.

Seul main y verse, et un versement à la fois (#6155). Un tournage lancé sur une branche garde ses clips dans l'artefact de son exécution et ne touche à aucune des deux pré-versions : son job de versement est sauté. Elle se compare à main par numéros d'exécution (la page de la comparaison). Deux tournages de main lancés ensemble versent l'un après l'autre. À trois, GitHub ne garde qu'un versement en attente : celui qui attendait est annulé, sans rien écrire, et ses clips restent dans son artefact.

Les notes de chaque pré-version disent l'exécution et le commit qui l'ont tournée. Elles se lisent avant le rapport : deux tournages du même commit mesurent du bruit, deux commits différents mesurent ce que le second a changé. Seuls deux tournages consécutifs se comparent ainsi. Au-delà, deux exécutions se comparent par leurs numéros, tant que leurs artefacts vivent, soit quatorze jours (ADR 5930).

Ce qu'un clip connecté prouve, et qu'un autre ne peut pas

L'ADR 4142 a mesuré que sur les 360 cas de recette non couverts, environ 220 vivent dans des sessions dont l'objet est hors de l'application : le dépôt reçu par la plateforme, la nuit rapatriée du serveur, les résultats Tadarida.

Filmé contre un bouchon, un cas pareil donne un clip convaincant et creux. Il ne devient pas faux : il devient muet sur son propre objet, ce qui est pire, parce qu'on le regarde en croyant savoir.

C'est mesurable plutôt qu'affirmé. Le bouchon stub_vigiechiro.py fait 135 lignes et ne sert que la ressource sites : il n'exige aucun If-Match, ne rejette jamais un max_results au-delà de 100, et ne connaît ni les dates RFC 1123 ni le refus de numero. Le vert des scénarios d'aujourd'hui dit donc que notre client parle à notre idée de la plateforme.

Pourquoi ils ne sont pas rangés avec les autres

Un clip connecté ne se compare pas.

Son écran dépend de données vivantes. Deux tournages du même commit peuvent différer parce qu'une nuit a été traitée entre les deux, et le plancher de bruit des clips ordinaires - médiane 0,160 %, pire cas 0,979 %, mesurés par #5885 le 5 octobre 2026, l'état courant étant dans la page de la comparaison - mesurerait alors la plateforme au lieu du rendu. Le plancher par cas n'y répond pas non plus : un cas connecté aurait un bruit énorme et se retrouverait durablement en bas du classement, y compris le jour où il change pour une vraie raison.

comparer-tournages.yml refuse donc cette source, en le disant. Un outil qui accepte une source dont il ne sait rien conclure rend un résultat qui a l'air juste.

	clips-recette	le tag vX.Y.Z	clips-connectes
ce qu'on y trouve	le dernier tournage sur fixtures	le tournage de cette version-là	le dernier tournage contre la plateforme
à quoi ça sert	regarder la recette du jour	comparer, et garder une trace	regarder ce qu'un bouchon ne montre pas
se compare ?	oui	oui	non, et l'outil le refuse

Ce qu'on y trouve, et qui l'écrit

L'énumération n'est pas tenue sur cette page, et c'est délibéré : une liste écrite à la main annoncerait des clips qui n'ont pas été tournés. Elle vient de l'index.md que le tournage verse à côté de ses pièces, à chaque passage :

L'index du dernier tournage connecté

L'adresse d'un clip se déduit de son nom, comme ailleurs :

https://github.com/echonuit/vigiechiro-pr-companion/releases/download/clips-connectes/<Classe>.<test>.mp4

Les pièces ne portent aucun préfixe, contrairement à celles d'un tag de version. La séparation est portée par la pré-version elle-même : un préfixe sert à distinguer deux populations rangées au même endroit, et il n'y en a qu'une ici.

Les clips

S8-01, S8-05, S8-06 · coller le jeton, voir l'avancement, lire l'identité

S8-01 Coller le jeton : l'avancement de la récupération s'affiche. S8-05 L'avancement paraît dans la modale, sans seconde fenêtre, et « Fermer » y est grisé. S8-06 À la fin, la modale annonce l'identité et le résumé de ce qui a été récupéré.

Un seul clip pour les trois, parce que c'est un seul geste : les couper en trois referait trois fois le préambule et casserait l'histoire.

Il se déroule en quatre temps, dont trois que l'ADR 4188 exige - une modale se filme avec l'écran d'où elle part et celui où elle rend. Ici c'est le même écran, l'accueil, mais il n'y revient pas identique :

Temps	Ce qu'on voit
1 · l'écran de départ	l'accueil sans bandeau de compteurs, et le geste qui ouvre la modale
2 · la modale	le jeton collé, l'avancement, « Fermer » grisé, puis l'identité et le résumé
3 · l'écran d'arrivée	l'accueil retrouvé, où le bandeau de compteurs a paru : il suit la donnée, et une synchronisation déroulée par-dessus l'accueil s'y voit sans qu'on ait navigué (#1376)
4 · le menu rouvert	l'entrée qui nomme désormais qui est connecté

Le quatrième n'est pas exigé par l'ADR : c'est une confirmation de plus que la connexion a eu lieu, et ce qui permet de voir ses conséquences de bout en bout, sur les deux surfaces qu'elle change.

Ce qu'il montre et qu'un clip bouchonné ne montrerait pas : la progression suit une vraie latence réseau, et l'identité affichée à la fin est celle que GET /moi a rendue.

S8-02, S8-03 · la barre avance nuit par nuit, et annonce le temps restant

S8-02 La barre avance et son libellé nomme la nuit en cours (« Nuits k / N »). S8-03 Une estimation du temps restant apparaît une fois l'avancement mesurable.

Ces deux cas se produisaient pendant le clip précédent sans que rien ne les asserte. Les y laisser paraissait économique : un seul geste, un seul préambule, cinq cas cités.

C'était une erreur, et le premier tournage l'a dite. Les cinq cas n'ont pas la même condition d'existence. Se connecter s'observe toujours. Voir une barre avancer suppose des nuits à rapatrier : se connecter rejoue le rapatriement des nuits du compte (#2557), donc la durée suit ce qui reste à récupérer. Sur un compte à jour, il n'y a ni barre qui avance ni temps à estimer.

Un test ne peut pas abandonner à moitié. Abandonner le geste entier perdait donc trois cas parfaitement observables, et c'est ce qui est arrivé : zéro cas sur cinq au lieu de trois.

Deux clips au lieu d'un. Le décompte y perd, et c'est le bon prix : un geste qui n'a pas lieu ne doit pas emporter trois cas qui, eux, ont lieu.

Ce lecteur peut rester vide sans qu'aucun défaut n'existe

Le scénario déclare sa précondition plutôt que de la supposer. Quand le compte de tournage n'a plus rien à rapatrier, il abandonne en le disant, n'indexe aucun cas, et son clip n'est pas versé. Le verdict du tournage compte alors trois cas sur cinq, et c'est exact.

Pour rejouer ce geste, il faut une participation sans passage local, ou un passage réduit à un squelette.

Ce que le dernier tournage a mesuré, et qui explique sa durée :

Connexion réussie · référentiel à jour : 1 site, 199 taxons,
2 nuit(s) récupérée(s) (sur 4, dont 2 en attente d'analyse Vigie-Chiro),
4 nuits opportunistes.

S2-59, S2-60 · l'import annonce la participation, et ce qu'il reste à faire

S2-59 Connecté, importer une nuit : le compte rendu annonce une participation créée. S2-60 La même annonce dit ce qu'il reste à faire sur le portail.

Pourquoi ce clip ne peut pas être bouchonné. L'objet de ces deux cas est hors de l'application : la participation vit sur la plateforme. Contre un double, le clip affirmerait la création parce qu'on aurait fait dire au double qu'elle a eu lieu - « convaincant et creux », exactement ce que cette page mesure plus haut.

Ce clip écrit. Il crée une participation sur le compte de tournage, et doit donc viser le compte prévu pour cela, jamais un compte portant de vraies nuits.

Sa précondition. Le compte doit porter au moins un site : sans lui, il n'y a rien à quoi rattacher la nuit, et la participation ne peut pas naître. Le scénario s'arrête alors en le disant, plutôt que d'échouer comme si le produit était en cause. Sur la plateforme de test, l'état de départ la tient : l'observatrice y porte le site du carré 130711, et la participation créée disparaît avec le run.

Il attend le texte du compte rendu, pas son nœud (#5804). Le nœud paraît avant que son texte soit posé ; la nationale, lente, masquait cette course, et la plateforme de test faisait lire un compte rendu vide.

Et il l'amène dans le cadre (#5797). Au premier tournage sur la plateforme de test, le clip s'arrêtait sur le formulaire, pendant la transformation : le compte rendu était lu par le banc et jamais montré. Sa dernière image changeait donc d'un tournage à l'autre, de 19 % sur la première paire.

Ce qu'il ne prouve pas. Que la participation soit correctement remplie. « Voir la participation » l'ouvre sur le portail, et cette moitié-là se juge à l'oeil, hors du banc - la session l'annonce déjà : deux de ces cas « exigent de regarder ailleurs que dans l'application ».

S4-47 · lancer la participation, et lire l'état que la plateforme rend

S4-47 « Lancer la participation » : la carte « Traitement Vigie-Chiro » apparaît (« Analyse planifiée »).

D'où vient ce clip. De la plateforme de test, et d'elle seule : il vit sur la pré-version clips-plateforme-de-test, pas sur clips-connectes. Contre un double, « Analyse planifiée » serait ce qu'on a fait dire au double. Contre la plateforme nationale, le geste lancerait pour de bon une analyse sur un compte réel. La plateforme de test joue le vrai code serveur sur un état qu'on jette.

Ce qu'il sème. Un passage local déjà téléversé, relié à la participation nuit-a-lancer de l'état de départ, réservée à ce geste (#5794).

Ce qu'il prouve. Avant le clic, la carte ne dit rien de planifié ; après, l'étape 4 dit que l'analyse est demandée, et la carte dit « Analyse planifiée ». Sans worker, la plateforme de test en reste là, et c'est l'état que le cas décrit.

Ce qu'il ne prouve pas. Que l'analyse aboutisse : rien ne la traite sur la plateforme de test.

S4-90, S4-92 · publier une correction, puis la republier

S4-90 Après une publication menée à son terme, le compte rendu annonce les corrections envoyées sans écart « sans ancrage ». S4-92 Republier immédiatement : la publication repart sans repasser par la récupération des identifiants.

D'où vient ce clip. De la plateforme de test, et d'elle seule : il vit sur la pré-version clips-plateforme-de-test. Les deux cas demandent des corrections réellement publiées. Contre un double, on lirait ce qu'on lui a fait dire ; contre la plateforme nationale, on réécrirait les observations d'un compte réel, et une correction publiée ne se retire pas.

Ce qu'il sème. Un passage local relié à la participation nuit-traitee de l'état de départ, avec ses deux séquences. Les codes de taxon sont reliés par le rapprochement que le produit joue à la connexion, pas par un lien fabriqué.

Ce qu'il montre. L'import depuis Vigie-Chiro rend deux observations. La première est corrigée de « Pippip » vers « Barbar », le second taxon de l'état de départ (#5794), et sa certitude déclarée. La première publication annonce qu'elle rapatriera d'abord un identifiant, puis rend son compte : une correction publiée, aucun écart. La seconde ne l'annonce plus.

Ce qu'il ne prouve pas. Que le portail montre la correction : c'est S4-91, qui n'aura pas de clip. Un test le lit sans le filmer, CorrectionPublieeRelueSurLaFicheWebTest, qui publie par le service et relit le taxon et la certitude dans un navigateur (#6064). Et pour S4-92 :

Le récapitulatif de confirmation, sur lequel S4-92 se juge, est lu par le banc et ne paraît pas à l'image : le clip montre les deux publications et leur compte rendu, pas la phrase qui dit que la seconde ne rapatrie plus rien.

S4-98 · « Actualiser » importe les observations d'une analyse terminée

S4-98 Une fois l'analyse terminée côté plateforme, « Actualiser » : la carte affiche « Analyse terminée » et, dessous, les observations importées avec leur nombre. Cliquer de nouveau : la carte dit que les observations sont déjà importées, et rien n'est réimporté.

D'où vient ce clip. De la plateforme de test, et d'elle seule : il vit sur la pré-version clips-plateforme-de-test. Le geste part d'un relevé qui rend « terminée » ; contre un double, on lirait l'état qu'on lui a fait rendre.

Ce qu'il sème. Un passage local déjà déposé, relié à la participation nuit-traitee de l'état de départ, avec ses deux séquences et aucune observation en base.

Ce qu'il prouve. Avant le clic, la base est vide et la carte n'annonce rien. Après, elle dit « Analyse terminée » et « Observations importées depuis Vigie-Chiro : 2 observation(s) », et les deux observations sont en base sans être passé par « Sons & validation ». Au second clic, elle dit qu'elles sont déjà importées, et leur nombre n'a pas bougé.

Ce qu'il ne joue pas. La moitié « ligne de commande » du cas, etat-traitement-vigiechiro --importer, ni l'ouverture de « Sons & validation » : le compte en base est lu par le banc.

Ce que ces clips publient, et le compte que cela engage

S8-06 montre l'identité que la plateforme a rendue. Un clip connecté porte donc, en clair et sur une pré-version publique, le nom du titulaire du compte employé et le résumé de ce que ce compte contient - combien de sites, combien de nuits, combien en attente d'analyse.

Ce n'est pas un effet de bord : c'est exactement ce que la case demande, et un clip qui le masquerait ne montrerait plus son cas.

La décision (#4345) : le compte du mainteneur EST le compte de tournage dédié. Son nom figure déjà dans chaque commit de ce dépôt, donc la publication n'ajoute rien à ce qu'il révèle déjà de cette personne-là.

Et la propriété ne tient qu'à ce choix. Le jour où un tournage connecté emploierait le compte de quelqu'un d'autre - un étudiant, un observateur qui prête son accès - le clip publierait un nom que rien n'oblige à être public, et le résumé décrirait des données qui ne sont pas les nôtres. Poser VIGIECHIRO_TOKEN_TOURNAGE avec le jeton d'un tiers n'est donc pas un geste anodin, et rien dans le dispositif ne s'y oppose : c'est une règle, pas un garde.

Comment en produire

Le flux tournage de recette (tournage-recette.yml, workflow_dispatch), avec le drapeau connecte coché.

Il exige le secret VIGIECHIRO_TOKEN_TOURNAGE et refuse de partir sans lui : sinon il rendrait des clips d'un écran hors ligne, convaincants et muets sur leur objet.

Ce que le jeton ne peut pas atteindre

Trois barrières, et chacune tient quand la précédente a manqué.

Il paraît à l'écran, et il y meurt. Le champ du jeton est un TextField et non un PasswordField : ce qu'on y colle se lit, et le banc photographie le graphe de scène. Le scénario colle donc son jeton devant la caméra, parce qu'une modale qui se connecte toute seule ne montre pas ce qui l'a connectée, et qu'un clip incompréhensible ne remplit pas son office.

Ce qui rend cela sans conséquence est la révocation : le jeton ne vaut plus rien avant même que le clip soit regardé. Et ce n'est pas une hypothèse laissée en l'air - le versement n'a lieu que si la plateforme a confirmé le retrait (#4324). Sans confirmation, le clip n'est pas publié.

Il ne dépasse pas son pas. Posé dans l'env: d'un job, un jeton serait offert à toute la suite de tests, que ConnexionModule pointe alors sur la production. verifie_portee_des_secrets.py le refuse ailleurs qu'au pas qui filme. Et le banc lui-même lie sa propre source de jeton : un scénario qui a demandé une connexion factice reste factice, même dans un tournage connecté (ADR 4134).

Il meurt avec le run. POST /logout en fin de tournage retire ce jeton et lui seul de la carte du compte. Sans cela, sa fenêtre d'exposition serait de quatorze jours pour des clips destinés à être publiés.

Le détail de ces mesures vit dans le spike.

Ce qu'ils ne remplacent pas

Le contrat d'API (api-live.yml, hebdomadaire) éprouve le contrat et rougit quand il dérive ; un tournage connecté éprouve le parcours et produit une image. Le premier fait foi, le second se regarde. Deux dispositifs, deux objets.