Aller au contenu principal
Menu

RECHERCHE APPLIQUÉE EN ACE

Tester comment les preuves d’un projet ACE deviennent plus comparables, révisables et réutilisables.

Crop Urbanis mène une recherche appliquée parallèlement au développement de la Plateforme. Le programme étudie si des structures de projet propres à l’ACE, le traitement de documents fournisseurs relié aux sources et la revue de cas de conception tenant compte de l’incertitude peuvent réduire les informations non résolues et l’effort de revue professionnelle avant des engagements matériels du projet.

Statut public actuel : cadre du programme défini · statut de recherche indiqué par axe · aucun résultat de performance externe revendiqué sans publication distincte

Le programme ne suppose pas que l’ajout d’IA améliore une décision de projet. Il teste si une meilleure structure, la provenance, le contexte métier, la gouvernance des calculs et la revue professionnelle produisent des améliorations mesurables par rapport aux workflows existants fondés sur des documents et des feuilles de calcul.

Cultures hydroponiques poussant sur des rayonnages superposés et dans des bacs peu profonds à l’intérieur d’une serre vitrée.

QUESTION DE RECHERCHE

Un modèle propre à l’ACE reliant preuves, exigences et hypothèses peut-il réduire les informations projet non résolues et l’effort de revue professionnelle avant les engagements du projet, sans dissimuler l’incertitude ni transférer la responsabilité à l’IA ?

Cette question relie les trois axes de recherche principaux : comment représenter les informations d’un projet ACE, comment normaliser des preuves fournisseurs hétérogènes et comment calculer et réviser des cas de conception conditionnels.

Le programme ne considère pas l’achèvement d’un logiciel, son usage interne ou une démonstration réussie comme une preuve suffisante d’amélioration. Toute amélioration exige un comparateur défini, un matériel d’évaluation, des métriques, des conditions d’acceptation et des limites déclarées.

PRINCIPES DE RECHERCHE

Les affirmations de recherche suivent les preuves, et non le langage produit.

Une question précède toute affirmation de capacité

Chaque activité de recherche commence par un problème défini et une hypothèse testable. Une liste de fonctionnalités implémentées n’est pas un résultat de recherche.

Une référence précède toute affirmation d’amélioration

La méthode proposée est comparée à un workflow existant défini, à une méthode générique ou à une version antérieure. Les seuils numériques sont fixés avant l’interprétation des résultats.

Le contexte précède le transfert

Un résultat est rapporté avec sa culture, son installation, son équipement, son document, sa langue, son étape de projet et son contexte d’exploitation. Une performance observée dans un contexte n’est pas généralisée silencieusement à un autre.

L’implémentation et la validation restent distinctes

Une capacité peut être implémentée sans être validée. Les tests internes, l’évaluation externe et les preuves publiées sont présentés comme des états différents.

Les limites restent partie intégrante du résultat

Les constats négatifs, résultats nuls, exceptions et conditions d’échec sont conservés au lieu d’être retirés de l’interprétation publique.

DOSSIER D’ÉTUDE

Chaque étude rapportée indique ce qui a été testé et ce qui constituerait un progrès.

Les dossiers de recherche utilisent une structure commune afin qu’un protocole, un résultat interne et un résultat évalué à l’extérieur ne puissent pas être confondus.

Question de recherche et hypothèse
Le problème étudié et la différence attendue entre la méthode proposée et son comparateur.
Périmètre d’évaluation
L’étape de projet, la classe d’installation, la culture ou classe d’équipement, le type de document, la langue et l’usage prévu concernés.
Matériel d’évaluation
Les dossiers, documents, cas de conception ou tâches de revue autorisés, anonymisés ou synthétiques utilisés dans l’étude.
Comparateur ou référence
Le workflow manuel, la méthode d’extraction générique, le processus existant sur feuille de calcul ou la version antérieure du système utilisé pour la comparaison.
Métriques et conditions d’acceptation
Les mesures quantitatives et qualitatives fixées avant l’évaluation, y compris toute condition qui empêcherait l’avancement.
Versions et conditions
Les versions du schéma, du modèle, du workflow, du prompt, du calcul et du jeu de données, avec les conditions d’exploitation matérielles.
Rôles de revue
Les rôles professionnels impliqués dans l’acceptation, la correction, le rejet ou l’escalade des résultats.
Résultat et statut de preuve
Le stade atteint par le travail : définition de la question, protocole, référence, évaluation interne, évaluation externe ou publication.
Limites et frontière de transfert
Les modes d’échec connus, les contextes exclus et les conditions dans lesquelles le résultat ne doit pas être généralisé.

STATUT DES PREUVES

Le statut de recherche n’est pas le statut produit.

La page MVP et bêta privée indique si une capacité est conçue, implémentée, utilisable en interne ou disponible dans une bêta convenue. La page Recherche indique la maturité des preuves qui soutiennent une méthode.

Question définie

Le problème, le contexte prévu et l’hypothèse ont été formulés.

Protocole fixé

Le matériel d’évaluation, le comparateur, les métriques, les seuils et les conditions de revue ont été définis avant les tests.

Référence mesurée

Le workflow existant ou le comparateur a été évalué dans les mêmes conditions d’étude.

Évaluation interne terminée

La méthode proposée a été testée en interne et ses limites ont été consignées.

Évaluation externe terminée

Un partenaire documenté, un réviseur indépendant ou une étude externe a évalué la méthode pour un périmètre déclaré.

Résultat publié

Le protocole, le résultat, le périmètre, les versions et les limites sont disponibles dans un dossier de recherche public.

« Opérationnel », « implémenté » et « utilisable en interne » sont des termes de statut produit. Ce ne sont pas des termes de preuve de recherche.

PROGRAMME DE RECHERCHE ACTIF

Trois axes de recherche soutiennent l’orientation actuelle de la Plateforme.

Les axes sont définis autour des décisions de projet plutôt qu’autour de modules logiciels. La recherche agronomique, l’assistance IA, la revue professionnelle et les tests d’impact des changements traversent l’ensemble du programme.

Modèle d’information et de décision des projets ACE

Question de recherche
Quelle structure minimale propre à l’ACE est nécessaire pour maintenir reliées les preuves du projet, les exigences, contraintes, hypothèses, alternatives, calculs, revues, décisions et exigences en aval ?
Hypothèse
Un modèle de projet propre à l’ACE représentera une plus grande part des informations critiques pour la décision, avec moins de champs ad hoc et moins de dossiers non reliés qu’un workflow générique fondé sur des fichiers et des feuilles de calcul.
Protocole d’évaluation
Évaluer le modèle au moyen de dossiers projet autorisés, anonymisés ou synthétiques provenant d’étapes de décision définies. Chaque étude doit préciser le type d’installation, la culture ou le contexte de production, l’étape du projet et les catégories d’information incluses.
Comparateur
Un schéma de projet générique, un workflow existant de feuilles de calcul et de documents, ou une version antérieure du schéma interne.
Mesures principales
  • Couverture des informations critiques pour la décision
  • Taux de champs personnalisés
  • Taux de correspondances ambiguës
  • Taux de déclarations non reliées ou orphelines
  • Complétude des dossiers de source et de responsabilité
  • Accord inter-réviseurs
  • Détection des dossiers affectés après un changement injecté
  • Temps de revue professionnelle
Condition d’avancement
Le schéma ne doit progresser que lorsqu’il améliore la couverture sans créer un niveau inacceptable de correspondances ambiguës, de croissance des champs personnalisés ou de désaccord entre réviseurs. Les seuils doivent être fixés avant chaque évaluation.
Statut public actuel
Question définie. Le modèle conceptuel et le workflow interne sont en cours de développement ; aucune référence publique de couverture ni aucun résultat de validation externe n’est revendiqué.
Limite connue
La couverture obtenue pour une installation, une culture, une région ou une étape de projet n’établit pas une couverture adéquate dans une autre.
Relation avec le produit
Cet axe informe les fonctions de référence projet, d’exigences, de continuité des décisions et d’impact des changements de la Plateforme, ainsi que le modèle de projet ACE présenté sur la page Technologie.
Prochaine étude
Mener une étude de couverture du schéma et d’accord entre réviseurs dans au moins deux contextes de décision ACE clairement définis, au moyen de dossiers synthétiques ou autorisés.

Normalisation et comparaison des preuves fournisseurs

Question de recherche
Des schémas propres à une classe d’équipement peuvent-ils convertir des documents fournisseurs hétérogènes en déclarations comparables reliées aux sources, sans masquer les conditions d’exploitation manquantes ni les corrections des réviseurs ?
Hypothèse
Un workflow d’extraction et de normalisation propre à l’ACE réduira les erreurs critiques de comparaison et le temps de revue professionnelle par rapport à une extraction générique ou à une comparaison manuelle ad hoc.
Protocole d’évaluation
Évaluer une seule classe d’équipement ou de document à la fois au moyen de propositions autorisées ou synthétiques. Conserver la formulation d’origine, l’emplacement dans la source, la valeur brute, la valeur normalisée, l’unité, les conditions d’exploitation, le statut de preuve et le résultat de la revue.
Comparateur
La comparaison manuelle de documents et, lorsque cela convient, une référence d’extraction documentaire générique.
Mesures principales
  • Précision et rappel des champs critiques
  • Exactitude de l’emplacement dans la source
  • Erreur de normalisation des unités
  • Complétude des conditions d’exploitation
  • Rappel des champs manquants
  • Précision des conflits candidats
  • Taux de correction par les réviseurs
  • Temps de revue par document
  • Performance par classe d’équipement, de document et de langue
Condition d’avancement
Un workflow ne doit pas être étendu à une autre classe d’équipement, langue ou type de document avant que la référence pertinente, les exigences relatives aux champs critiques, le comportement en cas d’exception et les conditions de revue professionnelle aient été évalués dans ce nouveau contexte.
Statut public actuel
Question définie. Le protocole d’évaluation et le matériel autorisé ou synthétique sont en préparation ; aucun résultat de référence public n’est revendiqué.
Limite connue
Une extraction correcte ne vérifie pas qu’une déclaration fournisseur est exacte, garantie ou applicable au projet proposé.
Relation avec le produit
Cet axe informe les preuves fournisseurs, la comparaison des configurations, les workflows de clarification et l’extraction préservant la provenance.
Prochaine étude
Mener une petite revue professionnelle en aveugle sur une classe d’équipement définie, en comparant le workflow relié aux sources à une extraction manuelle ou générique.

Validité des cas de conception, incertitude et revue professionnelle

Question de recherche
Les cas de conception physiques, de production, de services publics et financiers peuvent-ils rester reproductibles tout en exposant l’incertitude et en identifiant les conclusions devenues obsolètes après la modification d’une entrée matérielle ?
Hypothèse
Des modèles versionnés, des conditions de validité explicites, des statuts de preuve, des plages d’entrée, une analyse de sensibilité et des étapes de revue réduiront la fausse précision et les résultats obsolètes par rapport à des scénarios statiques non versionnés.
Protocole d’évaluation
Utiliser des ensembles de scénarios définis, des calculs de référence et des changements ou erreurs injectés. Chaque évaluation doit identifier la classe de modèle, les entrées, les unités, les conditions de validité, les plages supposées, la version du modèle et le périmètre de revue professionnelle.
Comparateur
Une feuille de calcul non versionnée, un scénario statique ou un workflow de calcul antérieur dépourvu de dossiers explicites de dépendance et de revue.
Mesures principales
  • Reproductibilité des calculs
  • Cohérence dimensionnelle et des unités
  • Écart par rapport aux cas de référence
  • Stabilité du classement de sensibilité
  • Détection des dossiers affectés après la modification d’une entrée
  • Complétude du dossier de décision
  • Substitutions et escalades des réviseurs
  • Temps de revue professionnelle
  • Nombre d’entrées critiques non résolues
Condition d’avancement
Une classe de modèle ne doit pas dépasser le statut exploratoire tant que sa méthode, ses exigences d’entrée, ses cas de référence, son périmètre de validité, ses limites connues et le réviseur responsable ne sont pas documentés.
Statut public actuel
Question définie. Les protocoles d’évaluation de la gouvernance des modèles et des changements injectés sont en préparation ; aucune validation externe ni affirmation de performance projet n’est formulée.
Limite connue
Un cas de conception reproductible reste conditionnel à ses entrées. Il ne constitue ni une prévision ni une garantie de rendement, de coût, de retour, de performance d’équipement ou de résultat de livraison réalisé.
Relation avec le produit
Cet axe informe la comparaison des cas de conception, le traitement de l’incertitude, l’impact des changements, les états de revue et les dossiers de décision.
Prochaine étude
Mener des tests de référence et de changements injectés sur un ensemble limité de calculs, puis une revue professionnelle des hypothèses, résultats et dossiers de décision affectés.

ÉVALUATION TRANSVERSALE

Quatre problèmes d’évaluation s’appliquent à l’ensemble du programme.

Transférabilité des preuves agronomiques

La qualité de la recherche n’est pas évaluée uniquement selon que le système a trouvé une phrase pertinente. Une déclaration retrouvée doit conserver le contexte nécessaire pour juger si elle est transférable au projet.

Contexte pertinent

  • Culture et cultivar
  • Système de production
  • Type d’installation
  • Stade de développement
  • Conditions environnementales
  • Géographie ou climat
  • Échelle expérimentale ou commerciale
  • Méthode de mesure
  • Classe de preuve
  • Date de publication ou d’observation

Mesures

  • Exactitude de la source et de la citation
  • Complétude du contexte
  • Taux de résultats non étayés
  • Rappel des contradictions ou désaccords
  • Taux approprié d’exception ou d’abstention
  • Taux de correction professionnelle

Un résultat évalué par les pairs peut être correctement retrouvé tout en restant inadapté comme hypothèse de projet.

Revue humain–IA

La revue humaine est évaluée comme une partie du système au lieu d’être seulement décrite comme une mesure de sécurité. Une étude doit identifier qui révise quoi, quelles informations le réviseur voit et ce qui se passe après acceptation, correction, rejet ou escalade.

Mesures

  • Taux d’acceptation
  • Taux de correction
  • Taux de rejet
  • Taux d’escalade
  • Fréquence de substitution
  • Taux de fuite des erreurs critiques
  • Minutes de revue
  • Accord inter-réviseurs

La présence d’un réviseur humain n’établit pas l’efficacité du processus de revue. La fiabilité de la revue doit elle aussi être évaluée.

Tests des changements et des dépendances

Des changements injectés sont utilisés pour tester si le modèle de projet identifie les exigences, calculs, comparaisons, décisions et résultats en aval susceptibles d’être devenus obsolètes.

Mesures

  • Rappel des dossiers affectés
  • Taux de faux dossiers affectés
  • Complétude du recalcul
  • Exactitude de l’état de revue
  • Temps nécessaire pour identifier le travail obsolète
  • Nombre de dépendances non résolues

Détecter un dossier potentiellement affecté est différent de déterminer la conclusion technique révisée.

Adéquation opérationnelle et valeur décisionnelle

Une méthode techniquement exacte peut malgré tout échouer si elle augmente l’effort professionnel, ne s’intègre pas au travail projet existant ou produit des résultats difficiles à utiliser.

Mesures

  • Temps jusqu’à une comparaison révisable
  • Effort d’intégration et de configuration
  • Temps du réviseur
  • Nombre de cycles de clarification
  • Complétude du dossier de décision
  • Compatibilité avec le workflow
  • Utilité déclarée par les utilisateurs
  • Coût par résultat accepté lorsqu’il est mesurable

La nouveauté technologique n’est pas considérée comme un résultat d’adoption suffisant.

RECHERCHE À LONG TERME

Les preuves d’exploitation constituent un axe ultérieur d’étalonnage des modèles.

Question de recherche

Les hypothèses de projet approuvées peuvent-elles être comparées aux performances d’exploitation mesurées afin d’identifier les modèles de calcul, protocoles ou décisions antérieures qui nécessitent un réétalonnage ?

Conditions requises

  • Données d’exploitation autorisées
  • Identité des capteurs, unités et informations d’étalonnage
  • Alignement temporel et règles relatives aux données manquantes
  • Culture, cultivar et version du protocole
  • Contexte de l’installation et des équipements
  • Vérité terrain définie ou annotation professionnelle
  • Référence et critères d’évaluation
  • Rôles de revue nommés
  • Conditions de conservation des données et de publication

Résultats d’étude possibles

  • Comparaison entre hypothèses et mesures
  • Dossier d’étalonnage du modèle
  • Comparaison des versions de protocole
  • Taxonomie révisée des problèmes d’exploitation
  • Évaluation du maintien de la validité des hypothèses du projet

Statut public actuel: Recherche à long terme uniquement. Cet axe n’implique ni déploiement en production, ni contrôle en direct de la serre, ni diagnostic autonome, ni jumeau numérique opérationnel.

Condition d’avancement: Cet axe ne doit pas devenir actif tant que les droits sur les données, la qualité des mesures, l’objectif d’évaluation, la référence et les conditions de revue professionnelle ne sont pas définis.

DOSSIER DE RECHERCHE PUBLIC

Les protocoles, résultats et limites sont rapportés comme des artefacts distincts.

Crop Urbanis peut publier des questions de recherche, des protocoles d’évaluation, des schémas simplifiés, du matériel d’évaluation synthétique ou anonymisé, des résultats agrégés, des limites, des constats négatifs, des comparaisons de modèles et des notes de révision.

Un résultat public doit identifier :

  • La question de recherche et l’hypothèse
  • Le périmètre et le matériel d’évaluation
  • Le comparateur ou la référence
  • Les définitions des métriques et les seuils
  • Les versions pertinentes du schéma, du modèle et du workflow
  • Les conditions de revue professionnelle
  • La date du résultat
  • Le type de validation
  • Les limites connues et les contextes exclus

Un résultat n’est décrit comme évalué à l’extérieur que lorsqu’un partenaire documenté, un réviseur indépendant ou une étude externe l’a évalué pour un périmètre déclaré. Les tests internes ne sont pas renommés validation externe.

Les données clients et fournisseurs, les identités de bêta privée, le code propriétaire, les détails d’implémentation sensibles pour la sécurité, les contrôles de routage des modèles et les résultats projet commercialement sensibles restent privés sauf autorisation spécifique de publication.

FONDEMENTS DE RECHERCHE SÉLECTIONNÉS

Le programme s’appuie sur des problèmes établis de l’ACE et de l’évaluation.

Publication primaire

Controlled Environment Agriculture Design Standards

Le programme CEADS informe le traitement transversal de l’énergie, de l’eau, des matériaux, des organismes nuisibles, du travail, des finances et des considérations liées au cycle de vie des installations.

Cadre officiel

Cadre de gestion des risques liés à l’IA du NIST

Le cadre informe l’évaluation propre au contexte, les jeux de test documentés, la mesure de l’incertitude, la supervision humaine et la séparation des tests internes de la revue indépendante.

Recherche évaluée par les pairs

Technology Adoption in the Vertical Farming Industry

Cette étude informe l’attention portée par le programme à l’adéquation opérationnelle, à la discipline du capital, à l’effort professionnel et à la valeur mesurable plutôt qu’à la seule sophistication technologique.

Ces publications constituent des fondements de recherche et non une preuve d’affiliation ou de partenariat avec leurs auteurs ou organisations.

COLLABORATION DE RECHERCHE

Une collaboration commence par une question de recherche et un périmètre d’évaluation.

Crop Urbanis peut travailler avec des universités, groupes de recherche, développeurs et opérateurs ACE, fournisseurs d’équipements et partenaires techniques lorsque la collaboration permet de tester une question définie sans présenter à tort un travail projet confidentiel comme une preuve publique.

Un périmètre proposé doit définir

  • Question de recherche et hypothèse
  • Classe de projet, document ou modèle
  • Données disponibles et autorisées
  • Comparateur ou référence
  • Métriques et conditions d’acceptation
  • Rôles de revue professionnelle et scientifique
  • Conditions de propriété intellectuelle et de publication
  • Exigences de sécurité, de conservation et de suppression
  • Artefact de recherche attendu
  • Conditions d’arrêt, de révision ou d’avancement

Résultats possibles

  • Protocole d’évaluation
  • Ensemble d’évaluation synthétique ou autorisé
  • Rapport de référence
  • Résultats agrégés
  • Note sur les limites
  • Schéma ou taxonomie simplifiés
  • Note technique coécrite lorsque cela convient

Une discussion de recherche ne crée ni accès automatique à la Plateforme, ni participation à la bêta privée, ni partage de données, ni droits de publication, ni droit de revendiquer publiquement un partenariat.

RESSOURCES ASSOCIÉES

Examiner le contexte produit, technique et des données.

Plateforme

Le workflow projet prévu, les groupes de capacités, les statuts de preuve, les cas de conception et les résultats décisionnels.

Technologie

L’architecture logique, le modèle de projet ACE, les limites des tâches IA, la gouvernance des modèles et l’approche d’évaluation.

MVP et bêta privée

Statut actuel de l’implémentation, conditions d’accès organisationnelles, limites et feuille de route.

Sécurité et données

Données autorisées, accès habilité, conditions relatives aux fournisseurs, conservation, export et limites de suppression.

Discuter d’un problème défini de recherche ou de validation en ACE.

Partagez des informations générales sur la question de recherche, la classe de projet ou de document, les données disponibles, le comparateur proposé, les réviseurs responsables et les contraintes de publication. Les données confidentielles de projet, de fournisseur ou d’exploitation ne doivent pas être soumises sur le site public.

Version 1.0 du programme de recherche · dernière revue en août 2026