Chapitre deux : que signifie la transformation agricole ?

Chapitre deux : que signifie la transformation agricole ?

Le message du chapitre : toute mise à niveau technique n'est pas une transformation

La transformation agricole ne commence pas à l'écran ; elle commence par le résultat qui change au champ et dans la vie de ceux qui le travaillent. Introduire une application à la ferme, faire passer les registres du papier à une base de données ou déléguer davantage de décisions à la machine peut constituer une numérisation utile ou une amélioration opérationnelle importante ; mais cela ne devient pas une transformation du seul fait que l'outil est moderne. La transformation agricole digne de ce nom est un changement organisé et durable dans la manière dont les décisions sont prises, les ressources allouées et le travail accompli, conduisant à un effet de valeur qui peut être mesuré et comparé : accroître la productivité, réduire les pertes et les risques, améliorer la qualité des cultures, le revenu de l'agriculteur et la sécurité des travailleurs, ou augmenter la capacité de l'exploitation à supporter la volatilité. Il ne suffit pas que le résultat s'améliore lors d'un essai passager ; il faut savoir ce qui a changé, dans quelle mesure, en comparaison de quoi, pour qui le bénéfice s'est matérialisé, à combien s'est élevé son coût total, et qui a supporté les risques et les effets non voulus. La transformation responsable ne dépouille pas les êtres humains de leur autorité au nom de l'efficacité. Elle préserve la capacité de l'agriculteur, du travailleur et de l'institution à comprendre la base sur laquelle une recommandation a été construite, à la réexaminer, à intervenir dans son cours et à passer outre lorsque cela est nécessaire ; ainsi qu'à conserver les données, à les transférer et à remplacer le système ou à le quitter sans dépendance technologique ni perte du savoir accumulé. Une technologie qui rend une décision plus rapide, tout en la rendant moins comprise ou plus dépendante, peut changer la forme du travail sans en élever la substance. Dès lors, tout discours sur la transformation qui ne répond pas clairement à six questions — Quel résultat a changé ? Pour qui ? Sur quelles preuves ? Par rapport à quelle situation de référence ? À quel coût et à quel risque ? Et qui détient le droit de comprendre, d'intervenir et de sortir ? — demeure une description de ce que la technologie est capable de faire, non la preuve qu'une transformation agricole a eu lieu. La transformation ne se mesure pas au nombre d'écrans et d'algorithmes, mais à ce qu'elle ajoute à la capacité humaine de prendre une meilleure décision, et à l'effet qu'elle laisse sur la terre, le travail et l'institution — un effet qui peut être démontré, défendu et maintenu dans la durée. La transformation agricole ne commence pas à l'écran, et elle ne se mesure pas au nombre d'applications et d'appareils qui entrent dans l'exploitation ; elle commence par le résultat qui change effectivement au champ et dans la vie de ceux qui le travaillent. Introduire une application numérique, transférer des registres papier dans une base de données ou déléguer certaines décisions à la machine peut être une étape utile de la numérisation, ou une amélioration importante de l'efficacité opérationnelle. Pourtant, la nouveauté de l'outil, si grande soit-elle, ne suffit pas à elle seule à établir qu'une transformation a eu lieu. La transformation agricole, au sens strict, est un changement organisé et durable dans la manière dont les décisions sont prises, les ressources allouées et le travail accompli, conduisant à un effet de valeur qui peut être mesuré et comparé. Cet effet peut prendre la forme d'une hausse de la productivité de l'eau, d'une réduction des pertes et des risques, d'une amélioration de la qualité des cultures, du revenu de l'agriculteur et de la sécurité des travailleurs, ou d'un renforcement de la capacité de l'exploitation à supporter la volatilité. Mais une amélioration temporaire dans un essai limité ne suffit pas à déclarer une transformation réussie. Il est essentiel de préciser ce qui a changé, l'ampleur de ce changement et la référence initiale à laquelle le résultat a été comparé. Il est de même nécessaire de clarifier qui a bénéficié de la transformation, quel en a été le coût total, qui en a supporté les risques et quels effets non voulus l'ont accompagnée. La valeur ne se mesure pas à la seule ampleur du bénéfice, mais aussi à sa répartition et au prix économique, opérationnel et humain payé pour l'obtenir. Une transformation qui préserve l'autorité humaine La transformation responsable ne dépouille pas les êtres humains de leur autorité au nom de la rapidité ou de l'efficacité. Elle préserve au contraire la capacité de l'agriculteur, du travailleur et de l'institution à comprendre la base sur laquelle une recommandation a été construite, à la réexaminer, à intervenir dans son cours et à passer outre lorsque cela est nécessaire. Une décision agricole ne devient pas meilleure du seul fait qu'elle est plus rapide ou automatisée ; elle devient meilleure lorsqu'elle est plus exacte, plus claire, plus redevable et plus applicable. La transformation véritable ne se mesure donc pas au nombre d'écrans, de capteurs et d'algorithmes, mais à ce que la technologie ajoute à la capacité humaine de prendre une meilleure décision. Elle se mesure également à l'effet qu'elle laisse sur la terre, le travail et l'institution — un effet qui peut être démontré, dont la valeur peut être défendue, et qui peut être maintenu dans la durée. Alors seulement la technologie passe du statut d'outil moderne à celui de force de transformation responsable et durable.

1. De la numérisation de la procédure à la refonte de la décision

Une exploitation peut numériser son registre de pulvérisation, remplaçant un carnet par un formulaire électronique, sans aucun changement dans le moment, la précision ou la sécurité de la pulvérisation. Elle peut ajouter un capteur qui transmet des milliers de relevés alors qu'aucune règle n'existe pour les interpréter et que personne n'est responsable d'y répondre. Dans les deux cas, la numérisation a eu lieu et la transformation n'a pas nécessairement eu lieu.

La transformation commence lorsque l'ensemble du parcours est repensé de bout en bout : le besoin est défini, les données minimales suffisantes sont collectées, les solutions de rechange sont comparées, l'alerte parvient à une personne détenant l'autorité d'agir, le résultat est mesuré, et l'erreur sert à améliorer le tour suivant. L'intelligence artificielle peut être une part importante de ce parcours, mais elle ne compense pas l'absence de responsabilité ou de possibilité de mise en œuvre. Les articles de synthèse scientifique récents dans le domaine de l'intelligence artificielle agricole et alimentaire agrègent les résultats d'un grand nombre d'études publiées et en tirent une image à double face du paysage. D'une part, ils documentent des usages prometteurs dans le suivi des cultures et des animaux, la détection précoce des maladies et des stress, la prévision des rendements et des risques, l'amélioration du calendrier d'irrigation et de fertilisation, et l'augmentation de l'efficacité de l'utilisation des ressources. D'autre part, ils révèlent que ces capacités se heurtent fréquemment aux coûts d'acquisition et d'exploitation, à une qualité ou une représentativité insuffisante des données, à des déficits de connectivité, d'infrastructures et de compétences, et à la difficulté de transférer un modèle d'une culture, d'une région ou d'une saison à une autre — ainsi qu'à des risques de biais, d'interprétabilité faible et de confiance excessive dans les recommandations automatisées [SRC001][SRC002][SRC003]. Ces synthèses offrent une carte générale de ce que la littérature a montré, mais elles ne prouvent pas que chaque bénéfice se matérialisera dans chaque exploitation ou dans toutes les conditions.

Cette image ne nous conduit pas non plus à la formule familière : « la technologie est bonne, mais elle rencontre quelques difficultés », car les difficultés dont il s'agit ici ne sont pas des marges externes que l'on pourrait renvoyer à après la construction du système. La qualité des données, le coût d'exploitation, la capacité de l'utilisateur à comprendre, la présence d'une personne ayant autorité pour répondre et la disponibilité d'une intervention juridique et économique au bon moment font toutes partie de la performance propre du système. Un modèle qui prédit avec exactitude alors que personne ne peut convertir sa prédiction en action ne réalise aucune transformation ; il produit une information qui risque de rester suspendue entre l'écran et le champ. Pour cette raison, la capacité technique et la préparation institutionnelle devraient être considérées comme deux maillons d'une même chaîne de valeur. La performance technique détermine ce que le système est capable de voir ou d'anticiper ; la préparation institutionnelle détermine si cette anticipation peut être convertie en une décision sûre, réalisable et rentable. Si l'un des deux maillons se rompt, le bénéfice diminue ou disparaît, si avancée que puisse paraître l'autre partie. Un algorithme peut donner à une institution un œil qui voit plus loin, mais il ne lui donne pas automatiquement une main capable d'intervenir, ni un budget de mise en œuvre, ni une loi autorisant l'acte, ni la confiance qui fait que l'utilisateur l'écoute. Ainsi, la bonne question n'est pas : La technologie est-elle bonne ? mais plutôt : Cette technologie, à ce niveau d'exactitude et dans cet environnement institutionnel et économique, peut-elle changer une décision précise et un résultat mesurable, sans reporter le coût ou le risque sur la partie la plus faible ? Ce n'est qu'une fois cette question résolue que la technologie passe d'une possibilité exposée dans les études à une transformation défendable dans la réalité.

2. Six dimensions pour juger si une transformation a eu lieu

Établir que la technologie fonctionne ne suffit pas pour dire qu'une transformation agricole a été accomplie. La transformation ne se mesure pas à la seule performance de l'algorithme, mais à ce qui a changé dans le résultat agricole, la résilience de l'exploitation, l'usage des ressources, la viabilité économique, les conditions de travail et l'indépendance des décideurs. Les six dimensions suivantes fournissent un cadre pour éprouver ce changement, avec des indicateurs choisis en fonction de la culture, du lieu et de la décision évaluée, et avec une situation de référence clairement définie pour la comparaison.

Ces dimensions ne sont pas six tests séparés, et il n'est pas exigé de chaque projet qu'il atteigne l'amélioration maximale dans toutes. Mais elles empêchent qu'un indicateur unique monopolise le jugement ; chaque indicateur éclaire un angle, et peut laisser le reste de la scène dans l'ombre. Un système peut accroître le rendement tout en augmentant la consommation d'énergie ou la dépendance à des intrants coûteux. Il peut réduire le travail manuel dangereux tout en déplaçant la charge vers une surveillance numérique épuisante, ou en évinçant des travailleurs à qui aucune possibilité de passer à de nouveaux rôles n'a été offerte. Il peut améliorer le résultat en moyenne, tandis que les erreurs et les pertes s'accumulent chez les petits exploitants ou dans un groupe moins capable de les absorber.

L'évaluation responsable ne s'arrête donc pas à la question : « Un indicateur s'est-il amélioré ? » Elle demande aussi : Qu'a-t-on obtenu dans les autres dimensions, qui en a bénéficié, qui en a payé le prix, et l'arbitrage a-t-il été divulgué, mesuré et susceptible de correction ? La transformation véritable ne prétend pas que les arbitrages ont disparu ; elle les fait sortir de l'ombre, les mesure, leur fixe des limites et des garde-fous, puis décide sur la base du tableau complet.

C'est alors que se dégage clairement la différence entre numériser la procédure et refondre la décision : la numérisation peut remplacer le papier par un écran, tandis que la transformation reconstruit la route qui va de l'information à l'action, et de l'action au résultat, puis tient cette route tout entière comptable de ce qu'elle a apporté à la terre, à l'être humain et à l'institution — et non de la nouveauté de l'outil placé à son point de départ.

3. La productivité n'est pas l'efficacité, et l'efficacité seule ne crée pas la durabilité

Les parcelles peuvent paraître plus verdoyantes, les rendements peuvent augmenter et le volume d'eau utilisé pour produire chaque tonne peut diminuer — sans que l'exploitation devienne pour autant plus rentable ou plus durable. Les chiffres peuvent annoncer un succès sur une dimension tout en dissimulant un coût plus élevé, une pression accrue sur les ressources ou une fragilité qui se révèle dès la première saison difficile. C'est pourquoi il nous faut distinguer cinq notions qui se confondent dans le discours courant alors qu'elles répondent à des questions entièrement différentes :

• Production : Quelle quantité est sortie du système ? Tonnes de céréales, litres de lait ou volume de fruits commercialisables.
• Productivité : Quelle production rapportée à un intrant déterminé ? Par exemple, des tonnes par hectare, des kilogrammes de récolte par mètre cube d'eau ou la valeur de la production par heure de travail.
• Efficacité : Le même résultat aurait-il pu être obtenu avec moins de ressources, ou un meilleur résultat avec les mêmes ressources, compte tenu des contraintes réelles de l'exploitation ?
• Rentabilité : Le revenu a-t-il dépassé l'ensemble des coûts associés à la production, y compris le financement, l'exploitation, la maintenance et la formation ?
• Durabilité : Cette performance peut-elle se maintenir dans la durée sans épuiser le sol et l'eau, sans affaiblir la capacité économique de l'exploitation, ni transférer le coût sur les travailleurs, la communauté et les générations futures ?

Ces distinctions ne sont pas de simples nuances de langage ; elles constituent le fondement du jugement professionnel porté sur tout projet agricole ou investissement technologique. Une hausse du rendement par hectare ne prouve pas, à elle seule, que l'exploitation est devenue plus efficace, plus rentable ou plus durable. Le rendement peut augmenter grâce à davantage d'irrigation, d'engrais, d'énergie et de main-d'œuvre, de sorte que la production croît tandis que le coût de production d'une unité augmente, ou que la pression sur l'eau s'intensifie, ou encore que la dégradation des sols s'accélère. La productivité de l'eau peut s'améliorer — c'est-à-dire que la quantité de récolte produite à partir de chaque mètre cube augmente — alors que le prélèvement total sur la ressource en eau s'élève du fait de l'extension de la surface irriguée. Les heures de travail manuel peuvent diminuer grâce à une machine intelligente, tandis que les coûts de financement, d'énergie et de maintenance augmentent et que l'exploitation devient plus dépendante d'un fournisseur unique dont les pièces détachées ne sont pas disponibles localement. Un indicateur isolé éclaire une partie de la scène ; une prise de décision solide, en revanche, exige de voir le tableau d'ensemble. Quand l'efficacité de l'irrigation s'améliore… et que la consommation d'eau augmente Supposons, pour les besoins d'un calcul détaillé, une exploitation de cent hectares, où chaque hectare consomme cinq mille mètres cubes d'eau et produit six tonnes de récolte. La situation avant l'installation du système d'irrigation de précision

• Surface irriguée : 100 hectares
• Consommation d'eau par hectare : 5000 mètres cubes
• Rendement : 6 tonnes par hectare
• Prélèvement total d'eau : 500 mille mètres cubes
• Productivité de l'eau (quantité de récolte ou valeur économique obtenue pour chaque unité d'eau utilisée) : environ 1,2 kilogramme de récolte par mètre cube

Après l'installation d'un système automatisé d'irrigation de précision, la consommation d'eau est tombée à 4500 mètres cubes par hectare, et le rendement est monté à 6,3 tonnes par hectare. La situation après l'amélioration de l'irrigation

• Consommation d'eau par hectare : 4500 mètres cubes
• Rendement : 6,3 tonnes par hectare
• Productivité de l'eau : environ 1,4 kilogramme par mètre cube

Du point de vue de l'hectare pris isolément, le résultat paraît excellent : moins d'eau et un rendement plus élevé. Mais que se passe-t-il si les économies réalisées incitent l'exploitation à étendre la surface irriguée de 100 hectares à 130 hectares ? Le prélèvement total devient alors : 130 hectares × 4500 mètres cubes = 585 mille mètres cubes Ainsi, l'efficacité de l'utilisation de l'eau s'est améliorée à la fois par hectare et par kilogramme produit, et pourtant le prélèvement total sur la ressource en eau est passé de 500 mille à 585 mille mètres cubes — soit une hausse de près de 17 %. Remarque : productivité de l'eau = quantité de récolte ÷ quantité d'eau utilisée (le plus souvent mesurée dans l'unité : kilogrammes de récolte par mètre cube d'eau) Qu'est-ce que cela signifie pour l'agriculteur et l'ingénieur agronome ? Cela ne signifie pas que la technologie d'irrigation a échoué. Elle a bel et bien réussi à rendre l'usage de l'eau plus précis et à améliorer la productivité de chaque mètre cube. Mais l'indicateur d'efficacité partielle (une mesure qui évalue un seul aspect de la performance en comparant la production à une ressource déterminée, sans englober l'ensemble des ressources, des coûts et des conséquences qu'implique le procédé) n'a pas suffi à juger du résultat global. Si l'objectif est de protéger la réserve en eau, il ne suffit pas de mesurer l'eau utilisée par tonne ; il faut aussi mesurer :

• Le prélèvement total sur la ressource en eau.
• L'ampleur de l'extension de la surface irriguée.
• Le volume d'eau qui est effectivement resté dans le bassin.
• Le degré de respect d'un plafond clair de consommation.

La technologie peut améliorer la précision de l'irrigation, mais elle ne décide pas à elle seule du sort de l'eau économisée : restera-t-elle dans le bassin, ou servira-t-elle à irriguer une surface supplémentaire ? Conclusion : Une baisse de la consommation d'eau par hectare ne signifie pas nécessairement une baisse de la consommation totale d'eau à l'échelle de l'exploitation ou du bassin hydrographique. Quand le rendement augmente… et que le bénéfice net n'augmente pas Supposons qu'un système de fertilisation à taux variable ait accru le rendement d'une demi-tonne par hectare. Il s'agit là d'un gain de productivité manifeste, et à première vue cela peut sembler une preuve suffisante de la réussite de l'investissement. Mais le jugement économique ne s'arrête pas à la quantité de récolte supplémentaire ; il commence par la question suivante : La valeur de la récolte supplémentaire a-t-elle dépassé l'ensemble des coûts nécessaires pour l'obtenir ? Ces coûts comprennent, selon le système utilisé :

• La préparation des cartes et des analyses.
• L'achat des capteurs et des équipements.
• Les frais d'abonnement et de logiciel.
• La connectivité et la transmission des données.
• La formation du personnel.
• La maintenance des équipements.
• Les coûts de financement.

Si la valeur de l'augmentation de la récolte est inférieure à la somme de ces coûts, alors la productivité a augmenté, mais pas le bénéfice net. Et le résultat peut différer considérablement entre deux exploitations utilisant la même technologie. Une grande exploitation peut répartir le coût fixe de l'appareil et du logiciel sur des milliers d'hectares, tandis qu'une petite exploitation supporte un coût presque identique sur une surface limitée. La technologie peut donc être rentable sur la grande exploitation et économiquement non viable si une petite exploitation l'achète pour son propre compte.

Néanmoins, la technologie peut devenir adaptée à la petite exploitation si elle est utilisée par l'intermédiaire :

• D'une coopérative agricole.
• D'un service partagé entre plusieurs agriculteurs.
• D'un prestataire de services spécialisé.
• D'un contrat saisonnier plutôt que de l'achat et de la possession individuelle du matériel.

Il n'existe donc pas de « viabilité économique de la technologie » dans l'abstrait. Il existe une viabilité pour une technologie déterminée, sur une exploitation déterminée, dans un ensemble déterminé de prix, de financements, de compétences, de risques et de conditions d'exploitation. Conclusion : Une hausse du rendement est un gain de productivité, mais elle ne devient un gain économique que si sa valeur dépasse l'ensemble des coûts directs et indirects. Quand la productivité du travail s'améliore… et que le coût se déplace ailleurs Une machine automatisée de tri ou de désherbage peut accomplir un travail qui exigeait autrefois un grand nombre d'heures de travail manuel. Une telle machine peut représenter un gain important si elle réduit la pénibilité du travail ou diminue l'exposition aux pesticides et aux blessures. Mais le nombre d'heures de travail économisées ne révèle pas tout le tableau. Le travail ne disparaît pas nécessairement ; c'est plutôt sa forme qui change. Le besoin peut se déplacer du travail manuel vers :

• La surveillance de la performance de la machine.
• La maintenance des composants mécaniques et électroniques.
• La gestion des données.
• L'interprétation des alertes.
• Le traitement des pannes.

Les travailleurs peuvent tirer profit de ce déplacement s'ils bénéficient d'une formation et de la possibilité d'accéder à des emplois meilleurs et plus sûrs. À l'inverse, ils peuvent en supporter la perte si leurs emplois disparaissent sans solutions de remplacement ni possibilités de reconversion. La machine peut aussi être très efficace dans des conditions ordinaires, tout en se transformant en source de fragilité lorsqu'elle tombe en panne pendant une courte fenêtre de récolte, ou lorsque sa réparation exige un expert éloigné, ou encore lorsqu'elle ne peut être utilisée en cas de perte de connectivité. Dans de tels cas, la productivité du travail peut s'améliorer en moyenne, tandis que la souplesse opérationnelle, l'équité sociale ou la capacité de l'exploitation à travailler indépendamment du fournisseur se dégradent. C'est pourquoi la durabilité ne demande pas seulement combien d'heures ont disparu, mais aussi :

• Quel type de travail est resté ?
• Le travail est-il devenu plus sûr et de meilleure qualité ?
• Qui a bénéficié de la technologie ?
• Qui a perdu sa source de revenu ?
• Qui a supporté les risques de pannes et d'immobilisation ?
• L'exploitation peut-elle assurer localement la maintenance et l'exploitation du système ?

Conclusion : Une automatisation durable ne se contente pas de réduire le travail ; elle en améliore la qualité, en limite les risques et préserve la capacité de l'exploitation à continuer de fonctionner lorsque surviennent pannes et chocs. La durabilité n'est pas un ensemble d'indicateurs verts déconnectés les uns des autres Une technologie ne devient pas durable du seul fait qu'elle a économisé de l'eau lors d'un essai, ou réduit la quantité d'engrais utilisée par tonne, ou remplacé le carburant par une batterie. Un jugement environnemental complet exige d'abord de définir les limites du système évalué. Comptabilisons-nous uniquement le fonctionnement au champ ? Ou l'évaluation inclut-elle également :

• La fabrication des capteurs et des machines ?
• L'énergie de la connectivité et de la transmission des données ?
• L'informatique en nuage ?
• La fabrication et le remplacement des batteries ?
• Le transport et la maintenance ?
• Élimination des équipements et des déchets électroniques ?

Il convient également de distinguer la réduction du volume d'utilisation par unité produite de la réduction de l'utilisation totale des ressources. L'eau ou les engrais par tonne peuvent diminuer alors même que l'utilisation totale augmente, parce que la production s'est accrue ou que la surface cultivée s'est étendue. Un impact environnemental peut décliner au champ pour se déplacer vers un autre site ou vers une autre étape du cycle de vie de la technologie. Durabilité économique Un système peut être rentable les années où les prix des cultures sont élevés, tout en imposant à l'exploitation une charge d'endettement qu'elle ne pourra pas supporter lors d'une saison médiocre. La rentabilité ne doit donc pas être évaluée à partir d'une bonne saison ou d'une moyenne optimiste seulement ; il faut éprouver la capacité de l'investissement à résister à une baisse des prix ou à un recul de la production. Durabilité sociale Le revenu moyen d'un groupe d'agriculteurs peut augmenter tandis que les exploitants plus petits ou plus isolés ne peuvent pas assumer le coût de la connectivité et de la formation. Une technologie peut améliorer la prise de décision au champ tout en enfermant les données chez le fournisseur et en rendant coûteux le passage à un autre système. C'est pourquoi la durabilité ne se limite pas à la performance environnementale. Elle est la capacité d'un système agricole à se maintenir et à s'adapter sans épuiser ses ressources naturelles, économiques ou humaines, et sans que son bénéfice repose sur le transfert d'un préjudice à une partie moins en mesure de s'y opposer ou de négocier. La même technologie ne produit pas le même résultat sur toutes les exploitations Une revue des technologies d'agriculture de précision référencée dans [SRC036] montre que ces technologies présentent un potentiel économique et environnemental considérable, mais ne produisent pas un résultat unique et figé dans tous les contextes. La faisabilité varie selon de nombreux facteurs, parmi lesquels :

• La taille de l'exploitation.
• Le type de culture.
• Le coût du capital.
• Le coût de la connectivité et de la maintenance.
• La disponibilité des compétences et des services.
• La manière dont les coûts fixes sont répartis.
• La valeur économique de l'information ou de la décision que la technologie améliore.

En conséquence, un résultat positif ne peut être transposé d'une grande exploitation à forte intensité capitalistique à une petite exploitation à connectivité limitée, et le succès d'une technologie sur une culture ou dans une région ne saurait être tenu pour une garantie de son succès sur une autre culture ou dans un autre contexte. La bonne question n'est pas : Cette technologie est-elle un succès ? Mais plutôt : Pour qui réussit-elle, dans quelles conditions, à quel coût et à quel niveau de risque ? Commencer par le résultat recherché, non par la technologie disponible Avant d'acheter une technologie ou de collecter des données, un projet doit définir clairement le résultat central qu'il cherche à modifier. S'agit-il de :

• Augmenter la production commercialisable ?
• Réduire la variabilité de la production d'une saison à l'autre ?
• Abaisser la consommation totale d'eau ou d'énergie ?
• Réduire l'exposition à un pesticide dangereux ?
• Détecter une maladie assez tôt pour permettre une intervention ?
• Élargir l'accès des petits exploitants à une vulgarisation agricole fiable ?

Ce ne sont pas différentes formulations d'un même objectif ; ce sont des objectifs indépendants, et chacun d'eux comporte :

• Une situation de référence qui doit être mesurée avant l'intervention.
• Un indicateur de succès approprié.
• Un horizon temporel d'évaluation.
• Des coûts et des risques potentiels.
• Des arbitrages susceptibles d'apparaître avec d'autres objectifs.

Si l'objectif est de protéger la ressource en eau, une baisse de l'eau utilisée par tonne ne suffit pas tant que les prélèvements totaux ne diminuent pas. Si l'objectif est d'améliorer la rentabilité, une hausse du rendement ne suffit pas tant que le revenu net ne s'améliore pas, tous coûts pris en compte. Indicateurs de garde-fou : pour qu'un objectif ne soit pas atteint aux dépens d'un autre Définir un indicateur principal de succès ne suffit pas ; il faut également définir des indicateurs de garde-fou permettant de révéler si l'amélioration d'une dimension a entraîné la détérioration d'une autre. Si l'objectif est d'accroître le rendement Il convient de suivre :

• La consommation d'eau.
• La consommation d'énergie.
• La quantité d'intrants.
• Le bénéfice net.
• La qualité du sol.

Si l'objectif est de réduire le travail manuel Il convient de mesurer :

• La sécurité des travailleurs.
• La qualité des emplois restants.
• Les possibilités de formation.
• La répartition des bénéfices et des pertes.
• La capacité à faire fonctionner et à entretenir le système.

Si l'objectif est de réduire l'eau par tonne Il faut surveiller :

• Le prélèvement total sur la ressource en eau.
• L'extension de la surface irriguée.
• L'ampleur réelle de la réduction de la pression sur la ressource.

Si l'objectif est d'améliorer la rentabilité La rentabilité doit être éprouvée :

• Tous coûts pris en compte.
• Lors des saisons médiocres.
• Lorsque les prix ou la production baissent.
• Sous les charges réelles de financement et de maintenance.

Les indicateurs de garde-fou fonctionnent comme un tableau d'alerte précoce ; ils empêchent un projet de proclamer son succès sur un indicateur unique alors que d'autres résultats, non moins importants, se dégradent. Les critères de succès doivent être fixés avant que les résultats n'apparaissent Les indicateurs d'évaluation doivent être définis avant le début de l'essai ou la mise en œuvre du projet, et non après l'apparition des résultats. Choisir, une fois l'essai terminé, la mesure qui s'est améliorée et écarter celles qui se sont dégradées ne démontre pas le succès du projet ; cela revient à redessiner la cible autour de la flèche après qu'elle est retombée. Une évaluation professionnelle déclare à l'avance :

• Quel résultat sera considéré comme un succès ?
• À quelle situation de référence sera-t-il comparé ?
• Quelles limites ne doivent pas être franchies ?
• Pendant combien de temps la mesure se poursuivra-t-elle ?
• Qui en supporte le coût ?
• Qui en supporte le risque ?
• Que se passera-t-il si l'indicateur principal s'améliore alors qu'un autre résultat important se détériore ?

Ainsi, les indicateurs cessent d'être des instruments de justification d'une technologie pour devenir des instruments d'évaluation de sa valeur réelle. Des chiffres isolés à la décision intégrée Une hausse n'est pas toujours un progrès. Une économie par unité n'est pas toujours une économie globale. L'efficacité lors d'une saison calme n'est en rien une garantie de résilience face à un choc. La véritable transformation agricole commence lorsque nous demandons non seulement : Combien avons-nous produit ? mais aussi :

• Avec quelle quantité de ressources cette production a-t-elle été obtenue ?
• Quel est le coût par unité produite ?
• Le bénéfice net a-t-il réellement augmenté ?
• La consommation totale d'eau et d'énergie a-t-elle diminué ?
• Qui a bénéficié du changement ?
• Qui en a supporté le coût et les risques ?
• L'exploitation peut-elle maintenir cette performance lors d'une saison médiocre ?
• Et pendant combien de temps le gain peut-il se prolonger ?

C'est alors seulement que les chiffres deviennent des instruments de compréhension, de responsabilité et de décision, plutôt que des ornements conférant à une technologie le label de durabilité avant qu'elle n'ait fait ses preuves. Car l'agriculture de demain ne se mesure pas seulement à ce qu'elle produit aujourd'hui, mais à sa capacité à continuer de produire demain, sans consommer le socle naturel, économique et humain sur lequel repose cette production.

4. La résilience opérationnelle : que reste-t-il quand les choses ne se passent pas comme prévu ?

La résilience ne signifie pas qu'un système ne tombe jamais en panne ; aucun système ne fonctionne sans erreurs ni interruptions. Elle signifie plutôt qu'une défaillance limitée ne se transforme pas en perte étendue, et que l'absence d'un composant unique ne devient pas la raison de l'effondrement d'une décision tout entière. Un système résilient détecte le défaut tôt, préserve ses fonctions critiques à une capacité acceptable, rétablit le service dans un délai connu, puis tire les leçons de l'incident afin de ne pas y revenir avec la même fragilité. L'efficacité se mesure habituellement dans des conditions attendues : de combien a-t-on réduit la consommation d'eau ou de carburant ? Combien de décisions ont été traitées par heure ? De combien le coût unitaire a-t-il baissé ? La résilience, à l'inverse, commence lorsque ces conditions changent : que se passe-t-il si le réseau tombe, ou si la station météorologique cesse de fonctionner, ou si un capteur transmet une valeur erronée, ou si le seul technicien qui connaît le système est absent, ou si le fournisseur cesse d'assurer le service, ou si une cyberattaque survient à un moment où la plante ou l'animal ne peut attendre le rétablissement du serveur ? Un paradoxe important apparaît ici : une partie de ce qui ressemble à du « superflu » les jours stables devient une condition de survie en cas de choc. Une source d'alimentation de secours, un stock de précaution, une voie manuelle, un fournisseur alternatif, un stockage local des données et la formation de plus d'un employé à une tâche ont tous un coût et peuvent paraître moins efficaces si le système est jugé à l'aune de sa journée de fonctionnement la moins coûteuse. Pourtant, ils peuvent éviter la perte d'une saison entière lorsque la voie principale est coupée. La redondance n'est pas nécessairement du gaspillage ; elle peut être le prix qu'un système paie pour conserver sa capacité d'agir quand les options se réduisent. Fiabilité, robustesse et résilience ne sont pas une seule et même chose Trois notions étroitement liées doivent être distinguées :

• La fiabilité est la probabilité qu'un système remplisse la fonction requise sans défaillance sur une période déterminée et dans des conditions déterminées. Une station d'irrigation peut être fiable si elle fonctionne des mois durant sans s'arrêter.
• La robustesse est la capacité du système à maintenir une performance proche de son niveau normal malgré des changements limités des conditions ou des données. Un modèle robuste ne voit pas sa précision s'effondrer simplement parce que l'éclairage a changé, ou que le type de téléphone a changé, ou qu'une petite lacune est apparue dans certaines mesures.
• La résilience est plus large que les deux précédentes ; elle englobe la préparation au choc, l'absorption de son impact, le rétablissement des fonctions, puis l'ajustement de la conception après compréhension de la cause de la défaillance. Un système résilient peut échouer, mais il échoue d'une manière limitée, compréhensible et dont on peut se relever, et ne laisse pas l'utilisateur sans alternative, sans connaissance, ni sans l'autorité d'intervenir.

Pour cette raison, un retour rapide à l'exploitation n'est pas toujours suffisant. Si le système revient à la conception même qui a produit sa fragilité, nous avons rétabli le service sans tirer les leçons de l'incident. La résilience véritable ne se contente pas de redémarrer la machine ; elle reconsidère la relation entre machine, données, être humain, fournisseur et procédure. Les quatre capacités de la résilience La résilience opérationnelle peut se décomposer en quatre capacités successives et interconnectées :

1. Visibilité et anticipation : détecter le défaut avant que ses effets ne s'étendent

La résilience ne commence pas après la survenue de la perte, mais avec la capacité de voir le signal précoce. Cela comprend la surveillance de l'état de santé des capteurs, la détection des valeurs anormales, le suivi de la connectivité, de l'alimentation électrique et de la latence des données, ainsi que la vérification que le modèle fonctionne toujours dans les conditions dans lesquelles il a été testé. Il ne suffit pas que le système déclenche une alarme ; il doit distinguer entre un aléa agronomique et un défaut de mesure. Si un capteur d'humidité du sol signale une sécheresse soudaine, le champ peut effectivement être sec, ou le câble peut être endommagé, ou le capteur peut avoir bougé de sa position, ou son étalonnage peut ne plus être correct. Un système qui traite chaque relevé comme une vérité peut convertir un petit défaut électrique en sur-irrigation ou en intervention inutile. Cette capacité se mesure par le temps de détection d'un défaut, la part des défauts détectés avant qu'ils n'affectent une décision, et la capacité du système à localiser la source du problème — et non simplement par le nombre d'alertes. Une abondance d'alarmes peut en réalité réduire la résilience si elle noie l'utilisateur dans un bruit qui le conduit à ignorer l'avertissement important.

2. Absorption : poursuivre les fonctions essentielles, même à capacité réduite

Lorsqu'un choc survient, ce qui est requis n'est pas toujours que chaque fonction se poursuive au même niveau. Ce qui importe davantage, c'est d'identifier les fonctions qui ne peuvent pas être perdues, et de basculer de manière ordonnée vers un mode de fonctionnement réduit qui protège la culture, l'animal ou l'aliment jusqu'au retour du service complet. Des analyses avancées dans le nuage peuvent s'interrompre, tandis que le pilotage local sur des règles sûres se poursuit. Une carte d'application à dose variable peut échouer, et la machine revient temporairement à une dose fixe conservatrice approuvée à l'avance. Une application de conseil peut perdre la connectivité, tout en continuant de mettre à disposition la dernière recommandation vérifiée accompagnée de l'indication de sa date, plutôt que de présenter une information périmée comme si elle était actuelle. L'absorption ne signifie pas que le système continue à tout prix, mais qu'il sait ce qu'il peut faire en sécurité et ce dont il doit s'abstenir. Dans certains cas, l'état sûr consiste à poursuivre un niveau minimal de fonctionnement ; dans d'autres, il s'agit d'un arrêt ordonné et d'une demande d'intervention humaine. Il n'existe pas d'état sûr unique pour tous les systèmes ; fermer une vanne peut protéger d'une inondation dans un contexte, tout en exposant les plantes d'une serre à un danger rapide dans un autre.

3. Rétablissement : revenir à un service acceptable dans un délai connu

Une fois le choc contenu, le système doit savoir comment reprendre le travail, qui en est responsable et quelles ressources sont nécessaires. Il ne suffit pas de dire que les données sont « sauvegardées dans le nuage » ou que le support technique est « disponible » ; il faut plutôt préciser la durée d'indisponibilité maximale acceptable, la quantité de données pouvant être perdue, et la méthode de vérification de l'intégrité du système avant son redémarrage. Le rétablissement peut se dérouler par étapes : rétablir d'abord le pilotage local, puis synchroniser les données, puis réactiver les modèles analytiques, puis vérifier si les décisions différées ont cessé d'être valides parce que l'état de la parcelle a changé. Une recommandation qui était correcte il y a deux jours peut devenir erronée après une pluie, un changement de température, ou le passage de la fenêtre d'intervention. Le rétablissement se mesure par le temps de retour au niveau de service sûr minimal, puis par le temps de retour au fonctionnement complet, par le volume de données perdues, et par le nombre de décisions ayant nécessité une revue humaine. Tant que ces valeurs restent inconnues, la promesse de rétablissement demeure plus proche d'un espoir que d'un plan.

4. Adaptation : modifier la conception après avoir tiré les leçons de l'incident

Un incident n'est pas simplement un défaut dont il faut clore le ticket ; c'est une épreuve qui a mis au jour une hypothèse erronée dans la conception. Une coupure de réseau peut révéler que le pilotage local est insuffisant ; un relevé corrompu peut révéler que le système se fie à un capteur unique ; l'absence d'un technicien peut montrer que la connaissance est confinée à une seule personne ; une pièce de rechange livrée avec retard peut faire apparaître que le fournisseur constitue un point de défaillance unique. L'adaptation commence par l'analyse des causes profondes, suivie de la modification des règles, de l'architecture ou des responsabilités : ajouter une vérification croisée entre capteurs, former un autre employé, stocker les pièces critiques, adopter un format de données portable, segmenter le réseau, modifier le contrat de maintenance, ou ajouter un fournisseur alternatif. Le but n'est pas seulement d'empêcher une répétition littérale de l'incident, mais de réduire la susceptibilité du système à la famille de défauts à laquelle il appartient. Premier exemple pratique : une irrigation intelligente dépendante du nuage Un système d'irrigation fondé sur le nuage peut fonctionner avec une grande efficacité les jours ordinaires. Les capteurs recueillent l'humidité du sol et les données météorologiques, le modèle émet le calendrier d'irrigation, et l'unité de commande exécute automatiquement les instructions. Un tel système peut réduire la consommation d'eau et de main-d'œuvre et améliorer le calage des irrigations. Mais le tableau change si la connectivité est perdue pendant une vague de chaleur. Si l'unité de commande ne sait rien faire d'autre qu'attendre l'ordre du serveur, l'irrigation peut s'arrêter alors même que la pompe, les vannes et l'eau sont disponibles localement. Ici, la cause de la perte n'est pas un manque de ressources, mais une conception qui a fait de la connectivité externe une condition préalable à toute décision. Une conception plus résiliente, à l'inverse, combine plusieurs couches :

• Des règles locales de fonctionnement sûres, capables d'opérer pendant une période déterminée sans le nuage.
• Un calendrier de secours conservateur, fondé sur les dernières données fiables et l'état de la culture.
• Une capacité d'intervention manuelle claire et testée — et non un bouton qui n'existe que dans le manuel.
• Un stockage local des relevés et des commandes, puis une synchronisation dès le retour de la connectivité.
• Une alerte indépendante indiquant clairement que le système fonctionne en mode réduit.
• Une source d'alimentation de secours pour les fonctions critiques.
• Des limites empêchant un fonctionnement de secours prolongé sur la base de données périmées.
• Un journal montrant ce qui a été exécuté automatiquement et ce qu'un humain a modifié pendant la panne.

Un tel système n'est pas réputé résilient du seul fait qu'il possède un mode manuel. L'opérateur doit pouvoir y accéder, doit y avoir été formé, les étiquettes et les vannes doivent rester intelligibles si l'application tombe en panne, et la bascule vers ce mode doit être testée avant la saison de stress. Une alternative que personne ne sait utiliser n'est pas une alternative opérationnelle. Deuxième exemple pratique : une chaîne du froid qui paraît stable jusqu'à ce qu'un seul relevé défaille Dans une installation de stockage de fruits ou de produits laitiers, des capteurs de température peuvent transmettre leurs données à une plateforme qui surveille les chambres froides et émet des alertes en cas de dépassement des limites. L'efficacité peut être améliorée en réduisant le fonctionnement des compresseurs et en abaissant la consommation d'énergie. Mais que se passe-t-il si le relevé du capteur reste bloqué sur une valeur normale alors que la température monte en réalité ? Le système peut voir un écran stable et continuer d'optimiser l'énergie, tandis que les produits à l'intérieur de l'installation de stockage se dégradent. Ici, le défaut n'était pas une interruption de service, mais un service fonctionnant avec assurance sur des données corrompues — un type de défaillance plus dangereux, parce qu'il se cache derrière l'apparence d'un fonctionnement normal. Une conception résiliente exige dans ce cas plus d'un capteur aux points critiques, la comparaison des relevés entre eux, une alerte si une valeur demeure anormalement constante, des contrôles d'étalonnage périodiques, et une alarme locale qui ne dépende pas entièrement d'internet. Elle exige aussi un plan précisant la priorité de déplacement des produits, l'espace alternatif disponible, la durée pendant laquelle chaque catégorie peut rester dans les limites de sécurité, et qui détient l'autorité d'arrêter les réceptions ou de dérouter les expéditions. Ainsi, la résilience d'une chaîne du froid ne se mesure pas à la température moyenne sur un mois, mais à ce qui s'est produit pendant les quelques heures durant lesquelles le système est sorti de ses limites : combien de temps a-t-il fallu pour détecter le défaut ? Quelle quantité de produit a pu être sauvée ? Un enregistrement fiable de la décision a-t-il été conservé ? Et la voie alternative était-elle réellement exécutable ? Troisième exemple pratique : une chaîne d'approvisionnement optimisée pour le coût mais fortement concentrée Une entreprise agricole peut réduire ses coûts en achetant semences, pièces de rechange ou matériaux d'emballage auprès d'un fournisseur unique offrant le meilleur prix, en détenant le stock le plus faible possible, et en faisant transiter tous les produits par un unique centre de conditionnement. Dans des conditions stables, ce système paraît très efficace : moins de capital immobilisé en stocks, une gestion plus simple, et un coût unitaire plus bas. Mais une panne au centre de conditionnement, une défaillance du transport, la faillite du fournisseur, ou un changement réglementaire peuvent arrêter la chaîne tout entière. Le « superflu » a été éliminé jusqu'à ce qu'il ne reste plus aucune voie alternative. Ce qui apparaissait comme une amélioration des coûts a créé un point de défaillance unique dont l'impact dépasse les économies réalisées. La résilience ne signifie pas conserver un double de tout ni internaliser toute la production ; cela coûte cher et peut créer de nouveaux risques. Elle signifie plutôt savoir où se situent la concentration et la dépendance, estimer le temps nécessaire pour remplacer chaque élément, et distinguer entre un intrant dont l'arrivée peut être retardée et un composant dont l'absence pendant quelques jours entraîne la perte de la fenêtre de semis ou de récolte. La réponse peut inclure un deuxième fournisseur pour certains composants critiques, un stock limité de pièces à long délai d'approvisionnement, des contrats alternatifs, des spécifications permettant d'utiliser plus d'un produit, ou des centres de conditionnement partagés activables en cas de besoin. C'est là que le cadre de l'OCDE mentionné dans [SRC034] est particulièrement utile : il traite la chaîne comme un réseau d'interdépendances plutôt que comme une ligne fixe allant du fournisseur à l'acheteur. Le risque peut se situer au-delà des limites de l'exploitation, tout en l'atteignant par le financement, l'énergie, la connectivité, les intrants, le transport ou le stockage. Quatrième exemple pratique : un système d'intelligence artificielle qui fonctionne, mais dont les données ne représentent plus la réalité Un modèle de prédiction des maladies peut être précis au lancement, puis les conditions dans lesquelles il opère changent : une nouvelle variété apparaît, les dates de semis se décalent, la station météorologique est remplacée, une maladie aux symptômes similaires entre dans la zone, ou les caméras qui saisissent les images changent. Le modèle continue de produire des résultats, mais la relation entre les données d'entraînement et la réalité a commencé à s'affaiblir. C'est un cas dans lequel la question « Le serveur fonctionne-t-il ? » ne suffit pas. Le serveur peut fonctionner alors que le modèle défaille sur le plan fonctionnel. La résilience exige ici de surveiller les déplacements de la distribution des données, de comparer les prédictions aux résultats de terrain, d'identifier les cas dans lesquels le modèle devrait s'abstenir d'émettre une recommandation, et d'orienter les cas inhabituels vers un spécialiste. Il doit aussi exister une voie alternative si le modèle défaille ou perd une source importante de ses données. Cette alternative peut être une règle agronomique conservatrice, un protocole d'inspection manuelle, ou le recours à une source officielle de vulgarisation agricole. L'objectif n'est pas que l'alternative offre la même précision, mais qu'elle préserve la justesse de la décision jusqu'à ce que le système soit rétabli ou revalidé. L'être humain peut lui aussi constituer un point de défaillance unique La résilience ne se limite pas au matériel et au logiciel. Un système entier peut dépendre d'un employé qui connaît le mot de passe, ou d'un technicien capable d'étalonner le capteur, ou d'un consultant externe qui sait interpréter les résultats. Si cette personne est absente, l'équipement demeure en place tandis que la capacité de l'utiliser est perdue. La résilience inclut donc la documentation des procédures, la répartition prudente des habilitations, la formation de plus d'une personne aux fonctions critiques, la conservation des coordonnées de contact et de support, la définition des pièces de rechange et des outils nécessaires, et la conduite d'exercices périodiques de fonctionnement manuel et de rétablissement. Une connaissance non documentée est un actif fragile, même lorsqu'elle réside dans l'esprit d'un excellent expert. Comment teste-t-on la résilience ? Il ne suffit pas que le plan indique que le système dispose d'une « sauvegarde » ou d'un « support technique en continu ». Ces affirmations doivent être testées dans des conditions maîtrisées et sûres, avant que la réalité n'impose l'épreuve au pire moment possible. Les tests peuvent inclure :

• Couper la connectivité externe et vérifier que les fonctions critiques se poursuivent localement.
• Couper l'alimentation d'un composant non critique, puis d'un composant critique, selon un protocole sûr.
• Envoyer un relevé manquant, constant, ou très largement hors plage.
• Désactiver un capteur unique et vérifier la capacité du système à détecter l'écart.
• Arrêter le service du modèle tout en maintenant disponibles l'interface utilisateur et la base de données.
• Restaurer le système à partir d'une sauvegarde et vérifier l'intégrité des données — et non simplement le succès de l'opération de copie.
• Simuler l'absence du technicien principal et dérouler la procédure avec un autre employé formé.
• Tester l'expiration des clés d'accès ou des certificats numériques.
• Conduire un exercice cyber défensif isolé simulant la perte d'un compte, le chiffrement d'un appareil, ou l'altération d'une source de données, sans exposer le système de production au risque.
• Passer en revue les décisions différées après le rétablissement pour confirmer qu'elles demeurent valides sur le plan agronomique.

Chaque fonction critique devrait avoir des limites déclarées : quelle est la plus longue durée d'indisponibilité tolérable ? Quelle est la perte de données maximale acceptable ? Quel est le niveau de service minimal à maintenir ? Qui déclare le passage en mode manuel ? Qui décide du retour à l'automatisation ? Et comment vérifions-nous que les données accumulées pendant la panne ne sont pas devenues périmées ou contradictoires ? Que mesure-t-on ? La résilience ne se mesure pas par une formule générale telle que « le système est stable », mais par des indicateurs liés à la décision agricole, dont les plus importants sont :

• Le temps écoulé entre la survenue d'un défaut et sa détection.
• Le temps écoulé entre la détection et l'endiguement de son impact.
• La part des fonctions critiques qui se poursuivent en mode réduit.
• La durée d'indisponibilité maximale avant que ne commencent des dommages agronomiques ou économiques inacceptables.
• Le temps nécessaire pour rétablir le niveau de service sûr minimal.
• Le temps nécessaire pour rétablir le fonctionnement complet.
• Le volume de données perdues ou devant être reconstituées.
• Le nombre de décisions émises pendant le défaut ayant nécessité une revue.
• L'ampleur de la perte évitée grâce à la détection ou à une alternative.
• Le nombre de points de défaillance uniques que les tests ont révélés et qui ont été éliminés.
• La capacité d'un utilisateur non spécialiste à exécuter correctement la procédure de secours.
• Les changements introduits après l'incident pour prévenir la répétition de la même classe de défaillance.

Aucune valeur unique n'est valable pour tous les systèmes. Un journal analytique peut tolérer un retard de plusieurs heures, tandis qu'un système de ventilation dans une serre ou un bâtiment d'élevage ne peut tolérer une interruption comparable. Les seuils de résilience se déduisent donc de la rapidité et des conséquences du dommage agronomique, et non simplement de la capacité du service informatique à rétablir le serveur. D'une bonne performance à une performance sur laquelle on peut compter Si un système a été testé avec une connectivité stable, des données propres, une alimentation électrique disponible, un utilisateur expert et un fournisseur disponible, il n'a été testé que dans la meilleure version du monde. Cela est utile pour démontrer la faisabilité technique, mais ne suffit pas à démontrer une transformation sur laquelle on peut compter. La transformation agricole opère dans un milieu vivant qui ne se met pas en pause quand le logiciel défaille : la plante continue de perdre de l'eau, l'animal continue de produire de la chaleur, le produit réfrigéré continue de se dégrader, et la fenêtre d'intervention peut se refermer avant l'arrivée du support. Le plan de validation doit donc englober les pannes, les données corrompues, la défaillance partielle, les conditions changeantes, l'absence de la personne experte, la perte d'un fournisseur et les incidents cyber. Il ne s'agit pas d'anticiper toutes les catastrophes possibles, mais de savoir quelles fonctions ne peuvent pas être perdues, de concevoir des alternatives proportionnées aux conséquences de la défaillance, et de les tester avant qu'elles ne soient nécessaires. La résilience ne consiste pas simplement en ce que le système reprenne le travail ; elle consiste en ce que la décision agricole demeure sûre en l'absence du système, et en ce que l'être humain sache quoi faire quand l'algorithme se tait. Alors seulement la technologie passe d'une performance qui impressionne dans des conditions idéales à une infrastructure à laquelle on peut se fier quand le monde réel la met à l'épreuve.

5. La capacité pratique d'agir et de contrôler de l'agriculteur : le consentement formel ne suffit pas

Un utilisateur peut cliquer sur « J'accepte » sans lire les conditions ; il peut les lire sans en saisir les implications techniques et juridiques ; ou il peut les comprendre et les accepter malgré tout, parce que l'accès au service est impossible autrement. Dans les trois cas, le système enregistre un consentement, mais celui-ci n'établit ni que l'utilisateur disposait d'un choix libre, ni qu'il avait des connaissances suffisantes, ni qu'il avait une réelle capacité de négociation. Le consentement est donc un événement ponctuel : accepter des conditions ou autoriser un traitement de données pour une finalité déclarée. Ce que la littérature appelle la capacité pratique d'agir et de contrôler de l'agriculteur est plus large ; cela signifie que l'agriculteur sait ce qui est collecté au sujet de son exploitation, qui le collecte, pourquoi, pendant combien de temps c'est conservé, qui peut y accéder, comment cela entre dans une recommandation ou une décision, et vers quels autres usages cela peut migrer. Cela signifie aussi pouvoir corriger des données erronées, contester une décision, refuser des usages non nécessaires au service, obtenir son dossier dans un format exploitable, et passer à un autre système sans perdre la mémoire de l'exploitation ni interrompre les opérations essentielles. La distinction est ici celle entre un droit écrit et une capacité effectivement exerçable. Un contrat peut énoncer que l'agriculteur a le droit d'accéder à ses données, mais ce droit reste formel si la demande exige des procédures alambiquées ou des semaines d'attente. Une plateforme peut proposer un bouton de téléchargement des enregistrements, sans pour autant réaliser la portabilité si le résultat est un fichier image ou un rapport PDF qu'aucun autre système ne peut lire. Elle peut permettre la fermeture du compte, sans permettre de récupérer les limites parcellaires, les journaux d'irrigation et de fertilisation, les cartes de rendement ou l'historique des recommandations antérieures à la fermeture. Dans de tels cas, l'utilisateur peut quitter l'interface, mais il ne peut pas quitter la relation que la plateforme a construite. De quelles données parlons-nous ? Les données agricoles numériques ne se limitent pas au nom et au numéro de téléphone de l'agriculteur. Elles peuvent comprendre :

• Les limites des parcelles et leur localisation géographique.
• Le type de sol et les résultats d'analyses.
• Les dates de semis, d'irrigation, de fertilisation et de pulvérisation.
• Des images des cultures, des animaux et des installations.
• Les données météorologiques et les relevés de capteurs et de stations locales.
• Les cartes de rendement, de production, de qualité et de pertes.
• Les données de déplacement des machines, la consommation de carburant et les pannes.
• Les coûts des intrants, les ventes, le financement et l'assurance.
• Les données relatives aux travailleurs, les tâches et les heures de fonctionnement.
• Les notes consignées par l'agriculteur ou l'agronome.
• Les inférences produites par la plateforme, telles que la classification du risque, les estimations de production, la solvabilité ou la probabilité de maladie.

L'affaire se complique lorsque la plateforme génère de nouvelles données à partir des données initiales. Un agriculteur peut téléverser l'image d'une feuille de plante pour un diagnostic de maladie, et l'image, sa localisation et sa date sont ensuite utilisées pour entraîner un modèle commercial, pour construire une carte régionale de la propagation de la maladie, ou pour estimer la demande anticipée d'un produit agricole. Certains de ces usages peuvent être légitimes et bénéfiques pour la recherche ou pour la collectivité, mais leur bénéfice potentiel n'élimine pas la nécessité de les divulguer, de séparer leur finalité de celle du service initial et d'en définir les conditions. Cet ouvrage ne saurait pas davantage décréter de manière générale que l'agriculteur « est propriétaire de toutes les données » ; la qualification juridique de la propriété et des droits d'usage diffère selon le type de données, le contrat et la juridiction, et elle peut faire intervenir des droits enchevêtrés de l'agriculteur, de l'exploitant, du fabricant, du prestataire de services et d'autres parties. Mais une gouvernance professionnelle peut, avant même que la question de la propriété soit tranchée sur le plan nominal, déterminer clairement : qui peut accéder ? Pour quelle finalité ? À quelles conditions ? Qui a le droit de corriger, de transférer et de s'opposer ? Et que se passe-t-il à la fin du contrat ? Un consentement véritablement significatif Le consentement ne devient pas significatif du seul fait qu'il existe un long texte juridique. Pour soutenir l'autonomie de l'utilisateur, il devrait être :

• Compréhensible : rédigé dans un langage clair adapté à l'utilisateur, avec une brève explication des implications pratiques plutôt qu'une terminologie juridique seule.
• Spécifique à une finalité : distinguant les données nécessaires à la fourniture du service et celles recherchées à des fins supplémentaires, comme l'entraînement de modèles, le marketing ou le partage avec des partenaires.
• Sélectionnable : différents consentements ne sont pas regroupés en bloc s'ils ne sont pas tous nécessaires à la fourniture du service.
• Consultable et révocable : l'utilisateur peut voir ce à quoi il a consenti et modifier son choix ultérieurement, les conséquences étant explicitées.
• Proportionné : la plateforme ne demande pas plus de données que la fonction déclarée ne l'exige.
• Honnête quant à ses effets : en précisant si le retrait du consentement n'arrête que les usages futurs, quelles données doivent être conservées pour des raisons légales ou d'audit, et ce qui ne peut plus être supprimé une fois entré dans des traitements agrégés ou anonymisés.

Ces principes ne signifient pas que toute opération de traitement de données doive juridiquement reposer sur le consentement ; d'autres bases légales ou contractuelles peuvent exister selon la juridiction. L'essentiel est que le bouton « J'accepte » ne serve pas d'écran dissimulant la complexité de la relation ou transférant tout le risque à l'utilisateur. Un exemple pratique : un dossier d'exploitation qui ne peut pas être déplacé Supposons qu'un agriculteur ait utilisé une plateforme pour gérer son exploitation pendant dix ans. La plateforme contient les limites parcellaires, l'historique des cultures, les analyses de sol, les quantités d'irrigation et de fertilisation, les notes sur les maladies, les registres des travailleurs, les factures d'intrants et les cartes de production. Lorsque l'agriculteur a décidé de passer à une autre plateforme, l'entreprise a autorisé le téléchargement de rapports mensuels au format PDF. Formellement, l'agriculteur a reçu « une copie des données », mais il n'a reçu ni les champs d'origine sous forme de tableaux structurés, ni les relations entre parcelles, saisons et opérations, ni les unités, codes et dates dans une forme que le nouveau système pourrait interpréter. La transition a donc exigé de ressaisir à la main des années de données, à un coût élevé et avec une probabilité d'erreur substantielle. Il ne s'agit pas là d'un véritable transfert. L'accès à un rapport n'équivaut pas à la portabilité, la portabilité n'équivaut pas à l'interopérabilité, et l'interopérabilité seule ne garantit pas une sortie sûre.

Un fichier contenant le nombre « 25 » ne devient utile que lorsqu'on sait : s'agit-il d'une température, d'une humidité ou d'une quantité d'engrais ? Quelle en est l'unité ? À quel champ, quelle couche, quel moment et quelle profondeur se rapporte-t-il ? Et s'agit-il d'une mesure brute, d'une valeur corrigée ou d'une estimation produite par le modèle ? La portabilité véritable ne transfère pas seulement des nombres ; elle transfère suffisamment de leur signification, de leur contexte et de leur provenance pour qu'ils restent exploitables. Un exemple pratique : des données machines qui excèdent la finalité de maintenance Une machine agricole connectée peut collecter des données de localisation, d'heures de fonctionnement, de consommation de carburant, de performance moteur et de codes de défaut. Le fabricant a besoin de certaines de ces données pour assurer une maintenance proactive ou le service sous garantie, et c'est une finalité compréhensible. Mais les mêmes données peuvent révéler les horaires de travail, les surfaces cultivées, l'intensité opérationnelle et, peut-être, des indicateurs indirects du volume de production. Si ces données sont transmises à d'autres parties, ou utilisées dans la tarification, le marketing ou le développement de produits commerciaux, l'agriculteur ne devrait pas le découvrir enfoui dans des dizaines de pages de conditions. L'agriculteur doit savoir ce qui est nécessaire au fonctionnement du service, ce qui est facultatif, ce qu'il reçoit en contrepartie, et s'il peut refuser l'utilisation secondaire tout en conservant les fonctions essentielles qu'il a payées. La capacité pratique d'agir de l'agriculteur se manifeste également lorsqu'une erreur survient. Si le système attribue les heures de fonctionnement d'une machine au mauvais champ, ou interprète son arrêt comme une négligence de l'utilisateur, ou si les données sont utilisées dans un litige de garantie, l'agriculteur doit pouvoir consulter l'enregistrement, sa source et son horodatage, soumettre une correction documentée, et savoir qui a examiné son objection et ce qui a changé en conséquence. Un exemple pratique : une recommandation intelligente fondée sur un enregistrement erroné Une plateforme peut enregistrer de manière incorrecte le type de sol d'une parcelle, puis utiliser cet enregistrement pour calculer les besoins en eau ou choisir une dose de fertilisation. Si l'agriculteur ou l'agronome ne peut pas corriger la donnée, l'erreur se répétera tout au long d'une chaîne de recommandations ultérieures. La correction ne doit pas non plus signifier l'effacement de l'historique d'une manière qui masquerait ce qui s'est passé. Dans les systèmes professionnels, l'enregistrement d'origine est conservé, accompagné de la documentation de l'erreur, de la valeur corrigée, de l'identité de l'auteur de la correction, de sa date et des décisions qui ont pu en être affectées. Le droit de l'utilisateur à la correction est ainsi concilié avec les exigences d'audit et de sécurité. Si, en revanche, le système présente la recommandation sans afficher les données sous-jacentes ni les hypothèses qui la fondent, l'utilisateur sera incapable de découvrir que l'erreur provenait de la classification du sol. L'interprétabilité devient ici une composante de l'autonomie décisionnelle, et non un ornement cosmétique de l'interface. Un exemple pratique : refuser une recommandation ne devrait pas signifier quitter le service Un agriculteur peut refuser une recommandation automatisée de pulvérisation parce que l'observation au champ a montré que l'infestation était limitée, ou parce que la substance proposée est indisponible, ou parce que des contraintes légales ou climatiques en empêchent l'application. Un système qui respecte l'autonomie de l'utilisateur ne se contente pas d'un bouton « refuser » ; il permet de consigner le motif du refus, préserve la décision humaine, suit le résultat obtenu et l'utilise — dans le cadre d'une gouvernance claire — pour améliorer le système. À l'inverse, le respect de l'autonomie de l'agriculteur ne doit pas être compris comme une exécution fondée sur le choix humain sans garde-fous. Si une décision est susceptible de menacer la sécurité sanitaire des aliments, la sécurité des travailleurs ou l'environnement, le système doit afficher l'avertissement et l'exigence légale et demander une escalade appropriée. La capacité d'action et de contrôle ne signifie pas l'absence de gouvernance ; elle signifie que l'autorité, la responsabilité et les limites sont claires, et que les décisions sensibles ne se dissimulent pas derrière une interface automatisée opaque. La capacité de sortie comme test du pouvoir de négociation Une plateforme peut, au départ, offrir à l'agriculteur une efficacité considérable : elle regroupe les enregistrements en un seul endroit, accélère les recommandations et relie les machines à l'inventaire et aux ventes. Pourtant, ce bénéfice peut se muer en dépendance technologique envers le fournisseur si les données sont stockées dans des formats propriétaires qu'aucun autre système ne peut comprendre ou réutiliser, ou si les fonctions essentielles des équipements deviennent exclusivement liées aux logiciels et services du fournisseur, ou encore s'il n'existe aucun moyen pratique de transférer l'historique agricole vers une plateforme alternative. À ce stade, l'agriculteur peut voir ses données à l'intérieur du système, mais n'a aucune liberté d'en disposer à l'extérieur ; et le coût du départ augmente à mesure que s'accumulent les saisons, les enregistrements et les cartes. Ainsi, l'efficacité qui avait d'abord séduit l'utilisateur peut se transformer en une dépendance qui affaiblit sa capacité à négocier et à s'adapter à l'avenir. Les effets de cette dépendance apparaissent lorsque le prix augmente, que les conditions d'utilisation changent, que le produit est abandonné, que l'entreprise est vendue, que la qualité du service décline ou que les intérêts divergent. Un agriculteur qui peut se tourner vers une solution alternative conserve un pouvoir de négociation ; tandis que celui dont les enregistrements seraient perdus ou dont les opérations s'arrêteraient en cas de départ peut consentir à de nouvelles conditions sans que ce consentement traduise nécessairement une satisfaction — il peut au contraire refléter le coût de sortie accumulé à son détriment.

C'est pourquoi la sortie doit être conçue avant la contractualisation, et non après la survenue d'un litige. Cela comprend :

• Préciser quelles données peuvent être exportées, y compris, le cas échéant, les données brutes, corrigées et dérivées.
• Documenter les formats, les unités, les identifiants et les relations entre les tables.
• Fournir un export lisible par machine, et non des rapports visuels seuls.
• Préciser pendant combien de temps les données restent disponibles après la fin du contrat.
• Indiquer ce qui sera supprimé, ce qui sera conservé, et pour quelle raison et pour quelle durée.
• Séparer, lors de l'export, les données de l'agriculteur de celles d'autres agriculteurs.
• Fournir une voie de migration des données ou des interfaces d'intégration documentées lorsque cela est nécessaire.
• Déterminer à l'avance les coûts de sortie, et empêcher des frais surprises qui rendraient le transfert impraticable.
• Préserver un moyen manuel ou local d'assurer les fonctions critiques pendant la transition.
• Révoquer les anciens identifiants d'accès et vérifier l'exhaustivité du transfert et de la suppression conformément à la politique déclarée.

Comment mesurer l'autonomie de l'agriculteur ? Il ne suffit pas qu'une plateforme d'agriculture numérique déclare dans sa politique qu'elle « respecte les droits sur les données ». Cela peut être vérifié au moyen d'indicateurs pratiques, tels que :

• Le temps nécessaire pour obtenir une copie complète des données.
• La proportion des enregistrements couverts par l'export au regard de ce que la plateforme affiche et utilise dans ses décisions.
• La capacité d'un autre système à importer les données et à en comprendre les unités et les relations.
• Le coût du passage à un autre prestataire et la durée d'interruption fonctionnelle pendant ce passage.
• La possibilité pour l'utilisateur de savoir quelles parties ont accédé à ses données.
• La facilité de corriger un enregistrement erroné et de retracer l'effet de la correction sur les décisions antérieures.
• La possibilité de refuser une utilisation secondaire non nécessaire sans perdre le service essentiel.
• L'existence d'une voie claire pour contester une recommandation ou une décision automatisée.
• La possibilité de passer outre l'automatisation et de revenir à une procédure manuelle sûre.
• La clarté sur ce qu'il advient des données à la clôture du compte ou à l'expiration du contrat.
• La capacité de l'utilisateur à extraire l'historique de l'exploitation sans dépendre d'une assistance exceptionnelle du fournisseur.

Et le test le plus probant n'est pas la question « existe-t-il un bouton d'export ? », mais la réalisation d'un essai de transfert réel : un utilisateur ordinaire peut-il déplacer une saison complète vers un autre système, vérifier l'exhaustivité des enregistrements et poursuivre son travail sans reconstruire de zéro l'historique de l'exploitation ? Du consentement à la confiance L'étude de l'OCDE, adoptant le point de vue des agriculteurs, montre clairement que l'accès aux données, les règles régissant leur utilisation, leur portabilité, l'interopérabilité et la confiance entre agriculteurs et fournisseurs de technologies ne sont pas des questions périphériques dans la transformation numérique de l'agriculture [SRC032]. Un agriculteur n'évalue pas un outil uniquement à sa capacité de produire une recommandation ; il se demande — explicitement ou implicitement — à qui profitent les données, qui peut les consulter, si elles peuvent être utilisées contre lui, et ce qu'il lui restera si la relation avec le fournisseur prend fin.

Par conséquent, la capacité de sortie n'est pas une annexe juridique dont on discute après l'achat du système ; c'est une propriété de la conception du système et un indicateur de la manière dont le pouvoir y est réparti. Une plateforme que l'on ne peut pas quitter peut apporter une efficacité à court terme, mais elle amoindrit la capacité de l'exploitation à négocier, s'adapter et innover sur le long terme. Si la mémoire de la parcelle devient l'otage de la plateforme, l'agriculteur n'a pas seulement numérisé son savoir ; il l'a transféré dans un lieu dont il ne détient aucune clé pour sortir. La transformation numérique responsable, à l'inverse, fait de la technologie un partenaire que l'on peut choisir, réexaminer et remplacer — et non une porte que l'utilisateur franchit une fois, pour découvrir que son histoire agricole est restée à l'intérieur. Entre principe et faisabilité : une gouvernance possible, non un idéal impossible La capacité de l'agriculteur à comprendre ses données, à les contrôler, à les transférer et à s'opposer à leur utilisation constitue une norme nécessaire pour une transformation numérique responsable. Mais faire de cette norme un système qui fonctionne réellement représente un formidable défi technique, opérationnel et juridique. La difficulté ne se limite pas aux plateformes émergentes ou locales ; même les entreprises mondiales dotées d'équipes spécialisées et d'infrastructures cloud étendues se heurtent à la fragmentation des données entre systèmes, à la divergence des législations d'un pays à l'autre, à la complexité des modèles, à l'accumulation de logiciels hérités, et à la difficulté de déplacer des enregistrements entre des produits logiciels qui n'ont jamais été conçus, à l'origine, pour parler la même langue. L'autonomie de l'agriculteur ne doit donc pas être comprise comme la promesse d'une perfection technique : que chaque résultat recevra une explication causale complète, que toutes les données migreront instantanément vers n'importe quelle plateforme, et que la trace de chaque enregistrement sera effacée d'un coup de toutes les sauvegardes et de tous les modèles préalablement entraînés sur elle. Certaines de ces exigences sont possibles en principe mais extrêmement coûteuses ; certaines demeurent techniquement immatures ; et certaines peuvent entrer en conflit avec des impératifs de sécurité, d'audit et de conservation légale des enregistrements. Reconnaître ces limites n'accorde pourtant pas à une plateforme d'intelligence artificielle une exonération générale de responsabilité. Une incapacité technique peut être compréhensible si la plateforme la déclare clairement, en définit les conséquences, propose une alternative adaptée et présente un plan d'amélioration réaliste. Mais invoquer cette incapacité pour retenir des données, imposer une dépendance ou livrer une fonction que la plateforme ne peut pas faire fonctionner en toute sécurité n'est pas un développement progressif ; c'est un transfert du coût de la défaillance vers l'utilisateur. Et si une plateforme ne peut pas livrer intégralement la version la plus avancée, elle doit restreindre la portée de sa promesse plutôt que d'abaisser le niveau de protection. Elle peut prendre en charge un nombre limité de cultures ou d'appareils ; elle peut soumettre une recommandation à un examen humain au lieu de l'exécuter automatiquement ; elle peut fournir une exportation des données dans un délai déclaré au lieu d'un transfert instantané ; et elle peut s'intégrer à un ensemble limité de formats documentés au lieu de revendiquer une compatibilité avec tous les systèmes. Ce sont là des contraintes compréhensibles, car elles réduisent l'étendue, la rapidité ou le degré d'automatisation du service sans dissimuler la vérité ni exposer l'utilisateur à un risque inconnu. La sécurité, la véracité des allégations, la sécurité élémentaire des données, la connaissance des finalités pour lesquelles les données sont utilisées, la possibilité d'accéder aux enregistrements essentiels et le pouvoir d'interrompre ou de réexaminer une décision à haut risque ne sont en revanche pas des options accessoires que l'on reporterait à une version ultérieure, une fois que le budget le permettra. Une plateforme aux capacités limitées peut offrir un service limité et bien gouverné ; ce qu'elle ne peut pas faire, c'est offrir un service largement dangereux et faire ensuite supporter à l'agriculteur le prix de ce qu'elle n'a pas su protéger. Pourquoi la mise en œuvre est-elle difficile, même pour les grandes entreprises ?

1. Les données agricoles ne forment pas un tableau unique

La mémoire d'une exploitation se répartit entre des types très hétérogènes : limites géographiques, imagerie satellitaire et aérienne, séries temporelles de capteurs, cartes de rendement, registres de fertilisation et de pulvérisation, fichiers de machines, factures et contrats, notes écrites, et recommandations générées par des modèles. Chaque type possède ses propres unités, dates, résolution spatiale, provenance, niveau de confiance et relations avec les autres enregistrements. Une liste d'opérations culturales peut être transférée dans un fichier tableur, mais transférer une carte de rendement avec son système de coordonnées, ses données d'étalonnage et sa relation à la parcelle, à la saison et à la machine exige une structure plus riche. Si les unités, les relations, la provenance ou la chronologie se perdent, les chiffres voyagent mais leur sens reste sur place. « Exporter toutes les données » n'est donc pas un simple bouton ; c'est un projet qui suppose de définir ce qui entre dans le périmètre de l'exportation, de documenter les formats, de préserver les relations et la sémantique, et de vérifier que le fichier obtenu est réellement utilisable en dehors du système d'origine.

2. Aucune norme unique ne couvre l'ensemble des systèmes agricoles

Les plateformes emploient des dénominations et des classifications différentes pour les cultures, les maladies, les opérations, les unités et les stades de développement. Un système peut enregistrer une quantité d'engrais en kilogrammes par hectare, un autre sous forme de quantité totale pour la parcelle, tandis qu'un troisième stocke le nom commercial du produit et le pourcentage de matière active. Même si deux plateformes sont techniquement capables d'échanger un fichier, elles peuvent ne pas s'accorder sur le sens de ses champs. C'est là toute la différence entre transfert de données et interopérabilité sémantique : le premier déplace des valeurs, la seconde garantit que le nouveau système les comprend comme l'ancien système l'entendait. Bâtir un vocabulaire unifié pour chaque culture, région, langue et machine est une tâche hors de portée de la plupart des petites entreprises, et elle demeure un défi ouvert même pour les grandes institutions. On peut donc exiger un standard minimal de documentation, d'unités et d'identifiants, mais il ne faut pas poser comme condition une compatibilité immédiate avec toutes les plateformes du marché.

3. Les données sources se propagent dans de nombreuses couches dérivées

Une information peut naître sous forme d'image ou de relevé de capteur, puis passer par un nettoyage et une correction, devenir une variable utilisée par un modèle, engendrer une prédiction, apparaître dans un rapport, être copiée dans un cache, entrer dans un index de recherche, et être utilisée dans un tableau de bord de suivi ou dans un modèle ultérieur. Si l'information d'origine est corrigée, propager cette correction à travers toutes ces couches est loin d'être simple. Cela peut exiger de recalculer des indicateurs, d'invalider un cache, de mettre à jour des index, de signaler des rapports antérieurs, et éventuellement de réexécuter un modèle. Une modification directe peut aussi corrompre la piste d'audit ou altérer après coup l'historique consigné d'une décision. Pour cette raison, une correction professionnelle est généralement une correction documentée et datée plutôt qu'un effacement silencieux de l'ancienne information. Une plateforme d'intelligence artificielle doit distinguer entre :

• L'enregistrement d'origine tel qu'il a été reçu.
• La valeur corrigée.
• Le motif de la correction, son auteur et sa date.
• Les résultats antérieurs susceptibles d'avoir été affectés par l'erreur.
• Les résultats recalculés après la correction.

Mettre en œuvre cette chaîne dans son intégralité est coûteux, mais le minimum auquel il est interdit de déroger consiste à empêcher que des données reconnues comme erronées continuent d'alimenter de nouvelles décisions à fort impact, tout en conservant une piste d'audit qui rende clair ce qui a été modifié.

4. Supprimer des données d'un modèle entraîné n'est pas comme supprimer une ligne dans une base de données

Si une image est supprimée d'un espace de stockage de fichiers, on peut être relativement certain qu'elle a disparu du système opérationnel une fois le cycle de sauvegarde achevé. Mais si des milliers d'images ont servi à entraîner un modèle, la trace de chaque image se répartit dans les poids du modèle, et il n'existe généralement aucun emplacement unique que l'on pourrait supprimer pour en retirer la contribution. La solution peut consister à réentraîner le modèle sans les données à exclure, mais cela coûte cher sur le plan informatique et opérationnel et peut exiger une revalidation des performances et de la sécurité. Il existe des travaux de recherche dans le domaine du « désapprentissage automatique » (machine unlearning), mais ce n'est pas une solution magique clés en main pour toute architecture et tout type de modèle. La plateforme doit donc être franche dès le départ sur la différence entre :

• La suppression du fichier brut.
• La suppression des copies opérationnelles et en cache.
• L'arrêt de toute utilisation future à des fins d'entraînement.
• L'expiration de la conservation des sauvegardes selon un calendrier déclaré.
• L'influence des données sur un modèle déjà entraîné.

Une plateforme ne peut pas promettre un effacement complet et immédiat si son architecture ne permet pas de le réaliser. Mais elle ne peut pas non plus se servir de cette complexité comme prétexte pour alimenter l'entraînement avec les données de l'exploitation sans divulgation ni choix approprié. Et si les données sont très sensibles, ou si leur utilisation pour l'entraînement n'est pas nécessaire au service, le traitement le moins coûteux et le plus sûr est que ces données n'entrent pas du tout dans l'entraînement, sauf sous des conditions claires. Les obligations légales demeurent contraignantes selon la juridiction ; la difficulté technique n'annule pas la loi, mais elle impose de concevoir dès le départ le cycle de vie des données de manière à abaisser le coût de la conformité.

5. L'explication complète de certains modèles d'intelligence artificielle n'est pas possible en pratique

Un système peut afficher les règles qu'il a employées dans un calcul simple, mais donner une explication causale complète d'un modèle profond ou génératif est bien plus ardu. Certains outils d'explication peuvent produire une description approximative des facteurs influents, mais ils ne révèlent pas nécessairement « la raison de la décision » au sens humain, et leurs explications peuvent changer au moindre changement dans les entrées. Le danger le plus grand est que le système engendre une explication verbale persuasive après l'émission du résultat, alors même que cette explication n'est pas une description fidèle du processus qui l'a produit. L'explication devient alors une histoire rassurante plutôt qu'un instrument de reddition de comptes. Une entreprise n'a pas besoin de divulguer les poids de ses logiciels ni ses secrets d'affaires pour respecter l'utilisateur, mais l'explication minimale pour des décisions agricoles sensibles devrait inclure :

• La finalité pour laquelle le modèle a été conçu.
• Le type de données sur lesquelles il s'est appuyé.
• La date des données ou de la recommandation.
• Les entrées les plus pertinentes ayant pesé sur le résultat, dans la mesure où cela peut être démontré.
• Le niveau de confiance ou la plage d'incertitude partout où cela est valable.
• Les cas dans lesquels le modèle ne doit pas être utilisé.
• La source de la recommandation ou la référence professionnelle lorsque la réponse repose sur une récupération d'informations.
• Ce que l'utilisateur peut faire si la réalité du terrain contredit le résultat.

Si une plateforme ne peut pas fournir ce minimum pour une décision à haut risque, le système devrait être converti en outil d'alerte ou de tri plutôt qu'en autorité d'exécution indépendante.

6. La portabilité peut entrer en conflit avec la cybersécurité si elle est mise en œuvre sans contrôles

Plus le téléchargement des données devient facile, plus il faut vérifier l'identité et les autorisations de celui qui demande l'exportation. Les données agricoles peuvent contenir des localisations, des informations financières, des contrats et des schémas de production ayant une valeur commerciale. Un bouton d'exportation non protégé peut ainsi devenir un instrument de fuite de toute l'histoire de l'exploitation. La plateforme a besoin d'une vérification d'identité, d'une séparation des données des utilisateurs, d'une journalisation des demandes d'exportation, d'une protection du fichier en transit, de limites d'expiration sur les liens de téléchargement, et éventuellement d'un chiffrement de l'archive. Ces exigences ne sont pas un luxe bureaucratique, mais elles augmentent bel et bien le coût et la complexité, en particulier pour les petites plateformes.

Il est donc acceptable qu'une exportation prenne un délai raisonnable ou passe par une vérification supplémentaire, mais la sécurité ne peut pas servir de prétexte pour refuser l'exportation ou pour fournir un fichier incomplet et inutilisable.

7. Une sortie sans aucune interruption de service est une exigence extrêmement coûteuse

Si une plateforme est liée à l'irrigation, aux machines, aux stocks, à la comptabilité et aux services de conseil, migrer vers une solution alternative peut exiger des semaines de planification et de vérification. Garantir une transition instantanée sans aucune interruption de service peut supposer de faire tourner deux systèmes en parallèle, de construire des connecteurs sur mesure et de retester tous les appareils et toutes les règles — un coût que la plupart des projets ne peuvent pas supporter. Ce qui est réellement exigible, ce n'est pas une « sortie sans une seconde d'interruption » dans tous les cas, mais une sortie ordonnée dont le coût, la durée et les risques sont déclarés et raisonnables. Les fonctions critiques, comme le pilotage de l'irrigation ou la ventilation des serres, doivent disposer d'une voie locale ou manuelle sûre pendant la transition. Pourquoi le défi est-il plus difficile pour les plateformes locales et les petites entreprises ? Une entreprise mondiale peut disposer d'équipes distinctes pour la sécurité, la protection de la vie privée, la conformité, l'ingénierie des données et l'exploitation, alors que dans une petite plateforme une seule personne cumule plusieurs rôles. Une plateforme locale peut dépendre d'un fournisseur cloud, d'un service cartographique, d'un modèle d'intelligence artificielle externe, d'un système de paiement et d'une bibliothèque logicielle, et manquer ainsi d'un contrôle complet sur le cycle de vie des données. Les petites entreprises de logiciels sont confrontées, en particulier, à :

• Le coût de construction de multiples interfaces d'intégration.
• Une pénurie de spécialistes de la sécurité de l'information et de la protection des données.
• La difficulté à prendre en charge les formats de nombreuses machines et de nombreux constructeurs.
• Le coût de maintenance des enregistrements, des index et des sauvegardes.
• Le coût du réentraînement et de la validation des modèles.
• La difficulté d'assurer un support continu dans différentes langues et régions.
• La dépendance envers des fournisseurs de modèles ou d'infrastructures cloud susceptibles de modifier leurs prix ou leurs conditions.
• Une capacité juridique limitée pour interpréter des législations divergentes d'un pays à l'autre.
• La difficulté de mener fréquemment des audits indépendants.
• Un marché local étroit, ce qui rend plus difficile la répartition des coûts fixes sur un grand nombre d'utilisateurs.

Mais la petite taille d'une entreprise ne réduit pas les conséquences de ses erreurs. Une plateforme locale qui pilote l'irrigation ou recommande l'utilisation d'un intrant agricole peut causer un préjudice réel tout autant qu'une plateforme mondiale. Les obligations doivent donc être proportionnées à la criticité de la fonction et des données, et non à la seule taille de l'entreprise. Et si une entreprise n'est pas en mesure de satisfaire aux exigences d'une fonction hautement sensible, la réponse professionnelle consiste à réduire le périmètre de cette fonction ou à maintenir un humain dans la boucle de décision — non à abaisser le niveau d'exigence en matière de sécurité. Sur quoi ne peut-on pas transiger ? Il existe un socle qu'il ne faut pas abandonner sous prétexte de coût ou de la petite échelle de la plateforme :

Il ne s'agit pas d'un ensemble complet de fonctionnalités de luxe ; c'est la ligne qui sépare une plateforme aux capacités limitées mais néanmoins honnête et responsable d'une plateforme qui transfère ses risques sur l'agriculteur. Que peut-on simplifier ou mettre en œuvre progressivement ? Une mise en œuvre progressive peut être admise pour les exigences suivantes, à condition qu'elle soit clairement déclarée et que la sécurité ne soit pas compromise :

Mais ces éléments ne doivent pas être décrits comme des choses que l'on peut « négliger » sans réserve. Plus précisément, ce sont des exigences que l'on peut simplifier, dont on peut différer la maturité, ou que l'on peut appliquer d'abord aux fonctions critiques. Quant à la transparence, à la sécurité, à l'absence d'allégations trompeuses, à l'accès aux données essentielles et à l'intervention dans les décisions dangereuses — cela ne doit pas être reporté à une version future non précisée. Un modèle réaliste pour la petite plateforme Il n'est pas demandé à une plateforme locale de construire, dès son premier jour, un système rivalisant avec celui des plus grandes entreprises mondiales. Elle peut atteindre une gouvernance respectable par une conception limitée mais franche :

1. Elle collecte le minimum de données nécessaires, plutôt que tout ce qui peut être collecté.
2. Elle sépare les données brutes des données dérivées et des journaux de décision.
3. Elle utilise dès le départ des identifiants, des unités et des dates normalisés.
4. Elle fournit un export complet des données essentielles dans un format unique et documenté.
5. Elle tient un journal d'audit simple qui ne peut être modifié en silence.
6. Elle sépare la fourniture du service du consentement à l'entraînement ou au marketing.
7. Elle permet la correction des enregistrements tout en conservant la version antérieure et le motif de la modification.
8. Elle affiche la source d'une recommandation, sa date et ses limites, plutôt que de construire une « explication » verbale fallacieuse.
9. Elle maintient les décisions sensibles sous revue humaine.
10. Elle prévoit une voie manuelle pour les fonctions dont l'interruption pourrait causer un préjudice.
11. Elle publie clairement ce qu'elle prend en charge et ce qu'elle ne prend pas en charge, la durée de conservation, ainsi que les délais d'export et de réponse.
12. Elle teste réellement la restauration des sauvegardes au lieu de se contenter de créer des sauvegardes.
13. Elle réduit sa dépendance aux formats fermés lorsqu'il existe des solutions de remplacement stables.
14. Elle diffère les fonctionnalités à haut risque qu'elle ne peut pas gouverner, au lieu de les lancer puis d'essayer d'en réparer les effets.

Cette approche est peut-être moins tape-à-l'œil qu'une plateforme promettant une automatisation totale, mais elle est plus mûre. Un système qui remplit cinq fonctions dans des limites déclarées et protège les données de l'utilisateur vaut mieux qu'un système offrant vingt fonctions dont le développeur ignore où vont les données des utilisateurs et ce qui se passe lorsque ces fonctions échouent. La proportionnalité se mesure au risque, non à la richesse de l'entreprise La prise en compte du coût de mise en œuvre ne doit pas se transformer en un double standard permettant aux petites plateformes d'offrir des services dangereux avec des garde-fous plus faibles. Une proportionnalité correcte examine quatre facteurs :

• La sensibilité des données que le système traite.
• L'ampleur du préjudice possible s'il se trompe ou s'arrête.
• Le degré de dépendance de l'utilisateur à son égard.
• La réversibilité de la décision une fois exécutée.

Une application qui enregistre des notes non sensibles et ne pilote aucune opération au champ peut fonctionner avec des garde-fous plus légers qu'un système qui ouvre des vannes d'irrigation, oriente l'utilisation d'un pesticide, évalue l'éligibilité d'un agriculteur à un financement, ou partage des données de production avec un acheteur ou une compagnie d'assurance. Ainsi, à mesure que la sensibilité de la décision augmente, le minimum requis augmente avec elle, même si le prestataire de services est une petite entreprise. Et si l'entreprise ne peut atteindre ce minimum, elle doit réduire l'autonomie du système, ajouter une revue humaine, ou le convertir en outil d'information plutôt qu'en outil d'exécution. Le critère équitable Ce qui est exigé, ce n'est pas une plateforme parfaite qui ne se trompe jamais, ne tombe jamais en panne et ne conserve aucune trace des données. Une telle image est irréaliste. Ce qui est exigé, c'est une plateforme qui connaît ses limites, les déclare, construit une protection proportionnée à son impact, accorde à l'utilisateur une porte de sortie praticable, et ne convertit pas la faiblesse de ses ressources en fardeau caché pour l'agriculteur. Il est tolérable que l'export ne soit pas instantané ; il n'est pas tolérable qu'il n'existe pas du tout. Il est acceptable de prendre en charge un nombre limité de formats ; il n'est pas acceptable de livrer un fichier sans unités ni signification. Il est acceptable de donner une explication approximative honnête ; il n'est pas acceptable de donner un compte rendu fabriqué qui laisse entendre une certitude inexistante. Il est acceptable de supprimer les sauvegardes selon un cycle déclaré ; il n'est pas acceptable d'utiliser les données indéfiniment sans divulgation. Il est acceptable que certaines fonctions non critiques s'arrêtent lorsque le réseau tombe ; il n'est pas acceptable de laisser une opération sensible sans état sûr. Il est acceptable que l'entreprise soit petite ; il n'est pas acceptable que sa responsabilité soit plus petite que le préjudice que sa technologie peut causer. Ainsi, le critère de la gouvernance n'est pas une question idéaliste du type : « La plateforme a-t-elle tout mis en œuvre ? », mais une question plus professionnelle et plus juste : A-t-elle fait ce qui était proportionné à son risque, a-t-elle honnêtement déclaré ce qu'elle ne pouvait pas faire, et a-t-elle restreint la portée de sa promesse lorsqu'elle était incapable de protéger l'utilisateur ? Car la plateforme mûre n'est pas celle qui prétend que les contraintes ont disparu, mais celle qui transforme les contraintes en limites de conception déclarées. Et si elle ne peut construire la route entière, elle doit signaler où la route s'arrête, et placer un panneau clair avant cette fin — et non laisser l'agriculteur découvrir le bord après que ses enregistrements, ses décisions et son travail sont déjà devenus dépendants du système. Conclusion La petite plateforme n'est pas dispensée de la sécurité, de la transparence et des droits fondamentaux, mais elle n'est pas tenue de reproduire l'architecture d'une multinationale. Elle peut simplifier l'intégration, l'explication, la vitesse de transfert et l'étendue de l'assistance ; elle ne peut pas simplifier la vérité, la sécurité, l'accès aux données essentielles, ni la capacité d'un être humain à interrompre une décision dangereuse. Et la règle la plus forte que l'on puisse fixer à cet égard est la suivante : Lorsqu'une plateforme n'est pas en mesure de gouverner une fonction à haut risque, la solution professionnelle consiste à réduire le périmètre de cette fonction ou à maintenir un humain dans la décision — et non à abaisser le niveau de protection.

6. La transition ne profite pas à tous de la même manière

Les bénéfices et les charges de la technologie n'atteignent pas au même degré toutes les personnes qui travaillent sur l'exploitation. Le propriétaire peut y gagner en réduction des coûts ou en heures de travail, tandis que l'ouvrier a besoin d'une formation supplémentaire, se trouve placé sous une surveillance plus étroite, voire perd une partie de ses tâches. L'entreprise peut tirer profit des données qu'elle collecte, alors que l'agriculteur ne peut pas en obtenir une copie exploitable. Une plateforme peut faciliter l'accès aux services de conseil pour ceux qui savent lire et utiliser des applications, tout en excluant ceux qui dépendent d'une explication orale ou ne disposent pas d'une bonne connexion internet. Il ne suffit donc pas de demander : « Le résultat de l'exploitation s'est-il amélioré ? » Il faut aussi demander : qui en a bénéficié ? Qui en a supporté le coût ou a perdu une possibilité d'emploi ? Et l'impact a-t-il différé selon la taille de l'exploitation, la localisation, la langue et la nature du travail, ou entre les femmes et les hommes ? Cela ne signifie pas rejeter l'automatisation, mais la gérer équitablement : identifier les tâches qui vont changer, dispenser une formation adaptée, proposer des modes d'utilisation appropriés aux différents groupes, répartir équitablement les gains de productivité et établir une trajectoire claire pour accompagner ceux dont le rôle est affecté. C'est la perspective contextuelle et globale que met en avant le rapport de l'Organisation des Nations unies pour l'alimentation et l'agriculture sur l'automatisation agricole [SRC031].

7. La technologie la plus adaptée n'est pas toujours la plus complexe

La maturité d'une solution agricole ne se mesure pas au nombre d'algorithmes qu'elle contient ni à leur complexité, mais à sa capacité d'améliorer une décision précise au bon moment et dans des conditions réelles d'exploitation. Une règle simple et transparente qui rappelle à l'agriculteur quand observer la culture en fonction du stade de développement et de la météo peut être plus utile qu'un modèle profond exigeant une connectivité constante, des données abondantes et une maintenance indisponible localement. La solution la plus simple, qui fonctionne de manière constante et dont l'utilisateur comprend la logique, peut avoir plus de valeur qu'un système avancé qui tombe en panne précisément au moment où l'on en a besoin. Le problème peut ne pas résider du tout dans l'absence d'intelligence artificielle. Si une décision est retardée parce que l'échantillon de sol parvient tardivement au laboratoire, ou parce que le résultat ne revient pas à l'agriculteur sous une forme intelligible, alors améliorer le prélèvement et le transport des échantillons et relier le laboratoire à l'exploitation peut avoir plus d'impact que de construire un modèle qui tente de deviner le résultat à partir de données incomplètes. La technologie appropriée commence par le diagnostic de l'endroit où le cheminement de la décision se rompt, et non par le choix de l'outil le plus enthousiasmant suivi de la recherche d'un rôle à lui attribuer. Le niveau de complexité est donc déterminé par la valeur de l'information, la conséquence de l'erreur, la rapidité de décision requise, la qualité des données, la capacité de compréhension des utilisateurs, ainsi que le coût d'exploitation et de maintenance. Le système peut être construit par paliers : une règle claire qui traite les cas courants, un modèle probabiliste qui filtre les cas ambigus et les classe par risque, puis un spécialiste qui examine les décisions sensibles ou celles susceptibles d'entraîner un coût substantiel ou un dommage irréversible. Dans le diagnostic d'une maladie des cultures, par exemple, le système pourrait rappeler à l'agriculteur quand observer la parcelle, puis utiliser un modèle pour classer les images selon le degré de suspicion, tout en laissant la confirmation du diagnostic et le choix d'un traitement sensible à un ingénieur agronome ou à une autorité compétente. Cette conception hybride ne diminue pas la valeur de l'intelligence artificielle ; elle la place là où son bénéfice est le plus grand et ses limites maîtrisables. Elle économise le temps du spécialiste, accélère l'accès aux cas prioritaires et préserve en même temps l'examen humain là où la conséquence de l'erreur est élevée. Une conception intelligente n'utilise pas le maximum de technologie possible ; elle en utilise la quantité que la décision exige, n'ajoutant de la complexité que lorsqu'il est démontré que son bénéfice dépasse son coût et ses risques.

8. Comment savons-nous que la transition a réellement eu lieu ? La mesure avant, pendant et après la mise en œuvre

Il ne suffit pas que la technologie fonctionne pour déclarer la transition réussie ; il faut démontrer qu'elle a modifié une décision importante et produit un meilleur résultat que celui qui serait survenu sans elle. La mesure commence donc avant l'installation du système, se poursuit pendant son fonctionnement, puis revient après la mise en œuvre à la question fondamentale : qu'est-ce qui a changé, pour qui, et à quel coût et quel risque ? Avant la mise en œuvre, la manière actuelle de travailler est documentée comme situation de référence : comment la décision est-elle prise ? Combien de temps prend-elle ? Combien coûte-t-elle ? Quelles erreurs ou pertes se répètent ? Et le résultat diffère-t-il selon les parcelles, les saisons et les catégories d'utilisateurs ? L'objectif principal est ensuite défini à l'avance — réduire la consommation totale d'eau, par exemple, ou diminuer les pertes de récolte, détecter plus tôt une maladie, ou améliorer le bénéfice net. L'ampleur de l'amélioration qui vaudra succès est également précisée, de même que les effets qui ne peuvent être acceptés ; augmenter le rendement n'est pas un succès s'il s'accompagne d'un épuisement inacceptable de l'eau ou d'une hausse du risque ou du coût qui dépasse le bénéfice. Pendant la mise en œuvre, la mesure ne se limite pas à l'exactitude du modèle mais suit toute la chaîne opérationnelle : les données sont-elles arrivées à temps ? Représentaient-elles l'ensemble des parcelles et des conditions ciblées ? À quelle fréquence le capteur ou la connexion sont-ils tombés en panne ? Combien de recommandations sont parvenues à l'utilisateur, et combien ont été comprises et suivies d'effet ? À quelle fréquence le système a-t-il refusé d'émettre une recommandation en raison de données manquantes ou d'une faible confiance ? Quand un humain est-il intervenu pour modifier ou interrompre une décision ? Et pourquoi certains agriculteurs n'ont-ils pas utilisé le système ? De telles informations révèlent si la défaillance se situe dans l'algorithme, les données, l'infrastructure, la conception du service ou la capacité de l'utilisateur à exécuter ce qui lui est proposé. Les jours d'interruption, les relevés corrompus et les cas où l'utilisateur a rejeté la recommandation ne doivent pas être écartés comme des détails agaçants ; ils font partie de la performance du système dans le monde réel. Une plateforme ne se juge pas seulement aux moments où elle fonctionne, mais à sa capacité à maintenir un service utile et sûr lorsque les conditions changent ou que certains de ses composants défaillent. Après la mise en œuvre, les résultats sont comparés à la situation de référence et, chaque fois que possible, à un groupe ou à une période de comparaison appropriés, en tenant compte des différences de météo, de prix, de superficie et de culture. Trois niveaux de réussite doivent être distingués : la réussite du modèle lors des tests, la réussite du système à délivrer et à rendre opérationnelle la recommandation, et la réussite de l'intervention à améliorer le résultat agricole, économique ou social. Un modèle peut être exact alors que ses recommandations arrivent en retard ; celles-ci peuvent arriver à temps alors que l'intervention n'est pas disponible ; elles peuvent être exécutées alors que leur coût dépasse la valeur de ce qu'elles ont permis d'économiser. Enfin, on examine si le bénéfice a été réellement réalisé ou si une partie du coût s'est simplement déplacée ailleurs ou vers une autre partie prenante. Le travail au champ peut diminuer tandis que la charge de saisie des données augmente ; l'eau par tonne peut baisser tandis que le prélèvement total augmente parce que la superficie cultivée s'est étendue ; les coûts d'exploitation sur l'exploitation peuvent baisser tandis que les frais d'abonnement, de maintenance et de connectivité grimpent ; le propriétaire peut bénéficier de l'automatisation tandis que l'ouvrier supporte une formation supplémentaire ou une surveillance plus étroite. L'énergie informatique, les équipements et les déchets électroniques sont comptabilisés là où ils comptent à l'échelle du projet, et non comme une ligne formelle à mesurer en détail dans chaque petite application. Ce cadre n'exige pas une étude académique coûteuse pour chaque projet. Dans un essai de faible ampleur, une situation de référence claire, un ensemble limité d'indicateurs, un registre des interruptions et des interventions humaines, ainsi qu'une comparaison rigoureuse après mise en œuvre peuvent suffire. Mais plus le coût du projet est élevé, plus le nombre de personnes concernées est large, ou plus la gravité de ses décisions est grande, plus l'évaluation doit devenir rigoureuse et indépendante. Le but n'est pas de multiplier les rapports, mais d'empêcher la technologie de juger elle-même de son succès à l'aune d'un indicateur qu'elle choisit après la fin de l'essai. Un exemple pratique : un système intelligent de gestion de l'irrigation Les trois étapes peuvent être illustrées pour le lecteur par cet exemple : Avant la mise en œuvre Avant l'installation du système, l'exploitation consigne :

• L'eau totale utilisée dans la saison, et non la seule eau par hectare.
• Le rendement et la qualité pour chaque parcelle.
• La consommation d'énergie et le coût du pompage.
• Le nombre d'heures de main-d'œuvre affectées à l'irrigation.
• Les cas d'irrigation retardée ou les occurrences de stress hydrique.
• La variation des résultats entre parcelles et selon les stades climatiques.
• Le coût de la manière actuelle de travailler.

L'objectif est ensuite défini à l'avance : réduire l'eau totale utilisée tout en maintenant le rendement et la qualité, et sans augmentation de l'énergie ou du coût dépassant la valeur des économies réalisées. Avec cette définition, le projet ne pourra pas ultérieurement se déclarer réussi au moyen d'un indicateur secondaire qui se serait amélioré alors que l'objectif initial a échoué. Pendant la mise en œuvre L'exploitation consigne :

• La proportion du temps pendant laquelle les capteurs ont fonctionné correctement.
• Les relevés manquants ou invraisemblables.
• Les cas de coupure de réseau ou d'électricité.
• Le délai entre la collecte des données et l'émission de la recommandation.
• Les recommandations arrivées au bon moment.
• Les cas dans lesquels le système a refusé d'émettre une recommandation faute de données suffisantes.
• Les fois où l'agriculteur a ajusté le calendrier d'irrigation et le motif de l'ajustement.
• Les jours où le système est revenu à un fonctionnement manuel.
• Les parcelles ou les utilisateurs que le service n'a en réalité pas couverts.

Si la consommation d'eau ne baisse pas, ces registres peuvent révéler si le problème réside dans la logique de la recommandation, dans sa transmission, dans sa non-exécution, ou dans une défaillance des capteurs pendant les jours critiques. Après la mise en œuvre Les résultats sont comparés à la situation de référence, en tenant compte des différences de pluviométrie, de température, de superficie et de culture. Puis sont passés en revue les éléments suivants :

• La quantité totale d'eau.
• Le rendement et la qualité.
• Le bénéfice net après frais du système, énergie et maintenance.
• Les heures de main-d'œuvre et de formation.
• Le nombre d'épisodes de stress hydrique.
• L'impact des interruptions.
• La variation du bénéfice entre parcelles et entre utilisateurs.
• La capacité de l'exploitation à poursuivre si le service cesse.

Si la consommation d'eau a baissé parce que la saison a été plus pluvieuse, le résultat ne peut pas être attribué entièrement au système. Si le rendement a augmenté mais que le coût du service a dépassé sa valeur, il y a succès agronomique partiel mais pas succès économique. Et si les résultats ne se sont améliorés que dans les parcelles connectées, ils ne peuvent pas être généralisés à tous les agriculteurs.

9. Le test de la transition véritable

Toute organisation peut utiliser les questions suivantes comme point de contrôle décisionnel :

• Quel résultat a changé, et combien de temps le changement a-t-il duré ?
• La comparaison a-t-elle été faite avec la pratique réelle ou avec une référence initiale faible et artificielle ?
• Le bénéfice s'est-il maintenu dans une autre saison, un autre lieu ou une autre catégorie d'utilisateurs ?
• Quel a été le coût total, et qui l'a payé ?
• Quel dommage ou risque nouveau est apparu ?
• La position de l'ouvrier et de l'agriculteur s'est-elle améliorée, ou leur capacité de contrôle s'est-elle réduite ?
• La fonction peut-elle se poursuivre si le fournisseur change ou si le service est interrompu ?
• Quelles connaissances locales sont entrées dans la conception, et qu'a-t-on perdu du fait de la standardisation ?

Résumé du chapitre

La transition agricole est une amélioration fiable et équitable d'un cheminement décisionnel et de son résultat, et non la simple prolifération d'appareils. Elle se mesure conjointement à la productivité, à la résilience, aux ressources, à l'économie, au travail et à la capacité d'action et de contrôle, et elle se conçoit dès le départ autour des arbitrages, de la défaillance et de la sortie. À ce moment-là, l'intelligence artificielle devient un instrument de transition ; avant cela, elle peut n'être qu'une couche numérique posée sur un problème qui n'a jamais été compris.

Notes sur les éléments de preuve

les revues [SRC001][SRC002][SRC003] étayent la cartographie générale des bénéfices et des contraintes. [SRC031] a servi à cadrer l'automatisation inclusive, [SRC032] les droits sur les données et la portabilité des données, [SRC034] la résilience, et [SRC036] le caractère contextuel de la faisabilité économique et environnementale. Les exemples analytiques de ce chapitre relèvent de l'interprétation éditoriale et ne sont pas les résultats de nouvelles expériences.