ERP drone : le plan de réponse d'urgence du télépilote
Ce qu'est l'ERP d'une opération drone, en quoi il diffère des procédures d'urgence, et ce qu'il doit contenir.
Vous êtes opérateur ? Ajoutez votre fiche gratuitement →
L'ERP - Emergency Response Plan, plan de réponse d'urgence - est le document qui dit quoi faire une fois que l'on a perdu le contrôle d'une opération drone : qui prévenir, dans quel ordre, et comment limiter les conséquences d'une chute, d'une collision ou d'une fuite de l'appareil.
⚠️ En français, « ERP » désigne d'abord un établissement recevant du public. Les deux sigles se croisent souvent dans un même dossier, puisqu'un survol à proximité d'un ERP est un cas classique d'analyse de risque. Ici, ERP désigne toujours le plan d'urgence, et le sigle anglais est celui qu'emploient l'EASA, JARUS et les autorités.
Ce qu'il n'est pas : une procédure d'urgence
C'est la confusion la plus fréquente, et la méthode SORA la tranche nettement. Elle distingue trois niveaux de réponse :
- les procédures de contingence ramènent une situation anormale sous contrôle, par exemple une batterie qui faiblit ou une perte de liaison temporaire ;
- les procédures d'urgence traitent l'appareil lui-même quand on ne le contrôle plus : terminaison de vol, parachute, atterrissage forcé ;
- l'ERP commence là où l'appareil ne compte plus. Il traite les effets secondaires d'une perte de contrôle - un blessé, un départ de feu, un aéronef percuté - et coordonne la réponse avec les secours.
Autrement dit, une procédure d'urgence se joue sur la radiocommande. L'ERP se joue au téléphone. Le corps du SORA 2.5 l'écrit en toutes lettres : l'ERP ne traite pas du contrôle de l'aéronef.
Ce qu'il doit contenir
Le SORA 2.5 le range dans l'objectif de sécurité opérationnelle OSO #08 (procédures opérationnelles définies, validées et respectées). Son annexe E fixe un contenu minimum :
- la liste des situations d'urgence anticipées qui peuvent avoir des effets secondaires ;
- une procédure pour chacune, avec les critères qui permettent de reconnaître la situation ;
- la liste des contacts à joindre : contrôle aérien, police, pompiers, premiers secours.
Elle ajoute quatre qualités attendues. L'ERP doit être adapté à la situation, réduire effectivement les effets secondaires prévisibles, répartir clairement les rôles entre les membres de l'équipage, et être praticable et entraîné, pour qu'on puisse l'appliquer sous stress.
Le dernier point est celui qu'on oublie. Un ERP que personne n'a jamais déroulé n'a de plan que le nom.
Proportionné au risque, pas au formulaire
L'annexe E précise que l'ERP doit être proportionné aux effets secondaires possibles d'un impact au sol : un incendie, un dégagement de gaz toxique. Un drone de 900 grammes au-dessus d'un champ et un multirotor de 25 kilos au-dessus d'un site industriel n'appellent pas le même plan.
Le niveau de preuve suit le même raisonnement. Aux niveaux d'assurance bas, l'exploitant déclare que son ERP est adéquat. Au niveau d'assurance élevé, un exercice sur table est attendu, et un tiers compétent valide qu'il est représentatif. Cet exercice peut associer les tiers nommés dans le plan, comme les pompiers ou le gestionnaire du site.
Ce qui a changé avec le SORA 2.5
Dans les versions antérieures de la méthode, l'ERP comptait comme une mesure d'atténuation du risque au sol : en disposer pouvait abaisser la classe de risque. Le SORA 2.5 l'a retiré des atténuations et l'a rattaché aux procédures opérationnelles.
La conséquence est pratique. Un ERP ne fait plus baisser votre niveau d'exigence. Il fait partie de ce que vous devez démontrer, quel que soit ce niveau.
Un plan général, et une fiche par site
Un ERP utile tient en deux étages.
Le premier est général. Il vit dans le MANEX, le manuel d'exploitation : les situations anticipées, les procédures, les rôles, la chaîne d'alerte. Il change peu.
Le second est propre à chaque intervention. C'est lui qui sert sur le terrain :
- les coordonnées exactes du site, à dicter aux secours ;
- l'hôpital et la caserne les plus proches, avec leurs accès ;
- les contacts locaux : client, gestionnaire du site, organisme de contrôle aérien ;
- le point de rassemblement et l'accès des véhicules de secours ;
- les risques propres au lieu : produits stockés, ligne électrique, public présent.
Un ERP générique, recopié d'une mission à l'autre, échoue précisément là. Le jour où il sert, personne n'a le temps de chercher l'adresse de l'hôpital.
Quand il est exigé
En catégorie Ouverte, aucun ERP formel n'est demandé. Préparer les numéros utiles et l'adresse du site reste une bonne pratique.
En catégorie Spécifique, il fait partie du dossier : il est attendu au titre de l'OSO #08 dans une analyse SORA, et le manuel d'exploitation le porte. C'est l'une des pièces que l'autorité regarde, parce qu'elle dit si l'exploitant a pensé à l'après.
Ce qu'il faut en retenir
- L'ERP n'est pas une procédure de vol. Il commence quand l'appareil ne compte plus.
- Il contient au minimum les situations anticipées, une procédure pour chacune et les contacts à joindre.
- Il se proportionne aux effets secondaires possibles, pas à la taille du dossier.
- Il s'entraîne. Un plan jamais déroulé ne tient pas sous stress.
- Il se décline par site. C'est la fiche de terrain qui sauve du temps.
Pour aller plus loin
- SORA drone - la méthode d'analyse de risque qui exige l'ERP en catégorie Spécifique.
- MANEX - le manuel d'exploitation qui porte l'ERP général.
- JARUS - le groupement d'autorités qui publie la méthode SORA.