QAPAS — cahier des charges produit et technique V1

Statut : baseline de référence, 27 septembre 2026. Ce document distingue les décisions retenues des points à préciser avant de les implémenter.

1. Identité, finalité et posture

QAPAS — Quintais Agroflorestais e Participativos em Aldeias Sustentáveis. « Sustentáveis » décrit l'ambition de pratiques pérennes, pas un label accordé à une aldeia.

QAPAS est un lieu de rencontre et une plateforme de services pour toutes les personnes concernées par ses activités : propriétaires et producteurs, personnes curieuses ou participantes, acheteurs potentiels, commerçants, transformateurs et prestataires. Ses outils permettent notamment de relever un lieu, imaginer et mettre en œuvre des pratiques agroécologiques, gérer cultures et interventions, trouver des partenaires ou des débouchés et observer l'évolution d'un projet. On peut découvrir QAPAS sans posséder de terrain ; une quinta peut regrouper plusieurs quintais et un quintal peut être inscrit sans quinta.

La proposition d'accueil est concrète et accessible à toute personne intéressée : mieux gérer potager, cultures maraîchères et verger, demander ou proposer de l'aide et des services, puis choisir de donner, troquer ou vendre des récoltes. Les applications annoncées « à venir » restent identifiées comme telles : le discours d'accueil décrit le projet, pas une disponibilité fictive. Le propriétaire peut agir seul ou inviter d'autres personnes ; l'accès aux outils réservés aux membres suppose l'adhésion volontaire à QAPAS — Community (volet adhésion). La présentation met en avant les outils et leurs bénéfices pratiques, pas des personnalités ou un classement des habitants.

Le premier public comprend aussi des particuliers qui cultivent leur jardin sans être agriculteurs professionnels. QAPAS ne les assimile pas à une exploitation agricole déclarée et ne présente pas les professionnels comme de simples vendeurs de surplus. Les outils de planification, d'entraide et de suivi restent ouverts selon les droits du membre ; dès qu'une offre payante ou une précommande est proposée, le parcours vérifie le rôle réel du vendeur et les obligations liées à la fréquence, au produit et au canal de vente. Le ton est pratique et accueillant, sans exposer publiquement la situation fiscale d'un voisin ni tirer argument d'une économie informelle pour dissimuler une transaction.

La première question reste simple : « Que souhaitez-vous faire de votre récolte ? » Garder l'information privée, donner, demander comment échanger ou vendre, puis ouvrir le parcours adapté. Les obligations ne sont présentées qu'au moment où elles deviennent pertinentes, dans un langage compréhensible ; aucune étiquette publique « particulier non déclaré » ou jugement sur les personnes. En revanche, avant une transaction réelle, vendeur, prix, documents et responsabilités ne sont jamais laissés implicites.

La résilience d'une aldeia est un potentiel qui se construit progressivement par des réalisations concrètes et la participation volontaire. QAPAS ne délivre aucun statut, label, certificat ou score de « village résilient ». L'adhésion QAPAS finance l'accès aux outils et n'accorde à personne un mandat sur l'aldeia, le quintal ou les autres membres. Aucun projet collectif, accord d'un village ni rattachement à une organisation locale n'est requis pour inscrire son propre quintal. La plateforme présente la méthode et, avec l'accord des personnes concernées, des exemples contextualisés.

QAPAS et ses applications complémentaires sont hébergées séparément ; elles ont leurs propres bases de données, sessions, gardes d'authentification et autorisations.

Identité et activité personnelle pour les applications clientes

QAPAS Platform est le fournisseur du parcours d'identification des personnes et des contrats privés communs. Son catalogue public et son manifeste de navigation ne prouvent ni l'identité ni les droits d'un visiteur. Une session navigateur ouverte sur Platform n'est pas une session ouverte dans une application cliente ; le jeton Passport client_credentials identifie seulement une installation. La barre QAPAS des applications peut déjà proposer un lien public « Mon compte QAPAS », mais l'avatar, les données de compte, les notifications et les messages n'y apparaissent qu'après livraison et vérification du parcours utilisateur et des API privées décrits ici.

Platform enregistre les applications clientes autorisées, leur origine, leur identifiant et leurs URI de retour exactes. Elle fournit un flux d'autorisation d'une personne (code d'autorisation OAuth2 avec PKCE, ou protocole d'identité humaine équivalent explicitement spécifié et testé) : session Platform existante réutilisée si valable, défi de connexion et, si nécessaire, consentement explicite, puis retour contrôlé à l'application. L'application vérifie state, l'émetteur, la destination et les preuves, lie le sujet par public_id stable et aléatoire, renouvelle sa propre session, et restaure uniquement le chemin local initial autorisé. Scopes minimaux, expiration, rotation/révocation et déconnexion locale sont contractualisés ; aucune promesse de connexion silencieuse, de déconnexion unique instantanée ni d'OIDC tant que ces capacités ne sont pas livrées. Ni jeton d'accès, ni message privé, ni URL de retour libre dans un paramètre non validé ou dans le manifeste public. Le compte d'administration Filament reste séparé.

Livraison du contrat d'identité initial : Passport protège /api/identity/v1 avec le scope qapas:identity, l'email vérifié et une liste explicite d'identifiants de clients PKCE ; la réponse ne contient que le sujet UUIDv4, le nom, l'adresse vérifiée, l'émetteur, l'audience et l'état de l'avatar. Les portraits privés sont relayés par /api/identity/v1/avatar, et /api/identity/v1/revoke permet la déconnexion locale avec révocation. Les jetons expirent après quinze minutes et sont aussi révoqués lors du changement ou de la réinitialisation du mot de passe. Le template qapas-application livre le client, la session locale, le menu et le middleware ; Farmers’ Games pourra l'utiliser pour reconnaître une personne. Le client Passport et son URI de retour sont provisionnés pour chaque installation ; le service est fermé en l'absence de client allowlisté ou de vérification du compte. Aucun droit sur une équipe ou un événement ne découle de ce seul contrat. Les notifications, messages et habilitations métier demandent des contrats distincts.

Platform publie des API privées versionnées et limitées à la personne autorisée : contexte minimal de compte (subject_public_id, nom d'affichage autorisé, locale, référence d'avatar privé avec durée et audience), activité (notifications_unread, messages_unread, révision et horodatage de fraîcheur), plus les destinations stables et protégées « Mon compte », « Profil », « Préférences », « Mes données », « Notifications » et « Messages » au fur et à mesure de leur livraison. La lecture et le marquage comme lu sont contrôlés côté Platform et ne transitent pas dans le manifeste ni dans un compteur seul ; avatar privé et compteurs ne sont jamais publics. Un zéro affiché provient d'une réponse personnelle authentifiée et fraîche ; panne, révocation ou changement de personne invalident les données en cache et affichent un état inconnu ou anonyme. Les API imposent scopes, contrôle de sujet, TLS, limitation de débit, caches privés bornés et absence de données sensibles dans les logs ; les mutations sensibles exigent une nouvelle vérification lorsque nécessaire.

Platform définit enfin le contrat d'accès aux applications : quelles routes peuvent être publiques, lesquelles requièrent une identité, une adhésion, une invitation ou une capacité précise ; comment exposer et révoquer à temps ces droits à l'application concernée. Une personne correctement identifiée n'obtient pas de droit implicite sur tous les dossiers : l'installation cliente applique ses propres policies sur chaque ressource personnelle et ses rôles administratifs. Pour une application à accès contrôlé, l'anonyme passe par le défi Platform, puis l'application vérifie le droit requis ; une personne identifiée mais non autorisée voit un refus ou un parcours de demande d'accès sans boucle de connexion. Si Platform ou ses preuves sont indisponibles, les accès protégés échouent fermés, tandis que les informations publiques prévues restent accessibles.

Réception conjointe Platform + template : depuis un navigateur avec et sans session Platform, ouvrir une application à accès public puis une application privée ; vérifier le retour au bon chemin, le refus d'un non-membre et d'un invité révoqué, et l'isolation de deux personnes et de deux installations. Afficher dans chaque langue disponible un avatar autorisé (ou un symbole neutre), deux compteurs corrects et les liens vers les pages personnelles de Platform ; marquer une notification et lire un message, puis vérifier la mise à jour. Tester expiration, refus de consentement, changement de compte, déconnexion locale et Platform, révocation, coupure API et absence de fuite entre comptes. Ces critères conditionnent l'activation de la couche privée de la barre commune.

Modèle commercial et responsabilité des produits

QAPAS (plateforme et association) ne vend ni n’achète jamais de produits. Ses seules recettes commerciales rémunèrent les services de plateforme réellement fournis : accès aux outils, développement, formation, mise en relation lorsqu’elle existe, conditionnement, équipement et logistique selon le prestataire contractuel effectif. La cotisation et les dons de développement sont identifiés séparément. Aucun produit, panier ou lot ne figure comme vente ou stock de QAPAS ; QAPAS ne devient pas vendeur sur la facture du produit ni propriétaire des récoltes, même lorsqu’une commande est organisée par ses outils.

Dans une vente directe, le producteur vend au client. Dans un achat ferme facultatif, un commerçant ou opérateur alimentaire juridiquement distinct de QAPAS achète en son nom, paie dès l’acceptation, puis revend en son nom, facture le client, supporte conformité, pertes, retours et invendus. Une structure commune peut exploiter un lieu ou des services seulement si son identité juridique, ses comptes, ses tarifs et ses responsabilités sont établis séparément ; elle ne prête pas l’identité de QAPAS au commerce. Chaque écran et document sépare prix du produit, vendeur, encaissement du produit et prix des services QAPAS. Une commission de service transparente ne transforme pas QAPAS en vendeur ; les modalités de paiement et de fiscalité demandent validation avant activation.

Service QAPAS de développement d'applications privées

QAPAS peut étudier, chiffrer, développer et maintenir sur devis individuel une application réservée à un client, avec les connexions aux outils communs qu'il autorise. Ce service relève de l'offre de la plateforme, sans carte d'application publique, don dédié, campagne de financement ou référencement d'une installation client dans le manifeste de navigation. L'étude décrit finalité, livrables, critères de réception, tarifs de création et d'hébergement, sauvegardes, propriété/licence du code, responsabilité des traitements et réversibilité ; le client commande seulement après devis et contrat. Aucune information sur lui, ses cultures, son installation ou ses usages n'est publiée à son insu.

Chaque réalisation privée a une base, un domaine, des secrets, une session et des permissions isolés. Les échanges avec QAPAS empruntent des API privées, versionnées et limitées au client, au quintal et au cas d'usage autorisés ; accès révocable, traçable et export de sortie convenu. La prestation ne donne ni accès aux données d'autres membres ni adhésion automatique ; le client accède aux applications communes selon les mêmes règles que tous. Si une fonction privée intéresse plus tard la communauté, ses droits doivent être négociés explicitement et les données et secrets du client retirés avant tout partage. Critère de réception : un client pilote autorisé consulte son seul livrable ; un autre membre, l'accueil public et le manifeste ne découvrent ni son installation ni ses données, et la révocation coupe l'échange.

2. Périmètre territorial et vocabulaire

Dans QAPAS, « aldeia » désigne un repère de localisation postale, pas une collectivité inscrite sur la plateforme, ni un organisme habilité à décider pour ses habitants. On conserve les éléments utiles à l'adresse : pays, région si connue, commune/concelho et freguesia si pertinents, localité et code postal. Un code postal est une donnée d'adressage, pas l'identifiant unique d'une communauté ou la preuve d'une limite foncière. Aldeia do Souto, 6200-501, est l'exemple local par défaut ; les autres lieux doivent être possibles dès le départ.

Les fiches de lieu ne doivent pas publier par défaut une position précise, l'identité ou l'adresse du propriétaire, ni permettre de reconstruire la liste des quintais d'un code postal.

3. Parcours propriétaire et qualité du levé

1. Une personne crée son compte gratuit : cela lui ouvre, sans cotisation, les démonstrations pertinentes pour un utilisateur final et le levé topographique de base gratuit dès que ces parcours seront effectivement livrés. Les démos restent isolées avec des données fictives ; la fiche réelle de levé est privée et soumise à ses permissions. En local seulement, un compte fictif peut ouvrir une session automatiquement, sans constituer une inscription ou une adhésion réelle.
2. La personne inscrite ouvre une fiche privée provisoire de quintal ou quinta, renseigne le lieu postal et choisit une ou plusieurs méthodes pour dessiner et relever le terrain. Le résultat gratuit reste un plan de travail personnel ; l'inscription à QAPAS ne prouve ni propriété, ni limites légales, ni accord du village.
3. Le propriétaire ou son mandataire peut ensuite adhérer volontairement à QAPAS pour utiliser les autres outils disponibles selon la version et ses droits. La démarche active dans ces applications suppose un levé suffisant pour l'usage visé et un contrôle indépendant de la qualité de titulaire ou du mandat. Les dons de développement restent possibles mais ne remplacent pas une cotisation ni un contrôle de droit.
4. Le propriétaire construit ses projets, suit cultures, arbres, eau, sols et interventions, et invite des personnes seulement s'il le veut. Des résultats peuvent être publiés sur consentement explicite, avec une granularité compatible avec la vie privée.

La qualité du levé et le droit de porter le projet sont deux contrôles indépendants. Une mesure topographique, même précise, ne démontre ni la propriété, ni une limite juridique, ni le consentement d'autres ayants droit. La plateforme ne présente pas une emprise observée comme un titre foncier.

Les critères d'acceptation du levé devront préciser au minimum : emprise ou objets effectivement relevés, système de coordonnées et transformations, date et auteur/provenance, méthode et état de mesure, incertitudes enregistrées, complétude, cohérence géométrique et possibilité de corriger ou refaire le travail. Les seuils chiffrés dépendent de l'usage : une implantation critique n'exige pas les mêmes preuves qu'un inventaire d'arbres. Le contrôle laisse une trace datée et une raison compréhensible en cas de rejet ; les versions précédentes restent attribuables.

Entrer dans Topographie par trois méthodes compatibles (V2 planifiée)

1. Esquisse sur image satellite ou orthophoto autorisée : l'inscrit place, déplace et ferme les sommets d'un polygone de quintal ou de quinta sur un fond de carte avec attribution et date d'imagerie affichées. Surface estimée et contour portent la mention « indicatif, non cadastral » ; ombres, décalage de l'image et végétation empêchent de prétendre à une précision centimétrique. La carte Leaflet peut recevoir un fond orthophoto sous licence appropriée ; une option Google Maps satellite exige son API officielle, sa clé, ses coûts et ses conditions d'usage propres. Ne jamais détourner les tuiles Google vers un fond Leaflet non autorisé. La bibliothèque Drawing de Google Maps étant retirée, l'outil de polygone doit être maintenu indépendamment du fond. Voir les dépréciations Google Maps et les données géographiques DGT disponibles.
2. Mesures GNSS/RTK avec kit QAPAS ou équipement compatible : points et lignes observés gardent session, matériel, date, système de référence, transformation, précision réellement constatée et responsable. La précision d'un relevé ne démontre pas une limite de propriété ; l'emploi d'un kit peut relever d'un prêt avec conditions et caution séparées de la cotisation.
3. Import de fichiers KML, GeoJSON ou autre format validé remis par un professionnel : enregistrer l'auteur, la date, le format, le système de coordonnées original et la transformation, les droits de réutilisation et la nature de chaque couche. Seul un contour légal documenté et vérifié comme tel peut servir de référence juridique ; une ligne tracée par un professionnel ou contenue dans un fichier n'est pas légale par sa seule origine. Les autres dessins importés restent des observations ou des plans de projet. Un cas nécessitant un cadastre, une RGG ou un acte habilitant est dirigé vers les autorités et professionnels compétents ; la DGT décrit le cadre du cadastro et BUPi soumet l'identification en ligne à une vérification technique.

Ces méthodes se complètent : couches séparées (esquisse, observations_de_terrain, référence_légale_vérifiée), sources et droits affichés pour chaque objet, qualité et historique conservés. On peut superposer, comparer les écarts, demander une vérification et produire un plan de travail versionné, sans écraser silencieusement une limite légale avec un tracé satellite ou déplacer un relevé pour le faire coïncider. Ni le coût nul du premier levé, ni l'adhésion, ni un fond satellite ne certifient une limite. La V2 précisera les validations géométriques, géoréférencement, import sûr, quotas, conflits et exports ; son ouverture sera annoncée séparément du levé GNSS déjà disponible.

4. Rôle des applications complémentaires

Montrer les outils et leur bénéfice concret

L'accueil répond d'abord à la question « Qu'est-ce que QAPAS peut faire pour moi ? ». Quatre portes d'entrée explicites — cultiver ou posséder un terrain, découvrir ou participer, acheter des produits locaux, produire/transformer/commercer — donnent immédiatement une promesse concrète, des bénéfices compréhensibles et les applications les plus pertinentes. Le visiteur choisit lui-même sa porte d'entrée ; aucune catégorie n'est inférée ni enregistrée dans son compte. Un simple paramètre de parcours autorisé dans l'URL permet de poursuivre la même présentation sur la vue d'ensemble, de changer de choix ou de partager la page ; il peut apparaître dans les journaux techniques et les liens que le visiteur choisit de diffuser. Sans choix, les deux pages restent lisibles. Le levé du terrain est la première étape pratique pour la personne qui en possède ou cultive un, pas une condition pour découvrir QAPAS, acheter ou participer.

La vue d'ensemble présente un titre, une description concise et une galerie masonry de cartes illustrées pour toutes les applications publiques. La barre mondiale conserve deux accès distincts : l'icône vers /overview et le menu déroulant des applications. Le bouton « Par où commencer » ouvre une modale accessible avec les quatre prismes ; le prisme choisi filtre les visuels par les associations éditoriales déclarées dans qapas_landing, avec un paramètre d'URL partageable et un lien pour retrouver le catalogue complet. Les noms et états restent lisibles sur chaque visuel ; « à venir » ne suggère aucune disponibilité. Chaque carte mène à sa fiche et à son cahier spécifique. Les illustrations vectorielles originales de cette galerie sont conservées dans qapas-platform/public/images/overview-*.svg : elles ne sont ni des photos de propriétés ni des données personnelles, et leur source reste Platform. Les photos éditoriales éventuelles des fiches applicatives suivent séparément le circuit de validation Media Library et ses licences. Aucun gain chiffré, témoignage, vente fictive ni inscription non ouverte n'est annoncé.

Un visuel éditorial par application, facultatif tant qu'aucune image licenciée n'a été approuvée, peut être enregistré dans Spatie Laravel Media Library et édité avec le plugin officiel Filament. Le média public est une photo de l'activité, jamais une photo de propriété identifiable sans consentement. Avant publication : œuvre source, auteur, intitulé/texte alternatif, URL de provenance, licence permettant l'exploitation commerciale et l'adaptation, URL de licence, date et preuve de vérification, recadrage 16:9 contrôlé ; conserver l'original et distinguer l'adaptation. CC0, CC BY 4.0 et CC BY-SA 4.0 peuvent être étudiées individuellement ; BY et SA imposent leurs conditions sur les dérivés. Exclure NC/ND, droits de personnalité inconnus et géodonnées EXIF. Un manifeste public en lecture seule /applications/{id}/artwork.json expose seulement une photo approuvée, sa légende, son crédit, sa licence et l'URL du dérivé ; chaque installation distante n'accepte que le domaine QAPAS configuré, vérifie la réponse et peut copier le fichier avec crédit et licence conservés. Ne pas confondre synchronisation d'une illustration publique et échange de photos privées de membres. Aucun crédit de photo fictif ne sert de remplissage.

Visibilité commerciale choisie et carte de visite imprimable

Premier hôte pilote : préparer une maquette QAPAS pour un Toyota Dyna 150 ancien, cabine blanche et ridelles (« taipais ») vertes : lettrage vert sur portière, lettrage blanc sur panneaux verts, marque QAPAS originale et emplacement du code public de membre. Les fichiers vectoriels d'épreuve sont dans resources/brand/vehicle/ : aucune identité d'hôte, code de membre, URL personnelle ou homologation « John Deere » n'y est inventée. Avant de commander la découpe : mesurer réellement les panneaux et éviter poignées, nervures, catadioptres et inscriptions réglementaires ; remplacer le code après attribution et demander un BAT prépresse à l'imprimeur. La couleur verte peut rappeler la teinte demandée mais aucun nom, logo, animal bondissant ou combinaison vert-jaune d'une autre marque n'est utilisé comme signe QAPAS.

Un générateur commun de documents et goodies est planifié pour les membres autorisés : cartes de visite et de marché, autocollants de véhicules et cagettes, affiches de récolte, étiquettes non réglementaires, fiches de présentation d'hôte, courriers et dossiers selon les applications. Il assemble des modèles versionnés, champs explicitement sélectionnés du profil public, rôle/vendeur vérifié, médias licenciés et code opaque stable ; aperçu personnalisé privé, choix de langue, taille, fond perdu, gabarit de découpe, contrôle QR et export SVG/PDF/PDF-X selon les capacités réelles de production. Une facture, une étiquette alimentaire obligatoire ou un dépôt administratif suivent leurs propres règles et ne sont jamais automatiquement remplacés par un goodie. Modèles associatifs mis à jour en un lieu ; fichiers privés accessibles au seul titulaire ou opérateur habilité, avec durée de conservation et possibilité de révocation du QR public. La marque QAPAS est autorisée pour les membres en règle selon une charte à publier.

Community fournit au membre à jour un assistant privé de préparation d'un profil public facultatif ; le propriétaire d'un quintal, professionnel ou non, choisit séparément s'il expose son identité commerciale, un descriptif de production, une zone assez large, un contact relayé et les offres Marketplace qu'il veut publier. Les cultures privées et la position exacte ne deviennent jamais des publicités. La validation de profil, des droits de vente et des offres par le vendeur réel précède toute diffusion. L'absence de page publique interdit la génération de cartes distribuables.

Un modèle QAPAS de carte de visite (recto/verso, SVG ou PDF vectoriel accessible, export PDF/X après contrôle prépresse) offre un aperçu et un fichier imprimable : format 85 × 55 mm à vérifier auprès de l'imprimeur, fond perdu 3 mm, marge de sécurité 3 mm, polices incorporées ou converties, CMJN/profil et résolution des éventuels visuels selon l'imprimeur. Il comprend un nom/publicité choisis, rôle vérifié, logo QAPAS sous charte, identifiant public de membre aléatoire sans date ni séquence, QR pointant seulement vers la page publique permanente du membre, et contact volontaire. Le QR n'embarque ni identité privée, ni NIF, ni données d'offre susceptibles d'expirer ; URL courte non énumérable, désactivation/renouvellement possibles. Un « matricule » public est un alias de présentation opaque, distinct de l'identifiant interne et du numéro légal éventuel. On scanne et relit l'épreuve avant impression ; profil révoqué ou cotisation échue → page d'orientation neutre, sans données privées. Une carte déjà imprimée ne peut être retirée : avertir clairement avant export.

La page publique peut proposer sa formule de panier, vendue directement à particuliers ou professionnels par son vendeur réel : contenu, quantité, période, zone/point de retrait, conditions, prix TTC affiché au consommateur et frais éventuels clairement distingués ; pour les professionnels, prix hors taxe et détail TVA éventuel seulement si le statut du vendeur et la règle applicable le justifient. Le cas d'un vendeur sous régime d'exonération doit être indiqué correctement : ne jamais afficher une TVA collectée imaginaire sous prétexte de prix « TVA incluse ». Vérifier obligations de facturation, CAE et information précontractuelle avant publication d'une offre. QAPAS facture uniquement ses services ; carte QAPAS ne vaut ni label de qualité ni garantie du produit.

Centre documentaire de chaque application membre

Compte, appartenance et vérification du vendeur

À l'inscription réelle (actuellement non ouverte), choisir sans valeur implicite « particulier » ou « professionnel » ; recueillir nom, email, pays, contact nécessaire et mot de passe solide ou fournisseur d'identité vérifié. Confirmer l'email ; consigner les versions et empreintes des textes juridiques effectivement adoptés, la date et le contexte de leur acceptation, sans conserver l'IP brute dans l'audit de consentement. Mot de passe Argon2id, session régénérée, récupération et inscription protégées contre l'énumération et l'abus. Profil public créé désactivé. Les textes présents sous /policies sont des brouillons et ne permettent pas encore une acceptation juridique définitive : tant que l'entité, les coordonnées, les traductions et les versions opératoires ne sont pas validées, le parcours doit échouer fermé.

La fiche de membre en ordre comporte adresse de facturation et numéro fiscal privés et une capacité de vente distincte. Le professionnel déclare en plus dénomination, numéro/registre pertinent, pays fiscal, régime de TVA, activité CAE réellement exercée, justificatifs et pouvoir de représentation si nécessaire. Une personne physique non professionnelle qui propose de vendre remplit aussi son régime d'activité et ses pièces appropriées : se déclarer « particulier » ne dispense pas de vérifier les obligations fiscales applicables. La saisie de nombres valides, un numéro de TVA ou un CAE ne vérifie pas l'identité ni la représentation ; demandes commerciales en brouillon tant que le contrôle indépendant et audité n'est pas achevé. Ne pas demander au simple curieux non vendeur des pièces sans nécessité. Le statut professionnel, les coordonnées légales dues avant un contrat et les données privées restent séparés du profil public ; les données de facturation sont chiffrées au repos et accessibles sous permissions resserrées.

Chaque membre peut gérer, lorsqu'un parcours sécurisé est livré, un avatar privé et une galerie photo privée avec choix individuel de publication. En l'absence de photo : avatar SVG spirographique QAPAS et vignette illustrative clairement signalée ; aucun emplacement vide ni visage factice. Originaux dans un disque privé, dérivés WebP 128/256/512 px pour avatar et 400/800/1200 px pour galerie ; diffusion contrôlée des seules images consenties, sans EXIF/GPS, avec suppression et cache invalidé. La page publique et les exports n'affichent jamais QR d'authentification, QR de rencontre ni code à usage unique ; le propriétaire connecté peut consulter ses propres QR sur une route privée et réauthentifiée si nécessaire. Le QR statique d'une carte publique pointe uniquement vers la page publique et ne contient pas de donnée privée.

Les sept projets de politiques communes sont reliés depuis le pied de page commun et ses manifestes distants : conditions, confidentialité, cookies, participation, ventes, médias, signalements. Chaque version adoptée devra porter responsable légal, coordonnées, langue, date d'effet, historique, voie d'exercice des droits et, selon le cas, gestion explicite des préférences. Ne jamais traiter ces brouillons visibles comme des textes adoptés ou des cases précochées.

Project Designer dispose déjà d'un inventaire public de collections DGT pour préparer des calques datés : OrtoSat, COS, CAOP, cadastro, CRUS, REN et RAN. Pour un projet autorisé, interroger l'emprise bornée, documenter la version et découper au périmètre privé ; ne jamais transformer une intersection cartographique en autorisation, titre ou diagnostic juridique définitif. Voir le cahier de Project Designer pour les collections et champs vérifiés.

Chaque application destinée aux membres porte une section Ressources éditée par ses responsables : vidéothèque (lien externe, auteur, durée, langue, droits/conditions et date de contrôle), bibliographie (édition et référence), textes officiels versionnés, formulaires utiles avec autorité compétente et date de vérification, et modèles de courriers paramétrables. La fiche précise pour qui, dans quel cas et dans quel territoire le document est utile. Chercher par besoin et langue, marquer les liens obsolètes, permettre la proposition d'une ressource soumise à revue. Les cours et examens restent propres à chaque application. Les vidéos externes ne sont pas copiées ou intégrées sans droits ; l'ouverture d'un lien ne transmet pas les données privées de l'utilisateur à un service tiers sans signalement.

L'IA prépare un brouillon privé de lettre ou de dossier à partir des seules données que le membre choisit de fournir : signale les pièces manquantes et cite la règle ou le formulaire daté, ne remplit jamais une parcelle, un droit, une surface ou un avis non vérifié, et exige la relecture du membre et, pour les actes réservés, d'un professionnel. Pas d'envoi automatique à l'administration. Version du modèle, sources, modifications et auteur conservés dans l'espace privé selon la politique de conservation ; suppression et droits d'accès contrôlés. La base documentaire approuvée est séparée des consignes de développement et des dossiers privés d'autres membres.

Dans Project Designer, un assistant distingue le PIP (pedido de informação prévia), la comunicação prévia municipale, les démarches pouvant concerner REN, les avis liés à RAN et d'autres contraintes : PDM et ses plans de zonage/conditionnants, servitudes, patrimoine, eau, accès et prévention incendie selon le terrain. Une superposition partielle REN/RAN est signalée comme indice à confronter aux cartes et actes officiels, jamais comme autorisation automatique ni interdiction absolue ; plusieurs procédures peuvent se cumuler. Il compose un plan de questions, un tableau des preuves et des destinataires possibles (Câmara, CCDR compétente, entité régionale RAN), puis invite à confirmer procédure, formulaires, date et signataire avec eux avant dépôt. L'assistant n'assimile pas une comunicação prévia REN à celle du RJUE.

Références de démarrage à vérifier au cas par cas : DGT, SNIT, gov.pt, urbanização e edificação, réforme RJUE publiée en 2026, CCDR, questions REN et questions RAN : ces deux dernières pages décrivent la région LVT et servent d'orientation, pas de formulaire pour Covilhã. Adapter aux instances du Centro.

QAPAS détient le parcours quintal, les permissions et le suivi agroécologique. Topographie et planification est la première application complémentaire : elle documente lieux, aménagements et observations spatiales utiles aux projets de culture et à leur suivi. Son fonctionnement et son déploiement restent indépendants. Une V2 élargira le relevé initial au plan complet du quintal ou d'une quinta regroupant plusieurs quintais : chemins, obstacles, constructions, arbres et couvert végétal, réseaux d'eau et d'électricité, avec niveau de précision indiqué pour chaque objet.

Le cahier de V2 de Topographie et planification détaille la consolidation des couches, la précision facultative au centimètre, la provenance et les droits de chaque quintal. Les zones de polyculture et leur suivi agronomique s'appuient sur ce plan sans altérer les observations spatiales.

Cette V2 proposera des modèles de missions sans imposer de formulaire unique : bâtiments existants (implantation, fenêtres, hauteur des murs et faîte), chemins et obstacles, réseau électrique, ressources hydriques, installation d'irrigation, arbres et couverts, noyaux d'espèces invasives. Le modèle suggère une méthode, des objets et des questions ; le responsable peut l'adapter et documenter un élément non observé. Les hauteurs inaccessibles et réseaux enterrés restent explicitement à confirmer, sans mesure inventée. Une mission libre demeure possible. Ces modèles et l'inventaire associé sont encore à développer dans l'application topographique.

La transition entre applications conserve une chaîne de provenance : observation située et datée → interprétation → décision → intervention → observation de suivi. Le propriétaire choisit quel livrable topographique rattacher à quel quintal ou projet. Les mesures restent des mesures ; une hypothèse agronomique ou une décision ne réécrit pas le relevé source. Les échanges utilisent des objets versionnés, des références stables et des contrôles d'accès à chaque installation ; le manifeste public des applications ne transporte jamais de données de quintal ni le statut de membre.

Exemple : le relevé d'une terrasse envahie de mimosas documente relief et accès ; le projet de restauration consigne séparément diagnostic, plan, travaux et suivi de la végétation. Une même étude peut être exportée vers un autre projet sans transformer ses observations en décisions implicites.

Le catalogue public des applications présente leurs cartes d'identité et leur disponibilité. Il affiche Topographie et planification comme disponible lorsqu'elle l'est, et les autres outils comme à venir tant qu'ils ne sont pas utilisables. Une barre QAPAS commune permet de naviguer entre installations ; la navigation métier et la session restent propres à chacune. Les cartes d'identité sont téléchargées uniquement depuis des origines autorisées et ne contiennent que des informations publiques.

Noms publics retenus pour les cartes : terrain → QAPAS — Farm Manager (gestion de cultures), projets → QAPAS — Project Designer (projets et scénarios), collecte → QAPAS — Harvest Supply (nom provisoire : lots de récolte et approvisionnement des points et producteurs-revendeurs), biomasse → QAPAS — Mimosa (pilote à étudier), paniers → QAPAS — Marketplace (paniers et vente aux clients). QAPAS — Community (compagnonnage) réunit adhésion, hôtes, compagnons, entraide, offres et demandes de services, stages et ateliers : services n'est plus une application autonome. Les autres cartes sont Topographie et planification, QAPAS — Ruchers et apiculture, QAPAS — Packer et QAPAS — Farmers’ Games (jeux d’hiver planifiés) ; les livraisons aux clients font partie de Marketplace et les applications privées sur mesure restent une prestation de plateforme. Les identifiants techniques des cartes conservées restent stables. Les anciens chemins de Services redirigent vers Community, mais leurs suggestions ou contributions historiques ne sont pas réaffectées sans audit comptable. Chaque carte explique en une phrase son usage réel dans les six langues ; aucun titre ne vaut annonce de fonctionnalité déjà livrée. Aide & Contact reste une fonction transversale accessible par navigation et pied de page, sans carte publique.

Chaque carte ouvre une fiche publique permanente sur QAPAS, y compris lorsqu'une application n'a pas encore d'installation accessible. La fiche donne l'objectif, les usages prévus, la version déjà disponible s'il y en a une, la version en cours de développement si sa réalisation est confirmée et la version simplement planifiée. Elle distingue ces états sans annoncer comme réalisée une fonction prévue dans le cahier des charges ; une phase non documentée est indiquée comme telle. Les dates et versions affichées proviennent d'informations éditoriales vérifiées ou de l'identité publique autorisée de l'application, jamais d'un nom de branche deviné. Depuis la fiche, un lien « ouvrir » peut conduire vers l'application disponible ; les autres liens mènent à la fiche QAPAS et non à une URL inactive. Cette page existe aussi dans les menus communs, sur ordinateur et sur téléphone, et reste accessible sans compte dans les six langues.

La fiche prévoit un formulaire de proposition de fonctionnalité réservé aux membres actifs : application visée, besoin concret, description courte et bénéfice attendu, sans exiger de données personnelles sur des tiers ni de coordonnées de quintal. Le serveur vérifie séparément l'authentification et l'adhésion active au dépôt, limite la fréquence, contrôle taille et contenu, rattache la demande au compte, accuse réception et donne une référence privée. Le membre peut revoir ses demandes ; l'équipe les examine avant publication éventuelle d'un résumé anonymisé. Dépôt ne signifie ni commande de développement ni acceptation du besoin. Tant que le volet d’adhésion de Community ne fournit pas de preuve fiable d'adhésion active, l'envoi est refusé côté serveur : la connexion du compte local de démonstration ne fait pas d'un visiteur un membre réel.

Financer une application commune. Chaque fiche et chaque carte d'application commune comporte un bouton « Donner » menant à son objectif de financement ; une prestation privée sur mesure relève des services de la plateforme, financés uniquement par devis individuel. Le budget par application distingue temps de travail rémunéré à un tarif et une durée expliqués, coûts vérifiables de calcul et de jetons d'IA, hébergement et essais, puis achats, prêt ou amortissement des équipements nécessaires à sa preuve de concept (par exemple GNSS et accessoires topographiques, ou balance conforme, lecteur et poste de conditionnement). Décrire qui paie, à qui appartiendra le matériel acheté, les justificatifs, les dépenses déjà prises en charge et la part qui bénéficie à plusieurs applications. Objectif, contributions effectivement reçues, dépenses engagées et solde sont datés, rapprochés et publiés en agrégats et, pour la liste publique, sous pseudonyme ou nom choisi et avec montant seulement après consentements explicites distincts du donateur ; les contributions anonymes restent dans les totaux. Aucun montant, pourcentage, équipement acquis ou état « financement atteint » n'est inventé ; si le budget ou la collecte ne sont pas validés, le bouton mène à une présentation qui dit clairement que le versement n'est pas encore ouvert.

Le financeur sait avant paiement qui reçoit les fonds, si le versement est un don sans contrepartie ou une prévente contractuelle, ce qui est livré en cas de réussite ou d'échec, et si un justificatif fiscal est applicable après vérification. QAPAS ne promet ni déduction fiscale ni retour sur investissement. Le prestataire agréé encaisse selon le montage retenu ; l'application ne stocke pas de carte ni ne présente une intention comme recette encaissée. Partager les méthodes, les spécifications et le code ou les livrables que les accords autorisent, puis vendre une preuve de concept reproductible, une installation, une formation ou un support, est un modèle envisageable à chiffrer. La licence, les droits des contributeurs et fournisseurs, l'éventuelle vente du prototype matériel et l'affectation de ses recettes sont fixés avant collecte ; une contribution ne cède pas automatiquement la propriété intellectuelle d'autrui et n'ouvre aucun droit sur l'installation privée d'un client.

Accès aux versions et financement sans ambiguïté

Les pages de présentation, cahiers des charges, règles d'adhésion, informations légales, contact humain et demandes relatives à la protection des données restent consultables sans compte, abonnement ni don. Une inscription gratuite donne accès aux modes de démonstration pertinents pour l'utilisateur final, avec données fictives, et au levé topographique de base privé dès leur livraison : ni cotisation ni don n'y sont exigés. L'utilisation effective et gratuite sans frais propres à l'application d'une version livrée est réservée à une personne inscrite, dont la cotisation d'adhésion est à jour, lorsque l'objectif vérifié de cette version a été atteint à 100 % par les fonds nets réellement encaissés et affectés à ce jalon. « Gratuit » signifie inclus dans l'adhésion : il ne promet ni cotisation nulle ni stages, hébergements ou services individuels gratuits. Le taux est recalculé sur l'objectif budgétaire approuvé de la version, les dons encaissés nets de remboursements et, le cas échéant, des recettes de service affectées comptabilisées dans une catégorie séparée ; ni intention de don, ni contribution contestée, ni paiement d'une autre version n'est un financement acquis. Le pourcentage de financement seul ne remplace pas la réception technique et la disponibilité effective de la version.

Une V1 déjà livrée et financée reste accessible aux membres en règle lorsqu'une V2 recherche son financement ; les besoins de trésorerie de V2 ne retirent pas rétroactivement l'accès à V1. Un remboursement exceptionnel après mise en production ne déclenche pas sans préavis une perte automatique de droits : réserve de financement, remédiation et transparence sont prévues. Le passage à une nouvelle version décrit le périmètre, le budget et les fonctions concernées, puis n'est déclaré « financé » qu'après rapprochement comptable. Chaque installation distincte vérifie côté serveur l'adhésion, la version, l'état de financement et ses propres permissions à l'aide d'une preuve de portée limitée, révocable et à durée courte ; la navigation publique et l'ouverture de la page d'accueil d'une application ne donnent jamais l'accès métier. La base de campagnes actuelle suit les projets par application et ne sait pas encore représenter plusieurs versions : une migration et la preuve interapplications restent nécessaires avant toute activation de cette règle.

Contrat technique à livrer : une version possède une référence stable (application_id, release_code), un budget approuvé immuable ou amendé avec historique, un état de livraison distinct de l'état de financement et des affectations uniques et traçables de recettes nettes. Chaque affectation porte son origine (don ou service bêta), le montant confirmé, les remboursements et la version bénéficiaire, sans permettre de compter deux fois la même recette ; le tableau public distingue ces catégories. Le moteur de droits distingue registered_demo (compte vérifié et données fictives uniquement), registered_survey (compte vérifié, levé topographique de base du seul titulaire et quotas publiés) et member_included (compte valide, cotisation en ordre, version métier livrée, objectif confirmé atteint et autorisation locale). Ni registered_demo ni registered_survey n'ouvrent les autres applications ou les données d'autrui. Le droit beta_paid exige en plus la prestation de bêta effectivement commandée et ses conditions acceptées ; un don isolé n'accorde jamais ces droits. Les installations reçoivent une preuve signée à portée et durée limitées, revérifient les permissions du quintal et échouent de façon sûre si elle est expirée. Une modification de budget ne peut transformer rétroactivement des droits déjà promis sans décision documentée et information des intéressés.

Un mode de démonstration isolé, réservé à un compte inscrit pour les applications pertinentes à l'utilisateur final, montre l'interface avec des données fictives, sans écriture sur un vrai quintal ni visibilité sur des utilisateurs réels ; aucun paiement ni cotisation pour essayer. Il ne constitue pas un droit d'usage gratuit de l'application en production ; la connexion locale fictive du développeur ne prouve pas une adhésion. Une bêta réelle peut être offerte aux membres en règle par un accès anticipé payant : le prix, la durée, les fonctions incomplètes, la possibilité de panne, les conditions d'annulation et de remboursement, la facture et la qualité de prestataire sont annoncés avant commande. Ce paiement est une recette de service, pas un don converti après coup ; il ne s’applique ni aux démonstrations ni au levé topographique de base gratuits. Il peut financer le développement si cette affectation est publiée et rapprochée ; dans le compteur, il figure séparément des dons.

Un don de développement demeure volontaire, indépendant de l'accès : une personne inscrite peut tester les démonstrations et faire son levé de base sans donner ; un membre peut payer une bêta sans donner, ou donner sans acheter la bêta. Nom ou pseudonyme et montant visibles sur le mur de soutien exigent deux choix distincts, désactivés par défaut, révocables pour l'affichage public ; les reçus comptables restent conservés selon les obligations applicables. Des remerciements aux bêta-testeurs peuvent être proposés avec leur accord, distincts de la liste des donateurs et sans révéler leur consommation ni leur montant. Ne jamais promettre une déduction fiscale ou présenter des frais obligatoires comme mécénat. Les règles fiscales portugaises sur les donativos et le consentement à la publication de données guident la validation avant ouverture.

En développement local, une commande de lancement copiable est fournie près de la carte de chaque application effectivement configurée, par exemple php artisan serve --port=8001 pour l'outil topographique ; QAPAS utilise le port 8000. Ces outils locaux ne s'affichent pas en production.

Annuaire transversal des intervenants locaux (« passants »)

Chaque application métier prévoit un accès contextualisé à un même annuaire QAPAS de personnes volontaires susceptibles d'aider les quinteiros. « Passant » est le terme de travail choisi pour la transmission des gestes et des connaissances ; les interfaces affichent aussi la profession, le rôle réel et les limites de la prestation. L'inscription comme membre ne crée aucun profil public : l'intervenant demande sa publication, sélectionne ses domaines, une zone générale de déplacement, langues, disponibilités, modes d'intervention, tarifs ou devis, et peut suspendre ou retirer son offre. La plateforme vérifie séparément identité, titre ou habilitation lorsqu'ils sont revendiqués, assurance et conditions nécessaires au service proposé ; un simple témoignage d'expérience n'est pas présenté comme une qualification réglementée.

QAPAS conserve le profil et les règles de découverte ; une application ne lit qu'une projection consentie et filtrée par métier, zone générale et langue via un contrat privé versionné. Le manifeste de navigation et les cartes d'identité des applications ne transportent ni profils, ni coordonnées personnelles, ni données des quintais. La demande est envoyée à un ou plusieurs intervenants choisis par le membre : besoin et période → devis ou proposition → accord et rémunération affichée → accès temporaire aux seuls éléments nécessaires → compte rendu, facture et éventuel litige. Chaque installation vérifie ses propres permissions avant d'ouvrir carte, livrable ou document ; la réservation d'une prestation ne donne pas un accès général à la quinta. L'ordre de présentation ne s'achète pas en secret : critères de recherche, offres sponsorisées éventuelles et conflits d'intérêts sont visibles ; aucun classement public des habitants ou recommandation exclusive par défaut.

L'annuaire, la prise de contact et les devis sont planifiés. Aucune personne réelle n'y figure sans son accord, aucun titre n'est déclaré vérifié avant contrôle, et les réservations ou paiements n'ouvrent qu'après validation du contrat applicable, de la facturation et du prestataire de paiement. La première intégration utile est le filtre topographique « planification » ou « démarche foncière », précisément parce que les livrables, les compétences et les habilitations ne sont pas interchangeables.

Profil de membre, hôte et compagnon : une identité, trois choix

Le membre en ordre de cotisation peut choisir de devenir hôte, compagnon, les deux ou aucun. Le compte privé, l'adhésion et la fiche publique sont des objets différents : aucun paiement, inscription, rôle ou participation n'active un profil public par défaut. QAPAS est l'autorité du dossier privé et des autorisations ; Community conserve les fiches d'accueil, de compagnon et les rencontres. Son cahier applicatif définit les assistants guidés et les critères de réception. Une même personne peut proposer plusieurs lieux d'accueil avec des règles distinctes, sans publier leurs contours ni les autres occupants.

L'assistant transversal de profil public propose partage nul par défaut, partiel par champ et audience, ou « total » uniquement pour une sélection de champs publiables : la publicité d'une biographie n'autorise jamais celle d'une adresse de facturation, d'un téléphone, de documents d'identité, d'une date de naissance, d'un trajet, d'un calendrier d'absence, d'un plan de quintal ou d'une donnée de santé. Audience par rubrique : propriétaire, invité explicitement, membre en règle ou public ; un champ n'est pas plus public que son parent. Brouillon, aperçu propriétaire signé à courte durée, confirmation, correction et retrait explicites ; seules des projections filtrées quittent la plateforme vers les applications. Recherche, médias, URL, exports et API vérifient les mêmes droits côté serveur. Coordonnées de contact relayées, localisation générale, identifiants publics opaques sans date, photos publiques sans EXIF/GPS, originaux privés, aucune indexation publique par défaut. Le partage total ne dispense jamais de l'accord des tiers photographiés ou nommés. La CNPD rappelle les droits d'accès, de rectification et d'effacement et le CEPD expose la protection par défaut.

L'assistant hôte demande objectif de la rencontre, pratiques réellement exercées, photos autorisées, activités proposées, prérequis théoriques, rythme et tâches, puis moyens d'accueil (sac à dos, tente, van, camping-car), sanitaires, eau, énergie, repas éventuels, prix et responsabilités selon le régime choisi. Une fiche reste privée jusqu'à la vérification du droit d'accueillir et des conditions applicables au site, à l'hébergement et au travail ; l'adresse précise n'est transmise qu'après acceptation. L'assistant compagnon distingue compétences déclarées, apports concrets, attentes et théorie validée, et règle séparément la visibilité de son histoire de rencontres. Un rôle ne donne pas automatiquement à son titulaire accès aux données de l'autre ; l'expiration de l'adhésion suspend les annonces et nouvelles candidatures.

Pour une rencontre acceptée, un QR à jeton aléatoire éphémère et unique affiché par le compagnon est scanné par l'hôte authentifié. Une confirmation serveur idempotente crée une attestation privée minimale même sans texte ; le QR seul n'atteste ni travail, ni heures, ni qualification. Commentaires favorables, visibilité de chaque entrée dans l'historique, identité de l'hôte et éventuelles photos relèvent de choix distincts des personnes concernées ; désaccords et signalements restent privés avec recours humain. Aucune note publique des habitants ou liste de « mauvais » participants. Ce parcours est planifié, sans fiche d'hôte, scan, certification ou publication réelle actuellement disponible ; il ne change pas le contrat des données topographiques.

Équipe QAPAS, trombinoscope et responsabilités par application

L'équipe qui conçoit, développe, anime et administre les applications relève de la plateforme QAPAS. Elle se distingue des propriétaires de quintais, des candidats du vivier de recrutement, des intervenants de Community et de l'annuaire transversal des intervenants agricoles. Une même personne peut occuper plusieurs de ces fonctions, mais chacune a son propre dossier, son fondement d'accès et ses règles de publication. Être membre de l'association, figurer dans l'équipe ou être présent dans un trombinoscope ne confère aucun privilège d'administration par implication.

Un dossier d'équipe porte un public_id UUIDv4 sans date incorporée, le type d'acteur (personne ou agent_logiciel), son rattachement interne QAPAS ou externe sous mandat, le compte d'identité associé lorsqu'il existe, l'état d'invitation/vérification/activité/suspension, les dates de mandat et un responsable humain désigné. Un prestataire externe peut intervenir sous un contrat limité sans être membre cotisant de l'association ; il ne reçoit que l'accès technique nécessaire. Un agent IA a une identité de service, son propriétaire humain, sa finalité, ses outils autorisés, des plafonds de dépenses et un arrêt d'urgence ; il n'a ni identité civile fictive, ni statut de salarié, ni capacité d'accorder des droits ou de prendre seul une décision sensible.

La plateforme gère des affectations distinctes par identifiant stable d'application : une personne peut être contributrice et traductrice pour Farm Manager, animatrice pour Community et sans aucun droit sur Marketplace. Chaque affectation regroupe un ou plusieurs rôles de travail, les permissions explicites réellement accordées, sa portée (application, projet ou ressource, si utile), sa date d'effet, son expiration, la raison, l'auteur et la version de la définition des permissions. Les applications définissent et publient en privé leurs capacités disponibles (topography.mission.review, manager.content.edit, companions.workshop.publish, assistance.ticket.handle à titre d'exemples) ; QAPAS peut les attribuer dans la portée approuvée, sans inventer des capacités qu'une application ne reconnaît pas. Un rôle est un modèle éditable de permissions, pas un is_admin global. Les permissions financières, l'administration des identités, la publication des politiques et la gestion des intégrations demandent une validation renforcée et une trace de l'approbateur distinct lorsque nécessaire.

Le trombinoscope public propose un filtre par application et fonctions, sans ordre de prestige ni indexation de privilèges. Chaque personne décide séparément de la publication du nom d'affichage, du portrait, de la biographie, de son rattachement externe et du numéro professionnel ; l'absence de portrait ou de téléphone ne bloque pas le travail. Pour un salarié, éviter de supposer que le consentement est forcément libre dans le contexte de travail : justifier la base de publication, offrir une alternative et obtenir une revue appropriée. Seule une dérivée volontairement publiée est placée sur un support public ; l'original reste privé, et la dépublication invalide aussi les caches et anciennes URLs publiques selon des délais annoncés. La CNPD distingue le consentement libre des traitements nécessaires dans la relation de travail.

Le formulaire de contact par membre d'équipe utilise une référence publique aléatoire ; le serveur retrouve l'affectation active et son canal sans publier l'adresse électronique du destinataire. Catégorie, application, contenu, anti-abus, pièces autorisées, accusé de réception et suivi privé ; un agent peut aider au tri mais n'envoie pas de réponse sensible sous l'identité d'un humain. Numéros professionnels visibles uniquement sur décision explicite selon la fonction (urgence d'exploitation, accueil, presse, par exemple), avec horaires ou préférences ; un numéro désactivé disparaît des profils et annuaires autorisés. Les demandes administratives ou relatives aux données personnelles disposent toujours d'un contact de l'organisation même si aucun profil individuel n'est public.

Administration Filament 5 : un espace « Équipe des applications » distinct de l'annuaire métier réunit fiches d'acteurs, portraits/publication, affectations par application, modèles de rôles, capacités déclarées, clients d'intégration et journal de changements. Dans les ressources Filament, utiliser sections, grilles adaptatives, tables, infolists, actions de vérification et de révocation ; les policies Laravel protègent la lecture et l'écriture et chaque action personnalisée revérifie sa propre autorisation. Guard d'administrateurs séparé du compte utilisateur ordinaire ; invitation nominative, authentification forte, accès temporaires aux prestataires, limitation du nombre de titulaires des permissions élevées et départ/révocation testés avant ouverture. Le personnel de support peut traiter un formulaire sans pouvoir attribuer des rôles. L'annuaire des « passants » peut partager la présentation et certains champs génériques, jamais son autorisation ou son workflow de publication avec l'équipe technique. La documentation Filament 5 rappelle notamment que l'autorisation automatique ne couvre pas les actions personnalisées.

Répercussion des affectations dans les installations complémentaires

QAPAS est la source des affectations d'équipe ; chaque application est responsable de ses décisions d'accès locales. Les applications restent sur leurs bases, sessions et guards séparés. QAPAS n'écrit pas directement dans leurs tables d'utilisateurs et ne propage jamais une session Filament. Pour chaque installation enregistrée dans une liste privée autorisée, un client OAuth2 Passport propre à l'installation authentifie ses lectures de machine à machine d'une API privée versionnée QAPAS. Le jeton client ne représente aucun être humain : une personne passe par son propre mécanisme d'identification et l'application relie son public_id UUIDv4 QAPAS à son identité locale avec preuve appropriée. Aucun identifiant de personne, rôle ou clé de service n'apparaît dans /navigation/v1.json ni dans la carte d'identité publique.

Contrat minimum de synchronisation : (application_id, subject_public_id, principal_type, role_codes, capability_codes, scope, effective_at, expires_at, status, revision, policy_version) ; seuls les dossiers relatifs à l'application appelante sont visibles et les capacités inconnues sont refusées. L'API fournit état initial et deltas ordonnés avec curseur opaque, révisions monotones et suppression explicite ; l'installation garde une projection minimale et rapproche périodiquement les écarts. Une notification d'invalidation peut accélérer la lecture, mais un simple envoi QAPAS → API de l'application sans accusé, reprise et contrôle de version ne suffit pas pour retirer un droit. TLS, identité du client, scopes restreints, limitation de débit, journaux d'échange expurgés, secrets par installation et rotation/révocation sont exigés. Le grant client_credentials de Passport 13 sert à authentifier l'installation, tandis que les policies et gates de Laravel 13 évaluent réellement l'action d'un acteur sur une ressource.

Pour une écriture d'administration sensible, vérifier aussi en ligne une preuve récente de l'affectation et de son état ; en cas d'indisponibilité ou de révision manquante, refuser l'opération sensible. La simple consultation éventuellement permise en mode dégradé dépend d'une preuve antérieure encore valide et de la politique propre à l'application. Un retrait de rôle doit bloquer l'opération suivante, révoquer les jetons concernés si possible et être observable depuis QAPAS ; une affectation ne remplace jamais le contrôle local du quintal, des données personnelles ou de la facture. Tester le cycle invitation → autorisation limitée → diffusion → modification → suspension/révocation immédiate → hors-ligne/reprise, y compris un agent IA arrêté et un prestataire externe arrivé au terme de son mandat. Cet espace Filament et l'API privée sont planifiés, sans droit interapplications actif à ce jour.

Socle clonable des applications clientes QAPAS

Après stabilisation du compte et des contrats d'intégration, créer un template d'application Laravel autonome pour démarrer les futures installations QAPAS et, si cela apporte un bénéfice vérifié, rapprocher les applications existantes comme Topography et Farm Sharing. Le template est un projet clonable versionné ; il n'est ni une installation métier déjà livrée ni une seconde base de données de la plateforme. Une application peut utiliser certains services partagés sans dépendre de tous. Distinguer trois périmètres, avec propriétaire du code et mode de mise à jour explicites :

Le socle ne recopie pas les tables privées de QAPAS et ne partage ni cookie, ni session, ni garde d'administrateur, ni clé Passport entre installations. Le manifeste public ne fournit que la présentation et les liens publics ; les données de membre, droits et livrables utilisent des contrats privés distincts, limités au contexte autorisé. Un client client_credentials identifie l'installation ; toute action d'une personne exige en plus une identité humaine prouvée et les politiques locales. Le flux humain code d'autorisation + PKCE est maintenant livré par Platform et qapas-application, et s'active client par client avec retour enregistré et scope qapas:identity. Il prouve le sujet pour une session locale, sans constituer une preuve d'adhésion, de rôle ni de permission métier. Le composant commun offre le repli de navigation prévu plus haut, sans accorder de droits lorsque QAPAS est indisponible.

Réception du template : générer deux installations de démonstration avec identifiants, domaines locaux, bases, clés et sessions distincts ; les installer depuis une version figée, exécuter migrations et tests, puis vérifier navigation localisée et repli hors ligne. Une révocation de l'accès privé bloque les écritures concernées ; un utilisateur ou un client OAuth d'une installation ne lit pas les données de l'autre. Faire évoluer une version du socle, appliquer sa migration de manière contrôlée et vérifier que les tests métier et les données des deux clones restent intacts. Documenter comment adopter le template dans Topography et Farm Sharing par étapes, sans remplacer leur code existant ni interrompre leur développement ; leur conformité au template reste à démontrer. Ce chantier suit la sécurisation de l'inscription de la plateforme et précède la duplication de nouveaux projets clients.

E-learning intégré aux applications et langage commun

Chaque application est responsable de son e-learning, pas Community. Son cahier applicatif précise les publics, les gestes ou décisions étudiés, les risques, les contenus, les prérequis, l'examen éventuel et qui peut voir le module. Une même application peut avoir un parcours pour membres ou intervenants et des modules strictement internes pour ses administrateurs (policies Laravel, gestion d'incidents, confidentialité, règles de publication, Filament). Les formations internes, questions, réponses, résultats et instructions d'exploitation ne figurent jamais dans la carte publique, le manifeste, un syllabus public ou le corpus de l'assistant d'aide. Une formation ne confère pas un rôle : l'affectation explicite et les policies restent nécessaires. QAPAS fournit le contrat commun d'identité, de statut et de preuve, et peut financer des supports de départ ; l'application conserve syllabus, questions et données des apprenants dans sa base et sa session.

Contrat pédagogique commun : identifiant stable d'application et de module, version et langue, public autorisé (public, membre, intervenant ou interne), objectifs observables, contenu sourcé, auteurs et droits, risques et limites, seuil et questions de sécurité, conditions de nouvelle tentative, durée de validité et procédure de correction. QAPAS peut proposer des cursus pilotes ; le responsable humain du domaine valide syllabus, banque de questions et traductions avant ouverture. L'IA peut aider à créer des exercices, expliquer les erreurs et produire une attestation interne, mais une réussite théorique repose sur un barème vérifiable approuvé humainement ; réponse ambiguë et contestation ont un recours humain. L'attestation minimale indique module, version, titulaire, date, validité et portée, avec référence aléatoire non prédictible ; elle n'est ni un diplôme officiel ni la preuve d'une aptitude pratique. Le régime DGERT de certification des entités formatrices est distinct de ces attestations. Le CEPD rappelle les garanties pour les décisions entièrement automatisées aux effets significatifs.

Contribution des hôtes et des pairs : un hôte peut suivre les modules pertinents, passer l'examen et proposer du contenu ou des questions à l'application propriétaire. Proposition en brouillon, sources et droits contrôlés, revue par un pair compétent distinct de l'auteur, validation éditoriale avec traçabilité et gestion des conflits d'intérêts ; personne ne valide seule ses propres questions ni ne change en secret un examen qui s'applique à ses candidats. Publication par version avec crédit choisi, traduction relue et correction/révocation rapide en cas d'erreur de sécurité. Une modification substantielle des risques peut exiger un nouvel examen des personnes concernées, avec information et recours.

Passage à l'activité chez un hôte : avant d'accepter une candidature de compagnon ou de bénévole pour participer à un quintal, Community doit vérifier côté serveur que les attestations des modules pertinents sont valides, y compris les règles communes d'accueil s'il y en a. Le contrat privé ne transmet à Community que module, version, validité et statut pour la mission considérée, jamais les réponses, notes détaillées, coordonnées du quintal ou données internes d'administration. L'indisponibilité, l'expiration ou la révocation suspend la candidature ; l'accord de l'hôte, la sécurité du lieu, les titres nécessaires et le vrai régime de travail ou de volontariat restent indépendants. Aucun module interne d'administrateur n'est une condition publique d'accès ; un module théorique ne donne aucun droit de travailler ni d'entrer sur une propriété.

Cahiers des charges applicatifs

La présente spécification fixe les règles communes ; chaque application possède son cahier de charges métier autonome ci-dessous, lié depuis sa fiche publique. L’état disponible, en cours ou planifié est donné par la fiche : une spécification ne prouve pas qu’une fonction soit livrée.

Le financement est affecté au développement de chaque application commune, pas à l’achat ou à la revente des récoltes. Les campagnes ouvertes publient objectif chiffré et daté, contributions nettes encaissées après remboursements, nombre de contributions, progression et donateurs ayant choisi leur visibilité. Les budgets non approuvés restent à chiffrer ; aucun total ni donateur fictif n’est affiché. L’application privée sur mesure relève d’un devis confidentiel.

QAPAS — Community gère l’adhésion volontaire, la cotisation et, séparément, les éventuelles cautions de matériel. Ses hôtes choisissent librement de prêter, louer ou valoriser leurs outils ; tous les membres autorisés, hôtes ou non, peuvent proposer ou demander des services dans le module intégré à Community, avec activité déclarée, CAE applicable et situation contractuelle vérifiés avant une prestation payante. Chacun fixe librement ses devis détaillés ; ni exclusivité de territoire ni tarif collectif imposé. Community organise aussi les expériences participatives et vérifie, avant toute candidature pour exercer une activité chez un hôte, les prérequis théoriques émis par les applications responsables de ces activités. Les hôtes peuvent suivre les mêmes cours et proposer contenus et questions soumis à une revue indépendante dans l’application concernée. Community coordonne également les bootcamps pratiques QAPAS prévus dans la zone postale 6200-501. Le cahier applicatif Community décrit les accueils, les candidatures et les limites entre participation, volontariat et emploi.

Navigation et aide communes, périmètres de publication

Le manifeste public /navigation/v1.json fournit aux installations autorisées une liste d'applications et un bloc footer versionné : liens publics localisés vers les applications, l'aide et le projet, ainsi qu'une courte note commune. Chaque installation valide strictement identifiants, URL et traductions, met en cache la dernière version saine et affiche une solution de repli si QAPAS est indisponible. En-tête et pied de page affichent les mêmes accès dans les six langues, sur la page d'accueil et dans les écrans internes ; ils ne transmettent ni session, statut d'adhésion, coordonnées privées, contact personnel ou lien de gestion. Les anciens chemins d'applications réorganisées redirigent vers Community, Marketplace, les prestations privées de la plateforme ou l'aide.

La charte d'interface commune couvre aussi la présentation, pas seulement les liens : fond clair #f8f9f3, vert profond #113b31, vert feuille #b6e2a7, police système avec Inter si disponible, marque QAPAS, barre globale à icônes accessibles, surfaces et pied de page cohérents. Les pages de Platform, y compris accueil, Overview, compte et pages publiques, utilisent ces mêmes composants et couleurs que le modèle qapas-application ; chaque application garde son propre menu métier lisible. Tant que le paquet de styles versionné du socle commun n'est pas extrait, toute modification de cette charte est reportée et vérifiée dans les deux dépôts avant diffusion. Les thèmes de Filament restent contrôlés séparément pour préserver la lisibilité de l'administration.

L'aide commune est une extension de plateforme, accessible sans connexion depuis l'en-tête et le pied de page. Sa page publique décrit l'état réel des fonctions et les règles approuvées ; une réponse IA planifiée s'appuiera uniquement sur un corpus validé, daté et adapté aux droits de lecture, citera ses sources et transférera les sujets sensibles à un humain. Contacts, demandes relatives aux données, recours et vivier volontaire de recrutement demandent leurs propres parcours privés et responsables habilités. Les instructions AGENTS.md, CLAUDE.md, Laravel Boost, tickets et secrets ne sont jamais un corpus public. Les budgets détaillés, accès de support, procédures d'incident et cahiers techniques internes de cette extension ne sont visibles que par des administrateurs et développeurs autorisés dans un espace protégé ; aucun dossier interne n'est rendu par /applications/{id}/specification, le manifeste ou un fichier de dépôt public. Seuls les objectifs et recettes confirmés des applications communes apparaissent publiquement, avec le consentement des soutiens. La page d'aide actuelle annonce clairement les fonctions encore en préparation.

Chaîne des récoltes : approvisionner sans confondre les ventes

Farm Manager contient le plan privé des cultures ; il ne publie aucun stock. Le producteur choisit s'il signale un lot dans Harvest Supply (collecte), à qui il montre son offre (point de collecte, atelier ou producteur-revendeur identifié), en quelle quantité et avec quelle disponibilité. Harvest Supply gère intentions, besoins des destinataires, portions réservées, enlèvement/dépôt, réceptions et transferts explicitement convenus ; une annonce ne vaut ni commande client ni lot en stock au point. Marketplace donne au consommateur un catalogue d'offres autorisées, prend éventuellement sa commande et gère sa vente et sa livraison par le vendeur identifié. Packer pèse et assemble les produits réellement reçus dans les paniers et cagettes, puis tient le lien de provenance par lot. Un producteur-revendeur peut acheter un lot via Harvest Supply pour son propre panier, vendu sur Marketplace ou indépendamment ; il doit distinguer son rôle d'acheteur-revendeur de l'origine de ses propres cultures, payer immédiatement le lot acheté à réception acceptée, et assumer sa vente finale. QAPAS n'achète ni ne vend le produit.

Un lot peut être annoncé sans avoir trouvé d'acheteur final ; une commande peut venir d'ailleurs que Marketplace ; un point et un producteur-revendeur peuvent se fournir directement sans exclusivité. Le dossier de lot suit les portions et leurs responsabilités sans aspirer la clientèle externe ni exposer les cultures privées. Une quantité disponible ne peut être réservée deux fois entre Supply, Marketplace, dépôt physique et vente directe ; confirmation, réception, pesée, statut de propriété, facturation et paiement sont des événements distincts, rapprochés côté serveur. Aucun prix collectif ni accès aux prix/volumes privés des concurrents. Le cahier Harvest Supply étudie ce rôle comme nom de travail à valider avec des cas concrets ; son financement public reste distinct de Marketplace et de Packer.

Engagement transversal : producteurs payés, qualité assumée, réclamations reliées aux lots

Pour chaque achat ferme de récolte à un producteur dans Collecte ou Marketplace, QAPAS exige une offre acceptée individuellement, une vérification de qualité et de quantité avant achat, puis un règlement immédiatement reçu par le producteur au point de remise ou de chargement. Le commerçant assume ensuite son stock, sa préparation, son transport sous sa responsabilité contractuelle, les invendus et les remboursements de ses clients. Les frais liés à son activité et sa marge éventuelle ne sont pas imputés après coup au producteur ; aucune ristourne cachée, rejet rétroactif non justifié, facture imposée pour accéder au marché ou compensation unilatérale d'une plainte client sur un lot déjà payé. Un défaut imputable au fournisseur se traite par une procédure contradictoire distincte et documentée. Le coût d'un vrai service d'intermédiation peut être facturé à la partie qui l'a choisi, au tarif convenu avant la vente, sans masquer qui est l'acheteur et qui encaisse. Chaque producteur reste libre de refuser un prix et de vendre ailleurs ; QAPAS ne fixe ni prix commun ni taux de marge commun.

Le commerçant et le préparateur répondent de la qualité effectivement emballée et livrée. Chaque panier associe les lots entrants, les contrôles à la réception, les opérations de stockage/préparation, l'identité du vendeur responsable, le distributeur et les commandes livrées. Avant expédition, une vérification documente état, poids et composition du panier ; un produit impropre ou manifestement différent de l'offre ne part pas sous prétexte qu'un producteur a déjà été payé. Le vendeur final affiche un moyen simple de signaler produit abîmé, quantité manquante, substitution non consentie ou soupçon sanitaire depuis la commande, avec preuve facultative, accusé immédiat et traitement prioritaire des alertes de sécurité. Cette voie QAPAS complète les voies officielles de réclamation auxquelles le client peut accéder ; elle ne les remplace pas.

Le registre opérationnel de traçabilité attribue un identifiant aléatoire à chaque lot de récolte et relie sans perte producteur vérifié, zone de culture tenue confidentielle, produit et variété, date de récolte ou incertitude, date et heure de réception, contrôle et décision, mouvements en stock, fractionnement ou assemblage, paniers/cagettes, commandes et destinataires. Chaque assemblage conserve tous ses lots parents et la quantité utilisée : « plusieurs producteurs » ne devient jamais « un producteur local » par facilité. Des lots différents peuvent composer un même panier si les ingrédients restent identifiables ; mélanger des produits indiscernables provenant de plusieurs exploitations exige un lot composé traçable et une présentation honnête de chaque origine. Les identifiants publics n'exposent ni clé interne, ni coordonnées ni date encodée. Une alerte permet de retrouver rapidement le stock encore sur place et tous les clients et établissements livrés concernés, sans publier ces listes.

Étiquetage simple de chaque panier. Le code du producteur, le code de récolte et le code du panier existent dans le système, mais le personnel de préparation n'a pas à les connaître ni à remplir trois formulaires.

• À la réception, une personne identifie le producteur une seule fois avec son badge ou sa fiche, choisit le produit et pèse la cagette. Le système enregistre automatiquement date et heure, crée le lot correspondant et imprime une étiquette à coller sur cette cagette. Une même personne qui revient un autre jour reçoit un nouveau lot. Chaque cagette contient un seul lot identifié ; si l'origine est inconnue, elle reste à l'écart de la préparation.
• Pour confectionner un panier ou remplir une cagette de livraison, l'écran montre la commande en gros caractères. L'emballeur scanne le lot source, pose la portion dans un plateau taré sur la balance reliée au poste et attend le poids stable affiché ; le produit et son origine viennent automatiquement du code scanné, la balance ne les devine pas. Il scanne ensuite le contenant de destination, qui reste physiquement seul au poste, et y verse la portion ; ce scan associe produit, poids et destination sans saisie. Il répète ce geste par lot utilisé, sans scanner chaque fruit, puis appuie sur « Fermer et imprimer ». Si un lot est bloqué, si le poids bouge ou si la destination ne correspond pas à la commande, l'écran demande d'appeler un responsable ; aucune expédition ne contourne l'alerte. La balance indisponible exige une pesée conforme sur un autre poste autorisé, contrôlée par le responsable ; il n'y a pas de poids librement inventé.
• Un clic imprime l'étiquette du panier, collée avant le départ : numéro unique en clair, date de préparation, vendeur responsable, contenu, quantités, pays d'origine par produit et autres informations exigées selon la vente réelle. Le QR code ouvre la fiche de ce panier précis, avec dates de récolte et de réception distinctes, provenance et pratiques déclarées ou effectivement vérifiées clairement différenciées. Si le producteur a choisi de publier son nom commercial, il figure sur cette fiche ; sinon son identité complète reste accessible à l'opérateur et aux autorités habilitées. Le QR ne remplace pas les mentions qui doivent figurer sur l'étiquette papier ni les informations dues avant la précommande.

En arrière-plan, le système relie automatiquement producteur → cagette/lot → quantités pesées → panier → commande. Le code du panier est aléatoire et ne contient ni date encodée, ni identité, ni adresse ou numéro de commande ; sa page publique n'affiche pas les dossiers privés de culture ou de traitement. Modifier un panier déjà étiqueté annule son étiquette et impose une nouvelle impression. En cas de réclamation, le responsable scanne le panier pour retrouver les cagettes concernées, ou scanne un lot suspect pour retrouver tous les paniers touchés. Une panne de lecteur ou d'imprimante impose une saisie assistée et une vérification humaine avant toute nouvelle étiquette ; aucun panier ne part sans provenance reconstituable et étiquette correcte. Les codes propres à QAPAS suffisent pour le pilote ; des standards interopérables sont étudiés si des grossistes en ont besoin.

Essai terrain à réussir : un emballeur débutant compose, avec l'écran de la commande, un panier de poires et de pommes provenant de deux producteurs. Pour chaque produit, il scanne la cagette source, attend le poids stable, scanne le panier de destination et verse ; il termine en imprimant et collant l'étiquette. L'opérateur peut ensuite retrouver tous les paniers issus d'une cagette de poires suspecte, sans que l'emballeur ait eu à saisir l'identité ou l'histoire du producteur.

L'admission phytosanitaire d'un lot vendu par le vendeur identifié vérifie, selon les exigences applicables à la production et au fournisseur, l'identité et les déclarations du producteur, le registre de traitements requis, la cohérence de la culture, de la date d'application et du délai avant récolte, et les pièces de certification revendiquées. Ce contrôle documentaire réduit un risque ; il ne prouve pas l'absence de traitement ni la conformité des résidus. Les prélèvements et analyses sont ciblés par le risque, les incidents et un programme d'échantillonnage indépendant ; tout résultat porte méthode, laboratoire compétent, substance recherchée, prélèvement et lot, sans transformer un échantillon négatif en garantie générale « zéro pesticide ». Les limites maximales de résidus applicables et l'usage autorisé des produits sont deux vérifications distinctes. Pour un doute sérieux, isolement sans délai du lot et de ses assemblages descendants, suspension des expéditions, investigation documentée, analyses lorsque pertinentes, puis retrait/rappel et notification aux autorités et clients selon le risque évalué ; aucune accusation publique contre le producteur ne précède des faits établis et une possibilité de réponse. La responsabilité du vendeur final envers ses clients et la règle de paiement initial du producteur restent claires ; un manquement fournisseur établi ouvre un recours contractuel distinct, sans reprendre unilatéralement la recette d'un lot acheté.

Les clients d'une même livraison, même tournée ou même lot source peuvent rattacher leurs réclamations à un dossier collectif visible aux acheteurs concernés : nature du problème, nombre de commandes touchées et état du traitement, sans exposer noms, adresses ou photos privées des autres clients. Les réclamations de clients ayant réellement commandé et reçu le produit sont distinguées des avis généraux ; doublons et abus sont modérés, avec réponse et pièces du vendeur consignées. Plusieurs alertes concordantes déclenchent une enquête sur le lot et des remboursements ou remplacements selon les faits et droits des clients ; une suspicion de risque alimentaire déclenche immédiatement l'isolement du lot et l'évaluation du retrait/rappel et de la notification aux autorités, même si une seule personne l'a signalée. L'historique des incidents confirmés et de leur résolution sert à contrôler l'opérateur ; aucun nombre de plaintes non vérifiées ne sert automatiquement à dénigrer publiquement un producteur ou à récupérer son paiement. Un incident causé par la préparation ou la livraison est attribué au maillon responsable, preuves à l'appui.

Critères d'acceptation : (1) un achat de fruits au point de préparation ou au camion ne transfère pas un lot au stock du commerçant tant que le producteur n'a pas confirmé le montant effectivement reçu ; en cas d'échec du paiement, l'expédition est bloquée ; (2) plusieurs acheteurs d'un panier issu du même lot peuvent déposer une plainte reliée, voir l'accusé, les mesures prises et l'issue sans découvrir leurs données personnelles mutuelles ; (3) une alerte sanitaire unique déclenche l'examen de sécurité sans attendre un vote ; (4) un remboursement au client ne débite pas rétroactivement le producteur d'un lot conforme déjà payé. Les rôles, délais de traitement, modalités de règlement et ressources de trésorerie sont validés avant ouverture.

Les applications décrites ici sont planifiées, non opérationnelles ; elles seront des solutions Laravel de l'écosystème QAPAS, chacune avec sa carte d'identité, son URL autorisée, ses permissions et ses traductions dans les six langues lorsqu'elle sera effectivement livrée. Leur carte QAPAS reste « à venir » avec une URL nulle jusque-là.

5. Fonctions V1 et ordre de livraison

La simple présence de dépendances Composer, de champs de profil ou d'une carte d'accueil ne vaut pas livraison des parcours métier et d'authentification.

L'adhésion, les cultures du quintal et la collecte suivent le premier parcours quintal/topographie : leurs cartes et leur navigation peuvent être annoncées dès le socle, mais les règlements, les fiches et calendriers de cultures, les témoignages et la déclaration et réception des lots constituent des livraisons ultérieures, à tester séparément avant activation.

QAPAS — Ruchers et apiculture, Project Designer, Community (y compris services), Mimosa, Harvest Supply, Marketplace et Packer suivent une étude métier et les validations propres à leur activité. Leurs cartes peuvent annoncer la réflexion sans présenter les formations, dossiers administratifs, emplois, ventes, livraisons ou ateliers comme déjà ouverts. Les applications privées sur mesure sont une prestation de la plateforme, présentée parmi ses services et non comme une application du catalogue.

6. Multilinguisme dès le départ

Langues prises en charge : fr (français), en (English), nl (Nederlands), es (español), de (Deutsch), pt (português). L'utilisateur peut choisir sa langue avant ou après connexion ; ce choix est conservé pendant la session, puis pourra être associé à son profil pour les sessions ultérieures lorsque le compte sera opérationnel. Une langue de repli documentée et testée évite les pages incomplètes. Le choix de langue ne modifie ni les droits ni les données métier.

Le sélecteur figure dans la barre QAPAS commune sur la plateforme et sur l'outil topographique, y compris sur mobile. Chaque installation conserve le choix dans sa propre session et le transmet à l'autre par un code de langue autorisé dans le lien de navigation, sans transporter la session ni les données du compte. Par défaut QAPAS démarre en français et l'outil topographique en portugais ; après le premier passage, le choix explicite de la personne prévaut. La conservation entre sessions distinctes et appareils demandera une préférence de profil et un mécanisme d'identité autorisé à définir avant ouverture publique.

Tous les textes écrits par la plateforme sont localisables dès leur création : accueil, menus communs, cartes d'application, formulaires, validation, erreurs, états de levé, invitations, courriels transactionnels, notifications, aide, administration Filament et libellés des exports. Dates, heures, unités et nombres suivent la locale sans altérer les valeurs enregistrées. Les contenus saisis par les utilisateurs conservent leur langue d'origine ; aucune traduction automatique n'est supposée ou affichée comme certaine.

L'identité publique des applications et la navigation partagée devront exposer ou résoudre des libellés dans les six langues. Leur contrat actuel exige surtout fr/pt/en : l'évolution sera compatible avec les premières installations topographiques, avec repli contrôlé pour nl/es/de jusqu'à leur traduction, puis tests de compatibilité. Les liens et permissions ne varient pas selon la langue.

L'interface et les parcours essentiels sont vérifiés dans chacune des six langues : pas de chaîne codée en dur visible, pas de clé de traduction apparente, pas de débordement majeur des menus, libellés compréhensibles et changement de langue qui conserve la page ou le contexte lorsque c'est possible.

7. Protection des personnes et des lieux

La plateforme collecte les seules données nécessaires au compte, à l'adhésion et aux droits effectifs ; les coordonnées exactes, observations, documents de qualité de titulaire, invitations et actions sont privés par défaut. Les données nécessaires à la cotisation ou à une facturation relèvent du payeur et du besoin effectif, pas automatiquement de tous les participants. Les références publiques de comptes sont des UUIDv4 aléatoires ; elles ne divulguent ni dates de création ni identifiants internes.

Les mots de passe sont hachés (Argon2id) ; sessions et jetons sont propres à chaque installation, secrets différents selon l'environnement, cookies sécurisés en production et vérification serveur systématique des accès aux pages, documents, exports et API. Les informations publiques ne doivent fournir aucun inventaire exploitable des propriétaires, des lieux précis ou des mouvements des participants. Les flux de compte, récupération, export et effacement des données restent à définir, implémenter et vérifier avant ouverture publique ; la conformité ne se déduit pas d'un framework installé.

La configuration locale peut comporter une clé d'exemple et un compte fictif, strictement limités à cet environnement. Les clés de production et Passport sont propres à chaque installation, ne sont pas commitées et sont créées avant toute donnée réelle.

8. Définition de « prêt » pour le premier parcours

Une première version est recevable lorsque, dans chacune des six langues, une personne peut créer un compte gratuit et accéder aux démos isolées et au levé privé de base sans adhésion ; un compte non cotisant ne peut entrer dans Farm Manager ni les autres outils réservés. Après adhésion distincte, un propriétaire autorisé peut soumettre un livrable topographique suffisant pour son usage, comprendre ce qui manque, activer le quintal après contrôle de la qualité de titulaire ou du mandat, puis créer un projet agroécologique et suivre une première intervention. La V2 du dessin satellite et des imports est évaluée comme jalon séparé : si elle n’est pas livrée, elle reste présentée comme planifiée. Un tiers non invité ne peut obtenir ni les coordonnées précises, ni la fiche, ni les données personnelles par l'accueil, le catalogue, une URL devinée, une API ou un export.

La démo d'Aldeia do Souto utilise des profils fictifs portugais et affiche sans ambiguïté qu'il s'agit d'un exemple. Elle ne fixe pas la localisation des futurs quintais. Les tests couvrent les parcours normaux, l'adhésion valide ou expirée, les refus d'accès, les levés rejetés et le changement de langue ; les livrables topographiques conservent provenance et version.

9. Arbitrages restants avant implémentation métier

• Définir les droits et justificatifs acceptables du propriétaire ou de son représentant, y compris les biens détenus à plusieurs, ainsi que les modalités de contrôle et de conservation minimale.
• Définir avec l'application topographique les critères de qualité et le processus de correction du levé suivant les usages, sans faire passer une observation pour une délimitation juridique.
• Décider de la structure des quintas facultatives, des rôles des participants et du niveau de partage volontaire des réalisations.
• Définir la première fiche de suivi agroécologique réellement utile au terrain, puis choisir les indicateurs observables sans score de résilience.
• Pour Projets et scénarios, définir avec les propriétaires deux variantes de référence, les hypothèses et sources des coûts/rendements, les règles d'export et de consentement par quintal et les procédures administratives effectivement visées avant de générer des dossiers spécialisés.
• Définir avec des maraîchers, oléiculteurs, arboriculteurs et jardiniers locaux le gestionnaire de cultures : choix de modes combinables par zone, fiche de plant ou de groupe, passage d'un groupe à un individu, cycle annuel ou suivi pluriannuel, événements datés prévus/réalisés, date inconnue, pertes et récoltes successives ; tester sur téléphone un olival spécialisé et un jardin mixte sans imposer de géolocalisation au plant. Valider aussi les unités et relevés du budget hydrique, les gestes d'entretien réellement faisables et les conditions de publication volontaire des témoignages ; vérifier pour chaque quintal les règles de gestion de combustible et les alternatives au paillage. Tester un essai volontaire de couvert en olival avec zone témoin, besoins en eau, fauche estivale, coûts, récolte et droit de revenir en arrière ; ne conditionner aucun accès commercial à cet essai.
• Pour QAPAS — Ruchers et apiculture, consulter des apiculteurs locaux sur les gestes et syllabi par tranche d'âge, vérifier l'implantation, les versions des formulaires et les démarches DGAV/IFAP, le calendrier sanitaire, les droits et moyens de produire des vidéos soignées ; définir ensuite mandat, qualifications, protection des mineurs, assurance, facturation, rémunération et paiement avant toute annonce nominative ou réservation payante.
• Définir le plan de migration du contrat public des applications pour les six langues et les liens privés entre livrables et projets.
• Concevoir le profil volontaire de « passant », les preuves professionnelles par métier et les critères publics de recherche ; préciser les contrats, tarifs, conflits d'intérêts, accès temporaires aux dossiers et échanges minimaux entre installations avant d'ouvrir l'annuaire.
• Définir les statuts de l’association QAPAS pour le volet Community, les montants et usages de la cotisation, l'objet et la restitution d'une éventuelle caution, ainsi que les droits d'accès, la revalidation, la facturation et le responsable des traitements.
• Pour les fiches publiques d'application, valider auprès de chaque équipe la version effectivement livrée, les travaux réellement engagés et le prochain jalon planifié ; ne pas exposer de tâches internes ou de coordonnées de clients privés. Ouvrir le dépôt de suggestions seulement après vérification effective de l'adhésion active, mise en place des rôles de lecture, du traitement des demandes et de leur durée de conservation.
• Pour la collecte par application commune, faire approuver un budget ventilé (travail, IA, équipements, frais), l'organisme bénéficiaire, les tarifs de rémunération et la propriété du matériel, la licence des livrables et le sort des surplus/échecs ; choisir le prestataire de paiement, valider qualification fiscale des versements et pièces remises, puis seulement afficher montant collecté et activer le versement. Les budgets privés sur devis restent distincts.
• Pour l'offre d'applications privées, définir un modèle de devis et contrat, les critères d'hébergement isolé, la responsabilité de chaque traitement, la licence et les modalités de sortie ; tester l'interconnexion limitée avec un membre volontaire, la révocation et l'absence totale de découverte de son installation ou de ses données par un autre membre.
• Définir avec les futurs utilisateurs du point de collecte ses créneaux, la pesée, le reçu par lot, les unités, les critères d'acceptation et de priorité, les frais, les cas de refus et le règlement des différends ; tester séparément vente directe, dépôt-vente et achat ferme, avec contrat, transfert de propriété, prix individuels, date de paiement et conflit d'intérêts ; puis mesurer un pilote sans exclusivité imposée.
• Trancher pour Travaux et services ce qui relève d'une simple demande de devis, d'un recrutement salarié ou d'une mise à disposition de main-d'œuvre et vérifier les obligations de chaque modèle avant de permettre la mise en relation.
• Pour le broyage, obtenir les données locales de biomasse, devis et coûts d'exploitation, identifier un référent ICNF et obtenir son accord pour construire un protocole pilote incluant l'essai sous EPDM ; valider ensuite la filière écologique et la possibilité juridique du traitement et de la valorisation avant de solliciter des fonds ou de vendre des broyats.
• Pour les paniers, sonder la demande et les producteurs, préciser les contrats et substitutions acceptées, identifier le vendeur et ses obligations, documenter la chaîne alimentaire et logistique, mesurer trajets et coûts réels de la vente indépendante ou groupée, fixer les conditions facultatives d'accès au point de collecte, chiffrer les marges par canal et contractualiser un mécanisme de paiement compatible avec les délais de récolte. Pour le parcours facultatif d'achat ferme, identifier l'acheteur/revendeur responsable, son statut et ses moyens de paiement, vérifier facture et transfert des risques au reçu d'acceptation, tracer le règlement reçu par le producteur, mesurer le fonds de roulement, définir le rôle du distributeur, les procédures d'hygiène du point de préparation et le retour de lots jusqu'aux paniers et clients ; tester un achat accepté, un lot refusé et une commande client remboursée sans reprise du paiement au producteur.
• Pour QAPAS — Marketplace, tester avec clients, producteurs directs et point de préparation la recherche par variété, budget, zone et créneau, l'absence de résultat, la liste de souhaits, les paniers composés, la réservation sans double vente et le routage direct ou central seulement sur accord du vendeur ; distinguer commandes, vendeurs réels et paiements quand plusieurs offres coexistent, puis vérifier les règles et coûts de don et de troc avant activation.
• Tester une fiche de lot pour deux variétés et qualités de pommes, avec maraîchers, arboriculteurs et acheteurs ; valider catégories applicables, preuves de certification biologique, modération des photos et avis, échantillon minimal de publication et garde-fous de concurrence avant d'afficher un retour chiffré sur le prix perçu.
• Pour la veille des prix, valider les licences et modalités de consultation des séries SIMA et de l'Observatório, la collecte autorisée d'offres publiques de magasins et coopératives, le coût d'actualisation, les unités et écarts de qualité, les preuves d'origine et le traitement confidentiel des règlements individuels aux producteurs ; faire relire le comparateur au regard du droit de la concurrence avant publication.
• Avec un centre d'emballage pilote, comparer un approvisionnement Marketplace et un achat direct hors Marketplace ; contrôler dans les deux cas justificatif de vente, traçabilité, pesée, paiement immédiat des achats fermes, rôles de facturation et absence de commission de mise en relation sur l'achat direct. Simuler deux acheteurs cherchant à reconstituer par recherches répétées les cultures d'un voisin ; vérifier qu'ils n'obtiennent ni plan privé ni stock non publié, tout en fournissant les informations précontractuelles dues au consommateur. Faire valider le parcours fiscal du fournisseur et l'éventuelle autofacturation par un professionnel avant transactions réelles.
• Pour les achats fermes, obtenir des commerçants volontaires la preuve de capacité à payer dès réception, vérifier plafonds et confirmation des virements immédiats pour petits lots et camions, fixer pesée contradictoire, transfert de propriété après encaissement et responsabilité des lots en garde temporaire ; définir triage rapide des réclamations, rattachement aux lots, procédures de retrait/rappel, réponse au consommateur et accès au Livro de Reclamações sans attribution automatique de faute au producteur.
• Dans le volet livraisons professionnelles de QAPAS — Marketplace, valider avec restaurants, artisans alimentaires, producteurs et transporteurs les volumes, créneaux, documents, conditions de transport et de température par type de produit, hygiène des cagettes et séparations propre/sale ; préciser propriétaire, valeur, comptage, garantie remboursable, retour, casse, TVA et coûts de lavage/retour avant un pilote d'établissements volontaires.
• Pour QAPAS — Packer, faire visiter le garage ou local candidat par des personnes compétentes en hygiène alimentaire, vérifier l'usage du bâtiment, les démarches d'ouverture et l'exploitant responsable ; mesurer les flux réel de réception, stockage, préparation, retrait et lavage, les besoins en eau et froid, la capacité horaire et les coûts d'aménagement. Tester avec des emballeurs le branchement d'une balance commercialement conforme et vérifiée, la tare, la lecture du poids stable, le lecteur, l'imprimante, la remise des colis et la reprise après panne sans double débit de stock. Définir les règles d'hygiène et d'étiquetage par produit avant les premières ventes.
• Pour toute vente alimentaire, prototyper avec plusieurs producteurs de pêches et un restaurateur la chaîne lot source → réception datée → fractions → panier ou cagette → clients, puis simuler une alerte de résidus sur un seul lot avec blocage et recherche de tous ses descendants ; éviter d'immobiliser inutilement les lots sans lien tout en élargissant le périmètre si une contamination croisée reste possible. Vérifier les obligations et preuves de traitements, les analyses ciblées, la confidentialité des registres, la conservation et la procédure contradictoire avec les producteurs avant d'ouvrir la publication de récoltes.
• Tester au point de préparation une imprimante d'étiquettes et un lecteur de QR ou code-barres avec des contenants de tailles différentes, la pesée, les réimpressions, les retours et un scanner hors service ; confronter la place disponible sur l'étiquette aux mentions exigées pour fruits frais seuls, paniers mixtes et éventuels produits transformés, et vérifier avec les producteurs quels éléments de leurs pratiques et identité commerciale sont partageables.
• À partir des sources de l'AT, de la DGAV et de l'ASAE, avec validation de conseils compétents, établir des parcours portugais clairs pour surplus privé, transaction effectivement isolée et activité commerciale suivie, sans inventer d'exemption générale ni reléguer les agriculteurs déclarés derrière une vente informelle récurrente ; définir les documents et contrôles nécessaires à chaque produit et vendeur avant de lancer les offres payantes.

Références pour les vérifications avant ouverture

• David Holmgren, Essence of Permaculture pour zones, secteurs et conception contextualisée ; RJUE consolidé, demande d'information préalable, mise à jour gouvernementale 2026 et ANEPC, avis sur les projets de sécurité incendie pour orienter la vérification des procédures et des signataires.
• DGT, activité de cadastro predial et liste des TCP habilités et BUPi, qui peut effectuer une géoréférenciation pour distinguer les démarches foncières d'un relevé auxiliaire de terrain.
• IRN, constitution d'une association, service public de création et Code civil portugais, associations pour vérifier statuts, admission et obligations avant collecte des cotisations.
• Heirloom, planification pour maraîchers diversifiés comme référence fonctionnelle ; DGADR, besoins en eau d'irrigation ; SGIFR, gestion de combustible ; DGAV, protection intégrée des cultures. Les recommandations de terrain nécessitent une vérification locale avant d'être automatisées.
• EU CAP Network, gestion de couverts dans les oliveraies, SGIFR, gestion du combustible végétal et Commission européenne, évolution des coûts des intrants agricoles : tester chaque couvert selon eau, production et risque de feu, et chiffrer la sensibilité économique à l'énergie sans condamner a priori les exploitations spécialisées.
• DGAV, identification et enregistrement de l'activité apicole, gov.pt, service de déclaration, DGAV, formulaires et suivi des maladies des abeilles et obligations des opérateurs du miel ; les démarches, versions et périodes sont vérifiées au moment d'ouvrir le service.
• ICNF, fiche Acacia dealbata et plan de gestion de biomasse invasive ; régime portugais des espèces invasives.
• IEFP, agences privées de placement et régime consolidé du travail temporaire et du placement.
• AT, CIVA article 29 sur la facturation, article 36 sur l'autofacturation et régime forfaitaire agricole ; décret-loi 24/2014, informations avant achat à distance et RGPD, article 25 pour concilier documents commerciaux, vendeur identifiable au moment requis et confidentialité par défaut des quintais.
• ASAE, vente en ligne de denrées, produits horticoles et confitures ; DGAV, normes de commercialisation des fruits et légumes pour vérifier les produits et obligations correspondant aux ventes effectivement ouvertes.
• ASAE, hygiène des installations alimentaires, ASAE, système HACCP et règlement (CE) 852/2004, annexe II pour examiner concrètement l'adaptation et l'exploitation du local de conditionnement ; IPQ, contrôle métrologique légal et réglementation des instruments de pesage pour le choix et la vérification de la balance commerciale.
• Autoridade da Concorrência, guide pour les associations d'entreprises et Commission européenne, relations commerciales dans la chaîne alimentaire : vérifier la liberté de fixation des prix individuels, le cadre éventuel d'une organisation de producteurs et les conditions réelles d'achat auprès des producteurs avant ouverture.
• GPP, système de cotations SIMA, Observatório de Preços Agroalimentar et DGAV, étiquetage de l'origine : distinguer production, gros et consommation, dater les prix affichés et documenter l'origine des lots avant d'ouvrir la veille.
• DGAV, obligations pour les fruits et légumes commercialisés, règlement délégué (UE) 2023/2429, norme applicable aux pommes selon le cas et Commission européenne, conditions d'utilisation du logo biologique : préciser les critères d'une fiche de lot sans créer un faux label QAPAS ni déduire la qualité sanitaire de l'aspect extérieur.
• Portugal, décret-loi 118/2010 consolidé, notamment article 3.º-A, règlement (CE) 852/2004, hygiène et enregistrement des établissements alimentaires et règlement (CE) 178/2002, traçabilité : vérifier conditions exactes du point de préparation, qualification et documentation des achats, délais maximaux légaux de paiement selon les parties et circulation des lots ; l'objectif commercial de règlement à la réception est plus rapide que ces plafonds et doit être financé.
• DGAV, fruits et légumes commercialisés, directive (UE) 2019/633 sur les pratiques commerciales déloyales et Commission européenne, poids des transports dans l'empreinte alimentaire : vérifier origine, catégorie, documents de transport, protection contractuelle du vendeur et méthode de comparaison des trajets avant le marché professionnel.
• BCE, règlement européen sur les paiements instantanés, Portugal, pratiques commerciales déloyales dans la chaîne agroalimentaire, règlement (CE) 178/2002, obligations de retrait et de rappel et ASAE, Livro de Reclamações : valider le paiement immédiat effectivement disponible, l'interdiction des retenues injustifiées et la réaction à une alerte sanitaire ou plainte de consommateur.
• Règlement (CE) 852/2004, transports et hygiène des denrées, règlement (CE) 1935/2004, matériaux au contact des aliments, Portugal, décret-loi 152-D/2017, systèmes d'emballages réutilisables et AT, article 36 du Code de la TVA sur les emballages rendus : définir cagettes aptes au contact, nettoyage, garantie, restitution et présentation sur les documents de vente selon le régime effectif.
• DGAV, obligations et calendrier des registres d'emploi professionnel de produits phytopharmaceutiques, DGAV, contrôle des résidus, règlement (CE) 396/2005, limites de résidus et règlement (CE) 178/2002, traçabilité et retrait : vérifier les registres et les analyses adaptés aux vendeurs réels, la filiation des lots, l'isolement et les notifications appropriées.
• Règlement délégué (UE) 2023/2429, informations sur les mélanges de fruits et légumes, règlement (UE) 1169/2011, informations alimentaires préalables et étiquetage et GS1, identifiants et liens numériques : contrôler les mentions physiques, les origines et l'information à distance selon le contenu, puis étudier les identifiants interopérables sans faire d'un QR privé un label légal.
• Autoridade Tributária, définition et documents de l'« ato isolado », gov.pt, activité indépendante et ventes et ASAE, production et commercialisation de fruits et légumes : cadrer les cas concrets avant d'activer un flux marchand ; aucun montant ou exemption générique n'est présumé par QAPAS.
• Documentation Stripe, durée des autorisations de carte et capture ; le prestataire effectif et le modèle de conservation des fonds restent à choisir.

Comptes fictifs, portraits et événements partagés · 28 septembre 2026

Le seed local optionnel de Platform crée quatre comptes fictifs avec des identifiants de sujet stables et des portraits générés, crédits et empreintes sous stockage privé ; il rattache leur image à la collection privée profile_avatar de chaque compte. Le template d’application utilise ces mêmes identifiants pour ses quatre « shadow users » de démonstration. Ces fixtures ne constituent pas un mécanisme de connexion partagé. Leur galerie est visible seulement en démo locale sur la boucle locale. Les événements de l’année et Farmers’ Games sont publiés dans le manifeste public /navigation/v1.json à destination de la barre commune. Le renvoi de messages de contact non résolus depuis les applications exige une API privée, l’authentification du client et une autorisation de modérateur Platform à concevoir avant tout transfert de données.

Navigation locale et configuration centrale — 6 octobre 2026

Le menu hamburger contient six liens vers l’instance : C’est pour moi ?, Contact center, FAQ, Informations légales, Téléchargements et Mes accès. C’est pour moi ? quitte les raccourcis de la barre. Platform possède les contenus officiels des quatre pages publiques, configurés par application et origine ; Impulsion en pilote les changements relus par le dépôt Platform. Les anciens brouillons locaux ne constituent plus la source publiée. Mes accès est privé et reflète exclusivement les droits de la session dans l’instance. Voir le contrat et ses limites.