Le GRC final est-il stabilisé ?
TRX-Drone doit vérifier que les mitigations sol retenues sont documentées et que le niveau de risque sol final ne repose pas sur une hypothèse fragile.
Parcours fictif TRX-Drone — étape 15/16
SORA : déduire le SAIL et structurer les OSO
Après avoir déterminé séparément le GRC final et l’ARC final, TRX-Drone peut déduire le SAIL de l’opération. Cette étape ne doit pas être abordée comme une recherche du niveau le plus bas possible. Le SAIL traduit le niveau d’exigence associé au risque résiduel de l’opération.
Une fois le SAIL établi, TRX-Drone doit organiser la démonstration OSO. Les OSO ne sont pas une liste décorative à copier dans le dossier. Ils structurent les preuves attendues : organisation, compétences, procédures, moyens techniques, maintenance, gestion des situations anormales et robustesse de l’exploitation.
Dans le cas client fictif traité par TRX-Drone, l’objectif pédagogique est de montrer comment passer des résultats de risque à une démonstration opérationnelle défendable. Le SAIL donne le niveau d’exigence ; les OSO obligent à prouver que l’exploitant sait réellement tenir ce niveau.
Rappel de l’étape précédente
À l’étape précédente, TRX-Drone a déterminé l’ARC final. Cette page montre comment déduire le SAIL et structurer la démonstration OSO.
Le SAIL est une conséquence, pas un objectif
Mini-schéma — du risque consolidé aux preuves
- GRC final + ARC final déduire le SAIL avec la table applicable
- SAIL identifier le niveau d’exigence applicable
- OSO structurer les objectifs de sécurité à démontrer
- Preuves attendues relier MANEX, procédures, compétences, technique et traçabilité
Le SAIL résulte de la combinaison entre le risque sol final et le risque air final. Il ne doit pas être choisi à l’avance pour rendre le dossier plus simple. Si TRX-Drone cherche à obtenir un SAIL plus favorable en sous-estimant le GRC ou l’ARC, elle fragilise toute la démonstration.
Le raisonnement doit donc rester lisible : iGRC, mitigations sol, GRC final, iARC, atténuations air, ARC final, puis SAIL. Chaque résultat doit pouvoir être relu depuis les hypothèses, les cartes, les notes de calcul et les preuves associées.
GRC final + ARC final → SAIL
SAIL → niveau de robustesse attendu pour les OSO
OSO → preuves opérationnelles, techniques et organisationnelles à produire
SAIL → niveau de robustesse attendu pour les OSO
OSO → preuves opérationnelles, techniques et organisationnelles à produire
Six questions avant de retenir le SAIL
L’ARC final est-il justifié ?
Le risque air final doit être relié au trafic, à la hauteur, au volume, aux sources consultées et aux atténuations recevables.
La table applicable est-elle utilisée ?
La détermination du SAIL doit être faite avec la table officielle applicable, et non avec un tableau pédagogique ou une interprétation simplifiée.
Les hypothèses sont-elles cohérentes ?
KML/KMZ, documentation de l’opération, notes de calcul, volumes, procédures et limites d’exploitation doivent raconter la même opération.
Les limites sont-elles reconnues ?
Un dossier crédible explique aussi ce que les mitigations ne couvrent pas : intrusion, trafic imprévu, météo, délai de réaction ou défaillance humaine.
Les preuves OSO existent-elles ?
Un SAIL plus exigeant impose une démonstration plus robuste. TRX-Drone doit vérifier qu’elle peut réellement produire les preuves attendues.
Table de consolidation GRC / ARC / SAIL
Cette table ne remplace pas la table officielle SORA. Elle sert à préparer la lecture du dossier et à éviter que le SAIL soit présenté comme une valeur isolée.
| Élément | Résultat TRX-Drone | Source ou preuve | Point de vigilance |
|---|---|---|---|
| GRC final | À reporter depuis l’étape 5 | iGRC, mitigations sol, preuves, limites reconnues | Ne pas reprendre une mitigation sol non recevable |
| ARC final | À reporter depuis l’étape 8 | iARC, atténuations air, trafic, hauteur, volume, sources | Ne pas forcer une réduction d’ARC pour faciliter le SAIL |
| SAIL | À déduire avec la table applicable | Table SORA 2.5 applicable au dossier | Le SAIL est une conséquence, pas un objectif commercial ou administratif |
| OSO applicables | À identifier selon le SAIL | Table OSO applicable et niveau de robustesse attendu | Ne pas lister les OSO sans preuve associée |
| Preuves disponibles | À inventorier | MANEX, procédures, compétences, essais, maintenance, organisation | Identifier les écarts avant le dépôt du dossier |
Comprendre le rôle des OSO
Les OSO traduisent les objectifs de sécurité opérationnelle attendus pour l’opération. Ils permettent de relier le niveau de risque retenu à des preuves concrètes. Plus le SAIL est exigeant, plus la démonstration attendue peut devenir structurée, documentée et robuste.
Pour TRX-Drone, le risque serait de traiter les OSO comme un tableau à cocher. Une case cochée ne prouve rien si le dossier ne contient pas la procédure, la compétence, l’essai, le manuel, l’organisation ou le moyen technique qui permet de soutenir l’affirmation.
Six familles de preuves OSO à organiser
Organisation
Responsabilités, chaîne de décision, préparation de mission, gestion documentaire, surveillance interne et capacité à interrompre une opération.
Compétences
Formation, expérience, briefing, maintien de compétence, rôle des observateurs, qualifications et aptitude des personnes essentielles à l’opération.
Procédures
Procédures normales, anormales et d’urgence, critères d’arrêt, gestion météo, intrusion, perte de liaison, dérive ou trafic aérien détecté.
Moyens techniques
Aéronef, station sol, liaisons, géovigilance, limitation de volume, confinement, dispositif de terminaison ou moyens de surveillance selon le cas.
Maintenance et configuration
Suivi de configuration, entretien, mises à jour, vérifications prévol, traçabilité, gestion des anomalies et retour d’expérience.
Preuves et traçabilité
MANEX, annexes, comptes rendus, essais, journaux, checklists, cartographies, échanges avec tiers et documents justificatifs.
Table de préparation de la démonstration OSO
TRX-Drone peut préparer une table de correspondance entre chaque OSO applicable, le niveau de robustesse attendu et la preuve disponible. Cette table permet de repérer rapidement les points faibles avant de finaliser le dossier.
| Bloc de démonstration | Question à poser | Preuve attendue | Écart possible |
|---|---|---|---|
| Procédure normale | La mission nominale est-elle décrite de manière exploitable ? | MANEX, ConOps, checklists, briefing, cartographie | Procédure trop générale ou non adaptée au cas réel |
| Procédure d’urgence | Les situations anormales sont-elles traitées avec des critères d’action ? | Procédures, seuils de déclenchement, responsabilités, entraînement | Absence de délai de réaction ou de critère d’interruption |
| Compétences | Les personnes essentielles savent-elles appliquer les procédures ? | Attestations, formations, expérience, briefing, maintien de compétence | Compétence déclarée mais non démontrée |
| Moyens techniques | Les moyens annoncés existent-ils et sont-ils disponibles ? | Fiches techniques, configuration, essais, photos, rapports, limites connues | Moyen décrit sans preuve de disponibilité ou d’efficacité |
| Maintenance | La configuration du système est-elle maîtrisée dans le temps ? | Registre, suivi d’entretien, anomalies, mises à jour, contrôle prévol | Absence de traçabilité ou de gestion de configuration |
| Surveillance opérationnelle | L’exploitant détecte-t-il les écarts et améliore-t-il ses pratiques ? | Retour d’expérience, comptes rendus, analyse d’incidents, actions correctives | Dossier figé sans boucle d’amélioration |
ERP et réponse d’urgence
Avant l’ERP : relier les OSO à la réponse d’urgence
L’ERP ne doit pas apparaître comme une pièce isolée ajoutée à la fin du dossier. À ce stade du parcours, TRX-Drone a déterminé le SAIL et commencé à structurer les OSO. La réponse d’urgence doit donc être comprise comme une partie de la démonstration : organisation, responsabilités, procédures, moyens de communication, entraînement et traçabilité.
L’encadré ERP qui suit sert à montrer comment cette capacité de réaction s’inscrit dans la continuité de l’analyse SORA, et non comme une annexe décorative ou déconnectée du reste du dossier.
ERP : le plan de réponse d’urgence reste une preuve opérationnelle
Même si la SORA 2.5 ne traite plus l’ERP comme dans la logique antérieure de la SORA 2.0, TRX-Drone ne doit pas faire disparaître le plan de réponse d’urgence du dossier. L’autorité peut toujours attendre une démonstration claire de la manière dont l’exploitant réagit lorsqu’une situation sort du cadre nominal.
L’ERP, au sens Emergency Response Plan, ne doit pas être confondu avec un établissement recevant du public. Il décrit les réactions attendues face à une perte de contrôle, une sortie de volume, un crash, une intrusion de tiers, une blessure, une perte de liaison, une dérive vers une zone adjacente ou une situation nécessitant une alerte.
| Situation à traiter | Question à poser | Preuve attendue | Point de vigilance |
|---|---|---|---|
| Perte de contrôle ou sortie de volume | Qui décide, à quel seuil, et quelle action est engagée ? | Procédure d’urgence, critères d’arrêt, responsabilités, entraînement | Éviter une procédure théorique sans délai d’action réaliste |
| Crash ou impact au sol | Comment sécuriser la zone et déclencher l’alerte ? | Consignes terrain, contacts utiles, conduite à tenir, traçabilité | Prévoir aussi les tiers non impliqués et les zones adjacentes |
| Atteinte possible d’une zone sensible | Que faire si l’UAS se dirige vers une zone plus exposée ? | Plan d’urgence, interruption, confinement, alerte interne ou externe | Ne pas limiter le raisonnement au volume nominal |
| Échange avec l’autorité ou un tiers | Qui informe, avec quel contenu, et comment la réponse est-elle tracée ? | Fiche réflexe, registre, compte rendu, suivi des actions correctives | Une réponse non tracée devient difficile à défendre |
Ne pas confondre conformité documentaire et capacité réelle
Une démonstration OSO ne doit pas seulement montrer que TRX-Drone sait écrire un dossier. Elle doit montrer que l’exploitant peut réellement conduire l’opération avec le niveau de robustesse attendu. La qualité documentaire est nécessaire, mais elle ne remplace pas la capacité opérationnelle.
Cette distinction est importante dans une pré-étude. Si le SAIL déduit impose des preuves que l’exploitant ne peut pas produire, il vaut mieux l’identifier avant le dépôt du dossier. Cela peut conduire à modifier l’opération, à renforcer les moyens, à réduire le volume ou à renoncer à l’opération telle qu’elle était envisagée.
Six erreurs fréquentes sur SAIL et OSO
Viser un SAIL
Le SAIL ne doit pas être choisi à l’avance. Il est la conséquence du GRC final et de l’ARC final.
Minimiser les risques
Sous-estimer le GRC ou l’ARC pour réduire le SAIL rend le dossier fragile et difficile à défendre.
Cocher les OSO
Les OSO ne sont pas de simples cases. Chaque objectif applicable doit être relié à une preuve.
Oublier la robustesse
Le niveau attendu ne porte pas seulement sur l’existence d’une mesure, mais aussi sur sa fiabilité et son assurance.
Négliger les preuves
Une affirmation non documentée ne suffit pas, même si elle est cohérente dans le texte du dossier.
Découvrir trop tard les écarts
Les manques de preuve doivent être identifiés avant le dépôt, pas pendant l’instruction.
Préparer la page finale : dossier, MANEX, preuves et METEOR
À la fin de cette étape, TRX-Drone doit disposer d’une vision claire : GRC final, ARC final, SAIL, OSO applicables, preuves disponibles et écarts à traiter. La dernière page du parcours pourra alors expliquer comment transformer cette analyse en dossier final.
Le dossier final devra faire le lien entre la SORA, le MANEX, les annexes, les preuves, la cartographie, les notes de calcul, les procédures et les échanges avec l’autorité. C’est cette cohérence d’ensemble qui rendra la demande lisible.
Dernière mise à jour : 18 mai 2026