L’IoT agricole promet beaucoup : capteurs dans les parcelles, suivi des troupeaux, équipements connectés, irrigation pilotée. Mais entre la promesse et un produit qui fonctionne au champ, il y a un fossé que les articles de tendances ne racontent jamais : les zones blanches, les batteries qui doivent tenir une saison, la poussière, le gel, et des utilisateurs qui manipulent l’application avec des gants, au soleil, entre deux interventions.
Chez Playmoweb, nous connectons depuis plus de 12 ans des applications mobiles et web à des objets de toutes natures, et l’agriculture fait partie de nos terrains de jeu historiques aux côtés du médical et de l’industrie. Cet article partage ce que ces projets nous ont appris : les contraintes qui font la différence, les choix techniques qui tiennent la route, et les pièges qui condamnent un produit agricole avant même son déploiement.
Sommaire
Un capteur en usine vit dans un environnement maîtrisé : alimentation électrique, Wi-Fi, température régulée, techniciens à proximité. Un capteur agricole vit dehors, loin de tout. Cette différence change chaque décision de conception.
L’environnement d’abord : humidité, amplitudes thermiques, poussière, chocs. L’indice de protection (IP67 et au-delà) et la tenue mécanique ne sont pas des options mais des prérequis, et ils pèsent sur le coût unitaire du hardware. La distance ensuite : les parcelles s’étendent sur des hectares, souvent sans couverture réseau fiable, et personne ne passera changer une pile chaque semaine. La saisonnalité enfin : un produit agricole se déploie et se prouve au rythme des campagnes. Rater la fenêtre de la saison, c’est attendre un an pour valider votre produit en conditions réelles. Cette contrainte de calendrier doit structurer votre planning projet dès le cadrage.
Dernier point, trop souvent oublié : l’utilisateur. L’agriculteur utilise votre application en extérieur, en plein soleil, parfois avec des gants, entre deux tâches. Gros boutons, contrastes élevés, parcours courts, mode hors ligne : l’UX agricole est une discipline à part entière, et c’est souvent elle qui fait la différence entre un produit adopté et un produit abandonné.
Le choix du protocole est la première décision structurante, et l’une des plus coûteuses à corriger après coup. Nous avons publié notre grille de lecture complète dans notre comparatif BLE, LoRa, Matter ou cellulaire ; voici sa déclinaison agricole.
| Scénario agricole | Protocole recommandé | Pourquoi |
|---|---|---|
| Capteurs fixes en parcelle (sol, météo, irrigation) | LoRa | Portée kilométrique, très faible consommation, données peu volumineuses |
| Équipements mobiles (matériel, remorques, troupeaux) | Cellulaire LTE-M / NB-IoT | Couverture nationale, pas de passerelle à installer |
| Relevé de proximité par le smartphone | BLE | L’agriculteur passe à portée, l’app collecte, zéro abonnement |
| Bâtiments d’élevage équipés | LoRa privé ou Wi-Fi | Passerelle locale, volumes plus élevés possibles |
Deux réalités de terrain à intégrer. La couverture réelle d’abord : LoRa opéré et NB-IoT ont des cartes de couverture théoriques qui ne valent rien face à un test terrain sur les sites cibles. Nous testons systématiquement avant de figer l’architecture. L’échéance réseau ensuite : l’arrêt de la 2G a commencé chez Orange fin 2025, SFR et Bouygues Telecom couperont la leur fin 2026. Tout équipement agricole encore en 2G doit migrer vers LTE-M ou NB-IoT : c’est une contrainte pour les parcs existants, et une opportunité pour les produits neufs bien conçus.
Sur un capteur de parcelle, l’autonomie se compte en mois, idéalement en saisons. C’est la contrainte maîtresse : elle dicte le protocole (LoRa consomme beaucoup moins que le cellulaire), la fréquence de remontée des données (toutes les heures plutôt qu’en continu), et même le firmware (réveils courts, veille profonde, traitement local pour ne transmettre que l’essentiel).
Ce dernier point rejoint l’IA embarquée : traiter le signal sur le capteur ou la passerelle pour n’envoyer que des événements qualifiés (seuil dépassé, anomalie détectée) plutôt que des données brutes économise à la fois la batterie et les coûts de transmission. Sur un parc de plusieurs centaines de capteurs, cette architecture change le modèle économique du produit.
Notre règle de conception : chiffrer le budget énergétique du device avant de figer l’électronique. Un prototype qui tient deux semaines sur batterie ne deviendra jamais un produit qui tient une saison par simple optimisation logicielle.
Un capteur qui remonte des courbes n’a aucune valeur en soi. La valeur naît quand la donnée devient une décision : irriguer ou pas, intervenir ou pas, vendre ou attendre. C’est le rôle de la chaîne logicielle : plateforme cloud qui agrège et traite, application qui restitue et alerte.
Trois principes guident nos choix sur cette chaîne. La restitution doit être actionnable : une alerte claire vaut mieux qu’un dashboard exhaustif. Le mode hors ligne est obligatoire : l’application doit fonctionner au champ et synchroniser au retour du réseau. Et la plateforme doit être pensée pour l’interopérabilité : les données agricoles alimentent de plus en plus d’écosystèmes tiers (coopératives, outils de gestion parcellaire, conseillers), et les architectures fermées deviennent un handicap commercial autant que réglementaire.
Côté hébergement, nous privilégions des solutions souveraines comme Scaleway IoT Hub, hébergé en France : pour des données d’exploitation agricole, la souveraineté devient un argument de confiance auprès des utilisateurs et des filières.
L’équipement agricole connecté est en première ligne des nouveaux textes européens. Le Data Act, applicable depuis septembre 2025, cite explicitement les équipements agricoles : les données générées par vos machines doivent être accessibles à l’utilisateur qui les génère, et dès septembre 2026, les nouveaux produits devront intégrer cette capacité d’accès dès la conception. Pour un fabricant de matériel ou un éditeur agricole, c’est un changement de modèle : la donnée d’exploitation appartient d’abord à l’exploitant.
Le Cyber Resilience Act suit le même calendrier : notification des failles exploitées sous 24 heures dès le 11 septembre 2026, exigences de sécurité dès la conception pour les produits mis sur le marché fin 2027, avec la mise à jour à distance (OTA) comme prérequis de fait. Un capteur agricole qu’on ne peut pas mettre à jour à distance, sur un parc dispersé dans les campagnes, ne sera défendable ni juridiquement ni économiquement.
De l’électronique au firmware, de la plateforme à l’application, ces sujets se traitent ensemble, par une équipe qui a l’habitude du terrain. Découvrez notre approche des projets IoT.
Vous avez un projet d’IoT agricole ? Contactez-nous pour un échange gratuit et sans engagement. 👉 playmoweb.com/nous-contacter