Machine learning pour prédire l’irrigation : tutoriel agritech 2026

📍 Article principal : Agritech IoT Afrique de l’Ouest 2026

Introduction

Pour la coopérative maraîchère ouest-africaine du pilier, équiper le terrain en capteurs n’est qu’une étape. Transformer ces données brutes en décisions actionnables (irriguer ou non, quand, combien) demande une couche analytique. Sans modèle prédictif, les agriculteurs interprètent eux-mêmes les valeurs d’humidité du sol selon leur intuition — résultats variables et souvent sous-optimaux. La mise en place d’un modèle de machine learning simple qui prédit les besoins d’irrigation des prochaines 24-48h à partir de l’historique des mesures et des prévisions météo a permis de réduire la consommation d’eau de 25 % tout en améliorant les rendements de 15 %. Ce tutoriel décrit la construction complète : exploration des données, feature engineering, entraînement scikit-learn, déploiement en production, et intégration au dashboard SvelteKit existant.

Prérequis

• Plusieurs mois de données capteurs collectées (minimum 2 saisons agricoles)
• VPS ou poste de travail avec Python 3.11+
• Connaissances de base Python et Pandas
• Notions élémentaires de statistiques et machine learning (utile mais pas indispensable)
• Niveau : intermédiaire avancé — Temps : 4-6 heures

Étape 1 — Exploration des données

Avant de construire un modèle, comprendre les données disponibles est crucial. Charger un échantillon de quelques semaines depuis TimescaleDB dans un Jupyter Notebook ou un script Python permet de visualiser les patterns, identifier les valeurs aberrantes, et formuler des hypothèses sur les variables prédictives. Cette phase exploratoire révèle souvent des problèmes de qualité de données qu’il faut corriger avant l’entraînement (capteurs en panne, valeurs aberrantes, plages de mesure incohérentes).

Pour le cas d’usage irrigation, les variables typiques disponibles sont : humidité du sol à différentes profondeurs, température et humidité de l’air, pluviométrie cumulée, radiation solaire. La variable cible (à prédire) est typiquement l’évolution de l’humidité du sol dans les prochaines 24-48 heures, ou plus directement la décision binaire « irriguer demain ou non » si on a un historique de décisions humaines correctes.

import pandas as pd
import psycopg2

conn = psycopg2.connect(dsn="postgres://reader:pass@db/agritech")
df = pd.read_sql_query("""
    SELECT capteur_id, type_mesure, valeur, ts
    FROM mesures
    WHERE ts > NOW() - INTERVAL '90 days'
""", conn)

# Pivot pour avoir une colonne par type de mesure
pivot = df.pivot_table(
    index=['capteur_id', 'ts'],
    columns='type_mesure',
    values='valeur',
    aggfunc='mean'
).reset_index()

print(pivot.describe())
print(pivot.isna().sum())

Cette analyse exploratoire révèle la couverture temporelle des données, les valeurs typiques de chaque mesure, et les éventuels trous de données. Pour le cas pratique, on observe souvent que les capteurs envoient bien des mesures toutes les 15 minutes en saison sèche mais espacées en saison des pluies (économie d’énergie). Cette irrégularité est à prendre en compte dans le feature engineering.

Étape 2 — Feature engineering

Le feature engineering est l’art de construire des variables explicatives pertinentes à partir des données brutes. Pour la prédiction d’irrigation, plusieurs features dérivées améliorent significativement la performance des modèles. Premièrement, des moyennes glissantes (humidité moyenne sur 24h, sur 7 jours) capturent les tendances. Deuxièmement, des dérivées temporelles (vitesse de baisse de l’humidité du sol) signalent l’évaporation rapide. Troisièmement, des features calendaires (jour de l’année, saison) capturent les patterns saisonniers. Quatrièmement, des features météo prévues sur 24-48h ajoutent l’anticipation.

Cette phase d’enrichissement transforme typiquement les 5-10 variables brutes en 30-50 features dérivées. Cette explosion peut sembler excessive mais améliore considérablement la qualité du modèle. Les algorithmes modernes (Random Forest, Gradient Boosting) gèrent bien les espaces de features riches sans sur-apprentissage si l’on dispose de suffisamment de données d’entraînement.

# Feature engineering pour modèle irrigation
def enrichir_features(df):
    df = df.sort_values('ts')
    # Moyennes glissantes
    df['hum_sol_mean_24h'] = df['hum_sol'].rolling('24h', on='ts').mean()
    df['hum_sol_mean_7d'] = df['hum_sol'].rolling('7d', on='ts').mean()
    # Dérivées
    df['hum_sol_delta_6h'] = df['hum_sol'] - df['hum_sol'].shift(24)  # 6h * 4 mesures/h
    # Features calendaires
    df['heure'] = df['ts'].dt.hour
    df['jour_annee'] = df['ts'].dt.dayofyear
    df['saison_pluies'] = df['jour_annee'].between(150, 280).astype(int)
    return df.dropna()

features_pret = enrichir_features(pivot)

Ces features dérivées capturent des informations cruciales que les valeurs instantanées des capteurs seules ne révèlent pas. La qualité du feature engineering distingue souvent un modèle médiocre d’un modèle utilisable en production. Cette phase mérite d’investir le temps nécessaire avant de basculer sur l’entraînement.

Étape 3 — Entraînement avec scikit-learn

Pour le premier modèle, scikit-learn offre des algorithmes simples mais efficaces. Random Forest est un bon point de départ : robuste aux valeurs manquantes, peu sensible au choix d’hyperparamètres, gère naturellement les features non-linéaires. Pour la prédiction binaire « irriguer demain ou non », on entraîne un classifieur. Pour la prédiction continue de l’humidité future, un régresseur. Les deux suivent le même pattern API.

Le découpage en jeux d’entraînement et de test est crucial pour évaluer la performance réelle du modèle. Pour les séries temporelles, ne pas faire de split aléatoire mais un split temporel (premières 80 % des données pour entraînement, dernières 20 % pour test). Cette discipline évite la fuite d’information temporelle qui surévaluerait artificiellement la performance.

from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report, roc_auc_score

# Split temporel
train = features_pret[features_pret['ts'] < '2026-01-01']
test = features_pret[features_pret['ts'] >= '2026-01-01']

cols_features = ['hum_sol', 'hum_sol_mean_24h', 'hum_sol_delta_6h', 'temp_air', 'hum_air', 'pluie_24h', 'saison_pluies', 'heure']
X_train, y_train = train[cols_features], train['besoin_irrigation']
X_test, y_test = test[cols_features], test['besoin_irrigation']

modele = RandomForestClassifier(n_estimators=100, max_depth=10, random_state=42)
modele.fit(X_train, y_train)

y_pred = modele.predict(X_test)
print(classification_report(y_test, y_pred))
print(f'AUC: {roc_auc_score(y_test, modele.predict_proba(X_test)[:,1]):.3f}')

Pour un premier modèle agritech typique, on obtient des AUC entre 0.80 et 0.92 selon la qualité des données et la quantité d’historique disponible. Au-delà de 0.85, le modèle est utilisable en production avec des décisions plus fiables que l’intuition humaine moyenne. Pour aller plus loin, expérimenter Gradient Boosting (LightGBM ou XGBoost) offre souvent quelques points de performance supplémentaire au prix d’une complexité accrue.

Étape 4 — Déployer le modèle en production

Une fois le modèle entraîné et validé, le déployer en production permet aux applications dashboard de l’interroger pour les prédictions du jour. Plusieurs patterns coexistent. Le plus simple : sauvegarder le modèle entraîné en pickle, charger côté API, exposer un endpoint qui prend les features actuelles et retourne la prédiction. Pour un VPS OVH SBG ou Scaleway PAR1 (alternative Hetzner pour la souveraineté), une simple API Flask ou FastAPI tourne en quelques Mo de RAM.

Le modèle Random Forest typique pour agritech tient en 5-50 Mo selon le nombre d’arbres. Le rechargement à chaque requête API serait inefficace, on charge donc en mémoire au démarrage. Pour les mises à jour périodiques (réentrainement mensuel), on régénère le pickle et redémarre le service. Cette simplicité est suffisante pour la majorité des cas d’usage agritech.

# API FastAPI exposant le modèle
from fastapi import FastAPI
import joblib
import pandas as pd

app = FastAPI()
modele = joblib.load('modele_irrigation.pkl')

@app.post('/predict')
def predict(features: dict):
    df = pd.DataFrame([features])
    proba = modele.predict_proba(df)[0][1]
    return {
        'besoin_irrigation': bool(proba > 0.5),
        'probabilite': round(proba, 3),
        'recommandation': 'IRRIGUER' if proba > 0.7 else ('SURVEILLER' if proba > 0.4 else 'OK')
    }

Avec cette API en place, le dashboard SvelteKit peut interroger directement le modèle au moment où l’agriculteur consulte sa parcelle. Le résultat s’affiche en quelques centaines de millisecondes, en temps réel. Pour les structures qui ont plusieurs parcelles, on peut aussi pré-calculer toutes les prédictions chaque matin et les stocker en cache pour une consultation instantanée.

Étape 5 — Réentraînement périodique

Un modèle ML se dégrade avec le temps si les conditions sous-jacentes évoluent (changement climatique, nouvelles cultures, modifications du sol). Pour maintenir la performance, on réentraîne périodiquement avec les données accumulées récentes. Cette discipline de MLOps est essentielle pour les modèles agritech qui couvrent plusieurs cycles agricoles.

Une cron mensuelle qui charge les données récentes, refait le feature engineering, ré-entraîne le modèle, et le re-déploie automatiquement maintient le système à jour sans intervention humaine régulière. Pour la sécurité, comparer la performance du nouveau modèle à l’ancien sur le jeu de test commun avant de basculer — ne pas remplacer un bon modèle par un moins bon en cas de problème dans les nouvelles données.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Trois aspects pratiques. Premièrement, pour les coopératives ouest-africaines qui démarrent leur projet IoT, attendre 2 saisons agricoles complètes avant d’investir dans le ML : sans suffisamment de données d’historique, les modèles sous-performent. Démarrer avec des règles métier simples (seuils d’humidité fixes selon saison) puis basculer en ML quand les données accumulent. Deuxièmement, l’hébergement du modèle ML peut se faire sur un VPS OVH GRA ou un Scaleway PAR pour la souveraineté française. Pour les structures qui veulent absolument héberger en Afrique, des fournisseurs locaux comme Africloud Casablanca ou Sénégal Numérique SA proposent des VPS adaptés. Troisièmement, pour les modèles plus avancés (deep learning sur imagerie satellite, par exemple), envisager les services cloud GPU de Scaleway ou Vultr en mode pay-per-use plutôt qu’investir dans du matériel GPU dédié — flexibilité économique pour des usages occasionnels.

Pour les compétences nécessaires, plusieurs écoles d’ingénieurs ouest-africaines forment désormais aux data sciences (École Polytechnique de Thiès, INPHB Yamoussoukro, Université Cheikh Anta Diop). Les structures qui veulent monter en compétence interne peuvent recruter ou collaborer avec ces formations. Pour les besoins ponctuels, des consultants data scientists indépendants à Dakar, Abidjan, Cotonou interviennent à des tarifs compétitifs comparés aux consultants européens.

Tutoriels frères

• Déployer ChirpStack
• Construire des capteurs LoRaWAN
• Dashboard Grafana et SvelteKit

Pour aller plus loin

• 🔝 Pilier : Agritech IoT Afrique 2026
• Doc : scikit-learn · LightGBM

FAQ

Combien de données pour entraîner un modèle utile ?
Minimum 2 saisons agricoles complètes (1 an) de mesures denses. Idéalement 3-5 ans pour capturer la variabilité inter-annuelle.

Faut-il du GPU pour ces modèles ?
Non pour Random Forest et Gradient Boosting classiques. CPU standard suffit largement. GPU pertinent uniquement pour deep learning sur imagerie ou volumes massifs.

Comment expliquer les prédictions aux agriculteurs ?
Utiliser SHAP pour visualiser quelles features influencent chaque prédiction. Pour les agriculteurs : « Le modèle prédit irrigation car humidité sol basse + pas de pluie prévue 48h ».

Quelle alternative à scikit-learn pour de gros volumes ?
Spark MLlib pour distribué, ou XGBoost/LightGBM/CatBoost pour gradient boosting performant. Tous restent accessibles en Python.

Évaluer l’impact réel sur le terrain

Au-delà des métriques statistiques classiques (AUC, accuracy, F1), évaluer l’impact réel d’un modèle ML en production demande un dispositif spécifique. Trois métriques métier essentielles. Premièrement, l’économie d’eau mesurée comparée à la pratique antérieure : compteur d’irrigation avant et après mise en place du modèle. Cette mesure directe valide ou invalide le ROI promis. Deuxièmement, le rendement final des cultures : le ML est utile s’il améliore le rendement, pas seulement s’il prédit bien. Comparer rendements parcelles avec et sans ML sur les mêmes saisons. Troisièmement, la satisfaction et l’adoption par les agriculteurs eux-mêmes : un modèle techniquement bon mais que les agriculteurs ignorent ou contournent ne crée aucune valeur. Mesurer le taux d’adoption des recommandations et collecter les feedbacks qualitatifs réguliers.

Cette discipline d’évaluation impact doit s’intégrer dès la conception du projet. Définir avec la coopérative les indicateurs de succès et les méthodes de mesure avant de lancer le ML évite les déceptions ultérieures où chacun a en tête des critères différents. Pour les bailleurs qui financent ces projets, ces métriques sont aussi la base du reporting et conditionnent les renouvellements de financement.

Éthique et limites de l’IA en agriculture

Au-delà de la technique, plusieurs considérations éthiques accompagnent le déploiement de l’IA en agriculture ouest-africaine. Premièrement, la dépendance technologique : un système qui guide totalement les décisions risque de déposséder les agriculteurs de leur savoir-faire ancestral. Pour éviter cela, positionner le ML comme aide à la décision plutôt que substitution, garder l’humain dans la boucle sur les choix critiques. Deuxièmement, la propriété des données : qui possède les données capteurs collectées ? La coopérative, l’éditeur de la solution, le fournisseur cloud ? Clarifier ces aspects contractuels en amont évite les conflits ultérieurs. Troisièmement, l’inclusion : un système qui exclut les petits producteurs sans smartphone ou sans formation creuse les inégalités au lieu de les réduire. Concevoir des modes d’accès dégradés (alertes SMS minimales, conseils via radio communautaire) garantit l’inclusion universelle.

Pour les développeurs et opérateurs ouest-africains qui se positionnent sur ce segment, intégrer ces dimensions éthiques dès la conception construit des solutions plus durables et mieux adoptées. C’est aussi un argument différenciant face à des solutions externes parachutées qui négligent ces aspects sociaux. La technique sans l’humain ne change rien durablement.