Nom de code : feature flipping

Le but

Cet enabler concernait le modèle Cropwin qui simule à l’échelle de la parcelle la croissance du maïs, du soja et du blé en fonction de la météorologie, de l’itinéraire technique cultural (le fameux « ITK ») et des caractéristiques du sol. Ce modèle donne en sortie de nombreuses variables comme le rendement, mais aussi la phénologie et les niveaux de stress en eau et en azote. Il a en effet été conçu pour aider les techniciens et les agriculteurs à piloter leur irrigation et leur fertilisation afin d’optimiser leurs revenus et minimiser les pertes d’intrants, en fonction du climat de l’année.

Très tôt, ce modèle a aussi été utilisé pour d’autres usages que celui pour lequel il a été conçu, comme pour prédire uniquement le rendement, parfois à des échelles bien au-delà de la parcelle (comme la commune, voire le département ou des unités géographiques équivalentes selon les pays).

De fil en aiguille, les contextes d’utilisation se sont multipliés, entrainant une diversification des interfaces pour compléter les entrées nécessaires au modèle d’origine (profondeur du sol, texture, paramètres variétaux, … je ne vais pas toutes les citer). Cet interfaçage était géré par les équipes d’informaticiens.

L’idée générale de cet enabler était de rapatrier au plus près du modèle la connaissance des différentes interfaces, pour gagner en fluidité et en lisibilité dans notre travail. En effet, les modélisateurs responsables du modèle sont les mieux placés pour gérer la connaissance agronomique.

En image, cela donnerait ceci :

Avant :

Après :

En bref, cela permet de gérer plus facilement les différents contextes d’utilisation du modèle, d’où le nom de « feature flipping ».

Quelles ont été les principales étapes de sa réalisation ?

Le premier travail a consisté à identifier les paramètres utilisateurs, par défaut, obligatoires et optionnels par contexte d’utilisation. Une des difficultés qui a dû être gérée était que des paramètres peuvent être obligatoires dans certains contextes et pas dans d’autres.

Les paramètres utilisés par défaut selon les contextes ont ensuite été rapatriés pour être lus directement par le modèle.

Le modèle a été adapté à l’avenant, avec de nouveaux tests fonctionnels et unitaires, et le code qui ne servait plus a été nettoyé (surtout côté IT).

Pour vérifier que rien n’avait changé, des simulations ont été réalisées avant et après les développements d’adaptations du « feature flipping », pour vérifier que les résultats restaient identiques (un « before/after » dans le jargon). Evidemment, cela n’a pas fonctionné du premier coup, ce qui montre bien l’utilité de cette précaution. Ce travail a été réalisé par séquences, sur un an, en planifiant des moments dédiés que les personnes impliquées dégageaient de leurs autres projets (note si vous lisez trop vite : le travail n’a pas pris un an équivalent temps plein !). Il a fait l’objet de pairing entre des modélisateurs et des informaticiens d’équipes différentes. Ce genre de pratiques a pour vertu de mélanger les métiers, pour voir d’autres façons de travailler et mieux connaître le vocabulaire spécifique de chacun.

Quelle pourrait être la suite ?

Ce travail va faciliter l’évaluation de nouvelles améliorations du modèle (rajout de variétés, modification d’un formalisme par exemple) pour tous les contextes. Cette précaution est en effet nécessaire pour s’assurer que l’amélioration du modèle dans un certain contexte ne provoque pas de dégradation dans d’autres. Il permet donc de faire évoluer le modèle Cropwin au mieux pour servir les besoins des clients.