Écarts entre les sources
Quand deux sources divergent, on applique l’ordre de priorité et on consigne l’écart ici, avec sa décision. Le raisonnement détaillé (sources en conflit, options écartées) reste dans l’historique git de ce fichier et dans les ADR quand il y en a une : il n’est pas recopié ici.
Un nouvel écart ajoute une ligne, décision À trancher jusqu’à ce qu’elle soit prise.
| id | sujet | décision | lot | date |
|---|---|---|---|---|
| EC-001 | Noms des applications front | Décidé : option 1, apps/backoffice et apps/terrain. |
0 | 29/09/2026 |
| EC-002 | Emplacement des ADR | Décidé : option 1, apps/docs/src/content/docs/technique/adr/. |
0 | 29/09/2026 |
| EC-003 | RG-157 fantôme | Décidé : option 1, RG-157 se lit RG-057, aucune RG-157 créée. | Cahier v1.3 | 29/09/2026 |
| EC-004 | SR-10 : écart de rendement | Décidé : option 1, −10 points, calculé à partir du rendement de référence du pack. | 2 | 29/09/2026 |
| EC-005 | SR-07 et taux du plan de contrôle (RG-026) | Décidé : option 1, taux paramétrés (5 %, 2 %, 10 % par défaut), contrôles non annoncés en sous-ensemble des ré-inspections, SR-07 réécrit. | 4 | 29/09/2026 |
| EC-006 | RG-173 contre SR-24 : échantillonnage | Décidé : option 2, 100 g par tonne pour chaque exemplaire. | 5 | 29/09/2026 |
| EC-007 | Rendements de référence par filière | Décidé : option 3, valeurs corrigées de l’analyse comme valeurs initiales « non calibrées » (alerte, pas blocage), puis calibrage. | 2, 4, 6 | 29/09/2026 |
| EC-008 | Dévalidation (RG-032) et annulation (RG-143) | Décidé : deux mécanismes distincts. Dévalidation : brouillon, numéro repris. Annulation : état définitif, numéro jamais réattribué. | 2 | 29/09/2026 |
| EC-009 | Format de la référence provisoire hors-ligne | Décidé : BR-{code appareil}-{AAAAMMJJ}-{NNNN} (compteur de l’appareil, code attribué à l’enrôlement) + UUID de commande. |
0 | 29/09/2026 |
| EC-010 | Format du numéro officiel après l’avenant | Décidé : modèle de numérotation paramétrable, format de l’avenant par défaut, préfixe entreprise en segment facultatif. | 1 | 29/09/2026 |
| EC-011 | Tolérance de bilan matière (RG-053) | Décidé : option 1, tolérance relative par produit, en centièmes de point, portée par le pack. | 2 | 29/09/2026 |
| EC-012 | Gouvernance de la capacité | Décidé : option 1, double validation direction + RSCI, auteur distinct, capacité par campagne sur surface mesurée. | 0, 1 | 29/09/2026 Appliqué en A8 : deux rôles direction et rsci, chacun une fois, par deux personnes différentes de l’auteur, tenus par la base ; capacité calculée sur la surface mesurée. |
| EC-013 | Dépassement de solde hors-ligne | Décidé : option 3, collecte acceptée et placée en file de contrôle (régularisation, déclassement ou non-conformité). | 0, 3 | 29/09/2026 |
| EC-014 | Éligibilité au groupe (RG-024) | Décidé : critères alternatifs, seuils en paramètres versionnés (m², EUR). | 1 | 29/09/2026 |
| EC-015 | Intrants dans le bilan matière (RG-050, RG-051) | Décidé : option 2, intrants en mouvements d’entrée typés, sortie ≤ entrées + intrants. | 0, 2 | 29/09/2026 |
| EC-016 | Base de paiement des producteurs (RG-191) | Décidé : option 1, humidité et réfaction sur la ligne de collecte, paiement sur le poids net marchand. | 2, 4 | 29/09/2026 |
| EC-017 | Règles induites par l’avenant, sans identifiant | Décidé : clés provisoires AV1-01 à AV1-07 (statut « nouvelle »), numéros RG attribués dans la v1.3. |
Cahier v1.3 | 29/09/2026 |
| EC-018 | Affectation des règles aux lots | Décidé : option 1, confirmée. | 1 | 29/09/2026 |
| EC-019 | Renvois, dates et couverture du cahier v1.2 | Décidé : option 1, corrections dans la v1.3, scénarios ajoutés lot par lot. | Cahier v1.3 | 29/09/2026 |
| EC-020 | Interface de programmation de TRACES NT | Décidé : option 1, pas d’intégration directe, export des données du COI. Réexamen au Lot 6. | 5 | 29/09/2026 |
| EC-021 | Fonctionnalités sans lot | Décidé : option 1, chaque fonctionnalité reçoit un lot (par défaut celui de sa règle). | 1 | 29/09/2026 |
| EC-022 | Conventions de modélisation et colonnes cree_le, modifie_le (PROPOSÉES) |
Décidé : option 1, uuid (v7), text + CHECK, timestamptz. |
0 | 29/09/2026 |
| EC-023 | Année et code de campagne (campagne.annee PROPOSÉE) |
Décidé : AA = année d’ouverture ; campagne.code unique par organisation. |
1 | 29/09/2026 |
| EC-024 | Colonnes de certification de producteur et de parcelle |
Décidé : option 1, colonnes retirées. | 1 | 29/09/2026 |
| EC-025 | Références polymorphes et statut « expiré » | Décidé : option 2 (une clé étrangère nullable par cible + CHECK) et option 3 (« expiré » calculé). |
0, 1 | 29/09/2026 |
| EC-026 | État « retiré » du statut de conformité | Décidé : option 1, « retiré » ajouté comme état distinct. | 1 | 29/09/2026 |
| EC-027 | Code de l’organisme certificateur : format et redondance | Décidé : option 1, pas de contrôle de format ; colonnes de l’organisation conservées. | 1 | 29/09/2026 |
| EC-028 | Devise des seuils d’éligibilité et des montants du producteur | Décidé : option 1, chaque montant porte sa devise ISO 4217, conversion par taux daté (XOF/EUR 655,957). | 0, 1 | 29/09/2026 |
| EC-029 | Stockage des fichiers | Décidé : option 1, stockage objet compatible S3 ; la base garde référence et empreinte (table fichier). |
0 | 29/09/2026 |
| EC-030 | Unités de surface et de rendement | Décidé : option 1, entiers : m², grammes, g/ha. | 0 | 29/09/2026 |
| EC-031 | Contraintes d’unicité proposées | Décidé : codes de campagne et de parcelle uniques ; doublon d’identité signalé, non bloquant. | 1, 3 | 29/09/2026 |
| EC-032 | Mécanisme d’isolation par RLS | Décidé : option 1, confirmée et complétée (organisation_id sur chaque table, docker-compose corrigé). |
0 | 29/09/2026 |
| EC-033 | Technologie de l’application terrain | Décidé : option 2. ADR Capacitor. | 0, 3 | 29/09/2026 |
| EC-034 | Attributs du rôle biotrace en développement |
Décidé : option 1, biotrace reste superutilisateur en développement ; en production, l’infrastructure crée l’extension puis les migrations tournent avec un rôle BYPASSRLS. |
0 | 01/10/2026 |
| EC-035 | Casse du code d’organisation | Décidé : option 1, majuscules en base (format déjà appliqué), minuscules dans Keycloak, conversion par l’API. | 0 | 01/10/2026 |
| EC-036 | Résolution de l’organisation avant la RLS | Décidé : option 1, app.organisation_par_keycloak (SECURITY DEFINER), appliquée dans le socle. |
0 | 29/09/2026 |
| EC-037 | Formules de réfaction de la pesée | Décidé : option 1, trois formules (excedent_lineaire, lineaire_simple, bilan_de_masse) dans packages/domain/pesee. Mode d’arrondi par défaut : voir EC-051. |
0 | 29/09/2026 |
| EC-038 | Catalogue des permissions et permissionRequise |
Décidé : option 1, modifiée. Une permission par type de commande, mais identifiants de permission en anglais (domaine.action), reliés aux types par une table figée dans packages/domain (« du même nom » n’est plus vrai). Commandes : producer.register, producer.update, plot.register, plot.survey, collection.record, collection.report_error, receipt.reprint, delivery.issue_note, input.issue, inspection.record, harvest.estimate, nonconformity.report ; back-office : users.manage, devices.manage, permission_sets.manage, settings.manage, capacity.approve, review.resolve, dashboard.view. Ensembles par défaut de la page Keycloak §6, ceux des lots 2 et suivants créés vides. |
0 | 01/10/2026 |
| EC-039 | Taux de change et unités mineures | Décidé : option 1, convertirMontant appliquée dans packages/domain. |
0 | 29/09/2026 |
| EC-040 | Format du contenu du QR code | Décidé : option 1, contenuQr dans packages/domain/commande. À valider avec la page de vérification (Lot 5). |
0 | 29/09/2026 |
| EC-041 | Prototype sur téléphone et critères de fin du Lot 0 | Décidé : option 2, test sur téléphone reporté (Lot 3, application terrain) ; il ne compte plus dans la fin du Lot 0. Le critère « sans perte ni doublon » reste couvert côté serveur (SP-01, SP-03, SP-04) et dans le navigateur | 30/09/2026 | |
| EC-042 | Droits du compte de service de l’API sur les organisations Keycloak | Décidé : option 2. Second client biotrace-api-organisations (manage-realm seul, secret distinct) ajouté au royaume ; tests KC dans infra/keycloak/test/. Le module identite qui l’utilise reste à écrire. |
0 | 30/09/2026 |
| EC-043 | Trace des rejets de sécurité | Décidé : option 1, table sync.rejet (migration 20260930100000). |
0 | 30/09/2026 |
| EC-044 | Type de commande inconnu | Décidé : option 1, issue acceptee_controle et motif donnees_illisibles (apps/api/src/sync/traiter-commande.ts). |
0 | 30/09/2026 |
| EC-045 | Organisation portée par le jeton Keycloak | Décidé : option 1, fonction app.organisation_par_code (migration 20260930110000). |
0 | 30/09/2026 |
| EC-046 | Brouillon public des référentiels contre le socle app |
Décidé : option 1, migrations correctives (DROP du brouillon public.*, tables recréées sous app.* séquence par séquence). Appliquée (migration 20260930120000). |
1 | |
| EC-047 | Emplacement des scénarios de recette du Lot 1 | Décidé : option 1, fonctionnel/recette/, identifiants SR-L1-xx, même front-matter que SR-01 (déjà en usage depuis A0). |
1 | 01/10/2026 |
| EC-048 | Méthode « import » des polygones | Décidé : option 1, « import » ajoutée aux valeurs de GPS-03 ; qualité lue sur la précision déclarée. | 1, 3 | 01/10/2026 |
| EC-049 | Tolérance de chevauchement des parcelles | Décidé : option 1, paramètre en m². Valeur de départ 50 m², arbitraire (aucun certificateur ne la fixe) et destinée à devenir paramétrable : amendé le 01/10/2026, plus de confirmation attendue. Appliqué en A5 : la base n’en contient aucune, app.signaler_chevauchements(version, tolerance_m2) la reçoit en paramètre, et l’API la lit dans PARAMETRES_FONCIER (apps/api/src/foncier/parametres.ts) en attendant le mécanisme de paramètres du noyau. |
1 | 01/10/2026 |
| EC-050 | Capacité des zones de cueillette | Décidé : option 1 pour le pilote (même mécanisme que les parcelles) ; option 2 (estimation par zone) à ouvrir avec le Lot 6. | 1, 6 | 01/10/2026 |
| EC-051 | Arrondi par défaut de la réfaction | Décidé : option 3 avec option 1 en valeur de départ — mode porté par contrat_ligne (arrondi au gramme le plus proche par défaut), à confirmer sur le premier contrat type d’achat. Appliqué en A7 : le mode d’arrondi est le champ arrondi de la formule portée par la ligne ; plus_proche est injecté quand la saisie ne le précise pas. |
1 | 01/10/2026 |
| EC-052 | Contenu minimal du contrat de prestation | Décidé : option 1, même structure que l’achat (contrat_ligne, unité facturée, service en texte libre), sans règle de calcul. Appliqué en A7 : une prestation va à un client ou à un fournisseur, jamais à un producteur ni à un groupement. |
1 | 01/10/2026 |
| EC-053 | Champs obligatoires des fournisseurs et des clients, certificat du fournisseur | Décidé : option 2, tous les champs du cahier v1.2 §11 obligatoires. Fournisseur : code, nom, pays, ville, adresse, telephone, email, contact (identité) ; organisme_certificateur, numero_certificat, certificat_debut, certificat_fin, certificat_fichier (certification — portée par la table certificat partagée, EC-025, pas par des colonnes propres à fournisseur, pour rester cohérent avec producteur/parcelle). Client : code, nom, pays, adresse_livraison, contact, telephone, email, incoterm_habituel, devise, conditions_reglement. Conséquence à assumer : aucune fiche fournisseur créable sans un certificat complet déjà saisi. |
4, 6 | 01/10/2026 |
| EC-054 | Niveau de détail des recettes de transformation au Lot 1 | Décidé : option 1. Recette = entrées, une sortie principale, coproduits ; le rendement n’est pas copié en base : cle_rendement désigne le jeu de règles du pack, résolu par resoudre (PC-04), et le pack fruits 1.0.0 n’en calibre aucun (valeur nulle). |
1 | 01/10/2026 |
| EC-055 | Sites et qualités autorisées d’un emplacement | Décidé : option 1, site minimal (code, nom, actif) ; qualites_autorisees en texte libre non contrôlé jusqu’à A6. |
1 | |
| EC-056 | Troisième langue (EX-076) contre la base et Keycloak | Décidé : option 1, CHECK assoupli en ^[a-z]{2,3}$, langues lues dans packages/i18n. Application de la migration reportée à l’ajout réel d’une troisième langue. |
0 | 01/10/2026 |
| EC-057 | Format de date en anglais | Décidé : option 1, en-GB (JJ/MM/AAAA, identique au français). |
0 | |
| EC-058 | Espace entre nombre et unité | Décidé : option 1, U+00A0 entre nombre et unité ; séparateurs de milliers laissés à Intl. |
0 | |
| EC-059 | Statut de l’utilisateur : back-office et synchronisation | Décidé : option 2, refusé aux routes du back-office (permission) ; jugé par la synchronisation (droit_manquant) hors-ligne. |
0 | |
| EC-060 | Portée de la révocation d’un appareil chez Keycloak | Décidé : option 1, révocation du consentement agent pour biotrace-terrain (ses autres téléphones doivent se reconnecter). |
0 | |
| EC-061 | Échec de création d’une organisation : où le tracer | Décidé : option 1, échec tracé dans les journaux applicatifs seulement. | 0 | |
| EC-062 | Protection du dernier administrateur et auto-désactivation | Décidé : option 2, appliquée (utilisateurs.service.ts, POST /v1/utilisateurs/{id}/desactiver refuse l’auto-désactivation et la désactivation du dernier détenteur de users.manage, codes auto_desactivation_refusee et dernier_administrateur). |
0 | 01/10/2026 |
| EC-063 | Format du code produit | Décidé : option 1, ^[A-Z0-9]{2,10}$ (comme le code d’organisation). |
1 | |
| EC-064 | Attributs et bornes de l’ananas (pack fruits 1.0.0) | Décidé : option 1, calibre 1 à 99, brix_dixiemes 0 à 300, non obligatoires, à valider avec les transformateurs. |
1 | |
| EC-065 | Facteurs dynamiques (produit, referentiel) |
Décidé : option 1, facteurs dynamique sans valeurs globales (codes pris dans le pack). |
1 | |
| EC-066 | Routes REST manquantes pour les écrans de la piste B | Décidé : option 1, la piste A écrit GET /v1/moi, GET /v1/campagnes, GET /v1/controles et POST /v1/controles/{id}/lever avant que B2 ne démarre. Appliqué le 01/10/2026 (voir EC-071). |
0, 1 | |
| EC-067 | Moment d’écriture du thème react-jsonschema-form « Registre » | Décidé : option 1, avec l’utilisateur, le 01/10/2026 | 01/10/2026 | |
| EC-068 | Codes de nature du numéro officiel et source du préfixe entreprise | À trancher. Les sources divergent : MP, REC, NET, PF (cahier v1.2 §5.10, retenus en A3 par un CHECK) ; « COL » dans les valeurs des vecteurs VT-NUM, dont la description dit « collecte ». Les vecteurs sont illustratifs. À confirmer. Le préfixe entreprise (EC-010) n’a aucune colonne source : inactif par défaut, sa valeur reste à placer (organisation ou segment du modèle) avant qu’un modèle l’active. |
1, 2 | 01/10/2026 |
| EC-069 | Où stocker les seuils d’éligibilité au groupe (RG-024, EC-014) | Décidé : même traitement qu’EC-049, le 01/10/2026. Le mécanisme de paramètres (PC-01 à PC-08) n’a que deux couches, organisation et pack, et app.parametre exige un utilisateur auteur : il n’existe pas de valeurs par défaut du noyau. Les seuils du cahier (5 ha, 0,5 ha, 15 ha, 25 000 EUR, 2 %) sont donc des valeurs par défaut nommées dans le code, SEUILS_ELIGIBILITE_PAR_DEFAUT (apps/api/src/acteurs/parametres.ts), que l’appelant peut surcharger ; la base n’en contient aucune. Quand le mécanisme de paramètres du noyau existera, ces constantes et celle d’EC-049 migrent ensemble. |
1, 4 | 01/10/2026 |
| EC-070 | Taux de change en base contre taux du domaine | Décidé et appliqué en A7, le 01/10/2026 : app.taux_change garde le taux publié en unités majeures (1 EUR = 655,957 XOF, 655957/1000), auditable. Le domaine l’adapte aux unités mineures avec les décimales de chaque devise (app.devise, devises.tauxUnitesMineures : EUR → XOF donne 655957/100000, comme VT-ENT-015) et choisit le taux daté (devises.choisirTaux). Les commentaires de taux_change le disent. Aucune ligne de la base n’a changé. |
0, 1 | 01/10/2026 |
| EC-071 | Droits et décisions de la file de contrôle (protocole §9) | À trancher. Le §9 distingue RSCI, administrateur et support par motif, mais EC-038 n’a qu’une permission (review.resolve) : une seule permission lève tous les motifs. Les décisions « valeur retenue » et « pièce fournie » sont rapprochées de correction, faute de valeur dédiée en base. Les motifs intrant_non_autorise, conflit_interets et parametre_introuvable n’ont aucune décision au §9 : leurs contrôles ne peuvent pas être levés. |
1, 4 | 01/10/2026 |
| EC-072 | Un statut de certificat n’est pas daté | À trancher. certificat.statut (valide, suspendu, retire) n’a pas de date d’effet : une suspension ou un retrait vaut pour toute date, y compris pour une opération passée, alors qu’« expiré » se calcule à la date de l’opération. Une vente antérieure à un retrait serait donc jugée comme faite sous un certificat retiré. Le journal d’audit garde la trace de la modification. À dater (période de suspension, ou historique en ajout seul comme statut_conformite) avant le Lot 2, où les ventes s’appuient sur ce verdict. |
1, 2 | 01/10/2026 |
| EC-073 | Formule de réfaction par défaut du produit | À trancher. L’analyse critique dit que la réfaction « est lue sur le contrat, puis sur le produit à défaut », mais app.produit n’a aucune colonne de formule et le cahier ne la définit pas par produit. A7 ne l’invente pas : la formule vit sur la ligne du contrat, et une réception sans contrat (« spot ») n’a pas de formule. À trancher avec le Lot 2, qui lit la réfaction. |
1, 2 | 01/10/2026 |
| EC-074 | Rendement agricole sans valeur par défaut du pack | À trancher. Une capacité exige un rendement en g/ha. Le jeu de règles rendement.reference du pack est un rendement de transformation (centièmes de point), vide (EC-007), et l’API n’appelle jamais resoudre : il n’existe pas de chargeur de couches de paramètres. A8 historise donc un rendement saisi par parcelle, avec motif (RG-023), et refuse la capacité sans valeur (rendement_inconnu). Une valeur par défaut issue du pack (clé et facteurs de résolution produit, region, type_sol, mode_culture, portés par la parcelle depuis A5) attend le mécanisme de paramètres du noyau (EC-069). |
1, 4 | 01/10/2026 |
| EC-075 | Rôle de validation lié au code de l’ensemble de permissions | À trancher. direction et rsci portent la même permission capacity.approve (EC-038) : le rôle d’une validation de capacité se prouve par le code de l’ensemble que le validateur détient. Une organisation qui renomme ou remplace ces ensembles n’ouvre plus le rôle. À remplacer par un attribut de rôle explicite sur l’ensemble de permissions ou par une permission par rôle, avant le premier client réel. |
1 | 01/10/2026 |
| EC-076 | Format des règles de synchronisation : bucket_definitions ou sync streams |
Décidé le 01/10/2026 : bucket_definitions (protocole §7.2), le format que le prototype a validé avec le service réel (PowerSync 1.26.1) ; les règles définitives sont dans infra/powersync/sync-config.yaml. PowerSync recommande désormais les « sync streams » : la migration reste à décider quand le service l’exigera ; le contrat des colonnes descendues (infra/powersync/contrat-donnees.json) est indépendant du format. |
0, 1, 3 | 01/10/2026 |
| EC-077 | Colonnes générées non répliquées avant PostgreSQL 18 | Décidé le 01/10/2026 : PostgreSQL 16 ne réplique pas les colonnes générées stockées, donc PowerSync ne les voit pas. Les règles n’en sélectionnent aucune (un test l’exige) et le téléphone les calcule : reste_g = capacite_g − consomme_g, incertitude_m2 = périmètre_m × précision_mediane_cm / 100 (arrondi au plus proche). capacite_g (capacité), annee (campagne) et numero_piece_normalise ne descendent pas. À revoir à la montée vers PostgreSQL 18. |
0, 1, 3 | 01/10/2026 |
| EC-078 | La capacité « applicable » n’est pas visible du téléphone | À trancher avec le Lot 3. app.capacite_applicable (validée, sur le polygone en vigueur, cible éligible, producteur hors contrôle) se juge sur le serveur ; le téléphone reçoit le solde d’une capacité validée, même si un nouveau relevé du polygone l’a rendue inapplicable. Le serveur la juge au traitement de la collecte (motif de contrôle à choisir au Lot 3 : capacite_depassee, EC-013, ou un motif dédié) ; l’application peut afficher un avertissement en comparant la version du polygone du solde à la plus récente reçue. |
1, 3 | 01/10/2026 |
| EC-079 | Sens de « effet bloquant » d’un contrôle | À confirmer. Le protocole §9 demande un tri « par ancienneté et par effet bloquant » sans définir l’effet. Retenu en B2 : un contrôle est bloquant quand sa commande n’a pas été écrite (donnees_illisibles, version_client_obsolete, empreinte_incoherente, protocole §6.3), calculé par controle.effetBloquant du domaine et rendu par l’API (bloquant, contrat 1.1.0). Les autres motifs laissent la commande écrite et l’entité « en anomalie » ; le tableau du §9 cite aussi des effets plus larges (« paiement de la collecte bloqué »), qui attendent les lots qui les portent. |
1 | 01/10/2026 |
| EC-080 | Mise en ligne du back-office : origine, CORS et Keycloak | Décidé le 03/10/2026 (ADR 0044). Le back-office est servi par Cloudflare Pages et l’API par Kubernetes : deux origines. L’API gère le CORS : CORS_ORIGINES liste les origines autorisées par environnement, les en-têtes admis sont Authorization, Content-Type et X-Organisation. Variable vide en développement : le serveur Vite relaie /v1, une seule origine. @fastify/cors est déjà une dépendance de @nestjs/platform-fastify : aucune dépendance nouvelle. Keycloak : seules VITE_KEYCLOAK_URL, VITE_REALM et BACKOFFICE_URL changent par environnement ; HTTPS et nom d’hôte propre obligatoires. Les jetons restent en mémoire : un rechargement repasse par Keycloak. |
0, 1 | 03/10/2026 |
| EC-081 | Fond de carte des parcelles | À trancher avec l’hébergement. B3 affiche les polygones sur fond uni (ADR 0041). Un fond de tuiles demande un fournisseur, ses conditions d’usage et, pour le terrain hors ligne, des tuiles embarquées (Lot 3). | 1, 3 | 01/10/2026 |
| EC-082 | Création et ouverture d’une campagne depuis le back-office | Droit ajouté au catalogue le 02/10/2026 (L1-6, étape 1), à confirmer : campaigns.manage (administrateur client). Routes d’écriture non livrées en L1-6 (voir EC-112). Reste ouvert : La table campagne tient les règles (code unique, version de pack figée à l’ouverture, « AA » calculé), mais aucun service d’API ne crée ni n’ouvre de campagne : l’écran B3 est en lecture. Une action d’interface demande un service, ses droits (aucune permission du catalogue EC-038 ne la couvre) et une route. |
1 | 01/10/2026 |
| EC-083 | Édition des produits et des attributs depuis le back-office | Droit ajouté au catalogue le 02/10/2026 (L1-6, étape 1), à confirmer : products.manage (administrateur client). Routes d’écriture non livrées en L1-6 (voir EC-112). Reste ouvert : Les produits viennent d’un pack chargé (A2) et sont « modifiables » selon la page de la séquence, mais aucun service d’API ne les crée ni ne les modifie, et aucune permission du catalogue (EC-038) ne le couvre. L’écran B3 est en lecture et aperçu de formulaire. |
1 | 01/10/2026 |
| EC-084 | Place des écrans « Numérotation » et « Capacités » dans la navigation | À trancher. La structure du design system §7 n’a d’entrée ni pour la numérotation ni pour les capacités. Placées sous Référentiels en B3, à déplacer si le design system les range ailleurs (Administration > Paramétrage pour la numérotation ; Conformité ou Pilotage pour les capacités). | 1 | 01/10/2026 |
| EC-085 | Écritures de la conformité depuis le back-office | Droit ajouté au catalogue le 02/10/2026 (L1-6, étape 1), à confirmer : certification.manage (RSCI). Routes livrées le 02/10/2026 (L1-6, étape 2) : POST /v1/conformite/statuts et POST /v1/fournisseurs, toutes deux sous certification.manage. Un droit unique couvre les deux ; à confirmer. Reste ouvert : Les services de A6 saisissent un fournisseur avec son certificat (EC-053) et révisent un statut de conformité avec motif (RG-150), mais le catalogue des permissions (EC-038) n’a aucun droit pour gérer les certificats ou la conformité, et l’on n’en invente pas. L’écran B3 est en lecture, avec synthèse et verdict. Il faut décider de la permission (une ou deux) et du rôle qui peut réviser un statut avant d’ouvrir les routes. |
1 | 01/10/2026 |
| EC-086 | Création et activation d’un contrat depuis le back-office | Droit ajouté au catalogue le 02/10/2026 (L1-6, étape 1), à confirmer : contracts.manage (commercial). Routes livrées le 02/10/2026 (L1-6, étape 2) : POST /v1/contrats (brouillon) et POST /v1/contrats/{id}/activer (brouillon seulement), sous contracts.manage. Pas de validation à deux personnes ; formule de réfaction par défaut si absente (EC-073) ; à confirmer. Reste ouvert : enregistrerContrat (brouillon, lignes, primes) et activerContrat existent, mais le catalogue des permissions (EC-038) n’a aucun droit pour gérer les contrats, et une activation fige le contrat (lignes et primes ne changent plus). L’écran B3 est en lecture. Il faut décider du droit, de la validation éventuelle à deux personnes et de la saisie de la formule de réfaction (EC-073 : formule par défaut). |
1 | 01/10/2026 |
| EC-087 | Proposition d’une capacité et saisie d’un rendement depuis le back-office | Droit ajouté au catalogue le 02/10/2026 (L1-6, étape 1), à confirmer : capacity.propose (inspecteur ; distinct de capacity.approve). Routes livrées le 02/10/2026 (L1-6, étape 2) : POST /v1/rendements et POST /v1/capacites, toutes deux sous capacity.propose (un seul droit pour fixer un rendement et proposer) ; la validation reste à capacity.approve. À confirmer. Reste ouvert : proposerCapacite et definirRendement (motif obligatoire, RG-023) existent en services ; le catalogue des permissions (EC-038) n’a que capacity.approve, droit de valider. Le donner à qui propose violerait la séparation des tâches (l’auteur ne valide pas) ; il faut une permission de proposition et une pour fixer un rendement, et le choix du rôle qui le fait. |
1 | 01/10/2026 |
| EC-088 | Rang de la note d’amendement dans l’ordre des sources | Décidé le 02/10/2026 : rang 0, au-dessus du découpage, une fois relue par l’équipe. Relue le 02/10/2026 : décisions AM-01 à AM-17 au statut « Décidé ». Elle remplace les sections de la note d’analyse critique sur les archétypes, les quatre couches et le moteur de combinaison (Q8 ; docs-sources/ restant en lecture seule, le renvoi est consigné ici). Plan : alignement. |
0 à 7 | 02/10/2026 |
| EC-089 | referentiel propre à chaque organisation (A6) contre référentiel global (AM-06) |
Appliqué le 02/10/2026 (L1-1+2) : app.referentiel est le catalogue global, app.organisation_referentiel la table des référentiels cochés (EC-101). Décidé le 02/10/2026 : catalogue global referentiel, alimenté par les packs référentiels (états de qualité, grilles) ; table organisation_referentiel pour les référentiels cochés (RG-301), datée, avec auteur. Certificats et statuts pointent vers le catalogue ; reprise du jeu de démonstration. À appliquer en L1-2. |
1 | 02/10/2026 |
| EC-090 | Couleur d’un état de qualité fourni par le référentiel (AM-16) | Appliqué le 02/10/2026 (L1-1+2) : STATUTS_QUALITE indexé par catégorie ; « hors statut » reprend le neutre du conventionnel, avec le symbole ⊘ et une bordure double. Décidé le 02/10/2026 : chaque état porte une catégorie d’affichage fermée (bio, conversion, conventionnel, hors_statut) ; TamponQualite et les jetons dépendent de la catégorie, jamais de l’état. Le vert reste réservé à bio. À appliquer en L1-1. |
1 | 02/10/2026 |
| EC-091 | Constat (AM-15) et file de contrôle (sync.controle, EC-013) |
Décidé le 02/10/2026 : deux objets distincts. La file garde les motifs techniques de synchronisation ; le constat enregistre l’écart à une règle métier ou réglementaire. Une issue « acceptée en file de contrôle » crée les deux, le constat référençant l’entrée de la file (clé facultative). À appliquer en L0-4. | 0, 2, 3 | 02/10/2026 |
| EC-092 | Langue des permissions : la note écrit collecte.creer, EC-038 a retenu l’anglais |
Décidé le 02/10/2026 : identifiants anglais (EC-038). Précisé le 02/10/2026 (L0-3) : le préfixe d’une permission désigne un domaine (collection, plot), pas le code du module (collecte, membres_foncier) ; chaque manifeste de module liste ses permissions. Libellés en français par packages/i18n. Il n’y a pas d’« alias français » au catalogue : collecte.enregistrer et les autres sont les noms des types de commande du protocole (§4.1), reliés chacun à leur permission. |
0 | 02/10/2026 |
| EC-093 | Certificat expiré : critère de fin n° 3 du Lot 1 contre P1 (signaler plutôt que bloquer) | Décidé le 02/10/2026 : la revendication reste bloquée (une action, AM-09 ; critère n° 3 inchangé). La réception sur certificat expiré (RG-014) devient une règle de processus réglable : blocage par défaut, option « enregistrer avec preuves renforcées » (fournisseur exempté NOP). Première entrée de la liste Q5 ; à reporter au cahier v1.3 (Q7). | 1, 2 | 02/10/2026 |
| EC-094 | Droit d’activer les modules et les activités : la note dit « la direction », le catalogue EC-038 n’a que settings.manage (administrateur client) |
Décidé le 02/10/2026 : nouveau droit modules.manage, donné par défaut aux ensembles direction et administrateur_client. Appliqué en L0-2. |
0 | 02/10/2026 |
| EC-095 | Dépendances et conditions de proposition des modules non écrites dans la note | Décidé en partie le 02/10/2026 (L0-3) : collecte → membres_foncier ajoutée (manifestes, migration L0-3). Le reste attend le Lot 4. Rappel de l’état initial : seules sci → membres_foncier et paiements → collecte sont écrites et appliquées (L0-2). À confirmer : collecte → membres_foncier (collecte auprès de membres sans fiches membres ?), planification et intrants_avances → collecte ou membres_foncier. Conditions non modélisées : le SCI n’est proposé que « si certification de groupe », l’EUDR que « si le produit est concerné ». Rappel Q1 : les types de sous-activité et d’étape du catalogue attendent l’avis de l’organisme de certification. |
0, 1 | 02/10/2026 |
| EC-096 | Commande du terrain pour un module inactif | Décidé le 02/10/2026 (L0-3) : nouveau motif de contrôle module_inactif. La commande est conservée et mise en contrôle sans écriture métier (comme donnees_illisibles) ; décision de levée reprise_manuelle. L’état du module est apprécié à la date d’opération (app.module_actif_a), comme les droits à l’étape 9 : un fait saisi pendant que le module était actif n’est pas mis en contrôle. Un fait n’est jamais rejeté. |
0, 3 | 02/10/2026 |
| EC-097 | Rattachement des contrats, de la file de contrôle et de l’estimation de récolte | Décidé le 02/10/2026 (L0-3) : les contrats (achat, vente, prestation : un tiers quelconque) et la file de contrôle relèvent du noyau ; harvest.estimate relève du SCI, avec l’ensemble « inspecteur ». |
0 | 02/10/2026 |
| EC-098 | Constat d’écart et livret : ce que la note laisse ouvert | Appliqué provisoirement le 02/10/2026 (L0-4), à confirmer. (1) La note veut « valeur constatée, valeur attendue, écart » pour chaque constat ; une condition CEL quelconque n’a pas de valeur attendue unique : seules les lignes qui déclarent une mesure (variable constatée, paramètre attendu) les portent, les autres gardent les valeurs lues. (2) constat n’a pas de groupement_id : il ne descend pas sur le téléphone avant le Lot 3, qui l’ajoutera. (3) Résolu le 02/10/2026 (L1-1+2) : le livret se filtre sur les référentiels cochés et actifs (app.organisation_referentiel). (4) Un paramètre cité par une ligne mais absent du pack référentiel n’est pas refusé à la publication (il peut venir d’une autre couche) ; à l’évaluation, il donne un constat « à vérifier ». |
0, 1, 3 | 02/10/2026 |
| EC-099 | Rôles de l’équipe BioTrace : la note (AM-14) prévoit rédacteur, relecteur, publieur et support, avec une séparation rédacteur / relecteur vérifiée par la base | Décidé le 02/10/2026 (L0-5) : BioTrace est l’éditeur, on n’audite pas son équipe. Trois rôles génériques du super back-office, qui paramètre l’application en global ou pour un client : editeur_admin (super administrateur, tous les droits, passe toutes les gardes de rôle éditeur), editeur_parametrage (packs, catalogues, publication), editeur_support (assistance et paramétrage d’un client, ouverture des comptes clients). Aucune séparation des tâches au sein de l’équipe éditeur, aucune signature des packs en base. Création d’organisation : support ou administrateur. À venir : l’accès journalisé de l’éditeur à un client (RG-309) et la garde de l’atelier de publication par editeur_parametrage (lots 6 et 7). La séparation des tâches chez les clients (EC-012, SB-11) n’est pas touchée. |
0 | 02/10/2026 |
| EC-100 | États de qualité du NOP | À trancher. La note donne les états de l’UE (bio, conversion A2+, conversion A1, conventionnel), pas ceux du NOP. Sur décision du 02/10/2026, le pack packs/referentiels/nop/1.0.0.json reprend provisoirement la liste de l’UE, libellée « à confirmer », pour que les statuts NOP existants restent valides. À remplacer par la liste du NOP (avec les catégories d’étiquetage, calculées par un indicateur, AM-16) dans une nouvelle version du pack. |
1 | 02/10/2026 |
| EC-101 | Passage au référentiel global sans réécrire les données | Décidé le 02/10/2026 (L1-1+2) : l’ancienne table par organisation est renommée app.organisation_referentiel, ses identifiants sont conservés ; certificat.referentiel_id et statut_conformite.referentiel_id gardent leur nom et désignent le référentiel coché par l’organisation. Son code est une clé étrangère vers le catalogue app.referentiel (global), dont les états viennent du dernier pack publié (app.etats_referentiel). Les codes déjà cochés sont entrés au catalogue par la migration, sans pack. |
1 | 02/10/2026 |
| EC-102 | Catégories de produits de la portée du certificat (AM-07) : la note les cite, le catalogue produit n’a aucune catégorie |
Appliqué provisoirement le 02/10/2026 (L1-1+2, partie B), à confirmer. Les produits sont listés un à un dans certificat_portee (dimension produit). Une catégorie (frais, transformé…) exigerait une colonne de produit et une version du pack fruits ; à décider quand un référentiel en aura besoin. |
||
| EC-103 | Portée du certificat : ce que la note laisse ouvert | Appliqué provisoirement le 02/10/2026 (L1-1+2, partie B), à confirmer. (1) Un certificat sans aucune ligne de portée a une portée non renseignée : aucun écart n’est calculé contre lui, il est signalé. (2) Un certificat qui a des lignes mais aucune activité incluse ne couvre aucune activité. (3) Une activité déclarée sans site (toute l’organisation) n’est pas restreinte par les sites du certificat ; une activité déclarée pour un site doit voir ce site inclus et non exclu quand le certificat liste des sites. (4) Sans certificat en vigueur il n’y a pas d’écart de portée : le verdict de revendication dit déjà certificat_absent. (5) Les dimensions produit et unité sont stockées mais ne servent pas encore : elles serviront à la revendication d’un lot (Lot 2). (6) La portée est en ajout seul et reste dans le back-office : elle ne descend pas sur le téléphone avant L1-5. |
||
| EC-104 | Grille de conformité (L1-3) : ce que la note laisse ouvert | Appliqué provisoirement le 02/10/2026, à confirmer. (1) Le thème d’un point (tableau « prêt pour l’audit » par thème) est un texte libre fourni par le pack : la note ne définit pas de catalogue de thèmes. (2) L’échéance d’un point est stockée en texte, non évaluée avant un besoin avéré. (3) « Non applicable » se calcule (point hors dates, module inactif, aucune activité du point exercée) et ne se stocke pas ; seul un « non applicable » déclaré par une personne, avec motif, est une évaluation. (4) « Preuve manquante » se déduit des pièces liées : une personne ne le déclare pas, et déclarer « satisfait » sans pièce donne « preuve manquante » plutôt qu’un refus. (5) Le mode automatique lit le résultat d’une règle du moteur ; le contexte de l’accroche periodique.quotidien (variable portee.nombre_ecarts) est construit par l’API en partie B de L1-3. (6) Les tables point_controle, evaluation_point, preuve ne descendent pas sur le téléphone avant L1-5. |
1 | 02/10/2026 |
| EC-105 | Points de grille UE du pilote : sources et date d’effet | Appliqué provisoirement le 02/10/2026, à confirmer. Le registre Excel des 957 exigences (AM-17) n’est pas dans le dépôt et la note interdit de publier une ligne non relue. Le pack ue 1.1.0 ne reprend donc que cinq points tirés du cahier v1.2 §1.6 (articles 34, 36, 39 §1 d, 32 du règlement (UE) 2018/848) et de la note (écart de portée, AM-07). La date d’effet 2022-01-01 (application du règlement) ne figure pas dans les sources du dépôt : à confirmer. Le point de groupe (article 36) est manuel : sa condition d’éligibilité automatique (RG-024) reste à exprimer comme règle. |
1 | 02/10/2026 |
| EC-106 | Grille CCPB : aucune source dans le dépôt | À trancher : fournir les exigences CCPB (ou l’extrait du registre) avant de créer le pack ccpb. Le plan d’alignement prévoit « quelques points UE et CCPB » ; le dépôt ne cite CCPB que comme nom d’organisme, sans exigence ni états de qualité. Aucun pack CCPB n’est créé : le publier exigerait d’inventer ses états de qualité et ses points (PC-07). |
1 | 02/10/2026 |
| EC-107 | Permission des écritures de la grille (L1-3, partie B) | Appliqué provisoirement le 02/10/2026, à confirmer. Évaluer la grille, déclarer un point et lier une pièce exigent review.resolve, comme la levée d’un contrôle : ce sont des décisions de la personne (RG-308). Aucune permission du catalogue ne les nomme ; une permission dédiée (par exemple compliance.assess) demanderait de toucher aux ensembles par défaut et à VT-DROITS, à décider quand un rôle d’auditeur interne sera défini. Un point est identifié par referentiel + code dans le corps (le code n’est unique que dans une grille), non par un chemin /points/{code}/evaluation comme le plan le laissait entendre. |
1 | 02/10/2026 |
| EC-108 | Types d’activité des niveaux 2 et 3, et contenu de l’arbre du pack fruits 1.1.0 (Q1 de la note, non validée avec l’organisme de certification) | Appliqué provisoirement le 02/10/2026 (L1-4), à confirmer. Six types sont posés dans app.activite (pesee_collecte, stockage_frais, preparation_fruits, calibrage, emballage, chargement_conteneur), marqués provisoire : le code reste stable, le libellé et le rangement peuvent changer. Le caractère obligatoire, critique et sous-traitable de chaque nœud de l’arbre ananas (pack 1.1.0) est une hypothèse de travail, sans source dans le dépôt. La fumigation, la sous-traitance et le transport de la Q1 n’ont aucun nœud. Un type de niveau 2 ou 3 n’est lié à son parent du catalogue que par parent_code : le pack peut rattacher une instance sous n’importe quel parent de niveau inférieur. |
1 | 02/10/2026 |
| EC-109 | RG-300 « profil à l’ouverture » : aucune définition de profil dans les sources | Appliqué provisoirement le 02/10/2026 (L1-4), à confirmer. La note dit que le profil est un préréglage de l’arbre ; ni la note, ni le cahier du dépôt ne définissent de profil. Le préréglage est donc l’arbre par défaut du pack, que l’opérateur décoche (POST /v1/arbre-activites/initialiser, liste facultative de nœuds) ; aucun profil nommé n’est inventé. |
1 | 02/10/2026 |
| EC-110 | Arbre d’activités : ce que la note laisse ouvert | Appliqué provisoirement le 02/10/2026 (L1-4), à confirmer. (1) Un nœud de premier niveau n’a pas de parent : il se désactive même s’il est obligatoire ; le garde-fou « obligatoire ou critique » ne vaut qu’aux niveaux 2 et 3. (2) La cascade écrit une ligne « désactivée » par descendant encore actif, avec le motif « Désactivation en cascade de … » ; la réactivation du parent ne réactive rien. (3) Un site peut désactiver un nœud que l’organisation a activé : l’état courant se lit sur la ligne du site, sinon sur celle de l’organisation. (4) À l’ouverture du compte, un nœud obligatoire ou critique ne peut pas être laissé de côté sous un parent activé. (5) L’état « actif » est apprécié à l’instant de la base, pas à celui de l’API. (6) La portée des certificats ne compte que les activités de premier niveau. (7) Non fait : « les points de grille liés à un nœud désactivé deviennent non applicables » ; les points citent des activités par leur code, et un point se lie à un type, pas à un nœud : il suit l’activité de son type, comme en L1-3. | 1 | 02/10/2026 |
| EC-111 | L1-5 : ce que l’écran « Activités » et la synchronisation par module laissent ouvert | Appliqué provisoirement le 02/10/2026 (L1-5), à confirmer. (1) L’écran « Activités » est visible de tout utilisateur connecté en lecture ; le changement d’état exige modules.manage (EC-094, EC-107 ouvert). (2) Aucune route ne rend l’identité de la filière chargée : l’intitulé vient de la dernière campagne qui l’a figée, sinon d’un libellé générique ; une route dédiée serait un ajout mineur (1.17.0). (3) Le contrat d’API reste 1.16.0 : aucune route ajoutée. (4) Contrat de données : colonnes inchangées, son numéro reste 1 ; seule la répartition en compartiments change (nouveau compartiment module_membres_foncier). (5) Seul Membres et foncier a des tables descendues ; Collecte et SCI n’en ont pas encore : aucun compartiment inventé. statut_conformite reste dans le périmètre de l’agent (c’est du noyau). (6) Aucune infrastructure de test de composants dans le back-office : la mise en forme de l’écran est une fonction pure testée par vitest, la vérification visuelle se fait dans le navigateur. (7) Les fonctions (modules) d’une activité se lisent par propose_par (AM-05) ; la correspondance fine entre un nœud de niveau 2 ou 3 et une fonction n’est pas décrite par la note. |
2 | 02/10/2026 |
| EC-112 | L1-6, étape 2 : ce que les routes d’écriture laissent ouvert | Appliqué provisoirement le 03/10/2026, à confirmer. (1) Ni campagnes (campaigns.manage) ni produits (products.manage) n’ont de route : l’ouverture d’une campagne fige la version de pack et le modèle de numérotation, la création d’un produit dépend des modèles du pack ; aucun scénario SR-L1 ne les exige, le jeu « ananas Togo » les charge par la démonstration. Les droits existent, les routes restent à écrire. (2) Les commandes producteur.enregistrer, producteur.modifier, parcelle.enregistrer et parcelle.relever sont déclarées au manifeste Membres et foncier, mais aucun gestionnaire n’existe encore : producteurs et parcelles de la recette sont posés par la connexion des migrations (Lot 3). (3) SR-L1-05 (refus d’un rattachement à une collecte, RG-012) ne peut pas être rejoué : collecte.enregistrer est du Lot 3 ; seul l’état de départ (producteur sans parcelle) est vérifié. (4) Un contrat sans ligne ne se crée pas par la route (la forme exige au moins une ligne) : le refus d’activation sans ligne reste couvert au niveau du service. (5) Activer un contrat déjà actif est refusé par la route (activation_refusee) alors que la base l’accepte ; choix de la route. (6) Un refus de la base (contrainte, déclencheur) devient contrat_refuse, statut_refuse ou fournisseur_refuse (409) avec le message de la base en détail : le code est volontairement générique. |
1 | 03/10/2026 |
| EC-113 | Lot 2 : ce que le découpage et la note laissent ouvert avant L2-1 | À trancher, appliqué provisoirement le 03/10/2026 (L2-0). (1) Décidé le 03/10/2026 (L2-3) : le pack fruits 1.2.0 ajoute le procédé « Séchage de l’ananas » (tri, découpe, séchage au four, contrôle d’humidité) ; ses types d’étape sont provisoires, à valider avec l’organisme (EC-108). (2) Durée avant qu’un en-cours devienne lot (TRA-01) : toujours ouvert, valeur à fournir ; aucun modèle d’en-cours n’est livré en L2-3 (un produit intermédiaire est un lot de l’étape qui le produit) ; la règle s’ajoutera avec sa valeur. (3) Décidé le 03/10/2026 (L2-2) : deux règles de processus à issue réglable en L2-2, le certificat non en vigueur (RG-014) et le dépassement des seuils d’acceptation (RG-172) ; la capacité d’un emplacement reste un signalement (EC-115) ; I5 est intangible. (4) Le parcours navigateur de la recette du Lot 1 est reporté « à un lot ultérieur » : le faire dans L2-8 ou le sortir ? | 2 | 03/10/2026 |
| EC-114 | RG-014 (« une certification expirée bloque la réception ») contre D6 / EC-093 (la réception devient une règle de processus réglable) | Décidé le 03/10/2026 (L2-2) : la proposition est retenue. La page RG-014 est au statut v1.2 et dit « bloque » avec dérogation de la direction ; EC-093 la rend réglable (signaler avec note ou bloquer). RG-014 passe au statut corrigee-v1.3, mode par défaut « bloquer » (comportement v1.2 conservé), réglable par organisation. Mis en œuvre en L2-2 avec la mise à jour de la page. |
2 | 03/10/2026 |
| EC-115 | Lot 2, L2-1 : lots, déplacements et stock | À trancher, appliqué provisoirement le 03/10/2026 (L2-1). (1) La quantité d’un lot (quantite_totale, quantite_disponible du cahier) est calculée depuis le solde de son compte (vue lot_solde), jamais stockée : une seule source de vérité (I1). (2) I4 : lot.mouvement_creation_id est obligatoire ; la base vérifie à la validation de la transaction que le compte est de nature lot et que le mouvement n’est pas une contre-passation et crédite ce compte. (3) Un déplacement entre emplacements est un événement en ajout seul (deplacement_lot), pas un mouvement de matière ; l’emplacement courant est le dernier déplacement (pas de colonne emplacement sur le lot, écart au plan L2-0). (4) La capacité de l’emplacement signale et ne refuse pas (aucune source ne dit « refuser » ; même logique que RG-022) ; la qualité refuse (RG-154). Liste qualites_autorisees vide = aucune restriction. (5) Matrice des statuts déduite des huit statuts du cahier, aucune table de transitions dans les sources : brouillon → en_attente, annulé ; en_attente → validé, rejeté, annulé ; validé → consommé, quarantaine, annulé, archivé ; quarantaine → validé (levée motivée, RG-161), annulé ; consommé, rejeté → archivé ; annulé et archivé terminaux. Un lot naît en brouillon ou en attente. (6) lot.nature reprend les quatre codes de numérotation (MP, REC, NET, PF, EC-068) faute de liste fermée dans le cahier ; lot.qualite est la catégorie d’affichage (EC-090), la qualité par référentiel arrive en L2-4. (7) Lot non descendu sur le téléphone : pas de groupement_id (à reprendre au Lot 3). (8) Les routes de lot sont au noyau (toujours actif), permission stock.manage pour déplacer, lecture à tout membre actif ; aucune route de création : un lot naît d’une réception (L2-2). |
2 | 03/10/2026 |
| EC-116 | Lot 2, L2-2 : réception, seuils, certificat et quarantaine | À trancher, appliqué provisoirement le 03/10/2026 (L2-2). (1) Une réception n’est pas en ajout seul : elle est figée par déclencheur, seules la décision (statut, auteur, date) et la dérogation changent ; ses pesées, ses mesures et la quarantaine sont en ajout seul ; une erreur se corrige par annulation (L2-6), pas par une nouvelle pesée. (2) Le net n’est jamais saisi ; le ticket de pesée est une référence de fichier facultative, stockage objet reporté. (3) Humidité et impuretés sont facultatives, mais une formule de contrat qui en a besoin refuse l’enregistrement (mesure_qualite_manquante) ; un constat « à vérifier » n’existe que pour un seuil défini dont la mesure manque. (4) La quantité du lot est le net de pesée (I1) ; le net marchand est une valeur distincte, base du montant dû (RG-191). (5) Seuils d’acceptation : paramètres reception.seuils.<produit> (humidite_max_cp, impuretes_max_cp), seul le maximum est évalué (RG-175 donne des fourchettes), aucune valeur inventée : sans seuil, pas d’évaluation, et le pack fruits n’en fournit pas pour l’ananas ; réglages reception.certificat_mode (bloquer par défaut ou exiger_note) et reception.seuils_effet (quarantaine par défaut ou exiger_note), lus dans app.parametre à la date de la réception, sans route d’écriture ni facteurs contextuels. (6) RG-014 s’applique à tout état de certificat hors « en vigueur » (pas commencé, suspendu, retiré, absent), pas aux producteurs ; la dérogation (reception.derogate, direction) ne vaut que pour RG-014, jamais pour une ligne de pack qui bloque. (7) Quarantaine : événement quarantaine_lot, le statut du lot suit ; I5 refuse tout débit, y compris la contre-passation de la création (la dévalidation de L2-6 lève d’abord la quarantaine) ; le déplacement reste permis ; levée par stock.release_quarantine (RSCI, direction), au noyau. (8) Constat d’une règle codée : app.constat.origine = processus, regle_decision_id vide, version 1 ; un seul constat ouvert par écart (un nouvel essai le retrouve), mais les constats des lignes de pack se dupliquent à chaque essai (evaluerAccroche inchangé). (9) Un lot de réception est de nature REC, naît en attente, reçoit son numéro à la validation ; sa qualité est saisie en attendant L2-4 ; l’issue « non-conformité ou tâche » n’est pas mise en œuvre (le constat suffit) ; le placement initial passe par deplacer. (10) Les routes de réception sont du module reception (inactif par défaut), la levée de quarantaine est au noyau. |
2 | 03/10/2026 |
Précision GPS et cartographie des parcelles
Section intitulée « Précision GPS et cartographie des parcelles »| id | sujet | décision | lot |
|---|---|---|---|
| GPS-01 | Traitement des points | Décidé : filtrage paramétré dans packages/domain (8 m, 3 m/s, 5 lectures stables) |
3 |
| GPS-02 | Modes de relevé | Décidé : sommets (défaut), marche, dessin sur carte, import (GeoJSON, Lot 1, EC-048) | 1, 3 |
| GPS-03 | Métadonnées de qualité | Décidé : méthode (dont « import »), précision, appareil par polygone ; trace brute conservée | 1, 3 |
| GPS-04 | Écart de surface | Décidé : affiché avec l’incertitude de mesure | 1 |
| EC-117 | Lot 2, L2-3 : procédés, étapes, sorties typées, bilan | À trancher, appliqué provisoirement le 03/10/2026 (L2-3). (1) Un procédé est un nœud de profondeur 2 ou 3 de l’arbre actif, sous une activité du regroupement « transformation » ; ses étapes sont ses enfants directs. Le facteur type_etape et le facteur nature_sortie du catalogue (AM-09, AM-12) n’existent pas encore : la nature d’une sortie est une liste fermée de la table sortie_etape, à reprendre quand le catalogue les porte. (2) Niveau de suivi : paramètre procedes.niveau_suivi.<procédé> (global ou detaille), suivi détaillé par défaut (la lecture la plus stricte, aucune source ne fixe de défaut) ; en suivi global, une saisie couvre le procédé et chaque étape critique est saisie à part ; « une étape qui produit un lot est saisie à part » n’est pas contrôlé (l’arbre ne dit pas quelle étape produit un lot). Sans route d’écriture des réglages (comme EC-116 (5)). (3) Tout mouvement de transformation exige une étape en cours (la note ne l’exige qu’en suivi détaillé) : un mouvement n’a jamais d’étape implicite. (4) Bilan : la partie double impose entrées = lots + purge + perte ; la perte comptabilisée est ce que les lots et les rebuts ne couvrent pas ; les pertes déclarées (motif obligatoire) s’en retranchent, l’écart inexpliqué est le reste, mesuré et non refusé ; il est signalé (ecart_bilan) au-delà du paramètre procedes.tolerance_bilan (centièmes de point des entrées), sans valeur fournie, rien n’est signalé (EC-011, aucune valeur inventée). Les intrants (compte intrant) sont lus dans le bilan mais aucune route ne les saisit encore. (5) Un rebut est débité du compte de purge et ne devient jamais un lot ; la règle « un rebut qui réintègre un flux bio » (note, normes visant des types) est reportée à L2-4 avec la qualité au mélange (reprise par EC-120). (6) La qualité des lots créés est saisie par l’appelant (catégorie d’affichage, EC-090) ; l’intersection par référentiel (RG-152) est en L2-4, de même que le choix automatique de la nature de numérotation du lot créé (MP, REC, NET ou PF : nature_lot obligatoire, jamais devinée). (7) Le point d’accroche etape.avant_validation est déclaré par le module « préparation » mais n’évalue aucune règle : ses variables et ses constats viennent avec les normes visant des types (L2-4 et suivantes). (8) recette et recette_ligne sont supprimées ; la section recettes des packs 1.0.0 et 1.1.0, déjà publiés, est acceptée et ignorée. |
2 |
| EC-118 | Contrat de la boîte d’activité (AM-04) absent du code après L2-3 | Constaté et décidé le 03/10/2026, à livrer en L2-3b. AM-04 dit que chaque nœud porte ses entrées, ses sorties typées, ses intrants, ses mesures et ses paramètres ; le nœud du pack (NoeudArbre) ne porte que son chemin, son type, son libellé, son caractère et son ordre. La suppression des recettes (AM-12) a retiré entrées, sortie et coproduits sans les reporter sur le nœud : une étape accepte tout lot et ses sorties sont libres. Décisions : (1) le nœud du pack porte un contrat facultatif (entrées, sorties avec leur nature, mesures, clés de paramètres), validé au chargement ; (2) une entrée ou une sortie hors contrat produit un constat, et un refus si l’étape est critique ; (3) le catalogue des types reste fermé pour les packs et les clients, mais devient une donnée versionnée éditable par l’équipe BioTrace au lieu d’une migration : la bascule se livre avec l’éditeur de packs ; (4) le type sechage_fruits, trop lié à une filière, est à remplacer par un type générique. Trois interfaces restent à planifier : éditeur de packs (BioTrace), paramétrage (administrateur client), travail quotidien (client). |
2 |
| EC-119 | Le contrat de nœud (EC-118) ne couvre pas les intrants que cite AM-04 | À trancher. AM-04 liste, parmi ce que porte chaque nœud, « ses entrées, ses sorties typées et ses intrants » ; le contrat ajouté en L2-3b (NoeudArbre.entrees, .sorties, .mesures, .parametres) ne porte que les deux premiers, les mesures et les paramètres. Aucune forme n’est décidée pour un intrant de nœud (produit non suivi en lot ? simple consommable ? emballage ?), ni pour son rattachement au compte intrant déjà lu par le bilan (EC-117 (4)). Recommandation : trancher sa forme avant d’ouvrir le contrat à un usage hors entrée/sortie matière des procédés. |
2 |
| EC-120 | Lot 2, L2-4 : qualité au mélange, déclassement, nature du lot | À trancher, appliqué provisoirement le 03/10/2026 (L2-4). (1) Qualité par référentiel : table app.lot_qualite (lot, référentiel, état), en ajout seul ; lot.qualite reste la catégorie d’affichage (EC-090) mais est calculée (qualite.categorieLot) : la plus basse catégorie entre celles des lots en entrée (saisies ou calculées) et celles des états du résultat ; « conventionnel » sans aucune information. Les lots de réception saisis avec la seule catégorie comptent donc par cette catégorie. La saisie de qualite sur une sortie d’étape disparaît (le champ reçu est accepté et ignoré). (2) Un lot sans qualité par référentiel (lots de réception de L2-2, saisis avec la seule catégorie) n’a aucun référentiel : un référentiel absent d’un composant est absent du mélange (intersectionQualites), aucune qualité n’est déduite. La réception reçoit une saisie facultative qualites. (3) RG-303 n’a ni page ni texte dans les sources (renvois seulement : « séquence héritée » dans la note, « gabarit affiché » à l’invariant I3) : lecture provisoire, un coproduit ou un sous-produit prend la nature_lot du produit principal de la même étape ; à valider. (4) nature_lot d’une sortie : portée par le contrat de la sortie du nœud du pack (sorties[].nature_lot, donnée de pack, AM-04), sinon héritée du produit principal, sinon la saisie reste obligatoire (nature_lot_requise, jamais devinée) ; la saisie explicite de l’opérateur prime sur le contrat ; pack fruits 1.4.0. (5) « Un rebut qui réintègre un flux bio » : destination est un texte libre et aucune liste fermée n’existe ; la sortie de nature rebut porte un booléen déclaré reintegre_flux_bio, lu par la norme (ligne de pack) qui choisit l’issue ; aucune règle de pack n’est livrée. (6) RG-153 : un déclassement est un référentiel dont l’état du résultat est plus bas que le meilleur état d’entrée (un référentiel perdu compte), ou une catégorie d’affichage plus basse que la meilleure catégorie d’entrée (lots saisis par catégorie, sans quoi SR-20 ne se joue pas sur les lots de réception) ; sans confirmer_declassement, refus declassement_a_confirmer (détail avant / après) ; avec, un constat processus RG-153, justifié, avec auteur et date. (7) Le point d’accroche etape.avant_validation s’évalue dans la validation de l’étape, avant l’attribution des numéros ; variables etape.produit, etape.entree_g, etape.sortie_g, etape.declassee, etape.rebut_reintegre_flux_bio, etape.nombre_referentiels_perdus ; seule l’issue « bloquer » refuse (etape_bloquee), les autres issues restent des constats (aucun canal de note sur la validation d’une étape, à ouvrir avec L2-6 ou L2-7). (8) Livré : pack fruits 1.4.0 (le séchage déclare PF ; le pack n’a pas de nœud de nettoyage ni de triage au niveau procédé, rien n’est déclaré NET) ; route PUT /v1/reglages/{cle} (settings.manage) qui écrit une version des réglages procedes.niveau_suivi.*, procedes.tolerance_bilan, reception.seuils.*, reception.certificat_mode et reception.seuils_effet, sans aucune valeur par défaut (EC-116 (5), EC-117 (2) et (4) : la route est livrée, les valeurs restent à fournir) ; le champ qualite des sorties d’étape est accepté et ignoré (contrat d’API 1.22.0 et 1.23.0, mineures). |
2 |
| EC-121 | Lot 2, L2-5 : ventes, expéditions, chaîne de certificats | À trancher, appliqué provisoirement le 03/10/2026 (L2-5). (1) Numéro officiel : aucune source ne numérote une vente ni une expédition ; aucun n’est attribué. (2) Solde : une vente passe à « soldée » quand le total expédié atteint la quantité engagée ; la tolérance du contrat ne sert qu’à autoriser un dépassement (reste négatif), jamais à solder plus tôt. (3) Lot consommé : un lot passe à « consommé » seulement quand son solde tombe à zéro à la validation d’une expédition. (4) PV de nettoyage valable : celui du véhicule, signé, tous points contrôlés, daté au plus tard le jour de l’expédition ; aucune durée de validité n’est donnée par les sources, aucune n’est inventée. Les points de contrôle sont libres (code, libelle, controle) : aucune liste n’est fournie. Le type de véhicule est un texte libre. (5) Chaîne de certificats (AV1-03), périmètre minimal : remontée par les mouvements de création jusqu’aux lots racines ; une racine est reliée à sa réception (producteur : statut de conformité à la date et certificats du groupement et de l’opérateur ; fournisseur : ses certificats, avec la qualité du lot) ; une racine sans réception (collecte du Lot 3, lot saisi à la main) est une origine inconnue qui bloque. Un lot issu de plusieurs lots en entrée remonte à toutes ses entrées (un coproduit multi-entrées n’est pas affiné). Profondeur limitée par le graphe, sans plafond. À reprendre avec la collecte (Lot 3). (6) Qualité d’un maillon fournisseur ou opérateur : celle du lot pour le référentiel (un fournisseur n’a pas de statut de conformité). (7) Portée : jugée sur les certificats de l’opérateur seul, pour le produit vendu et les producteurs remontés (ecartsDePortee avec produits et unites) ; un certificat sans ligne de portée ne limite rien. Réglage vente.certificat_mode : bloquer par défaut (D6), signaler en option ; un maillon qui ne peut pas revendiquer bloque toujours, sans réglage. (8) Documents : bordereau de livraison, PV imprimé, facture, fiche COI ne sont pas produits (aucun module documents) ; les références COI, NOP Import Certificate et EUDR sont des données facultatives ; document.avant_emission n’est pas câblé. (9) Facturation et règlement : hors L2-5. (10) Permissions sales.manage et shipping.manage : « commercial » reçoit la première, « magasinier » la seconde, l’administrateur client les deux (aucune source n’attribue ces droits). (11) Le point d’accroche vente.avant_expedition s’évalue à la validation de l’expédition ; seule l’issue « bloquer » refuse ; aucune règle de pack n’est livrée. |
2 |
| EC-122 | Lot 2, L2-5 : RG-304 et RG-305 (signature et zones) | À trancher. La note d’amendement cite RG-304 et RG-305 (« signature et zones »), mais aucune source ne porte leur texte (ni le cahier v1.2, ni l’analyse critique, ni le découpage). Non implémentées en L2-5 ; le module droits n’est pas modifié. Recommandation : fournir le texte, sinon reporter. |
2 |
| EC-123 | Environnement de QA : écarts avec le dépôt | À trancher. (1) Keycloak : la QA tourne en 26.8.0, le dépôt épingle 26.0.5 (compose, CI, ADR 0034) ; keycloak-config-cli n’est publié que jusqu’à 26.5.5 (version utilisée pour appliquer le royaume en QA) : les tests KC ne couvrent pas la version déployée. (2) PostgreSQL : la QA utilise postgis/postgis:18-3.6, le dépôt 16-3.4. (3) infra/keycloak/environnements/recette.env garde une adresse d’exemple ; la QA utilise https://bo-biotrace.qa.dev.solumae.com. (4) Les manifestes du Keycloak de QA et le Job qui applique le royaume sont hors du dépôt. (5) Rôle des migrations (04/10/2026) : en QA, les migrations tournent avec le superutilisateur de l’instance, alors qu’EC-034 prévoit un rôle BYPASSRLS non superutilisateur ; l’API, elle, se connecte bien en biotrace_app. (6) Rôles : aucune migration ne crée biotrace_app ni biotrace_powersync, contrairement à ce que disait db/README.md (corrigé) ; ils ont été créés à la main en QA. (7) Nom du rôle des migrations : socle posait les droits par défaut FOR ROLE biotrace, ce qui échouait dès que les migrations tournaient sous un autre nom ; la clause est retirée, les droits valent pour le rôle qui joue les migrations. (8) EC-034 inapplicable en l’état : lot1_a9_synchronisation utilise SET LOCAL session_replication_role, réservé au superutilisateur ; un rôle BYPASSRLS non superutilisateur ne peut donc pas jouer les migrations. À trancher : garder le superutilisateur ou réécrire cette migration. (9) Les 36 migrations passent sur PostgreSQL 18 et PostGIS 3.6 (essai du 04/10/2026), la CI ne testant que la version 16. |
0 |
| EC-124 | Exécution des migrations | Décidé le 03/10/2026 (ADR 0044, qui modifie l’ADR 0013). Le découpage dit « exécutés par un Job Kubernetes avant chaque déploiement de l’API ». Retenu : un job du pipeline de déploiement lance dbmate migrate depuis le runner, avant helm upgrade. L’image de l’API ne contient ni dbmate ni les migrations ; DATABASE_URL reste dans l’environnement GitHub. Contrepartie : la base doit être joignable depuis le runner. |
0 |
| EC-123 | Lot 2, L2-6 : dévalidation, annulation, registre | À valider, appliqué provisoirement le 04/10/2026 (L2-6). (1) Retour à l’état précédent, pas de lot « brouillon » : le texte v1.3 de RG-032 (« repasse le lot en brouillon ») n’est pas suivi, car un brouillon rouvrirait I1 et I4 ; décidé avec l’équipe. (2) Réception dévalidée : l’ancien lot est annulé (numéro conservé, I3), la réception reprend un nouveau lot en attente de même quantité et qualité ; la revalidation attribue le numéro suivant. (3) Vente : « soldée → validée » quand une expédition est dévalidée ; une vente soldée ne s’annule pas directement. (4) Lot né d’une étape : il ne s’annule pas seul (sa création est celle de toute l’étape), on dévalide l’étape. L’annulation d’un lot de réception rejette la réception. (5) Permission stock.reverse pour la direction seule (cahier : « par la direction ») ; la matrice §2.6 n’a pas été retrouvée dans les sources pour trancher RSCI et administrateur client. (6) Accroche *.avant_devalidation non créée (gel des spécifications). (7) Observation L2-3 : une transformation qui vide un lot ne le marque pas « consommé » (seule l’expédition le fait) ; il reste « validé » à solde nul. Non modifié. (8) L’annulation d’une expédition en brouillon n’est pas exposée. |
2 |
| EC-124 | Lot 2, L2-7 : bilan, rappel, dossier d’audit, tâches de fond | À valider, appliqué provisoirement le 04/10/2026 (L2-7). (1) Format du dossier d’audit : aucune source ne fixe le format attendu par l’auditeur ; le dossier est un JSON structuré (forme canonique, empreinte SHA-256) accompagné de l’édition HTML imprimable du registre (RG-144). Le PDF et la mise en page de l’auditeur Naturland restent à fournir. Le dossier présente des écarts, jamais de verdict (AM-01). (2) Inscription de la tâche : pg-boss tourne sous un rôle propriétaire distinct de biotrace_app ; la tâche est inscrite après la validation de la demande, non dans la même transaction (écart avec l’ADR 0015). La ligne dossier_audit « en_attente » reste la source de vérité, la tâche est idempotente (clé de singleton) ; une demande dont l’inscription échoue se redemande. Un rattrapage au démarrage reste à faire (L2-8 ou lot 7). (3) Rappel : un rappel réel met en quarantaine tous les lots validés du plan, y compris ceux à solde nul (un lot vidé par une transformation reste « validé », EC-123 (7)) ; les lots consommés, rejetés ou annulés sont listés lots_non_bloquables. La notification des clients (RG-162) n’a pas de route : la liste des clients et des quantités est dans le plan figé, l’information de l’organisme certificateur et les quantités retournées, détruites ou déclassées se saisissent à la clôture. (4) Produit d’une étape dans le bilan par produit : celui de la première ligne d’entrée du mouvement ; une étape à entrées de produits différents serait rangée sous le premier. (5) Permissions recall.manage et audit.export à la direction seule (comme stock.reverse, EC-123 (5)). (6) Le canal de note de l’issue « exiger une note » de etape.avant_validation reste ouvert. |
2 |
| EC-125 | Cockpit de l’éditeur (CP-0) : licences, facturation, journal de l’équipe | Points (1) et (2) arbitrés le 04/10/2026 par la direction du projet : licence = modules et période, facturation dans un outil externe, expiration = alerte seulement (voir EC-129, CP-6). Le point (5) est réglé pour les nouveaux comptes de l’équipe (EC-130). Le point (3) est tranché par un journal technique des écritures (EC-131). Les points (4) et (6) restent à trancher. (1) Licences et offres : aucune source ne définit les offres, les quotas, ni l’état d’une licence ; le cockpit ne présentera que ce que la table d’activation des modules porte déjà. (2) Facturation : aucune source ne dit si elle est interne ou confiée à un outil externe ; décision à prendre avant tout modèle de données. (3) Journal des actions de l’équipe : EC-099 dit que l’on n’audite pas l’équipe éditeur, mais RG-309 prévoit l’accès journalisé de l’éditeur à un client ; à arbitrer entre un simple journal technique et un journal d’accès client. (4) Descriptions des modules et activités : le cockpit les extraira des pages de apps/docs ; un nœud sans page n’aura pas de description. (5) Second facteur de l’équipe (CP-1) : le royaume impose le TOTP par un groupe (second_facteur_exige) que l’API pose sur les comptes clients ; rien ne l’impose aux comptes portant un rôle editeur_*. Le client biotrace-cockpit ne l’exige donc pas encore ; à trancher avec l’accès à l’infrastructure. (6) Visibilité par rôle : EC-099 donne les rôles mais pas ce que chacun voit ; en CP-1 toute la navigation est visible de tout rôle de l’éditeur, les écritures seront gardées route par route (CP-2 et suivants). |
cockpit |
| EC-126 | Cockpit, CP-2 : suspension d’une organisation et accès de l’éditeur aux données d’un client | À valider, appliqué provisoirement le 04/10/2026 (CP-2). (1) Suspension : aucune source ne la définit ; app.organisation.statut (active, suspendue) est posé par le support ou le super administrateur, avec motif écrit au journal d’administration de l’organisation. La garde d’authentification refuse l’organisation (organisation_suspendue, 403) ; données et comptes sont conservés. Les jetons déjà émis restent valables jusqu’à leur expiration, les sessions Keycloak ne sont pas révoquées et la synchronisation d’un appareil déjà connecté n’est pas coupée : à décider (révocation à la suspension, compte de service). (2) Lecture des données d’un client : le cockpit lit un client par une transaction posée sur son organisation (la RLS reste la seule règle d’isolation) ; la liste de toutes les organisations passe par app.editeur_lister_organisations(), fonction SECURITY DEFINER étroite. Seules les écritures sont journalisées ; l’accès journalisé en lecture (RG-309, EC-099) reste à décider. (3) Accès : le cockpit crée l’organisation et son premier administrateur (route existante, mot de passe temporaire affiché une fois). Il ne crée pas d’autres comptes et ne réinitialise pas le mot de passe de l’administrateur : à décider si le support doit pouvoir le faire. (4) Affichage : dates en UTC (Togo, Bénin et Ghana sont à UTC+0) ; liste des organisations sans pagination, journal limité aux 200 appels les plus récents. |
cockpit |
| EC-127 | Cockpit, CP-3 : descriptions des modules et activités, activation d’un module par l’éditeur | À valider, appliqué provisoirement le 04/10/2026 (CP-3). (1) Descriptions : aucune source ne décrit chaque module, activité ou étape en texte (aucune page de apps/docs n’est dédiée à un nœud, aucune colonne de description n’existe). Le cockpit n’invente rien : il affiche ce que la plateforme porte (libellés fr et en, regroupement, dépendances, permissions, routes, écrans, accroches, variables, contrat des nœuds d’un pack) et dit « pas de description rédigée ». À décider : rédiger les descriptions (où : colonne, champ du pack ou page de documentation par nœud) ; elles relèvent d’un travail de rédaction, pas de code. (2) Activation d’un module par l’éditeur (prévue au plan CP-3) : non livrée. app.organisation_module.cree_par est une clé étrangère vers app.utilisateur de l’organisation, et la vue module_en_vigueur joint cet utilisateur : un changement écrit par l’équipe de l’éditeur, qui n’a pas de ligne utilisateur chez le client, ne serait ni accepté ni relu. La décision d’activer appartient aujourd’hui à la direction du client (« BioTrace propose, la direction décide », AM-05). Le cockpit montre l’état des modules d’une organisation (fiche, onglet Modules) sans le modifier ; l’activation par l’éditeur se traitera avec les licences (EC-125, CP-6), en même temps que la question de l’auteur d’un changement. (3) Arbre du catalogue : un module affiche les activités de premier niveau qui le proposent (app.module_activite) ; une activité proposée par plusieurs modules apparaît sous chacun. Le cockpit ne lit que les tables globales et les manifestes de modules du domaine ; l’arbre d’un pack vient du contenu de sa version. |
cockpit |
| EC-128 | Cockpit, CP-5 : ce que la publication ne couvre pas | À valider, appliqué provisoirement le 04/10/2026 (CP-5). (1) Brouillon et revue : le plan prévoyait brouillon, revue, publié ; EC-099 écarte toute séparation des tâches dans l’équipe de l’éditeur, et le brouillon d’un pack est le fichier versionné dans packs/ (git). Le cockpit contrôle à blanc puis publie directement. À reprendre si une revue devient exigée. (2) Retrait d’une version (publie vers retire, permis par la base) : pas d’action dans le cockpit ; ses effets (campagnes qui l’utilisent, chargement refusé pour les nouveaux clients) ne sont décrits par aucune source. (3) Règles générales et documents : aucune source ne définit des règles générales globales distinctes des jeux de paramètres des packs, ni des documents publiés par l’éditeur (les modèles de documents sont dans les manifestes de modules). L’écran « Règles et normes » reste en attente de cet arbitrage ; les normes se publient comme des packs référentiels. (4) Provisionnement : le rôle PostgreSQL de publication et PUBLICATION_DATABASE_URL sont à créer par l’infrastructure (ADR 0045) ; rien ne les crée en recette ni en production. (5) Taille et fichier : le cockpit lit un fichier JSON local ; pas de dépôt depuis git ni de comparaison avec la version précédente. |
cockpit |
| EC-129 | Cockpit, CP-6 : licences et références de facturation | Arbitrage de la direction du projet le 04/10/2026 (modèle, facturation, expiration) ; le reste est appliqué provisoirement (CP-6), à valider. Décidé : (1) une licence = les modules ouverts à une organisation pour une période (premier et dernier jour inclus) ; (2) la facturation reste dans un outil externe, BioTrace ne garde que la référence saisie à la main ; (3) une licence échue ou proche de l’échéance signale, sans rien bloquer : ni l’accès, ni l’activation des modules n’en dépendent. Provisoire : (4) droits : lecture pour tout rôle de l’éditeur, saisie réservée au super administrateur (EC-099 ne dit rien des licences ni de la facturation) ; (5) une licence est en ajout seul, la plus récente fait foi, une correction est une nouvelle saisie motivée ; pas de périodes simultanées ; (6) licence : modules du catalogue hors noyau, sans doublon, et chaque module avec ses modules requis (collecte requiert membres_foncier, etc.) ; (7) facture : numéro de l’outil externe (unique par organisation), montant en unités mineures, devise (XOF, EUR et USD proposées à la saisie, celles de app.devise), émission, échéance ≥ émission ; état émise, payée ou annulée, payée et annulée définitifs ; date de paiement ≥ émission, par défaut le jour de l’appel ; en retard = émise, non payée, échéance dépassée depuis la veille ; (8) le jour est celui de l’horloge du serveur, en UTC ; les filtres d’échéance du cockpit (30, 60, 90 jours) sont des filtres d’affichage, pas des seuils métier ; aucune notification n’est envoyée ; (9) non traités : offres nommées et quotas (utilisateurs, appareils, sites), lien entre une facture et une licence, relances, avoirs, activation d’un module par l’éditeur (EC-127 (2) : une licence ne modifie pas les activations), blocage à l’échéance. |
cockpit |
| EC-130 | Cockpit, CP-8 : gestion de l’équipe BioTrace | Demande de la direction du projet le 04/10/2026 (le cockpit aide à créer les membres de l’équipe) ; le reste est appliqué provisoirement, à valider. (1) Droits : lecture pour tout rôle de l’éditeur, écriture réservée au super administrateur (EC-099 ne dit pas qui gère l’équipe). (2) Un compte, un rôle editeur_* ; l’identifiant de connexion est equipe.<identifiant>. (3) Second facteur : les comptes créés par le cockpit rejoignent le groupe second_facteur_exige (EC-125 point 5 réglé pour eux) ; les comptes existants et le client biotrace-cockpit n’y sont pas contraints. (4) Désactivation : sessions Keycloak révoquées ; un jeton d’accès déjà émis vit jusqu’à son expiration (5 minutes). (5) Mot de passe : réinitialisation par mot de passe temporaire affiché une fois, pas de lien par e-mail (le royaume l’interdit) ; pas de suppression d’un compte (désactivation seulement). (6) Premier super administrateur : créé dans la console Keycloak, hors cockpit. (7) Journal : seules les écritures sont journalisées (app.action_equipe) ; ni lecture ni connexions, comme EC-099. (8) Secret : BIOTRACE_API_EQUIPE_CLIENT_SECRET à fournir en recette et production (ADR 0046). |
cockpit |
| EC-131 | Cockpit, CP-7 : vision 360 et journal des actions de l’équipe | Appliqué provisoirement le 04/10/2026 (CP-7), à valider. (1) Seuils d’affichage : licences à l’échéance dans 30 jours, rejets des 7 derniers jours : des filtres d’affichage, pas des règles ; aucune notification. (2) Erreurs de synchronisation : la plateforme ne porte qu’un indicateur, les rejets de sécurité (sync.rejet, EC-043) ; aucune source ne définit les erreurs de synchronisation d’un appareil (retard, échecs de lot, appareils muets) : à définir avant de les montrer. (3) Versions de packs déployées : « déployée » = une campagne d’une organisation s’appuie sur la version ; il n’existe pas d’autre notion de déploiement. (4) Journal des actions : tranche EC-125 point 3 par un journal technique des écritures de l’équipe (appels d’administration sans compte client, actions sur l’équipe) ; l’accès journalisé en lecture à un client (RG-309, EC-099) reste à décider. Les 200 plus récentes, sans pagination ni filtre. (5) Activité des utilisateurs (dernière connexion, organisations dormantes) : non traitée, aucune source. |
cockpit |
| EC-132 | Back-office : coquille du cockpit et densité Bureau | Appliqué provisoirement le 04/10/2026 (ADR 0047), à valider. (1) Barre latérale : BioTrace_design_system.md §7 décrit une navigation Bureau sombre ; le back-office suit désormais la coquille claire du cockpit (priorité 2 contre une décision de la direction du projet de n’avoir qu’une interface). (2) Vert : le back-office employait --statut-bio-texte pour une validité (géométrie, capacité applicable, formulaire valide) ; remplacé par l’encre avec symbole, le vert ne signifiant que « bio ». (3) Palette ⌘K du back-office : navigation seule, sans recherche transversale. |
design |
| EC-133 | Back-office : parcours d’onboarding de la première connexion | Appliqué provisoirement le 04/10/2026 (UI-2), à valider. (1) Correspondance questions → activités et fonctions : choisie par l’équipe, sans source ; les fonctions déduites d’une activité suivent module_activite (EC-095), contrôle interne, planification, intrants et avances, paiements et EUDR viennent d’une case « besoins » et jamais d’une activité seule. Libellés d’aide des besoins provisoires. (2) Familles de culture : seule « fruits » (ananas) a un pack ; cacao, café, anacarde, coton, karité et « autre » sont annoncées « Bientôt ». (3) Demandes « Me prévenir » : enregistrées dans organisation_onboarding.reponses, aucune lecture dans le cockpit. (4) Visibilité : réservé à modules.manage ; les autres rôles ne voient rien tant que le compte n’est pas ouvert. (5) Pas de désactivation : le parcours n’enlève rien, y compris au rejeu. |
conception |
| EC-134 | Accès : mot de passe perdu, second facteur désactivé | Appliqué provisoirement le 04/10/2026, à valider. (1) Récupération du mot de passe : aucune source ne la décrit. Pas de lien « mot de passe oublié » en libre-service, car il exige un serveur de courriel (SMTP) et une adresse sur chaque compte, absents du royaume (resetPasswordAllowed reste à false). La reprise d’accès passe par un administrateur : page Utilisateurs du back-office (users.manage, mot de passe provisoire + fermeture des sessions) et, pour l’assistance, onglet Utilisateurs de la fiche d’organisation du cockpit (editeur_support, editeur_admin) ; le cockpit réinitialise les comptes de l’équipe dans « Accès et équipe » (CP-8). À trancher : SMTP et lien de récupération en libre-service. (2) Second facteur (TOTP) : désactivé sur demande de la direction du projet. Les deux sous-flux du royaume passent de CONDITIONAL à DISABLED ; groupe et rôle second_facteur_exige sont conservés, la réactivation est un retour à CONDITIONAL. Écart avec la note d’amendement et la page « Configuration Keycloak » §5, qui l’exigent pour certains rôles : à réactiver avant la mise en service. |
1 |
| EC-135 | Écran Activités : profil réglementaire déduit, couches de l’application, vision du pack | Appliqué provisoirement le 04/10/2026, à valider. (1) Profil déduit, pas saisi : le cahier §2.1 interdit un profil exclusif à l’inscription et EC-109 constate qu’aucune source ne définit de profil. L’écran affiche donc une situation réglementaire calculée des activités et fonctions actives (packages/domain/src/profil, PROF-01), cumulable : groupement (collecte auprès de membres ; art. 36 du règlement (UE) 2018/848, RG-024, SCI à activer), producteur individuel (production sans collecte ni SCI ; RG-302), préparateur, acheteur ou importateur, exportateur (EUDR à évaluer ou actif), distributeur. Rien n’est stocké. À confirmer : la bascule individuel / groupement repose sur la seule activité « collecte auprès de membres » (aucun seuil chiffré) ; les références citées sont celles de la note et du cahier. (2) Trois couches nommées : ossature BioTrace (noyau), activités et fonctions normalisées (catalogue fermé, AM-04 et AM-05), apport de la filière ; le texte pédagogique de chaque couche est rédigé ici et à relire. (3) « Ma filière » : nouvelle route de lecture GET /v1/ma-filiere (contrat 1.36.0), pack figé de l’organisation (noeud_activite.pack_version_id). Le pack fruits ne renseigne ni entrées, ni sorties, ni mesures par nœud (EC-118) : l’écran dit « contrat non renseigné par la filière » et n’invente rien. Les contrôles affichés sont les points de grille dont activites contient le type du nœud ; un point sans activité n’apparaît pas dans cette vue. (4) Les libellés des profils et des conséquences sont provisoires. |
1 |
| GPS-05 | Matériel | Décidé : GNSS bifréquence exigé au pilote ; récepteur externe au Lot 6 | 3, 6 |
| GPS-06 | Parcelles sous couvert | Décidé : mode sommets imposé, correction sur image satellite | 6 |
| GPS-07 | Test comparatif | Décidé : écart de surface < 5 %, répétabilité ≤ GPS Fields Area Measure | 3 |