L’objectif de la mission
L’exploitant doit distinguer ce que le client souhaite obtenir, ce qui est techniquement nécessaire et ce qui est réglementairement défendable.
Parcours fictif TRX-Drone — étape 7/16
SORA : démarrer l’analyse en documentant l’opération envisagée
Dans le parcours précédent, TRX-Drone a vérifié que la mission demandée ne pouvait pas être traitée comme une simple opération en catégorie ouverte, ni être ramenée sans précaution à un scénario standard. Le PDRA a ensuite été étudié comme une voie possible, mais l’analyse fait apparaître une limite : le cadre prédéfini ne couvre pas suffisamment la réalité opérationnelle.
Cette première page ouvre donc une variante du cas fictif : TRX-Drone ne considère plus la SORA comme un échec du PDRA, mais comme la méthode adaptée lorsque l’opération doit être analysée dans son contexte propre. Le point de départ n’est pas encore le calcul du risque. Le point de départ est la documentation précise de l’opération envisagée.
Dans la SORA 2.5, cette première étape correspond à la documentation de l’opération envisagée. Elle reprend l’idée du concept d’opérations, souvent appelé ConOps dans la SORA 2.0 et dans les usages professionnels. Le terme ConOps reste utile pour comprendre la logique, mais la page utilise désormais la terminologie plus actuelle.
Repère — entrée dans l’analyse SORA
Les limites du cadre PDRA imposent maintenant de reprendre l’opération selon la méthode SORA. TRX-Drone repart du ConOps réel pour documenter l’opération envisagée avant d’analyser les risques.
Pourquoi le PDRA ne suffit plus dans cette variante
Dans la première version de l’analyse, TRX-Drone cherchait à savoir si la mission pouvait entrer dans un cadre prédéfini. Ce réflexe est sain : il évite de lancer une SORA lorsque l’opération correspond déjà à un scénario plus simple ou à un PDRA utilisable. Mais le raisonnement doit aussi accepter l’inverse : lorsque les hypothèses du cadre prédéfini ne tiennent pas, il ne faut pas forcer le dossier.
Dans cette variante, plusieurs éléments conduisent TRX-Drone à ouvrir une analyse SORA : l’environnement réel est plus hétérogène que prévu, les tiers ne peuvent pas être écartés de manière simple, l’espace aérien doit être analysé avec précision, et les limites d’exploitation ne peuvent pas être résumées par une simple référence à un cadre prédéfini.
La SORA devient alors la méthode de clarification. Elle oblige l’exploitant à documenter l’opération, à identifier ses hypothèses, à évaluer ses risques, puis à démontrer que les mesures proposées sont cohérentes avec le niveau de risque réellement retenu.
SORA : documenter avant de justifier
Note terminologique — ConOps et SORA 2.5
Le terme ConOps reste utile pour faire le lien avec les usages professionnels et certains documents encore utilisés par les exploitants ou l’autorité. Dans la SORA 2.5, l’EASA privilégie toutefois la logique de documentation de l’opération proposée et de description opérationnelle détaillée. Dans ce parcours, ConOps doit donc être compris comme un repère pédagogique, non comme le libellé unique à employer dans un dossier SORA 2.5.
La documentation de l’opération envisagée n’est pas un simple préambule. Elle constitue le socle de l’analyse. Si l’opération est mal décrite, le reste du dossier devient fragile : le volume d’exploitation sera imprécis, les zones associées seront discutables, le risque sol sera mal apprécié, le risque air sera mal positionné et les OSO risqueront d’être traités comme une liste administrative plutôt que comme une démonstration de sécurité.
Dans le cas de TRX-Drone, ce travail ne repart pas de zéro. La vérification du PDRA a déjà conduit l’exploitant à décrire la mission, le site, le drone, les limites opérationnelles et les principales hypothèses. Cette base reste utile pour la SORA. Elle doit simplement être reprise avec un niveau de précision supérieur, car la SORA ne se contente plus de vérifier l’entrée dans un cadre prédéfini : elle analyse l’opération dans son contexte propre.
Pour TRX-Drone, documenter l’opération consiste à répondre à une question simple en apparence : quelle opération exacte veut-on autoriser ? Cela suppose de préciser le but de la mission, le site, les trajectoires envisagées, les hauteurs, les distances, les durées, la fréquence, le type d’aéronef, les personnes impliquées, les personnes non impliquées potentiellement exposées, l’organisation de l’équipe et les limites au-delà desquelles la mission ne sera pas réalisée.
Cette description doit rester opérationnelle. Elle ne doit pas promettre plus que ce que l’exploitant sait tenir. Elle ne doit pas non plus rester vague pour préserver une liberté apparente. Plus la documentation initiale est floue, plus l’analyse du risque devient incertaine.
Ce que TRX-Drone doit stabiliser dès le départ
Le site et son environnement
Le dossier doit décrire le lieu réel : infrastructures, voies de circulation, accès, zones sensibles, obstacles, présence possible de tiers et contraintes locales.
Le mode d’exploitation
VLOS, BVLOS, trajectoires, hauteurs, distances, horaires, fréquence des vols et organisation de l’équipe doivent être explicités sans approximation excessive.
Les moyens techniques
Le drone, ses fonctions utiles, ses limites, ses systèmes de sécurité et les preuves disponibles doivent être mis en relation avec l’opération envisagée.
Les limites de mission
Une bonne documentation précise aussi ce qui n’est pas fait : conditions météo refusées, zones exclues, cas d’arrêt, limites de performance et critères de report.
Les hypothèses critiques
Toute hypothèse utilisée ensuite dans l’analyse du risque doit pouvoir être retrouvée dans la description de l’opération et, si possible, être étayée.
Préparer les notes de calcul dès l’étape 1
La documentation de l’opération envisagée prépare aussi les notes de calcul qui apparaîtront dans les étapes suivantes. TRX-Drone doit donc identifier très tôt les données qui serviront à dimensionner les volumes et à déterminer le risque sol : configuration de l’aéronef, masse retenue, dimension caractéristique, vitesse maximale, autonomie utile, limites de vent, scénarios d’écart et conditions d’interruption.
Ces données ne sont pas encore exploitées dans cette première page. Elles doivent simplement être repérées, car elles seront utilisées ensuite pour définir la géographie de vol, le volume de contingence, la zone tampon sol, l’empreinte iGRC, la densité de population exposée et, si nécessaire, une note complémentaire sur l’énergie cinétique à l’impact.
Cette anticipation évite un défaut classique : rédiger une description générale de mission puis découvrir trop tard que les valeurs techniques nécessaires à l’analyse ne sont pas disponibles, pas justifiées ou pas cohérentes avec l’opération réellement envisagée.
La bonne question : qu’est-ce qui doit être autorisé ?
TRX-Drone ne doit pas documenter l’opération pour montrer immédiatement que la mission est acceptable. Elle doit d’abord documenter ce que la mission est réellement. La démonstration viendra ensuite. Cette distinction est importante, car un dossier trop orienté vers la conclusion peut masquer les vrais écarts et conduire à une instruction difficile.
Dans une SORA, les choix ultérieurs découlent de cette première description. Le volume d’exploitation, le volume de contingence, les zones tampon, le risque sol, le risque air, le niveau SAIL et les OSO n’ont de sens que si l’opération de départ est claire. La documentation de l’opération envisagée est donc moins une formalité qu’un acte de cadrage.
Point de vigilance pour l’exploitant
Le piège classique consiste à commencer par chercher un tableau, une valeur de GRC, une valeur d’ARC ou un niveau SAIL. Cette approche donne l’impression d’avancer, mais elle inverse la logique. Avant d’aboutir à une classe de risque, TRX-Drone doit être capable de décrire son opération de manière précise, vérifiable et cohérente.
Une autorité ne se prononce pas seulement sur des chiffres. Elle examine la cohérence d’ensemble : l’opération décrite, les hypothèses retenues, les preuves fournies, les mesures proposées et la capacité de l’exploitant à les appliquer réellement.
Dernière mise à jour : 18 mai 2026