Chapitre quatre : les méthodes de l'intelligence artificielle dans le contexte agricole

Deuxième partie — Fondements de l'intelligence artificielle et des données

La question de cette partie : que se passe-t-il à l'intérieur d'un système d'intelligence artificielle depuis le moment où il reçoit des données jusqu'à ce que sa réponse ou sa recommandation parvienne à l'agriculteur ?

Lorsqu'un système intelligent propose un moment pour irriguer, identifie une maladie affectant une feuille de plante, ou prédit la production, la réponse peut sembler avoir surgi d'un seul coup à l'écran. Pourtant, cette réponse est le terminus d'un long trajet que l'utilisateur ne voit pas : il commence par des données collectées au champ, par satellite ou à partir d'enregistrements passés, puis passe par la mesure, le nettoyage, la classification et l'analyse avant de devenir une prédiction, une recommandation ou une alerte. Dans le débat public, l'intelligence artificielle est parfois présentée comme s'il s'agissait d'un esprit unique capable de comprendre et de décider en toute situation. En réalité, ce n'est pas un outil unique, mais plusieurs familles de méthodes et de modèles, chacune conçue pour des tâches particulières. L'outil qui analyse l'image d'une feuille de plante n'est pas le même que celui qui prédit le rendement d'une culture ; et un système qui extrait des informations de milliers de documents ne fonctionne pas de la même manière que celui qui détermine quand irriguer. Chaque méthode a ses forces, les hypothèses dont elle dépend, les données qu'elle exige et les erreurs possibles qu'il faut comprendre avant de se fier à ses résultats. Cette partie n'entend pas faire du lecteur un spécialiste de l'intelligence artificielle, ni l'accabler de détails mathématiques et informatiques. Son objet est plus profond et plus pratique : donner aux lecteurs une compréhension qui les protège de l'éblouissement devant un résultat avant d'en connaître le mode de production, et qui les aide à distinguer un système bâti sur des données appropriées et des preuves claires d'un système qui propose des réponses assurées sans connaissance suffisante pour les étayer. À cette fin, nous tenterons de regarder à l'intérieur du système, dans une langue alliant précision et simplicité. Nous demanderons : de quelles données a-t-il appris ? D'où ces données proviennent-elles, qui les a collectées, et sur quelle terre, sous quel climat et à quelle saison ? Représentent-elles les conditions de l'exploitation où le système sera utilisé, ou un environnement différent ? Que peut voir le modèle, et qu'est-ce qui demeure hors de son champ de vision ? Comment sait-il que sa réponse est correcte ? Et comment peut-il se tromper, hésiter, ou exprimer plus d'assurance que les éléments de preuve ne l'autorisent ? Ce ne sont pas là des questions techniques éloignées de la réalité agricole. Si les données météorologiques sont incomplètes, si une image satellitaire est masquée par les nuages, si un capteur n'est pas étalonné, ou si le modèle a été entraîné sur une autre culture ou un autre climat, le défaut peut passer d'une étape à la suivante jusqu'à parvenir à l'agriculteur sous la forme d'une recommandation d'apparence précise. Cela ne signifie pas que l'intelligence artificielle est inutile ; cela signifie que sa véritable valeur ne provient pas de sa seule intelligence computationnelle, mais de la qualité de toute la chaîne qui a produit sa réponse. Nous commençons par les méthodes de l'intelligence artificielle et la logique du choix de chacune : pourquoi tel outil convient-il à un problème tandis que tel autre ne convient pas ? Nous passons ensuite aux données, car elles sont la matière dont le système apprend et le miroir par lequel il voit le monde. Après cela, nous examinons la provenance et la qualité des données, afin de savoir d'où l'information est issue, quel chemin elle a suivi, et quelles modifications lui ont été apportées. Nous arrivons alors à la télédétection, où les images des satellites et des drones, conjuguées aux appareils de terrain, sont converties en indicateurs relatifs aux plantes, au sol et à l'eau. De là, nous passons aux systèmes d'aide à la décision et à la récupération des connaissances, pour voir comment mesures, modèles et expertise agricole sont réunis en une réponse utilisable au bon moment et au bon endroit. Cet ordre n'est pas arbitraire ; il reflète le chemin que suit la connaissance à travers le système. Une méthode inadaptée peut corrompre l'inférence, des données faibles peuvent ruiner les meilleurs modèles, une source inconnue rend le résultat difficile à vérifier, et une mesure inexacte produit une recommandation inexacte. Une réponse qui n'explicite ni son fondement ni ses limites peut se transformer d'un outil d'assistance en une nouvelle source de risque. Comprendre ces fondements ne signifie pas que l'agriculteur doive connaître chaque équation ou chaque ligne de code, pas plus qu'un conducteur de tracteur n'a besoin d'être ingénieur en mécanique. Mais l'agriculteur a besoin d'en savoir assez pour distinguer un fonctionnement correct d'un dysfonctionnement, une capacité réelle d'une promesse commerciale, et un outil qui aide à décider d'un outil qui lui demande de lui abandonner la décision tout entière. Dans cette partie, nous ne considérons pas l'intelligence artificielle comme une boîte mystérieuse qui délivre des réponses, mais comme une chaîne interdépendante de données, d'hypothèses, de mesures, de modèles et de décisions humaines. Chaque maillon de cette chaîne influe sur le suivant. La question la plus importante n'est donc pas seulement : qu'a dit le système ? Elle est aussi : comment est-il parvenu à ce qu'il a dit, sur quels éléments de preuve, et dans quelles limites peut-on s'y fier ? Le propos demeure concret, sans rien perdre de sa profondeur scientifique ni transformer l'introduction en une lourde explication technique.

Chapitre quatre : les méthodes de l'intelligence artificielle dans le contexte agricole

Message du chapitre

Il n'existe pas de méthode unique appelée « IA agricole » qui conviendrait à toute culture, toute exploitation et toute décision. Ce que nous appelons intelligence artificielle recouvre un vaste éventail de méthodes : certaines apprennent d'exemples passés, certaines recherchent des motifs inhabituels, certaines interprètent des images, certaines suivent l'évolution dans le temps, certaines comparent des options sous contraintes, et certaines récupèrent des connaissances et les formulent en une réponse. La valeur d'une méthode ne commence ni avec la notoriété de son nom ni avec la nouveauté de son modèle, mais avec son adéquation à la question agricole à laquelle nous voulons répondre. Une erreur du système peut n'être rien de plus qu'une image à reprendre ; ou bien une décision retardée qui manque une fenêtre de traitement, ou encore une opération automatisée qui met en danger une culture ou un ouvrier. La sélection commence donc par la décision et la conséquence de l'erreur, et ne revient qu'ensuite aux données et à la méthode — et non l'inverse. Ce chapitre ne demande pas à l'agriculteur de devenir programmeur, et il ne se contente pas non plus de présenter au lecteur averti des noms familiers. Son objectif est de bâtir un pont entre ce qui se passe à l'intérieur du modèle et ce qui se passe ensuite au champ : que voit le système ? Qu'apprend-il ? Que produit-il ? Où peut-il se tromper ? Et quand le résultat est-il une information d'appui, et quand devient-il une action qui exige supervision et responsabilité ? Avant les noms d'algorithmes : le voyage de la question à travers le système Imaginons un agriculteur qui découvre des taches sur des feuilles de tomate, prend une photo, et demande à une application : « Quel est le problème ? » La tâche semble simple, mais le système ne voit pas la feuille comme la voit une personne, et il ne connaît pas de lui-même l'historique de la parcelle, la variété, l'humidité, ni l'ampleur de la propagation des symptômes. Il reçoit une représentation numérique de l'image, la compare aux motifs qu'il a appris, puis produit une classe, une probabilité ou un ensemble de probabilités. Ensuite, une autre application peut convertir le résultat en recommandation. Entre l'image et la recommandation s'étend toute une chaîne de choix. Tout système agricole intelligent peut se comprendre à travers six étapes :

1. La question : quel problème ou quelle décision voulons-nous appuyer ?
2. Les entrées : quelles données le système peut-il réellement voir ?
3. La représentation : comment la réalité agricole a-t-elle été convertie en image, en nombre, en texte ou en série temporelle ?
4. La méthode : quelle famille computationnelle relie les entrées à la sortie ?
5. La sortie : le résultat est-il une classification, une estimation, une probabilité, un classement ou une recommandation ?
6. L'action : qui utilisera le résultat, et que se passe-t-il s'il est erroné ou tardif ?

Séparer ces maillons importe. Un modèle peut être bon pour classer une image, alors que l'image elle-même n'est pas représentative de la parcelle. Une prédiction peut être raisonnable, mais sa conversion en dose ou en calendrier exige des règles agricoles et des contraintes de sécurité que le modèle n'a pas apprises. Dans les systèmes matures, ces distinctions ne disparaissent pas derrière le mot « intelligent » ; elles sont montrées à l'utilisateur, afin qu'il sache où la confiance est fondée et où la vérification s'impose.

1. De la question à la représentation

La question agricole telle qu'une personne la formule est généralement plus large que la question qu'un modèle peut traiter. Demander « Cette plante va-t-elle bien ? » réunit en une seule formule la possibilité d'une maladie, d'une carence nutritionnelle, d'un stress hydrique, d'un dommage mécanique et des effets de la météo. Un modèle, en revanche, a besoin d'une tâche précise dont les entrées peuvent être représentées, dont la sortie peut être définie, et dont l'erreur peut être mesurée. Prenons l'exemple d'une feuille atteinte. Elle peut être convertie en différents problèmes :

Ce ne sont pas là plusieurs noms pour une même tâche. Chaque question exige des données qui lui conviennent, des réponses correctes dont le système puisse apprendre, un moyen de mesurer ses erreurs, et une étape claire qui suive une fois le résultat apparu. La classification peut suffire à un triage initial, mais elle ne suffit pas à guider un outil robotisé vers un emplacement précis. Et une carte des dommages peut être visuellement excellente, sans pour autant prouver la cause du dommage. Il en va de même pour les adventices. Si tout ce qui est requis est de savoir si une adventice est présente, une tâche de classification suffit. Si ce qui est requis est de calculer la densité des adventices, il nous faut un comptage ou une estimation de surface. Si ce qui est requis est de guider un outil mécanique, il nous faut une localisation précise, un temps de réponse, un système de contrôle et une barrière de sécurité. Le passage de « il a vu l'adventice » à « il s'est dirigé vers elle » est un passage de l'information à l'action, et non un détail mineur de programmation. C'est pourquoi l'unité de décision précède le choix du modèle. La décision porte-t-elle sur une feuille unique, une plante, un rang, un secteur ou une parcelle entière ? Et prédisons-nous le rendement d'une parcelle avant la récolte, ou la production totale d'une région pour planifier le stockage et le transport ? Si l'unité change, le sens des données et de l'erreur change avec elle. Une bonne estimation à l'échelle régionale peut ne pas convenir pour décider de l'irrigation dans un petit secteur, même si l'une et l'autre emploient le mot « rendement » ou « production ». Quant à la représentation, elle est l'image numérique simplifiée de la réalité que le système autorise. Elle peut représenter le sol par une mesure d'humidité à une seule profondeur, ou représenter la plante par une image prise à la verticale, ou représenter la conduite de la parcelle par un registre de dates. Toute représentation éclaire un aspect et laisse d'autres aspects hors du champ de vision. Un modèle ne connaît pas ce qui ne lui a pas été fourni, et il ne peut corriger une définition floue de l'objectif par la seule augmentation de sa puissance de calcul. Une question pratique : avant de demander le nom de l'algorithme, demandez : quelle est l'unité de décision ? Que voit le système ? Que ne voit-il pas ? Et quelle action sera bâtie sur sa sortie ?

2. L'apprentissage supervisé : apprendre d'exemples aux résultats connus

L'apprentissage supervisé est une approche dans laquelle le système apprend d'exemples dont les résultats sont connus. Si nous voulons l'entraîner à distinguer les feuilles de plantes saines des feuilles atteintes, nous lui montrons des images qu'un spécialiste a déjà examinées et auxquelles il a attribué un état. Si nous voulons l'entraîner à prédire le rendement, nous lui fournissons des données sur la météo, le sol, la variété et la conduite de la parcelle, et, avec chaque enregistrement, la quantité de rendement effectivement mesurée après la récolte. À partir d'un grand nombre de tels exemples, le système tente d'apprendre la relation entre les données et les résultats connus, puis utilise ce qu'il a appris pour estimer le résultat d'un cas nouveau qu'il n'a jamais vu. Le résultat connu est appelé classe de référence vérifiée par un expert lorsqu'il s'agit du nom d'une classe, telle que « saine » ou « atteinte », et valeur de référence lorsqu'il s'agit d'un nombre mesuré, tel que la quantité de rendement. Un modèle ne commence généralement pas par une liste de règles écrites par un expert, du type : « Si une tache de cette couleur apparaît, alors l'état est tel ou tel. » Le développeur lui présente plutôt un grand nombre d'exemples aux résultats connus, et il recherche de lui-même les caractéristiques qui reviennent avec chaque résultat. Lorsqu'il voit un nouvel exemple, il le compare aux motifs qu'il a appris puis estime le résultat le plus proche. Cette capacité est utile, mais elle comporte un risque important : le système peut apprendre un indice secondaire facile au lieu d'apprendre la caractéristique agricole qui nous importe. Il ne sait pas de lui-même quelle partie de l'image représente la maladie et quelle partie n'est qu'un arrière-plan ; il apprend plutôt de la manière dont les exemples ont été collectés et présentés. Imaginons que nous voulions entraîner un système à distinguer une plante saine d'une plante atteinte. Toutes les plantes saines ont été photographiées à l'intérieur d'une serre devant un mur blanc, tandis que toutes les plantes atteintes l'ont été en plein champ, avec un sol sombre visible derrière elles. Ce que nous voulons, c'est que le système apprenne la forme des symptômes sur les feuilles, mais il peut découvrir une voie plus facile : le fond blanc accompagne les images saines, et le sol sombre accompagne les images atteintes. Le système peut sembler performant lorsqu'il est testé sur des images collectées de la même manière, car les arrière-plans du test ressemblent à ceux dont il a appris. Mais il peut échouer sur une nouvelle exploitation — en classant par exemple comme saine une plante atteinte à l'intérieur d'une serre blanche, ou en signalant une plante saine parce qu'un sol sombre se trouve derrière elle. Le système n'a pas cherché à induire en erreur ; il a appris l'association la plus facile que les données lui offraient, plutôt que les signes de maladie que le concepteur visait. Le même problème surgit dans les données numériques. Si un capteur de récolte fournit des relevés supérieurs ou inférieurs à la réalité parce qu'il n'est pas étalonné, le modèle apprendra à partir de nombres erronés. Si la production de certaines parcelles est consignée en tonnes par hectare, tandis que celle d'autres parcelles est consignée en tonnes totales sans que la différence soit précisée, le système traitera des valeurs non comparables comme si elles étaient identiques. Et si un même nom est utilisé pour des états pathologiques différents, le modèle ne connaîtra pas les frontières correctes entre eux. Dans chacun de ces exemples, l'erreur ne demeure pas à l'extérieur du modèle ; elle pénètre la matière même dont le modèle apprend. L'algorithme peut accomplir sa tâche computationnelle avec exactitude tout en apprenant une relation bâtie sur une mesure défectueuse ou une définition instable. Une méthode avancée ne peut extraire de données une certitude qui n'y était pas présente au départ. Il ne suffit donc pas de trouver une réponse écrite à côté de chaque image ou de chaque enregistrement. Nous devons savoir :

• Qui a déterminé l'état de référence ou la valeur de référence, et quelles règles a-t-il suivies ?
• Le résultat a-t-il été confirmé par un seul spécialiste, examiné par plusieurs spécialistes, ou établi par un test de référence ?
• Le degré de confiance a-t-il été consigné, et un résultat « non concluant » était-il admis lorsque les éléments de preuve étaient insuffisants ?
• La définition de chaque état est-elle restée cohérente d'une exploitation, d'une institution et d'une saison à l'autre ?
• Les exemples comprennent-ils des cas faciles et difficiles, des symptômes précoces et avancés, ainsi que des cas mixtes ?
• Les images et les enregistrements représentent-ils la diversité des variétés, des lieux, des appareils et des éclairages ?
• Les images ou enregistrements très semblables ont-ils été séparés entre l'entraînement et le test, afin que le système ne soit pas testé sur des versions très proches de ce qu'il avait déjà vu ?

Permettre au système de dire « Il n'y a pas assez d'informations pour juger » n'est pas un signe de faiblesse. Dans les applications agricoles, une abstention rigoureuse peut être plus sûre que de contraindre le système à choisir un nom de maladie pour chaque image. Un résultat responsable ne se contente pas d'énoncer la possibilité la plus probable ; il précise aussi les limites de la confiance, les informations manquantes et l'étape suivante requise pour la vérification. Pour le lecteur averti : un grand nombre d'exemples ne compense pas une diversité étroite ou des résultats de référence faibles. Un petit ensemble indépendant représentant différentes exploitations, saisons et appareils peut être mieux à même de révéler les limites du modèle que des milliers d'images semblables. Il faut donc évaluer la diversité des environnements, la cohérence de la définition du résultat, l'indépendance des données de test et le coût de chaque type d'erreur, au même titre que la taille du jeu de données.

3. Apprentissage non supervisé et semi-supervisé : que faire lorsque les résultats documentés sont rares ?

Dans le cas idéal, nous pourrions souhaiter qu'un spécialiste examine chaque image, chaque relevé ou chaque enregistrement, et détermine le résultat correct qui lui est associé. Mais cela est rarement possible en réalité. Une exploitation peut collecter des milliers d'images et des millions de relevés de capteurs, alors que le temps, l'argent ou la capacité d'expertise nécessaires pour examiner chaque enregistrement individuellement font défaut. Lorsque les résultats documentés sont peu nombreux ou indisponibles, on peut recourir à des méthodes qui aident à organiser les données et à y découvrir des motifs récurrents, sans partir d'une réponse correcte attachée à chaque exemple. Parmi les plus importantes de ces méthodes figurent l'apprentissage non supervisé, la détection d'anomalies et l'apprentissage semi-supervisé. Ces méthodes se ressemblent en ce qu'elles exploitent des données non examinées, mais elles ne remplissent pas la même fonction et ne confèrent pas le même degré de certitude à leurs résultats. Premièrement : l'apprentissage non supervisé Dans l'apprentissage non supervisé, on ne donne pas au système une liste préalable lui indiquant : « Cette zone est bonne », « celle-ci est faible », « celle-là présente un problème de drainage ». Il recherche plutôt, au sein des données, les enregistrements qui se ressemblent par leurs caractéristiques, puis regroupe les semblables entre eux. Supposons que nous disposions de relevés provenant de différentes zones de la parcelle, comprenant l'humidité du sol, la productivité, la température et les caractéristiques de réflectance captées par des images aériennes. Le système peut constater que certaines zones se ressemblent par ces relevés et les placer dans un même groupe, tout en plaçant d'autres zones dans des groupes différents. Ce résultat peut aider l'agriculteur à percevoir une différence qui n'était pas auparavant manifeste, mais il n'en explique pas automatiquement la cause. Des zones partageant un faible rendement peuvent être mathématiquement semblables, alors que la raison de la baisse diffère d'un endroit à l'autre :

• Une zone peut souffrir d'un mauvais drainage.
• Une autre peut être affectée par l'ombre.
• Une troisième peut différer par le type de sol.
• Et le relevé d'une quatrième zone peut être faible en raison d'un capteur non étalonné.

Ainsi, à ce stade, le système dit : « Ces enregistrements sont semblables selon les données que j'ai analysées. » Il ne dit pas : « J'ai prouvé que cette zone est médiocre ou qu'elle nécessite une quantité déterminée d'engrais. » Cette différence est fondamentale. Le regroupement computationnel aide à orienter l'attention, l'inspection et l'échantillonnage, mais il ne remplace pas l'interprétation agronomique. Les groupes trouvés par le système n'existent pas non plus indépendamment des choix du concepteur. Le résultat est influencé par les variables introduites dans l'analyse, par la manière dont leurs unités sont normalisées, par le nombre de groupes à former, et par le degré de similarité que l'algorithme considère comme important. Si nous omettons les données de drainage, par exemple, le système ne pourra pas mobiliser le drainage pour expliquer la différence, si avancée que soit la méthode d'analyse. Deuxièmement : la détection des cas inhabituels Un usage important de ces méthodes est la détection des cas inhabituels. Le système apprend le motif habituel des relevés ou du comportement sur une certaine période, puis alerte l'utilisateur lorsqu'un cas apparaît qui s'en écarte de façon substantielle. La différence peut être :

• Un capteur d'humidité dont les relevés ont commencé à dériver progressivement.
• Une hausse soudaine de la consommation d'eau, susceptible d'indiquer une fuite ou un changement dans l'exploitation.
• Une baisse inhabituelle du débit d'une ligne d'irrigation.
• Un changement notable dans les déplacements d'un animal ou dans son schéma d'ingestion alimentaire.
• Une température restée constante pendant une durée anormalement longue, ce qui peut signaler une défaillance du capteur.

Mais l'alerte à elle seule ne prouve pas qu'une panne ou une maladie est survenue. Elle signifie seulement : « Ce cas diffère de ce que le système considérait comme habituel, et mérite donc un examen. » La cause peut être un problème réel, une variation saisonnière naturelle, une nouvelle opération agricole, ou une erreur de mesure. C'est pourquoi un signal de différence ne doit pas être converti directement en diagnostic ou en instruction d'exploitation. Un nombre élevé d'alertes n'est pas davantage la preuve de la qualité du système. Si celui-ci envoie, par exemple, cent alertes par jour à une équipe qui ne peut pas en examiner plus de cinq, l'outil deviendra une source de bruit, et des avertissements importants risquent de se perdre parmi les alertes répétées. Le système doit donc être calibré selon trois facteurs :

• La gravité de la situation qu'il pourrait ne pas détecter.
• Le nombre de fausses alertes que l'équipe peut traiter.
• La capacité de l'ouvrier ou du spécialiste à examiner l'alerte à temps.

Chaque alerte doit indiquer pourquoi elle a été émise, par exemple : « La consommation d'eau de ce secteur a dépassé sa plage habituelle au cours des six dernières heures, alors qu'aucun changement comparable n'est apparu dans les secteurs voisins. » C'est plus clair et plus utile qu'un message générique disant : « Une anomalie a été détectée. » Troisièmement : l'apprentissage semi-supervisé L'apprentissage semi-supervisé s'emploie lorsque nous disposons d'un nombre limité d'exemples qu'un spécialiste a examinés et auxquels il a attribué le résultat correct, à côté d'un nombre plus important d'images ou d'enregistrements que personne n'a encore examinés. Supposons qu'une exploitation dispose de milliers d'images de feuilles de plantes, mais qu'un phytopathologiste n'ait pu en examiner que quelques centaines. Cet ensemble plus restreint contient des cas connus, tels que :

• Une feuille saine.
• Les symptômes d'une maladie déterminée.
• Les symptômes d'une carence nutritionnelle.
• Une image insuffisante pour porter un jugement.

Les images restantes sont disponibles, mais leur état n'a pas été documenté. Le système apprend d'abord à partir des exemples examinés par le spécialiste, puis met à profit les ressemblances et les différences présentes dans les autres images. On peut ainsi utiliser une grande quantité de données sans exiger de l'expert qu'il examine manuellement chaque image. Mais réduire le travail manuel ne signifie pas se passer de la vérification humaine, et cela ne signifie pas qu'un grand nombre d'images non examinées puisse corriger un ensemble documenté faible ou étroit. Si toutes les images examinées par le spécialiste provenaient :

• D'une seule exploitation.
• D'un seul cultivar.
• D'un seul téléphone.
• De conditions d'éclairage similaires.
• D'un stade avancé de la maladie.

alors le système peut apprendre que ces conditions limitées représentent l'ensemble des cas. Il peut bien fonctionner sur des images similaires, puis se révéler médiocre lorsqu'il rencontre des symptômes précoces, un autre cultivar, une autre exploitation, ou un appareil photo de moindre qualité. Un système qui a appris à quoi ressemble la maladie à un stade avancé peut échouer à en reconnaître les tout premiers signes. Un système entraîné sur un seul cultivar peut confondre les caractéristiques naturelles d'un autre cultivar avec des symptômes de maladie. Et des milliers d'images qu'aucun spécialiste n'a examinées ne peuvent pas compenser automatiquement l'étroitesse des exemples documentés à partir desquels le système a appris le sens des cas. Nous devons donc demander :

• Les exemples documentés représentent-ils des exploitations, des cultivars et des stades différents ?
• Qui a déterminé l'état de chaque exemple, et comment a-t-il été vérifié ?
• Existe-t-il des cas indéterminés, plutôt que de forcer chaque exemple à recevoir un résultat définitif ?
• Le spécialiste a-t-il examiné un échantillon des résultats proposés ultérieurement par le système ?
• La faiblesse est-elle apparue dans une catégorie, un lieu ou un stade de croissance particuliers ?
• Le résultat s'est-il réellement amélioré, ou le système est-il simplement devenu plus assuré ?

Quatrièmement : apprendre des caractéristiques générales avant de définir la tâche Il existe aussi des méthodes qui apprennent d'abord des caractéristiques générales récurrentes à partir d'une grande quantité d'images ou de signaux, avant que le système ne soit entraîné à une tâche agricole déterminée. Le système peut apprendre à distinguer des formes, des contours, des textures et des nuances de couleur sans que chaque image soit rattachée au nom d'une maladie ou d'une condition agricole. Ensuite, un ensemble plus restreint examiné par un spécialiste sert à enseigner au système la tâche requise, comme distinguer les feuilles saines des feuilles présentant des symptômes particuliers. Cette étape peut réduire la quantité de travail nécessaire, mais elle ne signifie pas que le système a compris de lui-même la maladie ou la culture. Il a appris des caractéristiques visuelles ou numériques générales, puis a été orienté vers une tâche agricole déterminée. La qualité du résultat reste liée à la justesse des exemples documentés et aux tests menés dans des conditions de terrain indépendantes. Exemple pratique : diviser la parcelle en trois zones Supposons que le système ait analysé des données d'humidité, des données de rendement et des images aériennes, puis divisé la parcelle en trois zones aux caractéristiques différentes. Ce résultat ne signifie pas directement que la parcelle a besoin de trois prescriptions de fertilisation. L'étape suivante correcte consiste à utiliser la carte pour orienter l'inspection :

1. L'équipe confirme d'abord l'intégrité des capteurs et des données.
2. L'équipe se rend en des points représentatifs de chaque zone.
3. Elle examine le sol, le drainage, l'ombrage et l'historique de gestion.
4. Elle prélève des échantillons appropriés lorsque c'est nécessaire.
5. Elle compare l'interprétation informatique à l'observation et à la mesure au champ.
6. Elle détermine ensuite si les zones exigent réellement des traitements différents.

L'examen peut conclure qu'une zone diffère à cause du sol, que la deuxième présente un problème de drainage, et que la troisième a paru différente en raison d'une erreur de capteur. Si les trois groupes étaient alors convertis directement en trois prescriptions de fertilisation, des causes différentes auraient été traitées comme s'il s'agissait d'un problème unique. Ainsi, dans ce cas, l'algorithme fournit une carte des questions qui méritent examen, et non une ordonnance toute faite pour y répondre. Conclusion Lorsque les résultats documentés sont peu nombreux, ces méthodes peuvent mettre à profit des données abondantes de différentes manières :

• L'apprentissage non supervisé regroupe les cas similaires, mais il n'établit pas pourquoi ils sont similaires.
• La détection d'anomalies nous alerte sur ce qui s'écarte du schéma habituel, mais elle ne fournit pas de diagnostic définitif.
• L'apprentissage semi-supervisé combine des exemples examinés par un spécialiste avec davantage de données non examinées, mais il peut transférer les insuffisances des exemples limités au reste du système.
• L'apprentissage de caractéristiques générales réduit la nécessité d'examiner chaque image dès le départ, mais il ne supprime ni les essais au champ ni le jugement de l'expert.

Et le principe unificateur est le suivant : Des données abondantes aident le système à voir des schémas, mais le sens agronomique ne provient pas de la seule quantité ; il provient d'une mesure rigoureuse, d'exemples documentés, du contexte de terrain et de la vérification humaine.

4. La vision par ordinateur : que voit le système dans l'image ?

Lorsqu'un agriculteur ou un spécialiste regarde une feuille de plante, il ne voit pas seulement une couleur et une forme. Il relie plutôt ce qu'il voit à l'âge de la plante, à l'extension des symptômes, à l'état de la parcelle, à la météo, à l'irrigation et à son expérience de cas antérieurs. Un système de vision par ordinateur, à l'inverse, part de quelque chose de plus étroit : une image ou une séquence vidéo convertie en données numériques qu'un ordinateur peut analyser. La vision par ordinateur est un ensemble de méthodes qui aident le système à trouver des schémas au sein d'images et de vidéos. Elle peut recourir à des modèles appelés réseaux de neurones convolutifs, ou à des modèles de vision plus récents, pour reconnaître des formes, des couleurs, des textures et des relations spatiales. Ses applications agricoles comprennent l'inspection des maladies des plantes, l'identification des adventices et des fruits, l'estimation de la maturité, le tri des produits, ainsi que la surveillance des déplacements et du comportement des animaux. Les revues scientifiques recensent l'étendue de ces applications en génie agricole et alimentaire [SRC001][SRC002]. Mais dire que le système « comprend l'image » peut laisser entendre qu'il la voit et l'interprète comme le ferait un humain. En réalité, une même image peut servir à répondre à des questions différentes, et chaque question a sa méthode, son résultat et ses limites propres. 1\. Déterminer l'état général de l'image — la classification Dans cette tâche, le système considère l'image comme une unité unique, puis choisit l'état le plus proche parmi un ensemble d'états qu'il a préalablement appris. Le résultat pourrait être, par exemple :

• La feuille paraît saine.
• Il existe des signes évocateurs d'une infection.
• Le fruit paraît relever d'une certaine catégorie de qualité.
• L'image est insuffisante pour donner un résultat fiable.

Ce type d'analyse est utile pour un tri initial. Mais il ne montre pas nécessairement où se situe le signe dans l'image, il n'en établit pas la cause, et il ne transforme pas une probabilité en diagnostic définitif. Ainsi, si le système indique que l'image est « suspecte », cela signifie que le schéma général ressemble à des exemples dont il a appris. Cela seul ne signifie pas que la maladie est confirmée, ni que le traitement est désormais connu. 2\. Déterminer l'emplacement de l'objet ou du signe — la détection Il ne suffit parfois pas de savoir que l'image contient un fruit, une adventice ou une tache suspecte ; nous avons aussi besoin de savoir où cela se trouve. Dans ce cas, le système trace un cercle ou un cadre visible autour de la partie qu'il a détectée. Lors de l'examen d'une feuille de plante, par exemple, un cadre peut apparaître autour d'une tache particulière. Lors de l'analyse de l'image d'une parcelle, le système peut placer un cadre autour de chaque fruit ou de chaque adventice qu'il a pu trouver. Ce résultat aide à répondre à la question : Où se trouve la chose que le système a détectée ? Il aide aussi l'utilisateur à vérifier que le système s'est concentré sur la bonne partie. Le système peut croire avoir détecté un symptôme de maladie alors qu'il s'est en fait concentré sur une ombre, une plage de sol ou un élément de l'arrière-plan de l'image. Mais identifier l'emplacement de la tache n'établit pas la cause de son apparition. Le système peut identifier correctement l'emplacement du dommage, tandis que déterminer la maladie ou le stress qui l'a provoqué requiert encore d'autres informations. 3\. Tracer les limites de la zone atteinte — la segmentation Nous pouvons avoir besoin de savoir plus que l'emplacement de l'objet ; nous pouvons vouloir connaître précisément la surface qu'il occupe. Dans cette tâche, le système colore la zone qu'il estime endommagée, ou en trace les limites sur l'image. Au lieu de placer un large cadre autour de la feuille entière, il tente d'identifier la partie atteinte à l'intérieur de celle-ci. Cela peut aider à :

• Estimer la proportion de la feuille qui est atteinte.
• Mesurer l'importance du couvert végétal sur une image aérienne.
• Séparer le fruit de l'arrière-plan.
• Déterminer la surface couverte par les adventices dans une partie de la parcelle.
• Comparer l'évolution de la zone endommagée dans le temps.

Les ingénieurs emploient le mot « pixels » pour décrire les petits points qui composent une image, mais le lecteur n'a pas besoin de ce terme pour comprendre le résultat. Ce qui importe en pratique, c'est que le système tente de tracer les limites précises de la zone qu'il a détectée. Malgré cela, déterminer la surface du dommage n'établit pas quelle maladie l'a causé. Les limites peuvent être précises, alors que l'interprétation de la cause est erronée. 4\. Suivre l'objet ou la condition dans le temps — le suivi Lors de l'analyse d'une vidéo ou d'une séquence d'images, le système peut avoir besoin de déterminer si l'objet visible à présent est le même que celui qui est apparu un instant plus tôt ou sur une image précédente. Cela peut s'utiliser pour :

• Suivre les déplacements d'un animal à l'intérieur de l'enclos.
• Suivre un fruit sur la ligne de tri.
• Compter des objets sans compter le même objet plus d'une fois.
• Surveiller l'extension d'une zone endommagée sur des images successives.
• Suivre le déplacement d'une machine ou d'un ouvrier dans une zone d'exploitation.

Ici, détecter l'objet sur chaque image séparément ne suffit pas ; le système doit relier ses apparitions sur des images successives. Le système peut rencontrer des difficultés lorsque l'objet disparaît derrière un autre objet, que l'éclairage change, que des animaux se chevauchent ou que la caméra bouge. C'est pourquoi une perte de suivi ne doit pas être convertie directement en conclusion selon laquelle l'animal, le fruit ou la machine a réellement quitté la zone. 5\. Estimer la distance et la forme — l'estimation de la profondeur Une image plane montre la hauteur et la largeur, mais elle ne fournit pas toujours directement la distance réelle. Un robot ou une machine de tri peut avoir besoin de savoir à quelle distance se trouve l'objet et quelle forme il occupe dans l'espace. Le système peut utiliser une ou plusieurs caméras, ou un capteur adapté, pour estimer :

• La distance entre l'outil et le fruit.
• La hauteur de la plante ou la taille d'un objet particulier.
• La proximité d'une personne ou d'un animal par rapport à la zone de mouvement.
• La position de la branche par rapport au bras robotisé.
• La forme de l'objet qu'il faut saisir ou éviter.

L'estimation de la profondeur peut aider la machine à s'approcher, mais elle ne suffit pas à elle seule à garantir un mouvement sûr. Le système doit encore connaître les limites et la vitesse de l'outil, s'arrêter lorsqu'un obstacle apparaît, et vérifier que la mesure n'a pas changé à cause de la poussière, des vibrations ou d'une mauvaise visibilité. Pourquoi la tâche doit-elle être définie avec précision ? Le choix de la tâche de vision est lié à l'action requise une fois le résultat obtenu. Si l'objectif est de savoir si l'image contient un fruit, la classification d'images peut suffire. Mais si l'objectif est de compter les fruits, le système doit déterminer chaque fruit individuellement. Et si l'objectif est de guider un bras robotisé pour cueillir un fruit, il doit connaître sa position, sa distance et sa forme, puis convertir ces informations en un mouvement sûr. De même, savoir que des adventices sont présentes sur une image ne suffit pas à guider un outil mécanique vers elles. Le système doit :

1. Identifier chaque adventice.
2. Les distinguer de la culture.
3. Déterminer sa position par rapport à la machine.
4. Calculer le mouvement de l'outil.
5. Vérifier qu'aucune personne, aucun animal ni aucun objet inattendu n'est présent.
6. Interrompre l'exécution si la confiance baisse ou si les données se contredisent.

Chaque transition dans cette chaîne ajoute une nouvelle possibilité d'erreur. Pour cette raison, il n'est pas valide de qualifier un système de sûr au seul motif que le modèle de vision a obtenu de bons résultats sur des images de test. Pourquoi une image prise au champ diffère-t-elle d'une image de laboratoire ? Les images agricoles sont par nature variables. La même feuille peut paraître différente en raison :

• De la lumière du matin ou de midi.
• De l'ombre.
• De l'angle de prise de vue.
• Du type de téléphone ou d'appareil photo.
• D'un objectif plus proche ou plus éloigné.
• De la poussière ou de l'humidité.
• De l'arrière-plan.
• Du stade de croissance de la plante.
• Du chevauchement des feuilles.
• De la sévérité des symptômes et de leur stade.

Des symptômes de causes différentes peuvent aussi se ressembler. Certains signes de carence nutritionnelle peuvent ressembler, sur une même image, à des symptômes de maladie ou de stress hydrique. C'est pourquoi la réussite d'un système à reconnaître un schéma visuel ne signifie pas qu'il a établi la cause agronomique. Un modèle entraîné sur des feuilles isolées placées sur un fond net peut paraître robuste en laboratoire, puis se heurter à une réalité très différente lorsqu'il voit, au champ, des feuilles qui se chevauchent, des ombres changeantes, de la poussière, des insectes et des symptômes à un stade précoce. Par conséquent, les images d'entraînement et de test doivent représenter les conditions dans lesquelles le système fonctionnera réellement, et non les meilleures conditions dans lesquelles une image peut être prise. Quand le système se souvient du test au lieu de prouver sa capacité Les images servant à entraîner le système doivent être séparées de celles servant à le tester. Mais cette séparation peut paraître correcte dans les fichiers tout en restant trompeuse en réalité. Supposons que nous ayons pris dix images très semblables de la même plante en quelques minutes, puis que nous ayons placé certaines de ces images dans les données d'entraînement et d'autres dans les données de test. Le système peut reconnaître des détails de la plante, de l'arrière-plan ou de l'angle de prise de vue, parce que l'image de test est extrêmement semblable à ce qu'il a déjà vu. C'est ce qu'on appelle un chevauchement non intentionnel entre les données d'entraînement et les données de test, connu techniquement sous le nom de « fuite de données ». C'est comme entraîner un élève sur une série d'exercices, puis l'évaluer sur les mêmes exercices après en avoir modifié l'ordre ou certaines formulations. L'élève peut obtenir une note élevée, mais le test ne prouve pas qu'il sait résoudre un exercice nouveau. Par conséquent, un test agricole est plus solide lorsqu'il sépare :

• des plantes entières, et non de simples images.
• des parcelles entières.
• des exploitations différentes.
• des saisons indépendantes.
• des appareils de prise de vue différents.
• des variétés ou des stades de croissance non inclus dans l'entraînement.

Et la vraie question n'est pas : Le système a-t-il réussi sur des images qu'il n'avait pas vues auparavant en tant que fichiers ? Mais plutôt : A-t-il réussi sur une exploitation, dans une saison ou avec un appareil dont il n'avait pas appris des données auparavant ? Pourquoi l'« exactitude globale » peut-elle être trompeuse ? Un unique résultat global ne suffit pas à juger un modèle de vision. Supposons, dans un exemple numérique simplifié, que l'ensemble de test contienne mille images :

• 950 images saines.
• 50 images atteintes d'une maladie importante.

Si un modèle faible affirme que toutes les images sont saines, il aura raison sur 950 images sur mille, et son exactitude globale pourra sembler être de 95 %. Mais ce modèle n'a détecté aucun cas malade, et il est donc inutile pour la tâche en vue de laquelle il a été créé. Pour cette raison, nous devons demander :

• Combien de cas malades a-t-il pu détecter ?
• Combien de cas malades a-t-il classés comme sains ?
• Combien de fausses alertes a-t-il émises ?
• La performance diffère-t-elle selon les maladies ou les variétés ?
• Peut-il s'abstenir lorsque l'image n'est pas claire ?
• Que se passe-t-il lorsqu'il rencontre un cas qui n'était pas inclus dans les données d'entraînement ?

Si l'erreur la plus dangereuse consiste à classer comme sain un cas rare et grave, alors la capacité du système à détecter ce cas précis doit être mesurée, plutôt que de se contenter d'une moyenne gonflée par les classes courantes. De la vue de l'objet au mouvement de la machine En robotique, la tâche ne s'achève pas lorsque le système reconnaît un fruit ou une adventice. Le résultat doit franchir une autre chaîne : Voir l'objet ← déterminer son emplacement ← convertir cet emplacement en coordonnées que la machine peut comprendre ← planifier le mouvement ← l'exécuter ← vérifier le résultat ← s'arrêter en présence d'un danger Chaque maillon de cette chaîne peut être une source d'erreur indépendante. Le modèle peut reconnaître correctement le fruit, et pourtant le bras peut se déplacer vers une position imprécise en raison des vibrations de la machine. Ou la position peut être correcte, mais la main d'un ouvrier peut apparaître dans la zone de mouvement. Ou la connexion peut être interrompue après l'envoi de la commande et avant la confirmation de son exécution. Le système doit donc comprendre :

• des limites de vitesse et de force.
• une zone de sécurité autour des humains et des animaux.
• un mécanisme d'arrêt local qui ne dépende pas des communications.
• la vérification que l'action a réussi.
• la capacité de revenir à un état sûr.
• une autorité claire de l'ouvrier pour arrêter le fonctionnement ou le neutraliser.

Et le principe qui doit rester clair est le suivant : Un modèle peut réussir à voir l'objet tandis que le système échoue à le manipuler en sécurité. L'exactitude de l'image n'est pas l'exactitude de la décision, et l'exactitude de la décision n'est pas la sécurité de l'exécution. Questions pratiques avant de faire confiance à un système de vision agricole Un agriculteur ou un acheteur peut demander :

• Quelle est la tâche précise : classification d'images, localisation, mesure de surface, ou guidage de machine ?
• Les images de test ont-elles été collectées dans des parcelles et des saisons indépendantes ?
• Les images couvrent-elles les conditions d'éclairage, les appareils et les variétés que l'on trouve sur mon exploitation ?
• Quels cas le système ne parvient-il pas à distinguer ?
• Montre-t-il des exemples d'erreurs, ou seulement les meilleurs cas ?
• Peut-il indiquer que l'image est insuffisante ?
• Que se passe-t-il après le résultat : une alerte, une recommandation, ou une exécution automatisée ?
• Qui examine le résultat avant qu'une action sensible ne soit effectuée ?
• Comment la machine s'arrête-t-elle si une personne apparaît ou si la confiance baisse ?

Conclusion La vision par ordinateur ne dote pas une machine d'un œil humain ni d'une compréhension agronomique complète. Elle aide le système à extraire des informations précises d'images et de vidéos : identifier un état général, trouver un objet, tracer les limites d'une zone, suivre un mouvement, ou estimer une distance. La valeur de ces informations est déterminée par trois choses :

1. La question visuelle est-elle formulée d'une manière qui convient à la décision requise ?
2. Les images représentent-elles les conditions réelles du terrain ?
3. Le résultat a-t-il été traduit en action au moyen d'un système sûr et d'une responsabilité clairement établie ?

Cela permet au lecteur de distinguer un système qui présente une image convaincante lors d'une courte expérimentation d'un système qui a réellement été testé pour fonctionner sous la lumière, la poussière, la diversité et les contraintes de sécurité du terrain.

5. Modèles probabilistes et inférence causale : qu'est-ce qui est attendu, et que peut changer une intervention ?

Les systèmes agricoles font face à deux types de questions différents, dont la formulation peut sembler voisine alors même que leur réponse exige des éléments de preuve différents. La première question est : Qu'est-il probable qu'il advienne si les conditions actuelles se maintiennent ? Par exemple, nous pouvons demander :

• Quel est le rendement attendu en fin de saison ?
• Quelle est la probabilité qu'un stress hydrique survienne dans les prochains jours ?
• Quelle est la probabilité que les symptômes soient associés à une maladie particulière ?
• Quelle quantité de production peut parvenir au stockage la semaine prochaine ?

Ce sont des questions prédictives. Ici, le système tente d'utiliser ce qu'il sait de la météo, du sol, de la culture et de la gestion antérieure pour estimer un résultat qui ne s'est pas encore produit.

La seconde question, en revanche, est : Que se passera-t-il si nous changeons quelque chose ? Par exemple, nous pouvons demander :

• Qu'adviendra-t-il du résultat si le calendrier d'irrigation change ?
• Modifier l'une des pratiques de gestion améliorera-t-il le rendement ?
• Réduire la durée de fonctionnement d'une pompe diminuera-t-il la consommation d'eau sans provoquer de stress pour la culture ?
• Le traitement appliqué a-t-il été la cause de l'amélioration, ou celle-ci est-elle survenue pour d'autres raisons ?

Ce sont des questions causales, car elles ne se bornent pas à décrire ce qui peut advenir ; elles portent sur l'effet d'une action que nous voulons entreprendre. La corrélation ne prouve pas qu'un facteur cause l'autre. Les données peuvent révéler que les parcelles ayant utilisé une plus grande quantité d'un intrant agricole particulier ont obtenu des rendements plus élevés. C'est une relation qui mérite d'être étudiée, mais elle ne prouve pas que l'augmentation de cet intrant a causé le rendement plus élevé.

D'autres explications peuvent exister, par exemple :

• que ces parcelles avaient dès le départ un meilleur sol.
• que l'irrigation y était plus régulière.
• que les agriculteurs qui les géraient étaient plus expérimentés.
• que leurs propriétaires disposaient de meilleurs équipements.
• que l'intrant a été utilisé dans des parcelles portant des cultures ou des variétés différentes.
• que les conditions météorologiques étaient plus favorables à leur emplacement.
• que l'agriculteur a augmenté l'intrant en réponse à une situation qui n'a pas été consignée dans les données.

Dans ce cas, l'intrant et le rendement peuvent apparaître ensemble, alors que la véritable cause de l'écart est un autre facteur ou une combinaison de facteurs. Cela revient à observer que les exploitations qui utilisent davantage de capteurs obtiennent de meilleurs résultats. Cela seul ne prouve pas qu'acheter des capteurs améliorera le résultat sur chaque exploitation ; les exploitations qui ont les moyens d'acheter des capteurs étaient peut-être déjà, dès le départ, mieux équipées, mieux financées et mieux gérées. La corrélation est donc utile pour découvrir des schémas et construire des prédictions, mais à elle seule elle ne répond pas à la question :

Modifier ce facteur sur une autre exploitation conduira-t-il au même résultat ? Pourquoi cette distinction importe-t-elle à l'agriculteur ? Cette distinction n'est pas un débat statistique abstrait, éloigné du terrain. Si le système trouve une relation entre une variable et le rendement, puis la convertit directement en recommandation, il est passé de l'observation d'une corrélation à la présomption d'une causalité. Un système qui prédit qu'une parcelle donnée obtiendra un rendement élevé ne sait pas nécessairement comment faire qu'une autre parcelle obtienne le même rendement. Sa capacité prédictive peut reposer sur des facteurs que l'agriculteur ne peut pas modifier, tels que le type de sol, l'historique du site ou les conditions de la saison. De même, un système peut être capable de prédire quelles parcelles sont les plus vulnérables au stress, mais cela ne prouve pas automatiquement qu'une intervention qu'il propose préviendra le stress ou apportera un bénéfice économique. Pour cette raison, trois étapes doivent être distinguées :

1. L'observation : quelle relation est apparue dans les données ?
2. L'interprétation : quelles sont les raisons possibles de cette relation ?
3. L'intervention : quels éléments de preuve indiquent que modifier un facteur particulier changera le résultat ?

Plus nous passons d'une étape à la suivante, plus les éléments de preuve requis doivent être solides. Comment nous rapprocher de la connaissance de l'effet d'une intervention ? Pour déterminer si l'intervention est bien ce qui a fait la différence, nous avons besoin d'une méthode qui sépare son effet de celui des autres facteurs autant que possible. Cela peut passer par :

• un essai au champ approprié comparant des traitements déterminés.
• une répartition des traitements qui réduise les différences préexistantes entre les groupes.
• la comparaison de parcelles ou de placettes aussi semblables que possible.
• la mesure des conditions avant et après l'intervention, avec une situation de référence claire.
• le recours à un plan d'analyse causale qui énonce ses hypothèses et ses limites.
• la mobilisation de connaissances agronomiques ou biologiques expliquant comment le facteur pourrait conduire au résultat.
• la reproduction du résultat sur différents sites ou différentes saisons.

Utiliser une méthode appelée « inférence causale » ne signifie pas non plus qu'une relation est devenue causale du seul fait que le logiciel lui a attribué un nombre. Toute analyse causale repose sur des hypothèses : quels facteurs ont été mesurés ? Quels facteurs manquaient ? Les groupes étaient-ils comparables ? Et la cause a-t-elle précédé le résultat dans le temps ? Et un algorithme ne peut corriger l'absence de mesure ou d'enregistrement d'un facteur important qu'en s'appuyant sur des hypothèses supplémentaires qu'il convient d'expliciter. La règle pratique : un modèle bon en prédiction n'est pas nécessairement bon pour estimer l'effet d'une intervention. Une prédiction exacte du résultat ne prouve pas que le système sait comment changer ce résultat. Qu'apportent les modèles probabilistes ? Dans de nombreuses situations agricoles, les données ne suffisent pas à donner une réponse définitive. L'image peut manquer de netteté, les symptômes peuvent se chevaucher, la série météorologique peut être incomplète, ou le relevé du capteur peut être instable. Plutôt que de dissimuler cette insuffisance, les modèles probabilistes tentent d'exprimer le degré d'incertitude. Imaginons des taches apparaissant sur les feuilles d'une culture. Les causes possibles peuvent être :

• une maladie fongique.
• une carence nutritionnelle.
• un stress hydrique.
• un dommage dû à la chaleur ou au soleil.
• un dommage mécanique.
• plus d'une cause à la fois.

Si le système s'appuie sur une seule image, il peut ne pas être en mesure de distinguer ces causes avec assurance. Il ne doit donc pas sauter directement à un diagnostic unique ; il peut plutôt hiérarchiser les possibilités et indiquer ce dont il a besoin pour les restreindre. C'est ce que l'on entend par diagnostic différentiel : comparer plusieurs explications possibles des symptômes, puis rassembler des informations qui aident à en écarter certaines et à en renforcer d'autres. Par exemple, le système peut demander :

• une image de la face inférieure de la feuille.
• une description de la répartition des symptômes au sein de la parcelle.
• si les symptômes sont apparus sur des feuilles plus jeunes ou plus âgées.
• un relevé de la température et de l'humidité.
• des informations sur l'irrigation ou les traitements antérieurs.
• une inspection au champ ou un test approprié en cas de besoin.

À mesure que chaque nouvelle information arrive, le système révise la hiérarchisation des possibilités. La valeur, ici, ne réside pas dans la rapidité à attribuer un nom, mais dans l'organisation de ce que nous savons et de ce que nous ignorons, et dans l'identification de la prochaine information la plus utile. La probabilité n'est pas une certitude persuasive mise en chiffres Le système peut dire : La probabilité de cette condition est de 80 %. Mais que signifie ce nombre ? Il ne signifie pas que la feuille considérée est « infectée à 80 % », ni que 80 % de la feuille est infectée. Ce qu'il signifie, si le système est bien calibré, c'est que lorsqu'il attribue une probabilité proche de 80 % à un grand nombre de cas similaires, le résultat devrait survenir dans environ quatre-vingts cas sur cent, et non dans tous les cas. La concordance entre les nombres de confiance et ce qui se produit réellement s'appelle la calibration des probabilités. Supposons qu'un système ait attribué à cent cas une probabilité proche de 80 % :

• s'il est confirmé dans environ quatre-vingts cas, sa confiance est relativement conforme à la réalité.
• s'il n'est confirmé que dans cinquante cas, le système est plus confiant qu'il ne devrait l'être.
• s'il est confirmé dans quatre-vingt-quinze cas, le système est peut-être moins confiant que ses résultats ne le justifient.

Cette comparaison ne se mène pas sur un cas isolé, mais sur un nombre approprié de cas similaires. Hiérarchiser les cas ne signifie pas que les nombres de probabilité sont corrects Le système peut réussir à hiérarchiser les cas du plus probable au moins probable, tout en attribuant des nombres de confiance trompeurs. Un cas auquel il a attribué 90 % peut effectivement être plus probable qu'un cas auquel il a attribué 60 %, et en ce sens le classement du système est utile. Mais si les cas auxquels il a attribué 90 % ne sont confirmés que dans 65 % des cas, alors ses nombres de confiance sont surévalués. Il existe donc deux questions distinctes :

1. Le système hiérarchise-t-il les cas de manière utile ?
2. Les nombres de probabilité reflètent-ils la réalité à un degré acceptable ?

Il peut réussir dans le premier cas et échouer dans le second. Pourquoi la confiance change-t-elle lors du passage à une nouvelle exploitation ? Les probabilités d'un système peuvent être bien calibrées dans l'environnement où il a été testé, puis devenir trompeuses lorsqu'il est transféré ailleurs. Cela peut se produire en raison de différences tenant :

• au cultivar.
• au stade de développement.
• au climat.
• à l'étendue de la propagation de l'affection.
• à la caméra ou au capteur.
• à la qualité de l'image.
• aux pratiques de gestion.
• À la proportion des cas rares et des cas courants.
• À la méthode employée pour confirmer le diagnostic.

Il ne suffit donc pas que le fournisseur montre que les probabilités étaient appropriées dans les données de développement. La confiance doit être suivie après le transfert, comparée aux résultats réels, et recalibrée au besoin. Le recalibrage ne rend pas automatiquement le modèle adapté si le nouvel environnement est fondamentalement différent ; de nouvelles données ou une révision du périmètre d'utilisation lui-même peuvent s'avérer nécessaires. Comment le résultat doit-il être présenté à l'utilisateur ? Idéalement, le système ne devrait pas présenter un nombre brut ni une réponse définitive, mais afficher le résultat en quatre strates : 1\. Le résultat le plus probable et l'incertitude Par exemple : Plusieurs causes sont possibles, et les données actuelles ne suffisent pas à en confirmer une seule. Ou : L'estimation se situe dans un certain intervalle et peut changer si la météo ou la gestion change. 2\. Les éléments de preuve qui ont influencé la pondération Par exemple : La probabilité d'un stress hydrique a augmenté en raison de relevés d'humidité faibles et de températures élevées, mais un relevé de capteur est manquant. 3\. L'information manquante et l'étape suivante Par exemple : Il faut vérifier le capteur, ou une image supplémentaire est nécessaire, ou une description de la distribution des symptômes, ou encore l'examen d'un spécialiste, avant que les possibilités puissent être restreintes. 4\. Les limites de la décision et la responsabilité Par exemple : Ce résultat est une alerte préliminaire, non un diagnostic confirmé ni une consigne d'appliquer un traitement. Ainsi, la probabilité devient un outil de structuration d'une décision, et non un nombre qui confère au système une autorité qu'il ne possède pas. Exemple pratique : la prédiction du rendement n'est pas une recette pour l'augmenter Supposons qu'un modèle prédise le rendement à partir :

• Du type de sol.
• De la météo.
• De la variété.
• Du calendrier des opérations.
• Des registres d'irrigation.
• Des données des saisons précédentes.

Le modèle peut produire une bonne prédiction parce qu'il a appris que certaines parcelles dotées d'un meilleur sol et d'une gestion plus constante donnent des rendements plus élevés. Mais s'il remarque également qu'un rendement supérieur était associé à l'augmentation de l'un des intrants, il ne peut pas en déduire directement qu'augmenter cet intrant dans toutes les parcelles élèvera le rendement. Cette augmentation peut n'être appropriée que pour certaines parcelles ou certaines conditions, ou n'être qu'un simple marqueur associé aux exploitations les mieux gérées. Un modèle prédictif répond à la question : Quel est le rendement probable dans ces conditions ? L'estimation de l'effet d'une intervention, en revanche, demande : En quoi le rendement aurait-il différé si nous avions modifié ce seul facteur, les autres facteurs restant comparables ? La seconde question est plus difficile, car elle porte sur un résultat alternatif que nous n'avons pas observé dans la même parcelle au même moment. C'est pourquoi elle exige une conception, une expérimentation et des hypothèses plus explicites que la simple observation de la relation dans les registres. Questions pratiques avant d'accepter une recommandation fondée sur une relation statistique Le lecteur peut demander :

• Le système fournit-il une prédiction, ou prétend-il estimer l'effet d'une intervention ?
• Quels autres facteurs pourraient expliquer la relation apparente ?
• L'intervention elle-même a-t-elle été testée, ou a-t-elle seulement été observée dans des données antérieures ?
• Les parcelles ou les groupes étaient-ils comparables ?
• Quels facteurs importants n'ont pas été mesurés ?
• Le résultat a-t-il été reproduit dans différents lieux et différentes saisons ?
• Le système présente-t-il un intervalle et une probabilité, ou un nombre définitif ?
• La validité des chiffres de confiance a-t-elle été testée après le transfert vers l'environnement local ?
• Quelles informations supplémentaires pourraient réduire l'incertitude ?
• Qui détient l'autorité de transformer le résultat en action ?

La règle de distinction La différence peut se résumer en trois questions :

• Que se passe-t-il en ce moment ? Une question de mesure ou de diagnostic.
• Que va-t-il probablement se passer ensuite ? Une question de prédiction.
• Qu'est-ce qui changera si nous intervenons ? Une question causale qui exige des éléments de preuve plus solides.

Un système responsable indique le type de question auquel il répond, et ne transforme pas la corrélation en causalité, ni une prévision en prescription, ni une probabilité en certitude.

6. Optimisation et recherche opérationnelle

La prédiction dit ce qui peut se produire, tandis que l'optimisation cherche une action ou un plan parmi de nombreuses possibilités sous des contraintes déterminées. Elle peut répartir une eau limitée entre des secteurs, organiser un itinéraire de collecte, coordonner la récolte, le transport et la réfrigération, ou affecter des ouvriers et des machines à des fenêtres temporelles concurrentes. Un problème d'optimisation se compose de trois éléments :

1. Des décisions modifiables : quand devons-nous irriguer ? Quel itinéraire le véhicule doit-il emprunter ? Quel lot doit être refroidi en premier ?
2. Des contraintes à ne pas ignorer : capacité de pompage, temps, stock, sécurité, énergie, main-d'œuvre et limites agricoles.
3. Un objectif que nous voulons améliorer : réduire l'eau, le temps ou les pertes, ou équilibrer plusieurs objectifs.

Imaginons trois secteurs qui ont besoin d'irrigation, alors que la capacité de pompage ne permet pas de les faire fonctionner en même temps. Le système peut proposer un calendrier qui tient compte de l'état hydrique, de la priorité des cultures et du prix de l'énergie. Mais si la fonction objectif minimise la seule consommation d'électricité, elle peut retarder un secteur sensible. Et si elle maximise le seul rendement attendu, elle peut ignorer la part d'un petit agriculteur ou une limite de prélèvement d'eau. L'algorithme exécute ce qui a été défini pour lui ; il n'ajoute pas de lui-même les valeurs que le concepteur a oublié de préciser. Pour cette raison, il n'existe pas de « solution optimale » dans l'absolu. Il existe une solution optimale au regard d'un objectif, de contraintes et de données à un instant donné. Si les priorités changent, si une ressource fait défaut ou si la confiance dans la prédiction décline, le système doit recalculer ou basculer sur un plan de remplacement. Dans les problèmes réels, les objectifs sont multiples. Nous voulons préserver le rendement, réduire l'usage de l'eau et de l'énergie, éviter le stress et respecter la fenêtre de travail. Ces valeurs ne peuvent pas toujours être ramenées à un nombre neutre. Dès lors, présenter plusieurs scénarios et leurs arbitrages est plus honnête que de présenter un plan unique comme s'il était la seule réponse. Le système doit aussi disposer d'un mode manuel sûr. En cas de perte de communication, de défaillance des données météorologiques ou de conflit entre contraintes, le processus principal ne doit pas s'arrêter ni se poursuivre sur un ancien plan sans avertissement. La puissance de l'optimisation ne se mesure pas seulement à l'élégance du plan dans des conditions idéales, mais à sa capacité à composer avec les contraintes et les exceptions réelles. Question pratique : lorsqu'un fournisseur dit « nous optimisons l'irrigation », demandez : quel objectif le système optimise-t-il ? Qui a fixé les pondérations de l'eau, du rendement et de l'énergie ? Et quel est le plan si les données sont incomplètes ?

7. Apprentissage par renforcement et commande : comment le système apprend-il d'une séquence d'actions ?

Dans certains problèmes agricoles, la tâche ne consiste pas à émettre une prévision unique puis à s'arrêter. Chaque action entreprise modifie l'état de l'exploitation ou de la machine, et le nouvel état influe sur la décision qui suit. Lorsqu'on ouvre un ouvrant dans une serre, la température peut baisser et l'humidité changer, mais l'effet de l'ouverture dépend aussi de la température de l'air extérieur, du vent et de la durée pendant laquelle l'ouvrant reste ouvert. Et lorsqu'un robot se déplace entre les rangs, sa position change, tout comme ce que ses caméras peuvent voir ; un ouvrier, un animal ou un obstacle peut apparaître devant lui alors qu'il n'y était pas quelques instants plus tôt. Dans de tels problèmes, nous n'avons pas affaire à une décision unique, mais à une séquence de décisions interdépendantes. C'est là que l'apprentissage par renforcement peut avoir un rôle. Qu'entend-on par apprentissage par renforcement ? L'apprentissage par renforcement est une méthode par laquelle le système apprend à choisir une séquence d'actions en observant les résultats de ce qu'il fait. Le mot « renforcement » ne signifie pas que ce type d'apprentissage est meilleur ou plus puissant que toutes les autres méthodes. Il signifie qu'après ses actions, le système reçoit des signaux numériques qui renforcent les choix le rapprochant du but, et diminuent la valeur des choix qui l'en éloignent ou le conduisent à des résultats indésirables. On peut comparer l'idée à un apprenant qui essaie plusieurs manières d'atteindre un résultat, puis retient progressivement celles qui ont conduit aux meilleurs résultats. Mais cette comparaison a ses limites ; le système ne comprend pas l'exploitation en termes éthiques ou agronomiques, et il ne sait pas de lui-même ce qui doit compter comme « meilleur ». Ce sont les humains qui déterminent ce qu'il mesure, quelles actions lui sont accessibles, et quelles limites ne doivent pas être franchies. L'apprentissage par renforcement se compose de plusieurs éléments principaux :

1. L'état : l'information qui décrit la situation actuelle dans la mesure où le système peut la mesurer.
2. L'action : l'option que le système peut exécuter à cet instant.
3. Le résultat : ce qui a changé dans l'environnement après l'exécution de l'action.
4. Le score numérique : un signal indiquant si le résultat s'est rapproché du but ou en a été éloigné.
5. La stratégie de sélection : la méthode que le système apprend pour choisir l'action appropriée dans chaque état.

Les spécialistes appellent agent le programme qui choisit les actions, récompense le score numérique, et politique la stratégie de sélection. Mais comprendre les fonctions importe davantage que mémoriser les noms. Un exemple simplifié tiré d'une serre Supposons qu'il existe un système qui aide à gérer la température, l'humidité et l'énergie à l'intérieur d'une serre. L'état que le système perçoit Les informations disponibles peuvent comprendre :

• La température à l'intérieur de la serre.
• L'humidité.
• La température extérieure.
• L'intensité de l'ensoleillement.
• La vitesse du vent.
• L'état des ouvrants et des ventilateurs.
• L'humidité du substrat de culture.
• L'heure de la journée.
• L'état des capteurs et des équipements.

Ce n'est pas « l'environnement dans son ensemble », mais la partie que les appareils peuvent mesurer et transmettre au système. Ainsi, si l'un des capteurs est défaillant, ou si les données arrivent en retard, le système peut prendre sa décision sur la base d'une image incomplète ou périmée. Les actions qu'il peut choisir Les actions disponibles peuvent comprendre :

• Ouvrir un ouvrant selon un degré déterminé.
• Le fermer.
• Mettre un ventilateur en marche.
• Réduire ou augmenter la vitesse du ventilateur.
• Déployer l'ombrage.
• Maintenir l'état actuel.
• Demander l'intervention d'un ouvrier au lieu d'une exécution automatique.

Le système ne doit pas non plus être autorisé à accomplir toute action imaginable. Les actions disponibles doivent être définies à l'avance et bornées par les limites des équipements, de la sécurité et de la culture. Que se passe-t-il après l'action ? Si le système ouvre l'ouvrant, la température peut baisser, mais l'humidité peut également changer. La consommation d'énergie peut elle aussi augmenter si le système compense ce changement en faisant fonctionner d'autres équipements. Et une action peut convenir à un moment de la journée et ne pas convenir à un autre. Le système observe ce qui s'est produit après l'action, puis utilise le résultat pour améliorer ses choix ultérieurs. Il n'apprend donc pas d'une décision isolée, mais d'une séquence : État → action → changement dans l'environnement → nouvel état → nouvelle action Que signifie « récompense » ? La récompense, dans ce contexte, n'est pas un prix, et elle ne signifie pas que le système éprouve satisfaction ou punition. C'est un score numérique défini par le concepteur pour évaluer le résultat d'une action. Le score peut monter lorsque :

• La température et l'humidité restent dans l'intervalle requis.
• La consommation d'énergie baisse sans nuire aux conditions des plantes.
• Le système évite de faire fonctionner des équipements inutilement.
• Il préserve la stabilité de l'environnement au lieu de provoquer des changements brusques.
• Il demande l'intervention d'un ouvrier lorsque les données sont insuffisantes ou contradictoires.

Et le score peut baisser lorsque :

• Les conditions dépassent les limites acceptables.
• Le système utilise plus d'énergie ou d'eau que nécessaire.
• Il allume et éteint les équipements à répétition d'une manière qui accélère leur usure.
• Il ignore un capteur défaillant.
• Il choisit une action qui s'approche des limites de sécurité.

Ainsi, l'expression « une récompense qui exprime le but » signifie en réalité : Une équation ou une méthode de calcul fixée par le concepteur pour convertir plusieurs résultats — tels que l'état des plantes, l'énergie, l'eau et la stabilité des équipements — en signaux qui aident le système à comparer ses actions. Mais ce score ne représente pas nécessairement le but dans son intégralité. Ce que le concepteur n'inclut pas dans le calcul, le système peut ne pas en tenir compte. Quand le système atteint le chiffre mais manque la finalité Supposons que le concepteur n'ait assigné au système qu'un seul but : minimiser la consommation d'énergie. Le système peut apprendre à réduire le fonctionnement des ventilateurs ou de la ventilation plus qu'il ne le faudrait. Il peut réussir, sur le plan computationnel, à réduire la consommation d'électricité tandis que la température ou l'humidité à l'intérieur de la serre se dégrade. Supposons que le but soit de maintenir la température à une valeur unique. Le système peut allumer et éteindre à répétition les équipements de chauffage et de refroidissement, ignorer l'humidité, ou consommer de grandes quantités d'énergie afin d'empêcher une petite variation naturelle qui ne nuit pas à la plante. Dans les deux cas, le système a computationnellement fait ce qui lui était demandé, mais il n'a pas atteint la finalité agricole plus large. L'erreur, ici, ne provient pas nécessairement d'une faiblesse de l'algorithme. L'erreur peut résider dans la manière dont les humains ont formulé l'objectif. Le système peut optimiser le score qui lui a été donné, mais il ne connaît pas automatiquement les intérêts et les contraintes qui n'ont pas été inclus dans sa définition. Par conséquent, selon le problème, la méthode d'évaluation doit inclure :

• L'état des plantes.
• L'eau et l'énergie.
• La stabilité des équipements.
• La sécurité des personnes et des animaux.
• Les limites d'exploitation.
• Le coût des changements fréquents.
• La capacité de se replier sur un mode sûr.
• Les cas dans lesquels la décision doit être remise à un humain.

La règle fondamentale : le système n'apprend pas ce que nous voulons dans notre esprit ; il apprend ce que nous avons exprimé dans les données, les scores et les contraintes. Pourquoi une pénalité computationnelle ne suffit-elle pas à protéger la sécurité ? Un concepteur peut songer à abaisser le score lorsque le système exécute une action dangereuse. Mais certaines actions ne doivent pas pouvoir être essayées d'emblée, même si elles conduiraient ensuite à un score négatif. Par exemple, le système ne doit pas être autorisé à apprendre le danger d'interrompre la ventilation dans des conditions sévères en exécutant l'action et en mettant la plante en péril. Un robot ne doit pas non plus apprendre que s'approcher d'un ouvrier n'est pas sûr en entrant une fois en collision avec cet ouvrier. Il faut donc distinguer entre :

• Les objectifs que le système peut optimiser.
• Les limites de sécurité qu'il ne doit pas franchir.

Le système peut chercher à réduire l'usage de l'énergie ou à améliorer la stabilité à l'intérieur de l'intervalle autorisé, mais une couche indépendante doit l'empêcher :

• De dépasser une limite de température dangereuse.
• D'actionner un outil lorsqu'un humain se trouve dans la zone de mouvement.
• De poursuivre si des capteurs critiques défaillent.
• D'exécuter une commande comportant une unité ou une valeur hors des limites approuvées.
• De continuer à se déplacer après la perte de la localisation ou de la communication.
• De désactiver le mécanisme d'arrêt manuel.

Ces limites sont parfois appelées contraintes strictes, c'est-à-dire des règles opérationnelles impératives que le système ne peut enfreindre pour obtenir un meilleur score. Qu'entend-on par exploration ? Pour que le système sache quelles actions sont les meilleures, il peut avoir besoin d'essayer des options qu'il a peu employées auparavant. C'est ce qu'on appelle l'exploration. Mais l'exploration dans un système réel diffère de l'expérimentation à l'intérieur d'un jeu numérique. Une erreur au champ peut gaspiller de l'eau, stresser une culture, endommager des équipements ou mettre un ouvrier en danger. Le système ne doit donc pas être libre d'essayer n'importe quelle action sur l'exploitation. Le risque peut être réduit par un cheminement graduel :

1. L'apprentissage ou l'évaluation commence dans une simulation qui représente raisonnablement bien l'environnement.
2. Les données historiques sont utilisées pour comprendre ce qui s'est produit dans des conditions antérieures, tout en gardant à l'esprit qu'elles ne couvrent pas toutes les actions possibles.
3. Le système est testé en mode de surveillance, proposant des actions sans les exécuter.
4. Ses propositions sont comparées à ce qu'a fait l'opérateur et à ce qui s'est produit ensuite.
5. Il passe à un essai limité dans une plage à faible risque.
6. Les contraintes indépendantes et l'autorité humaine d'arrêt restent actives.
7. L'exploitation n'est étendue qu'après que des éléments de preuve suffisants de sécurité et de stabilité ont été réunis.

La simulation seule ne suffit pas, car elle est une image simplifiée de la réalité. La réponse de la plante, des équipements ou de la météo peut différer de ce que le modèle supposait. On parle parfois à ce sujet de l'écart entre la simulation et la réalité. Le passage à l'exploitation réelle doit donc être graduel, surveillé et réversible. Tout problème de commande n'exige pas l'apprentissage par renforcement L'apprentissage par renforcement peut sembler attirant parce qu'il apprend d'une séquence de décisions, mais il n'est pas automatiquement la meilleure option. Si les règles de fonctionnement sont claires et stables, un système simple fondé sur des règles peut être plus transparent et plus facile à tester. Si la réponse des équipements est connue et peut être bien représentée, des méthodes de commande conventionnelles ou une optimisation sous contraintes peuvent être plus sûres et moins coûteuses. L'apprentissage par renforcement devient un candidat lorsque :

• les décisions sont séquentielles, et que chaque action influe sur ce qui suit.
• le résultat de certaines actions n'apparaît qu'après un délai.
• il existe un arbitrage entre un bénéfice immédiat et un effet ultérieur.
• il est difficile d'écrire une règle fixe couvrant tous les cas.
• un environnement d'entraînement ou une simulation appropriés sont disponibles.
• une plage d'actions sûre peut être spécifiée.
• il existe un moyen de suivre la performance et de revenir en arrière.

Mais si l'objectif consiste simplement à détecter une maladie sur une image, à prédire un rendement ou à émettre une alerte unique, d'autres méthodes peuvent être plus adaptées. L'apprentissage par renforcement ne doit pas être employé au seul motif qu'il paraît plus récent ou plus enthousiasmant. Qui fait quoi au sein du système de commande ? Dans un système agricole réel, plusieurs fonctions doivent être maintenues distinctes : 1\. La mesure de l'état Capteurs et caméras recueillent des informations sur l'environnement et les équipements. Ces informations peuvent être incomplètes, tardives ou inexactes. 2\. L'estimation ou la prédiction de l'état Un modèle peut être utilisé pour estimer ce qui n'est pas mesuré directement, ou pour prédire ce qui peut se produire après l'exécution d'une action donnée. 3\. La sélection de l'action La stratégie de commande détermine l'action proposée au regard de l'état, de l'objectif et des contraintes. 4\. Le contrôle de sécurité Une couche indépendante examine si l'action est permise, si les données sont suffisantes, et si les équipements et l'environnement se trouvent dans un état sûr. 5\. L'exécution Les commandes sont envoyées aux ouvrants, aux ventilateurs, aux pompes ou aux moteurs, et il faut confirmer que la commande a été effectivement exécutée, et non simplement envoyée. 6\. La vérification du résultat Le système compare ce qui était attendu à ce qui s'est produit après l'exécution. Si l'appareil ne répond pas, ou se déplace autrement, cela doit être détecté. 7\. La supervision humaine Un humain détient l'autorité d'approuver, d'arrêter ou de passer outre, et peut revenir à un fonctionnement manuel explicite lorsque l'application ou la connexion tombe en panne. Cette séparation est importante, car la réussite d'une partie ne prouve pas la réussite du système entier. Le logiciel peut sélectionner une action appropriée, mais la vanne ne répond pas. La vanne peut exécuter la commande, mais le capteur qui confirme le résultat peut être défaillant. Les composants peuvent fonctionner techniquement, mais l'objectif lui-même peut être incomplet. Qu'entend-on par apprentissage par renforcement profond ? L'apprentissage par renforcement profond est un apprentissage par renforcement qui utilise des réseaux de neurones profonds pour aider le système à représenter des états complexes, à estimer la valeur des actions ou à les sélectionner. Et le mot « profond » ne signifie pas que le système :

• comprend l'environnement à la manière d'un humain.
• est plus sûr.
• exige nécessairement un robot.
• voit automatiquement des images.
• est adapté à un déploiement au champ.
• est meilleur que des règles ou une commande conventionnelle.

L'apprentissage par renforcement profond peut être utilisé dans un environnement simulé pour sélectionner des actions, tandis que la vision par ordinateur utilise un autre modèle pour analyser des images. Les deux peuvent opérer au sein d'un même robot, mais ils remplissent deux fonctions différentes. Une correction de source importante : voir l'adventice n'est pas commander son élimination Dans un matériau éditorial antérieur de ce livre, une formule est apparue décrivant l'une des études de détection des adventices comme un exemple d'« apprentissage par renforcement profond » utilisé pour une élimination robotisée. Or la source qui a pu être vérifiée [SRC009] porte sur la classification d'images captées dans des champs de soja à l'aide de réseaux de neurones convolutifs. Autrement dit, l'étude étaye l'une des tâches de la vision par ordinateur : analyser l'image et distinguer des motifs. Et cette source n'établit pas que l'étude ait développé :

• un système qui apprend une séquence d'actions.
• une stratégie de commande dans un robot.
• un signal de récompense pour évaluer l'élimination.
• un déplacement automatisé vers l'adventice.
• un déploiement au champ pour l'élimination.
• un système fondé sur l'apprentissage par renforcement profond.

La différence est fondamentale : La vision par ordinateur demande : y a-t-il une adventice dans l'image, et où se trouve-t-elle ? L'apprentissage par renforcement et la commande, en revanche, demandent : Quelle action la machine doit-elle entreprendre maintenant, et comment influera-t-elle sur l'état et sur l'action suivante ? Un robot de désherbage peut avoir besoin d'un modèle de vision pour identifier la plante, puis d'un autre système pour déterminer la localisation, puis d'un planificateur de mouvement, puis d'un organe de commande pour exécuter l'action, puis d'une couche de sécurité qui arrête la machine lorsqu'un danger survient. La réussite d'un algorithme de classification ne prouve pas la réussite de cette chaîne. Insérer cette correction n'est pas une querelle de dénomination, mais une application de la méthode probatoire du livre : aucun algorithme, aucune capacité opérationnelle et aucun impact au champ ne doivent être attribués à la source si elle ne les établit pas. Exemple intégré : la gestion de la ventilation dans une serre Supposons que le système gère un ouvrant et un ventilateur à l'intérieur d'une serre. À un instant donné, il relève :

• une température intérieure légèrement élevée.
• une humidité élevée.
• une température extérieure plus basse.
• des vents modérés.
• aucune alarme d'équipement.

Il peut choisir entre :

• laisser les choses en l'état.
• ouvrir partiellement l'ouvrant.
• l'ouvrir davantage.
• mettre le ventilateur en marche.
• utiliser conjointement l'ouvrant et le ventilateur.
• demander l'examen d'un ouvrier.

S'il ouvre partiellement l'ouvrant et que la température et l'humidité baissent sans consommation d'énergie élevée, la méthode d'évaluation enregistre que le résultat s'est rapproché du but. Si l'action provoque un changement brusque ou que l'humidité sort de l'intervalle, le score numérique décline. Mais il doit néanmoins exister des règles non soumises à l'expérimentation, telles que :

• ne pas faire fonctionner les équipements si le capot de maintenance est ouvert.
• ne pas poursuivre lorsque des capteurs critiques se contredisent.
• ne pas dépasser les limites de fonctionnement des moteurs.
• passer en mode sûr en cas de perte de communication.
• permettre à l'ouvrier de l'arrêter immédiatement.

Ainsi, le système apprend à l'intérieur d'un espace autorisé et n'a pas la liberté de redéfinir la sécurité par l'expérimentation. Questions pratiques avant d'accepter un système fondé sur l'apprentissage par renforcement L'agriculteur, l'acheteur ou l'exploitant peut demander :

• Quelles décisions séquentielles le système apprend-il à prendre ?
• Quelles informations décrivent l'état actuel ?
• Que se passe-t-il si un capteur important est défaillant ou tardif ?
• Quelles actions le système est-il autorisé à entreprendre ?
• Comment a été calculé le score numérique qui guide l'apprentissage ?
• Quels aspects n'ont pas été inclus dans ce score numérique ?
• Quelles limites le système ne peut-il pas dépasser ?
• Où l'entraînement a-t-il été mené : en simulation ou en exploitation réelle ?
• Comment l'écart entre la simulation et l'exploitation a-t-il été traité ?
• Le système a-t-il commencé par la recommandation et la surveillance avant l'exécution ?
• Que se passe-t-il lorsqu'il rencontre une situation qu'il n'a jamais vue auparavant ?
• Existe-t-il un mécanisme d'arrêt local indépendant de l'application ?
• Qui détient l'autorité d'approuver, de passer outre et de revenir au mode manuel ?
• L'apprentissage par renforcement est-il véritablement nécessaire, ou existe-t-il une approche plus simple et plus claire ?

Pour le lecteur avancé : l'évaluation d'un système d'apprentissage par renforcement ne se limite pas au score moyen qu'il a obtenu pendant l'entraînement. Son comportement dans les cas rares, la stabilité de sa performance, sa sensibilité à la manière dont l'objectif est défini, sa capacité à fonctionner avec des données incomplètes, son respect des contraintes, l'écart entre la simulation et la réalité, ainsi que la sûreté du passage de la recommandation à l'exécution, doivent tous être examinés. Conclusion L'apprentissage par renforcement n'est pas une méthode qui donne à la machine la liberté d'expérimenter au champ. C'est une approche permettant d'apprendre à choisir des actions séquentielles à l'intérieur de limites conçues par des humains. Sa valeur dépend de cinq choses :

1. Que l'information disponible décrive véritablement l'état pertinent.
2. Que le score numérique représente l'objectif agricole sans le réduire à un nombre trompeur.
3. Que la sécurité demeure dans des règles indépendantes auxquelles il ne doit pas être dérogé.
4. Que le passage de la simulation à l'exploitation soit graduel et réversible.
5. Que les êtres humains restent ceux qui détiennent l'autorité d'arrêter le système et de donner l'approbation finale.

Et la règle que le lecteur doit retenir est la suivante : Le système n'apprend pas l'objectif que nous visons implicitement ; il apprend le comportement que les nombres récompensent et que les contraintes permettent. Il faut donc tester l'objectif et les limites avant de tester l'intelligence de l'algorithme. La règle de sécurité finale peut être énoncée plus clairement ainsi : Le champ ne doit pas être le premier endroit où le concepteur découvre que la méthode d'évaluation du système est incomplète, ou qu'essayer une nouvelle action peut nuire à la culture, aux personnes ou aux équipements.

8. Modèles de langage, génération et récupération : de la question à la réponse ancrée

Un agriculteur peut interroger l'assistant numérique en langage ordinaire au lieu de parcourir de longs menus ou de remplir un formulaire technique complexe. Il peut s'enquérir du sens d'une alerte, demander le résumé d'un document, faire traduire des consignes, comparer deux registres, ou extraire une information précise d'un rapport. Cette facilité est l'un des bénéfices les plus importants des modèles de langage, mais elle est aussi une source potentielle de malentendu. Une réponse rédigée dans une langue claire et assurée peut sembler provenir d'un expert qui connaît le domaine, le lieu et le produit, alors qu'en réalité le système peut l'avoir composée à partir de motifs linguistiques ou d'informations incomplètes qui ne suffisent pas à une prise de décision. Il ne suffit donc pas de demander : Le système sait-il rédiger une réponse compréhensible ? Nous devons aussi demander : D'où provient l'information contenue dans la réponse ? Et s'applique-t-elle à cette culture, ce lieu, ce moment et cette décision ? Que font les modèles de langage ? Un modèle de langage est un système entraîné sur de grandes quantités de texte afin d'apprendre les relations qui se répètent entre mots, phrases et idées. Lorsqu'on lui demande une réponse, il construit le texte morceau par morceau à partir de la question, des instructions du système et du contexte dont il dispose. Il peut être employé pour des tâches telles que :

• Résumer un long document.
• Traduire un contenu d'une langue vers une autre.
• Transformer des notes éparses en un rapport organisé.
• Extraire d'un registre le nom de la culture, le lieu, la date ou l'unité.
• Expliquer un terme technique dans une langue plus simple.
• Comparer plusieurs documents.
• Gérer un dialogue comportant plus d'une question et d'une réponse.
• Formuler en langue naturelle une réponse que l'utilisateur puisse lire.

Mais ces capacités ne signifient pas que le modèle possède une compréhension agricole indépendante ni une mémoire à jour de chaque réglementation, prix et produit. Il est bon pour construire un texte cohérent, et ce faisant il peut mobiliser une information correcte, une information incomplète, ou une liaison qui paraît linguistiquement plausible sans être solidement ancrée dans la source. La fluidité est donc une propriété de la formulation de la réponse, et non une preuve de l'exactitude de son contenu. Comment une réponse peut-elle être convaincante et pourtant non étayée ? Lorsque le modèle ne dispose pas d'assez d'informations, il peut ne pas laisser la lacune visible. Il peut compléter la phrase par une formulation qui semble plausible d'après les motifs appris de textes antérieurs. Il peut en résulter :

• Un nombre qui ne figure pas dans la source.
• Une cause incertaine présentée comme s'il s'agissait d'un diagnostic.
• Une dose qui paraît raisonnable mais qui n'est rattachée à aucun produit homologué.
• Un nom de produit non adapté à la culture ou au pays.
• Un prix périmé, ou provenant d'un autre marché.
• Une citation qui paraît officielle mais qui n'étaye pas l'affirmation.
• Une traduction qui a omis une réserve, modifié une unité ou surestimé le degré de certitude.
• Une réponse générale présentée comme s'il s'agissait d'une recommandation propre à l'exploitation.

Cela ne signifie pas que le modèle cherche délibérément à tromper. Le problème est qu'il est conçu pour produire un texte qui s'accorde au contexte linguistique, non pour garantir que chaque phrase a été vérifiée par rapport à une source valable pour cette décision. La règle fondamentale : la capacité d'un système à compléter une phrase ne signifie pas qu'il dispose des éléments de preuve nécessaires pour compléter une décision. Une brève question agricole peut dissimuler une grande quantité d'informations Si un agriculteur demande : « Des taches sont apparues sur ma culture ; que dois-je utiliser ? » la phrase peut sembler claire sur le plan linguistique, mais elle est incomplète sur le plan agronomique. Elle ne nous dit pas :

• Quelle est la culture ?
• Quelle est la variété ?
• Quel est l'âge de la plante et son stade de développement ?
• Où l'exploitation est-elle située ?
• Quand les symptômes sont-ils apparus ?
• Sont-ils apparus sur les jeunes feuilles ou sur les anciennes ?
• Sont-ils sur la face supérieure ou sur la face inférieure ?
• Sont-ils répandus sur l'ensemble de la parcelle, ou cantonnés à des zones limitées ?
• Y a-t-il des symptômes sur la tige, la racine ou le fruit ?
• Quelles sont les conditions météorologiques et d'irrigation ?
• Un traitement antérieur a-t-il été utilisé ?
• L'image est-elle nette, et est-elle représentative du cas ?
• Quels produits sont homologués pour cette culture et ce ravageur dans le pays d'utilisation ?
• Existe-t-il des restrictions liées au délai avant récolte ou au délai de rentrée des travailleurs ?

Si le système comble ces lacunes de lui-même, il peut donner une réponse adaptée à un cas qu'il a imaginé, et non au cas réellement présent sur l'exploitation. C'est pourquoi un système responsable doit s'arrêter lorsqu'une information manque et demander ce dont il a besoin avant de restreindre les possibilités. La meilleure réponse initiale peut être une question de clarification, et non une recommandation. Quelle est la différence entre génération et récupération ? La génération est le processus consistant à formuler une réponse nouvelle en langue naturelle. Le modèle prend la question et le contexte disponible, puis les organise en un texte que l'utilisateur peut lire. La récupération, en revanche, est la recherche, au sein d'un ensemble de documents ou d'enregistrements, de passages susceptibles d'être pertinents pour la question. Si l'utilisateur s'enquiert du délai d'attente requis pour un produit déterminé, le système peut chercher dans :

• L'étiquette homologuée en vigueur du produit.
• Le registre d'homologation du produit.
• Les documents émis par l'autorité réglementaire compétente.
• Les orientations officielles relatives à la culture et au ravageur.
• Une édition datée d'une base de connaissances agréée.

La récupération ne formule pas nécessairement la réponse finale ; elle trouve plutôt le matériau à partir duquel la réponse peut être construite. Lorsque le système combine la recherche dans des sources et la formulation d'une réponse sur la base de ce qu'il a récupéré, ce flux de travail est appelé génération augmentée par récupération, habituellement abrégé en RAG. Que se passe-t-il dans la génération augmentée par récupération ? Le flux de travail peut être simplifié en six étapes :

1. Comprendre la question : déterminer ce que l'utilisateur demande et quelle information manque.
2. Définir le périmètre de recherche : choisir l'ensemble des sources appropriées à la culture, au lieu et au sujet.
3. Trouver des passages candidats : rechercher les parties de documents qui paraissent pertinentes pour la question.
4. Vérifier la validité : exclure les documents obsolètes, non officiels ou inadaptés au contexte.
5. Formuler la réponse : utiliser les passages retenus pour rédiger une réponse claire.
6. Montrer la source et les limites : permettre à l'utilisateur de savoir d'où vient l'information et ce que la réponse ne peut pas établir.

Ce cheminement peut réduire les réponses non étayées, mais il ne les empêche pas automatiquement. Le système peut se tromper à chacune des six étapes. La récupération n'implante pas de connaissance permanente à l'intérieur du modèle Lorsque le système récupère un document au moment de la question, il en place une partie devant le modèle pour l'aider à formuler la réponse. Cela ne signifie pas que la connaissance est devenue une partie permanente du modèle, ni que toutes ses réponses ultérieures l'utiliseront correctement. Avec une nouvelle question, une nouvelle recherche peut être lancée et un passage différent récupéré. Dès lors, la qualité de chaque réponse dépend :

• de la formulation de la question.
• de l'ensemble des sources disponibles.
• de la manière dont elles sont organisées et indexées.
• des critères de recherche.
• des passages présentés au modèle.
• des consignes qui encadrent la formulation.
• de la capacité du système à s'abstenir lorsqu'il ne trouve pas d'appui suffisant.

Cela signifie qu'évaluer le modèle de langage seul ne suffit pas ; c'est l'ensemble du cheminement de recherche, de formulation et de citation qui doit être évalué. Comment le cheminement de récupération peut-il échouer ? Le cheminement peut échouer de plusieurs manières : 1\. Mécompréhension de la question Il peut interpréter un mot local comme le nom d'une maladie, ou confondre le nom d'une culture avec le nom d'une variété, ou supposer que l'utilisateur interroge sur le traitement alors qu'en réalité il interroge sur l'identification initiale. 2\. Recherche dans un ensemble inadapté Le système peut chercher dans des articles généraux quand la question exige un document local officiel, ou chercher des orientations pour une culture différente. 3\. Récupération d'un document ancien Le document a pu être correct au moment de son émission, mais l'homologation du produit, les restrictions, le prix ou les instructions ont pu changer par la suite. 4\. Récupération d'une source valide pour un contexte différent La recommandation peut être correcte pour un autre pays, une autre variété, un autre stade de développement, ou un système de production différent. 5\. Sélection d'un passage qui partage les mots mais non le sens Le passage peut contenir le nom de la maladie et celui de la culture, mais traiter de la prévention plutôt que du traitement, ou décrire une étude de recherche plutôt que des instructions opérationnelles. 6\. Dépassement de la source lors de la formulation La source peut mentionner une remarque générale, et le modèle peut alors la transformer en une recommandation précise qui n'y figure pas. 7\. Placement d'une citation exacte après une phrase que la source n'étaye pas La présence du nom de la source ou de son lien ne suffit pas. L'affirmation elle-même doit figurer dans la source, avec le même degré de certitude et les mêmes limites. Ainsi, la source peut être fiable, et la récupération peut réussir au niveau textuel, sans que la réponse soit pour autant apte à fonder une décision agricole. La similitude de formulation n'est pas une aptitude à l'usage Supposons que le système trouve un document traitant de taches foliaires sur une culture donnée. Le document peut paraître très pertinent pour la question, mais il peut :

• concerner un pays où l'homologation des produits diffère.
• porter sur une variété ou un environnement différents.
• être une étude de laboratoire plutôt qu'une orientation de terrain.
• décrire des symptômes similaires avec une cause différente.
• être ancien ou avoir été remplacé par une version plus récente.
• traiter de la prévention alors que l'utilisateur interroge sur un cas existant.
• mentionner une substance active sans produit homologué localement.
• être une traduction ayant perdu une réserve importante.

Par conséquent, la récupération ne doit pas reposer sur la seule similitude des mots. La recherche doit être restreinte à l'aide d'informations telles que :

• La culture.
• La variété, si nécessaire.
• Le lieu et la juridiction compétente.
• Le stade de développement.
• La date.
• Le type de document.
• L'organisme émetteur.
• Le statut du document : en vigueur, archivé, projet, ou abrogé.
• Le statut d'homologation du produit.
• Le type de décision : information générale, diagnostic, dosage, ou action réglementée.

Ces conditions sont parfois appelées filtres de recherche. Ce sont des règles qui empêchent le système de traiter tout texte linguistiquement similaire comme pertinent pour la question. Qui agrée les sources ? L'expression « sources agréées » ne doit pas rester vague. Nous avons besoin de savoir :

• Qui a sélectionné la source ?
• De quel type d'autorité dispose-t-elle ?
• S'agit-il d'une source scientifique, réglementaire ou commerciale ?
• Quand a-t-elle été publiée ou mise à jour ?
• Est-elle toujours en vigueur ?
• Pour quelle région, quelle culture et quel système de production est-elle applicable ?
• Quelles affirmations peut-elle étayer ?
• Que ne peut-on pas en déduire ?

Un article scientifique peut aider à comprendre un phénomène ou un résultat de recherche, mais il n'établit pas l'homologation légale d'un produit. Et le mode d'emploi officiel fixe les conditions d'un produit homologué, mais il ne prouve pas à lui seul un effet économique général. Et un prix publié sur un marché officiel peut être exact pour ce marché et cette date, mais il n'équivaut pas nécessairement à ce que perçoit un agriculteur d'une autre région après transport et commission. Ainsi, l'autorité d'une source varie selon la question. Trois couches ne suffisent pas toujours Il est utile qu'une réponse distingue entre ce que disent les sources, ce que le système a déduit, et ce qui requiert une décision humaine. Mais dans les décisions agricoles sensibles, il est préférable de présenter cinq couches : 1\. Ce que le système a compris de la question Par exemple : J'ai compris que vous interrogez sur la cause de taches apparues sur les feuilles d'une culture donnée à un stade de développement précis. Cela donne à l'utilisateur l'occasion de corriger cette compréhension avant que la réponse ne soit construite. 2\. Ce que disent les sources L'affirmation étayée par la source est présentée, avec le nom de la source, sa date et son périmètre. 3\. Ce que le système a assemblé à partir de plusieurs éléments d'information Si le système combine plus d'une source ou déduit une relation, il doit indiquer qu'il s'agit de sa propre formulation ou de sa propre comparaison, et non d'une citation directe. 4\. Ce qui demeure inconnu Par exemple l'absence d'image nette, l'absence d'analyse, l'ignorance du pays, ou le fait de ne pas avoir vérifié si le document est toujours valide. 5\. Ce qui requiert une décision humaine ou une autorité compétente Par exemple le diagnostic final, le choix d'une substance réglementée, la validation du dosage, ou la réalisation d'une intervention susceptible de nuire à la culture ou aux personnes. Cela empêche de confondre une information étayée avec une inférence automatisée ou un jugement professionnel. La citation n'est pas un ornement L'utilisateur doit pouvoir examiner la citation et comprendre son rapport à la réponse. Une bonne citation fait apparaître clairement :

• Le nom du document ou de l'organisme émetteur.
• La date d'émission ou de dernière mise à jour.
• La partie qui a été utilisée.
• Le périmètre du document.
• S'il est officiel, scientifique ou commercial.
• Si le système a reproduit le texte, l'a résumé, ou l'a combiné avec une autre source.

Placer un lien général après un long paragraphe ne montre pas quelle phrase la source étaye. Cela peut donner à la réponse une apparence de documentation sans permettre au lecteur de retracer l'affirmation. Règle : il ne suffit pas que la source existe ; elle doit être pertinente pour la question, elle doit étayer la phrase, et les limites de la phrase doivent rester à l'intérieur des limites de la source. Que fait le système lorsqu'il ne trouve pas d'appui suffisant ? L'abstention n'est pas un échec du dialogue. Le système peut continuer d'aider l'utilisateur sans inventer une réponse. Il pourrait dire :

• Je ne trouve pas de source valide pour ce produit dans le pays indiqué.
• Le document disponible est obsolète et ne suffit pas à établir la dose.
• L'image ne permet pas de distinguer les causes possibles.
• La question requiert le nom de la culture, le stade de développement et le lieu.
• Il existe une information générale, mais elle n'est pas suffisante pour une recommandation de traitement.
• Un examen par un spécialiste ou une analyse est nécessaire avant de choisir l'intervention.

Il propose ensuite une étape suivante sûre :

• Demander une image supplémentaire.
• Préciser le lieu.
• Donner le nom du produit exactement tel qu'il figure sur l'emballage.
• Vérifier le statut d'homologation.
• Consulter le mode d'emploi officiel en vigueur.
• Contacter le service de vulgarisation ou un spécialiste qualifié.

De la sorte, l'abstention devient non pas une impasse, mais une voie claire pour compléter les éléments de preuve. Exemple d'une démarche irresponsable L'utilisateur demande : « Des taches sont apparues sur ma culture ; que dois-je utiliser ? » Le système répond directement : « Utilisez le produit X à telle ou telle dose. » Cette réponse est irresponsable parce qu'elle passe d'une description générale à une substance et à une dose sans connaître :

• La culture.
• Le pays.
• Le diagnostic.
• Le stade de développement.
• Le statut d'homologation.
• Le mode d'emploi officiel.
• Le délai de sécurité.
• S'il existe d'autres causes des symptômes.
• La capacité de l'utilisateur à réaliser le traitement en toute sécurité.

La formulation peut être linguistiquement irréprochable, elle n'en manque pas moins de fondement pour la décision. Exemple d'une réponse responsable La réponse pourrait être : « Les informations actuelles ne suffisent pas à déterminer la cause des taches ni à choisir un traitement. Ces symptômes peuvent se recouper entre maladie, carence nutritionnelle, stress hydrique et dommage lié aux conditions météorologiques. Indiquez le nom de la culture et la variété, si vous la connaissez, le pays ou la région, le stade de développement, et l'endroit où les symptômes apparaissent sur la plante, et envoyez une image nette des faces supérieure et inférieure de la feuille, ainsi qu'une image montrant l'étendue de la propagation du problème dans la parcelle. Je pourrai alors comparer les symptômes avec des sources appropriées et exposer les possibilités ainsi que les informations manquantes, mais indiquer un produit ou une dose requiert la vérification du diagnostic, de l'homologation du produit pour la culture et le ravageur dans le pays d'utilisation, et du mode d'emploi officiel en vigueur, et cela peut nécessiter de consulter un spécialiste. » Cette réponse ne se contente pas de s'abstenir ; elle :

• Explique pourquoi l'information est insuffisante.
• Montre que plus d'une interprétation est possible.
• Demande des données précises.
• Clarifie ce que le système peut faire.
• Identifie ce qui requiert une source officielle ou un spécialiste.
• Empêche l'aisance linguistique de se transformer en autorité thérapeutique injustifiée.

Un autre exemple : une question sur le prix Si un agriculteur demande : « Quel est le prix de ma récolte aujourd'hui ? » il ne suffit pas que le système récupère un chiffre comportant le nom de la culture. Il doit connaître :

• Le pays, la région et le marché.
• La date du prix, et l'heure si nécessaire.
• La devise.
• L'unité de vente.
• La variété.
• La catégorie de qualité.
• S'il s'agit d'un prix de gros, de détail, ou départ exploitation.
• S'il inclut le transport ou la commission.
• Quelle entité l'a publié ?

Et une réponse responsable ne dit pas : « Le prix est de tant. » Elle dit plutôt, par exemple : « J'ai trouvé un prix publié sur le marché indiqué à telle date, pour l'unité et la catégorie mentionnées. Le prix perçu par l'agriculteur peut différer selon la qualité, le transport et la commission, et je n'ai pas vérifié de transaction locale sur votre exploitation. » Cela indique clairement que la récupération a restitué une information de marché précise, et non le « prix réel » en tout lieu. La traduction elle-même requiert une gouvernance Un modèle de langage peut être utilisé pour traduire l'étiquette d'un produit ou une orientation agricole. Mais une traduction fluide peut dissimuler une erreur portant sur :

• L'unité de mesure.
• La négation.
• Le délai d'attente.
• Le nom du ravageur.
• La culture homologuée.
• Le degré d'obligation.
• L'avertissement.
• La juridiction compétente.

Par conséquent, une traduction automatique d'un document de sécurité ne doit pas devenir une autorité alternative au texte officiel. Le système peut aider à la compréhension, mais la référence originale doit être conservée, sa source et sa version indiquées, et la terminologie sensible revue avant mise en œuvre. Comment évaluons-nous le système ? Il ne suffit pas d'apprécier la qualité stylistique ou la satisfaction de l'utilisateur. Chaque étape de la chaîne de traitement doit être testée : Compréhension de la question

• Le système a-t-il identifié la culture, le lieu et le sens visé ?
• A-t-il demandé l'information manquante ?

Récupération

• A-t-il trouvé la source appropriée ?
• A-t-il exclu une source obsolète ou non locale ?
• A-t-il récupéré la partie qui répond à la question ?

Formulation

• La réponse s'en est-elle tenue à ce qu'énonce la source ?
• A-t-elle ajouté une affirmation non étayée ?
• A-t-elle préservé les réserves et l'incertitude ?

Référencement

• Le lecteur peut-il accéder à la source ?
• La source étaye-t-elle réellement la phrase ?
• La date et le statut du document sont-ils indiqués ?

Sécurité

• Le système s'est-il abstenu de fournir une dose ou un diagnostic lorsque les éléments de preuve étaient insuffisants ?
• A-t-il indiqué clairement quand consulter un spécialiste ou une autorité réglementaire ?
• A-t-il empêché qu'une information générale soit transformée en instruction exécutable ?

Application agricole

• La réponse est-elle valable pour la culture, le lieu et le moment ?
• L'utilisateur peut-il la comprendre et l'exécuter ?
• La responsabilité humaine est-elle demeurée claire ?

Le système peut réussir à trouver un document correct, puis échouer à l'interpréter. Il peut formuler une réponse fidèle à un passage inadapté. Il peut fournir une référence authentique pour une phrase que la source n'étaye pas. Par conséquent, c'est toute la chaîne de traitement qui doit être évaluée, et non le modèle isolément. Pour le lecteur avancé : la récupération réduit la dépendance du modèle à ce qu'il a appris antérieurement, mais elle déplace une partie du risque vers la qualité de l'index, la compréhension de la question, le classement des résultats, la validité des documents et la discipline de la génération. Pour cette raison, la réussite de la chaîne de traitement ne se mesure pas à la simple présence d'une source dans la réponse, mais à la justesse de la relation entre la question, la source, l'affirmation, le contexte et la décision. Le rôle du chapitre sept Le renvoi au chapitre sept peut être conservé, mais il est préférable de préciser ce qu'il apportera : Le chapitre sept traitera plus en détail de la manière de construire des systèmes d'aide à la décision et de récupération de connaissances, d'organiser les sources, de restreindre la recherche selon le contexte, de montrer les références, et d'empêcher qu'un texte récupéré ne se transforme en une recommandation qui excède son autorité. Cela confère au renvoi une fonction claire, plutôt que de le laisser à l'état de simple promesse d'informations à venir. Conclusion Un modèle de langage peut faciliter l'accès à la connaissance : il transforme une question ordinaire en recherche, rassemble des passages, les résume, et formule une réponse intelligible. Mais l'aisance linguistique n'abrège pas le chemin scientifique et réglementaire entre la question et la décision. Un système responsable doit donc savoir :

• Ce qu'il a compris de la question.
• Quelle information lui manque.
• Où il a cherché.
• Pourquoi il a choisi la source.
• Si la source est à jour et valide pour le contexte.
• Ce qu'il a tiré de la source.
• Ce qu'il a déduit.
• Où s'arrête son rôle.
• Et quand il doit s'abstenir ou remonter la décision à un être humain.

Le message de la section peut se résumer dans l'énoncé suivant : Un modèle de langage peut être une porte d'entrée vers la connaissance, mais il ne devient pas une source du simple fait qu'il s'exprime avec aisance, ni un décideur du simple fait qu'il a trouvé un texte proche de la question. L'énoncé de clôture proposé est le suivant : Une réponse digne de confiance ne se contente pas de paraître correcte ; elle révèle sa source, les limites de son applicabilité, ce qui manque, et qui détient l'autorité de la transformer en action.

9. L'intelligence artificielle explicable

Lorsque le système produit une sortie, une question naturelle surgit : Pourquoi a-t-il produit cette sortie ? Le modèle peut prédire une baisse de rendement, élever le niveau de suspicion d'une maladie, émettre une alerte de stress hydrique, ou classer un fruit dans une catégorie de qualité particulière. Mais la sortie à elle seule n'indique pas à l'utilisateur sur quelles informations le système s'est appuyé, ni si ces informations étaient complètes ou fiables. Les outils d'intelligence artificielle explicable cherchent à aider l'utilisateur à comprendre la relation entre les données fournies au modèle et la sortie qu'il a produite. Ils peuvent montrer, par exemple :

• qu'une faible humidité du sol figurait parmi les facteurs associés à une estimation plus élevée du risque de stress.
• que la température prévue a influé sur le besoin d'irrigation estimé.
• que le cultivar et le stade de développement figuraient parmi les facteurs associés à la prédiction de rendement.
• qu'une partie déterminée de l'image de la feuille était associée à son classement comme suspecte.
• que l'absence d'un relevé de capteur, ou sa modification, a influé sur la confiance du système.
• que la sortie était proche du seuil séparant deux classes.

Mais ces outils ne répondent pas à toutes les acceptions du mot « pourquoi ». Ils expliquent habituellement pourquoi le modèle a produit cette sortie selon ses calculs, mais n'établissent pas nécessairement pourquoi le phénomène s'est produit au champ. Trois questions différentes se cachent dans le mot « pourquoi » Lorsque l'utilisateur demande « pourquoi ? », il peut avoir en tête l'une de trois questions : 1\. Pourquoi le modèle a-t-il produit cette sortie ? C'est une question sur le comportement du modèle. La réponse pourrait être : Le modèle a relevé l'estimation du risque parce que le relevé d'humidité a baissé, que la température prévue a augmenté, et qu'aucun relevé récent n'est parvenu de l'un des capteurs. Cette réponse montre quelles informations le modèle a utilisées. 2\. Pourquoi le phénomène agricole s'est-il produit ? C'est une question sur la réalité agricole. Une réponse possible pourrait être : Peut-être l'humidité a-t-elle baissé parce que la demande en eau a augmenté, ou parce que l'irrigation n'atteignait pas ce secteur correctement, ou en raison d'un problème de sol, ou d'une erreur de capteur. Un outil d'interprétation du modèle ne peut, à lui seul, déterminer laquelle de ces causes est la bonne. Le fait que le modèle ait utilisé le relevé d'humidité ne prouve pas la cause de sa baisse, pas plus qu'il ne prouve que la plante subit réellement un stress. 3\. Pourquoi devrions-nous entreprendre cette action ? C'est une question sur la décision. Même si l'alerte du modèle est raisonnable, il n'en découle pas automatiquement que l'action correcte consiste à augmenter l'irrigation. Le capteur peut être défectueux, de la pluie peut être attendue, le problème peut tenir à une eau n'atteignant qu'une zone limitée, ou le stade de la culture peut différer de ce que le système a supposé. Il faut donc distinguer entre : expliquer la sortie du modèle ← expliquer la situation agricole ← justifier l'action Et passer d'un niveau au suivant requiert des données et des éléments de preuve supplémentaires. À qui l'explication s'adresse-t-elle ? Il n'existe pas d'explication unique qui convienne à tous les utilisateurs. Chaque partie a besoin d'un niveau différent. Le développeur veut savoir :

• Le modèle s'est-il appuyé sur des données valides ?
• A-t-il appris un raccourci incorrect ?
• S'est-il concentré sur l'arrière-plan de l'image au lieu de la plante ?
• Son comportement a-t-il changé après la mise à jour des données ?
• La sortie est-elle stable sous une légère modification de l'entrée ?

Le spécialiste agricole veut savoir :

• Les facteurs utilisés par le modèle ont-ils un sens agronomique ?
• A-t-il négligé une variable importante ?
• A-t-il confondu une relation statistique avec une cause agronomique ?
• Le résultat est-il plausible pour ce cultivar, cette saison et ce lieu ?
• Quelle mesure ou quelle analyse pourrait le confirmer ou l'infirmer ?

L'agriculteur ou l'opérateur a besoin d'une réponse pratique :

• Qu'a dit le système ?
• Sur quelles informations le résultat repose-t-il ?
• Ces informations sont-elles à jour et fiables ?
• Que ne sait pas le système ?
• Quelle est la prochaine étape sûre ?

Le réviseur ou l'autorité responsable a besoin d'un enregistrement auditable :

• Quelle est la version du modèle ?
• Quelles données étaient disponibles au moment de la décision ?
• Quelles règles ou quelles limites ont été appliquées ?
• Un humain a-t-il passé outre au résultat ? Pourquoi ?
• La source ou le capteur était-il valide à ce moment-là ?

La visualisation adaptée au chercheur ou au développeur peut ne pas être utile à l'ouvrier qui doit agir en quelques minutes. Par conséquent, l'explication doit être conçue pour la personne et pour la décision, et non seulement en fonction de ce que l'outil peut afficher. Deux types d'explication On peut distinguer deux niveaux principaux : Explication d'un cas unique Elle cherche à répondre à la question : Pourquoi le système a-t-il donné ce résultat maintenant, pour cette image ou cette parcelle ? Elle peut montrer que l'humidité du sol et la température étaient les deux facteurs les plus fortement associés à une alerte donnée, ou qu'une partie de l'image de la feuille était associée à son classement. Cette explication est utile pour examiner un cas précis, mais elle ne décrit pas nécessairement le comportement du modèle dans tous les cas. Explication du comportement général du modèle Elle cherche à répondre à des questions telles que :

• Sur quels types d'informations le modèle s'appuie-t-il habituellement ?
• La prédiction de rendement augmente-t-elle ou diminue-t-elle à mesure qu'une certaine variable change ?
• Son comportement diffère-t-il selon les cultivars ou les régions ?
• Quelles variables apparaissent fréquemment parmi les facteurs influents ?
• S'affaiblit-il lorsqu'un certain type de données est absent ?

Ce niveau aide à comprendre le modèle sur un grand ensemble de cas, mais il n'explique pas à lui seul une décision individuelle. Le modèle peut s'appuyer en général sur la météo et le sol, alors que le résultat pour une parcelle donnée a pu être influencé principalement par un relevé inhabituel provenant d'un seul capteur. Par conséquent, l'explication générale ne doit pas être utilisée à la place de l'explication du cas, ni l'inverse. Quelles formes l'explication peut-elle prendre ? Il existe de multiples manières de présenter une explication, et chacune a son sens et ses limites propres. 1\. Montrer les facteurs associés au résultat Le système peut afficher une liste telle que :

• Faible humidité du sol : a augmenté l'estimation du risque.
• Température prévue élevée : a augmenté l'estimation.
• Probabilité de pluie : a réduit l'estimation.
• Aucun relevé récent : a réduit la confiance.

Cette liste montre comment le modèle a traité l'information, mais elle ne prouve pas que ces facteurs ont causé la situation agronomique. 2\. Mettre en évidence une partie de l'image Un outil d'explicabilité peut colorer des parties de l'image de la feuille pour montrer les zones les plus fortement associées au résultat. Cela peut aider à révéler que le modèle s'est concentré sur :

• La tache pertinente.
• Le bord de la feuille.
• L'arrière-plan de l'image.
• Une étiquette placée à côté de la plante.
• Une ombre ou un reflet sans rapport avec l'état sanitaire.

Mais la zone colorée ne signifie pas que le modèle a « vu la maladie » comme l'aurait fait un spécialiste, pas plus qu'elle ne prouve que la partie mise en évidence a causé le classement. C'est le signe d'une relation calculatoire interne au modèle, qui appelle une interprétation prudente. 3\. Comparer le résultat à un cas similaire Le système peut dire : Ce cas ressemble à des exemples antérieurs classés dans la même catégorie. La comparaison aide l'utilisateur à voir sur quoi repose la similitude. Mais l'utilisateur devrait savoir :

• Les exemples antérieurs sont-ils documentés ?
• Provenaient-ils d'une culture, d'un cultivar et d'un environnement similaires ?
• La similitude porte-t-elle sur les symptômes, ou sur l'arrière-plan et l'éclairage ?
• Existe-t-il des exemples similaires qui ont conduit à un résultat différent ?

4\. Indiquer ce qui aurait changé le résultat L'outil peut dire : Si le relevé d'humidité avait été plus élevé dans le calcul du modèle, l'estimation du risque aurait été plus basse. Cela montre la sensibilité du modèle à une modification de l'entrée, mais cela ne prouve pas qu'augmenter réellement l'humidité préviendrait le risque au champ. Cela décrit un changement dans le calcul du modèle, et non l'effet d'une intervention agricole réelle. Ici encore apparaît la différence entre : Qu'est-ce qui change le résultat du modèle ? et : Qu'est-ce qui change la réalité agricole ? L'interprétation peut être une approximation, non une divulgation complète Certains modèles sont relativement simples, et leur méthode de calcul peut être retracée directement. Avec certains modèles complexes, en revanche, un autre outil est employé après la production du résultat pour tenter d'en approcher les raisons. Dans le second cas, l'interprétation n'est pas une fenêtre complète sur tout ce qui s'est passé à l'intérieur du modèle. Elle peut être une simplification ou une approximation de son comportement. Par conséquent, l'interprétation elle-même doit être testée :

• Change-t-elle fortement si les données ne changent que légèrement ?
• Donne-t-elle des interprétations similaires pour des résultats contradictoires ?
• Reflète-t-elle véritablement ce que le modèle a utilisé ?
• Peut-elle distinguer un facteur important d'un facteur qui lui est simplement associé ?
• L'interprétation est-elle restée stable après la mise à jour du modèle ?

Ainsi, si la liste des « facteurs les plus importants » change radicalement après une légère modification qui n'altère pas le résultat, l'interprétation peut être instable, même si le graphique paraît convaincant. Facteurs associés les uns aux autres Les données peuvent contenir des variables qui évoluent de concert, telles que :

• La température et l'évaporation.
• La saison et la durée du jour.
• Le type de sol et le drainage.
• La taille de l'exploitation et le type d'équipement.
• L'expérience et la qualité de la tenue des registres.

Lorsque les variables sont fortement corrélées, l'outil d'explicabilité peut répartir l'importance entre elles de différentes manières. L'une peut apparaître en tête alors que l'autre porte une information similaire. Par conséquent, le classement des facteurs ne doit pas être lu comme un classement fixe des causes agronomiques. Un spécialiste peut avoir besoin d'examiner les relations entre elles, et de déterminer si le modèle utilise l'une comme substitut de l'autre. Les limites fondamentales de l'explicabilité L'explicabilité a des limites qui doivent rester visibles :

• Elle décrit ce que le modèle a utilisé, et n'établit pas nécessairement ce qui a causé le phénomène au champ.
• Elle peut être une approximation du comportement du modèle, non une description complète de sa manière de calculer.
• Elle ne transforme pas un modèle erroné en modèle correct.
• Elle ne compense pas des données insuffisantes ou des mesures corrompues.
• Elle ne prouve pas que les données d'entraînement représentent la nouvelle exploitation.
• Elle ne prouve pas que les probabilités sont calibrées ni que le résultat est exact.
• Elle ne justifie pas automatiquement l'action proposée.
• Elle peut sembler convaincante même lorsque le cas se situe hors du domaine de ce que le modèle a appris.
• Elle peut changer lorsqu'un outil d'explicabilité différent est utilisé.
• Elle peut dissimuler une instabilité derrière un graphique clair et séduisant.

L'explicabilité est donc un instrument d'examen et de responsabilisation, non un certificat de validation. L'explicabilité ne corrige pas les erreurs de données Supposons qu'un capteur d'humidité du sol n'ait pas transmis de relevé récent, de sorte que le système a utilisé le dernier relevé enregistré six heures plus tôt. Un outil d'explicabilité peut montrer que l'humidité a été un facteur important du résultat, mais il ne rend pas l'ancien relevé actuel. De même, si les images d'entraînement ne représentent pas un cultivar ou une région donnés, le système peut expliquer le résultat obtenu pour la nouvelle image, mais cette explication ne prouve pas que le modèle est valide pour cet environnement. L'explicabilité devrait présenter la qualité des données en même temps que leur effet, par exemple :

• L'heure du relevé le plus récent.
• La présence de valeurs manquantes.
• L'état d'étalonnage du capteur.
• La source des données.
• Le degré de ressemblance du cas avec les données d'entraînement.
• Le fait que le résultat se situe ou non dans le domaine sur lequel le modèle a été testé.

Un facteur influent n'est pas utile si sa valeur elle-même n'est pas fiable. L'explicabilité ne prouve pas la causalité Si le système montre que l'humidité a été un facteur influent dans la prédiction du rendement, cela signifie que le modèle a utilisé l'information d'humidité lors du calcul du résultat. Mais cela ne prouve pas que modifier la seule humidité changera le rendement dans la même proportion. L'humidité peut être associée à d'autres facteurs, tels que :

• Le type de sol.
• Le système d'irrigation.
• La météo.
• Le stade de développement.
• La conduite de la parcelle.
• Le cultivar.

Pour déterminer l'effet d'une intervention particulière, il nous faut une expérimentation ou un dispositif causal, accompagnés des connaissances agronomiques appropriées, comme la section précédente l'a expliqué. Une règle essentielle : l'explicabilité du modèle nous dit comment son calcul a changé, et non comment la parcelle changera nécessairement si nous modifions l'une des entrées. Limites de l'inférence tirée de l'étude sur la prédiction du rendement L'étude sur la prédiction du rendement [SRC006] offre un exemple d'utilisation de modèles de régression avec des outils qui aident à interpréter leurs résultats dans un cadre de recherche déterminé. L'étude peut servir à comprendre :

• Le type de données fournies aux modèles.
• La méthode de prédiction employée dans l'étude.
• La manière dont les outils d'explicabilité ont été appliqués dans ce cadre.
• Les résultats rapportés par les chercheurs dans les limites de leurs données et de la conception de leur étude.

Mais le classement des variables ou leur importance dans l'étude ne doit pas être transformé en règle causale générale valable pour toute exploitation. Si une variable donnée apparaît influente dans la prédiction du modèle, cela ne prouve pas :

• qu'elle est la cause principale du rendement dans tous les environnements.
• que modifier cette variable produira le même effet dans une autre parcelle.
• que le classement des facteurs restera stable pour une autre variété ou une autre saison.
• que le modèle convient pour formuler une recommandation d'intervention directe.
• que le résultat computationnel implique un impact économique ou agronomique général.

La conclusion admissible demeure dans les limites de l'étude et du cadre d'évaluation qu'elle a utilisé. De quoi l'agriculteur a-t-il besoin en matière d'explication ? Une explication utile à l'agriculteur ne commence pas par un schéma technique ni par une longue liste de variables. Elle répond plutôt à six questions :

1. Quel est le résultat ?

Qu'a dit exactement le système ?

2. Sur quelles informations s'est-il appuyé ?

Quels relevés, images ou enregistrements ont influencé le résultat ?

3. Quel est l'état de ces informations ?

Sont-elles récentes, complètes et étalonnées, ou existe-t-il un relevé ancien ou manquant ?

4. Quel est le degré d'incertitude ?

Le résultat est-il net, proche du seuil, ou hors du domaine d'expérience du modèle ?

5. Qu'est-ce que l'explication n'établit pas ?

Le résultat est-il une alerte préliminaire, un diagnostic, ou simplement une prédiction ?

6. Quelle est l'étape suivante sûre ?

Quelle mesure, quelle inspection ou quelle revue est requise avant de modifier la décision ?

Ainsi, l'explication devient un outil de travail, et non un affichage technique détaché de la décision. Reformulation de l'exemple Au lieu de dire : « Le risque de stress hydrique a augmenté parce que l'humidité de la couche de surface a baissé sur trois jours et que la température prévue s'est élevée... » — une formulation susceptible d'être comprise comme une preuve causale —, nous pouvons dire : « Le système a relevé son estimation de la probabilité de stress hydrique parce que le relevé d'humidité de la couche de surface a baissé au cours des trois derniers jours, et parce que les prévisions de température ont augmenté. Mais le capteur du secteur 4 n'a pas envoyé de nouveau relevé depuis six heures, de sorte que l'estimation peut reposer sur des données incomplètes. Avant d'ajuster le calendrier d'irrigation, inspectez le capteur, prenez une mesure indépendante dans le secteur, et comparez le résultat avec un secteur voisin placé dans des conditions similaires. » Cette formulation rend clair :

• qu'il s'agit de l'estimation du modèle, et non d'une cause confirmée.
• quelles données ont influencé l'estimation.
• qu'une des entrées de données est incomplète.
• en quoi ce manque affecte la confiance.
• quelle est l'étape suivante.
• que l'ajustement de l'irrigation n'a pas été transformé en ordre automatique.

Un exemple à partir de l'image d'une feuille Le système peut dire : « Le modèle a classé l'image comme cas suspect, et le résultat a été associé principalement aux taches situées près du bord de la feuille. Mais l'image ne montre pas la face inférieure, et le modèle n'a pas distingué avec confiance entre une maladie possible et une carence nutritionnelle. Envoyez une image plus nette des deux faces, et indiquez où les symptômes apparaissent sur la plante et comment ils se répartissent dans la parcelle avant de passer à un diagnostic ou à un traitement. » Cette explication vaut mieux qu'une carte colorée seule, car elle montre :

• Où le modèle a concentré son attention.
• Quelles possibilités se recoupent.
• Quelles informations manquent.
• Quelle est l'étape suivante.
• Que la classification n'est pas un diagnostic définitif.

Un exemple tiré de la prédiction du rendement Le système peut dire : « Le rendement prédit s'est situé au-dessous de la moyenne historique de cette parcelle. Au sein du modèle, les facteurs les plus fortement associés à cette prédiction plus basse sont un semis tardif, une faible humidité du sol pendant une période déterminée, et des températures prévues plus élevées. Mais l'enregistrement ne contient pas d'informations complètes sur le traitement le plus récent, et le modèle n'a pas été testé dans cette parcelle lors d'une saison extrêmement chaude. Le résultat doit donc être traité comme un scénario de planification, et non comme une valeur garantie. » Cette formulation empêche que l'explication ne soit transformée en :

• Une cause confirmée.
• Une promesse de rendement.
• Une recommandation d'intervention.
• Une généralisation au-delà du périmètre des tests.

Quand l'explication est-elle insuffisante ? On ne doit pas se fier à la seule explication lorsque :

• Des données critiques sont manquantes ou périmées.
• Le cas se situe hors des cultures ou des variétés sur lesquelles le modèle a été testé.
• Le résultat est proche du seuil de décision.
• Plusieurs capteurs se contredisent.
• L'erreur potentielle touche à la sécurité humaine ou animale.
• La décision conduit à une dose ou à une substance réglementée.
• Le système commande une machine en mouvement.
• L'utilisateur ne peut pas examiner l'explication ni sa source.
• L'explication change radicalement à la suite d'une légère modification des données.
• Il existe un écart entre ce que le modèle explique et ce que la décision doit établir.

Dans ces cas, l'explication doit conduire à une inspection ou à une escalade, et non simplement à une confiance accrue. Questions pratiques pour évaluer l'explication Le lecteur ou l'acheteur peut demander :

• Le système explique-t-il l'issue d'un cas particulier, ou son comportement général ?
• Précise-t-il sur quelles données il s'est appuyé, et de quand elles datent ?
• Signale-t-il les données manquantes ou peu fiables ?
• L'explication est-elle une description directe du modèle, ou une approximation produite par un autre outil ?
• L'explication change-t-elle à la suite d'une légère modification de l'entrée ?
• Le développeur a-t-il examiné la possibilité que le modèle s'appuie sur l'arrière-plan ou sur l'appareil ?
• Le système distingue-t-il corrélation et causalité ?
• Précise-t-il l'éventail des cultures, des lieux et des saisons dans lesquels il a été testé ?
• L'utilisateur peut-il comprendre l'explication sans compétences en programmation ?
• L'explication conduit-elle à une étape sûre et exploitable ?
• Un humain peut-il contester le résultat ou le passer outre ?
• Les données et la version qui ont produit l'explication ont-elles été conservées pour une revue ultérieure ?

Pour le lecteur averti : l'explication doit être évaluée selon la fidélité avec laquelle elle représente le comportement du modèle, sa stabilité face à de petites variations, son intelligibilité, et son adéquation à l'utilisateur et à la décision. Un modèle plus simple et plus clair peut valoir mieux, pour une décision sensible, qu'un modèle légèrement supérieur sur un indicateur de laboratoire mais exigeant une explication approximative instable. Conclusion L'intelligence artificielle explicable ne rend pas le modèle conscient de ses raisons, ne transforme pas une relation statistique en cause agronomique, et ne confère pas automatiquement une légitimité à la décision. Son meilleur rôle est de nous aider à demander :

• Quelles informations le modèle a-t-il utilisées ?
• Ces informations étaient-elles exactes et à jour ?
• S'est-il concentré sur ce sur quoi il devait se concentrer ?
• Qu'a-t-il laissé de côté ?
• Quelles sont les limites de sa confiance ?
• Et que faut-il vérifier avant de passer à l'action ?

Le message de la section peut se résumer dans la formule suivante : Une bonne explication ne se contente pas de nous dire pourquoi le chiffre est sorti tel qu'il est ; elle révèle les données qui l'ont produit, les limites qui le contraignent, et l'étape qui empêche de le transformer en décision aveugle.

10. Le système agricole intelligent est un système intégré, non un modèle isolé

Lorsque nous disons qu'une exploitation utilise un « modèle d'irrigation intelligent » ou un « système intelligent de détection des maladies », le lecteur peut imaginer un unique programme qui reçoit les données puis émet la décision. Mais les systèmes agricoles utiles ne fonctionnent généralement pas de cette manière simplifiée. Ils ressemblent davantage à une chaîne interconnectée : elle commence par mesurer ce qui se passe au champ, passe par la vérification et l'analyse des données ainsi que par leur confrontation aux contraintes agronomiques, et s'achève en présentant une recommandation à un être humain ou en exécutant une action automatisée dans des limites déterminées. Pour cette raison, on le décrit comme un système hybride : il ne repose pas sur un seul type d'intelligence artificielle, et ne laisse pas la décision à un modèle isolé. Il combine plutôt des capteurs, des modèles entraînés sur des données, des règles établies par des experts, des outils de sélection entre alternatives, des équipements, et l'être humain responsable de la décision. Ce système intégré peut se composer des couches suivantes :

1. Collecte de l'information :

La chaîne commence par un capteur mesurant l'humidité ou la température du sol, ou par une image prise par un téléphone ou un drone, ou encore par un enregistrement dans lequel l'ouvrier note ce qui s'est passé au champ. Cette couche ne fournit pas de décision ; elle transmet plutôt une description partielle de la réalité, qui peut être exacte ou incomplète, ou affectée par une panne d'appareil ou par la méthode de mesure.

2. Vérification de la qualité des données :

Avant que le système n'utilise un relevé, il vérifie s'il est plausible. Si un capteur d'humidité signale un saut brusque qui ne correspond ni à la pluie ni à l'irrigation, ou si un appareil cesse de transmettre, ou si certains relevés arrivent dans une unité différente, ces valeurs ne doivent pas être transmises au reste du système comme s'il s'agissait de faits fiables. Le système peut les exclure, abaisser la confiance qu'il leur accorde, ou demander que l'appareil soit inspecté.

3. Formation d'une estimation ou d'une prévision :

Un modèle analytique utilise les données disponibles pour estimer une condition qui ne peut être mesurée directement, ou pour prévoir ce qui pourra survenir plus tard. Il peut estimer la probabilité qu'une plante soit malade à partir d'une image, prévoir les changements d'humidité du sol au cours des heures à venir, ou estimer le volume de la demande en eau du lendemain. Ce résultat demeure une estimation, gouvernée par la qualité des données et par les limites de ce que le modèle a appris.

4. Application des règles agronomiques et réglementaires :

Tout résultat prédit n'est pas transformé en recommandation automatique. Il peut exister une règle qui empêche l'irrigation lorsque la vitesse du vent dépasse un certain seuil, ou qui interdit de suggérer une substance non homologuée pour la culture ou la région, ou qui exige que le cas soit renvoyé à un spécialiste lorsque le diagnostic n'est pas concluant. Ces règles ne sont pas nécessairement apprises à partir des données ; elles sont mises en place pour protéger la culture, l'ouvrier et l'environnement, et pour se conformer aux instructions officielles.

5. Pesée des alternatives disponibles :

Si plusieurs plans possibles sont disponibles, le système utilise un outil computationnel pour les comparer et choisir le plan le plus adapté dans le cadre des contraintes. Il peut, par exemple, chercher à répartir une quantité limitée d'eau entre plusieurs secteurs en tenant compte des besoins des cultures, de la capacité des pompes, des heures de fonctionnement et du coût de l'énergie. Ici, « le plus adapté » ne signifie pas qu'il existe une solution idéale absolue ; cela signifie la meilleure solution compte tenu de l'objectif et des contraintes introduits dans le système.

6. Présentation du résultat, de son fondement et de ses limites :

L'interface doit indiquer clairement à l'utilisateur ce que le système propose, sur quelles données il s'est appuyé, quel est son degré de confiance, et quelles contraintes ou quels relevés manquants peuvent affecter le résultat. Un tableau qui dit « Lancer l'irrigation pendant deux heures » est moins utile et moins sûr qu'un affichage qui précise le secteur concerné, le motif de la recommandation, l'heure de la mesure, l'état des capteurs, et si le plan requiert une approbation.

7. Revue ou exécution :

Dans certains systèmes, l'agriculteur ou le responsable examine la recommandation avant son exécution. Dans d'autres systèmes, des commandes peuvent être envoyées automatiquement aux pompes ou aux vannes, mais dans des limites d'exploitation et de sécurité fixées à l'avance. Les êtres humains doivent conserver le pouvoir d'arrêter le système ou de passer outre sa décision lorsqu'ils constatent quelque chose que les données ne saisissent pas.

Considérons l'exemple de l'irrigation. Le processus peut commencer par des relevés d'humidité du sol, des données météorologiques et le stade de développement de la culture. Le système vérifie d'abord les relevés pour s'assurer que les capteurs fonctionnent et que les unités de mesure sont correctes. Il utilise ensuite un modèle qui suit les variations d'humidité dans le temps pour prévoir le besoin en eau de chaque secteur au cours du lendemain. Mais cette prévision à elle seule ne détermine pas le plan d'irrigation. Des règles agronomiques peuvent ajouter des contraintes empêchant d'apporter davantage d'eau dans un sol mal drainé, ou donner la priorité à une culture traversant un stade de développement sensible. Ensuite, un programme de planification compare les alternatives possibles et répartit la capacité des pompes et le temps de fonctionnement entre les différents secteurs. Avant l'exécution, la couche de sécurité vérifie qu'il n'existe aucun conflit entre les capteurs, et que la pression du réseau et l'état des vannes permettent le plan. Elle présente alors le résultat à l'opérateur pour approbation, ou l'exécute automatiquement s'il se situe dans les limites autorisées. Dans cet exemple, « l'intelligence artificielle » n'a pas pris seule la décision. Le modèle a fourni une prévision, les règles ont imposé des contraintes, l'outil de planification a choisi parmi les alternatives, la couche de sécurité a examiné si l'exécution était réalisable, et l'opérateur est resté responsable de la décision finale. Décrire l'ensemble du système comme un « modèle d'irrigation par IA » dissimule donc des parties essentielles de son fonctionnement et rend difficile de déterminer où l'erreur s'est produite et qui en est responsable. Un modèle peut être exact tandis que le système échoue à une autre étape. En voici des exemples :

• Un capteur envoie un relevé dans une unité différente de celle qu'attend le système.
• La prévision repose sur des données anciennes, arrivées après la fermeture de la fenêtre de décision.
• Un résultat concernant le secteur oriental est relié à la vanne du secteur ouest.
• L'outil de planification choisit un plan correct sur le plan computationnel mais qui dépasse la capacité réelle de la pompe.
• L'interface affiche un chiffre sans indiquer l'heure de la mesure ni le degré de confiance qui lui est accordé.
• Le système envoie une commande correcte, mais la vanne ne l'exécute pas et ne renvoie aucun signal confirmant son état.
• La décision est exécutée automatiquement sans offrir à l'opérateur un moyen clair de l'interrompre.

Une revue de la numérisation agricole décrit un cheminement interconnecté qui commence par la détection, passe par les données, le contexte et la prise de décision, et s'achève par l'action dans le monde réel [SRC035]. L'importance de cette conception tient au fait que la qualité de chaque étape dépend de ce qui lui parvient de l'étape précédente, et qu'une petite erreur peut s'amplifier à mesure qu'elle progresse dans la chaîne. Si le relevé d'humidité est erroné, il peut produire une prévision erronée. Si la prévision est correcte mais envoyée trop tard, le plan peut devenir inadapté au moment de son exécution. Si le plan est correct mais dirigé vers la mauvaise vanne, un secteur qui n'avait pas besoin d'eau peut être endommagé tandis que le secteur qui en avait besoin reste non irrigué. C'est pourquoi vérifier les liaisons entre les composants du système peut être plus important que d'obtenir une légère augmentation de l'exactitude de l'algorithme lui-même. Pour le lecteur qui souhaite approfondir : il ne suffit pas d'évaluer le modèle isolément du système dans lequel il opère. L'erreur doit être suivie depuis la première mesure jusqu'à l'impact final au champ : quelle est l'ampleur de l'erreur du capteur ? Comment les valeurs manquantes ont-elles été traitées ? La prévision est-elle arrivée à temps ? Comment a-t-elle été convertie en règle de décision ? L'outil de planification a-t-il tenu compte des contraintes réelles ? La commande a-t-elle été exécutée sur l'équipement visé ? Et quel impact agronomique en a résulté ? Un modèle donné peut sembler meilleur lors des tests computationnels, tandis qu'un système utilisant un modèle plus simple peut se révéler plus fiable grâce à la qualité de ses données, à la clarté de ses règles et à la solidité de ses couches de sécurité. Toute couche du système ne doit pas devenir « intelligente » du seul fait que c'est techniquement possible. À certains endroits, une règle fixe est plus claire, plus facile à tester et plus sûre qu'un modèle appris. Empêcher une machine de fonctionner lorsqu'un carter de protection est ouvert n'exige pas un modèle qui prédit si le fonctionnement est dangereux ; cela exige une règle explicite qu'il est interdit de contourner. À l'inverse, l'apprentissage peut être utile pour analyser une image complexe ou anticiper un changement difficile à décrire par un simple ensemble de règles. Une ingénierie mûre ne commence pas par la question : « Où pouvons-nous ajouter de l'intelligence artificielle ? » Elle commence plutôt par des questions plus précises :

• Quelle partie du problème a besoin d'apprendre à partir des données ?
• Quelle partie exige une règle agronomique ou réglementaire explicite ?
• Quelles décisions peuvent être exécutées automatiquement, et lesquelles requièrent une approbation humaine ?
• Où les liaisons entre composants pourraient-elles défaillir ?
• Comment l'utilisateur sait-il que les données sont incomplètes ou que l'exécution n'a pas eu lieu comme prévu ?
• Qui a le pouvoir d'arrêter le système et de passer outre lorsque survient une situation imprévue ?

La règle directrice : la qualité d'un système agricole ne se mesure pas au modèle le plus intelligent qu'il contient, mais à la sécurité de la chaîne entière, du premier relevé au champ jusqu'à l'action finale qui y est exécutée.

11. Un guide préliminaire pour relier la tâche, la méthode et la vérification

La méthode appropriée ne commence pas par le nom de l'algorithme, mais par la question à laquelle nous voulons répondre et par l'action qui pourra se fonder sur cette réponse. Une même image peut servir d'entrée pour classer l'état d'une feuille, localiser une adventice ou mesurer l'étendue des dégâts, mais chacune de ces tâches exige des données de référence différentes, produit une sortie différente, et s'apprécie selon des indicateurs différents. Le guide suivant n'est pas une recette automatique pour choisir un algorithme, et il ne signifie pas que tout problème agricole relève d'une catégorie unique. C'est une carte préliminaire qui aide le lecteur à relier six éléments :

1. Tâche : À quelle question agricole voulons-nous répondre ?
2. Données : Quelles informations sont nécessaires pour y répondre ?
3. Famille de méthodes : Quel type d'analyse peut traiter la question ?
4. Sortie : Quel résultat le système doit-il fournir ?
5. Indicateur de performance : Comment savons-nous que le résultat est utile, et non seulement de belle apparence ?
6. Question de sécurité et de vérification : Que faut-il vérifier avant que le résultat ne soit converti en décision ou en action ?

La réponse à ces questions n'est complète qu'une fois précisés la culture, l'environnement, le moment de la décision, le coût de l'erreur et la capacité de l'utilisateur à réagir. 1\. Classer l'état d'une feuille à partir d'une image Tâche : Déterminer quelle classe correspond le mieux à l'image de la feuille, par exemple saine, affectée par une condition particulière, ou indéterminée. Données requises : Des images variées de tissus sains et d'états pathologiques, chacune reliée à une classe de référence vérifiée par un expert ou à un test fiable. Il ne suffit pas que les images soient simplement nombreuses ; elles doivent aussi représenter la variabilité des cultivars, des stades de développement, de l'éclairage, des appareils de prise de vue et de la sévérité des symptômes. Famille de méthodes : Modèles de classification d'images. Sortie attendue : Le nom de la condition la plus probable et un score de confiance, avec la possibilité pour le système de dire « indéterminé » ou de demander une image supplémentaire lorsque les éléments de preuve sont insuffisants. Que mesurons-nous ? Un taux de réussite global ne suffit pas. Nous devrions mesurer la capacité du système à détecter chaque condition importante, le nombre de cas qu'il manque, le nombre de fausses alertes, et les cas qu'il confond entre eux. Question de sécurité et de vérification : Que fait le système s'il rencontre une maladie qu'il n'a pas apprise, des symptômes découlant de plus d'une cause, ou une image de mauvaise qualité ? Renvoie-t-il les cas ambigus à un spécialiste, ou les force-t-il dans l'une des classes connues ? 2\. Localiser une adventice en vue de son traitement Tâche : Détecter l'adventice dans l'image et déterminer sa position avec une précision suffisante pour y diriger un ouvrier ou une machine. Données requises : Des images ou des séquences vidéo montrant les emplacements des adventices et de la culture, avec des annotations de référence de leurs positions. Si le système doit guider une machine, il a aussi besoin d'informations d'étalonnage reliant la position de l'objet dans l'image à sa position réelle devant l'outil. Famille de méthodes : Le travail commence par la détection d'objets ou par la délimitation des contours d'objets dans l'image ; le résultat passe ensuite à un système de commande qui détermine le mouvement de l'outil. Sortie attendue : La position de l'adventice, ses contours et le score de confiance de sa détection, puis des coordonnées que la machine peut exploiter à temps. Que mesurons-nous ? Nous mesurons quelles adventices ont été détectées et lesquelles ont été manquées, l'exactitude de leur localisation, la rapidité avec laquelle le résultat parvient, et le nombre de plants de culture endommagés lors de l'exécution. Question de sécurité et de vérification : L'outil s'arrête-t-il si le système perd confiance, si une personne ou un animal entre dans la zone de travail, ou s'il devient impossible de distinguer l'adventice de la culture ? Et la chaîne entière a-t-elle été testée, de la caméra au mouvement de l'outil, plutôt que le seul modèle d'image ? 3\. Prédiction du rendement Tâche : Estimer la quantité de récolte attendue sur une surface déterminée. Données requises : Des mesures de rendement antérieures, ainsi que des données sur la météo, le sol, le cultivar, le stade de développement et les pratiques agricoles, avec mention claire de la source de chaque valeur et de son unité de mesure. Famille de méthodes : Modèles de régression, ou modèles qui étudient l'évolution des données dans le temps ; des modèles spatiaux peuvent être ajoutés si les conditions diffèrent au sein de la parcelle ou entre les régions. Sortie attendue : Une estimation du rendement dans une unité intelligible, telle que des kilogrammes par hectare, accompagnée d'un intervalle montrant le degré d'incertitude plutôt qu'un chiffre unique suggérant une précision illusoire. Que mesurons-nous ? L'erreur se mesure dans la même unité que le rendement, tout en vérifiant si les intervalles de confiance annoncés concordent avec les résultats réels. Si le système affirme que le rendement a des chances de se situer dans un certain intervalle, nous devrions tester à quelle fréquence cela se produit effectivement. Question de sécurité et de vérification : Le modèle a-t-il été testé sur des exploitations, des saisons ou des régions qui ne faisaient pas partie de son entraînement ? Et l'utilisateur comprend-il que la prédiction se fonde sur des conditions passées qui peuvent ne pas représenter une saison exceptionnelle ou un nouveau cultivar ? 4\. Établir un calendrier d'irrigation Tâche : Déterminer quand les secteurs doivent être irrigués et quelle quantité d'eau chaque secteur doit recevoir, en tenant compte des besoins de la culture et de la capacité du réseau d'irrigation. Données requises : Humidité du sol, météo, stade de développement de la culture, propriétés du sol, sources d'eau, capacité des pompes, état des vannes, et contraintes de temps et d'exploitation. Famille de méthodes : Le système peut combiner un modèle prédisant les besoins en eau, des règles agronomiques empêchant les décisions dangereuses, et un programme de planification comparant les alternatives et répartissant les ressources disponibles. Sortie attendue : Un calendrier exécutable précisant le secteur, l'horaire, la quantité et la durée de fonctionnement, ainsi qu'un plan de repli en cas de pénurie d'eau ou de panne d'un équipement. Que mesurons-nous ? Le succès ne se mesure pas à la seule réduction de la consommation d'eau, mais aussi à l'état des plantes, au rendement, à la consommation d'énergie, à l'uniformité de la distribution, au moment de l'apport d'eau, et à la possibilité d'exécuter le plan avec les équipements disponibles. Question de sécurité et de vérification : Que se passe-t-il lorsque les données sont interrompues ou que l'un des capteurs tombe en panne ? Le système bascule-t-il en mode manuel ou vers un plan de secours sûr, ou continue-t-il d'émettre des commandes sur la base d'informations incomplètes ? 5\. Émettre une alerte sur l'état d'un animal Tâche : Détecter un changement pouvant indiquer une maladie, une blessure, ou une perturbation du déplacement ou de l'alimentation. Données requises : Les données peuvent être des sons, des images, des séquences vidéo, ou des relevés d'activité, de température et d'ingestion d'aliments. Elles devraient être reliées, autant que possible, à des cas examinés par un vétérinaire ou un autre spécialiste. Famille de méthodes : Détection de cas inhabituels lorsque nous ne disposons pas d'une définition complète de chaque maladie, ou classification lorsque nous disposons de cas documentés à partir desquels le système peut apprendre. Sortie attendue : Une alerte identifiant l'animal, l'heure et le motif de préoccupation, les alertes étant classées par ordre de priorité. Que mesurons-nous ? Le nombre de cas importants que le système n'a pas su détecter, le nombre de fausses alertes par animal ou par jour, et le délai entre le début du changement et l'émission de l'alerte. Question de sécurité et de vérification : Qui confirme l'état de manière professionnelle avant le traitement ? Et combien d'alertes l'équipe peut-elle réellement examiner ? Un système qui envoie des centaines d'alertes non hiérarchisées peut dissimuler le cas dangereux dans le bruit. 6\. Estimer l'étendue des symptômes et suivre leur propagation Tâche : Mesurer la surface affectée dans la plante ou la parcelle, puis déterminer si les symptômes s'étendent ou régressent au fil du temps. Données requises : Des images ou des cartes successives prises à des moments différents, accompagnées d'informations sur le lieu, la hauteur, l'angle et les conditions d'éclairage de la prise de vue, afin qu'une comparaison équitable soit possible. Famille de méthodes : Délimiter les contours des tissus ou des zones affectés dans l'image, puis analyser leur évolution entre différents instants. Sortie attendue : Une surface estimée ou un pourcentage de dégâts, la direction et la vitesse du changement, ainsi qu'une indication du degré de confiance dans la comparaison. Que mesurons-nous ? L'erreur d'estimation de la surface, la stabilité du résultat lorsque la prise de vue est répétée, et la capacité du système à suivre la même zone d'un moment à l'autre. Question de sécurité et de vérification : Les dégâts ont-ils réellement augmenté, ou bien la lumière, l'angle de prise de vue ou la hauteur de la caméra ont-ils changé, faisant paraître la surface plus grande ou plus petite ? Et les images sont-elles comparées sur la base d'un référentiel unique ? 7\. Fournir une réponse de conseil Tâche : Répondre à une question agricole dans une langue claire, en s'appuyant sur des sources faisant autorité et adaptées au contexte de l'utilisateur. Données requises : La question de l'utilisateur, des informations sur la culture, le lieu, le stade de développement et l'état, ainsi que des sources fiables et à jour que le système peut consulter. Famille de méthodes : Rechercher des sources faisant autorité et récupérer les passages pertinents, puis utiliser un modèle de langage pour formuler la réponse, avec des règles empêchant les affirmations ou recommandations non étayées par les éléments de preuve. Sortie attendue : Une réponse qui distingue l'information générale d'une recommandation qualifiée, cite ses sources, et demande des informations supplémentaires ou refuse de répondre lorsque les éléments de preuve sont insuffisants. Que mesurons-nous ? Les sources étayent-elles les affirmations formulées dans la réponse ? Les références sont-elles exactes et vérifiables ? La réponse est-elle adaptée à la culture, au lieu et au moment, et l'utilisateur peut-il comprendre l'étape suivante sans être poussé vers une action dangereuse ? Question de sécurité et de vérification : Le système s'abstient-il d'inventer une dose, une substance, une homologation officielle ou un prix non documentés ? Indique-t-il clairement que l'autorisation d'un produit ou ses conditions d'usage doivent être vérifiées au regard de l'étiquette homologuée en vigueur et de la réglementation locale ? 8\. Répartir une ressource limitée Tâche : Distribuer une quantité limitée d'eau, d'engrais, de main-d'œuvre ou de temps machine entre plusieurs parcelles ou secteurs. Données requises : L'ampleur de la demande, les ressources disponibles, les priorités, les contraintes techniques et temporelles, et les prévisions relatives au rendement, au coût ou au revenu. Famille de méthodes : Planification mathématique et arbitrages entre alternatives, connus dans les domaines spécialisés sous les noms d'optimisation et de recherche opérationnelle. Ces méthodes recherchent un plan atteignant l'objectif autant que possible sans enfreindre les contraintes spécifiées. Sortie attendue : Un plan exécutable, accompagné d'un énoncé de ce que reçoit chaque partie et de ce qui change si les priorités évoluent ou si la ressource se raréfie. Que mesurons-nous ? Le plan a-t-il respecté toutes les contraintes ? Peut-il réellement être mis en œuvre ? Et quel est son effet sur le coût, le rendement, le temps et l'équité entre secteurs ou bénéficiaires ? Question de sécurité et de vérification : Qui a déterminé l'objectif que l'outil cherche à maximiser ? Et qui a fixé les priorités ainsi que le niveau minimal acceptable pour chaque secteur ? Un plan peut être mathématiquement correct et pourtant inéquitable ou agronomiquement inacceptable si l'objectif se réduit à un seul chiffre. 9\. Commander une séquence d'actions Tâche : Choisir une séquence d'actions après lesquelles l'état du système change, comme régler la ventilation et le chauffage dans une structure protégée, ou guider une machine en mouvement entre les rangs de culture. Données requises : Une description de l'état actuel, l'ensemble des actions possibles, et des données sur ce qui s'est passé après chaque action, ainsi que les limites d'exploitation et de sécurité. Famille de méthodes : Le système peut utiliser une commande conventionnelle fondée sur des règles et des équations connues, un apprentissage par renforcement qui apprend une stratégie de sélection d'action à partir de la simulation ou de l'expérience, ou un mélange des deux. Sortie attendue : Une stratégie qui détermine l'action appropriée pour chaque état, suivie de commandes d'exploitation claires pour les équipements. Dans la terminologie technique, cette stratégie est désignée comme une « politique de sélection d'action ». Que mesurons-nous ? La stabilité du système, la rapidité de sa réponse, le nombre de dépassements de contraintes, la consommation de ressources, les effets des actions sur la plante, l'animal ou l'équipement, et sa capacité à faire face à des conditions imprévues. Question de sécurité et de vérification : Quelles limites le système n'est-il pas autorisé à franchir, quel que soit l'objectif ? Qui a le pouvoir de l'arrêter ? Et vers quel état sûr l'équipement se place-t-il si la communication est perdue, si les données font défaut, ou si la situation sort du domaine testé ? Cette carte montre qu'une même tâche agricole peut exiger plus d'une méthode, et que la réussite à chaque étape ne garantit pas la réussite de la chaîne dans son ensemble. Identifier la position de l'adventice ne suffit pas si la machine ne peut l'atteindre en sécurité ; prédire la demande en eau ne suffit pas si le plan d'irrigation dépasse la capacité de la pompe ; et récupérer une source correcte ne suffit pas si elle concerne une autre culture, un autre pays ou une autre date. Elle montre également que l'indicateur technique et la question de sécurité ne sont pas des affaires distinctes. L'indicateur signale la qualité des performances du système lors des tests, tandis que la question de sécurité signale ce qui peut advenir lorsque le système se trompe au champ. Un algorithme peut atteindre un résultat moyen élevé, alors que son erreur rare se produit dans le cas le plus risqué. Pour le lecteur en quête d'approfondissement : le choix de la méthode commence par la formulation de la décision et du coût des différentes formes d'erreur, non par la comparaison des noms de modèles. La méthode appropriée peut changer si la sortie attendue change, même lorsque les données restent les mêmes. Le système doit en outre être évalué à trois niveaux : la qualité de l'estimation, la qualité de la conversion de cette estimation en décision, et la qualité de la mise en œuvre de la décision dans la réalité. Une amélioration au premier niveau ne compense pas un échec aux deux autres. Et lors de l'évaluation de toute nouvelle application, la matrice peut se résumer dans les questions suivantes :

• Quelle question agricole précise le système cherche-t-il à résoudre ?
• De quelles données a-t-il besoin, et qui en a vérifié l'exactitude ?
• Quelle sortie produira-t-il, et dans quelle unité ou avec quel degré de confiance ?
• Quelle décision ou quelle action se fondera sur cette sortie ?
• Quel type d'erreur est le plus dangereux : un cas que le système manque ou une fausse alerte ?
• Le système a-t-il été testé dans un environnement indépendant ressemblant à son cadre d'utilisation réel ?
• Que se passe-t-il lorsque les données sont incomplètes ou que le cas est inhabituel ?
• Qui examine le résultat, et qui a le pouvoir de l'interrompre ou de passer outre ?

Le principe directeur : une méthode n'est pas choisie parce qu'elle est la plus récente ou la plus célèbre, mais parce qu'elle produit la sortie qu'exige la décision, peut être vérifiée à l'aide de l'indicateur approprié, et demeure sûre lorsque les données sont incomplètes ou que le résultat est erroné.

12. Comment comparer modèles et systèmes ? De l'exactitude aux tests à la valeur au champ

Lorsqu'un développeur ou une entreprise présente un nouveau système, la première question est souvent : quelle est son exactitude ? C'est une question légitime, mais elle ne suffit pas à juger de son utilité. Deux systèmes peuvent obtenir le même score lors d'un test en laboratoire et pourtant différer grandement par les types d'erreurs qu'ils commettent, leur rapidité de réponse, leur coût d'exploitation, leur aptitude à fonctionner au champ et l'ampleur du préjudice susceptible de survenir lorsqu'ils se trompent. Imaginons deux modèles obtenant chacun un score global de 92 % dans la classification d'images de feuilles. Le premier peut être bon pour détecter les cas sains, tout en manquant les stades précoces d'une maladie dangereuse. Le second peut détecter la plupart des cas malades, mais générer tant de fausses alertes que l'utilisateur perd confiance en lui. Le score global paraît identique, mais la valeur des deux modèles sur l'exploitation n'est pas la même. Le modèle lui-même peut être bon, alors que le système qui l'englobe demeure faible. Le modèle peut analyser correctement l'image, mais l'application la compresse jusqu'à perdre le détail, ou retarde l'envoi du résultat, ou l'affiche sans indiquer le degré de confiance, ou l'associe à une recommandation inadaptée à la région. Nous devons donc distinguer trois choses :

• La performance du modèle : la qualité de l'estimation ou de la classification qu'il produit.
• La performance du système : la qualité du fonctionnement de toute la chaîne, de la collecte des données à l'affichage du résultat ou à l'exécution de l'action.
• L'impact agricole : le fait de savoir si l'usage du système a réellement amélioré la décision et le résultat sur l'exploitation.

Une comparaison n'est juste et utile que si elle traite les niveaux suivants. A. Partir de ce que nous faisons aujourd'hui : la situation de référence pour la comparaison La situation de référence est la méthode que nous utilisons comme point de repère avant d'introduire le nouveau système. Plus simplement, nous ne demandons pas seulement : « Le modèle fonctionne-t-il ? », mais aussi : fonctionne-t-il mieux que ce que nous faisons aujourd'hui, et suffisamment pour justifier le coût du changement ? La situation de référence peut être :

• une inspection effectuée par un spécialiste ou un conseiller de vulgarisation agricole.
• une règle simple élaborée par un expert local.
• le rendement moyen des saisons précédentes.
• l'hypothèse que le relevé de demain sera proche de celui d'aujourd'hui.
• un calendrier d'irrigation fixe calibré sur les conditions locales.
• l'ancien système numérique que le nouveau est censé remplacer.

Ainsi, si l'objectif est de prévoir le rendement, le modèle peut être comparé au rendement moyen de la parcelle au cours des saisons précédentes. Si l'objectif est de détecter une maladie à partir d'une image, il peut être comparé à la performance de l'inspection actuelle, en précisant si celle-ci est réalisée par un agriculteur, un technicien ou un spécialiste. Si l'objectif est de piloter l'irrigation, il peut être comparé au calendrier actuellement en usage du point de vue de l'eau, de l'énergie, de l'état de la plante et du rendement. Il ne faut pas choisir délibérément une méthode de référence faible dans le seul but de faire paraître le nouveau modèle supérieur. Un système complexe peut surpasser une règle naïve, sans pour autant surpasser l'expérience de l'agriculteur ou un système simple calibré localement. Dans ce cas, le gain technique est limité et peut ne pas justifier le coût du matériel, de la connectivité, de la maintenance et de la formation. La comparaison ne doit pas non plus se limiter à la question : « Qui a obtenu le chiffre le plus élevé ? » Elle doit également inclure :

• l'ampleur de l'amélioration par rapport à la méthode actuelle.
• la constance de cette amélioration selon les parcelles et les saisons.
• les types d'erreurs qui ont diminué ou augmenté.
• le coût nécessaire pour obtenir l'amélioration.
• la mesure dans laquelle l'utilisateur est réellement capable d'en tirer parti.

Le sens pratique de la situation de référence : nous déterminons d'abord le niveau de performance dont nous disposons sans le nouveau système, puis nous testons si le système apporte une valeur réelle au-delà de ce niveau. B. Rendre le test proche des conditions réelles d'utilisation Un modèle apprend à partir d'un ensemble d'exemples appelé données d'entraînement. Une fois l'apprentissage achevé, il doit être testé sur des exemples indépendants qu'il n'a pas utilisés auparavant. Le but n'est pas de savoir avec quelle fidélité il se souvient des exemples antérieurs, mais s'il peut traiter de nouveaux cas ressemblant à ce qu'il rencontrera sur l'exploitation. Si le système doit être utilisé sur plusieurs parcelles, le test doit inclure des parcelles qui n'ont pas servi à l'entraînement. S'il doit fonctionner sur différentes saisons, il ne suffit pas de le tester sur des images de la même saison. Si les utilisateurs prennent des photos avec des téléphones de qualité variable, il n'est pas valable de l'évaluer entièrement sur des images captées par un seul appareil dans des conditions idéales. Un partage aléatoire des données peut donner une impression trompeuse. Si dix images similaires sont prises de la même plante, puis que certaines sont placées dans l'entraînement et les autres dans le test, le modèle peut reconnaître la plante, l'arrière-plan ou les conditions de prise de vue plutôt que les signes agricoles que nous voulons lui faire apprendre. Un test plus rigoureux sépare, selon la nature de la tâche :

• des plantes différentes.
• des parcelles ou des champs différents.
• des exploitations ou des régions différentes.
• des saisons ou des années différentes.
• des variétés et des stades de développement différents.
• des appareils de prise de vue ou des types de capteurs différents.
• des langues ou des dialectes différents, et des formulations de questions différentes dans les systèmes conversationnels.

Cela ne signifie pas que chaque test doive couvrir le monde entier, mais qu'il doit représenter fidèlement l'environnement dans lequel le système est censé être utilisé. Si le système a été testé dans un environnement limité, ces limites doivent être déclarées, et son résultat ne doit pas être présenté comme s'il valait pour toute culture, toute exploitation et toute saison. Les modèles candidats doivent également être soumis au même test, dans les mêmes conditions et avec les mêmes données. La comparaison n'est pas équitable si l'un est testé sur des images nettes tandis qu'un autre l'est sur des images de terrain difficiles, ou si l'un est mesuré sur un appareil rapide et l'autre sur un téléphone peu puissant. Le sens pratique du test indépendant : nous plaçons le système face à de nouveaux cas qui reflètent la réalité de son usage, puis nous observons s'il maintient sa performance une fois disparues les commodités du laboratoire. C. Relier l'indicateur à la conséquence de l'erreur Toutes les erreurs ne se valent pas. Un système peut se tromper en déclenchant une alerte au sujet d'une infection inexistante, ou en traitant comme saine une plante infectée. Ce sont deux erreurs, mais leurs conséquences peuvent différer. Une fausse alerte peut faire perdre du temps d'inspection, susciter une analyse supplémentaire ou agacer l'utilisateur. Manquer une infection grave, en revanche, peut retarder l'intervention jusqu'à ce que le dommage s'étende. Dans une autre application, comme le pilotage d'une machine, une fausse alerte peut être moins dangereuse qu'un mouvement incorrect qui endommage la culture ou blesse l'ouvrier. Par conséquent, la moyenne globale ne doit pas dissimuler le type d'erreur le plus important. Une comparaison doit demander :

• Combien de cas dangereux le système a-t-il manqués ?
• Combien de fausses alertes a-t-il émises ?
• Dans quelles variétés ou à quels stades de développement les erreurs sont-elles plus fréquentes ?
• Se trompe-t-il davantage sur les cas précoces que sur les cas manifestes ?
• Quel est le coût de chaque type d'erreur ?
• L'équipe peut-elle absorber le nombre d'alertes qui en résulte ?

Et si la tâche consiste à prédire un nombre, l'erreur doit être exprimée dans une unité que le décideur puisse comprendre. Au lieu de dire que « l'erreur moyenne est de 0,12 » sans explication, on peut dire que la prévision de rendement s'écarte en moyenne d'un certain nombre de kilogrammes ou de tonnes par hectare. Lorsqu'il s'agit aussi de planifier le stockage ou le transport, il convient de préciser si les petites erreurs habituelles dissimulent un petit nombre d'erreurs importantes susceptibles de perturber l'ensemble du plan. Il ne suffit pas non plus que la différence entre deux modèles apparaisse dans un seul chiffre. L'avantage peut être si ténu qu'il pourrait s'inverser si l'on répétait le test lors d'une autre saison ou sur un autre échantillon. Il faut donc examiner l'ampleur de la variation entre les tests, et non le seul meilleur résultat. Le sens pratique de l'indicateur : nous choisissons la méthode de mesure en fonction de la décision que le résultat viendra influencer, et nous traduisons l'erreur en un effet que l'agriculteur, le spécialiste ou le responsable d'exploitation puisse comprendre. D. Tester la manière dont le système exprime l'incertitude, et le moment où il s'abstient de juger Le modèle ne possède pas le même degré de connaissance dans tous les cas. L'image peut être nette et semblable à ce dont il a appris, ou bien sombre, incomplète, ou provenir d'un cas qu'il n'a jamais vu. Les relevés de capteurs peuvent être complets et cohérents, ou bien certains peuvent manquer tandis que les autres se contredisent. Cette variation s'appelle l'incertitude : les éléments de preuve disponibles n'étayent pas tous les résultats au même degré. Le système peut l'exprimer de plusieurs façons, notamment :

• Afficher un score de confiance au lieu d'émettre un jugement catégorique.
• Présenter plusieurs possibilités classées par ordre.
• Afficher une fourchette attendue au lieu d'un nombre unique.
• Signaler les données manquantes ou contradictoires.
• Demander une image, un relevé ou une information supplémentaires.
• Renvoyer le cas à un spécialiste lorsque les éléments de preuve sont insuffisants.

Dans la prévision de rendement, dire que le rendement attendu se situe entre 4,2 et 5,1 tonnes par hectare peut être plus honnête et plus utile que d'avancer un chiffre unique de 4,7 tonnes, surtout si les données météorologiques futures sont instables. Dans le diagnostic d'une image de feuille, il peut être plus approprié que le système déclare que l'image ne suffit pas à distinguer entre deux causes, puis demande une image de la face inférieure de la feuille. Mais le score de confiance affiché par le modèle n'est pas une vérité garantie. Il peut se dire confiant à 80 % alors que ses résultats réels sont bien plus mauvais. C'est pourquoi l'on examine la calibration de la confiance : tester si les chiffres de confiance concordent avec la réalité. Si l'on rassemble un grand nombre de cas auxquels le système a attribué une confiance d'environ 80 %, ses résultats devraient être corrects à un taux proche de cette valeur, et non corrects dans la moitié seulement d'entre eux. Un cas hors du périmètre de ce que le système a appris est un cas qui diffère nettement de ses exemples d'entraînement : une nouvelle variété, un appareil photo différent, une maladie absente des données, des conditions d'éclairage fortement différentes, ou une question dans une langue sur laquelle il n'a pas été testé. Le modèle peut répondre avec assurance même dans de tels cas, raison pour laquelle sa capacité à détecter qu'une entrée lui est étrangère doit être testée. L'abstention signifie que le système ne se force pas à émettre un diagnostic ou une recommandation lorsque les éléments de preuve sont insuffisants. Ce n'est ni un arrêt aléatoire ni un signe d'échec, mais un comportement intentionnel, consistant par exemple à dire : « L'image actuelle ne suffit pas à déterminer l'état avec sûreté. Prenez une image plus nette de la face inférieure de la feuille, précisez la culture et le stade de développement, ou confiez le cas à un spécialiste. » L'abstention elle-même doit également être évaluée. Si le système s'abstient dans la plupart des cas, il peut paraître sûr tout en étant de peu d'utilité. S'il ne s'abstient jamais, il peut donner des réponses assurées dans des cas qu'il ne connaît pas. Ce qu'il faut, c'est un équilibre adapté à la gravité de la tâche et à la capacité de l'équipe à examiner les cas qui lui sont renvoyés. Le sens pratique de l'incertitude et de l'abstention : nous ne demandons pas seulement si le système a répondu, mais s'il a reconnu les limites de ses éléments de preuve, s'il a demandé de l'aide au bon moment, et si cette demande est parvenue à la personne en mesure d'y donner suite. E. Mesurer la performance du système en exploitation, et non seulement en démonstration Un système peut bien fonctionner lors d'une courte démonstration publique, ou sur un ordinateur puissant relié à un réseau stable, puis se heurter à des difficultés lorsqu'il est utilisé jour après jour sur l'exploitation. Pour cette raison, la comparaison englobe des aspects qui n'apparaissent pas dans un chiffre d'exactitude, tels que :

• Le délai entre la saisie des données et l'apparition du résultat.
• La capacité du système à fonctionner sur le téléphone ou l'appareil réellement disponible.
• La consommation d'énergie et le volume de données transmises.
• Le besoin d'une connexion internet continue.
• Ce qui se passe lorsque le réseau est faible ou que le courant est coupé.
• Le coût des caméras, des capteurs, des serveurs et des abonnements.
• Le temps nécessaire pour installer, calibrer et entretenir les équipements.
• La facilité avec laquelle le logiciel peut être mis à jour sans perturber le travail.
• La clarté de l'interface et la capacité de l'utilisateur à comprendre le résultat.
• La disponibilité de l'assistance technique et des pièces de rechange.
• La possibilité de corriger une erreur ou de revenir à un mode de travail manuel.

Un modèle légèrement moins performant lors des tests en laboratoire peut être plus utile au champ s'il s'exécute rapidement sur un téléphone disponible, présente un résultat compréhensible et continue d'assurer ses fonctions de base lorsque la connectivité est faible. Inversement, le modèle le plus exact peut être impraticable s'il exige un appareil coûteux, une connectivité continue, ou un temps de réponse plus long que la fenêtre d'intervention. Si un système de détection des adventices envoie le résultat après que la machine est déjà passée à l'endroit de l'adventice, une grande exactitude d'image ne lui sert à rien. Si une alerte de maladie arrive plusieurs jours après la capture des données, elle peut perdre sa valeur même si le diagnostic est correct. Le sens pratique de la performance opérationnelle : un système utile est celui qui convient aux conditions de travail quotidiennes, et non celui qui ne réussit que lorsque des conditions de démonstration idéales sont réunies. F. Surveiller l'évolution des conditions et la dégradation de la performance après le déploiement Un bon résultat au lancement du système ne garantit pas qu'il se maintiendra. Les environnements agricoles changent : de nouvelles variétés apparaissent, les dates de semis se décalent, caméras et capteurs sont remplacés, les pratiques évoluent, et un ravageur ou une condition non représentée dans les données d'origine peut se propager. Lorsque la nature des données que reçoit le système s'écarte des données sur lesquelles il a été entraîné et testé, on parle de dérive des données. Il ne s'agit pas d'un déplacement littéral des données, mais du fait que les propriétés de la réalité que voit le système ne sont plus ce qu'elles étaient. Parmi les exemples :

• Entraîner un modèle sur des images issues d'une caméra donnée, puis remplacer celle-ci par une caméra aux couleurs et au traitement d'image différents.
• La variété cultivée change, et les symptômes se manifestent différemment.
• Le climat ou le calendrier de la saison change, et la relation entre la météo et le rendement s'en trouve modifiée.
• La modification du système d'alimentation ou d'éclairage dans une serre.
• La méthode de saisie des enregistrements, ou le nom des champs dans l'application, change.
• De nouvelles questions et de nouveaux dialectes apparaissent dans le système conversationnel de conseil.

Il peut aussi arriver que les données demeurent superficiellement semblables alors que la relation entre les données et le résultat change. Une température donnée pouvait être associée à un stress de la plante sous un ancien système d'irrigation, puis cette relation a changé après l'amélioration de la ventilation ou l'installation d'un nouvel ombrage. C'est pourquoi, après le déploiement, le système a besoin d'une surveillance comprenant :

• La comparaison des nouvelles données avec les données sur lesquelles il a été testé.
• L'enregistrement des cas inhabituels ou des cas où la confiance a baissé.
• L'examen d'un échantillon de résultats au champ.
• Le suivi du nombre de fausses alertes et de cas manqués.
• La définition d'un seuil déclenchant une réévaluation.
• La désignation de la personne qui décide de mettre à jour ou de réentraîner le modèle.
• Le test de la nouvelle version avant son approbation.
• Le maintien de la possibilité de revenir à une version antérieure si un problème apparaît.

Le réentraînement n'est pas une solution automatique à toute dégradation ; des erreurs ou des résultats non documentés peuvent s'introduire dans les nouvelles données, et le système peut les apprendre et devenir pire. Pour cette raison, les mises à jour doivent passer par un examen, des tests et une approbation. Le sens pratique de la dérive des données : ce qui valait la saison dernière peut ne pas rester automatiquement valable la saison suivante ; le système a donc besoin d'une surveillance continue, et non d'un certificat de réussite accordé une fois pour toutes. G. Mesurer ce qui s'est passé après que le résultat est parvenu à l'utilisateur La prédiction peut s'améliorer sans que le résultat agricole s'améliore. Le système peut détecter précocement une maladie, mais l'alerte n'atteint pas la bonne personne. L'alerte peut arriver, mais l'utilisateur ne la comprend pas. L'utilisateur peut la comprendre, mais ne pas disposer du produit, de la main-d'œuvre ou du temps nécessaires pour intervenir. L'utilisateur peut exécuter la recommandation, mais celle-ci peut ne pas convenir aux conditions de la parcelle. Pour cette raison, toute la chaîne doit être suivie :

1. L'estimation du modèle était-elle correcte ?
2. Le système l'a-t-il transformée en une alerte ou une recommandation claire ?
3. Le résultat est-il arrivé au bon moment ?
4. L'utilisateur l'a-t-il compris et lui a-t-il fait confiance ?
5. A-t-il changé la décision ?
6. La décision a-t-elle été mise en œuvre comme prévu ?
7. La mise en œuvre a-t-elle conduit à un meilleur résultat agricole ?

Ces niveaux ne signifient pas la même chose. L'exactitude de la prévision d'irrigation peut s'améliorer sans que la consommation d'eau baisse, parce que le réseau présente une fuite. Le système peut détecter précocement un état sanitaire chez un animal, mais l'équipe ne peut examiner les alertes qu'en fin de journée. Il peut proposer une meilleure répartition de la main-d'œuvre, mais le plan ne tient pas compte des déplacements entre parcelles. Lors de la mesure de l'impact, plus d'un résultat doit être pris en considération. Le système peut réduire la consommation d'eau mais augmenter l'usage d'énergie, ou accroître le rendement mais augmenter le coût des intrants, ou réduire le travail manuel mais accroître la dépendance à un service externe difficile à réparer. Tout changement de rendement ou de coût ne doit pas être attribué au système du seul fait qu'il est survenu après son utilisation ; la cause peut être une meilleure saison, une variation des prix ou une autre pratique agricole. Si l'on souhaite établir que le système a fait la différence, une mise en œuvre par phases, une comparaison de parcelles ou de périodes similaires, ou un dispositif de terrain approprié séparant l'effet du système des autres facteurs peuvent être nécessaires. Le sens pratique de la mesure de l'impact : l'évaluation ne s'arrête pas à la question de savoir si la réponse était correcte ; elle se poursuit en demandant si la réponse est arrivée, si elle a changé la décision, et si la décision a conduit à un meilleur résultat dans le monde réel. H. Examiner l'équité, la responsabilité et la gouvernance Le système peut atteindre une bonne moyenne tout en fonctionnant mieux pour un groupe d'utilisateurs ou d'exploitations au détriment d'un autre. Il peut dépendre d'une connectivité rapide indisponible dans les zones reculées, ou d'un téléphone récent que tous les utilisateurs ne possèdent pas, ou d'images provenant de grandes exploitations bien organisées qui ne représentent pas les petites exploitations, ou d'une langue soutenue qui traite mal les questions et les dialectes locaux. Par conséquent, les résultats doivent être ventilés, lorsque cela est pertinent, selon :

• La taille de l'exploitation et la nature de la production.
• La région et les conditions climatiques.
• La variété et le stade de développement.
• Le type d'appareil ou de capteur.
• La qualité de la connectivité.
• La langue ou le dialecte.
• L'expérience de l'utilisateur et sa capacité à utiliser l'interface.

L'équité ne signifie pas que le système doive donner le même résultat à tout le monde ; elle signifie plutôt examiner si un groupe donné supporte davantage d'erreurs, ne peut accéder au service, ou ne dispose d'aucun moyen de contester une décision erronée. Quant à la gouvernance, elle désigne les règles et les responsabilités qui encadrent le système tout au long de son cycle de vie, notamment :

• Qui a autorisé son usage ?
• Qui examine ses données et sa performance ?
• Qui porte la responsabilité de l'erreur ?
• L'utilisateur peut-il faire objection ou demander une revue humaine ?
• Quelles décisions le système peut-il proposer ou exécuter ?
• Quelles décisions doivent rester entre les mains d'un spécialiste ou d'une autorité habilitée ?
• Comment les enregistrements sont-ils conservés et la vie privée respectée ?
• Comment les changements et les versions sont-ils documentés ?
• Qui a le pouvoir d'arrêter le système lorsqu'un risque apparaît ?

Ces questions gagnent en importance lorsque le système affecte la santé végétale ou animale, la sécurité des travailleurs, l'usage de l'eau et de substances réglementées, ou l'acceptation du produit sur le marché. Cette perspective s'inspire de l'idée d'une gestion des risques de l'IA à travers les étapes de son cycle de vie, de la conception et des tests à l'exploitation, à la surveillance et à la mise à jour [SRC033]. Le sens pratique de la gouvernance : il ne suffit pas de savoir ce que le système peut faire ; nous devons aussi savoir qui le surveille, qui l'examine et qui détient le pouvoir de décision lorsqu'il se trompe. Pour le lecteur averti : une comparaison professionnelle ne présente pas un chiffre unique comme un verdict définitif. Elle doit préciser la taille de l'échantillon de test, le degré de variation du résultat, la performance selon les différents groupes et environnements, sa stabilité dans le temps, et le coût de chaque type d'erreur. Les conditions de la comparaison doivent également être maintenues constantes : les mêmes données, la même définition de la tâche, le même seuil d'alerte et le même environnement d'exploitation. Un modèle peut l'emporter lorsqu'il lui est permis d'envoyer de nombreuses alertes, tandis qu'un autre peut l'emporter lorsque le nombre d'alertes est limité à ce que l'équipe peut examiner. La comparaison est donc toujours liée aux conditions de la décision et aux ressources disponibles, et non à la performance de l'algorithme dans l'absolu. Une liste de contrôle pratique pour comparer n'importe quel système La comparaison peut se résumer en huit questions, à condition de bien comprendre ce que chacune signifie :

1. Quelle décision changera du fait du système ?

La sortie conduira-t-elle à une inspection supplémentaire, à l'irrigation d'un secteur, au traitement d'un animal, à l'achat d'un intrant ou au pilotage d'une machine ? Si nous ne savons pas quelle décision changera, nous ne saurons pas quelle performance est requise.

2. À quelle méthode actuelle le système est-il comparé ?

Surpasse-t-il l'expérience de l'agriculteur, l'inspection du spécialiste, une règle simple ou le système actuellement en usage ? Et quelle valeur ajoutée apporte-t-il ?

3. A-t-il été testé dans un environnement indépendant semblable à celui où il sera utilisé ?

Le test a-t-il inclus des parcelles, des saisons, des appareils, des variétés et des utilisateurs dont les données n'ont pas été intégrées à l'entraînement ?

4. Quelle erreur est la plus dangereuse, et à quelle fréquence est-elle survenue ?

Le risque le plus grand est-il de manquer le cas, d'émettre une fausse alarme, de prendre du retard, ou de diriger l'action au mauvais endroit ? Et quel effet cette erreur a-t-elle sur l'exploitation ?

5. Rend-il claires les limites de sa connaissance ?

Présente-t-il un degré de confiance ou une fourchette attendue ? Et demande-t-il des informations supplémentaires ou renvoie-t-il le cas à un humain lorsque les éléments de preuve sont insuffisants ?

6. Quel est le coût de son exploitation et de sa maintenance ?

Quels appareils, quelle connectivité, quelle alimentation, quelle formation, quelle assistance et quelle maintenance exige-t-il ? Et que se passe-t-il en cas d'interruption ou de panne ?

7. Comment détectons-nous que sa performance s'est dégradée ?

Qui surveille les résultats après le déploiement ? Quel signe indique la nécessité de retester ou de mettre à jour ? Et qui approuve la nouvelle version ?

8. Qui détient la décision finale et le pouvoir de l'arrêter ?

L'utilisateur sait-il quand le résultat est consultatif ? Qui examine les cas à haut risque ? Et peut-on interrompre l'exécution automatique et ramener le système à un mode sûr ?

Le principe directeur : un modèle n'est pas meilleur du seul fait que son chiffre est plus élevé ; il est meilleur lorsqu'il surpasse une méthode réaliste, tient bon dans l'environnement d'usage, révèle les limites de sa connaissance, fonctionne dans les limites des ressources disponibles, réduit l'erreur la plus dommageable, et conduit en définitive à une meilleure décision et à un meilleur résultat sur l'exploitation.

13. Un cas pédagogique intégré : comment une image de feuille devient-elle une décision agricole responsable ?

Le cas suivant est un exemple didactique qui réunit les concepts du chapitre en un seul cheminement. Il ne fournit le diagnostic d'aucune maladie particulière, ni ne décrit un traitement, une substance ou une dose ; il montre plutôt comment un système responsable devrait traiter une information incomplète, et comment il passe d'une image initiale à une décision dont les motifs et les limites peuvent être examinés. Un agriculteur a remarqué des taches jaunes et brunes sur certaines feuilles dans une partie de la parcelle. Il a pris une photo avec son téléphone, l'a envoyée à un système assistant, puis a écrit : « Quel est ce problème, et que dois-je utiliser contre lui ? » La question peut sembler simple, mais une réponse responsable ne commence pas par le nom d'une maladie ou d'une substance. Une image unique peut montrer un symptôme — c'est-à-dire un changement visible de la couleur ou de la forme de la feuille — mais elle n'établit pas à elle seule la cause du symptôme. Sur l'image, les effets d'une maladie fongique ou bactérienne, d'une carence en nutriments, d'un stress hydrique, d'une lésion chimique, d'un coup de soleil, de dégâts d'insectes, ou de plusieurs facteurs à la fois peuvent se ressembler. Pour cette raison, l'image est le début du cheminement d'examen, non son terme. Première étape — Transformer la question générale en une question examinable Le système ne passe pas d'un bond de la question « Que dois-je utiliser ? » à la proposition d'un traitement. Il restructure plutôt la question en questions plus petites :

• Des signes clairement descriptibles apparaissent-ils sur l'image ?
• Dans quelle partie de la feuille se situent-ils ?
• Le motif est-il localisé ou étendu ?
• L'image suffit-elle à distinguer entre certaines des possibilités ?
• Quelles informations manquent avant d'avancer vers un diagnostic ?
• Existe-t-il un signe appelant un examen rapide par un spécialiste ?

La première réponse du système pourrait être, par exemple : « L'image montre des zones jaunes et brunes, mais l'image seule ne suffit pas à déterminer la cause ni à choisir un traitement. Je vais d'abord évaluer la qualité de l'image, puis j'ai besoin d'informations sur la culture, l'étendue de la propagation des symptômes et les conditions environnantes. » Cette entrée en matière remplit une fonction importante : elle sépare la constatation du symptôme de la connaissance de sa cause, et empêche le système de transformer une ressemblance visuelle en une certitude qu'il ne possède pas. Deuxième étape — Vérifier que l'image se prête à l'analyse Avant d'analyser les taches, l'application examine la qualité de l'image elle-même. Ce qui paraît être un symptôme de maladie peut n'être en réalité qu'une ombre, un reflet lumineux, un artefact de compression d'image, ou une partie floue. Le système vérifie, dans la mesure du possible, des points tels que :

• La feuille est-elle nette ou floutée par le mouvement ?
• L'éclairage est-il assez naturel pour montrer la couleur véritable ?
• La zone atteinte est-elle visible en gros plan ?
• La feuille entière est-elle visible, de sorte que l'emplacement des symptômes sur celle-ci puisse être déterminé ?
• Existe-t-il une image de la face supérieure et une autre de la face inférieure ?
• Existe-t-il une image de la plante entière, et pas seulement de la feuille ?
• Existe-t-il un objet de référence permettant d'estimer la taille de la tache ?
• L'image a-t-elle été prise après que la feuille a été mouillée ou aspergée de quelque chose susceptible de modifier son aspect ?

En évoquant les « deux faces », on entend la photographie de la face supérieure de la feuille et de sa face inférieure, car certains signes peuvent être plus nets sur l'une que sur l'autre. Si l'image est insuffisante, le système ne doit pas produire une réponse assurée au seul motif que l'utilisateur en attend une. Il explique plutôt ce qui manque et demande que l'image soit reprise, par exemple : « L'image est floue autour des bords des taches. Prenez une image plus rapprochée à la lumière naturelle, une autre image de la face inférieure de la feuille, puis ajoutez une image de la plante entière et de la partie atteinte de la parcelle. » Ce comportement n'est pas une entrave pour l'utilisateur ; il le protège plutôt d'un résultat fondé sur une entrée qui n'étaye pas une inférence fiable. Troisième étape — Décrire ce que voit l'outil de vision, sans prétendre à un diagnostic Si l'image se prête à l'analyse, le système peut recourir à un modèle de vision par ordinateur pour accomplir une ou plusieurs tâches :

• Identifier les zones décolorées au sein de l'image.
• Estimer la proportion de la feuille qui est atteinte.
• Décrire la forme des taches et leur répartition apparente.
• Comparer le motif aux catégories que le modèle a apprises à partir d'images antérieures.
• Détecter que l'image ne ressemble pas suffisamment aux cas sur lesquels il a été testé.

La sortie doit être claire quant à ses limites. Ainsi, au lieu que le système dise : « Il s'agit de la maladie X. » il peut dire : « Le système a détecté des taches jaunes et brunes irrégulières dans certaines parties du tissu foliaire. Cet aspect ressemble visuellement à plus d'une affection, et l'image actuelle ne suffit pas à en déterminer la cause. » Le système peut également montrer la zone sur laquelle il s'est concentré dans l'image, afin que l'utilisateur ou le spécialiste puisse vérifier qu'il a bien analysé le tissu foliaire atteint, plutôt que l'arrière-plan ou une ombre voisine. Quant à l'expression « catégorie inconnue », elle ne signifie pas que le modèle a découvert une maladie nommée « inconnue ». Elle signifie que l'image ne correspond pas d'assez près aux catégories que le système a appris à distinguer, ou que sa qualité ne permet pas un jugement sûr. Dans ce cas, il doit afficher un résultat tel que :

• Le cas n'est pas représenté parmi les classes connues du système.
• L'image est inadéquate pour la comparaison.
• Des signes se recoupent et ne permettent pas la classification.
• Un examen humain ou des informations supplémentaires sont nécessaires.

Une distinction importante apparaît ici : le modèle peut être capable de localiser les taches avec exactitude sans être capable d'en déterminer la cause. La réussite de la première tâche visuelle ne prouve pas la réussite du diagnostic. Quatrième étape — Ajouter le contexte du champ au contexte de l'image Les symptômes végétaux ne peuvent être dissociés de la culture, de l'environnement et de la conduite. C'est pourquoi le système demande des informations susceptibles de changer l'interprétation de l'image, mais il vaut mieux ne pas accabler l'agriculteur de dizaines de questions d'un coup. Il commence par les questions les plus utiles, puis demande des précisions supplémentaires lorsque c'est nécessaire. Il peut d'abord demander :

• Quelles sont la culture et la variété, si elle est connue ?
• Quel est l'âge de la plante ou son stade de développement ?
• Quand les symptômes sont-ils apparus ?
• Augmentent-ils rapidement, ou paraissent-ils stables ?
• Apparaissent-ils sur une seule plante ou sur un groupe de plantes ?
• Sont-ils concentrés en bordure de parcelle, par taches dispersées, ou le long des rangs d'irrigation ?
• Ont-ils débuté sur les feuilles les plus âgées ou sur les plus jeunes ?
• Y a-t-il des signes supplémentaires à la face inférieure de la feuille ?
• Des symptômes sont-ils apparus sur la tige, les fruits ou les racines ?
• Y a-t-il eu une irrigation abondante, une interruption d'eau, une vague de chaleur ou un coup de froid ?
• Un intrant agricole a-t-il été utilisé, ou le programme de fertilisation a-t-il été modifié récemment ?
• Existe-t-il des symptômes similaires dans une culture ou une parcelle voisine ?

Ces informations n'ajoutent pas des « détails accessoires » ; elles peuvent changer entièrement le sens de l'image. Une répartition des symptômes le long d'une ligne d'irrigation peut orienter l'investigation vers l'eau, les racines ou le matériel d'irrigation, tandis qu'une propagation depuis un foyer vers les plantes voisines peut soulever un autre ensemble de possibilités. Et leur apparition sur les feuilles âgées peut avoir une signification différente de leur apparition d'abord sur les pousses nouvelles. Le système devrait également distinguer entre l'information saisie par l'utilisateur, l'information mesurée par un capteur, et une inférence tirée de l'image. Il ne devrait pas les présenter toutes comme s'il s'agissait de faits de poids égal. Cinquième étape — Classer les possibilités au lieu de déclarer une cause unique Après avoir réuni l'image et le contexte, le système peut classer les causes possibles. Ici, pondérer signifie comparer des possibilités à la lumière des éléments de preuve disponibles, et non déclarer que la cause la mieux classée est établie. Il peut présenter le résultat sous cette forme :

• Une possibilité est compatible avec la forme et la répartition des taches, mais il lui manque un signe qui devrait être vérifié à la face inférieure de la feuille.
• Une autre possibilité est étayée par les conditions météorologiques récentes, mais elle n'explique pas complètement la localisation des symptômes.
• Une possibilité liée à la nutrition ou à l'irrigation exige de revoir la répartition des symptômes dans la parcelle ainsi que des mesures de sol ou d'eau.
• D'autres causes sont moins probables, mais elles restent possibles parce que l'information est incomplète.

Il ne suffit pas non plus de présenter des pourcentages bruts, car un chiffre peut donner au lecteur un sentiment de certitude supérieur à ce que les éléments de preuve autorisent. Le système devrait préciser :

• Quels éléments de preuve ont renforcé chaque possibilité ?
• Quelles informations l'ont affaiblie ?
• Quelles données manquent ?
• Quelle question ou quel test suivant permettrait de distinguer le plus efficacement entre les possibilités ?
• Les scores de confiance qu'il présente ont-ils été testés dans une culture et un environnement similaires ?

En formulation technique, le terme couche probabiliste désigne la partie qui rassemble différents éléments de preuve et réordonne les possibilités lorsque de nouvelles informations arrivent. Mais cette partie ne « connaît pas la vérité » par elle-même ; elle organise plutôt ce que les données étayent et ce qu'elles ne permettent toujours pas de trancher. Ainsi, si l'utilisateur ajoute une image de la face inférieure de la feuille, ou une description de la manière dont les symptômes se propagent, ou le résultat d'un test au champ ou en laboratoire, le classement peut changer. Ce n'est pas le signe d'une contradiction, mais le résultat naturel de la mise à jour du jugement lorsque des éléments de preuve plus solides surviennent. Sixième étape — Rechercher des sources fiables adaptées au contexte Après avoir réduit l'éventail des possibilités, le système interroge des sources de connaissances approuvées. Par sources gouvernées, on n'entend pas n'importe quelles pages qu'une recherche trouverait par hasard, mais un ensemble de documents dont la source, la date, le champ de validité et le statut d'approbation ont été précisés. Celles-ci peuvent comprendre, selon la tâche et le pays :

• Des documents d'orientation émis par des autorités agricoles de confiance.
• Des références scientifiques ou diagnostiques appropriées pour la culture.
• Des bulletins officiels actualisés.
• Des instructions émises par les autorités réglementaires compétentes.
• Les consignes d'utilisation officielles en vigueur pour les produits homologués localement.
• Des protocoles d'échantillonnage ou le renvoi à un laboratoire.

Une source ne devient pas appropriée du seul fait qu'elle est correcte en elle-même. Elle peut avoir été émise par un autre pays où les produits homologués diffèrent, ou concerner une autre variété, ou être obsolète, ou traiter d'une maladie aux symptômes similaires dans une autre culture. Le système devrait donc faire correspondre, autant que possible :

• La culture et la variété.
• La localisation, ou le pays et la région.
• La date et la version du document.
• L'organisme émetteur.
• Le type de culture et l'environnement.
• Le stade de développement de la culture.
• Le statut réglementaire de la substance ou de la procédure.

Le système doit présenter la source d'une manière que l'utilisateur ou le spécialiste puisse examiner, en précisant le titre du document, l'organisme émetteur, la date et la partie sur laquelle il s'est appuyé. Il doit aussi distinguer entre :

• Ce qui est énoncé explicitement dans la source.
• Ce que le système a inféré en combinant plusieurs informations.
• Ce pour quoi il n'a pas trouvé d'appui suffisant.

S'il ne trouve pas de source appropriée, la formulation responsable est la suivante : « Je n'ai pas trouvé, au sein de l'ensemble disponible de sources approuvées, d'orientation récente et appropriée pour cette culture et cette région qui justifierait une recommandation précise. Il est nécessaire de consulter un spécialiste ou l'autorité agricole locale. » Ne pas trouver de source n'est pas une lacune que le modèle devrait combler par des conjectures ; c'est au contraire une information importante qui doit être affichée. Septième étape — Interrompre le passage non sûr de la probabilité au traitement Une fois les probabilités et les sources présentées, le verrou de sécurité entre en jeu. On entend par là un ensemble de règles et de revues qui empêchent le système de convertir une ressemblance visuelle ou une probabilité non tranchée en une consigne de traitement directe. Il convient de distinguer différents niveaux de sortie :

1. Description générale : Que montre l'image, et quelles informations manquent ?
2. Étape de vérification : Quelle est l'image, l'examen ou l'information suivante requise ?
3. Orientation préventive générale à faible risque : Si elle est étayée par une source appropriée et ne présuppose pas un diagnostic non confirmé.
4. Diagnostic professionnel : Il peut exiger un spécialiste ou un test de référence.
5. Choix d'une substance, d'une dose ou d'une procédure réglementée : Cela dépend du diagnostic, de l'homologation locale, des consignes d'utilisation officielles en vigueur du produit, et de l'autorité de la personne habilitée à prendre la décision.

La présence d'un nom de maladie dans la liste des probabilités ne justifie pas de passer automatiquement au nom d'une substance. Et la présence d'une substance mentionnée dans une source ancienne ou émise par un autre pays n'établit pas qu'elle est homologuée pour la culture et la région, ni que son usage est approprié au cas. Le verrou de sécurité peut déterminer que la sortie correcte consiste en :

• Une demande d'images ou d'informations supplémentaires.
• Une suggestion d'inspecter le reste de la plante et de la parcelle.
• Le renvoi du cas à un spécialiste agricole.
• Le respect des instructions du spécialiste lors de la soumission d'un échantillon pour examen.
• Une vérification auprès de l'autorité réglementaire compétente du pays ou de la région.
• L'abstention de proposer une substance ou une dose parce que le diagnostic ou la source est insuffisant.
• L'émission d'une alerte urgente si les indicateurs disponibles appellent une intervention professionnelle rapide, en indiquant le motif de l'alerte sans prétendre à un diagnostic définitif.

Le système ne devrait pas se contenter d'une formule générale du type « consultez un expert » à chaque fois, car cela le rend d'une utilité limitée. Mieux vaut qu'il explique pourquoi la question requiert un spécialiste, quelles informations doivent être préparées, et quelle question le spécialiste doit trancher. Huitième étape — Prendre la décision, documenter ce qui s'est passé et suivre le résultat Une fois les éléments de preuve et leurs limites présentés, la décision demeure entre les mains de l'agriculteur ou du spécialiste habilité, selon le type d'action et son niveau de risque. Le résultat peut être une demande d'examen complémentaire, une surveillance du cas pendant une durée déterminée, la réalisation d'un test, ou l'exécution d'une intervention approuvée par le spécialiste conformément aux exigences locales. Le système enregistre, avec le consentement de l'utilisateur et conformément aux règles de confidentialité, des éléments tels que :

• Les images et les informations sur lesquelles l'analyse s'est fondée.
• L'heure à laquelle le résultat a été émis.
• Les probabilités présentées et les niveaux de confiance.
• Les sources récupérées et leurs versions.
• Les données qui manquaient.
• Les avertissements ou les motifs d'abstention.
• La décision prise par l'utilisateur ou le spécialiste.
• Ce qui a été effectivement réalisé.
• Tout résultat ou changement ultérieur survenu.

Le retour d'information désigne les informations qui reviennent au système après la décision : le spécialiste a-t-il confirmé une cause particulière ? Le test a-t-il produit un résultat de référence ? Les symptômes ont-ils changé ? L'action a-t-elle été effectivement réalisée ? Mais ce que l'utilisateur écrit ensuite ne devient pas automatiquement un fait sur lequel l'entraînement peut s'appuyer. L'utilisateur peut penser que le diagnostic était correct parce qu'il a constaté une amélioration, alors que celle-ci peut en réalité résulter d'un changement de météo, d'irrigation ou d'un autre facteur. Il peut aussi saisir un nom imprécis, ou attribuer le résultat à une action qui n'a pas été exécutée telle qu'elle a été consignée. Par conséquent, les informations ultérieures restent de force variable :

• L'observation de l'utilisateur est utile pour le suivi.
• La confirmation d'un spécialiste est plus solide qu'une supposition initiale.
• Le résultat d'un test de référence peut être plus solide pour une tâche précise.
• Une amélioration après une action ne prouve pas à elle seule que le diagnostic ou l'action a causé l'amélioration.

Avant que ces informations ne soient utilisées pour mettre à jour le modèle, il faut examiner leur qualité, vérifier leur source, identifier qui les a validées, puis tester le modèle mis à jour avant sa diffusion. Sans quoi le système risque d'apprendre de ses anciennes erreurs et de les répéter avec plus d'assurance. À quoi la réponse pourrait-elle ressembler pour l'agriculteur ? Après avoir franchi les étapes initiales, le système pourrait présenter une réponse telle que : « L'image montre des taches jaunes et brunes sur le tissu foliaire, mais cet aspect peut résulter de plus d'une cause, et l'image actuelle ne suffit pas à confirmer un diagnostic ou à choisir un traitement. Envoyez une image nette de la face inférieure de la feuille, une image de la plante entière, et indiquez la culture et son stade de développement, la date d'apparition des symptômes, et s'ils apparaissent sur des plantes voisines ou le long de la ligne d'irrigation. Une fois ces informations complètes, les probabilités pourront être classées et le test suivant déterminé. Je ne proposerai ni substance ni dose tant qu'il n'y aura pas un diagnostic, une source appropriée à la région, et une vérification au regard des consignes d'utilisation officielles en vigueur du produit. » Cette réponse ne laisse pas l'agriculteur sans aide, tout en ne lui accordant pas une certitude artificielle. Elle explicite ce que le système a vu, ce qu'il n'a pas pu établir, quelles informations sont requises, et pourquoi il n'est pas passé directement au traitement. Où le parcours peut-il échouer ? Le cas montre que l'erreur ne réside pas dans le modèle d'image seul. Elle peut survenir à n'importe quelle étape :

• L'image peut être inexploitable, mais l'application l'accepte.
• Le modèle peut se concentrer sur une ombre ou un arrière-plan au lieu des taches.
• Le cas peut ne pas être représenté dans les données d'entraînement.
• L'utilisateur peut saisir un nom de culture ou une localisation erronés.
• Le système peut relier l'image au contexte d'une autre parcelle.
• Le système peut classer les probabilités avec plus d'assurance que les éléments de preuve ne le permettent.
• Le système peut récupérer une source correcte, mais obsolète ou inadaptée au pays.
• L'interface peut résumer la source d'une manière qui en change le sens.
• Une information générale peut se transformer en une recommandation de traitement non autorisée.
• La réponse peut arriver tard, après que l'état a changé.
• Le système peut consigner une décision proposée comme si elle avait été effectivement exécutée.
• Une observation non documentée peut entrer dans les données d'entraînement comme un diagnostic confirmé.

Pour cette raison, il ne suffit pas de dire que « le modèle a reconnu l'image ». Nous devons savoir comment l'image est devenue une probabilité, comment cette probabilité a été reliée à la source, comment une inférence non sûre a été empêchée, qui a pris la décision, et comment le résultat a été documenté. Pour le lecteur avancé : ce cas réunit plusieurs fonctions distinctes, dont chacune devrait être évaluée séparément : la qualité de l'image, la localisation des symptômes, la classification du motif visuel, la détection de cas inhabituels, la collecte du contexte, le classement des probabilités, la récupération des sources, la vérification de leur adéquation, la formulation de la réponse, l'application des règles de sécurité, le renvoi à un humain et le suivi du résultat. La réussite d'une fonction ne doit pas être utilisée comme preuve de la réussite des autres. Il faut aussi éviter la « clôture diagnostique prématurée » — c'est-à-dire s'arrêter à la première explication qui paraît convaincante — et rechercher au contraire les éléments de preuve qui l'étayent et ceux qui pourraient la réfuter. Si le parcours s'arrête après l'identification du motif visible dans l'image, alors nous avons affaire à un outil d'analyse d'images. Si l'on y ajoute le contexte et le classement des probabilités, alors nous avons affaire à un assistant de raisonnement initial. S'il est relié à des sources appropriées, à des règles de sécurité, à une voie de revue humaine, à une documentation et à un suivi, alors nous avons affaire à un système d'aide à la décision. La différence entre ces niveaux n'apparaît pas nécessairement dans l'élégance de l'interface ou la fluidité de la réponse ; elle apparaît plutôt dans les questions que le système a posées, les hypothèses qu'il a divulguées, les sources qu'il a rendues disponibles pour examen, et les limites qu'il ne s'est pas autorisé à franchir. Le principe directeur : l'image de la feuille peut révéler où commence la question, mais elle n'établit pas à elle seule où s'achève la réponse ; et une décision responsable est celle qui relie ce que le système a vu à ce qu'il sait du contexte, à ce qu'il peut établir à partir des sources, et à ce qui doit rester soumis au jugement humain.

14. Que doit retenir le lecteur de ce chapitre ?

Que doit retenir le lecteur de ce chapitre ? Le lecteur n'a pas besoin de mémoriser les noms des algorithmes, ni de connaître le détail de leur construction, pour réfléchir clairement à l'intelligence artificielle agricole. Ce qui importe, c'est de voir le lien entre quatre choses : la question à laquelle nous voulons répondre, les données dont nous disposons, le résultat que le système produit, et l'action qui peut avoir lieu au champ sur cette base. Un système qui analyse l'image d'une feuille n'accomplit pas la même tâche qu'un système qui prédit le rendement. Un système qui prévoit le besoin en eau d'une culture n'accomplit pas la même tâche qu'un outil de planification qui choisit quand mettre la pompe en marche. De même, émettre une alerte n'équivaut pas à prendre une décision, prendre une décision n'équivaut pas à exécuter une action, et exécuter une action ne garantit pas à elle seule un meilleur résultat agricole. Face à toute application, tout appareil ou toute présentation commerciale, le lecteur peut organiser son évaluation en quatre groupes de questions. Premièrement — quel problème le système cherche-t-il à résoudre ? Commencez par la finalité, et non par le nom de la technologie :

• À quel problème agricole précis le système répond-il ?
• Qui est l'utilisateur visé : l'agriculteur, le conseiller de vulgarisation, le vétérinaire, le responsable d'exploitation ou le chercheur ?
• Décrit-il ce qui se passe maintenant, ou prédit-il ce qui peut arriver plus tard ?
• Présente-t-il des probabilités, suggère-t-il une décision, ou exécute-t-il une action sur une machine ?
• Quelle décision est censée changer en raison du résultat ?
• La sortie arrive-t-elle tant qu'une intervention peut encore être utile ?

Une entreprise peut dire que son système « détecte les maladies des plantes », mais cette description peut recouvrir des tâches très différentes. Identifie-t-il seulement la présence d'un changement dans la feuille ? Compare-t-il l'image avec un nombre limité de cas ? Classe-t-il les causes possibles ? Fournit-il une source ? Suggère-t-il un traitement ? Chacun de ces niveaux met en jeu des données, des risques et des responsabilités différents. Il faut aussi se demander ce que signifie le résultat lui-même. Si le système affiche le nombre 0,82, que signifie-t-il ? Est-ce une probabilité ? Un score de similarité ? Une proportion de la surface atteinte ? Et s'il prédit un rendement de 4,7, quelle est l'unité : tonnes par hectare, par feddan, ou pour l'ensemble de l'exploitation ? Et à quelle période se réfère-t-il ? Une sortie dont l'unité, le moment ou le rapport à la décision sont inconnus peut sembler précise, mais elle ne fonde pas une action responsable. Deuxièmement — que sait le système, et que ne peut-il pas savoir ? Tout modèle dépend des données dont il a appris, ou des règles et sources qui lui ont été fournies. Il faut donc demander :

• Sur quel type de données a-t-il été construit ?
• D'où proviennent-elles ?
• Qui en a vérifié la qualité ?
• Représentent-elles les cultures, les variétés, les saisons et les environnements dans lesquels il sera utilisé ?
• Comprennent-elles des cas précoces, mixtes et difficiles, ou seulement des cas nets ?
• Quelles informations le système ne peut-il ni voir ni atteindre ?
• Que se passe-t-il si l'image est mauvaise, si le relevé est incomplet ou si le capteur est défaillant ?
• Distingue-t-il entre ce qu'il a effectivement mesuré, ce que l'utilisateur a saisi, et ce qu'il a lui-même inféré ?

Un modèle d'images de plantes peut apprendre à partir d'exemples reliés chacun à une classe de référence vérifiée par un expert. Un modèle de rendement peut apprendre à partir d'enregistrements reliés à des valeurs de référence mesurées après récolte. Si ces classes de référence ou ces mesures sont inexactes, l'erreur entre dans le processus d'apprentissage lui-même. La ressemblance entre les données d'entraînement et l'environnement de l'exploitation n'est pas non plus un détail secondaire. Un modèle entraîné sur des images de feuilles isolées en laboratoire peut peiner dans une parcelle où les feuilles se chevauchent et où la lumière change. Un système entraîné sur de grandes exploitations dotées d'une couverture régulière de capteurs peut ne pas maintenir sa performance sur une petite exploitation qui dépend de mesures intermittentes. La question importante n'est pas seulement « Qu'est-ce que le système a vu ? » mais aussi : Que ne peut-il pas voir, alors même que la décision en dépend ? Une image ne révèle pas toujours l'état des racines, n'explique pas à elle seule l'historique de l'irrigation et de la fertilisation, et ne prouve pas la présence d'un agent pathogène. Un relevé d'humidité en un seul point ne décrit pas nécessairement l'ensemble du secteur. Et un enregistrement numérique ne montre pas toujours si l'action consignée a été effectivement exécutée. Troisièmement — comment savons-nous que le système fonctionne réellement ? Il ne suffit pas qu'un produit affiche un pourcentage élevé ou un essai réussi. Il faut demander :

• À quoi le système a-t-il été comparé ?
• A-t-il surpassé la méthode actuellement utilisée, ou seulement une référence initiale faible ?
• A-t-il été testé sur des exploitations, des saisons ou des appareils qui ne faisaient pas partie de son entraînement ?
• Quel type d'erreur est le plus grave dans cette tâche ?
• À quelle fréquence cette erreur est-elle survenue ?
• Les résultats ont-ils été présentés pour chaque cas important, ou dissimulés dans une moyenne globale ?
• A-t-on seulement montré la réussite du modèle, ou a-t-on testé l'ensemble du système ?
• Existe-t-il des éléments de preuve d'un effet sur la décision et sur le résultat agricole, ou seulement sur l'exactitude de la prédiction ?

La méthode actuellement utilisée, ou la règle réaliste la plus simple à laquelle nous comparons le nouveau système, s'appelle la référence de comparaison ou « la référence initiale ». Cette référence peut être l'examen d'un expert, la moyenne des saisons précédentes, un calendrier d'irrigation calé localement, ou un système plus ancien déjà en service. La question n'est pas de savoir si le modèle a surpassé le néant, mais : A-t-il apporté une valeur au-delà de la méthode réaliste déjà disponible, et cette valeur vaut-elle le coût de son utilisation ? Le test devrait aussi ressembler aux conditions réelles d'usage. Si des images de la même plante, ou des images consécutives très similaires, entrent à la fois dans les données d'entraînement et dans les données de test, le résultat peut paraître excellent parce que le modèle a en pratique déjà vu quelque chose de semblable au test. C'est une forme de fuite de données : des informations ou des exemples étroitement liés parviennent à l'ensemble de test alors qu'ils auraient dû en rester séparés. Il est également nécessaire de distinguer trois types d'éléments de preuve :

1. Les éléments de preuve de la performance du modèle :

Ils montrent que le modèle a bien classé des images ou bien prédit des valeurs dans un test déterminé.

2. Les éléments de preuve de la performance du système :

Ils montrent que la collecte des données, les contrôles de qualité, l'analyse, la présentation du résultat, la communication et la mise en œuvre fonctionnent ensemble dans des conditions réelles.

3. Les éléments de preuve de l'impact agricole :

Ils montrent que l'usage du système a conduit à une meilleure décision, réduit un préjudice, préservé une ressource ou amélioré un résultat sur l'exploitation.

Et le premier type n'établit pas automatiquement les deux autres. La prédiction peut être correcte, mais l'alerte arriver en retard. Ou elle peut arriver à temps, mais l'utilisateur ne dispose pas de la ressource nécessaire pour exécuter la recommandation. Et la décision peut être exécutée, mais son effet différer en raison d'un facteur que le système n'a pas pris en compte. Quatrièmement — Que se passe-t-il lorsque le système ne sait pas, ou lorsqu'il défaille ? Un système responsable ne se comporte pas comme si tous les cas étaient familiers, toutes les données complètes et tous les appareils toujours fonctionnels. Nous devons donc demander :

• Indique-t-il clairement que les éléments de preuve sont insuffisants lorsque le cas est ambigu ?
• Fournit-il une fourchette ou un degré de confiance au lieu d'un chiffre définitif ?
• Peut-il demander des informations supplémentaires ?
• Peut-il s'abstenir de poser un diagnostic ou d'émettre une recommandation lorsqu'il manque de fondements suffisants ?
• Que fait-il si le capteur, la connexion ou l'alimentation électrique est coupé ?
• Bascule-t-il vers un mode sûr, ou continue-t-il sur la base de données anciennes ?
• Qui examine les cas non résolus ?
• Qui a le pouvoir d'interrompre la mise en œuvre ou de la contremander ?
• Comment l'équipe détecte-t-elle que la performance s'est dégradée après l'achat ou le déploiement ?
• Qui approuve les mises à jour et les nouvelles versions ?

L'incertitude signifie que les éléments de preuve n'étayent pas tous les résultats avec la même force. L'image peut être nette et semblable à celles dont le modèle a appris, ou elle peut être incomplète et représenter un cas qu'il n'a jamais vu. Les capteurs peuvent concorder, ou leurs relevés se contredire. Quant à l'abstention, elle signifie que le système ne se force pas à rendre un jugement lorsque les éléments de preuve ne le permettent pas. Il peut dire : « Les données actuelles sont insuffisantes pour déterminer l'état en toute sécurité. Envoyez une image supplémentaire, inspectez le capteur, ou renvoyez le cas à un spécialiste. » Ce n'est pas un signe de faiblesse si l'on y recourt au bon endroit. Une réponse qui énonce ses limites et indique l'étape suivante peut être plus utile qu'une réponse définitive non étayée par des éléments de preuve suffisants. Mais l'abstention exige aussi un équilibre. Un système qui s'abstient dans la plupart des cas peut être de peu d'utilité, et un système qui ne s'abstient jamais peut être dangereux. Ce qu'il faut, c'est préciser les cas où il doit répondre, les cas où il doit demander des informations supplémentaires, et les cas où l'autorité passe à un être humain qualifié. Lorsque les données ou la connexion font défaut, il ne suffit pas que le manuel technique indique que le système « prend en charge le fonctionnement hors ligne ». Nous devons savoir ce qui reste réellement disponible, quand les données ont été mises à jour pour la dernière fois, si l'utilisateur peut distinguer un relevé en direct d'un relevé ancien, et comment revenir à un mode de fonctionnement manuel sûr. Ces questions ne s'opposent pas à l'innovation Les questions ci-dessus peuvent paraître nombreuses, mais elles ne visent pas à entraver la technologie ni à la rejeter. Elles aident à faire passer l'innovation d'une démonstration enthousiasmante à un outil auquel on peut se fier, que l'on peut utiliser et que l'on peut réexaminer. Une technologie mûre peut expliquer :

• La tâche qu'elle accomplit.
• Les données sur lesquelles elle s'appuie.
• Les conditions dans lesquelles elle a été testée.
• Les types d'erreurs qu'elle commet.
• Les limites du résultat qu'elle produit.
• Ce qui se passe lorsque des données manquent ou que le matériel défaille.
• Qui détient la décision finale.
• Comment la performance est surveillée une fois l'usage commencé.

Mais une technologie qui dissimule ces questions derrière le nom d'un modèle célèbre, un pourcentage général ou une interface éblouissante manque encore de maturité, si fluide que soit sa présentation. La confiance ne naît pas de l'absence de questions, mais de la capacité du système et de la partie qui en est responsable à y répondre avec des éléments de preuve clairs.

Résumé du chapitre

Il n'existe pas de méthode unique qui soit la meilleure pour tous les problèmes agricoles, et les méthodes d'IA ne progressent pas non plus le long d'une échelle qui s'achèverait nécessairement par le modèle le plus grand ou le plus récent. Chaque méthode a un type de question qu'elle traite bien, un type de données dont elle a besoin, et des limites qu'il convient de comprendre. Ce que le chapitre a présenté peut être organisé selon la fonction que la méthode remplit. Les méthodes qui apprennent à partir d'exemples aux résultats connus Dans l'apprentissage supervisé, le modèle apprend la relation entre l'entrée et le résultat de référence qui lui est associé. Les entrées peuvent être des images de feuilles, et les résultats de référence des états confirmés par un spécialiste. Ou bien les entrées peuvent être des données météorologiques, pédologiques et de conduite, et les résultats de référence des valeurs de rendement mesurées après récolte. La force de cette méthode est qu'elle utilise des exemples antérieurs pour prédire un résultat nouveau. Sa limite fondamentale est qu'elle apprend de la manière dont ces exemples ont été construits, y compris de leurs erreurs, de leurs biais et de l'étroitesse de leur représentation. Quant à l'apprentissage semi-supervisé, il s'appuie sur un nombre limité d'exemples examinés par un spécialiste, aux côtés d'un nombre plus important d'images ou d'enregistrements dont les résultats n'ont pas encore été déterminés. Cela peut réduire la charge de revue, mais ne compense pas la faiblesse des exemples documentés ni le manque de diversité entre eux. Les méthodes qui recherchent des motifs sans réponse toute prête pour chaque exemple Dans l'apprentissage non supervisé, le système recherche des similitudes et des différences au sein des données. Il peut diviser la parcelle en zones d'humidité ou de rendement semblables, ou détecter des enregistrements qui s'écartent du motif habituel. Mais un groupe découvert par le système n'est pas, en soi, un diagnostic agricole. Deux zones peuvent être computationnellement semblables pour des raisons différentes. Le rôle de l'algorithme est de révéler un motif qui mérite examen ; l'interprétation de la cause exige un contexte de terrain, une inspection et une expertise. La détection d'anomalies relève de ce domaine dans de nombreuses applications. Le système peut attirer l'attention sur un capteur qui commence à dériver, sur un animal dont l'activité a changé, ou sur une consommation d'eau sortie de la plage habituelle. Mais il n'établit pas automatiquement qu'une maladie ou une panne est survenue. Les méthodes qui analysent les images et l'évolution dans le temps La vision par ordinateur utilise une image ou une vidéo pour classer un état, déterminer la position d'un objet, délimiter les contours d'une zone atteinte, ou suivre un objet à travers des images successives. Mais voir une tache ne signifie pas en connaître la cause, et localiser une adventice ne signifie pas que la machine peut l'éliminer en toute sécurité. Une sortie de vision peut être l'entrée d'une étape ultérieure d'inférence ou de commande, plutôt qu'une décision complète. Quant aux méthodes qui analysent l'évolution dans le temps, elles examinent des séquences de relevés : comment l'humidité a-t-elle changé ? L'activité de l'animal augmente-t-elle ou diminue-t-elle ? Quelle est la tendance attendue du rendement ou de la demande en eau ? Ces méthodes exigent d'être attentif à la saisonnalité, aux conditions changeantes, aux lacunes de mesure, et à la nécessité de ne pas supposer qu'un motif passé se poursuivra toujours. Les méthodes qui représentent la probabilité et séparent la prédiction de l'effet d'une intervention Les modèles probabilistes aident à exprimer l'incertitude plutôt qu'à la dissimuler. Ils peuvent classer plusieurs explications possibles, présenter une fourchette de rendement attendu, ou mettre à jour leurs probabilités lorsque de nouvelles informations arrivent. Mais une probabilité n'est pas utile du seul fait qu'elle apparaît sous forme de pourcentage ; il faut tester la fiabilité des scores de confiance, et montrer si le cas ressemble aux environnements dans lesquels le système a été testé. Quant à l'inférence causale, elle aborde une question plus difficile que la prédiction. La prédiction demande : « Que s'attend-on à voir se produire ? » tandis que la question causale demande : « Qu'est-ce qui devrait changer si nous intervenons ? » Un modèle peut réussir à prédire le rendement à partir de données de sol et de conduite sans établir qu'augmenter l'un des intrants élèvera le rendement. Passer de l'observation d'une relation à la recommandation d'une intervention exige des éléments de preuve plus solides, une conception appropriée, des connaissances agronomiques, ainsi que des limites environnementales et réglementaires. Les méthodes qui comparent des solutions de remplacement ou traitent des actions séquentielles La planification et l'optimisation mathématiques aident à répartir les ressources et à arbitrer entre des plans sous des contraintes claires. Elles peuvent distribuer une quantité limitée d'eau entre plusieurs secteurs en tenant compte du stade de développement, de la capacité de la pompe, de l'énergie et des horaires d'exploitation. Mais le plan obtenu reflète l'objectif et les contraintes que le concepteur a spécifiés. Si l'objectif néglige la santé des plantes ou l'équité entre secteurs, l'outil peut produire un plan computationnellement réussi mais agronomiquement inacceptable. Quant à l'apprentissage par renforcement, il traite d'une séquence d'actions qui modifient l'état de l'environnement. Le système peut choisir une action, en observer le résultat, puis ajuster ses choix pour améliorer un objectif de long terme. Toutefois, ce type d'apprentissage exige d'explorer les résultats des actions, et le système ne doit pas essayer des actions dangereuses au champ pour apprendre qu'elles ne sont pas sûres. Il requiert donc de la simulation, des essais progressifs, des contraintes de sécurité explicites, et une autorité humaine capable de l'arrêter. Les méthodes qui ouvrent la voie au dialogue avec la connaissance Les modèles de langage peuvent résumer des textes, les traduire, en extraire des informations et formuler une réponse en langage naturel. Ils facilitent l'accès à la connaissance, car l'agriculteur peut poser sa question dans sa propre langue au lieu de naviguer dans des menus complexes. Mais la fluidité d'une réponse ne prouve pas son exactitude. Un modèle peut produire un énoncé persuasif sans appui suffisant. C'est pourquoi il peut être relié à une chaîne de traitement qui interroge des sources faisant autorité et récupère les passages pertinents avant de formuler la réponse. La récupération ne garantit pas automatiquement l'exactitude de la réponse ; le système peut trouver une source correcte qui reste néanmoins inadaptée à la culture, au pays ou à la date. La réponse doit distinguer entre ce qui figure dans la source, ce que le système a inféré, et ce qui requiert le jugement d'un spécialiste. Les outils qui nous aident à examiner le résultat Les outils d'intelligence artificielle explicable tentent de montrer ce qui a influencé le résultat du modèle : des parties de l'image, des relevés associés à la prédiction, des exemples similaires, ou un changement qui aurait pu modifier la sortie du modèle. Ces outils peuvent aider le développeur à découvrir une erreur, ou aider le spécialiste à réexaminer un résultat. Mais ils expliquent ce que le modèle a utilisé, et n'établissent pas nécessairement ce qui a causé le phénomène au champ. Une explication persuasive ne transforme pas un résultat incorrect en résultat correct, et ne compense pas la faiblesse des données ni l'absence de tests externes. La méthode fait partie d'une chaîne plus vaste Aucune de ces méthodes n'opère dans le vide. Le système agricole passe généralement par une chaîne qui commence par la réalité et s'achève par un nouvel effet sur elle : Réalité du terrain → mesure, image ou enregistrement → contrôle de la qualité des données → estimation ou prédiction → règles et contexte → décision → mise en œuvre → impact agricole → suivi La chaîne peut se rompre à n'importe quel maillon :

• Le capteur peut produire un relevé incorrect ou exprimé dans une unité inattendue.
• Une image peut être associée à un résultat de référence inexact.
• Des images de la même plante peuvent se retrouver à la fois dans l'entraînement et dans le test, ce qui fait paraître le résultat meilleur que la capacité réelle de généralisation.
• Le modèle peut apprendre à partir d'un environnement qui ne ressemble pas à l'exploitation dans laquelle il fonctionnera.
• La prédiction peut être correcte, mais la règle de décision peut en traduire le sens de manière erronée.
• Un objectif computationnel peut être choisi qui néglige une contrainte agricole ou environnementale.
• Le système peut récupérer une source qui ne concerne ni la culture ni la région.
• La réponse langagière peut paraître plus fiable que les éléments de preuve sur lesquels elle repose.
• L'alerte peut arriver après que la fenêtre d'intervention est passée.
• La commande correcte peut être émise, mais l'équipement peut ne pas l'exécuter.
• L'utilisateur peut ne pas disposer des ressources ou de l'autorité nécessaires pour appliquer la recommandation.
• La réalité peut changer avec le temps tandis que le système poursuit comme si les conditions n'avaient pas changé.

C'est pourquoi comparer deux algorithmes ne suffit pas toujours. La différence entre eux peut être faible, alors que les effets de la qualité des capteurs, de la clarté de l'interface, de la sécurité de la mise en œuvre ou de la capacité de réaction de l'équipe peuvent être bien plus importants. Le contrat qui relie la technologie à la décision Le message du chapitre peut se résumer par l'énoncé suivant : La méthode technique fait partie d'un contrat clair reliant la question, les données, la sortie, l'action et la responsabilité. Ce que l'on entend par là n'est pas un contrat juridique, mais un accord intellectuel et pratique dont les termes doivent être clairs :

1. Question : Quel problème précis cherchons-nous à résoudre ?
2. Données : Quels éléments de preuve nous permettent d'y répondre, et quelles sont les limites de leur qualité et de leur représentativité ?
3. Sortie : Que produira le système, dans quelles unités, et avec quel degré de confiance ?
4. Erreur : Comment peut-il échouer, et quelle erreur serait la plus dommageable ?
5. Action : Quelle décision ou quelle action pourrait se fonder sur cette sortie ?
6. Responsabilité : Qui examine, approuve, met en œuvre, interrompt et surveille l'impact ?

Si l'algorithme est choisi avant que ces points ne soient compris, il devient un nom technique en quête d'un problème. Mais si la conception commence par la décision requise, les données disponibles, les conséquences de l'erreur, la base de comparaison réaliste et les contraintes d'exploitation, alors l'algorithme peut devenir un outil précis au sein d'un système plus vaste que des humains dirigent, examinent et tiennent pour responsable. Une compréhension réelle de l'intelligence artificielle agricole ne commence pas lorsque nous mémorisons les noms des modèles, mais lorsque nous pouvons demander :

• Qu'a réellement vu le système ?
• Qu'en a-t-il inféré ?
• Que lui était-il impossible de savoir ?
• Quels éléments de preuve étayent le résultat ?
• À quelle action va-t-il conduire ?
• Qui porte la responsabilité de cette action ?
• Que se passe-t-il si le résultat est erroné ?

Nous tirons profit de la rapidité de l'intelligence artificielle lorsque la tâche est claire, les données appropriées et les limites explicites. Nous nous arrêtons pour chercher une mesure, une source ou un spécialiste lorsque le résultat dépasse ce que les éléments de preuve peuvent établir. Synthèse : Ne demandez pas seulement : « Ce système est-il intelligent ? » Demandez plutôt : « Que sait-il, comment en est-il venu à le savoir, que ne sait-il pas, et que se passera-t-il au champ si nous lui faisons confiance ? »

Notes sur les éléments de preuve et les limites de la confiance à leur accorder

Les deux revues [SRC001] et [SRC002] étayent l'exposé général de l'étendue des applications de l'intelligence artificielle et de la vision par ordinateur dans les domaines agricole et alimentaire, sans impliquer que chaque application convienne à toutes les cultures et à tous les environnements. [SRC035] conforte le fait de considérer le système agricole numérique comme une chaîne interconnectée qui comprend la détection, les données, le contexte, la décision et l'action, ce qui justifie d'évaluer le système dans son ensemble plutôt que de se fier à la seule sortie du modèle. [SRC006] est utilisé comme exemple circonscrit de prédiction du rendement et d'emploi d'outils d'interprétabilité dans un cadre de recherche précis. Le classement des facteurs ou les conclusions issues de ce cadre ne doivent pas être transformés en relations causales générales ni en faits valables pour toute parcelle. [SRC009] est utilisé pour corriger l'attribution de la technologie de détection des adventices : il porte sur l'analyse d'images de champs de soja au moyen de méthodes de vision convolutives, et il n'établit pas l'existence d'un système robotisé d'élimination fondé sur l'apprentissage par renforcement. Cette correction aide à distinguer entre voir un objet dans une image et commander une machine qui interagit avec lui. La présentation des risques, de la supervision et de la revue continue tout au long du cycle de vie du système s'appuie sur le cadre cité en [SRC033]. Quant au cas pédagogique intégré, au guide reliant la tâche à la méthode, aux questions pratiques et aux exemples de terrain présentés dans le chapitre, ils constituent une synthèse éditoriale à visée didactique destinée à clarifier les distinctions entre mesure, analyse, décision et mise en œuvre. Ces exemples ne représentent ni les résultats d'une nouvelle expérience, ni la preuve de la performance d'un système particulier, ni un diagnostic agricole, ni une prescription pour le traitement d'une culture.