Pourquoi la robotique agricole échoue sans ingénierie de la sécurité fonctionnelle

Agricultural robotics does not usually fail because the algorithm is weak or because the prototype cannot move in a field. It fails because once the machine must operate near people, crops, implements, obstacles, network gaps and regulatory requirements, the project stops being only an autonomy problem and becomes a problème de sécurité fonctionnelle.

For founders, CTOs, production managers and machinery OEM teams, this changes the investment logic. If safety engineering is added after perception, navigation, and HMI have already been built, teams often face the redesign of the architecture, interfaces, validation plans, and even commercial timelines. Safety-based technical standards such as ISO 25119 et ISO 18497, conjointement avec Règlement (UE) 2023/1230, ne constituent pas de la paperasse autour du produit ; ils façonnent le produit lui-même.

Pourquoi les robots agricoles et leur sécurité revêtent-ils une telle importance aujourd'hui ?

La robotique agricole gagne du terrain car le secteur subit la pression des pénuries de main-d'œuvre, des exigences de durabilité et de la nécessité d'opérations de terrain plus précises. L'OCDE note que l'agriculture dans l'UE fournit plus de 30 millions d'emplois, yet faces an ageing and shrinking workforce. Meanwhile, the EU CAP Network, aside from labour shortages, also identifies interoperability issues, regulatory compliance, and farmers’ readiness as major barriers to the implementation of robotics and artificial intelligence.

That context matters because it clarifies why so many robotics initiatives receive attention, funding and pilot interest. It also explains why failure is expensive. In agriculture, a robot is not a lab system operating in a controlled aisle. It lives on farms and moves through mud, dust, variable light, crop rows, headlands, slopes, people, vehicles and attachments. The environment is dynamic, and the acceptable margin for unsafe behaviour is low.

Le problème principal : les équipes de robotique développent l'autonomie avant d'appliquer les exigences de sécurité

De nombreuses équipes commencent par une question technique pertinente : la machine peut-elle détecter, décider et agir ? C'est nécessaire, mais pas suffisant. En déploiement réel, la question plus difficile est différente : que doit faire la machine, et que ne doit-elle jamais faire, lorsque les capteurs se dégradent, que la communication chute, que la localisation dérive, qu'un opérateur s'approche ou qu'une fonction de sécurité est déclenchée ?

This is where projects begin to stall. A prototype can often demonstrate route following, crop detection, or targeted actuation. But once the programme moves towards validation, scaling or customer rollout, the team discovers that hazard analysis, safety-related control architecture, degraded modes, traceability and verification evidence were not built into the development process from the start. At that point, safety stops being a final review and becomes a redesign programme.

Ce qui échoue habituellement

Avant qu'une équipe robotique ne perçoive clairement le problème, celui-ci se manifeste souvent sous la forme d'un retard, d'une augmentation des coûts ou d'un « travail de certification imprévu ». En réalité, le schéma correspond généralement à l'un des cas suivants :

• La pile d'autonomie a été conçue sans frontières de sécurité claires entre la logique de mission et la logique de sécurité.
• La détection a été optimisée pour la performance des tâches, et non pour la vérification des fonctions de sécurité.
• Les flux HMI ont été conçus pour la commodité, et non pour une intervention sûre de l'opérateur.
• La gestion des défaillances était supposée, mais ni spécifiée, ni testée, ni documentée.
• Les équipes logicielles et les équipes de conformité ont travaillé en séquence plutôt qu'ensemble.

La conséquence commerciale est simple. Un système qui semble avancé dans des conditions de démonstration peut encore être immature en tant que produit.

Que signifie la sécurité fonctionnelle dans la robotique agricole ?

La sécurité fonctionnelle est souvent mal comprise comme une discipline de conformité étroite. En pratique, il s'agit d'une méthode d'ingénierie qui garantit qu'un système de contrôle exécute correctement les fonctions liées à la sécurité, même en conditions de défaillance. Dans les machines agricoles, L'ISO 25119 établit les principes généraux pour la conception et le développement des parties liées à la sécurité des systèmes de commande, souvent désigné sous le terme deSRP/CS.

Cela est particulièrement important en robotique car machines agricoles ne sont plus de simples actifs mécaniques dotés d'une logique de commande limitée. Ce sont des systèmes définis par logiciel qui combinent perception, planification, actionnement, connectivité et interaction avec l'opérateur. L'ISO 18497 étend la discussion aux machines avec des fonctions partiellement automatisées, semi-autonomes et autonomes, et traite explicitement les dangers significatifs dans le cadre de l'usage prévu et d'une mauvaise utilisation raisonnablement prévisible.

Une définition en langage clair

À première vue, le terme peut sembler abstrait, il est donc utile de l'énoncer simplement. La sécurité fonctionnelle pose la question suivante : si quelque chose ne va pas, la machine se déplacera-t-elle ou restera-t-elle dans un état sûr de manière prévisible ? Cela inclut l'arrêt, la limitation du mouvement, la désactivation d'un outil, la demande d'intervention humaine ou la prévention d'une condition de démarrage dangereuse.

Pourquoi est-ce différent de la qualité logicielle générale ?

Good software quality reduces bugs. Following Functional Safety standards reduces hazardous behaviour. A stable application can still be unsafe if it makes a wrong but deterministic decision during degraded sensing, timing drift, or actuator fault. That is why safety engineering needs its own concept phase, architecture discipline, verification method and evidence trail.

Normes techniques liées à la sécurité : ISO 25119, ISO 18497 et le règlement européen sur les machines

Les principales normes de sécurité pour la robotique agricole sont ISO 25119, ISO 18497 et la Règlement européen sur les machines. Ces trois références sont souvent mentionnées ensemble, mais elles n'ont pas la même fonction. Les équipes font de meilleurs choix de conception lorsqu'elles comprennent la différence dès le départ.

Ce que couvre chaque framework

This distinction is important because robotics teams often treat regulation as a late-stage legal matter. That is incorrect. The legal framework and the technical safety standards influence software partitioning, interfaces, fault responses, documentation, and validation strategy from the concept phase onward.

Une note sur le timing

La fenêtre de transition n'est pas théorique. Le règlement (UE) 2023/1230 est entré en vigueur après sa publication et s'appliquera à partir du 14 janvier 2027, certaines dispositions s'appliquant plus tôt. Les équipes qui construisent des systèmes destinés à un déploiement commercial, à une intégration OEM ou à des plans de mise à l'échelle dans l'UE doivent concevoir leurs solutions en tenant compte de cela dès maintenant, plutôt que d'attendre la fin réussie de la phase pilote.

La lecture pratique pour les équipes produit

For product teams, the implications are direct. If your roadmap includes autonomous navigation, remote supervision, automated implement control, human-machine interaction, or connected updates, then safety is no longer a document set around the machine. It is an integral part of the system design.

Pourquoi les projets de robotique agricole stagnent en pratique

The first reason is that agricultural environments are hard to model and even harder to bound. Weather changes visibility, crops change geometry, terrain changes traction, attachments change the system state, and human behaviour remains difficult to predict. Revues de recherche continuent d'identifier la sécurité, en particulier la détection humaine et l'exploitation sûre sur le terrain, comme un défi central de la robotique agricole.

La deuxième raison est que la robotique agricole est un problème de système de systèmes. Un produit peut inclure la navigation, le contrôle de machine, la perception, l'HMI, la télémétrie, données géospatiales, l'analytique cloud et les workflows de service. La sécurité doit être cohérente à travers ces couches. Une fonction de freinage sûre peut être compromise par une gestion d'état peu claire, une messagerie opérateur inadéquate ou un chemin de redémarrage non sécurisé.

The third reason is organisational. Prototype teams are often structured around speed, rather than certification capabilities. That is rational at the start, but it becomes dangerous once the architecture starts to solidify. Every month spent building autonomy without safety assumptions increases the risk of having to redo the work later.

Les points de blocage les plus courants

Un moyen pratique de repérer le danger consiste à rechercher les frictions répétées dans les mêmes domaines :

Ce schéma est courant car les équipes confondent performance opérationnelle et risque acceptable. En ingénierie de la sécurité, ces notions sont liées mais non identiques.

La sécurité fonctionnelle comme enjeu business, et non uniquement comme enjeu d'ingénierie

For production managers and OEM decision-makers, the issue is not only whether the robot can work. It is about whether the product can be industrialised, supported, insured, integrated, and sold at an acceptable level of risk. When safety is addressed late, product economics shift in several ways: timelines extend, test cycles multiply, hardware changes propagate back into software, and documentation effort becomes harder to reconstruct.

For investors, the signal is equally important. A robotics company that shows autonomy performance without a credible functional safety path may still be technically impressive, but it is not yet de-risked as a deployment business. In that sense, safety maturity is part of commercial maturity.

Où l'impact business apparaît en premier

Les premiers symptômes métier sont rarement étiquetés « sécurité fonctionnelle ». Ils se manifestent généralement sous la forme de :

• des prolongations répétées de projets pilotes au lieu d'une conversion commerciale,
• hésitation des clients concernant les modèles de supervision et de responsabilité,
• des discussions plus lentes avec les OEM car les hypothèses d'architecture ne sont pas claires,
• la difficulté de passer d'une configuration machine à une famille de produits plus large,
• la hausse des coûts de validation, de tests et de récupération de la documentation.

Ce que les différents groupes de parties prenantes gagnent à résoudre ce problème en amont

Dans la robotique agricole, chaque groupe de parties prenantes perçoit le même déficit de sécurité sous un angle différent.

Pour les responsables de production

Production managers need a machine that can move from prototype to repeatable delivery. For them, early functional safety reduces late engineering churn, helps stabilise bill of materials decisions, and improves confidence that manufacturing, commissioning, and service documentation will not change every few weeks. The benefit is fewer surprises when the product approaches the scale-up stage.

Pour les CTO

CTOs need architecture that remains coherent as product ambition grows. For them, safety-led design creates clearer boundaries between autonomy logic, safety logic, connectivity, and operator interaction. The benefits include lower rework, better verification discipline, and a product stack that can evolve without undermining core safety assumptions.

Pour les responsables techniques de produit

Technical product owners need a roadmap that aligns product goals with real delivery constraints. For them, functional safety turns vague risk into defined work packages: hazard analysis, safety requirements, traceability, verification planning, HMI behaviour, and evidence generation. The benefit is a backlog that supports deployment, not just demos.

Pour les responsables du numérique dans l'agriculture

Digital managers often sit between operations, suppliers, and transformation programmes. Functional safety standards can help them recognise why robotics cannot be treated like a normal software rollout. The benefits are better vendor evaluation, more realistic milestones, and stronger questions during procurement or partnership discussions.

Pour les fabricants de machines agricoles

OEMs and machinery producers need systems that can fit their product portfolio, certification path, and after-sales model. For them, functional safety is the bridge between innovation and marketable machinery. The benefit is faster alignment between embedded software, machine control, Technologie HMI, conformité et maintenabilité.

Pour les fondateurs et les investisseurs

Founders want speed, and investors want scale. Early safety engineering helps both, because it reduces the chance that a seemingly promising robotics platform will get trapped between pilot success and commercial readiness. The benefit is a clearer route from field trial to revenue-grade product.

Comparaison : robotique axée sur le prototype vs robotique axée sur la sécurité

Une comparaison directe permet de mieux voir la différence. Aucun des deux modèles ne garantit le succès, mais l'un d'eux permet une réduction structurelle des risques.

C'est là le compromis fondamental. Une approche axée sur le prototype semble plus rapide durant les premiers mois. Une approche axée sur la sécurité tend à être plus rapide sur l'ensemble du parcours vers un produit qui peut réellement être déployé, pris en charge et étendu.

Étape par étape : comment structurer un programme robotique plus sûr

Un processus clairement défini est utile, car de nombreuses équipes reconnaissent l'importance de la sécurité sans savoir comment l'intégrer. L'objectif de l'ingénierie de la sécurité fonctionnelle n'est pas de ralentir l'innovation, mais de prévenir le développement rapide d'un système défaillant.

1. Définir l'enveloppe opérationnelle dès le départ

Commencez par décrire où la machine est censée opérer, qui peut se trouver à proximité, quels outils sont impliqués et quelle variation environnementale est attendue. Cela semble évident, mais analyse de sécurité s'affaiblit lorsque « l'opération sur le terrain » est traitée comme un cas d'usage générique unique.

2. Séparer la logique de mission de la logique de sécurité

Ensuite, établissez une distinction architecturale explicite entre ce que le robot cherche à accomplir et ce qui doit le contraindre ou l'arrêter. Une machine peut continuer à améliorer sa pile d'autonomie, mais les décisions de sécurité ne doivent pas rester ambiguës au sein de cette pile.

3. Réalisez l'analyse des dangers avant que l'architecture ne se fige

L'analyse des dangers doit avoir lieu avant que les interfaces ne deviennent coûteuses à modifier. Si l'équipe attend que la navigation, l'HMI et l'actionnement soient intégrés, même de simples constats de sécurité peuvent imposer une refonte majeure.

4. Définir les états sûrs et les modes dégradés

Un robot ne devrait pas simplement « échouer en toute sécurité » comme un slogan. Il devrait être appliqué conformément aux réglementations de sécurité et disposent d'un comportement spécifié et testable pour la perte de capteur, la perte de communication, l'incertitude de localisation, les anomalies d'actionneur, la commande manuelle et les conditions de redémarrage.

5. Établir la traçabilité de l'exigence aux essais de validation

Une fois que les exigences de sécurité existent, chacune doit être traçable à travers la conception, la mise en œuvre et la vérification. C'est là que de nombreuses équipes fortement orientées logiciel rencontrent des difficultés, car le travail semble bureaucratique jusqu'à ce qu'elles aient besoin de preuves.

6. Traiter l'IHM comme une surface de sécurité

La vue opérateur, les alertes, la logique de reprise en main et la messagerie d'état ne sont pas des couches cosmétiques. Dans les systèmes d'automatisation, l'IHM détermine si un humain comprend l'état de la machine suffisamment rapidement pour intervenir correctement. Une approche appropriée deHMI agritech doit refléter clairement cette logique d'intégration : les interfaces doivent être connectées au comportement de la machine et aux données pertinentes, et non traitées comme des écrans autonomes.

7. Valider en gardant le déploiement à l'esprit

Enfin, validez non seulement la conformité technique mais aussi la voie d'accès au marché envisagée. Un pilote sur l'une des fermes n'est pas la même chose qu'une famille de produits déployée sur plusieurs machines, zones géographiques et variantes opérationnelles.

Étude de cas : du prototype terrain à une logique produit certifiable

Une étude de cas est utile ici car l'argument devient plus clair lorsqu'il est lié à une trajectoire robotique réelle. Spyrosoft a présenté des travaux avec Small Robot Company, une entreprise britannique d'agritech qui construit des robots destinés à transformer les opérations sur le terrain, en utilisant des technologies telles que Java, React et GeoServer.

Le contexte opérationnel public autour de ce programme aide à expliquer le défi d'échelle. Small Robot Company a rapporté des essais à la ferme à travers 118 hectares, en localisant 446 millions de plants de blé et identification 4,6 millions de mauvaises herbes, avec imagerie à0,39 mm par pixel à partir d'une configuration à six caméras. Cela équivaut à environ 3,78 millions de plants par hectare, 38 983 adventices identifiées par hectare, et un ratio adventices/plantes d'environ 1.03%.

Pourquoi ces chiffres comptent

Those figures are not just agronomic or computer vision metrics. They show the operational density with which safety engineering must coexist. When a system is making decisions at the plant level across millions of field objects, safety cannot be bolted on as a final gate. It must shape how sensing confidence, actuation authority, operator supervision, and degraded mode logic are handled. A system operating at that level of granularity still needs predictable behaviour when localisation is uncertain, when a person enters the work zone, or when a subsystem becomes unreliable.

Interprétation pratique des KPI

Une façon utile d'aborder ce cas est de s'appuyer sur les KPI de déploiement plutôt que sur de simples métriques d'IA :

La leçon pour les OEM et les fondateurs en robotique

La leçon n'est pas que la robotique avancée est trop risquée. La leçon est qu'une fois qu'une machine passe d'une capacité prometteuse à une intention de déploiement réel, le test de maturité clé devient : le système peut-il démontrer un comportement sûr par conception, et pas seulement une intelligence opérationnelle par démonstration ?

Comment Spyrosoft peut soutenir les normes de sécurité fonctionnelle dans ce domaine

Thanks to our expertise in both agritech and Functional Safety, we can provide engineering and software expertise for robotics, automation, and control systems used in agricultural machinery, including autonomous tractors, robotic harvesters, and specialist agribots, with an emphasis on safe, reliable systems aligned with international safety standards and requirements.

Où Spyrosoft crée de la valeur

Grâce à notre vaste expérience, nous pouvons gérer des projets où le défi se situe entre l'ambition logicielle et la réalité du déploiement. Dans le contexte de la robotique agricole, cela signifie un accompagnement dans des domaines tels que :

• logiciel embarqué et de contrôle pour le comportement des machines et les fonctions liées à la sécurité,
• conception HMI pour une conscience claire de l'état de l'opérateur et son intervention,
• intégration entre l'autonomie, la télématique, le cloud et les sous-systèmes des machines,
• l'ingénierie des exigences, la traçabilité et la discipline de vérification,
• une livraison de produit conforme aux attentes de niveau certification plutôt qu'aux attentes de simple démonstration.

Bénéfices pour différents publics

For CTOs, this means architecture that is easier to scale and defend. For machinery manufacturers, it means stronger alignment between product software, machine logic and compliance expectations. For technical product owners, it means a clearer decomposition of safety-critical work into implementable backlog items. And for investors and founders, it means a more credible path from prototype traction to industrial readiness.

Points pratiques et conseils pour les équipes de robotique sur l'évaluation de la sécurité fonctionnelle

Since safety topics become clearer when broken down into specific checkpoints, below we present notes and questions that can help your team prepare a risk assessment and determine whether safety remains merely an intention or has already become an integral part of the delivery.

Liste de contrôle de préparation du produit

• Avons-nous défini le domaine de fonctionnement avec suffisamment de précision pour analyser correctement les dangers ?
• Avons-nous séparé la logique de mission de la logique de sécurité dans l'architecture ?
• Avons-nous identifié les fonctions liées à la sécurité, les déclencheurs et les états sûrs ?
• Avons-nous défini des modes dégradés pour la détection, la localisation, les communications et l'actionnement ?
• Avons-nous conçu explicitement les flux d'intervention de l'opérateur et de redémarrage ?
• Disposons-nous d'une traçabilité depuis l'exigence de sécurité jusqu'aux tests, en passant par la mise en œuvre ?
• Notre HMI fait-elle partie du concept de sécurité, et pas seulement de l'ergonomie ?
• Concevons-nous pour la voie réglementaire européenne que nous avons réellement l'intention d'utiliser ?
• Pouvons-nous expliquer clairement notre dossier de sécurité à un OEM, un auditeur, un partenaire ou un investisseur ?

Signes avant-coureurs d'une dérive du programme

• Le prototype fonctionne, mais personne ne peut expliquer précisément l'état sûr.
• Les tests sont approfondis, mais les critères de réussite ne sont pas liés aux exigences de sécurité.
• L'autonomie et la conformité sont gérées par des équipes distinctes avec peu de responsabilité partagée.
• Un mécanisme de dérogation opérateur existe, mais l'état du système est difficile à interpréter.
• Les jalons produit se concentrent sur les fonctionnalités, pas sur les risques de déploiement vérifiés.

Synthèse des besoins de sécurité fonctionnelle en robotique agricole

Agricultural robotics fails without functional safety engineering because the machine doesn’t live in a closed technical problem. It lives in a real operational environment shaped by people, implements, variable terrain, uncertain sensing, service conditions, and legal obligations. That is precisely why companies should make a decisive shift from the question “Can the robot perform this task?” to the question “Can the robot perform this task safely, predictably, and repeatedly under real-world conditions?

ISO 25119, ISO 18497 and the EU Machinery Regulation are key because they force that question into the design process. Teams that treat them as end-stage compliance tend to discover hidden architecture debts too late. Teams that build around them earlier are usually better positioned to industrialise, integrate, and scale.

Pour Spyrosoft, c'est précisément là que la valeur de l'ingénierie devient visible. Notre attention ne porte pas uniquement sur la construction technologie logicielle agritech that works as a demo, but also on supporting the creation of robotics software, interfaces, and integrations that are robust enough for real-world product use. In agricultural robotics, that is the difference between an impressive idea for automation and deployable machinery.

If you are evaluating an autonomous or semi-autonomous agricultural machine programme, review the safety architecture before you expand the feature roadmap or reach out to our experts for assistance in that area. And remember to do this sooner rather than later to avoid unexpected risks or costs, and ensure system safety.

Glossaire

Sécurité fonctionnelle – Une discipline qui garantit que les fonctions de contrôle liées à la sécurité se comportent correctement, y compris dans des conditions de défaillance.

SRP/CS – Parties des systèmes de commande liées à la sécurité. En pratique, il s'agit des parties du système de commande d'une machine qui exécutent des fonctions de sécurité.

État sûr – Un état de machine défini qui réduit le risque, tel qu'un arrêt contrôlé, une limitation de mouvement ou une désactivation de l'actionnement.

Mode dégradé – Un mode de fonctionnement réduit utilisé lorsqu'une partie du système devient indisponible ou peu fiable, tout en maintenant un risque acceptable.

Analyse des dangers – Un processus structuré pour identifier les situations dangereuses, les causes et les besoins de réduction des risques.

HMI – Interface homme-machine. Dans les machines agricoles, cela comprend les écrans, les commandes, les alertes et les chemins d'intervention utilisés par les opérateurs.

Enveloppe opérationnelle – Les conditions dans lesquelles le robot est destiné à opérer, notamment le terrain, les cultures, les conditions météorologiques, le modèle de supervision et les acteurs à proximité.

Sources

ISO, ISO 25119-1:2018 – Tracteurs et matériels agricoles et forestiers – Parties des systèmes de commande relatives à la sécurité – Partie 1 : Principes généraux de conception et de développement. (WMS)

ISO, ISO 18497-1:2024 – Machines agricoles et tracteurs – Sécurité des machines partiellement automatisées, semi-autonomes et autonomes – Partie 1 : Principes de conception des machines et vocabulaire. (WMS)

EUR-Lex, Règlement (UE) 2023/1230 sur les machines. (EUR-Lex)

FAQ

Pourquoi la sécurité fonctionnelle est-elle si importante dans la robotique agricole ?

expand_more

Functional Safety is crucial because agricultural robots operate in open, variable and sometimes hazardous environments. The combination of moving machinery, attachments, people, crops and changing field conditions creates risks that cannot be handled by autonomy performance alone.

Quelle est la différence entre ISO 25119 et ISO 18497 ?

expand_more

L'ISO 25119 se concentre sur les parties liées à la sécurité des systèmes de commande dans les machines agricoles. L'ISO 18497 se concentre sur la sécurité des machines partiellement automatisées, semi-autonomes et autonomes, ainsi que sur les dangers associés à ces modes de fonctionnement.

Quand le nouveau règlement européen sur les machines entre-t-il en vigueur ?

expand_more

Le règlement (UE) 2023/1230 s'applique à partir du 14 janvier 2027, certaines dispositions s'appliquant plus tôt.

Un modèle d'IA performant peut-il compenser une ingénierie de sécurité défaillante ?

expand_more

Non. Un modèle d'IA performant peut améliorer la perception ou l'aide à la décision, mais il ne remplace pas l'architecture de sécurité, les états sûrs définis, la traçabilité, la vérification et la conformité réglementaire.

Quelle est la plus grande erreur que commettent les start-ups en robotique ?

expand_more

Une erreur courante consiste à considérer la sécurité comme un élément pouvant être documenté une fois l'autonomie déjà conçue. En pratique, un travail de sécurité tardif révèle souvent des problèmes d'architecture coûteux à corriger.

Que doit demander un OEM à un fournisseur de robotique avant un pilote ?

expand_more

Demandez comment les fonctions liées à la sécurité sont définies, comment les modes dégradés sont gérés, comment fonctionne l'intervention de l'opérateur, quelles normes guident le développement et comment les preuves de vérification sont produites. Ces questions sont souvent plus révélatrices qu'une démonstration soignée.